JP2014524096A - クラウドコンピューティングのためのシステム及び方法 - Google Patents

Abstract

開示される実装方法は、耐障害性及び可用性のあるプライベートクラウドを提供するために、汎用サーバノードと組合わせて構成してもよい、ハードウェアアプライアンス、及び、そのアプライアンスの使用方法、を含む。実装方法は、ソフトウェアコンテナのためのホスト、並びに、外部ネットワーク及びクラウドノードと通信するためのスイッチ、を用いることができる。このようにして、このクラウドコントローラアプライアンスは、企業内部にプライベートクラウドを配置するシステムを、提供することができる。
【選択図】図３

Description

本特許文献に記載される技術は、クラウドコンピューティング、特に、プライベート化されたクラウドの実装に関する。

クラウドコンピューティングは、ユーザにコンピューティングインフラへのリモートアクセスを許可するために確立されたコンピュータネットワークを取り扱う。このように、ユーザは、インフラを購入及び運用する必要はなく、むしろ、ネットワーク上のどこか他の場所に存在するインフラの利用を購入することを許可される。このように、ユーザは、弾力性のあるインフラを利用することが可能となる。

プライベートクラウドネットワークおよびパブリッククラウドネットワークは、様々なレベルのアクセスを提供するために存在する。プライベートクラウドを使うかパブリッククラウドを使うかの決定は、それぞれのパフォーマンスに影響される。

ここで説明されるように、開示される実装方法は、多くの典型的な利益を提供する。当該利益には、例えば、膨大なデータワークロードを組織がより経済的に管理できるようにすること、開発、統合、又は、コンサルティング、を必要としないすぐに使える解決方法を提供すること、汎用のハードウェアを利用してコストを削減することにより実現可能なプライベートクラウドを提供すること、特定のベンダのソリューション内に閉じ込められる企業の窮状を取り除き、代わりに、それら企業が、必要な任意のコンピュートハードウェアおよびストレージハードウェアを選んで簡単に新しいハードウェアに交換できるようにすること、企業がより少ない時間と費用でプライベートクラウドを構築および管理できるようにして、より多くのリソースを事業経営に利用できるよう残せるようにすること、そして、プロバイダが新しいアプリケーションを制作できるようなオープンプラットフォームを提供すること、などが含まれる。

オープンソースのプライベートクラウドプラットフォーム

組織は、ハードウェアとソフトウェアの互換性の問題なしに、つまり高いコストをかけず、プライベートクラウドが提供する柔軟性を求めている。要するに、企業は、「Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ （ＡＷＳ） ｂｅｈｉｎｄ ｔｈｅ ｆｉｒｅｗａｌｌ」、つまり、企業により完全にコントロールされたままであって、柔軟で無制限のストレージ、を求めている。

このビジョンを実現するためには、企業は、オープンソースのソリューションと組み合わされた、入手可能である上に強力な汎用ハードウェアを利用することができなければならない。そのようなハードウェアおよびソフトウェアの組み合わせは、コンサルタントの介在なしに、ＩＴ部門によって円滑に管理される必要があり、不具合があった場合に簡単に交換できるコンポーネントが基礎となっているべきである。

理想的なプライベートクラウドプラットフォームは、ビッグデータに対して拡張性があり、ソフトウェアおよびハードウェアと予め一体化されることを含んでおり、トータルの所有コストが小さいために費用が安く、優れた耐障害性（耐障害性）を有しており、そして、安全で準拠している。

マーケット

ここに開示されるシステム及び方法は、プライベートクラウドを開発及び管理する能力が成功のために重要であるような業界において役立つ可能性があり、また、多くの共通の課題に対処することが可能である。例えば、プライベートクラウドは、バイオテック／ライフサイエンス（研究開発のサイクルを短くする、臨床試験の費用および時間を削減する、研究者との共同研究を促進する）、金融サービス（ポートフォリオリスク分析を行う、不正を発見する）、テレコミュニケーション（顧客離れを減らす、ソーシャルメディアやコンタクトセンター（ｃｏｎｔａｃｔ ｃｅｎｔｅｒ）の情報を分析する）、小売り（サプライチェーンの効率を改善する）、消費者のウェブ環境（コンピュートおよびストレージのリソースを早く提供する、ソフトウェア開発のライフサイクルを短縮する、推薦エンジン（ｒｅｃｏｍｍｅｎｄａｔｉｏｎ ｅｎｇｉｎｅｓ）を改善するデータを分析する）、などで使用することが可能である。

本システムの一例は、プライベートクラウドコンピューティングネットワークを運用するように構成されたシステムであって、少なくとも一つのホスト、および、少なくとも一つのスイッチをそれぞれ備える一つ以上のハードウェアアプライアンスを備え、少なくとも一つのホストが、少なくとも一つのソフトウェアコンテナを管理するように構成され、そして、少なくとも一つのスイッチが、少なくとも一つのクラウドノードと通信するように構成され、かつ、少なくとも一つの外部ネットワークと通信するように構成される、システム、として説明することができる。さらに、前記の一つ以上のアプライアンスは、クラウドネットワークの運用／可用性を維持するように構成される。これは、後述するように、ネットワーク化された際のその冗長性能を通じてなされる。

この例においては、一つ以上のコンテナを、プロビジョニングコンテナ（ｐｒｏｖｉｓｉｏｎｉｎｇ ｃｏｎｔａｉｎｅｒ）、ロギングコンテナ（ｌｏｇｇｉｎｇ ｃｏｎｔａｉｎｅｒ）、データベースコンテナ（ｄａｔａｂａｓｅ ｃｏｎｔａｉｎｅｒ）、キューコンテナ（ｑｕｅｕｅ ｃｏｎｔａｉｎｅｒ）、ＤＮＳコンテナ（ＤＮＳ ｃｏｎｔａｉｎｅｒ）、および、ロードバランサコンテナ（ｌｏａｄ ｂａｌａｎｃｅｒ ｃｏｎｔａｉｎｅｒ）、のリストから選択することができる。

さらに、本例においては、前記一つ以上のアプライアンスは、クラウドコンピューティングシステムを定義づける一つ以上のゾーン内でグループ化され、前記ゾーンにおける前記アプライアンスは、マネジメントネットワーク、ゲストインスタンスネットワーク、及び、外部ネットワーク、の仮想ローカルエリアネットワークのうち一つ以上を通じて互いに通信するように構成され、前記ゾーンにおける前記アプライアンスは、プロビジョニングネットワークによって内部的にノードと通信するように構成されている。

そして、このシステムの例は、さらに、各接続されたデバイスを管理するように、かつ、それらの接続されたデバイスのステータスを提供するように、構成された、ウェブベースのユーザインターフェース、をさらに備えることができる。このアプライアンスの例は、前記クラウドネットワークを、運用、及び／又は、管理、するように構成された、オープンスタックコンテナとしての少なくとも一つのコンテナを有することができる。また、それは、前記クラウドネットワークの運用／可用性を維持するためのコンフィギュレーションであって、ハートビートシステム、及び、オーケストレーションマネージャ、を通じて、少なくとも一つのアプライアンスその他のモニタリングからなるコンフィギュレーションを有することができ、前記ハートビートシステムは、適切な動作を保証するために、アプライアンス、及び／又は、コンテナ、及び、前記オーケストレーションマネージャ、の間において、通信し、及び／又は、ステータスチェックを実行するように、構成された、一つ以上のコンポーネントを含むことができる。

このシステムの例は、それぞれ、冗長性のための同一のコンテナを備える一つ以上のアプライアンスを有することができる。そして、このシステムは、前記ハートビートシステムによって、前記の少なくとも一つのアプライアンス、及び、前記の少なくとも一つのコンテナ、を監視するように、かつ、前記ハートビートシステムが、前記のコンテナ、又は、前記のアプライアンス、が正常に動作していないことを示した場合、ネットワーク化されたアプライアンス内の別のコンテナ、又は、別のアプライアンス、を指定するように、構成された、オーケストレーションマネージャである、前記の一つ以上のコンテナのうちの少なくとも一つを有することができる。

このシステムの例は、前記一つ以上のアプライアンスに由来する一つ以上のコンテナにわたって、ロードを分散するように構成されたロードバランサである、前記ホスト内の前記一つ以上のコンテナの一つを有することができる。そして、少なくとも一つのスイッチは、仮想マシン、ストレージ、及び、計算、のリストから取り込まれるタスクの少なくとも一つに関する、前記の少なくとも一つのクラウドノード、と通信するように、かつ、データを、少なくとも一つの外部ネットワークへ送信、及び、前記少なくとも一つの外部ネットワークから受信、するように、構成されている。

アプライアンスがクラウドノードと通信することのできる別の例は、少なくとも一つのスイッチによって、外部ネットワークから、データリクエストを受信するステップ、少なくとも一つ以上のソフトウェアコンテナにおいて、前記の受信したデータリクエストを処理するステップ、及び、少なくとも一つのスイッチによって、少なくとも一つのクラウドノードへ、クラウドノードデータリクエストを送信するステップ、少なくとも一つのスイッチによって、少なくとも一つのクラウドノードから、クラウドノードデータを受信するステップ、前記少なくとも一つ以上のソフトウェアコンテナにおいて、前記の受信したクラウドノードデータを処理するステップ、及び、前記の受信したデータリクエストへの応答として、前記外部ネットワークへ、前記の処理されたデータを送信するステップ、による。この例では、少なくとも一つのアプライアンスは、別のアプライアンス、又は、多数のアプライアンス、と通信するように、構成される。

この例においては、少なくとも一つのアプライアンスは、冗長性のために構成された二つ以上のネットワーク化されたアプライアンスであり、かつ、前記冗長性は、コンテナタスクを引き継ぐための、冗長コンテナのホスティング、を含む。さらに、前記のバックアップは、前記のネットワーク化されたアプライアンスコンテナの全てとハートビートシステムによって通信するように構成された、オーケストレーションマネージャコンテナを含むことができ、前記オーケストレーションマネージャコンテナは、任意のネットワーク化されたアプライアンス内の少なくとも一つの冗長コンテナであって、前記ハートビートシステムが正常に動作していないと示す少なくとも一つのコンテナの役目を引き継ぐための冗長コンテナを指定する。

さらにこの例について、前記の少なくとも一つのコンテナは、少なくとも一つのコンテナにタスクを割り当てるように構成されたロードバランサであって、前記少なくとも一つのコンテナは、同一のアプライアンス内で、又は、別のネットワーク化されたアプライアンス内で、前記ロードバランサとしてホストされる。そして、この方法は、前記のクラウドネットワークを管理するように構成されたオープンスタックコンテナとしての少なくとも一つのコンテナを有することができる。

再び、この例において、前記のコンテナの少なくとも一つは、前記の少なくとも一つのコンテナからのハートビート情報を受信するように、前記の受信したハートビート情報を処理するように、かつ、前記コンテナが正常に動作していないことを前記ハートビート情報が示している場合、コンテナを交換するための少なくとも一つの他のコンテナを指定するように、構成されたオーケストレーションマネージャコンテナであり、前記少なくとも一つの他のコンテナは、前記のネットワーク化されたアプライアンスのいずれかに含まれる。

そして、これは、マネジメントネットワーク、ゲストインスタンスネットワーク、及び、外部サービスネットワーク、の仮想ローカルエリアネットワークのうちの一つ以上によって通信する、ネットワーク化されたアプライアンスであって、アグリゲーションスイッチによって、外部ネットワークと通信するように構成されたアプライアンスを用いることができる。

最後の一例は、プライベートクラウドコンピューティングネットワークを運用するように構成されたシステムであって、少なくとも一つのスイッチによって、外部ネットワークからデータリクエストを受信し、少なくとも一つ以上のソフトウェアコンテナにおいて、前記の受信したデータリクエストを処理し、少なくとも一つのスイッチによって、少なくとも一つのクラウドノードへクラウドノードデータリクエストを送信し、少なくとも一つのスイッチによって、少なくとも一つのクラウドノードからクラウドノードデータを受信し、前記少なくとも一つ以上のソフトウェアコンテナにおいて、前記の受信したクラウドノードデータを処理し、前記受信したデータリクエストへの応答として、前記外部ネットワークへ前記の処理したデータを送信するように、構成された一つ以上の、コンポーネント、及び／又は、ハードウェアアプライアンス、を備え、前記の少なくとも一つのアプライアンスは、少なくとも一つの他のアプライアンスと接続するように構成されたシステムであってよい。

このシステムの例は、オーケストレーションマネージャとしての少なくとも一つのコンテナを有することができる。当該オーケストレーションマネージャは、ハートビートシステムを用いて前記の少なくとも一つのコンテナの冗長性を管理するように構成され、前記ハートビートシステムは、前記少なくとも一つのコンテナ、及び、前記オーケストレーションマネージャコンテナ、の間の、コンテナのパフォーマンスに関する通信からなり、前記オーケストレーションマネージャは、正常に動作していないコンテナを、別のアプライアンスに含まれる別のコンテナと交換するように構成される。

そして、このシステムの最後の例は、前記のネットワーク化されたアプライアンスのいずれかの内の任意のコンテナにわたって、ロードを分散するように構成されたロードバランサとしての、少なくとも一つのコンテナを有することができる。

本願において説明される実装方法をよりよく理解するために、以下の図面と併せて、下記の詳細な説明が参照されるべきである。参照番号は、図面を通じて、対応する箇所を示している。

最近のデータの成長を示す図である。 パブリッククラウド対プライベートクラウドの長所と短所を示す図である。 開示された実装方法に基づく、代表的な、プライベートクラウドの実装のためのネットワークのコンフィギュレーションを示す図である。 開示された実装方法に基づく代表的なアプライアンスを示す図である。 開示された実装方法に基づく、代表的な、コンポーネント間のネットワーク通信路を示す図である。 開示された実装方法に基づく、代表的な、アプライアンス間のネットワーク通信路を示す図である。 開示された実装方法に基づく、代表的な、コンポーネント間の通信路とプロトコルを示す図である。

実装方法について詳述する。それらは、添付の図において図示されている。以下の詳細な説明においては、ここで示される内容の十分な理解を与えるために、多くの具体的な詳細が説明されている。しかし、当業者にとっては、これらの具体的な詳細がなくとも、当該内容を実施することは可能であると考えられる。さらには、ここで説明される特定の実装方法は、例として与えられるており、本発明の範囲をこれら特定の実装方法に限定するために用いられるべきではない。他の例において、周知のデータ構造、タイミングプロトコル（ｔｉｍｉｎｇ ｐｒｏｔｏｃｏｌｓ）、ソフトウェアオペレーション（ｓｏｆｔｗａｒｅ ｏｐｅｒａｔｉｏｎｓ）、プロシージャ（ｐｒｏｃｅｄｕｒｅｓ）、および、コンポーネント（ｃｏｍｐｏｎｅｎｔｓ）が、本発明の実装方法の特徴を不必要に不明瞭としないよう、詳細に説明されている。

イントロダクション

情報を、管理、分析、および、理解、する能力は、急速に競争の差異化要素になってきている。データを理解するためにコンピュータの力を利用できない組織は、それら組織が、革新的な躍進を達成できず、顧客にサービスを提供できず、また、グローバルに展開できないことに、気づくであろう。プライベートクラウドは、データ管理において必要とされる、柔軟性、収容力、および、安全性、をつくり出すためのアプローチであるとみなされてきた。しかし、プライベートクラウドテクノロジーの、コスト、および、複雑さ（および未熟さ）が、多くの企業がこれら利益を利用することを妨げてきた。

プライベートクラウド

開示される実装方法は、例えば、企業がデータから重要な躍進や洞察を得ることを妨げている財務的および技術的な障壁を取り除く、プライベートクラウドコンピューティングに対する新規なアプローチを解説している。三つのまとまったトレンドが、プライベートクラウドの採用を現実のものとすることを約束している。

トレンド１：データの爆発

企業は、事業データの急激な成長を経験している。記憶能力および計算能力は、この成長の早さに追いつくことができていない。マッキンゼー（ＭｃＫｉｎｓｅｙ）（登録商標）によると、２００９年までに、「米国経済のほとんど全ての分野が、１０００人以上の従業員を抱える一企業当たり、少なくとも平均２００テラバイト（米国の小売業者Ｗａｌ−Ｍａｒｔの１９９９年のデータウェアハウス（ｄａｔａ ｗａｒｅｈｏｕｓｅ）のサイズの２倍）、の保管データを有していた。」とされている（「Ｂｉｇ ｄａｔａ： ｔｈｅ ｎｅｘｔ ｆｒｏｎｔｉｅｒ ｆｏｒ ｉｎｎｏｖａｔｉｏｎ， ｃｏｍｐｅｔｉｔｉｏｎ， ａｎｄ ｐｒｏｄｕｃｔｉｖｉｔｙ」マッキンゼー・アンド・カンパニー、２０１１年５月）。フェイスブック（Ｆａｃｅｂｏｏｋ）（登録商標）やツイッター（Ｔｗｉｔｔｅｒ）（登録商標）などのソーシャルネットワーク（Ｓｏｃｉａｌ ｎｅｔｗｏｒｋｓ）は、会員によりアップロードされた莫大な数のデータを、当該データの利用可能性に対するますます高くなる期待を伴って、管理している。このデータの爆発（その一部は、デジタルデバイスおよびビッグデータを中心とする研究が激増することにより引き起こされる）は、新たな分析の、ツール、プロセス、および、プラットフォーム、を生み出しており、これらは、コンピューティングインフラをその性能の限界まで押しやっている。

データの爆発的な増加は、そこから情報が豊富に収集されるため、組織にとって、主としては良いことである。組織は、ビジネストレンドを見抜くため、犯罪行為を発見するため、そして、小さな問題が重大で利益を害する危機になる前にそれらを解決するため、データを利用することができる。

しかしながら、過剰な情報は、ビジネスを促進するものではなく、ビジネスを阻害するものである。企業は、データがますます氾濫するようになっているため、価値ある洞察を得るためのデータ解析ができていない。企業はまた、データの加工用のストレージはおろか、保存用のストレージも有していないのである。

トレンド２：サービスとしてのインフォメーションテクノロジー

企業は、ビジネスのあらゆる部分の効率を最大化する方法を探し求めており、そして、ＩＴも例外ではない。ＩＴ部門は、単に技術的サービスを提供するのではなく、コストを管理する、コンプライアンスの要求を満たす、サービスの利用可能性を保証する、−そして、全体的には、ビジネスに価値を付加する、という全体的なビジネスのゴールを共有しなければならない。特に、企業は、ビジネスにおける素早さに対する要求を満たすために、ＩＴサービスに頼っている。

弾力性のある、コンピュート、ストレージ、および、ネットワーク、のサービスをつくり出す必要性のみならず、ビジネスにおける素早さという目的を満たすため、ＩＴ部門は、彼らの能力を補うのに資するものとしてクラウドサービスに期待している。例えば、クラウドの利用は、効率や経営を改善し、コストを削減し、そして、成長の機会を増加させる。

他の技術トレンドが、サービスインペラティブ（Ｓｅｒｖｉｃｅ ｉｍｐｅｒａｔｉｖｅ）としてのＩＴに流れ込んでいる。企業は、プライベートクラウドの環境が整うと、突然多くのアプリケーションやコンフィギュレーションメディケーション（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｍｅｄｉｃａｔｉｏｎｓ）を管理するようになる。ガートナー（Ｇａｒｔｎｅｒ）（登録商標）によると、ひとたび組織がプライベートクラウドを採用すると、ＲＦＣ（ｒｅｑｕｅｓｔ ｆｏｒ ｃｈａｎｇｅ）は２，０００／月から７０，０００／月に増加する可能性があり、稼働中のアプリケーションは２００から３，０００に増加する可能性がある。ガートナーは、「サービス指向アーキテクチャ（ＳＯＡ）へと傾倒する結果として、ダイナミックな変化要求を伴って、変化量が増加するであろう。」としている。「ＩＴ組織がサービス提供者へと進化すると、変化およびコンフィギュレーションへの集中が継続し、ビジネス価値を示すのはより容易になるであろう。」（「Ｂｅｓｔ Ｐｒａｃｔｉｃｅｓ ｉｎ Ｃｈａｎｇｅ， Ｃｏｎｆｉｇｕｒａｔｉｏｎ ａｎｄ Ｒｅｌｅａｓｅ Ｍａｎａｇｅｍｅｎｔ」ガートナー、２０１０年７月）

開示された実装方法は、実装および運用における，コスト、複雑さ、および、パフォーマンス、の問題を解決するのに必要とされるアーキテクチャについての大きな進歩を提供する。金融サービス、バイオテクノロジー、および、エネルギー、などの多様な業界が、劇的に削減されたコストで、かつ、遙かに簡単な技術で、それら業界が有する最大のデータ処理という課題に対処することができる。結果として、常に増え続けるデータの中に見出される豊富な知識や発見を大いに利用することが可能となる。

トレンド３：オープンソース及びコモディティスケールアウトアーキテクチャ

オープンソースソフトウェアへの流れによって、企業は、独自のプライベートクラウドの開発により注視するようになっている。ソフトウェアサービスのレイヤおよびストレージそれ自体がコモディティ化するにつれて、ウェブ企業は−仕方なく−コモディティハードウェアの上に、安価にスケールアウトした独自のアーキテクチャを構築した。フェイスブックやグーグル（Ｇｏｏｇｌｅ）（登録商標）などのマーケットリーダーはこの方法を取っており、必要な計算力及びストレージを集中させるため、汎用の機械同士をつなげ、そして、独自のアプリケーションを書いている。オープンソースおよびコモディティスケールアウトアーキテクチャの実質的な利益は、それらがクラウドシステムの安価なスケールアウトを可能にしたという点である。

プライベートクラウドの問題点

上記のトレンドによりプライベートクラウドの採用がますますもたらされる一方で、それらのインプリメンテーションに対するいくつかの問題点が依然として存在する。そのような問題点のいくつかの例は以下の通りである。

問題点１：実証済みのスケールアウト

大量のデータを扱っている非常に大きい企業は、彼らがほぼ無制限のストレージおよび順応性を有するプライベートクラウドをつくり出すことができるということを示している。しかしながら、この種の企ては、非常に多額の予算及び多数のスタッフを有する企業に限られる傾向がある。プライベートクラウドは大抵、複雑で高価なサーバ及びストレージソリューションのインプリメンテーションを必要とし、それら全てが互換性およびインテグレーションの問題を生み出す可能性がある。これらの問題を解決するためには、企業は、それらのクラウドソリューションにおける全てのコンポーネントが協働して必要なコンピューティングプラットフォームをつくり出すようにするために、高額なコンサルタントのサービスを購入しなければならない。このレベルで、システムの、統合、開発、及び、試験、を実行するために要求されるスキルは、高度に専門化され、そして通常は社内で利用することはできない。それゆえに、外部のコンサルタントが必要とされる。

問題点２：コンピュート及びストレージの停滞

データは、プライベートクラウドのストレージ能力よりも速く増大している。下記の図１で示されるように、エコノミスト誌（Ｔｈｅ Ｅｃｏｎｏｍｉｓｔ）は、インターナショナル・データ・コーポレーション（ＩＤＣ）によると、世界のデータは２０１１年末までに１，７５０エクサバイトに達する見込みであり、一方で利用可能なストレージは７５０エクサバイトまでしか到達しないと予測されている、と伝えている。

問題点３：システム障害に対する脆弱性及び傾向

システムは、予測不可能で、また、その最も弱い要素と同じ程度に不安定である。システム障害は常に脅威である。企業は、耐障害性を企業のプライベートクラウドに組み込もうと試みることはできる。しかし、サーバが機能しなくなると、交換費用は高く、そして、データは何時間も利用できなくなる可能性がある。図２は、パブリッククラウド対プライベートクラウドの、長所と短所を示している。

オープンソース及びコモディティスケールアウトアーキテクチャ

オープンソースソフトウェアへの流れによって、企業は、独自のプライベートクラウドの開発により注視するようになっている。ソフトウェアサービスのレイヤおよびストレージそれ自体がコモディティ化するにつれて、ウェブ企業は−仕方なく−コモディティハードウェアの上に、安価にスケールアウトした独自のアーキテクチャを構築した。フェイスブック（登録商標）やグーグル（登録商標）などの市場のリーダーはこの方法を取っており、必要な計算力及びストレージを集中させるため、汎用の機械同士をつなげ、独自のアプリケーションを書いている。

アーキテクチャの概観

開示された実装方法の基礎は、耐障害性があり利用可能なプライベートクラウドを提供するために、汎用のサーバノードと一体となるように構成することのできるハードウェアアプライアンス、および、そのアプライアンスの使用方法、である。このクラウドコントローラアプライアンス（ｃｌｏｕｄ ｃｏｎｔｏｒｏｌｌｅｒ ａｐｐｌｉａｎｃｅ）は、企業内部にプライベートクラウドを配置するシステムを提供することができる。分散コントロールプレーン（ｄｉｓｔｒｉｂｕｔｅｄ ｃｏｎｔｒｏｌ ｐｌａｎｅ）、及び、さらなる高可用性（ＨＡ）のプライベートクラウド、をつくり出すため、複数のアプライアンスを併せて使用することが可能である。

図３は、この例では、固有の、ホスト３１２、及び、スイッチ３３０、を有する一つのアプライアンス３１０により構成される、ゾーン３００の例の全体像を示している。アプライアンス３１０は、外部ネットワーク３５０と通信する。アプライアンス３１０はまた、クラウドノード３６０及び３７０とも通信する。この図３は、単に一実施例にすぎない。アプライアンス、クラウドノード、および、外部ネットワーク、の数は任意の数でよい。

例であるアプライアンス３１０の内部には、ホスト３１２およびスイッチ３３０がある。ホスト３１２は、一組のクラウドマネジメントソフトウェアコンテナ３２０、および、一組のオープンスタックコンテナ３４０、を管理する。スイッチ３３０は、外部カスタマーネットワーク（ｅｘｔｅｒｎａｌ ｃｕｓｔｏｍｅｒ ｎｅｔｗｏｒｋ）３５０および、例３６０および３７０として示されているようなクラウドノードと通信するように構成される。

ゾーン

図３では、二つのクラウドノード３６０および３７０、並びに、外部カスタマーネットワーク３５０、と接続するアプライアンス３１０が一つだけ示されている。この例では、このグルーピングは、ゾーン３００と呼ばれる。この配置は単に一例に過ぎない。また、対応するクラウドノードを有し、外部カスタマーネットワークと通信するアプライアンスであって、ゾーン３００において協働するアプライアンスは、任意の数である。

ゾーン３００は、互いに通信する一組のアプライアンスの周囲における、抽象概念である。クラウドは、一つまたは複数のゾーン３００から構成されてもよい。ゾーン内部では、単一のアプライアンスを用いることができる。しかしながら、高可用性（ＨＡ）を確実なものとするためには、複数のアプライアンスを伴うコンステレーションアプローチ（ｃｏｎｓｔｅｌｌａｔｉｏｎ ａｐｐｒｏａｃｈ）が必要とされる。従来の高可用リナックス（Ｌｉｎａｘ−ＨＡ）技術を用いることができ（例えば、ハートビート（Ｈｅａｒｔｂｅａｔ）／ペースメーカー（Ｐａｃｅｍａｋｅｒ））、また、フローティングインターネットプロトコル（ＩＰ）アドレスを用いてゾーンを代表させることができる。これら実施例は、この公開中で後述されている。

オープンスタック

この説明中で、「オープンスタック（ＯｐｅｎＳｔａｃｋ）」の用語は、あるオープンソースプラットフォームを説明するために用いられ、この例においては、プライベートクラウドのソフトウェア基盤として用いられる。この公開の中では、「オープンスタック」の用語が使用される場合はいつでも、任意のクラウドコンピューティングネットワークのソフトウェア基盤として用いられる、後述の、類似のプラットフォームの実施例と、代替することができる。

オープンスタックは、効果的に配置するのが難しいかもしれない。ここで説明されるように、公開される実施例は、プライベートクラウドを効果的に実装および管理すべくオープンスタックの効果的かつ効率的な配置を容易にするために、一つのハードウェアアプライアンス（または複数のハードウェアアプライアンス）を利用しており、それによって、オープンスタックプライベートクラウドの設定および配置の複雑さを排除している。ここで説明されるアプライアンスは、既存のシステムに適合するように構成され、かつ、「プラグアンドプレイ」方式によって使用することができ、また、処理ワークロード、ストレージソリューション、および、ここで説明される追加の特徴、を提供するために、汎用のサーバノードを利用している。図３は、公開される実施例によるプライベートクラウドの実装のための代表的なネットワークコンフィギュレーションを示している。

プライベートクラウドの運用のためのサービスは、ソフトウェアコンテナとしてのアプライアンス内部に収容することができる。これらには、マネジメント・アンド・プロビジョニングダッシュボード（Ｍａｎａｇｅｍｅｎｔ ａｎｄ Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｄａｓｈｂｏａｒｄ）、オープンスタックコンピュートネットワークマネジメント（ＯｐｅｎＳｔａｃｋ Ｃｏｍｐｕｔｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ）（ＩＰＡＭ、ＤＮＳ、ＤＨＣＰ）、オープンスタックコンピュートＡＰＩ（ＯｐｅｎＳｔａｃｋ Ｃｏｍｐｕｔｅ ＡＰＩ）、オープンスタックイメージレジストリＡＰＩ（ＯｐｅｎＳｔａｃｋ Ｉｍａｇｅ Ｒｅｇｉｓｔｒｙ ＡＰＩ）、オープンスタックストレージＡＰＩ（ＯｐｅｎＳｔａｃｋ Ｓｔｏｒａｇｅ ＡＰＩ）、オープンスタックアイデンティティマネジメント（ＯｐｅｎＳｔａｃｋ Ｉｄｅｎｔｉｔｙ Ｍａｎａｇｅｍｅｎｔ）、コンピュート・アンド・ストレージプロビジョニングＡＰＩ（Ｃｏｍｐｕｔｅ ａｎｄ Ｐｒｏｖｉｓｉｏｎｉｎｇ ＡＰＩ），データベースサービス・アンド・キューイングインフラストラクチャ（ＤａｔａｂａｓｅＳｅｒｖｉｃｅ ａｎｄ Ｑｕｅｕｉｎｇ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）、ログアグリゲーション・アンド・シッピング（Ｌｏｇ ａｇｇｒｅｇａｔｉｏｎ ａｎｄ ｓｈｉｐｐｉｎｇ）、ヘルスモニタリング（Ｈｅａｌｔｈ Ｍｏｎｉｔｏｒｉｎｇ）、および、サービスロードバランシング（Ｓｅｒｖｉｃｅ ｌｏａｄ ｂａｌａｎｃｉｎｇ）、が含まれ得るが、しかし、これらに限られない。

クラウドノード

アプライアンス３１０内のスイッチ３３０は、任意の数のクラウドノードと通信するように構成される。図３におけるこの例では、二つのクラウドノード３６０および３７０が示されている。ここで説明されるクラウドノードは、意図された、ワークロード、および、ストレージのニーズ、にとって適切なハードウェアコンフィギュレーションにより構成される、任意の汎用サーバであってよい。適切なクラウドノードサーバは、例えば、ＯｐｅｎＣｏｍｐｕｔｅ、Ｄｅｌｌ（登録商標）、ＨＰ（登録商標）、ＩＢＭ（登録商標）、などを含むが、しかし、他のものでも同様に機能するかもしれない。クラウドノードは、ライブマイグレーション（ｌｉｖｅ ｍｉｇｒａｔｉｏｎ）のための稼働中の仮想マシン（ｖｉｒｔｕａｌ ｍａｃｈｉｎｅｓ）を格納するのに用いられる。ノードはまた、より永続的で信頼性のあるストレージのために稼働中の仮想マシンに取り付けられるブロックデバイス（ｂｌｏｃｋ ｄｅｖｉｃｅｓ）、をつくるために用いることもできる。

コンステレーションアプローチ

公開される実施例のアプライアンスは、単独で作動させることもできるし、より好ましくは、グループで作動させることもできる。図３では、一つのアプライアンス３１０のみが示されている。しかしながら、共にネットワーク化された任意の数のアプライアンスが存在し得る。これらアプライアンスが共にネットワーク化されているとき、本公開の他の箇所で説明されるように、それらアプライアンスはゾーンの中でグループ化することができる。プライベートクラウドのロジカルゾーン（ｌｏｇｉｃａｌ ｚｏｎｅ）に、より多くのアプライアンスが追加されるにしたがって、パフォーマンスは向上し、かつ、サービスはより耐障害性を増す。このように、より多くのアプライアンスが「コンステレーション」に追加されるにしたがって、システムの、冗長性、耐障害性、及び、パフォーマンス、が全体として直線的に向上する。

クラウドマネジメントコンテナ

さらに、図３の実施例において、クラウドマネジメントコンテナ３２０は、アプライアンス３１０のホスト３２０の内部に示されている。これらクラウドマネジメントコンテナ３２０は、クラウド、又は、ゾーン、の内部における、アプライアンス及び他のコンポーネント、及び、ソフトウェアコンテナ、の管理を容易にするために、用いられる。拡張性のある管理ツールを利用することで、しばしば個々の配置それぞれに特有のカスタマイゼーションとともに、複合環境（ｈｙｂｒｉｄ ｅｎｖｉｒｏｎｍｅｎｔ）での管理が可能となる。マネジメントコンテナ３２０は、ウェブベースのユーザインターフェースを含むことができ、これは、接続されたデバイスを管理し、かつ、システム内の各デバイスの現在のステータスを提供する。

クラウドコントローラアプライアンス

アプライアンスは、（たとえ、現在、ゾーンコントローラ（ｚｏｎｅ ｃｏｎｔｒｏｌｌｅｒ）／ゾーンマスタ（ｚｏｎｅ ｍａｓｔｅｒ）であっても、）ゾーンの一要素となり得るし、かつ、ゾーンＩＰから独立した独自のＩＰを有し得る。下記のように、アプライアンスレベルのオペレーションは、主として、アプライアンスを構成する個々のコンポーネントのプロビジョニングのような機能を中心として展開するであろう。

これらのオペレーションは、主として、コマンドラインインターフェース、又は、ウェブインターフェース、から情報を得るために存在する。したがって、各アプライアンス及び内部のコンテナの状態及び健康状態（ｈｅａｌｔｈ）についての、非常に詳細な情報を得ることができる。

コンテナによる組織化

図４は、図３に示したアプライアンス、及び、それに関連するクラウドノード、の詳細である。図４に示されているように、ここに説明される各アプライアンス４００は、様々なソフトウェアコンテナを管理するホスト４６４、及び、ここに説明されるスイッチ４４０、を含むことができる。各コンテナは、設定、リスタート、シャットダウン等のカスタムオペレーション（ｃｕｓｔｏｍ ｏｐｅｒａｔｉｏｎｓ）を有してもよい。

ホスト

ホスト４２０は、例えば、多くのソフトウェアコンテナを管理する。いくつかのコンテナは、アプライアンス、及び、クラウド、を管理するために用いることができるが、例えば、ゾーン、アプライアンス、及び、コンテナ、を管理するためのＡＰＩを公開するオーケストレーションマネージャ（ＯｒｃｈｅｓｔｒａｔｉｏｎＭａｎａｇｅｒ）４２４、データベースサービス（ＤａｔａｂａｓｅＳｅｒｖｉｃｅ）４２６、及び、分散ストレージサービス（ＤｉｓｔｒｉｂｕｔｅｄＳｔｏｒａｇｅＳｅｒｖｉｃｅ）４２２、などである。他の目的のためには、別のコンテナは用いることができる。それらは任意の様々なソフトウェアであってよく、そして、いくつかの例としては次のものを含んでもよい。

プロビジョニングサービスコンテナ（ＰｒｏｖｉｓｉｏｎｉｎｇＳｅｒｖｉｃｅ ｃｏｎｔａｉｎｅｒ）４３６は、アプライアンスにつながれたノードのベアメタルオーケストレーション（ｂａｒｅ−ｍｅｔａｌ ｏｒｃｈｅｓｔｒａｔｉｏｎ）を容易にし、オペレーティングシステムのコンフィギュレーションを起動（ｂｏｏｔ ｓｔｒａｐ）し、そして、アプライアンス内部の各個別のサービスコンテナを構成及び創作するように、構成される。

プロビジョニングサービスコンテナ４３６は、ベアメタルオーケストレーションに用いられるソフトウェアである。これは、オペレーティングシステムイメージ（ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ ｉｍａｇｅ）を取得し、そして、ＰＸＥプロトコルのような標準的なプロトコルを使って、ネットワークを超えて、コンピュートノード、又は、ストレージノード、にオペレーティングシステムイメージを適用する。プロビジョニングサービス４３６はまた、ＤＨＣＰにより、ＩＰアドレス管理を提供することもできる。オペレーティングシステムイメージは、分散ストレージサービス４２２を用いて、アプライアンスのグループ内で共有することができる。

ここに説明されるメッセージディスパッチャコンテナ（ＭｅｓｓａｇｅＤｉｓｐａｔｃｈｅｒ ｃｏｎｔａｉｎｅｒ）は、ＨＴＴＰベースのメッセージのディスパッチングのシステムである。これは、マネジメントダッシュボード及びコマンドラインインターフェースのツールを用いて、ＡＰＩリクエストに情報を提供し、かつ、システム管理者及びオーケストレーションマネージャソフトウェアの間を橋渡しするために用いることができる。

データベースサービスコンテナ４２６は、他のアプライアンスサービスによって使用可能な、高可用性の、ストレージ状態、及び、コンフィギュレーション情報、のデータベースを提供する。データベースは、分散ストレージサービスの上に位置し、高速のフェイルオーバー（ｆａｉｌｏｖｅｒ）及びレプリケーション（ｒｅｐｌｉｃａｔｉｏｎ）の能力を実現している。

ロギングサービス（ＬｏｇｇｉｎｇＳｅｒｖｉｃｅ）４３８コンテナは、プライベートクラウドの外側のシステムへのログシッピング能力だけでなく、ｒｓｙｓｌｏｇのようなシステムを通じたロギング能力を提供する。また、ロギングサービス（ＬｏｇｇｉｎｇＳｅｒｖｉｃｅ）４３８コンテナは、ＡｒｃＳｉｔｅやＳｐｌｕｎｋのような、多くの標準的なセキュリティ及びオペレーションソフトウェアへのアップリンク（ｕｐｌｉｎｋ）を提供する。

バランササービスコンテナ（ＢａｌａｎｃｅｒＳｅｒｖｉｃｅ ｃｏｎｔａｉｎｅｒ）４３２は、ロードバランサ（ｌｏａｄ ｂａｌａｎｃｅｒ）となるように構成される。バランサコンポーネントは、ＨＡＰｒｏｘｙのような技術を用いて、実装することができる。バランササービス４３２は、ＳＳＬ ｔｅｒｍｉｎａｔｉｏｎのフロントエンド（ｆｒｏｎｔ ｅｎｄ）を、ｎｏｖａ−ａｐｉやｇｌａｎｃｅ−ａｐｉなどの様々なウェブベースのＡＰＩに対する、各リクエストに提供することができる。バランササービスは、インテリジェントロードバランシング（ｉｎｔｅｌｌｉｇｅｎｔ ｌｏａｄ ｂａｌａｎｃｉｎｇ）を、これらのＡＰＩサービスに提供することができ、より多くのアプライアンスが追加されるにしたがってパフォーマンス及び信頼性が向上する。

モニタリングサービスコンテナ（ＭｏｎｉｔｏｒｉｎｇＳｅｒｖｉｃｅ ｃｏｎｔａｉｎｅｒ）４３４は、負荷を監視するように構成されたサービスとなるように構成される。モニタリングコンポーネントは、ＮａｇｉｏｓやＧａｎｇｌｉａのような技術を含み得る。モニタリングサービスは、汎用ハードウェア又はサービスの障害が多く発生した場合に、イベントベースの警告（ａｌｅｒｔｉｎｇ）を提供し、かつ、システム管理者がそれらの配置の健康状態の変化へと注意を向けることを可能とする。モニタリングサービスは、リアルタイム及びヒストリカル（ｈｉｓｔｏｒｉｃａｌ）なシステムレベル測定基準のモニタリングを提供し、ＣＰＵの使用、ディスクＩ／Ｏ、ネットワークＩ／Ｏ、その他をリアルタイムに見ることが可能となる。

ダッシュボードサービスコンテナ（ＤａｓｈｂｏａｒｄＳｅｒｖｉｃｅｓ ｃｏｎｔａｉｎｅｒ）４６４は、ウェブベースのダッシュボードに向かった管理者及びエンドユーザの両者を提供するように構成される。ダッシュボードサービス４６４は、システム管理者に、自身のプライベートクラウドの高レベルな、コンフィギュレーション、及び、運用ステータス、を見る方法を提供する。ダッシュボードサービスは、エンドユーザに、稼働中の自身のバーチャルインスタンス（ｖｉｒｔｕａｌ ｉｎｓｔａｎｃｅｓ）を監視する手段、自身のオブジェクトストア（ｏｂｊｅｃｔ ｓｔｏｒｅ）にアクセスする手段、及び、仮想マシンイメージ（ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ ｉｍａｇｅｓ）を管理する手段、のような、個人のクラウドアプリケーションを管理する多くの機能を提供する。

この例における最後のコンテナは、オープンスタックの一部である。それらは、ｇｌａｎｃｅコンテナ４６６、ｋｅｙｓｔｏｎｅコンテナ４６０、及び、Ｎｏｖａコンテナ４２８、である。環境次第で、他のオープンスタックコンテナをここで用いることもできるし、より少ないオープンスタックを用いてもよい。さらに、オープンスタックの他に、他の類似のタイプのコンテナをこれらの場所で管理してもよい。

この例においては、Ｇｌａｎｃｅコンテナ４６６（オープンスタックの一部）は、仮想マシンイメージストアとなるように構成される。このコンテナは、システムのユーザが、自身の稼働中の仮想マシンのスナップショット（ｓｎａｐｓｈｏｔｓ）を撮り、かつ、スナップショットをアップロードすることを、可能とするように構成されており、好きなように、そのイメージの多くのインスタンスを素速く提供することを可能とする。Ｇｌａｎｃｅコンポーネントは、ｇｌａｎｃｅ−ａｐｉ及びｇｌａｎｃｅ−ｒｅｇｉｓｔｒｙを含む。Ｇｌａｎｃｅ−ａｐｉは、このサービスに対するＨＴＴＰベースＡＰＩのフロントエンドであり、また、ｇｌａｎｃｅ−ｒｅｇｉｓｔｒｙは、仮想マシンイメージを保存及び取得する、核となるコンポーネントである。

Ｋｅｙｓｔｏｎｅコンテナ４６０（オープンスタックの一部）は、アブストラクションアイデンティティマネジメントシステム（ａｂｓｔｒａｃｔｉｏｎ ｉｄｅｎｔｉｔｙ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ）を提供するように構成することができる。このコンテナは、共通の認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）及び認可（ａｕｔｈｏｒｉｚａｔｉｏｎ）のフロントエンドとして機能するように構成することができる。このコンポーネントは、ｋｅｙｓｔｏｎｅ−ａｐｉを含んでいるが、これは、ＬＤＡＰ、Ｋｅｒｂｅｒｏｓ、及び、ＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙのような、多くの共通の認証システムに対するアイデンティティマネジメントフロントエンドである。これにより、カスタマーが、自身の既存アイデンティティマネジメントシステムを、オープンスタックサービスとともに使用することが、可能となる。

Ｎｏｖａコンテナ４２８（オープンスタックの一部）は、ノードを支持及び／又は制御する補完的なサービスを提供する。Ｎｏｖａ４２８コンポーネントは、ｎｏｖａ−ｎｅｔｗｏｒｋ、ｎｏｖａ−ｓｃｈｅｄｕｌｅｒ、及び、ＱｕｅｕｅＳｅｒｖｉｃｅｓ、を含む。Ｎｏｖａ−ｎｅｔｗｏｒｋは、ノードに対する、ＩＰアドレスマネジメント及びＤＨＣＰサービスを提供する。Ｎｏｖａ−ｓｃｈｅｄｕｌｅｒは、Ｎｏｖａ ＡＰＩからの仮想マシンプロビジョニングリクエストを受け取り、そして、負荷及び他の要素に基づいて、コンピュートホストを知的に選択する。ＱｕｅｕｅＳｅｒｖｉｃｅｓは、様々なＮｏｖａコンピュートサービスの全てに対するキューベースのメッセージ通信を提供し、ゾーンを横断する拡張性のある通信を可能にする。

スイッチ

アプライアンス４００のスイッチ４４０は、様々な、クラウドノード４５０、及び、外部ネットワーク（図示されていない）、と通信するように構成される。任意の適切なタイプのネットワークスイッチ４４０を、アプライアンスにおいて、ネットワークスイッチ４４０として使用することができる。これにより、アプライアンスにつながれた全てのノードに対する、高速で冗長性のあるネットワーク接続性を提供することが可能となる。

クラウドノード

図４の例は、アプライアンス４００のスイッチ４４０とつながった多くのクラウドノードを図示している。一つのアプライアンス４００は、任意の数のクラウドノード４５０を使用することができる。そして、クラウドノード４５０について、任意のタイプのサーバを用いてもよい。ここで説明されるように、代表的なノードは、ｎｏｖａ−ｃｏｍｐｕｔｅコンポーネント、及び、分散ストレージサービスコンポーネント、を含むであろう。Ｎｏｖａ−ｃｏｍｐｕｔｅ４２８は、Ｎｏｖａ ＡＰＩリクエストと、コンピュートノード自体におけるハイパーバイザー（ｈｙｐｅｒｖｉｓｏｒ）とを、橋渡しするサービスである。このサービスは、ｎｏｖａ−ａｐｉからｎｏｖａ−ｓｃｈｅｄｕｌｅｒを通じてメッセージを受け取り、かつ、仮想マシンを、作成し、終了し、又は、移行するよう、ハイパーバイザーに指示を出す。分散ストレージサービスは、簡易なライブマイグレーションのための稼働中の仮想マシンを、保存するために用いられる。分散ストレージサービスはまた、より永続的で信頼性のあるストレージのために稼働中の仮想マシンとつなげることのできる、ブロックデバイスを作成するために用いられる。

クラウドノード４５０はまた、拡張性、信頼性のあるオブジェクトストアを提供することができる。これにより、ユーザは、ＨＴＴＰインターフェースを超えてオブジェクトを読み書きしたり、あるいは、自身のオブジェクトストアを直接、稼働中の仮想マシンに、標準的なＰＯＳＩＴファイルシステムとして搭載したりすることが可能となる。これらの能力は、ゾーン内の全てのノードによって構成される分散ストレージサービスによって提供される。ここで説明されるように、オブジェクトストレージを提供する代表的なノードは、好ましくは、ｒｓｙｎｃ、ｓｗｉｆｔ−ａｃｃｏｕｎｔ、ｓｗｉｆｔ−ｏｂｊｅｃｔ、ｓｗｉｆｔ−ｃｏｎｔａｉｎｅｒ、ｓｗｉｆｔ−ｃｏｎｔａｉｎｅｒ−ｕｐｄａｔｅｒ、ｓｗｉｆｔ−ａｃｃｏｕｎｔ−ａｕｄｉｔｏｒ、ｓｗｉｆｔ−ｏｂｊｅｃｔ−ｒｅｐｌｉｃａｔｏｒ、ｓｗｉｆｔ−ｃｏｎｔａｉｎｅｒ−ｒｅｐｌｉｃａｔｏｒ、ｓｗｉｆｔ−ｃｏｎｔａｉｎｅｒ−ａｕｄｉｔｏｒ、ｓｗｉｆｔ−ａｃｃｏｕｎｔ−ｒｅｐｌｉｃａｔｏｒ、ｓｗｉｆｔ−ａｃｃｏｕｎｔ−ｒｅａｐｅｒ、ｓｗｉｆｔ−ｏｂｊｅｃｔ−ｕｐｄａｔｅｒ、及び、分散ストレージサービスコンポーネント、を含むであろう。

アプライアンスホストＯ／Ｓは、好ましくは、以下のロジカルサービス（ｌｏｇｉｃａｌ ｓｅｒｖｉｃｅｓ）を有するが、しかし、環境によって他のものを有したり、より少なくてもよい。データベースサービスのためのストレージを提供する分散ストレージサービス４２２（ゾーンを横切る共有ストレージ）は、データベースサービス、キューサービス、ログファイル、及び、共有ストレージハートビート／ｃｒｍを必要とする他の任意のもの、にストレージを提供し、マスター／スタンバイを提供し、フローティングｉｐを管理し、かつ、ロジカルゾーンコントローラを提供する。また、オーケストレーションマネージャ４２４は、マネージメント、及び、プロビジョニング、の能力を提供する。

ネットワーク接続性

この例におけるアプライアンスは、外部ネットワークと通信するように構成される。これは、カスタマーネットワークであってもよく、あるいは、ここに説明されるシステムの実装のために、任意の種類のコンピューティングネットワークを利用してもよい。適切なネットワーク接続性の代表的な図が、図５に示されている。

図５は、ネットワークがどのようにして、ここに説明されるプライベートクラウドのコンポーネントを接続してよいのかを示した例である。この図では、任意の内部コンテナ（図示されていない）の接続のために、仮想ローカルエリアネットワーク（ＶＬＡＮ）が用いられている。これらのＶＬＡＮを通じて、コンテナは、隔離したり、外部ネットワークと通信したり、他のコンテナと通信したり、そして、ラック（ｒａｃｋ）を下って通信したり、といったことが可能である。

図５はラックが描かれている。当該ラックは、ラック１、つまり５２２から、任意の数のラック、ここではラック「Ｎ」、つまり５３２までである。これらのラックは、管理ネットワーク５４０、ゲストインスタンスネットワーク５６０、及び、外部サービスネットワーク５９０、によってつながれている。各ラック、つまりラックＮ（５３２）及びラック１（５２２）は、独自のプロビジョニングネットワーク５８０及び５８２をそれぞれ有している。これらのネットワークを通じて、ラックは、アグリゲーションスイッチ５１０及びカスタマーネットワーク５１４に、ＶＬＡＮトンネル５１６によって、接続されている。

ここに示される管理ネットワーク（ＶＬＡＮ１０）５４０の例におけるＩＰ範囲は、１７２．１７．０．０／１２である。ここに示されるゲストインスタンスネットワーク（ＶＬＡＮ２０）５６０の例におけるＩＰ範囲は１０．１６．０．０／１２である。ここに示されるプロビジョニングネットワーク（ＬＣＡＮ２、Ｎａｔｉｖｅ）５８０の例におけるＩＰ範囲は１９２．１６８．２００．０／２４である。ここに示される外部サービスネットワーク（ＶＬＡＮ３０）５９０の例におけるＩＰ範囲は、ユーザ定義となる。

高可用性設計

開示される実施例は、ネットワーク化されたアプライアンスの「コンステレーション」アプローチを利用することによって、汎用性サーバのラックを、他のプライベートクラウドソリューションよりも非常に安価なコストで一体として機能する、ノードの組織化されたコンステレーション、に変えてしまうことを可能にする。

アプライアンスの各コンテナは、通信を容易にするために複数のＩＰアドレス（例えば、１０個のＩＰアドレス）を使ってもよい。グローバルな高可用性メカニズムでは、クラスタリングリソース（ｃｌｕｓｔｅｒｉｎｇ ｒｅｓｏｕｒｃｅｓ）のために、追加のＩＰアドレス（例えば、７個のグローバル（フローティング）ＩＰアドレス）を使用してもよい（例えば、アプライアンス／ゾーンマスタに１つ、内部コンテナ用に６つ）。

図６及び図７は、システムの高可用性（ＨＡ）設計の代表的なコンフィギュレーションを示している。図６及び図７は、２つの部分に分けられるが、しかし、線は頁を横切って流れており、断線によってそれが示されている。図６及び図７は、図４に示されているアプライアンスのもう一つの実施例を示しているが、しかし、それに接続可能な様々なアプライアンスの内部、及び、それらアプライアンス間、で通信するコンポーネントコンテナをつなぐ通信線と共に示している。そして、コンテナはアプライアンス内部にある。このようにして、複数のアプライアンスを共にネットワーク化することができ、システムの能力を高めることができる。

特に図６及び図７は、ここでは２つ、すなわち６２０及び６３０のみを示すことによって、一連のアプライアンスを描いている。任意の数のアプライアンスが同様に接続され得ると考えられるべきである。

ここで説明されるように、クラウドのＨＡの側面、つまり冗長性の側面は、（個々のアプライアンスに特有であるのとは対照的に）クラウドに特有のアプライアンス内部のコンテナは、冗長バックアップを必要とするということである。パックアップは、アプライアンスを関連づけることでＨＡを生み出し、そして、クラウドに特有のコンテナが停止したり、正常に機能していない場合に、別の類似のコンテナが、ロードを取り上げることを保証する。このようにして、アプライアンスは、お互いをバックアップし、アプライアンス内部のコンテナは他のアプライアンスコンテナをゾーン内でバックアップする。

「ハートビート」及び「ペースメーカー」通信

アプライアンスの「コンステレーション」内部で、例えばゾーン内で、各アプライアンスは、ゾーン又はクラウド内部の他の全てのアプライアンスと通信することができる。特に、クラウド内部で共に接続されたアプライアンスは、「ハートビート」シグナルの送信を利用して、他のアプライアンス及びデバイスのステータスを確認し、各々が適切に動作していることを保証すると共に、誤動作がないか確認している。「ハートビート」の利用をより容易にするために、コンテナは好ましくは、「コンステレーション」の内部でマスター又はスレーブの役割を与えられ、リクエストに最も効率よく情報を提供する。

「ハートビート」通信の間に利用するために、フローティングＩＰアドレスがアプライアンス間で与えられてもよい。データベースサービスのデータレプリケーション（ｄａｔａ ｒｅｐｌｉｃａｔｉｏｎ）の持続性において、データベースマスター／スレーブコンフィギュレーションを、データレプリケーションとともに利用することができる。

図６及び図７において、「クラスタｉｐ、ペースメーカー＋ハートビート」のシンボルが隣に添えられたもの、例えば、データベース６６４、キュー６４０、ＤＮＳ６４２、及び、バランサ６４６は全て、クラウドに特有のコンテナの例である。アプライアンスに特有のコンテナの例は、プロビジョニングコンテナ６６０、又は、ロギングコンテナ６６２、である。これらは、関連する「クラスタｉｐ、ペースメーカー＋ハートビート」のシンボルを示していないが、その理由は、これらが、クラウドに特有のコンテナのように高可用性であるように構成されてはいないからである。

アプライアンス６２０全体もまた、クラスタｉｐ、及び、ペースメーカーとハートビートのモニタ６２２を通じて、隣のアプライアンス６３０と、その各々の、クラスタｉｐ、及び、ペースメーカーとハートビートのモニタ６３２とに、接続されるように構成されている。このように、アプライアンスも、ＨＡを実現することができる。

この例において、ゾーンを代表するために用いられるフローティングＩＰは、１７２．２４．１．１．である。ＩＰを用いることで、ゾーンレベルの管理能力が、次のように公開される。

このリストが示すのは、例えばここでは、これらファンクションのうち、どの１アプライアンスにとっても、特別なものはない、ということである。アプライアンスのいずれもが、これらのリクエストに応じることができるが、しかし、論理的な理由から、１７２．２４．１．１．を有する現在のマスターのみである。

バックアップは、アプライアンスのオーケストレーションマネージャ６２６及び６３６によって管理される。各オーケストレーションマネージャには、分散ストレージシステム６２８及び６３８がそれぞれ関連している。クラウドに特有のコンテナはそれぞれ、オーケストレーションマネージャ６２６に、それらの「健康状態」を、「クラスタｉｐ、ペースメーカー＋ハートビート」システムを通して、伝える。コンテナの「健康状態」は、その特定のコンテナが有している適切に動作する能力、として考えることができる。コンテナが意図した通りに機能している場合、コンテナは良い「健康状態」を有している。もしそうでない場合、コンテナは、悪い健康状態を有しており、オーケストレーションマネージャ６２６によって交換する必要があるかもしれない。この場合、オーケストレーションマネージャ６２６は、別のネットワーク化されたアプライアンス内の、同じ機能を担う新しいコンテナを指定するであろう。

例えば、図６及び図７に示されるように、データベースコンテナ６６４のようなクラウドに特有のコンテナが不健康になった場合、第１のアプライアンス６２０のオーケストレーションマネージャ６２６は、別のアプライアンス６３０と通信する。交換が必要な関連するコンテナは、ここではデータベースコンテナ６６４であるが、それは、次のアプライアンス６３０内の冗長データベースコンテナ６７４に交換されるであろう。データベースコンテナの例においては、関連するデータベース自体６６８もまた、その冗長バックアップ６７８に交換されるであろう。「クラスタｉｐ、ペースメーカー＋ハートビート」システムがデータベース６６８に付随して、その関連するオーケストレーションマネージャ６３６にその健康状態を報告する。

このようにして、ゾーンを通して利用される全てのコンテナ、及び／又は、クラウドを、高可用にすることができる。キュー６４０は、そのバックアップ６５０によって、ＤＮＳ６４２はそのバックアップ６５２によって、バランサ６４６はそのバックアップ６５６によって、高可用性にすることができる。それらの「クラスタｉｐ、ペースメーカー＋ハートビート」システム６７６、６５０、６５４、及び、６５８それぞれについても、同様のことが当てはまる。そして、ここに示される２つだけよりも多くのアプライアンスを用いることにより、ＨＡを任意の数のアプライアンスにまで広げて、より高い冗長性能を得ることが可能である。

ロードバランシング

第１のアプライアンス６２０のバランサコンテナ６４６は、多数の他のコンテナと通信するように構成される。しかし、クラウドレベルに特有のコンテナにおけるＨＡバックアップシステムとは異なり、ロードバランサは、任意かつ全ての利用可能なオープンスタックコンテナに対するロードを、シャッフル（ｓｈｕｆｆｌｅ）、かつ、分散、するために、用いられる。これは、コンテナの「健康状態」を考えながらなされる。しかし、また、多くの他の要素も考慮される。この例では、ロードバランサは、オープンスタックシステム内のコンテナに対するロードを分散している。これは単に例に過ぎず、任意の種類のコンテナを、オープンスタックシステムの役割をさせるために用いることができる。

アプライアンスの例に示されているオープンスタックコンテナは、ｇｌａｎｃｅコンテナ６８０、ｄａｓｈｂｏａｒｄコンテナ６８２、ｋｅｙｓｔｏｎｅコンテナ６８４、及び、ｎｏｖａコンテナ６８６である。しかし、ＨＡシステムにおいては、壊れたコンテナ、又は、不良のコンテナ、を交換するために、オーケストレーションマネージャは、別のアプライアンス内にある冗長コンテナを必要とするが、ＨＡシステムとは異なり、ここでは、ロードバランサ６４６は、タスクを達成するために、任意の数のオープンスタックコンテナを必要とする。ｇｌａｎｃｅコンテナ６８０、ｄａｓｈｂｏａｒｄコンテナ６８２、ｋｅｙｓｔｏｎｅコンテナ６８４、及び、ｎｏｖａコンテナ６８６のような、これらのオープンスタックコンテナを、同じアプライアンス内に置くことができる。または、それらは、ｇｌａｎｃｅコンテナ６９０、ｄａｓｈｂｏａｒｄコンテナ６９２、ｋｅｙｓｔｏｎｅコンテナ６９４、及び、ｎｏｖａコンテナ６９６、からなる６３０の組のように、別のアプライアンスに置くことができる。

したがって、図６及び図７に示されるように、バランサコンテナ６４６は、ロードを、任意かつ全てのこれらコンテナに、設計された任意の方式で、送ることができる。このように、ロードバランサ６４６をこれら全てのオープンスタックコンテナにつなげている回路は、それらコンテナへと一斉に向かっている。ロードの送信には、任意の代表的な通信回路を用いることができる。

ロードバランサは、依然、全体的なＨＡシステムの一部でもある。したがって、アプライアンス６３０のような別のアプライアンス内のバランサコンテナ６５６は、マスター又はオリジナルのロードバランサ６４６の健康状態が悪く、オーケストレーションマネージャ６２６がその情報をバランサ「クラスタｉｐ、ペースメーカー＋ハートビート」システム６４８から受け取った場合にのみ、使われる。その場合、次のアプライアンス内のバランサ、ここでは６５６が、分散タスクを取り上げ、そして、上記の任意のアプライアンス内の、任意かつ全てのオープンスタックコンテナへのロードの分散を開始する。その代替バランサ６５６は、また、冗長性及びＨＡを保証するために、その「クラスタｉｐ、ペースメーカー＋ハートビート」システム６５８によって、健康状態の情報を、そのオーケストレーションマネージャ６３６へ送るであろう。

成長

開示されるアプローチによって、組織は、そのような配置に通常含まれる複雑さを排除することによって、組織のクラウドインフラを設け、そして、それを基礎として拡大することができるようになる。耐障害性及び故障防止のために、内部でサービスを構成することができる。共有ストレージシステムを内部で利用することにより、より多くのアプライアンスが追加され、そして、コンステレーションが成長するにつれて、各アプライアンスの入出力のスピードが増加する。

さらに、「コンステレーション」アプローチを利用することで、クラウド環境は拡張可能となり、そして成長する能力を得る。特に、開示される実施例のシステムは、数ノードからなる小さなシステムから、多数のノードへと拡大し、かつ、クラウド全体にわたってノンブロッキングファブリック（ｎｏｎ−ｂｌｏｃｋｉｎｇ ｆａｂｒｉｃ）を提供する、能力を有する。

耐障害性

耐障害性は、クラウド環境において重要であろう。「コンステレーション」アプローチ、及び、上述のアプライアンス間の「ハートビート」、を利用することで、開示される実施例のシステムは耐障害性を有している。単一のクラウドを形成するため、アプライアンスのグループを共に関連づけることにより、欠陥のあるアプライアンス又は他のコンポーネントを、特定し、分離し、そして、場合によってはシステムから排除することも、可能となる。欠陥が生じた場合、欠陥のあるアプライアンス又はコンポーネントの機能は、「コンステレーション」内の他のデバイスによって引き継ぐことができる。さらに、各機能は、「コンステレーション」内の複数のアプライアンスにより複製することができ、それによって、単一のアプライアンス又は他のコンポーネントが何らかの理由で故障した場合に、システムのクラッシュ及び他の問題の防止する一助となる。さらに、「コンステレーション」の拡張性により、低コストのコンピュート又はストレージのノード又はデバイスを、既存のシステムのラック内に（すなわち、既存の「コンステレーション」内に）追加することが容易になり、また、それらが機能しなくなったときにサーバのラックを交換することさえ容易になる。

自己修復

「コンステレーション」アプローチ及び上述のアプライアンス間の「ハートビート」を用いることによって、一つ以上のアプライアンス又は他のコンポーネントが、機能しなくなるか、又は、誤って機能したかを、診断することができる。これが起こる場合、他の任意のアプライアンスが、好ましく、欠陥のあるアプライアンス又はコンポーネントを修正することができ、必要であれば、それを初期の（又は、その後修正した）状態に復元することができる。

検疫

さらに、一つ以上のアプライアンス又は他のコンポーネントにおいて、セキュリティの欠陥が生じると、欠陥のあるアプライアンス又はコンポーネントを迅速に検疫することができ、そして、それらアプライアンス及びコンポーネントの機能はクラウド内の他のデバイスに引き継がれる。

代表的なハードウェアのバリエーション

ここに説明されるように、上述の実施例は、ハードウェアデバイス及びソフトウェアの任意の組み合わせ、例えば、コンピューティングデバイス上で実行されるモジュールとともに実装される。ここに説明されるデバイス及びコンポーネントは、様々な機能性を例証しており、かつ、いずれの実施例の構造も制限しない。むしろ、様々なデバイス及びコンポーネントの機能性は、様々に分けてもよく、かつ、様々な設計事情により、実行するデバイス及びコンポーネントはより多くても、より少なくてもよい。

ここに説明されるデバイスは、例えば、ストレージデバイスに保存されコンピュータが読み込むことのできる指示（すなわち、コード）のような指示を処理するように設計された、一つ以上のプロセシングデバイスを含んでもよい。プロセシングデバイスは、指示を処理することによって、ここに開示されるステップ及び機能を実行してもよい。ストレージデバイスは、例えば、非一時的（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ）ストレージデバイスのような、任意のタイプのストレージデバイス（例えば、光学ストレージデバイス、磁気ストレージデバイス、ソリッドステートストレージデバイス等）であってよい。代わりに、指示は一つ以上のリモートストレージデバイス、例えば、ネットワーク又はインターネットを通じてアクセスするストレージデバイスに、保存してもよい。コンピューティングデバイスは、さらに、メモリ、入力コントローラ、及び、出力コントローラ、を備えてもよい。バスが、動作可能なように、プロセッサ、メモリ、ストレージデバイス、入力コントローラ、出力コントローラ、及び、任意の他のデバイス（例えば、ネットワークコントローラ、サウンドコントローラ等）を含む、コンピューティングデバイス及びアプライアンスのコンポーネントを、組み合わせてもよい。（例えば実行されるモジュールへの応答として）出力コントローラがディスプレイデバイス上のディスプレイを変換できるような方法で、出力コントローラを、（例えば、有線接続又は無線接続によって）ディスプレイデバイス（例えば、モニタ、テレビジョン、モバイルデバイススクリーン、タッチディスプレイ等）に動作可能なようにつなげてもよい。ユーザからの入力を受信することができるような方法で、入力コントローラを（例えば、有線接続又は無線接続によって）入力デバイス（例えば、マウス、キーボード、タッチパッド、スクロールボール、タッチディスプレイ等）に動作可能なようにつなげてもよい。

もちろん、コンピューティングデバイス、ディスプレイデバイス、及び、入力デバイスは、特定を容易にするためだけに、別個のデバイスとして説明されている。コンピューティングデバイス、ディスプレイデバイス、及び、入力デバイスは、別個のデバイス（例えば、有線によりモニタ及びマウスにつながれたパーソナルコンピュータ）であってもよいし、単一のデバイス（例えば、スマートフォンやタブレットなどの、タッチディスプレイを備えたモバイルデバイス）の中に統合されてもよいし、あるいは、デバイスの任意の組み合わせ（例えば、タッチスクリーンディスプレイデバイスに動作可能なようにつながれたコンピューティングデバイス、単一のディスプレイデバイス及び入力デバイスに取り付けられた複数のコンピューティングデバイス）であってもよい。コンピューティングデバイスは、一つ以上のサーバ、例えば、ネットワーク化されたサーバのファーム（ｆａｒｍ）、クラスタ化されたサーバ環境、又は、コンピューティングデバイスのクラウドネットワーク、であってもよい。

ここでは実施例が開示されている。しかしながら、実施例の範囲から離れることなしに、様々な変更をなすことが可能である。前記の説明は、説明のために、特定の実施例を参照して記述されている。しかしながら、上述の実例の議論は、網羅的であることを意図したものではなく、また、開示された正確な形態に発明を限定することを意図したものではない。上述の説明を踏まえて、多くの変更や変種が可能である。発明の原理及びその実際の応用を最もよく説明し、それによって、当業者が、想定される特定の用途に適合するような様々な変更とともに、発明及び様々な実施例を最適に利用できるように、実施例が選択され、また、記述されている。

Claims (20)

1. プライベートクラウドコンピューティングネットワークを運用するように構成されたシステムであって、
   少なくとも一つのホスト、及び、少なくとも一つのスイッチ、をそれぞれ有する一つ以上のハードウェアアプライアンスを備え、
   前記少なくとも一つのホストは、少なくとも一つのソフトウェアコンテナを管理するように構成され、かつ、
   前記少なくとも一つのスイッチは、少なくとも一つのサーバノードと通信するように構成され、かつ、少なくとも一つの外部ネットワークと通信するように構成され、
   前記の一つ以上のアプライアンスは、前記のクラウドネットワークの運用／可用性を維持するように構成された、システム。
2. 前記の一つ以上のコンテナが、プロビジョニングコンテナ、ロギングコンテナ、データベースコンテナ、キューコンテナ、ＤＮＳコンテナ、及び、ロードバランサコンテナ、からなるリスト、から選択される、請求項１に記載のシステム。
3. 前記一つ以上のアプライアンスは、一つ以上のゾーン内で、グループ化され、前記ゾーンは、クラウドコンピューティングシステムを定義し、
   前記ゾーンにおける前記アプライアンスは、マネジメントネットワーク、ゲストインスタンスネットワーク、及び、外部ネットワーク、の仮想ローカルエリアネットワークのうち一つ以上を通じて互いに通信するように、構成され、かつ、
   前記ゾーンにおける前記アプライアンスは、プロビジョニングネットワークによって内部的にノードと通信するように、構成された、請求項１に記載のシステム。
4. 各接続されたデバイスを管理するように、かつ、それらの接続されたデバイスのステータスを提供するように、構成された、ウェブベースのユーザインターフェース、をさらに備える、請求項１に記載のシステム。
5. 前記の少なくとも一つのコンテナは、前記クラウドネットワークを、運用、及び／又は、管理、するように構成されたオープンスタックコンテナである、請求項１に記載のアプライアンス。
6. 前記クラウドネットワークの運用／可用性を維持するためのコンフィギュレーションは、ハートビートシステム、及び、オーケストレーションマネージャ、を通じて、前記の少なくとも一つのアプライアンスその他のモニタリングからなり、
   前記ハートビートシステムは、適切な動作を保証するために、アプライアンス、及び／又は、コンテナ、及び、前記オーケストレーションマネージャ、の間において、通信し、及び／又は、ステータスチェックを実行するように、構成された、一つ以上のコンポーネントを含む、請求項１に記載のシステム。
7. 前記の一つ以上のアプライアンスは、それぞれ、冗長性のための同一のコンテナを備えている、請求項６に記載のシステム。
8. 前記の一つ以上のコンテナのうちの少なくとも一つは、オーケストレーションマネージャであって、
   前記オーケストレーションマネージャは、ハートビートシステムによって、前記の少なくとも一つのアプライアンス、及び、前記の少なくとも一つのコンテナ、を監視するように、かつ、前記ハートビートシステムが、前記のコンテナ、又は、前記のアプライアンス、が正常に動作していないことを示した場合、ネットワーク化されたアプライアンス内の別のコンテナ、又は、別のアプライアンス、を指定するように、構成された、請求項１に記載のシステム。
9. 前記ホスト内の前記一つ以上のコンテナの一つは、前記一つ以上のアプライアンスに由来する一つ以上のコンテナにわたって、ロードを分散するように構成されたロードバランサである、請求項８に記載のシステム。
10. 前記少なくとも一つのスイッチは、仮想マシン、ストレージ、及び、計算、のリストから取り込まれるタスクの少なくとも一つに関する、前記の少なくとも一つのクラウドノード、と通信するように、かつ、データを、少なくとも一つの外部ネットワークへ送信、及び、前記少なくとも一つの外部ネットワークから受信、するように、構成された、請求項１に記載のシステム。
11. コンピュータにより実施される、プライベートクラウドコンピューティングネットワークシステムの運用のための方法であって、少なくとも一つのハードウェアアプライアンスにおいて、
    少なくとも一つのスイッチによって、外部ネットワークから、データリクエストを受信するステップ、
    少なくとも一つ以上のソフトウェアコンテナにおいて、前記の受信したデータリクエストを処理するステップ、
    少なくとも一つのスイッチによって、少なくとも一つのクラウドノードへ、クラウドノードデータリクエストを送信するステップ、
    少なくとも一つのスイッチによって、少なくとも一つのクラウドノードから、クラウドノードデータを受信するステップ、
    前記少なくとも一つ以上のソフトウェアコンテナにおいて、前記の受信したクラウドノードデータを処理するステップ、及び、
    前記の受信したデータリクエストへの応答として、前記外部ネットワークへ、前記の処理されたデータを送信するステップ、
    を含み、前記の少なくとも一つのアプライアンスは別のアプライアンスと通信するように構成された方法。
12. 前記少なくとも一つのアプライアンスは、冗長性のために構成された二つ以上のネットワーク化されたアプライアンスであり、かつ、
    前記冗長性は、コンテナタスクを引き継ぐための、冗長コンテナのホスティング、を含む、請求項１１に記載の方法。
13. 前記のバックアップは、前記のネットワーク化されたアプライアンスコンテナの全てとハートビートシステムによって通信するように構成された、オーケストレーションマネージャコンテナを含み、
    前記オーケストレーションマネージャコンテナは、任意のネットワーク化されたアプライアンス内の少なくとも一つの冗長コンテナであって、前記ハートビートシステムが正常に動作していないと示す少なくとも一つのコンテナの役目を引き継ぐための冗長コンテナを指定する、請求項１２に記載の方法。
14. 前記の少なくとも一つのコンテナは、少なくとも一つのコンテナにタスクを割り当てるように構成されたロードバランサであって、
    前記少なくとも一つのコンテナは、同一のアプライアンス内で、又は、別のネットワーク化されたアプライアンス内で、前記ロードバランサとしてホストされる、請求項１１に記載の方法。
15. 前記の少なくとも一つのコンテナは、前記のクラウドネットワークを管理するように構成されたオープンスタックコンテナである、前記請求項１１に記載の方法。
16. 前記のコンテナの少なくとも一つは、前記の少なくとも一つのコンテナからのハートビート情報を受信するように、前記の受信したハートビート情報を処理するように、かつ、前記コンテナが正常に動作していないことを前記ハートビート情報が示している場合、コンテナを交換するための少なくとも一つの他のコンテナを指定するように、構成されたオーケストレーションマネージャコンテナであり、
    前記少なくとも一つの他のコンテナは、前記のネットワーク化されたアプライアンスのいずれかに含まれる、請求項１１に記載の方法。
17. 前記のネットワーク化されたアプライアンスは、マネジメントネットワーク、ゲストインスタンスネットワーク、及び、外部サービスネットワーク、の仮想ローカルエリアネットワークのうちの一つ以上によって、通信し、
    各アプライアンスは、プロビジョニング仮想ローカルエリアネットワークによって、内部的に通信し、かつ、
    前記ネットワーク化されたアプライアンスは、アグリゲーションスイッチによって、外部ネットワークと通信するように構成された、請求項１１に記載の方法。
18. プライベートクラウドコンピューティングネットワークを運用するように構成されたシステムであって、
    少なくとも一つのスイッチによって、外部ネットワークからデータリクエストを受信し、少なくとも一つ以上のソフトウェアコンテナにおいて、前記の受信したデータリクエストを処理し、少なくとも一つのスイッチによって、少なくとも一つのクラウドノードへクラウドノードデータリクエストを送信し、少なくとも一つのスイッチによって、少なくとも一つのクラウドノードからクラウドノードデータを受信し、前記少なくとも一つ以上のソフトウェアコンテナにおいて、前記の受信したクラウドノードデータを処理し、前記受信したデータリクエストへの応答として、前記外部ネットワークへ前記の処理したデータを送信するように、構成された一つ以上の、コンポーネント、及び／又は、ハードウェアアプライアンス、を備え、
    前記の少なくとも一つのアプライアンスは、少なくとも一つの他のアプライアンスと接続するように構成されたシステム。
19. 前記のコンテナの少なくとも一つは、ハートビートシステムを用いて前記の少なくとも一つのコンテナの冗長性を管理するように構成されたオーケストレーションマネージャコンテナであって、
    前記ハートビートシステムは、前記少なくとも一つのコンテナ、及び、前記オーケストレーションマネージャコンテナ、の間の、コンテナのパフォーマンスに関する通信からなり、
    前記オーケストレーションマネージャは、正常に動作していないコンテナを、別のアプライアンスに含まれる別のコンテナと交換するように構成された、請求項１８に記載のシステム。
20. 前記のコンテナの少なくとも一つは、前記のネットワーク化されたアプライアンスのいずれかの内の任意のコンテナにわたって、ロードを分散するように構成されたロードバランサである、請求項１８に記載のシステム。

Images