特表 2022-511242 コンピュータシステムの自動動作管理

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-01-31

(54)【発明の名称】コンピュータシステムの自動動作管理

(51)【国際特許分類】

   G06F 9/48 20060101AFI20220124BHJP

   G06F 9/445 20180101ALI20220124BHJP

【ＦＩ】

G06F9/48 300H

G06F9/445

G06F9/48 370

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2021505357

(86)(22)【出願日】2019-12-02

(85)【翻訳文提出日】2021-01-29

(86)【国際出願番号】 US2019064021

(87)【国際公開番号】W WO2020117681

(87)【国際公開日】2020-06-11

(31)【優先権主張番号】62/774,811

(32)【優先日】2018-12-03

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】62/840,892

(32)【優先日】2019-04-30

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＢＬＵＥＴＯＯＴＨ

(71)【出願人】

【識別番号】506332063

【氏名又は名称】セールスフォース ドット コム インコーポレイティッド

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】ワイルディング，マーク エフ．

【テーマコード（参考）】

5B376

【Ｆターム（参考）】

5B376AA07

5B376AA11

5B376AA31

5B376AE44

5B376AE52

5B376AE55

5B376AE56

5B376AE58

(57)【要約】

コンピュータシステムの動作管理に関連する技術が開示される。コンピュータシステムは、動作シナリオのためのコマンドセットを定義する動作情報にアクセスし得る。コンピュータシステムは、前記動作シナリオを実施するために目標コンピュータ環境の中で利用されるべき動作エンティティセットのためのブループリントにアクセスしてよい。前記コンピュータシステムは、前記目標コンピュータ環境のための前記動作シナリオを実施してよい。前記実施するステップは、制御モジュールの階層構造を実行するステップを含んでよく、前記階層構造は、該階層構造の最上位にある、該階層構造の次のレベルにある制御モジュールへ命令を発行することにより前記コマンドセットを実行するために実行可能なオーケストレータ制御モジュールを有する。前記階層構造は、前記動作エンティティセットのうちの１つ以上の動作エンティティの状態を変化させることにより、動作シナリオを達成するためにそれぞれのブループリントに従い前記動作エンティティセットを管理するよう動作可能な制御モジュールを含んでよい。

【特許請求の範囲】

【請求項1】

目標コンピュータ環境の動作シナリオを管理する方法であって、前記方法は、
コンピュータシステムにより、前記動作シナリオのためのコマンドセットを定義する動作情報にアクセスするステップと、
前記コンピュータシステムにより、前記動作シナリオを実施する前記目標コンピュータ環境の中で利用されるべき動作エンティティセットのブループリントにアクセスするステップであって、前記動作エンティティセットは、ハードウェアエンティティ、ソフトウェアエンティティ、及び情報エンティティを含む、ステップと、
前記コンピュータシステムにより、前記目標コンピュータ環境のための前記動作シナリオを実施するステップと、
を含み、前記実施するステップは、
制御モジュールの階層構造を実行するステップを含み、前記階層構造は、該階層構造の最上位にあり、該階層構造の次のレベルにある制御モジュールに命令を発行することにより前記コマンドセットを実行するために実行可能なオーケストレータ制御モジュールを含み、前記制御モジュールの階層構造は、前記動作エンティティセットのうちの１つ以上の状態を変化させることによることを含む前記動作シナリオを達成するためにそれぞれのブループリントに従い前記動作エンティティセットを管理するために実行可能な制御モジュールを含む、方法。

【請求項2】

所与の動作エンティティは、該所与の動作エンティティを識別するユニークな識別子に関連付けられ、前記命令のうちの特定の命令は、前記所与の動作エンティティに関連付けられ、前記特定の命令を発行するステプは、
前記ユニークな識別子に基づき、前記所与の動作エンティティを管理する前記制御モジュールのうちの特定の１つを決定するステップと、
前記特定の命令を前記特定の制御モジュールに発行するステップと、
を含む、請求項１に記載の方法。

【請求項3】

所与のブループリントは,前記動作エンティティセットのうちの対応する第１動作エンティティについて、前記第１動作エンティティと前記動作エンティティセットのうちの１つ以上の他の動作エンティティとの間の関係セットを示し、前記関係セットは、前記コマンドセットのうちのコマンドセットが実行できる順序に影響する、請求項１又は２に記載の方法。

【請求項4】

前記関係セットは、前記動作エンティティセットのうちの前記第１動作エンティティと第２動作エンティティとの間の関係を含み、前記第１動作エンティティの状態を変化させるために前記命令のうちの特定の命令を実行するステップは、前記第１動作エンティティの前記状態を変化させる前に、前記第２動作エンティティの状態を変化させるステップを含む、請求項３に記載の方法。

【請求項5】

前記第１動作エンティティと前記第２動作エンティティとの間の前記関係は、前記第１動作エンティティが前記第２動作エンティティの存在に依存するという依存関係である、請求項４に記載の方法。

【請求項6】

所与の動作エンティティは、制御アプリケーションプログラミングインタフェース（ＡＰＩ）によりサポートされる機能セットのうちの１つ以上の機能を実施し、前記１つ以上の実施された機能は、制御モジュールが前記所与の動作エンティティの状態を変化させることを可能にする、請求項１～５のいずれか一項に記載の方法。

【請求項7】

前記ブループリントのうちの特定の１つは、前記所与の動作エンティティに関連付けられ、前記特定のブループリントは、前記所与の動作エンティティに関連付けられた現在ライフサイクルステージを示すライフサイクル値を指定し、前記ライフサイクル値は、前記１つ以上の実施される機能のうちのどれが前記ライフサイクルステージのために呼び出し可能かを決定するために制御モジュールにより使用可能である、請求項６に記載の方法。

【請求項8】

前記動作エンティティセットのうちの第１の特定の動作エンティティは、前記階層構造の中で、前記動作エンティティセットのうちの第２の特定の動作エンティティと異なるレベルにあり、前記動作エンティティセットを管理するために実行可能な前記制御モジュールのうちの制御モジュールは、前記階層構造の異なるレベルにある、請求項１～７のいずれか一項に記載の方法。

【請求項9】

前記命令のうちの特定の命令を実行するステップは、前記ソフトウェアエンティティに、別の情報エンティティをインスタンス化させるステップを含む、請求項１～８のいずれか一項に記載の方法。

【請求項10】

前記動作シナリオは、前記動作エンティティセットに含まれる１つ以上のソフトウェアエンティティの状態を変化させて、前記１つ以上のソフトウェアエンティティを第１ソフトウェアバージョンから第２ソフトウェアバージョンに遷移させることを含む、請求項１～９のいずれか一項に記載の方法。

【請求項11】

前記ハードウェアエンティティはプロセッサセットに対応し、前記ソフトウェアエンティティは、前記プロセッサセットを実行するデータベースサーバに対応し、前記情報エンティティは、前記データベースサーバにより管理される論理データベースに対応する、請求項１～１０のいずれか一項に記載の方法。

【請求項12】

非一時的コンピュータ可読媒体であって、格納されたプログラム命令を有し、前記プログラム命令は、コンピュータシステムに動作を実行させることができ、前記動作は、
目標コンピュータ環境に関連する動作シナリオのためのコマンドセットを定義する動作情報にアクセスするステップと、
前記動作シナリオを実施する前記目標コンピュータ環境の中で利用されるべき動作エンティティセットのブループリントにアクセスするステップであって、前記動作エンティティセットは、ハードウェアエンティティ、ソフトウェアエンティティ、及び情報エンティティを含む、ステップと、
前記目標コンピュータ環境のための前記動作シナリオを実施するステップと、
を含み、前記実施するステップは、
制御モジュールの階層構造を実行するステップを含み、前記階層構造は、該階層構造の最上位にあり、該階層構造の次のレベルにある制御モジュールに命令を発行することにより前記コマンドセットを実行するために実行可能なオーケストレータ制御モジュールを含み、前記制御モジュールの階層構造は、前記動作エンティティセットのうちの１つ以上の状態を変化させることによることを含む前記動作シナリオを達成するためにそれぞれのブループリントに従い前記動作エンティティセットを管理するために実行可能な制御モジュールを含む、媒体。

【請求項13】

前記アクセスされたブループリントのうちの特定のブループリントは、前記動作エンティティセットのうちの対応する動作エンティティのライフサイクル値及びタイプ値を指定し、前記ライフサイクル値及びタイプ値は、前記対応する動作エンティティの状態を変化させるために呼び出し可能な１つ以上の機能を決定するために使用可能である、請求項１２に記載の媒体。

【請求項14】

前記アクセスされたブループリントのうちの特定のブループリントは、前記動作エンティティセットのうちの対応する動作エンティティが前記動作エンティティセットのうちの別の特定の動作エンティティに依存するという関係を指定し、前記対応する動作エンティティを初期化する命令のうちの特定の命令を実行するステップは、前記対応する動作エンティティを初期化する前に、前記別の特定の動作エンティティを初期化するステップを含む、請求項１２に記載の媒体。

【請求項15】

前記動作は、
前記アクセスされたブループリントのうちの所与のブループリントが有効か否かを決定するために、前記所与のブループリントを検証するステップ、を更に含み、前記検証するステップは、
対応する定義にアクセスするステップであって、前記対応する定義は、該定義に対応するブループリントの中で指定されるべき許容可能な値セットを識別する、ステップと、
前記アクセスされた定義に基づき、前記所与のブループリントが前記許容可能な値セットに含まれない値を指定するか否かを決定するステップと、
を含む、請求項１２～１４のいずれか一項に記載の媒体。

【請求項16】

動作エンティティセットを管理する方法であって、
前記動作エンティティセットを含むコンピュータシステムにより、制御モジュールの階層構造を実行するステップであって、前記階層構造は、該階層構造の最上位にあり、前記動作エンティティセットを管理するために該階層構造の中の他の制御モジュールと通信するよう動作するオーケストレータ制御モジュールを有し、前記動作エンティティセットは、ハードウェアエンティティ、ソフトウェアエンティティ、及び情報エンティティを含む、ステップと、
前記オーケストレータ制御モジュールにより、動作情報にアクセスするステップであって、前記動作情報は、前記動作エンティティセットに関連する動作シナリオのステップシーケンスを実施するためのコマンドを有するワークフローを指定する、ステップと、
前記オーケストレータ制御モジュールにより、前記動作シナリオを実施するために前記ワークフローの前記コマンドを実施するステップであって、前記実施するステップは、前記動作エンティティセットのうちの１つ以上の動作エンティティの状態を変化させるために前記他の制御モジュールのうちの１つ以上の制御モジュールに命令を発行するステップと、
を含む方法。

【請求項17】

前記階層構造の中の特定の制御モジュールは、前記動作エンティティセットの属性を定義するそれぞれのブループリントに従い、前記動作エンティティセットを管理するよう動作する、請求項１６に記載の方法。

【請求項18】

前記属性は、前記動作エンティティセットのうちの動作エンティティの間の関係に関する情報を定義する関係属性を含み、前記関係は、前記１つ以上の動作エンティティの前記状態が前記命令に基づき変化される順序に影響する、請求項１７に記載の方法。

【請求項19】

前記１つ以上の他の制御モジュールは、前記オーケストレータ制御モジュールから受信された前記命令のうちの１つ以上の命令を、前記動作エンティティセットを管理する前記特定の制御モジュールへルーティングするよう動作する、請求項１７又は１８に記載の方法。

【請求項20】

前記１つ以上の他の制御モジュールは、前記動作エンティティセットに対応するユニークな識別子のセットに基づき、前記１つ以上の命令をルーティングするよう動作する、請求項１９に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、コンピュータシステムの動作管理に関連する。

【背景技術】

【0002】

歴史的に、サービス又はプラットフォームが実行し及び利用可能であることを保証するような管理システムは、種々の実行リスト（コマンドシーケンス）を実行することを含んでいる。このような実行リストは、標準的に、ユーザが実行リストのコマンドをコマンドラインに手動で入力するために長く時間がかかっていた。やがて、実行リストを通じてトラバースしてユーザの代わりにコマンドを入力するソフトウェアスクリプトが記述されるようになった。これらのソフトウェアスクリプトは、しかしながら、しばしばクラッシュして、被管理システムを不明な状態にしてしまう。結果として、ユーザは、依然として、システムの現在状態を決定し、次にソフトウェアスクリプトの再実行可能な状態にシステムを再設定することに関わる必要があった。更に、システムは、通常、複数のサブシステムに関連するので、複数の実行リストが維持され実行される必要があり、各実行リストがシステムを管理するためのそれら自体のステップ及び方法を有している。

【図面の簡単な説明】

【0003】

【図1】幾つかの実施形態による、動作エンティティを管理可能なシステムの例示的な要素を示すブロック図である。

【0004】

【図2】幾つかの実施形態による、動作エンティティの例示的な要素を示すブロック図である。

【0005】

【図3A】幾つかの実施形態による、動作エンティティの定義及びブループリントの例示的な要素を示すブロック図である。

【0006】

【図3B】幾つかの実施形態による、動作エンティティのためのエンティティデスクリプタの例示的な要素を示すブロック図である。

【0007】

【図3C】幾つかの実施形態による、動作エンティティの関係情報の例示的な要素を示すブロック図である。

【0008】

【図3D】幾つかの実施形態による、例示的な動作エンティティの間の例示的な関係を示すブロック図である。

【0009】

【図4】幾つかの実施形態による、制御モジュールの例示的な要素を示すブロック図である。

【0010】

【図5】幾つかの実施形態による、動作エンティティの管理に関連する例示的な方法を示すフロー図である。

【0011】

【図7】幾つかの実施形態による、制御ＡＰＩの例示的な要素を示すブロック図である。

【0012】

【図8】幾つかの実施形態による、ルーティングエンジン、ルーティング層、及びルーティング可能エンティティの例示的な要素を示すブロック図である。

【0013】

【図9】幾つかの実施形態による、動作エンティティに関連付けられた命令の実施に関連する例示的な方法を示すフロー図である。

【図10】幾つかの実施形態による、動作エンティティに関連付けられた命令の実施に関連する例示的な方法を示すフロー図である。

【0014】

【図11】幾つかの実施形態による、動作エンティティに関連付けられた命令のルーティングに関する例示的な方法を示すフロー図である。

【図12】幾つかの実施形態による、動作エンティティに関連付けられた命令のルーティングに関する例示的な方法を示すフロー図である。

【図13】幾つかの実施形態による、動作エンティティに関連付けられた命令のルーティングに関する例示的な方法を示すフロー図である。

【0015】

【図14】幾つかの実施形態による、ワークフローエンジンの例示的な要素を示すブロック図である。

【0016】

【図15】幾つかの実施形態による、ワークフローの実施に関連する例示的な方法を示すフロー図である。

【図16】幾つかの実施形態による、ワークフローの実施に関連する例示的な方法を示すフロー図である。

【0017】

【図17】幾つかの実施形態による、推理エンジンの例示的な要素を示すブロック図である。

【0018】

【図18】幾つかの実施形態による、ワークフローの生成に関連する例示的な方法を示すフロー図である。

【0019】

【図20A】幾つかの実施形態による、認証サービスの例示的な要素を示すブロック図である。

【図20B】幾つかの実施形態による、認証サービスの例示的な要素を示すブロック図である。

【0020】

【図21】幾つかの実施形態による、認証シートの例示的な要素を示すブロック図である。

【0021】

【図22】幾つかの実施形態による、認証サービスにより生成されるトークンの例示的な要素を示すブロック図である。

【0022】

【図23】幾つかの実施形態による、認証サービスに関連する例示的な方法を示すフロー図である。

【0023】

【図24】幾つかの実施形態による、テストエンジンの例示的な要素を示すブロック図である。

【0024】

【図25】幾つかの実施形態による、テストエンジンに関連する例示的な方法を示すフロー図である。

【0025】

【図26】幾つかの実施形態による、例示的なコンピュータシステムを示すブロック図である。

【発明を実施するための形態】

【0026】

本開示は、「一実施形態」又は「実施形態」への言及を含む。「一実施形態では」又は「実施形態では」の語句の出現は、必ずしも同じ実施形態を表さない。特定の特徴、構造、又は特性は、本開示と矛盾しない任意の適切な方法で結合されてよい。

【0027】

本開示において、異なるエンティティ（これは、「ユニット」、「回路」、他のコンポーネント、等のように様々に表されてよい）は、１つ以上のタスク又は動作を実行するよう「構成される」と記載され又は請求されてよい。この明確な記述－［１つ以上のタスクを実行する］よう構成される［エンティティ］－は、本願明細書で、構造（つまり、電子回路のような何らかの物理的なもの）を表すために使用される。より具体的には、この明確な記述は、この構造が動作中に１つ以上のタスクを実行するよう配置されることを示すために使用される。構造は、該構造が現在作動中でない場合でも、何らかのタスクを実行する「よう構成される」と言える。「ネットワークを介して通信するよう構成されるネットワークインタフェース」は、例えば、対象の集積回路が現在使用中でない場合でも（例えば、それに電源が接続されていない）、動作中にこの機能を実行する回路を有する集積回路を包含することを意図する。従って、何らかのタスクを実行する「よう構成される」と記載され又は引用されるエンティティは、装置、回路、タスクを実施するために実行可能なプログラム命令を格納するメモリ、等のような何らかの物理的なものを表す。この語法は、本願明細書で、何らかの無形物を表すために使用されない。従って、「～よう構成される」構成は、本願明細書では、アプリケーションプログラミングインタフェース（application programming interface(API)）のようなソフトウェアエンティティを表すために使用されない。

【0028】

用語「～よう構成される（configured to）」は、「構成可能である（configurable to」を意味しない。未設定ＦＰＧＡは、例えば、何らかの特定の機能を実行するよう「構成される」と考えられない。しかしながら、未設定ＦＰＧＡは、該機能を実行するよう「構成可能」であってよく、設定（プログラミング）後に該機能を実行するよう「構成され」てよい。

【0029】

本願明細書で使用されるとき、用語「第１」、「第２」、等は、それらが先行する名詞のラベルとして使用され、特に断りの無い限り、いかなる種類の順序（例えば、空間的、時間的、論理的、等）も意味しない。例えば、８個の処理コアを有するプロセッサでは、用語「第１」及び「第２」処理コアは、８個の処理コアのうちの任意の２つを表すために使用できる。言い換えると、「第１」及び「第２」処理コアは、例えば処理コア０及び１に限定されない。

【0030】

本願明細書で使用されるとき、用語「に基づき」は、決定に影響する１つ以上の要素を記述するために使用される。この用語は、追加要素が決定に影響し得る可能性を排除しない。つまり、決定は、特定の要素に単独で基づいて、又は特定の要素及び他の指定されていない要素に基づいてよい。語句「Ｂに基づきＡを決定する」を検討する。この語句は、ＢがＡを決定するための要因であること、又はＡの決定に影響することを指定する。この語句は、Ａの決定が何からの他の因子、例えばＣに基づいてもよいことを排除しない。この語句は、ＡがＢにのみ基づき決定される実施形態を包含することも意図する。本願明細書で使用されるとき、語法「に基づき」は、従って、「に少なくとも部分的に基づき」と同義である。

【0031】

実行リストからコマンドを入力するソフトウェアスクリプトを使用する代わりに、一部の開発者は、彼らのシステムを管理するために、Ｋｕｂｅｒｎｅｔｅｓ（登録商標）のような大規模展開システムを使用し始めている。Ｋｕｂｅｒｎｅｔｅｓ（登録商標）は、コンテナの展開及び管理を自動化するコンテナ型（container－centric）管理環境を提供する。コンテナは、ポータブルな自給自足型のユニットであり、アプリケーション及びその依存関係を有する。従って、開発者は、Ｋｕｂｅｒｎｅｔｅｓ（登録商標）を使用して、例えばデータベースサーバを含むコンテナを展開し得る。Ｋｕｂｅｒｎｅｔｅｓ（登録商標）は、しかしながら、様々な理由から、システム全体を管理するには不十分である。Ｋｕｂｅｒｎｅｔｅｓ（登録商標）は、ワーカノード（例えば、仮想マシン）の上にあるコンテナを管理するよう設計された。例えば、Ｋｕｂｅｒｎｅｔｅｓ（登録商標）は、ハードウェア又は論理データベース若しくは構成仕様のような情報エンティティを管理するために使用できない。Ｋｕｂｅｒｎｅｔｅｓ（登録商標）は、コンテナ内の全てのものに渡る可視性及び／又は制御を提供しない。例えば、Ｋｕｂｅｒｎｅｔｅｓ（登録商標）は、コンテナ内にインスタンス化されたデータベースサーバとインタフェースできない。その結果、コンテナ内のシステムの起動、それらのシステムのトラブルシューティング、及びそれらのシステム上のメタデータの収集、のような管理目的は、Ｋｕｂｅｒｎｅｔｅｓ（登録商標）のみを用いて実行できない。Ｓｐｉｎｎａｋｅｒ（登録商標）のような他のアプローチは、システム内で発見され得るコンポーネントの全範囲を制御する能力に欠けるので、Ｋｕｂｅｒｎｅｔｅｓ（登録商標）と同じ欠点を共有する。

【0032】

システムの管理は伝統的に非常に困難であるが、これらのシステムをテストすること又は生じるトラブルシューティングの問題は同等に困難である。前述のように、実行リストが失敗すると、実行リストは該実行リストがクラッシュ前にシステムをおいた状態に関する情報を提供しないので、システムの現在状態を見分けることは通常困難である。更に、通常、テストされるべきシステム内部は非常に複雑である。その結果、システムの部分は、システムの複雑さにより見逃された場合にはテストされないことがあり、それらのテストされるべき部分が十分に完全にテストされないことがある。

【0033】

本開示は、従来のアプローチの欠点の一部又は全部を克服する、システムを管理する技術を記載する。後述する種々の実施形態で、システム内の動作エンティティ（operational entity）（例えば、データベースサーバ、論理データベース、等）は、形式的な構造化された方法で記載され、従って制御モジュールにより管理される。一般的に、システム内の動作エンティティの多くは、ハードウェア、又はハードウェアに格納された情報である。動作エンティティが単にシステムの物理的な有形コンポーネントである場合、それは本開示では「ハードウェアエンティティ」と呼ばれる。物理的サーバラック及びブレードは、ハードウェアエンティティの例である。動作エンティティがハードウェアではない場合、それは、情報で構成されてよく、つまりハードウェアに格納されたデータであってよい。この情報は、実行可能又は非実行可能であってよい。動作を実行するためにシステムにより実行可能な情報は、本開示では「ソフトウェアエンティティ」と呼ばれる。データベースサーバインスタンス、警告サーバインスタンス、及びメトリックサーバインスタンスは、ソフトウェアエンティティの例である。一方で、実行可能ではない、システム内の移情報は、本開示では「情報エンティティ」（又は代替として「情報型（information－oriented）エンティティ」）と呼ばれる。データベースバックアップイメージ、及び複数テナントデータベースのうちのテナントのデータを含むテナント構成は、情報エンティティの例である。

【0034】

これらの３つのエンティティ種類、つまりハードウェア、ソフトウェア、及び情報は、システム内で見付かる任意の動作エンティティの「構成ブロック（building blocks）」と考えることができる。本開示の目的のために、システム内の任意の動作エンティティは、３つの構成ブロックエンティティ種類のうちの１つを用いて、又はこれらの構成ブロックのうちの２つ以上を含む組み合わせエンティティ種類（又は代替として「組成物（formation）」）を用いて、記載され得る。組成物（formation）エンティティの一例は、「データベースシステム」の動作エンティティであってよい。何故なら、データベースシステムは、プロセッサ及び記憶媒体（ハードウェアエンティティ）、該プロセッサ上で実行するデータベースサーバ（ソフトウェアエンティティ）、及び該データベースサーバにより管理される論理データベース（情報エンティティ）を含み得るからである。組成物エンティティの別の例は、「ストレージ領域ネットワーク」の動作エンティティであってよい。何故なら、ストレージ領域ネットワークは、記憶媒体、ネットワークスイッチ（これは、それ自体がハードウェア及びソフトウェアエンティティの組成物であってよい）、及び該記憶媒体上に格納されるデータオブジェクト（情報エンティティ）を含み得るからである。

【0035】

種々の実施形態で、システムの意図される／期待される状態、つまりシステムのオペレータがシステムを置きたい状態は、最初に定義される。システムの意図される状態を定義することは、これらの動作エンティティの間の関係と一緒にシステムを設定する種々の動作エンティティを定義する定義及びブループリント（blueprints）を生成することを含み得る。これらの定義及びブループリントは、動作エンティティを記述するための構造化された方法を提供する共通のスキーマに従ってよい。更に説明するように、定義及びブループリントは、制御モジュールが定義及びブループリントに対応する動作エンティティを管理できるようにする情報を、制御モジュールに伝達してよい。例えば、制御モジュールがデータベースサービス動作エンティティを管理している場合、制御モジュールは、データベースサービスにリンクされたブループリントから、データベースサービスが３つの実行中のデータベースサーバを含むべきであると知ることができる。制御モジュールが、データベースサービスが２つの実行中のデータベースサーバのみを含むことを知った場合、制御モジュールは、該データベースサービスエンティティの意図された状態に達するために、第３データベースサーバを起動してよい。

【0036】

２つの実行中のデータベースサーバから３つの実行中のデータベースサーバへのこの遷移は、２つの状態間のシステムの状態遷移として見ることができる。従って、システムの動作管理は、システムが存在し得る及び異なる状態を通じて遷移し得る状態マシンとして又はそれと同等であると見ることができる。上述のように、定義及びブループリントは、システム内のエンティティ及び従ってシステム全体としての意図される状態を定義し得る。種々の実施形態で、システムの制御モジュールは、システムが意図された状態に到達するまで、システムをある状態から別の状態へと遷移させる。従って、制御モジュールは、システムが意図された状態に留まることを保証するために、システムを監視し続けてよい。システムが意図された状態を離れた場合（例えば、エンティティがクラッシュした場合）、制御モジュールは、システム内のコンポーネントに命令を発行することにより、システムを意図された状態に戻すために、１つ以上のコマンドを実施してよい。幾つかの場合には、コマンドは、ユーザが読むことができる方法で記述されてよく（つまり、人間により読み取り可能なコマンド）、従って、制御モジュールは、そのコマンドをシステム内のコンポーネントにより理解可能な命令に変換してよい。幾つかの場合には、コマンドは、理解可能な命令であってよく、従って、制御モジュールは、それを変換する必要がなくてよく、制御モジュールは、該コマンドをコンポーネントへの命令として発行してよい。本願明細書で使用されるとき、用語「コンポーネント」は、動作エンティティ及び制御モジュールを包含することを意図する。従って、用語「コンポーネント」は、動作エンティティ又は制御モジュールを表し得る。

【0037】

システムの状態間で遷移を実現するために、種々の実施形態で、システムの現在状態を理解し及び必要な場合及び必要なときにシステムを変化させる方法を提供する制御アプリケーションプログラミングインタフェース（application programming interface (API)）が実装される。制御ＡＰＩは、動作エンティティの状態に関して学習し及び該動作エンティティによりサポートされる機能を呼び出すメカニズムを提供するＡＰＩ呼び出しのセットを通じて、システム内の動作エンティティへの構造化されたアクセスを提供してよい。種々の実施形態で、制御モジュールは制御ＡＰＩをホスティングし、従って、ユーザ及び／又は他の制御モジュールが制御ＡＰＩを介して該制御モジュールにより管理される動作エンティティにアクセスできるようにする。

【0038】

種々の実施形態で、制御モジュール及びシステム内の動作エンティティは階層構造を形成してよい。該階層構造では、オーケストレータ制御モジュールが階層構造の最上位に存在してよく、階層構造を通じて下方へ下位レベルに存在する制御モジュール及び動作エンティティへ命令（これは制御ＡＰＩ呼び出しを含んでよい）を発行してよい。一例として、オーケストレータ制御モジュールは、コマンドラインツールを介してユーザから、特定エンティティに関するコマンドを受信してよい。従って、オーケストレータ制御モジュールは、適切な制御ＡＰＩ呼び出しを行うことにより、階層構造のレベルを通じて、特定エンティティへの命令を実施し得る管理制御モジュールへ、命令（これはコマンドに基づく）をルーティングしてよい。該呼び出しは、特定の動作エンティティに別の状態への遷移を生じさせてよい。

【0039】

この枠組みは、動作シナリオを実施させることを可能にする。大まかに言うと、用語「動作シナリオ（operational scenario）」は、本願明細書では、何らかのアクションを実行するために使用されるステップのシーケンスを表すために使用される。例えば、ある動作シナリオは、データベースサービスの起動を含んでよく、別の動作シナリオはデータベースサービスの更新を含んでよい。動作シナリオは、制御ＡＰＩ呼び出しのセットを介して実行され得る順序付きコマンドセットを含むワークフローを用いて実施されてよい。例えば、データベースサービスを更新するワークフローは、データベースサービスの動作エンティティを「オンライン」から「オフライン」へ遷移させるコマンド、それらをそれらの現在バージョンから更新されたバージョンへ遷移させるコマンド、及びそれらを遷移させてオフラインからオンラインに戻すコマンド、を含んでよい。幾つかの実施形態では、オーケストレータ制御モジュールは、ワークフロー情報にアクセスし、対応するワークフローを達成する目的で適切な動作エンティティに対する変化を生成するために、ワークフロー情報に基づき、階層構造を通じて下方へ命令を発行する。

【0040】

動作シナリオは、代替として、適切なエンティティの意図された状態のセットを定義することにより実施されてよい。オーケストレータ制御モジュールは、次に、意図された状態のセットから、該状態に達するためのコマンドを決定してよい。例えば、意図された状態（又は目標）は、３つのデータベースサーバを含む実行データベースサービスを有することであってよい。従って、オーケストレータ制御モジュールは、３つのデータベースサーバを起動する制御ＡＰＩ呼び出しを有するコマンドを生成してよい。この処理は、意図された状態に関するオーケストレータの「推理（reasoning）」と呼ぶことができる。この推理は、従って、幾つかの場合には、ユーザが目標を定義することを可能にする。ここで、当該目標を達成するために必要な特定ステップ又はアクションを明瞭に表現する必要がなく、これは代わりにオーケストレータにより実行される「推理」により決定され得る。幾つかの場合には、このアプローチは、ワークフローを定義するよりもロバストであり得る。何故なら、システムは、それ自体の意図された状態で終了し得るからである（例えば、コンテナの消失は、該コンテナを有しない意図された状態を満たし得る）。

【0041】

これらの技術は、自動的にシステム全体を記述し、そして管理できるので、これらの技術は従来のアプローチに勝り有利であり得る。Ｋｕｂｅｒｎｅｔｅｓ（登録商標）のような従来のアプローチは、コンテナを定義しインスタンス化することを可能にするが、システム内の全範囲のコンポーネント（例えば、ハードウェア、コンテナ内のソフトウェア、論理データベースのような情報構造、等）を制御するメカニズムを提供しない。更にこれらの技術は、システムの意図された状態を定義することを可能にし、従ってシステムを自動的な方法で制御可能にし、これはシステムを管理するための人間の介入への依存を低減する。つまり、システム内の制御モジュールは、システムが意図された状態にあることを保証するために、システムを絶えず監視し得る。システムが異なる望ましくない状態に変化した場合、制御モジュールは、多くの場合に人間の介入無しにシステムを遷移させて意図された状態へと戻し得る。この自動的方式は、システムを管理する際に巻き込まれる人の数を削減できる。更に、エンティティを記述するための共通フォーマットの使用は、操作を簡略化し、動作シナリオをテストする能力を向上し、製造環境でソフトウェアを管理するために必要なコードの量を削減し得る。これらの技術は、展開全体を再生成することなく、（例えば、アプリケーションサーバのプールにノードセットを追加することにより）展開が変更され得る変わりやすい展開に、及び（例えば、展開全体が展開に対する変化の度に再生成される）不変の展開に、更に適用されてよい。これらの技術は、（完全に別個のツールを使用しなければならないことに対して）統合された障害テスト、統合されたセキュリティ、及び統合されたトラブルシューティングも提供する。

【0042】

図１を参照すると、システム１００のブロック図が示される。図示の実施形態では、システム１００は、動作エンティティ１１０、制御モジュール１２０（オーケストレータ制御モジュール１２０を含む）、データベース１３０、及び認証サービス１４０を含む。また図示のように、データベース１３０は動作情報（operational information）１３５を含み、認証サービス１４０はテストエンジン１５０を含む。幾つかの実施形態では、システム１００は、図と異なる方法で実装されてよい。一例として、システム１００は、複数のオーケストレータ制御モジュール１２０、別のレベルの動作エンティティ１１０及び／又は制御モジュール１２０、複数のデータベース１３０、等を含んでよい。

【0043】

動作エンティティ１１０は、種々の実施形態で、１つ以上の要素、及びそれらの要素に関連する情報の集合を含む。要素の例は、例えば、物理プロセッサ、物理メモリ、仮想マシン、仮想マシンイメージ、論理データベース、データベーススナップショット、コンテナ、コンテナイメージ、データベースサービス、オペレーティングシステム、ワークフロー、アドレスセンタ、ネットワーク境界／ドメイン、等を含んでよい。上述のように、３つの基本的な種類の動作エンティティ１１０がある：ハードウェアエンティティ１１０、ソフトウェアエンティティ１１０、及び情報エンティティ１１０である。動作エンティティ１１０の種類は、種々の実施形態では、どんなエンティティが該動作エンティティを構成するかに依存する。例えば、物理プロセッサのみを含む動作エンティティ１１０は、ハードウェアエンティティ１１０と考えられる。これらの３つの基本的な種類は、組成物動作エンティティ１１０を生成するために使用されてよい。組成物エンティティ１１０は、２以上のエンティティの集合であり、該２以上のエンティティの各々は他のエンティティとゼロ以上の関係を有する。組成物（formation）エンティティ１１０の一例は、プロセッサ及び記憶媒体（ハードウェアエンティティ１１０）を含むデータベースシステムエンティティ１１０、該プロセッサ上で実行するデータベースサーバ（ソフトウェアエンティティ１１０）、及び該データベースサーバにより管理される論理データベース（情報エンティティ１１０）であってよい。

【0044】

動作エンティティ１１０は、該動作エンティティを記述する情報の集合を含み又はそれに関連付けられてよい。情報は、どんな要素及び変数が動作エンティティ１１０の特定種類の動作エンティティを構成するために使用できるか定義する定義、及び該種類の動作エンティティ１１０のインスタンスを定義するブループリント（blueprint）を含んでよい。例えば、定義は、データベースサービスエンティティ１１０がデータベースサーバエンティティ１１０を含むことを定義してよく、一方で、ブループリントは、特定のデータベースサービスエンティティ１１０が１５個のデータベースサーバエンティティ１１０を含むことを定義してよい。種々の実施形態で、動作エンティティ１１０に関連付けられた情報は、制御ＡＰＩの機能を更に定義する。このような情報は、例えば動作エンティティを異なる状態に遷移させることにより該動作エンティティを管理するために、該動作エンティティ１１０のためにどんな機能が呼び出され得るかについて知るために、制御モジュール１２０により使用されてよい。

【0045】

制御モジュール１２０は、種々の実施形態で、動作エンティティ１１０及び／又は制御モジュール１２０のセットを管理するために実行可能なソフトウェアルーチンのセットである。幾つかの実施形態で、制御モジュール１２０は、システム１００内の各制御モジュール１２０が同じ機能をサポートするように一般的方法で定義されが、それらはシステム１００内で異なる役割で機能してよい。制御モジュール１２０は、ベアメタル、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅ（登録商標）（ＡＷＳ）、及びＫｕｂｅｒｎｅｔｅｓ（登録商標）を含む様々な環境でも動作し得る。例えば、Ｋｕｂｅｒｎｅｔｅｓ（登録商標）環境では、制御モジュール１２０は、データベースコンテナの中にある他の制御モジュール１２０と相互作用するＫｕｂｅｒｎｅｔｅｓ（登録商標）オペレータとして機能してよい。ＡＷＳでは、ＡＷＳクラウドは、仮想マシンエンティティ１１０を施行する動作エンティティ１１０として定義され得る。各仮想マシンエンティティ１１０の内部には、該仮想マシンエンティティのコンテンツ（動作エンティティ１１０）を管理する制御モジュール１２０が存在し得る。

【0046】

動作エンティティ１１０及び／又は制御モジュール１２０を管理するために、制御モジュール１２０は、自身の制御又は権限の下にある各動作エンティティ１１０の制御ＡＰＩへのアクセスを有してよい。種々の場合において、制御ＡＰＩの制御ＡＰＩ呼び出しは、全ての動作エンティティ１１０について同じであってよいが、それら制御ＡＰＩ呼び出しの機能の実施は動作エンティティ１１０の間で異なってよい。制御ＡＰＩ呼び出しの発行を通じて、制御モジュール１２０は、動作エンティティ１１０に関する情報（例えば、ブループリント）を取得してよく、該動作エンティティを状態間で遷移させてよい。一例として、制御モジュール１２０は、「遷移」制御ＡＰＩ呼び出しをデータベースサーバエンティティ１１０へ送信して、データベースサーバ要素をオフラインからオンラインに遷移させてよい。

【0047】

種々の実施形態で、制御モジュール１２０は、該制御モジュールにより管理される動作エンティティ１１０及び／又は制御モジュール１２０に関する情報を維持する。幾つかの場合には、開始されると、制御モジュール１２０は、該制御モジュール１２０に初期情報を提供するプロパティファイルにアクセスしてよい。このような情報は、リッスンすべきポート番号、及び制御モジュール１２０の制御下にある任意の動作エンティティ１１０を識別してよい。制御モジュール１２０により維持される情報は、動作エンティティ１１０から集められた情報、例えばブループリント、定義、及びそれらの動作エンティティによりサポートされるアドバタイズされた制御ＡＰＩ呼び出しも含んでよい。

【0048】

上述のように、動作エンティティ１１０及び制御モジュール１２０は、階層構造を形成してよい。該階層構造の最上位にある制御モジュール１２０は、オーケストレータ制御モジュールと呼ばれる。オーケストレータ制御モジュール１２０は、上位レベルの目標を実施する任務があってよく、従って、その目標を達成するために階層構造の他のレベルにある他の制御モジュール１２０を組織化してよい（orchestrate）。一例として、オーケストレータ制御モジュール１２０は、データベースフリート（database fleet）エンティティ１１０全体を更新する任務があってよい。結果として、オーケストレータ制御モジュール１２０は、データベースフリートエンティティ１１０内の各データベースクラスタエンティティ１１０の更新を調整してよい。これは、それらデータベースクラスタエンティティ１１０の中の動作エンティティ１１０を管理する他の制御モジュール１２０を利用してよい。これらの制御モジュール１２０は、しかしながら、これらのデータベースクラスタエンティティ１１０を更新する際に何が起こるかの詳細を、オーケストレータ制御モジュール１２０から隠してよい。幾つかの実施形態では、システム１００は、複数の階層構造を含んでよく、階層構造の各々は、それらのオーケストレータ制御モジュール１２０を含んでよい。

【0049】

データベース１３０は、種々の実施形態で、情報のアクセス、記憶、及び操作を可能にする方法で組織化された情報の集合である。データベース１３０は、単一の記憶装置又はネットワーク上で一緒に接続される複数の記憶装置、例えばストレージの取り付けられたネットワークにより実装され、データ損失を防ぐために情報を冗長に格納するよう構成されてよい。データベース１３０は、制御モジュール１２０がデータベース１３０内の情報に対して動作（例えば、アクセス、格納、操作、等）を実行することを可能にするソフトウェアのサポートを含んでよい。種々の実施形態で、データベース１３０は、定義、ブループリント、動作情報１３５、及び／又はシステム１００内の動作エンティティ１１０に関する他の情報を格納する。動作エンティティ１１０を管理するとき、制御モジュール１２０は、データベース１３０からの情報にアクセスしてよく、その結果、制御モジュール１２０は該動作エンティティを正しく管理し得る。

【0050】

動作情報１３５は、種々の実施形態で、目標環境１３７の動作シナリオを定義する情報の集合である。上述のように、動作シナリオは、何らかのアクション（又は上位の目標）を実行するために使用されるステップのシーケンスである。幾つかの実施形態では、動作シナリオは、ワークフロー文書の中で定義される。ここで、所与のワークフロー文書は、対応する動作シナリオのためのステップシーケンスを実施するためのコマンドセットを指定してよい。所与の動作シナリオは、目標環境１３７に関連付けられて、動作シナリオが該目標環境の状態を変化させ得るようにしてよい。

【0051】

目標環境１３７は、種々の実施形態で、動作シナリオの一部として作動され得る動作エンティティ１１０及び／又は制御モジュール１２０のグループである。例えば、データベースフリートエンティティ１１０を新しいバージョンに更新する動作シナリオでは、データベースフリートエンティティ１１０（その全部の動作エンティティ１１０及び制御モジュール１２０を含む）は、該動作シナリオの目標環境１３７であると考えられる。別の動作シナリオは、異なる動作エンティティ１１０及び／又は制御モジュール１２０を有する異なる目標環境１３７に関連してよい。

【0052】

認証サービス１４０は、種々の実施形態で、認証（「誰が状態を変化しようとしているか？」）、認可（「彼らは状態を変化させることを許可されているか？」）、及び監査（認証及び認可の結果を記録する）コマンドが制御モジュール１２０及び／又は動作エンティティ１１０に発行されることにより、システム１００を（悪意あるものか悪意のないものかに拘わらず）不正な使用から保護するよう動作する。例えば、サービス１４０は、任意の認可されていない発行されたコマンドの実行を防ぐために、ユーザによりオーケストレータ制御モジュール１２０に発行されたコマンドを監査してよい。サービス１４０は、ユーザがオーケストレータ制御モジュール１２０を回避することにより認可されたアクセスを得ようと企てていないことを保証するために、オーケストレータ制御モジュール１２０により他の制御モジュール１２０へ（又は他の制御モジュール１２０から動作エンティティ１１０へ）発行されたコマンドも監査してよい。図２０～２３に関して後述するように、種々の実施形態で、認証サービス１４０は、目標コンピューティング環境の中で様々な動作シナリオを実施するために許容されるアクションを定義するセキュリティルールセットを保持し、発行されたコマンドがセキュリティルールセットにより定義された許容アクションに従うかを検証する。

【0053】

テストエンジン１５０は、種々の実施形態で、システム１００が障害し正しく機能しない状態を識別するために、システム１００に障害状態を入力するよう動作するテストコンポーネントである。通常、これらの障害は、クラッシュ、ハング、エラー、ロックステップの順序の問題、時間注入、等に関連してよい。例えば、テストエンジン１５０は、このようなアクションがシステム１００を復旧するために使用できない状態にするかを知るために、システム１００により使用されているデータベースサーバを無効にしてよい。図２４及び２５に関連して以下に更に詳述するように、種々の実施形態で、テストエンジン１５０は、システム１００の現在状態を決定するために、１つ以上の制御モジュール１２０及び／又は動作エンティティ１１０とインタフェースする。例えば、テストエンジン１５０は、障害条件を注入する前にシステム１００の現在状態に関する情報を集め、次に、システム１００の状態がどのように変更されたかを決定するために、注入後の現在状態に関する情報を集めてよい。幾つかの実施形態では、テストエンジン１５０は、特定のコマンドが制御モジュール１２０により発行されているときの特定の障害条件を注入するために、システム１００の状態を監視してもよい。つまり、要求が認証サービス１４０を通るので、テストエンジン１５０は、（例えば、変化前、変化後、及び変化中に）障害注入を調整するためにアーキテクチャ内のこの点を使用してよい。例えば、テストエンジン１５０は、認証サービス１４０により処理されている要求から、動作エンティティ１１０が更新を経験していることを決定してよく、次に、システム１００が更新処理中に障害条件を処理できるか否かを決定するために、結果として更新失敗をもたらし得る障害条件を注入することを試みてよい。図示の実施形態では、テストエンジン１５０は、認証サービス１４０に統合されているとして示される。このような統合は、種々のコンポーネントがサービス１４０に種々のアクションの実行許可を依頼するとき、テストエンジン１５０がシステム１００の現在状態のより深い見識を有することを可能にし得る。幾つかの実施形態では、外部テストシステムが、変化を編成し及びシステム１００に障害を注入するためにテストエンジン１５０と相互作用してよい。

【0054】

図２を参照すると、動作エンティティ１１０のブロック図が示される。図示の実施形態で、動作エンティティ１１０は、ブループリント２１０、１つ以上の要素２２０、及び制御ＡＰＩ実装２３０を含む。図示のように、動作エンティティ１１０は、制御モジュール１２０とインタフェースする。幾つかの実施形態では、動作エンティティ１１０は、外部制御モジュール１２０とインタフェースする制御モジュール１２０を含んでよい。一例として、動作エンティティ１１０は、オーケストレータ制御モジュール１２０と通信する制御モジュール１２０を有するソフトウェアコンテナであってよい。幾つかの実施形態では、動作エンティティ１１０は、図示と異なるように実装されてよい。例えば、ブループリント２１０は、動作エンティティ１１０ではなくデータベース１３０に格納されてよい（或いは、ブループリント１２０は、エンティティ１１０及びデータベース１３０の両方に格納されてよい）。

【0055】

上述のように、システム１００の動作エンティティ１１０を管理できるために、種々の実施形態で、エンティティ１１０は、ブループリント２１０、及び動作エンティティ自体及びそれらの他のエンティティ１１０との関係に関する情報を含む定義（これは図３Ａに関して更に詳述される）を用いて記述されてよい。このような情報は、制御モジュール１２０に、異なる動作エンティティ１１０がどのように管理され得るかを伝達してよい。

【0056】

ブループリント２１０は、種々の実施形態で、動作エンティティ１１０の特定の実装の態様を定義する情報の集合である。ブループリント２１０は、システム１００の管理者が動作エンティティ１１０の存在することを望む該動作エンティティ１１０の望ましい又は意図された状態を定義してよい。例えば、ある特定のブループリント２１０は、データベースフリートエンティティ１１０が１５個のデータベースサーバを含むことを記述してよく、一方で、別の特定のブループリント２１０は、データベースフリートエンティティ１１０が１０個のデータベースサーバを含むことを記述してよい。図３Ａ～３Ｄに関して更に詳述されるように、種々の実施形態で、ブループリント２１０は、動作エンティティ１１０を管理するために使用可能な属性の選択されたセットの値を定義し得るエンティティデスクリプタと、動作エンティティ１１０と他のエンティティとの間の関係を記述し得る関係情報と、動作エンティティ１１０を構成するために使用されうるエンティティ固有変数と、を含む。動作エンティティ１１０のブループリント２１０は、システム１００のユーザ、該エンティティを開発したユーザ（例えば、ソフトウェアを記述したユーザ）、制御モジュール１２０、等（それらの任意の組み合わせを含み得る）により提供され及び／又は変更されてよい。例えば、管理制御モジュール１２０は、対応する動作エンティティ１１０を新しいバージョンへと更新するとき、エンティティデスクリプタの中のバージョン情報を変更してよい。

【0057】

種々の実施形態で、ブループリント２１０は、該ブループリントにより定義される動作エンティティ１１０のインスタンスを生成するために展開可能であってよい。例えば、オペレータは、データベースサービスエンティティ１１０のためのブループリント２１０を提供してよい。このブループリントは、該データベースサービスエンティティが１４個のデータベースサーバを有するという意図された状態を定義してよい。該ブループリントを展開することを担う制御モジュール１２０は、データベースサービスエンティティ１１０が存在するか否かを決定するために、システム１００の状態を観察してよい。データベースサービスエンティティ１１０が存在しない場合、管理制御モジュール１２０は、例えば１５個のデータベースサーバを生成する能力のある特定の動作エンティティ１１０と通信することにより、自身のブループリント２１０に従いデータベースサービスエンティティ１１０をインスタンス化してよい。

【0058】

幾つかの例では、ブループリント２１０は、階層構造を形成してよい。ここで、最上位のブループリント２１０の実装は、下位レベルのブループリント２１０の実装を含んでよい。従って、ブループリント２１０は、他のブループリント２１０への参照を含んでよい。前述の例に戻ると、データベースサービスエンティティ１１０のブループリント２１０は、データベースサーバエンティティ１１０の特定の実装のためのブループリント２１０への参照を含んでよい。従って、データベースサービスエンティティ１１０をインスタンス化するとき、管理制御モジュール１２０は、自身が１５個のデータベースサーバのインスタンス化を生じることができるように、データベースサービスエンティティ１１０のブループリント２１０を介してデータベースサーバエンティティ１１０のブループリント２１０を探してよい。

【0059】

要素２２０は、種々の実施形態で、ハードウェア（例えば、物理プロセッサ及びメモリ）、ソフトウェア（例えば、データベースサーバ）、情報構造（例えば、論理データベース）、又はそれらの任意の組み合わせ（例えば、要素２２０は動作エンティティ１１０を含んでよく、該動作エンティティ１１０が、ハードウェア、ソフトウェア、及び情報構造である、それ自体の要素２２０セットを含む）を含む。要素２２０の例は、限定ではないが、物理プロセッサ及びメモリ、ラックに設置されたネットワークスイッチ、オペレーティングシステム、仮想マシン、仮想マシンイメージ、データベースサーバ、論理データベース、データベーススナップショット、コンテナ、コンテナイメージ、ワークフロー、データベースセンタ、テナントスナップショット、及びテナントを含む。種々の場合に、制御モジュール１２０は、制御ＡＰＩ実装２３０を介して要素２２０とインタフェースしてよい。

【0060】

制御ＡＰＩ実装２３０は、種々の実施形態で、（図７に関して更に詳細に議論される）制御ＡＰＩの１つ以上の機能を実行するために実行可能なソフトウェアルーチンのセットである。制御ＡＰＩ実装２３０は、要素２２０／ブループリント２１０、及び制御モジュール１２０の間のインタフェースとして機能してよい。制御ＡＰＩが「生成」機能を含み、データベースサーバエンティティ１１０が存在する例を考える。このデータベースサーバエンティティ１１０は、例えば該生成機能について論理データベースエンティティ１１０を生成する動作セットを定義する制御ＡＰＩ実装２３０を含んでよい。従って、データベースサーバエンティティ１１０を管理する制御モジュール１２０は、論理データベースエンティティ１１０を生成するために、制御ＡＰＩ実装２３０のロジックを呼び出す生成機能ＡＰＩ呼び出しを発行してよい。このようなロジックは、論理データベースエンティティを生成するようデータベースサーバ（要素２２０）に指示してよい。種々の実施形態で、制御ＡＰＩ実装２３０は、動作エンティティ１１０の間で異なってよい。ここで、各動作エンティティ１１０は、制御ＡＰＩによりサポートされる機能のうちの１つ以上をユニークに実装してよい。

【0061】

種々の実施形態で、制御ＡＰＩ実装２３０は、要素２２０の基礎にある複雑性をカプセル化し隠すラッパとして実装される。例えば、データベースサーバは、データベースサーバを起動し及び停止することを担うサービス又はコマンドラインツールを含んでよい。制御ＡＰＩ実装２３０は、サービスの最上位に存在してよく、制御モジュール１２０が、データベースサーバをオンラインに遷移させるために、制御ＡＰＩの遷移機能を呼び出した場合、制御ＡＰＩ実装２３０は、データベースサーバを起動するためにデータベースサーバのサービスとの通信を処理してよい。データベースサーバを起動することの複雑さは、制御モジュール１２０から隠されてよい。制御モジュール１２０は、適切な制御ＡＰＩ呼び出しを生成するだけでよい。

【0062】

幾つかの実施形態では、動作エンティティ１１０は、制御モジュール１２０に、制御ＡＰＩ実装２３０により実装され従って呼び出し可能である制御ＡＰＩの機能をアドバタイズしてよい。幾つかの例では、動作エンティティ１１０は、インスタンス化されると、この情報をアドバタイズしてよい。他の例では、この情報は、制御モジュール１２０により要求されると、アドバタイズされてよい。例えば、制御モジュール１２０は、制御ＡＰＩ実装２３０に関する情報を受信するために、動作エンティティ１１０に「記述（describe）」機能ＡＰＩ呼び出しを発行してよい。幾つかの実施形態では、制御モジュール１２０は、制御ＡＰＩ実装２３０に関する情報を含むようインスタンス化されてよく、このような情報を受信するために動作エンティティ１１０と通信する必要がなくてよい。

【0063】

動作エンティティ１１０の制御ＡＰＩ実装２３０に関する知識を有すると、制御モジュール１２０は、命令を処理できるようになってよい。一例として、制御モジュール１２０は、論理データベースエンティティ１１０を生成するための命令を受信してよい。該制御モジュール１２０は、論理データベースエンティティ１１０を生成できるとアドバタイズするデータベースサーバエンティティ１１０を管理してよい。従って、制御モジュール１２０は、次に、論理データベースエンティティ１１０を生成するために、該データベースサーバエンティティ１１０に、生成機能ＡＰＩ呼び出しを発行してよい。しかしながら、制御モジュール１２０により維持される情報が、被管理動作エンティティ１１０が適切な機能をサポートしないので命令が処理できないと示す場合、制御モジュール１２０は命令を拒否してよい。幾つかの例では、制御モジュール１２０は、発行側の制御モジュール１２０に、命令は完了されなかった又は完了できないことを通知してよい。

【0064】

図３Ａを参照すると、データベース１３０内のブループリント２１０及び定義３１０のブロック図が示される。図示の実施形態で、ブループリント２１０及び定義３１０の両方は、エンティティデスクリプタ３２０、関係情報３３０、及び期待される状態変数３４５を含む変数３４０を含む。幾つかの実施形態では、ブループリント２１０及び／又は定義３１０は、図と異なる方法で実装されてよい。例えば、ブループリント２１０は、図示のような１つの定義３１０より多くの定義３１０に対応してよい。

【0065】

定義３１０は、種々の実施形態で、動作エンティティ１１０の態様を定義する情報の集合である。ブループリント２１０と同様に、定義３１０は、図示のようにエンティティデスクリプタ３２０、関係情報３６３０、及び変数３４０を含む。ブループリント２１０と対照的に、定義３１０は、動作エンティティ１１０の特定のインスタンスを定義しなくてよいが、代わりに、対応するブループリント２１０の中にどんな値が含まれ得るかを記述してよい。つまり、定義３１０は、ブループリント２１０がどのように見えるべきかを記述してよい。例えば、データベースフリートエンティティ１１０の定義３１０は、データベースフリートがデータベースサーバエンティティ１１０を含むことを記述してよく、一方で、対応するブループリント２１０は、特定のデータベースフリートエンティティ１１０が１５個のデータベースサーバエンティティ１１０を含むことを定義してよい。種々の場合において、定義３１０は、対応するブループリント２１０が許可されることを検証するために使用されてよい。上述の例を続けると、ブループリント２１０が特定のデータベースフリートエンティティ１１０が、１５個のデータベースサーバエンティティ１１０に加えてアプリケーションサーバエンティティ１１０を含むことを定義する場合、データベースフリートエンティティ１１０の定義３１０が、データベースフリートエンティティ１１０がアプリケーションサーバエンティティ１１０を含むことを記述しないので、ブループリント２１０は、拒否されてよい。幾つかの実施形態では、定義３１０は、所定の値を有する属性のセット、及びブループリントが展開されるときに値が対応するブループリント２１０の中に制御モジュール１２０により記述される属性のセット、を含んでよい。

【0066】

幾つかの実施形態では、ブループリント２１０は、複数の定義３２１０に対応してよい。例えば、特定のプラットフォームサービスエンティティ１１０のブループリント２１０は、プラットフォームサービスエンティティ１１０がデータベースサーバエンティティ１１０及びアプリケーションサーバエンティティ１１０を有するとして記述してよい。このように、ブループリント２１０は、データベースサーバエンティティ１１０の定義３１０、及びアプリケーションサーバエンティティ１１０の定義３１０に関連付けられてよい。種々の場合に、ブループリント２１０は、該ブループリントに関連付けられた定義３１０により指定される全部の関係を満たさない場合に、有効でなくてよい。例えば、アプリケーションサーバエンティティ１１０の定義３１０は、アプリケーションサーバエンティティ１１０がメトリックサーバエンティティ１１０に依存することを記述してよい。このように、前述の例のブループリント２１０は、それがメトリックサーバエンティティ１１０を記述しない限り、有効でなくてよい。従って、ブループリント２１０は、対応する定義３１０の中で定義された関係を満たすために、動作エンティティ１１０のセットがどのように一緒にされるかを記述してよい。

【0067】

エンティティデスクリプタ３２０は、種々の実施形態で、対応する動作エンティティ１１０の種々の属性を記述する情報の集合である。これらの属性は、全ての動作エンティティ１１０に渡り同じであってよいが、与えられた値は動作エンティティ１１０の間で異なってよい。例えば、エンティティデスクリプタ３２０は、動作エンティティ１１０がハードウェア、ソフトウェア、又は情報であるかを示すある種の属性を含んでよい。従って、プロセッサエンティティ１１０のエンティティデスクリプタ３２０はハードウェアを示してよく、一方で、メトリックサーバエンティティ１１０のエンティティデスクリプタ３２０はソフトウェアを指定してよい。種々の実施形態で、エンティティデスクリプタ３２０は、制御モジュール１２０に、対応する動作エンティティ１１０がどのように管理され得るかに関する情報を伝達する。前述の例を続けると、制御モジュール１２０は、プロセッサエンティティ１１０のエンティティデスクリプタ３２０が種類属性にハードウェアを指定するので、自身が該プロセッサエンティティ１１０を複製（クローン化、clone）できないことを知り得る。エンティティデスクリプタ３２０の種々の属性は、図３Ｂに関して更に詳述される。

【0068】

関係情報３３０は、種々の実施形態で、特定の動作エンティティ１１０と他の動作エンティティ１１０との間の関係を指定する情報の集合である。動作エンティティ１１０の間の関係は、全ての関係に渡り共通であってよいがそれらの値は関係と関係の間で異なってよい種々の属性を用いて定義されてよい。例えば、関係情報３３０は、関係毎に「タイプ」属性を含んでよい。アプリケーションサーバエンティティ１１０の関係情報３３０は、アプリケーションサーバエンティティ１１０とデータベースサーバエンティティ１１０との間に「依存」タイプ関係が存在することを指定してよい。エンティティデスクリプタ３２０と同様に、関係情報３３０は、制御モジュール１２０に、対応する動作エンティティ１１０がどのように管理され得るかに関する情報を伝達してよい。種々の場合に、動作エンティティ１１０の間の関係は、動作シナリオに対応するコマンドが実行され得る、該動作シナリオの実施され得る順序に影響してよい。前述の例を続けると、アプリケーションサーバエンティティ１１０はデータベースサーバエンティティ１１０に依存するので、制御モジュール１２０は、アプリケーションサーバエンティティ１１０の前に、該データベースサーバエンティティ１１０がインスタンス化される必要があることを知ってよい。関係情報３３０の種々の属性は、図３Ｃに関して更に詳述される。

【0069】

変数３４０は、種々の実施形態で、対応する動作エンティティ１１０を管理するのに有用な追加情報の集合である。図示のように、変数３４０は、期待される状態変数３４５を含む。期待される状態変数３４５は、種々の実施形態で、対応する動作エンティティ１１０の期待される状態を指定する。例えば、データベースサーバエンティティ１１０の期待される状態変数３４５は、「オンライン」の値を指定してよい。変数３４０は、現在状態、ＩＰ（Internet Protocol）ポートのような１つ以上のサービスエンドポイント、ＩＰアドレス、構成変数、等を指定するために使用されてよい。例えば、変数３４０は、どんな永久データストアを、特定のデータベースサーバエンティティ１１０が使用すべきかを、指定してよい。種々の実施形態で、変数３４０は階層的特性であってよい。変数３４０は、それらが展開時に又は別の時点で定義されるかのような属性を更に含んでよい。例えば、ＩＰアドレス変数３４０は、ＩＰアドレス変数３４０が対応する動作エンティティ１１０の展開中に満たされることを示す属性に関連付けられてよい。

【0070】

図３Ｂを参照すると、エンティティデスクリプタ３２０のブロック図が示される。図示の実施形態では、エンティティデスクリプタ３２０は、ユニバーサルにユニークなタイプ（universally unique type (UUT)）３２１、ライフサイクル３２２、バージョン３２３、種類３２４、ユニバーサルにユニークな識別子（universally unique identifier (UUI)）３２５、コンテキスト識別子３２６、ベンダ３２７、名称３２８、及び生成データ３２９を含む。エンティティデスクリプタ３２０は、図示のものより多くの又は少ない情報を含んでよい。例えば、エンティティデスクリプタ３２０は、名称３２８を含まなくてよい。

【0071】

ユニバーサルにユニークなタイプ３２１は、種々の実施形態で、動作エンティティ１１０のタイプ又は種類を示すデータ値を指定する。ＵＵＴ３２１の例は、限定ではないが、「データベースサーバ」、「アプリケーションサーバ」、「論理データベース」、「物理ホストシステム」、「データベースバックアップ」、「テナント」、「ワークフロー」、「ログ拡張」、及び「データ拡張」を含む。ＵＵＴ３２１は、幾つかの実施形態では、対応する定義３１０及び／又はブループリント２１０を探すためのキーとして使用されてよい。例えば、関係情報３３０は、それらのＵＵＴ３２１を使用する関係の動作エンティティ１１０を指定してよい。これは、それらのエンティティ１１０を管理するのに適切であり得る情報を取得するために、管理制御モジュール１２０が対応する定義３１０及びブループリント２１０にアクセスすることを可能にし得る。図８に関して更に詳述するように、ＵＵＴ３２１（種々の場合にライフサイクル３２２及びバージョン３２３を有する）は、特定の動作エンティティ１１０へ命令をルーティングするために更に使用されてよい。また、ＵＵＴ３２１は、ユーザがどんな動作エンティティ１１０がシステム１００内に存在するかを理解できるように、ユーザに表示されてよい。

【0072】

ライフサイクル３２２は、種々の実施形態で、動作エンティティ１１０がいるそれ自体のライフサイクル中にあるステージを示すデータ値を指定する。ライフサイクルステージの例は、限定ではないが、仕様、スナップショット、及びインスタンスを含む。例えば、データベースバックアップイメージは、データベースのスナップショットステージであってよい。ライフサイクル３２２は、動作エンティティ１１０に関して実行可能な動作のタイプに影響してよい。例えば、データベースサーバエンティティ１１０がそのインスタンスステージにあるとき、制御モジュール１２０は、該データベースサーバエンティティ１１０にデータベースバックアップイメージを生成するよう指示可能であってよい。しかしながら、該データベースサーバエンティティ１１０がその仕様ステージにある場合、制御モジュール１２０は、データベースサーバエンティティにデータベースバックアップイメージを生成するよう指示しなくてよい。種々の実施形態では、ライフサイクル３２２は、対応する定義３１０及び／又はブループリント２１０を探すためのキーとして、ＵＵＴ３２１と一緒に使用されてよい。幾つかの実施形態では、ライフサイクル３２２は、異なるライフサイクルステージの間のパスを提供し、例えば状態を通じて動作エンティティを遷移させる制御ＡＰＩ呼び出しを通じてソースコードからライブプロダクションソフトウェアへの、動作エンティティ１１０のパイプラインを自動化するために使用できる。

【0073】

バージョン３２３は、種々の実施形態で、動作エンティティ１１０のバージョンを示すデータ値を指定する。例えば、特定のデータベースサーバエンティティ１１０のバージョン３２３は、バージョン「３．２．４」を指定してよい。ライフサイクル３２２と同様に、バージョン３２３は、動作エンティティ１１０に関して実行可能な動作のタイプに影響してよい。例えば、動作エンティティ１１０のより新しいバージョンは、制御ＡＰＩの機能のうちの１つ以上について追加実装を含んでよい。種々の実施形態では、バージョン３２３は、特定の定義３１０及び／又はブループリント２１０を探すためのキーとして、ＵＵＴ３２１及びライフサイクル３２２の両方と一緒に使用されてよい。

【0074】

種類３２４は、種々の実施形態で、動作エンティティ１１０の形式又は明示（manifestation）（つまり、ハードウェア、ソフトウェア、情報、又は組成物）を示すデータ値を指定する。エンティティデスクリプタ３２０の他の属性と同様に、種類３２４は、動作エンティティ１１０が制御モジュール１２０によりどのように管理できるかに影響してよい。一例として、動作エンティティ１１０がソフトウェアの形式を取る場合、動作エンティティ１１０は、クローン化可能であってよいが、ハードウェアの形式を取る別の動作エンティティ１１０はクローン化できなくてよい。種々の実施形態で、種類３２４は、エンティティデスクリプタ３２０内の他の属性のためにどんな値が使用できるかに影響する。一例として、ソフトウェアの形式を取る動作エンティティ１１０は、スナップショットライフサイクルステージを有してよいが、ハードウェアである動作エンティティ１１０はそうでなくてよい。

【0075】

ユニバーサルにユニークな識別子（Universally unique identifier (UUID)）３２５は、種々の実施形態で、ブループリント２１０又は定義３１０により指定される任意の他の情報と独立に、動作エンティティ１１０をユニークに識別するデータ値を指定する。一例として、特定の動作エンティティ１１０は、「C７３６６F４－４BED－８BF０－BF２８１」のＵＵＩＤ３２５を有してよい。ＵＵＩＤ３２５は、特定の動作エンティティ１１０が制御モジュール１２０又はユーザにより直接参照されることを可能にし得る。これは、制御モジュール１２０が複数の同じタイプの動作エンティティ１１０（例えば、２つのデータベースサーバエンティティ１１０）を管理する状況での曖昧さを除去し得る。以下に更に詳述するように、所与のコマンドは、そのＵＵＩＤ３２５を用いて動作エンティティ１１０を具体的に識別してよい。このように、制御モジュール１２０は、所与のコマンドにより識別されるＵＵＩＤ３２５に基づき、該所与のコマンドを適切な管理制御モジュール１２０へルーティングしてよい。

【0076】

コンテキスト識別子（Contextual identifier (CID)）３２６は、種々の実施形態で、動作エンティティ１１０に関連付けられたコンテキストを示すデータ値を指定する。例えば、ＣＩＤ３２６は、対応する動作エンティティ１１０に関連付けられた組織／テナントの組織ＩＤを指定してよい。幾つかの実施形態では、ＣＩＤ３２６は、動作エンティティ１１０のメトリックをシステム１００の特定のテナントに関連付けるために使用されてよい。

【0077】

ベンダ３２７は、種々の実施形態で、動作エンティティ１１０に関連付けられたベンダを識別するデータ値を指定する。名称３２８は、種々の実施形態で、動作エンティティ１１０の名称、例えば、製品名、ワークフロー名、テナント名等を識別するデータ値を指定する。生成データ３２９は、種々の実施形態で、動作エンティティ１１０が生成された時間を（例えばエポックＵＴＣ以来のナノ秒単位で）識別するデータ値を指定する。

【0078】

図３Ｃを参照すると、関係情報３３０のブロック図が示される。図示の実施形態では、関係情報３３０は、関係３３１を含む。更に図示のように、関係３３１は、ＵＵＴ３２１、ライフサイクル３２２、バージョン３２３、関係タイプ３３２、方向３３３、濃度（cardinality）３３４、及び特性３３６を含む。関係３３１は、図示のものより多くの又は少ない情報を含んでよい。例えば、関係３３１は、バージョン３２３を含まなくてよい。

【0079】

多くの場合、システム１００内の動作エンティティ１１０は、何らかの方法で関連付けられてよい。一例として、別の動作エンティティ１１０からメトリック情報を集める動作エンティティ１１０は、該他のエンティティの存在に依存する。種々の実施形態で、動作エンティティ１１０が制御モジュール１２０により管理される方法は、動作エンティティと他の動作エンティティ１１０との間に存在する関係３３１に依存する。図示のように、エンティティの関係３３１は、関係情報３３０の中で定義され、複数の変数を含む。

【0080】

特定の動作エンティティ１１０が関連付けられる動作エンティティ１１０を識別するために、種々の実施形態で、関係３３１は、ＵＵＴ３２１、ライフサイクル３２２、及びバージョン３２３を指定する。例えば、制御モジュール１２０は、データベースサーバエンティティ１１０を制御してよい。代替として、制御モジュール１２０とデータベースサーバエンティティ１１０との間の関係に対応する関係３３１は、「データベースサーバ」のＵＵＴ３２１、「インスタンス」のライフサイクル３２２、及び「３．２１」のバージョン３２３を指定してよい。幾つかの実施形態では、関係３３１は、該関係に関連付けられた動作エンティティ１１０を具体的に識別するＵＵＩＤ３２５を示してよい。

【0081】

関係タイプ３３２は、種々の実施形態で、特定の動作エンティティ１１０と１つ以上の他の動作エンティティ１１０との間の関係のタイプを示すデータ値を指定する。関係のタイプは、限定ではないが、「ホスト」関係、「制御」関係、「依存」関係、「構成する」関係、「含まれる」関係、「小部分」関係、及び「提供」関係を含む。ホスト関係は、種々の実施形態で、特定の動作エンティティ１１０が１つ以上の他の動作エンティティ１１０をホスティングする関係である。一例として、データベースサーバエンティティ１１０は、論理データベースエンティティ１１０をホスティングしてよい。制御関係は、種々の実施形態で、特定の動作エンティティ１１０が１つ以上の他の動作エンティティ１１０を制御する関係である。一例として、制御モジュール１２０は、メトリックサーバエンティティ１１０及びデータベースサーバエンティティ１１０を制御してよい。依存関係は、種々の実施形態で、特定の動作エンティティ１１０が１つ以上の他の動作エンティティ１１０に依存する関係である。一例として、メトリックサーバエンティティ１１０は、存在するデータベースサーバエンティティ１１０に依存してよく、従ってメトリックサーバエンティティ１１０はメトリックを収集し得る。「構成する」関係は、種々の実施形態で、特定の動作エンティティ１１０が１つ以上の他の動作エンティティ１１０で構成される関係である。一例として、データベースサービスエンティティ１１０は、２つのデータベースサーバエンティティ１１０で構成されてよい。「含まれる」関係は、種々の実施形態で、特定の動作エンティティ１１０が１つ以上の他の動作エンティティ１１０に含まれる関係である。一例として、データベースサーバエンティティ１１０は、コンテナエンティティ１１０に含まれてよい。提供関係は、種々の実施形態で、特定の動作エンティティ１１０によりプロビジョニングされ得る１つ以上の動作エンティティ１１０を識別する関係である。一例として、コンテナ環境エンティティ１１０は、コンテナエンティティ１１０をプロビジョニング（提供）（又はインスタンス化）してよい。幾つかの実施形態では、特定の動作エンティティ１１０が自身を記述する「私は（Ｉ am）」関係が存在してよい。例えば、データベースサーバエンティティ１１０は、「データベースサーバ」の「I ａｍ」関係値を有してよい。

【0082】

方向３３３は、種々の実施形態で、特定の動作エンティティ１１０と１つ以上の他の動作エンティティ１１０との間の関係の方向を示すデータ値を指定する。方向３３３は、特定の動作エンティティ１１０が別の動作エンティティ１１０に従属するかどうかを示してよい。データベースサーバエンティティ１１０と論理データベースエンティティ１１０との間の関係が存在する一例を考える。データベースサーバエンティティ１１０の観点から定義された関係３３１は、「ホスト」の関係タイプ３３２及び「偽（false）」の方向３３３を指定してよい。論理データベースエンティティ１１０の観点から定義された関係３３１は、「ホスト」の関係タイプ３３２及び「真（true）」の方向３３３を指定してよい。２つの関係３３１の結果として生じる解釈は、データベースサーバエンティティ１１０が論理データベースエンティティ１１０をホスティングすること、及び論理データベースエンティティ１１０がデータベースサーバエンティティ１１０によりホスティングされることであってよい。別の例として、方向３３３は、制御モジュール１２０がデータベースサーバエンティティ１１０を制御することを（該制御部の関係情報３３０の中で）、及びデータベースサーバエンティティ１１０が該制御モジュールにより制御されることを（該データベースサーバの関係情報３３０の中で）、示してよい。

【0083】

濃度３３４は、種々の実施形態で、対応する関係タイプ３３２に関連付けられた動作エンティティ１１０の数（これは、対応する関係３３１が定義される特定の動作エンティティ１１０を除いてよい）を示すデータ値を指定する。例えば、データベースサービスエンティティ１１０は、３つのデータベースサーバエンティティ１１０で構成されてよい。結果として、濃度３３４は、データベースサービスエンティティの観点から、該データベースサービスエンティティ１１０と３つのデータベースサーバエンティティ１１０との間の関係３３１について「３」の値を指定してよい。

【0084】

特性３３５は、種々の実施形態で、対応する動作エンティティ１１０を管理するのに有用な追加データ値を指定する。特性３３５は、存在する関係の状態を関連する動作エンティティ１１０に通信するために、該関連する動作エンティティ１１０により使用されるプロトコルを指定してよい。ここで、これらの動作エンティティは、システム１００等の中に位置する。一例として、特性３３５は、特定関係の動作エンティティ１１０が起動し実行中であることを示してよい。異なる関係の状態はシステム１００内で変化するので、制御モジュール１２０は、関係情報３３０を更新してよい（例えば、特性３３５を更新する）。

【0085】

エンティティデスクリプタ３２０と同様の方法で、幾つかの実施形態では、関係３３１は、動作エンティティ１１０をどのように管理すべきかを理解するのを助けるために、制御モジュール１２０に情報を伝達してよい。メトリックサーバエンティティ１１０がデータベースサーバエンティティ１１０に依存する例を考える。制御モジュール１２０は、メトリックサーバエンティティ１１０を起動したいとき、メトリックサーバエンティティ１１０がデータベースサーバエンティティ１１０に依存している結果として、データベースサーバエンティティ１１０が先ず起動される必要があることを決定してよい。従って、制御部は、動作エンティティ１１０を状態間でどのように（例えば、オフラインからオンラインへ）遷移させるかに関して推理するために、定義３１０及びブループリント２１０からの情報と一緒に、関係情報３３０を使用してよい。関係情報３３０は、種々の実施形態で、システムのリソース利用を計算するために使用されてよい。例えば、コンテナエンティティ１１０は、ホストシステムエンティティ１１０により含まれてよい。コンテナエンティティ１１０は、従って、該ホストシステムのリソースの部分を使用する。同様に、コンテナエンティティ１１０に含まれるソフトウェアは、該コンテナのリソースの一部を使用する。この情報は、プロビジョニング及び自動化されたキャパシティ計画に有用であってよい。

【0086】

図３Ｄを参照すると、例示的な動作エンティティ１１０の間の関係のブロック図が示される。図示の実施形態では、動作エンティティ１１０Ａは、アプリケーションサーバエンティティであり、動作エンティティ１１０Ｂは、データベースサーバエンティティであり、動作エンティティ１１０Ｃは、メトリックサーバエンティティである。図示のように、動作エンティティ１１０Ｂは、動作エンティティ１１０Ａに依存し、動作エンティティ１１０Ａと１１０Ｃとの間に共依存関係が存在する。上述のように、動作エンティティ１１０の間の関係は、制御モジュール１２０がこれらの動作エンティティをどのように管理するかに影響してよい。例えば、動作エンティティ１１０～Ｃをインスタンス化するとき、制御モジュール１２０は、動作エンティティ１１０Ｂが動作エンティティ１１０Ａの存在に依存するので、動作エンティティ１１０Ｂの前に、動作エンティティ１１０Ａをインスタンス化してよい。

【0087】

図４を参照すると、制御モジュール１２０のブロック図が示される。図示の実施形態では、制御モジュール１２０は、動作エンティティ情報４１０、制御ＡＰＩ情報４２０、動作エンティティマネジャエンジン４３０、ワークフローエンジン４４０、及び推理エンジン４５０を含む。幾つかの実施形態では、制御モジュール１２０は、図と異なる方法で実装されてよい。例えば、制御モジュール１２０は、推理エンジン４５０を含まなくてよい。

【0088】

前述のように、制御モジュール１２０は、動作エンティティ１１０及び制御モジュール１２０を管理してよい。それらを管理するために、種々の実施形態で、制御モジュール１２０は、動作エンティティ情報４１０及び制御ＡＰＩ情報４２０を維持する。幾つかの場合には、制御モジュール１２０は、情報４１０及び４２０をローカルストレージに維持してよい。他の場合には、制御モジュール１２０は、情報４１０及び４２０をデータベース１３０に維持してよく、これは、ローカルストレージが永久的でないために、制御モジュール１２０が、自身がクラッシュしたとき、自身の取り残された場所で継続することを可能にできる。つまり、制御モジュール１２０がクラッシュした場合（又はそのコンテナがクラッシュした場合）、そのローカルストレージに格納された情報が、それと一緒に消えてしまうことがある。従って、制御モジュール１２０の動作エンティティ１１０の管理に関連する任意の情報は、不揮発性永久ストレージであってよいデータベース１３０に維持されてよい。更に他の場合には、制御モジュール１２０は、情報４１０及び４２０を、自身のローカルストレージ及びデータベース１３０の両方に維持してよい。

【0089】

インスタンス化されると、種々の実施形態で、制御モジュール１２０は、初期情報を提供するプロパティファイルを提供されてよい。この初期情報は、制御モジュール１２０のローカルストレージ及び／又はデータベース１３０の位置を識別してよい。該位置は、動作エンティティ情報４１０及び該制御モジュールに関連する制御ＡＰＩ情報４２０を含む。幾つかの場合には、プロパティファイルは、制御モジュール１２０が管理する責任のある動作エンティティ１１０を示してよく、該エンティティ１１０及び他の制御モジュール１２０に関してリッスンすべきポートを示してよい。種々の実施形態で、制御モジュール１２０は、自身のプロパティファイルを用いて情報４１０及び４２０にアクセスする。

【0090】

動作エンティティ情報４１０は、種々の実施形態で、制御モジュール１２０により管理される動作エンティティ１１０を記述する情報である。情報４１０は、被管理動作エンティティ１１０のブループリント２１０及び定義３１０を含んでよい。種々の実施形態で、動作エンティティマネジャエンジン４３０は、自身の動作エンティティ１１０の意図された状態を決定するために、動作エンティティ情報４１０を使用する。このような知識により、マネジャエンジン４３０は、自身の動作エンティティ１１０を（例えば、制御ＡＰＩ呼び出しを発行することにより）、それらの意図された状態へと遷移させてよい。幾つかの場合には、制御モジュール１２０は、動作エンティティ情報４１０を含むようインスタンス化されてよい。また幾つかの場合には、制御モジュール１２０は、動作エンティティ１１０から情報４１０（例えば、ブループリント２１０）を読み出すために、自身の動作エンティティ１１０へ制御ＡＰＩ呼び出しを発行してよい。

【0091】

制御ＡＰＩ情報４２０は、種々の実施形態で、制御モジュール１２０により管理される動作エンティティ１１０により実施される制御ＡＰＩの機能を示す情報である。上述のように、種々の実施形態で、動作エンティティ１１０は、制御ＡＰＩの１つ以上の機能を実装する制御ＡＰＩ実装２３０を含む。制御ＡＰＩ実装２３０を通じて、制御モジュール１２０は、動作エンティティ１１０の要素２２０とインタフェースしてよい。従って、制御ＡＰＩ情報４２０は、制御ＡＰＩ実装２３０により実装される１つ以上の機能を示してよい。幾つかの場合に、制御モジュール１２０は、該制御モジュール１２０が制御ＡＰＩ情報４２０を含むようインスタンス化されてよい。幾つかの場合には、制御モジュール１２０は、自身の管理する動作エンティティ１１０から制御ＡＰＩ情報４２０を受信するために、該動作エンティティ１１０へ（制御ＡＰＩの）「記述」機能呼び出しを発行してよい。種々の実施形態で、各動作エンティティ１１０は、「記述」機能呼び出しを実装し得ることに留意する。

【0092】

種々の実施形態で、制御ＡＰＩ情報４２０は、動作エンティティ１１０に関する特定の情報を該動作エンティティ１１０の実装する機能にマッピングする機能マップを含む。種々の実施形態で、機能にマッピングされた情報は、動作エンティティのＵＵＴ３２１及びライフサイクル３２２を含んでよい。幾つかの場合には、動作エンティティ１１０は、異なるライフサイクルステージについて同じＡＰＩ機能呼び出しの異なる実装を含んでよいことに留意する。図８に関して更に詳述されるように、制御モジュール１２０は、動作エンティティのＵＵＴ３２１、ライフサイクル３２２、及び／又はＵＵＩＤ３２５を使用して、コマンドをルーティングしてよい。

【0093】

動作エンティティマネジャエンジン４３０は、種々の実施形態では、動作エンティティ１１０を管理するために実行可能なソフトウェアルーチンのセットである。制御モジュール１２０は、種々の場合に、動作エンティティ１１０と考えられてよく、それは定義３１０及びブループリント２１０に関連付けられてよいことに留意する。このように、マネジャエンジン４３０は、制御モジュール１２０も管理してよい。動作エンティティ１１０及び制御モジュール１２０を管理するために、種々の実施形態で、マネジャエンジン４３０は、種々のモジュール、例えばスケジューラモジュール、スイーパモジュール、健全性評価モジュール、及び調査モジュールを含む。

【0094】

スケジューラモジュールは、種々の実施形態で、制御モジュール１２０により管理されている動作エンティティ１１０を変化させるときを決定する機能のセットである。種々の実施形態で、スケジューラモジュールは、マネジャエンジン４３０の他のコンポーネントにより実行されるためにそれらをスケジューリングすることにより、アクションを実行させる。スケジューラモジュールは、宣言型（declarative）（例えば、「この動作エンティティ１１０はこの意図された状態であるべきだ」）又は命令型（imperative）（「ＤＢのスナップショットを生成しなさい」）であってよい。アクションをスケジューリングするために、スケジューラモジュールは、スケジューリングされた時間と共に要求されたアクション（例えば、ユーザからのコマンド）をローカルストレージ及び／又はデータベース１３０に書き込んでよい。スケジューラモジュールは、スケジューリングされたアクションの進捗及び結果も、ローカルストレージ及び／又はデータベース１３０に書き込んでよい。このような情報は、データベース１３０に書き込まれてよい。その結果、制御モジュール１２０がクラッシュした場合、制御モジュール１２０の新しいインスタンスが、他方のインスタンスがクラッシュした場所をピックアップし得る。種々の場合に、スケジューラモジュールは、スイーパモジュールが動作エンティティ１１０を調査する（probe）時間をスケジューリングしてよい。

【0095】

スイーパモジュールは、種々の実施形態で、動作エンティティ１１０の健康状態（健全性、health）に関する情報（例えば、容量に対するリソース利用率、主要健全性指示子、等）を集めるために管理されている該動作エンティティ１１０を調査する機能のセットである。幾つかの実施形態では、スイーパモジュールは、（永久的であってよい）ローカルストレージ及又はデータベース１３０から動作エンティティ情報４１０を読み出す。動作エンティティ情報４１０から、スイーパモジュールは、動作エンティティ１１０の制御モジュール１２０により管理されている該動作エンティティ１１０について、及びそれらにどのように接続するかについて、知ることができる。スイーパモジュールは、次に、それらの動作エンティティを調査してよい。幾つかの実施形態では、スイーパモジュールは、状態要求メッセージを、リストされた動作エンティティ１１０の各々へ送信する。該メッセージは、該動作エンティティ１１０の現在状態を詳述する情報を要求する。スイーパモジュールが最初に状態要求メッセージを送信する代わりに、幾つかの実施形態では、動作エンティティ１１０が、自身の現在状態を示す情報を、スイーパモジュールへ定期的に送信してよい。種々の実施形態で、スイーパモジュールは、動作エンティティ１１０から受信した情報を、動作エンティティ情報４１０の一部として格納する。このような情報は、リソース利用率、リソース容量、当該動作エンティティ１１０の状態（例えば、オフライン、オンライン、等）、当該動作エンティティの状態の他の動作エンティティ１１０との関係（例えば、他の動作エンティティ１１０が応答者ではない）、等を示してよい。スイーパモジュールは、調査されるべき「出来事（incident）」としてトリガされ得る任意の警告を格納してよい。一例として、スイーパモジュールは、動作エンティティ１１０から連絡がない場合、該動作エンティティ１１０が健全ではない可能性があるという指示を格納してよい。もはや動作上関連しない情報（例えば、古い、無意味なレコード）は、ローカルストレージ及び／又はデータベース１３０から除去されてよい。

【0096】

健全性評価モジュールは、種々の実施形態で、スイーパモジュールにより取得された情報を用いて、被管理動作エンティティ１１０の健全性を評価する機能のセットである。種々の実施形態では、健全性評価モジュールは、ローカルストレージ又はデータベース１３０から動作エンティティ情報４１０を読み出す。健全性評価モジュールは、次に、動作エンティティ情報４１０に基づき、動作エンティティ１１０を調査するよう調査モジュールをトリガするためにレポートを生成すべきか否かを決定してよい。例えば、健全性評価モジュールは、動作エンティティ１１０のリソース利用率を評価してよく、リソース利用率が然るべきものと比べて高すぎる又は低すぎる場合、健全性評価モジュールは、該動作エンティティ１１０についてレポートを生成してよい。種々の実施形態で、健全性評価モジュールは、過去の動作エンティティ情報４１０に基づき、更なるイベントを予測することを試みてよい。例えば、動作エンティティ１１０が、該動作エンティティ１１０が障害になって終わる特定の傾向に従う兆候を示した場合、健全性評価モジュールは、先取り的に該動作エンティティを調査させるためにレポートを生成してよい。

【0097】

調査モジュールは、種々の実施形態で、動作エンティティ１１０を検査する機能のセットである。調査モジュールは、未だ調査されていないレポートをチェックしてよい。各レポートについて、調査モジュールは、関連する動作エンティティ１１０に関する情報を収集してよい。このような情報は、システム１００の他のコンポーネント又はユーザにより任意の問題をトラブルシュートするために利用されてよい。例えば、調査モジュールは、動作エンティティ１１０が障害になる前に、動作エンティティ１１０により実行される動作を詳述するログ情報を収集してよい。種々の場合に、調査モジュールは、全ての健全でないエンティティの関係情報３３０へのアクセスを有してよい。例えば、調査モジュールは、健全でない別のサービスエンティティ１１０に依存する健全でないデータベースサーバエンティティ１１０の関係情報３３０へのアクセスを有してよい。データベースサーバエンティティ１１０が健全でないという事実は、単に兆候である場合があり、調査すべき場所は、実際には、それが依存するサービスによってよい。従って、調査モジュールは、データベースサーバエンティティ１１０に問題を生じるかどうかを決定するために、当該サービスの健全性をドリルダウン（drill down ）する制御ＡＰＩを使用してよい。幾つかの実施形態では、調査モジュールは、自身の発見した任意の問題をトラブルシュートすることを試みてよい。例えば、調査モジュールは、クラッシュした動作エンティティ１１０を再起動／再初期化するためのコマンドのセットを発行してよい。調査モジュールは、自動化された調査が完了した後に、レポートの状態及び所有権を更新してよい（例えば、自動調査が問題をトラブルシュートすることに失敗した場合、所有権はユーザに移転されてよい）。

【0098】

従って、種々の実施形態で、スイーパモジュールは、制御モジュール１２０により管理される動作エンティティ１１０に関する健全性情報を集める。健全性情報は、それらの動作エンティティ１１０に問題があるかどうかを決定するために、健全性評価モジュールにより評価されてよい。潜在的な問題がある場合、問題は、更なる分析のために調査モジュールに報告されてよい。

【0099】

幾つかの実施形態では、動作エンティティマネジャエンジン４３０は、動作エンティティ１１０（幾つかの場合には、マネジャエンジン４３０の配下にあるもの）の管理に関する命令を受信してよい。マネジャエンジン４３０の配下にない動作エンティティ１１０に関する命令については、マネジャエンジン４３０は、該命令を処理のために適切な制御モジュール１２０へとルーティングしてよい。幾つかの場合には、マネジャエンジン４３０は、命令を、該命令に含まれる情報、例えば対応する動作エンティティ１１０のＵＵＩＤ３２５の値に基づきルーティングしてよい。例えば、マネジャエンジン４３０は、ＵＵＩＤ３２５の値に基づき、該ＵＵＩＤ３２５の値に対応する動作エンティティ１１０を管理する特定の制御モジュール１２０を決定してよい。従って、マネジャエンジン４３０は、対応する命令を、処理のために、該制御モジュール１２０へとルーティングしてよい。

【0100】

マネジャエンジン４３０の管理下にある動作エンティティ１１０に関する命令については、マネジャエンジン４３０は命令を処理してよい。該命令は、１つ以上の動作エンティティ１１０の変化する状態を含んでよい。種々の場合に、マネジャエンジン４３０は、制御ＡＰＩのどの機能が呼び出すために利用可能であるかを決定するために、制御ＡＰＩ情報４２０にアクセスしてよい。目例は、対応する動作エンティティ１１０、及び該動作エンティティに関して実行されるべき機能を識別してよい。従って、（制御ＡＰＩ情報４２０から決定され得るように）適切な制御ＡＰＩ機能が動作エンティティ１１０により実装されている場合、マネジャエンジン４３０は、該制御ＡＰＩ機能を実行するために、制御ＡＰＩ呼び出しを動作エンティティ１１０へ送信してよい。幾つかの例では、マネジャエンジン４３０は、下の動作エンティティ１１０に変更を行うために、別の動作エンティティ１１０の制御ＡＰＩ機能実装を呼び出してよい。制御ＡＰＩ呼び出しを発行する際に、マネジャエンジン４３０は、受信した命令を実行してよい。

【0101】

ワークフローエンジン４４０は、種々の実施形態では、ワークフローを実施するために実行可能なソフトウェアルーチンのセットである。上述のように、動作シナリオは、該動作シナリオのステップシーケンスを実施するコマンドセットを含むワークフローの中で記述されてよい。コマンドは、特定の動作エンティティ１１０上で実行されるべき動作（例えば、状態変化）を識別してよい。種々の実施形態で、ワークフローエンジン４４０は、動作エンティティ１１０及び／又は制御モジュール１２０へ、ワークフローのコマンドを実行するための命令を発行することにより、ワークフローを実施する。一例として、ワークフローエンジン４４０は、（制御モジュール１２０により管理されている）動作エンティティ１１０の状態を「オフライン」から「オンライン」へと変化させる命令を、制御モジュール１２０へ発行してよい。種々の場合に、ワークフローエンジン４４０は、データベース１３０からワークフローを取得してよい。幾つかの場合には、ワークフローエンジン４４０は、推理エンジン４５０からワークフローを取得してよい。

【0102】

推理エンジン４５０は、種々の実施形態では、上位レベルの目標に基づきワークフローを生成するために実行可能なソフトウェアルーチンのセットである。推理エンジン４５０は、最初に、ユーザから、特定の上位レベルの目標を実施するための要求を受信してよい。例えば、ユーザは、データベースサーバエンティティ１１０があるバージョンから別のバージョンへとアップグレードされることを要求してよい。推理エンジン４５０は、種々の実施形態で、目標を実施するコマンドセットを有するワークフローを生成するために、要求された上位レベルの目標について「推理」する。幾つかの例では、推理エンジン４５０の出力（例えば、ワークフロー）は、出力を介して上位レベルの目標を実施するために、ワークフローエンジン４４０に提供されてよい。推理エンジン４５０は、システム１００の開発者により記述されなければならない特定の動作コードの量を大幅に削減し得る。推理エンジン４５０は、図１７に関して更に詳述される。

【0103】

図５を参照すると、方法５００のフロー図が示される。方法５００は、目標コンピュータ環境（例えば、目標環境１３７）の（例えば、動作情報１３５の中の）動作シナリオを管理するために、コンピュータシステム（例えば、システム１００）により実行される方法の一実施形態である。方法５００は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの場合には、方法５００は、コンピュータシステムがユーザから要求を受信することに応答して実行されてよい。幾つかの実施形態では、方法５００は、追加ステップを含んでよい。一例として、コンピュータシステムは、ブループリント（例えば、ブループリント２１０）を有効にするために、定義（例えば、定義３１０）にアクセスしてよい。

【0104】

方法５００は、ステップ５１０で開始し、コンピュータシステムが、動作シナリオのコマンドセットを定義する動作情報（例えば、動作情報１３５）にアクセスする。動作シナリオは、動作エンティティセットに含まれる１つ以上のソフトウェアエンティティの状態を変化させて、１つ以上のソフトウェアエンティティを第１ソフトウェアバージョンから第２ソフトウェアバージョンに遷移させることを含んでよい。

【0105】

ステップ５２０で、コンピュータシステムは、動作シナリオを実施するために目標コンピュータ環境で利用されるべき、動作エンティティ（例えば、動作エンティティ１１０）のセットのブループリント（例えば、ブループリント２１０）にアクセスする。所与のブループリントは、動作エンティティセットのうちの第１動作エンティティについて、第１動作エンティティと該動作エンティティセットのうちの１つ以上の他の動作エンティティとの間の関係（例えば、関係３３１）のセットを示してよい。動作エンティティセットは、ハードウェアエンティティ（例えば、プロセッサのセット）、ソフトウェアエンティティ（例えば、プロセッサのセットのうちの少なくとも１つのプロセッサ上で実行するデータベースサーバ）、及び情報エンティティ（例えば、データベースサーバにより管理される論理データベース）を含んでよい。

【0106】

ステップ５３０で、コンピュータシステムは、目標コンピュータ環境のための動作シナリオを実施する。種々の場合に、動作シナリオを実施するステップは、制御モジュール（例えば、制御モジュール１２０）の階層構造を実行するステップを含んでよく、階層構造は、該階層構造の最上位にある、該階層構造の次のレベルにある制御モジュールへ命令を発行することによりコマンドセットを実行するために実行可能なオーケストレータ制御モジュールを含んでよい。種々の場合に、制御モジュールの階層構造は、動作エンティティセットのうちの１つ以上の動作エンティティの状態を変化させることにより、動作シナリオを達成するためにそれぞれのブループリントに従い動作エンティティセットを管理するよう動作可能な制御モジュールを含んでよい。幾つかの場合には、動作エンティティセットのうちの第１動作エンティティは、階層構造の中で、動作エンティティセットのうちの第２動作エンティティと異なるレベルにあってよい。従って、動作エンティティセットを管理するために実行可能な制御モジュールのうちの制御モジュールは、階層構造の異なるレベルにあってよい。

【0107】

幾つかの実施形態では、所与の動作エンティティは、制御アプリケーションプログラミングインタフェース（application programming interface (API)）によりサポートされる機能のセット（例えば、制御ＡＰＩ実装２３０）のうちの１つ以上を実装する。１つ以上の実施された機能は、制御モジュールが所与の動作エンティティの状態を変化させることを可能にし得る。種々の場合に、ブループリントのうちの特定の１つは、所与の動作エンティティに関連付けられてよく、該所与の動作エンティティに関連付けられた現在ライフサイクルステージ（例えば、仕様ステージ）を示すライフサイクル値（例えば、ライフサイクル３２２の値）を指定してよい。ライフサイクル値は、１つ以上の実施された機能のうちのどれがライフサイクルステージのために呼び出し可能であるかを決定するために、制御モジュールにより使用可能であってよい。

【0108】

幾つかの実施形態では、所与の動作エンティティは、該所与の動作エンティティをユニークに識別し得るユニーク識別子（例えば、ＵＵＩＤ３２５の値）に関連付けられる。命令のうちの特定の１つは、所与の動作エンティティに関連付けられてよい。幾つかの場合には、特定の命令を発行するステップは、ユニーク識別子に基づき、制御モジュールのうちの、該所与の動作エンティティを管理する特定の１つを決定するステップと、該特定の命令を該特定の制御モジュールに発行するステップと、を含んでよい。特定の命令は、ソフトウェアエンティティ（例えば、データベースサーバ）に、別の情報エンティティ（例えば、論理データベース）をインスタンス化させることを含んでよい。

【0109】

幾つかの実施形態では、第１動作エンティティについて指定された関係セットが、コマンドセットのうちのコマンドが実行され得る順序に影響する。幾つかの場合には、関係セットは、第１動作エンティティと動作エンティティセットのうちの第２動作エンティティとの間の関係を含んでよい。このように、第１動作エンティティの状態を変化させるために命令のうちの特定の１つを実行するステップは、第１動作エンティティの状態を変化させる前に、第２動作エンティティの状態を変化させるステップを含んでよい。幾つかの場合には、第１動作エンティティと第２動作エンティティとの間の関係は、第１動作エンティティが第２動作エンティティの存在に依存するという依存関係であってよい。

【0110】

図６を参照すると、方法６００のフロー図が示される。方法６００は、動作エンティティ（例えば、動作エンティティ１１０）のセットを管理するために、コンピュータシステム（例えば、システム１００）により実行される方法の一実施形態である。方法６００は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの実施形態では、方法６００は、追加ステップを含んでよい。一例として、コンピュータシステムは、動作情報（例えば、動作情報１３５）を格納するデータベース（例えば、データベース１３０）を維持してよい。

【0111】

方法６００は、ステップ６１０で開始し、コンピュータシステムが、制御モジュール（例えば、制御モジュール１２０）の階層構造を実行する。階層構造は、該階層構造の一番上にあり、動作エンティティセットを管理するために階層構造の中の他の動作エンティティと通信するよう動作するオーケストレータ制御モジュールを有する。種々の場合に、動作エンティティセットは、ハードウェアエンティティ、ソフトウェアエンティティ、及び情報エンティティを含んでよい。

【0112】

ステップ６２０で、オーケストレータ制御モジュールは、動作エンティティセットに関連する動作シナリオのステップシーケンスを実施するためのコマンドを有するワークフローを指定する動作情報（例えば、動作情報１３５）にアクセスする。

【0113】

ステップ６３０で、オーケストレータ制御モジュールは、動作シナリオを実施するために、ワークフローのコマンドを実施する。幾つかの場合には、コマンドを実施するステップは、動作エンティティセットのうちの１つ以上の動作エンティティの状態を変化させるために、他の制御モジュールのうちの１つ以上に、命令を発行するステップを含んでよい。階層構造の中の特定の制御モジュールは、動作エンティティセットの属性（例えば、ＵＵＴ３２１、ライフサイクル３２２、バージョン３２３、等）を定義するそれぞれのブループリント（例えば、ブループリント２１０）に従い、動作エンティティセットを管理するよう動作してよい。幾つかの実施形態では、属性は、動作エンティティセットのうちの動作エンティティの間の関係（例えば、関係３３１）に関する情報を定義する関係属性（例えば、関係タイプ３３２、方向３３３、等）を含む。これらの関係は、１つ以上の動作エンティティの状態が命令に基づき変化されるべき順序に影響してよい。

【0114】

幾つかの場合には、１つ以上の他の制御モジュールは、オーケストレータ制御モジュールから受信された命令のうちの１つ以上の命令を、動作エンティティセットを管理する特定の制御モジュールへルーティングするよう動作してよい。幾つかの場合には、１つ以上の他の制御モジュールは、動作エンティティセットに対応するユニーク識別子（例えば、ＵＵＩＤ３２５）のセットに基づき、１つ以上の命令をルーティングするよう動作してよい。

【0115】

図７を参照すると、制御ＡＰＩ７００のブロック図が示される。図示の実施形態では、制御ＡＰＩ７００は、記述機能７１０、フェッチ機能７２０、遷移機能７３０、生成機能７４０、破棄機能７５０、混乱（perturb）機能７６０、検証機能７７０、及び分析機能７８０を含む。種々の実施形態では、制御ＡＰＩ７００は、図示のものより多くの機能を含んでよい。例えば、制御ＡＰＩ７００は、制御モジュール１２０が動作エンティティ１１０により維持されているログ情報を読み出すことを可能にするログ機能を含んでよい。

【0116】

制御ＡＰＩ７００は、種々の実施形態で、動作エンティティ１１０からの情報にアクセスするために、動作エンティティ１１０の特長を変化させるために（例えば、当該エンティティを別のエンティティへと遷移させる）、及び／又は動作エンティティ１１０により管理されてる別の動作エンティティ１１０を変化させるために、呼び出し可能な機能又はＡＰＩの集合である。制御ＡＰＩ７００は、システム１００内の全部の動作エンティティ１１０に渡り共通である選択された機能セットを含んでよいが、その機能は動作エンティティ１１０毎に個別に定義される。例えば、制御ＡＰＩ実装２３０Ａ及び２３０Ｂは、それぞれ、動作エンティティ１１０を生成するための生成機能７４０を定義するが、制御ＡＰＩ実装２３０Ａにより生成された特定のタイプの動作エンティティ１１０は、制御ＡＰＩ実装２３０Ｂにより生成された特定のタイプと異なってよい。種々の実施形態で、動作エンティティ１１０は、同じタイプの機能の複数の異なる実装をサポートしてよい。一例として、データベースサーバエンティティ１１０は、生成機能７４０の２つの実装をサポートしてよい。１つは、論理データベースエンティティ１１０を生成するためであり、もう１つはバックアップイメージエンティティ１１０を生成するためである。幾つかの場合には、動作エンティティ１１０は、制御ＡＰＩ７００により提供される全部の機能をサポートしなくてよい。例えば、混乱機能７６０は、論理データベースエンティティ１１０については実施されなくてよい。

【0117】

記述機能７１０は、種々の実施形態で、動作エンティティ１１０に関する情報を返す。情報は、動作エンティティ１１０のブループリント２１０、定義３１０、及び／又は自信の制御ＡＰＩ実装２３０に関する情報を含んでよい。制御モジュール１２０が、どの動作エンティティ１１０に特定の動作エンティティ１１０が依存するかを発見したいと望む例を考える。該制御モジュール１２０は、該特定の動作エンティティ１１０の記述機能７１０を呼び出して、そのブループリント２１０を受信してよい。該ブループリント２１０は、特定の動作エンティティ１１０の関係３３１を識別してよい。幾つかの場合には、記述機能７１０は、他の機能（例えば、機能７２０、７３０、等）のうちのどれが、動作エンティティの制御ＡＰＩ実装２３０の中に実装されているかを決定するために呼び出されてよい。従って、幾つかの実施形態では、各動作エンティティ１１０は記述機能７１０を定義し、従って、制御モジュール１２０は、それらの動作エンティティ１１０について知る保証された方法を有し得る。

【0118】

フェッチ機能７２０は、種々の実施形態で、動作エンティティ１１０の１つ以上の変数３４０をフェッチする。一例として、制御モジュール１２０は、動作エンティティ１１０のフェッチ機能７２０を呼び出して、該動作エンティティが「オンライン」か「オフライン」かを示す特定の変数３４０にアクセスしてよい。フェッチ機能７２０を呼び出すとき、制御モジュール１２０は、要求された変数３４０をフェッチ機能７２０への入力として指定してよい。幾つかの場合には、制御モジュール１２０は、記述機能７１０を呼び出して、どの変数３４０が特定の動作エンティティ１１０からその制御ＡＰＩ実装２３０を介して要求されたかを決定してよい。幾つかの実施形態では、フェッチ機能７２０から返された情報は、返された変数３４０の特定の特性を示してよい。このような特性は、変数３４０の名称、その値、該変数の可能な最小値及び最大値、データ型（例えば、ブール、整数、文字列、浮動小数、等）、情報タイプ（例えば、カウンタ、率、等）、単位タイプ（例えば、秒、キロバイト、等）、及びフラグ（例えば、変化する、標準的、等）を含んでよい。例えば、フェッチ機能７２０は、「状態」という名称、「オンライン」という値、及び「変化する」フラグを有する変数３４０を指定する情報を返してよい。

【0119】

遷移機能７３０は、種々の実施形態で、動作エンティティ１１０の１つ以上の変数３４０（又はエンティティデスクリプタ３２０及び／又は関係情報３３０に含まれる値のような他の情報）を、第１値から第２値へと遷移させ又は変化させる。一例として、データベースサーバエンティティ１１０の遷移機能７３０は、状態変数３４０を「オフライン」から「オンライン」へと変化させるために呼び出されてよい。データベースサーバエンティティ１１０の制御ＡＰＩ実装２３０は、データベースサーバエンティティ１１０にオフラインからオンラインへと遷移させるソフトウェアルーチンを呼び出してよい。制御ＡＰＩ実装２３０は、次に、状態変数３４０を「オフライン」から「オンライン」へと更新してよい。該制御ＡＰＩ実装２３０は、データベースサーバをオンライン状態へと遷移させる基礎にある複雑性を、遷移機能７３０を呼び出す制御モジュール１２０から隠してよい。つまり、制御モジュール１２０の観点から、遷移機能７３０の呼び出しは、変数３４０を変化させてよく、一方で制御ＡＰＩ実装２３０は、実際には該変数の変化により示される変化を実施してよい。このように、種々の実施形態で、遷移機能７３０は、制御モジュール１２０が、第１状態から第２状態へ動作エンティティ１１０を遷移させることを可能にする。

【0120】

遷移機能７３０を使用する他の例は、動作エンティティ１１０を新しいバージョンに更新すること、動作エンティティ１１０が他の動作エンティティ１１０を生成することを無効化すること、動作エンティティ１１０の構成仕様を変更すること、動作エンティティ１１０をシャットダウンすることを、等を含んでよい。種々の実施形態で、動作シナリオを実施するステップは、複数の動作エンティティ１１０に、それらの状態を変化させるために、複数の遷移機能７３０呼び出しを発行するステップを含んでよい。

【0121】

生成機能７４０は、種々の実施形態で、動作エンティティ１１０に別の動作エンティティ１１０を生成させる。例えば、データベースサーバエンティティ１１０は、論理データベースエンティティ１１０を生成するために生成機能７４０を実施してよい。結果として、制御モジュール１２０は、望ましい場合には、論理データベースエンティティ１１０を生成するために生成機能７４０を呼び出してよい。種々の実施形態で、動作エンティティ１１０は、他の動作エンティティに対して又は他の動作エンティティの代わりに、アクションを実行し得るという点で、動作エンティティ１１０は、他の動作エンティティ１１０を制御してよい。種々の場合に、別の動作エンティティ１１０を制御する動作エンティティ１１０は、該他の動作エンティティを生成し、破棄し、リストし、及び／又は記述する能力を有してよい。幾つかの場合には、動作エンティティ１１０は、別の動作エンティティと同じである動作エンティティをクローン化することにより、該別の動作エンティティ１１０を生成してよい。幾つかの場合には、動作エンティティ１１０は、別の動作エンティティをそのライフサイクルステージに沿って遷移させることにより、該別の動作エンティティ１１０を生成してよい。例えば、データベース永続性をインスタンスステージからスナップショットステージへと遷移させることにより、データベース永続性のスナップショットを生成する。種々の実施形態で、生成機能７４０は、新しい動作エンティティ１１０を生成するための基礎（例えば、ディスクイメージファイル）を識別するソース情報を入力として受信する。

【0122】

破棄機能７５０は、種々の実施形態で、システム１００から動作エンティティ１１０を破棄／削除する。幾つかの場合には、制御モジュール１２０は、特定の動作エンティティ１１０の破棄機能７５０を呼び出して、動作エンティティがもはやシステム１００内で必要ないことに応答して、該動作エンティティを破棄する。例えば、高いトラフィック需要の存在したときに生成されたデータベースサーバエンティティ１１０は、少ないトラフィックしか存在しないときには破棄されてよい。幾つかの場合には、動作エンティティ１１０の破棄機能７５０は、該動作エンティティが機能不全である場合に、呼び出されてよい。制御モジュール１２０は、次に、同じタイプの動作エンティティ１１０のもう１つをインスタンス化してよい。

【0123】

混乱機能７６０は、種々の実施形態で、動作エンティティを異常に動作させることにより、動作エンティティ１１０を混乱させる。例えば、特定の動作エンティティ１１０の混乱機能７６０は、該動作エンティティに障害を注入してよい。このような障害は、例えば、特定の動作エンティティ１１０にクラッシュ、ハング、又はシャットダウンさせることを含んでよい。図２４に関して更に詳述されるように、混乱機能７６０は、システム１００が問題から復旧できるかを調べるために、システム１００内に問題を生じさせることにより、システム１００をテストする際に役立ち得る。

【0124】

検証機能７７０は、種々の実施形態で、動作エンティティ１１０を正しさについて検証する。例えば、制御モジュール１２０は、動作エンティティ１１０の検証機能７７０を呼び出して、該動作エンティティの構成及び／又は環境が正しいかを決定してよい（例えば、構成が適切な値を使用しているかどうかを決定する）。分析機能７８０は、種々の実施形態で、動作エンティティ１１０に関するメトリック情報を集める。一例として、制御モジュール１２０は、動作エンティティ１１０の分析方法を呼び出して、該動作エンティティ１１０からエラーログを取得してよい。

【0125】

図８を参照すると、ルーティングエンジン８１０及びルーティング可能エンティティ８３０のブロック図が示される。図示の実施形態で、制御モジュール１２０は、ルーティングエンジン８１０を有する動作エンティティマネジャエンジン４３０を含む。更に図示のように、ルーティング可能エンティティ８３０Ａは、制御モジュール１２０に関してローカルに位置し（例えば、同じネットワーク上に位置し）、一方で、ルーティング可能エンティティ８３０Ｂは、制御モジュール１２０に関してリモートに位置する。

【0126】

上述のように、動作エンティティ１１０及び制御モジュール１２０は、最上位にオーケストレータ制御モジュール１２０を有する階層構造を形成してよい。動作シナリオを実施するとき、オーケストレータ制御モジュール１２０は、階層構造を通じて、動作エンティティ１１０を管理する制御モジュール１２０へ命令を発行してよい。このような制御モジュール１２０は、それらの被管理動作エンティティ１１０により実施される制御ＡＰＩ７００の適切な機能を呼び出すために、制御ＡＰＩ呼び出しを発行することにより、受信した命令を実行してよい。制御ＡＰＩ７００の機能を呼び出すことにより、制御モジュール１２０は、動作エンティティ１１０の状態を変化させてよい。

【0127】

命令は、種々のソースから受信され及び／又はアクセスされてよい。幾つかの場合には、命令は、最初に、（ユーザにより又はアドホックスクリプトにより入力された）人間により読み取り可能なコマンドを制御モジュール１２０により理解される命令に変換するコマンドラインツールから受信されてよい。コマンドラインに入力されたコマンドから導出された命令は、最初に、オーケストレータ制御モジュール１２０により受信されてよい。オーケストレータ制御モジュール１２０は、命令を、動作エンティティ１１０及び制御モジュール１２０の階層構造を通じて伝搬させてよい。種々の場合に、命令は、データベース１３０に格納されたワークフロー情報から導出されてよい。従って、（例えば、コマンドラインツールを介して）命令された後に、オーケストレータ制御モジュール１２０は、データベース１３０からのワークフロー情報にアクセスし、階層構造を通じてワークフロー情報に関連付けられた命令を伝搬させてよい。幾つかの場合には、ワークフロー情報は、人間により読み取り可能なコマンドを含んでよい。該コマンドは、制御モジュール１２０により、これらのコマンドを実施するための命令に変換されてよい。

【0128】

制御モジュール１２０が命令を受信すると、制御モジュール１２０は、ルーティング決定を行ってよい。命令が制御モジュール１２０により管理される動作エンティティ１１０に対応する場合、制御モジュール１２０は、該動作エンティティ１１０へ、適切な制御ＡＰＩ７００呼び出しを発行してよい。しかし、命令が別の制御モジュール１２０により管理される動作エンティティ１１０に対応する場合、第１制御モジュール１２０は、該別の制御モジュールへ、命令をルーティングしてよい。命令をルーティングし制御ＡＰＩ７００の機能を呼び出すために、種々の実施形態で、制御モジュール１２０はルーティングエンジン８１０を含む。

【0129】

ルーティングエンジン８１０は、種々の実施形態で、命令をルーティングするために及び制御ＡＰＩ７００の機能を呼び出すために実行可能なソフトウェアルーチンのセットである。命令は、該命令に含まれる情報に基づきルーティングされてよい。このような情報は、動作エンティティ１１０のＵＵＴ３２１、動作エンティティ１１０のライフサイクル３２２、動作エンティティ１１０のＵＵＩＤ３２５、動作エンティティ１１０を管理する制御モジュール１２０のＵＵＩＤ３２５、動作エンティティ１１０及び制御モジュール１２０を含むコンテナエンティティ１１０のＵＵＩＤ３２５、変数３４０の名称、ソース、及び／又は、動作エンティティ１１０の名称３２８のようなブループリント２１０及び／又は定義３１０に含まれ得る他の情報を含んでよい。一例として、命令は、フェッチ機能７２０に対応してよく、フェッチすべき変数３４０の名称（例えば、「状態」）、該変数をフェッチすべき動作エンティティ１１０のＵＵＩＤ３２５、該動作エンティティを管理する、従って該動作エンティティのフェッチ機能７２０を呼び出すべき制御モジュール１２０のＵＵＩＤ３２５、を指定してよい。

【0130】

命令を受信した後に、種々の実施形態で、ルーティングエンジン８１０は、命令が別の制御モジュール１２０へルーティングされるべきか、又は制御ＡＰＩ７００の特定の機能が呼び出されるべきかを決定する。該命令がルーティングされるべきであるかどうかを決定するために、幾つかの実施形態では、ルーティングエンジン８１０は、命令が制御モジュール１２０のＵＵＩＤ３２５を指定するか否かを決定する。命令が制御モジュール１２０のＵＵＩＤ３２５を指定するが、指定されたＵＵＩＤ３２５が別の制御モジュール１２０に属する場合、ルーティングエンジン８１０は、命令をルーティングしてよい。幾つかの場合には、ルーティングエンジン８１０は、自身の制御モジュール１２０が動作エンティティの制御ＡＰＩ実装２３０へのアクセスを有しない場合、該動作エンティティ１１０が自身の制御モジュール１２０のローカルにないと決定してよい。ルーティングエンジン８１０は、制御モジュール１２０により維持されるローカル制御ＡＰＩ実装２３０のマップに基づき、この決定を行ってよい。幾つかの場合には、命令の中で識別されるＵＵＩＤ３２５及び制御ＡＰＩ呼び出しは、マップへのキーとして使用されてよい。マップがこのようなキーについてエントリを有しない場合、ルーティングエンジン８１０は、命令をルーティングしてよい。

【0131】

幾つかの場合には、ルーティングエンジン８１０は、該命令を自身の制御モジュール１２０の管理する各制御モジュール１２０へブロードキャストすることにより、該命令をルーティングしてよい。幾つかの場合には、指定されたＵＵＩＤ３２５がルーティングエンジンの制御モジュール１２０により管理される制御モジュール１２０に属する場合、ルーティングエンジン８１０は、該命令を該制御モジュールに直接提供してよい。ルーティングエンジン８１０は、ブループリント２１０を使用して、命令の対象である動作エンティティ１１０を誰が管理するかを決定してよい。命令は、制御モジュール１２０のＵＵＩＤ３２５を指定しなくてよい。しかしながら、命令は、動作エンティティ１１０のＵＵＩＤ３２５を依然として指定してよい。このように、ルーティングエンジン８１０は、動作エンティティ情報４１０に基づき、自身の制御モジュール１２０が該動作エンティティを管理するか否かを決定してよい。自身の制御モジュール１２０が該動作エンティティを管理しない場合、ルーティングエンジン８１０は、命令を、自身の制御モジュール１２０の管理する各制御モジュール１２０へブロードキャストしてよい。幾つかの実施形態では、ルーティングエンジン８１０は、自身の制御モジュール１２０が動作エンティティ１１０を管理するか否かを、動作エンティティのＵＵＩＤ３２５を用いて（又はＵＵＴ３２１のような他の情報を用いて）動作エンティティ情報４１０内で動作エンティティの情報を探すことを試みることにより、決定する。幾つかの実施形態では、各制御モジュール１２０の能力を、それらがどの動作エンティティ１１０を管理するかと一緒にアドバタイズするルーティングテーブルが使用されてよい。従って、ルーティングエンジン８１０は、このルーティングテーブルを使用して、命令をどこへルーティングすべきかを決定してよい。

【0132】

受信した命令が、ルーティングエンジンの制御モジュール１２０により管理される動作エンティティ１１０に対応する場合、ルーティングエンジン８１０は、該動作エンティティが、命令により示されたアクション／動作を処理するための、制御ＡＰＩ７００の機能を実装するか否かを調べてよい。上述のように、種々の実施形態で、制御モジュール１２０は、制御ＡＰＩ情報４２０に機能マップを格納してよい。機能マップは、制御ＡＰＩ７００の機能を、動作エンティティのＵＵＴ３２１及びライフサイクル３２２にマッピングする。従って、ルーティングエンジン８１０は、機能マップ、ＵＵＴ３２１、及びライフサイクル３２２に基づき、動作エンティティ１１０により実施される制御ＡＰＩ７００の機能のリストを構築し得る。命令が動作エンティティ１１０のＵＵＴ３２１及びライフサイクル３２２を指定しない場合、ルーティングエンジン８１０は、該動作エンティティに対する命令の中で指定され得るＵＵＩＤ３２５を用いて、動作エンティティのブループリント２１０を探してよい。ルーティングエンジン８１０は、次に、アクセスされたブループリント２１０からＵＵＴ３２１及びライフサイクル３２２を抽出してよい。ブループリント２１０が特定できない場合、ルーティングエンジン８１０は、命令の発行元にエラーを返してよい。種々の実施形態で、ルーティングエンジン８１０は、関連する動作エンティティ１１０のＵＵＴ３２１及びライフサイクル３２２に対応する機能マップの中で示された機能を選択することにより、機能のリストを構築する。

【0133】

実施される機能のリストを構築した後に、種々の実施形態で、ルーティングエンジン８１０は、命令により要求された動作を実施するための機能が該リストに含まれるか否かを決定する。例えば、命令が、特定の変数３４０を新しい値に遷移させる遷移動作を特定する場合、ルーティングエンジン８１０は、リストに基づき、動作エンティティ１１０が該特定の変数を遷移させる遷移機能７３０を実施するか否かを決定してよい。実施する場合、ルーティングエンジン８１０は、該遷移機能を呼び出してよく、その他の場合、ルーティングエンジン８１０は、命令の発行元にエラーを返してよい。この方法で、ルーティングエンジン８１０は、受信した命令を処理してよい。

【0134】

命令をルーティングするとき、又は制御ＡＰＩ７００の機能を呼び出すとき、ルーティングエンジン８１０は、ルーティング層８２０への呼び出しを行ってよい。ルーティング層８２０は、種々の実施形態で、ソフトウェアルーチンのセット、ハードウェア、又は命令を別のコンポーネント（動作エンティティ１１０又は制御モジュール１２０）へルーティングする及び／又は制御ＡＰＩ７００の機能を呼び出すよう動作するそれらの組み合わせである。ルーティング層８２０は、制御モジュール１２０から要求を受信して、命令を別の特定の制御モジュール１２０へ送信するか、又は制御ＡＰＩ７００の特定の動作エンティティ１１０により実施される特定の機能を呼び出してよい。従って、該要求は、命令、制御モジュール１２０のＵＵＩＤ３２５、動作エンティティ１１０のＵＵＩＤ３２５、及び／又は機能呼び出しを指定してよい。ルーティング層８２０は、命令がルーティングされるべきか、又は機能が呼び出されるべきかを、制御モジュール１２０から受信された要求の内容に基づき決定してよい。要求が命令を指定する場合、ルーティング層８２０は、（例えば、ＵＵＩＤ３２５に基づき）適切な制御モジュール１２０を特定し、命令を該制御モジュールへ送信してよい。要求が機能を指定する場合、ルーティング層８２０は、（例えば、ＵＵＩＤ３２５に基づき）適切な動作エンティティ１１０を特定し、該特定の動作エンティティにより実施される機能を呼び出してよい。

【0135】

種々の場合に、ルーティング層８２０は、リモートにある（例えば、ルーティングエンジン８１０に関連付けられたローカルネットワークの外部にある動作エンティティ１１０）動作エンティティ１１０又は制御モジュール１２０と通信する必要があってよい。本願明細書で使用されるとき、動作エンティティ１１０又は制御モジュール１２０は、それらが同じローカルネットワーク内に存在しない場合、別の動作エンティティ１１０又は制御モジュール１２０に対して「リモート」である。動作エンティティ１１０又は制御モジュール１２０がローカルかリモートかを決定するために、種々の実施形態で、ルーティング層８２０は、該動作エンティティ又は制御モジュールに関連付けられたルーティング可能エンティティ８３０の情報（例えば、ブループリント２１０）にアクセスする。

【0136】

ルーティング可能エンティティ８３０は、種々の実施形態で、別の動作エンティティ１１０又は制御モジュール１２０がルーティング層８２０からリモートにあるか否かを識別する特別な動作エンティティ１１０である。幾つかの場合には、ルーティング可能エンティティ８３０は、リモートホストポートを（例えば、変数３４０として）指定するブループリント２１０又は定義３１０を含んでよい。幾つかの実施形態では、ルーティング可能エンティティ８３０がリモートホストポートを識別する場合、ルーティング層８２０は、関連付けられた動作エンティティ１１０又は制御モジュール１２０がリモートであると決定し、その他の場合、ローカルであると決定する。例えば、ルーティング可能エンティティ８３０Ａに関連付けられた情報（例えば、ブループリント２１０）は、動作エンティティ１１０Ａがローカルにあることを示してよい。一方で、ルーティング可能エンティティ８３０Ｂに関連付けられた情報は、動作エンティティ１１０Ｂがリモートにあることを示してよい。この情報に基づき、ルーティング層８２０は、動作エンティティ１１０又は制御モジュール１２０と通信する適切な通信プロトコルを選択してよい。適切なルーティング可能エンティティ８３０にアクセスするために、種々の実施形態で、ルーティング層８２０は対応する動作エンティティ１１０又は制御モジュール１２０についての関係情報３３０にアクセスする。関係情報３３０は、対応する動作エンティティ１１０と関連するルーティング可能エンティティ８３０との間の関係３３１を識別してよい。一例として、動作エンティティ１１０は、ルーティング可能エンティティ８３０内に「含まれ」てよい。これに基づき、ルーティング層８２０は、ローカルストレージ及び／又はデータベース１３０から、該ルーティング可能エンティティ８３０のブループリント２１０を探してよい。

【0137】

種々の実施形態で、制御モジュール１２０は、動作エンティティ１１０又は制御モジュール１２０がリモートかローカルかについて不可知である。制御モジュール１２０は、代わりに、この決定を行うためにルーティング層８２０に依存してよい。制御モジュールの観点から、ローカル動作エンティティ１１０及びリモート動作エンティティ１１０と通信することは、同じであってよい（それは、全ての動作エンティティ１１０がローカルにあるかのように見えてよい）。これは、２つの異なる制御ＡＰＩを使用する代わりに、動作エンティティ１１０と通信する処理を１つの制御ＡＰＩに簡略化することを可能にする。

【0138】

図９を参照すると、方法９００のフロー図が示される。方法９００は、目標コンピュータ環境（例えば、目標環境１３７）の（例えば、動作情報１３５の中の）動作シナリオの一部として、動作エンティティ（例えば、動作エンティティ１１０）への命令を発行するために、制御モジュール（例えば、制御モジュール１２０）により実行される方法の一実施形態である。方法９００は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの場合には、方法９００は、制御モジュールがユーザ又は別の制御モジュールから命令を受信することに応答して実行されてよい。幾つかの実施形態では、方法９００は、追加ステップを含んでよい。例えば、制御モジュールは、命令を、実施するために別の制御モジュールへルーティングしてよい。

【0139】

方法９００は、ステップ９１０で開始し、制御モジュールが発見手順を実行する。発見手順の一部として、ステップ９１２で、制御モジュールは、制御モジュールにより制御されるべき目標コンピュータ環境の階層構造の中のコンポーネントを識別する。制御モジュールは、制御モジュールにより制御されるべき階層構造内のコンポーネントに対応するユニーク識別子（例えば、ＵＵＩＤ３２５）を定義する動作エンティティ情報（例えば、動作エンティティ情報４１０）にアクセスすることにより、階層構造の中のコンポーネントを識別してよい。種々の場合に、階層構造は、制御モジュール及び動作エンティティの両方を含んでよい。

【0140】

発見手順の一部として、ステップ９１４で、制御モジュールは、識別されたコンポーネントの機能的能力を発見する。所与のコンポーネントは、制御アプリケーションプログラミングインタフェース（application programming interface (API)）（例えば、制御ＡＰＩ７００）によりサポートされる複数の機能（例えば、機能７１０、７２０、７３０、等）のうちの１つ以上の機能を実施してよい。１つ以上の機能は、制御モジュールが所与のコンポーネントの状態を変化させることを可能にし得る。制御モジュールは、動作エンティティセットのうちの所与の動作エンティティを、制御ＡＰＩによりサポートされる複数の機能のうちの所与の動作エンティティにより実施される機能のセットにマッピングするマッピングを生成してよい。制御モジュールは、特定の動作エンティティ及び別の特定の動作エンティティを制御してよい。種々の場合に、特定の動作エンティティは、他の特定の動作エンティティと異なる、複数の機能セットを実施してよい。

【0141】

種々の実施形態で、コンポーネントの機能的能力を発見するステップは、制御ＡＰＩの特定の動作エンティティにより実施される記述機能（例えば、記述機能７１０）を呼び出すことにより、特定の動作エンティティの機能的能力を発見するステップを含んでよい。記述機能を呼び出すことに応答して、制御モジュールは、特定の動作エンティティにより実施される制御ＡＰＩの複数の機能のうちの機能セットを識別する応答を、特定の動作エンティティからを受信してよい。

【0142】

ステップ９２０で、制御モジュールは、目標コンピュータ環境のための動作シナリオの一部を実施する。動作シナリオは、発見手順の間に識別されたコンポーネントを、第１バージョンから第２バージョンへ更新するステップを含んでよい。動作シナリオの一部を実施する部分として、ステップ９２２で、制御モジュールは、制御モジュールを制御するコンポーネント（例えば、別の制御モジュール１２０））から、特定の動作及び該特定の動作を実行するための特定の動作エンティティを指定する命令を受信する。

【0143】

動作シナリオの一部を実施する部分として、ステップ９２２で、制御モジュールは、特定の動作、特定の動作エンティティ、及び識別されたコンポーネントの発見された機能的能力を用いて、命令に対する応答を生成する。命令に対する応答を生成するステップは、制御モジュールが、機能セットから、特定の動作エンティティに特定の動作を実行させるために呼び出し可能な特定の機能を識別するステップを含んでよい。制御モジュールは、ライフサイクルステージを示すライフサイクル値に基づき、機能セットから特定の機能を決定してよい。幾つかの場合には、命令は、特定の動作エンティティに関連付けられたユニーク識別子を定義してよい。従って、制御モジュールは、ユニーク識別子に基づき、特定の動作エンティティに対応するブループリントにアクセスし得る。ブループリントは、ライフサイクル値を指定してよい。特定の機能は、第１状態から第２状態へと特定の動作エンティティを遷移させるために呼び出し可能な遷移機能（例えば、遷移機能７３０）であってよい。制御モジュールは、特定の動作を実行するために、特定の機能を呼び出す制御ＡＰＩ呼び出しを、特定の動作エンティティに発行してよい。制御部は、更に、特定の制御モジュールを制御しているコンポーネントに、特定の動作の実行が成功したか否かを示す結果を指定するメッセージを送信してよい。

【0144】

幾つかの場合には、制御モジュールは、別の動作及び別の動作を実行する別の動作エンティティを指定する別の命令を受信してよい。制御モジュールは、他の命令に基づき、他の動作エンティティが別の特定の制御モジュールにより制御されることを決定してよい。このように、制御モジュールは、他の命令を他の特定の制御モジュールへルーティングしてよい。

【0145】

図１０を参照すると、方法１０００のフロー図が示される。方法１０００は、目標コンピュータ環境（例えば、目標環境１３７）の（例えば、動作情報１３５の中の）動作シナリオの一部として、動作エンティティ（例えば、動作エンティティ１１０）への命令を発行するために、制御モジュール（例えば、制御モジュール１２０）により実行される方法の一実施形態である。方法１０００は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの実施形態では、方法１０００は、追加ステップを含んでよい。例えば、制御モジュールは、命令を、実施するために別の制御モジュールへルーティングしてよい。

【0146】

方法１０００は、ステップ１０１０で開始し、制御モジュール及び動作エンティティを含む階層構造の中にある制御モジュールは、動作エンティティにより実行されるべき動作を指定する命令を、動作シナリオの一部として受信する。幾つかの場合には、命令は、制御モジュールを制御する、階層構造の中の別の制御モジュールから受信されてよい。

【0147】

ステップ１０２０で、制御モジュールは、所与の動作エンティティの状態を変化させることを可能にする、制御アプリケーションプログラミングインタフェース（ＡＰＩ）（例えば、制御ＡＰＩ７００）によりサポートされる複数の機能から、動作エンティティにより実施される機能セット（例えば、機能７１０、７２０、等）を発見する。機能セットを発見するステップは、制御モジュールが、動作エンティティから、動作エンティティにより実施される機能セットを識別するブロードキャストを受信するステップを含んでよい。

【0148】

ステップ１０３０で、制御モジュールは、機能セットが、動作エンティティに動作を実行させるために呼び出し可能な機能を含むか否かを決定する。

【0149】

ステップ１０４０で、動作エンティティに動作を実行させるために呼び出し可能な特定の機能を決定することに応答して制御モジュールは、特定の機能を呼び出す。特定の機能は、動作エンティティを破棄させるために呼び出し可能な破棄機能であってよい。種々の場合に、制御モジュールは、命令を送信した他の制御モジュールに、命令の実行に成功したことを示すメッセージを送信してよい。

【0150】

図１１を参照すると、方法１１００のフロー図が示される。方法１１００は、（例えば、動作情報１３５の中の）動作シナリオの一部として、動作エンティティ（例えば、動作エンティティ１１０）への命令を発行するために、制御モジュール（例えば、制御モジュール１２０）により実行される方法の一実施形態である。方法１１００は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの場合には、方法１１００は、制御モジュールがユーザ又は別の制御モジュールから命令を受信することに応答して実行されてよい。幾つかの実施形態では、方法１１００は、追加ステップを含んでよい。例えば、制御モジュールは、自身の動作エンティティと通信して、制御ＡＰＩ（例えば、制御ＡＰＩ７００）のどの機能（例えば、機能７１０、７２０、等）がそれらの動作エンティティにより実施されているかを決定してよい。

【0151】

方法１１００は、ステップ１１１０で開始し、制御モジュールが、動作シナリオの自動化された実施の一部とし第１状態から第２状態へと遷移させられるべき特定の動作エンティティを識別する命令を受信する。制御モジュールは、制御モジュール及び動作エンティティを有するコンポーネントの階層構造の中に含まれてよい。種々の場合に、階層構造は、該階層構造の最上位にある、該階層構造の次のレベルにある制御モジュールへ命令を発行することにより動作シナリオを実施するために実行可能なオーケストレータ制御モジュールを有してよい。従って、動作シナリオを実施するステップの一部として、命令は、オーケストレータ制御モジュールから制御モジュールにより受信されてよい。動作シナリオは、制御モジュールを実行するコンピュータシステムのユーザの代わりに、データベーストランザクションを実行する能力のあるデータベースサーバのセットを有するデータベースサービスを機能するステップを含んでよい。

【0152】

ステップ１１２０で、制御モジュールは、ルーティング層（例えば、ルーティング層８２０）へ呼び出しを行うことにより、特定の動作エンティティについて、命令を実行させる。幾つかの場合には、呼び出しは、特定の動作エンティティが制御モジュールのローカル環境に対してリモートであるか否かを指定しなくてよい。種々の実施形態で、制御モジュールは、特定の動作エンティティがローカル環境内にあるか又はローカル環境に対してリモートにあるかとは独立して、ルーティング層へ同じ呼び出しを行う。呼び出しは、命令を実行する特定の動作エンティティにより実施される特定の機能を指定してよい。幾つかの場合には、ルーティング層は、特定の機能を呼び出すことにより、ルーティング動作を実行してよい。幾つかの場合には、呼び出しは、データベースを起動するステップの一部として、データベースをインスタンス化するよう、ルーティング層に特定の動作エンティティの特定の機能を呼び出させるために、ルーティング層に対して行われてよい。更に幾つかの場合には、ルーティング層は、特定の動作エンティティを管理する別の制御モジュールへ命令をルーティングすることにより、ルーティング動作を実行してよい。

【0153】

種々の実施形態で、ルーティング層は、特定の動作エンティティがローカル環境内にあるか又はローカル環境に対してリモートにあるかについて、決定を行うよう動作する。ルーティング層は、該決定を用いて、特定の動作エンティティに関連するルーティング動作を実行してよい。幾つかの実施形態では、ルーティング層は、特定の動作エンティティに関連付けられたルーティング可能エンティティ（例えば、ルーティング可能エンティティ８３０）のブループリント（例えば、ブループリント２１０）にアクセスするよう動作する。ルーティング層は、先ず、特定の動作エンティティとルーティング可能エンティティとの間の関係（例えば、関係情報３３０）を指定する特定の動作エンティティのブループリントにアクセスしてよい。該関係は、ルーティング層がルーティング可能エンティティのブループリントにアクセスすることを可能にしてよい。

【0154】

種々の実施形態で、ルーティング層は、ブループリントがリモートホストポートを指定するか否かに基づき、特定の動作エンティティがローカル環境に対してリモートにあることを決定する。ルーティング層は、特定の動作エンティティがローカル環境に対してリモートにあることを示す決定に基づき、他の制御モジュールへ命令をルーティングするために第１ルーティングプロトコルを選択してよい。種々の場合に、第１ルーティングプロトコルは、ローカル環境内の命令をルーティングするために使用可能な第２ルーティングプロトコルと異なってよい。

【0155】

図１２を参照すると、方法１２００のフロー図が示される。方法１２００は、（例えば、動作情報１３５の中の）動作シナリオの一部として、動作エンティティ（例えば、動作エンティティ１１０）へ命令をルーティングするために、ルーティング層を実装するコンピュータシステムにより実行される方法の一実施形態である。方法１２００は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの実施形態では、方法１１００は、追加ステップを含んでよい。

【0156】

方法１２００は、ステップ１２１０で開始し、ルーティング層は、第１状態から第２状態へ遷移されるべき特定の動作エンティティへ、命令をルーティングする要求を受信する。要求は、特定の動作エンティティが、要求の受信された制御モジュールのローカル環境に対してリモートにあるか否かを指定しなくてよい。

【0157】

ステップ１２２０で、ルーティング層は、特定の動作エンティティについて維持される情報に基づき、特定の動作エンティティがローカル環境内にあるか又はローカル環境に対してリモートにあるかについて決定を行う。情報は、特定の動作エンティティのブループリント（例えば、ブループリント２１０）を定義してよい。種々の場合に、ブループリントは、特定の動作エンティティと、ルーティング可能エンティティとの間の関係（例えば、関係３３１）を定義してよい。ここで、該ルーティング可能エンティティは、該第２ブループリントに関連付けられ、該第２ブループリントは、該特定の動作エンティティがローカル環境内にあるか又はローカル環境に対してリモートにあるかを示す。ルーティング層は、該関係に基づき第２ブループリントにアクセスし、リモートホストポートを指定するアクセスされた第２ブループリントに基づき、特定の動作エンティティがローカル環境に対してリモートにあることを決定してよい。

【0158】

ステップ１２３０で、ルーティング層は、決定に基づき特定の動作エンティティへ命令をルーティングする。命令をルーティングするステップの一部として、ルーティング層は、特定の動作エンティティを第１状態から第２状態へと遷移されるための、特定の動作エンティティにより実施される特定の機能（例えば、遷移機能７３０）を呼び出してよい。幾つかの場合には、命令をルーティングするステップの一部として、ルーティング層は、命令を、要求の受信された制御モジュールに対して制御部の階層構造の次のレベルにある別の制御モジュールへ送信してよい。この他の制御モジュールは、特定の動作エンティティを直接管理してよい。

【0159】

図１３を参照すると、方法１３００のフロー図が示される。方法１３００は、（例えば、動作情報１３５の中の）動作シナリオの一部として、動作エンティティ（例えば、動作エンティティ１１０）への命令を発行するために実行される方法の一実施形態である。方法１３００は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの実施形態では、方法１３００は、追加ステップを含んでよい。一例として、制御モジュールは、自身の権限下にある動作エンティティと通信して、制御ＡＰＩ（例えば、制御ＡＰＩ７００）のどの機能（例えば、機能７１０、７２０、等）がそれらの動作エンティティにより実施されているかを決定してよい。

【0160】

方法１３００は、ステップ１３１０で開始し、コンピュータシステム（例えば、システム１００）は、制御モジュール及び動作エンティティを含むコンポーネントの階層構造を実行する。種々の場合に、階層構造は、該階層構造の最上位にある、該階層構造の次のレベルにある制御モジュールへ命令を発行することにより動作シナリオを実行するために実行可能なオーケストレータ制御モジュールを有してよい。

【0161】

ステップ１３２０で、階層構造の制御モジュールは、第１状態から第２状態へと遷移されるべき動作エンティティのうちの特定の動作エンティティを識別する命令を受信する。

【0162】

ステップ１３３０で、制御モジュールは、ルーティング層（例えば、ルーティング層８２０）へ呼び出しを行うことにより、命令を実行させる。呼び出しは、特定の動作エンティティが制御モジュールのローカル環境に対してリモートであるか否かを指定しなくてよい。幾つかの実施形態では、制御モジュールは、特定の動作エンティティが制御モジュールのローカル環境に対してリモートにあるか否かとは独立して、ルーティング層へ同じ呼び出しを行う。

【0163】

ルーティング層は、特定の動作エンティティがローカル環境内にあるか又はローカル環境に対してリモートにあるかについて、決定を行うよう動作してよい。ルーティング層は、該決定を用いて、特定の動作エンティティへ命令をルーティングしてよい。種々の場合に、ルーティング層は、特定の動作エンティティがリモートホストポートに関連付けられていることに応答して、特定の動作エンティティがローカル環境に対してリモートにあることを決定してよい。ルーティング層は、ローカル環境に対してリモートにある動作エンティティへ命令をルーティングするために第１ルーティングプロトコルを利用し、及びローカル環境内にある動作エンティティへ命令をルーティングするために第２の異なるルーティングプロトコルを利用してよい。幾つかの場合には、命令をルーティングするステップは、特定の動作エンティティを直接管理する、階層構造の次のレベルにある別の制御モジュールへ命令をルーティングするステップを含んでよい。

【0164】

図１４を参照すると、ワークフローエンジン４４０のブロック図が示される。幾つかの実施形態では、ワークフローエンジン４４０は、ワークフロー処理エンジン１４２０及び予約エンジン１４４０を含む。更に示されるように、データベース１３０は、ワークフロー１４１０及びワークフロー状態情報１４３０を含む。ワークフロー状態情報１４３０は、図示のように、動作エンティティ１１０に格納することができる。幾つかの実施形態では、ワークフローエンジン４４０は、図と異なる方法で実装されてよい。例えば、ワークフローエンジン４４０は、ワークフロー状態情報１４３０を含んでよい。

【0165】

上述のように、動作シナリオは、何らかの意図された目標（例えば、動作エンティティ１１０のセットを新しいバージョンに更新する）を実行するステップシーケンスに対応するコマンドセットを用いて実施されてよい。ワークフロー１４１０は、種々の実施形態で、特定の動作シナリオに対応する順序付きコマンドセットを指定する。従って、ワークフロー１４１０のコマンドセットの実施は、結果として、関連付けられた動作シナリオを実行させ得る。幾つかの場合には、ワークフロー１４１０は、ユーザにより提供されデータベース１３０に格納されてよい。ワークフロー１４１０は、図１７に関して詳述されるように、推理エンジン４５０により提供されてもよい。制御モジュール１２０は、ワークフロー要求１４０５に応答して、（例えば、データベース１３０から）ワークフロー１４１０にアクセスしてよい。

【0166】

ワークフロー要求１４０５は、種々の実施形態で、指定されたワークフロー１４１０を実施するようワークフローエンジン４４０に指示する要求である。ワークフロー要求１４０５は、制御モジュール１２０が対応するワークフロー１４１０にアクセスすることを許可する名称又は識別子を識別してよい。ワークフロー要求１４０５は、コマンドラインツールを介してユーザから及び／又は別の制御モジュール１２０から受信されてよい。例えば、オーケストレータ制御モジュール１２０は、ワークフロー要求１４０５をユーザから受信してよい。幾つかの場合には、ワークフロー１４１０の実施は、他の異なるワークフロー１４１０の実施を含んでよい。幾つかの実施形態では、ワークフロー１４１０は、ワークフローの階層構造を形成するよう積層されてよい。該階層構造の中では、最上位ワークフロー１４１０は上位タスクを実行し、下位ワークフロー１４１０はそれぞれ、該上位タスクのサブタスクを実行する。前述の例を続けると、受信されたワークフロー要求１４０５の中で指定された特定のワークフロー１４１０を実施するステップは、オーケストレータ制御モジュール１２０が、下位レベル制御モジュール１２０に、特定のワークフロー１４１０に対応するワークフロー１４１０のセットを実施させることを含んでよい。所与のワークフロー１４１０を実施するために、種々の実施形態で、制御モジュール１２０は、ワークフロー進行エンジン１４２０及び逆方向エンジン１４４０を含む。

【0167】

ワークフロー処理エンジン１４２０は、種々の実施形態では、ワークフロー１４１０の中で指定された順序付きコマンドセットを実施するために実行可能なソフトウェアルーチンのセットである。ワークフロー処理エンジン１４２０は、システム１００内のコンポーネントに命令を発行することにより、コマンドセットを実施してよい。前述のように、幾つかの実施形態では、コマンドは、人間により読み取り可能な形式で又は動作エンティティ１１０及び制御モジュール１２０により理解可能な形式であってよい。結果としてワークフロー処理エンジン１４２０により発行された命令は、実際の対応するコマンド又は動作エンティティ１１０及び制御モジュール１２０により理解可能なフォーマットへのコマンドの変換であってよい。ワークフロー処理エンジン１４２０は、前述の方法で（例えば、ルーティングエンジン８１０１と相互作用して、ルーティング層８２０への呼び出しを行うことにより）命令を発行してよい。

【0168】

順序付きコマンドセットを実施するとき、種々の実施形態で、ワークフロー処理エンジン１４２０は、ワークフロー状態情報１４３０を維持する。ワークフロー状態情報１４３０は、種々の実施形態で、ワークフロー１４１０の実施の現在状態及び／又は目標環境１３７の現在状態を指定する。例えば、ワークフロー状態情報１４３０は、既に実施されたワークフロー１４１０のコマンドを識別してよい。従って、コマンドが完了したことに応答して、ワークフロー処理エンジン１４２０は、該完了したコマンドを反映するよう、ワークフロー状態情報１４３０を更新してよい。ワークフロー状態情報１４３０は、目標環境内の動作エンティティ１１０及び制御モジュール１２０の状態を識別することにより、目標環境１３７の状態を識別してよい。例えば、ワークフロー状態情報１４３０は、どの動作エンティティ１１０が「オンライン」であるか、及びどれが「オフライン」であるかを示してよい。ワークフロー状態情報１４３０は、ワークフローが順方向に又は逆方向に実行しているかを示してもよい。上述のように、ワークフロー１４１０を実施する際にエラーが生じることに応答して、逆方向エンジン１４４０は、ワークフロー状態情報１４３０を用いてエラーに応答してよい。

【0169】

逆方向エンジン１４４０は、種々の実施形態で、システム１００の状態を、ワークフロー１４１０の開始される前に存在した初期状態に戻すために実行可能なソフトウェアルーチンのセットである。幾つかの場合には、ワークフロー１４１０を実施している間に、エラーが生じ得る。例えば、コマンドは、ワークフローエンジン４４０がそれを実施しようとする度に失敗し得る。別の例として、ワークフローエンジン４４０（及びその制御モジュール１２０）は、クラッシュし、ハングし、又は別の種類の機能不全を経験し得る。ワークフロー１４１０の実施中にエラーが生じた場合、種々の場合に、ワークフローエンジン４４０は、対応するコマンドを再度実施することにより、関連するステップを再試行してよい。幾つかの場合には、しかしながら、逆方向エンジン１４４０は、システム１００の状態を、ワークフロー１４１０に関連付けられた初期状態に戻すことを試みてよい。

【0170】

システム１００の状態を逆行させるために、逆方向エンジン１４４０は、逆順にコマンドセットをトラバースしてよい。種々の実施形態で、ワークフロー１４１０の中で指定されたコマンドセットは、目標環境１３７を初期状態から意図された状態へ遷移させるために順方向の順序でトラバースされ、目標環境１３７を現在状態（例えば、意図された状態）から初期状態へ遷移させるために逆方向の順序でトラバースされ得る。逆方向の順序でコマンドをトラバースすることにより、逆方向エンジン１４４０は、システムを壊れた又は不明な状態のままにする代わりに、知られた状態に戻すことができる。従って、エラー（例えば、コマンドが完了できないこと）に応答して、逆方向エンジン１４４０は、既に実施されたこれらのコマンドを逆方向に進み、これらのコマンドにより生じた１つ以上の状態変化を取り消してよい。例えば、特定のコマンドが動作エンティティ１１０を「オフライン」から「オンライン」へと遷移させた場合、逆方向エンジン１４４０は、（例えば、制御ＡＰＩ７００の機能を呼び出すことにより、又は動作エンティティ１１０を管理する制御モジュール１２０へ命令を発行することにより）該動作エンティティ１１０を「オフライン」へと遷移させて戻してよい。幾つかの場合には、ワークフローコマンド逆転することができない。これは、コマンドに関連付けられたメタデータにより示されてよい。従って、ワークフローエンジン４４０は、停止し、ユーザに問題を警告してよい。

【0171】

種々の場合に、制御モジュール１２０（例えば、オーケストレータ制御モジュール１２０）はワークフロー１４１０を実施している間に機能不全になり得る（例えば、クラッシュする）。このような状況では、制御モジュール１２０が復旧すると（例えば、新しい制御モジュール１２０がインスタンス化されると）、該ワークフロー１４１０の実施を再開することが望ましいことがある。従って、復旧し又は復元されると、制御モジュール１２０は、ワークフロー１４１０の進行中の実施が存在するかどうかを決定するために、ワークフロー状態情報１４３０へのアクセスを試みてよい。制御モジュール１２０は、続いて、進行中のものが存在する場合、ワークフロー１４１０の実施を再開してよい。幾つかの場合には、制御モジュール１２０は、ワークフロー１４１０の中の次のコマンドを実行することを試みてよい。更に他の場合には、制御モジュール１２０は、目標環境１３７を初期状態に戻すために、既に完了したコマンドを逆戻ししてよい。制御モジュール１２０は、次に、ワークフロー１４１０全体を再試行してよい。

【0172】

制御モジュール１２０は機能不全であり得るので、種々の実施形態で、ワークフロー状態情報１４３０は、制御モジュール１２０の外部の場所に格納される。その結果、制御モジュール１２０が機能不全になった場合、ワークフロー状態情報１４３０が失われない。状態情報１４３０が外部位置に格納されるか否かは、制御モジュール１２０により管理されるエンティティ１１０が「状態」であるか否か、及び該制御モジュールの寿命が該エンティティにより制限されるか否かにも依存してよい。一例として、制御モジュール１２０が、無状態（stateless）アプリケーションと同じコンテナの内部にある場合、それは、ワークフロー状態情報１４３０を外部に格納しなくてよく、ローカルメモリに格納してよい。コンテナを終了させる問題が存在した場合、該エンティティ１１０及び該制御モジュール１２０の両方は破棄され、ワークフローの状態は、次にその場合に論点（moot）になり得る。しかし、変更されている状態が該コンテナの外部に存続する場合、該制御モジュール１２０は、ワークフロー状態情報１４３０をコンテナの外部の場所に格納してよい。図１４に示されるように、ワークフロー状態情報１４３０は、動作エンティティ１１０及びデータベース１３０に格納することができる。幾つかの実施形態では、制御モジュール１２０が、要素２２０としてデータベースを含む動作エンティティ１１０を管理する場合、制御モジュール１２０は、該データベースを利用して、ワークフロー状態情報１４３０を格納してよい。制御モジュール１２０が初期化されると、それは、動作エンティティ１１０について知るために、自身の管理する動作エンティティ１１０の記述機能７１０を呼び出してよい。動作エンティティ１１０がワークフロー状態情報１４３０を格納している場合、それは、制御モジュール１２０に該情報を通知してよい。この方法で、制御モジュール１２０は、対応するワークフロー状態情報１４３０と一緒に、ワークフロー１４１０の進行中の実施について知ってよい。

【0173】

図１５を参照すると、方法１５００のフロー図が示される。方法１５００は、目標コンピュータ環境（例えば、目標環境１３７）でワークフローを実施するために、オーケストレータ制御モジュール（例えば、制御モジュール１２０）により実行される方法の一実施形態である。方法１５００は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの実施形態では、方法１５００は、追加ステップを含んでよい。一例として、オーケストレータ制御モジュールは、動作シナリオを実行するための要求（例えば、ワークフロー要求１４０５）を受信してよい。幾つかの場合には、要求は、ワークフロー情報をアクセス可能にする、ワークフローに対応する名称値を指定してよい。

【0174】

方法１５００は、ステップ１５１０で開始し、オーケストレータ制御モジュールが、制御モジュールと動作エンティティとを含むコンポーネントのセット及び初期状態を有する目標コンピュータ環境で動作シナリオを自動的に実施するステップシーケンスに対応するコマンドセットを有するワークフロー（例えば、ワークフロー１４１０）を定義するワークフロー情報（例えば、動作情報１３５）にアクセスする。幾つかの場合には、動作シナリオは、コンピュータシステムのユーザの代わりに、データベーストランザクションを実行する能力のある１つ以上のデータベースサーバを有するデータベースサービスを起動するステップを含んでよい。

【0175】

ステップ１５２０で、オーケストレータ制御モジュールは、ステップシーケンスを実行させるために、コンポーネントセットのうちのコンポーネントに命令を発行することにより、ワークフローのコマンドセットを実施する。コマンドセットを実施するステップは、目標コンピュータ環境において、初期状態に対して１つ以上の状態変化を生じさせてよい。種々の実施形態で、コマンドセットは、コマンドセットのうちのコマンドが、目標コンピュータ環境を初期状態から指定された終了状態へ遷移させるために、及び目標コンピュータ環境を現在状態から初期状態へ戻すよう逆に遷移させるために実施され得るよう定義される。目標コンピュータ環境における１つ以上の状態変化は、コンポーネントセットのうちの特定のコンポーネントが、目標コンピュータ環境内の新しいコンポーネントをインスタンス化する状態変化を含んでよい。幾つかの場合には、新しいコンポーネントは、目標コンピュータ環境において、特定のコンポーネントと異なる役割を有してよい。

【0176】

ステップ１５３０で、オーケストレータ制御モジュールは、オーケストレータ制御モジュールがコマンドセットを実施する際にエラーに応答することを可能にする、目標コンピュータ環境の現在状態を識別する状態情報（例えば、ワークフロー状態情報１４３０）を維持する。ステップシーケンスのうちの特定のステップが実行に失敗したことを検出することに応答して、オーケストレータ制御モジュールは、コンポーネントセットのうちのコンポーネントに、該特定のステップに対応する１つ以上の命令を再発行することにより、特定のステップを再試行してよい。幾つかの場合には、エラーは、コマンドセットが完了するのを妨げ得る。従って、オーケストレータ制御モジュールは、目標コンピュータ環境を初期状態に戻すために、目標コンピュータ環境における１つ以上の状態変化を逆行させることにより、エラーに応答してよい。幾つかの実施形態では、１つ以上の状態変化を逆行させるステップは、コマンドセットのうちのコマンドが完了した順序を逆方向にトラバースするステップを含む。トラバースするステップを実行する間、オーケストレータ制御モジュールは、既に完了したこれらのコマンドにより引き起こされた１つ以上の状態変化を取り消してよい。

【0177】

幾つかの場合には、エラーは、コマンドセットを実施する間、オーケストレータ制御モジュールがクラッシュすることを含む。状態情報は、復帰したオーケストレータ制御モジュールがコマンドセットの実施を後に再開できるようにしてよい。幾つかの実施形態では、状態情報は、オーケストレータ制御モジュールのクラッシュが状態情報を損失させないように、オーケストレータ制御モジュールの外部にある位置（例えば、データベース１３０）において、オーケストレータ制御モジュールにより維持される。状態情報は、目標コンピュータ環境内の動作エンティティにおいて、オーケストレータ制御モジュールにより維持されてよい。

【0178】

図１６を参照すると、方法１６００のフロー図が示される。方法１６００は、目標コンピュータ環境（例えば、目標環境１３７）でワークフローを実施するために実行される方法の一実施形態である。方法１６００は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの実施形態では、方法１６００は、追加ステップを含んでよい。一例として、オーケストレータ制御モジュールは、動作シナリオを実行するための要求（例えば、ワークフロー要求１４０５）を受信してよい。幾つかの場合には、要求は、ワークフロー情報をアクセス可能にする、ワークフローに対応する名称値を指定してよい。

【0179】

方法１６００は、ステップ１６１０で開始し、コンピュータシステムは、制御モジュール及び動作エンティティを含むコンポーネントの階層構造を実行する。種々の場合に、階層構造は、該階層構造の最上位にある、動作シナリオのステップシーケンスに対応するコマンドセットを実行することにより動作シナリオを実施するために実行可能なオーケストレータ制御モジュールを有してよい。

【0180】

ステップ１６２０で、階層構造のコンポーネントセットと初期状態とを有する目標コンピュータ環境の特定の動作シナリオを実施するための要求を受信することに応答して、オーケストレータ制御モジュールは、特定の動作シナリオに対応するコマンドを有するワークフローを実施する。

【0181】

ステップ１６２２で、ワークフローを実施するステップの部分として、オーケストレータ制御モジュールは、ワークフローのコマンドを実行させるために、階層構造の中の制御モジュールのうちの制御モジュールに命令を発行する。その結果、目標コンピュータ環境に、初期状態に対して１つ以上の状態変化が生成される。幾つかの場合には、命令を発行するステップは、階層構造の中の特定の制御モジュールに、第２の異なるワークフローを実施させてよい。ワークフロー及び第２ワークフローは、ワークフローの階層構造を形成してよい。該階層構造は、該ワークフローをワークフローの階層構造の最上位に、該第２ワークフローをワークフローの階層構造の次のレベルに含む。幾つかの場合には、特定の制御モジュールは、特定の制御モジュールを含むレベルに対して、コンポーネントの階層構造の次のレベルにあるコンポーネントに命令を発行することにより、第２ワークフローを実施してよい。

【0182】

ステップ１６２４で、ワークフローを実施するステップの一部として、オーケストレータ制御モジュールは、ワークフローを実施する際にエラーに応答することを可能にする、目標コンピュータ環境の現在状態を識別する状態情報（例えば、ワークフロー状態情報１４３０）を維持する。幾つかの場合には、エラーは、ワークフローを実施する間、オーケストレータ制御モジュールがハングすることを含んでよい。したがって、状態情報は、復帰したオーケストレータ制御モジュールがワークフローの実施を後に再開できるようにしてよい。幾つかの実施形態では、状態情報は、目標コンピュータ環境に含まれるコンポーネントセットの構成変数（例えば、変数３４０）を指定する。

【0183】

図１７を参照すると、推理エンジン４５０のブロック図が示される。幾つかの実施形態では、推理エンジン４５０は、直接推理エンジン１７１０及び間接推理エンジン１７２０を含む。図示のように、推理エンジン４５０は、実施するために、ワーフフローエンジン４４０に、ワークフロー１４１０を提供できる。

【0184】

幾つかの実施形態では、推理エンジン４５０は、図と異なる方法で実装されてよい。例えば、推理エンジン４５０は、ワークフローエンジン４４０を有しないで動作してよい。つまり、推理エンジン４５０は、システム１００を意図された状態へと移行させるステップを生成し実施してよい。これは、推理エンジン４５０が、システム１００の状態を評価し、制御ＡＰＩ７００のサポートするコマンドを発行し、そして、意図された状態に達するまでシステム１００の状態を再評価するステップを含んでよい。例えば、推理エンジン４５０は、アプリケーションバージョンを「Ａ」から「Ｘ」へ遷移させる推理要求１７０５を受信してよい。従って、推理エンジン４５０は、アプリケーションバージョンを「Ａ」から「Ｘ」へ遷移させる遷移要求を発行してよい。しかし、例えば、遷移コマンドに関連付けられたデータベースサーバがクラッシュした場合、推理エンジン４５０は、システム１００のこの新しい状態を識別してよい。従って、推理エンジン４５０は、データベースサーバの状態を「オフライン」から「オンライン」へ遷移させる新しいコマンドを生成し発行してよい。推理エンジン４５０は、次に、アプリケーションバージョンを「Ａ」から「Ｘ」へ遷移させることを再試行してよい。この方法で、推理エンジン４５０は、ワークフローエンジン４４０と非常に似た順序でステップを実施してよいが、ステップは、オンザフライで又は事前にまとめて生成することもできる。

【0185】

直接推理エンジン１７１０は、種々の実施形態では、ワークフロー１４１０を生成するために実行可能なソフトウェアルーチンのセットである。図示のように、推理エンジン４５０は、推理要求１７０５を受信し得る。ワークフロー１４１０が実施されることを指定する代わりに、推理要求１７０５は、上位目標（例えば、管理下にあるシステムの所望の状態）又は達成されるべき遷移バージョンコマンドのようなコマンドを指定してよい。例えば、推理要求１７０５は、１つ以上のデータベースサーバエンティティ１１０と１つ以上のメトリックサーバエンティティ１１０とを含むデータベースサービスエンティティ１１０がインスタンス化されるべきであると指定してよい。該推理要求は、しかしながら、データベースサービスエンティティ１１０をインスタンス化するためにコマンドを指定しなくてもよい。従って、直接推理エンジン１７１０は、ワークフロー１４１０を生成するために、直接推理の概念を適用してよい。種々の場合に、直接推理エンジン１７１０は、動作エンティティ１１０がどのように関連付けられるかを識別するために、ブループリント２１０に含まれる関係情報３３０のような情報を使用してよい。動作エンティティ１１０がどのように関連付けられるかに基づき、直接推理エンジン１７１０は、特定の動作エンティティ１１０が他の動作エンティティ１１０の前にインスタンス化されるべきであると決定してよい。この推理に基づき、直接推理エンジン１７１０は、順序付きコマンドセットを生成してよい。

【0186】

前述の例を続けると、推理要求１７０５は、データベースサービスエンティティ１１０のＵＵＴ３２１又はＵＵＩＤ３２５を指定してよい。直接推理エンジン１７１０は、該情報を用いて、データベースサービスエンティティ１１０のブループリント２１０にアクセスしてよい。該ブループリントは、データベースサービスエンティティ１１０がデータベースサーバエンティティ１１０とメトリックサーバエンティティ１１０とを含むことを示してよい。データベースサービスエンティティのブループリント２１０に基づき、直接推理エンジン１７１０は、データベースサーバエンティティ１１０のブループリント２１０及びメトリックサーバエンティティ１１０のブループリント２１０にアクセスしてよい。これらのブループリント２１０は、データベースサーバエンティティ１１０とメトリックサーバエンティティ１１０との間の関係３３１を示してよい。幾つかの場合には、関係３３１は、メトリックサーバエンティティ１１０が正しく動作するために、メトリックサーバエンティティ１１０がデータベースサーバエンティティの存在に依存することを示してよい。従って、直接推理エンジン１７１０は、関係に基づき、メトリックサーバエンティティ１１０の前にデータベースサーバエンティティ１１０がインスタンス化される必要があることを決定してよい。該決定に基づき、直接推理エンジン１７１０は、データベースサーバエンティティ１１０をインスタンス化するコマンドを含むコマンドセットを生成してよい。ここで、コマンドセットは、該コマンドが、メトリックサーバエンティティ１１０をインスタンス化する別のコマンドの前にくるように順序付けられる。

【0187】

間接推理エンジン１７２０は、種々の実施形態では、ワークフロー１４１０を生成するために実行可能なソフトウェアルーチンのセットである。直接推理エンジン１７１０と対照的に、間接推理エンジン１７２０は、ワークフロー１４１０を生成するために、間接推理の概念を適用してよい。例えば、データベーステーブルが多くの高価なスキャンを有してよく、可能なソリューションはインデックスを生成するためであってよい。従って、間接推理エンジン１７２０は、（例えば、高価なスキャンを有する他のデータベーステーブルについて、インデックスが有用であることを示す情報を分析することにより）該データベーステーブルのためにインデックスが生成されるべきであると決定してよい。間接推理エンジン１７２０は、該データベーステーブルのインデックスを生成するためのコマンドセットを有するワークフロー１４１０を生成してよい。ワークフロー１４１０が推理エンジン４５０により生成された後に、ワークフロー１４１０は、実施のためにワークフローエンジン４４０に提供されてよい。幾つかの場合には、再生成される必要がなく上位目標を再び実施するためにワークフロー１４１０を読み出し可能なように、ワークフロー１４１０は（例えば、データベース１３０に）格納されてよい。

【0188】

図１８を参照すると、方法１８００のフロー図が示される。方法１８００は、目標コンピュータ環境（例えば、目標環境１３７）でワークフロー（例えば、ワークフロー１４１０）を生成し実施するために、オーケストレータ制御モジュール（例えば、制御モジュール１２０）により実行される方法の一実施形態である。方法１８００は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの実施形態では、方法１８００は、追加ステップを含んでよい。一例として、オーケストレータ制御モジュールは、ワークフローを再生成することなく動作シナリオが再実施できるように、生成したワークフローをデータベースに格納してよい。

【0189】

方法１８００は、ステップ１８１０で開始し、オーケストレータ制御モジュールは、目標コンピュータ環境を第１状態から第２の異なる状態へと遷移させるために動作シナリオを実施する要求（例えば、推理要求１７０５）を受信する。目標コンピュータ環境は、制御モジュール及び動作エンティティを含むコンポーネントセットを有してよい。種々の場合に、受信した要求は、目標コンピュータ環境を第１状態から第２状態へ遷移させるコマンドを指定しなくてよい。要求は、動作シナリオの一部として、目標コンピュータ環境内にインスタンス化されるべき第１及び第２コンポーネントを識別してよい。動作シナリオは、コンピュータシステムのユーザの代わりに、データベーストランザクションを実行する能力のあるデータベースサーバのセットを有するデータベースサービスを起動するステップを含んでよい。

【0190】

ステップ１８２０で、オーケストレータ制御モジュールは、コンポーネントセットのうちのコンポーネントの状態の変化によることを含む、目標コンピュータ環境を第１状態から第２状態へ遷移させる特定のコマンドセットを定義するワークフローを生成する。種々の場合に、オーケストレータ制御モジュールは、コンポーネントセット、第１コンポーネント、及び第２コンポーネントに対応するブループリント（例えば、ブループリント２１０）にアクセスしてよい。ブループリントは、特定のコマンドセットが実施される順序に影響する、コンポーネント間の関係を定義してよい。例えば、関係は、第１コンポーネントが有効な方法で動作するために、第１コンポーネントが第２コンポーネントの存在に依存するという依存関係を含んでよい。このように、特定のコマンドセットは、第１コンポーネントをインスタンス化する第１コマンドと、第２コンポーネントをインスタンス化する第２コマンドと、を含んでよい。特定のコマンドセットは、実施の中で第２コマンドが第１コマンドに先行するように、依存関係に基づき順序付けられてよい。

【0191】

ステップ１８３０で、オーケストレータ制御モジュールは、目標コンピュータ環境を第２状態へ遷移させるために、コンポーネントセットの中の１つ以上の制御モジュールへ命令を発行することにより、特定のコマンドセットを実施する。幾つかの場合には、特定のコマンドセットが目標コンピュータ環境を第１状態から第２状態へと遷移させるために順方向の順序で実施でき、目標コンピュータ環境を第１状態へ遷移させるために逆方向の順序で実施できるように、特定のコマンドセットが定義されてよい。特定のコマンドセットを実施する際にエラーを検出することに応答して、オーケストレータ制御モジュールは、目標コンピュータ環境を逆方向の順序に従い遷移させて第１状態に戻してよい。幾つかの場合には、コンポーネントセットのうちのコンポーネントの状態を変化させるステップは、動作エンティティを第１バージョンから第２バージョンへ更新するステップを含んでよい。

【0192】

図１９を参照すると、方法１９００のフロー図が示される。方法１９００は、目標コンピュータ環境（例えば、目標環境１３７）でワークフロー（例えば、ワークフロー１４１０）を生成し実施するために実行される方法の一実施形態である。方法１９００は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの実施形態では、方法１９００は、追加ステップを含んでよい。例えば、オーケストレータ制御モジュールは、ワークフローを再生成することなく動作シナリオが再実施できるように、生成したワークフローをデータベースに格納してよい。

【0193】

方法１９００は、ステップ１９１０で開始し、コンピュータシステムは、制御モジュール及び動作エンティティを含むコンポーネントの階層構造を実行する。階層構造は、該階層構造の最上位にある、動作シナリオのステップシーケンスに対応するコマンドセットを実行することにより動作シナリオを実施するために実行可能なオーケストレータ制御モジュールを有してよい。

【0194】

ステップ１９２０で、目標コンピュータ環境を初期状態から終了状態へと遷移させる特定の動作シナリオを実施するための要求（例えば、推理要求１７０５）を受信することに応答して、オーケストレータ制御モジュールは、目標コンピュータ環境を初期状態から終了状態へと遷移させる特定のコマンドセットを定義するワークフローを生成する。種々の場合に、要求は、特定のコマンドセットを識別しなくてよい。特定の動作シナリオは、動作エンティティを生成することを含んでよい。このように、ワークフローを生成するステップは、動作エンティティのブループリント（例えば、ブループリント２１０）にアクセスするステップを含んでよい。幾つかの場合には、ブループリントは、動作エンティティに加えて生成されるべき第２動作エンティティを識別してよい。従って、オーケストレータ制御モジュールは、動作エンティティと第２動作エンティティとの間の関係に基づき、動作エンティティ及び第２動作エンティティを生成すべき順序を決定してよい。特定のコマンドセットは、決定された順序に基づき生成されてよい。

【0195】

ステップ１９３０で、オーケストレータ制御モジュールは、コンポーネントの階層構造のうちのコンポーネントの状態を変化させることによることを含み、目標コンピュータ環境を終了状態へ遷移させるために、コンポーネントの階層構造の中の１つ以上の制御モジュールへ命令を発行することにより、特定のコマンドセットを実施する。

【0196】

図２０Ａを参照すると、認証サービス１４０のブロック図が示される。上述のように、主体が、何らかの望ましくない目的を達成するために、システム１００へ認可されていない命令を発行できないことを保証することが重要であり得る。システム１００を保護するために、認証サービス１４０は、主体により要求されているアクションがシステム１００とインタフェースするのを監査するために利用されてよい。図示の実施形態では、認証サービス１４０は、認証エンジン２０１０、認証シート２０２０、及びテストエンジン１５０を含み、監査レポート２０３０を含むデータベース１３０とインタフェースしてよい。図２０Ａに示すように、幾つかの実施形態では、認証サービス１４０は、制御モジュール１２０と別個の認証コンポーネントであり、制御モジュール１２０及び／又は動作エンティティ１１０へ発行されたコマンドを監査する。他の実施形態では、認証サービス１４０は、図と異なる方法で実装されてよい。例えば、図２０Ｂと共に後述するように、認証サービス１４０は、制御モジュール１２０（又はオーケストレータ制御モジュール１２０）に統合されてよく、認証サービス１４０は、テストエンジン１５０を含まなくてよい。

【0197】

認証エンジン２０１０は、種々の実施形態で、発行されたコマンドの監査を実行するために実行可能な命令のセットである。例えば、特定のユーザは、特定のデータベースクラスタをオンラインからオフラインへと遷移させるために、オーケストレータ制御モジュール１２０へコマンドを発行していてよい。オーケストレータ制御モジュール１２０がこのコマンドを実施し始める前に、認証エンジン２０１０は、特定のユーザ（又は制御モジュール１２０がコマンドを発行した場合には該制御モジュール１２０）がそのようなコマンドを発行することを認可されているか否かを確認してよい。図示の実施形態では、認証サービス１４０は、認証要求２００５を介して、どんなコマンドが発行されたかの指示を受信する。従って、制御モジュール１２０が、エンティティ（例えば、ユーザ、上位制御モジュール１２０、等）から、１つ以上のアクションを実行するためのコマンドを受信すると、制御モジュール１２０は、要求２００５を用いて、受信したコマンドの実行を認可し、実行されるべきアクション、コマンドの発行元、又はコマンドに関する他のコンテキスト情報のような、コマンドに関する種々の情報を識別してよい。図示の実施形態では、認証エンジン２０１０は、発行されたコマンドがセキュリティルールセットにより定義される許可されたアクションに従うことを検証するために、認証要求２００５に含まれる情報を、認証シート２０２０の中で定義されるセキュリティルールセットに対して評価する。認証シート２０２０の一例は、図２１と関連して以下に更に詳述される。

【0198】

監査処理の部分として、種々の実施形態で、認証エンジン２０１０（又はサービス１４０又はシステムの他のコンポーネント）は、認証要求２００５に関連付けられた種々のエンティティを認証してよく、これは要求２００５を受信する前（又は後）に生じてよい。幾つかの実施形態では、これは、コマンドの最初の発行元（例えば、ユーザ又は制御モジュール１２０）を認証するステップを含む。従って、ユーザが発行元である場合、ユーザ名及びパスワードを依頼する認証プロンプトが、彼又は彼女のアイデンティティを確認するために、ユーザに提示されてよい。幾つかの実施形態では、これは、認証要求２００５を生成している制御モジュール１２０を認証することを含む。幾つかの実施形態では、この認証を実施するために、動作エンティティ１１０、制御モジュール１２０、及び／又は認証サービス１４０は、コンポーネント１１０、１２０、及び１４０により維持されることによる公開鍵ペアの証明を提供されてよい。コンポーネント１１０、１２０、及び１４０は、次に、互いに相互認証するためにこれらの証明を交換し、セキュアな通信リンクを確立してよい。例えば、制御モジュール１２０及び認証サービス１４０は、相互認証のために楕円曲線Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎ（Elliptic－curve Diffie－Hellman (ECDH)）交換で証明を交換し、トランスポート層セキュリティ（Transport Layer Security (TLS)）セッションの共有シークレットを確立してよい。該ＴＬＳセッションを通じて、認証要求２００５及び認証応答２０１５がセキュアに交換されてよい。

【0199】

種々の実施形態で、認証エンジン２０１０により実行される監査は、データベース１３０に監査レポート２０３０のログを維持するステップも含む。従って、認証要求２００５が受信されると、認証エンジン２０１０は、監査レポート２０３０内の要求２００５に関する種々の情報を記録してよい。この情報は、ユーザ名又はコンポーネント名（例えば、オーケストレータ制御モジュール１２０の識別子の値）のような、誰がコマンドを発行したか、及び制御モジュール１２０又は動作エンティティ１１０の名称又はＵＵＩＤのようなコマンドの目標は何か、を含んでよい。この情報は、どんなアクションがコマンドにより指示されているかを含んでよい。この情報は、コマンドが発行されたときを含んでよい。この情報は、ＩＰアドレス、ＵＤＰ又はＴＣＰポート番号、等のような、コマンド発生源の指示を含んでよい。認証エンジン２０１０は、所与の要求２００５が許可されたか又は拒否されたか、及びこのようなイベントで拒否された理由のような、対応する認証応答２０１５に関する情報を記録してもよい。幾つかの実施形態では、データベース１３０は、監査レポート２０３０への認証サービス１４０のアクセスを制限してよい。その結果、サービス１４０は、監査レポート２０３０を書き込むことを許可されるが、任意のレポート２０３０を削除することを許可されない。従って、監査レポート２０３０は、認証サービス１４０が損なわれ又はサービス１４０の認証されたマネジャが彼又は彼女のアクセス権を悪用しようと試みた場合でも、維持されてよい。

【0200】

所与の要求２００５についての認証シート２０２０の評価に基づき、認証エンジン２０１０は、受信したコマンドが認可されたか否かを示す対応する応答２０１５を発行してよい。図２２に関して後述するように、幾つかの実施形態では、認証エンジン２０１０は、自身の認証応答２０１５に署名済みトークンを含んでよい。これは、後続のコンポーネント（例えば、制御モジュール１２０及び／又は動作エンティティ１１０）により、サービス１４０により認可された発行されたコマンドの中で識別された１つ以上のアクションを実行することを確認するために、使用可能である。そうする際に、初期制御モジュール１２０（例えば、オーケストレータ制御モジュール１２０）は、トークンを取得するために認証サービス１４０との相互作用を処理してよく、次に、アクションを実行する１つ以上の他のコンポーネントに及びアクションの認可が許可されたことを検証する者に、トークンを渡すことができ、同じ認可されたアクションについて認証サービス１４０に再度連絡を取る必要がない。

【0201】

図２０Ｂを参照すると、認証サービス１４０の別のブロック図が示される。上述の図２０Ａに示した図示の実施形態では、認証サービス１４０のコンポーネントは、制御モジュール１２０及び／又は動作エンティティ１１０とは別個である。幾つかの実施形態では、しかしながら、認証サービス１４０のコンポーネントは、コンポーネント１２０及び／又は１１０の間で分散されてよい。例えば、図２０Ｂに示すように、認証エンジン２０１０のインスタンスは、制御モジュール１２０により受信されたコマンドが認証シート２０２０内のルールにより定義された許容アクションに従うことを検証するために、制御モジュール１２０に含まれてよい。図示の実施形態では、認証サービス１４０は、認証シート２０２０Ａのマスタコピーを維持する分配部２０４０も含み、自身のローカルで実行される評価を実現するために、認証シート２０２０Ｂのコピーを認証エンジン２０１０の各インスタンスに分配する。幾つかの実施形態では、認証シート２０２０Ｂのローカルコピーは、認証シート２０２０Ａに含まれる各ルールの完全なコピーではなく、該エンジン２０１０に適用可能なルールだけを含んでよい。種々の実施形態で、分配部２０４０は、また、認証シート２０２０Ｂの各コピーに、その完全性を保護するために署名する。幾つかの実施形態では、認証サービス１４０は、図と異なる方法で実装されてよい。例えば、認証エンジン２０１０の各インスタンスは、中央エンティティからシート２０２０のコピーを受信するのではなく、自身のシート２０２０を維持する責任があってよく、認証エンジン２０１０のインスタンスは、動作エンティティ１１０内に位置してもよい、等である。

【0202】

図２１を参照すると、認証シート２０２０のブロック図が示される。図示のように、認証シート２０２０は、上述のように認証要求２００５を許可するか否かを決定するとき認証エンジン２０１０により評価され得るルール２１００のリストを含んでよい。図示の実施形態では、ルール２１００は、許可２１０２、主体２１０４、アクション２１０６、及び他のパラメータ２１０８を含む。他の実施形態では、ルール２１００は、発行されたコマンドを評価するための他の適切な基準を含んでよい。

【0203】

許可２１０２は、種々の実施形態で、所与のルール２１００が権利を許可するか又は権利を制限するかを定義する。例えば、ルール２１００Ａの許可は、主体２１０４Ｊｏｈｎに関して制限的であり、ルール２１００Ｂの許可は、主体２１０４Ｊａｎに関して許容的であることを示す。

【0204】

主体２１０４は、種々の実施形態で、所与のルール２１００に関して、発行元／要求元（つまり、評価中のコマンドを発行しているもの）を識別する。例えば、ルール２１００Ｂ及び２１００Ｃの主体２１０４は、両方のルール２１００が要求元Ｊａｎに関連することを示す。従って、要求２００５が、階層構造の中のコンポーネントのうちの１つへ発行されるべき所与のコマンドについて受信されると、認証エンジン２０１０は、コマンドの要求元が主体２１０４により識別される認可された要求元であるか否かを検証してよい。図２１に示した例はユーザ名であるが、ＩＰアドレス、ＵＵＩＤ、等のような他の形式の識別が使用されてよい。

【0205】

アクション２１０６は、種々の実施形態で、所与のルール２１００に関して容認できる又は容認できないアクションを識別する。例えば、ルール２１００Ｂ及び２１００Ｃのアクションは、主体Ｊａｎがアクション「生成（create）」及び「遷移（transition）」を要求することを許可されていることを示す。ルール２１００Ａの場合には、主体２０１４Ｊｏｈｎに関して全てのアクションを拒否するために、アスタリスク（＊）が使用される。従って、所与のコマンドについて要求２００５が受信されると、認証エンジン２０１０は、要素２０１２及び２１０４を検証することに加えて、コマンドにより実行されるべきアクションが認可されたアクション２１０６のうちの１つであるか否かも検証してよい。

【0206】

パラメータ２１０８は、種々の実施形態で、所与のアクション２１０６に関連付けられた種々の追加基準を含む。例えば、ルール２１００Ｂは、「Ｊａｎ」についてアクション「生成（create）」がデータベースのインスタンスに対して制限されることを示すために、「ＤＢ」及び「インスタンス（instance）」のパラメータを指定する。パラメータ２１０８の他の例は、時間制限（例えば、アクションが要求できる（又はできない）とき）、目標制限（例えば、アクションが実行されてよい（又は実行されてはならない）目標について特定のＵＵＩＤを識別する）、ＩＰアドレス制限、等を含んでよい。

【0207】

種々の実施形態で、認証サービス１４０は、セキュリティチームがルール２１００のうちの種々のルールを設定できるように、コマンドラインインタフェース又はグラフィカルユーザインタフェースであってよいユーザインタフェースを提供する。幾つかの実施形態では、セキュリティチームは、システムを管理する可能性のあるユーザと異なる。ルール２１００は、それらが改ざんされていないことを保証するために、定期的に、署名され、ダウンロードされ、検証されてもよい。

【0208】

図２２を参照すると、トークン２２００を用いる交換のブロック図が示される。上述のように、幾つかの実施形態では、認証サービス１４０は、トークン２２００を発行してよい。トークン２２００は、受信したコマンドに関連付けられたアクションのセットが認証サービス１４０により既に認可されていることを確認するために、制御モジュール１２０及び／又は動作エンティティ１１０により使用可能である。例えば、第１制御モジュール１２０Ａは、データベースの複数のインスタンスを生成するための第１の発行されたコマンド２２１０Ａを受信し、このコマンド２２１０Ａを実施するために、第２コマンド２２１０Ｂをデータベースインスタンスのうちのそれぞれ１つの生成を扱う各制御モジュール１２０（又は動作エンティティ１１０）へ発行することを意図してよい。図示の実施形態では、制御モジュール１２０Ａは、受信した第１コマンド２２１０Ａに対応する認証要求２００５を発行できる。要求２００５を認可することに応答して、認証サービス１４０は、データベースインスタンスを生成するために必要な種々のアクションが認可されていることを示すトークン２２００を含む認証応答２０１５を返送してよい。制御モジュール１２０Ａは、次に、後続の制御モジュール１２０及び／又は動作エンティティ１１０へ発行されるコマンド２２１０Ｂの第２セットに、トークン２２００を含めることができる。後続の制御モジュール１２０及び／又は動作エンティティ１１０は、トークン２２００から、どんなアクションが既に認可されているかを決定し、それらを実行し始めることができ、それらのアクションを実行するための許可を得るために認証サービス１４０に再度連絡する必要がない。

【0209】

トークン２２００は、コマンド２２１０の実行が認証サービス１４０により承認されていることの確認を実現するための任意の適切なコンテンツを含んでよい。図示の実施形態では、トークン２２００は、アクセス権２２０２、タイムスタンプ２２０４、及び署名２２０６を含む。他の実施形態では、トークン２２００は、図示のものより多くの（又は少ない）コンポーネントを含んでよい。幾つかの実施形態では、トークン２２００は、ＪＳＯＮウェブトークン（JSON web token (JWS)）、Ｋｅｒｂｅｒｏｓトークン、Ｘ．５０９証明書、又は署名付きアテステーションのための何らかの他の標準的形式として実装されてよい。

【0210】

アクセス権２２０２は、種々の実施形態で、認証サービス１４０により実行について認可されている特定のアクションのセットを示し、通常、上述のルール２１００からの種々の要素を含んでよい。従って、所与の権利２２０２は、所与のアクション２１０６を識別するだけでなく、該アクション２１０６のためのコマンドを発行することを許可された特定の主体２１０４も示してよい。従って、制御モジュール１２０Ａから特定のアクションを実行するためのコマンド２２１０Ｂを受信することに応答して、制御モジュール１２０Ｂは、制御モジュール１２０Ａがアクセス権２２０２の中で該特定のアクションを要求することを許可されているとして識別されることを検証してよい。幾つかの実施形態では、アクセス権２２０２は、特定のアクションを実行することを認可された目標も識別してよく、これはＩＰアドレス、ＵＵＩＤ、等を用いて識別されてよい。従って、トークン２２００を受信する制御モジュール１２０Ｂは、トークン２２００の中で、自身がコマンド２２１０Ｂの中で識別された特定のアクションを実行するために認可された目標として識別されることを確認してよい。

【0211】

タイムスタンプ２２０４及び署名２２０６は、種々の実施形態で、制御モジュール１２０又は動作エンティティ１１０のような後続の受信者によりトークン２２００についての検証を実現するために含まれる。通常、タイムスタンプ２２０４は、発行されたトークン２２００がどれくらい長い間、有効であるかの何らかの制限であってよい。従って、一実施形態では、タイムスタンプ２２０４は、トークン２２００が発行されたときを示す時間値であってよく、コンポーネント１２０及び１１０は、タイムスタンプ２２０４後の何らかのウインドウの範囲内でのみトークン２２００を受け付けるよう動作してよい。別の実施形態では、タイムスタンプ２２０４は、アクセス権により認可されたアクションが実行されなければならないウインドウを示す開始時間及び停止時間であってよい。更に別の実施形態では、タイムスタンプ２２０４は、トークンがもはや有効ではなくなる満了時間値を示してよい。署名２２０６は、通常、トークン２２００の完全性が保護されることを、又は異なる方法では、該トークン２２００が改ざんされていないことを、保証するために使用されてよい。従って、幾つかの実施形態では、署名２２０６は、コンポーネント１２０及び１１０に知られている対応する信頼される公開鍵を有する、認証サービス１４０により維持される秘密鍵によりトークン２２００のコンテンツから生成される。トークン２２００を受信することに応答して、コンポーネント１１０又は１２０は、発行されたコマンド２２１０Ｂの中で識別された任意のアクションを実行する前に、公開鍵を用いて、トークン２２００のコンテンツに対して署名２２０６を検証してよい。

【0212】

図２３を参照すると、方法２３００のフロー図が示される。方法２３００は、認証サービス１４０のような目標コンピュータ環境に関連付けられた認証サービスを有するコンピュータシステムにより実行される方法の一実施形態である。種々の実施形態で、方法２３００の実行は、目標コンピュータ環境のセキュリティを向上し得る。

【0213】

方法２３００は、ステップ２３１０で開始し、コンピュータシステムは、目標コンピュータ環境内で動作シナリオを実施するコンポーネント（例えば、動作エンティティ１１０、制御モジュール１２０、等）の階層構造の中で許容可能なアクションを定義するセキュリティルールセット（例えば、認証シート２０２０に含まれるルール２１００）を格納する。ステップ２３２０で、コンピュータシステムは、目標コンピュータ環境内で動作シナリオを実施し、該実施は、階層構造の中のコンポーネントへコマンドセットを発行するステップと、コマンドセットがセキュリティルールセットにより定義された許容可能なアクションに従うことを検証するステップと、を含む。

【0214】

種々の実施形態で、コマンドセットを発行するステップは、階層構造のうちの第１コンポーネントが、検証を実行している認証サービス（例えば、認証サービス１４０）へ、特定の発行されたコマンドについての認証要求（例えば、認証要求２００５）を送信するステップと、認証サービスが特定のコマンドがセキュリティルールセットにより定義された許容可能なアクションに従うと決定することに応答して、第１コンポーネントが、コマンドの実行を認可する応答（例えば、認証応答２０１５）を受信するステップと、を含む。認証応答に基づき、第１コンポーネントは、発行されたコマンドの中で識別された１つ以上のアクションを実行する。幾つかの実施形態では、検証するステップは、認証応答を送信するステップの前に、認証要求の送信元を認証するステップを含む。幾つかの実施形態では、検証するステップは、認証サービスが、ログに、認証要求の受信を識別するレポート（例えば、データベース１３０内の監査レポート２０３０）を格納するステップを含む。幾つかの実施形態では、受信した認証応答は、階層構造の中の第２コンポーネントが特定のアクションの実行を認可されたことを示すトークン（例えば、トークン２２００）を含み、１つ以上のアクションを実行するステップは、第１コンポーネントが、第２コンポーネントへ、トークンを含むコマンド（例えば、第２の発行されたコマンド２２１０Ｂ）を発行するステップを含む。トークンは、特定のアクションの実行が認可されていることを確認するために第２コンポーネントにより検証される。幾つかの実施形態では、トークンは、（例えば、アクセス権２２０２の中の）特定のアクション、第１コンポーネント、及び認証サービスの署名（例えば、署名２２０６）を識別する。

【0215】

種々の実施形態で、ルールセットは、認可された要求元（例えば、主体２１０４）及び認可された要求元に関連付けられた１つ以上の認可されたアクション（例えば、アクション２１０６）を識別するルールを含む。検証するステップは、階層構造の中のコンポーネントのうちの１つへ発行されるべきコマンドの指示を受信するステップと、コマンドの要求元が認可された要求元に対応することを検証するステップと、コマンドにより実行されるべきアクションが認可されたアクションのうちの１つであるか否かを検証するステップと、を含む。

【0216】

種々の実施形態で、方法２３００は、階層構造の中の第１コンポーネントが、階層構造の中の第２コンポーネントへコマンドを発行するための要求を受信するステップを更に含み、検証するステップは、第１コンポーネントがコマンドを第２コンポーネントに発行する前に、第１コンポーネントが、要求されたコマンドがセキュリティルールセットにより定義された許容可能なアクションに従うことを（例えば、認証シート２０２０Ｂを用いて）検証するステップを含む。幾つかの実施形態では、第２コンポーネントは、発行されたコマンドを実行するよう動作する動作エンティティ（例えば、動作エンティティ１１０）である。幾つかの実施形態では、第２コンポーネントは、１つ以上の動作エンティティに発行されたコマンドを実行させるよう動作する制御モジュール（制御モジュール１２０）である。

【0217】

図２４を参照すると、テストエンジン１５０のブロック図が示される。上述のように、適切なテストを実行するステップは、システムが信頼できる方法で動作することを保証するために重要であり得る。多くの例では、しかしながら、ステムがその寿命の間に経験し得る全ての可能な状態をテストすることは、特にこのようなテストが手動で実行されるとき、困難であり得る。後述するように、種々の実施形態で、テストエンジン１５０は、システム１００が正しく機能しない状態を識別するために、種々の障害条件の注入を通じて、システム１００のテストを自動化するために利用される。図示の実施形態では、テストエンジン１５０は、スキャンエンジン２４１０、スキャン前グラフ２４２０、スキャン後グラフ２４３０、及び混乱エンジン２４４０を含む。他の実施形態では、テストエンジン１５０は、図と異なる方法で実装されてよい。

【0218】

スキャンエンジン２４１０は、種々の実施形態で、テストエンジン１５０の動作を実現するために、制御モジュール１２０及び動作エンティティ１１０に関する情報の集合を処理する。幾つかの実施形態では、この集合は、スキャンエンジン２４１０がシステム１００内の種々の制御モジュール１２０及び動作エンティティ１１０について知ることを試みる発見動作の実行により開始する。従って、スキャンエンジン２４１０は、最初に、オーケストレータ制御モジュール１２０にそれ自体を記述し及び他の制御モジュール１２０と区別するよう依頼する要求２４１２を送信してよく、オーケストレータ制御モジュール１２０と直接（又は幾つかの実施形態では間接的に）相互作用する。幾つかの実施形態では、オーケストレータ制御モジュール１２０は、システム１００の制御モジュール１２０及び動作エンティティ１１０を識別する、並びにそれらの構成を記述する、グラフデータ構造を含む応答２４１４を送信してよい。この受信した情報に基づき、スキャンエンジン２４１０は、次に、記述応答２４１２を、新たに発見された制御モジュール１２０及び動作エンティティ１１０へ送信してよい。これらのコンポーネントは、種々の適切な情報のうちのいずれかを含み得る対応する記述応答２４１４を送信してよい。例えば、所与の制御モジュール１２０又は動作エンティティ１１０は、それ自体の一般的記述を含んでよく、システム内でのそれ自体の役割を識別することを含んでよく、それ自体のユニバーサルにユニークな識別子（universally unique identifier (UUID)）、ベンダ、バージョン、他の制御モジュール１２０及び／又は動作エンティティ１１０に対する関係、属性、構成変数、等のような情報を含む。幾つかの実施形態では、所与の制御モジュール１２０は、それ自体によりサポートされる種々のアプリケーションプログラミングインタフェース（ＡＰＩ）機能を、応答２４１４の中で識別してもよい。例えば、制御モジュール１２０は、構成情報、ログ、メトリック、ファクト、等をフェッチするような、被制御動作エンティティ１１０に関する情報を読み出すために、スキャンエンジン２４１０からのＡＰＩ呼び出しをサポートしてよい。種々の実施形態で、制御モジュール１２０は、それらの応答２４１４の中で、どんな注入可能な障害条件がサポートされるか、及びテストエンジン１５０により要求可能か、を識別してもよい。例えば、複数のデータベース動作エンティティ１１０を制御する制御モジュール１２０は、自身がデータベースインスタンスの強制終了（又はデータベースインスタンスを含むコンテナの強制終了）、データベースインスタンスの実行停止、データベースインスタンスのスタービング（starving）等をサポートすることをアドバタイズしてよい。

【0219】

種々の実施形態で、スキャンエンジン２４１０は、また、障害条件の注入前のシステム１００の状態及び障害条件の注入後のシステム１００の状態に関する種々の状態情報を収集する。従って、スキャンエンジン２４１０は、上述のように要求２４１２の発行及び応答２４１４の受信を通じて、この情報を収集してよい。幾つかの実施形態では、制御モジュール１２０は、スキャンエンジン２４１０へリアルタイムテレメトリデータを提供してもよい。例えば、データベースインスタンスを維持している制御モジュール１２０は、いくつのデータベースインスタンスが現在動作中かを示し、及びその数が変化するとスキャンエンジン２４１０に通知してよい。上述のように、幾つかの実施形態では、スキャンエンジン２４１０は、テストエンジン１５０の認証サービス１４０への統合を通じて、情報を受信してよい。例えば、制御モジュール１２０が別のデータベースインスタンスを提供するためのコマンドを発行していた場合、制御モジュール１２０がコマンドを実施するための許可を依頼するために認証要求２００５を認証サービス１４０に送信するとき、スキャンエンジン２４１０は、この発行されたコマンドを知ることができる。図示の実施形態では、障害条件注入の前の状態について収集されたメタデータは、スキャン前グラフ２４２０へと組み立てられてよく、障害条件注入の後の状態について収集されたメタデータは、スキャン後グラフ２４３０へと組み立てられてよい後述するように、スキャンエンジン２４１０（又は他の実施形態では、テストエンジン１５０の何らかの他のコンポーネント）は、注入された障害条件がシステム１００にどのように影響するかについての洞察を集めるために、これらのグラフ２４２０及び２４３０を比較してよい。幾つかの実施形態では、このメタデータの編成、及びグラフ２４２０及び２４３０の後の比較を実現するために、スキャンエンジン２４１０は、グラフ２４２０及び２４３０をそれぞれのグラフデータ構造として組み立てる。従って、スキャン前グラフ２４２０の中の各ノードは、システム１００内のそれぞれの制御モジュール１２０又は動作エンティティ１１０に対応してよく、注入前の該モジュール１２０又はエンティティ１１０の状態に関して収集された種々のメタデータを含んでよい。ノード間の辺（edge）は、制御モジュール１２０と動作エンティティ１１０との間に存在する関係に対応してよい。スキャン後グラフ２４３０の中の各ノードは、同様に編成され、障害条件の注入後の所与の制御モジュール１２０又は動作エンティティ１１０の状態に関するメタデータを含んでよい。スキャンエンジン２４１０は、スキャン前グラフ２４２０とスキャン後グラフ２４３０との間でどのノードが変更されたかを識別し、次に変更されたノードのコンテンツを調べて、注入された障害条件から生じた特定の詳細事項を決定することにより、所与の注入された障害条件がシステム１００にどのように影響を与えたかを決定してよい。

【0220】

混乱エンジン２４４０は、種々の実施形態では、注入するための障害条件を選択すること、及びそれらの注入を生じさせるために、適切な制御モジュールに混乱命令２４１８を送信することを担う。これらの障害条件は、システム１００に障害を経験させ得る任意の適切な条件に対応してよい。例えば、幾つかの実施形態では、混乱エンジン２４４０は、動作エンティティ１１０を強制終了し、一時停止し、停止し、ハングし、又は終了する混乱命令２４１８を発行して、システム１００に与えられるその効果を調べてよい。幾つかの実施形態では、混乱エンジン２４４０は動作エンティティ１１０に利用可能なリソースを変更する混乱命令２４１８を発行して、動作エンティティ１１０をスタービング又は過負荷にしてよい。例えば、混乱エンジン２４４０は、動作エンティティ１１０に利用可能な処理リソースを変更して、動作エンティティ１１０が、低い実行優先度を割り当てられ、実行のために少ない頻度をスケジューリングされ、実行のために少ないプロセッサを割り当てられるようにしてよい。混乱エンジン２４４０は、動作エンティティ１１０に少ない揮発性又は不揮発性ストレージを割り当てる、メモリにページをスワッピングして出す、等により、動作エンティティ１１０に利用可能なメモリリソースを変更してよい。混乱エンジン２４４０は、動作エンティティ１１０との通信のために利用可能なネットワーク帯域を削減する、動作エンティティ１１０との通信の待ち時間を増大する、動作エンティティ１１０との通信をドロップする、動作エンティティ１１０のネットワーク接続を切断する、等により、動作エンティティ１１０に利用可能なネットワークリソースを変更してよい。種々の実施形態で、混乱エンジン２４４０は、システム１００内の動作エンティティ１１０の相互依存性を妨害するために障害条件を注入してよい。例えば、アプリケーションサーバ（第１動作エンティティ１１０）は、データベースサーバ（第２動作エンティティ１１０）に格納されたデータに依存してよい。アプリケーションサーバの回復力をテストするために、混乱エンジン２４４０は、データベース内のデータを壊して（単に、データベースをクラッシュして）、アプリケーションサーバ上の影響を決定してよい。別の例として、２つ以上の動作エンティティ１１０は、特定の目的を達成するためにロックステップで（in lockstep）一緒に動作してよく、混乱エンジン２４４０は、デッドロックの達成に成功するか否かを決定するために、エンティティ１１０のうちの１つの動作を停止することを試みてよい。更に別の例として、動作エンティティ１１０は、構成ファイルに格納された構成データに依存してよく、混乱エンジン２４４０は、その動作を妨害するために該データを変更し（又は壊して）よい。混乱エンジン２４４０は、電源障害を生じる、ブレードサーバを切断する、ネットワークスイッチ障害を生じる、等のような他の現実世界の障害条件を注入してもよい。上述のように、これらの障害条件は、（システムの何らかの理論モデルで動作することと対照的に）実際のシステムが実行している間／ライブである間に、該システムに注入されてよい。

【0221】

混乱エンジン２４４０は、どんな障害条件が注入されるべきかを決定するために、任意の適切な選択アルゴリズムを利用してよい。幾つかの実施形態では、混乱エンジン２４４０は、障害条件をランダムに選択し、対応する命令２４１８を該障害条件を注入させるために発行してよい。種々の実施形態で、混乱エンジン２４４０は、システム１００の特定の態様、例えば、特定の動作エンティティ１１０又はエンティティ１１０のグループを目標とするよう指示されて、該態様に関連付けられた障害条件を選択してよい。種々の実施形態で、混乱エンジン２４４０は、制御モジュール１２０及び／又は動作エンティティ１１０へ発行されているコマンドを監視し、発行されたコマンドに基づき注入するための障害条件を選択する。例えば、テストエンジン１５０は、システム１００に関して実行されている更新処理を目標とするよう指示されてよい。制御モジュール１２０が、更新処理に関して特定のコマンドがそれに対して発行されたことの指示２４１６を提供することに応答して、混乱エンジン２４４０は、更新処理を妨害するよう企てるために、対応する障害条件を選択し、適切な混乱指示２４１８を発行してよい。選択された障害条件は、例えば、更新処理中に更新されている動作エンティティ１１０の実行を終了すること、例えば、更新を行っているデータベースインスタンスを含むコンテナをクラッシュすることを含んでよい。選択された障害条件は、別の例として、更新に関連する障害を生じさせる試みの中で、更新処理中に更新されている動作エンティティ１１０との通信のネットワーク遅延を増大することを含んでよい。幾つかの実施形態では、混乱エンジン２４４０は、前に注入した障害条件を識別する過去の情報を維持し、選択のために検討されている障害条件のセット毎に、履歴情報から決定されたとき前に注入されたものと比べてその障害条件がどれ位困難かを示すそれぞれのエントロピースコアを決定してよい。混乱エンジン２４４０は、次に、前に選択されたものと最も異なる（又は少なくとも十分異なる）ことを示すエントロピースコアを有する障害条件を選択してよい。幾つかの実施形態では、混乱エンジン２４４０は、システム１００内に障害を生じた前に注入された障害条件を識別する履歴情報を維持してよく、これらの条件について修正するための試みが行われた後に、それらの修正が成功したか否かを決定するために、これらの障害条件を再選択してよい。

【0222】

上述のように、スキャンエンジン２４１０（又は他のコンポーネント）は、システム１００についてより良好な洞察を集めるために、スキャン前グラフ２４２０及びスキャン後グラフ２４３０からのメタデータを比較してよい。幾つかの例では、この比較は、特定の注入された障害条件により何な影響を受け得るかを決定するために実行されてよい。このような決定は、スキャンエンジン２４１０が、どの動作エンティティ１１０が注入された障害条件により直接影響されるかを識別すること、及びエンティティ１１０間の予期しない関係に起因して、どの動作エンティティ１１０が注入された障害条件により間接的に影響されるかを識別すること、を含んでよい。例えば、ある動作エンティティ１１０をクラッシュさせるために混乱命令２４１８を発行することは、別の動作エンティティ１１０がクラッシュすることを明らかにし得る。従って、何らかの知覚されていない依存関係が存在し得る。このような決定は、動作エンティティ１１０が注入された障害条件により影響されないこと（又は少なくとも障害を経験している時点で影響されないこと）を確立するために使用されてもよい。例えば、スキャンエンジン２４１０は、ネットワーク接続の帯域幅を特定量だけ減少することが、ネットワーク接続を使用する動作エンティティ１１０の障害を生じないことを決定してよい。幾つかの例では、この比較は、障害条件に対するシステム１００の回復力を決定するために実行されてよい。例えば、制御モジュール１２０は、動作エンティティ１１０の特定数のインスタンスを維持するよう指示されてよい。混乱エンジン２４４０は、次に、制御モジュール１２０が強制終了に応答して動作エンティティ１１０の別のインスタンスをインスタンス化するか否かを決定するために、動作エンティティ１１０のインスタンスのうちの１つを強制終了する混乱命令２４１８を発行してよい。この例では、成功した結果は、スキャン前グラフ２４２０及びスキャン後グラフ２４３０の場合に相違が識別されないことであってよい。これは、制御モジュール１２０が、前の強制終了されたインスタンスを置き換えるために、動作エンティティ１１０の新しいインスタンスをインスタンス化することに成功できた後に、システム１００が回復できたことを意味する。

【0223】

多くの例では、テストエンジン１５０をこのように用いて、システム１００をより良く理解するために、システム１００が完全にテストされることを可能にし得る。テストエンジン１５０から取得された知識により、管理者は、潜在的な脆弱点を良好に識別し、それらを解決するために適正な措置を取ることができてよい。管理者は、良好にテストされたシステムは悪条件が生じたときに設計通りに動作できることをより自信を持って知ることもできる。更に、テストエンジン１５０は、システム１００内に展開された（独立した種類の）任意のコンポーネントの障害時動作を自動的且つ完全に探索し得る。

【0224】

図２５を参照すると、方法２５００のフロー図が示される。方法２５００は、テストエンジン１５０を含むコンピュータシステムのような目標コンピュータ環境をテストするコンピュータシステムにより実行される方法の一実施形態である。多くの例では、方法２５００の実行は、修正されると目標コンピュータ環境の回復力を向上する問題を識別するために使用できてよい。

【0225】

方法２５００は、ステップ２５１０で開始し、コンピュータシステムは、制御モジュール（例えば、制御モジュール１２０）及び動作エンティティ（例えば、動作エンティティ１１０）を含むコンポーネントの階層構造を有する目標コンピュータ環境内で動作シナリオを実施する。種々の実施形態で、実施するステップは、目標コンピュータ環境内のコンポーネントに、コマンドセットを発行するステップを含む。ステップ２５２０で、コンピュータシステムは、コマンドセットのうちの特定のコマンドが発行されたことの指示（例えば、コマンド指示２４１６）を受信する。ステップ２５３０で、指示を受信することに応答して、コンピュータシステムは、目標コンピュータ環境をテストするために、動作エンティティのうちの１つに関する障害条件を注入するよう、（例えば、混乱命令２４１８を介して）制御モジュールに指示する。

【0226】

種々の実施形態で、方法２５００は、コンピュータシステムが、障害条件の注入前の目標コンピュータ環境の第１状態に関するメタデータ（例えば、スキャン前グラフ２４２０）を収集するステップと、障害条件の注入後の目標コンピュータ環境の第２状態に関するメタデータ（例えば、スキャン後グラフ２４３０）を収集するステップと、第１状態に関するメタデータと第２状態に関するメタデータとを比較して、障害条件の効果を決定するステップと、を更に含む。幾つかの実施形態では、コンピュータシステムは、第１グラフデータ構造を、第１状態に関する収集したメタデータから組み立て、第２グラフデータ構造を、第２状態に関する収集したメタデータから組み立て、第１グラフデータ構造と第２グラフデータ構造とを比較する。幾つかの実施形態では、コンピュータシステムは、受信した指示に基づき、特定のコマンドが、階層構造の中のコンポーネントのうちの１つ以上を更新する更新処理に関連付けられることを決定し、更新処理を妨害することを試みるために障害条件を選択する。このような一実施形態では、選択された障害条件は、更新処理中に更新されている動作エンティティの実行を終了することを含む。このような一実施形態では、選択された障害条件は、更新処理中に更新されている動作エンティティとの通信の遅延を増大することを含む。

【0227】

種々の実施形態で、方法２５００は、コンピュータシステムが、制御モジュールによりサポートされる注入可能な障害条件のセットを識別するために（例えば、要求２４１２及び応答２４１４により）発見動作を実行するステップと、特定の発行されたコマンドに基づき、指示された制御モジュールによる注入のために注入可能な障害条件のセットのうちの注入可能な障害条件を選択するステップと、を更に含む。幾つかの実施形態では、発見動作は、コンピュータシステムが、制御モジュールのうちの１つ以上のアイデンティティを決定するために、階層構造のうちのオーケストレータ（例えば、オーケストレータ制御モジュール１２０）に連絡するステップを含み、オーケストレータは、他の制御モジュールにコマンドを発行する制御モジュールである。幾つかの実施形態では、発見動作は、コンピュータシステムが、決定されたアイデンティティに基づき、１つ以上の制御モジュールによりサポートされる注入可能な障害条件を識別するよう、１つ以上の制御モジュールに依頼する要求を、１つ以上の制御モジュールへ送信するステップを含む。幾つかの実施形態では、コンピュータシステムは、前に注入された障害条件を識別する履歴情報を維持し、該履歴情報に基づき、注入可能な障害条件のセットのうちの障害条件毎にそれぞれ差異スコアを決定する。それぞれの差異スコアは、前に注入された障害条件に対する当該障害条件の相違を示す。このような一実施形態では、注入のために障害条件を選択するステップは、決定された差異スコアに更に基づく。

【0228】

＜例示的なコンピュータシステム＞
図２６を参照すると、例示的なコンピュータシステム２６００のブロック図が示され、システム１００、動作エンティティ１１０、制御モジュール１２０、データベース１３０、及び／又は認証サービス１４０を実装してよい。コンピュータシステム２６００は、相互接続２６６０（例えば、システムバス）を介してシステムメモリ２６２０及びＩ／Ｏインタフェース２６４０に結合されるプロセッササブシステム２６８０を含む。Ｉ／Ｏインタフェース２６４０は、１つ以上の装置２６５０に結合される。コンピュータシステム２６００は、限定ではないが、サーバシステム、パーソナルコンピュータシステム、デスクトップコンピュータ、ラップトップ又はノードブックコンピュータ、メインフレームコンピュータシステム、タブレットコンピュータ、ハンドヘルドコンピュータ、ワークステーション、ネットワークコンピュータ、携帯電話機、音楽プレイヤ又はＰＤＡ（personal data assistant）のような消費者装置を含む、種々の種類の装置のうちのいずれであってもよい。便宜上単一のコンピュータシステム２６００が図２６に示されるが、システム２６００は、一緒に動作する２つ以上のコンピュータシステムとして実装されてもよい。

【0229】

プロセッササブシステム２６８０は、１つ以上のプロセッサ又は処理ユニットを含んでよい。コンピュータシステム２６００の種々の実施形態では、プロセッササブシステム２６８０の複数のインスタンスが相互接続２６６０に結合されてよい。種々の実施形態では、プロセッササブシステム２６８０（又は２６８０内の各処理ユニット）は、キャッシュ又は他の形式のオンボードメモリを含んでよい。

【0230】

システムメモリ２６２０は、プロセッササブシステム２６８０により実行可能なプログラム命令を格納し、システム２６００に本願明細書に記載の種々の動作を実行させるために使用可能である。システムメモリ２６２０は、異なる物理メモリ媒体、例えばハードディスク記憶装置、フロッピーディスク記憶装置、取り外し可能ディスク記憶装置、フラッシュメモリ、ランダムアクセスメモリ（ＲＡＭ、ＳＲＡＭ、ＥＤＯ ＲＡＭ、ＳＤＲＡＭ、ＤＤＲ、ＳＤＲＡＭ、ＲＡＭＢＵＳ ＲＡＭ、等）、読み出し専用メモリ（ＰＲＯＭ、ＥＥＰＲＯＭ、等）、等を用いて実装されてよい。コンピュータシステム２６００内のメモリは、メモリ２６２０のような主記憶装置に限定されない。むしろ、コンピュータシステム２６００は、プロセッササブシステム２６８０内のキャッシュメモリ及びＩ／Ｏ装置２６５０上の２次記憶（例えば、ハードドライブ、ストレージアレイ、等）のような他の形式の記憶装置を含んでもよい。幾つかの実施形態では、これらの他の形式の記憶装置は、プロセッササブシステム２６８０により実行可能なプログラム命令を格納してもよい。幾つかの実施形態では、実行されると、動作エンティティ１１０、制御モジュール１２０、データベース１３０、認証サービス１４０、及び／又はテストエンジン１５０を実装するプログラム命令は、システムメモリ２６２０内に含まれ／格納されてよい。

【0231】

Ｉ／Ｏインタフェース２６４０は、種々の実施形態に従い他の装置と結合され通信するよう構成される種々の種類のインタフェースのうちのいずれであってもよい。一実施形態でっは、Ｉ／Ｏインタフェース２６４０は、フロントサイドから１つ以上のバックサイドバスへのブリッジチップ（例えば、Ｓｏｕｔｈｂｒｉｇｄｇｅ）である。Ｉ／Ｏインタフェース２６４０は、１つ以上の対応するバス又は他のインタフェースを介して１つ以上のＩ／Ｏ装置２６５０に結合されてよい。Ｉ／Ｏ装置２６５０の例は、記憶装置（ハードドライブ、光ドライブ、取り外し可能フラッシュドライブ、記憶アレイ、ＳＡＮ、又はそれらの関連する制御部）、（例えば、ローカル又はワイドエリアネットワークへの）ネットワークインタフェース装置、又は他の装置（例えば、グラフィック、ユーザインタフェース装置、等）を含む。一実施形態では、コンピュータシステム２６００は、（例えば、ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ、Ｅｔｈｅｒｎｅｔ、等を介して通信するよう構成される）ネットワークインタフェース２６５０を介してネットワークに結合される。

【0232】

本願の主題の実現は、限定ではなく以下の例１～２０を含む。
（例１）目標コンピュータ環境の動作シナリオを管理する方法であって、前記方法は、
コンピュータシステムにより、前記動作シナリオのためのコマンドセットを定義する動作情報にアクセスするステップと、
前記コンピュータシステムにより、前記動作シナリオを実施する前記目標コンピュータ環境の中で利用されるべき動作エンティティセットのブループリントにアクセスするステップであって、前記動作エンティティセットは、ハードウェアエンティティ、ソフトウェアエンティティ、及び情報エンティティを含む、ステップと、
前記コンピュータシステムにより、前記目標コンピュータ環境のための前記動作シナリオを実施するステップと、
を含み、前記実施するステップは、
制御モジュールの階層構造を実行するステップを含み、前記階層構造は、該階層構造の最上位にあり、該階層構造の次のレベルにある制御モジュールに命令を発行することにより前記コマンドセットを実行するために実行可能なオーケストレータ制御モジュールを含み、前記制御モジュールの階層構造は、前記動作エンティティセットのうちの１つ以上の動作エンティティの状態を変化させることによることを含む前記動作シナリオを達成するためにそれぞれのブループリントに従い前記動作エンティティセットを管理するために実行可能な制御モジュールを含む、方法。
（例２）所与の動作エンティティは、該所与の動作エンティティを識別するユニークな識別子に関連付けられ、前記命令のうちの特定の命令は、前記所与の動作エンティティに関連付けられ、前記特定の命令を発行するステプは、
前記ユニークな識別子に基づき、前記所与の動作エンティティを管理する前記制御モジュールのうちの特定の１つを決定するステップと、
前記特定の命令を前記特定の制御モジュールに発行するステップと、
を含む、例１に記載の方法。
（例３）所与のブループリントは,前記動作エンティティセットのうちの対応する第１動作エンティティについて、前記第１動作エンティティと前記動作エンティティセットのうちの１つ以上の他の動作エンティティとの間の関係セットを示し、前記関係セットは、前記コマンドセットのうちのコマンドセットが実行できる順序に影響する、例１又は２に記載の方法。
（例４）前記関係セットは、前記動作エンティティセットのうちの前記第１動作エンティティと第２動作エンティティとの間の関係を含み、前記第１動作エンティティの状態を変化させるために前記命令のうちの特定の命令を実行するステップは、前記第１動作エンティティの前記状態を変化させる前に、前記第２動作エンティティの状態を変化させるステップを含む、例３に記載の方法。
（例５）前記第１動作エンティティと前記第２動作エンティティとの間の前記関係は、前記第１動作エンティティが前記第２動作エンティティの存在に依存するという依存関係である、例４に記載の方法。
（例６）所与の動作エンティティは、制御アプリケーションプログラミングインタフェース（ＡＰＩ）によりサポートされる機能セットのうちの１つ以上の機能を実施し、前記１つ以上の実施された機能は、制御モジュールが前記所与の動作エンティティの状態を変化させることを可能にする、例１～５のいずれか一項に記載の方法。
（例７）前記ブループリントのうちの特定の１つは、前記所与の動作エンティティに関連付けられ、前記特定のブループリントは、前記所与の動作エンティティに関連付けられた現在ライフサイクルステージを示すライフサイクル値を指定し、前記ライフサイクル値は、前記１つ以上の実施される機能のうちのどれが前記ライフサイクルステージのために呼び出し可能かを決定するために制御モジュールにより使用可能である、例６に記載の方法。
（例８）前記動作エンティティセットのうちの第１の特定の動作エンティティは、前記階層構造の中で、前記動作エンティティセットのうちの第２動作エンティティと異なるレベルにあり、前記動作エンティティセットを管理するために実行可能な前記制御モジュールのうちの制御モジュールは、前記階層構造の異なるレベルにある、例１～７のいずれか一項に記載の方法。
（例９）前記命令のうちの特定の命令を実行するステップは、前記ソフトウェアエンティティに、別の情報エンティティをインスタンス化させるステップを含む、例１～８のいずれか一項に記載の方法。
（例１０）前記動作シナリオは、前記動作エンティティセットに含まれる１つ以上のソフトウェアエンティティの状態を変化させて、前記１つ以上のソフトウェアエンティティを第１ソフトウェアバージョンから第２ソフトウェアバージョンに遷移させることを含む、例１～９のいずれか一項に記載の方法。
（例１１）前記ハードウェアエンティティはプロセッサセットに対応し、前記ソフトウェアエンティティは、前記プロセッサセットを実行するデータベースサーバに対応し、前記情報エンティティは、前記データベースサーバにより管理される論理データベースに対応する、例１～１０のいずれか一項に記載の方法。
（例１２）非一時的コンピュータ可読媒体であって、格納されたプログラム命令を有し、前記プログラム命令は、コンピュータシステムに動作を実行させることができ、前記動作は、
目標コンピュータ環境に関連する動作シナリオのためのコマンドセットを定義する動作情報にアクセスするステップと、
前記動作シナリオを実施する前記目標コンピュータ環境の中で利用されるべき動作エンティティセットのブループリントにアクセスするステップであって、前記動作エンティティセットは、ハードウェアエンティティ、ソフトウェアエンティティ、及び情報エンティティを含む、ステップと、
前記動作シナリオを実施するステップと、
を含み、前記実施するステップは、
制御モジュールの階層構造を実行するステップを含み、前記階層構造は、該階層構造の最上位にあり、該階層構造の次のレベルにある制御モジュールに命令を発行することにより前記コマンドセットを実行するために実行可能なオーケストレータ制御モジュールを含み、前記制御モジュールの階層構造は、前記動作エンティティセットのうちの１つ以上の状態を変化させることによることを含む前記動作シナリオを達成するためにそれぞれのブループリントに従い前記動作エンティティセットを管理するために実行可能な制御モジュールを含む、媒体。
（例１３）前記アクセスされたブループリントのうちの特定のブループリントは、前記動作エンティティセットのうちの対応する動作エンティティのライフサイクル値及びタイプ値を指定し、前記ライフサイクル値及びタイプ値は、前記対応する動作エンティティの状態を変化させるために呼び出し可能な１つ以上の機能を決定するために使用可能である、例１２に記載の媒体。
（例１４）前記アクセスされたブループリントのうちの特定のブループリントは、前記動作エンティティセットのうちの対応する動作エンティティが前記動作エンティティセットのうちの別の特定の動作エンティティに依存するという関係を指定し、前記対応する動作エンティティを初期化する命令のうちの特定の命令を実行するステップは、前記対応する動作エンティティを初期化する前に、前記他の特定の動作エンティティを初期化するステップを含む、例１２に記載の媒体。
（例１５）前記動作は、
前記アクセスされたブループリントのうちの特定のブループリントが有効か否かを決定するために、前記特定のブループリントを検証するステップ、を更に含み、前記検証するステップは、
対応する定義にアクセスするステップであって、前記対応する定義は、該定義に対応する所与のブループリントの中で指定されるべき許容可能な値セットを識別する、ステップと、
前記アクセスされた定義に基づき、前記特定のブループリントが前記アクセス可能な値セットに含まれない値を指定するか否かを決定するステップと、
を含む、例１２に記載の媒体。
（例１６）動作エンティティセットを管理する方法であって、
前記動作エンティティセットを含むコンピュータシステムにより、制御モジュールの階層構造を実行するステップであって、前記階層構造は、該階層構造の最上位にあり、前記動作エンティティセットを管理するために該階層構造の中の他の制御モジュールと通信するよう動作するオーケストレータ制御モジュールを有し、前記動作エンティティセットは、ハードウェアエンティティ、ソフトウェアエンティティ、及び情報エンティティを含む、ステップと、
前記オーケストレータ制御モジュールにより、動作情報にアクセスするステップであって、前記動作情報は、前記動作エンティティセットに関連する動作シナリオのステップシーケンスを実施するためのコマンドを有するワークフローを指定する、ステップと、
前記オーケストレータ制御モジュールにより、前記動作シナリオを実施するために前記ワークフローの前記コマンドを実施するステップであって、前記実施するステップは、前記動作エンティティセットのうちの１つ以上の動作エンティティの状態を変化させるために前記他の制御モジュールのうちの１つ以上の制御モジュールに命令を発行するステップと、
を含む方法。
（例１７）前記階層構造の中の特定の制御モジュールは、前記動作エンティティセットの属性を定義するそれぞれのブループリントに従い、前記動作エンティティセットを管理するよう動作する、例１６に記載の方法。
（例１８）前記属性は、前記動作エンティティセットのうちの動作エンティティの間の関係に関する情報を定義する関係属性を含み、前記関係は、前記１つ以上の動作エンティティの前記状態が前記命令に基づき変化される順序に影響する、例１７に記載の方法。
（例１９）前記１つ以上の他の制御モジュールは、前記オーケストレータ制御モジュールから受信された前記命令のうちの１つ以上の命令を、前記動作エンティティセットを管理する前記特定の制御モジュールへルーティングするよう動作する、例１７に記載の方法。
（例２０）前記１つ以上の他の制御モジュールは、前記動作エンティティセットに対応するユニークな識別子のセットに基づき、前記１つ以上の命令をルーティングするよう動作する、例１９に記載の方法。

【0233】

特定の実施形態が上述されたが、これらの実施形態は、単一の実施形態のみが特定の特徴に関して記載されたとしても、本開示の範囲を限定することを意図しない。本開示で提供される特徴の例は、特に断りの無い限り、限定ではなく説明を意図している。上述の説明は、本開示の利益を享受する当業者に明らかなように、このような代替、変更、及び均等物をカバーすることを意図している。

【0234】

本開示の範囲は、本願明細書で解決される問題のうちのいずれか又は全部を軽減するか否かにかかわらず、本願明細書に開示した任意の特徴又は特徴の結合（明示的又は暗示的のいずれも）、又はそれらの任意の一般化を含む。従って、新規な請求項が、任意のこのような特徴の組み合わせに対して、本願（又は本願に基づく優先権を主張する出願）の審査中に形成され得る。特に、添付の請求項を参照して、従属請求項による特徴は、独立請求項の特徴と結合されてよく、それぞれの独立請求項の特徴は、添付の請求の範囲に列挙されない特定の組み合わせではなく、任意の適切な方法で結合されてよい。

【図1】

【図2】

【図3A】

【図3B】

【図3C】

【図3D】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20A】

【図20B】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【国際調査報告】