JP2023546907A - クラスタリング可能なサービスの自動クラスタリングのためのシステムおよび方法 - Google Patents

Abstract

システムは、クラスタリング可能なサービスのクラスタを自動的にデプロイするように構成することができる。例えば、コントローラは、アプリケーションの複数のコピーをデプロイすることができ、これらのアプリケーションは、互いに依存し合うことができる。また、コントローラは、これらのアプリケーションを管理する（ロードバランシングを含む）スケジューラを構成することができる。コントローラで使用されるサービステンプレートには、クラスタリングルールを含めることができ、これらのクラスタリングルールは、コントローラに対して、これらのサービスの接続方法を指示することができます。クラスタリングルールは、複数のリソースへのサービスのデプロイを提供するロジック命令および／または一連のテンプレートであり得る。クラスタリングルールの結合命令は、別々に予約された物理および／または仮想リソースの調整および相互作用を定義し、依存関係を設定する。クラスタリングルールは、サービスによって使用されるリソースをスケールアップまたはスケールダウンするための情報の使用を定義する。

Description

関連特許出願への相互参照と優先権の請求：
本特許出願は、２０２０年１０月１９日に出願され、「クラスタリング可能なサービスの自動クラスタリングのためのシステムおよび方法」と題された米国仮特許出願６３／０９３，６９１の優先権を請求しており、その開示全体は参照として本書に組み込まれる。

はじめに：
コンピュータユーザー、特に企業によって生成され、消費されるデータの量が増加し続ける中、ハイパフォーマンス・コンピューティング（ＨＰＣ）システムの幅広い展開に技術的なニーズがある。ＨＰＣの魅力は、並列化による計算収束の低減だけでなく、巨大なデータ記憶帯域幅へのアクセス、ＣＰＵやグラフィックプロセッサユニット（ＧＰＵ）などのコンピュートハードウェアを異なるタスク用にスケジュールする能力、人工知能（ＡＩ）／機械学習（ＭＬ）コンポーネントとの統合、計算ハードウェアリソースの効率的管理にもある。さらに、ＨＰＣを利用したコンピュータ工学支援システム／電子設計自動化（ＥＤＡ）とＡＩの融合も進んでおり、シミュレーションによって生成された膨大なデータをＡＩモデルに再帰的に送り込み、光ネット、ロジックの配備、プロセスの調節を解析して特定する。このＥＤＡとＡＩ／ＭＬの統合により、製品開発が加速して品質を向上させるが、安定でシンプルかつ複雑なハードウェア環境でも光学性能を発揮するランタイム環境が必要となる。

ＨＰＣは従来、低レイテンシー、高スループット、大規模並列処理、大規模分散システムを特徴としてきた。数百万ドルの計算機予算を持つ従来の科学的ユーザーにとって、情報技術（ＩＴ）や専門家によるソフトウェア開発のコストは、計算時間のコストのほんの数パーセントに過ぎないこともあり、セットアップの容易さと使いやすさがシステムに十分に備わっていないことを意味する。その結果、従来のＨＰＣは使いにくく、運用のための人材費用が高額になる。

しかし、ＨＰＣの広い普及は多くの企業にとって課題となっている。なぜなら、モノリシックなワークステーションベースや特注のコンピューティングベースのプラットフォームからＨＰＣプラットフォームへの移行は、非自明なタスクだからである。つまり、限られたＩＴ予算と平均的なＩＴ管理能力を持つ専門家ではないユーザーがＨＰＣアプリケーションにアクセスできるようにすることは技術的に難しい。

これらの技術的課題の解決策として、本発明者らはクラスタリング可能なサービスのクラスタのデプロイを自動化する技術を開示する。システムがサービスを「クラスタ化」すると言えるのは、そのサービスの複数のインスタンスを実行し、複数のインスタンスが連携して動作し、互いに命令を受け渡しできる場合である。例えば、データマイニングのアプリケーションを実行する２０台のサーバを含むシステムを考えてみる。これらのサーバはそれぞれ相互に作用する必要があり、これらの相互作用をスケジュールするためのリソースが必要である。クラスタ化されたサービスのこの調整は、特に（仮想化ではなく）ベアメタル上でサービスを実行しているシステムにとって困難な技術的課題となる可能性がある。クラスタ化されたサービスのベアメタルデプロイは、顧客のコプロセッサまたはＧＰＵ上で実行されるサービスにとって有利である。ここで使用する「インスタンス」という用語は、リソース上にデプロイされたサービスを指し、リソースには物理、仮想、またはコンテナリソースが含まれるが、これらに限定されていない。クラスタは、そのクラスタに属する複数のインスタンスを持つことができる。

これらの技術は、ＨＰＣアプリケーションをデスクトップから超並列環境を持つコンピュータシステムにシームレスにスケーリングするためのツールとして使用でき、これにはＧＰＵクラスタやＧＰＵをサポートする混合ハードウェアにわたるデプロイが含まれる場合がある。例示的な実施形態において、Ｕ．Ｓ． Ｐａｔ． Ａｐｐ． Ｐｕｂ． ２０１９／０３３４９０９およびＷＩＰＯ Ｐｕｂ． ＷＯ ２０２０／２５２０８８の中で本発明者らにより記載されたコンピュータシステムは、これらの開示全体が参照により本明細書に組み込まれており、クラスタ管理サービスを含めて拡張させ、ＨＰＣにおけるクラスタリング可能なアプリケーションの商業的に実行可能な自動構成のための経路を提供することができる。

このような例示的な実施形態を通じて、クラスタを採用するコンピュータシステムは、サービスとしての高性能コンピューティング（ＨＰＣａａＳ）を提供するために使用することができる。ＨＰＣａａｓは、クラウドコンピューティングとＨＰＣのハイブリッドであり、手頃なコストと、比較的少ないコンピュータ時間で、多くのユーザーがＨＰＣにアクセスできるようにする。従来のＨＰＣシステムでは、一度に１つのアプリケーションを利用することが多かったが、ＨＰＣａａＳでは、リソースプールとしてクラスタ化されたサービスやストレージを利用する機能、ユーザーがジョブ要求を提出するためのＷｅｂインターフェース、全体としての最大の生産性を得るために異なるアプリケーション特性を考慮して特定のクラスタで複数の異なるアプリケーションを同時にスケジュールできるスマートスケジューリングを利用することができる。

本発明の例示的な実施形態のこれらおよび他の特徴や利点は、以下において詳細に説明される。

図１は、実施形態例によるシステムの略図である。 図２は、図１のシステムのコントローラの一例を示す略図である。 図３は、クラスタ化されたネットワークにサービスインスタンスをデプロイした例である。 図４は、クラスタ化されたネットワークにサービスインスタンスをデプロイした例である。 図５は、クラスタにコンピュートリソースを追加するためのプロセスフローの例を示す。 図６は、クラスタツールがクラスタの要求を管理する場合の例である。 図７は、クラスタの依存関係を満たすために、コントローラが依存関係を管理／計算する例を示す。 図８は、スマートクラスタリング可能なネットワークとストレージエリアネットワーク（ＳＡＮ）を備えた、クラスタにおけるサービスインスタンスの別のデプロイ例を示す。 図９は、クラスタリングルールの例を示す。 図１０は、相互に依存する２つのクラスタ化されたサービスが、共有ストレージで結合されている例である。 図１１は、クラスタをサービスとしてデプロイする例である。 図１２は、システム起動時の処理フロー例である。 図１３は、エンドポイントを呼び出すためのさまざまな方法の例である。 図１４は、エンドポイントを呼び出すためのさまざまな方法の例である。 図１５は、コントローラによってデプロイされるクラスタを示す図である。 図１６Ａは、コンピュータリソースを追加してクラスタを成長させる例を示している。 図１６Ｂは、コンピュータリソースを追加してクラスタを成長させる例を示している。 図１７Ａは、新しいクラスタを作成するためのプロセスフローの例を示す図である。 図１７Ｂは、クラスタを成長させるか、ノード／リソースを追加するためのプロセスフローの例を示す図である。 図１８Ａは、様々なクラスタ操作のための例示的なプロセスフローを示す。 図１８Ｂは、様々なクラスタ操作のための例示的なプロセスフローを示す。

実施形態の例の詳細な説明：
図１は、本明細書に記載のクラスタリング技術の実施に関連して使用することができる例示的なコンピュータシステム１００を示す。

システムコンポーネント例：
ユーザーインターフェース（ＵＩ）１１０が、アプリケーションプログラムインターフェース（ＡＰＩ）アプリケーション１２０を介してコントローラ２００に結合されているのが示されている。ＡＰＩ１２０は、スタンドアローンの物理サーバまたは仮想サーバに存在することができるが、その必要はない。ＡＰＩ１２０は、１つまたは複数のＡＰＩアプリケーションで構成されることがあり、これらは冗長であること、および／または並行して動作することがある。ＡＰＩ１２０は、システムリソースを構成する要求を受け取り、要求を解析して、コントローラ２００に渡す。ＡＰＩ１２０は、コントローラ２００から１つまたは複数の応答を受け取り応答を解析し、ＵＩ（またはアプリケーション）１１０にそれらを渡す。代替的または追加的に、アプリケーションまたはサービスはＡＰＩ １２０と通信することができる。

コントローラ２００は、本明細書で議論される制御操作のいずれかを実施するために、１つまたは複数のプロセッサおよび１つまたは複数のメモリにデプロイすることができる。そのような制御操作を実行するためのプロセッサ（複数可）による実行のための命令は、プロセッサメモリなどの非一過性のコンピュータプログラムを記録した記録媒体に常駐させることができる。コントローラ２００は、１つまたは複数の計算リソース３００、ストレージリソース４００およびネットワークリソース５００に結合される。したがって、システムは、コントローラ２００がシステム１００内で設定および制御することができる複数の計算リソース３００、複数のストレージリソース４００、および／または複数のネットワークリソース５００のプールを含むことができる。リソース３００、４００、５００は、単一のノード上に存在してもよいが、システム１００内の複数のノードに存在し得るので、そうである必要はない（または複数のノードに様々な組み合わせで存在してもよい）。また、リソース３００、４００、５００のうちの１つ以上は仮想であってもよい。物理デバイスは、計算リソース３００、ストレージリソース４００、およびネットワークリソース５００を含むが、これらに限定されないリソースタイプの１つまたは複数のうちのそれぞれを構成し得る。上述のように、リソース３００、４００、５００は、異なる物理的な場所にあるかどうか、仮想であるかどうかにかかわらず、そのようなリソースのプールを構成することができる。ベアメタルのコンピュートリソースは、仮想またはコンテナのコンピュートリソースの使用を有効にするために使用されることもある。

ノードの既知の定義に加えて、本明細書で使用するノードは、ネットワーク（複数可）に接続された任意のシステム、デバイスまたはリソース、またはスタンドアローンまたはネットワーク接続デバイスで機能を実行する他の機能ユニットであり得る。また、ノードは、例えば、サーバ、物理または仮想ホスト上のサービス／アプリケーション／複数のサービス、仮想サーバ、および／またはマルチテナントサーバ上の複数または単一のサービス、またはコンテナ内で実行されるサービスを含むことができるが、これらに限定されない。

コントローラ２００がデプロイされる１つまたは複数のプロセッサは、１つまたは複数の物理または仮想コントローラサーバの形態をとることができ、これらはまた、冗長化および／または並列に動作することができる。コントローラ２００は、コンピュートホストとして機能している物理的または仮想的なホスト上で動作してもよい。一例として、コントローラ２００は、例えば、機密リソースへのアクセスを有するために他の目的を果たすホスト上で実行されるコントローラを構成することができる。コントローラ２００は、ＡＰＩ１２０からリクエストを受け取り、リクエストを解析し、他のリソースに対して適切なタスキングを行い、指示し、リソースを監視し、リソースから情報を受け取り、システムの状態および変更の履歴を維持し、システム１００に存在し得る他のコントローラと通信してもよい。コントローラ２００は、ＡＰＩ１２０を含むこともできる。

本明細書で定義されるコンピュートリソース３００は、単一のコンピュートノード、または現実もしくは仮想の１つもしくは複数のコンピュートノードを有するリソースプールを構成することができる。計算リソース３００は、１つまたは複数のサービスをホストし、または１つまたは複数のアプリケーションを実行し得る、１つまたは複数の物理的または仮想的なマシンまたはコンテナホストを含んでいてもよい。計算リソース３００はまた、コンピューティング、ストレージ、キャッシング、ネットワーク、および／または特殊コンピューティングを含むが、これらに限定されない複数の目的のために設計されたハードウェア上にあってもよく、このようなハードウェアには、ＧＰＵ、ＡＳＩＣ、コプロセッサ、ＣＰＵ、ＦＰＧＡ、および他の特殊コンピューティングハードウェアがあるがこれらに限定されるわけではない。そのようなデバイスは、ＰＣＩエクスプレススイッチまたは同様のデバイスで追加されてもよく、そのような方法で動的に追加されてもよい。コンピュートリソース３００は、サービスまたはアプリケーションを実行する複数の異なる仮想マシンを含む１つまたは複数のハイパーバイザーまたはコンテナホストから構成されてもよいし、仮想コンピュートリソースになり得るコンテナホストを実行してもよい。コンピュートリソースの重点はコンピュート機能を提供することにあるかもしれないが、データストレージおよび／またはネットワーク機能を含んでいてもよい。

本明細書で定義されるストレージリソース４００は、ストレージノードまたはプールもしくはストレージノードを構成することができる。ストレージリソース４００は、任意のデータ記憶媒体、例えば、高速、低速、ハイブリッド、キャッシュおよび／またはＲＡＭから構成されてもよい。ストレージリソース４００は、１つまたは複数のタイプのネットワーク、マシン、デバイス、ノード、またはそれらの任意の組み合わせから構成されてもよく、それらは他のストレージリソースに直接接続されてもされなくてもよい。例示的な実施形態の側面によれば、ストレージリソース（複数可）４００は、ベアメタルまたは仮想またはそれらの組合せであってもよい。ストレージリソースは、ストレージ機能を提供することに重点を置いているかもしれないが、計算機能および／またはネットワーク機能を含んでいることもある。

ネットワークリソース（複数可）５００は、単一のネットワークリソース、複数のネットワークリソース、またはネットワークリソースのプールを構成することができる。ネットワークリソース（複数可）５００は、物理的または仮想的なデバイス（複数可）、ツール（複数可）、スイッチ、ルータ、またはシステムリソース間の他の相互接続、またはネットワークを管理するためのアプリケーションから構成されてもよい。そのようなシステムリソースは、物理的または仮想的であってよく、コンピューティング、ストレージ、または他のネットワークリソースを含むことができる。ネットワークリソース５００は、外部ネットワークとアプリケーションネットワークとの間の接続を提供し、ドメインネームシステム（ＤＮＳまたはｄｎｓ）、ダイナミックホスト構成プロトコル（ＤＨＣＰ）、サブネット管理、レイヤ３ルーティング、ネットワークアドレス変換（ＮＡＴ）、および他のサービスを含むが、これに限定されないコアネットワークサービスをホストしてもよい。これらのサービスの一部は、物理または仮想マシン上の計算リソース３００、ストレージリソース４００、またはネットワークリソース５００にデプロイされることがある。ネットワークリソース５００は、ＩｎｆｉｎｉＢａｎｄ、イーサネット、ＲｏＣＥ（コンバージド・イーサーネット上のリモートＤＭＡ）、ファイバーチャネルおよび／またはＯｍｎｉｐａｔｈを含むが、これらに限定されない１つまたは複数のファブリックまたはプロトコルを利用し、複数のファブリック間の相互接続を含むことができる。ネットワークリソース５００は、ソフトウェア定義ネットワーク（ＳＤＮ）が可能であり得るが、そうである必要はない。コントローラ２００は、ＳＤＮ、仮想ローカルエリアネットワーク（ＶＬＡＮ）などを使用して、ネットワークリソース５００を直接変更したり、ＩＴシステムなどのコンピュータシステムのトポロジーを構成できる可能性がある。ネットワークリソースの重点は、ネットワーク機能を提供することにあるかもしれないが、それはまた、コンピュートおよび／またはストレージ機能を構成することができる。

本明細書で使用するアプリケーションネットワークとは、アプリケーション、リソース、サービス、および／または他のネットワークを接続または結合する、あるいはユーザーおよび／またはクライアントをアプリケーション、リソース、および／またはサービスに結合するためのネットワークリソース５００、またはネットワークリソース５００の任意の組合せのことである。アプリケーションネットワークは、サーバが他のアプリケーションサーバ（物理または仮想）と通信するため、およびクライアントと通信するために使用されるネットワークを構成することができる。アプリケーションネットワークは、システム１００の外部のマシンまたはネットワークと通信することができる。例えば、アプリケーションネットワークは、Ｗｅｂフロントエンドをデータベースに接続することができる。ユーザーは、インターネットまたはコントローラ２００によって管理されていてもいなくてもよい別のネットワークを通じて、Ｗｅｂアプリケーションに接続することができる。

例示的な実施形態によれば、コンピュート、ストレージ、およびネットワークリソース３００、４００、５００はそれぞれ、コントローラ２００によって自動的に追加、削除、設定、割り当て、再割り当て、構成、再構成、および／またはデプロイすることができる。例示的な実施形態によれば、追加のリソースがリソースプールに追加されることがある。そのようなリソースを追加、削除、セットアップ、割り当て、再割り当て、構成、再設定、およびデプロイするための技術の例は、上記参照され組み込まれたＵ．Ｓ． Ｐａｔ． Ａｐｐ．Ｐｕｂ． ２０１９／０３３４９０９およびＷＩＰＯ Ｐｕｂ． ＷＯ２０２０／２５２０８８により詳細に記載されている。

図１は、ユーザー１０５が、ユーザーインターフェース１１０を介してシステム１００にアクセスし、相互作用することができることを示している。図１はまた、アプリケーション（ａｐｐ）がシステム１００にアクセスし、または代替的にアクセスし、相互作用し得ることを示している。例えば、ユーザー１０５またはアプリケーションは、ＡＰＩ１２０を介してコントローラ２００に要求を送信することができ、このような要求には、ＩＴシステムを構築する要求、ＩＴシステム内の個々のスタックを構築する要求、サービスまたはアプリケーションを作成する要求、サービスまたはアプリケーションを移行する要求、サービスまたはアプリケーションを変更する要求、サービスまたはアプリケーションを削除する要求、異なるネットワーク上の別のスタックにスタックを複製する要求、リソースまたはシステムコンポーネントを作成、追加、削除、セットアップ、構成、および／または再構成する要求があるが、それのみに限らない。これらのような要求を実行するための技術の例は、上記参照され組み込まれたＵ．Ｓ． Ｐａｔ． Ａｐｐ． Ｐｕｂ． ２０１９／０３３４９０９およびＷＩＰＯ Ｐｕｂ． ＷＯ ２０２０／２５２０８８に記載されている。

図１のシステム１００は、物理的または仮想的またはそれらの任意の組み合わせのいずれかであり得る様々な要素、コンポーネントまたはリソースへの接続または他の通信インターフェースを有するサーバから構成されてもよい。変形例によれば、図１に示されるシステム１００は、接続を有するベアメタルサーバから構成されてもよい。

上記で参照され、組み込まれたＵ．Ｓ． Ｐａｔ． Ａｐｐ． Ｐｕｂ． ２０１９／０３３４９０９およびＷＩＰＯ Ｐｕｂ． ＷＯ ２０２０／２５２０８８に詳細が記載されているように、コントローラ２００は、リソースまたはコンポーネントの電源をオンにすること、リソースの起動を自動的に設定、構成、および／または制御すること、リソースを追加すること、リソースを割り当てること、リソースを管理すること、および／または利用可能なリソースを更新することに構成される場合がある。パワーアッププロセスは、起動されるデバイスの順序が一貫しており、ユーザーがデバイスに電源を入れることに依存しないようにコントローラ２００に電源を入れることから始まる場合がある。このプロセスは、起動されたリソースの検出を含むこともある。

図２は、システム１００内のコントローラ２００の追加の態様を示し、コントローラ２００は、コントローラロジック２０５、グローバルシステムルール２１０、システム状態２２０、およびテンプレート２３０を含む。

グローバルシステムルール２１０は、とりわけ、計算リソース３００、ストレージリソース４００、およびネットワークリソース５００を含み得るリソースを設定、構成、起動、割り当て、および管理するルールを宣言し得る。グローバルシステムルール２１０は、システム１００が正しい状態または所望の状態にあるための最小要件を構成する。それらの要件は、完了することが期待されるタスクと、所望のシステムを予測可能に構築するために必要な期待されるハードウェアの更新可能なリストからなる場合がある。予想されるハードウェアの更新可能なリストは、コントローラ２００が、必要なリソース（例えば、ルールを開始する前またはテンプレートを使用する前）が利用可能であることを検証することを可能にする場合がある。グローバルシステムルール２１０は、様々なタスクに必要な操作のリストと、操作およびタスクの順序付けに関連する対応する命令とから構成されてもよい。例えば、ルール２１０はコンポーネントの電源をオンにする順序、リソース、アプリケーションおよびサービスを起動する順序、依存関係、異なるタスクをいつ開始するか、例えば、アプリケーションを構成、開始、再ロード、またはハードウェアを更新するロードを指定することができる。ルール２１０はまた、以下のうちの１つまたは複数を含むことができる：リソース割り当てのリスト、例えば、アプリケーションおよびサービスに必要なリソース割り当てのリスト、使用可能なテンプレートのリスト、ロードされるべきアプリケーションのリストおよび構成方法、ロードされるべきサービスのリストおよび構成方法、アプリケーションネットワークのリストおよびどのアプリケーションがどのネットワークと連携するか、異なるアプリケーションに固有の構成変数のリストおよびユーザー固有のアプリケーション変数、コントローラ２００がシステム状態２２０をチェックして状態が期待通りであり各命令の結果が期待通りであるかを検証できると期待される状態、および／またはルールに対する変更のリストを含むバージョンリスト、（例：スナップショットなど）であり、ルールへの変更の追跡、および異なる状況において異なるルールをテストまたは元に戻す能力を可能にすることができる場合がある。コントローラ２００は、物理リソース、仮想リソース、または物理リソースと仮想リソースの組み合わせで、グローバルシステムルール２１０をシステム１００に適用するように設定することが可能である。システム１００によって使用可能なグローバルシステムルール２１０に関する追加情報および例は、上記参照され組み込まれたＵ．Ｓ． Ｐａｔ． Ａｐｐ． Ｐｕｂ． ２０１９／０３３４９０９およびＷＩＰＯ Ｐｕｂ． ＷＯ ２０２０／２５２０８８に記載されている。

テンプレート２３０は、テンプレート２３０のライブラリを構成することが可能で、かかるテンプレート２３０は、ベアメタルテンプレートおよび／またはサービステンプレートを含んでもよい。テンプレート２３０は、リソース、アプリケーション、またはサービスとの関連付けを有することができ、そのようなリソース、アプリケーション、またはサービスがシステム１００に統合される方法を定義するレシピとして機能することができる。

このように、テンプレート２３０は、リソース、またはリソースにロードされたアプリケーションもしくはサービスを作成、構成、および／またはデプロイするために使用される確立された一連の情報を含むことができる。このような情報には以下のものが含まれるが、これらに限定されない：カーネル、ｉｎｉｔｒｄファイル、ファイルシステムまたはファイルシステムイメージ、ファイル、構成ファイル、構成ファイルテンプレート、異なるハードウェアおよび／または計算バックエンドの適切なセットアップを決定するために使用される情報、および／またはアプリケーションの作成、ブートまたは実行を可能にし、かつ／または容易にするアプリケーションおよびＯＳイメージを動かすためのリソースを構成するための他の利用できるオプションがある。

テンプレート２３０は、複数の物理サーバタイプまたはコンポーネント、複数のハードウェアタイプ上で動作する複数のハイパーバイザー、複数のハードウェアタイプ上でホストされ得るコンテナホストを含むがこれに限定されない、サポートされる複数のハードウェアタイプ／および／または計算バックエンド上でアプリケーションをデプロイするために使用され得る情報を含み得る。

テンプレート２３０は、コンピューティングリソース３００上で実行されるアプリケーションまたはサービスのためのブートイメージを導出してもよい。テンプレート２３０およびテンプレート２３０から導出されたイメージは、アプリケーションの作成を可能にし、および／または容易にするアプリケーションまたはサービスのデプロイ、および／または様々なシステム機能のためのリソースのデプロイに使用されてもよい。テンプレート２３０は、デフォルト設定またはコントローラ２００から与えられる設定のいずれかからの構成オプションで上書きされ得る、ファイル、ファイルシステム、および／またはオペレーティングシステムイメージの可変パラメータを有する場合がある。テンプレート２３０は、アプリケーションまたは他のリソースを構成するために使用される構成スクリプトを有することができ、構成変数、構成ルール、および／またはデフォルトルールまたは変数を利用することができる。これらのスクリプト、変数、および／またはルールは、特定のハードウェアまたは他のリソース固有のパラメータ、例えばハイパーバイザー（仮想時）、利用可能なメモリに対する特定のルール、スクリプト、または変数を含む場合がある。テンプレート２３０は、バイナリリソース、バイナリリソースまたはハードウェアまたは他のリソース固有のパラメータをもたらすコンパイル可能なソースコード、特定のハードウェアまたは他のリソース固有のパラメータ、例えばハイパーバイザー（仮想時）、利用可能なメモリに対するコンパイル命令を有するバイナリリソースまたはソースコードの特定のセットの形態のファイルを有することができる。テンプレート２３０は、リソース上で実行されるものとは独立した一連の情報を構成することができる。

テンプレート２３０は、ベースイメージから構成されてもよい。ベースイメージは、ベースオペレーティングシステムのファイルシステムから構成されてもよい。ベースオペレーティングシステムは、読み取り専用であってもよい。ベースイメージはまた、実行されているものに依存しないオペレーティングシステムの基本的なツールから構成されてもよい。ベースイメージは、ベースディレクトリとオペレーティングシステムツールとを含むことができる。

テンプレート２３０は、カーネルを含んでいてもよい。カーネルまたは複数のカーネルは、異なるハードウェアタイプおよびリソースタイプのために構成されたｉｎｉｔｒｄまたは複数のカーネルを含んでもよい。イメージは、テンプレート２３０から導出され、１つまたは複数のリソースにロードされるか、またはデプロイされる場合がある。取り込まれたイメージは、対応するテンプレート２３０のカーネルまたはｉｎｉｔｒｄのようなブートファイルも含んでよい。

イメージは、テンプレート２３０に基づいてリソースに取り込まれ得るテンプレートファイルシステム情報を含んでいてもよい。テンプレートファイルシステムは、アプリケーションまたはサービスを構成することができる。テンプレートファイルシステムは、例えば、ファイルシステムが格納されるストレージスペースを節約するため、または読み取り専用ファイルの使用を容易にするために、すべてのリソースまたは同様のリソースに共通する共有ファイルシステムを構成することができる。テンプレートファイルシステムまたはイメージは、デプロイされるサービスに共通する一連のファイルから構成される場合がある。テンプレートファイルシステムは、コントローラにあらかじめ取り込まれるか、またはダウンロードされることがある。テンプレートファイルシステムは、更新される場合がある。テンプレートファイルシステムは、再構築を必要としないため、比較的迅速なデプロイを可能にする可能性がある。ファイルシステムを他のリソースやアプリケーションと共有することで、ファイルが不必要に複製されないため、ストレージを削減できる場合がある。また、テンプレートファイルシステムと異なるファイルのみを復元する必要があるため、障害からの復旧が容易になる可能性がある。

テンプレートブートファイルは、ブートプロセスを支援するために使用されるカーネルおよび／またはｉｎｉｔｒｄまたは同様のファイルシステムから構成されることがある。ブートファイルは、オペレーティングシステムを起動し、テンプレートファイルシステムをセットアップすることができる。ｉｎｉｔｒｄは、テンプレート２３０がブートできるようにセットアップする方法に関する指示を含む小さな一時ファイルシステムからなる場合がある。

テンプレート２３０は、テンプレートＢＩＯＳ設定をさらに含んでいてもよい。テンプレートＢＩＯＳ設定は、物理ホスト上でアプリケーションを実行するためのオプション設定を設定するために使用される場合がある。使用される場合、アウトオブバンド管理ネットワーク２６０は、リソースまたはアプリケーションを起動するために使用され得る。物理ホストは、アウトオブバンド管理ネットワーク２６０またはＣＤＲＯＭを使用してリソースまたはアプリケーションを起動してもよい。コントローラ２００は、そのようなテンプレート２３０で定義されたアプリケーション固有のＢＩＯＳ設定を設定してもよい。コントローラ２００は、アウトオブバンド管理ネットワーク２６０を使用して、特定のリソースに固有のＡＰＩを介して、直接バイオの変更を行うことができる。設定は、コンソールおよび画像認識を通じて検証されてもよい。したがって、コントローラ２００はコンソール機能を使用し、仮想キーボードおよびマウスでバイオス変更を行うことができる。また、コントローラ２００はＵＥＦＩシェルを使用し、コンソールに直接入力してもよく、画像認識を使用して成功した結果を検証し、コマンドを正しく入力し、成功した設定変更を確認してもよい。ＢＩＯＳの変更または特定のＢＩＯＳバージョンへの更新のために利用可能なブート可能なオペレーティングシステムがある場合、コントローラ２００は、ディスクイメージまたはＩＳＯブートのオペレーティングシステムをリモートでロードし、ＢＩＯＳを更新し、信頼できる方法で設定の変更を可能にするアプリケーションを実行してもよい。

テンプレート２３０は、テンプレート固有のサポートされるリソースのリスト、または特定のアプリケーションまたはサービスの実行に必要なリソースのリストをさらに含むことができる。

テンプレートイメージまたはイメージの一部もしくはテンプレート２３０は、コントローラ２００に格納されてもよいし、コントローラ２００がストレージリソース４００に移動またはコピーしてもよい。

システム１００によって使用され得るテンプレート２３０に関する追加情報および例は、上記に参照され組み込まれたＵ．Ｓ． Ｐａｔ． Ａｐｐ． Ｐｕｂ． ２０１９／０３３４９０９およびＷＩＰＯ Ｐｕｂ． ＷＯ ２０２０／２５２０８８に記載されている。

システム状態２２０は、コンピュートリソース３００、ストレージリソース４００、およびネットワークリソース５００などのリソースを含むが、これらに限定されないシステム１００の状態を追跡、維持、変更および更新する。システム状態２２０は、データベースの形態を用いて利用可能なリソースを追跡することができ、これは、ルール２１０およびテンプレート２３０の実装のために利用可能なリソースがあるかどうか、およびどのようなリソースがあるかをコントローラロジック２０５に伝える。システム状態２２０は使用済みのリソースの追跡を行い、コントローラロジック２０５が効率を調べる、効率を利用する、アップグレードまたは他の理由のために切り替える必要があるかどうか、効率を改善するためまたは優先順位のために切り替えが可能になる。システム状態２２０は、どのようなアプリケーションが実行されているかを追跡してもよい。コントローラロジック２０５は、システム状態２２０に従って、実行中の予想されるアプリケーションと実行中の実際のアプリケーションとを比較し、修正する必要性があるかどうかを判断してもよい。システム状態２２０は、アプリケーションが実行されている場所を追跡することもできる。コントローラロジック２０５は、効率性の評価、変更管理、更新、トラブルシューティング、または監査証跡を目的として、この情報を使用することができる。システム状態２２０は、ネットワーク情報、例えば、どのネットワークがオンであるか、または現在実行されているか、または構成値および履歴を追跡してもよい。システム状態２２０は、変更の履歴を追跡してもよい。また、システム状態２２０は、どのテンプレート２３０が使用されるかを規定するグローバルシステムルール２１０に基づいて、どのテンプレート２３０がどのデプロイで使用されるかを追跡することができる。履歴は、監査、警告、管理変更、レポートの構築、ハードウェアおよびアプリケーションと構成に相関するバージョンの追跡、または構成変数に使用されてもよい。システム状態２２０は、監査、コンプライアンステスト、またはトラブルシューティングを目的として、構成の履歴を維持することができる。

システム１００によって使用され得るシステム状態２２０に関する追加情報および例は、上記に参照され組み込まれたＵ．Ｓ． Ｐａｔ． Ａｐｐ． Ｐｕｂ． ２０１９／０３３４９０９およびＷＩＰＯ Ｐｕｂ． ＷＯ ２０２０／２５２０８８に記載されている。

コントローラ２００は、システム状態２２０、テンプレート２３０、およびグローバルシステムルール２１０に含まれるすべての情報を管理するためのコントローラロジック２０５を含む。コントローラロジック２０５（アプリケーションの形態をとることができる）、グローバルシステムルール２１０、システム状態２２０、およびテンプレート２３０はコントローラ２００によって管理され、コントローラ２００に常駐することも、常駐しないことも可能である。コントローラロジック２０５、グローバルシステムルール２１０、システム状態２２０、およびテンプレート２３０は、物理的または仮想的であってもよい。そしてそれらは、分散サービス、分散データベース、および／またはファイルであってもよいが、そうである必要はない。ＡＰＩ１２０は、コントローラロジック２０５に含まれていてもよい。

コントローラ２００は、スタンドアローンマシンを実行してもよく、および／または１つ以上のコントローラから構成されてもよい。コントローラ２００は、コントローラサービスまたはアプリケーションを構成してもよく、別のマシン内で実行してもよい。コントローラマシンは、スタック全体またはスタック群の秩序あるおよび／または一貫した起動を保証するために、コントローラサービスを最初に起動してもよい。

コントローラ２００は、計算、ストレージ、およびネットワークリソース３００、４００、５００を有する１つまたは複数のスタックを制御することができる。各スタックは、グローバルシステムルール２１０内のルールの異なるサブセットによって制御されてもよいし、制御されなくてもよい。例えば、システム内に異なる機能を有する試作品、製品、開発、テストスタック、パラレル、バックアップ、および／または他のスタックが存在する場合がある。

コントローラロジック２０５は、所望のシステム状態を実現するために、グローバルシステムルール２１０を読み取り、解釈するように構成される場合がある。コントローラロジック２０５は、グローバルルール２１０に従ってテンプレート２３０を使用して、アプリケーションまたはサービスなどのシステムコンポーネントを構築し、リソースを割り当て、追加、または削除して、システム１００の所望の状態を達成するように構成される場合がある。コントローラロジック２０５は、グローバルシステムルール２１０を読み取って、正しい状態にするためのタスクのリストを作成し、利用可能なオペレーションに基づいてルールを満たすための命令を発行してもよい。コントローラロジック２０５は、操作（例えば、システムの起動、リソースの追加、削除、再構成）を実行するためのロジックを含むことができ、何が実行可能であるかを特定する。コントローラロジック２０５は、起動時および定期的にシステム状態２２０をチェックして、ハードウェアが利用可能かどうかを確認し、利用可能であればタスクを実行することができる。必要なハードウェアが利用できない場合、コントローラロジック２０５はグローバルシステムルール２１０、テンプレート２３０、およびシステム状態２２０から利用可能なハードウェアを使用して代替オプションを提示し、それに応じてグローバルルール２１０および／またはシステム状態２２０を修正する。

コントローラロジック２０５は、どの変数が必要であるか、ユーザーが続行するために何を入力する必要があるか、またはユーザーがシステム１００を機能させるために何を必要とするかを知ることができる。コントローラロジック２０５は、グローバルシステムルール２１０からのテンプレート２３０のリストを使用し、システム状態２２０で必要なテンプレートと比較して、必要なテンプレートが利用可能であることを確認することができる。コントローラロジック２０５は、システム状態２２０から、テンプレート固有のサポートされるリソースのリスト上のリソースが利用可能であるかどうかを特定してもよい。コントローラロジック２０５は、リソースを割り当て、状態２２０を更新し、グローバルルール２１０を実装するための次の一連のタスクに進むことができる。コントローラロジック２０５は、グローバルルール２１０で指定されたように、割り当てられたリソース上でアプリケーションを開始／実行することができる。ルール２１０は、テンプレート２３０からアプリケーションを構築する方法を指定することができる。コントローラロジック２０５は、テンプレート（複数可）２３０を取得し、変数からアプリケーションを構成することができる。テンプレート２３０はコントローラロジック２０５に、どのカーネル、ブートファイル、ファイルシステム、およびサポートされるハードウェアリソースが必要かを伝えることができる。次に、コントローラロジック２０５は、アプリケーションのデプロイに関する情報をシステム状態２２０に追加することができる。各命令の後、コントローラロジック２０５はシステム状態２２０とグローバルルール２１０の予想状態を比較して、予想される操作が正しく完了したかどうかを検証することができる。

コントローラロジック２０５は、バージョンルールにしたがってバージョンを使用することができる。システム状態２２０は、どのルールバージョンが異なるデプロイで使用されたかに関連するデータベースを有することができる。

コントローラロジック２０５は、最適化および効率的な順序を規定する効率的なロジックを含んでもよい。コントローラロジック２０５は、リソースを最適化するように構成される場合がある。実行中または実行が予想されるアプリケーションに関連するシステム状態２２０、ルール２１０、およびテンプレート２３０の情報を、コントローラロジック２０５が使用して、リソースに関する効率または優先順位を実施することができる。コントローラロジック２０５は、システム状態２２０の「使用済みリソース」の情報を使用して、効率性、またはアップグレード、再利用、または他の理由のためにリソースを切り替える必要性を判断することができる。

コントローラ２００は、システム状態２２０に従って実行中のアプリケーションを確認し、グローバルルール２１０の予想される実行中のアプリケーションと比較してもよい。アプリケーションが実行されていない場合、それを開始することができる。アプリケーションが実行されてはならない場合、それを停止し、適切であればリソースを再割り当てすることができる。コントローラロジック２０５は、リソース（コンピュート、ストレージネットワーク）仕様のデータベースを含むことができる。コントローラロジック２０５は、使用可能なシステムで利用可能なリソースタイプを認識するためのロジックを含むことができる。これは、アウトオブバンド管理ネットワーク２６０を使用して実行されてもよい。コントローラロジック２０５は、アウトオブバンド管理ネットワーク２６０を使用して新しいハードウェアを認識するように構成される場合がある。また、コントローラロジック２０５は、監査、レポートの構築、および変更管理を目的として、変更の履歴、使用されたルール、およびバージョンに関する情報をシステム状態２２０から取り込むことができる。

コントローラ２００は、複数のネットワーク、相互接続、またはコントローラ２００が計算、ストレージ、およびネットワークリソースに動作を指示できる他の接続のうちの１つまたは複数によってスタックまたはリソースと通信を行う。このような接続には、アウトオブバンド管理接続２６０、インバンド管理接続２７０、ストレージエリアネットワーク（ＳＡＮ）接続２８０、およびオプションのインバンドネットワーク管理接続２９０が含まれ得る。

アウトオブバンド管理は、コントローラ２００によって、コントローラ２００を介してシステム１００のコンポーネントを検出、構成、および管理するために使用され得る。アウトオブバンド管理接続２６０は、コントローラ２００が、プラグインされ利用可能であるが電源が入っていないリソースを検出することを可能にする場合がある。プラグインされたリソースは、システム状態２２０に追加されることがある。アウトオブバンド管理は、システム１００に属するブートイメージを取り込み、構成し、リソースを監視するように構成される場合がある。アウトオブバンド管理は、オペレーティングシステムの診断のための一時的なイメージのブートも行うことができる。アウトオブバンド管理は、ＢＩＯＳ設定を変更するために使用されてもよく、また、実行中のオペレーティングシステム上でコマンドを実行するためにコンソールツールを使用することができる。また、ＴＡコンソール、キーボード、およびＶＧＡ、ＤＶＩまたはＨＤＭＩポートなどのハードウェアリソース上の物理または仮想モニタポートからのビデオ信号の画像認識を使用して、および／またはＲｅｄｆｉｓｈなどのアウトオブバンド管理によって提供されるＡＰＩを使用して、コントローラ２００によって設定を変更することができる。

本明細書で使用されるアウトオブバンド管理は、オペレーティングシステムおよびメインのマザーボードから独立したリソースまたはノードに接続できる管理システムを含むことができるが、これに限定されない。アウトオブバンド管理接続２６０は、ネットワークまたは複数のタイプの直接的または間接的な接続または相互接続から構成され得る。アウトオブバンド管理接続タイプの例としては、ＩＰＭＩ、Ｒｅｄｆｉｓｈ、ＳＳＨ、Ｔｅｌｎｅｔ、他の管理ツール、キーボード・ビデオ・マウス（ＫＶＭ）またはＫＶＭ ｏｖｅｒ ＩＰ、シリアルコンソール、またはＵＳＢが挙げられるが、これらに限定されない。アウトオブバンド管理とは、ネットワーク上で使用されるツールで、ノードやリソースの電源のオン・オフ、温度やその他のシステムデータの監視、ＢＩＯＳやオペレーティングシステムの制御外にあるその他の低レベルの変更、コンソールへの接続とコマンドの送信、キーボード、マウス、モニターなどの入力制御を行うことができるが、これらに限定されない。アウトオブバンド管理は、物理リソース内のアウトオブバンド管理回路に結合される場合がある。アウトオブバンド管理は、インストール媒体を起動するために使用され得るディスクとしてディスクイメージを接続してもよい。

管理ネットワークまたはインバンド管理接続２７０は、コントローラ２００が、コンピュート、ストレージ、ネットワークまたは他のリソースに関する情報を収集し、リソースが実行されているオペレーティングシステムに直接通信することを可能にする場合がある。ストレージリソース、コンピュートリソースまたはネットワークリソースは、接続２６０および／または２７０と相互作用する管理インターフェースを構成してもよく、それにより、コントローラ２００と通信し、何が実行中で何がリソースとして利用可能であるかをコントローラ２００に伝え、コントローラ２００からコマンドを受信してもよい。本明細書で使用されるインバンド管理ネットワークは、リソースと、リソースのオペレーティングシステムと直接通信することができる管理ネットワークからなる。インバンド管理接続２７０の例は、ＳＳＨ、Ｔｅｌｎｅｔ、他の管理ツール、シリアルコンソール、またはＵＳＢを含み得るが、これらに限定されない。

アウトオブバンド管理は、本明細書ではインバンド管理ネットワークから物理的または仮想的に分離されたネットワークとして説明されているが、本明細書でより詳細に説明するように、効率化を目的としてこれらを組み合わせることができ、または互いに連携して動作することができる。したがって、アウトオブバンド管理およびインバンド管理またはその側面は、コントローラの同じポートを介して通信するか、または結合された相互接続で結合されることがある。オプションとして、１つあるいは複数の接続２６０、２７０、２８０、２９０は、そのようなネットワークの他のものと別々でも結合されてもよく、同じファブリックから構成されてもされなくてもよい。

さらにコンピュートリソース、ストレージリソース、およびコントローラは、コントローラ２００がストレージネットワークを使用して各リソースを起動できるように、ＳＡＮ接続２８０を介してストレージネットワークに結合されてもよいし、結合されなくてもよい。コントローラ２００は、他のリソースがストレージまたは他のリソースから起動できるように、ブートイメージまたは他のテンプレートを別のストレージまたは他のリソースに送信してもよい。コントローラ２００は、そのような状況においてどこから起動するのかを指示してもよい。コントローラ２００は、リソースの電源をオンにし、どこから起動し、どのようにそれを構成するかをリソースに指示してもよい。コントローラ２００は、リソースに、どのように起動するか、どのようなイメージを使用するか、およびそのイメージが他のリソース上にある場合、そのイメージがどこにあるかを指示する。ＢＩＯＳのリソースは、予め設定されていてもよい。コントローラ２００はまた、または代替的に、ＢＩＯＳがストレージエリアネットワークから起動するように、アウトオブバンド管理を通じてＢＩＯＳを構成してもよい。コントローラ２００はまた、ＩＳＯからオペレーティングシステムを起動し、リソースがデータをローカルディスクにコピーすることを可能にするように構成されることもある。その後、ローカルディスクは起動のために使用され得る。コントローラ２００は、他のコントローラを含む他のリソースを、リソースが起動できるように構成することができる。一部のリソースは、コンピュート、ストレージ、またはネットワーク機能を提供するアプリケーションを構成することができる。さらに、コントローラ２００がストレージリソースを起動し、その後、ストレージリソースが後続のリソースまたはサービスのブートイメージを供給する責任を負うようにすることが可能である。また、ストレージは、別の目的のために使用されている別のネットワーク上で管理されることもある。

任意選択で、リソースの１つまたは複数は、ネットワーク上のインバンド管理接続２９０に結合され得る。この接続２９０は、インバンド管理接続２７０に関して説明したような１つまたは複数のタイプのインバンド管理で構成されてもよい。接続２９０は、ネットワークを利用するため、またはインバンド管理ネットワークを通じて管理するために、コントローラ２００をアプリケーションネットワークに接続してもよい。

サービスの自動クラスタリング：
本発明者らは、クラスタリング可能なサービス２５０の１つまたは複数のクラスタ２５２のデプロイを自動化するために、システム１００によって実装可能な多数の異なる技術を開示する（例：図２参照）。

例えば、コントローラ２００は、アプリケーションの複数のコピー（例えば、アプリケーションのｎ個のコピー、ここでｎは１より大きい整数であり得る）をデプロイすることができ、これらのアプリケーションは互いに依存し合うことができる。これらのアプリケーションは、サービス２５０の形態をとることができる。コントローラ２００は、これらのアプリケーション（図３のサービスインスタンス２５０を参照）を管理する（図３で示される負荷分散３１０を含み得る）スケジューラも構成することができる。一例として、スケジューラは、図３によって示されるように、クラスタマネージャ３０２とすることができ、クラスタマネージャ３０２はクラスタ２５２を管理し、ロードバランシングを管理し、および／または他のタスクを管理してそれらのタスクをスケジュールして処理負荷を分割するサービスであることができる。したがって、クラスタマネージャ３０２は、タスクを送り出すスケジューラ（ＳＬＵＲＭのようなもの）として機能することができ、他のクラスタマネージャ３０２は、様々なホストをジャストインタイムで構成するかもしれない。そして、環境内の他のサービスは、単一のサービスだけに依存するのではなく、サービス２５０のクラスタ２５２に依存することができる。

図４によって示されるように、サービステンプレート４３０はコントローラ２００によって使用される。サービステンプレート４３０は、テンプレート２３０の中に含めることができる。サービステンプレート４３０は、クラスタリングルールを含むことができ、これらのクラスタリングルールは、コントローラ２００にそれらのサービスを接続する方法を指示することができる。クラスタリングルールは、複数のリソースへのサービスのデプロイを提供するロジック命令および／または一連のテンプレートであり得る。クラスタリングルールの結合命令は、別々に予約された物理リソースおよび／または仮想リソースの調整および相互作用を定義し、依存関係を設定する。別個のリソースは、マシン、物理、メタル、仮想、および／またはコンテナを含むことができるが、これらに限定されない。クラスタリングルールは、サービスによって使用されているリソースをスケールアップまたはスケールダウンするための情報の利用を定義する。例示的なクラスタリングルールに関する追加の詳細については、図９を参照して後述する。

図４の点線は、クラスタ内の各コンピュートリソース／サービスインスタンスに接続される接続を示す。これらの接続は、物理的または仮想的であり得る。また、コントローラ２００がネットワークリソース５００でソフトウェア定義ネットワーク（ＳＤＮ）を使用しなければならない場合、コントローラ２００は、ＳＤＮスイッチのアウトオブバンド管理を使用してそれらのサービスをクラスタリングすることができる（図４の２６０を参照）。例えば、スイッチのＯＯＢは、シリアルコンソールを介してコントローラ２００に接続することができ、それらのポートにＶＬＡＮを設定することができる。別の例として、コントローラ２００は、スイッチ上またはどこか他の場所でＯｐｅｎＳＭ（ＩｎｆｉｎｉＢａｎｄのサブネットマネージャー）を設定することができる。ＳＤＮは、クラスタ化されたサービス２５０が相互に通信するためだけに使用されるネットワークとすることができ、このようなネットワーク構成により、パフォーマンスを向上させながらシステムをより安全にすることができる。

クラスタリングルールは、負荷分散サポートを提供することができ、どのクラスタ化されたサービスが「マスター」であるかを決定することができるクラスタリングツール４０２（例えば、ＳＬＵＲＭ（Ｓｉｍｐｌｅ Ｌｉｎｕｘ Ｕｔｉｌｉｔｙ ｆｏｒ Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ））を指定することができ、クラスタリングツール（複数可）は、従属サービスになる。例えば、クラスタリングツール３０２は、依存関係としてサービステンプレート４３０で定義することができる。すなわち、サービス２５０のクラスタ２５２は、スケジューラ／クラスタリングツール３０２に依存し得る。また、例えば、サービス２５０がデータベースサービスに依存する場合、それはそのサービス２５０のクラスタ２５２に依存することができる。他の例示的な実施形態では、サービス２５０自体がそれ自身の「選出」プロセスを有することができる。

図９は、クラスタリングルール９００のセットの一例を示す。これらのクラスタリングルール９００は、コントローラロジックまたはリソース／サービスインスタンスにクラスタを管理させる命令を含む。これらのルールは、電源オン／オフのルールおよびクラスタ初期化ルールを含み得るが、これらに限定されない。クラスタ初期化ルールは、コントローラロジック、クラスタマネージャ、およびスケジューラが、クラスタリソースを初期化し、新しいクラスタに必要なリソースを構成することを可能にする。

これらの命令は、サポートされるハードウェアに基づいてルールを変更することができるハードウェア固有の命令を含む可能性がある。これらは、ルール９００の内部で条件付きロジックとして行うことができ、またはルール９００は一連の「ハードウェアルール」を呼び出すことができる（これらのハードウェアルールは、サポートされるハードウェアと、サポートされるハードウェアの各タイプに対して何を行うべきかを特定する）。ハードウェアタイプは、ベースハードウェアに関する情報を含むことができ、および／または、ネットワークカード、ＩｎｆｉｎｉＢａｎｄカード、ＨＢＡ、ディスク、ＧＰＵ、ＡＳＩＣ、ＦＰＧＡ、および／または任意のタイプのドータカードを含むが、これらに限定されない拡張カードに関する要件を含むことができる。任意選択として、ハードウェアの種類を変更できるハードウェア変更ルールがある。多くの場合、ハードウェア変更ルールは複雑で、ＧＰＵの削除／追加などの簡単な変更以外では実装されないが、あらゆる変更に使用でき、コントローラまたはハードウェアを変更したコンピュートリソースにリモートパワーでアクセスできるデーモンに、リソースの再起動を指示することができる。

サービステンプレート４３０は、テンプレートからデプロイされるすべてのサービスがクラスタでなければならないことを示す可能性があり、また、依存サービスがクラスタとしてデプロイされること、およびそのクラスタ化されたインスタンスのハードウェアタイプを義務付けることも示す可能性がある。クラスタリングルールにおける成長／縮小ルール（例えば、図９によって示されるように、ノードを追加するルールおよびノードを破棄するルール）は、依存サービスのクラスタリングルール内部のロジックを呼び出すことによって、依存クラスタ上の成長／縮小ルールを呼び出し得る。これは、より多くのディスクが必要なストレージ依存関係で、そのストレージプロバイダが依存クラスタへのストレージリソースプロバイダとして使用されるサービステンプレートにパッケージ化されている可能性がある。クラスタリングのルールでは、依存サービスが特定のクラスタの依存サービスとしてのみ機能するように指示することもできる（例えば、ストレージ、ネットワークは、通常であれば共有しても問題ないサービスを共有することに何らかのソフトウェアの問題がある場合、そのサービス専用のプールとし得る）。

クラスタ初期化ルールは、クラスタを初期化するためのプログラム、ロジック、および／または命令を含む。必要な各ハードウェアのためのハードウェア命令が存在することが可能で、コントローラ２００は任意のリソース要件をチェックし得る。クラスタ初期化ルールは、依存サービス上のエンドポイントへの呼び出しを含むことができる。それらは、ネットワークスイッチに構成ルールを送信し、ストレージアレイへのアクセスを設定し、データプールを予約し、クラスタに必要な依存関係を解決することができる（例えば、サービスの単一のインスタンスはそれ自身の内部ストレージのみを必要とするかもしれないが、クラスタの場合は共有ストレージが必要かもしれない）。図１１は、システムによるクラスタの開始とデプロイに関連して実行可能な操作の一例を示す。

成長ルールは、リソースをクラスタに追加することを許可する。これらのルールは、クラスタリング可能なサービスの新しいコピーのデプロイとなる新しいリソースを生成、プロビジョニングする。その後、ルールはサービスの他のすべてのリソース／インスタンス、クラスタマネージャ、および／またはマスターインスタンスに対する特定の命令を更新することができる。

縮小ルールは、クリーンアップルールを呼び出して、クラスタ内のリソースのインスタンスを他のリソースから削除し、もはや存在しないリソースへの依存を防ぐことができる。クリーンアップルールは、成長ルールに結合させることができる。

スケーリングエンドポイントやスケールルールは、特定のサイズでクラスタの構成を自動的に変更するかユーザープロンプトを提案できる。例として、ネットワーク帯域幅がノード間通信でクラスタを飽和させることがあり、共有ストレージがあるノード数の後にスケーリングを改善できることを示すことがでる。したがって、このルールは、共有ファイルシステムのストレージ依存などの依存関係を義務付けることができる。

クラスタリングルールは、クラスタのために変更が必要な場合、サービス内のエンドポイントを置き換えることができる。新しいエンドポイントは、ハードウェア固有のものになる可能性がある。このようなエンドポイントの変更は、クラスタに変更を加えることが個々のサービスとは異なるため、しばしば存在する。多くの場合、このケースに限定されないが、マスターノード、クラスタマネージャ、またはその他のケースでは、置換エンドポイントは、「クラスタマネージャ」になり得る依存サービスに呼び出すことができ、その後クラスタのすべてのインスタンスに同じコマンドを作成するエンドポイントとして置換することができる。

クラスタリングルール９００は、エンドポイントがクラスタに割り当てられたすべてのリソース上で実行されることを指示することもできる。例えば、複数のノードがある場合、コントローラ２００は、各ノードにリモートインして必要なコマンドを実行することができ、またはレイアウトに応じて各インスタンス／リソース上で動作するエンドポイントを呼び出すことができる（例えば、エンドポイントはコントローラ２００上にあり、コントローラはリモートインしてコマンドをタイプするか？あるいは、サービスを実行しているマシン上でＡＰＩエンドポイントを呼び出すのか？）。

図１３は、エンドポイントを呼び出す異なる方法の例を示す。例えば、コントローラ２００は、バンド内管理２７０を使用して、ＡＰＩを介してサービスを呼び出すことができる。別の例として、コントローラ２００はエンドポイント／ＡＰＩを使用して、ＯＯＢ ２７０（例えば、ＯＯＢコンソール）を介してサービス（例えば、サービスの一部であるスクリプト／実行可能なもの）を呼び出すことができる。別の例として、コントローラ２００は、エンドポイント／ＡＰＩを使用して、インバンド管理２７０を介してサービス上のＳＳＨ、Ｔｅｌｎｅｔ、または他のリモートを呼び出す一方で、それ以外の場合はＯＯＢ ２６０を使用することができる。図１４は、クラスタのためのエンドポイントを呼び出す異なる方法の例を示す。

図５は、新しいサービスインスタンスをクラスタに初期化するための例示的なプロセスフローを表す。ステップ５０２で、コントローラ２００はサービス２５０をコンピュートリソース３００にプロビジョニングする。ステップ５０４において、コントローラ２００は、クラスタ２５２におけるサービス２５０の作成をトリガーする。ステップ５０４で、サービス２５０は起動される。次に、ステップ５０６において、サービス２５０をクラスタ２５２に結合するためにクラスタリングルールが起動される。

また、システムは、自身の環境においてクラスタ化されたサービスを提供することができ、依存／従属サービスの代わりに依存／従属クラスタ（自身の環境にあることもある）とすることができる。

クラスタリング可能なサービスには、クラスタリングサポートが組み込まれたサービス内部で実行されるコードを含めることができる。そして、そのようなサービスがサービステンプレート４３０としてパッケージ化されるとき、コントローラが自動的にそのサービスを構成し、そのサービスのすべてのインスタンスが適切に互いに会話できるように、クラスタ化されたデプロイのためのネットワークや他のインフラの設定を含めて、サービスをクラスタで設定する方法についての指示がサービステンプレート４３０にあることができる。異なるシナリオは、ユーザーが選択するか、クラスタリングルール９００の内部のルールによって選択することができる。例えば、あるノード数、リソース使用量、利用可能なハードウェアの種類（ストレージ、コンピュート、およびネットワーク－ＩｎｆｉｎｉＢａｎｄやイーサネットなど）があると、自動的に、またはユーザーに提案されるいくつかのルールが存在することができる。クラスタリング可能なサービスをクラスタにデプロイするために使用されるサービステンプレート４３０は、ユーザーが指定することもできるし、サービス仕様ファイルがそれを義務付けることもできる。例えば、サービステンプレート４３０（例えば、ＪＳＯＮ形式であり得るサービステンプレート４３０の一部）は、クラスタリングオプションと共にハードウェアオプションを含むことができ、サービスの構成ルールが処理されるとき、使用されているハードウェアに基づいて異なることができる。例えば、異なるハードウェアタイプに対して異なるベースイメージが存在する場合がある。別の例として、異なるネットワークが使用される場合があり、または他の変更などがある場合がある。

図１５は、コントローラ２００によってデプロイされるクラスタを示す図である。この図は（図１５の１を参照）、デプロイされたサービスでクラスタ化されたサービス、またはクラスタとしてデプロイされたサービスのいずれかを示す（クラスタルールも必要に応じて処理することができるが、最初のインスタンスでは、それを必要としないことも可能である。エンドポイントはリソース／インスタンス上、またはコントローラ上に存在することができ、コントローラはリモートコマンドを使用することができる（図１４で示される）。最初のサービスは、サービステンプレート（図１５の２参照）からデプロイされ、サービスイメージ（図１５の３参照）はリソース上で実行される（通常はコンピュートリソース）。コンピュートリソース３００（図１５の５を参照）は、物理、仮想、またはコンテナであることができ、コントローラ２００は、ＩＳＯを使用してリソース上にイメージをデプロイし、アウトオブバンド管理２６０を介してコピーし、インバンド管理、ＡＰＩを介して構成されたファイル、ＦｌｅｘＢｏｏｔ、ＰＸＥブート、および／またはそれらの組合せをコピーできる。

クラスタルール（図１５の７を参照）は、コンピュートリソースをストレージリソースまたはストレージリソースの複数および／またはクラスタに結合することができる共有ストレージルール（図１５の８を参照）を有することができる。ストレージリソース４００は、現在のクラスタへの依存として、または異なる「リソースタイプ」として、クラスタ化されたサービスとしてもデプロイされ得る。図１５の１５は、ストレージリソース４００への結合を示し、これにはストレージリソースへの認証クレデンシャル／公開鍵認証、ストレージリソースのアドレス、接続命令、コンピュートリソースの１つ以上の接続にＩｎｉｆｎｉＢａｎｄパーティションおよび／またはＶＬＡＮタグを追加することが含まれ得るが、これらに限定されない。より一般的には、ストレージリソースに接続するために必要なあらゆる情報、およびストレージリソースが適切に構成されている（および結合に必要なネットワークリソースの変更が完了している）。

クラスタは複数のリソースを使用するため、サービステンプレート（図１５の６参照）とサービスイメージ（図１５の１０参照）からデプロイされる別のリソース（図１５の１１参照）を示し、サービステンプレートとクラスタルールの両方から得られる設定ルールをリソースにインストールする（図１５の７と１０参照）。

クラスタルールは、リソース（図１５の１１参照）が適切なハードウェアかどうかを確認し、特定のハードウェア関連の設定を行うことができる（図９の「ハードウェアの指示」参照）。

クラスタルールは、ネットワークルールも含むことができる（図１５の９を参照）。これらのネットワークルールは、「追加リソースタイプ」としてパッケージ化することができ、また、クラスタが迅速な相互接続のために独自の高速ネットワークを持つことが多いため、特にクラスタのネットワークルールとしてパッケージ化することもできる。一般的なリソースタイプや、クラスタとしてデプロイされる依存サービスである場合もあるが、ほとんどの実装では専用のネットワークルールが用意されている。

ネットワークルールは、リソースをネットワークリソース５００（図１５の１２参照）に結合することができ、また、ネットワークリソースをプロビジョニングすることもできる。ネットワークルール（図１５の９参照）は、既存のネットワークを取り込み、専用ネットワークがない場合はそのネットワークへのポインタを単に含むことができる。ネットワークルールは、コンピュートリソースに接続するポートを有効にすることができる。ネットワークリソースはＳＡＮであることもあるが、専用のＳＡＮや複数の専用ネットワークが存在することもある。ネットワークルールには、ＤＮＳラウンドロビンのようなロードバランシングも含まれることがある。複数のネットワークリソースおよび／またはネットワークがクラスタリソースに結合されていることもある。クラスタのネットワークルールは、適切なネットワークをコンピュートまたは他のリソースに直接結合することがでる（図１５の１４を参照）。

ネットワークとストレージの両リソースは、ハードウェアの種類も異なり、異なるストレージプロトコル、ネットワークプロトコル、またはネットワークファブリックが異なるハードウェアタイプで望まれ、これらの構成の違いはハードウェアルール（図９の「ハードウェアの指示」参照）から導き出すことができる。

クラスタは、クラスタマネージャまたはクラスタマネージャに依存することができ（図１５の１８を参照）、サービステンプレートはクラスタルールの内部にパッケージ化することができる。クラスタマネージャは、マスターインスタンスであることも、別々のサービスであることもできる。別のインスタンスは、そのような指定が必要な場合、「マスター」と示すことができる。クラスタマネージャは、リソースをジャストインタイムで構成し、クラスタ内のリソースを管理する方法を指示し、クラスタで実行されている各サービスを監視することができる。さらに、クラスタマネージャはスケジューラとして機能し、クラスタ内の様々なインスタンスにタスクをスケジュールすることができる。クラスタマネージャの例としては、スケジューラ（ＳＬＵＲＭなど）、ｍｐｉｒｕｎまたは他のメッセージパッシングのプロセス起動ツールを実行するクラスタ上のサービスのインスタンスが挙げられるが、これらに限定されない。また、クラスタルールにコントローラが起動可能なロジックが含まれており、コントローラ上でそれらのタスクをスケジュールできる場合、コントローラロジックはクラスタマネージャとして機能することができる。

図１６Ａでは、クラスタを成長させるために、未使用の計算リソースが利用可能である（図１６Ａの２０を参照）。これは、任意のタイプのリソースであることができ、この図は、ストレージまたはネットワークリソースを追加する場合に類似している。このリソースは、元々ストレージとネットワークにそれぞれ物理的に結合されていることができる（図１６Ａの２１と２２を参照）。接続はソフトウェア定義ネットワークで無効にすることができ、あるいは接続を有効にして使用せず、および／またはＵＩでユーザーに新しいケーブルを差し込むように指示することができる。クラスタリングのルールにより、未使用のリソースはクラスタに結合される。

クラスタはリソースを追加しており、図１６Ｂは新しいリソースが追加された後の概略図である。コントローラロジックは、サービステンプレート（図１６Ｂの６参照）を、対応するクラスタルール（図１６Ｂの７参照）と共に使用してリソースを追加する。サービスイメージ（図１６Ｂの２４参照）は、新しいコンピュートリソース２３がクラスタの一部となるように構成される。そして、他のすべてのクラスタ／依存関係／リソース（すなわち、コンピュートおよびストレージ）に結合される。他のすべてのリソースは、この新しいリソースを利用するように更新され得る（図１６Ｂの参照番号４、１２、３、１１、１８を含むがこれらに限定されない）。クラスタマネージャ（図１６Ｂの１６／１８を参照）がある場合、それは、新しいリソース（図１６Ｂの２３を参照）をクラスタに結合する方法に関する情報で更新され得る。

図１７Ａは、新しいクラスタを作成するためのプロセスフローの例を示す図である。

図９に示すようなクラスタリングのルールは、初期化ルールを持つことができる。サービスは、初期化ステップですでにデプロイ１７０１またはデプロイされ得る。初期化ルールは、新しいクラスタの適切な動作を満たすために、他のリソースタイプまたはサービスへの依存関係および／またはポインタを有することができる。図１６のラベル３に例を示す。

クラスタ初期化ルールは、コントローラから、または既存のリソース上で、あるいはクラスタマネージャのサービスから実行することができる。初期化ルールには、クラスタを構築し、コンピュート、ネットワーク、およびストレージ１７０２を含むが、これらに限定されない複数のリソースを結合する方法に関する指示が含まれる。

リソース割り当て１７０３に基づくことができる依存性計算が存在し得る。追加のサービスまたはクラスタ化されたサービスのインスタンスがデプロイされ得る１７０４。追加の依存関係がある可能性があり、その場合、他のサービスおよび／またはクラスタ化されたサービスがデプロイされ得る（例えば、クラスタコンピュートノード間の共有ストレージ機能のためのオブジェクトストレージのクラスタなど）。

クラスタルールを持つサービステンプレートは、複数のリソースタイプ１７０６にデプロイするためのハードウェアルールとともに、クラスタルール内のロジックとクラスタルール内で必要なデータを使用して、複数のイメージを生成する機能を持つことができる。実際には、クラスタごとに１つのリソースタイプを使用し、追加のリソースタイプ（例えば、オブジェクトストレージのクラスタサービスを依存関係とすることができる）１７０５の依存関係を含めることでより簡単に実現できる。

初期化命令には、各リソースタイプを結合し、すべての接続１７０７を有効にするロジックが含まれる。

クラスタ内のサービスの各インスタンスは、構成ルール１７０８を実行でき、システム状態１７０９は、クラスタ上の各インスタンスの状態を認識することができる。クラスタ内のサービスのインスタンスはシステム状態を使用して、インバンド管理２７０が他のインスタンスの情報を収集するために利用可能である場合、コントローラから情報を収集することができる。別の方法として、クラスタマネージャは、リソース上で実行されている各サービスインスタンスに新しい設定をプッシュすることができる。

図１７Ｂは、クラスタを成長させるか、ノード／リソースを追加するプロセスフローの例を示す図である。

未使用のリソースは、１７１０（図１６の２０の例）に割り当てられ、リソースは、システムおよびクラスタリソース１７１１（図１６の２１と２２の例）に物理的に結合されていなければならない。次に、コントローラは、クラスタルール１７１２（図１６の７）内の追加／成長ルールを処理できる。次に、コントローラは、クラスタルール、システム状態、およびサービステンプレートおよび／またはルールからサービスイメージを導出し、新しいリソース１７１３にデプロイすることができる。リソースの他のリソースプール、サービス、またはサービスクラスタへの接続は、それらが最初に無効になっていた場合、１７１４で有効にすることができる。

他のリソースは、クラスタルールを使用して新しいリソースに結合され、クラスタマネージャ、マスターノードを更新し、および／または、すべてのリソースにコマンドを送信するためのループを処理するクラスタの各リソース上のロジックを呼び出すことができる。１７１５

ロードバランサーやクラスタマネージャを使用している場合、新しいリソースはリソースへの接続ロジックとともに利用可能なリソースのリストとして追加することができる。

クラスタリング可能なサービスの例として、Ｘｙｃｅがある。ＸｙｃｅはＯｐｅｎＭＰＩのサポートを内蔵しており、ＯｐｅｎＭＰＩのＣＵＤＡのサポートの使用方法を理解している。Ｘｙｃｅをパッケージ化する際、サービステンプレートは、ＣＵＤＡを意識したＯｐｅｎＭＰＩの設定と、ＩｎｆｉｎｉＢａｎｄ、イーサネット、または別のネットワークファブリックを使用するかどうかを知る必要だけある。ＣＵＤＡは、Ｃ＋＋のＮＶＩＡＤＩＡ ＧＰＵバージョンで、ＣＵＤＡ対応ＯｐｅｎＭＰＩは、他のハードウェアと結合できるＧＰＵ（例えば、サーバ、サービスインスタンスと結合したＣＰＵ）上で実行するすべてのＧＰＵに、ＧＰＵ実行可能コードを送信する。ＩｎｆｉｎｉＢａｎｄ の使用は、例えば ＮＶＩＤＩＡ ＮＶｌｉｎｋを使用して、サービスをホストするコンピュートノードのＣＰＵをバイパスするように自動構成することができる。Ｘｙｃｅ自体にはこのサポートが組み込まれており、サービステンプレートは、Ｘｙｃｅが適切なハードウェアにデプロイされている場合、そのクラスタリング機能が自動的にオンになるようなルールを含むように設計することができる。

コントローラ２００は、ＰＸＥまたはＩＰＭＩを使用してアウトオブバンドおよびインバンド管理（２６０／２７０）を介してプロビジョニングすることができ、カスタムブートローダおよびスイッチへのＯＯＢ２６０を使用し、クラスタ化された環境において複数のアプリケーションを構成し、アプリケーション、複数のアプリケーション、インスタンスまたは複数のインスタンスまたはそれらの組み合わせを結合することができる。参考のために、コントローラ２００は、ＡＳＳＣＭと表示され得る。

図６は、要求６００がクラスタツール４０２に送信され得る例を示す。この要求は、クラスタ２５２内の１つまたは複数のサービスによって実行されるべきデータ処理ジョブに対する、ユーザーまたはアプリケーションからの要求であり得る。クラスタツール４０２は、任意にクラスタリング可能なサービスの依存関係として構成することができ、クラスタツール４０２はタスクをスケジュールすることができ、ＯｐｅｎＭＰＩなどのメッセージパッシングのツールを使用することができる。関連するクラスタ２５２のサービステンプレート４３０によって指定されたクラスタリングルールは、コントローラによって実装され得るクラスタ化されたサービスを結合するために使用されるクラスタリングネットワークの構成を指示し得る（例えば、上述の図９参照）。クラスタリングルールは、任意でアウトオブバンド管理２６０を介して、ネットワークリソース５００（例えば、スイッチ）を構成するために使用されてもよい。

コントローラ２００は、任意に外部ネットワーク６０２を結合し、任意にクラスタツール上でリクエストの処理を構成することができる。これは、クラスタのネットワーク、クラスタリソース、クラスタのマスターインスタンス、および／またはクラスタマネージャのインターネットへの結合、および／またはシステム内またはシステム外の別のネットワークに結合される可能性がある。

コントローラ２００のデプロイシステムおよび依存関係管理は、サービス間の依存関係またはクラスタ化されたサービスと依存または従属サービスとの間の依存関係を構成することができる。

図７は、別のサービス７０４に依存するサービス７０２を示し、ここでサービス７０４はクラスタ７０６としてデプロイされる。［関連するクラスタ７０６は、サービス７０４の２つのインスタンスからなる（それらのサービス７０４は、互いに「相互依存性」を持つことができる。相互依存は、あるサービスが、現在実行されているそのサービスの他のインスタンスに対する任意の依存関係を有するクラスタをより単純化した方法である。また、図１０は、２つのクラスタ化されたサービスが相互依存し、共有ストレージと結合している例を示している。

図８は、コントローラ２００が、ＯＯＢ、ＩＰＭＩ、ＰＸＥ、Ｒｅｄｆｉｓｈ、ＦｌｅｘＢｏｏｔ、カスタムブートローダまたはそれらの組み合わせを含むが、これらに限定されないツールを介してアプリケーション、すなわちベアメタル（例えば、サーバ３００）上に任意にデプロイされるクラスタリング可能アプリケーションをデプロイしていることを示す。ＮＶｌｉｎｋは、ＣＰＵをバイパスしてＩｎｆｉｎｉＢａｎｄ接続を使用してＧＰＵメモリから別のＧＰＵのメモリにコピーするために使用することができる。したがって、ノード間の通信をコプロセッサに最適化することができる。また、ベアメタル上に自動的に構成できるクラスタリング可能なアプリケーションのインスタンス間でストレージリソースを提供したり、共有ストレージリソースとして機能したりできるＳＡＮ２８０またはストレージリソース２８０が存在する可能性がある。また、ネットワークリソースは、コントローラ２００によってアウトオブバンドで構成されることもある。図８のスイッチ８００（複数のスイッチから構成され得る）は、コンピュート・インスタンスに接続し（通常はイーサネット）、バンド内および／またはバンド外の管理を行うスイッチとすることができる。（２つのスイッチであり得る）。ＳＤＮファブリック８０２は、コントローラ２００が設定できる別のスイッチ（例えば、スマートスイッチ）で、スイッチ８０２がクラスタの高速スイッチとして機能し、ノード３００が非常に速く一緒に会話できるようにすることができる。

実施形態の例として、自動クラスタリング機能を持つシステム１００は、ベアメタルにクラスタリング可能なアプリケーションを自動的にデプロイし、システムの残りの部分を構成して、ターンキーデプロイのＨＰＣシステム環境を作ることができるようになる。一例として、システムはＩＳＯをブートし、ストレージリソースが接続され、ｐｉｖｏｔ＿ｒｏｏｔが呼び出されてルートファイルシステムを移動させる。図１２は、このためのプロセスフローの例を示す。ステップ１２０２で、コントローラ２００は、ネットワークインターフェースを介して、仮想ＣＤハードウェアにＩＳＯイメージを与える。あるいは、仮想ＣＤインターフェースは、ＣＤイメージをインテリジェントに要求することができる。ステップ１２０４で、ＩＳＯから適切なカーネルがロードされ、システムはそれに応じてブートする（ステップ１２０６）。ステップ１２０８において、コントローラ２００はＳＡＮログオン情報を提供し、そこでＳＡＮへの接続が達成される（ステップ１２１０）。ステップ１２１２で、新しいユーザーランドへのｐｉｖｏｔ＿ｒｏｏｔがあり得る。

例示的な実施形態として、システム１００は、ほぼすべてのハードウェア上でネットワークインフラとオンデマンドの高性能アプリケーションおよびサービスを迅速に実装できるように設計された、アウトオブバンドのコントローラ環境を含む。コントローラ２００は、デスクトップ／ワークステーション環境から数千ノードの超並列ＨＰＣ環境までＨＰＣアプリケーションを確実に拡張できる、ＶＭおよびコンテナ管理および／またはベアメタル自動デプロイを提供できる、高度にスケーラブルで「クラスタリング認識」の自動デプロイシステムを提供できる。クラスタ化されたサービス、アプリケーション、およびリソースの認識を通じて、コントローラ２００は、クラスタ２５２をリアルタイムで作成、破壊、縮小、および成長させることができる。クラスタリングルール９００の一部として含めることができるコントローラ２００のＡＰＩは、ＧＰＵサポート、クラスタセキュリティ管理、およびＭＬインターフェースなどの追加機能を追加するための柔軟性を提供する抽象化レイヤーを含むことができる。

コントローラ２００のクラスタ管理ＡＰＩは、各ＡＰＩエンドポイントの名前、説明、引数タイプ、および結果タイプを含むＡＰＩ定義ファイルを含むことができる。クラスタリングルール９００は、「クラスタコマンド」を行うためのエンドポイントを有することができる。これらのエンドポイントのためのＳＤＫが存在することができる。そして、これらのファイルは、実行時にＡＰＩエンドポイントマッピングを生成するために使用され得る。このＡＰＩ生成方法により、新しいサービスや機能が追加されたときに、コアＡＰＩの拡張を比較的容易に開発することができる。ＡＰＩエンドポイントのサーバ側の実装は、ＡＰＩエンドポイント名と、引数を処理し、作業を行い、ＡＰＩ定義で指定された型のオブジェクトを返すルーチンとのマッピングで構成することができる。

ＡＰＩ定義ファイルに含めることができるＡＰＩエンドポイントの例としては、以下のものがある：
・新しいクラスタを作成する
・クラスタを破壊する
・クラスタを成長させる
・クラスタを縮小する
・クラスタの起動と停止
・クラスタヘルスを取得する
・クラスタをアップグレードする

図１８Ａおよび図１８Ｂは、これらの操作のプロセスフロー例を示す。

コントローラ２００のクラスタマネージャ拡張は、アプリケーションおよびサービスの複数のインスタンス間の並列化をオーケストレーションする機能、ならびにシングルユーザーのアプリケーションの複数のインスタンスをスピンアップする機能を組み込むことができる。クラスタマネージャは、（１）クラスタへの変更を検証、追跡、およびスケジューリングし、それらの変更を永続データベースに格納すること、（２）コントローラ２００内の他のマネージャにコマンドを発行してクラスタに必要なリソース（仮想マシン（ＶＭ）、ストレージオブジェクト、ネットワークなど）をクリースすること、（３）それらの操作をサポートするクラスタに対してクラスタを自動的に成長させて縮小することなど、相互に作用するクラスタ間でも、クラスタ化されたサービスおよびアプリケーションの管理に関するタスクに責任を負うことができる。

この点で、クラスタマネージャの操作は、クラスタＡＰＩに対するＡＰＩコール（ユーザーが発行するＡＰＩコールなど）および内部で生成される自動化イベントに応答してトリガーされることがある。コマンドはドメインマネージャに発行され、各クラスタに新しい隔離環境を作成する。これらの環境は、独自のサブドメインとサブネットを持つことができる。これらの環境は、クラスタ内外のトラフィックを管理するための専用のルータ／ファイアウォール（Ｌｉｎｕｘ ＶＭとして実装されたルータ／ファイアウォールなど）を持つこともできる。一例として、このドメインはドメインＡＰＩを通じて直接ユーザーが管理できるものではなく、代わりにクラスタマネージャが管理することができる。したがって、このような例では、ドメインに対するすべての管理操作は、クラスタマネージャによって発行される（または許可される）場合を除き、禁止することができる。

また、ドメインマネージャには、クラスタ内に存在するサービスを作成するためのコマンドも発行される。これは、特定のサービスのＮ個のコピーかもしれないし、クラスタ内のノードに仕事を渡す専用のスケジューラ（または制御）サービスを含むかもしれない。このアプローチにより、実行者はスケジューラを必要とするクラスタリングソフトウェアや、クラスタを指揮する独自の「リーダー」を自ら選出できるソフトウェアに対応することができる。

また、クラスタ内のルータ／ファイアウォールサービスにコマンドを発行して、クラスタが存在するドメインからクラスタへのアクセスを許可することもできる。

さらに、クラスタ内の各サービスをデプロイし管理するために、サービスマネージャにコマンドを発行することができる。例示的な実施形態では、クラスタの一部としてデプロイされるサービスは、サービスＡＰＩを通じて直接管理することができない。これにより、ユーザーが誤って（または意図的に）サービスの一部を変更し、クラスタを一貫性のない状態にすることを防ぐ。代わりに、サービスはグループとして管理可能であり、変更はクラスタマネージャを通じてすべてのノードに適用されるため、すべてのクラスタメンバーで一貫性が確保される。

クラスタマネージャ拡張機能は、管理されたソフトウェアのデプロイメントを通じてサービス間の依存関係を定義し、サービスの依存関係を解決する目的でクラスタを１つのサービスとして扱うことを可能にすることができる。例えば、クラスタのジョブスケジューラは、ジョブ結果を保存するためにデータベースサービスにアクセスする必要がある。クラスタマネージャ拡張機能による依存関係のサポートにより、クラスタは他のクラスタに依存することができ、これは高信頼性環境にとって望ましい特性である。

システムのサービスパッケージ定義を更新して、ＨＰＣアプリケーションのクラスタリング要件に関する情報を含めることができる。新しいサービスパッケージ定義の拡張機能は、クラスタマネージャがクラスタを適切にデプロイする方法を決定するために使用することができる。

別の例示的な実施形態として、システム１００は、ＨＰＣ環境におけるＩｎｆｉｎｉＢａｎｄファブリックの構成とセキュリティ確保のために、ＯｐｅｎＳＭの自動化と管理を組み込むことができる。ＩｎｆｉｎｉＢａｎｄ（ＩＢ）は、システム間の高速（最大２００Ｇｂｐｓ）接続を可能にする最新のデータファブリックであり、高性能ブロックストレージへのアクセスを提供することができ、また、ＯｐｅｎＭＰＩのトランスポートとして機能する。

これを実現するために、ローカルサービスＯｐｅｎＳＭを、ＨＰＣシステム、個々のノード、ファブリック、コンポーネント、アプリケーション、および並列演算のクラスタの状態を認識するスマートコントローラに適合させることができる。また、スマートコントローラは、これらのコンポーネント間の相互作用を構成して、最大限のセキュリティを確保することができる。

ＯｐｅｎＳＭは、ＩＢファブリックをスキャンし、初期化し、変化への対応に時々掃引することができる。ＯｐｅｎＳＭは、まず、アウトオブバンド接続２６０を介してコントローラ２００と統合し、ネットワークデーモンと統合して、システム１００のネットワーク管理デーモン（ＮＭＤ）を作成することができる。ＮＭＤは、ＩＢ構成および内部システムイベントおよびサービスによって生成された自動化された要求を、作成、破壊、最適化、およびその他の方法で管理することができるようになる。ＮＭＤは、経路最適化アルゴリズム（最小ホップ、ＤＯＲルーティング、およびＴｏｒｕｓ－２ＱｏＳを含み得る）を含む、ホスト上のＩＢハードウェアを管理および構成することができる。しかし、各ＶＭやホストを直列に管理する代わりに、ＮＭＤは各ホストと交渉してＩＢファブリックを最適に構成することができる。

ＩＢパーティションの定義と構成をサポートするためにネットワークＡＰＩを拡張し、ＩＢとサブネットマネージャの状態を追跡するためのデータベーステーブルを追加することにより、クラスタ化されたシステムでＩＢファブリックをサポートすることができる。したがって、ユーザーはシステム１００を使用してＩＢパーティションを作成し、それをシステム１００の内部データベースで永続させることができるようになる。これに関して、システム１００のためのネットワークＡＰＩ仕様は、ＩＢパーティションを表す新しいネットワークの作成をサポートすることができる。これは、新しい種類のネットワーク、例えば「ｉｂ－ｐａｒｔｉｔｉｏｎ」のサポートを追加することによって達成することができる。この新しいｉｂ－ｐａｒｔｉｔｉｏｎネットワークのタイプは、パーティション名のみを供給する必要がある。ネットワークＡＰＩの仕様が更新され、ｉｂ－ｐａｒｔｉｔｉｏｎが新しいタイプのネットワークとして受け入れられるようになれば、新しいネットワーク・プラグインを採用することもできる。このプラグインは、定義された各ＩＢパーティションの状態と構成を追跡し、ファブリック構成を永続データベースに保存し、システム１００内の他のコンポーネントによって消費されるＩＢパーティションデータ構造の形状を定義する責任を負うことができる。

Ｉｂ－ｐａｒｔｉｔｉｏｎネットワークをＶＭに追加する場合、ＩＢインターフェースにＧＵＩＤを生成することができ、ＶＭ起動時に永続的でデプロイ内で一意である。これらのＧＵＩＤは、ＶＭに渡すためにＱＥＭＵに渡される前に、ＮＭＤがＳＲ－ＩＯＶ仮想機能のＧＵＩＤを設定するために使用される。

新しいデータベースのテーブルを追加して、ｉｂ－ｐａｒｔｉｔｉｏｎネットワークとＶＭのマッピング、およびそのＶＭで使用されるＧＵＩを追跡することができる。このデータベースのテーブルでは、固有の制約と組み込みのデータベース関数を使用して、すべてのマッピングにおいて固有でＩＢのＧＵＩＤとして使用可能なＵＵＩＤ（６４ビット数値ＩＤの形式をとることができる）を生成することができる。ＶＭがどのコンピュートホスト上で実行されるかにかかわらず、デバイスがＶＭから削除されるまでは、常に同じＩＢ ＧＵＩＤを持つことになる。

関連する機能をまとめるために、ＮＭＤは、ホスト上に存在するＣｏｎｎｅｃｔＸ ＶＰＩカードを構成してＳＲ－ＩＯＶを有効にし、各ＩＢ ＳＲ－ＩＯＶ仮想機能（ＶＦ）のＧＵＩＤをシステム１００が制御する値に設定するためのサポートを得ることができる。これは、ｉｂ－ｐａｒｔｉｔｉｏｎネットワークがＶＭに追加されるときにＧＵＩＤが作成されるため、ファブリックのトポロジーの一貫性を確保するのに役立つ。ＶＭは、ネットワークがＶＭから削除されるまで、そのＩＢ ＧＵＩＤを保持することができる。これを実現するには、システムが保持する ＬｉｎｕｘカーネルのイメージでＳＲ－ＩＯＶを有効にし、ホスト上でＩｎｔｅｌ ＶＴ－ｘとＶＴ－ｄまたは ＡＭＤ Ｖｉ が有効であることを確認する。この取り組みでは、Ｍｅｌｌａｎｏｘ ＯＦＥＤで配布されているアウトオブツリーＩＢドライバではなく、インカーネルＩＢドライバを使用することができる。また、ＳＲ－ＩＯＶ ＶＦをＶＭに渡すためにＱＥＭＵが利用するＬｉｎｕｘ ＶＦＩＯドライバも有効にすることができる。ＮＭＤは、Ｌｉｎｕｘ ＳｙｓＦＳを利用してＣｏｎｎｅｃｔＸカードのＳＲ－ＩＯＶを構成し、ＶＦのＧＵＩＤを構成し、ＶＭがＶＦにアクセスする必要があるときにＭｅｌｌａｎｏｘ ＤｒｉｖｅｒからＶＦを結合および結合解除できる。

この取り組みの一環として、システム１００において、Ｃｏｍｐｕｔｅ Ｄａｅｍｏｎとコントローラ２００がＩＢファブリックにアクセスするためのＳＲ－ＩＯＶ ＶＦの作成と設定を要求できるように、新しい内部ＡＰＩ拡張を開発することができる。このために採用できる新しいＡＰＩ機能としては、以下の４つがある：
・ＩｎｆｉｎｉＢａｎｄ仮想関数をリクエスト
・ＩｎｆｉｎｉＢａｎｄ仮想関数をリリース
・仮想関数の最大数を取得
・使用中の仮想関数の数を取得

リクエストＡＰＩとリリースＡＰＩは、ＶＦを構成または撤去するために必要なすべてのＧＵＩＤが供給されることを要求することができ、ＶＦ利用ＡＰＩは、ホストが別のＶＦをサポートできるかどうかを判断するために使用される。新しいＶＦを構成できない場合、リクエストＡＰＩコールはエラーを報告することができる。成功した場合、リクエストのエンドポイントは仮想機能にマッピングされたＰＣＩ Ｂｕｓ－Ｄｅｖｉｃｅ－Ｆｕｎｃｔｉｏｎ（ＢＤＦ）タプルを返すことができ、要求者は新しいＶＦを使用することができる。

システム１００がＩＢ用のＳＲ－ＩＯＶ ＶＦを管理できるようになると、コントローラ２００を介してＯｐｅｎＳＭを管理する必要がある。この機能が必要なのは、コントローラ２００が、ＯｐｅｎＳＭの複数のインスタンスを独自のＬｉｎｕｘコンテナ内で実行し、ＯｐｅｎＳＭがクラッシュした場合に冗長性とフェイルオーバーサポートを提供することができるためである。これらの各コンテナは、ＯｐｅｎＳＭインスタンスがファブリックを構成するために使用できる独自のＩＢ ＶＦを有し、コントローラ２００は、ファブリックの安定性を確保するために一貫している必要があるため、これらのインターフェースのＧＵＩＤの生成および保存の責任を負うことができる。コントローラ２００は、必要なＯｐｅｎＳＭ設定ファイルを生成し、ホストからコンテナファイルシステムへの読み取り専用のバインドマウントを介してコンテナに渡すことも担当する。別の読み取り／書き込み可能なバインドマウントを使用して、インスタンスごとのログディレクトリを各コンテナで共有することができる。

この作業は、コントローラ２００に組み込むことができる軽量プロセス管理レイヤで使用される「Ｗｏｒｋｅｒ Ｐｌｕｇｉｎ」として実装することができる。Ｗｏｒｋｅｒ Ｐｌｕｇｉｎは、コントローラ２００と同じホスト上で実行されることが期待されるプロセスまたは一連のプロセスを定義する。これは現在、インフラストラクチャのオーケストレーションの一部として使用されるローカルＤＨＣＰとＨＴＴＰサーバを管理するために利用されている。この新しいＷｏｒｋｅｒ Ｐｌｕｇｉｎは、既存のコンテナランタイム（ｒｕｎｃ、ＬＸＣ、ｒｋｔ など）を使用するか、Ｌｉｎｕｘの名前空間とコントロールグループ（ｃｇｒｏｕｐｓ）を管理してコンテナを手動で作成することによって、複数のＯｐｅｎＳＭ 管理コンテナを起動できる。このタスクの作業の大部分はコンテナの動作を定義することであるが、ＯｐｅｎＳＭ設定ファイルの生成は、Ｍｅｌｌａｎｏｘ のＯＦＥＤドキュメントで完全な仕様が公開されているため、非常に簡単である。ＯｐｅｎＳＭ管理コンテナの起動は８つのステップに分けられ、デプロイされるレプリカごとにステップ２から８を繰り返す：
１．共通のＯｐｅｎＳＭ設定ファイルを生成する。これにはパーティションメンバーシップ、ルーティング設定、ＱｏＳに関する情報が含まれる。
２．ＮＭＤと通信し、ＩＢ ＳＲ－ＩＯＶ ＶＦを作成して設定する。
３．インスタンス単位のファイルを生成する：
ａ．ＣｏｎｔｒｏｌｌｅｒがアクセスするＯｐｅｎＳＭログを保存するログストレージディレクトリ。
ｂ．フェイルオーバーサポートのためのＯｐｅｎＳＭ Ｐｒｉｏｒｉｔｙを指定するインスタンス固有の設定。
４．Ｃｏｎｔａｉｎｅｒのランタイムを使用して、ＯｐｅｎＳＭをはじめ、正常に機能するために必要なＯＦＥＤのコンポーネントやシステムパッケージが入った新しいコンテナを作成する。
５．ＯｐｅｎＳＭ Ｃｏｎｆｉｇｕｒａｔｉｏｎファイルを読み取り専用としてコンテナにバインドマウントする。
６．Ｃｏｎｔａｉｎｅｒにログディレクトリをｒｅａｄ－ｗｒｉｔｅでバインドマウントする。
７．Ｃｏｎｔａｉｎｅｒ内からＩＢ ＶＦにアクセスできるようにする。
８．Ｃｏｎｔａｉｎｅｒ内でＯｐｅｎＳＭを起動する。

ベースとなるコンテナイメージは、Ａｌｐｉｎｅ Ｌｉｎｕｘ、Ｇｅｎｔｏｏ Ｓｔａｇｅ ３のイメージ、またはその他の同様に小さく切り詰められたＬｉｎｕｘディストリビューションをベースとすることができる。ＯｐｅｎＳＭがクラッシュしてＣｏｎｔａｉｎｅｒが終了した場合、レプリカの１つがファブリックの管理を引き継ぐ間に、コンテナを再始動または破壊して再作成することができる。

ＯｐｅｎＳＭ構成は、定義されたＯｐｅｎＳＭレプリカの数、およびＶＭに接続されたＮｅｔｗｏｒｋ Ｄｅｖｉｃｅとして実装されるＶＭの「ｉｂ－ｐａｒｔｉｔｉｏｎ」ネットワークメンバーシップによって定義されるＩＢパーティションメンバーシップに基づいて生成することができる。コントローラ２００は、生成されるインスタンスごとの構成における各ＯｐｅｎＳＭインスタンスの優先度を指示することができるが、要件は、少なくとも優先度１および２のインスタンスを実行するであろう。

ＱＥＭＵは、Ｌｉｎｕｘ ＶＦＩＯドライバとＱＥＭＵ起動時の特定のコマンドライン引数によって、ＰＣＩｅ Ｐａｓｓｔｈｒｏｕｇｈをサポートする。この機能をサポートするために、Ｃｏｍｐｕｔｅ Ｄａｅｍｏｎは、新しいＶＭを起動する際にそのＶＭが「ｉｂ－ｐａｒｔｉｔｉｏｎ」ネットワークデバイスを持つ場合、同じホスト上のＮＭＤに対してＩＢ ＳＲ－ＩＯＶ ＶＦ Ｒｅｑｕｅｓｔを発行することができる。このリクエストに失敗した場合、ＶＭは起動できないが、そうでなければＶＭの起動は通常通り行われる。次のステップは、ＶＦをＶＭに渡すために必要な引数を生成することである。

Ｃｏｍｐｕｔｅ Ｄａｅｍｏｎは、接続されたＤｅｖｉｃｅのリストを同等の一連の引数にマッピングすることによって、ＱＥＭＵコマンドライン引数を生成する。新しいマッピングを追加するには、Ｄｅｖｉｃｅのタイプ（この場合、「ｉｂ－ｐａｒｔｉｔｉｏｎ」Ｎｅｔｗｏｒｋに接続されているＮｅｔｗｏｒｋ Ｄｅｖｉｃｅ）を検査し、そのＤｅｖｉｃｅに関連する設定を取得してコマンドライン引数を構築することからなる。ＰＣＩ Ｐａｓｓｔｈｒｏｕｇｈの場合、これは「－ｄｅｖｉｃｅ ｖｆｉｏ－ｐｃｉ，ｈｏｓｔ＝＄ｂｄｆ」引数を使用して、どのＶＦをＶＭに通す必要があるかをＱＥＭＵに通知することを意味する。

本発明は、その例示的な実施形態に関連して上述されているが、本発明の範囲内にある様々な変更がなされる可能性がある。本発明に対するそのような修正は、本明細書の教示を検討すれば認識できるであろう。

Claims (38)

1. コンピュータシステムのコントローラを備えるシステムであって、前記コントローラは、サービステンプレートによって定義された複数のクラスタリングルールを用いて、クラスタリング可能なサービスを自動クラスタリングする、システム。
2. 前記コントローラは、（１）テンプレートのライブラリからサービステンプレートを選択し、（２）選択されたサービステンプレートによって定義されたクラスタリングルールを読み出し、（３）読み出したクラスタリングルールに従って複数のサービスインスタンスをクラスタリング可能なサービスとして展開する、請求項１に記載のシステム。
3. 前記複数のサービスインスタンスは、互いに依存し合う、請求項２に記載のシステム。
4. コントローラが、サービスインスタンスを管理または負荷分散するためのスケジューラをデプロイする、請求項２～３のいずれかに記載のシステム。
5. 前記クラスタリングルールは、クラスタ開始ルールを含み、前記クラスタ開始ルールは、前記クラスタリング可能なサービスに対応するクラスタの依存関係を特定する、請求項１～４のいずれかに記載のシステム。
6. 前記クラスタリングルールは、前記クラスタが展開される複数の異なるハードウェアタイプに基づいて、前記クラスタリング可能なサービスに対応するクラスタを展開するための異なるルールを含む、請求項１～５のいずれかに記載のシステム。
7. 前記ハードウェアの種類は、ＧＰＵを含む、請求項６に記載のシステム。
8. 前記クラスタリングルールは、前記クラスタリング可能なサービスに対応するクラスタを成長させるためのルールを含む、請求項１～７のいずれかに記載のシステム。
9. 前記クラスタ成長ルールは、前記クラスタのサービスイメージへのポインタを含む、請求項８に記載のシステム。
10. 前記クラスタ成長ルールは、前記クラスタのネットワーキング・ルールを含む、請求項８に記載のシステム。
11. 前記クラスタリングルールは、前記クラスタリング可能なサービスに対応するクラスタを縮小するためのルールを含む、請求項１～１０のいずれかに記載のシステム。
12. 前記クラスタリングルールは、前記クラスタブルサービスに対応するクラスタのリソース要件を特定するルールを含む、請求項１～１１のいずれか一項に記載のシステム。
13. 前記クラスタリングルールは、前記クラスタブルサービスに対応するクラスタをパワーオンおよびパワーオフするためのルールを含む、請求項１～１２のいずれかに記載のシステム。
14. 前記サービステンプレートは、前記クラスタリング可能なサービスに対応するクラスタを管理するために前記コントローラによって展開されるクラスタマネージャを定義する、請求項１～１３のいずれかに記載のシステム。
15. 前記コントローラは、アウトオブバンド管理接続を介して、前記クラスタリング可能なサービスに対応するクラスタを構成する、請求項１～１４のいずれかに記載のシステム。
16. 前記クラスタリング可能なサービスに対応するクラスタは、ネットワークリソースを介して互いに接続された複数の計算リソース上にデプロイされる、請求項１～１５のいずれかに記載のシステム。
17. 前記コントローラは、前記サービステンプレートに基づくｐｉｖｏｔ＿ｒｏｏｔプロセスを採用し、前記ｐｉｖｏｔ＿ｒｏｏｔプロセスは、前記クラスタリング可能なサービスに対応するクラスタを、Ｂｉｏｓ依存なしにストレージエリアネットワーク（ＳＡＮ）からブートすることを可能にする、請求項１～１６のいずれかに記載のシステム。
18. サービステンプレートから複数のクラスタリングルールを読み取るステップと、
    前記クラスタリングルールに従って、前記複数のアプリケーションをクラスタとしてデプロイするステップと、
    を含む、方法。
19. アプリケーションが相互に依存する、請求項１８に記載の方法。
20. アプリケーションを管理または負荷分散するためにスケジューラを構成することをさらに含む、請求項１８に記載の方法。
21. サービスのクラスタとしてのアプリケーションに依存する他のサービスをさらに含む、請求項１８に記載の方法。
22. 非一過性のコンピュータ読み取り可能な記憶媒体に常駐する複数のプロセッサ実行可能な命令を含むコンピュータプログラム製品であって、前記命令は、プロセッサによる実行のために構成され、サービステンプレートによって定義された複数のクラスタリングルールを使用して、プロセッサにクラスタリング可能なサービスを自動クラスタリングさせる、コンピュータプログラム製品。
23. 前記命令は、前記プロセッサによる実行により、前記プロセッサに、（１）テンプレートのライブラリからサービステンプレートを選択させ、（２）選択されたサービステンプレートによって定義されたクラスタリングルールを読み取らせ、（３）読み取られたクラスタリングルールに従って、複数のサービスインスタンスを前記クラスタブルサービスとしてデプロイさせるようにさらに構成されている請求項２２記載のコンピュータプログラム製品。
24. 前記複数のサービスインスタンスは、互いに依存し合う、請求項２３に記載のコンピュータプログラム製品。
25. 前記命令は、前記プロセッサによる実行のために、前記プロセッサに、前記サービスインスタンスを管理または負荷分散するためのスケジューラをデプロイさせるようにさらに構成される、請求項２３に記載のコンピュータプログラム製品。
26. クラスタリングルールがクラスタ開始ルールを含み、クラスタ開始ルールがクラスタリング可能なサービスに対応するクラスタの依存関係を識別する、請求項１８～２５のいずれかに記載の方法またはコンピュータプログラム製品。
27. クラスタリングのルールは、クラスタがデプロイされる複数の異なるハードウェアタイプに基づいて、クラスタリング可能なサービスに対応するクラスタをデプロイするための異なるルールを含む、請求項１８～２６のいずれかに記載の方法またはコンピュータプログラム製品。
28. ハードウェアの種類は、ＧＰＵを含む、請求項２７に記載の方法またはコンピュータプログラム製品。
29. 前記クラスタリングのルールは、前記クラスタリング可能なサービスに対応するクラスタを成長させるためのルールを含む、請求項１８～２８のいずれかに記載の方法またはコンピュータプログラム製品。
30. 前記クラスタ成長ルールは、前記クラスタのサービスイメージへのポインタを含む、請求項２９に記載の方法またはコンピュータプログラム製品。
31. 前記クラスタ成長ルールは、前記クラスタのネットワークのルールを含む、請求項２９～３０のいずれかに記載の方法またはコンピュータプログラム製品。
32. 前記クラスタリングのルールは、前記クラスタリング可能なサービスに対応するクラスタを縮小するためのルールを含む、請求項１８～３１のいずれかに記載の方法またはコンピュータプログラム製品。
33. 前記クラスタリングルールは、前記クラスタリングが可能なサービスに対応するクラスタのリソース要件を特定するルールを含む、請求項１８～３２のいずれかに記載の方法またはコンピュータプログラム製品。
34. 前記クラスタリングルールは、前記クラスタリング可能サービスに対応するクラスタをパワーオンおよびパワーオフするためのルールを含む、請求項１８～３３のいずれかに記載の方法またはコンピュータプログラム製品。
35. 前記サービステンプレートは、前記クラスタリング可能なサービスに対応するクラスタを管理するために前記コントローラによってデプロイされるクラスタマネージャを定義する、請求項１８～３４のいずれかに記載の方法またはコンピュータプログラム製品。
36. 前記コントローラは、アウトオブバンド管理接続を介して、前記クラスタリング可能なサービスに対応するクラスタを構成する、請求項１８～３５のいずれかに記載の方法またはコンピュータプログラム製品。
37. クラスタリング可能なサービスに対応するクラスタは、ネットワークリソースを介して互いに接続された複数の計算リソース上にデプロイされる、請求項１８～３６のいずれかに記載の方法またはコンピュータプログラム製品。
38. コントローラが、サービステンプレートに基づくピボットルートプロセスを採用し、ｐｉｖｏｔ＿ｒｏｏｔプロセスが、Ｂｉｏｓ依存関係なしに、ストレージエリアネットワーク（ＳＡＮ）からクラスタリング可能なサービスに対応するクラスタをブート可能にする、請求項１８～３７のいずれかに記載の方法またはコンピュータプログラム製品。