知財求人 - 知財ポータルサイト「IP Force」
▶ インターナショナル・ビジネス・マシーンズ・コーポレーションの特許一覧
特表2024-505415大規模クラウド・コンピューティング・システムのヘルスステータスのモニタリング
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-02-06
(54)【発明の名称】大規模クラウド・コンピューティング・システムのヘルスステータスのモニタリング
(51)【国際特許分類】
G06F 11/07 20060101AFI20240130BHJP
G06F 9/50 20060101ALI20240130BHJP
【ＦＩ】
G06F11/07 157
G06F9/50 150D
G06F11/07 140A
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023542715
(86)(22)【出願日】2022-02-08
(85)【翻訳文提出日】2023-07-13
(86)【国際出願番号】 CN2022075497
(87)【国際公開番号】W WO2022171075
(87)【国際公開日】2022-08-18
(31)【優先権主張番号】17/171,380
(32)【優先日】2021-02-09
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】390009531
【氏名又は名称】インターナショナル・ビジネス・マシーンズ・コーポレーション
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【住所又は居所原語表記】Ｎｅｗ Ｏｒｃｈａｒｄ Ｒｏａｄ， Ａｒｍｏｎｋ， Ｎｅｗ Ｙｏｒｋ １０５０４， Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】100112690
【弁理士】
【氏名又は名称】太佐 種一
(74)【代理人】
【識別番号】100120710
【弁理士】
【氏名又は名称】片岡 忠彦
(72)【発明者】
【氏名】スターブリング、スヴェン
(72)【発明者】
【氏名】タイヒ、トーステン
(72)【発明者】
【氏名】ミュラー、イェルク
(72)【発明者】
【氏名】ビルトハウアー、ゲオルク
【テーマコード（参考）】
5B042
【Ｆターム（参考）】
5B042GA12
5B042GA19
5B042JJ15
5B042JJ29
(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】
【図1】本発明の実施形態による、複数のワーカ・ノードを含むコンピューティング・システムのヘルスステータスをモニタリングするための、本発明のコンピュータ実装方法の一実施形態のブロック図である。
【図2】本発明の実施形態による、提案される概念をサポートするコンポーネントを伴うアーキテクチャの一実施形態のブロック図である。
【図3】本発明の実施形態による、Ｃｏｕｎｔｉｎｇ Ｂｌｏｏｍ Ｆｉｌｔｅｒの実施形態のブロック図である。
【図4】本発明の実施形態による、モニタリング予測エージェントの機能性の態様の一実施形態の図である。
【図5】本発明の実施形態による、方法全体の実施形態に近いバージョンの、もう１つの実装形態のフローチャートである。
【図6】本発明の実施形態による、提案される概念の予測的な態様の実施形態に近いもう１つの実装形態のフローチャートである。
【図7】本発明の実施形態による、本発明のコンピューティング・インフラストラクチャ・モニタリング・システムの一実施形態のブロック図である。
【図9】本発明の実施形態による、クラウド・コンピューティング・インフラストラクチャの一実施形態の図である。
【発明を実施するための形態】
【0009】
本説明のコンテキストにおいて、以下の慣例、用語、または表現あるいはその組合せが使用され得る。
【0010】
「ヘルスステータス」またはヘルスステータス値という用語は、ワーカ・ノードもしくはコンピューティング・システム、または複数のコンピューティング・システムの複数のワーカ・ノードのような、複雑なシステムがうまく機能しているかを表現する数値的指標値を表すことができる。様々な実施形態では、「ヘルスステータス」またはヘルスステータス値という用語は、「トラブルが起こりそう」または「すべてのシステムがスムーズに実行中である」というステータスを示すことができる。
【0011】
「コンピューティング・システム」という用語は、１つもしくは複数のハードウェア・コンピューティング・システム、クラスタ、クラウド・コンピューティング・センタ、または１つもしくは複数の仮想機械もしくはコンピューティング・コンテナ（例えば、Ｄｏｃｋｅｒコンテナ）あるいはその組合せも表すことができる。コンピューティング・システムはまた、ネットワークまたはストレージ・システムまたは匹敵するシステムであってもよい。また、他の周辺ユニットが、本発明の多様な実施形態による、提案される概念のコンテキストにおいて、コンピューティング・システムとして説明される場合がある。
【0012】
「ワーカ・ノード」という用語は、仮想的または物理的な、コンピュータ・システムまたはその一部を表すことができる。ワーカ・ノードは、プログラム・コードを実行するように適合されてもよい。したがって、仮想機械またはステートレスなコンピューティング・コンテナもまた、ワーカ・ノードと表されてもよい。ワーカ・ノードは、１０，０００もしくは１００，０００の範囲内、またはさらにはそれ以上などの、大規模なクラウド・コンピューティング・センタに展開される場合がある。
【0013】
「モニタリング予測エージェント」という用語は、ワーカ・ノードのバイナリヘルスステータス値を決定する能力を有するワーカ・ノード内の機能を表すことができる。例示の実施形態では、「モニタリング予測エージェント」は、ワーカ・ノードのメモリ使用量を表現することができる。
【0014】
「単一のバイナリヘルスステータス値」という用語は、論理「０」または論理「１」を表すことができる。例示の実施形態では、個々のワーカ・ノードにおいて、論理「０」は「問題検出なし」を意味することができ、論理「１」は「問題が存在する可能性がある」を表現することができる。
【0015】
「時間依存関数」という用語は、本明細書では例えば、例えば、消費可能メモリおよび実際に決定されたメモリ使用量の所与のセットポイントを使用し、それにより短期履歴メモリ消費値も反映することができる、ＰＩＤ（比例－積分－微分）フィルタを表すことができる。それにより、メモリ消費もまた、ワーカ・ノードの他のリソースの１つの例であることができる。
【0016】
「パフォーマンス計量データ値」という用語は、現実の数値データ値を表すことができ、より計算的なプロセスを伴うコンピューティング・システムによる特定のリソース消費を表現することができることもある。１つの例は、利用可能な合計メモリと比較する場合の、消費されるメモリの割合であってもよい。他のパフォーマンス計量データ値は、ネットワーク使用率、またはプロセッサ使用率、またはコンピュータ電力使用率に関連してもよい。
【0017】
「上側しきい値」という用語は、初期化時にモニタリング予測エージェントにアップロードすることができる数値（例えば、百分率値）を表すことができ、これに対してパフォーマンス計量データの値を比較することが可能である。したがって、２つの百分率値を互いに比較することができる。パフォーマンス計量データ値が上側しきい値を超えることができる場合、個々のワーカ・ノードのバイナリヘルスステータス値として論理「１」を生成することができる。「下側しきい値」という用語は、上側しきい値と比較した場合に対応するしきい値を表すことができる。
【0018】
「ヘルス管理エージェント」という用語は、複数のワーカ・ノードのヘルスステータスの決定のためのＣＢＦ（Ｃｏｕｎｔｉｎｇ Ｂｌｏｏｍ Ｆｉｌｔｅｒ）の代わりとなる、本発明の様々な態様を制御する中心的なプロセッサまたはシステムを表すことができる。典型的には、必ずしもではないが、ヘルスモニタリング・エージェントは、ワーカ・ノードからリモートに展開されてもよく、またＭａａＳソリューションの一部分であってもよい。
【0019】
「識別情報」という用語は、例えばアドレス・ラベルおよび対応するネットワーク（例えば、ワーカ・ノード）を表すことができる。しかしながら、ネットワーク・アドレスの一部分もまた、識別情報として使用することができる。例えば、完全なアドレスの仮想機械部分、関連するハードウェア・システムのアドレス、クラスタ・アドレスまたは領域アドレスなどである。
【0020】
「ハッシュ関数」という用語は、任意のサイズのデータ（例えば、アドレス・データ）を固定サイズの値にマッピングするために使用することができる、あらゆる関数を表すことができる。ハッシュ関数によって返される値（例えば、データ・アレイのインデックス・フィールドへのインデックス・ポインタ）は、ハッシュ値、ハッシュ・コード、ダイジェスト、または単純にハッシュと呼ばれる。
【0021】
「Ｃｏｕｎｔｉｎｇ Ｂｌｏｏｍ Ｆｉｌｔｅｒ」（ＣＢＦ）という用語は、一連の要素が与えられたとき、所与の要素のカウント数が所与のしきい値よりも小さいかどうかを試験するために使用することができる、Ｂｌｏｏｍ Ｆｉｌｔｅｒの一般化されたデータ構造を表すことができる。Ｂｌｏｏｍフィルタの一般化された形態として、偽陽性の一致は可能であるが、偽陰性は可能ではない。換言すれば、クエリは、「しきい値以上である可能性がある」または「間違いなく、しきい値よりも小さい」のいずれかを返す。ここでは、ハッシュ関数は、入って来たデータ（例えば、アドレス・データ）を、Ｂｌｏｏｍ Ｆｉｌｔｅｒデータセットまたはデータ・アレイの一部であるカウンタにマッピングする。
【0022】
「データセット」という用語は、アレイ中の（例えば、整数値の）フィールドの１つのアレイを表すことができ、このアレイでは論理「１」値は受信したバイナリヘルスステータス値に応じて増加または減少する。
【0023】
「時系列」という用語は、さらなる分析のためのデータの時間依存セットを生成するために、比較可能なデータ構造のデータ値が永続的に記憶されることを表すことができる。
【0024】
「クラウド・コンピューティング」という用語は、このコンテキストでは、構成可能なコンピューティング・リソースの共有プール（例えば、ネットワーク、サーバ、ストレージ、アプリケーション、およびサービス）への便利でオンデマンドのネットワーク・アクセスを可能とするための、最小限の管理努力で、またはサービス・プロバイダとの対話で迅速にプロビジョニングおよびリリースすることができるモデルとして解釈することができる。リモートでマルチテナントのコンピューティング環境は、クラウド・コンピューティング・データ・センタとして実装されてもよい。クラウド・モデルは可用性を促進し、少なくとも５つの本質的な特性、３つのサービス・モデル、および４つの展開モデルから構成される。
【0025】
クラウド・コンピューティングの本質的な特性は、以下を含む：
（ｉ）オンデマンドなセルフサービス。消費者は、各サービス・プロバイダとの人間対話を要求することなく必要とされると自動的に、サーバ時間およびネットワーク・ストレージなどのコンピューティング機能を一方的にプロビジョニングすることができる。
（ｉｉ）幅広いネットワーク・アクセス。機能はネットワークの上で利用可能であり、異種のシン・クライアントまたはシック・クライアントのプラットフォーム（例えば、携帯電話、ラップトップ、およびＰＤＡ）による使用を促進する標準的なメカニズムを通じてアクセスされる。
（ｉｉｉ）リソース・プーリング。プロバイダのコンピューティング・リソースは、異なる物理的および仮想的なリソースを伴うマルチテナントのモデルを使用して複数の消費者にサービス提供するためにプールされ、消費者需要にしたがって動的に割当ておよび再割当てされる。顧客が提供されるリソースの正確な場所についての制御または情報を一般的に持たない点で、場所の独立性の意味があるが、より高い抽象レベルにおいて場所（例えば、国、州、またはデータセンタ）を特定できることもある。リソースの例としては、ストレージ、処理、メモリ、ネットワーク帯域幅、および仮想機械が挙げられる。
（ｉｖ）迅速な拡張性。機能は迅速かつ拡張可能にプロビジョニングすることができ、いくつかの場合において、自動的に、素早くスケール・アウトされて迅速にリリースし、素早くスケール・インされる。消費者にとって、プロビジョニングのために利用可能な機能は、しばしば無制限に見え、いつでもいくらでも購入することができる。
（ｖ）サービスの計測。クラウド・システムは、サービスのタイプ（例えば、ストレージ、処理、帯域幅、およびアクティブなユーザ・アカウント）に適当ないくつかの抽象レベルにおいて計測機能を活用することによりリソース使用を自動的に制御し、最適化する。リソース使用量は監視され、制御され、そして報告され得、利用されるサービスのプロバイダおよび消費者の両方にとって透明性を与えている。
（ｉ）オンデマンドなセルフサービス。消費者は、各サービス・プロバイダとの人間対話を要求することなく必要とされると自動的に、サーバ時間およびネットワーク・ストレージなどのコンピューティング機能を一方的にプロビジョニングすることができる。
（ｉｉ）幅広いネットワーク・アクセス。機能はネットワークの上で利用可能であり、異種のシン・クライアントまたはシック・クライアントのプラットフォーム（例えば、携帯電話、ラップトップ、およびＰＤＡ）による使用を促進する標準的なメカニズムを通じてアクセスされる。
（ｉｉｉ）リソース・プーリング。プロバイダのコンピューティング・リソースは、異なる物理的および仮想的なリソースを伴うマルチテナントのモデルを使用して複数の消費者にサービス提供するためにプールされ、消費者需要にしたがって動的に割当ておよび再割当てされる。顧客が提供されるリソースの正確な場所についての制御または情報を一般的に持たない点で、場所の独立性の意味があるが、より高い抽象レベルにおいて場所（例えば、国、州、またはデータセンタ）を特定できることもある。リソースの例としては、ストレージ、処理、メモリ、ネットワーク帯域幅、および仮想機械が挙げられる。
（ｉｖ）迅速な拡張性。機能は迅速かつ拡張可能にプロビジョニングすることができ、いくつかの場合において、自動的に、素早くスケール・アウトされて迅速にリリースし、素早くスケール・インされる。消費者にとって、プロビジョニングのために利用可能な機能は、しばしば無制限に見え、いつでもいくらでも購入することができる。
（ｖ）サービスの計測。クラウド・システムは、サービスのタイプ（例えば、ストレージ、処理、帯域幅、およびアクティブなユーザ・アカウント）に適当ないくつかの抽象レベルにおいて計測機能を活用することによりリソース使用を自動的に制御し、最適化する。リソース使用量は監視され、制御され、そして報告され得、利用されるサービスのプロバイダおよび消費者の両方にとって透明性を与えている。
【0026】
クラウド・コンピューティング使用のためのサービス・モデルは、以下を含む：
（ｉ）サービスとしてのクラウド・ソフトウェア（ＳａａＳ：Ｃｌｏｕｄ Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）。消費者に提供される機能は、クラウド・インフラストラクチャ上で実行中のプロバイダのアプリケーションを使用することである。アプリケーションは、ウェブ・ブラウザなどのシン・クライアント・インターフェース（例えば、ウェブ・ベースの電子メール）を通じて様々なクライアント・デバイスからアクセス可能である。消費者は、ネットワーク、サーバ、オペレーティング・システム、ストレージ、またはさらには個々のアプリケーション機能を含む基礎となるクラウド・インフラストラクチャを管理または制御することはなく、例外として限定されたユーザ固有アプリケーションの構成設定が可能である。
（ｉｉ）サービスとしてのクラウド・プラットフォーム（ＰａａＳ：Ｃｌｏｕｄ Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）。消費者に提供される機能は、プロバイダによってサポートされるプログラミング言語およびツールを使用して作成された、消費者が作成した、または取得したアプリケーションをクラウド・インフラストラクチャに展開することである。消費者は、ネットワーク、サーバ、オペレーティング・システム、またはストレージを含む基礎となるクラウド・インフラストラクチャの管理または制御をしないが、展開されたアプリケーション、および場合によっては環境構成をホストするアプリケーションについての制御を有する。
（ｉｉｉ）サービスとしてのクラウド・インフラストラクチャ（ＩａａＳ：Ｃｌｏｕｄ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）。消費者に提供される機能は、任意のソフトウェアを消費者が展開および実行することができる、処理、ストレージ、ネットワーク、および他の基本的なコンピューティング・リソースをプロビジョニングすることであり、これにはオペレーティング・システムおよびアプリケーションが含まれ得る。消費者は、基礎となるクラウド・インフラストラクチャの管理または制御をしないが、オペレーティング・システム、ストレージ、展開されたアプリケーションに対する制御、および場合によっては選択されたネットワーキング・コンポーネント（例えば、ホスト・ファイヤウォール）の限定された制御を有する。
（ｉ）サービスとしてのクラウド・ソフトウェア（ＳａａＳ：Ｃｌｏｕｄ Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）。消費者に提供される機能は、クラウド・インフラストラクチャ上で実行中のプロバイダのアプリケーションを使用することである。アプリケーションは、ウェブ・ブラウザなどのシン・クライアント・インターフェース（例えば、ウェブ・ベースの電子メール）を通じて様々なクライアント・デバイスからアクセス可能である。消費者は、ネットワーク、サーバ、オペレーティング・システム、ストレージ、またはさらには個々のアプリケーション機能を含む基礎となるクラウド・インフラストラクチャを管理または制御することはなく、例外として限定されたユーザ固有アプリケーションの構成設定が可能である。
（ｉｉ）サービスとしてのクラウド・プラットフォーム（ＰａａＳ：Ｃｌｏｕｄ Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）。消費者に提供される機能は、プロバイダによってサポートされるプログラミング言語およびツールを使用して作成された、消費者が作成した、または取得したアプリケーションをクラウド・インフラストラクチャに展開することである。消費者は、ネットワーク、サーバ、オペレーティング・システム、またはストレージを含む基礎となるクラウド・インフラストラクチャの管理または制御をしないが、展開されたアプリケーション、および場合によっては環境構成をホストするアプリケーションについての制御を有する。
（ｉｉｉ）サービスとしてのクラウド・インフラストラクチャ（ＩａａＳ：Ｃｌｏｕｄ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）。消費者に提供される機能は、任意のソフトウェアを消費者が展開および実行することができる、処理、ストレージ、ネットワーク、および他の基本的なコンピューティング・リソースをプロビジョニングすることであり、これにはオペレーティング・システムおよびアプリケーションが含まれ得る。消費者は、基礎となるクラウド・インフラストラクチャの管理または制御をしないが、オペレーティング・システム、ストレージ、展開されたアプリケーションに対する制御、および場合によっては選択されたネットワーキング・コンポーネント（例えば、ホスト・ファイヤウォール）の限定された制御を有する。
【0027】
クラウド・コンピューティングのための展開モデルは、以下を含む：
（ｉ）プライベート・クラウド。クラウド・インフラストラクチャは、１つの組織のみによって運用される。クラウド・インフラストラクチャは、組織またはサード・パーティによって管理され得、オンプレミスまたはオフプレミスで存在することができる。
（ｉｉ）コミュニティ・クラウド。クラウド・インフラストラクチャは、いくつかの組織によって共有され、共有される事案（例えば、ミッション、セキュリティ要件、ポリシ、およびコンプライアンス検討）を有する特定のコミュニティをサポートする。クラウド・インフラストラクチャは、組織またはサード・パーティによって管理され得、オンプレミスまたはオフプレミスで存在することができる。
（ｉｉｉ）パブリック・クラウド。クラウド・インフラストラクチャは、一般公衆または大規模な業界団体に対して利用可能とされ、クラウド・サービスを販売する組織によって所有される。
（ｉｖ）ハイブリッド・クラウド。クラウド・インフラストラクチャは、一意なエンティティのままである２つ以上のクラウド（プライベート、コミュニティ、またはパブリック）を組み合わせたものであるが、データおよびアプリケーションのポータビリティを可能にする標準化された、または専有的な技術（例えば、クラウド間でロード・バランシングを行うためのクラウド・バースティング）によって共に結合される。
（ｉ）プライベート・クラウド。クラウド・インフラストラクチャは、１つの組織のみによって運用される。クラウド・インフラストラクチャは、組織またはサード・パーティによって管理され得、オンプレミスまたはオフプレミスで存在することができる。
（ｉｉ）コミュニティ・クラウド。クラウド・インフラストラクチャは、いくつかの組織によって共有され、共有される事案（例えば、ミッション、セキュリティ要件、ポリシ、およびコンプライアンス検討）を有する特定のコミュニティをサポートする。クラウド・インフラストラクチャは、組織またはサード・パーティによって管理され得、オンプレミスまたはオフプレミスで存在することができる。
（ｉｉｉ）パブリック・クラウド。クラウド・インフラストラクチャは、一般公衆または大規模な業界団体に対して利用可能とされ、クラウド・サービスを販売する組織によって所有される。
（ｉｖ）ハイブリッド・クラウド。クラウド・インフラストラクチャは、一意なエンティティのままである２つ以上のクラウド（プライベート、コミュニティ、またはパブリック）を組み合わせたものであるが、データおよびアプリケーションのポータビリティを可能にする標準化された、または専有的な技術（例えば、クラウド間でロード・バランシングを行うためのクラウド・バースティング）によって共に結合される。
【0028】
クラウド・ソフトウェアは、ステートレス性（例外あり）、低結合性、モジュール性、およびセマンティックな相互運用性に着目したサービス指向であることによって、クラウドのパラダイムを最大限に活用することに留意されたい。このことは、特に、クラウド・コンピューティング・センタに展開された、コンピューティング・システム上またはその内部のワーカ・ノードに当てはまる。
【0029】
複数のワーカ・ノードを含むコンピューティング・システムのヘルスステータスをモニタリングするための、提案されるコンピュータ実装方法は、複数の利点、寄与、および技術的効果を提供することができる。
【0030】
本発明の実施形態は、通常はリカバリまたは高可用性システムが、エンタープライズ・グレードのＩＴインフラストラクチャに配置されるが、ユーザは単一のマイクロサービスまたはいくつかのマイクロサービスの停止を経験することがあることを認識している。クラウド・プロバイダの観点から、最小限の努力でできるだけそのような停止を防ぐために、これは必要である。しかしながら、この目的のため、現在利用可能なモニタリング・サービスおよびシステムは、あまりに複雑である場合があり、既存のＩＴインフラストラクチャとその運用者に実際の負担となる可能性がある。特に、１０，０００またはさらには１００，０００サービスをモニタリングする必要がある環境では、本発明の実施形態は、より洗練された、扱いが容易で、高度に自動化されたＭａａＳ技術が必要とされるであろうことを認識している。
【0031】
従来のモニタリング・システムおよびシステム管理システムとは対照的に、本発明の実施形態は、ワーカ・ノードのヘルスステータスを単一のバイナリヘルスステータス値（基本的に「０」または「１」）に低減し、それにより可能な限り少ない情報のみを必要とし、オーバヘッドを生じないように動作することができる。上で考察したように、従来のモニタリング・システムは、コンピューティング・システムのかなり多様なライフ・パワー計測値を、場合によっては実行中のサービスからも収集する。ワーカ・ノード上またはその内部ならびに分析システム上またはその内部で必要とされるメモリ消費の点で、すべてのこれらのパラメータ値をワーカ・ノードから中央分析システムに伝送するために必要とされる帯域幅、ならびに中央分析システム上で必要とされるコンピューティング・キャパシティの点で、ここに関与するオーバヘッドを最小限の１ビットにまで低減することができる。したがって、従来のモニタリング・システムによる、１秒当たり１００またはさらには１０００またはより多くのデータ点の収集は、ワーカ・ノードのヘルスステータスを１つの重要なデータ点に限定することによって、回避することができる。データ点またはこのパフォーマンス計量データ値は、特定のワーカ・ノード（例えば、コンピュータ・システム）、仮想機械、ハイパバイザ、またはプログラム実行コンテナなどのメモリ消費であり得る。
【0032】
したがって、本発明の実施形態は、データの量を劇的に低減するように動作することができ、それによって各ワーカ・ノードをスリムかつ軽量にすることができる。また、計算時間および反応時間が著しく低減される場合がある。したがって、提案される概念は、あるハードウェア・コンピューティング・プラットフォーム上で数万のサービスが実行されている、大規模および非常に大規模なクラウド・コンピューティング・システムに特に適用可能であり得る。
【0033】
さらには、１つのワーカ・ノードと関連付けられるモニタリング予測エージェントは、選択されたパフォーマンス計量データ値（例えば、メモリ消費）を固定の上限に対して比較することができるだけではなく、ある（短い）履歴時間にかけてのメモリ消費を決定し、その単一のバイナリヘルスステータス値におけるワーカ・ノードのメモリ消費の進展に反映することができる。
【0034】
次いで、続いての上側しきい値と下側しきい値に対しての比較は、これらは両方とも設定可能であるが、上側の危険なメモリ消費値に対してチェックするだけでなく、観察されるサービスに何らかの不具合を示し得る疑わしい下側しきい値に対してもチェックする。これは、例えば示されるメモリが、対象となるプロセス・ソフトウェアには、そのバッファとキャッシュを合わせてもなお小さい場合があるためである。したがって、この事例でも、低すぎるメモリ消費もまた、ワーカ・ノードにおける個々のサービスの低い機能の指標となり得る。
【0035】
Ｃｏｕｎｔｉｎｇ Ｂｌｏｏｍ Ｆｉｌｔｅｒ（ＣＢＦ）の使用はまた、コンピューティング・システムのヘルスステータスをモニタリングするための提案される方法のコンテキストにおいて、興味深い概念を表現することができる。ＣＢＦの中心概念は、フィルタ・データ・アレイ中のデータと個々のソース（すなわち、ワーカ・ノード）を分離することである。故に、モニタリング・サービス運用者は、観察されるサービスの特定の１つに問題があり得ると言うことができる場合があるが、サービス運用者は、ワーカ・ノードのグループが何らかのしきい値を超えている場合がある、または異常の可能性があるコンピューティング電力消費傾向を表している場合があると言うことができる。したがって、セキュリティとデータ・プライバシーの観点から、提案される概念はまた、どんな詳細なデータも捉えられないことから高評価を得ることができる。
【0036】
さらには、本発明の様々な実施形態は、ワーカ・ノードの特定の識別子にイベントを追加することによってだけでなく、ワーカ・ノードから問題がレポートされない場合はフィルタ・データ・アレイ中のカウンタを低減することによっても、ＣＢＦの概念を拡げることができる。加えて、すべてのフィルタ・アレイ・セルのコンテンツ全体を加算することによって（例えば、すべてのＣＢＦセル全体を加算し、キャッシュ関数の数で割ることによって）、（例えば、オーバロードによる）障害の可能性があるコンピューティング・ノードについての指標を得ることもできる。
【0037】
加えて、ワーカ・ノードの指標はまた、ワーカ・ノード自身のＩＤに加えて、クラスタまたは領域のＩＤ情報も含むことができる。故に、クラスタおよび領域のヘルスステータスは、ワーカ・ノード自身のヘルスステータスとは独立してモニタリングすることもできる。
【0038】
したがって、本発明の実施形態は、１ビットのみのヘルスステータス情報をネットワークの上で伝送するように動作することができるが、本発明の実施形態は、計画されておらず危険なセッティングとなり得る、クラウド・コンピューティング・システム内のコンピュータ・システム、クラスタ、および全体領域についての状況を予測する利点を提供することができる。それによって、本発明の実施形態は、ワークロードを１つのコンピューティング・システムから別のコンピューティング・システムに、１つの領域から別の領域に、または１つのクラスタから別のクラスタに、移すことができる。タスクは、関連するシステム管理ツールによって実施することができる。それによって、本発明の実施形態は、１０，０００またはさらには１００，０００のワーカ・ノードを伴うさらに非常に大規模なクラウド・コンピューティングのインストールをモニタリングするための、軽量であるがパワフルなＭａａＳソリューションに、うまくまとめることができる。
【0039】
以下では、方法ならびに関連システムに適用可能な、さらなる実施形態を、さらに詳細に説明する。
【0040】
例示の実施形態によると、パフォーマンス計量データ値は、個々のワーカ・ノードのメモリ使用量に関連してもよいか、または個々のワーカ・ノードのメモリ使用量であってもよく、これは、ワーカ・ノードがそのタスクをどのように実施しているかを示す特徴的なパフォーマンス計量値を表現することができる。上側および下側境界が与えられると、ワーカ・ノードのヘルスステータスは、そのような単一のバイナリ値によって特性付けることができる。特に、モニタリング予測エージェントはまた、（例えば、時系列の形態における）最も最近のメモリ使用量へのアクセスを有することができるため、エージェントは、近い将来に期待されるメモリ使用量の進展を予測することもできるようになり得る。関数は、ＰＩＤ（比例、積分、微分）フィルタによって実施され得、その結果もまた、所定の上側および下側しきい値と比較することができる。それによって、低すぎるメモリ使用量は、高すぎるメモリ使用量と同じやり方で、ワーカ・ノード内の潜在的な問題を示すことができる。したがって、高度な一実施形態によると、時間依存関数によって単一のバイナリヘルスステータス値を決定することは、予測されるメモリ使用量を決定するためのモニタリング予測エージェントの一部として、ＰＩＤフィルタを使用することを含んでもよい。
【0041】
さらには、メモリ使用量の代わりに、本発明の様々な実施形態は、使用されるネットワーク帯域幅、必要とされる合計ストレージ容量、Ｉ／Ｏ（入力／出力）レート、ＣＰＵ使用率、内部バス使用率、または他の個々の百分率値あるいはその組合せなど、他のパラメータ値を利用することができる。
【0042】
方法の別の実施形態によると、データセットは、所定の長さ（例えば、所定の時間の長さを有する）のアレイ（例えば、整数値）として記憶されてもよく、この場合、識別情報の一部分はハッシュ関数への入力として使用することができる。それにより、ハッシュ関数の出力値は、アレイ中のデータ・フィールドをアドレス指定するためのインデックス値であることができ、データセットのアドレス指定されたデータ・フィールドのそれぞれの個々の値は、受信した個々の単一のバイナリヘルスステータス値が論理「１」である場合、増加し得る（例えば、１ずつ）。他の増分値もまた、可能であり得る。
【0043】
結果として、また別の実施形態によると、本発明の実施形態は、受信した個々の単一のバイナリヘルスステータス値が論理「０」である場合、データセットのアドレス指定されたデータ・フィールドのそれぞれの個々の値を（例えば、１ずつ）低減するように動作することができる。故に、Ｃｏｕｎｔｉｎｇ Ｂｌｏｏｍ Ｆｉｌｔｅｒはその可能性を最大限にまで発揮することができる。
【0044】
加えて、識別情報の一部分は、個々のハードウェア・ノード、またはコンピューティング・ノードのラック、またはノードもしくはラックのクラスタ、または領域に関連し得ると言うこともできる。さらに、完全な識別情報（すなわち、完全なネットワーク・アドレス）もまた、個々のハッシュ関数のための入力として使用することができる。
【0045】
有利な１つの実施形態によると、アレイ中のデータ・フィールドの値の合計は、コンピューティング・システムのヘルスステータスを示す。このために、すべてのエリア・フィールドのすべての値を合計することができる。さらなる態様は、所定の時間間隔の後、データ・エリア・フィールドをリセットするために、その機能性を提供することもできる。したがって、複数のワーカ・ノードを含むシステム全体の変更された一般条件に適合するように、「ゼロ」への正規化が定期的に行われてもよい。
【0046】
さらには、個々の初期化の後、各ワーカ・ノードは、初期化時刻のすぐ後に「１」を、またワーク量におけるコンピューティング・プロセスが起動して実行された後に論理「０」を送信することができる。ワーカ・ノードからの通信は、ワーカ・ノード中の個々のコンピューティング・プロセスまたは複数プロセスの正常な初期化についての指標として使用することができる、データ・アレイ中の個々のフィールドを、リセットするように動作することができる。
【0047】
例示の実施形態によると、方法はまた、永続的ストレージにヘルスステータス値（例えば、ＣＢＦのステータス）を記憶することを含むことができ、それによりコンピューティング・システム負荷履歴データを生成する。ヘルスステータスの記憶（例えば、ＣＢＦの値のコピー）は定期的に記憶されてもよいか、またはヘルスステータス値についての１つまたは複数の所定のしきい値がオーバーランまたはアンダーランし得る場合、これはヘルスステータス管理システムの微調整を可能とすることができる。
【0048】
別の例示の実施形態によると、方法はまた、コンピューティング・システム負荷履歴データに基づいて、将来的な特定の時点についての例外のコンピューティング・システム負荷値を決定すること（例えば、傾向計算エージェントを使用して、予測すること）を含むことができる。（例えば、ワーカ・ノードのより大きな集合のステータスを表現し得る）システム負荷の、そのような集合的で保護的な値は、システムのオーバロードを予測するために、運用者または後続のワークロード制御システムが慎重なアクションを決定するのを支援することができる。
【0049】
したがって、また別の例示の実施形態によると、方法はまた、例外のコンピューティング・システム負荷値が所定のコンピューティング・システム負荷値を超えると、推奨される是正的なインフラストラクチャまたはワークロード管理アクションを開始することを含むことができる。そのような推奨される是正的なインフラストラクチャまたはワークロード管理アクションは、別の、あまりビジーではないハードウェア・ノード上での、コンピューティング・システムのワーカ・ノードの一部分の再展開を含むことができる。さらには、所与の使用事例に特に依存的であってもよい、他の是正的なアクションが、指示されてもよい。
【0050】
方法の別の実施形態によると、ワーカ・ノードは、１つの物理的なコンピューティング・ノード、複数の物理的なノード、１つの仮想機械、複数の仮想機械、１つのコンピューティング・コンテナ（例えば、Ｄｏｃｋｅｒコンテナ）、複数のコンピューティング・コンテナ、１つのコンピューティング・プロセス、および複数のコンピューティング・プロセスからなる群から選択することができる。加えて、モニタリング対象となる他のオブジェクトもまた、提案される概念によってサポートすることができる。
【0051】
追加的な一実施形態によると、方法はまた、モニタリング予測エージェントの開始の間、設定可能上側しきい値および設定可能下側しきい値を受信することを含むことができる。一部の実施形態では、ワーカ・ノードまたはそのグループの個別の１つのみが、上側および下側しきい値を受信することができる。それにより、すべてのワーカ・ノードに対し、値が同一であることを必要とされない。
【0052】
以下では、図面の詳細な説明を与える。図面におけるすべての命令は、概略的なものである。まず、複数のワーカ・ノードを含むコンピューティング・システムのヘルスステータスをモニタリングするための、本発明のコンピュータ実装方法の一実施形態のブロック図を与える。その後、さらなる実施形態、ならびに複数のワーカ・ノードを含むコンピューティング・システムのヘルスステータスをモニタリングするためのコンピューティング・インフラストラクチャ・モニタリング・システムの実施形態を、説明する。
【0053】
図１は、本発明の実施形態による、クラウド・コンピューティング・センタの要素として典型的にセットアップされる、コンピューティング・システムのヘルスステータスをモニタリングするための、コンピュータ実装方法１００の好ましい一実施形態のブロック図を示す。様々な実施形態において、コンピューティング・システムは、複数のワーカ・ノードを含み、これらは物理的または論理的な、ユニット、仮想機械、コンピューティング・コンテナ、またはハードウェア・システムなどであることができる。説明目的で、図１で説明される方法１００は、図２（例えば、アーキテクチャ２００の１つまたは複数のコンポーネントを利用する）、図４（例えば、モニタリング予測エージェントの機能性の態様の、実施形態４００を利用する）、図７（例えば、本発明のコンピューティング・インフラストラクチャ・モニタリング・システム７００の一実施形態のブロック図の１つまたは複数のコンポーネントを利用する）、および図８（例えば、コンピューティング・システム８００を利用する）において、図示されるシステムに示される図およびシステムのうちの、１つまたは複数に実装することができる。例示の一実施形態では、ヘルス管理エージェント２１４などの、アーキテクチャ２００の１つまたは複数のコンポーネントは、方法１００の処理ステップを実行することができる。代替的に、方法１００の実行は、この実装形態に限定されない。
【0054】
ステップ１０２において、方法１００は、複数のワーカ・ノードのそれぞれにおいて、個々のモニタリング予測エージェントを展開することを含む。ステップ１０４において、方法１００は、個々のモニタリング予測エージェントによって複数のワーカ・ノードのそれぞれについて、個々のワーカ・ノードの少なくとも１種類のパフォーマンス計量データ値（例えば、ワーカ・ノード当たりのメモリ使用量の百分率）の時間依存関数によって、単一のバイナリヘルスステータス値を（例えば、「ＯＫ」には「０」を、「何かしらの問題があり得る」には「１」を）決定すること（例えば、ルックアップまたは計算を介して）を含む。ステップ１０６において、方法１００は、対応する結果を、所定の設定可能上側しきい値および設定可能下側しきい値と比較する。
【0055】
次に、ステップ１０８において、方法１００は、ワーカ・ノードからリモートにあってもよいヘルス管理エージェントにおいて、複数のワーカ・ノードのそれぞれから、バイナリヘルスステータス値を個々の識別情報（例えば、ワーカ・ノード、クラスタ、領域のＩＤなど）と共に受信することを含む（典型的には定期的に）。次いでステップ１１０において、方法１００は、ヘルス管理エージェントにおいて、複数のワーカ・ノードのそれぞれの受信した識別情報を、Ｃｏｕｎｔｉｎｇ Ｂｌｏｏｍ Ｆｉｌｔｅｒのハッシュ関数にフィードし、それによりコンピューティング・システムのヘルスステータスを示すデータセットを生成することを含む。データセットは、整数値のアレイとして編成されてもよい。
【0056】
図２は、本発明の実施形態による、提案される概念をサポートするコンポーネントのアーキテクチャ２００の一実施形態のブロック図を示す。複数のワーカ・ノードのそれぞれ（すなわち、ワーカ・ノード２０２、ワーカ・ノード２０４からワーカ・ノードｎ２０６）は、個々の関連するモニタリング予測エージェント（すなわち、モニタリング予測エージェント２０８、モニタリング予測エージェント２１０、およびモニタリング予測エージェント２１２）を含む。個別のコンポーネント間の矢印は、コンポーネント同士の共通のオケージョン(Occasion)経路を示すことができる。まず、中央システム管理システムまたはＭａａＳソリューションにおいてワーカ・ノード２０２、２０４から２０６に対してリモートで実行することができる管理エージェント２１４は、ワーカ・ノードを初期化し、「モニタリングを初期化」アクションを個々のワーカ・ノードに送信する。それぞれ初期化中のワーカ・ノードは、ワーカ・ノードごとに異なる可能性がある「デフォルト負荷」仕様で受信する。特に、ヘルス管理エージェントは、上側および下側しきい値を、個々のワーカ・ノードに送信することができる。
【0057】
さらには、ＣＢＦ（Ｃｏｕｎｔｉｎｇ Ｂｌｏｏｍ Ｆｉｌｔｅｒ）は、ヘルス管理エージェント２１４において初期化される。次いで、ワーカ・ノードは、対応するモニタリング予測エージェントを使用して、バイナリヘルスステータス値をどのようにするか、特に論理「０」（「ＯＫ」を意味する）かそれとも論理「１」（「問題があり得る」を意味する）かを決定する。決定は、定期的にもしくは周期的にまたはその両方で、あるいはイベントベースで行うことができる。上述のように（また、やはり図１のコンテキストにおけるように）、ワーカ・ノード２０２、２０４から２０６の受信したバイナリヘルスステータス値は、ＣＢＦを更新する。加えて、ＣＢＦのデータ・アレイの定期的なスナップショットは、コンピューティング・システムのヘルス値の履歴を生成するためにヘルスステータス・ストレージ２１８に記憶することができる。
【0058】
傾向計算エージェント２１６は、複数のワーカ・ノードのバイナリヘルスステータス値についての予測される傾向の決定についてのＣＢＦ値およびスナップショットを読み取り、その傾向からコンピューティング・システム（すなわち、ワーカ・ノード）に推奨される是正的なアクションを導く。次いでヘルス管理エージェント２１４は、是正的なアクションを実装するためにシステム管理システムに通知することができる。例えば、ヘルス管理エージェント２１４は、ワークロードの一部（すなわち、ワーカ・ノードの一部分）を別のハードウェア環境に移動させることができる、または完全に複数のワーカ・ノードを（例えば、別の領域にある）さらに強力なハードウェア・サポーティング・システムに移動させることができる。他の選択肢としては、コンピューティング・システム内でより多くのメモリを利用可能にすること、またはコンピューティング・システムに追加的なリソースを加えること（例えば、追加的なリソースのソフトウェア有効化による）が挙げられる。システム管理システムを使用して是正的なアクションを実装する代わりに、ヘルス管理エージェント２１４はまた、ワーカ・ノードに直接的に命令することによって是正的なアクションを直接的に実施してもよい。
【0059】
図３は、Ｃｏｕｎｔｉｎｇ Ｂｌｏｏｍ Ｆｉｌｔｅｒ３００の実施形態のブロック図を示す。図示される例では、ｈ１およびｈ２は、２つの異なるハッシュ関数を表す。様々な実施形態において、ワーカ・ノードＷＮ１ ３０４、ＷＮ２ ３０６、およびＷＮ３ ３０８から、論理「１」を受信する。いずれかの完全なアドレス（すなわち、識別子または識別情報）が、ハッシュ関数ｈ１およびｈ２への入力として使用される。別の実施形態では、ハッシュ関数の微調整されたセットが展開されてもよい。微調整されたハッシュ関数が生成するインデックス値は、データ・アレイ３０２の長さに制限することができる。
【0060】
見て分かるように、左から２番目のデータ・フィールドは、ＷＮ１ ３０４の識別子用にアドレス指定されており、これは、データ・アレイ３０２のデータ・フィールドにおいて論理「１」に導く。同様のことが、ワーカ・ノードＷＮ２ ３０６の識別情報について、データ・アレイ３０２の４番目と６番目のデータ・フィールドに当てはまる。データ・アレイ３０２の７番目のフィールド（右から２番目のデータ・フィールド）では、データ・フィールドは「２」を記憶する。これは、ワーカ・ノードＷＮ１ ３０４の識別情報のハッシュ関数ｈ２によって生成されるインデックス値、ならびにワーカ・ノードＷＮ３ ３０８の識別情報のハッシュ関数ｈ２によって生成されるインデックス値が、データ・アレイ３０２の同一データ・フィールドまたはインデックスをポイントするためである。
【0061】
データ・アレイ３０２中のデータ・フィールドはまた、ハッシュ関数がインデックス値を生成するカテゴリとして表すことができる。一般に、データ・アレイ３０２のデータ・フィールドの値は、論理「１」が個々の識別情報（例えば、個々のワーカ・ノードのアドレスの一部分（またはすべて））と共に受信される場合、増加する。さらには、データ・アレイ３０２のデータ・フィールド上のカウンタは、論理「０」が受信される場合、減少する。例示の実装形態では、データ・アレイ３０２中のデータ・フィールドの数は、ここで示される８フィールドよりもずっと大きい。加えて、それぞれ受信した識別情報に適用されるハッシュ関数の数も、ずっと大きい場合がある。
【0062】
データ・アレイ３０２が「すべてゼロ」で初期化される（または周期的にリセットされる）場合、本発明の実施形態は、論理「１」よりも多くの論理「０」が受信される場合に負の値を生成する可能性がある。データ・アレイ３０２のデータ・フィールド中に正のカウンタ値のみを有したい場合、個別のカウンタについての初期化値は正の開始値（例えば、５１２または１０００または類似の値）を取るべきである。
【0063】
別の実施形態３５０では、ＣＢＦにステータスをレポートするノードは、データ・アレイ３５２において順序良く制御されたやり方で、選択されたバケット(buckets)に割り振られ、このことにより、期待される実際の負荷、クラスタ・メンバシップ、セキュリティ制約などのカテゴリに応じて、ノードをグループ化することが可能となり得る。想定または制約が変わる場合、割当てはいつでも調整することができ、これは運用者によって行うことができる。そのような実施形態は、異なる特性のワーカ・ノードに対し、ある単一のＣＢＦを使用できるようにすることができる。代替的に、別個のＣＢＦをそのような異なる特性のために使用することもでき、これにより、ワーカ・ノードの計算負荷のさらにずっと細かい粒度の分析を可能にすることができる。ここでは、ワーカ・ノードＷＮ１ ３５３、ＷＮ２ ３５４は、ワーカ・ノードの同一バケット／特性に関係し得る。データ・アレイ３５２中の個々のデータ・フィールドについての論理「１」は、単に象徴的に示される。ＷＮ３ ３５６は、それ自身のカテゴリを作成するが、ＷＮ４ ３５８およびＷＮ５ ３６０は、個々のワーカ・ノードの他の特性についての別のカテゴリを作成する。
【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】
以下の特許請求の範囲における、対応する構造、材料、動作、およびすべてのミーンズまたはステップ・プラス・ファンクション要素の均等物は、具体的に特許請求されるように、他の特許請求される要素と組み合わせて機能を実施するための、あらゆる構造、材料、または動作を含むことを意図されている。例示および説明を目的として、本発明の説明を提示してきたが、網羅的であること、または発明を開示された形態に限定することは意図されていない。本発明の範囲から逸脱することなく、多くの変更形態および変形形態が当業者にとって明らかとなろう。実施形態は、本発明の原理および実践的な用途を最良に説明するために、また企図される特定の使用に適したものとして様々な変更形態を伴う様々な実施形態について本発明を当業者の他の者に理解させることができるために、選ばれ説明されたものである。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【手続補正書】
【提出日】2023-12-21
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
コンピュータ実装方法であって、１つまたは複数のコンピュータ・プロセッサによって、コンピューティング・システムの複数のワーカ・ノードのそれぞれに個々のモニタリング予測エージェントを展開することと、
１つまたは複数のコンピュータ・プロセッサによって、前記複数のワーカ・ノードのそれぞれについて、前記個々のモニタリング予測エージェントによって、単一のバイナリヘルスステータス値を決定することであり、個々の単一のバイナリヘルスステータス値を決定することが、
１つまたは複数のコンピュータ・プロセッサによって、前記個々のワーカ・ノードのパフォーマンス計量データ値の時間依存関数を、所定の設定可能上側しきい値および設定可能下側しきい値と比較すること
をさらに含む、前記決定することと、
１つまたは複数のコンピュータ・プロセッサによって、前記バイナリヘルスステータス値を個々の識別情報と共に前記複数のワーカ・ノードのそれぞれから受信することと、
１つまたは複数のコンピュータ・プロセッサによって、前記複数のワーカ・ノードのそれぞれの前記受信した識別情報を、Ｃｏｕｎｔｉｎｇ Ｂｌｏｏｍ Ｆｉｌｔｅｒのハッシュ関数にフィードすることによって、前記コンピューティング・システムのヘルスステータスを示すデータセットを生成することと
を含む、コンピュータ実装方法。
【請求項2】
前記パフォーマンス計量データ値が、前記個々のワーカ・ノードのメモリ使用量に相当する、請求項１に記載の方法。
【請求項3】
前記単一のバイナリヘルスステータス値を決定することが、１つまたは複数のプロセッサによって、前記モニタリング予測エージェントの一部としてＰＩＤ（比例－積分－微分）フィルタを使用して、予測されるメモリ使用量を決定すること
をさらに含む、請求項２に記載の方法。
【請求項4】
前記データセットが、所定の長さのアレイとして記憶され、前記識別情報の一部分が、前記ハッシュ関数への入力として使用され、
前記ハッシュ関数の出力値が、前記アレイ中のデータ・フィールドをアドレス指定するためのインデックス値であり、
前記個々の単一のバイナリヘルスステータス値が論理「１」であると決定したことに応答して、前記データセットの前記アドレス指定されたデータ・フィールドのそれぞれの個々の値が増加する、
請求項１に記載の方法。
【請求項5】
前記アレイ中の前記データ・フィールドの前記値の合計が、前記コンピューティング・システムの前記ヘルスステータスを示す、請求項４に記載の方法。
【請求項6】
ヘルスステータス値の前記データセットの時系列を永続的ストレージに記憶することによって、１つまたは複数のプロセッサによって、コンピューティング・システム負荷履歴データを生成することをさらに含む、請求項１に記載の方法。
【請求項7】
１つまたは複数のプロセッサによって、例外のコンピューティング・システム負荷値を、特定の将来的な時点の前記コンピューティング・システム負荷履歴データに基づいて、決定することをさらに含む、請求項６に記載の方法。
【請求項8】
前記例外のコンピューティング・システム負荷値が所定のコンピューティング・システム負荷値を超えたと判定したことに応答して、１つまたは複数のプロセッサによって、推奨される是正的なインフラストラクチャまたはワークロード管理アクションを開始することをさらに含む、請求項７に記載の方法。
【請求項9】
ワーカ・ノードが、１つの物理的なコンピューティング・ノード、複数の物理的なノード、１つの仮想機械、複数の仮想機械、１つのコンピューティング・コンテナ、複数のコンピューティング・コンテナ、１つのコンピューティング・プロセス、および複数のコンピューティング・プロセスからなる群から選択される、請求項１に記載の方法。
【請求項10】
１つまたは複数のプロセッサによって、前記モニタリング予測エージェントの開始の間、前記設定可能上側しきい値および前記設定可能下側しきい値を受信することをさらに含む、請求項１に記載の方法。
【請求項11】
コンピュータに、請求項１ないし１０のいずれかに記載の方法を実行させる、コンピュータ・プログラム。
【請求項12】
コンピュータ・システムであって、１つまたは複数のコンピュータ・プロセッサと、
１つまたは複数のコンピュータ可読記憶媒体と、
前記１つまたは複数のプロセッサのうちの少なくとも１つによる実行のために、前記コンピュータ可読記憶媒体に記憶されたプログラム命令であり、前記プログラム命令が、
コンピューティング・システムの複数のワーカ・ノードのそれぞれに個々のモニタリング予測エージェントを展開するためのプログラム命令と、
前記複数のワーカ・ノードのそれぞれについて、前記個々のモニタリング予測エージェントによって、単一のバイナリヘルスステータス値を決定するためのプログラム命令であり、個々の単一のバイナリヘルスステータス値を決定するための前記プログラム命令が、
前記個々のワーカ・ノードのパフォーマンス計量データ値の時間依存関数を、所定の設定可能上側しきい値および設定可能下側しきい値と比較する
ためのプログラム命令をさらに含む、前記単一のバイナリヘルスステータス値を決定するための前記プログラム命令と、
前記バイナリヘルスステータス値を個々の識別情報と共に前記複数のワーカ・ノードのそれぞれから受信するためのプログラム命令と、
前記複数のワーカ・ノードのそれぞれの前記受信した識別情報を、Ｃｏｕｎｔｉｎｇ Ｂｌｏｏｍ Ｆｉｌｔｅｒのハッシュ関数にフィードすることによって、前記コンピューティング・システムのヘルスステータスを示すデータセットを生成するためのプログラム命令と
を含む、前記プログラム命令と
を含む、コンピュータ・システム。
【請求項13】
前記パフォーマンス計量データ値が、前記個々のワーカ・ノードのメモリ使用量に相当する、請求項１２に記載のコンピュータ・システム。
【請求項14】
前記単一のバイナリヘルスステータス値を決定するための前記プログラム命令が、前記モニタリング予測エージェントの一部としてＰＩＤ（比例－積分－微分）フィルタを使用して、予測されるメモリ使用量を決定する
ためのプログラム命令をさらに含む、請求項１３に記載のコンピュータ・システム。
【請求項15】
前記１つまたは複数のプロセッサのうちの少なくとも１つによる実行のために、前記コンピュータ可読記憶媒体に記憶された、ヘルスステータス値の前記データセットの時系列を永続的ストレージに記憶することによって、コンピューティング・システム負荷履歴データを生成する
ためのプログラム命令をさらに含む、請求項１２に記載のコンピュータ・システム。
【請求項16】
前記１つまたは複数のプロセッサのうちの少なくとも１つによる実行のために、前記コンピュータ可読記憶媒体に記憶された、例外のコンピューティング・システム負荷値を、特定の将来的な時点の前記コンピューティング・システム負荷履歴データに基づいて、決定する
ためのプログラム命令をさらに含む、請求項１５に記載のコンピュータ・システム。
【請求項17】
前記１つまたは複数のプロセッサのうちの少なくとも１つによる実行のために、前記コンピュータ可読記憶媒体に記憶された、前記例外のコンピューティング・システム負荷値が所定のコンピューティング・システム負荷値を超えたと判定したことに応答して、推奨される是正的なインフラストラクチャまたはワークロード管理アクションを開始する
ためのプログラム命令をさらに含む、請求項１６に記載のコンピュータ・システム。
【請求項18】
ワーカ・ノードが、１つの物理的なコンピューティング・ノード、複数の物理的なノード、１つの仮想機械、複数の仮想機械、１つのコンピューティング・コンテナ、複数のコンピューティング・コンテナ、１つのコンピューティング・プロセス、および複数のコンピューティング・プロセスからなる群から選択される、請求項１２に記載のコンピュータ・システム。
【国際調査報告】