毎回しっかりとした記事を連載しているので読み応えのある、Impress Enterprise Watchウェブサイトにて連載されている山本雅史さんの「仮想化道場」にてXen4.0が記事になっていました。Xen Summit Asia 2009については、こちらにVA Linux System Japanさんのレポート、本家xen.orgのoverviewなどはこちら。
Xen4.0の技術的な解説は各レポートをお読み頂ければと思いますが、dom0 Linux kernelにおけるpv_ops採用、カナダのブリティッシュコロンビア大学のプロジェクト成果であるRemusを取り込んだFT機能の統合、ページシェアリングの実装、blktap2モジュールへのアップデートによるVHDファイルのサポート、netchannel2サポートによるネットワークまわりの性能向上など、なかなか魅力的な機能向上が多そうです。
で、このエントリーのテーマに戻ります。オープンソースソフトウェアであるXen4.0は商用製品であるXenServerなどにおける基盤にもなっているわけですが、どうしてもオープンソースソフトウェアの場合は「欲しいと思った機能を追加していく」ことで製品のアップデートが行われていくことになります。XenSourceを買収したCitrix自身も最大の貢献者となっていますし、Xenをベースにした仮想化製品を提供している各社が積極的にXenの機能向上に寄与していますので、商用製品としての意向は強く反映されていますが、1社で開発が進められているわけではないのでどうしても相互の調整やマージ、安定性の確保などのために一定の期間が必要となります。XenServerの現時点における最新版5.5もベースとしているXenは3.3系でありまだ3.4系とはなっていません。Xen4.0がリリースされてもXenServerに採用されるのは1年後ぐらいになると思われます。Xen4.0に実装される予定の機能の多くも、すでにVMware vSphere4に実装されているものが多く、後追いになってしまいがち。また、基本機能であるXenそのもの以外の部分は各社がバラバラで開発・実装していくことになりますので、管理ツールや監視・運用関連のユーティリティ、3rd Party製品との連携などはどうしても弱いものとなってしまっています。機能実装の遅れはともかく、管理ツールや3rd Party製品との連携などといった部分はソフトウェア製品としての使い勝手そのものであるため、日々運用で使用する立場のIT部門としてはそうした要素を重要視する場合も多いと思われます。
VMwareは良くも悪くも商用製品としてvSphereを開発しています。リソースは限定的ですが、開発の方向性は明確。そして3rd Partyにとっても窓口が明確です。企業ユーザにとってもサポートや製品ライフサイクルが明確であることを重視する場合も多いのではないかと思います。また、製品として当然機能面の強化していくことは当然ですが、VMwareはそれ以上に管理機能やツール群の充実に注力しているはずです。そしてvSphere4からは3rd Partyベンダーに対するAPIの提供やユーティリティ群の充実などによって各社の開発リソースをVMwareに向けさせることによる仮想化製品としてのデファクトスタンダード化に力を入れています。VMwareはMicrosoftに対抗することを意識しているのか、自社製品の幅を次第に拡張しつつあるため3rd Partyベンダーとしても切り捨てられる？リスクはありますが、それであっても市場シェアを考慮するとVMwareを外すことは難しいのが実情です。リソースが限定されているからこそ、3rd Party各社はどの仮想化製品向けに自社ソフトウェアを開発するかについて選択する必要があります。ソースコードが公開されているオープンソース製品の場合は、その根幹までを把握した上で連携ツールを開発することができますが連携のためのインターフェイスは充実していないことが多いので開発が難しい面もあります。対して、商用製品の場合は基本的にソースコードが公開されていない場合が多いですが、APIやコマンドラインなどによるインターフェイスが提供されています。連携ツール側としても作りやすさがあるといえます。
どちらがよいかという点についてはユーザ次第ではありますが、同じ用途のソフトウェアであっても、商用製品とオープンソースでは根幹的な部分でだいぶ違うなぁと思うわけです。どちらだけ、ではなくどちらも存在しているからこそ、市場には様々な選択肢が用意されるわけで、それはユーザにとっても意味があることでしょう。当たり前に商用製品とオープンソースが共存する市場が形成されているということ自体がなかなか興味深いと思います。
