特許 6586465 ストレージ・クラスタ要素のモニタリングのための方法、装置、記憶媒体及びコンピュータ・プログラム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6586465

(24)【登録日】2019年9月13日

(45)【発行日】2019年10月2日

(54)【発明の名称】ストレージ・クラスタ要素のモニタリングのための方法、装置、記憶媒体及びコンピュータ・プログラム

(51)【国際特許分類】

   G06F 11/07 20060101AFI20190919BHJP

   G06F 11/30 20060101ALI20190919BHJP

   G06F 3/06 20060101ALI20190919BHJP

   G06F 13/10 20060101ALI20190919BHJP

   G06F 13/14 20060101ALI20190919BHJP

【ＦＩ】

   G06F11/07 151

   G06F11/07 140M

   G06F11/30 151

   G06F11/30 172

   G06F11/30 140M

   G06F3/06 304N

   G06F13/10 340A

   G06F13/14 330A

【請求項の数】22

【全頁数】20

(21)【出願番号】特願2017-541285(P2017-541285)

(86)(22)【出願日】2016年1月12日

(65)【公表番号】特表2018-513442(P2018-513442A)

(43)【公表日】2018年5月24日

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

(87)【国際公開番号】WO2016126390

(87)【国際公開日】20160811

【審査請求日】2018年2月26日

(31)【優先権主張番号】14/613,085

(32)【優先日】2015年2月3日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】303039534

【氏名又は名称】ネットアップ，インコーポレイテッド

(74)【代理人】

【識別番号】100107766

【弁理士】

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

(74)【代理人】

【識別番号】100070150

【弁理士】

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

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(74)【代理人】

【識別番号】110002262

【氏名又は名称】ＴＲＹ国際特許業務法人

(72)【発明者】

【氏名】アンキット・バットラ

(72)【発明者】

【氏名】アマナッツ・ゾラド

(72)【発明者】

【氏名】カズノフ・ニシメ

【審査官】 多賀 実

(56)【参考文献】

【文献】 特開２００７−０５８４８４（ＪＰ，Ａ）

【文献】 特開２００７−３３４７１６（ＪＰ，Ａ）

【文献】 特開２０１１−０７６２９３（ＪＰ，Ａ）

【文献】 特開２０１４−１９１４０１（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ３／０６

Ｇ０６Ｆ １３／１０

Ｇ０６Ｆ １３／１４

Ｇ０６Ｆ １１／０７

Ｇ０６Ｆ １１／２８−１１／３６

(57)【特許請求の範囲】

【請求項1】

コンピュータにより実現される方法であって：
第１ストレージ・クラスタのバックエンド及び前記第１ストレージ・クラスタに関連する第２ストレージ・クラスタのバックエンドのトポロジを判定するステップ；
前記第１ストレージ・クラスタのバックエンドのネットワーク要素から及び前記第２ストレージ・クラスタのバックエンドのネットワーク要素から、第１動作情報を周期的に取得するステップ；
何れかのネットワーク要素から前記第１動作情報を取得した後に：動作情報に少なくとも部分的に基づいて、前記第１ストレージ・クラスタ内で通信されるストレージ・クラスタ情報を更新し；前記動作情報が１つ以上のルールの第１セットに違反するか否かを判定し；前記動作情報が前記第１セットのルールに違反する旨の判定に応じて、通知が生成されるべきであるか否かを判定し；前記通知が生成されるべきである旨の判定に応じて前記通知を生成するステップ；
ローカル・サブシステムから第２動作情報を取得するステップ；
前記第１動作情報との組み合わせで前記第２動作情報が、１つ以上のルールの第２セットに違反するか否かを判定するステップ；及び
前記第１動作情報及び前記第２動作情報の組み合わせが前記第２セットのルールに違反する場合に、通知を生成するステップ；
を有する方法。

【請求項2】

前記第１ストレージ・クラスタのバックエンド及び前記第１ストレージ・クラスタに関連する第２ストレージ・クラスタのバックエンドのトポロジを判定することが、前記第１ストレージ・クラスタ及び前記第２ストレージ・クラスタの間の通信チャネルの帯域外で、前記第２ストレージ・クラスタからトポロジ情報を収集することを含む、請求項１に記載の方法。

【請求項3】

前記第１ストレージ・クラスタ及び前記第２ストレージ・クラスタの双方のフロント・エンドのトポロジを帯域内通信で決定するステップを更に有する請求項２に記載の方法。

【請求項4】

前記帯域外でトポロジ情報を収集することが、シンプル・ネットワーク管理プロトコルに従って前記トポロジ情報を収集することを含む、請求項２又は３に記載の方法。

【請求項5】

判定されたトポロジをトポロジ検証ルールにより検証するステップを更に有する請求項１ないし４のうち何れか一項に記載の方法。

【請求項6】

前記第１動作情報を周期的に取得することが、第１動作情報を第１期間内で第１通信チャネルにより収集し、及び、第１動作情報を第２期間内で第２通信チャネルにより収集することを含む、請求項１ないし５のうち何れか一項に記載の方法。

【請求項7】

前記動作情報は、コンフィギュレーション情報及び現在の運用情報のうち少なくとも何れかを含む、請求項１ないし６のうち何れか一項に記載の方法。

【請求項8】

前記第２動作情報が、前記第１ストレージ・クラスタ及び前記第２ストレージ・クラスタ間の接続の喪失を指示していることを判定するステップ；及び
前記第２動作情報が前記接続の喪失を指示している旨の判定に応じて、前記第１動作情報も、前記第１ストレージ・クラスタ及び前記第２ストレージ・クラスタ間の接続の喪失を指示しているか否かを判定するステップ；
を更に有する請求項１ないし７のうち何れか一項に記載の方法。

【請求項9】

プログラム・コードを保存する１つ以上の非一時的なマシン読み取り可能な媒体であって、前記プログラム・コードは、実行されると、１つ以上のコンピュータ・システムに：
第１ストレージ・クラスタのバックエンド及び前記第１ストレージ・クラスタに関連する第２ストレージ・クラスタのバックエンドのトポロジを判定するステップ；
前記第１ストレージ・クラスタのバックエンドのネットワーク要素から及び前記第２ストレージ・クラスタのバックエンドのネットワーク要素から、動作情報を周期的に取得するステップ；
ネットワーク要素から前記動作情報を受信したことに応じて：前記ネットワーク要素からの動作情報に少なくとも部分的に基づいて、前記第１ストレージ・クラスタ内で通信されるストレージ・クラスタ情報を更新し；前記動作情報が１つ以上のルールの第１セットに違反するか否かを判定し；前記動作情報が前記第１セットのルールに違反する旨の判定に応じて、通知が生成されるべきであるか否かを判定し；前記通知が生成されるべきである旨の判定に応じて前記通知を生成するステップ；
ローカル・サブシステムから動作情報を取得するステップ；
周期的に取得された動作情報との組み合わせで前記ローカル・サブシステムからの動作情報が、１つ以上のルールの第２セットに違反するか否かを判定するステップ；及び
動作情報の組み合わせが前記第２セットのルールに違反する場合に、通知を生成するステップ；
を実行させる、マシン読み取り可能な媒体。

【請求項10】

前記第１ストレージ・クラスタのバックエンド及び前記第１ストレージ・クラスタに関連する第２ストレージ・クラスタのバックエンドのトポロジを判定するためのプログラム・コードが、前記第１ストレージ・クラスタ及び前記第２ストレージ・クラスタの間の通信チャネルの帯域外で、前記第２ストレージ・クラスタからトポロジ情報を収集するためのプログラム・コードを含む、請求項９に記載のマシン読み取り可能な媒体。

【請求項11】

前記第１ストレージ・クラスタのフロント・エンド及び前記第２ストレージ・クラスタのフロント・エンドのトポロジを帯域内通信で決定するためのプログラム・コードを更に有する請求項１０に記載のマシン読み取り可能な媒体。

【請求項12】

前記帯域外でトポロジ情報を収集するためのプログラム・コードが、シンプル・ネットワーク管理プロトコルに従って前記トポロジ情報を収集するためのプログラム・コードを含む、請求項１０又は１１に記載のマシン読み取り可能な媒体。

【請求項13】

判定されたトポロジをトポロジ検証ルールにより検証するためのプログラム・コードを更に有する請求項９ないし１２のうち何れか一項に記載のマシン読み取り可能な媒体。

【請求項14】

前記ネットワーク要素から前記動作情報を周期的に取得するためのプログラム・コードが、第１期間内で第１通信チャネルにより前記ネットワーク要素から動作情報を取得し、及び、第２期間内で第２通信チャネルにより前記ネットワーク要素から動作情報を取得するためのプログラム・コードを含む、請求項９ないし１３のうち何れか一項に記載のマシン読み取り可能な媒体。

【請求項15】

前記動作情報は、コンフィギュレーション情報及び現在の運用情報のうち少なくとも何れかを含む、請求項９ないし１４のうち何れか一項に記載のマシン読み取り可能な媒体。

【請求項16】

前記ローカル・サブシステムからの動作情報が、前記第１ストレージ・クラスタ及び前記第２ストレージ・クラスタ間の接続の喪失を指示していることを判定し；及び
前記ローカル・サブシステムからの動作情報が前記接続の喪失を指示している旨の判定に応じて、前記ネットワーク要素からの動作情報も、前記第１ストレージ・クラスタ及び前記第２ストレージ・クラスタ間の接続の喪失を指示しているか否かを判定する；
ためのプログラム・コードを更に有する請求項９ないし１５のうち何れか一項に記載のマシン読み取り可能な媒体。

【請求項17】

プロセッサ；及び
プログラム・コードを保存するマシン読み取り可能な記憶媒体；
を有する装置であって、前記プログラム・コードは、請求項１ないし８のうち何れか一項に記載の方法を前記装置に実行させるように、前記プロセッサにより実行可能である、装置。

【請求項18】

プロセッサ；及び
プログラム・コードを保存するマシン読み取り可能な記憶媒体；
を有する装置であって、前記プログラム・コードは：
第１ストレージ・クラスタのバックエンド及び前記第１ストレージ・クラスタに関連する第２ストレージ・クラスタのバックエンドのトポロジを判定するステップ；
前記第１ストレージ・クラスタのバックエンドのネットワーク要素から及び前記第２ストレージ・クラスタのバックエンドのネットワーク要素から、動作情報を周期的に取得するステップ；
ネットワーク要素から前記動作情報を受信したことに応じて：前記ネットワーク要素からの動作情報に少なくとも部分的に基づいて、前記第１ストレージ・クラスタ内で通信されるストレージ・クラスタ情報を更新し；前記動作情報が１つ以上のルールの第１セットに違反するか否かを判定し；前記動作情報が前記第１セットのルールに違反する旨の判定に応じて、通知が生成されるべきであるか否かを判定し；前記通知が生成されるべきである旨の判定に応じて前記通知を生成するステップ；
ローカル・サブシステムから動作情報を取得するステップ；
周期的に取得された動作情報との組み合わせで前記ローカル・サブシステムからの動作情報が、１つ以上のルールの第２セットに違反するか否かを判定するステップ；及び
動作情報の組み合わせが前記第２セットのルールに違反する場合に、通知を生成するステップ；
を前記装置に実行させるように、前記プロセッサにより実行可能である、装置。

【請求項19】

前記第１ストレージ・クラスタのバックエンド及び前記第１ストレージ・クラスタに関連する第２ストレージ・クラスタのバックエンドのトポロジを判定することを前記装置に実行させるプログラム・コードが、前記第１ストレージ・クラスタ及び前記第２ストレージ・クラスタの間の通信チャネルの帯域外で、前記第２ストレージ・クラスタからトポロジ情報を収集することを、前記装置に実行させるように、前記プロセッサにより実行可能なプログラム・コードを含む、請求項１８に記載の装置。

【請求項20】

前記帯域外でトポロジ情報を収集することを前記装置に実行させるプログラム・コードが、シンプル・ネットワーク管理プロトコルに従って前記トポロジ情報を収集することを前記装置に実行させるように、前記プロセッサにより実行可能なプログラム・コードを含む、請求項１９に記載の装置。

【請求項21】

前記ローカル・サブシステムからの動作情報が、前記第１ストレージ・クラスタ及び前記第２ストレージ・クラスタ間の接続の喪失を指示していることを判定し；及び
前記ローカル・サブシステムからの動作情報が前記接続の喪失を指示している旨の判定に応じて、前記ネットワーク要素からの動作情報も、前記第１ストレージ・クラスタ及び前記第２ストレージ・クラスタ間の接続の喪失を指示しているか否かを判定する；
ことを前記装置に実行させるように、前記プロセッサにより実行可能なプログラム・コードを更に有する請求項１８ないし２０のうち何れか一項に記載の装置。

【請求項22】

請求項１ないし８のうち何れか一項に記載の前記方法を前記コンピュータに実行させるコンピュータ・プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

＜関連出願＞
本願は2015年2月3日付けで出願された「MONITORING STORAGE CLUSTER ELEMENTS」と題する米国特許出願第14/613,085号による優先的利益を享受し、その内容は本願のリファレンスに組み込まれる。

【背景技術】

【0002】

本開示による形態は一般に分散コンピューティングの分野に関連し、特に、ネットワークにわたって分散されるストレージ要素をモニタリングすることに関連する。

【0003】

クラスタリングは一般に(ディスク・ドライバ、ストレージ・アレイ、ファイル・サーバー、ストレージ・コントローラ等のような)ハードウェア要素のグループ(「クラスタ」)の恩恵を享受するためにハードウェア要素を一緒にグループ化することに関連し、その恩恵は個々のハードウェア要素から得ることはできないものである。クラスタリングは様々な保存機能に使用されることが可能であり、その具体例は、負荷バランシング、フェイルオーバー(又は障害迂回)、I/O帯域幅の増加、データ・アベイラビリティ(data availability)を含む。これらの機能をサポートするため、データは、サポート・ストレージ要素同士の間でコピーされる。

【発明の概要】

【0004】

関連してはいるが分離しているストレージ・クラスタについての健全性(health)のモニタリングは、ノード・スコープ(a node scope)及びクラスタ・スコープ(a cluster scope)の双方で実行されることが可能である。クラスタ・スコープでストレージ・クラスタをモニタリングすることは、ストレージ・クラスタをサポートし且つストレージ・クラスタを接続するネットワーク要素をモニタリングすることを含む。初めに、各クラスタのファブリック・モニタ(a fabric monitor)が、クラスタ・トポロジ(cluster topology)を発見する。このクラスタ・トポロジは、ストレージ・クラスタの管理ストレージ要素により通信され維持される。ストレージ・クラスタ・トポロジが発見された後、各クラスタのファブリック・モニタは、ストレージ・クラスタのネットワーク要素のステータス(又は状態)を、周期的に判定することが可能である。これは、ストレージ・クラスタが、相互接続状態の自覚を維持すること、及び、ステータスの変更に反応することを許容する。更に、各々の管理ストレージ要素は自身の健全性を監視している。修正のアクション、アラート及び/又はストレージ機能をいつトリガするかを、管理ストレージ要素で定めたルールに従って決定するために、上記の情報は統合(又はアグリゲーション)される。

【図面の簡単な説明】

【0005】

開示される具体例は添付図面を参照することにより更に理解されるであろう。

【0006】

【図1】ストレージ・クラスタの健全性を監視するヘルス・モニタを伴う2つの例示的なストレージ・クラスタを示す図。

【0007】

【図2】ストレージ・クラスタのモニタリングを実現するための例示的なモジュール群を示す図。

【0008】

【図3】ストレージ・クラスタ・ネットワーク及び関連するストレージ・クラスタ・ネットワークをモニタリングする動作例のフローチャートを示す図。

【0009】

【図4】イベント及びイベント履歴をモニタリングする動作例のフローチャートを示す図。

【0010】

【図5】ストレージ・クラスタ・ヘルス・モニタを有するシステム例を示す図。

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

【0011】

以下の説明は、本開示の技術を具現化する例示的なシステム、方法、技術、命令シーケンス及びコンピュータ・プログラム・プロダクトを含む。しかしながら、説明される形態は、これらの具体的な詳細なしに実施されても良いことが理解される。例えば、具体例はストレージ・クラスタ・ファブリックに言及しているが、実施形態は他のバックエンド接続コンフィギュレーションに適用されることが可能である。なお、周知の命令インスタンス、プロトコル、構造及び技術は、説明を曖昧にしないように、詳細には説明されていない。

【0012】

専門用語

【0013】

本説明は、データに対するアクセスをホスト及び/又は管理するストレージ・システム内の任意のエンティティ(any entity)を指すために、「ストレージ要素」という用語を使用する。本願で言及されるストレージ要素は、管理ストレージ要素及びホスティング・ストレージ要素(hosting storage elements)として分類されることが可能である。管理ストレージ要素及びホスティング・ストレージ要素の間の区別は、ストレージ要素の主要な機能に起因する。管理ストレージ要素は、主に、ホスティング・ストレージ要素に対するアクセスを管理する。管理ストレージ要素は、他のデバイス(例えば、クライアント)からのリクエストを処理し、オペレーション(例えば、スナップショット・オペレーション)を実行するためのリクエストを創出することが可能である。リクエストが他のデバイスからのものであるか或いは管理ストレージ要素から創出されたものであるかによらず、管理ストレージ要素はリクエストをホスティング・ストレージ要素へ送信する。管理ストレージ要素の具体例は、ファイル・サーバー及びストレージ・コントローラを含む。ホスティング・ストレージ要素は、主に、管理ストレージ要素からのリクエストを最終的に実施するオペレーションを実行する。ホスティング・ストレージ要素は、管理ストレージ要素からのリクエストにより指定されるロケーションの読み込み又はそれに対する書き込みを実行する。この読み込み又は書き込みは1つのディスク又は複数のディスクにおいて実行されて良い。仮想化による複数レイヤの場合、読み込み又は書き込みは、管理ストレージ要素の観点から言えば、1つのディスク又は複数のディスクであるように見えるものの上で実行される。ホスティング・ストレージ要素の具体例は、ディスク・ドライブ、光ディスク、ストレージ・アレイ、及びテープ・ドライブを含む。

【0014】

管理ストレージ要素及びホスティング・ストレージ要素という用語は、ストレージ要素の主要な機能に基づいて使用されており、その理由は、エレメント同士の間で機能は排他的ではないからである。例えば、ストレージ・コントローラは、アクセス・リクエストの取り扱いを促進するためにキャッシュにローカルに保存されたデータを有しても良い。ストレージ・コントローラがアクセス・リクエストを充足することが可能であったとしても、ストレージ・コントローラの主要機能は、ローカル・メモリからデータを読み込むこと及びそこへデータを書き込むことではない。同様に、ホスティング・ストレージ要素は、ディスクに対するアクセスを管理するハードウェアを含むことが可能である。例えば、RAIDコントローラ(a redundant array of independent disks (RAID) controller)及びディスクのアレイは、単独の筐体の中に収容されることが可能である。RAIDコントローラはディスクのアレイに対するアクセスを管理するが、単独の筐体に収容されるコンポーネントの主要な機能は、管理ストレージ要素から受信されるリクエストを実行することである。

【0015】

本説明は「帯域外又はアウトオブバンド(out-of-band)」及び「帯域内又はインバンド(in-band)」という用語を使用している。これらの用語は異なる通信チャネルに対応する。帯域内通信は、例えば、ストレージ・クラスタに関してデータ交換や管理に主に使用される通信チャネル上で通信される通信に関連する。帯域外通信は、データ交換や管理に主に使用されない通信チャネル上で通信されるメッセージに関連するが、帯域内通信チャネルよりも重要性の低い目的に使用されることが可能である。これらの通信チャネルは、(例えば、異なるケーブル、異なるインターフェース等のように)物理的に区別できるものとすることが可能であり、及び/又は異なる通信プロトコルとすることも可能である。

【0016】

本説明は「ネットワーク要素」という用語も使用している。ネットワーク要素という用語は、通信を指図するデバイスを指し、その通信は、ネットワークを介するデータ及びアクセス・リクエストを含むことが可能である。ネットワーク要素は、ルータ、スイッチ、ブリッジ等であるとすることが可能である。

【0017】

序 論

【0018】

ストレージ要素のクラスタ(「ストレージ・クラスタ」)は、複数のネットワークを介して及び/又は(例えば、数千キロメートルに及ぶ)長距離コネクションを介して相互接続される他のストレージ・クラスタと関連付けられる。ストレージ・クラスタは、上述した何らかのストレージ機能をサポートするために互いに関連付けられている。データ入手、フェイルオーバー、障害復旧などのために、データは、ストレージ・クラスタ同士の間で「ミラー化」され(mirrored)及びストレージ・クラスタ間で同期させられることが可能である。長距離にわたって隔てられるクラスタを関連付けることは、地域的な障害に対する感受性を減らし、データ・アベイラビリティの増進を許容する。

【0019】

(例えば、フェイルオーバー、ミラーリング等のような)クラスタ間でサポートされる何らかのストレージ機能は、ストレージ・クラスタ要素に関する情報を利用する。この情報は、コンフィギュレーション情報、環境情報、及び、統計量を含むことが可能である。この情報は本願では「ヘルス情報」のように言及され、なぜなら、ストレージ・クラスタの「健全性」(すなわち、動作の完全性(operational integrity))の指標となることが可能だからである。関連してはいるが分離しているストレージ・クラスタについての健全性のモニタリングは、ノード・スコープ及びクラスタ・スコープの双方で実行されることが可能である。クラスタ・スコープでストレージ・クラスタをモニタリングすることは、ストレージ・クラスタをサポートし且つストレージ・クラスタを接続するネットワーク要素をモニタリングすることを含む。初めに、各クラスタのファブリック・モニタが、クラスタ・トポロジを発見する。このクラスタ・トポロジは、ストレージ・クラスタの管理ストレージ要素により通信され維持される。ストレージ・クラスタ・トポロジが発見された後、各クラスタのファブリック・モニタは、ストレージ・クラスタのネットワーク要素のステータスを、周期的に判定することが可能である。これは、ストレージ・クラスタが、相互接続状態の自覚を維持すること、及び、ステータスの変更に反応することを許容する。更に、各々の管理ストレージ要素は自身の健全性を監視している。修正のアクション、アラート及び/又はストレージ機能をいつトリガするかを、管理ストレージ要素で定めたルールに従って決定するために、上記の情報は統合される。

【0020】

説 明

【0021】

図1は、ストレージ・クラスタの健全性を監視するヘルス・モニタを行う2つの例示的なストレージ・クラスタを示す。第1ストレージ・クラスタ101及び第2ストレージ・クラスタ103は同じ構成で描かれている。破線107はストレージ・クラスタ101、103の分離を示す。各々のストレージ・クラスタは、相互に接続された管理ストレージ要素(「フロント・エンド」)及びストレージ・バックエンドのグループを含む。各々のストレージ・クラスタに関し、図1に示される例示的なストレージ・バックエンド構成は、4つのストレージ要素・グループ(例えば、ストレージ・アレイ又はストレージ・スタック)と、管理ストレージ要素のネットワーク及びストレージ要素のネットワークを橋渡しする2つのブリッジ(例えば、ファイバ・チャネル(Fibre Channel)をSCSIへブリッジする)と、2つのスイッチとを含む(SCSIは、「Small Computer System Interface」の略である)。ストレージ・クラスタのスイッチの各々は、ネットワーク・クラウドとして描かれている長距離にわたって隔てられている他のストレージ・クラスタのピア・スイッチに接続する。ストレージ・クラスタ101のスイッチ104は、長距離ネットワーク105を介してストレージ・クラスタ103のスイッチ106に接続する。ストレージ・クラスタ101のスイッチ113は、長距離ネットワーク123を介してストレージ・クラスタ103のスイッチ108に接続する。当然に、他の構成も可能である。

【0022】

上述したように、各々のストレージ・クラスタ101、103は4つのストレージ管理要素も含む。ストレージ・クラスタ101は管理ストレージ要素109、115を含む。ストレージ・クラスタ103は管理ストレージ要素116を含む。ストレージ・クラスタ101、103の他の管理ストレージ要素は本説明に関して個々には特定されていない。管理ストレージ要素109は、ノード・モニタ111をホストする(即ち、ホストとして動作する)。ラベルは付されてはいないが、ストレージ・クラスタ101、103のうちの全ての管理ストレージ要素が、ノード・モニタをホストしている。ノードは、管理ストレージ要素のサブシステムの健全性を監視する。そして、ノード・モニタ111は、管理ストレージ要素109のサブシステムの健全性を監視する。管理ストレージ要素115は、ノード・モニタだけでなくファブリック・モニタ119もホストする。ファブリック・モニタ119は、双方のストレージ・クラスタ101、103のバックエンド・ファブリックのネットワーク要素の健全性を監視する。管理ストレージ要素116は、ファブリック・モニタ及びノード・モニタの双方をホストする。管理ストレージ要素116上で動作するファブリック・モニタは、双方のストレージ・クラスタ101、103のバックエンド・ファブリックの健全性も監視する。上述したように、単独のファブリック・モニタが、各ストレージ・クラスタにおいてインスタンス化される(instantiated)。管理ストレージ要素上で動作するファブリック・モニタの動作については、ファブリック・モニタ119のものと類似するので、更には説明されない。

【0023】

バックエンド・ファブリックにおける特定の問題に反応するファブリック・モニタ119の具体例として、一連のステージA-Eが図1に示されている。これらはファブリック・モニタの機能の説明を支援するために使用される例示的なステージ(又は段階)である。これらのステージは特許請求の範囲を限定するように使用されるべきではない。

【0024】

ステージAにおいて、ファブリック・モニタは、双方のストレージ・クラスタ101、103のトポロジを発見する。ポートが接続されると、ファブリック・モニタは、管理ストレージ要素115に接続されるネットワーク要素へ、情報を求めるリクエストを送信し始める。情報を求めるこれらのリクエストは、ファブリックを通じて、管理ストレージ要素に直接的に接続されるネットワーク要素へ伝搬する。トポロジに加えて、ファブリック・モニタ119は、ストレージ・クラスタ101、103のスイッチ及びブリッジからのヘルス情報を要求する。ファブリック・モニタ119は、パワー・サブシステムに関する情報、環境情報、コンフィギュレーション情報などを要求することが可能である。例えば、ファブリック・モニタ119は、要求される情報に対応するオブジェクトを規定する管理情報ベース(management information bases：MIBs)を有するシンプル・ネットワーク管理プロトコル(Simple Network Management Protocol (SNMP))メッセージを送出することが可能である。SNMPメッセージの利用は、ストレージ・クラスタの完了前に、ネットワーク要素から情報を収集し始めることを、ファブリック・モニタ119に許容する(これは、例えば、他の管理ストレージ要素に接続するために、ファイバ・チャネル・アダプタが管理ストレージ要素115にインストールされる前になされる)。トポロジを発見した後に、管理ストレージ要素115は、ストレージ・クラスタ101の他の管理ストレージ要素との間でトポロジ情報を共有する。同様に、管理ストレージ要素116は双方のストレージ・クラスタのトポロジを発見し、その情報を、ストレージ・クラスタ103の管理ストレージ要素との間で共有する。クラスタ・トポロジが確立した後に、ファブリック・モニタ119は、ヘルス情報を求めて、ストレージ・クラスタ101、103のネットワーク要素に周期的に問い合わせを行う。

【0025】

ステージBにおいて、スイッチ113のヘルス情報が変わる。ヘルス情報の変更例は、仮想ストレージ・エリア・ネットワーク(virtual storage area network： VSAN)コンフィギュレーションにおける変化、及び、温度変化を含む。

【0026】

ステージCにおいて、ファブリック・モニタ119は、周期的なモニタリング・リクエストの何れかの間にスイッチ113に問い合わせを行う。ファブリック・モニタ119は、VSANコンフィギュレーションの変化及びスイッチ113の温度を含む情報を収集する。

【0027】

ステージDにおいて、ファブリック・モニタ119は、収集した情報によりデータベース117を更新する。データベース117は、双方のストレージ・クラスタ101、103の管理ストレージ要素の間で維持され且つ同期させられる。データベース117が更新されると、ファブリック・モニタ119は、データベース117における少なくとも更新されたエントリに対して、ルールを適用する。例えば、そのルールは、スイッチ113の温度が所定の温度閾値を超えている場合には通知が生成されるべきこと、及び、スイッチ113の一部分が特定のVSAN用に構成されていない場合には通知が生成されるべきことを指示していても良い。

【0028】

ステージEにおいて、ファブリック・モニタ119はルールをデータベース117に適用し、アラート通知が生成されるべきことを確認する。ファブリック・モニタ119は、通知を生成し、それを、管理ストレージ要素115の他のモジュールに渡す。例えば、ファブリック・モニタ119は、管理ストレージ要素115のユーザー・インターフェースに対する通知を生成し、その通知は、スイッチ113の温度が温度警告閾値を超えたことを示す。その通知に基づいて、システム又はアドミニストレータは、是正措置をとる又は是正アクション・プランを開始することができる(例えば、スイッチ113の負荷を減らす)。

【0029】

図2は、ストレージ・クラスタのモニタリングを実現するための例示的なモジュール群を示す。図2には、ファブリック・データ・コレクタ203と、ファブリック・モニタ207と、クラスタ・モニタ209と、ノード・モニタ211とが描かれている。これらのモジュールは全て管理インターフェース201を通じて設定されることが可能である。ファブリック・データ・コレクタ203、ファブリック・モニタ207、クラスタ・モニタ209及びノード・モニタ211は、通知を生成し、その通知を管理インターフェース201へ提示することも可能である。図2にはサブシステム213、215も描かれている。ノード・モニタ211はサブシステム215と相互作用し、クラスタ・モニタ209はサブシステム213と相互作用する。

【0030】

ファブリック・データ・コレクタ203は、ストレージ・クラスタのバックエンド・ファブリック及び関連するストレージ・クラスタに関する情報を収集する。ファブリック・データ・クラスタ203は、ジョブ(即ち、一連のプログラム)を、バックグランド・プロセスとして実行させることが可能である。ファブリック・データ・クラスタ203は、ファブリック・データ・クラスタ203をホストするデバイス(「ノード」)のインターフェースに接続されるネットワーク要素を発見する。ファブリック・データ・クラスタ203は、ホスティング・ノード(the hosting node)から取り出されたネットワーク要素(例えば、高々n個のリンクだけ離れたネットワーク要素)をも発見する。ファブリック・データ・クラスタ203は、ホスティング・ノードに直接的に接続されるデバイスに問い合わせを行うことにより、或いは、これらのネットワーク要素から収集された情報を分析することにより、ホスティング・ノードに直接的に接続されるネットワーク要素を発見することが可能である。例えば、ファブリック・データ・クラスタ203は、ネットワーク要素から収集される転送テーブルを分析することが可能である。ファブリック・データ・クラスタ203は、ネットワーク要素から収集した情報により、クラスタ・データベース205を更新する。この情報は、クラスタのトポグラフィ(the cluster topography)及びネットワーク要素のヘルス情報を示す。図1に関して上述したように、クラスタ・データベース205は、ストレージ・クラスタの全ての管理ストレージ要素につながっている。

【0031】

ファブリック・モニタ207は、クラスタ・データベース205及びファブリック・データ・クラスタ203を利用してストレージ・クラスタ・ファブリックの健全性を監視する。ファブリック・モニタ207は、ファブリックのネットワーク要素からヘルス情報を周期的に収集することを、ファブリック・データ・クラスタ203に行わせる。ファブリック・モニタ207は、ルール217からのルール又はルールに対するリファレンスを、クラスタ・データベース205にインストールすることが可能である。ファブリック・データ・コントローラ203がクラスタ・データベース205を更新すると、その更新がルールの何れの条件にも違反しないことを保証するために、インストールされたルールが呼び出される。例えば、ファブリック・データ・コレクタ203は、クラスタ・データベース205の更新の一部分として、ルールを評価する。ファブリック・モニタ207は、クラスタ・データベース205においてインタレスト(interest)を登録し、更新が為された場合に通知又は割り込みを受信することも可能である。そして、ファブリック・モニタ207は、ルール217からのルールを、クラスタ・データベース205の更新されたエントリに適用することが可能である。ルール条件に違反する場合(例えば、不適切なスイッチ電源供給、ポート設定ミス等の場合)、ファブリック・モニタ207は管理インターフェース201に対する通知を生成することが可能である。しかしながら、通知が生成される前に、所定数の違反(violations)及び/又は違反の組み合わせを必要とするポリシーが規定されることが可能である。こうして、ファブリック・モニタ207は、通知又はアラートを生成する場合を判断するために、違反の履歴を維持することが可能である。

【0032】

クラスタ・モニタ209も、クラスタ・データベースにインタレストを登録し、及び/又は、ルール217からのルールをクラスタ・データベース205にインストールすることが可能である。クラスタ・モニタ209は、ファブリック・データ・コレクタ203及びクラスタ・データベース205により、ストレージ・クラスタのトポロジを認証する(即ち、正当性を確認する)。クラスタ・モニタ209は、ストレージ・クラスタの設定(例えば、単独のスイッチ・ファブリック)又は配備されるストレージ・クラスタにおいて違反(例えば、管理ストレージ要素の喪失)が無いことを保証するために、ファブリック・データ・クラスタ203にトポロジ・ルールを伝える。クラスタ・モニタ209は、他のルールの違反を判定するためにサブシステム213とやり取りを行う。サブシステム213の具体例は、相互接続サブシステム及びネットワーキング・サブシステムを含む。ネットワーキング・サブシステムは、ネットワーク・プロトコルの実装、(例えば、論理インターフェース、ソケット等のような)ネットワーキングに関する構造の管理、ネットワーキング機能(例えば、フェイルオーバー処理など)等を具現化することが可能である。クラスタ・モニタ209は、何れかのサブシステムに対して(例えば、アプリケーション・プログラミング・インターフェース(API)に対して)周期的にインターフェースを為すことが可能である。相互接続サブシステムの具体例に関し、クラスタ・モニタ209は、他の管理ストレージ要素との接続状態(例えば、プロトコル・コネクション、ポート統計量など)及びバックエンド・ストレージとの接続状態を判定するために周期的に機能を呼び出すことが可能である。ネットワーキング・サブシステムの具体例に関し、クラスタ・モニタ209は、クラスタ間コネクションのために設定される論理インターフェースの状態を判定するために周期的に機能を呼び出すことが可能である。クラスタ・モニタ209は、そのクラスタ・モニタの管理ストレージ要素もスキャンする。クラスタ・モニタ209は、コネクション、コンフィギュレーション(例えば、クラスタ間コネクションのためにインスタンス化されたオブジェクト)等を検証するために管理ストレージ要素をスキャンすることが可能である。ファブリック・モニタと同様に、クラスタ・モニタ209は通知が生成されるべきである場合を指定するルール及びポリシーに応じて、通知を生成することが可能である。しかしながら、通知が生成される前に、所定数の違反、違反の組み合わせ、及び/又は時間集計(time aggregation)を必要とするポリシーが定義されることが可能である。これに応じて、クラスタ・モニタ209は、通知又はアラートを生成する場合を判定するために、違反の履歴を維持することが可能である。

【0033】

ノード・モニタ211はホスティング・ノードの健全性を監視する。これを行うため、ノード・モニタ211はシステム215と相互作用する。サブシステムの具体例は、ストレージ・サブシステム、パワー・サブシステム及び相互接続サブシステムを含む。ノード・モニタ211は、APIsを有するサブシステム215と相互作用することが可能であり、或いは、(例えば、ファンの不具合(failed fan)、臨界温度、電力損失、ポート不具合などのような)特定のイベントの通知を受信するためにサブシステム・プロセスを登録することが可能である。場合によっては、クラスタ内部であってノード自体ではない問題を示唆するイベントが、サブシステム215から生成されることが可能である。例えば、サブシステム215は、クラスタ間インターフェースの不具合を示すイベントを生成することが可能である。ノード・モニタ211は、不具合を、可能性のある「バックホー」イベント(a possible "back-hoe" event)として示すイベントに、ルールを適用する。バックホー・イベントは、イベントの規模及び/又は影響が及ぶネットワーク関係に依存して、サイト、システム、クラスタ、領域等との接続の完全な欠落に関わる。接続の欠落に関する共通の原因は、ケーブルを切断する実際のバックホー(又は掘り起こし)であることに起因して、このイベントはバックホーに関連付けられる。しかしながら、バックホー・イベントは他のイベント(例えば、自然災害)であるとすることが可能である。可能性のあるバックホー・イベントに対するルールは、クラスタ・モニタ209に通知するノード・モニタ211のアクションを規定することが可能である。これに応じて、クラスタ・モニタ209は、バックホー・イベントが生じたか否かを判定するために、一連のオペレーションを実行することが可能である。クラスタ・モニタ209は、例えば、関連するストレージ・クラスタ内の全ての提携した管理ストレージ要素(all partnered managing storage elements)に、PING信号を送信することを、(例えば、障害復旧ピア・ストレージ・クラスタのような)ストレージ・クラスタの全ての管理ストレージ要素に行わせることが可能である。

【0034】

バックホー・イベントの高速検出は、バックホー・イベントに対する速やかの応答を可能にする。バックホー・イベントが中断すると、ファブリック・モニタ209は、関連するストレージ・クラスタのネットワーク要素へ、帯域外メッセージ(例えば、SNMPリクエスト)を送信するために、ファブリック・データ・コレクタ203をトリガする(又はその契機を与える)。更に、クラスタ・モニタ209は、ストレージ・クラスタの管理ストレージ要素に、ハートビート(heartbeats)の検査を行わせることが可能である。一例として、ハートビートは、ファイバ・チャネル仮想インターフェースによる、関連するストレージ・クラスタの管理ストレージ要素におけるハートビート・カウンタの遠隔的なダイレクト・メモリ・アクセスの読み込みとして実現されることが可能である。

【0035】

図示の個々のモジュールは、機能の理解を支援するための機能に基づく構成である。図2は請求項の範囲を特定のモジュール又はプログラム機構に狭めるように使用されるべきではない。例えば、単独のモジュールは、ファブリック・モニタ207及びファブリック・データ・コレクタ209の説明された機能を包含するように実現又は記述されることが可能である。更に、実現は様々なプラットフォームに応じて異なるであろう。一例として、モニタリングの実現は、マルチ・スレッド・シングル・コア・プロセッサ及びマルチ・プロセッサ・ノードの間で異なることが可能である。

【0036】

上記の具体例はストレージ・クラスタ・ファブリックに言及していたが、特許請求の範囲はそのように限定されない。ストレージ・クラスタは、ファブリックとともに構成されること(即ち、管理ストレージ要素同士の間に完全なコネクションが存在すること)が一般的であるかもしれないが、そのような接続構成は必須ではない。以下の具体例は、ファブリックだけではなく、ストレージ・クラスタ・ネットワークに関してより一般的に言及している。以下の具体例は、図2に示される特定のモジュールの区分けによらない動作例のフローチャートを示す。

【0037】

図3は、ストレージ・クラスタ・ネットワーク及び関連するストレージ・クラスタ・ネットワークをモニタリングする動作例のフローチャートを示す。ブロック同士の間の破線は、動作フローが直結していないことを示し、応答又は中断の間待機していることを示す。この図はストレージ・クラスタのクラスタにも言及している。このオペレーションは或るノードに関連して説明され、そのノードは、オペレーションを実行するストレージ・クラスタにおける管理ストレージ要素である。

【0038】

ブロック301において、ノードは、そのストレージ・クラスタのネットワーク・トポロジを発見し、それに応じてクラスタ・データベースを更新する。コネクションが設定されると、ノードは、バックエンドにおけるエレメントを発見するために連絡(又は通信信号)を送る。バックエンド・エレメントは、ストレージ要素及びネットワーク要素の双方だけでなく、他の管理ストレージ要素も含むことが可能である。ノードは、管理ストレージ要素以外の様々なインターフェース/ポート/カードによりバックエンドに接続される。ノードは、物理インターフェース、論理インターフェース、ワールドワイド・ネーム(worldwide names)及びネットワーク・アドレスの任意の組み合わせを利用して、ストレージ・クラスタ・トポロジを決定することが可能である。ノードは、帯域外及び帯域内の通信によりトポロジを発見することが可能である。例えば、ノードは、SNMPメッセージをネットワーク要素へ帯域外で(例えば、ファイバ・チャネル以外で)送信することが可能である。例えば、ストレージ・ノードが設定されつつある間に及び/又はクラスタ関係が設定されつつある間に、ノードは、初めに、第1期間における帯域外通信によりトポロジを発見することが可能である。その後、収集されたトポロジ情報の更新が、帯域内通信に基づいて行われることが可能である。この第2の又は以後の期間は、所定のイベントが生じるまで(例えば、クラスタ関係の崩壊又は変更になるまで)持続することが可能である。更に、ノードは、所定のインターバルで動作情報及び/又はトポロジ情報を収集するために、帯域内及び帯域外の通信の間で遷移することが可能である。所定のインターバルは、イベントの発生に依存することが可能であり、或いは、イベントに依存しないことも可能である。例えば、ノードは、帯域内通信が設定されたところである旨が通知されるまで、帯域外通信を利用することが可能である。可能性のあるバックホー・イベントの通知の後に、ノードは、可能性のあるバックホー・イベントの解決までの所定の期間にわたって帯域内及び帯域外の通信の間で変更を行うことが可能である。ノードは、ストレージ・クラスタのメンバーから受信した又は取り出した情報により、クラスタ・データベースを更新する。ノードは、(例えば、モニタリング又は災害復旧の関係を有するストレージ・クラスタ等のような)関連するストレージ・クラスタのトポロジも発見する。ノードは、クラスタ間コネクションのために構成されるインターフェースを決定する。例えば、指定されたネットワーク要素を通じて関連するクラスタの管理ストレージ要素への接続のために、論理インターフェースが管理ストレージ要素で設定されることが可能である。

【0039】

ブロック303において、ノードは、発見されたネットワーク・トポロジに検証ルールを適用する。クラスタ・ストレージ・トポロジの少なくとも一部が発見された後に、発見されたトポロジは検証ルールにより表現される仕様を順守しているか否かを判定するために、その情報にトポロジ検証ルールが適用されることが可能である。例えば、トポロジ検証ルールは、所定数のスイッチ、関連するストレージ・クラスタ間の冗長的な経路、所定数の管理ストレージ要素等を要求することが可能である。

【0040】

ブロック305において、ノードは、発見されたクラスタ・ストレージ・トポロジが、ブロック303で適用されるトポロジ検証ルールに応じて有効であるか否かを判定する。発見されたトポロジが有効である場合、制御はブロック309へ流れる。そうでない場合、制御はブロック307へ流れる。ブロック307において、ノードは、発見されたネットワーク・トポロジ検証ルールに違反している通知を生成する。通知は、違反していたトポロジ・ルール(例えば、バックエンド・ファブリックにおいて最低限2つのスイッチ)を指定することが可能である。

【0041】

ブロック309において、ストレージ・クラスタ・ネットワークのネットワーク要素の各々について、反復する動作が始まる。例示的な反復する動作はブロック311により表現されている。

【0042】

ブロック311において、ノードは、ストレージ・クラスタのうち発見されたネットワーク要素からの動作情報(「ヘルス情報」)を要求する。動作情報の具体例は、環境情報(例えば、現在の温度、製造業者が推奨する動作温度)、コンフィギュレーション情報(例えば、VSANコンフィギュレーション、プロトコル・コンフィギュレーション等)、サブシステム情報(例えば、電力供給情報、ファン情報(fan information))、及び、動作統計量(例えば、スループット、欠落したパケット、コネクション当たりの負荷など)を含む。ノードは、ネットワーク要素の各情報源(例えば、オペレーティング・システム、プロトコル・モジュール等)をターゲットとする一連のリクエストを送信する。例えば、ノードは、動作統計量を求めるリクエストを別途送信する前に、コンフィギュレーションに関する情報を求めるリクエストを送信することが可能である。ノードは、全ての動作情報が要求されていることを示す単独のリクエストを送信することが可能である。メッセージのフォーマットは事前に合意されるであろう。場合によっては、ノードは、動作情報を要求する前に、ネットワーク要素を構成しても良い。一例として、ノードは、メッセージの仕様及び報告するプロトコルをネットワーク要素に通知しても良い。ノードは、報告プロトコル及びメッセージ仕様をサポートするコードをインストールしても良い。動作情報の初期の収集の後、ノードは、以後のリクエストで動作情報の一部分のみを要求しても良い。

【0043】

ブロック313において、ノードは、動作情報が取得される元となる更なる発見されたネットワーク要素が存在するか否かを判定する。この時間ウィンドウの中にそれ以上のものが無い場合、制御はブロック315に流れる。問い合わせる追加的な発見されたネットワーク要素が存在する場合、制御はブロック309に流れる。

【0044】

ブロック315において、ノードは、モニタ・トリガを待機する。モニタ・トリガは時間期間の満了であっても良い。ノードは、所定の期間において、バックエンド・ネットワーク要素を含むクラスタ・メンバーから動作情報を収集するように構成されることが可能である。モニタ・トリガは、イベント駆動型又はインタラプト駆動型のトリガであるとすることが可能である。例えば、ノード・サブシステムにおけるイベントは、ある期間の満了前に、全部又は特定のクラスタ・メンバーから、全体的又は特定の動作情報を要求することを、ノードに行わせることが可能である。モニタ・トリガの後、制御はブロック309に流れる。

【0045】

ブロック317において、ノードは、ストレージ・クラスタ・ネットワークのエレメントから、動作情報を受信する。ブロック311からブロック317への破線は、ノードが動作情報を受信することを示す。動作情報は、ブロック311のリクエストの後であって実装される何らかのタイムアウト・メカニズムの前の任意の時点で受信されることが可能である。従って、ブロック311及び317の間のシーケンスは必須のシーケンスではない。言い換えれば、ノードは、エレメントX、Y及びZからの動作情報を要求した後に、エレメントXから動作情報を受信するかもしれない。

【0046】

ブロック319において、ノードは、受信した動作情報に従ってクラスタ・データベースを更新する。ノードは、エレメントから受信される動作情報の全てを必ずしも書き込む必要はない。ノードは、受信される動作情報のうち一部分のみを書き込んでも良い。場合によっては、ノードはクラスタ・データベースに何も書き込まないかもしれない。例えば、応答するエレメントは動作ファン(operational fan)を有し、許容可能な温度で動作していることを、動作情報が示しているかもしれない。その場合、ノードは、その要素が応答したという通知以外何もクラスタ・データベースを更新しなくて良い。

【0047】

ブロック321において、ノードは、受信した動作情報がルールに反するか否かを判定する。概念的には、ルールは、スイッチの送信電力が所定の閾値を超えるものであっても良い。プログラム・コードにおいて、ルールは、或る条件として表現され、例えば、所定の閾値を上回るスイッチの送信電力である。従って、ルールの違反は、プログラム・コードにおけるルールを表現する条件の充足である。ルールは、ルールに違反する場合に行うアクションを示す又はそれに関連する/それを参照することが可能である。一例として、ネットワーク要素の動作電圧が閾値を超える場合、管理インターフェースに対するアラート通知を生成する。ノードは、(例えば、スイッチ電圧のような)動作情報を表現するパラメータでルールをインデックス化することにより、一群のルールにアクセスすることが可能である。別の例として、クラスタ・データベースのエントリがルールに関連付けられることが可能である。ルールは、クラスタ・データベースで参照される又は文字通り組み込まれることが可能である。エントリが更新されると、対応するルールが評価され、それに違反するか否かを判定する。ルールに違反する場合、制御はブロック323に流れる。そうでない場合、ノードが再び動作情報を受信すると、制御はブロック317に戻る。

【0048】

ブロック323において、ノードは通知を生成するか否かを判定する。あるルールは違反するかもしれないが、ルールに依存して、個数又は期間の観点から違反を統合するようにポリシーが規定されても良い。例えば、ポリシーは、指定期間内で動作温度ルールに対する警告レベルの反復的な違反に関する通知の生成を条件付けても良い。或いは、ノードは、臨界温度レベルの1回の違反に応じて通知を生成しても良い。通知が生成されるべき場合、制御はブロック325へ流れる。ブロック325はルールに従って通知を生成する。ルールは、ユーザー・インターフェースでアラートが生成されること、或いは、エラー履歴が更新されることを指定してもよい。

【0049】

ブロック327において、ノードはルール違反を追跡する。ノードは、違反の集まりが通知生成を契機となる場合に、ルール違反を追跡する。ルール違反は、通知が生成された場合でさえ、追跡されることが可能である。同じルールの複数の違反に関し、異なる通知が生成されても良い。更に、ルールは、追跡が実行されるべきか否かを指定することが可能である。

【0050】

ルール違反を追跡することに加えて、ノードは、他のイベントとの組み合わせ又は累積によりルールに違反するイベントを追跡することが可能である。図2はAPIsを有するサブシステムとの相互作用を主に示しているが、その実現は、メッセージの受け渡し、イベント生成、及びモニタリング用APIの任意の組み合わせを利用することが可能である。

【0051】

図4は、イベント及びイベント履歴をモニタリングする動作例のフローチャートを示す。図4の動作は、図3と同様にストレージ・クラスタのノードに関連して説明される。

【0052】

ブロック401において、ノードは、イベントの通知を受信し、イベントに対応するルールを評価する。ノードに関するモニタリング・プロセスは、イベントの通知を受信するために、ノードの他のプロセスに登録する。モニタリング・プロセスは、イベントのタイプ、特定のサブシステム、サブシステム及びイベント・タイプの組み合わせ等を指定することが可能である。例えば、モニタリング・プロセスは、サブシステムのプロセスに登録することが可能である、或いは、ノードのオペレーティング・システムのセントラル化されたプロセスに登録することが可能である。ノードは、イベント通知の内容及び通知元のサブシステムに基づいて、イベントに対応するルールを決定する。一群のルールが、各々のサブシステムについて規定されることが可能である。例えば、一群のルールは、相互接続サブシステムについて規定されることが可能である。ルールは、統計量に基づくルール、接続時間ルール、論理インターフェース・ルール等を含むことが可能である。

【0053】

ブロック403において、ノードは、評価されたルールによれば、そのイベント単独でアラート通知をトリガするか否か(又は契機となり得るか否か)を判定する。なり得る場合、ノードはブロック405においてアラート通知を生成する。アラート通知は、ユーザー・インターフェース、メッセージング、又は、ノードのプロセス間の通信により、提示するために生成されることが可能である。イベント単独でアラート通知のトリガとはならない場合、制御はブロック407に流れる。

【0054】

ブロック407において、ノードは、イベントが他のイベントとの組み合わせによりアラート通知をトリガするか否かを判定する。他のイベントは、所与の期間の間に生じる異なるイベントであっても良いし、或いは、他のイベントはそのイベントの以前の出現であっても良い。イベントが他のイベントとの組み合わせでアラート通知をトリガとなり得る場合、制御はブロック409に流れる。そうでない場合、制御はブロック417に流れる。

【0055】

ブロック409において、ノードは、他のノードが既に登録されているか否か (即ち、既に生じているか否か)を判定する。そうである場合、制御はブロック411に流れる。そうでない場合、制御はブロック413に流れる。他のイベントと組み合わせるイベントの具体例は、クラスタ間コネクションの場合に設定される論理インターフェースの不具合である。他のノードが関連するストレージ・クラスタに対するコネクションを有する場合、論理インターフェースの不具合はおそらくローカルなものである。論理インターフェースの不具合が検出される場合に、ノードは、その不具合を、ストレージ・クラスタを現在モニタリングしているノードへ連絡することを、ルールは指定することが可能である。ノードがストレージ・クラスタをモニタリングしているノードである場合、ルールは、他のノードに、関連するストレージ・クラスタにおける各自の相手にPING信号を送るように要求することを、指定することが可能である。

【0056】

ブロック413において、ノードは他のイベントに対応するサブシステムを決定する。一例として、イベントは、警告閾値を超えるが、臨界温度閾値を超えてはいない温度であっても良い。ルールは、ノードが冷却サブシステムからファン状態を判定すべきであることを指定することが可能である。場合によっては、サブシステムは異なるノードにおけるものであっても良い。例えば、クラスタ・モニタ・ノードは、ストレージ・クラスタの他のノードに連絡することを判定する。

【0057】

ブロック419において、ノードは、他のイベントが生じたか否かを判定するためにサブシステムに問い合わせる。ルールが、ノードは冷却サブシステムに問い合わせるべきであることを指示している場合、ノードはファン状態について冷却サブシステムに問い合わせる。ルールが、(クラスタ・モニタとして動作する)ノードが他のノードのコネクション状態を問い合わせることを指示していた場合、ノードは、他のノードに、関連するストレージ・クラスタにおける各自の相手にPING信号を送信することを指示し、その結果に基づいて応答することを要求する。

【0058】

ブロック421において、ノードは問い合わせ(即ち、クエリ)に対する応答を受信する。応答を受信した後、制御はブロック411へ流れる。

【0059】

ブロック411において、ノードは、イベント・トリガの組み合わせがアラート通知をトリガするか否かを判定する。イベント・トリガの組み合わせがアラート通知をトリガする場合、制御はブロック415へ流れ、その場合、ノードはアラート通知を生成する。そうでない場合、制御はブロック417へ流れる。ブロック417において、ノードはイベントを示すようにイベントの履歴を更新する。

【0060】

フローチャートは、説明の理解を促すために提供されており、特許請求の範囲を限定するようには使用されるべきでない。フローチャートは、本開示の実施形態の中で変わり得る動作例を描いている。追加的な動作が実行されても良いし；より少ない動作が実行されても良いし；複数の動作が並列的に実行されても良いし；及び、動作が異なる順序で実行されても良い。例えば、ブロック301及び303に示される動作はオーバーラップしていても良い。或る期間の後、又は、所定数のクラスタ・メンバーが発見された後に、ノードはトポロジ・ルールの適用を開始することが可能であり、これらのルールの適用の継続は、更なるストレージ・クラスタが発見される場合であっても良い。別の例として、図3は、ブロック309、311及び313を含む動作のループを描くように見えている。実施形態はループを実行することを必要とせず、反復シーケンスの変形例に加えて、動作の割り込みを許容しても良い。図4に関し、ノードは、組み合わせイベント・ルール評価の結果に応じて、イベント履歴を更新することが可能である。

【0061】

当業者に認められるように、本開示の実施形態は、システム、方法、又は、1つ以上のマシン読み取り可能な媒体に保存されるプログラム・コード/命令として組み込まれても良い。従って、実施形態は、ハードウェア、ソフトウェア(ファームウェア、常駐ソフトウェア、マイクロ・コード等を含む)、又は、ソフトウェア及びハードウェアの組み合わせの形式をとっても良く、本願においてこれらは全て包括的に「回路」、「モジュール」又は「システム」として言及されても良い。例示の説明で個別的なモジュール/ユニットとして示される機能は、プラットフォーム(オペレーティング・システム及び/又はハードウェア)、適用する生態系(application ecosystem)、インターフェース、プログラマの好み、プログラミング言語、アドミニストレータの好み等のうちの任意の何れかに従って様々に組織化されることが可能である。

【0062】

1つ又は複数のマシン読み取り可能な媒体の任意の組み合わせが使用されて良い。マシン読み取り可能な媒体は、マシン読み取り可能な信号媒体又はマシン読み取り可能な記憶媒体であっても良い。マシン読み取り可能な記憶媒体は、例えば、プログラム・コードを保存するために、電子的、磁気的、光学的、電磁的、赤外線的又は半導体的な技術のうちの任意の何れか又は組み合わせを利用するシステム、装置又はデバイスであっても良いが、これらの例に限定されない。マシン読み取り可能な記憶媒体の更に具体的な例は以下のものを含む(以下の列挙は網羅的ではない)：携帯用コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ(RAM)、リード・オンリ・メモリ(ROM)、消去可能でプログラム可能なリード・オンリ・メモリ(EPROM又はフラッシュ・メモリ)、携帯用コンパクト・ディスク・リード・オンリ・メモリ(CD-ROM)、光ストレージ・デバイス、磁気ストレージ・デバイス、又は、それらの適切な任意の組み合わせ。この文献の文脈において、マシン読み取り可能な記憶媒体は、命令実行可能システム、装置又はデバイスにより使用するための又はそれらとの組み合わせのためのプログラムを包含又は保存することが可能な任意の有形媒体であって良い。

【0063】

マシン読み取り可能な信号媒体は、例えば、ベースバンドで又は搬送波の一部として、そこに組み込まれるマシン読み取り可能なプログラム・コードを含む伝送されるデータ信号を含んで良い。そのような伝送される信号は任意の様々な形式をとっても良く、電磁的な、光学的な又はそれらの適切な任意の組み合わせによる形式を含んでも良いが、これらの例に限定されない。マシン読み取り可能な信号媒体は、マシン読み取り可能な記憶媒体ではなく且つ命令実行システム、装置又はデバイスにより使用するための又はそれらに関連するプログラムを通信、伝搬又は転送することが可能な任意のマシン読み取り可能な媒体であって良い。

【0064】

マシン読み取り可能な媒体に組み込まれるプログラム・コードは、無線、優先、光ファイバ・ケーブル、RF等又はそれらの適切な任意の組み合わせを含む適切な任意の媒体を利用して伝送されて良いが、これらの例に限定されない。

【0065】

本開示の実施形態のためのオペレーションを実行するためのコンピュータ・プログラム・コードは、1つ以上のプログラミング言語の任意の組み合わせで書かれても良く、プログラミング言語は、ジャバ(登録商標)プログラミング言語、C++等のようなオブジェクト指向プログラミング言語；パイソン(Python)のようなダイナミック・プログラミング言語；パール(perl)プログラミング言語又はPowerShellスクリプト言語等のようなスクリプト言語；「C」プログラミング言語又は類似するプログラミング言語等のような通常の手続プログラミング言語を含む。プログラム・コードは、スタンド・アローン・コンピュータで完全に実行しても良いし、複数のコンピュータにわたって分散形式で実行しても良いし、或るコンピュータで実行する一方、他のコンピュータで結果を提供し及び/又は入力を受け入れても良い。

【0066】

具体例は、本開示の実施形態による方法、装置(システム)及びプログラム・コードについてのフローチャート説明及び/又はブロック図を参照しながら説明される。フローチャート説明及び/又はブロック図の各ブロック、及び、フローチャート説明及び/又はブロック図のブロックの組み合わせは、プログラム命令により実現可能であることが理解されるであろう。プログラム命令は、汎用コンピュータ、専用コンピュータ、又はマシンをもたらすその他のプログラム可能なデータ処理装置のプロセッサに提供され、それにより、コンピュータ又はその他のプログラム可能なデータ処理装置のプロセッサによる実行は、フローチャート及び/又はブロック図の1つ以上のブロックに示される機能/動作を実現する手段をもたらす。

【0067】

プログラム命令は、コンピュータ、その他のプログラム可能なデータ処理装置又はその他のデバイスに、特定の方法で機能するように指図することが可能なマシン読み取り可能な媒体に保存されても良く、それにより、マシン読み取り可能な媒体に保存される命令は、フローチャート及び/又はブロック図の1つ以上のブロックに示される機能/動作を実現する命令を含む製品をもたらす。

【0068】

プログラム命令は、コンピュータ、その他のプログラム可能なデータ処理装置又はその他のデバイスにロードされ、コンピュータ、その他のプログラム可能なデータ処理装置又はその他のデバイスにおいて、一連の動作ステップが実行され、コンピュータで実現されるプロセスをもたらすことを引き起こし、それにより、コンピュータ又はその他のプログラム可能な装置において実行する命令は、フローチャート及び/又はブロック図の1つ以上のブロックに示される機能/動作を実現するプロセスを提供する。

【0069】

図5はストレージ・クラスタ・ヘルス・モニタを有するシステム例を示す。システムはプロセッサ・ユニット501を含む(おそらくは、複数のプロセッサ、複数のコア、複数のノードを含み、及び/又は、マルチスレッド等を実現する)。コンピュータ・システムはメモリ507を含む。メモリ507は、システム・メモリ(例えば、キャッシュ、SRAM、DRAM、ゼロキャパシタRAM、ツイン・トランジスタRAM、eDRAM、「EDO RAM」、「DDR RAM」、EEPROM、 NRAM、RRAM、SONOS、PRAM等のうちの1つ以上)、或いは、マシン読み取り可能な媒体の上記の可能な実現手段のうちの1つ以上の任意のものであっても良い。コンピュータ・システムは、バス503(例えば、PCI、ISA、PCI-Express、 HyperTransport(登録商標)バス、InfiniBand(登録商標)バス、NuBus等)、ネットワーク・インターフェース(例えば、ファイバ・チャネル、イーサーネット(登録商標)インターフェース、インターネット・スモール・コンピュータ・システム・インターフェース、インターフェース、SONETインターフェース、無線インターフェース等)、及び、ストレージ・デバイス509(例えば、光ストレージ・磁気ストレージ等)を含む。システムはストレージ・クラスタ・ヘルス・モニタ511も含む。ストレージ・クラスタ・ヘルス・モニタ511は、ストレージ・クラスタのストレージ要素、ストレージ・クラスタのバックエンド要素、及び、関連するストレージ・クラスタのエレメントの健全性を監視する。これらの機能のうちの何れもハードウェア及び/又は処理ユニット501において部分的に(又は全体的に)実現されて良い。例えば、その機能は、特定用途向け集積回路、処理ユニット501に実装されるロジック(又は論理装置)、ペリフェラル・デバイス又はカードにおけるコプロセッサ等により実現されても良い。更に、実現手段は、図5に示されるものより少ない又は追加的なコンポーネントを含んでも良い(例えば、ビデオ・カード、オーディオ・カード、追加的なネットワーク・インターフェース、ペリフェラル・デバイス等を含んでも良い)。プロセッサ・ユニット501、ストレージ・デバイス509及びネットワーク・インターフェース505は、バス503に結合される。バス503に結合されるように図示されているが、メモリ507はプロセッサ・ユニット501に結合されても良い。

【0070】

本開示は様々な実現手段及び実施例に関連して説明されているが、説明は例示的であること、及び、特許請求の範囲はそれらに限定されないことが理解されるであろう。一般に、ストレージ・クラスタ及び関連するストレージ・クラスタの健全性を本願で説明されるように監視することは、何らかのハードウェア・システム又は複数のハードウェア・システムに調和する設備とともに実現されて良い。様々な変形、修正、追加及び改善が可能である。

【0071】

単独のインスタンス(a single instance)として本願で説明されたコンポーネント、オペレーション又は構造に関して、複数のインスタンスが提供されても良い。最後に、様々なコンポーネント、オペレーション及びデータ・ストアの間の境界は、いくらか任意的であり、特定のオペレーションは、特定の例示的なコンフィギュレーションの文脈で説明される。機能についての他の応用例も想定されており、それらも特許請求の範囲に属する。一般に、例示的なコンフィギュレーションにおいて個別的なコンポーネントとして提示される構造及び機能は、結合された構造又はコンポーネントとして実現されて良い。同様に、単独のコンポーネントとして提示された構造及び機能は、個別的なコンポーネントとして実現されても良い。これら及び他の変形、修正、追加及び改善は、特許請求の範囲に属する。

【図1】

【図2】

【図3】

【図4】

【図5】