InfiniCloud® HV

InfiniCloud HV Xenモデル

XenはType Iハイパーバイザであり、設計上、非常に高い安定性を持つことが特徴です。

システムを構成するソフトウェアの中で、特にバグが発生しやすいのは、ハードウェアを制御するドライバと言われています。Xenでは、ハイパーバイザを可能な限り薄く作り(マイクロハイパーバイザー)、それぞれの仮想マシン(DomU)同士、あるいはそれらを管理する管理マシン(Dom0)毎の隔離性を高めることで、1つの仮想マシンの問題が他の仮想マシンに影響を与えないように設計されています。

そのため、Xenではデバイス仮想化層を、ハイパーバイザーからDom0上にリクエストをし、Dom0のLinux OS経由でハードウェアエミュレーション(qemu-dm)を行い、Dom0内でデバイスを管理し、インシデントがハイパーバイザーに直接影響を与えにくい実装になっています。VMware ESXiがパフォーマンスの向上を目的とし、ハイパーバイザーにドライバー類を内包したこととは対照的です。

そのため、仮想マシン同士の隔離性能はVMware ESXiを凌ぐレベルですが、結果的に、デバイスアクセス時のメモリコピーの頻度が多く、アクセスごとにレイテンシーが発生し、シングルスレッド性能が低下することがあります。このため、ハードウェアが遅かった時代には、この点が敬遠されることもありました。オンプレミスで使われている多くのXen実装では、比較的安定した基盤を構築しやすいというメリットがあります。

オンプレミスなどでXenをセットアップしたにもかかわらず安定していない場合、Dom0内のLinux OS内のハードウェアリソース仮想化サービス類や、HA機能に対して十分にリソースが割り振られてないケースがほとんどです。Citrix XenServerや、Vates XCP-ngでは、標準でハードウェアのサイズに合わせてDom0のスペックを決めてはいますが、ワークロードがよっては十分ではありません。たとえばネットワーク仮想化層のリソースが足りない場合は、DDoSなどでトラフィック流量だけでなくCPUハンドリング時間が増え、他のリソース仮想化層に悪影響を及ぼします(ちなみにこれは、VMwareでも同様です)。この場合、HAも不安定になりがちです。従って、Dom0のリソース管理は重要であり、ハードウェアリソース不足による障害が発生することがあります。オンプレミスXenシステムが不安定になる主な原因は、Dom0のリソース管理にあります。

そこで、InfiniCloud®HVでは、Dom0に内包されるさまざまな重要なサービス機能を、可能な限りリソース隔離し、時にはリソースを固定的に割り当てることで、デバイス仮想化層が安定するように、堅牢なシステムへとカスタマイズしています。スケジューラの変更やメモリ確保の厳密化、一部リソースの固定化、ストレージの割り当てなど、さまざまな工夫を経て、速度よりも堅牢性を重視している点が特徴です。

InfiniCloud®HVのXenモデルが対応しているディストリビューションは、現在、Vates社のXCP-ngのみです。Cirix社のXenServerには現時点では対応しておりません。XCP-ng自体はオープンソースであり、Xenハイパーバイザーだけでなく、デバイス仮想化層、仮想マシン管理、仮想ディスク管理、プール管理などの様々な機能がありますが、InfiniCloud®HVは純粋なXenハイパーバイザー部分や、qemuなどのハードウェア仮想化層の部分を差し替える形でインストールされます。

InfiniCloud HV KVMモデル

KVMはLinux OSの上で動作し、学術的な観点からはType IIと分類されるハイパーバイザーです。

しかし、Red Hat社をはじめとするいくつかのベンダーは、Type Iハイパーバイザーとして分類しています。 KVMは、仮想マシンのCPU命令を直接、親OSで実行したり、CPUの仮想化支援命令等を利用してメモリやIOアクセスする、いわゆるリソース制御、仮想化処理をLinuxのカーネル層で処理します。このことは、Type I ハイパーバイザーの雄と言えるVMware ESXiが、結果的にハイパーバイザー層でハードウェアドライバやリソース仮想化層を内包しているのだから、Linux OSが同じように管理しても、広義ではType Iハイパーバイザーと言えるのではないか？という考えなのでしょう。

現実的なデプロイメントでは、KVMがホストOS（Linux）上で動作し、そのOSのリソース管理機能を利用して仮想化を提供する以上、リソース管理やその最適化は、Type IIならでは最適化が必要になっています。

Xenは隔離性の為ならば性能低下もやむを得ない設計思想でしたが、KVMは親OSのLinux OSから比較し、仮想化ボトルネックが比較的少なくなるように設計されています。特にシングルスレッド性能の劣化を防ぐため、ハイパーバイザに相当する部分の大半を親のLinux OSが担っています。

CPUの割り当ては基本的にLinuxのCFS（公平配分スケジューラ）を利用しており、仮想マシンにとっての仮想CPUコアは、親OSの1スレッドでしかありません。CPUコアを固定割当（pinning）する方法もありますが、基本的には物理ホストの物理・論理コア数とゲストマシンに与えるvCPU数にはほとんど相関関係がありません。（例: 4コアと8コアのパソコンで、Chromeのタブを開く数に大きな差がないのと同様）

メモリ管理もLinux OSのメモリアロケーターが使われるため、仮想マシンにはメモリを固定で確保することができません。他のタスクと同じように、初めてページアクセスが行われた際に動的メモリが消費されていきます。そのため、メモリは柔軟に共有されますが隔離性は下がることになります。

Linux OSという汎用OSで管理されているため、必要な各種主要Daemon(サービス)と仮想マシンは、対等の関係にあります。そのため、1つの仮想マシンに大きな負荷がかかると、各仮想マシンやサービスがリソースを奪い合い不安定になることがあります。これらの点が、エンタープライズ用途においてVMwareやXenに比べ、不安定だと言われてしまう所以でもあります。

KVMはNutanixをはじめとする、さまざまなオーケストレーション製品、ディストリビューションなどでも利用されており、エンタープライズ用途でも使われています。 Linuxのカーネル内に含まれている事もあり、最新機能の開発が活発です。VMwareの準仮想ドライバーであるPVSCSIや、VMXNET3にも対応してることも、VMwareからの移設時に準仮想ドライバを入れ替えることなく動作させることができる利点に繋がっています。 

InfiniCloud®HVでは、Linux OS自体の管理技術を組み合わせ、ハイパーバイザーとして重要なサービスに可能な限りリソースを隔離して割り当て、仮想マシンとリソースを奪い合いしにくいように設計されています。特にメモリマネージャーの動きに対するカスタマイズを重点的に行っており、オーバーコミットやBallooning時のメモリ回収など、一度、安定して動いた仮想マシンのリソースをなるべくシステムが再配置しないように、設計されています。

また、重要サービスに対するスケジューラの変更やメモリ確保の厳密化、一部のリソースの固定化やストレージ割り当てなどに、さまざまな工夫を施し、速度よりも堅牢性に重点を置いているのが特徴です。

KVMは様々なディストリビューションがあるため、理論的にはInfiniCloud® HVは様々なKVMベースのディストリビューションに対応します。しかし、現時点でInfiniCloud®HVのKVMモデルが対応しているディストリビューションは、Proxmox社のProxmox VEのみです。Proxmox VEはオープンソースであり、Debian OSの上に、様々なオーケストレーションシステム、デバイス仮想化層、仮想マシン管理、仮想ディスク管理、(仮想)データセンター機能などが含まれています。InfiniCloud®HVはkvmカーネルモジュール部分や、qemuのハードウェアやデバイス仮想化層の部分が差し替わりつつ、カーネルのリソース制御がリソース共有よりも堅牢側に最適化されます。