運用管理ツールから見るサーバ仮想化製品【第1回】まず押さえておきたいサーバ仮想化導入のポイント
サーバ仮想化の運用管理方法について検討する前に、押さえておきたいサーバ仮想化のポイントを解説する。
サーバ仮想化のメリット
サーバ仮想化のメリットは一言では説明できない。さまざまなメリットがあり、またどのメリットを重視するかはシステムによって異なる。あるシステムではコストが重要視され、あるシステムでは冗長性が最も重要視される。ここでは、3つの観点でサーバ仮想化のメリットを解説する。
コスト適正化
サーバ仮想化の一番大きなメリットはサーバ統合による「コスト削減」だろう。ただし、このコスト削減という言い方はやや正確さに欠ける。複数のサーバで構成されたシステムは非常に無駄が多く、運用管理の手間が掛かり過ぎるため、結果としてコスト高に陥っていた。複数のサーバを仮想化によって統合することで、システムの無駄を大幅に省き、導入コストや運用管理コストを削減できるようになる。一方で、仮想化を導入してもある程度のコストは掛かる。そのため、サーバ仮想化のメリットは無駄を省いて「コストを適正化する」と言った方が正しいだろう。
柔軟性
サーバ仮想化は、主に仮想マシンの技術を使って実現する。仮想マシンは、物理的な制限を受けにくい仕組みとなっている。例えば、簡単に仮想マシンの複製を作れるので、物理環境と同じOSやアプリケーションがインストールされた仮想マシンを用意できる（プロビジョニング）。ほかにも、仮想マシンの状態を一時的に保存したり（スナップショット）、CPUやメモリの割当量を変更することも設定1つでできる。
可用性
仮想マシンは、互換性のある仮想マシンソフトウェア上であればどこでも実行可能だ。この特性を利用すれば、可用性の高いシステム構成を容易に実現できる。例えば、仮想マシンを別の物理マシン上で再起動させたり（フェイルオーバー）、OSやアプリケーションを停止せずに別の物理マシン上に移動させたりできる（ライブマイグレーション）。
サーバ仮想化での運用管理ツールの役割
サーバ仮想化のメリットを十分に引き出すには、運用管理ツールが欠かせない。サーバ仮想化のための運用管理ツールに求められる主な機能は以下の通りだ。
構成管理
仮想マシンの構成、つまり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」について紹介する。
この記事を読んだ人にお薦めのホワイトペーパー
この記事を読んだ人にお薦めの関連記事
ITmediaはアイティメディア株式会社の登録商標です。