本開示は、「一実施形態」又は「実施形態」への言及を含む。「一実施形態では」又は「実施形態では」の語句の出現は、必ずしも同じ実施形態を表さない。特定の特徴、構造、又は特性は、本開示と矛盾しない任意の適切な方法で結合されてよい。
本開示において、異なるエンティティ(これは、「ユニット」、「回路」、他のコンポーネント、等のように様々に表されてよい)は、1つ以上のタスク又は動作を実行するよう「構成される」と記載され又は請求されてよい。この明確な記述-[1つ以上のタスクを実行する]よう構成される[エンティティ]-は、本願明細書で、構造(つまり、電子回路のような何らかの物理的なもの)を表すために使用される。より具体的には、この明確な記述は、この構造が動作中に1つ以上のタスクを実行するよう配置されることを示すために使用される。構造は、該構造が現在作動中でない場合でも、何らかのタスクを実行する「よう構成される」と言える。「ネットワークを介して通信するよう構成されるネットワークインタフェース」は、例えば、対象の集積回路が現在使用中でない場合でも(例えば、それに電源が接続されていない)、動作中にこの機能を実行する回路を有する集積回路を包含することを意図する。従って、何らかのタスクを実行する「よう構成される」と記載され又は引用されるエンティティは、装置、回路、タスクを実施するために実行可能なプログラム命令を格納するメモリ、等のような何らかの物理的なものを表す。この語法は、本願明細書で、何らかの無形物を表すために使用されない。従って、「~よう構成される」構成は、本願明細書では、アプリケーションプログラミングインタフェース(application programming interface(API))のようなソフトウェアエンティティを表すために使用されない。
用語「~よう構成される(configured to)」は、「構成可能である(configurable to」を意味しない。未設定FPGAは、例えば、何らかの特定の機能を実行するよう「構成される」と考えられない。しかしながら、未設定FPGAは、該機能を実行するよう「構成可能」であってよく、設定(プログラミング)後に該機能を実行するよう「構成され」てよい。
本願明細書で使用されるとき、用語「第1」、「第2」、等は、それらが先行する名詞のラベルとして使用され、特に断りの無い限り、いかなる種類の順序(例えば、空間的、時間的、論理的、等)も意味しない。例えば、8個の処理コアを有するプロセッサでは、用語「第1」及び「第2」処理コアは、8個の処理コアのうちの任意の2つを表すために使用できる。言い換えると、「第1」及び「第2」処理コアは、例えば処理コア0及び1に限定されない。
本願明細書で使用されるとき、用語「に基づき」は、決定に影響する1つ以上の要素を記述するために使用される。この用語は、追加要素が決定に影響し得る可能性を排除しない。つまり、決定は、特定の要素に単独で基づいて、又は特定の要素及び他の指定されていない要素に基づいてよい。語句「Bに基づきAを決定する」を検討する。この語句は、BがAを決定するための要因であること、又はAの決定に影響することを指定する。この語句は、Aの決定が何からの他の因子、例えばCに基づいてもよいことを排除しない。この語句は、AがBにのみ基づき決定される実施形態を包含することも意図する。本願明細書で使用されるとき、語法「に基づき」は、従って、「に少なくとも部分的に基づき」と同義である。
実行リストからコマンドを入力するソフトウェアスクリプトを使用する代わりに、一部の開発者は、彼らのシステムを管理するために、Kubernetes(登録商標)のような大規模展開システムを使用し始めている。Kubernetes(登録商標)は、コンテナの展開及び管理を自動化するコンテナ型(container-centric)管理環境を提供する。コンテナは、ポータブルな自給自足型のユニットであり、アプリケーション及びその依存関係を有する。従って、開発者は、Kubernetes(登録商標)を使用して、例えばデータベースサーバを含むコンテナを展開し得る。Kubernetes(登録商標)は、しかしながら、様々な理由から、システム全体を管理するには不十分である。Kubernetes(登録商標)は、ワーカノード(例えば、仮想マシン)の上にあるコンテナを管理するよう設計された。例えば、Kubernetes(登録商標)は、ハードウェア又は論理データベース若しくは構成仕様のような情報エンティティを管理するために使用できない。Kubernetes(登録商標)は、コンテナ内の全てのものに渡る可視性及び/又は制御を提供しない。例えば、Kubernetes(登録商標)は、コンテナ内にインスタンス化されたデータベースサーバとインタフェースできない。その結果、コンテナ内のシステムの起動、それらのシステムのトラブルシューティング、及びそれらのシステム上のメタデータの収集、のような管理目的は、Kubernetes(登録商標)のみを用いて実行できない。Spinnaker(登録商標)のような他のアプローチは、システム内で発見され得るコンポーネントの全範囲を制御する能力に欠けるので、Kubernetes(登録商標)と同じ欠点を共有する。
システムの管理は伝統的に非常に困難であるが、これらのシステムをテストすること又は生じるトラブルシューティングの問題は同等に困難である。前述のように、実行リストが失敗すると、実行リストは該実行リストがクラッシュ前にシステムをおいた状態に関する情報を提供しないので、システムの現在状態を見分けることは通常困難である。更に、通常、テストされるべきシステム内部は非常に複雑である。その結果、システムの部分は、システムの複雑さにより見逃された場合にはテストされないことがあり、それらのテストされるべき部分が十分に完全にテストされないことがある。
本開示は、従来のアプローチの欠点の一部又は全部を克服する、システムを管理する技術を記載する。後述する種々の実施形態で、システム内の動作エンティティ(operational entity)(例えば、データベースサーバ、論理データベース、等)は、形式的な構造化された方法で記載され、従って制御モジュールにより管理される。一般的に、システム内の動作エンティティの多くは、ハードウェア、又はハードウェアに格納された情報である。動作エンティティが単にシステムの物理的な有形コンポーネントである場合、それは本開示では「ハードウェアエンティティ」と呼ばれる。物理的サーバラック及びブレードは、ハードウェアエンティティの例である。動作エンティティがハードウェアではない場合、それは、情報で構成されてよく、つまりハードウェアに格納されたデータであってよい。この情報は、実行可能又は非実行可能であってよい。動作を実行するためにシステムにより実行可能な情報は、本開示では「ソフトウェアエンティティ」と呼ばれる。データベースサーバインスタンス、警告サーバインスタンス、及びメトリックサーバインスタンスは、ソフトウェアエンティティの例である。一方で、実行可能ではない、システム内の移情報は、本開示では「情報エンティティ」(又は代替として「情報型(information-oriented)エンティティ」)と呼ばれる。データベースバックアップイメージ、及び複数テナントデータベースのうちのテナントのデータを含むテナント構成は、情報エンティティの例である。
これらの3つのエンティティ種類、つまりハードウェア、ソフトウェア、及び情報は、システム内で見付かる任意の動作エンティティの「構成ブロック(building blocks)」と考えることができる。本開示の目的のために、システム内の任意の動作エンティティは、3つの構成ブロックエンティティ種類のうちの1つを用いて、又はこれらの構成ブロックのうちの2つ以上を含む組み合わせエンティティ種類(又は代替として「組成物(formation)」)を用いて、記載され得る。組成物(formation)エンティティの一例は、「データベースシステム」の動作エンティティであってよい。何故なら、データベースシステムは、プロセッサ及び記憶媒体(ハードウェアエンティティ)、該プロセッサ上で実行するデータベースサーバ(ソフトウェアエンティティ)、及び該データベースサーバにより管理される論理データベース(情報エンティティ)を含み得るからである。組成物エンティティの別の例は、「ストレージ領域ネットワーク」の動作エンティティであってよい。何故なら、ストレージ領域ネットワークは、記憶媒体、ネットワークスイッチ(これは、それ自体がハードウェア及びソフトウェアエンティティの組成物であってよい)、及び該記憶媒体上に格納されるデータオブジェクト(情報エンティティ)を含み得るからである。
種々の実施形態で、システムの意図される/期待される状態、つまりシステムのオペレータがシステムを置きたい状態は、最初に定義される。システムの意図される状態を定義することは、これらの動作エンティティの間の関係と一緒にシステムを設定する種々の動作エンティティを定義する定義及びブループリント(blueprints)を生成することを含み得る。これらの定義及びブループリントは、動作エンティティを記述するための構造化された方法を提供する共通のスキーマに従ってよい。更に説明するように、定義及びブループリントは、制御モジュールが定義及びブループリントに対応する動作エンティティを管理できるようにする情報を、制御モジュールに伝達してよい。例えば、制御モジュールがデータベースサービス動作エンティティを管理している場合、制御モジュールは、データベースサービスにリンクされたブループリントから、データベースサービスが3つの実行中のデータベースサーバを含むべきであると知ることができる。制御モジュールが、データベースサービスが2つの実行中のデータベースサーバのみを含むことを知った場合、制御モジュールは、該データベースサービスエンティティの意図された状態に達するために、第3データベースサーバを起動してよい。
2つの実行中のデータベースサーバから3つの実行中のデータベースサーバへのこの遷移は、2つの状態間のシステムの状態遷移として見ることができる。従って、システムの動作管理は、システムが存在し得る及び異なる状態を通じて遷移し得る状態マシンとして又はそれと同等であると見ることができる。上述のように、定義及びブループリントは、システム内のエンティティ及び従ってシステム全体としての意図される状態を定義し得る。種々の実施形態で、システムの制御モジュールは、システムが意図された状態に到達するまで、システムをある状態から別の状態へと遷移させる。従って、制御モジュールは、システムが意図された状態に留まることを保証するために、システムを監視し続けてよい。システムが意図された状態を離れた場合(例えば、エンティティがクラッシュした場合)、制御モジュールは、システム内のコンポーネントに命令を発行することにより、システムを意図された状態に戻すために、1つ以上のコマンドを実施してよい。幾つかの場合には、コマンドは、ユーザが読むことができる方法で記述されてよく(つまり、人間により読み取り可能なコマンド)、従って、制御モジュールは、そのコマンドをシステム内のコンポーネントにより理解可能な命令に変換してよい。幾つかの場合には、コマンドは、理解可能な命令であってよく、従って、制御モジュールは、それを変換する必要がなくてよく、制御モジュールは、該コマンドをコンポーネントへの命令として発行してよい。本願明細書で使用されるとき、用語「コンポーネント」は、動作エンティティ及び制御モジュールを包含することを意図する。従って、用語「コンポーネント」は、動作エンティティ又は制御モジュールを表し得る。
システムの状態間で遷移を実現するために、種々の実施形態で、システムの現在状態を理解し及び必要な場合及び必要なときにシステムを変化させる方法を提供する制御アプリケーションプログラミングインタフェース(application programming interface (API))が実装される。制御APIは、動作エンティティの状態に関して学習し及び該動作エンティティによりサポートされる機能を呼び出すメカニズムを提供するAPI呼び出しのセットを通じて、システム内の動作エンティティへの構造化されたアクセスを提供してよい。種々の実施形態で、制御モジュールは制御APIをホスティングし、従って、ユーザ及び/又は他の制御モジュールが制御APIを介して該制御モジュールにより管理される動作エンティティにアクセスできるようにする。
種々の実施形態で、制御モジュール及びシステム内の動作エンティティは階層構造を形成してよい。該階層構造では、オーケストレータ制御モジュールが階層構造の最上位に存在してよく、階層構造を通じて下方へ下位レベルに存在する制御モジュール及び動作エンティティへ命令(これは制御API呼び出しを含んでよい)を発行してよい。一例として、オーケストレータ制御モジュールは、コマンドラインツールを介してユーザから、特定エンティティに関するコマンドを受信してよい。従って、オーケストレータ制御モジュールは、適切な制御API呼び出しを行うことにより、階層構造のレベルを通じて、特定エンティティへの命令を実施し得る管理制御モジュールへ、命令(これはコマンドに基づく)をルーティングしてよい。該呼び出しは、特定の動作エンティティに別の状態への遷移を生じさせてよい。
この枠組みは、動作シナリオを実施させることを可能にする。大まかに言うと、用語「動作シナリオ(operational scenario)」は、本願明細書では、何らかのアクションを実行するために使用されるステップのシーケンスを表すために使用される。例えば、ある動作シナリオは、データベースサービスの起動を含んでよく、別の動作シナリオはデータベースサービスの更新を含んでよい。動作シナリオは、制御API呼び出しのセットを介して実行され得る順序付きコマンドセットを含むワークフローを用いて実施されてよい。例えば、データベースサービスを更新するワークフローは、データベースサービスの動作エンティティを「オンライン」から「オフライン」へ遷移させるコマンド、それらをそれらの現在バージョンから更新されたバージョンへ遷移させるコマンド、及びそれらを遷移させてオフラインからオンラインに戻すコマンド、を含んでよい。幾つかの実施形態では、オーケストレータ制御モジュールは、ワークフロー情報にアクセスし、対応するワークフローを達成する目的で適切な動作エンティティに対する変化を生成するために、ワークフロー情報に基づき、階層構造を通じて下方へ命令を発行する。
動作シナリオは、代替として、適切なエンティティの意図された状態のセットを定義することにより実施されてよい。オーケストレータ制御モジュールは、次に、意図された状態のセットから、該状態に達するためのコマンドを決定してよい。例えば、意図された状態(又は目標)は、3つのデータベースサーバを含む実行データベースサービスを有することであってよい。従って、オーケストレータ制御モジュールは、3つのデータベースサーバを起動する制御API呼び出しを有するコマンドを生成してよい。この処理は、意図された状態に関するオーケストレータの「推理(reasoning)」と呼ぶことができる。この推理は、従って、幾つかの場合には、ユーザが目標を定義することを可能にする。ここで、当該目標を達成するために必要な特定ステップ又はアクションを明瞭に表現する必要がなく、これは代わりにオーケストレータにより実行される「推理」により決定され得る。幾つかの場合には、このアプローチは、ワークフローを定義するよりもロバストであり得る。何故なら、システムは、それ自体の意図された状態で終了し得るからである(例えば、コンテナの消失は、該コンテナを有しない意図された状態を満たし得る)。
これらの技術は、自動的にシステム全体を記述し、そして管理できるので、これらの技術は従来のアプローチに勝り有利であり得る。Kubernetes(登録商標)のような従来のアプローチは、コンテナを定義しインスタンス化することを可能にするが、システム内の全範囲のコンポーネント(例えば、ハードウェア、コンテナ内のソフトウェア、論理データベースのような情報構造、等)を制御するメカニズムを提供しない。更にこれらの技術は、システムの意図された状態を定義することを可能にし、従ってシステムを自動的な方法で制御可能にし、これはシステムを管理するための人間の介入への依存を低減する。つまり、システム内の制御モジュールは、システムが意図された状態にあることを保証するために、システムを絶えず監視し得る。システムが異なる望ましくない状態に変化した場合、制御モジュールは、多くの場合に人間の介入無しにシステムを遷移させて意図された状態へと戻し得る。この自動的方式は、システムを管理する際に巻き込まれる人の数を削減できる。更に、エンティティを記述するための共通フォーマットの使用は、操作を簡略化し、動作シナリオをテストする能力を向上し、製造環境でソフトウェアを管理するために必要なコードの量を削減し得る。これらの技術は、展開全体を再生成することなく、(例えば、アプリケーションサーバのプールにノードセットを追加することにより)展開が変更され得る変わりやすい展開に、及び(例えば、展開全体が展開に対する変化の度に再生成される)不変の展開に、更に適用されてよい。これらの技術は、(完全に別個のツールを使用しなければならないことに対して)統合された障害テスト、統合されたセキュリティ、及び統合されたトラブルシューティングも提供する。
図1を参照すると、システム100のブロック図が示される。図示の実施形態では、システム100は、動作エンティティ110、制御モジュール120(オーケストレータ制御モジュール120を含む)、データベース130、及び認証サービス140を含む。また図示のように、データベース130は動作情報(operational information)135を含み、認証サービス140はテストエンジン150を含む。幾つかの実施形態では、システム100は、図と異なる方法で実装されてよい。一例として、システム100は、複数のオーケストレータ制御モジュール120、別のレベルの動作エンティティ110及び/又は制御モジュール120、複数のデータベース130、等を含んでよい。
動作エンティティ110は、種々の実施形態で、1つ以上の要素、及びそれらの要素に関連する情報の集合を含む。要素の例は、例えば、物理プロセッサ、物理メモリ、仮想マシン、仮想マシンイメージ、論理データベース、データベーススナップショット、コンテナ、コンテナイメージ、データベースサービス、オペレーティングシステム、ワークフロー、アドレスセンタ、ネットワーク境界/ドメイン、等を含んでよい。上述のように、3つの基本的な種類の動作エンティティ110がある:ハードウェアエンティティ110、ソフトウェアエンティティ110、及び情報エンティティ110である。動作エンティティ110の種類は、種々の実施形態では、どんなエンティティが該動作エンティティを構成するかに依存する。例えば、物理プロセッサのみを含む動作エンティティ110は、ハードウェアエンティティ110と考えられる。これらの3つの基本的な種類は、組成物動作エンティティ110を生成するために使用されてよい。組成物エンティティ110は、2以上のエンティティの集合であり、該2以上のエンティティの各々は他のエンティティとゼロ以上の関係を有する。組成物(formation)エンティティ110の一例は、プロセッサ及び記憶媒体(ハードウェアエンティティ110)を含むデータベースシステムエンティティ110、該プロセッサ上で実行するデータベースサーバ(ソフトウェアエンティティ110)、及び該データベースサーバにより管理される論理データベース(情報エンティティ110)であってよい。
動作エンティティ110は、該動作エンティティを記述する情報の集合を含み又はそれに関連付けられてよい。情報は、どんな要素及び変数が動作エンティティ110の特定種類の動作エンティティを構成するために使用できるか定義する定義、及び該種類の動作エンティティ110のインスタンスを定義するブループリント(blueprint)を含んでよい。例えば、定義は、データベースサービスエンティティ110がデータベースサーバエンティティ110を含むことを定義してよく、一方で、ブループリントは、特定のデータベースサービスエンティティ110が15個のデータベースサーバエンティティ110を含むことを定義してよい。種々の実施形態で、動作エンティティ110に関連付けられた情報は、制御APIの機能を更に定義する。このような情報は、例えば動作エンティティを異なる状態に遷移させることにより該動作エンティティを管理するために、該動作エンティティ110のためにどんな機能が呼び出され得るかについて知るために、制御モジュール120により使用されてよい。
制御モジュール120は、種々の実施形態で、動作エンティティ110及び/又は制御モジュール120のセットを管理するために実行可能なソフトウェアルーチンのセットである。幾つかの実施形態で、制御モジュール120は、システム100内の各制御モジュール120が同じ機能をサポートするように一般的方法で定義されが、それらはシステム100内で異なる役割で機能してよい。制御モジュール120は、ベアメタル、Amazon Web Service(登録商標)(AWS)、及びKubernetes(登録商標)を含む様々な環境でも動作し得る。例えば、Kubernetes(登録商標)環境では、制御モジュール120は、データベースコンテナの中にある他の制御モジュール120と相互作用するKubernetes(登録商標)オペレータとして機能してよい。AWSでは、AWSクラウドは、仮想マシンエンティティ110を施行する動作エンティティ110として定義され得る。各仮想マシンエンティティ110の内部には、該仮想マシンエンティティのコンテンツ(動作エンティティ110)を管理する制御モジュール120が存在し得る。
動作エンティティ110及び/又は制御モジュール120を管理するために、制御モジュール120は、自身の制御又は権限の下にある各動作エンティティ110の制御APIへのアクセスを有してよい。種々の場合において、制御APIの制御API呼び出しは、全ての動作エンティティ110について同じであってよいが、それら制御API呼び出しの機能の実施は動作エンティティ110の間で異なってよい。制御API呼び出しの発行を通じて、制御モジュール120は、動作エンティティ110に関する情報(例えば、ブループリント)を取得してよく、該動作エンティティを状態間で遷移させてよい。一例として、制御モジュール120は、「遷移」制御API呼び出しをデータベースサーバエンティティ110へ送信して、データベースサーバ要素をオフラインからオンラインに遷移させてよい。
種々の実施形態で、制御モジュール120は、該制御モジュールにより管理される動作エンティティ110及び/又は制御モジュール120に関する情報を維持する。幾つかの場合には、開始されると、制御モジュール120は、該制御モジュール120に初期情報を提供するプロパティファイルにアクセスしてよい。このような情報は、リッスンすべきポート番号、及び制御モジュール120の制御下にある任意の動作エンティティ110を識別してよい。制御モジュール120により維持される情報は、動作エンティティ110から集められた情報、例えばブループリント、定義、及びそれらの動作エンティティによりサポートされるアドバタイズされた制御API呼び出しも含んでよい。
上述のように、動作エンティティ110及び制御モジュール120は、階層構造を形成してよい。該階層構造の最上位にある制御モジュール120は、オーケストレータ制御モジュールと呼ばれる。オーケストレータ制御モジュール120は、上位レベルの目標を実施する任務があってよく、従って、その目標を達成するために階層構造の他のレベルにある他の制御モジュール120を組織化してよい(orchestrate)。一例として、オーケストレータ制御モジュール120は、データベースフリート(database fleet)エンティティ110全体を更新する任務があってよい。結果として、オーケストレータ制御モジュール120は、データベースフリートエンティティ110内の各データベースクラスタエンティティ110の更新を調整してよい。これは、それらデータベースクラスタエンティティ110の中の動作エンティティ110を管理する他の制御モジュール120を利用してよい。これらの制御モジュール120は、しかしながら、これらのデータベースクラスタエンティティ110を更新する際に何が起こるかの詳細を、オーケストレータ制御モジュール120から隠してよい。幾つかの実施形態では、システム100は、複数の階層構造を含んでよく、階層構造の各々は、それらのオーケストレータ制御モジュール120を含んでよい。
データベース130は、種々の実施形態で、情報のアクセス、記憶、及び操作を可能にする方法で組織化された情報の集合である。データベース130は、単一の記憶装置又はネットワーク上で一緒に接続される複数の記憶装置、例えばストレージの取り付けられたネットワークにより実装され、データ損失を防ぐために情報を冗長に格納するよう構成されてよい。データベース130は、制御モジュール120がデータベース130内の情報に対して動作(例えば、アクセス、格納、操作、等)を実行することを可能にするソフトウェアのサポートを含んでよい。種々の実施形態で、データベース130は、定義、ブループリント、動作情報135、及び/又はシステム100内の動作エンティティ110に関する他の情報を格納する。動作エンティティ110を管理するとき、制御モジュール120は、データベース130からの情報にアクセスしてよく、その結果、制御モジュール120は該動作エンティティを正しく管理し得る。
動作情報135は、種々の実施形態で、目標環境137の動作シナリオを定義する情報の集合である。上述のように、動作シナリオは、何らかのアクション(又は上位の目標)を実行するために使用されるステップのシーケンスである。幾つかの実施形態では、動作シナリオは、ワークフロー文書の中で定義される。ここで、所与のワークフロー文書は、対応する動作シナリオのためのステップシーケンスを実施するためのコマンドセットを指定してよい。所与の動作シナリオは、目標環境137に関連付けられて、動作シナリオが該目標環境の状態を変化させ得るようにしてよい。
目標環境137は、種々の実施形態で、動作シナリオの一部として作動され得る動作エンティティ110及び/又は制御モジュール120のグループである。例えば、データベースフリートエンティティ110を新しいバージョンに更新する動作シナリオでは、データベースフリートエンティティ110(その全部の動作エンティティ110及び制御モジュール120を含む)は、該動作シナリオの目標環境137であると考えられる。別の動作シナリオは、異なる動作エンティティ110及び/又は制御モジュール120を有する異なる目標環境137に関連してよい。
認証サービス140は、種々の実施形態で、認証(「誰が状態を変化しようとしているか?」)、認可(「彼らは状態を変化させることを許可されているか?」)、及び監査(認証及び認可の結果を記録する)コマンドが制御モジュール120及び/又は動作エンティティ110に発行されることにより、システム100を(悪意あるものか悪意のないものかに拘わらず)不正な使用から保護するよう動作する。例えば、サービス140は、任意の認可されていない発行されたコマンドの実行を防ぐために、ユーザによりオーケストレータ制御モジュール120に発行されたコマンドを監査してよい。サービス140は、ユーザがオーケストレータ制御モジュール120を回避することにより認可されたアクセスを得ようと企てていないことを保証するために、オーケストレータ制御モジュール120により他の制御モジュール120へ(又は他の制御モジュール120から動作エンティティ110へ)発行されたコマンドも監査してよい。図20~23に関して後述するように、種々の実施形態で、認証サービス140は、目標コンピューティング環境の中で様々な動作シナリオを実施するために許容されるアクションを定義するセキュリティルールセットを保持し、発行されたコマンドがセキュリティルールセットにより定義された許容アクションに従うかを検証する。
テストエンジン150は、種々の実施形態で、システム100が障害し正しく機能しない状態を識別するために、システム100に障害状態を入力するよう動作するテストコンポーネントである。通常、これらの障害は、クラッシュ、ハング、エラー、ロックステップの順序の問題、時間注入、等に関連してよい。例えば、テストエンジン150は、このようなアクションがシステム100を復旧するために使用できない状態にするかを知るために、システム100により使用されているデータベースサーバを無効にしてよい。図24及び25に関連して以下に更に詳述するように、種々の実施形態で、テストエンジン150は、システム100の現在状態を決定するために、1つ以上の制御モジュール120及び/又は動作エンティティ110とインタフェースする。例えば、テストエンジン150は、障害条件を注入する前にシステム100の現在状態に関する情報を集め、次に、システム100の状態がどのように変更されたかを決定するために、注入後の現在状態に関する情報を集めてよい。幾つかの実施形態では、テストエンジン150は、特定のコマンドが制御モジュール120により発行されているときの特定の障害条件を注入するために、システム100の状態を監視してもよい。つまり、要求が認証サービス140を通るので、テストエンジン150は、(例えば、変化前、変化後、及び変化中に)障害注入を調整するためにアーキテクチャ内のこの点を使用してよい。例えば、テストエンジン150は、認証サービス140により処理されている要求から、動作エンティティ110が更新を経験していることを決定してよく、次に、システム100が更新処理中に障害条件を処理できるか否かを決定するために、結果として更新失敗をもたらし得る障害条件を注入することを試みてよい。図示の実施形態では、テストエンジン150は、認証サービス140に統合されているとして示される。このような統合は、種々のコンポーネントがサービス140に種々のアクションの実行許可を依頼するとき、テストエンジン150がシステム100の現在状態のより深い見識を有することを可能にし得る。幾つかの実施形態では、外部テストシステムが、変化を編成し及びシステム100に障害を注入するためにテストエンジン150と相互作用してよい。
図2を参照すると、動作エンティティ110のブロック図が示される。図示の実施形態で、動作エンティティ110は、ブループリント210、1つ以上の要素220、及び制御API実装230を含む。図示のように、動作エンティティ110は、制御モジュール120とインタフェースする。幾つかの実施形態では、動作エンティティ110は、外部制御モジュール120とインタフェースする制御モジュール120を含んでよい。一例として、動作エンティティ110は、オーケストレータ制御モジュール120と通信する制御モジュール120を有するソフトウェアコンテナであってよい。幾つかの実施形態では、動作エンティティ110は、図示と異なるように実装されてよい。例えば、ブループリント210は、動作エンティティ110ではなくデータベース130に格納されてよい(或いは、ブループリント120は、エンティティ110及びデータベース130の両方に格納されてよい)。
上述のように、システム100の動作エンティティ110を管理できるために、種々の実施形態で、エンティティ110は、ブループリント210、及び動作エンティティ自体及びそれらの他のエンティティ110との関係に関する情報を含む定義(これは図3Aに関して更に詳述される)を用いて記述されてよい。このような情報は、制御モジュール120に、異なる動作エンティティ110がどのように管理され得るかを伝達してよい。
ブループリント210は、種々の実施形態で、動作エンティティ110の特定の実装の態様を定義する情報の集合である。ブループリント210は、システム100の管理者が動作エンティティ110の存在することを望む該動作エンティティ110の望ましい又は意図された状態を定義してよい。例えば、ある特定のブループリント210は、データベースフリートエンティティ110が15個のデータベースサーバを含むことを記述してよく、一方で、別の特定のブループリント210は、データベースフリートエンティティ110が10個のデータベースサーバを含むことを記述してよい。図3A~3Dに関して更に詳述されるように、種々の実施形態で、ブループリント210は、動作エンティティ110を管理するために使用可能な属性の選択されたセットの値を定義し得るエンティティデスクリプタと、動作エンティティ110と他のエンティティとの間の関係を記述し得る関係情報と、動作エンティティ110を構成するために使用されうるエンティティ固有変数と、を含む。動作エンティティ110のブループリント210は、システム100のユーザ、該エンティティを開発したユーザ(例えば、ソフトウェアを記述したユーザ)、制御モジュール120、等(それらの任意の組み合わせを含み得る)により提供され及び/又は変更されてよい。例えば、管理制御モジュール120は、対応する動作エンティティ110を新しいバージョンへと更新するとき、エンティティデスクリプタの中のバージョン情報を変更してよい。
種々の実施形態で、ブループリント210は、該ブループリントにより定義される動作エンティティ110のインスタンスを生成するために展開可能であってよい。例えば、オペレータは、データベースサービスエンティティ110のためのブループリント210を提供してよい。このブループリントは、該データベースサービスエンティティが14個のデータベースサーバを有するという意図された状態を定義してよい。該ブループリントを展開することを担う制御モジュール120は、データベースサービスエンティティ110が存在するか否かを決定するために、システム100の状態を観察してよい。データベースサービスエンティティ110が存在しない場合、管理制御モジュール120は、例えば15個のデータベースサーバを生成する能力のある特定の動作エンティティ110と通信することにより、自身のブループリント210に従いデータベースサービスエンティティ110をインスタンス化してよい。
幾つかの例では、ブループリント210は、階層構造を形成してよい。ここで、最上位のブループリント210の実装は、下位レベルのブループリント210の実装を含んでよい。従って、ブループリント210は、他のブループリント210への参照を含んでよい。前述の例に戻ると、データベースサービスエンティティ110のブループリント210は、データベースサーバエンティティ110の特定の実装のためのブループリント210への参照を含んでよい。従って、データベースサービスエンティティ110をインスタンス化するとき、管理制御モジュール120は、自身が15個のデータベースサーバのインスタンス化を生じることができるように、データベースサービスエンティティ110のブループリント210を介してデータベースサーバエンティティ110のブループリント210を探してよい。
要素220は、種々の実施形態で、ハードウェア(例えば、物理プロセッサ及びメモリ)、ソフトウェア(例えば、データベースサーバ)、情報構造(例えば、論理データベース)、又はそれらの任意の組み合わせ(例えば、要素220は動作エンティティ110を含んでよく、該動作エンティティ110が、ハードウェア、ソフトウェア、及び情報構造である、それ自体の要素220セットを含む)を含む。要素220の例は、限定ではないが、物理プロセッサ及びメモリ、ラックに設置されたネットワークスイッチ、オペレーティングシステム、仮想マシン、仮想マシンイメージ、データベースサーバ、論理データベース、データベーススナップショット、コンテナ、コンテナイメージ、ワークフロー、データベースセンタ、テナントスナップショット、及びテナントを含む。種々の場合に、制御モジュール120は、制御API実装230を介して要素220とインタフェースしてよい。
制御API実装230は、種々の実施形態で、(図7に関して更に詳細に議論される)制御APIの1つ以上の機能を実行するために実行可能なソフトウェアルーチンのセットである。制御API実装230は、要素220/ブループリント210、及び制御モジュール120の間のインタフェースとして機能してよい。制御APIが「生成」機能を含み、データベースサーバエンティティ110が存在する例を考える。このデータベースサーバエンティティ110は、例えば該生成機能について論理データベースエンティティ110を生成する動作セットを定義する制御API実装230を含んでよい。従って、データベースサーバエンティティ110を管理する制御モジュール120は、論理データベースエンティティ110を生成するために、制御API実装230のロジックを呼び出す生成機能API呼び出しを発行してよい。このようなロジックは、論理データベースエンティティを生成するようデータベースサーバ(要素220)に指示してよい。種々の実施形態で、制御API実装230は、動作エンティティ110の間で異なってよい。ここで、各動作エンティティ110は、制御APIによりサポートされる機能のうちの1つ以上をユニークに実装してよい。
種々の実施形態で、制御API実装230は、要素220の基礎にある複雑性をカプセル化し隠すラッパとして実装される。例えば、データベースサーバは、データベースサーバを起動し及び停止することを担うサービス又はコマンドラインツールを含んでよい。制御API実装230は、サービスの最上位に存在してよく、制御モジュール120が、データベースサーバをオンラインに遷移させるために、制御APIの遷移機能を呼び出した場合、制御API実装230は、データベースサーバを起動するためにデータベースサーバのサービスとの通信を処理してよい。データベースサーバを起動することの複雑さは、制御モジュール120から隠されてよい。制御モジュール120は、適切な制御API呼び出しを生成するだけでよい。
幾つかの実施形態では、動作エンティティ110は、制御モジュール120に、制御API実装230により実装され従って呼び出し可能である制御APIの機能をアドバタイズしてよい。幾つかの例では、動作エンティティ110は、インスタンス化されると、この情報をアドバタイズしてよい。他の例では、この情報は、制御モジュール120により要求されると、アドバタイズされてよい。例えば、制御モジュール120は、制御API実装230に関する情報を受信するために、動作エンティティ110に「記述(describe)」機能API呼び出しを発行してよい。幾つかの実施形態では、制御モジュール120は、制御API実装230に関する情報を含むようインスタンス化されてよく、このような情報を受信するために動作エンティティ110と通信する必要がなくてよい。
動作エンティティ110の制御API実装230に関する知識を有すると、制御モジュール120は、命令を処理できるようになってよい。一例として、制御モジュール120は、論理データベースエンティティ110を生成するための命令を受信してよい。該制御モジュール120は、論理データベースエンティティ110を生成できるとアドバタイズするデータベースサーバエンティティ110を管理してよい。従って、制御モジュール120は、次に、論理データベースエンティティ110を生成するために、該データベースサーバエンティティ110に、生成機能API呼び出しを発行してよい。しかしながら、制御モジュール120により維持される情報が、被管理動作エンティティ110が適切な機能をサポートしないので命令が処理できないと示す場合、制御モジュール120は命令を拒否してよい。幾つかの例では、制御モジュール120は、発行側の制御モジュール120に、命令は完了されなかった又は完了できないことを通知してよい。
図3Aを参照すると、データベース130内のブループリント210及び定義310のブロック図が示される。図示の実施形態で、ブループリント210及び定義310の両方は、エンティティデスクリプタ320、関係情報330、及び期待される状態変数345を含む変数340を含む。幾つかの実施形態では、ブループリント210及び/又は定義310は、図と異なる方法で実装されてよい。例えば、ブループリント210は、図示のような1つの定義310より多くの定義310に対応してよい。
定義310は、種々の実施形態で、動作エンティティ110の態様を定義する情報の集合である。ブループリント210と同様に、定義310は、図示のようにエンティティデスクリプタ320、関係情報3630、及び変数340を含む。ブループリント210と対照的に、定義310は、動作エンティティ110の特定のインスタンスを定義しなくてよいが、代わりに、対応するブループリント210の中にどんな値が含まれ得るかを記述してよい。つまり、定義310は、ブループリント210がどのように見えるべきかを記述してよい。例えば、データベースフリートエンティティ110の定義310は、データベースフリートがデータベースサーバエンティティ110を含むことを記述してよく、一方で、対応するブループリント210は、特定のデータベースフリートエンティティ110が15個のデータベースサーバエンティティ110を含むことを定義してよい。種々の場合において、定義310は、対応するブループリント210が許可されることを検証するために使用されてよい。上述の例を続けると、ブループリント210が特定のデータベースフリートエンティティ110が、15個のデータベースサーバエンティティ110に加えてアプリケーションサーバエンティティ110を含むことを定義する場合、データベースフリートエンティティ110の定義310が、データベースフリートエンティティ110がアプリケーションサーバエンティティ110を含むことを記述しないので、ブループリント210は、拒否されてよい。幾つかの実施形態では、定義310は、所定の値を有する属性のセット、及びブループリントが展開されるときに値が対応するブループリント210の中に制御モジュール120により記述される属性のセット、を含んでよい。
幾つかの実施形態では、ブループリント210は、複数の定義3210に対応してよい。例えば、特定のプラットフォームサービスエンティティ110のブループリント210は、プラットフォームサービスエンティティ110がデータベースサーバエンティティ110及びアプリケーションサーバエンティティ110を有するとして記述してよい。このように、ブループリント210は、データベースサーバエンティティ110の定義310、及びアプリケーションサーバエンティティ110の定義310に関連付けられてよい。種々の場合に、ブループリント210は、該ブループリントに関連付けられた定義310により指定される全部の関係を満たさない場合に、有効でなくてよい。例えば、アプリケーションサーバエンティティ110の定義310は、アプリケーションサーバエンティティ110がメトリックサーバエンティティ110に依存することを記述してよい。このように、前述の例のブループリント210は、それがメトリックサーバエンティティ110を記述しない限り、有効でなくてよい。従って、ブループリント210は、対応する定義310の中で定義された関係を満たすために、動作エンティティ110のセットがどのように一緒にされるかを記述してよい。
エンティティデスクリプタ320は、種々の実施形態で、対応する動作エンティティ110の種々の属性を記述する情報の集合である。これらの属性は、全ての動作エンティティ110に渡り同じであってよいが、与えられた値は動作エンティティ110の間で異なってよい。例えば、エンティティデスクリプタ320は、動作エンティティ110がハードウェア、ソフトウェア、又は情報であるかを示すある種の属性を含んでよい。従って、プロセッサエンティティ110のエンティティデスクリプタ320はハードウェアを示してよく、一方で、メトリックサーバエンティティ110のエンティティデスクリプタ320はソフトウェアを指定してよい。種々の実施形態で、エンティティデスクリプタ320は、制御モジュール120に、対応する動作エンティティ110がどのように管理され得るかに関する情報を伝達する。前述の例を続けると、制御モジュール120は、プロセッサエンティティ110のエンティティデスクリプタ320が種類属性にハードウェアを指定するので、自身が該プロセッサエンティティ110を複製(クローン化、clone)できないことを知り得る。エンティティデスクリプタ320の種々の属性は、図3Bに関して更に詳述される。
関係情報330は、種々の実施形態で、特定の動作エンティティ110と他の動作エンティティ110との間の関係を指定する情報の集合である。動作エンティティ110の間の関係は、全ての関係に渡り共通であってよいがそれらの値は関係と関係の間で異なってよい種々の属性を用いて定義されてよい。例えば、関係情報330は、関係毎に「タイプ」属性を含んでよい。アプリケーションサーバエンティティ110の関係情報330は、アプリケーションサーバエンティティ110とデータベースサーバエンティティ110との間に「依存」タイプ関係が存在することを指定してよい。エンティティデスクリプタ320と同様に、関係情報330は、制御モジュール120に、対応する動作エンティティ110がどのように管理され得るかに関する情報を伝達してよい。種々の場合に、動作エンティティ110の間の関係は、動作シナリオに対応するコマンドが実行され得る、該動作シナリオの実施され得る順序に影響してよい。前述の例を続けると、アプリケーションサーバエンティティ110はデータベースサーバエンティティ110に依存するので、制御モジュール120は、アプリケーションサーバエンティティ110の前に、該データベースサーバエンティティ110がインスタンス化される必要があることを知ってよい。関係情報330の種々の属性は、図3Cに関して更に詳述される。
変数340は、種々の実施形態で、対応する動作エンティティ110を管理するのに有用な追加情報の集合である。図示のように、変数340は、期待される状態変数345を含む。期待される状態変数345は、種々の実施形態で、対応する動作エンティティ110の期待される状態を指定する。例えば、データベースサーバエンティティ110の期待される状態変数345は、「オンライン」の値を指定してよい。変数340は、現在状態、IP(Internet Protocol)ポートのような1つ以上のサービスエンドポイント、IPアドレス、構成変数、等を指定するために使用されてよい。例えば、変数340は、どんな永久データストアを、特定のデータベースサーバエンティティ110が使用すべきかを、指定してよい。種々の実施形態で、変数340は階層的特性であってよい。変数340は、それらが展開時に又は別の時点で定義されるかのような属性を更に含んでよい。例えば、IPアドレス変数340は、IPアドレス変数340が対応する動作エンティティ110の展開中に満たされることを示す属性に関連付けられてよい。
図3Bを参照すると、エンティティデスクリプタ320のブロック図が示される。図示の実施形態では、エンティティデスクリプタ320は、ユニバーサルにユニークなタイプ(universally unique type (UUT))321、ライフサイクル322、バージョン323、種類324、ユニバーサルにユニークな識別子(universally unique identifier (UUI))325、コンテキスト識別子326、ベンダ327、名称328、及び生成データ329を含む。エンティティデスクリプタ320は、図示のものより多くの又は少ない情報を含んでよい。例えば、エンティティデスクリプタ320は、名称328を含まなくてよい。
ユニバーサルにユニークなタイプ321は、種々の実施形態で、動作エンティティ110のタイプ又は種類を示すデータ値を指定する。UUT321の例は、限定ではないが、「データベースサーバ」、「アプリケーションサーバ」、「論理データベース」、「物理ホストシステム」、「データベースバックアップ」、「テナント」、「ワークフロー」、「ログ拡張」、及び「データ拡張」を含む。UUT321は、幾つかの実施形態では、対応する定義310及び/又はブループリント210を探すためのキーとして使用されてよい。例えば、関係情報330は、それらのUUT321を使用する関係の動作エンティティ110を指定してよい。これは、それらのエンティティ110を管理するのに適切であり得る情報を取得するために、管理制御モジュール120が対応する定義310及びブループリント210にアクセスすることを可能にし得る。図8に関して更に詳述するように、UUT321(種々の場合にライフサイクル322及びバージョン323を有する)は、特定の動作エンティティ110へ命令をルーティングするために更に使用されてよい。また、UUT321は、ユーザがどんな動作エンティティ110がシステム100内に存在するかを理解できるように、ユーザに表示されてよい。
ライフサイクル322は、種々の実施形態で、動作エンティティ110がいるそれ自体のライフサイクル中にあるステージを示すデータ値を指定する。ライフサイクルステージの例は、限定ではないが、仕様、スナップショット、及びインスタンスを含む。例えば、データベースバックアップイメージは、データベースのスナップショットステージであってよい。ライフサイクル322は、動作エンティティ110に関して実行可能な動作のタイプに影響してよい。例えば、データベースサーバエンティティ110がそのインスタンスステージにあるとき、制御モジュール120は、該データベースサーバエンティティ110にデータベースバックアップイメージを生成するよう指示可能であってよい。しかしながら、該データベースサーバエンティティ110がその仕様ステージにある場合、制御モジュール120は、データベースサーバエンティティにデータベースバックアップイメージを生成するよう指示しなくてよい。種々の実施形態では、ライフサイクル322は、対応する定義310及び/又はブループリント210を探すためのキーとして、UUT321と一緒に使用されてよい。幾つかの実施形態では、ライフサイクル322は、異なるライフサイクルステージの間のパスを提供し、例えば状態を通じて動作エンティティを遷移させる制御API呼び出しを通じてソースコードからライブプロダクションソフトウェアへの、動作エンティティ110のパイプラインを自動化するために使用できる。
バージョン323は、種々の実施形態で、動作エンティティ110のバージョンを示すデータ値を指定する。例えば、特定のデータベースサーバエンティティ110のバージョン323は、バージョン「3.2.4」を指定してよい。ライフサイクル322と同様に、バージョン323は、動作エンティティ110に関して実行可能な動作のタイプに影響してよい。例えば、動作エンティティ110のより新しいバージョンは、制御APIの機能のうちの1つ以上について追加実装を含んでよい。種々の実施形態では、バージョン323は、特定の定義310及び/又はブループリント210を探すためのキーとして、UUT321及びライフサイクル322の両方と一緒に使用されてよい。
種類324は、種々の実施形態で、動作エンティティ110の形式又は明示(manifestation)(つまり、ハードウェア、ソフトウェア、情報、又は組成物)を示すデータ値を指定する。エンティティデスクリプタ320の他の属性と同様に、種類324は、動作エンティティ110が制御モジュール120によりどのように管理できるかに影響してよい。一例として、動作エンティティ110がソフトウェアの形式を取る場合、動作エンティティ110は、クローン化可能であってよいが、ハードウェアの形式を取る別の動作エンティティ110はクローン化できなくてよい。種々の実施形態で、種類324は、エンティティデスクリプタ320内の他の属性のためにどんな値が使用できるかに影響する。一例として、ソフトウェアの形式を取る動作エンティティ110は、スナップショットライフサイクルステージを有してよいが、ハードウェアである動作エンティティ110はそうでなくてよい。
ユニバーサルにユニークな識別子(Universally unique identifier (UUID))325は、種々の実施形態で、ブループリント210又は定義310により指定される任意の他の情報と独立に、動作エンティティ110をユニークに識別するデータ値を指定する。一例として、特定の動作エンティティ110は、「C7366F4-4BED-8BF0-BF281」のUUID325を有してよい。UUID325は、特定の動作エンティティ110が制御モジュール120又はユーザにより直接参照されることを可能にし得る。これは、制御モジュール120が複数の同じタイプの動作エンティティ110(例えば、2つのデータベースサーバエンティティ110)を管理する状況での曖昧さを除去し得る。以下に更に詳述するように、所与のコマンドは、そのUUID325を用いて動作エンティティ110を具体的に識別してよい。このように、制御モジュール120は、所与のコマンドにより識別されるUUID325に基づき、該所与のコマンドを適切な管理制御モジュール120へルーティングしてよい。
コンテキスト識別子(Contextual identifier (CID))326は、種々の実施形態で、動作エンティティ110に関連付けられたコンテキストを示すデータ値を指定する。例えば、CID326は、対応する動作エンティティ110に関連付けられた組織/テナントの組織IDを指定してよい。幾つかの実施形態では、CID326は、動作エンティティ110のメトリックをシステム100の特定のテナントに関連付けるために使用されてよい。
ベンダ327は、種々の実施形態で、動作エンティティ110に関連付けられたベンダを識別するデータ値を指定する。名称328は、種々の実施形態で、動作エンティティ110の名称、例えば、製品名、ワークフロー名、テナント名等を識別するデータ値を指定する。生成データ329は、種々の実施形態で、動作エンティティ110が生成された時間を(例えばエポックUTC以来のナノ秒単位で)識別するデータ値を指定する。
図3Cを参照すると、関係情報330のブロック図が示される。図示の実施形態では、関係情報330は、関係331を含む。更に図示のように、関係331は、UUT321、ライフサイクル322、バージョン323、関係タイプ332、方向333、濃度(cardinality)334、及び特性336を含む。関係331は、図示のものより多くの又は少ない情報を含んでよい。例えば、関係331は、バージョン323を含まなくてよい。
多くの場合、システム100内の動作エンティティ110は、何らかの方法で関連付けられてよい。一例として、別の動作エンティティ110からメトリック情報を集める動作エンティティ110は、該他のエンティティの存在に依存する。種々の実施形態で、動作エンティティ110が制御モジュール120により管理される方法は、動作エンティティと他の動作エンティティ110との間に存在する関係331に依存する。図示のように、エンティティの関係331は、関係情報330の中で定義され、複数の変数を含む。
特定の動作エンティティ110が関連付けられる動作エンティティ110を識別するために、種々の実施形態で、関係331は、UUT321、ライフサイクル322、及びバージョン323を指定する。例えば、制御モジュール120は、データベースサーバエンティティ110を制御してよい。代替として、制御モジュール120とデータベースサーバエンティティ110との間の関係に対応する関係331は、「データベースサーバ」のUUT321、「インスタンス」のライフサイクル322、及び「3.21」のバージョン323を指定してよい。幾つかの実施形態では、関係331は、該関係に関連付けられた動作エンティティ110を具体的に識別するUUID325を示してよい。
関係タイプ332は、種々の実施形態で、特定の動作エンティティ110と1つ以上の他の動作エンティティ110との間の関係のタイプを示すデータ値を指定する。関係のタイプは、限定ではないが、「ホスト」関係、「制御」関係、「依存」関係、「構成する」関係、「含まれる」関係、「小部分」関係、及び「提供」関係を含む。ホスト関係は、種々の実施形態で、特定の動作エンティティ110が1つ以上の他の動作エンティティ110をホスティングする関係である。一例として、データベースサーバエンティティ110は、論理データベースエンティティ110をホスティングしてよい。制御関係は、種々の実施形態で、特定の動作エンティティ110が1つ以上の他の動作エンティティ110を制御する関係である。一例として、制御モジュール120は、メトリックサーバエンティティ110及びデータベースサーバエンティティ110を制御してよい。依存関係は、種々の実施形態で、特定の動作エンティティ110が1つ以上の他の動作エンティティ110に依存する関係である。一例として、メトリックサーバエンティティ110は、存在するデータベースサーバエンティティ110に依存してよく、従ってメトリックサーバエンティティ110はメトリックを収集し得る。「構成する」関係は、種々の実施形態で、特定の動作エンティティ110が1つ以上の他の動作エンティティ110で構成される関係である。一例として、データベースサービスエンティティ110は、2つのデータベースサーバエンティティ110で構成されてよい。「含まれる」関係は、種々の実施形態で、特定の動作エンティティ110が1つ以上の他の動作エンティティ110に含まれる関係である。一例として、データベースサーバエンティティ110は、コンテナエンティティ110に含まれてよい。提供関係は、種々の実施形態で、特定の動作エンティティ110によりプロビジョニングされ得る1つ以上の動作エンティティ110を識別する関係である。一例として、コンテナ環境エンティティ110は、コンテナエンティティ110をプロビジョニング(提供)(又はインスタンス化)してよい。幾つかの実施形態では、特定の動作エンティティ110が自身を記述する「私は(I am)」関係が存在してよい。例えば、データベースサーバエンティティ110は、「データベースサーバ」の「I am」関係値を有してよい。
方向333は、種々の実施形態で、特定の動作エンティティ110と1つ以上の他の動作エンティティ110との間の関係の方向を示すデータ値を指定する。方向333は、特定の動作エンティティ110が別の動作エンティティ110に従属するかどうかを示してよい。データベースサーバエンティティ110と論理データベースエンティティ110との間の関係が存在する一例を考える。データベースサーバエンティティ110の観点から定義された関係331は、「ホスト」の関係タイプ332及び「偽(false)」の方向333を指定してよい。論理データベースエンティティ110の観点から定義された関係331は、「ホスト」の関係タイプ332及び「真(true)」の方向333を指定してよい。2つの関係331の結果として生じる解釈は、データベースサーバエンティティ110が論理データベースエンティティ110をホスティングすること、及び論理データベースエンティティ110がデータベースサーバエンティティ110によりホスティングされることであってよい。別の例として、方向333は、制御モジュール120がデータベースサーバエンティティ110を制御することを(該制御部の関係情報330の中で)、及びデータベースサーバエンティティ110が該制御モジュールにより制御されることを(該データベースサーバの関係情報330の中で)、示してよい。
濃度334は、種々の実施形態で、対応する関係タイプ332に関連付けられた動作エンティティ110の数(これは、対応する関係331が定義される特定の動作エンティティ110を除いてよい)を示すデータ値を指定する。例えば、データベースサービスエンティティ110は、3つのデータベースサーバエンティティ110で構成されてよい。結果として、濃度334は、データベースサービスエンティティの観点から、該データベースサービスエンティティ110と3つのデータベースサーバエンティティ110との間の関係331について「3」の値を指定してよい。
特性335は、種々の実施形態で、対応する動作エンティティ110を管理するのに有用な追加データ値を指定する。特性335は、存在する関係の状態を関連する動作エンティティ110に通信するために、該関連する動作エンティティ110により使用されるプロトコルを指定してよい。ここで、これらの動作エンティティは、システム100等の中に位置する。一例として、特性335は、特定関係の動作エンティティ110が起動し実行中であることを示してよい。異なる関係の状態はシステム100内で変化するので、制御モジュール120は、関係情報330を更新してよい(例えば、特性335を更新する)。
エンティティデスクリプタ320と同様の方法で、幾つかの実施形態では、関係331は、動作エンティティ110をどのように管理すべきかを理解するのを助けるために、制御モジュール120に情報を伝達してよい。メトリックサーバエンティティ110がデータベースサーバエンティティ110に依存する例を考える。制御モジュール120は、メトリックサーバエンティティ110を起動したいとき、メトリックサーバエンティティ110がデータベースサーバエンティティ110に依存している結果として、データベースサーバエンティティ110が先ず起動される必要があることを決定してよい。従って、制御部は、動作エンティティ110を状態間でどのように(例えば、オフラインからオンラインへ)遷移させるかに関して推理するために、定義310及びブループリント210からの情報と一緒に、関係情報330を使用してよい。関係情報330は、種々の実施形態で、システムのリソース利用を計算するために使用されてよい。例えば、コンテナエンティティ110は、ホストシステムエンティティ110により含まれてよい。コンテナエンティティ110は、従って、該ホストシステムのリソースの部分を使用する。同様に、コンテナエンティティ110に含まれるソフトウェアは、該コンテナのリソースの一部を使用する。この情報は、プロビジョニング及び自動化されたキャパシティ計画に有用であってよい。
図3Dを参照すると、例示的な動作エンティティ110の間の関係のブロック図が示される。図示の実施形態では、動作エンティティ110Aは、アプリケーションサーバエンティティであり、動作エンティティ110Bは、データベースサーバエンティティであり、動作エンティティ110Cは、メトリックサーバエンティティである。図示のように、動作エンティティ110Bは、動作エンティティ110Aに依存し、動作エンティティ110Aと110Cとの間に共依存関係が存在する。上述のように、動作エンティティ110の間の関係は、制御モジュール120がこれらの動作エンティティをどのように管理するかに影響してよい。例えば、動作エンティティ110~Cをインスタンス化するとき、制御モジュール120は、動作エンティティ110Bが動作エンティティ110Aの存在に依存するので、動作エンティティ110Bの前に、動作エンティティ110Aをインスタンス化してよい。
図4を参照すると、制御モジュール120のブロック図が示される。図示の実施形態では、制御モジュール120は、動作エンティティ情報410、制御API情報420、動作エンティティマネジャエンジン430、ワークフローエンジン440、及び推理エンジン450を含む。幾つかの実施形態では、制御モジュール120は、図と異なる方法で実装されてよい。例えば、制御モジュール120は、推理エンジン450を含まなくてよい。
前述のように、制御モジュール120は、動作エンティティ110及び制御モジュール120を管理してよい。それらを管理するために、種々の実施形態で、制御モジュール120は、動作エンティティ情報410及び制御API情報420を維持する。幾つかの場合には、制御モジュール120は、情報410及び420をローカルストレージに維持してよい。他の場合には、制御モジュール120は、情報410及び420をデータベース130に維持してよく、これは、ローカルストレージが永久的でないために、制御モジュール120が、自身がクラッシュしたとき、自身の取り残された場所で継続することを可能にできる。つまり、制御モジュール120がクラッシュした場合(又はそのコンテナがクラッシュした場合)、そのローカルストレージに格納された情報が、それと一緒に消えてしまうことがある。従って、制御モジュール120の動作エンティティ110の管理に関連する任意の情報は、不揮発性永久ストレージであってよいデータベース130に維持されてよい。更に他の場合には、制御モジュール120は、情報410及び420を、自身のローカルストレージ及びデータベース130の両方に維持してよい。
インスタンス化されると、種々の実施形態で、制御モジュール120は、初期情報を提供するプロパティファイルを提供されてよい。この初期情報は、制御モジュール120のローカルストレージ及び/又はデータベース130の位置を識別してよい。該位置は、動作エンティティ情報410及び該制御モジュールに関連する制御API情報420を含む。幾つかの場合には、プロパティファイルは、制御モジュール120が管理する責任のある動作エンティティ110を示してよく、該エンティティ110及び他の制御モジュール120に関してリッスンすべきポートを示してよい。種々の実施形態で、制御モジュール120は、自身のプロパティファイルを用いて情報410及び420にアクセスする。
動作エンティティ情報410は、種々の実施形態で、制御モジュール120により管理される動作エンティティ110を記述する情報である。情報410は、被管理動作エンティティ110のブループリント210及び定義310を含んでよい。種々の実施形態で、動作エンティティマネジャエンジン430は、自身の動作エンティティ110の意図された状態を決定するために、動作エンティティ情報410を使用する。このような知識により、マネジャエンジン430は、自身の動作エンティティ110を(例えば、制御API呼び出しを発行することにより)、それらの意図された状態へと遷移させてよい。幾つかの場合には、制御モジュール120は、動作エンティティ情報410を含むようインスタンス化されてよい。また幾つかの場合には、制御モジュール120は、動作エンティティ110から情報410(例えば、ブループリント210)を読み出すために、自身の動作エンティティ110へ制御API呼び出しを発行してよい。
制御API情報420は、種々の実施形態で、制御モジュール120により管理される動作エンティティ110により実施される制御APIの機能を示す情報である。上述のように、種々の実施形態で、動作エンティティ110は、制御APIの1つ以上の機能を実装する制御API実装230を含む。制御API実装230を通じて、制御モジュール120は、動作エンティティ110の要素220とインタフェースしてよい。従って、制御API情報420は、制御API実装230により実装される1つ以上の機能を示してよい。幾つかの場合に、制御モジュール120は、該制御モジュール120が制御API情報420を含むようインスタンス化されてよい。幾つかの場合には、制御モジュール120は、自身の管理する動作エンティティ110から制御API情報420を受信するために、該動作エンティティ110へ(制御APIの)「記述」機能呼び出しを発行してよい。種々の実施形態で、各動作エンティティ110は、「記述」機能呼び出しを実装し得ることに留意する。
種々の実施形態で、制御API情報420は、動作エンティティ110に関する特定の情報を該動作エンティティ110の実装する機能にマッピングする機能マップを含む。種々の実施形態で、機能にマッピングされた情報は、動作エンティティのUUT321及びライフサイクル322を含んでよい。幾つかの場合には、動作エンティティ110は、異なるライフサイクルステージについて同じAPI機能呼び出しの異なる実装を含んでよいことに留意する。図8に関して更に詳述されるように、制御モジュール120は、動作エンティティのUUT321、ライフサイクル322、及び/又はUUID325を使用して、コマンドをルーティングしてよい。
動作エンティティマネジャエンジン430は、種々の実施形態では、動作エンティティ110を管理するために実行可能なソフトウェアルーチンのセットである。制御モジュール120は、種々の場合に、動作エンティティ110と考えられてよく、それは定義310及びブループリント210に関連付けられてよいことに留意する。このように、マネジャエンジン430は、制御モジュール120も管理してよい。動作エンティティ110及び制御モジュール120を管理するために、種々の実施形態で、マネジャエンジン430は、種々のモジュール、例えばスケジューラモジュール、スイーパモジュール、健全性評価モジュール、及び調査モジュールを含む。
スケジューラモジュールは、種々の実施形態で、制御モジュール120により管理されている動作エンティティ110を変化させるときを決定する機能のセットである。種々の実施形態で、スケジューラモジュールは、マネジャエンジン430の他のコンポーネントにより実行されるためにそれらをスケジューリングすることにより、アクションを実行させる。スケジューラモジュールは、宣言型(declarative)(例えば、「この動作エンティティ110はこの意図された状態であるべきだ」)又は命令型(imperative)(「DBのスナップショットを生成しなさい」)であってよい。アクションをスケジューリングするために、スケジューラモジュールは、スケジューリングされた時間と共に要求されたアクション(例えば、ユーザからのコマンド)をローカルストレージ及び/又はデータベース130に書き込んでよい。スケジューラモジュールは、スケジューリングされたアクションの進捗及び結果も、ローカルストレージ及び/又はデータベース130に書き込んでよい。このような情報は、データベース130に書き込まれてよい。その結果、制御モジュール120がクラッシュした場合、制御モジュール120の新しいインスタンスが、他方のインスタンスがクラッシュした場所をピックアップし得る。種々の場合に、スケジューラモジュールは、スイーパモジュールが動作エンティティ110を調査する(probe)時間をスケジューリングしてよい。
スイーパモジュールは、種々の実施形態で、動作エンティティ110の健康状態(健全性、health)に関する情報(例えば、容量に対するリソース利用率、主要健全性指示子、等)を集めるために管理されている該動作エンティティ110を調査する機能のセットである。幾つかの実施形態では、スイーパモジュールは、(永久的であってよい)ローカルストレージ及又はデータベース130から動作エンティティ情報410を読み出す。動作エンティティ情報410から、スイーパモジュールは、動作エンティティ110の制御モジュール120により管理されている該動作エンティティ110について、及びそれらにどのように接続するかについて、知ることができる。スイーパモジュールは、次に、それらの動作エンティティを調査してよい。幾つかの実施形態では、スイーパモジュールは、状態要求メッセージを、リストされた動作エンティティ110の各々へ送信する。該メッセージは、該動作エンティティ110の現在状態を詳述する情報を要求する。スイーパモジュールが最初に状態要求メッセージを送信する代わりに、幾つかの実施形態では、動作エンティティ110が、自身の現在状態を示す情報を、スイーパモジュールへ定期的に送信してよい。種々の実施形態で、スイーパモジュールは、動作エンティティ110から受信した情報を、動作エンティティ情報410の一部として格納する。このような情報は、リソース利用率、リソース容量、当該動作エンティティ110の状態(例えば、オフライン、オンライン、等)、当該動作エンティティの状態の他の動作エンティティ110との関係(例えば、他の動作エンティティ110が応答者ではない)、等を示してよい。スイーパモジュールは、調査されるべき「出来事(incident)」としてトリガされ得る任意の警告を格納してよい。一例として、スイーパモジュールは、動作エンティティ110から連絡がない場合、該動作エンティティ110が健全ではない可能性があるという指示を格納してよい。もはや動作上関連しない情報(例えば、古い、無意味なレコード)は、ローカルストレージ及び/又はデータベース130から除去されてよい。
健全性評価モジュールは、種々の実施形態で、スイーパモジュールにより取得された情報を用いて、被管理動作エンティティ110の健全性を評価する機能のセットである。種々の実施形態では、健全性評価モジュールは、ローカルストレージ又はデータベース130から動作エンティティ情報410を読み出す。健全性評価モジュールは、次に、動作エンティティ情報410に基づき、動作エンティティ110を調査するよう調査モジュールをトリガするためにレポートを生成すべきか否かを決定してよい。例えば、健全性評価モジュールは、動作エンティティ110のリソース利用率を評価してよく、リソース利用率が然るべきものと比べて高すぎる又は低すぎる場合、健全性評価モジュールは、該動作エンティティ110についてレポートを生成してよい。種々の実施形態で、健全性評価モジュールは、過去の動作エンティティ情報410に基づき、更なるイベントを予測することを試みてよい。例えば、動作エンティティ110が、該動作エンティティ110が障害になって終わる特定の傾向に従う兆候を示した場合、健全性評価モジュールは、先取り的に該動作エンティティを調査させるためにレポートを生成してよい。
調査モジュールは、種々の実施形態で、動作エンティティ110を検査する機能のセットである。調査モジュールは、未だ調査されていないレポートをチェックしてよい。各レポートについて、調査モジュールは、関連する動作エンティティ110に関する情報を収集してよい。このような情報は、システム100の他のコンポーネント又はユーザにより任意の問題をトラブルシュートするために利用されてよい。例えば、調査モジュールは、動作エンティティ110が障害になる前に、動作エンティティ110により実行される動作を詳述するログ情報を収集してよい。種々の場合に、調査モジュールは、全ての健全でないエンティティの関係情報330へのアクセスを有してよい。例えば、調査モジュールは、健全でない別のサービスエンティティ110に依存する健全でないデータベースサーバエンティティ110の関係情報330へのアクセスを有してよい。データベースサーバエンティティ110が健全でないという事実は、単に兆候である場合があり、調査すべき場所は、実際には、それが依存するサービスによってよい。従って、調査モジュールは、データベースサーバエンティティ110に問題を生じるかどうかを決定するために、当該サービスの健全性をドリルダウン(drill down )する制御APIを使用してよい。幾つかの実施形態では、調査モジュールは、自身の発見した任意の問題をトラブルシュートすることを試みてよい。例えば、調査モジュールは、クラッシュした動作エンティティ110を再起動/再初期化するためのコマンドのセットを発行してよい。調査モジュールは、自動化された調査が完了した後に、レポートの状態及び所有権を更新してよい(例えば、自動調査が問題をトラブルシュートすることに失敗した場合、所有権はユーザに移転されてよい)。
従って、種々の実施形態で、スイーパモジュールは、制御モジュール120により管理される動作エンティティ110に関する健全性情報を集める。健全性情報は、それらの動作エンティティ110に問題があるかどうかを決定するために、健全性評価モジュールにより評価されてよい。潜在的な問題がある場合、問題は、更なる分析のために調査モジュールに報告されてよい。
幾つかの実施形態では、動作エンティティマネジャエンジン430は、動作エンティティ110(幾つかの場合には、マネジャエンジン430の配下にあるもの)の管理に関する命令を受信してよい。マネジャエンジン430の配下にない動作エンティティ110に関する命令については、マネジャエンジン430は、該命令を処理のために適切な制御モジュール120へとルーティングしてよい。幾つかの場合には、マネジャエンジン430は、命令を、該命令に含まれる情報、例えば対応する動作エンティティ110のUUID325の値に基づきルーティングしてよい。例えば、マネジャエンジン430は、UUID325の値に基づき、該UUID325の値に対応する動作エンティティ110を管理する特定の制御モジュール120を決定してよい。従って、マネジャエンジン430は、対応する命令を、処理のために、該制御モジュール120へとルーティングしてよい。
マネジャエンジン430の管理下にある動作エンティティ110に関する命令については、マネジャエンジン430は命令を処理してよい。該命令は、1つ以上の動作エンティティ110の変化する状態を含んでよい。種々の場合に、マネジャエンジン430は、制御APIのどの機能が呼び出すために利用可能であるかを決定するために、制御API情報420にアクセスしてよい。目例は、対応する動作エンティティ110、及び該動作エンティティに関して実行されるべき機能を識別してよい。従って、(制御API情報420から決定され得るように)適切な制御API機能が動作エンティティ110により実装されている場合、マネジャエンジン430は、該制御API機能を実行するために、制御API呼び出しを動作エンティティ110へ送信してよい。幾つかの例では、マネジャエンジン430は、下の動作エンティティ110に変更を行うために、別の動作エンティティ110の制御API機能実装を呼び出してよい。制御API呼び出しを発行する際に、マネジャエンジン430は、受信した命令を実行してよい。
ワークフローエンジン440は、種々の実施形態では、ワークフローを実施するために実行可能なソフトウェアルーチンのセットである。上述のように、動作シナリオは、該動作シナリオのステップシーケンスを実施するコマンドセットを含むワークフローの中で記述されてよい。コマンドは、特定の動作エンティティ110上で実行されるべき動作(例えば、状態変化)を識別してよい。種々の実施形態で、ワークフローエンジン440は、動作エンティティ110及び/又は制御モジュール120へ、ワークフローのコマンドを実行するための命令を発行することにより、ワークフローを実施する。一例として、ワークフローエンジン440は、(制御モジュール120により管理されている)動作エンティティ110の状態を「オフライン」から「オンライン」へと変化させる命令を、制御モジュール120へ発行してよい。種々の場合に、ワークフローエンジン440は、データベース130からワークフローを取得してよい。幾つかの場合には、ワークフローエンジン440は、推理エンジン450からワークフローを取得してよい。
推理エンジン450は、種々の実施形態では、上位レベルの目標に基づきワークフローを生成するために実行可能なソフトウェアルーチンのセットである。推理エンジン450は、最初に、ユーザから、特定の上位レベルの目標を実施するための要求を受信してよい。例えば、ユーザは、データベースサーバエンティティ110があるバージョンから別のバージョンへとアップグレードされることを要求してよい。推理エンジン450は、種々の実施形態で、目標を実施するコマンドセットを有するワークフローを生成するために、要求された上位レベルの目標について「推理」する。幾つかの例では、推理エンジン450の出力(例えば、ワークフロー)は、出力を介して上位レベルの目標を実施するために、ワークフローエンジン440に提供されてよい。推理エンジン450は、システム100の開発者により記述されなければならない特定の動作コードの量を大幅に削減し得る。推理エンジン450は、図17に関して更に詳述される。
図5を参照すると、方法500のフロー図が示される。方法500は、目標コンピュータ環境(例えば、目標環境137)の(例えば、動作情報135の中の)動作シナリオを管理するために、コンピュータシステム(例えば、システム100)により実行される方法の一実施形態である。方法500は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの場合には、方法500は、コンピュータシステムがユーザから要求を受信することに応答して実行されてよい。幾つかの実施形態では、方法500は、追加ステップを含んでよい。一例として、コンピュータシステムは、ブループリント(例えば、ブループリント210)を有効にするために、定義(例えば、定義310)にアクセスしてよい。
方法500は、ステップ510で開始し、コンピュータシステムが、動作シナリオのコマンドセットを定義する動作情報(例えば、動作情報135)にアクセスする。動作シナリオは、動作エンティティセットに含まれる1つ以上のソフトウェアエンティティの状態を変化させて、1つ以上のソフトウェアエンティティを第1ソフトウェアバージョンから第2ソフトウェアバージョンに遷移させることを含んでよい。
ステップ520で、コンピュータシステムは、動作シナリオを実施するために目標コンピュータ環境で利用されるべき、動作エンティティ(例えば、動作エンティティ110)のセットのブループリント(例えば、ブループリント210)にアクセスする。所与のブループリントは、動作エンティティセットのうちの第1動作エンティティについて、第1動作エンティティと該動作エンティティセットのうちの1つ以上の他の動作エンティティとの間の関係(例えば、関係331)のセットを示してよい。動作エンティティセットは、ハードウェアエンティティ(例えば、プロセッサのセット)、ソフトウェアエンティティ(例えば、プロセッサのセットのうちの少なくとも1つのプロセッサ上で実行するデータベースサーバ)、及び情報エンティティ(例えば、データベースサーバにより管理される論理データベース)を含んでよい。
ステップ530で、コンピュータシステムは、目標コンピュータ環境のための動作シナリオを実施する。種々の場合に、動作シナリオを実施するステップは、制御モジュール(例えば、制御モジュール120)の階層構造を実行するステップを含んでよく、階層構造は、該階層構造の最上位にある、該階層構造の次のレベルにある制御モジュールへ命令を発行することによりコマンドセットを実行するために実行可能なオーケストレータ制御モジュールを含んでよい。種々の場合に、制御モジュールの階層構造は、動作エンティティセットのうちの1つ以上の動作エンティティの状態を変化させることにより、動作シナリオを達成するためにそれぞれのブループリントに従い動作エンティティセットを管理するよう動作可能な制御モジュールを含んでよい。幾つかの場合には、動作エンティティセットのうちの第1動作エンティティは、階層構造の中で、動作エンティティセットのうちの第2動作エンティティと異なるレベルにあってよい。従って、動作エンティティセットを管理するために実行可能な制御モジュールのうちの制御モジュールは、階層構造の異なるレベルにあってよい。
幾つかの実施形態では、所与の動作エンティティは、制御アプリケーションプログラミングインタフェース(application programming interface (API))によりサポートされる機能のセット(例えば、制御API実装230)のうちの1つ以上を実装する。1つ以上の実施された機能は、制御モジュールが所与の動作エンティティの状態を変化させることを可能にし得る。種々の場合に、ブループリントのうちの特定の1つは、所与の動作エンティティに関連付けられてよく、該所与の動作エンティティに関連付けられた現在ライフサイクルステージ(例えば、仕様ステージ)を示すライフサイクル値(例えば、ライフサイクル322の値)を指定してよい。ライフサイクル値は、1つ以上の実施された機能のうちのどれがライフサイクルステージのために呼び出し可能であるかを決定するために、制御モジュールにより使用可能であってよい。
幾つかの実施形態では、所与の動作エンティティは、該所与の動作エンティティをユニークに識別し得るユニーク識別子(例えば、UUID325の値)に関連付けられる。命令のうちの特定の1つは、所与の動作エンティティに関連付けられてよい。幾つかの場合には、特定の命令を発行するステップは、ユニーク識別子に基づき、制御モジュールのうちの、該所与の動作エンティティを管理する特定の1つを決定するステップと、該特定の命令を該特定の制御モジュールに発行するステップと、を含んでよい。特定の命令は、ソフトウェアエンティティ(例えば、データベースサーバ)に、別の情報エンティティ(例えば、論理データベース)をインスタンス化させることを含んでよい。
幾つかの実施形態では、第1動作エンティティについて指定された関係セットが、コマンドセットのうちのコマンドが実行され得る順序に影響する。幾つかの場合には、関係セットは、第1動作エンティティと動作エンティティセットのうちの第2動作エンティティとの間の関係を含んでよい。このように、第1動作エンティティの状態を変化させるために命令のうちの特定の1つを実行するステップは、第1動作エンティティの状態を変化させる前に、第2動作エンティティの状態を変化させるステップを含んでよい。幾つかの場合には、第1動作エンティティと第2動作エンティティとの間の関係は、第1動作エンティティが第2動作エンティティの存在に依存するという依存関係であってよい。
図6を参照すると、方法600のフロー図が示される。方法600は、動作エンティティ(例えば、動作エンティティ110)のセットを管理するために、コンピュータシステム(例えば、システム100)により実行される方法の一実施形態である。方法600は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの実施形態では、方法600は、追加ステップを含んでよい。一例として、コンピュータシステムは、動作情報(例えば、動作情報135)を格納するデータベース(例えば、データベース130)を維持してよい。
方法600は、ステップ610で開始し、コンピュータシステムが、制御モジュール(例えば、制御モジュール120)の階層構造を実行する。階層構造は、該階層構造の一番上にあり、動作エンティティセットを管理するために階層構造の中の他の動作エンティティと通信するよう動作するオーケストレータ制御モジュールを有する。種々の場合に、動作エンティティセットは、ハードウェアエンティティ、ソフトウェアエンティティ、及び情報エンティティを含んでよい。
ステップ620で、オーケストレータ制御モジュールは、動作エンティティセットに関連する動作シナリオのステップシーケンスを実施するためのコマンドを有するワークフローを指定する動作情報(例えば、動作情報135)にアクセスする。
ステップ630で、オーケストレータ制御モジュールは、動作シナリオを実施するために、ワークフローのコマンドを実施する。幾つかの場合には、コマンドを実施するステップは、動作エンティティセットのうちの1つ以上の動作エンティティの状態を変化させるために、他の制御モジュールのうちの1つ以上に、命令を発行するステップを含んでよい。階層構造の中の特定の制御モジュールは、動作エンティティセットの属性(例えば、UUT321、ライフサイクル322、バージョン323、等)を定義するそれぞれのブループリント(例えば、ブループリント210)に従い、動作エンティティセットを管理するよう動作してよい。幾つかの実施形態では、属性は、動作エンティティセットのうちの動作エンティティの間の関係(例えば、関係331)に関する情報を定義する関係属性(例えば、関係タイプ332、方向333、等)を含む。これらの関係は、1つ以上の動作エンティティの状態が命令に基づき変化されるべき順序に影響してよい。
幾つかの場合には、1つ以上の他の制御モジュールは、オーケストレータ制御モジュールから受信された命令のうちの1つ以上の命令を、動作エンティティセットを管理する特定の制御モジュールへルーティングするよう動作してよい。幾つかの場合には、1つ以上の他の制御モジュールは、動作エンティティセットに対応するユニーク識別子(例えば、UUID325)のセットに基づき、1つ以上の命令をルーティングするよう動作してよい。
図7を参照すると、制御API700のブロック図が示される。図示の実施形態では、制御API700は、記述機能710、フェッチ機能720、遷移機能730、生成機能740、破棄機能750、混乱(perturb)機能760、検証機能770、及び分析機能780を含む。種々の実施形態では、制御API700は、図示のものより多くの機能を含んでよい。例えば、制御API700は、制御モジュール120が動作エンティティ110により維持されているログ情報を読み出すことを可能にするログ機能を含んでよい。
制御API700は、種々の実施形態で、動作エンティティ110からの情報にアクセスするために、動作エンティティ110の特長を変化させるために(例えば、当該エンティティを別のエンティティへと遷移させる)、及び/又は動作エンティティ110により管理されてる別の動作エンティティ110を変化させるために、呼び出し可能な機能又はAPIの集合である。制御API700は、システム100内の全部の動作エンティティ110に渡り共通である選択された機能セットを含んでよいが、その機能は動作エンティティ110毎に個別に定義される。例えば、制御API実装230A及び230Bは、それぞれ、動作エンティティ110を生成するための生成機能740を定義するが、制御API実装230Aにより生成された特定のタイプの動作エンティティ110は、制御API実装230Bにより生成された特定のタイプと異なってよい。種々の実施形態で、動作エンティティ110は、同じタイプの機能の複数の異なる実装をサポートしてよい。一例として、データベースサーバエンティティ110は、生成機能740の2つの実装をサポートしてよい。1つは、論理データベースエンティティ110を生成するためであり、もう1つはバックアップイメージエンティティ110を生成するためである。幾つかの場合には、動作エンティティ110は、制御API700により提供される全部の機能をサポートしなくてよい。例えば、混乱機能760は、論理データベースエンティティ110については実施されなくてよい。
記述機能710は、種々の実施形態で、動作エンティティ110に関する情報を返す。情報は、動作エンティティ110のブループリント210、定義310、及び/又は自信の制御API実装230に関する情報を含んでよい。制御モジュール120が、どの動作エンティティ110に特定の動作エンティティ110が依存するかを発見したいと望む例を考える。該制御モジュール120は、該特定の動作エンティティ110の記述機能710を呼び出して、そのブループリント210を受信してよい。該ブループリント210は、特定の動作エンティティ110の関係331を識別してよい。幾つかの場合には、記述機能710は、他の機能(例えば、機能720、730、等)のうちのどれが、動作エンティティの制御API実装230の中に実装されているかを決定するために呼び出されてよい。従って、幾つかの実施形態では、各動作エンティティ110は記述機能710を定義し、従って、制御モジュール120は、それらの動作エンティティ110について知る保証された方法を有し得る。
フェッチ機能720は、種々の実施形態で、動作エンティティ110の1つ以上の変数340をフェッチする。一例として、制御モジュール120は、動作エンティティ110のフェッチ機能720を呼び出して、該動作エンティティが「オンライン」か「オフライン」かを示す特定の変数340にアクセスしてよい。フェッチ機能720を呼び出すとき、制御モジュール120は、要求された変数340をフェッチ機能720への入力として指定してよい。幾つかの場合には、制御モジュール120は、記述機能710を呼び出して、どの変数340が特定の動作エンティティ110からその制御API実装230を介して要求されたかを決定してよい。幾つかの実施形態では、フェッチ機能720から返された情報は、返された変数340の特定の特性を示してよい。このような特性は、変数340の名称、その値、該変数の可能な最小値及び最大値、データ型(例えば、ブール、整数、文字列、浮動小数、等)、情報タイプ(例えば、カウンタ、率、等)、単位タイプ(例えば、秒、キロバイト、等)、及びフラグ(例えば、変化する、標準的、等)を含んでよい。例えば、フェッチ機能720は、「状態」という名称、「オンライン」という値、及び「変化する」フラグを有する変数340を指定する情報を返してよい。
遷移機能730は、種々の実施形態で、動作エンティティ110の1つ以上の変数340(又はエンティティデスクリプタ320及び/又は関係情報330に含まれる値のような他の情報)を、第1値から第2値へと遷移させ又は変化させる。一例として、データベースサーバエンティティ110の遷移機能730は、状態変数340を「オフライン」から「オンライン」へと変化させるために呼び出されてよい。データベースサーバエンティティ110の制御API実装230は、データベースサーバエンティティ110にオフラインからオンラインへと遷移させるソフトウェアルーチンを呼び出してよい。制御API実装230は、次に、状態変数340を「オフライン」から「オンライン」へと更新してよい。該制御API実装230は、データベースサーバをオンライン状態へと遷移させる基礎にある複雑性を、遷移機能730を呼び出す制御モジュール120から隠してよい。つまり、制御モジュール120の観点から、遷移機能730の呼び出しは、変数340を変化させてよく、一方で制御API実装230は、実際には該変数の変化により示される変化を実施してよい。このように、種々の実施形態で、遷移機能730は、制御モジュール120が、第1状態から第2状態へ動作エンティティ110を遷移させることを可能にする。
遷移機能730を使用する他の例は、動作エンティティ110を新しいバージョンに更新すること、動作エンティティ110が他の動作エンティティ110を生成することを無効化すること、動作エンティティ110の構成仕様を変更すること、動作エンティティ110をシャットダウンすることを、等を含んでよい。種々の実施形態で、動作シナリオを実施するステップは、複数の動作エンティティ110に、それらの状態を変化させるために、複数の遷移機能730呼び出しを発行するステップを含んでよい。
生成機能740は、種々の実施形態で、動作エンティティ110に別の動作エンティティ110を生成させる。例えば、データベースサーバエンティティ110は、論理データベースエンティティ110を生成するために生成機能740を実施してよい。結果として、制御モジュール120は、望ましい場合には、論理データベースエンティティ110を生成するために生成機能740を呼び出してよい。種々の実施形態で、動作エンティティ110は、他の動作エンティティに対して又は他の動作エンティティの代わりに、アクションを実行し得るという点で、動作エンティティ110は、他の動作エンティティ110を制御してよい。種々の場合に、別の動作エンティティ110を制御する動作エンティティ110は、該他の動作エンティティを生成し、破棄し、リストし、及び/又は記述する能力を有してよい。幾つかの場合には、動作エンティティ110は、別の動作エンティティと同じである動作エンティティをクローン化することにより、該別の動作エンティティ110を生成してよい。幾つかの場合には、動作エンティティ110は、別の動作エンティティをそのライフサイクルステージに沿って遷移させることにより、該別の動作エンティティ110を生成してよい。例えば、データベース永続性をインスタンスステージからスナップショットステージへと遷移させることにより、データベース永続性のスナップショットを生成する。種々の実施形態で、生成機能740は、新しい動作エンティティ110を生成するための基礎(例えば、ディスクイメージファイル)を識別するソース情報を入力として受信する。
破棄機能750は、種々の実施形態で、システム100から動作エンティティ110を破棄/削除する。幾つかの場合には、制御モジュール120は、特定の動作エンティティ110の破棄機能750を呼び出して、動作エンティティがもはやシステム100内で必要ないことに応答して、該動作エンティティを破棄する。例えば、高いトラフィック需要の存在したときに生成されたデータベースサーバエンティティ110は、少ないトラフィックしか存在しないときには破棄されてよい。幾つかの場合には、動作エンティティ110の破棄機能750は、該動作エンティティが機能不全である場合に、呼び出されてよい。制御モジュール120は、次に、同じタイプの動作エンティティ110のもう1つをインスタンス化してよい。
混乱機能760は、種々の実施形態で、動作エンティティを異常に動作させることにより、動作エンティティ110を混乱させる。例えば、特定の動作エンティティ110の混乱機能760は、該動作エンティティに障害を注入してよい。このような障害は、例えば、特定の動作エンティティ110にクラッシュ、ハング、又はシャットダウンさせることを含んでよい。図24に関して更に詳述されるように、混乱機能760は、システム100が問題から復旧できるかを調べるために、システム100内に問題を生じさせることにより、システム100をテストする際に役立ち得る。
検証機能770は、種々の実施形態で、動作エンティティ110を正しさについて検証する。例えば、制御モジュール120は、動作エンティティ110の検証機能770を呼び出して、該動作エンティティの構成及び/又は環境が正しいかを決定してよい(例えば、構成が適切な値を使用しているかどうかを決定する)。分析機能780は、種々の実施形態で、動作エンティティ110に関するメトリック情報を集める。一例として、制御モジュール120は、動作エンティティ110の分析方法を呼び出して、該動作エンティティ110からエラーログを取得してよい。
図8を参照すると、ルーティングエンジン810及びルーティング可能エンティティ830のブロック図が示される。図示の実施形態で、制御モジュール120は、ルーティングエンジン810を有する動作エンティティマネジャエンジン430を含む。更に図示のように、ルーティング可能エンティティ830Aは、制御モジュール120に関してローカルに位置し(例えば、同じネットワーク上に位置し)、一方で、ルーティング可能エンティティ830Bは、制御モジュール120に関してリモートに位置する。
上述のように、動作エンティティ110及び制御モジュール120は、最上位にオーケストレータ制御モジュール120を有する階層構造を形成してよい。動作シナリオを実施するとき、オーケストレータ制御モジュール120は、階層構造を通じて、動作エンティティ110を管理する制御モジュール120へ命令を発行してよい。このような制御モジュール120は、それらの被管理動作エンティティ110により実施される制御API700の適切な機能を呼び出すために、制御API呼び出しを発行することにより、受信した命令を実行してよい。制御API700の機能を呼び出すことにより、制御モジュール120は、動作エンティティ110の状態を変化させてよい。
命令は、種々のソースから受信され及び/又はアクセスされてよい。幾つかの場合には、命令は、最初に、(ユーザにより又はアドホックスクリプトにより入力された)人間により読み取り可能なコマンドを制御モジュール120により理解される命令に変換するコマンドラインツールから受信されてよい。コマンドラインに入力されたコマンドから導出された命令は、最初に、オーケストレータ制御モジュール120により受信されてよい。オーケストレータ制御モジュール120は、命令を、動作エンティティ110及び制御モジュール120の階層構造を通じて伝搬させてよい。種々の場合に、命令は、データベース130に格納されたワークフロー情報から導出されてよい。従って、(例えば、コマンドラインツールを介して)命令された後に、オーケストレータ制御モジュール120は、データベース130からのワークフロー情報にアクセスし、階層構造を通じてワークフロー情報に関連付けられた命令を伝搬させてよい。幾つかの場合には、ワークフロー情報は、人間により読み取り可能なコマンドを含んでよい。該コマンドは、制御モジュール120により、これらのコマンドを実施するための命令に変換されてよい。
制御モジュール120が命令を受信すると、制御モジュール120は、ルーティング決定を行ってよい。命令が制御モジュール120により管理される動作エンティティ110に対応する場合、制御モジュール120は、該動作エンティティ110へ、適切な制御API700呼び出しを発行してよい。しかし、命令が別の制御モジュール120により管理される動作エンティティ110に対応する場合、第1制御モジュール120は、該別の制御モジュールへ、命令をルーティングしてよい。命令をルーティングし制御API700の機能を呼び出すために、種々の実施形態で、制御モジュール120はルーティングエンジン810を含む。
ルーティングエンジン810は、種々の実施形態で、命令をルーティングするために及び制御API700の機能を呼び出すために実行可能なソフトウェアルーチンのセットである。命令は、該命令に含まれる情報に基づきルーティングされてよい。このような情報は、動作エンティティ110のUUT321、動作エンティティ110のライフサイクル322、動作エンティティ110のUUID325、動作エンティティ110を管理する制御モジュール120のUUID325、動作エンティティ110及び制御モジュール120を含むコンテナエンティティ110のUUID325、変数340の名称、ソース、及び/又は、動作エンティティ110の名称328のようなブループリント210及び/又は定義310に含まれ得る他の情報を含んでよい。一例として、命令は、フェッチ機能720に対応してよく、フェッチすべき変数340の名称(例えば、「状態」)、該変数をフェッチすべき動作エンティティ110のUUID325、該動作エンティティを管理する、従って該動作エンティティのフェッチ機能720を呼び出すべき制御モジュール120のUUID325、を指定してよい。
命令を受信した後に、種々の実施形態で、ルーティングエンジン810は、命令が別の制御モジュール120へルーティングされるべきか、又は制御API700の特定の機能が呼び出されるべきかを決定する。該命令がルーティングされるべきであるかどうかを決定するために、幾つかの実施形態では、ルーティングエンジン810は、命令が制御モジュール120のUUID325を指定するか否かを決定する。命令が制御モジュール120のUUID325を指定するが、指定されたUUID325が別の制御モジュール120に属する場合、ルーティングエンジン810は、命令をルーティングしてよい。幾つかの場合には、ルーティングエンジン810は、自身の制御モジュール120が動作エンティティの制御API実装230へのアクセスを有しない場合、該動作エンティティ110が自身の制御モジュール120のローカルにないと決定してよい。ルーティングエンジン810は、制御モジュール120により維持されるローカル制御API実装230のマップに基づき、この決定を行ってよい。幾つかの場合には、命令の中で識別されるUUID325及び制御API呼び出しは、マップへのキーとして使用されてよい。マップがこのようなキーについてエントリを有しない場合、ルーティングエンジン810は、命令をルーティングしてよい。
幾つかの場合には、ルーティングエンジン810は、該命令を自身の制御モジュール120の管理する各制御モジュール120へブロードキャストすることにより、該命令をルーティングしてよい。幾つかの場合には、指定されたUUID325がルーティングエンジンの制御モジュール120により管理される制御モジュール120に属する場合、ルーティングエンジン810は、該命令を該制御モジュールに直接提供してよい。ルーティングエンジン810は、ブループリント210を使用して、命令の対象である動作エンティティ110を誰が管理するかを決定してよい。命令は、制御モジュール120のUUID325を指定しなくてよい。しかしながら、命令は、動作エンティティ110のUUID325を依然として指定してよい。このように、ルーティングエンジン810は、動作エンティティ情報410に基づき、自身の制御モジュール120が該動作エンティティを管理するか否かを決定してよい。自身の制御モジュール120が該動作エンティティを管理しない場合、ルーティングエンジン810は、命令を、自身の制御モジュール120の管理する各制御モジュール120へブロードキャストしてよい。幾つかの実施形態では、ルーティングエンジン810は、自身の制御モジュール120が動作エンティティ110を管理するか否かを、動作エンティティのUUID325を用いて(又はUUT321のような他の情報を用いて)動作エンティティ情報410内で動作エンティティの情報を探すことを試みることにより、決定する。幾つかの実施形態では、各制御モジュール120の能力を、それらがどの動作エンティティ110を管理するかと一緒にアドバタイズするルーティングテーブルが使用されてよい。従って、ルーティングエンジン810は、このルーティングテーブルを使用して、命令をどこへルーティングすべきかを決定してよい。
受信した命令が、ルーティングエンジンの制御モジュール120により管理される動作エンティティ110に対応する場合、ルーティングエンジン810は、該動作エンティティが、命令により示されたアクション/動作を処理するための、制御API700の機能を実装するか否かを調べてよい。上述のように、種々の実施形態で、制御モジュール120は、制御API情報420に機能マップを格納してよい。機能マップは、制御API700の機能を、動作エンティティのUUT321及びライフサイクル322にマッピングする。従って、ルーティングエンジン810は、機能マップ、UUT321、及びライフサイクル322に基づき、動作エンティティ110により実施される制御API700の機能のリストを構築し得る。命令が動作エンティティ110のUUT321及びライフサイクル322を指定しない場合、ルーティングエンジン810は、該動作エンティティに対する命令の中で指定され得るUUID325を用いて、動作エンティティのブループリント210を探してよい。ルーティングエンジン810は、次に、アクセスされたブループリント210からUUT321及びライフサイクル322を抽出してよい。ブループリント210が特定できない場合、ルーティングエンジン810は、命令の発行元にエラーを返してよい。種々の実施形態で、ルーティングエンジン810は、関連する動作エンティティ110のUUT321及びライフサイクル322に対応する機能マップの中で示された機能を選択することにより、機能のリストを構築する。
実施される機能のリストを構築した後に、種々の実施形態で、ルーティングエンジン810は、命令により要求された動作を実施するための機能が該リストに含まれるか否かを決定する。例えば、命令が、特定の変数340を新しい値に遷移させる遷移動作を特定する場合、ルーティングエンジン810は、リストに基づき、動作エンティティ110が該特定の変数を遷移させる遷移機能730を実施するか否かを決定してよい。実施する場合、ルーティングエンジン810は、該遷移機能を呼び出してよく、その他の場合、ルーティングエンジン810は、命令の発行元にエラーを返してよい。この方法で、ルーティングエンジン810は、受信した命令を処理してよい。
命令をルーティングするとき、又は制御API700の機能を呼び出すとき、ルーティングエンジン810は、ルーティング層820への呼び出しを行ってよい。ルーティング層820は、種々の実施形態で、ソフトウェアルーチンのセット、ハードウェア、又は命令を別のコンポーネント(動作エンティティ110又は制御モジュール120)へルーティングする及び/又は制御API700の機能を呼び出すよう動作するそれらの組み合わせである。ルーティング層820は、制御モジュール120から要求を受信して、命令を別の特定の制御モジュール120へ送信するか、又は制御API700の特定の動作エンティティ110により実施される特定の機能を呼び出してよい。従って、該要求は、命令、制御モジュール120のUUID325、動作エンティティ110のUUID325、及び/又は機能呼び出しを指定してよい。ルーティング層820は、命令がルーティングされるべきか、又は機能が呼び出されるべきかを、制御モジュール120から受信された要求の内容に基づき決定してよい。要求が命令を指定する場合、ルーティング層820は、(例えば、UUID325に基づき)適切な制御モジュール120を特定し、命令を該制御モジュールへ送信してよい。要求が機能を指定する場合、ルーティング層820は、(例えば、UUID325に基づき)適切な動作エンティティ110を特定し、該特定の動作エンティティにより実施される機能を呼び出してよい。
種々の場合に、ルーティング層820は、リモートにある(例えば、ルーティングエンジン810に関連付けられたローカルネットワークの外部にある動作エンティティ110)動作エンティティ110又は制御モジュール120と通信する必要があってよい。本願明細書で使用されるとき、動作エンティティ110又は制御モジュール120は、それらが同じローカルネットワーク内に存在しない場合、別の動作エンティティ110又は制御モジュール120に対して「リモート」である。動作エンティティ110又は制御モジュール120がローカルかリモートかを決定するために、種々の実施形態で、ルーティング層820は、該動作エンティティ又は制御モジュールに関連付けられたルーティング可能エンティティ830の情報(例えば、ブループリント210)にアクセスする。
ルーティング可能エンティティ830は、種々の実施形態で、別の動作エンティティ110又は制御モジュール120がルーティング層820からリモートにあるか否かを識別する特別な動作エンティティ110である。幾つかの場合には、ルーティング可能エンティティ830は、リモートホストポートを(例えば、変数340として)指定するブループリント210又は定義310を含んでよい。幾つかの実施形態では、ルーティング可能エンティティ830がリモートホストポートを識別する場合、ルーティング層820は、関連付けられた動作エンティティ110又は制御モジュール120がリモートであると決定し、その他の場合、ローカルであると決定する。例えば、ルーティング可能エンティティ830Aに関連付けられた情報(例えば、ブループリント210)は、動作エンティティ110Aがローカルにあることを示してよい。一方で、ルーティング可能エンティティ830Bに関連付けられた情報は、動作エンティティ110Bがリモートにあることを示してよい。この情報に基づき、ルーティング層820は、動作エンティティ110又は制御モジュール120と通信する適切な通信プロトコルを選択してよい。適切なルーティング可能エンティティ830にアクセスするために、種々の実施形態で、ルーティング層820は対応する動作エンティティ110又は制御モジュール120についての関係情報330にアクセスする。関係情報330は、対応する動作エンティティ110と関連するルーティング可能エンティティ830との間の関係331を識別してよい。一例として、動作エンティティ110は、ルーティング可能エンティティ830内に「含まれ」てよい。これに基づき、ルーティング層820は、ローカルストレージ及び/又はデータベース130から、該ルーティング可能エンティティ830のブループリント210を探してよい。
種々の実施形態で、制御モジュール120は、動作エンティティ110又は制御モジュール120がリモートかローカルかについて不可知である。制御モジュール120は、代わりに、この決定を行うためにルーティング層820に依存してよい。制御モジュールの観点から、ローカル動作エンティティ110及びリモート動作エンティティ110と通信することは、同じであってよい(それは、全ての動作エンティティ110がローカルにあるかのように見えてよい)。これは、2つの異なる制御APIを使用する代わりに、動作エンティティ110と通信する処理を1つの制御APIに簡略化することを可能にする。
図9を参照すると、方法900のフロー図が示される。方法900は、目標コンピュータ環境(例えば、目標環境137)の(例えば、動作情報135の中の)動作シナリオの一部として、動作エンティティ(例えば、動作エンティティ110)への命令を発行するために、制御モジュール(例えば、制御モジュール120)により実行される方法の一実施形態である。方法900は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの場合には、方法900は、制御モジュールがユーザ又は別の制御モジュールから命令を受信することに応答して実行されてよい。幾つかの実施形態では、方法900は、追加ステップを含んでよい。例えば、制御モジュールは、命令を、実施するために別の制御モジュールへルーティングしてよい。
方法900は、ステップ910で開始し、制御モジュールが発見手順を実行する。発見手順の一部として、ステップ912で、制御モジュールは、制御モジュールにより制御されるべき目標コンピュータ環境の階層構造の中のコンポーネントを識別する。制御モジュールは、制御モジュールにより制御されるべき階層構造内のコンポーネントに対応するユニーク識別子(例えば、UUID325)を定義する動作エンティティ情報(例えば、動作エンティティ情報410)にアクセスすることにより、階層構造の中のコンポーネントを識別してよい。種々の場合に、階層構造は、制御モジュール及び動作エンティティの両方を含んでよい。
発見手順の一部として、ステップ914で、制御モジュールは、識別されたコンポーネントの機能的能力を発見する。所与のコンポーネントは、制御アプリケーションプログラミングインタフェース(application programming interface (API))(例えば、制御API700)によりサポートされる複数の機能(例えば、機能710、720、730、等)のうちの1つ以上の機能を実施してよい。1つ以上の機能は、制御モジュールが所与のコンポーネントの状態を変化させることを可能にし得る。制御モジュールは、動作エンティティセットのうちの所与の動作エンティティを、制御APIによりサポートされる複数の機能のうちの所与の動作エンティティにより実施される機能のセットにマッピングするマッピングを生成してよい。制御モジュールは、特定の動作エンティティ及び別の特定の動作エンティティを制御してよい。種々の場合に、特定の動作エンティティは、他の特定の動作エンティティと異なる、複数の機能セットを実施してよい。
種々の実施形態で、コンポーネントの機能的能力を発見するステップは、制御APIの特定の動作エンティティにより実施される記述機能(例えば、記述機能710)を呼び出すことにより、特定の動作エンティティの機能的能力を発見するステップを含んでよい。記述機能を呼び出すことに応答して、制御モジュールは、特定の動作エンティティにより実施される制御APIの複数の機能のうちの機能セットを識別する応答を、特定の動作エンティティからを受信してよい。
ステップ920で、制御モジュールは、目標コンピュータ環境のための動作シナリオの一部を実施する。動作シナリオは、発見手順の間に識別されたコンポーネントを、第1バージョンから第2バージョンへ更新するステップを含んでよい。動作シナリオの一部を実施する部分として、ステップ922で、制御モジュールは、制御モジュールを制御するコンポーネント(例えば、別の制御モジュール120))から、特定の動作及び該特定の動作を実行するための特定の動作エンティティを指定する命令を受信する。
動作シナリオの一部を実施する部分として、ステップ922で、制御モジュールは、特定の動作、特定の動作エンティティ、及び識別されたコンポーネントの発見された機能的能力を用いて、命令に対する応答を生成する。命令に対する応答を生成するステップは、制御モジュールが、機能セットから、特定の動作エンティティに特定の動作を実行させるために呼び出し可能な特定の機能を識別するステップを含んでよい。制御モジュールは、ライフサイクルステージを示すライフサイクル値に基づき、機能セットから特定の機能を決定してよい。幾つかの場合には、命令は、特定の動作エンティティに関連付けられたユニーク識別子を定義してよい。従って、制御モジュールは、ユニーク識別子に基づき、特定の動作エンティティに対応するブループリントにアクセスし得る。ブループリントは、ライフサイクル値を指定してよい。特定の機能は、第1状態から第2状態へと特定の動作エンティティを遷移させるために呼び出し可能な遷移機能(例えば、遷移機能730)であってよい。制御モジュールは、特定の動作を実行するために、特定の機能を呼び出す制御API呼び出しを、特定の動作エンティティに発行してよい。制御部は、更に、特定の制御モジュールを制御しているコンポーネントに、特定の動作の実行が成功したか否かを示す結果を指定するメッセージを送信してよい。
幾つかの場合には、制御モジュールは、別の動作及び別の動作を実行する別の動作エンティティを指定する別の命令を受信してよい。制御モジュールは、他の命令に基づき、他の動作エンティティが別の特定の制御モジュールにより制御されることを決定してよい。このように、制御モジュールは、他の命令を他の特定の制御モジュールへルーティングしてよい。
図10を参照すると、方法1000のフロー図が示される。方法1000は、目標コンピュータ環境(例えば、目標環境137)の(例えば、動作情報135の中の)動作シナリオの一部として、動作エンティティ(例えば、動作エンティティ110)への命令を発行するために、制御モジュール(例えば、制御モジュール120)により実行される方法の一実施形態である。方法1000は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの実施形態では、方法1000は、追加ステップを含んでよい。例えば、制御モジュールは、命令を、実施するために別の制御モジュールへルーティングしてよい。
方法1000は、ステップ1010で開始し、制御モジュール及び動作エンティティを含む階層構造の中にある制御モジュールは、動作エンティティにより実行されるべき動作を指定する命令を、動作シナリオの一部として受信する。幾つかの場合には、命令は、制御モジュールを制御する、階層構造の中の別の制御モジュールから受信されてよい。
ステップ1020で、制御モジュールは、所与の動作エンティティの状態を変化させることを可能にする、制御アプリケーションプログラミングインタフェース(API)(例えば、制御API700)によりサポートされる複数の機能から、動作エンティティにより実施される機能セット(例えば、機能710、720、等)を発見する。機能セットを発見するステップは、制御モジュールが、動作エンティティから、動作エンティティにより実施される機能セットを識別するブロードキャストを受信するステップを含んでよい。
ステップ1030で、制御モジュールは、機能セットが、動作エンティティに動作を実行させるために呼び出し可能な機能を含むか否かを決定する。
ステップ1040で、動作エンティティに動作を実行させるために呼び出し可能な特定の機能を決定することに応答して制御モジュールは、特定の機能を呼び出す。特定の機能は、動作エンティティを破棄させるために呼び出し可能な破棄機能であってよい。種々の場合に、制御モジュールは、命令を送信した他の制御モジュールに、命令の実行に成功したことを示すメッセージを送信してよい。
図11を参照すると、方法1100のフロー図が示される。方法1100は、(例えば、動作情報135の中の)動作シナリオの一部として、動作エンティティ(例えば、動作エンティティ110)への命令を発行するために、制御モジュール(例えば、制御モジュール120)により実行される方法の一実施形態である。方法1100は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの場合には、方法1100は、制御モジュールがユーザ又は別の制御モジュールから命令を受信することに応答して実行されてよい。幾つかの実施形態では、方法1100は、追加ステップを含んでよい。例えば、制御モジュールは、自身の動作エンティティと通信して、制御API(例えば、制御API700)のどの機能(例えば、機能710、720、等)がそれらの動作エンティティにより実施されているかを決定してよい。
方法1100は、ステップ1110で開始し、制御モジュールが、動作シナリオの自動化された実施の一部とし第1状態から第2状態へと遷移させられるべき特定の動作エンティティを識別する命令を受信する。制御モジュールは、制御モジュール及び動作エンティティを有するコンポーネントの階層構造の中に含まれてよい。種々の場合に、階層構造は、該階層構造の最上位にある、該階層構造の次のレベルにある制御モジュールへ命令を発行することにより動作シナリオを実施するために実行可能なオーケストレータ制御モジュールを有してよい。従って、動作シナリオを実施するステップの一部として、命令は、オーケストレータ制御モジュールから制御モジュールにより受信されてよい。動作シナリオは、制御モジュールを実行するコンピュータシステムのユーザの代わりに、データベーストランザクションを実行する能力のあるデータベースサーバのセットを有するデータベースサービスを機能するステップを含んでよい。
ステップ1120で、制御モジュールは、ルーティング層(例えば、ルーティング層820)へ呼び出しを行うことにより、特定の動作エンティティについて、命令を実行させる。幾つかの場合には、呼び出しは、特定の動作エンティティが制御モジュールのローカル環境に対してリモートであるか否かを指定しなくてよい。種々の実施形態で、制御モジュールは、特定の動作エンティティがローカル環境内にあるか又はローカル環境に対してリモートにあるかとは独立して、ルーティング層へ同じ呼び出しを行う。呼び出しは、命令を実行する特定の動作エンティティにより実施される特定の機能を指定してよい。幾つかの場合には、ルーティング層は、特定の機能を呼び出すことにより、ルーティング動作を実行してよい。幾つかの場合には、呼び出しは、データベースを起動するステップの一部として、データベースをインスタンス化するよう、ルーティング層に特定の動作エンティティの特定の機能を呼び出させるために、ルーティング層に対して行われてよい。更に幾つかの場合には、ルーティング層は、特定の動作エンティティを管理する別の制御モジュールへ命令をルーティングすることにより、ルーティング動作を実行してよい。
種々の実施形態で、ルーティング層は、特定の動作エンティティがローカル環境内にあるか又はローカル環境に対してリモートにあるかについて、決定を行うよう動作する。ルーティング層は、該決定を用いて、特定の動作エンティティに関連するルーティング動作を実行してよい。幾つかの実施形態では、ルーティング層は、特定の動作エンティティに関連付けられたルーティング可能エンティティ(例えば、ルーティング可能エンティティ830)のブループリント(例えば、ブループリント210)にアクセスするよう動作する。ルーティング層は、先ず、特定の動作エンティティとルーティング可能エンティティとの間の関係(例えば、関係情報330)を指定する特定の動作エンティティのブループリントにアクセスしてよい。該関係は、ルーティング層がルーティング可能エンティティのブループリントにアクセスすることを可能にしてよい。
種々の実施形態で、ルーティング層は、ブループリントがリモートホストポートを指定するか否かに基づき、特定の動作エンティティがローカル環境に対してリモートにあることを決定する。ルーティング層は、特定の動作エンティティがローカル環境に対してリモートにあることを示す決定に基づき、他の制御モジュールへ命令をルーティングするために第1ルーティングプロトコルを選択してよい。種々の場合に、第1ルーティングプロトコルは、ローカル環境内の命令をルーティングするために使用可能な第2ルーティングプロトコルと異なってよい。
図12を参照すると、方法1200のフロー図が示される。方法1200は、(例えば、動作情報135の中の)動作シナリオの一部として、動作エンティティ(例えば、動作エンティティ110)へ命令をルーティングするために、ルーティング層を実装するコンピュータシステムにより実行される方法の一実施形態である。方法1200は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの実施形態では、方法1100は、追加ステップを含んでよい。
方法1200は、ステップ1210で開始し、ルーティング層は、第1状態から第2状態へ遷移されるべき特定の動作エンティティへ、命令をルーティングする要求を受信する。要求は、特定の動作エンティティが、要求の受信された制御モジュールのローカル環境に対してリモートにあるか否かを指定しなくてよい。
ステップ1220で、ルーティング層は、特定の動作エンティティについて維持される情報に基づき、特定の動作エンティティがローカル環境内にあるか又はローカル環境に対してリモートにあるかについて決定を行う。情報は、特定の動作エンティティのブループリント(例えば、ブループリント210)を定義してよい。種々の場合に、ブループリントは、特定の動作エンティティと、ルーティング可能エンティティとの間の関係(例えば、関係331)を定義してよい。ここで、該ルーティング可能エンティティは、該第2ブループリントに関連付けられ、該第2ブループリントは、該特定の動作エンティティがローカル環境内にあるか又はローカル環境に対してリモートにあるかを示す。ルーティング層は、該関係に基づき第2ブループリントにアクセスし、リモートホストポートを指定するアクセスされた第2ブループリントに基づき、特定の動作エンティティがローカル環境に対してリモートにあることを決定してよい。
ステップ1230で、ルーティング層は、決定に基づき特定の動作エンティティへ命令をルーティングする。命令をルーティングするステップの一部として、ルーティング層は、特定の動作エンティティを第1状態から第2状態へと遷移されるための、特定の動作エンティティにより実施される特定の機能(例えば、遷移機能730)を呼び出してよい。幾つかの場合には、命令をルーティングするステップの一部として、ルーティング層は、命令を、要求の受信された制御モジュールに対して制御部の階層構造の次のレベルにある別の制御モジュールへ送信してよい。この他の制御モジュールは、特定の動作エンティティを直接管理してよい。
図13を参照すると、方法1300のフロー図が示される。方法1300は、(例えば、動作情報135の中の)動作シナリオの一部として、動作エンティティ(例えば、動作エンティティ110)への命令を発行するために実行される方法の一実施形態である。方法1300は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの実施形態では、方法1300は、追加ステップを含んでよい。一例として、制御モジュールは、自身の権限下にある動作エンティティと通信して、制御API(例えば、制御API700)のどの機能(例えば、機能710、720、等)がそれらの動作エンティティにより実施されているかを決定してよい。
方法1300は、ステップ1310で開始し、コンピュータシステム(例えば、システム100)は、制御モジュール及び動作エンティティを含むコンポーネントの階層構造を実行する。種々の場合に、階層構造は、該階層構造の最上位にある、該階層構造の次のレベルにある制御モジュールへ命令を発行することにより動作シナリオを実行するために実行可能なオーケストレータ制御モジュールを有してよい。
ステップ1320で、階層構造の制御モジュールは、第1状態から第2状態へと遷移されるべき動作エンティティのうちの特定の動作エンティティを識別する命令を受信する。
ステップ1330で、制御モジュールは、ルーティング層(例えば、ルーティング層820)へ呼び出しを行うことにより、命令を実行させる。呼び出しは、特定の動作エンティティが制御モジュールのローカル環境に対してリモートであるか否かを指定しなくてよい。幾つかの実施形態では、制御モジュールは、特定の動作エンティティが制御モジュールのローカル環境に対してリモートにあるか否かとは独立して、ルーティング層へ同じ呼び出しを行う。
ルーティング層は、特定の動作エンティティがローカル環境内にあるか又はローカル環境に対してリモートにあるかについて、決定を行うよう動作してよい。ルーティング層は、該決定を用いて、特定の動作エンティティへ命令をルーティングしてよい。種々の場合に、ルーティング層は、特定の動作エンティティがリモートホストポートに関連付けられていることに応答して、特定の動作エンティティがローカル環境に対してリモートにあることを決定してよい。ルーティング層は、ローカル環境に対してリモートにある動作エンティティへ命令をルーティングするために第1ルーティングプロトコルを利用し、及びローカル環境内にある動作エンティティへ命令をルーティングするために第2の異なるルーティングプロトコルを利用してよい。幾つかの場合には、命令をルーティングするステップは、特定の動作エンティティを直接管理する、階層構造の次のレベルにある別の制御モジュールへ命令をルーティングするステップを含んでよい。
図14を参照すると、ワークフローエンジン440のブロック図が示される。幾つかの実施形態では、ワークフローエンジン440は、ワークフロー処理エンジン1420及び予約エンジン1440を含む。更に示されるように、データベース130は、ワークフロー1410及びワークフロー状態情報1430を含む。ワークフロー状態情報1430は、図示のように、動作エンティティ110に格納することができる。幾つかの実施形態では、ワークフローエンジン440は、図と異なる方法で実装されてよい。例えば、ワークフローエンジン440は、ワークフロー状態情報1430を含んでよい。
上述のように、動作シナリオは、何らかの意図された目標(例えば、動作エンティティ110のセットを新しいバージョンに更新する)を実行するステップシーケンスに対応するコマンドセットを用いて実施されてよい。ワークフロー1410は、種々の実施形態で、特定の動作シナリオに対応する順序付きコマンドセットを指定する。従って、ワークフロー1410のコマンドセットの実施は、結果として、関連付けられた動作シナリオを実行させ得る。幾つかの場合には、ワークフロー1410は、ユーザにより提供されデータベース130に格納されてよい。ワークフロー1410は、図17に関して詳述されるように、推理エンジン450により提供されてもよい。制御モジュール120は、ワークフロー要求1405に応答して、(例えば、データベース130から)ワークフロー1410にアクセスしてよい。
ワークフロー要求1405は、種々の実施形態で、指定されたワークフロー1410を実施するようワークフローエンジン440に指示する要求である。ワークフロー要求1405は、制御モジュール120が対応するワークフロー1410にアクセスすることを許可する名称又は識別子を識別してよい。ワークフロー要求1405は、コマンドラインツールを介してユーザから及び/又は別の制御モジュール120から受信されてよい。例えば、オーケストレータ制御モジュール120は、ワークフロー要求1405をユーザから受信してよい。幾つかの場合には、ワークフロー1410の実施は、他の異なるワークフロー1410の実施を含んでよい。幾つかの実施形態では、ワークフロー1410は、ワークフローの階層構造を形成するよう積層されてよい。該階層構造の中では、最上位ワークフロー1410は上位タスクを実行し、下位ワークフロー1410はそれぞれ、該上位タスクのサブタスクを実行する。前述の例を続けると、受信されたワークフロー要求1405の中で指定された特定のワークフロー1410を実施するステップは、オーケストレータ制御モジュール120が、下位レベル制御モジュール120に、特定のワークフロー1410に対応するワークフロー1410のセットを実施させることを含んでよい。所与のワークフロー1410を実施するために、種々の実施形態で、制御モジュール120は、ワークフロー進行エンジン1420及び逆方向エンジン1440を含む。
ワークフロー処理エンジン1420は、種々の実施形態では、ワークフロー1410の中で指定された順序付きコマンドセットを実施するために実行可能なソフトウェアルーチンのセットである。ワークフロー処理エンジン1420は、システム100内のコンポーネントに命令を発行することにより、コマンドセットを実施してよい。前述のように、幾つかの実施形態では、コマンドは、人間により読み取り可能な形式で又は動作エンティティ110及び制御モジュール120により理解可能な形式であってよい。結果としてワークフロー処理エンジン1420により発行された命令は、実際の対応するコマンド又は動作エンティティ110及び制御モジュール120により理解可能なフォーマットへのコマンドの変換であってよい。ワークフロー処理エンジン1420は、前述の方法で(例えば、ルーティングエンジン8101と相互作用して、ルーティング層820への呼び出しを行うことにより)命令を発行してよい。
順序付きコマンドセットを実施するとき、種々の実施形態で、ワークフロー処理エンジン1420は、ワークフロー状態情報1430を維持する。ワークフロー状態情報1430は、種々の実施形態で、ワークフロー1410の実施の現在状態及び/又は目標環境137の現在状態を指定する。例えば、ワークフロー状態情報1430は、既に実施されたワークフロー1410のコマンドを識別してよい。従って、コマンドが完了したことに応答して、ワークフロー処理エンジン1420は、該完了したコマンドを反映するよう、ワークフロー状態情報1430を更新してよい。ワークフロー状態情報1430は、目標環境内の動作エンティティ110及び制御モジュール120の状態を識別することにより、目標環境137の状態を識別してよい。例えば、ワークフロー状態情報1430は、どの動作エンティティ110が「オンライン」であるか、及びどれが「オフライン」であるかを示してよい。ワークフロー状態情報1430は、ワークフローが順方向に又は逆方向に実行しているかを示してもよい。上述のように、ワークフロー1410を実施する際にエラーが生じることに応答して、逆方向エンジン1440は、ワークフロー状態情報1430を用いてエラーに応答してよい。
逆方向エンジン1440は、種々の実施形態で、システム100の状態を、ワークフロー1410の開始される前に存在した初期状態に戻すために実行可能なソフトウェアルーチンのセットである。幾つかの場合には、ワークフロー1410を実施している間に、エラーが生じ得る。例えば、コマンドは、ワークフローエンジン440がそれを実施しようとする度に失敗し得る。別の例として、ワークフローエンジン440(及びその制御モジュール120)は、クラッシュし、ハングし、又は別の種類の機能不全を経験し得る。ワークフロー1410の実施中にエラーが生じた場合、種々の場合に、ワークフローエンジン440は、対応するコマンドを再度実施することにより、関連するステップを再試行してよい。幾つかの場合には、しかしながら、逆方向エンジン1440は、システム100の状態を、ワークフロー1410に関連付けられた初期状態に戻すことを試みてよい。
システム100の状態を逆行させるために、逆方向エンジン1440は、逆順にコマンドセットをトラバースしてよい。種々の実施形態で、ワークフロー1410の中で指定されたコマンドセットは、目標環境137を初期状態から意図された状態へ遷移させるために順方向の順序でトラバースされ、目標環境137を現在状態(例えば、意図された状態)から初期状態へ遷移させるために逆方向の順序でトラバースされ得る。逆方向の順序でコマンドをトラバースすることにより、逆方向エンジン1440は、システムを壊れた又は不明な状態のままにする代わりに、知られた状態に戻すことができる。従って、エラー(例えば、コマンドが完了できないこと)に応答して、逆方向エンジン1440は、既に実施されたこれらのコマンドを逆方向に進み、これらのコマンドにより生じた1つ以上の状態変化を取り消してよい。例えば、特定のコマンドが動作エンティティ110を「オフライン」から「オンライン」へと遷移させた場合、逆方向エンジン1440は、(例えば、制御API700の機能を呼び出すことにより、又は動作エンティティ110を管理する制御モジュール120へ命令を発行することにより)該動作エンティティ110を「オフライン」へと遷移させて戻してよい。幾つかの場合には、ワークフローコマンド逆転することができない。これは、コマンドに関連付けられたメタデータにより示されてよい。従って、ワークフローエンジン440は、停止し、ユーザに問題を警告してよい。
種々の場合に、制御モジュール120(例えば、オーケストレータ制御モジュール120)はワークフロー1410を実施している間に機能不全になり得る(例えば、クラッシュする)。このような状況では、制御モジュール120が復旧すると(例えば、新しい制御モジュール120がインスタンス化されると)、該ワークフロー1410の実施を再開することが望ましいことがある。従って、復旧し又は復元されると、制御モジュール120は、ワークフロー1410の進行中の実施が存在するかどうかを決定するために、ワークフロー状態情報1430へのアクセスを試みてよい。制御モジュール120は、続いて、進行中のものが存在する場合、ワークフロー1410の実施を再開してよい。幾つかの場合には、制御モジュール120は、ワークフロー1410の中の次のコマンドを実行することを試みてよい。更に他の場合には、制御モジュール120は、目標環境137を初期状態に戻すために、既に完了したコマンドを逆戻ししてよい。制御モジュール120は、次に、ワークフロー1410全体を再試行してよい。
制御モジュール120は機能不全であり得るので、種々の実施形態で、ワークフロー状態情報1430は、制御モジュール120の外部の場所に格納される。その結果、制御モジュール120が機能不全になった場合、ワークフロー状態情報1430が失われない。状態情報1430が外部位置に格納されるか否かは、制御モジュール120により管理されるエンティティ110が「状態」であるか否か、及び該制御モジュールの寿命が該エンティティにより制限されるか否かにも依存してよい。一例として、制御モジュール120が、無状態(stateless)アプリケーションと同じコンテナの内部にある場合、それは、ワークフロー状態情報1430を外部に格納しなくてよく、ローカルメモリに格納してよい。コンテナを終了させる問題が存在した場合、該エンティティ110及び該制御モジュール120の両方は破棄され、ワークフローの状態は、次にその場合に論点(moot)になり得る。しかし、変更されている状態が該コンテナの外部に存続する場合、該制御モジュール120は、ワークフロー状態情報1430をコンテナの外部の場所に格納してよい。図14に示されるように、ワークフロー状態情報1430は、動作エンティティ110及びデータベース130に格納することができる。幾つかの実施形態では、制御モジュール120が、要素220としてデータベースを含む動作エンティティ110を管理する場合、制御モジュール120は、該データベースを利用して、ワークフロー状態情報1430を格納してよい。制御モジュール120が初期化されると、それは、動作エンティティ110について知るために、自身の管理する動作エンティティ110の記述機能710を呼び出してよい。動作エンティティ110がワークフロー状態情報1430を格納している場合、それは、制御モジュール120に該情報を通知してよい。この方法で、制御モジュール120は、対応するワークフロー状態情報1430と一緒に、ワークフロー1410の進行中の実施について知ってよい。
図15を参照すると、方法1500のフロー図が示される。方法1500は、目標コンピュータ環境(例えば、目標環境137)でワークフローを実施するために、オーケストレータ制御モジュール(例えば、制御モジュール120)により実行される方法の一実施形態である。方法1500は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの実施形態では、方法1500は、追加ステップを含んでよい。一例として、オーケストレータ制御モジュールは、動作シナリオを実行するための要求(例えば、ワークフロー要求1405)を受信してよい。幾つかの場合には、要求は、ワークフロー情報をアクセス可能にする、ワークフローに対応する名称値を指定してよい。
方法1500は、ステップ1510で開始し、オーケストレータ制御モジュールが、制御モジュールと動作エンティティとを含むコンポーネントのセット及び初期状態を有する目標コンピュータ環境で動作シナリオを自動的に実施するステップシーケンスに対応するコマンドセットを有するワークフロー(例えば、ワークフロー1410)を定義するワークフロー情報(例えば、動作情報135)にアクセスする。幾つかの場合には、動作シナリオは、コンピュータシステムのユーザの代わりに、データベーストランザクションを実行する能力のある1つ以上のデータベースサーバを有するデータベースサービスを起動するステップを含んでよい。
ステップ1520で、オーケストレータ制御モジュールは、ステップシーケンスを実行させるために、コンポーネントセットのうちのコンポーネントに命令を発行することにより、ワークフローのコマンドセットを実施する。コマンドセットを実施するステップは、目標コンピュータ環境において、初期状態に対して1つ以上の状態変化を生じさせてよい。種々の実施形態で、コマンドセットは、コマンドセットのうちのコマンドが、目標コンピュータ環境を初期状態から指定された終了状態へ遷移させるために、及び目標コンピュータ環境を現在状態から初期状態へ戻すよう逆に遷移させるために実施され得るよう定義される。目標コンピュータ環境における1つ以上の状態変化は、コンポーネントセットのうちの特定のコンポーネントが、目標コンピュータ環境内の新しいコンポーネントをインスタンス化する状態変化を含んでよい。幾つかの場合には、新しいコンポーネントは、目標コンピュータ環境において、特定のコンポーネントと異なる役割を有してよい。
ステップ1530で、オーケストレータ制御モジュールは、オーケストレータ制御モジュールがコマンドセットを実施する際にエラーに応答することを可能にする、目標コンピュータ環境の現在状態を識別する状態情報(例えば、ワークフロー状態情報1430)を維持する。ステップシーケンスのうちの特定のステップが実行に失敗したことを検出することに応答して、オーケストレータ制御モジュールは、コンポーネントセットのうちのコンポーネントに、該特定のステップに対応する1つ以上の命令を再発行することにより、特定のステップを再試行してよい。幾つかの場合には、エラーは、コマンドセットが完了するのを妨げ得る。従って、オーケストレータ制御モジュールは、目標コンピュータ環境を初期状態に戻すために、目標コンピュータ環境における1つ以上の状態変化を逆行させることにより、エラーに応答してよい。幾つかの実施形態では、1つ以上の状態変化を逆行させるステップは、コマンドセットのうちのコマンドが完了した順序を逆方向にトラバースするステップを含む。トラバースするステップを実行する間、オーケストレータ制御モジュールは、既に完了したこれらのコマンドにより引き起こされた1つ以上の状態変化を取り消してよい。
幾つかの場合には、エラーは、コマンドセットを実施する間、オーケストレータ制御モジュールがクラッシュすることを含む。状態情報は、復帰したオーケストレータ制御モジュールがコマンドセットの実施を後に再開できるようにしてよい。幾つかの実施形態では、状態情報は、オーケストレータ制御モジュールのクラッシュが状態情報を損失させないように、オーケストレータ制御モジュールの外部にある位置(例えば、データベース130)において、オーケストレータ制御モジュールにより維持される。状態情報は、目標コンピュータ環境内の動作エンティティにおいて、オーケストレータ制御モジュールにより維持されてよい。
図16を参照すると、方法1600のフロー図が示される。方法1600は、目標コンピュータ環境(例えば、目標環境137)でワークフローを実施するために実行される方法の一実施形態である。方法1600は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの実施形態では、方法1600は、追加ステップを含んでよい。一例として、オーケストレータ制御モジュールは、動作シナリオを実行するための要求(例えば、ワークフロー要求1405)を受信してよい。幾つかの場合には、要求は、ワークフロー情報をアクセス可能にする、ワークフローに対応する名称値を指定してよい。
方法1600は、ステップ1610で開始し、コンピュータシステムは、制御モジュール及び動作エンティティを含むコンポーネントの階層構造を実行する。種々の場合に、階層構造は、該階層構造の最上位にある、動作シナリオのステップシーケンスに対応するコマンドセットを実行することにより動作シナリオを実施するために実行可能なオーケストレータ制御モジュールを有してよい。
ステップ1620で、階層構造のコンポーネントセットと初期状態とを有する目標コンピュータ環境の特定の動作シナリオを実施するための要求を受信することに応答して、オーケストレータ制御モジュールは、特定の動作シナリオに対応するコマンドを有するワークフローを実施する。
ステップ1622で、ワークフローを実施するステップの部分として、オーケストレータ制御モジュールは、ワークフローのコマンドを実行させるために、階層構造の中の制御モジュールのうちの制御モジュールに命令を発行する。その結果、目標コンピュータ環境に、初期状態に対して1つ以上の状態変化が生成される。幾つかの場合には、命令を発行するステップは、階層構造の中の特定の制御モジュールに、第2の異なるワークフローを実施させてよい。ワークフロー及び第2ワークフローは、ワークフローの階層構造を形成してよい。該階層構造は、該ワークフローをワークフローの階層構造の最上位に、該第2ワークフローをワークフローの階層構造の次のレベルに含む。幾つかの場合には、特定の制御モジュールは、特定の制御モジュールを含むレベルに対して、コンポーネントの階層構造の次のレベルにあるコンポーネントに命令を発行することにより、第2ワークフローを実施してよい。
ステップ1624で、ワークフローを実施するステップの一部として、オーケストレータ制御モジュールは、ワークフローを実施する際にエラーに応答することを可能にする、目標コンピュータ環境の現在状態を識別する状態情報(例えば、ワークフロー状態情報1430)を維持する。幾つかの場合には、エラーは、ワークフローを実施する間、オーケストレータ制御モジュールがハングすることを含んでよい。したがって、状態情報は、復帰したオーケストレータ制御モジュールがワークフローの実施を後に再開できるようにしてよい。幾つかの実施形態では、状態情報は、目標コンピュータ環境に含まれるコンポーネントセットの構成変数(例えば、変数340)を指定する。
図17を参照すると、推理エンジン450のブロック図が示される。幾つかの実施形態では、推理エンジン450は、直接推理エンジン1710及び間接推理エンジン1720を含む。図示のように、推理エンジン450は、実施するために、ワーフフローエンジン440に、ワークフロー1410を提供できる。
幾つかの実施形態では、推理エンジン450は、図と異なる方法で実装されてよい。例えば、推理エンジン450は、ワークフローエンジン440を有しないで動作してよい。つまり、推理エンジン450は、システム100を意図された状態へと移行させるステップを生成し実施してよい。これは、推理エンジン450が、システム100の状態を評価し、制御API700のサポートするコマンドを発行し、そして、意図された状態に達するまでシステム100の状態を再評価するステップを含んでよい。例えば、推理エンジン450は、アプリケーションバージョンを「A」から「X」へ遷移させる推理要求1705を受信してよい。従って、推理エンジン450は、アプリケーションバージョンを「A」から「X」へ遷移させる遷移要求を発行してよい。しかし、例えば、遷移コマンドに関連付けられたデータベースサーバがクラッシュした場合、推理エンジン450は、システム100のこの新しい状態を識別してよい。従って、推理エンジン450は、データベースサーバの状態を「オフライン」から「オンライン」へ遷移させる新しいコマンドを生成し発行してよい。推理エンジン450は、次に、アプリケーションバージョンを「A」から「X」へ遷移させることを再試行してよい。この方法で、推理エンジン450は、ワークフローエンジン440と非常に似た順序でステップを実施してよいが、ステップは、オンザフライで又は事前にまとめて生成することもできる。
直接推理エンジン1710は、種々の実施形態では、ワークフロー1410を生成するために実行可能なソフトウェアルーチンのセットである。図示のように、推理エンジン450は、推理要求1705を受信し得る。ワークフロー1410が実施されることを指定する代わりに、推理要求1705は、上位目標(例えば、管理下にあるシステムの所望の状態)又は達成されるべき遷移バージョンコマンドのようなコマンドを指定してよい。例えば、推理要求1705は、1つ以上のデータベースサーバエンティティ110と1つ以上のメトリックサーバエンティティ110とを含むデータベースサービスエンティティ110がインスタンス化されるべきであると指定してよい。該推理要求は、しかしながら、データベースサービスエンティティ110をインスタンス化するためにコマンドを指定しなくてもよい。従って、直接推理エンジン1710は、ワークフロー1410を生成するために、直接推理の概念を適用してよい。種々の場合に、直接推理エンジン1710は、動作エンティティ110がどのように関連付けられるかを識別するために、ブループリント210に含まれる関係情報330のような情報を使用してよい。動作エンティティ110がどのように関連付けられるかに基づき、直接推理エンジン1710は、特定の動作エンティティ110が他の動作エンティティ110の前にインスタンス化されるべきであると決定してよい。この推理に基づき、直接推理エンジン1710は、順序付きコマンドセットを生成してよい。
前述の例を続けると、推理要求1705は、データベースサービスエンティティ110のUUT321又はUUID325を指定してよい。直接推理エンジン1710は、該情報を用いて、データベースサービスエンティティ110のブループリント210にアクセスしてよい。該ブループリントは、データベースサービスエンティティ110がデータベースサーバエンティティ110とメトリックサーバエンティティ110とを含むことを示してよい。データベースサービスエンティティのブループリント210に基づき、直接推理エンジン1710は、データベースサーバエンティティ110のブループリント210及びメトリックサーバエンティティ110のブループリント210にアクセスしてよい。これらのブループリント210は、データベースサーバエンティティ110とメトリックサーバエンティティ110との間の関係331を示してよい。幾つかの場合には、関係331は、メトリックサーバエンティティ110が正しく動作するために、メトリックサーバエンティティ110がデータベースサーバエンティティの存在に依存することを示してよい。従って、直接推理エンジン1710は、関係に基づき、メトリックサーバエンティティ110の前にデータベースサーバエンティティ110がインスタンス化される必要があることを決定してよい。該決定に基づき、直接推理エンジン1710は、データベースサーバエンティティ110をインスタンス化するコマンドを含むコマンドセットを生成してよい。ここで、コマンドセットは、該コマンドが、メトリックサーバエンティティ110をインスタンス化する別のコマンドの前にくるように順序付けられる。
間接推理エンジン1720は、種々の実施形態では、ワークフロー1410を生成するために実行可能なソフトウェアルーチンのセットである。直接推理エンジン1710と対照的に、間接推理エンジン1720は、ワークフロー1410を生成するために、間接推理の概念を適用してよい。例えば、データベーステーブルが多くの高価なスキャンを有してよく、可能なソリューションはインデックスを生成するためであってよい。従って、間接推理エンジン1720は、(例えば、高価なスキャンを有する他のデータベーステーブルについて、インデックスが有用であることを示す情報を分析することにより)該データベーステーブルのためにインデックスが生成されるべきであると決定してよい。間接推理エンジン1720は、該データベーステーブルのインデックスを生成するためのコマンドセットを有するワークフロー1410を生成してよい。ワークフロー1410が推理エンジン450により生成された後に、ワークフロー1410は、実施のためにワークフローエンジン440に提供されてよい。幾つかの場合には、再生成される必要がなく上位目標を再び実施するためにワークフロー1410を読み出し可能なように、ワークフロー1410は(例えば、データベース130に)格納されてよい。
図18を参照すると、方法1800のフロー図が示される。方法1800は、目標コンピュータ環境(例えば、目標環境137)でワークフロー(例えば、ワークフロー1410)を生成し実施するために、オーケストレータ制御モジュール(例えば、制御モジュール120)により実行される方法の一実施形態である。方法1800は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの実施形態では、方法1800は、追加ステップを含んでよい。一例として、オーケストレータ制御モジュールは、ワークフローを再生成することなく動作シナリオが再実施できるように、生成したワークフローをデータベースに格納してよい。
方法1800は、ステップ1810で開始し、オーケストレータ制御モジュールは、目標コンピュータ環境を第1状態から第2の異なる状態へと遷移させるために動作シナリオを実施する要求(例えば、推理要求1705)を受信する。目標コンピュータ環境は、制御モジュール及び動作エンティティを含むコンポーネントセットを有してよい。種々の場合に、受信した要求は、目標コンピュータ環境を第1状態から第2状態へ遷移させるコマンドを指定しなくてよい。要求は、動作シナリオの一部として、目標コンピュータ環境内にインスタンス化されるべき第1及び第2コンポーネントを識別してよい。動作シナリオは、コンピュータシステムのユーザの代わりに、データベーストランザクションを実行する能力のあるデータベースサーバのセットを有するデータベースサービスを起動するステップを含んでよい。
ステップ1820で、オーケストレータ制御モジュールは、コンポーネントセットのうちのコンポーネントの状態の変化によることを含む、目標コンピュータ環境を第1状態から第2状態へ遷移させる特定のコマンドセットを定義するワークフローを生成する。種々の場合に、オーケストレータ制御モジュールは、コンポーネントセット、第1コンポーネント、及び第2コンポーネントに対応するブループリント(例えば、ブループリント210)にアクセスしてよい。ブループリントは、特定のコマンドセットが実施される順序に影響する、コンポーネント間の関係を定義してよい。例えば、関係は、第1コンポーネントが有効な方法で動作するために、第1コンポーネントが第2コンポーネントの存在に依存するという依存関係を含んでよい。このように、特定のコマンドセットは、第1コンポーネントをインスタンス化する第1コマンドと、第2コンポーネントをインスタンス化する第2コマンドと、を含んでよい。特定のコマンドセットは、実施の中で第2コマンドが第1コマンドに先行するように、依存関係に基づき順序付けられてよい。
ステップ1830で、オーケストレータ制御モジュールは、目標コンピュータ環境を第2状態へ遷移させるために、コンポーネントセットの中の1つ以上の制御モジュールへ命令を発行することにより、特定のコマンドセットを実施する。幾つかの場合には、特定のコマンドセットが目標コンピュータ環境を第1状態から第2状態へと遷移させるために順方向の順序で実施でき、目標コンピュータ環境を第1状態へ遷移させるために逆方向の順序で実施できるように、特定のコマンドセットが定義されてよい。特定のコマンドセットを実施する際にエラーを検出することに応答して、オーケストレータ制御モジュールは、目標コンピュータ環境を逆方向の順序に従い遷移させて第1状態に戻してよい。幾つかの場合には、コンポーネントセットのうちのコンポーネントの状態を変化させるステップは、動作エンティティを第1バージョンから第2バージョンへ更新するステップを含んでよい。
図19を参照すると、方法1900のフロー図が示される。方法1900は、目標コンピュータ環境(例えば、目標環境137)でワークフロー(例えば、ワークフロー1410)を生成し実施するために実行される方法の一実施形態である。方法1900は、非一時的コンピュータ可読媒体に格納されたプログラム命令のセットを実行することにより実行されてよい。幾つかの実施形態では、方法1900は、追加ステップを含んでよい。例えば、オーケストレータ制御モジュールは、ワークフローを再生成することなく動作シナリオが再実施できるように、生成したワークフローをデータベースに格納してよい。
方法1900は、ステップ1910で開始し、コンピュータシステムは、制御モジュール及び動作エンティティを含むコンポーネントの階層構造を実行する。階層構造は、該階層構造の最上位にある、動作シナリオのステップシーケンスに対応するコマンドセットを実行することにより動作シナリオを実施するために実行可能なオーケストレータ制御モジュールを有してよい。
ステップ1920で、目標コンピュータ環境を初期状態から終了状態へと遷移させる特定の動作シナリオを実施するための要求(例えば、推理要求1705)を受信することに応答して、オーケストレータ制御モジュールは、目標コンピュータ環境を初期状態から終了状態へと遷移させる特定のコマンドセットを定義するワークフローを生成する。種々の場合に、要求は、特定のコマンドセットを識別しなくてよい。特定の動作シナリオは、動作エンティティを生成することを含んでよい。このように、ワークフローを生成するステップは、動作エンティティのブループリント(例えば、ブループリント210)にアクセスするステップを含んでよい。幾つかの場合には、ブループリントは、動作エンティティに加えて生成されるべき第2動作エンティティを識別してよい。従って、オーケストレータ制御モジュールは、動作エンティティと第2動作エンティティとの間の関係に基づき、動作エンティティ及び第2動作エンティティを生成すべき順序を決定してよい。特定のコマンドセットは、決定された順序に基づき生成されてよい。
ステップ1930で、オーケストレータ制御モジュールは、コンポーネントの階層構造のうちのコンポーネントの状態を変化させることによることを含み、目標コンピュータ環境を終了状態へ遷移させるために、コンポーネントの階層構造の中の1つ以上の制御モジュールへ命令を発行することにより、特定のコマンドセットを実施する。
図20Aを参照すると、認証サービス140のブロック図が示される。上述のように、主体が、何らかの望ましくない目的を達成するために、システム100へ認可されていない命令を発行できないことを保証することが重要であり得る。システム100を保護するために、認証サービス140は、主体により要求されているアクションがシステム100とインタフェースするのを監査するために利用されてよい。図示の実施形態では、認証サービス140は、認証エンジン2010、認証シート2020、及びテストエンジン150を含み、監査レポート2030を含むデータベース130とインタフェースしてよい。図20Aに示すように、幾つかの実施形態では、認証サービス140は、制御モジュール120と別個の認証コンポーネントであり、制御モジュール120及び/又は動作エンティティ110へ発行されたコマンドを監査する。他の実施形態では、認証サービス140は、図と異なる方法で実装されてよい。例えば、図20Bと共に後述するように、認証サービス140は、制御モジュール120(又はオーケストレータ制御モジュール120)に統合されてよく、認証サービス140は、テストエンジン150を含まなくてよい。
認証エンジン2010は、種々の実施形態で、発行されたコマンドの監査を実行するために実行可能な命令のセットである。例えば、特定のユーザは、特定のデータベースクラスタをオンラインからオフラインへと遷移させるために、オーケストレータ制御モジュール120へコマンドを発行していてよい。オーケストレータ制御モジュール120がこのコマンドを実施し始める前に、認証エンジン2010は、特定のユーザ(又は制御モジュール120がコマンドを発行した場合には該制御モジュール120)がそのようなコマンドを発行することを認可されているか否かを確認してよい。図示の実施形態では、認証サービス140は、認証要求2005を介して、どんなコマンドが発行されたかの指示を受信する。従って、制御モジュール120が、エンティティ(例えば、ユーザ、上位制御モジュール120、等)から、1つ以上のアクションを実行するためのコマンドを受信すると、制御モジュール120は、要求2005を用いて、受信したコマンドの実行を認可し、実行されるべきアクション、コマンドの発行元、又はコマンドに関する他のコンテキスト情報のような、コマンドに関する種々の情報を識別してよい。図示の実施形態では、認証エンジン2010は、発行されたコマンドがセキュリティルールセットにより定義される許可されたアクションに従うことを検証するために、認証要求2005に含まれる情報を、認証シート2020の中で定義されるセキュリティルールセットに対して評価する。認証シート2020の一例は、図21と関連して以下に更に詳述される。
監査処理の部分として、種々の実施形態で、認証エンジン2010(又はサービス140又はシステムの他のコンポーネント)は、認証要求2005に関連付けられた種々のエンティティを認証してよく、これは要求2005を受信する前(又は後)に生じてよい。幾つかの実施形態では、これは、コマンドの最初の発行元(例えば、ユーザ又は制御モジュール120)を認証するステップを含む。従って、ユーザが発行元である場合、ユーザ名及びパスワードを依頼する認証プロンプトが、彼又は彼女のアイデンティティを確認するために、ユーザに提示されてよい。幾つかの実施形態では、これは、認証要求2005を生成している制御モジュール120を認証することを含む。幾つかの実施形態では、この認証を実施するために、動作エンティティ110、制御モジュール120、及び/又は認証サービス140は、コンポーネント110、120、及び140により維持されることによる公開鍵ペアの証明を提供されてよい。コンポーネント110、120、及び140は、次に、互いに相互認証するためにこれらの証明を交換し、セキュアな通信リンクを確立してよい。例えば、制御モジュール120及び認証サービス140は、相互認証のために楕円曲線Diffie-Hellman(Elliptic-curve Diffie-Hellman (ECDH))交換で証明を交換し、トランスポート層セキュリティ(Transport Layer Security (TLS))セッションの共有シークレットを確立してよい。該TLSセッションを通じて、認証要求2005及び認証応答2015がセキュアに交換されてよい。
種々の実施形態で、認証エンジン2010により実行される監査は、データベース130に監査レポート2030のログを維持するステップも含む。従って、認証要求2005が受信されると、認証エンジン2010は、監査レポート2030内の要求2005に関する種々の情報を記録してよい。この情報は、ユーザ名又はコンポーネント名(例えば、オーケストレータ制御モジュール120の識別子の値)のような、誰がコマンドを発行したか、及び制御モジュール120又は動作エンティティ110の名称又はUUIDのようなコマンドの目標は何か、を含んでよい。この情報は、どんなアクションがコマンドにより指示されているかを含んでよい。この情報は、コマンドが発行されたときを含んでよい。この情報は、IPアドレス、UDP又はTCPポート番号、等のような、コマンド発生源の指示を含んでよい。認証エンジン2010は、所与の要求2005が許可されたか又は拒否されたか、及びこのようなイベントで拒否された理由のような、対応する認証応答2015に関する情報を記録してもよい。幾つかの実施形態では、データベース130は、監査レポート2030への認証サービス140のアクセスを制限してよい。その結果、サービス140は、監査レポート2030を書き込むことを許可されるが、任意のレポート2030を削除することを許可されない。従って、監査レポート2030は、認証サービス140が損なわれ又はサービス140の認証されたマネジャが彼又は彼女のアクセス権を悪用しようと試みた場合でも、維持されてよい。
所与の要求2005についての認証シート2020の評価に基づき、認証エンジン2010は、受信したコマンドが認可されたか否かを示す対応する応答2015を発行してよい。図22に関して後述するように、幾つかの実施形態では、認証エンジン2010は、自身の認証応答2015に署名済みトークンを含んでよい。これは、後続のコンポーネント(例えば、制御モジュール120及び/又は動作エンティティ110)により、サービス140により認可された発行されたコマンドの中で識別された1つ以上のアクションを実行することを確認するために、使用可能である。そうする際に、初期制御モジュール120(例えば、オーケストレータ制御モジュール120)は、トークンを取得するために認証サービス140との相互作用を処理してよく、次に、アクションを実行する1つ以上の他のコンポーネントに及びアクションの認可が許可されたことを検証する者に、トークンを渡すことができ、同じ認可されたアクションについて認証サービス140に再度連絡を取る必要がない。
図20Bを参照すると、認証サービス140の別のブロック図が示される。上述の図20Aに示した図示の実施形態では、認証サービス140のコンポーネントは、制御モジュール120及び/又は動作エンティティ110とは別個である。幾つかの実施形態では、しかしながら、認証サービス140のコンポーネントは、コンポーネント120及び/又は110の間で分散されてよい。例えば、図20Bに示すように、認証エンジン2010のインスタンスは、制御モジュール120により受信されたコマンドが認証シート2020内のルールにより定義された許容アクションに従うことを検証するために、制御モジュール120に含まれてよい。図示の実施形態では、認証サービス140は、認証シート2020Aのマスタコピーを維持する分配部2040も含み、自身のローカルで実行される評価を実現するために、認証シート2020Bのコピーを認証エンジン2010の各インスタンスに分配する。幾つかの実施形態では、認証シート2020Bのローカルコピーは、認証シート2020Aに含まれる各ルールの完全なコピーではなく、該エンジン2010に適用可能なルールだけを含んでよい。種々の実施形態で、分配部2040は、また、認証シート2020Bの各コピーに、その完全性を保護するために署名する。幾つかの実施形態では、認証サービス140は、図と異なる方法で実装されてよい。例えば、認証エンジン2010の各インスタンスは、中央エンティティからシート2020のコピーを受信するのではなく、自身のシート2020を維持する責任があってよく、認証エンジン2010のインスタンスは、動作エンティティ110内に位置してもよい、等である。
図21を参照すると、認証シート2020のブロック図が示される。図示のように、認証シート2020は、上述のように認証要求2005を許可するか否かを決定するとき認証エンジン2010により評価され得るルール2100のリストを含んでよい。図示の実施形態では、ルール2100は、許可2102、主体2104、アクション2106、及び他のパラメータ2108を含む。他の実施形態では、ルール2100は、発行されたコマンドを評価するための他の適切な基準を含んでよい。
許可2102は、種々の実施形態で、所与のルール2100が権利を許可するか又は権利を制限するかを定義する。例えば、ルール2100Aの許可は、主体2104Johnに関して制限的であり、ルール2100Bの許可は、主体2104Janに関して許容的であることを示す。
主体2104は、種々の実施形態で、所与のルール2100に関して、発行元/要求元(つまり、評価中のコマンドを発行しているもの)を識別する。例えば、ルール2100B及び2100Cの主体2104は、両方のルール2100が要求元Janに関連することを示す。従って、要求2005が、階層構造の中のコンポーネントのうちの1つへ発行されるべき所与のコマンドについて受信されると、認証エンジン2010は、コマンドの要求元が主体2104により識別される認可された要求元であるか否かを検証してよい。図21に示した例はユーザ名であるが、IPアドレス、UUID、等のような他の形式の識別が使用されてよい。
アクション2106は、種々の実施形態で、所与のルール2100に関して容認できる又は容認できないアクションを識別する。例えば、ルール2100B及び2100Cのアクションは、主体Janがアクション「生成(create)」及び「遷移(transition)」を要求することを許可されていることを示す。ルール2100Aの場合には、主体2014Johnに関して全てのアクションを拒否するために、アスタリスク(*)が使用される。従って、所与のコマンドについて要求2005が受信されると、認証エンジン2010は、要素2012及び2104を検証することに加えて、コマンドにより実行されるべきアクションが認可されたアクション2106のうちの1つであるか否かも検証してよい。
パラメータ2108は、種々の実施形態で、所与のアクション2106に関連付けられた種々の追加基準を含む。例えば、ルール2100Bは、「Jan」についてアクション「生成(create)」がデータベースのインスタンスに対して制限されることを示すために、「DB」及び「インスタンス(instance)」のパラメータを指定する。パラメータ2108の他の例は、時間制限(例えば、アクションが要求できる(又はできない)とき)、目標制限(例えば、アクションが実行されてよい(又は実行されてはならない)目標について特定のUUIDを識別する)、IPアドレス制限、等を含んでよい。
種々の実施形態で、認証サービス140は、セキュリティチームがルール2100のうちの種々のルールを設定できるように、コマンドラインインタフェース又はグラフィカルユーザインタフェースであってよいユーザインタフェースを提供する。幾つかの実施形態では、セキュリティチームは、システムを管理する可能性のあるユーザと異なる。ルール2100は、それらが改ざんされていないことを保証するために、定期的に、署名され、ダウンロードされ、検証されてもよい。
図22を参照すると、トークン2200を用いる交換のブロック図が示される。上述のように、幾つかの実施形態では、認証サービス140は、トークン2200を発行してよい。トークン2200は、受信したコマンドに関連付けられたアクションのセットが認証サービス140により既に認可されていることを確認するために、制御モジュール120及び/又は動作エンティティ110により使用可能である。例えば、第1制御モジュール120Aは、データベースの複数のインスタンスを生成するための第1の発行されたコマンド2210Aを受信し、このコマンド2210Aを実施するために、第2コマンド2210Bをデータベースインスタンスのうちのそれぞれ1つの生成を扱う各制御モジュール120(又は動作エンティティ110)へ発行することを意図してよい。図示の実施形態では、制御モジュール120Aは、受信した第1コマンド2210Aに対応する認証要求2005を発行できる。要求2005を認可することに応答して、認証サービス140は、データベースインスタンスを生成するために必要な種々のアクションが認可されていることを示すトークン2200を含む認証応答2015を返送してよい。制御モジュール120Aは、次に、後続の制御モジュール120及び/又は動作エンティティ110へ発行されるコマンド2210Bの第2セットに、トークン2200を含めることができる。後続の制御モジュール120及び/又は動作エンティティ110は、トークン2200から、どんなアクションが既に認可されているかを決定し、それらを実行し始めることができ、それらのアクションを実行するための許可を得るために認証サービス140に再度連絡する必要がない。
トークン2200は、コマンド2210の実行が認証サービス140により承認されていることの確認を実現するための任意の適切なコンテンツを含んでよい。図示の実施形態では、トークン2200は、アクセス権2202、タイムスタンプ2204、及び署名2206を含む。他の実施形態では、トークン2200は、図示のものより多くの(又は少ない)コンポーネントを含んでよい。幾つかの実施形態では、トークン2200は、JSONウェブトークン(JSON web token (JWS))、Kerberosトークン、X.509証明書、又は署名付きアテステーションのための何らかの他の標準的形式として実装されてよい。
アクセス権2202は、種々の実施形態で、認証サービス140により実行について認可されている特定のアクションのセットを示し、通常、上述のルール2100からの種々の要素を含んでよい。従って、所与の権利2202は、所与のアクション2106を識別するだけでなく、該アクション2106のためのコマンドを発行することを許可された特定の主体2104も示してよい。従って、制御モジュール120Aから特定のアクションを実行するためのコマンド2210Bを受信することに応答して、制御モジュール120Bは、制御モジュール120Aがアクセス権2202の中で該特定のアクションを要求することを許可されているとして識別されることを検証してよい。幾つかの実施形態では、アクセス権2202は、特定のアクションを実行することを認可された目標も識別してよく、これはIPアドレス、UUID、等を用いて識別されてよい。従って、トークン2200を受信する制御モジュール120Bは、トークン2200の中で、自身がコマンド2210Bの中で識別された特定のアクションを実行するために認可された目標として識別されることを確認してよい。
タイムスタンプ2204及び署名2206は、種々の実施形態で、制御モジュール120又は動作エンティティ110のような後続の受信者によりトークン2200についての検証を実現するために含まれる。通常、タイムスタンプ2204は、発行されたトークン2200がどれくらい長い間、有効であるかの何らかの制限であってよい。従って、一実施形態では、タイムスタンプ2204は、トークン2200が発行されたときを示す時間値であってよく、コンポーネント120及び110は、タイムスタンプ2204後の何らかのウインドウの範囲内でのみトークン2200を受け付けるよう動作してよい。別の実施形態では、タイムスタンプ2204は、アクセス権により認可されたアクションが実行されなければならないウインドウを示す開始時間及び停止時間であってよい。更に別の実施形態では、タイムスタンプ2204は、トークンがもはや有効ではなくなる満了時間値を示してよい。署名2206は、通常、トークン2200の完全性が保護されることを、又は異なる方法では、該トークン2200が改ざんされていないことを、保証するために使用されてよい。従って、幾つかの実施形態では、署名2206は、コンポーネント120及び110に知られている対応する信頼される公開鍵を有する、認証サービス140により維持される秘密鍵によりトークン2200のコンテンツから生成される。トークン2200を受信することに応答して、コンポーネント110又は120は、発行されたコマンド2210Bの中で識別された任意のアクションを実行する前に、公開鍵を用いて、トークン2200のコンテンツに対して署名2206を検証してよい。
図23を参照すると、方法2300のフロー図が示される。方法2300は、認証サービス140のような目標コンピュータ環境に関連付けられた認証サービスを有するコンピュータシステムにより実行される方法の一実施形態である。種々の実施形態で、方法2300の実行は、目標コンピュータ環境のセキュリティを向上し得る。
方法2300は、ステップ2310で開始し、コンピュータシステムは、目標コンピュータ環境内で動作シナリオを実施するコンポーネント(例えば、動作エンティティ110、制御モジュール120、等)の階層構造の中で許容可能なアクションを定義するセキュリティルールセット(例えば、認証シート2020に含まれるルール2100)を格納する。ステップ2320で、コンピュータシステムは、目標コンピュータ環境内で動作シナリオを実施し、該実施は、階層構造の中のコンポーネントへコマンドセットを発行するステップと、コマンドセットがセキュリティルールセットにより定義された許容可能なアクションに従うことを検証するステップと、を含む。
種々の実施形態で、コマンドセットを発行するステップは、階層構造のうちの第1コンポーネントが、検証を実行している認証サービス(例えば、認証サービス140)へ、特定の発行されたコマンドについての認証要求(例えば、認証要求2005)を送信するステップと、認証サービスが特定のコマンドがセキュリティルールセットにより定義された許容可能なアクションに従うと決定することに応答して、第1コンポーネントが、コマンドの実行を認可する応答(例えば、認証応答2015)を受信するステップと、を含む。認証応答に基づき、第1コンポーネントは、発行されたコマンドの中で識別された1つ以上のアクションを実行する。幾つかの実施形態では、検証するステップは、認証応答を送信するステップの前に、認証要求の送信元を認証するステップを含む。幾つかの実施形態では、検証するステップは、認証サービスが、ログに、認証要求の受信を識別するレポート(例えば、データベース130内の監査レポート2030)を格納するステップを含む。幾つかの実施形態では、受信した認証応答は、階層構造の中の第2コンポーネントが特定のアクションの実行を認可されたことを示すトークン(例えば、トークン2200)を含み、1つ以上のアクションを実行するステップは、第1コンポーネントが、第2コンポーネントへ、トークンを含むコマンド(例えば、第2の発行されたコマンド2210B)を発行するステップを含む。トークンは、特定のアクションの実行が認可されていることを確認するために第2コンポーネントにより検証される。幾つかの実施形態では、トークンは、(例えば、アクセス権2202の中の)特定のアクション、第1コンポーネント、及び認証サービスの署名(例えば、署名2206)を識別する。
種々の実施形態で、ルールセットは、認可された要求元(例えば、主体2104)及び認可された要求元に関連付けられた1つ以上の認可されたアクション(例えば、アクション2106)を識別するルールを含む。検証するステップは、階層構造の中のコンポーネントのうちの1つへ発行されるべきコマンドの指示を受信するステップと、コマンドの要求元が認可された要求元に対応することを検証するステップと、コマンドにより実行されるべきアクションが認可されたアクションのうちの1つであるか否かを検証するステップと、を含む。
種々の実施形態で、方法2300は、階層構造の中の第1コンポーネントが、階層構造の中の第2コンポーネントへコマンドを発行するための要求を受信するステップを更に含み、検証するステップは、第1コンポーネントがコマンドを第2コンポーネントに発行する前に、第1コンポーネントが、要求されたコマンドがセキュリティルールセットにより定義された許容可能なアクションに従うことを(例えば、認証シート2020Bを用いて)検証するステップを含む。幾つかの実施形態では、第2コンポーネントは、発行されたコマンドを実行するよう動作する動作エンティティ(例えば、動作エンティティ110)である。幾つかの実施形態では、第2コンポーネントは、1つ以上の動作エンティティに発行されたコマンドを実行させるよう動作する制御モジュール(制御モジュール120)である。
図24を参照すると、テストエンジン150のブロック図が示される。上述のように、適切なテストを実行するステップは、システムが信頼できる方法で動作することを保証するために重要であり得る。多くの例では、しかしながら、ステムがその寿命の間に経験し得る全ての可能な状態をテストすることは、特にこのようなテストが手動で実行されるとき、困難であり得る。後述するように、種々の実施形態で、テストエンジン150は、システム100が正しく機能しない状態を識別するために、種々の障害条件の注入を通じて、システム100のテストを自動化するために利用される。図示の実施形態では、テストエンジン150は、スキャンエンジン2410、スキャン前グラフ2420、スキャン後グラフ2430、及び混乱エンジン2440を含む。他の実施形態では、テストエンジン150は、図と異なる方法で実装されてよい。
スキャンエンジン2410は、種々の実施形態で、テストエンジン150の動作を実現するために、制御モジュール120及び動作エンティティ110に関する情報の集合を処理する。幾つかの実施形態では、この集合は、スキャンエンジン2410がシステム100内の種々の制御モジュール120及び動作エンティティ110について知ることを試みる発見動作の実行により開始する。従って、スキャンエンジン2410は、最初に、オーケストレータ制御モジュール120にそれ自体を記述し及び他の制御モジュール120と区別するよう依頼する要求2412を送信してよく、オーケストレータ制御モジュール120と直接(又は幾つかの実施形態では間接的に)相互作用する。幾つかの実施形態では、オーケストレータ制御モジュール120は、システム100の制御モジュール120及び動作エンティティ110を識別する、並びにそれらの構成を記述する、グラフデータ構造を含む応答2414を送信してよい。この受信した情報に基づき、スキャンエンジン2410は、次に、記述応答2412を、新たに発見された制御モジュール120及び動作エンティティ110へ送信してよい。これらのコンポーネントは、種々の適切な情報のうちのいずれかを含み得る対応する記述応答2414を送信してよい。例えば、所与の制御モジュール120又は動作エンティティ110は、それ自体の一般的記述を含んでよく、システム内でのそれ自体の役割を識別することを含んでよく、それ自体のユニバーサルにユニークな識別子(universally unique identifier (UUID))、ベンダ、バージョン、他の制御モジュール120及び/又は動作エンティティ110に対する関係、属性、構成変数、等のような情報を含む。幾つかの実施形態では、所与の制御モジュール120は、それ自体によりサポートされる種々のアプリケーションプログラミングインタフェース(API)機能を、応答2414の中で識別してもよい。例えば、制御モジュール120は、構成情報、ログ、メトリック、ファクト、等をフェッチするような、被制御動作エンティティ110に関する情報を読み出すために、スキャンエンジン2410からのAPI呼び出しをサポートしてよい。種々の実施形態で、制御モジュール120は、それらの応答2414の中で、どんな注入可能な障害条件がサポートされるか、及びテストエンジン150により要求可能か、を識別してもよい。例えば、複数のデータベース動作エンティティ110を制御する制御モジュール120は、自身がデータベースインスタンスの強制終了(又はデータベースインスタンスを含むコンテナの強制終了)、データベースインスタンスの実行停止、データベースインスタンスのスタービング(starving)等をサポートすることをアドバタイズしてよい。
種々の実施形態で、スキャンエンジン2410は、また、障害条件の注入前のシステム100の状態及び障害条件の注入後のシステム100の状態に関する種々の状態情報を収集する。従って、スキャンエンジン2410は、上述のように要求2412の発行及び応答2414の受信を通じて、この情報を収集してよい。幾つかの実施形態では、制御モジュール120は、スキャンエンジン2410へリアルタイムテレメトリデータを提供してもよい。例えば、データベースインスタンスを維持している制御モジュール120は、いくつのデータベースインスタンスが現在動作中かを示し、及びその数が変化するとスキャンエンジン2410に通知してよい。上述のように、幾つかの実施形態では、スキャンエンジン2410は、テストエンジン150の認証サービス140への統合を通じて、情報を受信してよい。例えば、制御モジュール120が別のデータベースインスタンスを提供するためのコマンドを発行していた場合、制御モジュール120がコマンドを実施するための許可を依頼するために認証要求2005を認証サービス140に送信するとき、スキャンエンジン2410は、この発行されたコマンドを知ることができる。図示の実施形態では、障害条件注入の前の状態について収集されたメタデータは、スキャン前グラフ2420へと組み立てられてよく、障害条件注入の後の状態について収集されたメタデータは、スキャン後グラフ2430へと組み立てられてよい後述するように、スキャンエンジン2410(又は他の実施形態では、テストエンジン150の何らかの他のコンポーネント)は、注入された障害条件がシステム100にどのように影響するかについての洞察を集めるために、これらのグラフ2420及び2430を比較してよい。幾つかの実施形態では、このメタデータの編成、及びグラフ2420及び2430の後の比較を実現するために、スキャンエンジン2410は、グラフ2420及び2430をそれぞれのグラフデータ構造として組み立てる。従って、スキャン前グラフ2420の中の各ノードは、システム100内のそれぞれの制御モジュール120又は動作エンティティ110に対応してよく、注入前の該モジュール120又はエンティティ110の状態に関して収集された種々のメタデータを含んでよい。ノード間の辺(edge)は、制御モジュール120と動作エンティティ110との間に存在する関係に対応してよい。スキャン後グラフ2430の中の各ノードは、同様に編成され、障害条件の注入後の所与の制御モジュール120又は動作エンティティ110の状態に関するメタデータを含んでよい。スキャンエンジン2410は、スキャン前グラフ2420とスキャン後グラフ2430との間でどのノードが変更されたかを識別し、次に変更されたノードのコンテンツを調べて、注入された障害条件から生じた特定の詳細事項を決定することにより、所与の注入された障害条件がシステム100にどのように影響を与えたかを決定してよい。
混乱エンジン2440は、種々の実施形態では、注入するための障害条件を選択すること、及びそれらの注入を生じさせるために、適切な制御モジュールに混乱命令2418を送信することを担う。これらの障害条件は、システム100に障害を経験させ得る任意の適切な条件に対応してよい。例えば、幾つかの実施形態では、混乱エンジン2440は、動作エンティティ110を強制終了し、一時停止し、停止し、ハングし、又は終了する混乱命令2418を発行して、システム100に与えられるその効果を調べてよい。幾つかの実施形態では、混乱エンジン2440は動作エンティティ110に利用可能なリソースを変更する混乱命令2418を発行して、動作エンティティ110をスタービング又は過負荷にしてよい。例えば、混乱エンジン2440は、動作エンティティ110に利用可能な処理リソースを変更して、動作エンティティ110が、低い実行優先度を割り当てられ、実行のために少ない頻度をスケジューリングされ、実行のために少ないプロセッサを割り当てられるようにしてよい。混乱エンジン2440は、動作エンティティ110に少ない揮発性又は不揮発性ストレージを割り当てる、メモリにページをスワッピングして出す、等により、動作エンティティ110に利用可能なメモリリソースを変更してよい。混乱エンジン2440は、動作エンティティ110との通信のために利用可能なネットワーク帯域を削減する、動作エンティティ110との通信の待ち時間を増大する、動作エンティティ110との通信をドロップする、動作エンティティ110のネットワーク接続を切断する、等により、動作エンティティ110に利用可能なネットワークリソースを変更してよい。種々の実施形態で、混乱エンジン2440は、システム100内の動作エンティティ110の相互依存性を妨害するために障害条件を注入してよい。例えば、アプリケーションサーバ(第1動作エンティティ110)は、データベースサーバ(第2動作エンティティ110)に格納されたデータに依存してよい。アプリケーションサーバの回復力をテストするために、混乱エンジン2440は、データベース内のデータを壊して(単に、データベースをクラッシュして)、アプリケーションサーバ上の影響を決定してよい。別の例として、2つ以上の動作エンティティ110は、特定の目的を達成するためにロックステップで(in lockstep)一緒に動作してよく、混乱エンジン2440は、デッドロックの達成に成功するか否かを決定するために、エンティティ110のうちの1つの動作を停止することを試みてよい。更に別の例として、動作エンティティ110は、構成ファイルに格納された構成データに依存してよく、混乱エンジン2440は、その動作を妨害するために該データを変更し(又は壊して)よい。混乱エンジン2440は、電源障害を生じる、ブレードサーバを切断する、ネットワークスイッチ障害を生じる、等のような他の現実世界の障害条件を注入してもよい。上述のように、これらの障害条件は、(システムの何らかの理論モデルで動作することと対照的に)実際のシステムが実行している間/ライブである間に、該システムに注入されてよい。
混乱エンジン2440は、どんな障害条件が注入されるべきかを決定するために、任意の適切な選択アルゴリズムを利用してよい。幾つかの実施形態では、混乱エンジン2440は、障害条件をランダムに選択し、対応する命令2418を該障害条件を注入させるために発行してよい。種々の実施形態で、混乱エンジン2440は、システム100の特定の態様、例えば、特定の動作エンティティ110又はエンティティ110のグループを目標とするよう指示されて、該態様に関連付けられた障害条件を選択してよい。種々の実施形態で、混乱エンジン2440は、制御モジュール120及び/又は動作エンティティ110へ発行されているコマンドを監視し、発行されたコマンドに基づき注入するための障害条件を選択する。例えば、テストエンジン150は、システム100に関して実行されている更新処理を目標とするよう指示されてよい。制御モジュール120が、更新処理に関して特定のコマンドがそれに対して発行されたことの指示2416を提供することに応答して、混乱エンジン2440は、更新処理を妨害するよう企てるために、対応する障害条件を選択し、適切な混乱指示2418を発行してよい。選択された障害条件は、例えば、更新処理中に更新されている動作エンティティ110の実行を終了すること、例えば、更新を行っているデータベースインスタンスを含むコンテナをクラッシュすることを含んでよい。選択された障害条件は、別の例として、更新に関連する障害を生じさせる試みの中で、更新処理中に更新されている動作エンティティ110との通信のネットワーク遅延を増大することを含んでよい。幾つかの実施形態では、混乱エンジン2440は、前に注入した障害条件を識別する過去の情報を維持し、選択のために検討されている障害条件のセット毎に、履歴情報から決定されたとき前に注入されたものと比べてその障害条件がどれ位困難かを示すそれぞれのエントロピースコアを決定してよい。混乱エンジン2440は、次に、前に選択されたものと最も異なる(又は少なくとも十分異なる)ことを示すエントロピースコアを有する障害条件を選択してよい。幾つかの実施形態では、混乱エンジン2440は、システム100内に障害を生じた前に注入された障害条件を識別する履歴情報を維持してよく、これらの条件について修正するための試みが行われた後に、それらの修正が成功したか否かを決定するために、これらの障害条件を再選択してよい。
上述のように、スキャンエンジン2410(又は他のコンポーネント)は、システム100についてより良好な洞察を集めるために、スキャン前グラフ2420及びスキャン後グラフ2430からのメタデータを比較してよい。幾つかの例では、この比較は、特定の注入された障害条件により何な影響を受け得るかを決定するために実行されてよい。このような決定は、スキャンエンジン2410が、どの動作エンティティ110が注入された障害条件により直接影響されるかを識別すること、及びエンティティ110間の予期しない関係に起因して、どの動作エンティティ110が注入された障害条件により間接的に影響されるかを識別すること、を含んでよい。例えば、ある動作エンティティ110をクラッシュさせるために混乱命令2418を発行することは、別の動作エンティティ110がクラッシュすることを明らかにし得る。従って、何らかの知覚されていない依存関係が存在し得る。このような決定は、動作エンティティ110が注入された障害条件により影響されないこと(又は少なくとも障害を経験している時点で影響されないこと)を確立するために使用されてもよい。例えば、スキャンエンジン2410は、ネットワーク接続の帯域幅を特定量だけ減少することが、ネットワーク接続を使用する動作エンティティ110の障害を生じないことを決定してよい。幾つかの例では、この比較は、障害条件に対するシステム100の回復力を決定するために実行されてよい。例えば、制御モジュール120は、動作エンティティ110の特定数のインスタンスを維持するよう指示されてよい。混乱エンジン2440は、次に、制御モジュール120が強制終了に応答して動作エンティティ110の別のインスタンスをインスタンス化するか否かを決定するために、動作エンティティ110のインスタンスのうちの1つを強制終了する混乱命令2418を発行してよい。この例では、成功した結果は、スキャン前グラフ2420及びスキャン後グラフ2430の場合に相違が識別されないことであってよい。これは、制御モジュール120が、前の強制終了されたインスタンスを置き換えるために、動作エンティティ110の新しいインスタンスをインスタンス化することに成功できた後に、システム100が回復できたことを意味する。
多くの例では、テストエンジン150をこのように用いて、システム100をより良く理解するために、システム100が完全にテストされることを可能にし得る。テストエンジン150から取得された知識により、管理者は、潜在的な脆弱点を良好に識別し、それらを解決するために適正な措置を取ることができてよい。管理者は、良好にテストされたシステムは悪条件が生じたときに設計通りに動作できることをより自信を持って知ることもできる。更に、テストエンジン150は、システム100内に展開された(独立した種類の)任意のコンポーネントの障害時動作を自動的且つ完全に探索し得る。
図25を参照すると、方法2500のフロー図が示される。方法2500は、テストエンジン150を含むコンピュータシステムのような目標コンピュータ環境をテストするコンピュータシステムにより実行される方法の一実施形態である。多くの例では、方法2500の実行は、修正されると目標コンピュータ環境の回復力を向上する問題を識別するために使用できてよい。
方法2500は、ステップ2510で開始し、コンピュータシステムは、制御モジュール(例えば、制御モジュール120)及び動作エンティティ(例えば、動作エンティティ110)を含むコンポーネントの階層構造を有する目標コンピュータ環境内で動作シナリオを実施する。種々の実施形態で、実施するステップは、目標コンピュータ環境内のコンポーネントに、コマンドセットを発行するステップを含む。ステップ2520で、コンピュータシステムは、コマンドセットのうちの特定のコマンドが発行されたことの指示(例えば、コマンド指示2416)を受信する。ステップ2530で、指示を受信することに応答して、コンピュータシステムは、目標コンピュータ環境をテストするために、動作エンティティのうちの1つに関する障害条件を注入するよう、(例えば、混乱命令2418を介して)制御モジュールに指示する。
種々の実施形態で、方法2500は、コンピュータシステムが、障害条件の注入前の目標コンピュータ環境の第1状態に関するメタデータ(例えば、スキャン前グラフ2420)を収集するステップと、障害条件の注入後の目標コンピュータ環境の第2状態に関するメタデータ(例えば、スキャン後グラフ2430)を収集するステップと、第1状態に関するメタデータと第2状態に関するメタデータとを比較して、障害条件の効果を決定するステップと、を更に含む。幾つかの実施形態では、コンピュータシステムは、第1グラフデータ構造を、第1状態に関する収集したメタデータから組み立て、第2グラフデータ構造を、第2状態に関する収集したメタデータから組み立て、第1グラフデータ構造と第2グラフデータ構造とを比較する。幾つかの実施形態では、コンピュータシステムは、受信した指示に基づき、特定のコマンドが、階層構造の中のコンポーネントのうちの1つ以上を更新する更新処理に関連付けられることを決定し、更新処理を妨害することを試みるために障害条件を選択する。このような一実施形態では、選択された障害条件は、更新処理中に更新されている動作エンティティの実行を終了することを含む。このような一実施形態では、選択された障害条件は、更新処理中に更新されている動作エンティティとの通信の遅延を増大することを含む。
種々の実施形態で、方法2500は、コンピュータシステムが、制御モジュールによりサポートされる注入可能な障害条件のセットを識別するために(例えば、要求2412及び応答2414により)発見動作を実行するステップと、特定の発行されたコマンドに基づき、指示された制御モジュールによる注入のために注入可能な障害条件のセットのうちの注入可能な障害条件を選択するステップと、を更に含む。幾つかの実施形態では、発見動作は、コンピュータシステムが、制御モジュールのうちの1つ以上のアイデンティティを決定するために、階層構造のうちのオーケストレータ(例えば、オーケストレータ制御モジュール120)に連絡するステップを含み、オーケストレータは、他の制御モジュールにコマンドを発行する制御モジュールである。幾つかの実施形態では、発見動作は、コンピュータシステムが、決定されたアイデンティティに基づき、1つ以上の制御モジュールによりサポートされる注入可能な障害条件を識別するよう、1つ以上の制御モジュールに依頼する要求を、1つ以上の制御モジュールへ送信するステップを含む。幾つかの実施形態では、コンピュータシステムは、前に注入された障害条件を識別する履歴情報を維持し、該履歴情報に基づき、注入可能な障害条件のセットのうちの障害条件毎にそれぞれ差異スコアを決定する。それぞれの差異スコアは、前に注入された障害条件に対する当該障害条件の相違を示す。このような一実施形態では、注入のために障害条件を選択するステップは、決定された差異スコアに更に基づく。
<例示的なコンピュータシステム>
図26を参照すると、例示的なコンピュータシステム2600のブロック図が示され、システム100、動作エンティティ110、制御モジュール120、データベース130、及び/又は認証サービス140を実装してよい。コンピュータシステム2600は、相互接続2660(例えば、システムバス)を介してシステムメモリ2620及びI/Oインタフェース2640に結合されるプロセッササブシステム2680を含む。I/Oインタフェース2640は、1つ以上の装置2650に結合される。コンピュータシステム2600は、限定ではないが、サーバシステム、パーソナルコンピュータシステム、デスクトップコンピュータ、ラップトップ又はノードブックコンピュータ、メインフレームコンピュータシステム、タブレットコンピュータ、ハンドヘルドコンピュータ、ワークステーション、ネットワークコンピュータ、携帯電話機、音楽プレイヤ又はPDA(personal data assistant)のような消費者装置を含む、種々の種類の装置のうちのいずれであってもよい。便宜上単一のコンピュータシステム2600が図26に示されるが、システム2600は、一緒に動作する2つ以上のコンピュータシステムとして実装されてもよい。
プロセッササブシステム2680は、1つ以上のプロセッサ又は処理ユニットを含んでよい。コンピュータシステム2600の種々の実施形態では、プロセッササブシステム2680の複数のインスタンスが相互接続2660に結合されてよい。種々の実施形態では、プロセッササブシステム2680(又は2680内の各処理ユニット)は、キャッシュ又は他の形式のオンボードメモリを含んでよい。
システムメモリ2620は、プロセッササブシステム2680により実行可能なプログラム命令を格納し、システム2600に本願明細書に記載の種々の動作を実行させるために使用可能である。システムメモリ2620は、異なる物理メモリ媒体、例えばハードディスク記憶装置、フロッピーディスク記憶装置、取り外し可能ディスク記憶装置、フラッシュメモリ、ランダムアクセスメモリ(RAM、SRAM、EDO RAM、SDRAM、DDR、SDRAM、RAMBUS RAM、等)、読み出し専用メモリ(PROM、EEPROM、等)、等を用いて実装されてよい。コンピュータシステム2600内のメモリは、メモリ2620のような主記憶装置に限定されない。むしろ、コンピュータシステム2600は、プロセッササブシステム2680内のキャッシュメモリ及びI/O装置2650上の2次記憶(例えば、ハードドライブ、ストレージアレイ、等)のような他の形式の記憶装置を含んでもよい。幾つかの実施形態では、これらの他の形式の記憶装置は、プロセッササブシステム2680により実行可能なプログラム命令を格納してもよい。幾つかの実施形態では、実行されると、動作エンティティ110、制御モジュール120、データベース130、認証サービス140、及び/又はテストエンジン150を実装するプログラム命令は、システムメモリ2620内に含まれ/格納されてよい。
I/Oインタフェース2640は、種々の実施形態に従い他の装置と結合され通信するよう構成される種々の種類のインタフェースのうちのいずれであってもよい。一実施形態でっは、I/Oインタフェース2640は、フロントサイドから1つ以上のバックサイドバスへのブリッジチップ(例えば、Southbrigdge)である。I/Oインタフェース2640は、1つ以上の対応するバス又は他のインタフェースを介して1つ以上のI/O装置2650に結合されてよい。I/O装置2650の例は、記憶装置(ハードドライブ、光ドライブ、取り外し可能フラッシュドライブ、記憶アレイ、SAN、又はそれらの関連する制御部)、(例えば、ローカル又はワイドエリアネットワークへの)ネットワークインタフェース装置、又は他の装置(例えば、グラフィック、ユーザインタフェース装置、等)を含む。一実施形態では、コンピュータシステム2600は、(例えば、WiFi、Bluetooth、Ethernet、等を介して通信するよう構成される)ネットワークインタフェース2650を介してネットワークに結合される。
本願の主題の実現は、限定ではなく以下の例1~20を含む。
(例1)目標コンピュータ環境の動作シナリオを管理する方法であって、前記方法は、
コンピュータシステムにより、前記動作シナリオのためのコマンドセットを定義する動作情報にアクセスするステップと、
前記コンピュータシステムにより、前記動作シナリオを実施する前記目標コンピュータ環境の中で利用されるべき動作エンティティセットのブループリントにアクセスするステップであって、前記動作エンティティセットは、ハードウェアエンティティ、ソフトウェアエンティティ、及び情報エンティティを含む、ステップと、
前記コンピュータシステムにより、前記目標コンピュータ環境のための前記動作シナリオを実施するステップと、
を含み、前記実施するステップは、
制御モジュールの階層構造を実行するステップを含み、前記階層構造は、該階層構造の最上位にあり、該階層構造の次のレベルにある制御モジュールに命令を発行することにより前記コマンドセットを実行するために実行可能なオーケストレータ制御モジュールを含み、前記制御モジュールの階層構造は、前記動作エンティティセットのうちの1つ以上の動作エンティティの状態を変化させることによることを含む前記動作シナリオを達成するためにそれぞれのブループリントに従い前記動作エンティティセットを管理するために実行可能な制御モジュールを含む、方法。
(例2)所与の動作エンティティは、該所与の動作エンティティを識別するユニークな識別子に関連付けられ、前記命令のうちの特定の命令は、前記所与の動作エンティティに関連付けられ、前記特定の命令を発行するステプは、
前記ユニークな識別子に基づき、前記所与の動作エンティティを管理する前記制御モジュールのうちの特定の1つを決定するステップと、
前記特定の命令を前記特定の制御モジュールに発行するステップと、
を含む、例1に記載の方法。
(例3)所与のブループリントは,前記動作エンティティセットのうちの対応する第1動作エンティティについて、前記第1動作エンティティと前記動作エンティティセットのうちの1つ以上の他の動作エンティティとの間の関係セットを示し、前記関係セットは、前記コマンドセットのうちのコマンドセットが実行できる順序に影響する、例1又は2に記載の方法。
(例4)前記関係セットは、前記動作エンティティセットのうちの前記第1動作エンティティと第2動作エンティティとの間の関係を含み、前記第1動作エンティティの状態を変化させるために前記命令のうちの特定の命令を実行するステップは、前記第1動作エンティティの前記状態を変化させる前に、前記第2動作エンティティの状態を変化させるステップを含む、例3に記載の方法。
(例5)前記第1動作エンティティと前記第2動作エンティティとの間の前記関係は、前記第1動作エンティティが前記第2動作エンティティの存在に依存するという依存関係である、例4に記載の方法。
(例6)所与の動作エンティティは、制御アプリケーションプログラミングインタフェース(API)によりサポートされる機能セットのうちの1つ以上の機能を実施し、前記1つ以上の実施された機能は、制御モジュールが前記所与の動作エンティティの状態を変化させることを可能にする、例1~5のいずれか一項に記載の方法。
(例7)前記ブループリントのうちの特定の1つは、前記所与の動作エンティティに関連付けられ、前記特定のブループリントは、前記所与の動作エンティティに関連付けられた現在ライフサイクルステージを示すライフサイクル値を指定し、前記ライフサイクル値は、前記1つ以上の実施される機能のうちのどれが前記ライフサイクルステージのために呼び出し可能かを決定するために制御モジュールにより使用可能である、例6に記載の方法。
(例8)前記動作エンティティセットのうちの第1の特定の動作エンティティは、前記階層構造の中で、前記動作エンティティセットのうちの第2動作エンティティと異なるレベルにあり、前記動作エンティティセットを管理するために実行可能な前記制御モジュールのうちの制御モジュールは、前記階層構造の異なるレベルにある、例1~7のいずれか一項に記載の方法。
(例9)前記命令のうちの特定の命令を実行するステップは、前記ソフトウェアエンティティに、別の情報エンティティをインスタンス化させるステップを含む、例1~8のいずれか一項に記載の方法。
(例10)前記動作シナリオは、前記動作エンティティセットに含まれる1つ以上のソフトウェアエンティティの状態を変化させて、前記1つ以上のソフトウェアエンティティを第1ソフトウェアバージョンから第2ソフトウェアバージョンに遷移させることを含む、例1~9のいずれか一項に記載の方法。
(例11)前記ハードウェアエンティティはプロセッサセットに対応し、前記ソフトウェアエンティティは、前記プロセッサセットを実行するデータベースサーバに対応し、前記情報エンティティは、前記データベースサーバにより管理される論理データベースに対応する、例1~10のいずれか一項に記載の方法。
(例12)非一時的コンピュータ可読媒体であって、格納されたプログラム命令を有し、前記プログラム命令は、コンピュータシステムに動作を実行させることができ、前記動作は、
目標コンピュータ環境に関連する動作シナリオのためのコマンドセットを定義する動作情報にアクセスするステップと、
前記動作シナリオを実施する前記目標コンピュータ環境の中で利用されるべき動作エンティティセットのブループリントにアクセスするステップであって、前記動作エンティティセットは、ハードウェアエンティティ、ソフトウェアエンティティ、及び情報エンティティを含む、ステップと、
前記動作シナリオを実施するステップと、
を含み、前記実施するステップは、
制御モジュールの階層構造を実行するステップを含み、前記階層構造は、該階層構造の最上位にあり、該階層構造の次のレベルにある制御モジュールに命令を発行することにより前記コマンドセットを実行するために実行可能なオーケストレータ制御モジュールを含み、前記制御モジュールの階層構造は、前記動作エンティティセットのうちの1つ以上の状態を変化させることによることを含む前記動作シナリオを達成するためにそれぞれのブループリントに従い前記動作エンティティセットを管理するために実行可能な制御モジュールを含む、媒体。
(例13)前記アクセスされたブループリントのうちの特定のブループリントは、前記動作エンティティセットのうちの対応する動作エンティティのライフサイクル値及びタイプ値を指定し、前記ライフサイクル値及びタイプ値は、前記対応する動作エンティティの状態を変化させるために呼び出し可能な1つ以上の機能を決定するために使用可能である、例12に記載の媒体。
(例14)前記アクセスされたブループリントのうちの特定のブループリントは、前記動作エンティティセットのうちの対応する動作エンティティが前記動作エンティティセットのうちの別の特定の動作エンティティに依存するという関係を指定し、前記対応する動作エンティティを初期化する命令のうちの特定の命令を実行するステップは、前記対応する動作エンティティを初期化する前に、前記他の特定の動作エンティティを初期化するステップを含む、例12に記載の媒体。
(例15)前記動作は、
前記アクセスされたブループリントのうちの特定のブループリントが有効か否かを決定するために、前記特定のブループリントを検証するステップ、を更に含み、前記検証するステップは、
対応する定義にアクセスするステップであって、前記対応する定義は、該定義に対応する所与のブループリントの中で指定されるべき許容可能な値セットを識別する、ステップと、
前記アクセスされた定義に基づき、前記特定のブループリントが前記アクセス可能な値セットに含まれない値を指定するか否かを決定するステップと、
を含む、例12に記載の媒体。
(例16)動作エンティティセットを管理する方法であって、
前記動作エンティティセットを含むコンピュータシステムにより、制御モジュールの階層構造を実行するステップであって、前記階層構造は、該階層構造の最上位にあり、前記動作エンティティセットを管理するために該階層構造の中の他の制御モジュールと通信するよう動作するオーケストレータ制御モジュールを有し、前記動作エンティティセットは、ハードウェアエンティティ、ソフトウェアエンティティ、及び情報エンティティを含む、ステップと、
前記オーケストレータ制御モジュールにより、動作情報にアクセスするステップであって、前記動作情報は、前記動作エンティティセットに関連する動作シナリオのステップシーケンスを実施するためのコマンドを有するワークフローを指定する、ステップと、
前記オーケストレータ制御モジュールにより、前記動作シナリオを実施するために前記ワークフローの前記コマンドを実施するステップであって、前記実施するステップは、前記動作エンティティセットのうちの1つ以上の動作エンティティの状態を変化させるために前記他の制御モジュールのうちの1つ以上の制御モジュールに命令を発行するステップと、
を含む方法。
(例17)前記階層構造の中の特定の制御モジュールは、前記動作エンティティセットの属性を定義するそれぞれのブループリントに従い、前記動作エンティティセットを管理するよう動作する、例16に記載の方法。
(例18)前記属性は、前記動作エンティティセットのうちの動作エンティティの間の関係に関する情報を定義する関係属性を含み、前記関係は、前記1つ以上の動作エンティティの前記状態が前記命令に基づき変化される順序に影響する、例17に記載の方法。
(例19)前記1つ以上の他の制御モジュールは、前記オーケストレータ制御モジュールから受信された前記命令のうちの1つ以上の命令を、前記動作エンティティセットを管理する前記特定の制御モジュールへルーティングするよう動作する、例17に記載の方法。
(例20)前記1つ以上の他の制御モジュールは、前記動作エンティティセットに対応するユニークな識別子のセットに基づき、前記1つ以上の命令をルーティングするよう動作する、例19に記載の方法。
特定の実施形態が上述されたが、これらの実施形態は、単一の実施形態のみが特定の特徴に関して記載されたとしても、本開示の範囲を限定することを意図しない。本開示で提供される特徴の例は、特に断りの無い限り、限定ではなく説明を意図している。上述の説明は、本開示の利益を享受する当業者に明らかなように、このような代替、変更、及び均等物をカバーすることを意図している。
本開示の範囲は、本願明細書で解決される問題のうちのいずれか又は全部を軽減するか否かにかかわらず、本願明細書に開示した任意の特徴又は特徴の結合(明示的又は暗示的のいずれも)、又はそれらの任意の一般化を含む。従って、新規な請求項が、任意のこのような特徴の組み合わせに対して、本願(又は本願に基づく優先権を主張する出願)の審査中に形成され得る。特に、添付の請求項を参照して、従属請求項による特徴は、独立請求項の特徴と結合されてよく、それぞれの独立請求項の特徴は、添付の請求の範囲に列挙されない特定の組み合わせではなく、任意の適切な方法で結合されてよい。