リソースのロードバランシング

　仮想環境と物理環境のどちらを運用する場合でも、どのようなリソースが使われているか、それらのリソースがどのVMに割り当てられているかを把握することが重要だ。例えば、8コアと24GバイトのRAMを搭載する1台の物理ホストを持っている場合、エンジニアは、使用可能なリソースを全て使おうとはしないだろう。調整や障害対応の余地がなくなるからだ。

（図1）米Citrixのサーバ仮想化ソフトウェア「Citrix XenServer 6.0 Enterprise Edition」をインストールした1台のマシンが、ローカルストレージのみを使用するホストとして構成されている。小規模な環境ならこれでよいが、ビジネスの変化に伴って、より多くのホストが必要になる可能性がある

　上記の例では、1台のXenServerホスト上でエンドユーザーに対して実行されているワークロードの幾つかで、リソース使用率が高くなっている。このソリューションは当面は機能するだろうが、一連のワークロードを実行している仮想サーバの負荷が急増した場合や、仮想サーバを追加する必要が生じた場合に、調整を行う余地がほとんどない。これらの場合、エンジニアは1台の物理マシン上でリソースの需要増加に対応するために、他のVMから仮想リソース（この例ではRAM）を振り向けなければならないだろう。

　物理リソースは、全てのVMに必要に応じて提供されるようにしなければならない。どのような環境でも、緊急時やシステム拡張に対応する余地を残しておく必要がある。そこで出番となるのが「ロードバランシング」と「VM管理」だ。

　仮想サーバと物理サーバの両方に、適切なタイプのリソースを割り当てる必要がある。リソースを大量に使用するワークロードを展開するときは、それらを実行する各VMに、リソースを計画的に提供し、他の仮想ワークロードや物理ワークロードに影響を与えないようにしなければならない。図2のように、先述のシナリオと同様のハードウェア仕様を持つセカンダリ物理ホストを追加して、物理リソース要素と仮想リソース要素のロードバランシングに着手することができる。

（図2）XenServer 6.0 Enterpriseでは、複数のXenServerホストで構成されるリソースプールを作成できる。このプールではリソースが共有される。実行中のVMを、SANバックボーンを介してホスト間で動的に移行できるからだ

　この新しいシナリオでは、2台の物理ホストで構成されるリソースプールにおいて、VM間でリソースが共有されている。実運用される全ての環境は、どれ1つとして同じものがないため、物理リソースのロードバランシングプロセスは、ケースバイケースで個別に計画しなければならない。この例の2台の物理ホストは、既存のVMの要求に余裕を持って対応できる豊富なリソースを持っている。この環境では、VMのアジリティが保証されるようにCPUやRAM、ストレージについて高い要件が設定されている。

　また、多くの環境では、高可用性（HA：High Availability）を実現するためにロードバランシングを行うことが求められる。XenServer 6.0を例に見ると、ビルトインツールがこのプロセスに役立つ。XenServerプール（XenServerで作成されたリソースプール）のHA機能を利用すれば、管理者は、あるホストから別のホストにどのVMを安全にフェイルオーバーできるかを把握できる。さらに、エンジニアは、その処理のために物理マシンごとにどれだけのリソースが必要かを判断できる。

　ここで留意すべき最も重要なことは、これら2台のサーバ間でロードバランシングが行われ、VMの新規作成、フェイルオーバー、ワークフロー自動化のためにリソースが提供されることだ。HAに関しては、物理サーバの1台で障害が発生すると、もう1台がそのホストの重要なVMを引き継げる。

　マシン間でリソースのロードバランシングが行われていると、VMを物理ホスト間で必要に応じて、現在のリソース状態に影響を与えずに移動できる。ディザスタリカバリ（DR）の例を考えてみよう。こうしたロードバランシングのシナリオでは、物理ホストで障害が発生した場合、VMは、リソースが見つかる別の使用可能なホストに移行される。マシンのいずれかが完全に使用されていると、DRやフェイルオーバーは不可能になる。そのサーバでは、移動してくるVMをサポートするのに使用可能なリソースがないからだ。

　次回は、ワークフロー自動化やアラート監視などの管理機能を紹介しよう。