JP6174604B2

JP6174604B2 - クラウド・コンピューティング・スタンプの自動化された構築

Info

Publication number: JP6174604B2
Application number: JP2014554760A
Authority: JP
Inventors: ジュブラン，マルワーン・イー; ガーシャフト，アレクサンドル
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2012-01-30
Filing date: 2013-01-21
Publication date: 2017-08-02
Anticipated expiration: 2033-01-21
Also published as: JP2015512079A; CN104081371B; CN104081371A; US20130198346A1; EP2810175A1; WO2013116021A1; KR101954480B1; EP2810175A4; ES2587902T3; KR20140120895A; EP2810175B1; US9641394B2

Description

本願発明の一実施例は、例えば、クラウド・コンピューティング・スタンプの自動化された構築に関する。

[0001]一般的に、分散されたサービスアプリケーションは、（様々なノードを横断して）クラウド・コンピューティング・ネットワークでホストされ、主として、サービスアプリケーション・コンポーネントの冗長性、動的な拡張性、および自動修復機能を通じて高い利用可能度を促進することを意図する。これらのサービスアプリケーションは、多くの場合、サービスアプリケーション・コンポーネントのグループを含む部分に分割される。これらのサービスアプリケーション・コンポーネントは、１つまたは複数のデータセンターのノード（たとえば物理的なマシンおよび仮想マシン）の全体にわたってホストすることができる。多くの場合、サービスアプリケーションの使用の需要に対応し、基礎的なハードウェアからのサポートの不足のためにサービスアプリケーション全体が利用不可能にならないことを保証するのを支援するために、これらのデータセンターの計算／ストレージ容量を作成または拡張する必要性が存在する。

[0002]データセンターの拡張は、データセンター内の既存のノードと連携して動作するように、新しい組のハードウェアを構成するか、または既存の組のハードウェアを再構成するなど、様々なシナリオを含むことができる。一例では、データセンターノードを相互に連結させるファブリック内に統合するために、それぞれが複数のブレードを収容するラックの新しい組を対象とすることができる。このファブリックは、既存のノードを横断して分散されたサービスアプリケーション・コンポーネントおよびラック、ネットワークデバイス（Ｌ２／３スイッチ、ルーター、負荷分散装置）、電源装置およびシリアルデバイス、ならびにブレードなどの新しく追加されたハードウェアが、あたかも各サービスアプリケーションがそれ自身の独立したコンピューティングデバイスで実行されているかのように対話できることを保証することを支援する。

[0003]データセンターの拡張を実施する場合、ファブリックに新しい組のハードウェアを統合するためのステップは現在、手作業で行われる。これらの手作業で行われるステップは、多くの場合、時間がかかり、効果的ではなく、かつ結果に一貫性がないため、ファブリック内のサービス中断につながる可能性がある。したがって、ファブリックに展開するために、１組の指定されたハードウェアを構築する自動化されたエンドツーエンドプロセスが、データセンターの計算／ストレージ容量を拡張するために、効率的で堅牢、かつ拡張可能なフレームワークを達成するのに役に立つだろう。

[0004]この「発明の概要」は、以下に「発明を実施するための形態」にさらに記述する概念を簡素化された形で紹介するために提供するものである。この「発明の概要」は、請求された主題の重要な特徴または必須の特徴を特定することを意図するものではなく、請求された主題の範囲を決定する際の支援として使用することを意図するものでもない。

[0005]本発明の実施形態は、構成されていないハードウェアのインベントリーの物理的なトポロジーを検証し、データセンターのクラウド・コンピューティング・ファブリック内のファブリック・コンピューティング・クラスター（ＦＣＣ）としてハードウェアインベントリーを統合／展開する、自動化されたブートストラッププロセスを実施するためのシステム、方法、およびコンピューター記憶媒体に関する。ブートストラッププロセスが実装される自動化された方法により、データセンターの容量を再構成したり、または追加したりするために、手作業で実行される手順から突然生じる、（上に記述した）解決が難しい悪い影響を回避する。したがって、本発明の実施形態では、自動化されたブートストラッププロセスにより、一貫性があり効果的な方法で、ハードウェアインベントリーを構築し、クラウド・コンピューティング・ファブリックにそれを組み込むことが可能になる。

[0006]一般的に、ブートストラッププロセスは、データセンターの計算／ストレージ容量を作成または拡張するための指示を受信したときにトリガーされる。実施形態では、データセンターは、複数のノード（たとえば物理的なマシンまたは仮想マシン）、ネットワークデバイス、シリアルデバイス、電源装置、および操作可能なように相互に連結され、クラウド・コンピューティング・ファブリックを介して管理される他の装置を含む。ファブリックは、データセンターの全体にわたって分散されたサービスアプリケーションに対して基礎的なサポートを提供する。特に、ノードの全体にわたって分散されたこれらのサービスアプリケーションの部分（たとえば役割のインスタンス、またはプログラムコンポーネント）は、ファブリックのコントローラーによって管理することができる。ファブリックコントローラーは、一般的に、コンピューターリソース、ネットワークギヤ、シリアルデバイス、およびファブリックの基礎的な機能をサポートする電源ユニットの正常性の監視、維持、および管理に関わる様々な職務を担当する。

[0007]代表的な一実施形態では、ブートストラッププロセスは、イベント（たとえばデータセンターの容量を拡張するための呼び出し）によってトリガーされたときに独立したフェーズで実行される。これらのフェーズは、それぞれ自己完結型のワークフローを実行することによって実施され、図２に全体的に描写されている。最初に、ハードウェアのインベントリーの初期セットアップを指定するために共同編集フェーズを実施することができる。このフェーズは、顧客の敷地で必要な追加の容量を指定する顧客の依存関係スキーマを受信するプロセスと、依存関係スキーマを満たすハードウェアを識別するプロセスと、識別されたハードウェアを構成するための値を収集するために顧客とインターフェースするプロセスと、値から記号表現を生成するプロセスと、ハードウェアの配達時に記号表現を使用して構成を検証するプロセスと、トポロジーの配置を記念するテンプレートファイルを準備するプロセスとの１つまたは複数を実装するためのワークフローを含む。

[0008]テンプレートファイルを準備するときに、ネットワークデバイスおよびハードウェアデバイスの検出および検証を含むフェーズを始めることができる。これらのデバイスのそれぞれに対して検出および検証を実行するためのワークフローは、一般的に、ネットワークベースの接続および／またはハードウェアデバイスに関する物理的なトポロジー（たとえばラック間の場所および配線の配置）を検出するシリアルベースの接続を介してネットワークデバイスと通信するユーザーデバイス（複数可）を含む。これらのユーザーデバイス（複数可）は、ハードウェアデバイスを検証するために、検出された物理的なトポロジーをテンプレートファイルに対して相互参照することができる。トポロジーの物理的／論理的な構造が完全に生成されると、新しいファブリックインスタンスの展開、または既存のファブリックインスタンスの拡張を始めることができる。

[0009]次に、ユーザーデバイス（複数可）は、ファブリック・コンピューティング・クラスター（ＦＣＣ）として、データセンターのファブリック内でハードウェアインベントリーを展開し、ＦＣＣでセキュリティを供給するフェーズを有効にするために、データセンターのクラウド・コンピューティング・ファブリックとの通信を開始することができる。これらのフェーズは、データセンター内のリソースおよび既存のハードウェアと対話するために、ハードウェアクラスターのセットアップをサポートする様々なワークフローを含む。さらに、これらのワークフローは、ハードウェアインベントリーの物理的なトポロジーを検証するときに収集した情報からのインフラストラクチャー状態を準備するステップと、ファブリックコントローラーとインフラストラクチャー状態を共有することによって、データセンターのファブリック内でハードウェアインベントリーを統合するステップと、ハードウェアインベントリー内でファブリックで実行するサービスを展開するステップと、データセンターＦＣＣとしてハードウェアインベントリーを指定するステップとを含むことができる。したがって、連続して実施された場合、ブートストラッププロセスのこれらのフェーズは、ハードウェアインベントリーを構築し、データセンターのファブリック内でハードウェアインベントリーを統合するためのエンドツーエンドの自動化を促進する。このエンドツーエンドの自動化は、データセンター内にあらかじめ確立されたハードウェアインベントリー（たとえば、データセンター内の新しいＦＣＣインスタンスを表すために既存のＦＣＣを再構成）、またはデータセンター外のサイトで（たとえば、データセンター内の新しいＦＣＣインスタンスとしてリモートハードウェアインベントリーを統合）、効率的で堅牢かつ拡張可能なフレームワークをさらに達成することができる。

[0010]本発明の実施形態について、添付図に関して以下に詳細に記述する。

[0011]本発明の実施形態を実装するときに使用するのに適した代表的なコンピューター環境を示すブロック図である。 [0012]本発明の一実施形態による、データセンターのクラウド・コンピューティング・ファブリックにハードウェアのインベントリーを組み込むためのブートストラッププロセスの代表的なフェーズを示す流れ図である。 [0013]ハードウェアのインベントリーの第１のタイプのトポロジーを検出、検証、および構成するための代表的な検証エコシステムを示す図であり、検証エコシステムは、本発明の実施形態を実装するときに使用するのに適している。 [0014]ハードウェアインベントリーの第２のタイプのトポロジーを検出、検証、および構成するための代表的な検証エコシステムを示す図であり、検証エコシステムは、本発明の実施形態を実装するときに使用するのに適している。 [0015]データセンターのクラウド・コンピューティング・ファブリック内でハードウェアインベントリーを統合および展開するための代表的なブートストラップエコシステムを示す図であり、ブートストラップエコシステムは、本発明の実施形態を実装するときに使用するのに適している。 [0016]本発明の一実施形態により、データセンターのトポロジー内に組み込まれるハードウェアのインベントリーを検出および検証するための全体的な方法を示す流れ図である。 [0017]本発明の一実施形態により、データセンターのファブリック・コンピューティング・クラスター（ＦＣＣ）にハードウェアの新しいインベントリーを構築する際にファブリックインスタンスを展開するため、またはデータセンター内の既存のＦＣＣスタンプの拡張時に、検出および検証された新しい／再び目的が与えられたハードウェアインベントリーを追加するための全体的な方法を示す流れ図である。

[0018]本発明の実施形態の主題について、法的要件を満たすために本明細書に特に記述している。しかし、記述自体は、本特許の範囲を限定することを意図するものではない。むしろ、発明者は、請求された主題は、他の現在の技術または将来的な技術に関連して、異なるステップまたは本文書に記述したものに類似するステップの組み合わせを含むように、他の方法でも具体化できることを意図している。

[0019]一般的に、本発明の実施形態は、ブートストラッププロセスを用いることによって、データセンターと、ハードウェアの洗練されていない組またはインベントリーを自動的にマージするために、クラウド・コンピューティング・ファブリック内に技術を導入する。本明細書で使用する場合、「ハードウェアインベントリー」というフェーズは、コンポーネントの特定の構成に限定することを意図するものではなく、最終的にファブリック内に統合できるデバイスの集まりを広く指し示している（たとえばネットワークデバイス、コンピューティングデバイス、および電源デバイス）。１つの実例では、ハードウェアインベントリーは、クラウド・コンピューティング・ネットワーク・サービス・プロバイダーの顧客によって管理された民間企業のネットワーク内にあってもよく、ここで、このタイプのハードウェアインベントリーに装置としてブートストラッププロセスを実装することで、データセンターと民間企業のネットワークとの間でリモートで到達可能になる。他の実例では、ハードウェアインベントリーは、クラウド・コンピューティング・ネットワーク・サービス・プロバイダーによって管理されるデータセンター内にある場合があり、ここで、ブートストラッププロセスを実装することで、データセンターのローカルストレージ／計算容量の構築が可能になる。

[0020]以下により詳しく記述するように、ブートストラッププロセスは、ブートストラッププロセスを含む様々なフェーズのオーケストレーションおよび実行を駆動する（図５のユーザーデバイス３１０で実行される）１つまたは複数のワークフローエンジンを使用するエンドツーエンドの自動化を備える。実施形態では、これらのフェーズは、独立したワークフローとして実施することができるため、各フェーズは、他のフェーズまたはワークフローの並行操作に頼ることなく、別々に呼び出しかつ完了まで駆動することができる。自己完結型の方法で、フェーズが独立して実施されることを可能にすることによって、各フェーズにおいて、以前または次のワークフローの有害な対話なく、ハードウェアインベントリーに増加分の改善を一貫して加える。

[0021]本発明の実施形態の概要を簡単に記述したので、本発明の実施形態を実装するのに適した代表的な操作環境について以下に記述する。
操作環境
[0022]特に最初に図１を参照すると、本発明の実施形態を実装するための代表的な操作環境が図示されており、コンピューティングデバイス１００として全体を示している。コンピューティングデバイス１００は、適切なコンピューター環境のほんの一例であり、本発明の使用または機能の範囲に関して限定を示唆することを意図するものではない。また、コンピューティングデバイス１００は、図示したコンポーネントの１つまたは組み合わせに関係する依存関係または要件を持つものとして解釈されるべきでない。

[0023]本発明は、コンピューター、またはパーソナル・データ・アシスタントもしくは他のハンドヘルドデバイスなど、他のマシンによって実行されるプログラムモジュールなどコンピューターで実行可能な命令を含む、コンピューターコードまたはマシンで使用可能な命令の一般的な文脈において記述することができる。一般的に、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含むプログラムモジュールは、特定のタスクを実行するか、または特定の抽象データ型を実装するコードを示している。本発明は、ハンドヘルドデバイス、民生用電子機器、汎用コンピューター、より専門的なコンピューティングデバイスなどを含む様々なシステム構成で実施することができる。本発明は、また、通信ネットワークを通じてリンクされるリモート処理デバイスによってタスクが実行される、分散されたコンピューティング環境に実施することができる。

[0024]図１を参照すると、コンピューティングデバイス１００は、メモリー１１２と、１つまたは複数のプロセッサー１１４と、１つまたは複数のプレゼンテーションコンポーネント１１６と、入力／出力（Ｉ／Ｏ）ポート１１８と、入力／出力コンポーネント１２０と、説明のための電源１２２と、というデバイスを直接的または間接的に結合するバス１１０を含む。バス１１０は、１つまたは複数のバスの可能性があるもの（アドレスバス、データバス、またはそれらの組み合わせなど）を表している。図１の様々なブロックは明瞭さのために線で示しているが、実際には、様々なコンポーネントの線引きはそれほど明瞭ではなく比喩的なものであり、線はより正確には灰色で曖昧である。たとえば、ディスプレイデバイスなどのプレゼンテーションコンポーネントをＩ／Ｏコンポーネントと考えることができる。また、プロセッサーはメモリーを備えている。発明者は、当技術分野の性質はそのようなものであることを認識しており、図１の図は、本発明の１つまたは複数の実施形態に関して使用することができる代表的なコンピューティングデバイスの単なる説明であることを繰り返す。「ワークステーション」、「サーバー」、「ラップトップ」、「ハンドヘルドデバイス」などのようなカテゴリは区別されておらず、すべてが図１の範囲内にあると考えられ、「コンピューティングデバイス」と呼ばれる。

[0025]コンピューティングデバイス１００は、典型的には、様々なコンピューター可読媒体を含む。コンピューター可読媒体は、コンピューティングデバイス１００によってアクセスできる任意の利用可能な媒体でもよく、揮発性および不揮発性の媒体、取り外し式および取り外し式でない媒体を含む。限定を目的とせずに例を挙げると、コンピューター可読媒体は、コンピューター記憶媒体および通信媒体を含むことができる。コンピューター記憶媒体は、コンピューター可読命令、データ構造、プログラムモジュール、または他のデータなど、情報を格納するための任意の方法または技術で実装された、揮発性および不揮発性、取り外し式および取り外し式でない媒体の両方を含む。コンピューター記憶媒体は、限定しないが、望まれる情報を格納するために使用することができ、コンピューティングデバイス１００によってアクセスすることができる、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリーもしくは他のメモリー技術、ＣＤ−ＲＯＭ、デジタル・バーサタイル・ディスクもしくは他の光学ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、もしく他の磁気記憶装置、または他の媒体を含む。通信媒体は、典型的には、コンピューター可読命令、データ構造、プログラムモジュール、または搬送波もしくは他の移送メカニズムなど、変調されたデータ信号の他のデータを具体化することができ、任意の情報配送媒体を含む。「変調されたデータ信号」という用語は、信号の情報を符号化する方法で設定または変更された、１つまたは複数のその特性を持つ信号を意味する。限定を目的とせずに例を挙げると、通信媒体は、有線ネットワークまたは直接的な有線接続などの有線媒体、ならびにアコースティック、ＲＦ、赤外線、および他の無線媒体などの無線媒体を含む。上記のいずれの組み合わせも、コンピューター可読媒体の範囲に含まれている。

[0026]メモリー１１２は、揮発性および／または不揮発性メモリーの形のコンピューター記憶媒体を含む。メモリーは、取り外し式、取り外し式ではない、またはそれらの組み合わせの場合がある。代表的なハードウェアデバイスは、ソリッドステートメモリー、ハードドライブ、光ディスクドライブなどを含む。コンピューティングデバイス１００は、メモリー１１２またはＩ／Ｏコンポーネント１２０など、様々なエンティティからデータを読み込む１つまたは複数のプロセッサーを含む。プレゼンテーションコンポーネント（複数可）１１６は、ユーザーまたは他のデバイスにデータ表示を提示する。代表的なプレゼンテーションコンポーネントは、ディスプレイデバイス、スピーカー、印刷コンポーネント、振動するコンポーネントなどを含む。

[0027]Ｉ／Ｏポート１１８は、コンピューティングデバイス１００が、その一部は組み込むことができる、Ｉ／Ｏコンポーネント１２０を含む他のデバイスに論理的に結合されることを可能にする。説明のためのコンポーネントは、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送アンテナ、スキャナー、プリンタ、無線デバイスなどを含む。
ブートストラッププロセスのフェーズ
[0028]ハードウェアのインベントリーとデータセンターのクラウド・コンピューティング・ファブリックとの間に相互運用を確立するためのブートストラッププロセスの個々のフェーズについて、ここで図２に関して記述する。一般的に、図２は、本発明の実施形態による、データセンターのファブリックにハードウェアインベントリーを組み込むためのブートストラッププロセスの５つの代表的なフェーズを示す流れ図２００を示している。実施形態では、以下に記述するフェーズを使用して、ファブリック・コンピューティング・クラスター（ＦＣＣ）としてハードウェアインベントリーを構築することは、ユーザーデバイス（図３の参照番号３１０を参照）の構成ソフトウェア（図３の参照番号３１１を参照）によって実施することができる。ハードウェアインベントリー、データセンター、および／または他のネットワークデバイスとともにユーザーデバイスは、ブートストラッププロセスの１つまたは複数のフェーズをそれぞれ実装する様々なエコシステムを形成するように協調して動作する。

[0029]図２に戻ると、ブロック２１０に描写したように、ブートストラッププロセスの第１のフェーズは、ハードウェアインベントリーの初期セットアップを指定するためのワークフローを含む。一般的に、ワークフローの結果として、ブロック２３０と２４０との間にファブリックネットワークを展開するために必要な論理的／物理的な構成を生成することになる。第１のフェーズの間に、ワークフローは、データセンターのＦＣＣとしてハードウェアインベントリーを解放する前に、ハードウェアインベントリーの初期構成を理解することを含むことができる。たとえば、第１のフェーズのワークフローは、ハードウェアインベントリーの初期構成を検証することを試みて、それが予測されるハードウェア配置（たとえばデバイスの場所、ＩＰアドレス、ＶＬＡＮ、および配線）に対応していることを保証し、それがデータセンターによって実施された特定の規制（たとえば、フラグを付けられた安全でないコンポーネントがなく、望ましい通信コンポーネントが存在する）を満たすことを保証する。

[0030]代表的な実施形態では、第１のフェーズのワークフローは、最初の論理的なリソースおよびそれらのリソースの適切な仕様が、サポートされている構成に一致することを検証することに関係する。検証の１つの実例として、そこで構成で提供される十分なネットワークリソース（たとえばＩＰアドレス、ＶＬＡＮ、ポートなど）が、仕様によって明記された望まれる構成と一致するかどうかを決定することを含むことができる。たとえば、第１のフェーズのワークフローは、そのような条件が仕様内に存在する場合、少なくとも１つのＩＰアドレスがマシンごとに提供されることを検証することができる。

[0031]検証の他の実例は、既知の既存する範囲との構成の重複が存在するかどうかを決定することを含むことができる（たとえば、現在使用されている偶然に提供されたリソース）。しかし、検証の他の実例は、計画されたリソースの組がサポートされている構成の構成要素となるかどうかを決定することを含むことができる（たとえば、仕様を満たすのにそれぞれ必要なリソースが十分になるか、これらのタイプのリソースの組み合わせはサポートされているか、検出されたＴＯＲスイッチは、検出されたブレードと互換性があるか）。さらに検証の他の実例は、実行に必要なリソースを収集ために（たとえば、パスワード、アドレス、ＩＰブロック、ＶＬＡＮなど）、エンドユーザー／顧客との対話が必要かどうかを決定することを含む。

[0032]ブロック２２０に描写したように、検出の第２のフェーズ、ネットワークデバイスの検証、および配線チェックは、ハードウェアインベントリーに実装することができる。実施形態では、第２のフェーズのワークフローは、それぞれシリアルベースの接続およびネットワークベースの接続を介して、ラック上部（ＴＯＲ）のスイッチおよびネットワークデバイスのシリアルアクセスデバイスと通信することを含むことができる。さらに、第２のフェーズのワークフローは、接続の１つまたは複数を通じて、分析のためにユーザーデバイスにトラフィックを送信することをハードウェアデバイス（たとえばプロセッサー、処理ユニット、コンピューティングデバイス、サーバー、およびラックに挿入されたブレード）が選択的に引き起こすように、ＴＯＲスイッチおよび／またはシリアルアクセスデバイスを促す命令を送信することを含むことができ、それらの状態をリセットするために選択的にデバイスの電源を入れ直すための配電器（ＰＤＵ）の使用を含むことができる。この分析は、ブロック２３０に描写したように、ハードウェアデバイスを検出および検証することを含むことができる。すなわち、ブートストラッププロセスの第３のフェーズは、ハードウェアデバイスからユーザーデバイスに運ばれるデータパケットを用いる。第３のフェーズのワークフローは、ハードウェアデバイスの場所または不在、構成、およびハードウェアデバイスへの内部接続を決定するために、データパケットのコンテンツ（たとえばペイロードおよびヘッダー）を解析することを含むことができる。

[0033]実施形態では、第３のフェーズのワークフローは、また、デバイス／ブレード自体内で、ハードウェアおよび／またはソフトウェアのコンポーネント（たとえばＢＩＯＳおよびデバイスファームウェア）の検証、更新、および／または構成を実行するために、様々なデバイスおよび／またはブレードに、特定のワークフロー、ツールなどを送信することができる。他の実施形態では、第３のフェーズのワークフローは、デバイス／ブレードとともにコンポーネントが機能し、ファブリック要件を満たすことを検証する役割を果たす「スモークテスト」を実行することができる。さらに、第３のフェーズのワークフローは、記録および最終的な使用のために、デバイス／ブレードのモデル、製造者、およびファームウェアバージョンを識別することができる。

[0034]ブロック２４０に描写したように、ブートストラッププロセスの第４のフェーズは、データセンターのファブリック内でＦＣＣインスタンスとしてインベントリーを展開させることを含む。代表的な一実施形態では、第４のフェーズのワークフローは、（たとえば、以前のフェーズの少なくとも１つの間に生成された）ハードウェアインベントリーのインフラストラクチャー状態をファブリックと共有することと、ハードウェアインベントリーに、ファブリックとの対話を可能にするサービスをインストールすることとを含むことができる。ハードウェアインベントリーにサービスを設置することは、以下の項に記述した複数のシナリオの１つに対応することができる。ブロック２５０に描写したように、ブートストラッププロセスの第５のフェーズは、ＦＣＣインスタンスとして指定されたら、ハードウェアインベントリーへのセキュリティ措置のクラスター全体の検証と供給を含む。代表的な一実施形態では、第５のフェーズのワークフローは、新しいＦＣＣインスタンスに関連するシークレットストアとファブリックのコントローラーとの間で、データ（たとえばデバイス資格情報、オリジナル証明書、秘密キー、およびパスワード）を渡すことを含むことができる。

[0035]ブートストラッププロセスの個別の５つのフェーズについて記述したが、データセンターのファブリック内でハードウェアインベントリーの組み込みを進めるのを支援するワークフローの他のタイプの適切な配置を使用できること、および本発明の実施形態は、本明細書に記述し５つのフェーズに限定されないことを理解し評価されたい。たとえば、本発明の実施形態は、個々のフェーズ（たとえばフェーズ５）のワークフローを相互に排他的な方法で実行できる個別のワークフロー（たとえばクラスター全体の検証およびセキュリティ供給）に分割することを意図する。

[0036]ハードウェアインベントリーにサービスをインストールするための複数のシナリオの例についてここで記述する。１つのシナリオでは、ハードウェアインベントリーは、データセンターには新しく、以前に構成されていない装置を表している。したがって、新しいハードウェアは、データセンターの既存のリソースと透過的に動作するように構成され、クラウド・コンピューティング・ファブリックのコントローラーによって管理される新しいＦＣＣインスタンスまたはクラウド・コンピューティング・スタンプとしてデータセンター内に正常に統合される。

[0037]他のシナリオでは、ハードウェアインベントリーは、データセンターが追加のストレージ／計算容量を要求するときに追加されるデータセンターのローカル拡張を表している。ローカル拡張は、ファブリックコントローラーによる管理を可能にするために構築するブレードのラックを含むことができる。実施形態では、構築するプロセスは、ラック内のブレードの配線パターンを検出することと、事前定義されたテンプレートファイルに対して配線パターンを検証することと、データセンターに組み込みのためにブレードを承認することとを含む。事実上、ブレードを構築することで、ラック内の潜在的な配線の課題またはハードウェアの課題（たとえば物理的欠陥、見つからないパーツ、無効なパーツのバージョン、または不適当な構成）が検出および対処されることを保証するのを支援し、それによって、データセンター内のブレードの組み込みが、そこで実行されているサービスに、データセンターによって提供されている現行の基礎的なサポートに悪影響を与えないことを保証する。

[0038]さらに他のシナリオでは、ハードウェアインベントリーは、現在、データセンターのリソースを相互結合しているファブリックから分離され区分されたクラウド・コンピューティング・ファブリックのそれ自身のインスタンスで構成される。したがって、データセンターにハードウェアインベントリーを組み込むときに、データセンターは、オリジナルのデータセンターに割り当てられたサービスから新しくブートストラップされたハードウェアインベントリーに割り当てられたサービスを分離するように機能する、少なくとも２つのクラウド・コンピューティング・ファブリック（たとえばオペレーティングシステム）を実行する。このようにして、個別のファブリックは、特定の顧客のサービスに専用することができ、それによって、データセンター内の他のもの（たとえばデータセンターコンテナの構築／ブートストラップ）から実質的かつ物理的に一部のサービスを除外／保護する。

[0039]返却製造承認（ＲＭＡ：ｒｅｔｕｒｎｍａｎｕｆａｃｔｕｒｅａｕｔｈｏｒｉｚａｔｉｏｎ）シナリオと呼ばれる、さらに他のシナリオでは、ハードウェアインベントリーは、データセンターのファブリックのコントローラー（以下「ファブリックコントローラー」）によって到達できない（たとえば動作不能または切断された）と考えられるコンピューティングデバイス（複数可）または他のデバイス（たとえばネットワーク、ＰＤＵ、およびシリアル）を表している。ハードウェアのライフサイクル管理の間に、ファブリックコントローラーは、データセンター内に集められたコンピューティングデバイス（たとえば物理的なマシンおよび／または仮想マシン）の状態を定期的に請求することができる。状態の請求は、それぞれコンピューティングデバイスで実行されているエージェントに要求を通信することと、返事として正常性の情報を受信することとを含むことができる。何らかの理由により、ファブリックコントローラーが特定のコンピューティングデバイスに到達できない場合（たとえば、ファブリックコントローラーにコンピューティングデバイスを相互連結させるネットワークデバイスに障害があるなど）、ファブリックコントローラーは、ハードウェアインベントリーに到達できないことを示す通知を発することができる。

[0040]ハードウェアインベントリーを到達不能として認識すると、ファブリックコントローラーは、自動修復手順を開始することができる。実施形態では、自動修復手順は、少なくとも退避および検証のステップを含み、ここで検証は、多くの場合、ブートストラッププロセスの１つまたは複数のフェーズ内でも実施される。退避のステップは、代わりのハードウェアインベントリーに、到達できないハードウェアインベントリーでリソースを消費するサービス（たとえば顧客が所有するアプリケーションおよびシステムベースのアプリケーション）を転送することを含む場合がある。したがって、それらのサービスへの可視性は、検証および維持の間に影響を受けないため、退避により、自動修復手順がデータセンターの顧客に透過的であることが保証される。

[0041]退避が正しく実行されたら、検証のステップが呼び出される。代表的な一実施形態では、検証のステップは、到達できないハードウェアインベントリー内に存在するコンポーネントの構成設定を検証し、到達できないハードウェアインベントリーの検出された物理的なトポロジー（たとえばコンポーネントとびデバイス間の配線との間のリンク）を到達できないハードウェアインベントリーの予測された物理的なトポロジー（たとえば、テンプレートファイル内に提供）に対して相互参照するブートストラッププロセスのワークフローを実施することを含む。したがって、検証のステップは、到達できないハードウェアインベントリーが、ファブリックコントローラーのドライバーと対話するように適切に構成されているかどうかを決定し、ここでドライバーは、特定のハードウェア構成と対話するように設計されている。

[0042]以下により完全に記述するように、検証のステップは、到達できないハードウェアインベントリーをオフラインで取ることを含み、これは退避のステップを前もって行う理由である。一般的に、到達できないハードウェアインベントリーは、オフラインで取られる。その理由は、到達できないハードウェアインベントリーのデバイスおよび／またはデータセンターのデバイスのサービスの実行を中断するであろう複数の破壊的な動作が発生するためである。これらの破壊的な動作は、そこに（ＰＤＵを介して）電力を選択的に駆動するようにシリアルアクセスデバイスに要求することによって、ブレードへの電力の流れを操作することと（たとえばオンおよびオフ）、操作されたブレードから送信されたトラフィックから情報を収集することと、トラフィック内で送信されたデータパケットのコンテンツから情報（たとえばブレードのＭＡＣアドレス）を抽出することと、抽出された情報をテンプレートファイルに対して評価し、検証を実行することによって、ブレードの場所および配線を検証することとの１つまたは複数を含むことができる。シリアルアクセスデバイスは、典型的に、帯域外通信に使用される一方、ＴＯＲスイッチは、（たとえばイーサネット（登録商標）を介して）帯域内通信を用いることに注意されたい。

[0043]ブレードに選択的に電力を駆動する例では、ファブリックコントローラーは、未知／無効なハードウェアインベントリーのブレードに供給するポートの範囲への電力をオフにすることができる。次に、ファブリックコントローラーは、対象となるブレードにリンクする選択されたポートへの電力をオンにするように、直接的または間接的にＰＤＵに指示することができる。次に、ファブリックコントローラーは、現在、トラフィックを送信している対象となるブレードから送信されているデータパケットからＭＡＣアドレスを読み込むことができる。したがって、選択されたポートがテンプレートファイルの予測されたポートに対応する場合、対象となるブレードの接続性が検証される。ＰＤＵから電力を受信するために選択されたポートを検証することに加えて、検証のステップは、未知のハードウェアインベントリーのブレードに割り当てられたポートの範囲内で、どのポートが対象となるブレードに接続されるかを決定できるＴＯＲスイッチをさらに含むことができる。この決定は、対象となるブレードから伝達されているデータパケットを受信しているポート範囲の対象となるポートを識別することによってなされる。
共同編集フェーズのワークフロー
[0044]共同編集フェーズ（図２のブロック２１０を参照）のワークフローは、ハードウェアインベントリーのオリジナルセットアップを指定することを促進し、その結果、検証の間に調べられるテンプレートファイルを生成する。最初に、相手先商標製造会社（ＯＥＭ）は、ハードウェアインベントリーを出荷する前に、（たとえば物品に対する契約の一部として）デバイス間の配線を検証することが予測される。これは、図２のブロック２１０、２２０、２３０に描写した、ワークフローの最初の３つのフェーズを個々に呼び出すことによって別々に行うことができる。さらに、ＯＥＭは、ハードウェアインベントリーのデバイス内にインストールされたソフトウェアの属性を記述するマニフェストを提供するツールを用いることが予測される。配線の検証およびソフトウェア属性のマニフェストは、適切なハードウェアインベントリーの選択を支援するために、ハードウェアインベントリーと関連して維持される。一部の実施形態では、ＯＥＭは、ハードウェアインベントリーをゼロ構成に設定することができる。

[0045]共同編集フェーズのワークフローの操作では、ハードウェアインベントリーの命令は、ストレージ／計算容量の不足を改善するために、自動的または管理者による手作業で開始することができる。１つの実例では、命令を開始することは、容量不足を満たすことを目標とする１組の装置（たとえばデバイス、ラック、およびソフトウェア）に関係する特定でないデータを用いてフォーム（たとえばＸＭＬ文書）を生成することを含む。予備値は、フォームに自動的または管理者による手作業で入力することができ、ここで予備値は、データセンター特定の詳細（たとえばＶＬＡＮの範囲、ポート範囲、およびＩＰアドレス）または顧客に規定されたトポロジースキーマを反映する。トポロジースキーマは、ハードウェアインベントリーのハードウェアデバイスおよびネットワークデバイスのタイプ、量、および配線パターンを規定し、デバイスを実行するために使用される追加情報を示す（たとえば、ラックの数、ＶＬＡＮの範囲、ポートの数、およびサポートするリソース）。

[0046]値を入力すると、フォームは記号表現に変換することができる。記号表現は、装置（たとえばデバイス）およびその間のルーティング（たとえば配線）の高レベルの論理的な青写真としての役割を果たす。たとえば、記号表現は、装置のどの部分が共通のＶＬＡＮ内にグループ化されているかを示すことができる。

[0047]記号表現は、シナリオに基づいて、適切なハードウェアインベントリーを選択するために、ＯＥＭ、顧客、または管理者に送信することができる。１つの実例では、適切なハードウェアインベントリーの選択は、配線の検証および／またはＯＥＭでハードウェアインベントリーに関連して維持されるソフトウェア属性マニフェストに対して記号表現を比較することを含む。適切なハードウェアインベントリーを選択すると、選択されたハードウェアインベントリーは、顧客または管理者によってＯＥＭに提供される軽量のソフトウェアを使用してチェックすることができる。実施形態では、軽量のソフトウェアも、データセンターへのハードウェアインベントリーの到着時に、配達ドックで実行することができ、これはＯＥＭのハンドオフ前に発生する。この早期のチェックでは、移送の間にハードウェアインベントリーに持ち込まれた課題を検出することができる。

[0048]一般的に、軽量のソフトウェアは、それらのデバイスのＩＰまたはＭＡＣアドレスを知らずに、ハードウェアインベントリーデバイスで実行できる１組のタスクを実行する。動作において、軽量のソフトウェアは、出荷前にＯＥＭでオンサイトで物理的な配線を検証し、ここで検証では、選択が適切であることを保証するために記号表現を調べる。場合によっては、軽量のソフトウェア検証は、グローバルにアクセス可能なＩＰアドレスが必要ないように変更されたネットワークチェックを用いて、図２のブロック２２０および２３０に描写したフェーズの代替実装として使用することができる。

[0049]ＯＥＭから出荷した後、管理者は、デバイスおよびデバイスの配線が、ハードウェアインベントリーの配達を受け取るときに記号表現を満たしていることを視覚的に検証することができる。さらに、管理者は、ハードウェアインベントリーの配線（たとえばシリアルおよびネットワークケーブルの接続）を視覚的に検査し、検査に基づいてハードウェアインベントリーの実際の値（たとえばポート番号、ＩＰアドレス、ＶＬＡＮメンバーシップ、およびデバイスの場所）を決定し、記号表現内に入力された予備値を実際の値と交換／変換することができる。管理者による手作業の検査に加えて、ネットワークデバイスのデバイスドライバーが利用可能な場合、検査を自動化することができ、ここで自動化は、記号表現の仕様に従ってネットワークデバイスを構成するために使用することができる。伝達されたハードウェアインベントリーから調べ出された実際の値に交換または変換された予備値を用いるこの記号表現は、本明細書において「テンプレートファイル」と呼ばれる。以下により完全に記述するように、テンプレートファイルは、ユーザーデバイスがハードウェアインベントリーにどのように接続されるかを示し、かつハードウェアインベントリーが適切に構成されていることを保証するために、ブートストラッププロセスの次のフェーズで使用される。
検証エコシステムの構造
[0050]ハードウェアのインベントリーのネットワークデバイスおよびハードウェアデバイスを検出、検証、および構成する検証エコシステムの構造について、ここで図３および図４に関して説明する。一般的に、図３は、ハードウェアインベントリー３６０の第１のタイプのトポロジーを検出、検証、および構成するための検証エコシステム３００を示す図を表している一方、図４は、ハードウェアインベントリー３６０の第２のタイプのトポロジーを検出、検証、および構成するための検証エコシステム４００を示す図を表している。

[0051]最初に、図３を参照すると、検証エコシステム３００は、ハードウェアインベントリー３６０のコンポーネントと通信できるように結合されたユーザーデバイス３１０を含む。代表的な一実施形態では、通信に関する結合は、少なくともネットワークベースの接続およびシリアルベースの接続へと整理される。図３に示すように、シリアルベースの接続は、シリアルアグリゲーター３２０を介して、ユーザーデバイス３１０とシリアルアクセスデバイス３６１および３６２との間に通信路を含み、ここでシリアルアグリゲーター３２０は、（たとえば、ユーザーデバイス３１０からデータパケットのストリーム内で運ばれるアドレスを処理することによって）ユーザーデバイス３１０から適切なシリアルアクセスデバイスに適切に指示を配布することを担当する。ネットワークベースの接続は、Ｌ３アグリゲータースイッチ３３０を介して、ユーザーデバイス３１０とラック上部（ＴＯＲ）のスイッチ３５０、３５１、および３５２との間の通信路を含み、ここでアクセスルーター３４０とは対照的に、Ｌ３アグリゲータースイッチ３３０は、ＴＯＲスイッチ３５０、３５１、および３５２からユーザーデバイス３１０にデータパケットを適切に伝達することを担当する（たとえば、複数のネットワークデバイスからデータパケットを集める）。シリアルアグリゲーター３２０を介して、ＴＯＲスイッチ３５０、３５１、および３５２との通信を行えることに注意されたい。動作において、アクセスルーター３４０は、既存のインフラストラクチャーとハードウェアインベントリー３６０との間のアップリンクとして機能する。したがって、図３に示すように相互運用可能である場合、アクセスルーター３４０は、インターネットとともに、既存のインフラストラクチャーの残りからハードウェアインベントリー３６０を分離する役割を果たす。以下により完全に記述するように、アップリンクを通じて入る、または出て行くブロードキャストトラフィックがないことを保証することによって、アクセスルーター３４０は、現在、既存のインフラストラクチャーで実行されている外部サービスへの影響も打ち消すのを支援する。

[0052]このようにして、構築されるハードウェアインベントリー３６０と既存のインフラストラクチャー（たとえばデータセンター５５０）との間の適切な分離を保証するために、検証エコシステム３００は、ユーザーデバイス３１０とハードウェアインベントリー３６０との間の相互通信にメッセージングを限定する自己完結型の方法で動作する。この分離は、外部干渉を限定することによってブートストラッププロセスの間により高い信頼性を提供することと、既存のインフラストラクチャー内で現在機能しているハードウェアが、ブートストラッププロセスによって影響を受けないことを保証することと、という少なくとも２つの点で役に立つ。実施形態では、分離は、既存のインフラストラクチャーおよびハードウェアインベントリー３６０を切り離す仮想レイヤーとしての役割を果たすセキュリティ境界として構成され、これはフェーズのそれぞれが成功するまで、信頼されるものとして考えることができない。したがって、ブートストラッププロセス自身は、一般的に、セキュリティ資格情報／トークンがセットアップされるブートストラッププロセスの最終フェーズの間（検証および供給のフェーズの前）に、既存のインフラストラクチャーのセキュリティコンテキストに依存しない。

[0053]検証エコシステム３００の構成について、ここで説明する。最初に、エコシステム３００は、ハードウェアインベントリー３６０内のラック３０１、３０２、および３０３にリンクし、その機能を制御するために、ユーザーデバイス３１０を含む。ラック３０１（たとえば高密度ラック）に関して、１つまたは複数の配電器（ＰＤＵ）３８１および３８２、演算装置（たとえばブレード３７１〜３７４）、およびネットワークデバイスが存在する（たとえば、ＴＯＲスイッチ３５０、上部シリアルアクセスデバイス３６１、および下部シリアルアクセスデバイス３６２）。ラックごとに追加的なＴＯＲスイッチがある場合があることに注意されたい（たとえば、上部および下部のＴＯＲデバイス）。コンピューティングデバイス３７１〜３７４は、計算／ストレージのタスクを実施するためのプロセッサーとして設計されており、ＯＥＭによって、それぞれ電力の受信時にデータパケットを生成するように構成されている一方、ＰＤＵは、コンピューティングデバイス３７１〜３７４に選択的に電力を供給するように設計されている。ＴＯＲスイッチ３５０は、ネットワークベースの接続を通じてデータパケットを送信するために構成されている一方、シリアルアクセスデバイス３６１および３６２は、シリアルベースの接続を通じて指示の受信時にデータパケットの生成を引き起こすように構成されている。実施形態では、シリアルアクセスデバイス３６２は、ラック内のデバイスを構成するために使用することができる（たとえば、ＰＤＵ、ＴＯＲスイッチ、およびブレード）。

[0054]ユーザーデバイス３１０は、ブートストラッププロセスの少なくとも最初のフェーズを駆動するように設計されている構成ソフトウェア３１１を含む。構成ソフトウェア３１１は、ネットワークベースの接続（帯域内チャネル）を介してＴＯＲスイッチ３５０に、およびシリアルベースの接続（帯域外チャネル）を介してシリアルアクセスデバイス３６１および３６２に通信するように結合される。実施形態では、ブートストラッププロセスの最初のフェーズは、ネットワークデバイス（ＴＯＲスイッチ３５０、ならびにシリアルアクセスデバイス３６１および３６２）および１組のブレード（演算装置３７１〜３７４）を検出することと、ラック３０１の物理的なトポロジーを記述するテンプレートファイル３１２に対して、データパケット内で運ばれた情報を比較することによって、１組のブレードの場所を検証することとを含む。上記のように、テンプレートファイル３１２は、ハードウェアインベントリー３６０の最初のセットアップの指定のフェーズを完了するときに生成される。シリアルアクセスデバイス３６１および３６２は、構成ソフトウェアから指示を受信するようにさらに構成され、指示を処理すると、それぞれＰＤＵ３８１および３８２を制御する。１つの実例では、ＰＤＵ３８１および３８２を制御することは、そこに指示を伝達することを含む。指示を受信し読み込むときに、ＰＤＵ３８１および３８２は、コンピューティングデバイス３７１〜３７４の少なくとも１つの選択されたブレードに電力を送り、コンピューティングデバイス３７１〜３７４の少なくとも１つの選択されていないブレードに電力を与えないように構成することができる。これに応じて、選択されたブレード（複数可）は、構成ソフトウェアにルーティングされる前に、ＴＯＲスイッチ３５０、次にＬ３アグリゲータースイッチ３３０で集められたデータパケットの生成を始めることができる。他方では、選択されていないブレード（複数可）は、データパケットの送信を避ける可能性がある。したがって、構成ソフトウェアは、指示によってブレードが選択した場所と、ラック３０１内に生成されているデータパケットの発アドレスとの間の比較に応じて、ネットワークデバイス３５０、３６１、および３６２と、コンピューティングデバイス３７１〜３７４と、ＰＤＵ３８１および３８２との間の内部接続を確認することができる。さらに、コンピューティングデバイス３７１〜３７４は、シリアル出力を通じてデータをシリアルアクセスデバイス３６１および３６２に放出するように構成することができ、これらは次に、ブレードからシリアル伝導路、ならびにＰＤＵ３８１および３８２への内部接続を検証することができる。

[0055]ネットワークデバイス３５０、３６１、および３６２の様々な異なる構成について記述してきたが、メッセージを配布または集める他のタイプの適切なデバイスおよび／またはマシンを使用できること、および本発明の実施形態は、本明細書に記述したシリアルアクセスデバイス３６１および３６２、ならびにＴＯＲスイッチ３５０に限定されないことを理解し評価されたい。たとえば、単一のシリアルアクセスデバイスをラック３０１全体に提供することができ、ここでシリアルアクセスデバイスは、ＰＤＵ３８１および３８２へのシリアル接続／インターフェースとして機能し、ブレードのそれぞれへのシリアル接続／インターフェースとして機能する。他の実例では、シリアルアクセスデバイスおよびＰＤＵは、単一デバイスへと組み合わせることができる。さらに他の実例では、ＴＯＲスイッチ３５０は、イーサネット（登録商標）インターフェース機能を持つ専門化されたブレードと交換することができる。したがって、検出および実証のフェーズは、任意の数のネットワークデバイスを使用して実施することができるため、少なくとも１つのネットワークデバイスは、ネットワーク通信のための帯域内機能を含み、少なくとも１つのネットワークデバイスは、シリアル通信のための帯域外機能を含む。または、帯域外機能がイーサネット（登録商標）を通じて用いられる場合、第２のネットワークスイッチをシリアルデバイスの代わりに使用することができる。このようにして、帯域内機能は帯域外機能を補足し、機能の１つがオフラインになった場合に、コンピューティングデバイス３７１〜３７４へのアクセスを継続するだけでなく、ネットワークデバイスのデバッグおよび診断を可能にする。

[0056]当業者は、図３に示したエコシステム３００は、単にブートストラッププロセスのフェーズを実施するための環境の１つの適切な部分の例であり、本発明の実施形態の使用または機能の範囲に関して限定を示唆することを意図しないことを理解し評価されるだろう。また、エコシステム３００は、そこに図示した単一のリソースまたはリソースの組み合わせに関係する依存関係または要件を持つものと解釈されるべきでない。さらに、図３の様々なブロックは明瞭さのための線で示しているが、実際には、様々なコンポーネントの線引きはそれほど明瞭ではなく比喩的なものであり、線はより正確には灰色で曖昧である。

[0057]ハードウェアインベントリー３６０は、シリアルベースの接続および／またはネットワークベースの接続を介してユーザーデバイス３１０に相互連結された様々な装置／リソースを含む。この装置／リソースは、本明細書に記述したように、（たとえば、ネットワークデバイスにインストールされた）ソフトウェアコンポーネントだけでなく、ラック３０１、３０２、および３０３、ならびにユーザーデバイス３１０など、有形のハードウェア要素を含むことができる。装置／リソースは、様々な物理的なリソースを横断して分配できるように配置できるため、ユーザーデバイス３１０は、その間に通信を確立するために、検出および検証のフェーズを通じて装置／リソースの場所を認識することができる（図２の参照番号２２０および２３０を参照）。さらに、装置／リソース、およびブートストラッププロセスによって必要とされる他の要素を接続するチャネルを通じてこの通信を促進するネットワーク（図示せず）を提供することができる。ネットワークは、限定することなく、１つまたは複数のローカル・エリア・ネットワーク（ＬＡＮ）および／またはワイド・エリア・ネットワーク（ＷＡＮ）を含むことができる。そのようなネットワーキング環境は、オフィス、企業規模のコンピューターネットワーク、イントラネット、およびインターネットではありふれている。したがって、ネットワークについて、本明細書にはこれ以上は記述しない。

[0058]エコシステム３００の代表的なシステムアーキテクチャーは、ユーザーデバイス３１０およびコンピューティングデバイス３７１〜３７４を含む。図３および４に示した、これらのデバイス３１０および３７１〜３７４のそれぞれは、たとえば、図１に関して上に記述したコンピューティングデバイス１００など、様々なタイプのコンピューティングデバイスの形を取ることができる。限定を目的とせずに例を挙げると、デバイス３１０および３７１〜３７４は、パーソナルコンピューター、デスクトップコンピューター、ラップトップ型コンピューター、家庭用電子機器、ハンドヘルドデバイス（たとえば携帯情報端末）、様々なサーバー、ブレードなどの場合がある。しかし、本発明は、そのようなコンピューティングデバイスへの実装に限定されず、本発明の実施形態の範囲内にある様々な異なるタイプのコンピューティングデバイスのいずれにも実装できることに注意されたい。

[0059]典型的には、デバイス３１０および３７１〜３７４のそれぞれは、そこで実行されているコンポーネント（複数可）の動作をサポートするために何らかの形の演算装置（たとえば中央制御装置、マイクロプロセッサーなど）を含むか、またはそれにリンクされている（たとえば、信号の受信時または電源を供給されるときの発信元のデータパケット）。本明細書で利用する場合、「演算装置（ｃｏｍｐｕｔｉｎｇｕｎｉｔ）」という語句は、一般的に、処理能力および記憶装置を備える専用のコンピューティングデバイスを表し、これはそこにソフトウェア、アプリケーション、およびコンピュータープログラムの実行の基礎となるオペレーティングソフトをサポートする。１つの実例では、演算装置は、各デバイスが通信関連のプロセスおよび他の操作を実行することを可能にするために、デバイス３１０および３７１〜３７４に一体型か、または操作可能なように結合された有形のハードウェア要素、またはマシンで構成される。他の実例では、演算装置は、デバイス３１０および３７１〜３７４のそれぞれによって収められたコンピューター可読媒体に結合されたプロセッサー（図示せず）を包含することができる。一般的に、コンピューター可読媒体は、少なくとも一時的に、プロセッサーによって実行可能な複数のコンピューター・ソフトウェア・コンポーネントを格納する。本明細書で利用する場合、「プロセッサー（ｐｒｏｃｅｓｓｏｒ）」という用語は、限定することを目的とするものではなく、計算容量内で動作する演算装置の任意の要素を包含することができる。そのような容量において、プロセッサーは、指示を処理する有形の物品として構成することができる。代表的な一実施形態では、処理は、指示のフェッチ、復号／解釈、実行、および書き戻しを含むことができる（たとえば、動きパターンのアニメーションを提示することによって物理的なジェスチャーを再構築する）。

[0060]また、処理の指示以外に、プロセッサーは、デバイス３１０および３７１〜３７４と一体型、またはそこに配置された他のリソースとの間で情報を双方向に転送することができる。一般的に、リソースは、デバイス３１０および３７１〜３７４が特定の機能を実行することを可能にするソフトウェアおよびハードウェアのメカニズムを表している。例示のみを目的として、リソースは、構成ソフトウェア３１１と、テンプレートファイル３１２と、コンピューティングデバイス３７１〜３７４内に存在するコンポーネントと、というメカニズムの１つまたは複数を含むことができる。

[0061]ネットワークデバイス３５０、３６１、および３６２を検出および検証するための代表的なワークフロー、およびエコシステム３００内のコンピューティングデバイス３７１〜３７４（たとえばブレード１〜４）について、ここで図３に関して記述する。最初に、構成ソフトウェア３１１は、シリアルベースの接続のシリアルアグリゲーター３２０を介して、ハードウェアインベントリー３６０へのアクセスを獲得することを試みる。アクセスを獲得したら、ハードウェアインベントリー３６０のシリアルアクセスデバイス（たとえばシリアルアクセスデバイス３６１および３６２）にリンクされたシリアルアグリゲーター３２０のポートの識別が行われる。次に、シリアルアクセスデバイス３６１および３６２を検出するために、信号は識別されたポートからシリアルベースの接続を通じて送信される。検出されたシリアルアクセスデバイス３６１および３６２から抽出された情報は、テンプレートファイル３１２に対して相互参照される。上により完全に記述したように、テンプレートファイル３１２は、予測されるデバイス（たとえばデバイス３５０、３６１、３６２、および３７１〜３７４）の青写真を表すトポロジースキーマおよびその間の予測される配線、ならびにコンピューティングデバイス３７１〜３７４それぞれの中に存在することが予測されるコンポーネントを規定するハードウェアスキーマを含む。

[0062]シリアルアクセスデバイス３６１および３６２がシリアルアグリゲーター３２０を介して適切に接続されているものと検出すると、構成ソフトウェア３１１は、シリアルアクセスデバイス３６１および３６２にシリアルベースの接続を通じて指示を配布することができる。配布された指示は、シリアルアクセスデバイス３６１および３６２によって処理されると、ラック３０１の内部結合を介して、構成ソフトウェア３１１がＴＯＲスイッチ３５０ならびにＰＤＵ３８１および３８２にアクセスすることを可能にする。ＰＤＵ３８１および３８２に到達すると、構成ソフトウェア３１１は、電力を選択的に制御する指示をコンピューティングデバイス３７１〜３７４に提供することができる。実施形態では、シリアルアクセスデバイス３６１および３６２ならびにＰＤＵ３８１および３８２を制御する前に、構成ソフトウェア３１１は、デバイスを検証し、これらのデバイスのソフトウェアを検証することができ（たとえば、ファームウェアおよびＯＳがサポートされているバージョンであることを保証する）、ファブリックによって必要とされる仕様（複数可）に対してこれらのデバイスを構成できることに注意するべきである。

[0063]たとえば、選択的に電力を制御することは、コンピューティングデバイス３７１〜３７４のそれぞれへの電源をオフにすることと、テンプレートファイル３１２に記載されたコンピューティングデバイス３７１〜３７４の１つまたは複数を対象とすることと、対象とされたコンピューティングデバイス（複数可）への電源をオンにすることとを含むことができる。対象とされるコンピューティングデバイス（複数可）に電力が供給されると、データパケットが生成され、対象とされるコンピューティングデバイス（複数可）から送信することができる。次に、データパケットはＴＯＲスイッチ３５０に集められ、これはコンピューティングデバイス３７１〜３７４からデータパケットを受信するために割り当てられたポートの範囲をスキャンし、実際にデータパケットを受信しているポート範囲からポート（複数可）を識別することができる。また、ＴＯＲスイッチ３５０は、以前にそこに割り当てられたアドレス（たとえばＭＡＣアドレスまたはＩＰアドレス）を識別することができる。この情報を収集すると、ＴＯＲスイッチ３５０は、ネットワークベースの接続を通じてＬ３アグリゲータースイッチ３３０を介して、構成ソフトウェア３１１にそれらをルーティングして戻す前に、識別されたポート（複数可）および／または識別されたアドレスをデータパケットに添付することができる。

[0064]構成ソフトウェア３１１は、ハードウェアインベントリー３６０から送信されているトラフィックの流れからデータパケットをキャプチャーするように設計されている。さらに、構成ソフトウェア３１１は、コンピューティングデバイス３７１〜３７４を検証するように設計されている。検証は、データパケット内で運ばれる情報を抽出するステップと（たとえば、対象となるコンピューティングデバイス（複数可）およびＴＯＲスイッチ３５０のアドレス、ならびに対象となるコンピューティングデバイス（複数可）に内部的に結合されていると識別されたＴＯＲスイッチ３５０、ならびにシリアルアクセスデバイス３６１および３６２のポート）、アドレスおよび内部結合がトポロジー方式と一致することを確認するために、テンプレートファイル３１２に対して、抽出された情報を比較するステップとの１つまたは複数を含むことができる。

[0065]さらに、データパケットは、現在、対象となるコンピューティングデバイス（複数可）に存在するコンポーネントに適用された構成設定だけでなく、コンポーネントを認識して、構成ソフトウェア３１１を提供する情報を伝達することができる。これらの伝達された構成設定は、テンプレートファイル３１２のハードウェアスキーマ内に維持される予測された構成設定と比較することができる。伝達された構成設定が予測される構成設定に対応しない場合、対象となるコンピューティングデバイス（複数可）の再構成を促すことができる。この再構成は、シリアルアクセスデバイス３６１を介して、またはＴＯＲスイッチ３５０を通じたネットワーク接続を介して実行することができる。

[0066]ネットワークデバイスおよびハードウェアデバイスを検出および検証するための上記のステップは、反復して実行できるため、連続してデバイス３７１〜３７４、３６１、３６２、および３５０のそれぞれの場所および接続を検証するために、コンピューティングデバイス３７１〜３７４、ならびにネットワークデバイス３６１、３６２、および３５０を再帰的に対象にできることを評価して理解されたい。したがって、上記のステップを繰り返すだけで、ラック３０１の配線パターン全体を引き出すことができる。

[0067]ここで図４を参照して、エコシステム３００の基礎となるシステムアーキテクチャーの変形形態について、ここで記述する。全体的に、図４は、ハードウェアインベントリー３６０の第２のタイプのトポロジーを検出、検証、および構成するための代表的な検証エコシステム４００を示す図を示しており、検証エコシステムは、本発明の実施形態を実装するときに使用するのに適している。図示するように、シリアルアグリゲーター３２０は、シリアルベースの接続を通じて通信にルーティングするように用いられ続ける一方、図３のＬ３アグリゲータースイッチ３３０は、１つまたは複数のスパインデバイス（ｓｐｉｎｅｄｅｖｉｃｅ）４１１および４１２、ならびに少なくとも１つの統合ルーターデバイス４１０と交換される。これらのデバイス４１０〜４１２は、全体的に木型のトポロジーに整理され、木に沿って上に向かって進むと次第に接続がより少なくなる（たとえば、２つのスパインデバイス４１１および４１２は、３つのＴＯＲスイッチ３５０〜３５２の親ノードであり、１つの統合ルーターデバイス４１０の子ノードである）。動作において、この木型のトポロジーは、ラック３０１〜３０３のコンピューティングデバイス３７１〜３７４を含む、複数のデバイスから通信を集める役割を果たす。

[0068]図４のエコシステム４００のデバイス４１０〜４１２、ルーター３４０、およびＴＯＲスイッチ３５０〜３５１について、ここでより完全に記述する。スパインデバイス４１１および４１２は、デバイス間のより高速な通信を促進するために、ユーザーデバイス３１０のメッセージおよびハードウェアインベントリー３６０内の他の内部トラフィックを散開させるように構成される。一般的に、スパインデバイス４１１および４１２、ならびに他のデバイスの間のトラフィックは、ローカルに生成され、ブートストラッププロセスの最初のフェーズの間にローカルに分散される（つまり、アウトバウンドトラフィックをほとんど扱わない）。さらに、スパインデバイス４１１および４１２は、ラック３０１〜３０３の間、およびハードウェアインベントリー３６０の全体で、ローカルトラフィックを拡張および最適化するために、それぞれ複数の共通のラック３０１〜３０３に接続することができる。統合ルーターデバイス４１０はローカルトラフィックを集めるように構成され、それによって、ブートストラッププロセスの間により大きな帯域幅が可能になる。

[0069]実施形態では、ＴＯＲスイッチ３５０〜３５２は、それぞれラック３０１〜３０３内のデバイスからトラフィックを集め、それらにトラフィックを配布するように構成される。１つの実例では、ＴＯＲスイッチ３５０〜３５２は、ブートストラッププロセスの最初のセットアップフェーズの間に、ハードウェアインベントリー３６０内に確立された仮想ローカル・エリア・ネットワーク（ＶＬＡＮ）内でトラフィックをルーティングすることができるＬ３タイプ・ネットワーク・デバイスを表している。しかし、本発明の実施形態は、ＴＯＲスイッチ３５０〜３５２にサポートされた異なるレイヤーの通信を通じてトラフィックを伝えることを考える。

[0070]実施形態では、アクセスルーター３４０は、ハードウェアインベントリー３６０とユーザーデバイス３１０以外の任意の外部デバイスとの間のゲートウェイとしての役割を果たす。このようにして、アクセスルーター３４０でインバウンドおよびアウトバウンドの通信を限定することによって、ハードウェアインベントリー３６０は、展開の自己完結型ユニットとして機能する。たとえば、ハードウェアインベントリー３６０が民間企業ネットワーク内の展開のユニットを表している場合、ハードウェアインベントリー３６０は、ブートストラッププロセスの間に民間企業ネットワークのローカルサーバーと協調して（たとえばクラウド・コンピューティング・ネットワークのインスタンスとして）運用することができない。別の実施例では、ハードウェアインベントリー３６０がリモート・データ・センター内の展開のユニットを表している場合、ハードウェアインベントリー３６０は、ブートストラッププロセスの間に他のクラウド・コンピューティング・スタンプと協調して（たとえばクラウド・コンピューティング・スタンプとして）運用することができない
[0071]ハードウェアインベントリーの様々な異なる構成について記述してきたが、ストレージ／計算容量の増加を可能にする他のタイプの適切なマシンおよびマシン間のトラフィックをルーティングする適切なデバイスを使用することができ、本発明の実施形態は、本明細書に記述したエコシステム３００および４００の配置に限定されないことを理解して評価されたい。すなわち、デバイスの様々な他のタイプの物理的なトポロジーが、本発明の実施形態によって考えられるハードウェアインベントリー３６０内で使われる場合がある。トポロジーの変化に伴い、テンプレートファイル３１２はそれに対応して変えることができるため、相互参照および検証の手順は、配線の修正（ネットワークスキーマ）およびデバイスの変更（ハードウェアスキーマ）に適応させることができる。結果的に、構築される新しいハードウェアインベントリー３６０の物理的なトポロジーに修正が行われるたびに、検証コードを完全に書き直すのではなく、新しいハードウェアインベントリー３６０に基づいて、新しいテンプレートファイル３１２が単に生成される一方、手順においてネットワークデバイスおよびハードウェアデバイスを検証するためのブートストラッププロセスのフェーズは変更されない。したがって、それぞれのフェーズのワークフローを一新することなく、現在存在する様々な物理的なトポロジーだけでなく、まだ開発されていないものにもブートストラッププロセスを適用する能力のために、標準的で一様な配線およびデバイスのセットアップ以外に、ハードウェアインベントリーを構築および展開することが可能になる。

[0072]図４に示す検証エコシステム４００のハードウェアインベントリー３６０内のネットワークデバイスおよびハードウェアデバイスを検出および検証するためのブートストラッピングプロセスのフェーズ（図２００の参照番号２２０および２３０を参照）についてここで記述する。最初に、ユーザーデバイス３１０には、ハードウェアインベントリー３６０からＦＣＣをセットアップするように機能する、そこで実行されている構成ソフトウェア３１１が提供される。ユーザーデバイス３１０は、それぞれシリアルベースの接続およびネットワークベースの接続を形成するために、シリアルアグリゲーター３２０および統合ルーターデバイス４１０につながれ、ここでシリアルアグリゲーター３２０および統合ルーターデバイス４１０は、ハードウェアインベントリー３６０を構築するためにユーザーデバイス３１０の入口点としての役割を果たす。ユーザーデバイス３１０からの接続は、直接的に、またはその間の通信を可能にするためにデバイス３１０、３２０、３３０、３４０、および４１０の間のトラフィックをルーティングするための追加のネットワークデバイスを通じて実行することができる。

[0073]実施形態では、シリアルアグリゲーター３２０および統合ルーターデバイス４１０は、ゼロ構成／ゼロネットワーキング状態でＯＥＭによってセットアップされる。この場合、構成ソフトウェア３１１は、デバイス３１０と３６０との間の通信を確立することができる。または、シリアルアグリゲーター３２０および統合ルーターデバイス４１０は、適切なラック３０１〜３０３にメッセージを自動的にルーティングし、ラック３０１〜３０３から戻るトラフィックを集めるように事前構成される。したがって、ユーザーデバイス３１０をつなげることは、一般的に、ブートストラッププロセスに関係する唯一の手作業のセットアップであり、構成ソフトウェア３１１を始動することで、デバイスを自動的に検出し、応答するようにデバイスに自動的に命令するワークフローが開始する。

[0074]上記のように、テンプレートファイル３１２は、ユーザーデバイス３１０で提供されるか、またはユーザーデバイス３１０と通信するデータストアで維持される。一般的に、テンプレートファイル３１２は、ラック３０１〜３０３に組み込まれたデバイスの識別だけでなく、デバイス間の内部配線のパターンを明らかにする。１つの実例では、テンプレートファイル３１２は、コンピューティングデバイス３７１〜３７４をマッピングするために、予測された場所およびアドレスを規定するハードウェアスキーマを含む（たとえば、ＭＡＣアドレス、ＩＰアドレス、または物理的なネットワークセグメントで通信を指示するためにネットワークインターフェースに割り当てられた他の一意の識別子）。たとえば、ハードウェアスキーマは、ラック３０１がＢＬＡＤＥ_１、ＢＬＡＤＥ_２、ＢＬＡＤＥ_３、およびＢＬＡＤＥ_４（コンピューティングデバイス３７１〜３７４）として識別されたハードウェアデバイスを含むことを指定できる一方、ラック３０１〜３０３は、それぞれＴＯＲ_１、ＴＯＲ_２、およびＴＯＲ_３（ＴＯＲスイッチ３５０〜３５２）として識別されたネットワークデバイスを装備している。これはコメントである：図３において、ブロック３７３は、ＢＬＡＤＥ_３であるべきであり、ブロック３７３は、ＢＬＡＤＥ_４であるべきである。

[0075]さらに、ハードウェアスキーマは、シリアルアクセスデバイス３６１および３６２への最初のアクセスを許可するハードウェアインベントリー３６０のベンダーから資格情報のデフォルトの組でプログラムすることができる。背景として、資格情報および／またはアドレスは、ベンダーのハードウェア承認技術者が、ハードウェアインベントリー３６０内で出荷されたデバイスのバーコードをスキャンするときに、ハードウェアスキーマに入力することができる。

[0076]他の実例では、テンプレートファイル３１２は、ＴＯＲスイッチ３５０、コンピューティングデバイス３７１〜３７４、ＰＤＵ３８１および３８２、ならびにシリアルアクセスデバイス３６１および３６２の間の内部配線を規定するトポロジースキーマを含む。典型的には、トポロジースキーマは、様々な機能的なタイプ（たとえば、格納および計算）の配線を別々に指定する。代表的な実施形態では、トポロジースキーマは、シリアルベースの接続を介して、シリアルアクセスデバイス３６１および３６２との通信に割り当てられたシリアルアグリゲーター３２０内にポートの範囲を含む。また、トポロジースキーマは、ネットワークベースの接続を介して、ＴＯＲスイッチ３５０〜３５２と通信するために割り当てられたデバイス４１０〜４１２内にポートの範囲を含むことができる。さらに、実施形態では、トポロジースキーマは、正しく検証するために特定のデバイスへのリンクが生じるべき割り当てられたポート範囲内で予測されるスロットを指定する。たとえば、トポロジースキーマは、スパインデバイス４１２のポートの範囲のスロット「Ａ」が、ＴＯＲ_１（ＴＯＲスイッチ３５０）とリンクするように指定される一方、ＴＯＲ_１のポートの範囲のスロット「Ｂ」は、ＢＬＡＤＥ_２（コンピューティングデバイス３７２）とリンクするように指定されるように指定することができる。別の実施例では、トポロジースキーマは、シリアルアグリゲーター３２０のポートの範囲のスロット「Ｃ」が、上位のシリアルアクセスデバイス３６１とリンクするように指定される一方、上位のシリアルアクセスデバイス３６１のポートの範囲のスロット「Ｄ」および「Ｅ」は、それぞれＢＬＡＤＥ_２およびＰＤＵ_２（ＰＤＵ３８１）とリンクするように指定されるように指定することができる。したがって、ハードウェアおよびトポロジーのスキーマは、関連して、認知されたネットワーク通信からハードウェアデバイスおよびネットワークデバイスの物理的な場所を識別する方法を提供する。

[0077]この時点で、構成ソフトウェア３１１は、コンピューティングデバイス３７１〜３７４に電力を選択的に供給するように、ＰＤＵ３８１および３８２を制御することによって、デバイスの場所および配線の検出および検証を開始することができる。最初に、構成ソフトウェア３１１は、シリアルアクセスデバイス３６１および３６２が制御可能な方法でＰＤＵ３８１および３８２を駆動することを可能にするために、シリアルアクセスデバイス３６１および３６２の１つまたは複数に信号を送信する。説明のために、ＢＬＡＤＥ_２（コンピューティングデバイス３７２）、ＴＯＲ_１（ＴＯＲスイッチ３５０）、およびＰＤＵ_２（ＰＤＵ３８１）の検出および検証について、ブートストラッププロセスのフェーズのワークフローを示すためにここで記述する。この代表的な場合では、構成ソフトウェア３１１は、シリアルアグリゲーター３２０でポートの範囲のスロット「Ｃ」を通じて信号を送信するようにシリアルアグリゲーター３２０に指示することによって、上位のシリアルアクセスデバイス３６１に信号を向けることができる。これは、トポロジースキーマに基づいて、上位のシリアルアクセスデバイス３６１とリンクするように指定されることと認識される。

[0078]代表的な実施形態では、信号は、安全かつアクセス可能であり、法的な要件、運用上の要件、およびファブリックの要件に準拠させるために、上位のシリアルアクセスデバイス３６１内に構成設定をインストールする指示を含む。上位のシリアルアクセスデバイス３６１が構成設定を用いてセットアップされると、ＴＯＲ_１およびＰＤＵ_２も構成される。１つの実例では、ＴＯＲ_１は、ラック３０１内の内部結合を使用して、そこに構成設定をインストールするように、上位のシリアルアクセスデバイス３６１に指示することによって間接的に構成される。他の実例では、ＴＯＲ_１は、スパインデバイス４１２でポートの範囲のスロット「Ａ」を介して信号を送信するようにスパインデバイス４１２に指示するソフトウェア３１１の構成により直接的に構成され、これはトポロジースキーマに基づいてＴＯＲ_１とリンクするように指定されることと認識される。さらに、ＰＤＵ_２は、上位のシリアルアクセスデバイス３６１が信号を送信するときに、ＰＤＵ_２とリンクするように指定されているようにトポロジースキーマによって認識されたポートの範囲のスロット「Ｅ」を通じて構成設定をインストールするように構成することができる。

[0079]ラック３０１のデバイスの構成時に、ＴＯＲ_１を検出および検証することができる。実施形態では、検出および検証は、アウトバウンド・データパケットを送信するためにＴＯＲ_１を呼び出すための指示を含むメッセージを上位のシリアルアクセスデバイス３６１に送信することを含む。アウトバウンド・データパケットがスパインデバイス４１１および４１２の１つまたは複数を介してユーザーデバイス３１０で受信される場合、構成ソフトウェア３１１は、テンプレートファイル３１２に対して、上位のシリアルアクセスデバイス３６１およびＴＯＲ_１が、トポロジースキーマによって指定された予測されたスロットで適切に内部的に結合されていることを確認することができる
[0080]ＰＤＵ_２は、ＰＤＵにリンクするように指定されたポートの範囲の予測されたスロット「Ｅ」を通じてＰＤＵ_２と通信するように上位のシリアルアクセスデバイス３６１に指示することと、ＰＤＵとリンクするように割り当てられたポート範囲でスロット「Ｆ」を通じてＰＤＵ_２と通信するようにＴＯＲ_１に指示することであって、ここでスロット「Ｆ」は、トポロジースキーマに基づいてＰＤＵ_２とリンクすると予測されることと、それぞれ上位のシリアルアクセスデバイス３６１およびＴＯＲ_１によって呼び出されたコマンドを通じて（ＰＤＵ_２を介して）ラック３０１の上位部分への電力の供給を制御することを試みることと、というワークフローを使用して検出および検証することができる。適切に起動されているものとして構成ソフトウェア３１１によって電源が検出された場合、ＴＯＲ_１とＰＤＵ_２との間の内部結合（ネットワークベースの接続）だけでなく、上位のシリアルアクセスデバイス３６１とＰＤＵ_２との間の内部結合（シリアルベースの接続）も検証される。典型的には、スロット「Ｅ」および「Ｆ」は、拡張されたセキュリティ機構が供給されるか、かつ／またはそれぞれ上位のシリアルアクセスデバイス３６１およびＴＯＲ_１内のポートの範囲の他のスロットと比較して、より高い優先度レベルが割り当てられる。

[0081]ＢＬＡＤＥ_２は、そこに電力を選択的に供給するようにＰＤＵ_２を制御することによって検出および検証することができる。一般的に、電力を選択的に供給することは、ラック３０１の上位部分内に存在するコンピューティングデバイス３７１および３７２のそれぞれから電力に控えさせるようにＰＤＵ_２に指示するように上位のシリアルアクセスデバイス３６１に指示することと、電力が取り除かれたことを検証するために、ＴＯＲ／シリアルデバイスのシリアルおよび／またはネットワーク接続を通じて出力が生成されないことを保証することと、コンピューティングデバイス３７１および３７２とリンクするように指定されたポートの範囲内のスロット「Ｇ」を横断してＢＬＡＤＥ_２に電力を供給するようにＰＤＵ_２に指示することであって、ここでトポロジースキーマは、スロット「Ｇ」がＰＤＵ_２およびＢＬＡＤＥ_２を内部的に結合することを予測することと、というワークフローを含む。電力を選択的に供給するこのワークフローは、ＢＬＡＤＥ_２をトリガーし（たとえば、ＰＸＥ起動を使用）、それによりＢＬＡＤＥ_２がデータパケットを生成するようにトリガーする。

[0082]これらの起動で生成されたデータパケットはＴＯＲ_１で集められ、これはデータパケットを受信するコンピューティングデバイス３７１および３７２に割り当てられたポートの範囲内のスロットを識別する。識別されたスロット、ＴＯＲ_１のアドレス、および他の関連情報の証拠（ｉｎｄｉｃｉａ）は、データパケットのコンテンツに添付され、ユーザーデバイス３１０に戻すことができる。ユーザーデバイス３１０で添付されたデータパケットを受信すると、構成ソフトウェア３１１は、添付されたデータパケットのコンテンツを読み込み、ＢＬＡＤＥ_２の特定の属性を検証するために、テンプレートファイル３１２に対して、添付されたデータパケットから抽出された情報を相互参照することができる。たとえば、データパケット内で伝達されたＢＬＡＤＥ_２のアドレス（たとえばＭＡＣアドレス）または識別子（たとえばシリアルコード）は、それぞれＢＬＡＤＥ_２の予測される場所または予測される識別情報を検証するために、ハードウェアスキーマで予測されるアドレスまたは識別子と比較することができる。他の実例では、ＢＬＡＤＥ_２から単にデータパケットを受信することは、上位のシリアルアクセスデバイス３６１、ＢＬＡＤＥ_２、およびＰＤＵ_２の間の内部結合を確認するように機能する。さらに他の実例では、データパケットに添付された情報は、ハードウェアスキーマに対して添付された情報を相互参照するときに、ＴＯＲ_１の場所または識別情報だけでなく、ＢＬＡＤＥ_２とＴＯＲ_１との間の内部結合を確認する。また、データパケットは、予測されるシリアル接続を通じてブレードからブレードまでの出力をチェックすることによって、シリアル接続を検証するのを支援する。

[0083]構成ソフトウェア３１１が、ＢＬＡＤＥ_２の再起動を引き起こすようにＰＤＵ_２に指示するように上位のシリアルアクセスデバイス３６１に指示するときに、データパケットがユーザーデバイス３１０によって受信されない場合、構成ソフトウェア３１１は、見つからないまたは応答なしとしてＢＬＡＤＥ_２を記録することができる。上記の場合において不一致を見つけたときに、ブートストラッププロセスは、現在のフェーズ内のワークフローの次のフェーズに進むか、またはブートストラッププロセスを中断し、かつ／もしくはハードウェアインベントリー３６０を検査するために技術者に通知するアラームを発行するかを自動的に決定するように柔軟にプログラムすることができる。自動的な決定は、ブートストラッププロセスの間に発生する不一致の品質および量に基づいてもよい。一例では、検証の間に検出された誤配線の数が事前定義されたしきい値を超える場合、ユーザーデバイス３１０は、手作業で配線を修繕し、ＢＬＡＤＥ_２に関して検証を繰り返すように技術者に通知することができる。別の実施例では、誤配線の数が事前定義されたしきい値を下回ったままの場合、ユーザーデバイス３１０は、可能性として、不一致を示す警告を発行しながら、ブートストラッププロセス内で進めることができる。したがって、自動的な決定は、重要でない課題の不一致のためにブートストラッププロセスを止めないように支援することができる。しかし、見つからない上位のシリアルアクセスデバイス３６１など、重要な課題であるこれらの検出された不一致は、誤配線の数が事前定義されたしきい値を下回っている場合でも、ブートストラッププロセスの中断をトリガーする場合がある。さらに、構成ソフトウェア３１１は、予測されないデバイスは、ハードウェアスキーマによって予測されたデバイスを交換することができるか、または見つからない予測されたデバイスは、その高いレベルの品質のために絶対に存在するべきであるかどうかについて決定を行うように設計される。

[0084]さらに、構成ソフトウェア３１１が、データパケットのコンテンツを読み込み、テンプレートファイル３１２に対してデータパケットから抽出された情報を相互参照するときに、データパケットがユーザーデバイス３１０によって、しかし予測しないポートで受信された場合、構成ソフトウェア３１１は、その配線パターンに不整合性を持つものとしてＢＬＡＤＥ_２を記録することができる。この実例では、ＢＬＡＤＥ_２に関する配線パターンをチェックし、ラック３０１全体を再評価することなく、ＢＬＡＤＥ_２を独立して検証するためにワークフローを再実行するように、技術者に通知を発行することができる。

[0085]検証の間に、構成ソフトウェア３１１は、データパケットのコンテンツから、ラック３０１内のデバイスの構成をさらに収集することができる。たとえば、データパケット内のコンテンツは、ＢＬＡＤＥ_２内で供給された特定のコンポーネントは、特定のレベルのセキュリティに関連しており、特定の機能を用いてプログラムされていることを明らかにすることができる。セキュリティのレベルおよび／またはプログラムされた機能は、ＢＬＡＤＥ_２の構成が受け入れ可能かどうかを決定するために、ハードウェアスキーマに対して相互参照することができる。たとえば、ＢＬＡＤＥ_２のコンポーネントからの特定の機能がない場合、セキュリティのレベルに望ましくない妥協が生じるだろうことをデータパケットのコンテンツが示している場合、これらの不在の機能によって、アラームを引き起こされるか、またはＢＬＡＤＥ_２を再構成するように構成ソフトウェア３１１をトリガーすることができる。

[0086]実施形態では、ブランクのデバイスを再構成、または最初に構成する手順は、ブートストラッププロセスの検出および検証のフェーズの間または後に行うことができる。最初に、ネットワークデバイスおよびハードウェアデバイスのインターフェースを記述するドライバー開発キット（ＤＤＫ）を提供することができ、これを相手先商標製造会社（ＯＥＭ）は、配達前にハードウェアインベントリー３６０のネットワークデバイスおよびハードウェアデバイス内にドライバーを実装するために用いることができる。たとえば、データセンターのサービスプロバイダーは、ＯＥＭにＤＤＫを提供することができ、ここでＯＥＭは、ＤＤＫにより適切なネットワークデバイスおよびハードウェアデバイスにドライバーをインストールするように契約する。動作において、実装されたドライバーは、ネットワークデバイスとハードウェアデバイスとの間の対話を促進し、構成ソフトウェア３１１が、そこに指示を送信することによって、シリアルアクセスデバイス３６１および３６２を制御することを可能にする。

[0087]ネットワークデバイスおよびハードウェアデバイス内において、これらのドライバーだけでなく、コンポーネントの他の属性は、検証検出のフェーズの間に検査することができる。実施形態では、検査は、既に現在インストールされている場合、ネットワークデバイスおよびハードウェアデバイスにインストールされているファームウェアおよび／またはオペレーティングシステム（ＯＳ）のタイプを識別することができる。現在インストールされているファームウェアおよび／またはＯＳのタイプがテンプレートファイル３１２に関して不適切な場合、再構成手順が引き起こされる。代表的な実施例では、再構成手順は、現在インストールされているファームウェアおよび／またはＯＳを一掃することと、メンテナンスＯＳを展開させることであって、ここでメンテナンスＯＳは、迅速なインストールを可能にし、検証を達成するために、適切なドライバーおよびコンポーネントがネットワークデバイスおよびハードウェアデバイスに現れることを保証することと、というワークフローを実装することによって実施される。ブートストラップのワークフロー以外に、ファブリックは、データセンター内で実行されているサービスをサポートするために、メンテナンスＯＳを運用ＯＳに交換することを担当することができる。運用ＯＳは、データセンターのクラウドコンピューティング規制を満たすように全体的に構成されているため、ハードウェアインベントリー３６０は、クラウド・コンピューティング・ネットワークの特定のトポロジー内に透過的に統合することができる。一実施形態では、運用ＯＳの設置は、ハードウェアインベントリー３６０を展開することがスケジュールされているデータセンター内で実行されるクラウド・コンピューティング・ファブリックの属性に対応するイメージをダウンロードすることを含む。
ブートストラップエコシステムの構造
[0088]ここで図５を参照して、図３および図４のハードウェアインベントリー３６０を展開および統合するための構造およびブートストラッププロセスのフェーズ（図２の参照番号２４０を参照）についてここで記述する。全体的に、図５は、データセンター５５０のクラウド・コンピューティング・ファブリック内でハードウェアインベントリーを統合および展開するための代表的なブートストラップエコシステム５００を示す図であり、ブートストラップエコシステム５００は、本発明の実施形態を実装するときに使用するのに適している。

[0089]最初に、ネットワークデバイスおよびハードウェアデバイスに構成設定および運用ＯＳをインストールすると、より完全に上に記述したように、インフラストラクチャー状態は、図３のハードウェアインベントリー３６０の物理的なトポロジーを検証するときに収集されたデータパケットのコンテンツ内で取得された情報から準備される。本明細書で使用する場合、「インフラストラクチャー状態（ｉｎｆｒａｓｔｒｕｃｔｕｒｅｓｔａｔｅ）」という語句は、ネットワークデバイスおよびハードウェアデバイスによって現在示されているハードウェアプロパティーおよび／またはソフトウェアプロパティーを記述するのに役立つ任意のデータを広く包含することを意図するものである。特定の一例では、インフラストラクチャー状態は、ストレージ、計算、またはストレージおよび計算を組み合わせたもののユーティリィティを識別するのを支援し、ここでユーティリィティは、物理的なトポロジー（たとえば、露出度の高いブレードは、より安全な格納目的のために適切な権限を持つポートにリンクされる）、構成設定、ならびにネットワークデバイスおよびハードウェアデバイスの識別情報などの考察に基づく。したがって、インフラストラクチャー状態は、ＦＣＣスタンプに構築された場合、表面上は、ハードウェアインベントリー内にインストールされたソフトウェアのイメージ、構成設定、および運用ＯＳとしての役割を果たす。

[0090]動作において、インフラストラクチャー状態は、クラウド・コンピューティング・ファブリック内のハードウェアインベントリーを統合する場合、ユーザーデバイス３１０によって、データセンター５５０の１つまたは複数のコンポーネントと共有される。このようにして、インフラストラクチャー状態は、ファブリックコントローラーがＦＣＣインスタンスまたはクラウド・コンピューティング・スタンプとしてハードウェアインベントリーを管理することを可能にするハードウェアインベントリーの詳細を含む入力として機能する。たとえば、詳細は、ネットワークデバイスおよびハードウェアデバイスのＭＡＣアドレスまたはＩＰアドレスおよび構成、特定のデバイスの場所、デバイスとＰＤＵとの間のポート接続、ならびにＦＣＣスタンプを管理するために必要な他の情報を含むことができる。

[0091]一実施形態では、ユーザーデバイス３１０には、展開および統合のフェーズを実装するために、様々なソフトウェアが供給される。このソフトウェアは、ブートストラップ・データセンター・マネージャー（ＤＣＭ）５１０と、構成エンジン５１１と、展開エンジン５１２と、安全な場所に存在するシークレットストア５２５と通信するブートストラップ・シークレットストア（ＳＳ）５２０とを含む。ブートストラップＤＣＭ５１０は、展開および統合のフェーズのワークフローを駆動する、ネットワークデバイスおよびハードウェアデバイスを管理することができる、ファブリックコントローラーの一部を提示する。１つの実例では、ブートストラップＤＣＭ５１０は、データセンター５５０内で、構築されたハードウェアインベントリーまたは「ＦＣＣインスタンス」の追加および削除を効果的に管理する。管理は、典型的には、１つまたは複数のファブリック（たとえばマスターおよびクライアント）からの展開／調整を含む。

[0092]ＦＣＣのインスタンスの追加を管理することは、ユーザーデバイス３１０のブートストラップＤＣＭ５１０と、データセンター５５０内のサーバー５３０内のＤＣＭ５４２との間のインターフェースを提供することと、インターフェースを使用して、ブートストラップＤＣＭ５１０からＤＣＭ５４２に、ＦＣＣインスタンスのインフラストラクチャー状態（たとえばラックレベル情報）をコピーすることと、ネットワークマネージャー５４１で、最近共有されたインフラストラクチャー状態を使用して、ＦＣＣインスタンスを自己統治する能力を与えることと、というワークフローを含むことができる。マスターサービス５４０は、複数のサーバーに展開することができ、サーバー５３０の単一デバイス実装に限定されないことに注意されたい。図５に示すように、ネットワークマネージャー５４１およびＤＣＭ５４２は、マスターサービス５４０を含むことができ、これはファブリックコントローラー、バックアップサービス、ウェアハウスなど他のコンポーネントとともに、クラウド・コンピューティング・ファブリック内に新しいＦＣＣインスタンスを組み込むことを担当する。

[0093]ＦＣＣインスタンスのインフラストラクチャー状態を共有することに加えて、ブートストラップエコシステム５００は、実施形態では、ＦＣＣインスタンスにクラウド・コンピューティング・ファブリックのサービスを展開させるように設計されている。これらのサービスは、コアテナント、インフラストラクチャーテナント、および／またはプラットフォームテナントを含むことができる。１つの実例では、コアテナントは、クラウド・コンピューティング・ファブリックの全体的な機能を可能にする必須のサービスを表し、データセンター５５０内のノード間通信（たとえばドメイン・ネーム・サーバー（ＤＮＳ）機能）をサポートし、ストレージ操作を管理する。インフラストラクチャーテナントは、たとえば、データセンター５５０内に分散的にホストされた顧客のサービスアプリケーションを効率的に管理するために、クラウド・コンピューティング・スタンプを可能にする、使用可能度および利用可能度のサービスを表す。インフラストラクチャーテナントの例は、リモートに位置するアカウントで顧客のデータを見つけることをサポートするストレージの場所サービスおよび顧客がＣＴＭ５３１〜５３３と対話するためのインターフェースを提供するフロントエンドＡＰＩを含む。プラットフォームテナントは、典型的には、オプションとして顧客に提供されるサービスを表している（たとえば、データセンター５５０と民間企業ネットワークとの間をリンクするためのクラウドから建物へのアクセス）。したがって、プラットフォームテナントは、データセンター５５０の操作に必ずしも必要ではないが、インフラストラクチャー状態の定義と一致するべきである。

[0094]ＦＣＣスタンプ時のテナントの展開の間に、構成エンジン５１１および展開エンジン５１２は、それらを関与させることができる。最初に、展開エンジン５１２は、展開を開始するために呼び出すことができる。一般的に、展開エンジン５１２は、フェーズ内に内在するワークフローを達成するために使用されるツールおよびメカニズムの実行を含むブートストラッププロセスの展開および統合のフェーズのエンドツーエンドの自動化を駆動することを担当する。たとえば、ワークフローは、ＦＣＣインスタンスに構築された様々なハードウェアインベントリーの展開をスケジュールすることと、現在進行中の展開を管理することと、展開の進捗について報告すること、発生する干渉の課題に応答することとを含むことができる。多くの場合、展開エンジン５１２は、機能しているクラウド・コンピューティング・ファブリックに対して展開を実行するため、展開エンジン５１２は、機能しているファブリックに関係する課題をエスカレートさせ、時間の経過とともに展開の改善を実装するために使用可能な測定基準を収集することができる。

[0095]構成エンジン５１１は、展開時にマスターサービス５４０を構成および更新するために、データセンター５５０とインターフェースすることを担当し、それによってクラウド・コンピューティング・ファブリック内でＦＣＣスタンプを統合する。統合の実例の１つでは、構成エンジン５１１は、ハードウェアインベントリーの初期構成を記録し、ＦＣＣスタンプにハードウェアインベントリーを構築するときに構成への変更を検出し、ＦＣＣスタンプの構成に変更の履歴を提供する。一般的に、変更のこの履歴は、再構成手順の影響を示し、かつコンプライアンス基準が満たされていることを保証するために用いられる。このようにして、変更の履歴は、ＦＣＣスタンプへの構成変更の間に発生した競合または可能性がある見つからないパラメーターを明らかにすることができる。したがって、ＦＣＣスタンプは、コア、インフラストラクチャー、およびプラットフォームテナントの構成のためのレポジトリーとして機能することができる。

[0096]実施形態では、（ＦＣＣスタンプによって満たされる）追加のストレージ／計算容量に対する要求を駆動する顧客は、また、顧客のサービスアプリケーション（複数可）を適切に起動するために、ＦＣＣスタンプによって満たされる基準を概説する依存関係スキーマを提供することができる。動作において、依存関係スキーマは、顧客によって指定された前提条件を満たす方法でＦＣＣインスタンスが構築されていることを保証するために、インフラストラクチャー状態および構成における変更の履歴と比較することができる。したがって、依存関係スキーマがＦＣＣインスタンスの既知の属性によって満たされる場合、顧客のサービスアプリケーションをホストし始めるために、ＦＣＣを解放することができる。

[0097]顧客の依存関係スキーマに対して機能をチェックするために利用されるＦＣＣインスタンスの様々な異なる属性（たとえばインフラストラクチャー状態および構成における変更の履歴）について記述してきたが、展開の間に他のタイプの適切な情報をブートストラップＤＣＭ５１０とＤＣＭ５４２との間で渡すことができること、および本発明の実施形態は、本明細書に記述した特定の記事の情報に限定されないことを理解し評価されたい。たとえば、ＦＣＣインスタンスの全体的なサイズ（たとえばノードの数）および／または入口点の場所（たとえばＦＣＣインスタンスに接続する方法）は、ブートストラップＤＣＭ５１０からＤＣＭ５４２に中継することができる。機能チェックの他の実例では、マスターサービス５４０を展開させるのに十分なインベントリーを識別し、次にＦＣＣインスタンスにおける残りのハードウェアの検出、検証、および構成を駆動するためにＤＣＭ５４２を活用するために、最小限の検出および検証が行われる。さらに他の機能チェックの実例では、機能しているインベントリーに対して適切なセキュリティおよび分離を用いて、ハードウェアの検出、検証、および構成を駆動するために、既存のＤＣＭインスタンスが使用される。

[0098]ＦＣＣスタンプの展開の間に、シークレットストア５２５は、ＦＣＣスタンプに図３のハードウェアインベントリー３６０を構築するときに生成される秘密情報を提供するためにアクセスすることができる。本明細書で使用する場合、「シークレットストア」という語句は、ユーザーデバイス３１０で典型的に実行されるブートストラップＳＳ５２０とインターフェースするスタンドアロンのメカニズムを全体的に表している。このように、シークレットストア５２５は、インターネットまたは他の公にアクセス可能なネットワークに対して依存関係を持っていないため、それによってシークレットストア５２５内に格納された秘密情報のプライベートな性質が維持される。一部の実施形態では、シークレットストアは、インターネットを通じてアクセスされる中央に安全に維持された秘密のストレージの場所を表すことができる。

[0099]ＦＣＣスタンプの展開の前に、シークレットストア５２５は、最初のブートストラッププロセスのフェーズの間にハードウェアインベントリーを構築する間に、実行中に生成される秘密情報を管理するために管理ＡＰＩを用いる。この秘密情報（たとえばネットワークデバイスおよびハードウェアデバイスの資格情報、オリジナル証明書、秘密キー、シリアルアクセスデバイスのパスワード、および他の権限）は、検出および検証のフェーズの完了まで、および必要な場合は再構成手順を含めて、シークレットストア５２５に継続的に書き込まれる。展開の間に、シークレットストア５２５は、マスターサービス５４０にエキスポートするために、ブートストラップＳＳ５２０に一部の秘密情報を自動的に転送することができ、データセンター５５０の管理者が見るために非常に利便性の高い場所に他の秘密情報を転送することができる。この秘密情報は、次に、データセンター５５０内に統合されたときに問題が生じたときにＦＣＣインスタンスをデバッグするために、管理者によって使用することができる。

[00100]展開が正しく完成したとき、ブートストラッププロセスのクラスター規模の検証フェーズの前に、ＦＣＣインスタンスは、データセンター５５０内に統合することができる。図５のＣＴＭ５３１〜５３３の他の展開は、展開の完了およびマスターサービス５４０の検証のときに始めることができる。

[00101]統合は、また、ハードウェアインベントリーの構築の間に用いられる、（ネットワークデバイスおよびハードウェアデバイスにアクセスするために使用される）ローカルに生成された資格情報を新しい安全な資格情報と交換することを含むことができる。１つの実例では、資格情報の交換は、既存のノードでセキュリティトークンを作成、監査、および循環させるために既存のクラウド・コンピューティング・ファブリックのプロセスを活用することによって実行される。このようにして、ハードウェアインベントリーを構築する間に様々な関係者（たとえば、技術者、ＯＥＭ、責任者、または管理者）と共有された可能性がある構築された資格情報は、役割から解放されるため、ＦＣＣスタンプはより安全になる。統合時でさえ、ユーザーデバイス３１０は、ブートストラッププロセスが完了した後に、ファブリックインスタンス（たとえばマスターおよびクライアント）にサービスを提供するためにゲートウェイデバイスとして保持できることに注意するべきである。

[00102]展開および統合のフェーズが正しく完成すると、クラスター規模の検証のフェーズが始められる。実施形態では、正しく完了すると、展開および統合のフェーズの各前提条件のために、展開および統合のフェーズの結果として生じる出力により、次のフェーズが困難なく増加する状態にＦＣＣのインスタンスが残されることが保証される。たとえば、展開および統合のフェーズの結果として生じる出力が、オペレーターによるＦＣＣインスタンスへの十分なアクセスを許可しない場合（つまり、展開および統合のフェーズの前提条件）、次のフェーズに進む前に修正するべき問題が存在する。このようにして、展開および統合のフェーズだけでなく、他のブートストラッププロセスのフェーズは、フェーズの間に実行された操作の合計から結果として生じる出力（複数可）を自己評価するそれぞれのワークフローにステップを含む。自己評価により、ワークフローステップを繰り返させるか、または正しく完成したものとして特定のフェーズを指定できるため、それによって、次のフェーズを始めることが可能になる。

[00103]それぞれのフェーズの内部における自己評価以外に、ＦＣＣインスタンスを使用する準備ができていることを保証するために、クラスター規模の検証フェーズ（図２の参照番号２５０を参照）が実行される。実施形態では、クラスター規模の検証は、自動的に実行できるか、またはテストハーネスを介して手作業での支援を含むことができるテストの一式を実施することを含む。テストの一式は、様々な場所から様々なシステムに対して実施することができる。たとえば、テストの一式は、ＦＣＣインスタンスがＣＴＭ_１を介して内部的に到達可能かどうかを検証するように、マスターサービス５４０に指示することを含むことができる。他の実例では、テストの一式は、ＦＣＣインスタンスが外部的に到達可能かどうかを検証するように、外部エンティティ（たとえばイーサネット（登録商標）を通じた企業ネットワークまたは顧客によって要求された専門化されたエンティティ）に指示することを含むことができる。

[00104]ブートストラップエコシステム５００の代表的なシステムアーキテクチャーは、本発明の態様を実施するために実装できる適切な環境の一例に過ぎず、本発明の使用法または機能の範囲に関して制限を示唆することを意図するものではないことに注意されたい。また、図示するブートストラップエコシステム５００は、図示したコンポーネント５１０〜５１２、５２０、５４１、５４２、および５３１〜５３３の任意の１つまたは組み合わせに関係する依存関係または要件を持つものと解釈されるべきでない。一部の実施形態では、コンポーネント５１０〜５１２、５２０、５４１、５４２、および５３１〜５３３の１つまたは複数は、シークレットストア５２５と同様にスタンドアロンのデバイスとして、またはサービスもしくは実行可能ファイル（複数可）として実装することができる。他の実施形態では、コンポーネント５１０〜５１２、５２０、５４１、５４２、および５３１〜５３３の１つまたは複数は、計算するサーバー５３０および／またはユーザーデバイス３１０に直接的に統合することができる。図５に示したコンポーネント５１０〜５１２、５２０、５４１、５４２、および５３１〜５３３は、性質および数において代表的なものであり、限定するものとして解釈されるべきでないことを当業者は理解されるだろう。展開は、上記の特定のコンポーネントのいずれかがなくても、同様の機能を提供する代替プロセスによって実施できることに注意されたい。

[00105]したがって、本発明の実施形態の範囲において望まれる機能を達成するために、任意の数のコンポーネントを用いることができる。図５の様々なコンポーネントは明瞭さのために線で示しているが、実際には、様々なコンポーネントの線引きはそれほど明確ではなく比喩的なものであり、線はより正確には灰色または曖昧である。さらに、図５の一部のコンポーネントは単一のブロックとして描写されているが、描写は、性質および数において代表的なものであり、限定的なものと解釈すべきではない（たとえば、１つのＤＣＭ５４２だけを示しているが、他のハードウェアインベントリーでブートストラッププロセスを実行している他のユーザーデバイスにさらに多くを通信できるように結合することができる）。

[00106]さらに、サーバー５３０は、たとえば図１に関して上に記述したコンピューティングデバイス１００など、任意のタイプのコンピューティングデバイス（複数可）の場合がある。限定を目的とせずに例を挙げると、サーバー５３０は、パーソナルコンピューター、デスクトップコンピューター、ラップトップ型コンピューター、ハンドヘルドデバイス、携帯用ハンドセット、家庭用電子機器などの場合がある。実施形態では、データセンター５５０は、上に記載した任意の数の物理的なリソースを含むことができ、コンピューティングデバイスの任意の集合、または分散された方法で顧客のサービスアプリケーションを実行できる他のマシンを含むことができる。

[00107]さらに、上に記載した物理的なリソースの他のデバイス（複数可）は、サーバー５５０に存在するように示しているマスターサービス５４０をホストすることができる。これらの他のデバイス（複数可）は、データセンター５５０を通じて有線または無線のネットワーク経路を介してマスターサービス５４０の操作を管理することができる。しかし、本発明の実施形態は、図５に示す物理的なリソースなどへの実装に限定されず、その実施形態の範囲内にある様々な異なるタイプのコンピューティングデバイスおよび装置のいずれにも実装することができる。言い換えると、データセンター５５０の図示されたリソースは、説明目的のみを意図する代表的な構成を表しており、したがって、コンピューター業界で知られているリソースの任意の適切な配置を使用することができ、本発明によって意図するものである。
プロセスの流れ
[00108]ここで図６を参照すると、本発明の実施形態に従って、ハードウェアのインベントリーを検出および検証する全体的な方法６００を示す流れ図を示している。「ステップ（ｓｔｅｐ）」および／または「ブロック（ｂｌｏｃｋ）」という用語は、本明細書において、用いられる方法の異なる要素を暗示するために使用できるが、個々のステップの順序が明示的に記述されていない限り、および個々のステップの順序が明示的に記述されている場合という例外を除いて、これらの用語は、本明細書に開示された様々なステップの中または間において特定の順序を意味するものと解釈されるべきでない。最初に、ハードウェアインベントリーはラックを表し、ここでラックは、ネットワークデバイス（たとえばラック上部のスイッチおよびシリアルアクセスデバイス）、および１組の演算装置（たとえばラックに挿入された１組のブレード）を含むことができる。１組のブレードは、典型的には、シリアルアクセスデバイスとＴＯＲスイッチとの間で相互に連結される。

[00109]方法６００は、ブロック６１０に描写したように、ユーザーデバイスと、ハードウェアインベントリー内のシリアルアクセスデバイスまたは第２のネットワークアクセスデバイス（帯域外デバイスがシリアルデバイスではなく第２のネットワークスイッチである場合）との間の通信を開始することを含むことができる。１つの実例では、シリアルアクセスデバイスへの通信は、シリアルベースの接続を通じてユーザーデバイスによって開始される。方法６００は、ブロック６２０に描写したように、ＰＤＵに指示を送信するためにシリアルアクセスデバイスを構成することを含む。より完全に上に記述したように、ＰＤＵは、１組の演算装置に電力を選択的に供給することを全体的に担当する。したがって、シリアルアクセスデバイスから指示を受信すると、指示は、ＰＤＵに、１組の演算装置の少なくとも１つの選択された演算装置に電力を伝達させ、１組の演算装置の少なくとも１つの選択されていない演算装置に電力に控えさせる。最終的に、ブロック６３０に描写したように、選択された演算装置からユーザーデバイスで少なくとも１つのデータパケットを受信することができる。典型的には、データパケットは、選択された演算装置（複数可）から発するデータパケットを検出するように有効なラック上部のスイッチ（ＴＯＲ）とのネットワークベースの接続を介してユーザーデバイスで受信される。一実施形態では、ネットワークデバイスは、データパケットが検出されたポートを識別し、識別されたポートの証拠をデータパケットに添付するように構成される。結果的に、選択された演算装置（複数可）の場所を識別するためにデータパケットを使用する場合、ユーザーデバイスは、データパケットのペイロード内で運ばれた識別されたポートを読み込み記録することができる。さらに、ユーザーデバイスは、データパケットのヘッダー内で運ばれるインターネットプロトコル（ＩＰ）アドレスまたはメディアアクセス制御（ＭＡＣ）アドレスを読み込み記録することによって、選択された演算装置（複数可）の場所を識別することができる。選択された演算装置（複数可）のこの識別された場所は、ブロック６４０に描写したように、部分的に、ハードウェアインベントリーの物理的なトポロジーの配置を理解するために用いることができる。

[00110]代表的な実施形態では、ブロック６５０に描写したように、方法６００は、ハードウェアインベントリーの物理的なトポロジーがテンプレートファイルに対して比較可能であることを検証するために、テンプレートファイル対して、選択された演算装置（複数可）の識別された場所を相互参照することを含むことができる。一般的に、テンプレートファイルは、トポロジースキーマおよび／またはハードウェアスキーマを含むことができる。一般的に、トポロジースキーマは、選択された演算装置（複数可）の予測される場所を指定し、ハードウェアインベントリーが適切に配線されることを検証するためにユーザーデバイスによって用いられる。他方では、ハードウェアスキーマは、一般的に、どのコンポーネントが選択された演算装置（複数可）内に存在すると予測されるかを指定するために用いられる。さらに、ハードウェアスキーマは、演算装置（複数可）の内部構成を検証するために、ユーザーデバイスによって用いることができる。

[00111]ユーザーデバイスが、選択された演算装置（複数可）の場所がテンプレートファイルと一致していることを検証すると、ユーザーデバイスは、選択された演算装置（複数可）に確認設定をインストールすることを引き起こす信号を、シリアルベースの接続を通じてシリアルアクセスデバイスに送信することができる。また、ユーザーデバイスは、シリアル接続を検証するためにシリアルアクセスデバイスの出力を監視することができる。さらに、ユーザーデバイスがハードウェアインベントリーの物理的なトポロジーを検証すると、ユーザーデバイスは、ブートストラッププロセスの検出および検証のフェーズの間に収集された情報からインフラストラクチャー状態を準備することができる。ブートストラッププロセスの統合および展開のフェーズの間に、ユーザーデバイスは、データセンターのファブリック内でハードウェアインベントリーの統合を促進するために、クラウド・コンピューティング・ファブリックのコントローラーとインフラストラクチャー状態を共有することができる。また、ユーザーデバイスは、ハードウェアインベントリーでファブリックで実行されているサービスの展開をトリガーすることができ、それによって、ファブリックのＦＣＣとしてハードウェアインベントリーを指定することができる。ＦＣＣとしてハードウェアインベントリーを指定することによって、ファブリックコントローラーは、データセンターのコンテキスト内でハードウェアインベントリーを管理し見つけることが可能になる。

[00112]ここで図７を参照すると、本発明の実施形態に従って、データセンターのファブリック・コンピューティング・クラスター（ＦＣＣ）にハードウェアのインベントリーを構築するための全体的な方法７００を示す流れ図を示している。方法７００は、ブロック７１０に描写したように、ネットワークベースの接続を介してラック上部（ＴＯＲ）スイッチに、およびシリアルベースの接続を介してシリアルアクセスデバイスに、ユーザーデバイスからそれぞれの信号を送信することによってネットワークデバイス（複数可）を検出すること含む。ＴＯＲスイッチとシリアルアクセスデバイスの間で相互に連結された１組の演算装置は、ブロック７２０に描写したように、１組の演算装置に割り当てられたポートのそれぞれの範囲を介して、ＴＯＲスイッチおよびシリアルアクセスデバイスに信号をリッスンするように指示することによって検出することができる（たとえば、図３の構成ソフトウェア３１１、３１１は、必要な情報を取得するためにＴＯＲスイッチ／シリアルデバイスに問い合わせる）。

[00113]方法７００は、ブロック７３０に描写したように、ＴＯＲスイッチに再帰的にトラフィックを送信するように１組の演算装置に指示するようにシリアルアクセスデバイスを構成することをさらに含む。ブロック７４０に描写したように、ハードウェアインベントリーの物理的なトポロジーを記述するテンプレートファイルは、リモートデータストアから、またはユーザーデバイスのローカルメモリーからアクセスすることができる。１組の演算装置の場所は、ブロック７５０に描写したように、１組の演算装置から受信されたトラフィック内で運ばれた情報に対してテンプレートファイルを比較することによってそれぞれ検証することができる。インフラストラクチャー状態は、ブロック７６０に描写したように、１組の演算装置からトラフィック内で受信された情報を使用して準備することができる。ブロック７７０に描写したように、ハードウェアインベントリーは、クラウド・コンピューティング・ファブリックのコントローラーとインフラストラクチャー状態を共有することによって、データセンターのクラウド・コンピューティング・ファブリック内に統合することができる。統合と同時に、または後の時点で、クラウド・コンピューティング・ファブリックで実行されているサービスは、ハードウェアインベントリーに展開することができ（ブロック７８０を参照）、ハードウェアインベントリーは、ブロック７９０でデータセンター内のＦＣＣとして指定することができる。実例では、それが適切に展開／構成されることを保証するために、ＦＣＣスタンプとしてハードウェアインベントリーを指定する前に、検証が実行される。

[00114]本発明の実施形態について、特定の実施形態に関して記述してきたが、これらはあらゆる点において、限定ではなく説明を意図するものである。当業者には、その範囲から逸脱することなく本発明の実施形態が関係する代替実施形態が明らかになるだろう。

[00115]前述から、本発明は、システムおよび方法にとって明白かつ固有である他の利点とともに、上に記述したすべての限度および目的を達成するように十分に適応されていることが分かるだろう。特定の機能および下位の組み合わせが利用可能であり、他の機能および下位の組み合わせに関係なく用いることができることを理解されるだろう。これは特許請求の範囲によって意図するものであり、その範囲内にある。

Claims

実行された場合、ハードウェアのインベントリー(inventory)を検出(discovering)および検証する(validating)方法を実行する、１つまたは複数のコンピューター可読媒体に組み込まれたコンピューター実行可能命令を持つ当該１つまたは複数のコンピューター可読媒体であって、前記方法は、
前記ハードウェアインベントリー内のシリアルアクセス(serial-access)デバイスまたは前記ハードウェアインベントリー内の第２の帯域外(out-of-band)ネットワークに存在するネットワークスイッチデバイスとの通信を開始するステップと、
配電器（power distribution unit:ＰＤＵ）に指示を送信するためにシリアルアクセスデバイスを構成するステップであって、前記ＰＤＵは、１組の演算装置(computing units)に電力を選択的に供給することを担当し、前記指示は、ＰＤＵに、前記１組の演算装置の少なくとも１つの選択された演算装置に電力を送り、前記１組の演算装置の少なくとも１つの選択されていない演算装置に電力を控えさせる(withhold)ことを引き起こすステップであって、当該１組の演算装置が、事前にOSによってサポートされているものと、
前記少なくとも１つの選択された演算装置からデータパケットを受信するステップと、
前記ハードウェアインベントリーの物理的なトポロジー内の前記少なくとも１つの選択された演算装置の場所を識別する(identify)ために前記データパケットを使用するステップと、
前記ハードウェアインベントリーの前記物理的なトポロジーがそれに対応することを検証する(verify)ために、テンプレートファイルに対して、前記少なくとも１つの選択された演算装置の識別された(identified)場所を相互参照する(cross-referencing)ステップと
を含む１つまたは複数のコンピューター可読媒体。
前記データパケットは、前記少なくとも１つの選択された演算装置から発するデータパケットを検出するように有効なネットワークデバイスとのネットワークベースの接続を介してユーザーデバイスで受信され、前記方法は、処理されたトラフィックに関係する情報のために前記ネットワークデバイスに問い合わせるステップを含む請求項１に記載のコンピューター可読媒体。
前記シリアルアクセスデバイスへの通信は、シリアルベースの接続を通じて前記ユーザーデバイスによって開始される請求項２に記載のコンピューター可読媒体。
前記テンプレートファイルは、前記少なくとも１つの選択された演算装置の予測される場所を指定するトポロジースキーマを含み、前記ハードウェアインベントリーが適切に配線されている(wired)ことを検証するために、前記トポロジースキーマはユーザーデバイスによって用いられ、前記トポロジースキーマは、配線(wiring)ルール、デバイス構成(configuration)、またはデバイスの場所の少なくとも１つを含む請求項１に記載のコンピューター可読媒体。
前記方法は、
前記シリアルベースの接続を通じて前記ユーザーデバイスから前記シリアルアクセスデバイスに、前記少なくとも１つの選択された演算装置の場所が前記テンプレートファイルと一致している(consistent with)ことを検証すると、前記少なくとも１つの選択された演算装置に確認設定(confirmation settings)をインストールすることを引き起こす信号を送信するステップ
を含む請求項３に記載のコンピューター可読媒体。
前記方法は、前記ハードウェアインベントリーの前記物理的なトポロジーを検証するときに収集した情報からインフラストラクチャー状態を準備するステップをさらに含む請求項４に記載のコンピューター可読媒体。
前記方法は、クラウド・コンピューティング・ファブリック(fabric)のコントローラーと前記インフラストラクチャー状態を共有するステップと、
前記ハードウェアインベントリーにクラウド・コンピューティング・ファブリックのサービスを展開するステップと、
ファブリック・コンピューティング・クラスターとして前記ハードウェアインベントリーを指定するステップと
を含む請求項６に記載のコンピューター可読媒体。
データセンターのファブリック・コンピューティング・クラスター（ＦＣＣ）にハードウェアのインベントリーを構築するためのコンピューター化された方法であって、
ネットワークベースの接続を介してラック上部（top-of-rack:ＴＯＲ）スイッチに、
およびシリアルベースの接続を介してシリアルアクセスデバイスに、ユーザーデバイスからそれぞれの信号を送信することによって、１つまたは複数のネットワークデバイスを検出するステップと、
１組の演算装置に割り当てられたポートのそれぞれの範囲を介して、信号をリッスンするように前記ＴＯＲスイッチおよび前記シリアルアクセスデバイスに指示することによって、前記ＴＯＲスイッチと前記シリアルアクセスデバイスとの間で相互に連結された前記１組の演算装置を検出するステップであって、当該１組の演算装置が、事前にOSによってサポートされているものと、
前記ＴＯＲスイッチに再帰的にトラフィックを送信するように前記１組の演算装置に指示するように前記シリアルアクセスデバイスを構成するステップと、
前記ハードウェアインベントリーの物理的なトポロジーを記述するテンプレートファイルにアクセスするステップと、
前記１組の演算装置から受信された前記トラフィック内で運ばれた情報に対して前記テンプレートファイルを比較することによって、前記１組の演算装置の場所をそれぞれ検証するステップと、
前記１組の演算装置から前記トラフィック内で受信された前記情報を使用してインフラストラクチャー状態を準備するステップと、
クラウド・コンピューティング・ファブリックのコントローラーと前記インフラストラクチャー状態を共有することによって、前記データセンターの前記クラウド・コンピューティング・ファブリック内に前記ハードウェアインベントリーを統合するステップと、
前記ハードウェアインベントリーに前記クラウド・コンピューティング・ファブリックのサービスを展開するステップと、
前記データセンター内のＦＣＣとして前記ハードウェアインベントリーを指定するステップと
を含む方法。
データセンターのクラウド・コンピューティング・ファブリック内で１つまたは複数の演算装置を自動的に組み込む方法を実行するためのコンピューターシステムであって、
ラックと、
前記ラック内に存在する複数のネットワークデバイスであって、前記複数のネットワークデバイスは、
（ａ）ネットワークベースの接続を通じてデータパケットを送信するためのラック上部（ＴＯＲ）スイッチと、
（ｂ）シリアルベースの接続を通じて指示を受信するときに前記データパケットの生成を引き起こすためのシリアルアクセスデバイスと
を含む複数のネットワークデバイスと、
前記ラック内に挿入された１組のブレード(blades)であって、前記１組のブレードは、
それぞれ電力を受信するときにデータパケットを個々に生成するように構成された前記１つまたは複数の演算装置を含む１組のブレードであって、当該１組のブレードが、事前にOSによってサポートされているものと、
前記１組のブレードに電力を選択的に供給するための配電器（ＰＤＵ）と、
前記ネットワークベースの接続を介して前記ＴＯＲスイッチに、および前記シリアルベースの接続を介して前記シリアルアクセスデバイスに通信するように結合されたユーザーデバイスであって、
（ａ）前記ネットワークデバイスおよび前記１組のブレードを検出するステップと、
（ｂ）前記ラックの物理的なトポロジーを記述するテンプレートファイルに対して、前記データパケット内で運ばれた情報を比較することによって、前記１組のブレードの場所を検証するステップと
を含むブートストラッププロセスを実行するように構成されたユーザーデバイスとを含むコンピューターシステム。
前記シリアルアクセスデバイスは、前記ユーザーデバイスから指示を受信し、そこに前記指示を伝達することによって前記ＰＤＵを制御するようにさらに構成されている請求項９に記載のコンピューターシステム。