特表 2024-535426 タスクを実行するノードの自動選択

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

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

(11)【公表番号】

(43)【公表日】2024-09-30

(54)【発明の名称】タスクを実行するノードの自動選択

(51)【国際特許分類】

   G06F 9/50 20060101AFI20240920BHJP

【ＦＩ】

G06F9/50 150A

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2024519037

(86)(22)【出願日】2022-07-01

(85)【翻訳文提出日】2024-03-27

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

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

(87)【国際公開日】2023-04-06

(31)【優先権主張番号】17/489,999

(32)【優先日】2021-09-30

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】390009531

【氏名又は名称】インターナショナル・ビジネス・マシーンズ・コーポレーション

【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ

【住所又は居所原語表記】Ｎｅｗ Ｏｒｃｈａｒｄ Ｒｏａｄ， Ａｒｍｏｎｋ， Ｎｅｗ Ｙｏｒｋ １０５０４， Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ

(74)【代理人】

【識別番号】100112690

【弁理士】

【氏名又は名称】太佐 種一

(74)【代理人】

【識別番号】100120710

【弁理士】

【氏名又は名称】片岡 忠彦

(74)【復代理人】

【識別番号】110000420

【氏名又は名称】弁理士法人ＭＩＰ

(72)【発明者】

【氏名】チュー、シャオジェン

(72)【発明者】

【氏名】チェン、シャオリン

(72)【発明者】

【氏名】カオ、ヤン

(72)【発明者】

【氏名】ヤン、ユンジュアン

(57)【要約】

マネージド・ノード上にタスクを実装する方法、コンピュータ・プログラム製品、およびコンピュータ・システム。２つ以上のマネージド・ノードのうちの１つまたは複数のマネージド・ノード上でＡｎｓｉｂｌｅモジュールにより実行される規定されたタスクが受信される。１つまたは複数のマネージド・ノードは、ＡｎｓｉｂｌｅモジュールのｈｏｓｔＤｅｃｉｓｉｏｎ属性の属性値に基づき決定される。属性値は、ｐｒｉｍａｒｙＮｏｄｅ、ａｌｌＮｏｄｅｓ、またはＤｙｎａｍｉｃとすることができ、ｐｒｉｍａｒｙＮｏｄｅは、１つまたは複数のマネージド・ノードがプライマリ・ノードであることを要求し、ａｌｌＮｏｄｅｓは、１つまたは複数のマネージド・ノードが２つ以上のマネージド・ノードであることを要求し、Ｄｙｎａｍｉｃは、１つまたは複数のマネージド・ノードがランタイム情報に基づき動的に決定されることを要求する。Ａｎｓｉｂｌｅモジュールは、１つまたは複数のマネージド・ノード上でタスクを実行するように１つまたは複数のマネージド・ノードに送信される。

【特許請求の範囲】

【請求項1】

マネージド・ノード上にタスクを実装する方法であって、
コンピュータ・システムにおけるＡｎｓｉｂｌｅ制御ノード内のＡｎｓｉｂｌｅエンジンの１つまたは複数のプロセッサにより、ホストの複数のマネージド・ノードのうちの１つまたは複数のマネージド・ノード上でＡｎｓｉｂｌｅモジュールにより実行されるタスクの規定を受信することと、
前記ＡｎｓｉｂｌｅモジュールのｈｏｓｔＤｅｃｉｓｉｏｎ属性の属性値に基づき前記１つまたは複数のマネージド・ノードを前記１つまたは複数のプロセッサにより決定することであって、前記属性値は、ｐｒｉｍａｒｙＮｏｄｅ、ａｌｌＮｏｄｅｓ、およびＤｙｎａｍｉｃからなる群から選択され、ｐｒｉｍａｒｙＮｏｄｅは、前記１つまたは複数のマネージド・ノードが前記複数のマネージド・ノードから選択されたプライマリ・ノードからなることを要求し、ａｌｌＮｏｄｅｓは、前記１つまたは複数のマネージド・ノードが前記複数のマネージド・ノードからなることを要求し、Ｄｙｎａｍｉｃは、前記プライマリ・ノードにより取得された、前記複数のマネージド・ノードのうちの前記マネージド・ノードに関する１つまたは複数のファクタの現ステータスを含むランタイム情報に基づき、前記１つまたは複数のマネージド・ノードが動的に決定されることを要求する、前記決定することと、
前記１つまたは複数のマネージド・ノード上で前記タスクを実行するように、前記１つまたは複数のプロセッサにより前記Ａｎｓｉｂｌｅモジュールを前記１つまたは複数のマネージド・ノードに送信することと
を含む、前記方法。

【請求項2】

前記属性値は、ｐｒｉｍａｒｙＮｏｄｅまたはＤｙｎａｍｉｃのいずれかである、請求項１に記載の方法。

【請求項3】

前記Ａｎｓｉｂｌｅ制御ノード内のＡｎｓｉｂｌｅインベントリから前記プライマリ・ノードの識別情報を前記１つまたは複数のプロセッサにより受信すること
を含み、前記Ａｎｓｉｂｌｅインベントリは、前記複数のマネージド・ノードおよび前記プライマリ・ノードの前記識別情報を記憶する、請求項２に記載の方法。

【請求項4】

エンド・ユーザにより前記Ａｎｓｉｂｌｅインベントリに記憶される前記プライマリ・ノードの静的識別情報を前記１つまたは複数のプロセッサにより前記エンド・ユーザから受信すること
を含む、請求項３に記載の方法。

【請求項5】

前記プライマリ・ノードの動的識別情報を前記１つまたは複数のプロセッサにより受信すること
を含む、請求項２に記載の方法。

【請求項6】

前記複数のマネージド・ノードは、前記複数のマネージド・ノードのうちの前記マネージド・ノードが相互にまたは互いに隔離されるようなパブリック・クラウド上にあり、前記プライマリ・ノードの前記動的識別情報を前記受信することは、
各マネージド・ノードから、前記各マネージド・ノードが前記プライマリ・ノードであるという通知を受信すること
を含む、請求項５に記載の方法。

【請求項7】

前記複数のマネージド・ノードは、前記複数のマネージド・ノードのうちの前記マネージド・ノードそれぞれが前記複数のマネージド・ノードのうちの他の前記マネージド・ノードの存在を認識するようなオンプレミス環境内の同じシスプレックスにあり、前記プライマリ・ノードの前記動的識別情報を前記受信することは、
複数のプライマリ・ノードのうちのマネージド・ノードに関する前記１つまたは複数のファクタの前記現ステータスに基づく前記プライマリ・ノードの動的決定を通して前記プライマリ・ノードの前記動的識別情報を受信すること
を含む、請求項５に記載の方法。

【請求項8】

前記マネージド・ノードに関する前記１つまたは複数のファクタは、中央処理ユニット（ＣＰＵ）キャパシティ・ウェイト、システム環境変数、およびヘルス・ステータスを含む、請求項７に記載の方法。

【請求項9】

前記属性値は、ｐｒｉｍａｒｙＮｏｄｅである、請求項２に記載の方法。

【請求項10】

前記属性値は、Ｄｙｎａｍｉｃであり、前記方法は、
前記タスクが実行される前記１つまたは複数のマネージド・ノードを、前記複数のマネージド・ノードのうちの前記マネージド・ノードに関する前記１つまたは複数のファクタの前記現ステータスを含む前記ランタイム情報に基づき、前記１つまたは複数のプロセッサにより動的に決定すること
を含む、請求項２に記載の方法。

【請求項11】

前記マネージド・ノードに関する前記１つまたは複数のファクタは、システム環境変数、ヘルス・データ、およびワークロード・ステータスを含む、請求項１０に記載の方法。

【請求項12】

前記タスクが実行される前記１つまたは複数のマネージド・ノードを前記動的に決定することは、
前記プライマリ・ノードが前記ランタイム情報に基づき前記１つまたは複数のマネージド・ノードを動的に決定した後に、前記１つまたは複数のマネージド・ノードのリストを前記プライマリ・ノードから前記１つまたは複数のプロセッサにより受信すること
を含む、請求項１０に記載の方法。

【請求項13】

前記タスクが実行される前記１つまたは複数のマネージド・ノードを前記動的に決定することは、
前記ランタイム情報を前記プライマリ・ノードから前記１つまたは複数のプロセッサにより受信することと、
前記プライマリ・ノードから受信された前記ランタイム情報に基づき前記１つまたは複数のプロセッサにより前記１つまたは複数のマネージド・ノードを動的に決定することと
を含む、請求項１０に記載の方法。

【請求項14】

前記Ａｎｓｉｂｌｅ制御ノードは、前記ＡｎｓｉｂｌｅモジュールのｈｏｓｔＤｅｃｉｓｉｏｎ属性を規定する設定ファイルをさらに含む、請求項１に記載の方法。

【請求項15】

前記Ａｎｓｉｂｌｅ制御ノードは、前記Ａｎｓｉｂｌｅモジュールと、実行される前記タスクに関連して前記Ａｎｓｉｂｌｅエンジンにより要求されるかまたは必要とされる特化された機能を実行するように構成されたプラグインとを含む、Ａｎｓｉｂｌｅギャラクシーをさらに含む、請求項１に記載の方法。

【請求項16】

前記１つまたは複数のマネージド・ノード上で前記Ａｎｓｉｂｌｅモジュールにより前記タスクを実行すること
を含む、請求項１に記載の方法。

【請求項17】

コンピュータ可読プログラム・コードが記憶された１つまたは複数のコンピュータ可読ハードウェア・ストレージ・デバイスを含むコンピュータ・プログラム製品であって、前記プログラム・コードは、マネージド・ノード上にタスクを実装する方法を実装するようにコンピュータ・システムにおけるＡｎｓｉｂｌｅ制御ノード内のＡｎｓｉｂｌｅエンジンの１つまたは複数のプロセッサにより実行可能な命令を含み、前記方法は、
ホストの複数のマネージド・ノードのうちの１つまたは複数のマネージド・ノード上でＡｎｓｉｂｌｅモジュールにより実行されるタスクの規定を前記１つまたは複数のプロセッサにより受信することと、
前記ＡｎｓｉｂｌｅモジュールのｈｏｓｔＤｅｃｉｓｉｏｎ属性の属性値に基づき前記１つまたは複数のマネージド・ノードを前記１つまたは複数のプロセッサにより決定することであって、前記属性値は、ｐｒｉｍａｒｙＮｏｄｅ、ａｌｌＮｏｄｅｓ、およびＤｙｎａｍｉｃからなるグループから選択され、ｐｒｉｍａｒｙＮｏｄｅは、前記１つまたは複数のマネージド・ノードが前記複数のマネージド・ノードから選択されたプライマリ・ノードからなることを要求し、ａｌｌＮｏｄｅｓは、前記１つまたは複数のマネージド・ノードが前記複数のマネージド・ノードからなることを要求し、Ｄｙｎａｍｉｃは、前記プライマリ・ノードにより取得された、前記複数のマネージド・ノードのうちの前記マネージド・ノードに関する１つまたは複数のファクタの現ステータスを含むランタイム情報に基づき、前記１つまたは複数のマネージド・ノードが動的に決定されることを要求する、前記決定することと、
前記１つまたは複数のマネージド・ノード上で前記タスクを実行するように、前記１つまたは複数のプロセッサにより前記Ａｎｓｉｂｌｅモジュールを前記１つまたは複数のマネージド・ノードに送信することと
を含む、コンピュータ・プログラム製品。

【請求項18】

前記属性値は、ｐｒｉｍａｒｙＮｏｄｅまたはＤｙｎａｍｉｃのいずれかである、請求項１７に記載のコンピュータ・プログラム製品。

【請求項19】

コンピュータ・システムにおけるＡｎｓｉｂｌｅ制御ノード内のＡｎｓｉｂｌｅエンジンの１つまたは複数のプロセッサと、１つまたは複数のメモリと、１つまたは複数のコンピュータ可読ハードウェア・ストレージ・デバイスとを含む前記コンピュータ・システムであって、前記１つまたは複数のハードウェア・ストレージ・デバイスは、マネージド・ノード上にタスクを実装する方法を実装するように前記１つまたは複数のメモリを介して前記１つまたは複数のプロセッサにより実行可能なプログラム・コードを含み、前記方法は、
ホストの複数のマネージド・ノードのうちの１つまたは複数のマネージド・ノードにより実行されるタスクの規定を前記１つまたは複数のプロセッサにより受信することと、
前記複数のマネージド・ノード上で前記タスクを実行するように構成されたＡｎｓｉｂｌｅモジュールのｈｏｓｔＤｅｃｉｓｉｏｎ属性の属性値に基づき前記１つまたは複数のマネージド・ノードを前記１つまたは複数のプロセッサにより決定することであって、前記属性値は、ｐｒｉｍａｒｙＮｏｄｅ、ａｌｌＮｏｄｅｓ、およびＤｙｎａｍｉｃからなるグループから選択され、ｐｒｉｍａｒｙＮｏｄｅは、前記１つまたは複数のマネージド・ノードが前記複数のマネージド・ノードから選択されたプライマリ・ノードからなることを要求し、ａｌｌＮｏｄｅｓは、前記１つまたは複数のマネージド・ノードが前記複数のマネージド・ノードからなることを要求し、Ｄｙｎａｍｉｃは、前記プライマリ・ノードにより取得された、前記複数のマネージド・ノードのうちの前記マネージド・ノードに関する１つまたは複数のファクタの現ステータスを含むランタイム情報に基づき、前記１つまたは複数のマネージド・ノードが動的に決定されることを要求する、前記決定することと、
前記１つまたは複数のマネージド・ノード上で前記タスクを実行するように、前記１つまたは複数のプロセッサにより前記Ａｎｓｉｂｌｅモジュールを前記１つまたは複数のマネージド・ノードに送信することと
を含む、コンピュータ・システム。

【請求項20】

前記属性値は、ｐｒｉｍａｒｙＮｏｄｅまたはＤｙｎａｍｉｃのいずれかである、請求項１９に記載のコンピュータ・システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、全般的に、Ａｎｓｉｂｌｅエンジンを使用した、Ａｎｓｉｂｌｅプラットフォームにおいてタスクを実行するＡｎｓｉｂｌｅモジュールのデプロイメントに関し、特に、Ａｎｓｉｂｌｅホスト・グループ内のすべてのマネージド・ノード上ではタスクの実行が要求されないであろうシナリオで、どのマネージド・ノード上でタスクが実行されるかを選択的に決定することに関する。

【背景技術】

【0002】

Ａｎｓｉｂｌｅは、Ａｎｓｉｂｌｅ ＩＴプラットフォーム上にデプロイされる情報技術（ＩＴ：Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）エンジンである。クラウド・プラットフォームにおいて広く使用されているソフトウェアであるＡｎｓｉｂｌｅエンジンは、Ａｎｓｉｂｌｅプレイブックに規定された１つまたは複数のタスクを、Ａｎｓｉｂｌｅモジュールを使用して実行することにより、アプリケーションのデプロイメントを自動化する。１つまたは複数のタスクは、ホスト・グループ（以下「ホスト」）のすべてのマネージド・ノード上でＡｎｓｉｂｌｅモジュールにより実行される。ホスト・グループは、Ａｎｓｉｂｌｅプレイブックに規定される。ホストのマネージド・ノードは、Ａｎｓｉｂｌｅインベントリにおいて特定される。

【0003】

Ａｎｓｉｂｌｅプレイブックは、典型的にはＹｅｔ Ａｎｏｔｈｅｒ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＹＡＭＬ）で記述されるテキスト・スクリプトである。Ａｎｓｉｂｌｅプレイブックは、特に、プレイブックの名称、実行される１つまたは複数のタスク、Ａｎｓｉｂｌｅインベントリにおいてそのマネージド・ノードが特定されているホスト・グループの識別情報を規定する。

【0004】

ホストはシステム内のカテゴリ特有であってもよく、ホストのマネージド・ノードはカテゴリのインスタンスである。ホスト・カテゴリの例は、ウェブ・サーバ、データベース・サーバ、メール・サーバ、ストレージ・リポジトリなどである。例えば、ホストがウェブ・サーバ特有であれば、ホストの各マネージド・ノードは、インターネット・プロトコル（ＩＰ：Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスなどのアドレスにある特定のウェブ・サーバである。

【0005】

Ａｎｓｉｂｌｅエンジンは、ＡｎｓｉｂｌｅプレイブックおよびＡｎｓｉｂｌｅインベントリを入力として使用してタスクが実行されるマネージド・ノードを選択するために特に使用されるＡｎｓｉｂｌｅ制御ノードにおいて実行される。

【0006】

Ａｎｓｉｂｌｅロールは、Ａｎｓｉｂｌｅプレイブックに自動的にロード可能なモジュール、タスク、変数、ファイル、およびテンプレートの、独立した再利用可能なコレクションのためのスケルトンを提供する。よって、ＡｎｓｉｂｌｅプレイブックはＡｎｓｉｂｌｅロールのコレクションである。Ａｎｓｉｂｌｅロールは相互に独立している。Ａｎｓｉｂｌｅギャラクシーは、Ａｎｓｉｂｌｅロールのリポジトリである。

【0007】

Ａｎｓｉｂｌｅコレクションは、Ａｎｓｉｂｌｅコンテンツのディストリビューション形式である。Ａｎｓｉｂｌｅプレイブック、ロール、モジュール、およびプラグインを、Ａｎｓｉｂｌｅコレクションを使用してパッケージ化および配布できる。

【0008】

図１は、従来技術による、ホスト・グループ１５０の相互に独立したマネージド・ノード１、２、３、４それぞれでタスク１３０をＡｎｓｉｂｌｅモジュール１１１に実行させるために、モジュール１１１をセキュア・シェル（ＳＳＨ：Ｓｅｃｕｒｅ Ｓｈｅｌｌ）プロトコルを使用してマネージド・ノード１、２、３、４それぞれに送信する、Ａｎｓｉｂｌｅ制御ノード１１０を示す。タスク１３０およびホスト・グループ１５０は、Ａｎｓｉｂｌｅプレイブック１４０に規定されている。ホスト・グループ１５０のマネージド・ノード１、２、３、４は、Ａｎｓｉｂｌｅインベントリ１６０に規定されている。

【0009】

従来技術において典型的に使用される図１の構成において、マネージド・ノードにより実行される自動アクションが相互にまたは互いに影響しないように、マネージド・ノードは独立し、隔離されている。したがって、マネージド・ノードのグループは、同じアクションを実行するものとなる。よって、Ａｎｓｉｂｌｅプレイブックにおいて「ホスト・グループ」は、マネージド・ノードのグループに対して同じタスクを容易に実行できるように使用される。

【0010】

Ａｎｓｉｂｌｅの採用および使用は徐々に増加してきた。多数の異なるプラットフォームがＡｎｓｉｂｌｅエコシステムに加わった。そうしたプラットフォームは、相互にまたは互いに可視となり得るマネージド・ノードをもたらし、１つのマネージド・ノード上で実行されるアクションは他のマネージド・ノードに影響する可能性があり、マネージド・ノードが相互にまたは互いに可視であるシステムは本願明細書においてシステムＳと示され、図１に例示されている。

【0011】

図２は、従来技術による、ホスト・グループ２５１、２５２、２５３それぞれの相互に可視であるマネージド・ノード１、２、３、４上でＡｎｓｉｂｌｅモジュール２１１がタスクを実行するように、モジュール２１１を、ＳＳＨプロトコルを使用してマネージド・ノード１、２、３、４に送信する、Ａｎｓｉｂｌｅ制御ノード２１０を示す。

【0012】

タスク２３０およびホスト・グループ２５１、２５２、２５３がＡｎｓｉｂｌｅプレイブック２４０に規定されている。ホスト・グループ２５１、２５２、２５３のマネージド・ノード１、２、３、４はＡｎｓｉｂｌｅインベントリ２６０に規定され、ホスト・グループ２５１（ＯＳＧｒｏｕｐ）のみがＡｎｓｉｂｌｅインベントリ２６０に明示的に示されている。

【0013】

図２において、Ａｎｓｉｂｌｅプレイブック２４０内のＰｌａｙ１は、ホスト・グループＯＳＧｒｏｕｐと、システムＳ内のすべてのＯＳオペレーティング・システム上で実行されるタスクとを規定する。タスクは、２つのコマンド、すなわちｃｏｍｍａｎｄ１およびｃｏｍｍａｎｄ２を含み、かかるコマンドはそれぞれ、他のＯＳオペレーティング・システムに影響しないようになっている。

【0014】

Ａｎｓｉｂｌｅプレイブック２４０内のＰｌａｙ２は、ホスト・グループｎｏｄｅ１．ｂｊ．ｃｏｍと、マネージド・ノード１および２を包含するシスプレックス２６５内で一度のみ実行されるタスクとを規定する。シスプレックスは、複数のコンピュータの複合体内の、ＯＳオペレーティング・システムの独立したインスタンスのクラスタを指す。マネージド・ノード１および２のカップリング・ファシリティ（ＣＦ：ｃｏｕｐｌｉｎｇ ｆａｃｉｌｉｔｙ）２７０への接続性により、マネージド・ノード１および２はカップリング・ファシリティ・リンクを通してデータを共有できる。

【0015】

Ａｎｓｉｂｌｅプレイブック２４０内のＰｌａｙ３は、独立したアクションを実行するホストＯＳＧｒｏｕｐに再び切り替えることを規定する。

【0016】

システムＳによりＡｎｓｉｂｌｅがサポートされることで、ハイブリッド・クラウドの使用のためにシステムＳをデプロイできる。しかしながら、Ａｎｓｉｂｌｅプレイブック２４０は、特に以下の２つの問題を生じ得る。

【0017】

Ａｎｓｉｂｌｅプレイブックに関する第１の問題は、ホストを切り替えられるようにエンド・ユーザが１つのロジック・プロセスを複数のロジック・プロセスに分割しなければならず、これにより、システムＳのプレイブックは他のプラットフォームのものと異なるように見える可能性があり、習熟曲線が生じるということである。

【0018】

Ａｎｓｉｂｌｅプレイブックに関する第２の問題は、各タスクが一度実行されるべきか、またはすべてのシステムＳ上で実行されるべきかをエンド・ユーザが決定しなければならず、これによりエラーが生じて効率が落ちる可能性があるということである。

【0019】

さらに、ハイブリッド・クラウドのシナリオにおいて、Ａｎｓｉｂｌｅは最も人気の高いインフラストラクチャ・アズ・コード（ＩａＣ：Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ Ｃｏｄｅ）ツールの１つである。ＡｎｓｉｂｌｅプレイブックはＩａＣアーティファクトである。理想的なケースでは、同じＩａＣアーティファクトは同じインフラストラクチャをプロビジョニングする。しかしながら、図２に関して上述した問題が理由で、オートメーションがパブリック・クラウドからオンプレミス環境にシフトされると同じＩａＣアーティファクト（すなわちＡｎｓｉｂｌｅプレイブック）を使用し続けるのが難しい。

【0020】

図３Ａおよび図３Ｂは、従来技術による、パブリック・クラウド３３０のためのＡｎｓｉｂｌｅプレイブック３１０およびＡｎｓｉｂｌｅインベントリ３６１ならびにオンプレミス（「Ｏｎ－Ｐｒｅｍ」）環境３４０のためのＡｎｓｉｂｌｅプレイブック３２０およびＡｎｓｉｂｌｅインベントリ３６２を示す。Ａｎｓｉｂｌｅプレイブック３１０と３２０とは、異なるプレイブックである。

【0021】

シスプレックス３６５は、マネージド・ノード１およびマネージド・ノード２を含む。マネージド・ノード１および２のカップリング・ファシリティ（ＣＦ）３７０への接続性により、マネージド・ノード１および２はカップリング・ファシリティ・リンクを通してデータを共有できる。

【0022】

パブリック・クラウド３３０では、ＯＳオペレーティング・システムは相互にまたは互いに隔離されているため、Ａｎｓｉｂｌｅプレイブック３１０内のタスクはすべてのＯＳオペレーティング・システム上で実行可能であると考えられる。オンプレミス環境３４０では、ＯＳオペレーティング・システムは同じシスプレックス内にある可能性も考えられるため、Ａｎｓｉｂｌｅプレイブック３２０内のタスクは特定のＯＳオペレーティング・システムにおいて一度のみ実行されるべきである。よって、異なるプレイブックがパブリック・クラウドおよびオンプレミス環境に使用されるが、このことは非効率であり、エラーに対する脆弱性を生じさせる。

【0023】

要約すると、従来技術においてＡｎｓｉｂｌｅは、クロス・マネージド・ノードの影響に対処するのに十分な柔軟性および分析能力を有さず、これは特に、クロス・マネージド・ノードのオートメーションを作成するための大きな習熟曲線、クロス・マネージド・ノードのオートメーションを作成するための低い生産性、エラーが発生しやすいオートメーション・スクリプト、およびハイブリッド・クラウド・シナリオにおける一貫性のないＩａＣコード、という問題を生じさせる可能性があると考えられる。

【発明の概要】

【0024】

本発明の実施形態は、マネージド・ノード上にタスクを実装する方法、コンピュータ・プログラム製品、およびコンピュータ・システムを提供する。コンピュータ・システムにおけるＡｎｓｉｂｌｅ制御ノード内のＡｎｓｉｂｌｅエンジンの１つまたは複数のプロセッサが、ホストの複数のマネージド・ノードのうちの１つまたは複数のマネージド・ノード上でＡｎｓｉｂｌｅモジュールにより実行されるタスクの規定を受信する。

【0025】

１つまたは複数のプロセッサは、ＡｎｓｉｂｌｅモジュールのｈｏｓｔＤｅｃｉｓｉｏｎ属性の属性値に基づき１つまたは複数のマネージド・ノードを決定する。属性値は、ｐｒｉｍａｒｙＮｏｄｅ、ａｌｌＮｏｄｅｓ、およびＤｙｎａｍｉｃからなるグループから選択され、ｐｒｉｍａｒｙＮｏｄｅは、１つまたは複数のマネージド・ノードが複数のマネージド・ノードから選択されたプライマリ・ノードからなることを要求し、ａｌｌＮｏｄｅｓは、１つまたは複数のマネージド・ノードが複数のマネージド・ノードからなることを要求し、Ｄｙｎａｍｉｃは、プライマリ・ノードにより取得された、複数のマネージド・ノードのうちのマネージド・ノードに関する１つまたは複数のファクタの現ステータスを含むランタイム情報に基づき、１つまたは複数のマネージド・ノードが動的に決定されることを要求する。

【0026】

１つまたは複数のプロセッサは、１つまたは複数のマネージド・ノード上でタスクを実行するように、Ａｎｓｉｂｌｅモジュールを１つまたは複数のマネージド・ノードに送信する。

【図面の簡単な説明】

【0027】

【図1】従来技術による、モジュールがマネージド・ノード上でタスクを実行するように、セキュア・シェル（ＳＳＨ）プロトコルを使用してホスト・グループの相互に独立したマネージド・ノードにモジュールを送信する、Ａｎｓｉｂｌｅ制御ノードを示す。

【図2】従来技術による、モジュールがマネージド・ノード上でタスクを実行するように、ＳＳＨプロトコルを使用してホスト・グループの相互に可視であるマネージド・ノードにモジュールを送信する、Ａｎｓｉｂｌｅ制御ノードを示す。

【図3A】従来技術による、パブリック・クラウドのためのＡｎｓｉｂｌｅプレイブックを示す。

【図3B】従来技術による、オンプレミス（「Ｏｎ－Ｐｒｅｍ」）環境のためのＡｎｓｉｂｌｅプレイブックを示す。

【図4】本発明の実施形態によるＡｎｓｉｂｌｅ制御ノードを示す。

【図5】本発明の実施形態による、マネージド・ノード上にタスクを実装する方法を記載したフローチャートである。

【図6】本発明の実施形態による、ｈｏｓｔＤｅｃｉｓｉｏｎ属性を処理する方法を記載したフローチャートである。

【図7】本発明の実施形態によるコンピュータ・システムを示す。

【図8】本発明の実施形態によるクラウド・コンピューティング環境を示す。

【図9】本発明の実施形態による抽象化モデル層を示す。

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

【0028】

本発明の実施形態は、クロス・ホストの影響を回避するためにＡｎｓｉｂｌｅマネージド・ノードを自動的に選択する。Ａｎｓｉｂｌｅインベントリに対する静的または動的なプライマリ・ノードの決定をサポートすることによりＡｎｓｉｂｌｅエンジンが拡張される。Ａｎｓｉｂｌｅエンジンはさらに、Ａｎｓｉｂｌｅモジュールの新たな属性ｈｏｓｔＤｅｃｉｓｉｏｎを導入するよう拡張され、ｈｏｓｔＤｅｃｉｓｉｏｎの値は、ｐｒｉｍａｒｙＮｏｄｅ、ａｌｌＮｏｄｅｓ、またはＤｙｎａｍｉｃとするものとする。ｈｏｓｔＤｅｃｉｓｉｏｎ属性は、異なる様々なファクタに基づき静的または動的にマネージド・ノードを選択するために使用される。

【0029】

様々な実施形態において、Ａｎｓｉｂｌｅエンジンは、特定のタスクを実行するよう構成されたＡｎｓｉｂｌｅモジュールに特有の属性ｈｏｓｔＤｅｃｉｓｉｏｎに依存して、マネージド・ノードのホスト・グループのうちのどのマネージド・ノードにおいてＡｎｂｓｉｂｌｅプレイブックに規定されている特定のタスクがＡｎｓｉｂｌｅモジュールにより実行されるべきかを、静的または動的に決定する。Ａｎｓｉｂｌｅモジュールは、特定のタスクを実行するよう構成されたコンピュータ・プログラム（すなわちソフトウェア）である。よって、Ａｎｓｉｂｌｅモジュールは、１つまたは複数のコンピュータ・プロセッサによりマネージド・ノードにてソフトウェアとして実行されることにより、マネージド・ノードにて特定のタスクを実行する。ｈｏｓｔＤｅｃｉｓｉｏｎ属性は、「ｐｒｉｍａｒｙＮｏｄｅ」、「ａｌｌＮｏｄｅｓ」、および「Ｄｙｎａｍｉｃ」の値を有することができる。

【0030】

ｈｏｓｔＤｅｃｉｓｉｏｎ属性の「ｐｒｉｍａｒｙＮｏｄｅ」の値の場合、タスクはホスト・グループ内のノードのうちのプライマリ・ノード上でのみ実行される。

【0031】

ｈｏｓｔＤｅｃｉｓｉｏｎ属性の「ａｌｌＮｏｄｅｓ」の値の場合、タスクはホスト・グループ内のすべてのノード上で実行される。

【0032】

ｈｏｓｔＤｅｃｉｓｉｏｎ属性の「Ｄｙｎａｍｉｃ」の値の場合、タスクが実行される単数または複数のノード（ホスト・グループ内）は、ホストのマネージド・ノードに関する１つまたは複数のファクタの現ステータスに基づき動的に決定され、かかる１つまたは複数のファクタは特に、中央処理ユニット（ＣＰＵ）キャパシティ・ウェイト、システム環境変数、ヘルス・ステータス、ワークロード、ビジー・ステータスなどを含む。

【0033】

図４は、本発明の実施形態によるＡｎｓｉｂｌｅ制御ノード４１０を示す。

【0034】

Ａｎｓｉｂｌｅ制御ノード４１０は、Ａｎｓｉｂｌｅギャラクシー４７０、Ａｎｓｉｂｌｅプレイブック４４０、Ａｎｓｉｂｌｅインベントリ４６０、Ａｎｓｉｂｌｅエンジン４８０、動的プライマリ・ノード決定４９０、および設定ファイル４５０を含む。一実施形態において動的プライマリ・ノード決定４９０は、図のようにＡｎｓｉｂｌｅエンジン４８０の外にある。一実施形態において動的プライマリ・ノード決定４９０は、Ａｎｓｉｂｌｅエンジン４８０内にある。

【0035】

Ａｎｓｉｂｌｅギャラクシー４７０は、Ａｎｓｉｂｌｅモジュール４１１、４１２、４１３、４１４を含み、さらにプラグイン４１６および４１７も含んでもよく、プラグインは、実行されるタスクに関連してＡｎｓｉｂｌｅエンジン４８０により要求されるかまたは必要とされる特化した機能を実行するために、Ａｎｓｉｂｌｅエンジン４８０により呼び出し可能である。

【0036】

Ａｎｓｉｂｌｅインベントリ４６０は、ホスト・グループ４５０、ならびに「ｎｏｄｅ１．ｂｊ．ｃｏｍ」、「ｎｏｄｅ２．ｂｊ．ｃｏｍ」、「ｎｏｄｅ３．ｂｊ．ｃｏｍ」、および「ｎｏｄｅ４．ｂｊ．ｃｏｍ」によりそれぞれ識別されるマネージド・ノード１、２、３、４を規定する。

【0037】

Ａｎｓｉｂｌｅプレイブック４４０は、ホスト・グループ４５０（「ｈｏｓｔＧｒｏｕｐ」）、タスク４３０（タスク４３１、４３２、４３３、４３４を含む）、およびタスク４３１、４３２、４３３、４３４をそれぞれ実行するよう構成されたＡｎｓｉｂｌｅモジュール４１１、４１２、４１３、４１４を規定する。

【0038】

Ａｎｓｉｂｌｅエンジン４８０は、各モジュールのｈｏｓｔＤｅｃｉｓｉｏｎ属性に依存してマネージド・ノード１、２、３、４のうちの１つまたは複数のマネージド・ノードそれぞれにおいてＡｎｓｉｂｌｅモジュール４１１、４１２、４１３、４１４がそれぞれモジュール別のタスク４３０を実行するように、マネージド・ノード１、２、３、４のマネージド・ノード・ロケーション４６５にセキュア・シェル（ＳＳＨ）プロトコルを使用してモジュール４１１、４１２、４１３、４１４を送信する。マネージド・ノード１が、図４の例におけるプライマリ・ノードである。

【0039】

一実施形態において、各Ａｎｓｉｂｌｅモジュールについて、ＡｎｓｉｂｌｅモジュールのｈｏｓｔＤｅｃｉｓｉｏｎ属性値が、特に、Ａｎｓｉｂｌｅモジュールの開発者、Ａｎｓｉｂｌｅモジュールのユーザ、Ａｎｓｉｂｌｅモジュールにより実行されるべきタスクのイニシエータまたはユーザ、タスクが実行されるノードのグループのプライマリ・ノードまたはそのサブセットを含む様々なソースのうちの任意のソースから、Ａｎｓｉｂｌｅエンジン４８０により受信される。

【0040】

一実施形態において、設定ファイル４５０は、各モジュールのｈｏｓｔＤｅｃｉｓｉｏｎ属性値（モジュール１：ｐｒｉｍａｒｙＮｏｄｅ；モジュール２：ａｌｌＮｏｄｅｓ；モジュール３：ｐｒｉｍａｒｙＮｏｄｅ；モジュール４：Ｄｙｎａｍｉｃ）を規定する。

【0041】

よって、Ａｎｓｉｂｌｅモジュール４１１は、「ｐｒｉｍａｒｙＮｏｄｅ」のｈｏｓｔＤｅｃｉｓｉｏｎ属性値を有する。モジュール４１２は、「ａｌｌＮｏｄｅｓ」のｈｏｓｔＤｅｃｉｓｉｏｎ属性値を有する。モジュール４１３は、「ｐｒｉｍａｒｙＮｏｄｅ」のｈｏｓｔＤｅｃｉｓｉｏｎ属性値を有する。モジュール４１４は、「Ｄｙｎａｍｉｃ」のｈｏｓｔＤｅｃｉｓｉｏｎ属性値を有する。

【0042】

一実施形態において、Ａｎｓｉｂｌｅエンジン４８０の制御下にある動的プライマリ・ノード決定４９０は、どのマネージド・ノードがプライマリ・ノードであるかを決定するために使用されてもよい。

【0043】

本発明の実施形態について、エンド・ユーザ４３５は、Ａｎｓｉｂｌｅインベントリ４６０においてホスト・グループ４５０のプライマリ・ノードを静的に規定してもよいし、またはＡｎｓｉｂｌｅエンジン４８０は、追加されたプライマリ・ノード決定モジュール４９０を用いてプライマリ・ノードを動的に決定してもよい。図４では、マネージド・ノード・ロケーション４６５およびＡｎｓｉｂｌｅインベントリ４６０に示されている通り、マネージド・ノード１がプライマリ・ノードである。

【0044】

特定のタスクを実行するモジュールのｈｏｓｔＤｅｃｉｓｉｏｎ属性値が「ｐｒｉｍａｒｙＮｏｄｅ」である場合は、プライマリ・ノードが、ホスト・グループ内で特定のタスクが実行され得る唯一のマネージド・ノードである。よって、関連するモジュールがｈｏｓｔＤｅｃｉｓｉｏｎ＝ｐｒｉｍａｒｙＮｏｄｅを有する当該のＡｎｓｉｂｌｅタスクは、同じホスト・グループ内の他のマネージド・ノード上では実行されない。

【0045】

どのマネージド・ノードがプライマリ・ノードであるかを決定する方式には、静的方式および動的方式の２つがある。

【0046】

どのマネージド・ノードがプライマリ・ノードであるかを決定するための静的方式では、エンド・ユーザ４３５が、Ａｎｓｉｂｌｅインベントリ４６０においてホスト・グループ４５０のプライマリ・ノードを静的に規定し、この結果、図のようにＡｎｓｉｂｌｅインベントリ４６０内のホスト・グループ４５０においてプライマリ・ノードが規定される。プライマリ・ノードは、図のようにマネージド・ノード・ロケーション４６５において規定することもできる。Ａｎｓｉｂｌｅエンジン４８０は、ユーザから直接、またはＡｎｓｉｂｌｅインベントリ４６０もしくは設定ファイル４５０からなどＡｎｓｉｂｌｅ制御ノード４１０の中のストレージからのいずれかにより、プライマリ・ノードの識別情報を受信する。

【0047】

どのマネージド・ノードがプライマリ・ノードであるかを決定するための動的方式では、Ａｎｓｉｂｌｅエンジン４８０が、追加されたプライマリ・ノード決定モジュール４９０を使用してプライマリ・ノードを動的に決定してもよく、この結果、プライマリ・ノードがマネージド・ノード・ロケーション４６５において規定され、さらに、設定ファイル４５０およびＡｎｓｉｂｌｅ制御ノード４１０内の他のストレージ・ロケーションに記憶される。

【0048】

ホストのマネージド・ノードに関する１つまたは複数のファクタの現ステータスに基づきどのマネージド・ノードがプライマリ・ノードであるかを決定する動的処理には、２つのタイプがある。

【0049】

どのマネージド・ノードがプライマリ・ノードであるかを決定する第１のタイプの動的処理では、マネージド・ノードは、例えば［ｎｏｄｅＧｒｏｕｐ１］ｎｏｄｅ１．ｃｌｏｕｄ．ｃｏｍおよびｎｏｄｅ２．ｃｌｏｕｄ．ｃｏｍのノード・グループを備えるパブリック・クラウド上のものであり、このケースにおいて、ｎｏｄｅ１およびｎｏｄｅ２は、通常は事前テスト環境として使用されるスタンドアロン・ノードであり、相互に隔離されている可能性がある。この第１のタイプの「動的」処理は、どのマネージド・ノードがｎｏｄｅ１．ｃｌｏｕｄ．ｃｏｍのプライマリ・ノードであり、どのマネージド・ノードがｎｏｄｅ２．ｃｌｏｕｄ．ｃｏｍのプライマリ・ノードであるかを特定する。実装の観点から見ると、特定の処理がｎｏｄｅ１およびｎｏｄｅ２の両方で実行される。このパブリック・クラウドのケースでは、ｎｏｄｅ１およびｎｏｄｅ２は相互に隔離され相互に認識しないため、ｎｏｄｅ１はそれ自体をプライマリ・ノードとみなし、ｎｏｄｅ２はそれ自体をプライマリ・ノードとみなすものとなる。よって、動的処理は、Ａｎｓｉｂｌｅエンジン４８０にｎｏｄｅ１のプライマリ・ノードをｎｏｄｅ１として返す。同じく動的処理は、Ａｎｓｉｂｌｅエンジン４８０にｎｏｄｅ２のプライマリ・ノードをｎｏｄｅ２として返す。Ａｎｓｉｂｌｅエンジン４８０は、Ａｎｓｉｂｌｅインベントリ４６０および設定ファイル４５０にプライマリ・ノードの識別情報を記憶する。

【0050】

後に、Ａｎｓｉｂｌｅエンジン４８０がタスクの実行を開始した際、特定のタスクの「ｈｏｓｔＤｅｃｉｓｉｏｎ」が「ｐｒｉｍａｒｙＮｏｄｅ」であれば、ｎｏｄｅ１のタスクがｎｏｄｅ１上で実行され、ｎｏｄｅ２の同じタスクがｎｏｄｅ２上で実行される。言い換えると、同じタスクが「ｎｏｄｅＧｒｏｕｐ１」内のあらゆるノード上で実行される。

【0051】

どのマネージド・ノードがプライマリ・ノードであるかを決定する第２のタイプの動的処理では、マネージド・ノードは、例えば［ｎｏｄｅＧｒｏｕｐ２］ｎｏｄｅ３．ｃｕｓｔｏｍｅｒ．ｃｏｍおよびｎｏｄｅ４．ｃｕｓｔｏｍｅｒ．ｃｏｍのノード・グループを備えるオンプレミス（「Ｏｎ－Ｐｒｅｍ」）環境上のものであり、このケースにおいて、ｎｏｄｅ３およびｎｏｄｅ４は顧客のデータ・センターにある。ｎｏｄｅ３およびｎｏｄｅ４がシステムＳ内にあれば、ｎｏｄｅ３およびｎｏｄｅ４は同じシスプレックス内にある可能性が非常に高く、これは、ｎｏｄｅ３およびｎｏｄｅ４が相互に認識および影響する可能性があることを意味する。ｎｏｄｅ３およびｎｏｄｅ４は同じシスプレックスを共有するので、一部のタスクは一度のみ（つまりｎｏｄｅ３上またはｎｏｄｅ４上のいずれかで）実行可能である。「動的」処理中、ｎｏｄｅ３およびｎｏｄｅ４は、同じシスプレックス内にあることが理由で、相互を認識している。よって、プライマリ・ノードを、ホストのマネージド・ノードに関する１つまたは複数のファクタの現ステータスに基づき動的に決定できると考えられ、本例のマネージド・ノードはｎｏｄｅ３およびｎｏｄｅ４である。ホストのマネージド・ノードに関する１つまたは複数のファクタは、特に、中央処理ユニット（ＣＰＵ）キャパシティ・ウェイト、システム環境変数、およびヘルス・ステータスを含む。

【0052】

プライマリ・ノードを動的に決定するためにＣＰＵキャパシティ・ウェイトを使用する例として、システムＳは、異なるＣＰＵキャパシティがそれぞれのノードに割り当てられた複数のノードを含むことができるであろう。一実施形態において、最大のＣＰＵキャパシティを割り当てられているノードがプライマリ・ノードであると決定される。

【0053】

プライマリ・ノードを動的に決定するためにシステム環境変数を使用する例として、システムＳは、規定のソフトウェア製品（例えばＣＩＣＳ（ＩＢＭ社の登録商標）、ＤＢ２（ＩＢＭ社の登録商標））がそれぞれのノードにインストールされた複数のノードを含むことができよう。一実施形態において、最新バージョンのソフトウェア製品をインストールされているノードがプライマリ・ノードであると決定される。

【0054】

プライマリ・ノードを動的に決定するためにヘルス・ステータスを使用する例として、システムＳは、各ノード上にインストールされた複数の製品（つまりハードウェア製品、ソフトウェア製品、およびその組み合わせ）のヘルス・ステータスを含むことができるであろう。各製品のヘルス・ステータスは、スコアリングされ、ハードウェア要件、システム要件、セキュリティ要件などに対する製品の準拠の程度を反映する。一実施形態において、最高のヘルス・ステータス・スコアを有するノードがプライマリ・ノードであると決定される。

【0055】

ｈｏｓｔＤｅｃｉｓｉｏｎ属性がＤｙｎａｍｉｃであれば、本発明の実施形態は、タスクが実行されるマネージド・ノードを決定する。

【0056】

一実施形態において、どのマネージド・ノード上でタスクが実行されるべきかの決定は、モジュールのｈｏｓｔＤｅｃｉｓｉｏｎ属性に従って、Ａｎｓｉｂｌｅエンジンがプライマリ・ノードにタスクを実行するモジュールを送信した後にプライマリ・ノードにより行われてもよい。プライマリ・ノードは、タスクがどのマネージド・ノード上で実行されるべきかを、特にシステム環境変数、ヘルス・データ、ワークロード・ステータスなどを含む１つまたは複数のファクタの現ステータスを含むランタイム情報に基づき、動的に決定してもよい。次にプライマリ・ノードは、タスクが実行される１つまたは複数のターゲット・ノードのリストをＡｎｓｉｂｌｅエンジンに返す。次にＡｎｓｉｂｌｅエンジンは、返された１つまたは複数のターゲット・ノードのリストをＡｎｓｉｂｌｅ制御ノード内のストレージ・エリアに記憶し、そのストレージ・エリアのターゲット・ノードのリストが、後にＡｎｓｉｂｌｅエンジンによりアクセスされてもよい。

【0057】

一実施形態において、どのマネージド・ノード上でタスクが実行されるべきかの決定は、Ａｎｓｉｂｌｅエンジンが、特にシステム環境変数、ヘルス・データ、ワークロード・ステータスなどを含むランタイム情報をプライマリ・ノードから受信した後に、Ａｎｓｉｂｌｅエンジンにより行われてもよい。次にＡｎｓｉｂｌｅエンジンは、返された１つまたは複数のターゲット・ノードのリストをＡｎｓｉｂｌｅ制御ノード内のストレージ・エリアに記憶し、そのストレージ・エリアのターゲット・ノードのリストが、後にＡｎｓｉｂｌｅエンジンによりアクセスされてもよい。

【0058】

以下の例は、ｈｏｓｔＤｅｃｉｓｉｏｎがＤｙｎａｍｉｃである場合に、どのノード上で所与のタスクが実行されるかをＡｎｓｉｂｌｅエンジンが特定する方法を示す。

【0059】

本例のＡｎｓｉｂｌｅインベントリは以下の通りである：
［ｎｏｄｅＧｒｏｕｐ３］
ｎｏｄｅ５．ｃｕｓｔｏｍｅｒ１．ｃｏｍ
ｎｏｄｅ６．ｃｕｓｔｏｍｅｒ１．ｃｏｍ
ｎｏｄｅ７．ｃｕｓｔｏｍｅｒ１．ｃｏｍ

【0060】

プライマリ・ノードはｎｏｄｅ５である。

【0061】

本例のＡｎｓｉｂｌｅプレイブックは以下の通りである：
Ｐｌａｙ１：
ｈｏｓｔ：ｎｏｄｅＧｒｏｕｐ３
－Ｔａｓｋ１（Ａｎｓｉｂｌｅ ｍｏｄｕｌｅ１をコールする（ｍｏｄｕｌｅ１のｈｏｓｔＤｅｃｉｓｉｏｎは「ｐｒｉｍａｒｙＮｏｄｅ」である）
－Ｔａｓｋ２（Ａｎｓｉｂｌｅ ｍｏｄｕｌｅ２をコールする（ｍｏｄｕｌｅ２のｈｏｓｔＤｅｃｉｓｉｏｎは「ａｌｌＮｏｄｅｓ」である）
－Ｔａｓｋ３（Ａｎｓｉｂｌｅ ｍｏｄｕｌｅ３をコールする（ｍｏｄｕｌｅ３のｈｏｓｔＤｅｃｉｓｉｏｎは「Ｄｙｎａｍｉｃ」である）

【0062】

ＡｎｓｉｂｌｅエンジンがＴａｓｋ１を実行するとき、Ｔａｓｋ１はプライマリ・ノードでのみ実行されるべきであり、プライマリ・ノードはｎｏｄｅ５であるため、Ｔａｓｋ１はｎｏｄｅ５上でのみ実行される。

【0063】

ＡｎｓｉｂｌｅエンジンがＴａｓｋ２を実行するとき、Ｔａｓｋ２はすべてのノード（ｎｏｄｅ５、ｎｏｄｅ６、ｎｏｄｅ７）上で実行される。

【0064】

ＡｎｓｉｂｌｅエンジンがＴａｓｋ３を実行するとき、Ｔａｓｋ３は、Ｔａｓｋ３が実行されるべきターゲット・ノードを動的に特定する「動的」処理をトリガする。この処理は特定のロジックを使用して実行される。このロジックは、次に限定はされないが、ワークロード・バランシング、ヘルス・ステータス、ソフトウェア・インストール・バージョン、およびシステム環境変数の各ファクタに基づきターゲット・ノードを決定する。

【0065】

前述のファクタ（ワークロード・バランシング、ヘルス・ステータス、ソフトウェア・インストール・バージョン、システム環境変数）のうちどれが使用されるか、および当該ファクタがどのように使用されるかは、各モジュールの実装に依存する。例えば、ロジックがｎｏｄｅ５およびｎｏｄｅ７をターゲット・ノードをとして返すと想定する。その結果、Ｔａｓｋ３は、すべてのノードではなくｎｏｄｅ５およびｎｏｄｅ７上でのみ実行される。例示として、これらのファクタはシステムＳにおいて以下のように使用されてもよい。

【0066】

本例において、ワークロード・バランシングのファクタに関し、Ｔａｓｋ３はバッチ・ジョブを実行する。プライマリ・ノードのｎｏｄｅ５は、各ノードの現在のＣＰＵ利用率を調査することができよう。バッチ・ジョブは一度だけ実行されればよく、同じシスプレックス（ｎｏｄｅ５、ｎｏｄｅ６、およびｎｏｄｅ７は同じシスプレックス内にある）内のどのノード上でジョブが実行されるべきかは重要でないため、ｎｏｄｅ７のＣＰＵ利用率が最も低ければ、動的処理はｎｏｄｅ７をターゲット・ノードとして返す。その結果、Ｔａｓｋ３は、ワークロード・バランシングを実装するためにｎｏｄｅ７上でのみ実行される。

【0067】

本例において、ヘルス・ステータスのファクタに関し、Ｔａｓｋ３は新たなＣＩＣＳ（ＩＢＭ社の登録商標）アプリケーションをノードにデプロイする。アプリケーションは、現在健全ではないＣＩＣＳ（ＩＢＭ社の登録商標）サーバにデプロイされるべきではない。よって、動的処理は、各ノード内のＣＩＣＳ（ＩＢＭ社の登録商標）サーバのヘルス・ステータスを（例えばＨｅａｌｔｈＣｈｅｃｋ技術を通して）チェックすることができ、すべてのノードは含まないノードのサブセットである、健全なＣＩＣＳ（ＩＢＭ社の登録商標）サーバを有するノードのみを返す。よって、Ｔａｓｋ３は、すべてのノードではなく、返されたサブセットのノード上でのみ実行される。

【0068】

本例において、ソフトウェア・インストール・バージョンのファクタに関し、Ｔａｓｋ３はＣＩＣＳ（ＩＢＭ社の登録商標）アプリケーションをノードにデプロイする。ＣＩＣＳ（ＩＢＭ社の登録商標）アプリケーションは、規定されている最低ＣＩＣＳ（ＩＢＭ社の登録商標）バージョン・ナンバー以上のＣＩＣＳ（ＩＢＭ社の登録商標）バージョン・ナンバーを有する任意のノードにデプロイされることが可能であろう。動的処理は、各ノードに関するＣＩＣＳ（ＩＢＭ社の登録商標）バージョンをスキャンし、次に前述の最低バージョン要件を満たす単数または複数のノードを返すことができるであろう。

【0069】

本例において、システム環境変数のファクタに関し、Ｔａｓｋ３は、規定されたシステム環境変数がＯＮの値を有する場合にパッチを適用する。動的処理は、各ノードの規定されたシステム環境変数をスキャンする。ｎｏｄｅ６およびｎｏｄｅ７の規定されたシステム環境変数がＯＮであり、ｎｏｄｅ５のものはそうでなければ、ｎｏｄｅ６およびｎｏｄｅ７がターゲット・ノードとして返され、Ｔａｓｋ３はｎｏｄｅ６およびｎｏｄｅ７上でのみ実行される。

【0070】

図５は、本発明の実施形態による、マネージド・ノード上にタスクを実装する方法を記載したフローチャートである。図５の方法はステップ５１０～５３０を含む。

【0071】

ステップ５１０は、コンピュータ・システムにおけるＡｎｓｉｂｌｅ制御ノード内のＡｎｓｉｂｌｅエンジンの１つまたは複数のプロセッサにより、ホストの複数のマネージド・ノードのうちの１つまたは複数のマネージド・ノード上でＡｎｓｉｂｌｅモジュールにより実行されるタスクの規定を受信する。

【0072】

ステップ５２０は、ＡｎｓｉｂｌｅモジュールのｈｏｓｔＤｅｃｉｓｉｏｎ属性の属性値に基づき１つまたは複数のマネージド・ノードを１つまたは複数のプロセッサにより決定し、属性値は、ｐｒｉｍａｒｙＮｏｄｅ、ａｌｌＮｏｄｅｓ、およびＤｙｎａｍｉｃからなるグループから選択され、ｐｒｉｍａｒｙＮｏｄｅは、１つまたは複数のマネージド・ノードが複数のマネージド・ノードから選択されたプライマリ・ノードからなることを要求し、ａｌｌＮｏｄｅｓは、１つまたは複数のマネージド・ノードが複数のマネージド・ノードからなることを要求し、Ｄｙｎａｍｉｃは、プライマリ・ノードにより取得された、複数のマネージド・ノードのうちのマネージド・ノードに関する１つまたは複数のファクタの現ステータスを含むランタイム情報に基づき、１つまたは複数のマネージド・ノードが動的に決定されることを要求する。

【0073】

ステップ５３０は、１つまたは複数のマネージド・ノード上でタスクを実行するように、１つまたは複数のプロセッサによりＡｎｓｉｂｌｅモジュールを１つまたは複数のマネージド・ノードに送信する。

【0074】

図６は、本発明の実施形態による、ｈｏｓｔＤｅｃｉｓｉｏｎ属性を処理する方法を記載したフローチャートである。図６のフローチャートはステップ６１０～６７０を含む。

【0075】

ステップ６１０は、ｈｏｓｔＤｅｃｉｓｉｏｎ属性がａｌｌＮｏｄｅｓの属性値を有するかどうかを、Ａｎｓｉｂｌｅエンジンにより判断する。

【0076】

ステップ６１０が、ｈｏｓｔＤｅｃｉｓｉｏｎ属性はａｌｌＮｏｄｅｓの属性値を有すると判断すれば、ステップ６２０においてＡｎｓｉｂｌｅモジュールは、ホストの複数のマネージド・ノードのうちのすべてのマネージド・ノード上でタスクを実行する。

【0077】

ステップ６１０が、ｈｏｓｔＤｅｃｉｓｉｏｎ属性はａｌｌＮｏｄｅｓの属性値を有すると判断しなければ、ｈｏｓｔＤｅｃｉｓｉｏｎ属性はｐｒｉｍａｒｙＮｏｄｅまたはＤｙｎａｍｉｃであり、ステップ６３０が次に実行される。

【0078】

ステップ６３０は、ステップ６３１、ステップ６３２、またはステップ６３３によりプライマリ・ノードを決定する。

【0079】

ステップ６３１は、Ａｎｓｉｂｌｅ制御ノード内のＡｎｓｉｂｌｅインベントリからプライマリ・ノードの識別情報を１つまたは複数のプロセッサにより受信し、Ａｎｓｉｂｌｅインベントリは、複数のマネージド・ノードおよびプライマリ・ノードの識別情報を記憶する。

【0080】

ステップ６３２は、プライマリ・ノードの動的識別情報を１つまたは複数のプロセッサにより受信し、複数のマネージド・ノードは、複数のマネージド・ノードのうちのマネージド・ノードが相互にまたは互いに隔離されるようなパブリック・クラウド上にあり、プライマリ・ノードの動的識別情報を受信することは、各マネージド・ノードから、各マネージド・ノードがプライマリ・ノードであるという通知を受信することを含む。

【0081】

ステップ６３３は、プライマリ・ノードの動的識別情報を１つまたは複数のプロセッサにより受信し、複数のマネージド・ノードは、複数のマネージド・ノードのうちのマネージド・ノードそれぞれが複数のマネージド・ノードのうちの他のマネージド・ノードの存在を認識するようなオンプレミス環境内の同じシスプレックスにあり、プライマリ・ノードの動的識別情報を受信することは、複数のプライマリ・ノードのうちのマネージド・ノードに関する１つまたは複数のファクタの現ステータスに基づくプライマリ・ノードの動的決定を通してプライマリ・ノードの動的識別情報を受信することを含む。一実施形態において、マネージド・ノードに関する１つまたは複数のファクタは、中央処理ユニット（ＣＰＵ）キャパシティ・ウェイト、システム環境変数、およびヘルス・ステータスを含む。

【0082】

ステップ６４０は、ｈｏｓｔＤｅｃｉｓｉｏｎ属性がｐｒｉｍａｒｙＮｏｄｅの属性値を有するか、またはＤｙｎａｍｉｃの属性値を有するかを、Ａｎｓｉｂｌｅエンジンにより判断する。

【0083】

ステップ６４０が、ｈｏｓｔＤｅｃｉｓｉｏｎ属性はｐｒｉｍａｒｙＮｏｄｅの属性値を有すると判断すれば、ステップ６５０においてＡｎｓｉｂｌｅモジュールは、プライマリ・ノード上でタスクを実行する。

【0084】

ステップ６４０が、ｈｏｓｔＤｅｃｉｓｉｏｎ属性はＤｙｎａｍｉｃの属性値を有すると判断すれば、ステップ６６０が次に実行される。

【0085】

ステップ６６０は、タスクが実行される１つまたは複数のマネージド・ノードを、複数のマネージド・ノードのうちのマネージド・ノードに関する１つまたは複数のファクタの現ステータスを含むランタイム情報に基づき、１つまたは複数のプロセッサにより動的に決定する。一実施形態において、マネージド・ノードに関する１つまたは複数のファクタは、システム環境変数、ヘルス・データ、およびワークロード・ステータスを含む。

【0086】

ステップ６７０において、Ａｎｓｉｂｌｅモジュールは、ステップ６６０において動的に決定された１つまたは複数のマネージド・ノード上でタスクを実行する。

【0087】

一実施形態において、タスクが実行される１つまたは複数のマネージド・ノードを動的に決定することは、プライマリ・ノードがランタイム情報に基づき１つまたは複数のマネージド・ノードを動的に決定した後に、１つまたは複数のマネージド・ノードのリストをプライマリ・ノードから１つまたは複数のプロセッサにより受信することを含む。

【0088】

一実施形態において、タスクが実行される１つまたは複数のマネージド・ノードを動的に決定することは、ランタイム情報をプライマリ・ノードから１つまたは複数のプロセッサにより受信することと、プライマリ・ノードから受信されたランタイム情報に基づき１つまたは複数のプロセッサにより１つまたは複数のマネージド・ノードを動的に決定することとを含む。

【0089】

一実施形態において、Ａｎｓｉｂｌｅ制御ノードは、ＡｎｓｉｂｌｅモジュールのｈｏｓｔＤｅｃｉｓｉｏｎ属性を規定するインベントリ・ファイルを含む。

【0090】

一実施形態において、Ａｎｓｉｂｌｅ制御ノードは、Ａｎｓｉｂｌｅモジュールと、実行されるタスクに関連してＡｎｓｉｂｌｅエンジンにより要求されるかまたは必要とされる特化された機能を実行するように構成されたプラグインとを含む、Ａｎｓｉｂｌｅギャラクシーをさらに含む。

【0091】

一実施形態において、Ａｎｓｉｂｌｅモジュールは、１つまたは複数のマネージド・ノード上でタスクを実行する。

【0092】

図７は、本発明の実施形態によるコンピュータ・システム９０を示す。

【0093】

コンピュータ・システム９０は、プロセッサ９１、プロセッサ９１に結合された入力デバイス９２、プロセッサ９１に結合された出力デバイス９３、ならびにプロセッサ９１にそれぞれ結合されたメモリ・デバイス９４および９５を含む。プロセッサ９１は、１つまたは複数のプロセッサを表現しており、単一のプロセッサまたは複数のプロセッサを示し得る。入力デバイス９２は特に、キーボード、マウス、カメラ、タッチスクリーンなどとされてもよいし、またはその組み合わせとされてもよい。出力デバイス９３は特に、プリンタ、プロッタ、コンピュータ・スクリーン、磁気テープ、取り外し可能なハード・ディスク、フレキシブル・ディスクなどとされてもよいし、またはその組み合わせとされてもよい。メモリ・デバイス９４および９５はそれぞれ、特に、ハード・ディスク、フレキシブル・ディスク、磁気テープ、コンパクト・ディスク（ＣＤ）もしくはデジタル・ビデオ・ディスク（ＤＶＤ）などの光学ストレージ、動的ランダム・アクセス・メモリ（ＤＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）、またはその組み合わせとされてもよい。メモリ・デバイス９５はコンピュータ・コード９７を含む。コンピュータ・コード９７は、本発明の実施形態を実行するアルゴリズムを含む。プロセッサ９１はコンピュータ・コード９７を実行する。メモリ・デバイス９４は入力データ９６を含む。入力データ９６は、コンピュータ・コード９７により要求される入力を含む。出力デバイス９３は、コンピュータ・コード９７からの出力を表示する。メモリ・デバイス９４および９５の一方または両方（またはリード・オンリ・メモリ・デバイス９８などの１つまたは複数のさらに別のメモリ・デバイス）は、アルゴリズムを含んでもよく、コンピュータ可読プログラム・コードが具現化されている、もしくは他のデータが記憶されている、またはその両方のコンピュータ使用可能媒体（またはコンピュータ可読媒体またはプログラム・ストレージ・デバイス）として使用されてもよく、コンピュータ可読プログラム・コードは、コンピュータ・コード９７を含む。一般に、コンピュータ・システム９０のコンピュータ・プログラム製品（あるいは製造品）は、コンピュータ使用可能媒体（またはプログラム・ストレージ・デバイス）を含み得る。

【0094】

一部の実施形態において、ハード・ドライブ、光学ディスク、またはその他書き込み可能、書き換え可能、もしくは取り外し可能ハードウェア・メモリ・デバイス９５に記憶されてそこからアクセスされるのではなく、記憶されるコンピュータ・プログラム・コード９９（例えばアルゴリズムを含む）は、リード・オンリ・メモリ（ＲＯＭ）デバイス９８などの静的な取り外し不能のリード・オンリ・ストレージ媒体上に記憶されてもよいし、またはそのような静的な取り外し不能のリード・オンリ媒体９８からプロセッサ９１により直接アクセスされてもよい。同じく、一部の実施形態において、記憶されるコンピュータ・プログラム・コード９７は、コンピュータ可読ファームウェア９８として記憶されてもよいし、またはハード・ドライブもしくは光学ディスクなどのより動的なもしくは取り外し可能なハードウェア・データ・ストレージ・デバイス９５からではなく、かかるファームウェア９８からプロセッサ９１により直接アクセスされてもよい。

【0095】

さらに、本発明のコンポーネントの任意のものが、プラグイン・コンポーネントに関連する相互参照メトリクスに関連するソフトウェア技術を改善し、ソフトウェア・コード・モジュールを生成し、ターゲット・クラウド・コンポーネントの動作機能性を可能にすることをオファーするサービス・サプライヤにより作成、統合、ホスト、維持、デプロイ、管理、サービス提供などされることが可能であろう。よって、本発明は、コンピュータ・システム９０にコンピュータ可読コードを統合することを含む、コンピューティング・インフラストラクチャのデプロイ、作成、統合、ホスト、もしくは維持、またはその組み合わせを行うためのプロセスを開示し、コンピュータ・システム９０と組み合わされたコードは、プラグイン・コンポーネントに関連する相互参照メトリクスに関連したソフトウェア技術を改善するプロセスを可能にし、ソフトウェア・コード・モジュールを生成し、ターゲット・クラウド・コンポーネントの動作機能性を可能にする方法を実行できる。別の実施形態では、本発明は、契約、宣伝、もしくは手数料、またはその組み合わせに基づき本発明のプロセス・ステップを実行するビジネス方法を提供する。つまり、ソリューション・インテグレータなどのサービス・プロバイダは、プラグイン・コンポーネントに関連する相互参照メトリクスに関連したソフトウェア技術を改善し、ソフトウェア・コード・モジュールを生成し、ターゲット・クラウド・コンポーネントの動作機能性を可能にするプロセスを可能にすることをオファーすることが可能であろう。このケースでは、サービス・サプライヤは、１つまたは複数の顧客に対して本発明のプロセス・ステップを実行するコンピュータ・インフラストラクチャを作成、維持、サポートなどすることができる。見返りとして、サービス・サプライヤは、契約もしくは手数料の取り決めもしくはその両方に従って顧客（単数または複数）から支払いを受けること、もしくは１つまたは複数のサード・パーティに対する宣伝コンテンツの販売からの支払いを受けること、またはその両方ができる。

【0096】

図７は、コンピュータ・システム９０を、ハードウェアとソフトウェアとの特定の構成として示すが、当業者には周知であると考えられるハードウェアとソフトウェアとの任意の構成が、上述された目的のために、図７の特定のコンピュータ・システム９０とともに利用されてよい。例えばメモリ・デバイス９４および９５は、独立したメモリ・デバイスではなく、単一のメモリ・デバイスの一部であってもよい。

【0097】

本発明は、可能な任意の技術的詳細レベルで統合された、システム、方法、もしくはコンピュータ・プログラム製品、またはその組み合わせとされ得る。コンピュータ・プログラム製品は、プロセッサに本発明の各側面を実行させるコンピュータ可読プログラム命令を有する１つまたは複数のコンピュータ可読ストレージ媒体を含んでもよい。

【0098】

コンピュータ可読ストレージ媒体は、命令実行デバイスにより使用される命令を保持および記憶できる有形のデバイスとすることができる。コンピュータ可読ストレージ媒体は、例えば、電子ストレージ・デバイス、磁気ストレージ・デバイス、光学ストレージ・デバイス、電磁ストレージ・デバイス、半導体ストレージとされ得るが、これらに限定されない。コンピュータ可読ストレージ媒体は、命令実行デバイスにより使用される命令を保持および記憶できる有形のデバイスとすることができる。コンピュータ可読ストレージ媒体は、例えば、電子ストレージ・デバイス、磁気ストレージ・デバイス、光学ストレージ・デバイス、電磁ストレージ・デバイス、半導体ストレージ・デバイス、または前述のものの任意の適切な組み合わせとされ得るが、これらに限定されない。コンピュータ可読ストレージ媒体のより具体的な例の網羅的でないリストは、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）、消去可能プログラマブル・リード・オンリ・メモリ（ＥＰＲＯＭ）またはフラッシュ・メモリ）、静的ランダム・アクセス・メモリ（ＳＲＡＭ）、ポータブル・コンパクト・ディスク・リード・オンリ・メモリ（ＣＤ－ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、メモリ・スティック、フレキシブル・ディスク、パンチ・カード、または命令が記録された溝の中の隆起構造などの機械的にエンコードされたデバイス、および前述のものの任意の適切な組み合わせを含む。本願明細書で使用されるとき、コンピュータ可読ストレージ媒体は、電波もしくはその他自由に伝搬する電磁波、導波路もしくはその他伝送媒体を伝搬する電磁波（例えば光ファイバ・ケーブルを通過する光パルス）、またはワイヤを介して伝送される電気信号など、本質的に一時的な信号であるとは解釈されないものとする。

【0099】

本願明細書に記載されたコンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体から個々のコンピューティング／処理デバイスに、または例えばインターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、もしくはワイヤレス・ネットワーク、またはその組み合わせなどのネットワークを介して外部コンピュータもしくは外部ストレージ・デバイスに、ダウンロード可能である。ネットワークは、銅製伝送ケーブル、光伝送ファイバ、ワイヤレス伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、もしくはエッジ・サーバ、またはその組み合わせを含み得る。各コンピューティング／処理デバイスのネットワーク・アダプタ・カードまたはネットワーク・インターフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、コンピュータ可読プログラム命令を個々のコンピューティング／処理デバイス内のコンピュータ可読ストレージ媒体に記憶するために転送する。

【0100】

本発明の動作を実行するコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、集積回路の設定データ、または、Ｓｍａｌｌｔａｌｋ（登録商標）、Ｃ＋＋、もしくは同様のものなどのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語もしくは同様のプログラミング言語などの手続き型プログラミング言語を含む、１つまたは複数のプログラミング言語の任意の組み合わせで記述されたソース・コードもしくはオブジェクト・コードのいずれかであってもよい。コンピュータ可読プログラム命令は、完全にユーザのコンピュータ上で実行されても、部分的にユーザのコンピュータ上で実行されても、スタンドアロン・ソフトウェア・パッケージとして実行されても、部分的にユーザのコンピュータ上で且つ部分的にリモート・コンピュータ上で実行されても、または完全にリモート・コンピュータもしくはサーバ上で実行されてもよい。後者のシナリオでは、ローカル・エリア・ネットワーク（ＬＡＮ）もしくはワイド・エリア・ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを介してリモート・コンピュータがユーザのコンピュータに接続されてもよいし、または（例えばインターネット・サービス・プロバイダを使用しインターネットを介して）外部コンピュータに接続されてもよい。一部の実施形態において、本発明の各側面を実行するために、例えばプログラマブル・ロジック回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、またはプログラマブル・ロジック・アレイ（ＰＬＡ）を含む電子回路が、電子回路をパーソナライズするためコンピュータ可読プログラム命令の状態情報を利用することによりコンピュータ可読プログラム命令を実行してもよい。

【0101】

本発明の各側面は、本発明の実施形態による方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図もしくはブロック図またはその両方を参照して本願明細書に記載されている。当然のことながら、フローチャート図もしくはブロック図またはその両方の各ブロック、およびフローチャート図もしくはブロック図またはその両方の複数ブロックの組み合わせは、コンピュータ可読プログラム命令により実装可能である。

【0102】

マシンをもたらすよう、こうしたコンピュータ可読プログラム命令が、コンピュータのプロセッサまたはその他プログラマブル・データ処理装置に提供されて、この命令が、コンピュータまたはその他プログラマブル・データ処理装置のプロセッサにより実行されて、フローチャートもしくはブロック図またはその両方の１つもしくは複数のブロックに規定された機能／動作を実装する手段を作り出すようにすることもできる。特定の形で機能するようコンピュータ、プログラマブル・データ処理装置、もしくはその他デバイス、またはその組み合わせに指示することができる当該コンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体に記憶されて、命令を記憶されたコンピュータ可読ストレージ媒体が、フローチャートもしくはブロック図またはその両方の１つもしくは複数のブロックに規定された機能／動作の各側面を実装する命令を含む製造品を含むようにすることもできる。

【0103】

さらに、コンピュータ可読プログラム命令は、コンピュータ、その他プログラマブル・データ処理装置、またはその他デバイスにロードされて、コンピュータ、その他プログラマブル装置、またはその他デバイス上で一連の動作ステップが実行されるようにしてコンピュータに実装されるプロセスをもたらし、コンピュータ、その他プログラマブル装置、またはその他デバイス上で実行される命令が、フローチャートもしくはブロック図またはその両方の１つもしくは複数のブロックに規定された機能／動作を実装するようにすることもできる。

【0104】

各図面のフローチャートおよびブロック図は、本発明の様々な実施形態によるシステム、方法、およびコンピュータ・プログラム製品の考えられる実装のアーキテクチャ、機能性、および動作を示す。この関連で、フローチャートまたはブロック図の各ブロックは、規定された論理機能（単数または複数）を実装する１つまたは複数の実行可能命令を含むモジュール、セグメント、または命令の一部を表現し得る。一部の代わりの実装では、ブロックに示されている機能が、図面に示されているのとは異なる順序で生じてもよい。例えば、関連する機能性次第で、連続して示されている２つのブロックが実際には１つのステップとして実現されてもよく、同時に実行されてもよく、事実上同時に実行されてもよく、一部または全体が時間的に重複する形で実行されてもよいし、または各ブロックが逆順で実行されることがあってもよい。さらに、ブロック図もしくはフローチャート図またはその両方の各ブロック、およびブロック図もしくはフローチャート図またはその両方の複数ブロックの組み合わせは、規定された機能もしくは動作を実行するかまたは専用ハードウェアおよびコンピュータ命令の組み合わせを実行する、専用ハードウェア・ベースのシステムにより実装できるということに留意されたい。

【0105】

本発明のコンピュータ・プログラム製品は、コンピュータ可読プログラム・コードが記憶された１つまたは複数のコンピュータ可読ハードウェア・ストレージ・デバイスを含み、前記プログラム・コードは、本発明の方法を実装するためにコンピュータ・システムの１つまたは複数のプロセッサにより実行可能な命令を含む。

【0106】

本発明のコンピュータ・システムは、１つまたは複数のプロセッサ、１つまたは複数のメモリ、および１つまたは複数のコンピュータ可読ハードウェア・ストレージ・デバイスを含み、前記１つまたは複数のハードウェア・ストレージ・デバイスは、本発明の方法を実装するために１つまたは複数のメモリを介して１つまたは複数のプロセッサにより実行可能なプログラム・コードを含む。

【0107】

クラウド・コンピューティング環境
当然のことながら、本開示は、クラウド・コンピューティングについての詳細な記載を含むものの、本願明細書に記載する教示の実装は、クラウド・コンピューティング環境に限定されない。むしろ本発明の実施形態は、現在周知の、または後に開発される、ほかの任意のタイプのコンピューティング環境に関連して実装することができる。

【0108】

クラウド・コンピューティングは、最小限の管理作業またはサービスのプロバイダとの対話で迅速にプロビジョニングおよびリリースできる、構成可能なコンピューティング・リソース（例えばネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、およびサービス）の共有プールに対する、オンデマンドの便利なネットワーク・アクセスを実現するサービス供給のモデルである。このクラウド・モデルは、少なくとも５つの特徴と、少なくとも３つのサービス・モデルと、少なくとも４つのデプロイメント・モデルとを含み得る。

【0109】

特徴は以下の通りである。

【0110】

オンデマンド・セルフサービス：クラウド消費者は、サーバ時間およびネットワーク・ストレージなどのコンピューティング能力を、必要に応じて自動的に、サービスのプロバイダとの人的対話の必要なく一方的にプロビジョニングできる。

【0111】

広範なネットワーク・アクセス：各能力はネットワーク上で利用可能であり、ヘテロジニアスなシンまたはシック・クライアント・プラットフォーム（例えばモバイル電話、ラップトップ、およびＰＤＡ（携帯情報端末））による使用を促進する標準のメカニズムを介してアクセスされる。

【0112】

リソース・プーリング：プロバイダのコンピューティング・リソースは、マルチ・テナント・モデルを使用して複数の消費者にサービスを提供するようプールされ、種々の物理リソースおよび仮想リソースが要求に応じて動的に割り当ておよび再割り当てされる。一般に、消費者は、提供されるリソースの正確な場所についての制御権または知識を有しないという点で、場所に依存しない感覚があるが、より高い抽象化レベルでは場所（例えば国、州、またはデータセンター）を指定できることもある。

【0113】

迅速な伸縮性：各能力は、一部のケースでは自動的に、迅速且つ伸縮自在にプロビジョニングされて素早くスケール・アウトすること、および迅速にリリースされて素早くスケール・インすることができる。多くの場合、消費者には、プロビジョニングに利用可能な各能力は無制限であるように見え、任意の量をいつでも購入できる。

【0114】

測定されるサービス：クラウド・システムは、サービスのタイプ（例えばストレージ、処理、帯域幅、およびアクティブなユーザ・アカウント）に適した或る抽象化レベルでの計測能力を活用することによって、リソースの使用を自動的に制御および最適化する。リソース使用量は、監視、制御、およびレポート可能であり、利用されるサービスのプロバイダおよび消費者の双方に透明性が提供される。

【0115】

サービス・モデルは以下の通りである。

【0116】

ソフトウェア・アズ・ア・サービス（ＳａａＳ：Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）：消費者に提供される能力は、クラウド・インフラストラクチャ上で実行されているプロバイダのアプリケーションの使用である。アプリケーションは、ウェブ・ブラウザなどのシン・クライアント・インターフェース（例えばウェブ・ベースの電子メール）を介して様々なクライアント・デバイスからアクセス可能である。消費者は、ネットワーク、サーバ、オペレーティング・システム、ストレージを含む基礎をなすクラウド・インフラストラクチャも、個々のアプリケーションの能力さえも管理または制御しないが、限られたユーザ別のアプリケーション構成設定は例外とされることもある。

【0117】

プラットフォーム・アズ・ア・サービス（ＰａａＳ：Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）：消費者に提供される能力は、プロバイダによってサポートされるプログラミング言語およびツールを使用して作成された、消費者が作成または入手したアプリケーションを、クラウド・インフラストラクチャ上にデプロイすることである。消費者は、ネットワーク、サーバ、オペレーティング・システム、またはストレージを含む基礎をなすクラウド・インフラストラクチャの管理または制御は行わないが、デプロイされたアプリケーション、さらに場合によってはアプリケーション・ホスティング環境構成を制御する。

【0118】

インフラストラクチャ・アズ・ア・サービス（ＩａａＳ：Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）：消費者に提供される能力は、処理、ストレージ、ネットワーク、およびその他基本的なコンピューティング・リソースのプロビジョニングであり、消費者はそこで、オペレーティング・システムおよびアプリケーションを含み得る任意のソフトウェアをデプロイし、実行することができる。消費者は、基礎をなすクラウド・インフラストラクチャの管理または制御は行わないが、オペレーティング・システム、ストレージ、デプロイされたアプリケーションを制御し、場合によっては選ばれたネットワーキング・コンポーネント（例えばホスト・ファイアウォール）を限定的に制御する。

【0119】

デプロイメント・モデルは以下の通りである。

【0120】

プライベート・クラウド：クラウド・インフラストラクチャは或る組織のみのために運用される。組織またはサード・パーティによって管理可能であり、オンプレミスまたはオフプレミスに存在し得る。

【0121】

コミュニティ・クラウド：クラウド・インフラストラクチャはいくつかの組織によって共有され、共有される関心事（例えばミッション、セキュリティ要件、ポリシー、およびコンプライアンス意識）を有する特定のコミュニティをサポートする。組織またはサード・パーティによって管理可能であり、オンプレミスまたはオフプレミスに存在し得る。

【0122】

パブリック・クラウド：クラウド・インフラストラクチャは公衆または大規模業界団体に利用可能にされ、クラウド・サービスを販売する組織によって所有される。

【0123】

ハイブリッド・クラウド：クラウド・インフラストラクチャは、２つ以上のクラウド（プライベート、コミュニティ、またはパブリック）の複合であり、各クラウドは一意のエンティティのままであるが、データおよびアプリケーションの移植性（例えばクラウド間のロード・バランシングのためのクラウド・バースト）を実現する標準またはプロプライエタリ技術によってバインドされる。

【0124】

クラウド・コンピューティング環境は、サービス指向であり、ステートレス性、疎結合性、モジュール性、および意味的相互運用性に焦点を合わせる。クラウド・コンピューティングの中心には、相互接続されたノードのネットワークを含むインフラストラクチャがある。

【0125】

以下、図８を参照する。例示のクラウド・コンピューティング環境５０が示されている。図のように、クラウド・コンピューティング環境５０は、１つまたは複数のクラウド・コンピューティング・ノード４０を含み、例えば携帯情報端末（ＰＤＡ）または携帯電話５４Ａ、デスクトップ・コンピュータ５４Ｂ、ラップトップ・コンピュータ５４Ｃ、もしくは自動車用コンピュータ・システム５４Ｎ、またはその組み合わせなど、クラウド消費者により使用されるローカル・コンピューティング・デバイスが、クラウド・コンピューティング・ノード４０と通信できる。ノード４０は、互いに通信してもよい。ノード４０は、上述のプライベート、コミュニティ、パブリック、もしくはハイブリッド・クラウド、またはその組み合わせなどの１つまたは複数のネットワークにおいて物理的または仮想的にグループ化され得る（図示せず）。これにより、クラウド・コンピューティング環境５０は、インフラストラクチャ、プラットフォーム、もしくはソフトウェア、またはその組み合わせをサービスとして提供することができ、それらのためにクラウド消費者がローカル・コンピューティング・デバイス上にリソースを維持する必要はない。当然のことながら、図８に示されているコンピューティング・デバイス５４Ａ～Ｎのタイプは、例示のみを目的としており、コンピューティング・ノード４０およびクラウド・コンピューティング環境５０は、任意のタイプのネットワークもしくはネットワーク・アドレス指定可能な接続（例えばウェブ・ブラウザを使用）またはその両方によって任意のタイプのコンピュータ化されたデバイスと通信できる。

【0126】

以下、図９を参照する。クラウド・コンピューティング環境５０（図８）により提供される機能抽象化層のセットが示されている。図９に示されているコンポーネント、層、および機能は例示のみを目的としており、本発明の実施形態はそれに限定されないことをあらかじめ理解されたい。図のように、以下の層および対応する機能が提供される。

【0127】

ハードウェアおよびソフトウェア層６０は、ハードウェア・コンポーネントおよびソフトウェア・コンポーネントを含む。ハードウェア・コンポーネントの例には、メインフレーム６１、ＲＩＳＣ（縮小命令セット・コンピュータ・アーキテクチャ・ベースのサーバ６２、サーバ６３、ブレード・サーバ６４、ストレージ・デバイス６５、ならびにネットワークおよびネットワーキング・コンポーネント６６が含まれる。一部の実施形態においてソフトウェア・コンポーネントは、ネットワーク・アプリケーション・サーバ・ソフトウェア６７およびデータベース・ソフトウェア６８を含む。

【0128】

仮想化層７０は、仮想サーバ７１、仮想ストレージ７２、仮想プライベート・ネットワークを含む仮想ネットワーク７３、仮想アプリケーションおよびオペレーティング・システム７４、ならびに仮想クライアント７５を例とする仮想エンティティが提供され得る抽象化層を提供する。

【0129】

一例では、管理層８０は下記の機能を提供し得る。リソース・プロビジョニング８１は、クラウド・コンピューティング環境の中でタスクを実行するように利用されるコンピューティング・リソースおよびその他のリソースの動的な調達を提供する。計測および価格決定８２は、クラウド・コンピューティング環境内でリソースが利用されるときのコストの追跡と、こうしたリソースの消費に対する請求またはインボイス作成とを提供する。一例では、これらのリソースはアプリケーション・ソフトウェア・ライセンスを含んでもよい。セキュリティは、クラウド消費者およびタスクのアイデンティティ確認、ならびにデータおよびその他のリソースの保護を提供する。ユーザ・ポータル８３は、消費者およびシステム管理者に、クラウド・コンピューティング環境に対するアクセスを提供する。サービス水準管理８７は、必要なサービス水準が満たされるようにクラウド・コンピューティング・リソースの割り当ておよび管理を提供する。サービス水準合意（ＳＬＡ：Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）計画および達成８８は、ＳＬＡに従い将来の要求が予想されるクラウド・コンピューティング・リソースの事前準備および調達を提供する。

【0130】

ワークロード層１０１は、クラウド・コンピューティング環境が利用される目的となり得る機能性の例を提供する。この層から提供され得るワークロードおよび機能の例には、マッピングおよびナビゲーション３１、ソフトウェア開発およびライフサイクル管理３２、仮想教室教育配信３３、データ分析処理３４、トランザクション処理３５、およびマネージド・ノード上へのタスク実装３６がある。

【0131】

本願明細書に記載された本発明の例および実施形態は、例示目的で提示されたものであり、網羅的であると解釈されるべきではない。本発明の実施形態は、例示のために本願明細書に記載されたが、当業者には多数の変形および変更が明白となるであろう。本願明細書の本発明の記載は、本発明の実践的な応用、および既知の技術、コンピュータ・システム、もしくは製品、またはその組み合わせと比べた本発明の技術的改善を示すために、これらの例および実施形態の基礎をなす原理を説明している。

【図1】

【図2】

【図3A】

【図3B】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【手続補正書】

【提出日】2024-04-04

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

マネージド・ノード上にタスクを実装する方法であって、
コンピュータ・システムにおけるＡｎｓｉｂｌｅ制御ノード内のＡｎｓｉｂｌｅエンジンの１つまたは複数のプロセッサにより、ホストの複数のマネージド・ノードのうちの１つまたは複数のマネージド・ノード上でＡｎｓｉｂｌｅモジュールにより実行されるタスクの規定を受信することと、
前記ＡｎｓｉｂｌｅモジュールのｈｏｓｔＤｅｃｉｓｉｏｎ属性の属性値に基づき前記１つまたは複数のマネージド・ノードを前記１つまたは複数のプロセッサにより決定することであって、前記属性値は、ｐｒｉｍａｒｙＮｏｄｅ、ａｌｌＮｏｄｅｓ、およびＤｙｎａｍｉｃからなる群から選択され、ｐｒｉｍａｒｙＮｏｄｅは、前記１つまたは複数のマネージド・ノードが前記複数のマネージド・ノードから選択されたプライマリ・ノードからなることを要求し、ａｌｌＮｏｄｅｓは、前記１つまたは複数のマネージド・ノードが前記複数のマネージド・ノードからなることを要求し、Ｄｙｎａｍｉｃは、前記プライマリ・ノードにより取得された、前記複数のマネージド・ノードのうちの前記マネージド・ノードに関する１つまたは複数のファクタの現ステータスを含むランタイム情報に基づき、前記１つまたは複数のマネージド・ノードが動的に決定されることを要求する、前記決定することと、
前記１つまたは複数のマネージド・ノード上で前記タスクを実行するように、前記１つまたは複数のプロセッサにより前記Ａｎｓｉｂｌｅモジュールを前記１つまたは複数のマネージド・ノードに送信することと
を含む、方法。

【請求項2】

前記属性値は、ｐｒｉｍａｒｙＮｏｄｅまたはＤｙｎａｍｉｃのいずれかである、請求項１に記載の方法。

【請求項3】

前記Ａｎｓｉｂｌｅ制御ノード内のＡｎｓｉｂｌｅインベントリから前記プライマリ・ノードの識別情報を前記１つまたは複数のプロセッサにより受信すること
を含み、前記Ａｎｓｉｂｌｅインベントリは、前記複数のマネージド・ノードおよび前記プライマリ・ノードの前記識別情報を記憶する、請求項２に記載の方法。

【請求項4】

エンド・ユーザにより前記Ａｎｓｉｂｌｅインベントリに記憶される前記プライマリ・ノードの静的識別情報を前記１つまたは複数のプロセッサにより前記エンド・ユーザから受信すること
を含む、請求項３に記載の方法。

【請求項5】

前記プライマリ・ノードの動的識別情報を前記１つまたは複数のプロセッサにより受信すること
を含む、請求項２に記載の方法。

【請求項6】

前記複数のマネージド・ノードは、前記複数のマネージド・ノードのうちの前記マネージド・ノードが相互にまたは互いに隔離されるようなパブリック・クラウド上にあり、前記プライマリ・ノードの前記動的識別情報を前記受信することは、
各マネージド・ノードから、前記各マネージド・ノードが前記プライマリ・ノードであるという通知を受信すること
を含む、請求項５に記載の方法。

【請求項7】

前記複数のマネージド・ノードは、前記複数のマネージド・ノードのうちの前記マネージド・ノードそれぞれが前記複数のマネージド・ノードのうちの他の前記マネージド・ノードの存在を認識するようなオンプレミス環境内の同じシスプレックスにあり、前記プライマリ・ノードの前記動的識別情報を前記受信することは、
複数のマネージド・ノードのうちのマネージド・ノードに関する前記１つまたは複数のファクタの前記現ステータスに基づく前記プライマリ・ノードの動的決定を通して前記プライマリ・ノードの前記動的識別情報を受信すること
を含む、請求項５に記載の方法。

【請求項8】

前記マネージド・ノードに関する前記１つまたは複数のファクタは、中央処理ユニット（ＣＰＵ）キャパシティ・ウェイト、システム環境変数、およびヘルス・ステータスを含む、請求項７に記載の方法。

【請求項9】

前記属性値は、ｐｒｉｍａｒｙＮｏｄｅである、請求項２に記載の方法。

【請求項10】

前記属性値は、Ｄｙｎａｍｉｃであり、前記方法は、
前記タスクが実行される前記１つまたは複数のマネージド・ノードを、前記複数のマネージド・ノードのうちの前記マネージド・ノードに関する前記１つまたは複数のファクタの前記現ステータスを含む前記ランタイム情報に基づき、前記１つまたは複数のプロセッサにより動的に決定すること
を含む、請求項２に記載の方法。

【請求項11】

前記マネージド・ノードに関する前記１つまたは複数のファクタは、システム環境変数、ヘルス・データ、およびワークロード・ステータスを含む、請求項１０に記載の方法。

【請求項12】

前記タスクが実行される前記１つまたは複数のマネージド・ノードを前記動的に決定することは、
前記プライマリ・ノードが前記ランタイム情報に基づき前記１つまたは複数のマネージド・ノードを動的に決定した後に、前記１つまたは複数のマネージド・ノードのリストを前記プライマリ・ノードから前記１つまたは複数のプロセッサにより受信すること
を含む、請求項１０に記載の方法。

【請求項13】

前記タスクが実行される前記１つまたは複数のマネージド・ノードを前記動的に決定することは、
前記ランタイム情報を前記プライマリ・ノードから前記１つまたは複数のプロセッサにより受信することと、
前記プライマリ・ノードから受信された前記ランタイム情報に基づき前記１つまたは複数のプロセッサにより前記１つまたは複数のマネージド・ノードを動的に決定することと
を含む、請求項１０に記載の方法。

【請求項14】

前記Ａｎｓｉｂｌｅ制御ノードは、前記ＡｎｓｉｂｌｅモジュールのｈｏｓｔＤｅｃｉｓｉｏｎ属性を規定する設定ファイルをさらに含む、請求項１に記載の方法。

【請求項15】

前記Ａｎｓｉｂｌｅ制御ノードは、前記Ａｎｓｉｂｌｅモジュールと、実行される前記タスクに関連して前記Ａｎｓｉｂｌｅエンジンにより要求されるかまたは必要とされる特化された機能を実行するように構成されたプラグインとを含む、Ａｎｓｉｂｌｅギャラクシーをさらに含む、請求項１に記載の方法。

【請求項16】

前記１つまたは複数のマネージド・ノード上で前記Ａｎｓｉｂｌｅモジュールにより前記タスクを実行すること
を含む、請求項１に記載の方法。

【請求項17】

コンピュータ可読プログラム・コードを含むコンピュータ・プログラムであって、前記プログラム・コードは、マネージド・ノード上にタスクを実装する方法を実装するようにコンピュータ・システムにおけるＡｎｓｉｂｌｅ制御ノード内のＡｎｓｉｂｌｅエンジンの１つまたは複数のプロセッサにより実行可能な命令を含み、前記方法は、
ホストの複数のマネージド・ノードのうちの１つまたは複数のマネージド・ノード上でＡｎｓｉｂｌｅモジュールにより実行されるタスクの規定を前記１つまたは複数のプロセッサにより受信することと、
前記ＡｎｓｉｂｌｅモジュールのｈｏｓｔＤｅｃｉｓｉｏｎ属性の属性値に基づき前記１つまたは複数のマネージド・ノードを前記１つまたは複数のプロセッサにより決定することであって、前記属性値は、ｐｒｉｍａｒｙＮｏｄｅ、ａｌｌＮｏｄｅｓ、およびＤｙｎａｍｉｃからなるグループから選択され、ｐｒｉｍａｒｙＮｏｄｅは、前記１つまたは複数のマネージド・ノードが前記複数のマネージド・ノードから選択されたプライマリ・ノードからなることを要求し、ａｌｌＮｏｄｅｓは、前記１つまたは複数のマネージド・ノードが前記複数のマネージド・ノードからなることを要求し、Ｄｙｎａｍｉｃは、前記プライマリ・ノードにより取得された、前記複数のマネージド・ノードのうちの前記マネージド・ノードに関する１つまたは複数のファクタの現ステータスを含むランタイム情報に基づき、前記１つまたは複数のマネージド・ノードが動的に決定されることを要求する、前記決定することと、
前記１つまたは複数のマネージド・ノード上で前記タスクを実行するように、前記１つまたは複数のプロセッサにより前記Ａｎｓｉｂｌｅモジュールを前記１つまたは複数のマネージド・ノードに送信することと
を含む、コンピュータ・プログラム。

【請求項18】

請求項１７に記載のコンピュータ・プログラムを記録した、コンピュータ可読なストレージ媒体。

【請求項19】

コンピュータ・システムにおけるＡｎｓｉｂｌｅ制御ノード内のＡｎｓｉｂｌｅエンジンの１つまたは複数のプロセッサと、１つまたは複数のメモリと、１つまたは複数のコンピュータ可読ハードウェア・ストレージ・デバイスとを含む前記コンピュータ・システムであって、前記１つまたは複数のハードウェア・ストレージ・デバイスは、マネージド・ノード上にタスクを実装する方法を実装するように前記１つまたは複数のメモリを介して前記１つまたは複数のプロセッサにより実行可能なプログラム・コードを含み、前記方法は、
ホストの複数のマネージド・ノードのうちの１つまたは複数のマネージド・ノードにより実行されるタスクの規定を前記１つまたは複数のプロセッサにより受信することと、
前記複数のマネージド・ノード上で前記タスクを実行するように構成されたＡｎｓｉｂｌｅモジュールのｈｏｓｔＤｅｃｉｓｉｏｎ属性の属性値に基づき前記１つまたは複数のマネージド・ノードを前記１つまたは複数のプロセッサにより決定することであって、前記属性値は、ｐｒｉｍａｒｙＮｏｄｅ、ａｌｌＮｏｄｅｓ、およびＤｙｎａｍｉｃからなるグループから選択され、ｐｒｉｍａｒｙＮｏｄｅは、前記１つまたは複数のマネージド・ノードが前記複数のマネージド・ノードから選択されたプライマリ・ノードからなることを要求し、ａｌｌＮｏｄｅｓは、前記１つまたは複数のマネージド・ノードが前記複数のマネージド・ノードからなることを要求し、Ｄｙｎａｍｉｃは、前記プライマリ・ノードにより取得された、前記複数のマネージド・ノードのうちの前記マネージド・ノードに関する１つまたは複数のファクタの現ステータスを含むランタイム情報に基づき、前記１つまたは複数のマネージド・ノードが動的に決定されることを要求する、前記決定することと、
前記１つまたは複数のマネージド・ノード上で前記タスクを実行するように、前記１つまたは複数のプロセッサにより前記Ａｎｓｉｂｌｅモジュールを前記１つまたは複数のマネージド・ノードに送信することと
を含む、コンピュータ・システム。

【国際調査報告】