| Japan Worldwide |
|
| Japan Worldwide |
 |
 |
 |
|
 |
|
『仮想化』の未来を考える
今回は、仮想化について再び話題にします。私の書いていることに根拠がない、と熱心な読者が思われるといけないので、私がとりあげている一連の技術の積み重ねが、データセンタのコスト削減やハードウェア利用率の改善、アプリケーションの可用性及びパフォーマンス向上に貢献することになるということについて説明します。 最近、サンのチップマルチスレッド化プロセッサによるデータセンタ要件の緩和、オープンソースとOpenSolarisによるセキュリティ及びアプリケーションパフォーマンスの向上、またオープンソースのミドルウェアによる過去の投資の最大限の活用という話題をとりあげました。
ここでは、この積み重ねを少しさかのぼって、今日の企業の最新の話題、『仮想化』をとりあげます。 基本的な見方では、『仮想化』の目的は、土台のハードウェアからコンピューティング資源を抽出することにあります。仮想マシンは、そのようなものとして登場し、最近は仮想化とほぼ同義になっています。しかし、仮想マシンは決して「究極」の仮想化ではありません。SolarisコンテナのようなOSによる仮想化の方が重要な役割を担っています。もっと広い見方をすると、グリッドの方が、アプリケーションの開発・配信方法を劇的に転換させる、広範囲に及ぶ仮想化及び共有アーキテクチャになる可能性があります。 企業から見た仮想化の合理性 データセンタにおけるハードウェアの保守費用が高くなることは秘密でも何でもありません。電力、空調、設置スペースのコストは、IT予算の3つの災いです。たいていの企業がピーク負荷に備えますが、ピーク時間は四半期または年度の終わりにまとめてやってくる傾向があり、残りの時間のハードウェア利用率は10〜15%あたりをさまよいます。この結果、重要なリソースが使われないままになり、資本、電力及びスペースの莫大な無駄になります。 大きなサーバファームの管理では、別のコストの高騰も生まれています。ハードウェアの価格が下がる一方で、管理コストは上昇し続けています。このため、大規模データセンタで生じる直接経費のほかに、監視、保守する物理マシン数の削減が、仮想化技術を導入するもう一つの動機になっています（当然のこととして、仮想マシンの管理が、単純に物理的な管理に置き換わるわけではありませんが）。 あまり触れられませんが、同様に重要なことに、企業がアプリケーションの可用性をハードウェアに頼っていることが挙げられます。多くの企業は、アプリケーションの運用や業務の継続を保証し、停止時間が致命的になるのを回避するために冗長なハードウェアを導入しています。冗長なハードウェアは、アプリケーションの可用性を保証する完璧な手段とは言えないばかりでなく、データセンタの経費増加をもたらします。 仮想化は、利用率と可用性の両方に取り組む手段として登場しました。仮想化は、複数のアプリケーション及びOSインスタンスがハードウェアリソースを共有できるようにすることによって、利用率ばかりでなく、投資利益率（ROI）の向上を促します。土台のハードウェアからソフトウェアを抽出することによって、気紛れなハードウェアに依存することなくアプリケーションを冗長にできるため、アプリケーションの可用性を高めます。 つまり、仮想化は次の点で企業に貢献するというわけです。
仮想マシンの夜明け 仮想化マシン技術は、一般によく受け入れられている仮想化方式です。基本的に仮想化マシン技術では、1台の物理マシンで複数の仮想OSインスタンスをホスティングすることが可能で、SolarisやLinux、Windowsなどの異なるOSを同じハードウェアに共存させることができます。 近年では、仮想マシン市場の最有力候補としてVMwareが登場しています。VMware仮想化技術は、ハイパーバイザを作成することによって機能します。ハイパーバイザは、最初に起動されるミニOSのような働きをし、基本的には、土台のハードウェアを仮想化して分割し、同じ物理サーバ上で複数のOSが動作できるようにします。この手法は、混在OS環境を必要とするレガシアプリケーションを持つ企業にとって特に魅力的であることが分かっています。 VMware仮想マシンは、魅力的ではありますが、パフォーマンスの面からは比較的高価なものになります。一般に、OSが増えるたびにオーバーヘッドが増す一方で、ハイパーバイザそのものがCPUの全パワーの5〜15%を消費します。最終的に、仮想マシンの基盤をサポートするためにだけ、大量のCPUリソースを消費する可能性があります。仮想マシンはまた、「観察性（observability）」に悪い影響を及ぼす可能性があります。アプリケーションで問題が起きた場合、その問題の原因がアプリケーション、OS、または仮想マシン技術のどれなのか判定が難しくなるためです。 最近、このVMwareの代替として登場したのがオープンソースの『Xen』ソフトウェアです。VMware同様、Xenは同じハードウェア上での複数のゲストOSの実行をサポートしています。非常に下層での仮想化であり、メモリやCPUなどのシステムの様々な構成要素を仮想化できます。このように下層に位置するため、優れたリソース及び障害分離が可能になっています。 Xenを検討せざるをえない理由は数多くあります。
Solarisコンテナと仮想マシン Solaris 10ユーザは誰でも、もう1つの形態の仮想化技術、すなわち、Solarisコンテナを無料で利用できます。Solaris内でSolarisコンテナを使って、アプリケーション環境を仮想化できます。各アプリケーションに専用のIPアドレス、専用のファイルシステム、専用のユーザ、専用の割り当て資源を提供できます。また、仮想化がカーネルレベルで行われるため、Solarisコンテナはきわめて軽量です。複数のカーネルというオーバーヘッドの追加がないため、1つのサーバ上で、数千とはいかないまでも、数百のSolarisコンテナを実行できます。 加えて、Solarisコンテナ for Linux Applicationsでは、何の変更を加えることもなく、Solarisコンテナ内でLinuxアプリケーションを実行できます。 Solarisコンテナで複数のOSインスタンスを実行することはできませんが、この技術には非常に多くの利点があります。
しかしながら、仮想マシンが提供するリソース及び障害分離の水準の高さは、過小評価すべきではありません。Solarisコンテナの能力を必要とする以上に、単純にアプリケーションで分離が必要になることがあります。そうした場合は、仮想マシンとSolarisコンテナを組み合わせて、最高度の分離、利用率及び管理性を実現することができます。 Solarisコンテナと仮想マシンの混在 仮想マシンとSolarisコンテナの混在が合理的と思われる事例を考えてみましょう。セキュリティまたはパフォーマンスの理由からパッチを必要とするアプリケーションがあり、そのアプリケーションと相容れないパッチレベルのアプリケーションがあると仮定します。また、3つ目のアプリケーションとして、Windowsに関係しているレガシアプリケーションがあると仮定します。これらの3つのアプリケーションは、それぞれ独立した3つの仮想マシンOSインスタンス内で実行する必要があります。同じ環境に、パッチ面で寛容なアプリケーションがさらに4つあると仮定します。 この例では、専用のOSインスタンスを必要とするアプリケーションが3つあり、それらアプリケーションは仮想マシンを使って仮想化します。残りの4つのアプリケーションはSolarisインスタンス1つだけですむため、4つ目の仮想マシンOSインスタンス1つで4つのSolarisコンテナを実行することによって対処できます。この方法には、次のようなメリットがあります。
グリッド：昨日、今日、そして明日の仮想化 これまでとりあげたことは、仮想化にまつわる論議の地平を広げるという点で、かなりありきたりのものでした。しかし、ここからは違います。仮想化が採用されてきた歴史は長いのですが、仮想化の観点からあまり論じられることのなかった分野があります。それは、グリッドです。一見したところ、グリッドは仮想化のように見えないでしょうが、最初の定義を思い出してください。仮想化とは、土台のハードウェアからコンピューティングリソースを抽出することです。グリッドほど、有望な仮想化の例はありません。 仮想化環境に至る道を遡ると、仮想化は本質的にグリッド環境に適していることに気付くでしょう。なぜなら、仮想化されたSolarisインスタンスと複数のSolarisコンテナが存在するのであれば、複数のグリッドで、それらコンテナ内のリソースを消費できるためです。グリッドフレームワークによってアプリケーショングリッドを形成、制御して、ソフトウェアをサービスとして提供できます。グリッドエンジンが、コンピュートグリッド内の余剰サイクルを利用できます。例によって、少し先走りしていますね。 グリッドは目新しいものではありません。計算集約型のタスクに集団で取り組む手段として採用された長い歴史があります。例えばグリッドは、複雑な気象シミュレーションや広大な地下油田の地図、核爆発の影響のモデリング、複雑なデリバティブの運用シミュレーション、映画の個々のフレームへの重層感の付与に利用されてきました。計算集約型の処理を必要とするほぼ全ての業界、そしてそれ以外の大部分の業界も、グリッドに依存しています。 ステートレス・グリッドとステートフル・グリッド 従来のグリッドの仕組みはかなり単純です。1本の映画で1000枚のフレームをテキスチャマッピングする必要があると、グリッドコントローラによって1000個の並列プロセスが生成され、プロセスと同数のサーバに送られます（当然、仮想間環境では、これは、1000台の物理サーバまたは1000個のCPUではなく、1000個のSolarisコンテナになります）。 いずれにしても、それらサーバのうちの1つが停止した場合、グリッドコントローラは残りの999の作業負荷を集めて、1つ足りないことを検出し、その負荷を正常なサーバに送信します。このもっとも基本的な形のグリッドは、誰かがサーバのある場所で電源を切ったとしても、ほとんど違いがないため、『ステートレス・グリッド』として知られています。グリッドコントローラは単に足りない作業負荷を別のサーバに割り当てなおすだけです。害がなければ、問題になりません。 最近、いわゆる『ステートフル・グリッド』が登場しています。サンでは、多数のデスクトップを導入して、膨大な量の処理能力の無駄を出す代わりに、1つのディスプレイグリッドとSun Rayシンクライアントを組み合わせて、ユーザが必要とするタイミング、必要とする場所にデスクトップを届けます。サンにあるグリッドコントローラが、必要とされる処理能力を、ディスプレイグリッド専用の700のサーバの中から各ユーザに提供します。 例えば社員がStarOfficeを起動する場合に、通常のCPUの処理能力全体の60%が必要になると仮定します。グリッドコントローラは、60%の処理能力をその社員に提供します。ユーザが土台の基盤にステーフル接続しているため、サンのこのディスプレイグリッドは、ステートフルグリッドと呼ばれます。デスクトップの電源が切られた場合、そのユーザは、ほぼ確実にそのことに気付きます。 アプリケーショングリッドによるリソースの最適利用 もっと高度な形態のステートフルグリッドをみてみましょう。アプリケーショングリッドです。非RACのOracle ERPシステムをグリッド環境に移すことを考えていて、そのシステムが典型的な3層（プレゼンテーション層とアプリケーション層、データベース層）アーキテクチャであると仮定します。Webサーバとして20個のグリッドコンテナを割り当て、それらコンテナのうちの4つに負荷バランサの働きを持たせることができます。 アプリケーションサーバの場合は、アプリケーションサーバの働きをする2組のコンテナの間にステートフルクラスタを1つ作成できます。このため、アプリケーションサーバのうちの1つの電源が切られると、グリッドコントローラは正常に動作しているアプリケーションサーバでそのタスクを再開できます。グリッドにデータベース層を追加すると、ステートフルコンポーネントとしてコンテナが割り当てられます。このときコンテナは様々な物理的な場所をとりますから、それらコンテナがグリッド全体にわたる1つの高可用性クラスタにさえなるかもしれません。 過去、スタンドアロンのOracle ERPシステムで、こうしたアーキテクチャを実現するには、各階層専用に20個のCPUといったものが必要でした。通常のERPシステムは午前中は忙しく、その後、小休止状態になって、午後に再び処理要求のピークになる傾向があるという事実があるにもかかわらずです。ここでもまた、ピーク時だけのためのハードウェアが大量にあり、あまりにも多くの資源が十分に活用されていないことになります。 グリッド環境では、グリッドコンテナを使って同じアーキテクチャを作ることができますから、Webサーバ層は20個のコンテナ、アプリケーション層は一次コンテナ10個と冗長コンテナ10個、データベース層は10個のコンテナと10個の冗長コンテナの構成になります。これら階層の全てが、仮想化された同じハードウェアリソースを利用します。 ハードウェア利用率100%に向けた動き 真の革命は、ステートレスまたはステートフルに関係なく、同じグリッド上で負荷を混在、調和させられるようになりつつあることです。そして、全ての負荷のステートフル性または重要度を考慮して、優先順位を割り当てることができます。例えばStarOfficeを起動する社員は、バックグラウンドで動作する大きなステートレス負荷からCPU能力の提供を受けます。同様に、Oracleアプリケーションまたはデータベースサーバから処理能力の要求があった場合、その社員は残りのCPUサイクルの提供を受け、ステートレス負荷は、残りの全ての処理能力を受けます。 要するに、全てのアプリケーションが同じ仮想化基盤を共有し、適切なリソース管理を利用することによって、企業は、今日の15%ではなく、100%に近いハードウェア利用率を達成し、同時にアプリケーションの冗長性及び可用性も高められるようになります。 仮想化、グリッド、そしてその力の結集 ここに示したシナリオは、絵に描いた餅ではありません。今日、現実に起きていることです。当然、企業はVMwareやXenなどの仮想マシン技術をすでに活用し始めています。多くの企業がSolarisコンテナを導入して、利用率の改善を図っています。 自動車業界の巨人や世界的な金融機関などの大手企業数社が、仮想化OSや仮想化アプリケーション、共有デスクトップ基盤、ステートレス及びステートフル負荷を処理するためのグリッドなどからなる完全な仮想化環境に移行しつつあります。 この流れは明白です。あらゆる規模の企業が全てのアプリケーション用の共有リソースとして土台のハードウェア基盤全体を扱うようになるのは、時間の問題にすぎません。コストの面からも、常識的にも、単純に無視することのできない流れです。 ビル・バス
|
|
|
|||||||||||||||||||||||||||||||||||||||||
|
|
【仮想化がもたらす様々な利点 〜無秩序なサーバ増大からの脱出〜】（Inner Circle Vol.36）
印刷用ページ