基幹システムは重要データを扱うからこそ、リプレースにも慎重にならざるを得ない。過去資産は各企業のノウハウの集合体であり、人的資産と同じくらい重要な資産である。例えば、日本を代表する超巨大企業、トヨタ自動車では、多くの情報システムでクラウドサービスを採用する一方、本社が持つ旧資産今後も活用していく方針を採っている(関連記事)。
SPARC M10は既存UNIXサーバが持つ資産を、そのまま集約するために複数レイヤで仮想化する機能を持つ。
先の記事でも紹介したが、SPARC M10はOracle Solaris 10および11が使える。このため、ハードウェア分割、Oracle VM(Oracle VM for SPARC)を使った論理的な仮想化、SolarisゾーンによるOSより上位での仮想化という3つの層での仮想化に対応できる。
このことの意味するところは大きい。
既存UNIX資産の集約はOracle VMによる仮想化技術を活用して集約が可能になる上、Solaris 8/9などの旧OS環境もSolarisゾーンを活用した「Oracle Solaris Legacy Containers」技術で仮想的に移植できる。
ここで、「Oracle Solaris Legacy Containers」の概念は重要だ。ハードウェアに依存するドライバなどは、Solaris 10のものを活用しながら、旧資産をそのまま仮想化技術を使って乗せかえることができる。
また、Oracle VMやSolarisゾーンで仮想化されたシステムは、一般的なVMwareなどの仮想化技術と異なり、CPUやメモリ領域はダイレクトにゲストOSにマッピングされており、I/Oも完全に独立させることが可能なので、オーバーヘッドの問題は考慮しなくて済む。SPARC64 Xチップ自体の処理が高速化していることを考慮すれば、場合によっては旧資産を移しかえるだけでレスポンス性能が向上するケースも多いと考えられる。
「SPARC64プロセッサ用のOracle VMは、物理的なパーティションとほぼ変わらないパフォーマンスと信頼性を得られるのです」(志賀氏)
先に大量ノードによる並列処理を可能にするアーキテクチャであることを紹介したが、既存の基幹システムでは16コア以下のシステムも多い。そこで、これらの仮想化機能を利用し、例えば4コアずつをおのおののシステムに振り分けることも考えられる。
システムとしてはゲストOSのプロセッサやメモリ、I/Oを独立して配置できるため、障害が発生した場合であっても、別のCPUコア上のシステムに影響を与えることはない。
こうなるとシステムあたりのCPUやメモリというのは、システム上抽象化し、合理的な計画の下で再配分できるようになる。つまり、あるシステムに対して将来の負荷やピークの負荷を考慮して最大値のメモリやCPUを割り当て、稼働率が10%などというムダは回避できる。システム導入時には、最低限の環境でスタートし、システム稼働の最終段階で、実際に今必要なハードウェアスペックを割り当て、余剰や不足があれば、稼働後に動的に変更を行える。この部分はSolarisが以前から提供している、CPU、メモリ、I/Oをサーバ稼働中に増設したり削減する機構を活用して、システム稼働中にハードウェアを自由に抜き差ししてもソフトウェアを安全に動作させられる仕組みだ。
停止することのできないシステムにおいて、この柔軟さを得られるのはSolarisというOSを活用する大きな利点となるだろう。
Copyright © ITmedia, Inc. All Rights Reserved.