運用上の課題を解決する管理ツール：知って見るみるKVM（3）（3/3 ページ）

» 2009年08月07日 00時00分公開

敷居が高い原因は？

　今回の検証で、導入の敷居が高いと感じた要因を下記に挙げてみます。

●現状では、サポート対象のOSは基本的にFedora 10以降のみ

　2009年6月上旬にFedora 11がリリースされましたが、リリース段階ではまだoVirtは含まれていませんでした。また、開発元のドキュメントには「10以降サポート」と書いてはあるものの、Fedora 11リリース時の段階ではFedora 10にしか対応していませんでした。なお、ほかのディストリビューションでは仮想アプライアンスを使えば導入は可能なようですが、ドキュメントが更新に追い付いていない状態です。

●ドキュメントの更新が追い付いていない。注意事項の記述が目立ちにくい

　oVirt自体の開発速度が速いので、前者はある意味、仕方のないことかもしれません。後者は、ドキュメントに沿って行うと、一見、自分が何か失敗したのだと勘違いする処理結果があります。ところがドキュメントをよく読むと、http://ovirt.org/install-instructions.htmlに、

Even if it succeeds, it always exits with an error code of ``1''. Yes, this is a bug.

（訳：成功したとしてもいつもエラーコード1が出力される。これはバグだ）

と記述されています。「this is a bug.」のところは、もっと目立つようにしてほしいものですね。

●サブシステムが多い

　検証中に悩まされたのはこの点です。oVirtを構成するサブシステムが多いので、1つ解決してはまた別の問題、1つ解決してはまた別の問題、という具合に、対応してもなかなかうまくいかず、どつぼにハマってしまったような気になります。

　今後、インストーラがさらに簡単になり、自動的にほぼ問題なくインストールできるようになれば、導入自体の難易度は下がると思います。ただ一方、ユーザーにとってのブラックボックスとなる部分は増加します。これはトレードオフなので仕方ないことではありますが、運用するうえでは、やはりサブシステム間の関係を理解し、全体を把握していないと、障害が発生した際の対応が非常に困難になると推測できます。

　なお、トラブル原因の当たりは付けているのですが、確認して検証の続きをやる時間が取れないので、検証の続きは次回に。

　またoVirtの開発目標は、oVirt projectのWebサイトのホームページ（http://ovirt.org/）に「oVirt goals」として記載されています。ここには以下のように記載されています。

Empower virtual machine owners without giving up control of hardware
（訳：ハードウェアの制御を失うことなく、仮想マシン所有者に力を与える）
Automate virtual machine clustering, load balancing, and SLA maintenance
（訳：仮想マシンのクラスタリングや負荷分散、SLA維持（注8）を自動化する）
Simplify management of large numbers of machines
（訳：多数のマシン管理を単純化する）
Work across platforms and architectures
（訳：プラットフォーム、アーキテクチャの違いを超えて動作するようにする）

　これを見ても分かるとおり、oVirtはビジネス向けの機能強化を図っていくものと期待できます。特に、最近のRed Hatのリリースなどでは、いわゆるクラウドコンピューティングに言及した発表がなされるのを報道記事で目にしますが、ここでの内容はそれを意識しているものと思われます。ここでは深く言及しませんが、サービスレベルの向上につながる機能が実装され、それがシンプルに、簡単に扱えるようになるのであれば、運用管理の観点からはとても好ましいことでしょう。

注8：原文では「SLA maintenance」となっていますが、意味を考えると「SLAの維持」を自動化するのではなく、「サービスレベルの維持を自動化すること」と考えるのが妥当でしょう。

そもそもKVMの優位性は？

　さて、ここまでの説明を踏まえて、あらためてほかの仮想化技術に比べたKVMの優位性について考えてみましょう。

　明確な優位性としては、1回目でも触れましたが、Linux Kernelのメインラインにマージされていることが挙げられます。KVMはそのアーキテクチャ上、VMwareやXenに比べるとパフォーマンスが劣るのではないかと思われています。とはいえ、カーネルを再構築しなくても、コマンドラインだけでノートPCでも気軽に使える点はメリットです。

　そうした意味合いからKVMは、サーバ仮想化の手段としてではなくとも、ニッチな領域で生き残っていく（注9）のではないかと思います。ちなみに筆者個人としては、わざわざ同じ土俵で勝負をしなくてもいいのではと思っています。

注9：ニッチとはいっても、将来的にスケールしない領域であれば、ビジネス的には意味がありませんが。