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

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

[まえだこうへい,Debian JP Project]
前のページへ 1|2|3       

敷居が高い原因は?

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

●現状では、サポート対象の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:ニッチとはいっても、将来的にスケールしない領域であれば、ビジネス的には意味がありませんが。


まとめ

 今回、KVMを実際に運用していくうえでの課題として2つの管理ツールを挙げました。そしてその中で、主にRed Hatによって開発されているoVirtについて紹介しました。

 ただ残念ながら、今回の検証では実際にoVirtを動かし、仮想マシンを制御するところまではできていません。そこで次回は、実際に正常に稼働するところまで検証・確認し、紹介できるようにしたいと思います。


前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。