全文は以下の通り：
クラウド分野で最も議論されているトピックは、VMwareとOpenStackの比較です。実際、OpenStackを使いたいと考えている人たちの間では、この話題で熱い議論が交わされています。私はSF BayのOpenStackカンファレンスで何度かこのトピックを取り上げましたが、カンファレンスに参加した多くの友人から、これらの議論について書いてほしいと言われました。読者の皆さんにこの記事の内容をよりよく理解していただくために、データセンター用途の2つの主要なクラウド・コンピューティング製品の要点を比較することでこの記事を完成させることにしました。これには、オープンなソフトウェア・システムとオープンでないソフトウェア・システム、エンタープライズ・クラスのレガシー・アプリケーションとクラウド・コンピューティング・アプリケーション、フリー・ソフトウェアとライセンス・ソフトウェア、厳格な機能テストに合格した製品とオープンな機能を持つ製品などが含まれると思われます。
具体的には、デザイン、機能セット、顧客ユースケース、価値の各項目で、各ポイントを10点満点で評価し、最終的に合計点で勝敗を決めます。
ラウンド1：デザイン
VMwareのソフトウェア・スイートは、Virtual Machine Managerを下層に持つボトムアップ・アーキテクチャです。VMwareのvSphereやvCloud directorのような製品は、無料のESX(i) Virtual Machine Managerに依存しており、優れたデプロイメント・アーキテクチャを提供しています。VMwareのソフトウェア・スイート自体は徹底的にテストされており、すべて単一のデプロイメント・フレームワークを備えています。全体として、VMwareの製品は、そのアーキテクチャの堅牢性により、マルチデータセンター規模の環境で多くのハイスペックユーザーに使用されています。言い換えれば、VMwareのソフトウェアシステムは閉鎖的であり、ソフトウェアはVMware自身の開発目標に完全に沿った道筋に沿って開発され、ユーザーや消費者はそれを制御することができません。
OpenStackはオープンソースのシステムであるため、1つの企業がOpenStackの流れをコントロールすることはできません。OpenStackの歴史はまだ3年と浅いですが、市場には大きな勢いがあり、同時に多くの大企業がOpenStackの開発をサポートしています。多くの企業がリソースを投入することで、OpenStackの開発は多様化しています。しかし、これは同時に、OpenStackの導入とアーキテクチャのメンテナンスコストがVMwareに比べて急増しているという問題をもたらし、同時に、バージョンアップの速度が比較的速いため、技術サポートドキュメントが製品に追いついていないという問題もあります。
VMwareは、その優れたドキュメントと使いやすいデプロイと管理のインターフェイスにより、デザイン面でやや優位に立っており、OpenStackはそれに追随し、ハードウェアとVMの管理面で柔軟性を維持し、マルチベンダーをサポートしています。
第2ラウンド：機能性
VMware vMotion
vMotion は、vSphere DRS、DPM、およびホストメンテナンスの 3 つの主要な機能を統合したものです。VM ダイナミックマイグレーションは、仮想マシンをあるホストから別のホストにゼロシャットダウンで移行できる機能で、当初は共有ストレージのサポートが必要でしたが、vSphere 5.1 ではダイナミックマイグレーションに共有ストレージが不要になりました。仮想マシンをホスト間で移行する場合、仮想マシンのメモリ状態とデータの両方を同時に移行する必要があります。共有ストレージの場合、実際にデータを移行する必要はなく、データストアを指すリンクだけを変更する必要があります。これにより、移行が高速化され、レプリケーション時のネットワーク負荷が軽減されます。
OpenStack ダイナミックマイグレーション
KVM ダイナミックマイグレーションでは、仮想マシンをある仮想マシンマネージャから別の仮想マシンマネージャに移行することができます。 より詳しく言うと、AMDアーキテクチャのホストとIntelアーキテクチャのホスト上の仮想マシンを移行する間を行ったり来たりすることができますが、64ビットの仮想ホストは64ビットのホストにしか移行できませんが、32ビットのものは32ビットと64ビットの両方のオプションが利用可能であることに注意する必要があります。ダイナミック・マイグレーション・プロセスの間、仮想マシンは操作できなくなりますが、仮想マシン内のユーザは仮想マシン内で作業を続けることができます。KVMはまだ共有ストレージに大きく依存しており、ある程度、相対的な設備投資が必要です。
動的な移行要件：
VMのストレージは、NFSやGlusterFSLibvirtのような分散ファイルシステムの上に配置する必要があります各コンピュートノードがリッスンフラグをオンにする必要があります各コンピュートノード間で同じネットワーク/サブネット内にある必要があります認証は、各コンピュートノードのDFSのマウントノードを構成するために事前に完了する必要があります一貫性があること
OpenStackブロックストレージの移行
OpenStackでは、KVMはブロック・マイグレーションをサポートしており、VMのマイグレーションに共有ストレージは必要ありません。ブロック・マイグレーションのシナリオでは、仮想マシンのメモリ状態とデータの両方がマイグレーションされますが、マイグレーション操作では双方のCPUリソースも消費され、共有ストレージよりも時間がかかります。ユーザーシナリオによっては、ホストの保守性を重視し、あまりコストをかけたくない場合、ブロックストレージ移行を適用するのが良い解決策になります。同時に、共有ストレージのない環境でコンピュートノードのカーネルメンテナンスやセキュリティアップグレードを行いたい場合も、仮想マシンのサービスを中断させないためにブロックストレージマイグレーションが最適です。
ユーザーシナリオ：
ユーザは、おそらく財務的なサポートや組織内のネットワークレイテンシのために分散ファイルシステムを持たないが、VMの高可用性を実現したいと考えています。
VMware DRSとDPM
vMotionに基づき、DRSは仮想マシンとホストの現在の使用状況を動的に監視し、ホストの負荷分散をサポートします。
ユーザーシナリオ：
デプロイメントフェーズ：監視対象のVMにカスタム自動化スクリプトを実行 モニタリングフェーズ：DRSはESX(i)ホストに分散されたVMをデプロイし、アクティブなVMと利用可能なリソースを継続的に監視して、リソースの利用率を最大化するためにVMを動的に移行することができます。
vMotion に基づき、DPM は低負荷のホストから VM を移行し、電力損失を減らすためにシャットダウンします。負荷が増大すると、DPM はホストをリブートし、新しい VM をデプロイして負荷を満たします。
OpenStack スケジューラ
OpenStackには、コンピュートとボリューム用のスケジューラが含まれています。 管理者が定義した一連のルールパラメータとフィルタを通して、OpenStackスケジューラはVMを適切なホストにデプロイします。フィルタに関しては、スケジューラは非常に柔軟で、ユーザはJSONフォーマットで独自のフィルタを作成することができます。OpenStackのスケジューラは非常に柔軟ですが、以下の理由により、DRSの完全な代替とはなっていません：
VMwareの高可用性
vSphere では、VM レベルでの高可用性とは、VM や ESX(i) ホストにエラーが発生した場合に、同じ VM を別のホストにデプロイできるようにすることです。ここでフォールト・トレランスの仕組みと混同してはいけませんが、高可用性のポイントは、何か問題が発生したときに、一定の時間内にそれ自体を修正できることです。ハイ・アベイラビリティは、ハードウェアに何か問題が発生したときに、VMが正常に動作することを保証するものです。 何か問題が発生した場合、VMは異なるESX(i)ホスト上でしか起動できず、サービスの中断を引き起こす可能性もあります。
OpenStackの高可用性
OpenStackがVMレベルの高可用性をサポートするという公式声明はありません。この機能はFolsomリリースで提案されましたが、その後削除されました。現在OpenStackには、仮想マシンレベルの高可用性サポートをOpenStackに提供するためのインキュベーションプロジェクトEvacuateがあります。
VMware のフォールトトレランス
VMwareのフォールト・トレランス・メカニズムは、仮想マシンの状態とすべての変更を監視し、第2のバックアップESX(i)サーバ上でこれらの変更を同期させることで機能します。フォールト・トレランスの考え方は、マスター・ホストとスレーブ・ホストのどちらに問題があっても、片方が機能している限り、ホスト上のVMは機能し続けるというものです。片側がクラッシュした場合、その変更はスレーブ・ノードに同期され、それを修正するためにVMのサービスを停止すると、スレーブ・ノードも同様にサービスを停止するからです。つまり、このメカニズムは単一障害点が再び発生しないことを保証するだけであり、真のアプリケーションレベルのフォールト・トレランスはMSCSやWCSで対処する必要があります。最大リソース使用量、メモリ、ハードドライブ、CPU、帯域幅フォールトトレランスなどの他の側面を考慮すると、これらの側面には限界があり、比較的使用量の少ない機能です。もしこれらが実装された場合、メモリはホスト間で複製できないため、2倍の量のメモリが必要になり、各CPU命令を同期させるためにCPUロックステッピングも必要になります。その結果、フォールト・トレランス・メカニズムによって監視されるのは単一の仮想CPUのみとなります。
OpenStackのフォールトトレランス
OpenStackにはフォールトトレランスの機能はなく、今のところこれらの機能を完成させる予定はありません。将来的には、KVM は Image オペレーションもサポートしなくなります。
VMwareの高額な投資によってもたらされた機能のほとんどは、OpenStackによって顧客に無料で提供することができます。OpenStackは、VMwareが投資した機能のほとんどを無料で顧客に提供できます。
VMwareが機能面でリードしていることからもわかるように、VMwareはvMotion、高可用性、フォールトトレランスに加えて、VMを保護するための新機能を開発し続けています。OpenStackは一方でVMwareの足跡をたどり、他方ではその上でより多くのハードウェアベンダのソリューションのサポートに投資しています。
第3ラウンド：ユースケース
上記の機能の価値を評価するにあたっては、まずユースケースの問題を考える必要があります。クラウドエコシステムでは、クラウドリソースを利用する必要があるユーザには、従来型ユーザとクラウドアプリケーションユーザの2種類があります。クラウド・アプリケーション・ユーザーは独自のHAとDRポリシーを処理しますが、従来のユーザーはクラウド・プラットフォームが提供するHAとDRに依存します。VMware Cloud Computing Architectureの記事から以下の図を参照してください。
クラウドベースのアプリケーションに共通する特徴
アプリケーション側での分散ステートレス、ソフトステートフェイルオーバー アプリケーション側でのスケーラビリティ
従来のアプリケーションに共通する特徴
クライアント・サーバー・アーキテクチャーは水平方向の拡張が難しい フェイルオーバーはサーバー側で行う スケーラビリティはサーバー側で行う
従来のタイプのアプリケーションには、FT、VMレベルの高可用性、自動ウイルススキャンなどの機能が必要ですが、クラウド・タイプのアプリケーションには必要ありません。
ペット対牛
これを別の方法で考えてみると、OpenStackとVmwareの関係は、MicrosoftのWilliam Baker氏の有名な記事「Pets vs. Cattle」に例えることができます。
従来のサービスモデルでは、ホストをペットに見立て、ダスティ、サーンなどの名前をつけて大切に育てます。ホストが病気になったら、あなたが治療しなければなりません。クラウドベースのアプリケーション・サービス・モデルでは、仮想マシンは農場の雄牛とみなされ、その名前は通常数字で、牛や雄牛は似たような姿をしています。
仮想マシンを維持・保護するVMwareのさまざまな機能は、クラウド・コンピューティング型のアプリケーション・モデルに比べ、重要性が低くなってきています。
VMwareにはOpenStackにはない機能がたくさんありますが、クラウドベースのアプリケーションではそれほど重要ではありません。将来的には、VMwareの追加機能のためにお金を払うことになるでしょう。
ラウンド4：バリュー
さて、いよいよ勝負の行方を左右する最終ラウンドです。とはいえ、OpenStackとVMwareのどちらがより価値があるかという問題には明確な答えはなく、その答えはデプロイの規模にも左右されます。OpenStackは無料で使えますが、多くのエンジニアリングリソースとドメインエキスパートを必要とし、多くのデプロイシナリオをサポートするため、多くのアーキテクチャとビルド作業が必要で、インストールプロセスも異なります。VMwareはパーミッションにいくらかお金がかかりますが、インストールと実行は比較的簡単で、VMwareはコマンドラインよりも学習コストが少し高いです。VMwareはコマンドラインよりも学習コストが低いです。
全体として、OpenStackは参入障壁が高いですが、プロジェクトの規模が大きくなるにつれて、高額なロイヤリティを支払う必要がなくなるというメリットがあります。VMwareは、小規模であれば比較的簡単にインストールできますが、規模が大きくなるにつれて状況が変わってきます。とはいえ、クラウドアプリケーションの規模が拡大し、人々がOpenStackに慣れ親しむようになれば、OpenStackの参入障壁はずっと低くなります。
OpenStackとVMwareは、クラウド・コンピューティングの分野で2つの重鎮であり、VMwareが機能とアーキテクチャの面でわずかにリードしていますが、OpenStackは劣勢で、第3ラウンドで追いつき、最終ラウンドで壊滅的な打撃を与えました。
追記
偶然にも、この記事を書いている1月29日時点で、VMwareの株価は22%下落しており、市場アナリストは、VMwareには明確で優れたクラウド・コンピューティング戦略が欠けていると主張しています。
OpenStackコミュニティ by Toby Ford
この記事は、ペットと家畜の例えなど、両者の違いを深く掘り下げた優れたもので、さらに評価基準にはもう少し幅を持たせるべきだと思います。
DRSとOS Schedulerの比較では、現在のところ、DRSがOpenStack Schedulerよりも優位に立っています。DRSは、VMをデプロイする際に、様々な主要メトリクスを使用してホストノードの選択を決定し、さらに、DRSはVMのライフサイクル全体を監視しているからです。
しかし、DRSはクローズドであり、これらの重み付けメトリクスはいずれも設定できません。そのため、単純な例として、夜間にCPU負荷が突然短時間増加した場合、VMを別のホストに移行する必要があるとは限りません。また、管理者が、今後一定期間にVMに何かが起こると分かっていて、DRSを巻き込みたくない場合、対処が非常に難しい状況になります。その代わり、OpenStack Schedulerは、特にスケーラブルになるにつれて、DRSから徐々に距離を置くようになるでしょう。
VMをダイナミック/フルライフサイクルで維持するためにvMotionが重要である理由に対して：vMotion/DRS/HAはすべてレガシーVMを扱うために必要な機能であり、VMのクラスとはあまり関係がないことは明らかです。
実際の環境では、スケジューリングルールをカスタマイズする必要があったために、DRSをオフにしなければならなかったことがあります。スケジューリングルールはカスタマイズされていましたが、VMwareのアップグレードによって、そのようなカスタマイズされたスケジューラのメンテナンスが非常に難しくなりました。
私が言いたいのは、OpenStackはバトルモードのシナリオに向けたものだけでなく、ペッツモードのVMの扱いもどんどん良くなっていくということです。
