これで、OpenStackイニシアチブに参加する会社になりました。毎日、顧客やパートナーと話し合うだけで、マーケティングや製品管理に関するほとんどのデータを取得できます。 それはともかく、この分野での競争は非常に激しいので、コミュニティと個々のベンダーにとって、誰が何を望んでいるかを明確に理解しながら、十分な機能を確保して優先順位を付けることが重要です。 私は「証拠のキャプテン」として行動しますが、それでも、企業のニーズは、サービスプロバイダー、政府、またはWorld Wide Web上で動作するITユニットのニーズとは非常に異なると言います。
この投稿（および今後のいくつかの記事）では、機能（実際には「ビルディングブロック」）に関する考えを共有します。これらはまだOpenStackでは利用できませんが、プラットフォームをエンタープライズレベルで正常に使用するために必要です。 さらに、このギャップを埋めるための作業が現在進行中かどうか、もしそうなら、どのような解決策が存在するかを確認します。
欠落している構造要素＃1：エンタープライズレベルでの高可用性/フォールトトレランス
高可用性（またはHA）：企業にとって、これらはおそらく仮想化/クラウドのコンテキストで2つの最も重要な文字です。 簡単に言えば、その存在とは、何らかの理由で、たとえばオペレーティングシステムの障害、ハイパーバイザーノード全体の障害などによって仮想マシン（VM）が誤動作した場合、データセンター/クラウド管理プラットフォームは、すぐにそれを復活させます。 これは、ハイパーバイザーの同じホストでクイックリスタートするか、ハイパーバイザーの別のホストに緊急転送（避難）することで実行できます。 VIP仮想マシンの「極端な」モードは「フォールトトレランス」、またはCPU /メモリの状態をミラーリングする異なるハイパーバイザー上の2つのVMの機能であり、障害が発生した場合に常に動作可能なVMが少なくとも1つ残るようにします。
なぜ企業に高可用性サポートが必要なのですか？
歴史的に、エンタープライズレベルのvSphereの成功は、主に既存のアプリケーションが「ペット」クラスに属するという認識に基づいていました。 このようなアプリケーションは長年にわたって積極的に開発されており、ベアメタルで動作し、特別なチームによって正常に動作するように維持されています。 このタイプのアプリケーションは、原則として、クラウドで動作する準備ができていません。 固有のインテリジェントフェールオーバーは実質的に組み込まれていませんが、ビジネスニーズを満たすためにうまく使用されており、今後の開発のための予算が計画されています。
vSphereは、より少ない物理サーバーに統合することに加えて、これらのアプリケーションの「生活の質」を向上させ、「仮想化/クラウドサービスのパフォーマンスを考慮する」必要なく、障害からの回復を支援します。 成功するには、OpenStackプラットフォームが同じ機能を実行できる必要があります。
OpenStackの高可用性についてはどうですか？
良いニュースは、高度な可用性をサポートするために必要な「部分」がすでに存在することです。したがって、OpenStackの全体的な「サービスとしてのアクセス」の構築は、予想よりも少ない労力で済みます。
OpenStackは、動的移行/緊急移行に適した複数の共有+分散サーバーストレージシステムをサポートします（CephはMirantisで私たちのお気に入りのシステムです）。また、Novaは「nova evacuate」コマンドを実装し、多数のAPI呼び出しにつながります別のハイパーバイザーホストへの緊急VM転送用。
不足しているのは、コントロール+監視コンポーネント（そしてもちろん、美しいユーザーインターフェイスと強力なPR）です。 ただし、いくつかのプロセスでは、さまざまなレベルの高可用性（ハイパーバイザーの可用性、nova-computeの操作性、VM pingへの応答など）をサポートするVMの動作を注意深く監視し、「すべて、彼女が死んだ」という決定を下してから実行する必要がありますNova経由の緊急転送。 さらに、もちろん、そのようなシステムは緊急転送の成功を保証する必要があります。
悪いニュースは、OpenStackコミュニティが、アプリケーションをアクセス可能にするという文脈でOpenStack開発ベクトルを定義する際に一貫性がなかったということです（ある程度はまだ残っています）。 幸いなことに、最新のアトランタサミットは「エンタープライズコンクエスト」の必要性を強化し、「DevOps /クラウド対応アプローチの使用」というOpenStackの元の原則を尊重しながら、 多くのオープンマインドコミュニティメンバーが 「 Nova APIは、他のサービスまたはすべてのVMを監視し、ボリュームの最後のスナップショットから別のインスタンスを起動したり、追加の コピーなど」。
最も不愉快な（または単に不幸な）瞬間は、コミュニティが一貫した地位を確立するまで、OpenStackのデプロイを検討している潜在的な顧客が間違ったメッセージを受け取り、「OpenStackは高可用性の確保を気にかけない、コントローラー自身のインフラストラクチャを超えています。」 これらの人々の信頼を取り戻す時間はまだあるのだろうか。
そして今、真実の瞬間が訪れます。誰がコードを書き、いつそれが有用な機能に変わるのでしょうか？
回避策
誰かが、可能な解決策は、ペットクラスの仮想マシンと緊急移行をトリガーするスクリプトの集中的なポーリングを実行するNagiosまたはZabbixシステムを構成することであると主張するかもしれません。 これはある種の奇妙な日曜大工の環境で機能するかもしれませんが、管理の文脈では企業レベルにとっては面倒すぎると思います。 多くの場合、ITは依然として企業内でコストが発生する場所であることを忘れないでください。そのため、IT従業員の作業を促進する必要があります。 さらに、Heatを「ステートマシン」として使用し、Ceilometerを緊急管理者として使用することも検討できますが、少なくとも現時点では、適切な成功事例はありません。
この場合の本当の妥協点は、KVMとvSphereハイパーバイザーを同時に使用してOpenStackの実装を開始することです（企業に特定のvSphereライセンスがある場合）。 OpenStackは、KVMベースのクラウドで動作するアプリケーションのセルフサービス/集団賃貸/オーケストレーションおよびホスティングに役立ちます。vSphereは、ベストを尽くします-ペットクラスのアプリケーションのホストとして機能し、ベアメタルのような仮想化に満足しています。
幸い、VMWareはNova用のvCenterドライバーの開発に多大な投資をしてきました。KennethHuiが一連の優れた投稿で説明したように、HA、DRS、vMotionなどの機能はOpenStackで実行していても機能します。 この設定を簡単に活用することもできます。MirantisOpenStackを使用して最初のOpenStack + vSphereパッケージをビルドする方法に関する最新の投稿を参照してください 。
OpenStackがエンタープライズレベルで成功するために必要な他の機能は何だと思いますか？
PS：ESXiのみのEssentials Kitに次いで2番目に安価なVMWare製品であるEssentials Plus Kit以降、vSphereに高可用性サポートが含まれていることを忘れないでください。ただし、使用するにはvCenterライセンスも必要です。
英語のオリジナル記事。