構成管理

　仮想マシンの構成、つまりCPUやメモリなどの割り当てが柔軟に行える分、容易かつしっかりと管理できなくてはならない。リソースの変更だけでなく、仮想マシンに対するデバイスの追加や削除などがスムーズに行えるかどうかがポイントだ。

プロビジョニング

　プロビジョニングには2つの意味がある。1つは仮想マシンを用意することだ。仮想マシンの新規作成や複製などがこれに当たる。テンプレート機能を利用して、仮想マシンを用意しやすくする機能も必要となる。

　もう1つは、用意した仮想マシンを仮想ホスト上で動作させることもプロビジョニングと呼ぶことがある（あるいはメモリ上に仮想マシンを作成することから「インスタンス化」と呼ぶ場合もある）。複数台の仮想ホストを管理している場合、どの仮想ホスト上で仮想マシンを動作させるかが重要になる。例えば、仮想ホストに対する負荷を分散させるのであれば、その時点で負荷の低い仮想ホストを見つけて仮想マシンを起動するなどの処理が必要である。

監視

　仮想ホストや仮想マシンに対する監視も運用管理ツールの役目である。動作しているかどうかをチェックする死活監視だけでなく、CPUやメモリ、I/Oなどの使用量を監視するリソース監視もサーバ仮想化では重要な機能である。もし死活監視で問題が起きた場合には、フェイルオーバーによる仮想マシンの再起動などが必要となる。

バックアップ／リカバリ

　バックアップやリカバリは運用管理ツールそのものの役目ではないが、運用管理を考える上では必須の機能である。仮想環境では仮想マシン単位でのバックアップ、実際には仮想ディスク単位でのバックアップが可能だ。稼働中の仮想マシンが利用している仮想ディスクは、メモリ上のキャッシュバッファにまだ書き込まれていないデータが存在する可能性があるので、単純なコピーでは完全なバックアップとはならない点に注意すべきだろう。スナップショット機能を使うと、バッファ上のデータを仮想ディスクに書き込んでくれるので、バックアップが容易になる。スナップショット機能とバックアップを連動させる機能が運用管理ツールで提供されている場合には利用を検討したい。

各製品の簡単な紹介

　本連載では、運用管理および用意されている運用管理ツールの観点から、毎回さまざまな仮想化ソフトウェアを紹介していく。第1回である今回はその前提として、製品ごとのアーキテクチャおよび特徴的な機能についてまとめて解説する。

アーキテクチャの違い

　アーキテクチャの違いは、ハードウェアの選定やパフォーマンス、トラブルシューティングにおいて重要なポイントとなる。同じハイパーバイザー型の仮想化ソフトウェアでも、それぞれの製品でアーキテクチャが異なっていることを理解しておきたい。

VMware ESX／ESXi

　「VMware ESX」「VMware ESXi」のハイパーバイザーはvmkernelと呼ばれる（図1）。その名の通り、VM（仮想マシン）のためのカーネルだ。最大の特徴は、デバイスドライバがカーネル空間に組み込まれている（実際にはモジュール式）ことだ。そのため、VMware ESX／ESXiではvmkernel対応のデバイスドライバが必要であり、デバイスドライバが単体で配布されていることはほとんどない。そのため、VMware ESX／ESXiを動作させるには互換性の確認が取れているハードウェアを選定する必要がある。

　このように動作ハードウェアが狭められる半面、デバイスドライバを利用した処理は高速に行えるメリットがある。

図１　vmkernelのデバイスドライバモデル

Hyper-V／Xen

　「Hyper-V」や「Xen」の特徴は、通常のOSのデバイスドライバを利用できることにある。これは管理およびデバイスI/Oを行う特別な仮想マシンを利用するアーキテクチャで実現している。デバイスドライバは、Hyper-Vでは親パーティション、XenではDomain 0と呼ばれる仮想マシンで動作する（図2）。

　vmkernelの場合と異なり、通常OSのデバイスドライバがそのまま使えるので、そのOSが動作するハードウェアであれば基本的に仮想環境へもそのまま対応できる。

図2　Xenのデバイスドライバモデル

KVM

　「KVM」のアーキテクチャは前の二者とやや異なり、仮想マシンの実行機能がLinuxカーネルの一部として提供されている。Linuxカーネルから見て、仮想マシンは1つのプロセスとして動作し、仮想マシンはLinuxカーネルの仮想デバイス/dev/kvmへアクセスしてさまざまな機能を実行する。仮想マシン内部ではPCエミュレータである「QEMU」がさまざまな機能を提供する（図3）。

　KVMはLinuxカーネルの一部であるため、デバイスドライバもLinuxカーネルに対応したものをそのまま使える。Hyper-VやXenの場合にはハードウェアとデバイスドライバの間にハイパーバイザーが入っていたが、KVMの場合には完全にネイティブにデバイスドライバが動作する。その点に違いがあるといっていいだろう。

図3　LVMのアーキテクチャ

機能の違い

　各製品の機能的な違いについて、ハイパーバイザーの主たる機能、すなわち「仮想マシンの上でゲストOSを実行する」という観点ではほとんど違いはなくなってきた。

　また、製品としてのさまざまな機能はハイパーバイザーそのものの機能ではなく、仮想マシンの外部で動作するそのほかのソフトウェアで実現しているものが多い。例えば、フェイルオーバーの機能はハイパーバイザーの機能ではなく、死活監視と仮想マシンの再起動の組み合わせによって実現している。ここでは、比較的質問されることが多い機能について解説する。

メモリのオーバーコミットメント

　オーバーコミットメントとは、仮想マシンに割り当てられたリソース量が、物理リソース量よりも多くなることを指す。例えばCPUの場合、仮想CPUの数が物理CPUの数よりも多い場合、時分割で切り替えながら処理をすることでオーバーコミットメントを実現している。当然、仮想CPUに対して割り当てられる物理CPU時間は少なくなるので、その分だけ性能が劣化する。

　メモリのオーバーコミットメントは、もう少し複雑な手法が取られている。まず、メモリ上の重複を排除することで仮想マシンが消費する物理メモリの量を削減する処理が行われる。さらにメモリが不足している場合には、通常のOSが持つ仮想メモリの機能と同様に、あまり使用されていないメモリ領域をディスクに書き出す（スワップアウト）処理を行う。メモリの重複排除はそれほど性能劣化を引き起こさないが、スワップアウトが発生すると極端に性能が劣化するのは通常のOSと同様である。

　メモリのオーバーコミットメントは副作用も大きいので、ハイパーバイザーによっては実装されていないものもある（開発上の優先順位が低いため）。また実際の構築においては仮想マシンに割り当てたメモリの合計量が物理メモリ量をオーバーしないように2、3割程度は未使用のまま残すように設計するのが望ましい。また、そうした設計に合わせ、メモリの大容量化、低価格化が進み、サーバへの搭載可能枚数が増えている。

フォールトトレラント

　フォールトトレラントは、2つの仮想マシンの動作を同期させ、片方の仮想マシンが物理障害などで停止してしまった場合でも、もう一方の仮想マシンが動作を継続する仕組みである。フェイルオーバーの場合、再起動が終わるまでの時間はシステムが停止する上、障害発生時にメモリ上にあったデータは失われるが、フォールトトレラントであれば論理的にはそのようなことは発生しない。

　これまでフォールトトレラント機能は専用のハードウェアで二重化を行う必要があったが、「VMware FT」や「Xen 4.0」の新機能などでサポートされるようになってきている。ただ、まだ比較的新しい実装であるため、ミッションクリティカルなシステムで利用するにはもう少し時間が必要ではないかと思っている。

　これらの機能は仮想化らしい特徴的な機能といえるが、あまり過大な期待をしない方がいい機能でもある。そのほかの機能についても、本当にその機能が必要かどうか、その機能が要求を満たせるかどうかをシビアに判断する必要があるだろう。

　次回は「VMware vSpehere 4」について紹介する。

宮原 徹（みやはら とおる）

日本仮想化技術 代表取締役社長兼CEO

株式会社びぎねっとを設立後、Linuxをはじめとするオープンソースの普及活動を積極的に行い、IPA 「2008年度 OSS貢献者賞」を受賞。

次の目標を仮想化技術の普及に定め、日本仮想化技術株式会社を設立。仮想化技術のエバンジェリストとして、日々全国を飛び回っている。最近は省電力化とSSDを使った爆速ストレージが持ちネタ。