JP5476481B2 - ノード故障の対処 - Google Patents

Description

本発明は、複数の記憶デバイスと通信する分散型多重処理コンピュータ・システムに関する。より特定的には、本発明は、動的レプリカ・ボリューム・スワップ（ｄｙｎａｍｉｃ ｒｅｐｌｉｃａ ｖｏｌｕｍｅ ｓｗａｐ：ＤＲＶＳ）動作の際の１つまたはそれ以上のノードの故障に対処することに関する。

コンピュータ科学において、クラスタとは一緒に作業して単一のコンピュータ・システムを形成する、ノードとしても公知のコンピュータの群である。クラスタには異なるカテゴリがあり、それは高可用性クラスタおよびグリッド・クラスタを含むがそれに限定されない。高可用性クラスタはクラスタのサービスの可用性を改善するために用いられ、ここでクラスタの各メンバは複数の記憶デバイスと通信する。高可用性クラスタにおいては、時に記憶デバイスが故障したときに、記憶故障におけるアプリケーション許容力（ａｐｐｌｉｃａｔｉｏｎ ｒｅｓｉｌｉｅｎｃｅ）を提供することが望ましい。記憶デバイスの故障は、もし故障したかまたは故障している記憶デバイスに重要なデータが維持されていれば、システムを破壊するおそれがある。なぜなら、たとえ同期的記憶複製を用いて別の記憶システムにデータの最新レプリカを維持していたとしても、アプリケーションにレプリカ・データが使用可能になる前にアプリケーションを停止して再始動させる必要があり、企業環境によってはこうしたアプリケーションの停止は許容できないことがあるためである。

たとえばＩＢＭ（登録商標）のＨｙｐｅｒＳｗａｐ（ＩＢＭ社の登録商標）動作などの動的レプリカ・ボリューム・スワップ動作は、連続的な可用性の解決策であり、ここでは、記憶ボリュームの群を含む同期的に複製された記憶システムにアクセスするノードの組が、１次記憶システムから２次（レプリカ）記憶システムに切り替わるが、これはクラスタ内のいずれのノードにおけるいかなるアプリケーション停止も起こることなく行なわれる必要がある（ＩＢＭおよびＨｙｐｅｒＳｗａｐは、米国、その他の国、またはその両方におけるインターナショナル・ビジネス・マシーンズ社（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ）の登録商標である）。動的レプリカ・ボリューム・スワップ動作は記憶システム故障が原因で行なわれてもよく、これは非計画的（ｕｎｐｌａｎｎｅｄ）動的レプリカ・ボリューム・スワップとして公知であり、代替的には管理制御下で行なわれてもよく、これは計画的（ｐｌａｎｎｅｄ）動的レプリカ・ボリューム・スワップとして公知である。さらに、動的レプリカ・ボリューム・スワップ動作は記憶システム中のブート・ボリュームおよび非ブート・ボリュームの両方を伴ってもよい。

図１は、システム・エラーを起こし得るクラスタ化環境における先行技術の動的レプリカ・ボリューム・スワップ動作の例を示す流れ図（１００）である。この例のクラスタは、１次記憶システム上の１つまたはそれ以上の記憶ボリュームと、２次システム上の対応するレプリカ・ボリュームとを有する記憶サブシステムと通信する少なくとも２つのノードからなる（１０２）。クラスタ内の各ノードは、２次記憶システムにレプリカを有する１次記憶システム中の（ブート）ボリュームからブートする（１０４）。クラスタ内の第３のノードは一時的オフライン状態にある（１０６）。動的レプリカ・ボリューム・スワップ動作が呼び出され（１０８）、ここで１次記憶システムに存在するブート・ボリュームはもはやアクセスに対して有効でなくなり、代わりに２次記憶システム中のそれらのボリュームのレプリカが優先ボリュームとなる。これは第３のノードがオフラインの間に起こるため、結果として第３のノードは動的レプリカ・ボリューム・スワップ動作を認識していない。動的レプリカ・ボリューム・スワップ動作の完了後のある時点で、第３のノードがオンラインとなり、１次記憶システムに対してローカルなブート・ボリュームからブートしようとする（１１０）。動的レプリカ・ボリューム・スワップ動作の後にたとえ１次記憶システム上のそのブート・ボリュームがアクセス可能だったとしても、このブート・ボリュームはアクセスに対して有効ではない。より特定的には、管理者によって作成されるクラスタ内のノードに対するブート・ボリューム上のブート・イメージに対するすべての更新が、２次記憶システム上に作成される。（専用アーキテクチャを有さない汎用計算システムでは）クラスタにはブート・ボリュームの場所を参照するための中央共用メモリがないため、第３のノードは１次記憶システム中の誤ったブート・ボリュームからブートする（１１０）。したがって、動的レプリカ・ボリューム・スワップ動作の際にオフラインであったか、またはオンラインになるプロセス中であったノードにブート・ボリューム再配置を伝えるための構成要素がクラスタ計算環境には存在しない。

図１に示される問題に対する解決策の１つは、リブートの際に各ノードによって使用されるべき正しいブート・ボリュームを常時含んだ中央共用メモリ設備を提供することである。

しかし、こうした中央メモリはクラスタ化環境における活用のために利用できない。したがって、動的レプリカ・ボリューム・スワップ動作の際にオフラインであったか、またはオンラインになるプロセス中であった、すなわちクラスタに再結合する任意のノードに正しいブート・ボリュームを伝えて、影響されたノード（単数または複数）がオンラインとなってクラスタに結合する際に正しいブート・ボリュームからブートすることを確実にするための、クラスタ化環境における動的レプリカ・ボリューム・スワップ動作を支援する解決策が必要とされている。

本発明の実施形態は、ブートの全段階におけるすべての現在および将来のクラスタ・メンバ・ノードを収容するクラスタ化環境における動的レプリカ・ボリューム・スワップ動作を支援するための方法、システムおよび物品を含む。

本発明の一局面においては、たとえば中央共用メモリなどの専用ハードウェア構成要素なしにオフライン・ノードに対するブート・ボリューム・アクセス問題を解決する、動的レプリカ・ボリューム・スワップ動作をオープン・システムに適応させるための方法が提供される。クラスタ内の各ノードは、２つまたはそれ以上のブート・ボリュームのリストを備えて構成される。各ノードに対するリストは各ノードのフラッシュ・メモリに保存され、このブート・ボリューム・リストはノードと１次記憶サブシステムとの間の第１の論理パス、およびノードと２次記憶サブシステムとの間の第２の論理パスを含む。第１の論理パスは優先ブート・ボリュームを指すのに対し、第２の論理パスは非優先ブート・ボリュームを指す。動的レプリカ・ボリューム・スワップ動作に応答して、その動的レプリカ・ボリューム・スワップ動作に関与する各ノードに対して、第１および第２の論理パスの役割が変更される。この役割変更は、第１の論理パスを２次記憶サブシステム上の非優先ブート・ボリュームに向けることと、第２の論理パスを１次記憶サブシステム中の優先ブート・ボリュームに向けることとを含む。

本発明の別の局面においては、２つまたはそれ以上のノードを有するクラスタにおける動的レプリカ・ボリューム・スワップ動作を管理するためにコンピュータ・システムが導入される。クラスタ内の各ノードは管理ノードと通信する。各ノードのフラッシュ・メモリ中に少なくとも２つのブート・ボリュームのリストが維持されている。このリストは、ノードと１次記憶サブシステムとの間の第１の論理パス、およびノードと２次記憶サブシステムとの間の第２の論理パスを含む。第１の論理パスは優先ブート・ボリュームに向けられ、第２の論理パスは非優先ブート・ボリュームに向けられる。管理ノードの責務は、オフラインのノードを含むクラスタ内の各ノードに影響する動的レプリカ・ボリューム・スワップ動作に応答して、ブート・ボリュームに対する第１および第２の論理パスの役割を常時把握することである。動的レプリカ・ボリューム・スワップ動作が起こってクラスタ内のすべてのノードが２次記憶システムにアクセスすると考えられるとき、管理ノードの仕事は、ブート・ボリューム情報を問い合わせてきた各クラスタ・ノードに、ブート・ボリュームへの第１の論理パスは２次記憶サブシステム上のレプリカであり、優先ブート・ボリュームへの第２の論理パスは１次記憶サブシステム上にあるという情報を通信することである。

本発明のさらに別の局面においては、動的レプリカ・ボリューム・スワップ動作をオープン・システムに適応させるように構成されたコンピュータ・プログラム命令を含むコンピュータ読取り可能担体が物品に設けられる。２つのブート・ボリュームのリストによってクラスタ内の各ノードを構成し、各ノードに対するブート・ボリュームのリストを各ノードのフラッシュ・メモリに保存するための命令が提供される。このリストは、ノードと１次記憶サブシステムとの間の第１の論理パス、およびノードと２次記憶サブシステムとの間の第２の論理パスを有するものとしてブート・ボリューム・リストを定義する。第１の論理パスは優先ブート・ボリュームに向けられ、第２の論理パスは非優先ブート・ボリュームに向けられる。動的レプリカ・ボリューム・スワップ動作に応答して、その動的レプリカ・ボリューム・スワップ動作に関与する各ノードに対して第１および第２の論理パスの役割を変更するための命令が提供される。論理パスの役割を変更するための命令は、第１の論理パスを２次記憶サブシステム上の非優先ブート・ボリュームに向けること、および第２の論理パスを１次記憶サブシステムの優先ブート・ボリュームに向けることを含む。

動的レプリカ・ボリューム・スワップ動作は、ノードのオペレーティング・システム・デバイスが使用しているボリュームへのパスを、１次記憶システムからこれらのボリュームが同期的かつシームレスに複製される１つまたはそれ以上の記憶システムに変更することを支援する。この変更は、当該ノードにおいて実行中であり当該ボリュームに対して入出力を行なっているアプリケーションが、この計画的または非計画的フェールオーバを検知しないように変更される。本明細書に示される動的レプリカ・ボリューム・スワップ動作は、いかなるカスタム・ハードウェアも必要とせずに、オフライン・ノードの存在下のクラスタにおける動的レプリカ・ボリューム・スワップ動作を支援するためにオープン・システムにおいて用いられ得る。本出願の状況において、オープン・システムとは、公的に利用可能なインタフェースを有するアーキテクチャに基づく任意の汎用計算システムのことである。本発明は、動的レプリカ・ボリューム・スワップの際にオフラインであったノードがリブートされてクラスタに再結合するときに、そのノードが記憶ボリューム中の適切なブート・イメージからブートする必要があるという問題に対処するものである。各ノードのユーザ・スペースおよびカーネル・スペースの各々は、動的レプリカ・ボリューム・スワップ動作の管理を支援するためのツールによって変更される。加えて、ユーザ・スペースのツールと通信して記憶サブシステム中のブート・ボリュームの状態を追跡するために、管理構成要素が提供される。これらの付加的ツールは分散型システムにおける動的レプリカ・ボリューム・スワップ動作を支援し、ここでクラスタ内の各ノードはクラスタに結合するか、または動的レプリカ・ボリューム・スワップ動作の間もしくはその後にリブートしてもよく、正しいブート・イメージからブートする。したがって動的レプリカ・ボリューム・スワップ動作は、ブート・イメージを保持するための中央共用メモリなしに支援される。

本発明のその他の特徴および利点は、添付の図面とともに、本発明の現在好ましい実施形態の以下の詳細な説明から明らかになるであろう。

本明細書において参照される図面は本明細書の一部を形成する。図面に示される特徴は本発明のいくつかの実施形態の例示のみを意味するものであって、特に明示がない限り、本発明のすべての実施形態を示すことを意味しない。また、これ以外の意味もない。

クラスタ化環境における動的レプリカ・ボリューム・スワップ動作の欠点を示す、先行技術の流れ図である。 動的レプリカ・ボリューム・スワップ動作を支援する構成要素を有するコンピュータ・クラスタ内のノードのブロック図である。 クラスタ内のすべてのノード間の動的レプリカ・ボリューム・スワップ動作の協調を支援するために利用される、クラスタの別個のノード内に存在する管理構成要素のブロック図である。 本発明の好ましい実施形態に従った、動的レプリカ・ボリューム・スワップ動作の間またはその後のブートするプロセスにおけるノードに対する、動的レプリカ・ボリューム・スワップ動作を支援するためのプロセスを示す流れ図である。 動的レプリカ・ボリューム・スワップ動作を支援する、クラスタ・ノードおよび管理ノード中の構成要素を示すブロック図である。

本明細書において一般的に記載され、図面に例示されている本発明の構成要素は、多様な異なる構成に配置および設計されてもよいことが容易に理解されるだろう。よって、図面に示されるとおりの本発明の装置、システムおよび方法の実施形態の以下の詳細な説明は、請求される本発明の範囲を制限することは意図されておらず、単に本発明の選択された実施形態を表わすものである。

本明細書に記載される機能単位は、マネージャおよびエンジンと呼ばれている。マネージャまたはエンジンは、たとえばフィールド・プログラマブル・ゲート・アレイ、プログラマブル・アレイ論理、プログラマブル論理デバイスなどのプログラマブル・ハードウェア・デバイスにおいて実現されてもよい。加えてマネージャまたはエンジンは、さまざまなタイプのプロセッサによる実行のためのソフトウェアにおいて実現されてもよい。実行可能コードの識別マネージャまたはエンジンは、たとえばオブジェクト、プロシージャ、関数、またはその他の構成体などとして編成されてもよいコンピュータ命令の１つまたはそれ以上の物理的または論理的ブロックなどを含んでもよい。しかし、識別マネージャまたはエンジンの実行可能コードは物理的に一緒に位置付けられる必要はなく、異なる場所に保存された異なる命令を含んでもよく、それらが論理的に結合されたときにマネージャまたはエンジンを含んで、マネージャまたはエンジンの記述される目的を達成してもよい。

実際に、実行可能コードのマネージャまたはエンジンは単一の命令であっても多くの命令であってもよく、いくつかの異なるコード・セグメント、異なるアプリケーション、およびいくつかのメモリ・デバイスの間で分散されていてもよい。同様に、本明細書においてオペレーショナル・データはマネージャもしくはエンジンまたはその両方において識別および例示されることがあり、任意の好適な形で実施されてもよいし、任意の好適なタイプのデータ構造内に編成されてもよい。オペレーショナル・データは単一のデータ組として収集されてもよいし、異なる記憶デバイスを含む異なる場所に分散されてもよく、システムまたはネットワーク上の電子信号として少なくとも部分的に存在してもよい。

本明細書全体における「選択実施形態」、「一実施形態」または「実施形態」への言及は、その実施形態に関連して記載される特定の特徴、構造または特性が本発明の少なくとも１つの実施形態に含まれることを意味する。よって、本明細書全体のさまざまな場所に現れる「選択実施形態」、「一実施形態において」または「実施形態において」という表現は、必ずしも同じ実施形態を示すものではない。

さらに、記載される特徴、構造または特性は、１つまたはそれ以上の実施形態において任意の好適な態様で組合わされてもよい。以下の説明においては、本発明の実施形態の完全な理解を提供するために、たとえば計画的または非計画的な動的レプリカ・ボリューム・スワップ動作を経験するコンピュータ・クラスタ内のノードをブートする例など、多数の特定の詳細が提供される。しかし、関連技術分野の当業者は、その特定の詳細の１つまたはそれ以上を伴わずに、または他の方法、構成要素、材料などとともに本発明が実施されてもよいことを認識するだろう。他の場合には、本発明の局面を不明瞭にすることを避けるために、周知の構造、材料または動作の図示または詳細な説明は行なっていない。

例示される本発明の実施形態は、図面を参照することによって最もよく理解され、図面における類似の部分は全体にわたって類似の数字によって示される。以下の説明は単なる例であることが意図されており、本明細書において請求される本発明に一致するデバイス、システムおよびプロセスの特定の選択された実施形態を単に示すものである。

技術的詳細
実施形態の以下の説明においては、本発明が実施され得る特定の実施形態を例示によって示す、本明細書の一部を形成する添付の図面を参照する。本発明の趣旨および範囲から逸脱することなく構造的変更が行なわれ得るため、他の実施形態が使用されてもよいことが理解されるべきである。

図２は、活動中の記憶システムへの優先ブート・ボリュームの割当を適応させながら、動的レプリカ・ボリューム・スワップ動作を支援するための構成要素を中に有するコンピュータ・クラスタのブロック図（２００）である。図示されるとおり、クラスタには少なくとも２つのノード、すなわち第１のノード（２１０）および第２のノード（２２０）と、少なくとも２つの記憶サブシステム、すなわち第１の記憶サブシステム（２１２）および第２のサブシステム（２２２）とがある。第１および第２の記憶サブシステム（２１２）および（２２２）の各々は、それぞれ１つまたはそれ以上の記憶ボリュームを含んでもよい。一実施形態において、コンピュータ・クラスタ（２００）は拡張されて付加的なノードおよび記憶サブシステムを含んでもよい。第１の記憶サブシステム（２１２）はすべての同期的ミラリング関係のソースであり、第２の記憶サブシステム（２２２）はすべての同期的ミラリング関係のターゲットである。ノード（２１０）および（２２０）の各々は、動的レプリカ・ボリューム・スワップ動作を支援するように構成される。したがって、各クラスタ・メンバは第１の記憶サブシステム（２１２）中の少なくとも１つの記憶ボリュームに対する記憶従属性を有し、第１の記憶サブシステム（２１２）中の各ボリュームは、同期的ミラリング関係によって第２の記憶サブシステム（２２２）中のボリュームの同一組にリンクされている。

図示されるとおり、第１のノード（２１０）は、カーネル・スペース（２７２）およびユーザ・スペース（２７６）を有するオペレーティング・システム（２７０）を有する。同様に、第２のノード（２２０）は、カーネル・スペース（２８２）およびユーザ・スペース（２８６）を有するオペレーティング・システム（２８０）を有する。一実施形態においては、クラスタが拡張されて付加的なノードを含み、各ノードはカーネル・スペースおよびユーザ・スペースを有するオペレーティング・システムによって構成される。いずれかのノードにおけるアプリケーションによる記憶へのアクセスは、カーネル・スペース内の拡張デバイス・ドライバを通じてゲート制御される。図２の構成要素に関して、ノード（２１０）はカーネル・スペース（２７２）内に拡張デバイス・ドライバ（２７４）を有し、ノード（２２０）はカーネル・スペース（２８２）内に拡張デバイス・ドライバ（２８４）を有する。先行技術において、カーネル・スペースのデバイス・ドライバは単一の記憶システム・ボリュームに対する複数のパスを管理し、ノードのオペレーティング・システムからそのボリュームへのすべてのパスを論理ボリューム・マネージャに対して可視である単一のデバイスとして仮想化する。本発明の好ましい実施形態に必要とされる、それぞれ第１および第２のノード（２１０）および（２２０）の拡張デバイス・ドライバ（２７４）および（２８４）は、クラスタ内のノード（２１０）および（２２０）の各々から２つの記憶システム中の２つの別々のボリュームへの少なくとも２つの論理パスの管理を行い、それらの記憶システムの内容は同期的記憶システム複製を介して同期されたままである。より特定的には、本明細書においてノード（２１０）に関して示されるとおり、拡張デバイス・ドライバ（２７４）は第１の論理パス（２３４）を１次記憶サブシステム（２１２）内のボリュームにアドレス指定し、第２の論理パス（２３６）を２次記憶サブシステム（２２２）内のレプリカ・ボリュームにアドレス指定することが示される。したがって、ノード・オペレーティング・システムからボリュームおよびそのレプリカへのすべてのパスは単一のデバイスとして仮想化される。

拡張デバイス・ドライバ（２７４）、（２８４）は動的レプリカ・ボリューム・スワップ動作に対するクラスタ（２００）内の各ノードに対する論理パスの管理を容易にする。より特定的には、それぞれ第１および第２のノード（２１０）、（２２０）中の拡張デバイス・ドライバ（２７４）、（２８４）は、各１次ボリュームおよびそのレプリカをノード・オペレーティング・システムにおける単一デバイスとして仮想化することを可能にする。各論理パスは、各記憶システムへの複数の物理パスによって構成されてもよい。動的レプリカ・ボリューム・スワップ動作が行なわれるとき、２つの論理パスが役割を変えるため、すべての記憶ボリュームへのアクセスが２次記憶サブシステム（２２２）に向けられる。アクセスが１次記憶サブシステム（２１２）に戻されるのは、フェールバック（ｆａｉｌｂａｃｋ）動作が行なわれるときだけである。一実施形態においては、マネージャを用いて論理パスの役割を変更することによって、１つの論理パスが２次デバイスの非優先ブート・ボリュームに向けられ、第２の論理パスが１次記憶サブシステムの優先ブート・ボリュームに向けられる。さらに、前に動的レプリカ・ボリューム・スワップ動作の際に非活動状態であった第３のノードのリブートの際に、マネージャを用いてこの第３のノードにおける論理パスの順序を変更してもよい。したがってカーネル・スペースの拡張デバイス・ドライバは、ノードと優先記憶サブシステムとの間の論理パスに沿って記憶要求を導く。

カーネルに対してローカルなデバイス・ドライバに加えて、各ノードのユーザ・スペースに対してローカルな管理構成要素が用いられる。より特定的には、第１のノード（２１０）のユーザ・スペース（２７６）にはアービトレーション・エンジン（２７８）が設けられ、第２のノード（２２０）のユーザ・スペース（２８６）にはアービトレーション・エンジン（２８８）が設けられる。アービトレーション・エンジン（２７８）、（２８８）は、それぞれのノードのカーネル・スペースの拡張デバイス・ドライバ（２７４）、（２８４）とそれぞれ通信し、さらにクラスタ内の別のノードにおいて実行する外部管理構成要素とも通信することによって、すべての影響される記憶サブシステムおよびノードにわたってクラスタ化動的レプリカ・ボリューム・スワップを制御する。

ユーザ・スペースに存在するアービトレーション・エンジン（２７８）、（２８８）は、非ページ化メモリにおいて実行するように構成される。この構成は、ページング・ボリュームが故障した記憶サブシステム中にあるときに、スワップされたコードのページインを防ぐことによって、記憶サブシステムの故障がノードに基づくコードの動作を妨げ得ないようにするために必要である。カーネル・スペース（２７２）、（２８２）に存在する拡張デバイス・ドライバ（２７４）、（２８４）も非ページ化メモリにおいて実行するように構成される。この拡張デバイス・ドライバ（２７４）、（２８４）の構成と、それぞれユーザ・スペース（２７６）、（２８６）に存在するアービトレーション・エンジン（２７８）、（２８８）の構成とが一緒になって、記憶サブシステム故障に対処するための要件を支援する。

図３は、それぞれのノードおよび記憶サブシステムと通信する管理構成要素のブロック図（３００）である。図面には管理ノード（３０５）に対してローカルな３つの構成要素が示されており、それらはＯｐｅｎＳｗａｐマネージャ（３１０）、順序付けエンジン（３２０）、および複製マネージャ（Ｒｅｐｌｉｃａｔｉｏｎ Ｍａｎａｇｅｒ：ＲＭ）プロキシ（３３０）を含む。管理構成要素（３１０）、（３２０）および（３３０）の各々は、動的レプリカ・ボリューム・スワップ動作による連続的な可用性に対して保護されるべきアプリケーションが管理構成要素を実行するノード上では実行しないという点から、管理ノード（３０５）の外部に存在する。したがって管理構成要素はページ化メモリにおいて実行できる。ＯｐｅｎＳｗａｐマネージャ（３１０）は、動的レプリカ・ボリューム・スワップ構成を管理するためのインタフェースを提供する。一実施形態において、このインタフェースはウェブに基づくインタフェースである。ＯｐｅｎＳｗａｐマネージャ（３１０）の運営機能は、動的レプリカ・ボリューム・スワップ構成確立、その構成の初期化、計画的な動的レプリカ・ボリューム・スワップ動作の開始、フェールバック動作の開始、現在のシステム状態の表示、および操作ログのブラウジングを含むがそれに限定されない。順序付けエンジン（３２０）は、クラスタ内の各ノード（３４０）のユーザ・スペース（３４４）のアービトレーション・エンジン（３４６）と通信する。より特定的には、順序付けエンジン（３２０）は、記憶クラスタ内の１つまたはそれ以上のノードにわたって動的レプリカ・ボリューム・スワップ動作を協調させるための集中状態マシンを実装する。順序付けエンジン（３２０）はＲＭプロキシ構成要素（３３０）を活用して、動的レプリカ・ボリューム・スワップ動作に関与する記憶サブシステム（３５０）にコピー・サービス（記憶複製管理）コマンドを発行する。ＲＭプロキシ構成要素（３３０）はアプリケーション・プログラム・インタフェース（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍ ｉｎｔｅｒｆａｃｅ：ＡＰＩ）を用いて、計画的および非計画的な動的レプリカ・ボリューム・スワップ動作の両方の際に、同期的ミラリング関係および記憶サブシステム（３５０）構成要素の状態を管理する。一実施形態において、ＲＭプロキシ構成要素（３３０）は、動的レプリカ・ボリューム・スワップ構成確立の際に記憶サブシステムの同期的ミラリング関係を問い合わせるために同じＡＰＩコールを用いる。

動的レプリカ・ボリューム・スワップ動作の前に、システム中のすべてのノードは優先順位によって並べられたブート・デバイスのリストを有する。各ノードは、ブート・デバイスの階層的表現に基づいてリストの中の第１のデバイスからブートし、もしそのブートが失敗すると、ノードはリストの下に進む。動的レプリカ・ボリューム・スワップ動作が行なわれるとき、システム内で動作するすべてのノードに対するブート・デバイスのリストが変更される。より特定的には、動的レプリカ・ボリューム・スワップ動作の後に、その動的レプリカ・ボリューム・スワップ動作に関与するすべてのオンライン・ノードのブート・ボリューム・リストが変更されて、ブート・ボリュームへの優先パスが２次デバイス上のものであることを指示する。その結果、動的レプリカ・ボリューム・スワップ動作の際にオンラインであったすべてのノードは、２次デバイス内のブート・ボリュームからブートしなければならないことを知る。図４は、動的レプリカ・ボリューム・スワップの際にオフラインだったノードが、オンラインになった後にいかにして自身のブート・ボリューム・リストを調整するかを説明する流れ図（４００）である。ノードはリブートする（４０２）。基本入出力システム（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ：ＢＩＯＳ）コードを走らせることによってブートの予備段階を実行しながら、ノードは不揮発性メモリからローカル・ブート・リストを得る（４０４）。ブートはそのリストの次のデバイスから行なわれる（４０６）。ブートが成功しなければ、ノードはリストの次のデバイスからブートを試みる（４０６）。ブート・リストにブートを試みるべき別のデバイスがなくなり、かつブートがまだ成功していないとき、それはすべてのブート・ボリュームが到達不可能である場合に違いなく、この場合にはノードが自身をリブートして再びブート・プロセス全体を始動させる（４０２）。逆にブートが成功すれば、ノードは順序付けエンジンに連絡する（４１２）。しかし、もしネットワーキングの問題または順序付けエンジン自体がオフラインであるためにノードが順序付けエンジンに連絡できなければ（４１４）、適切な待機期間の後に、ノードが自身をリブートしてプロセス全体を再始動する（４０２）。順序付けエンジンに連絡できて、順序付けエンジンがノードに対して、動的レプリカ・ボリューム・スワップ動作が現在進行中であることを通信するとき（４１８）、その状態は流動的であるため、ノードは自身をリブートする（４０２）。しかし、それ以外の場合には、ノードは順序付けエンジンから現在の動的レプリカ・ボリューム・スワップ状態を得る。動的レプリカ・ボリューム・スワップ状態を得るプロセスは、どの記憶システムが１次であり、どれが２次であるか、すなわちブート・ボリュームの新しく順序付けされたリストが何であるかを知るステップを含む。もしそのリストがノードの現在のブート・ボリューム・リストと一致すれば、そのノードは正しいボリュームからブートされている。順序付けエンジンから動的レプリカ・ボリューム・スワップ指示および状態情報が得られ、その後ノードのオペレーティング・システムがアクセスするよう構成されている他のデバイスのマウントが続けられる（４２６）。しかしもし順序付けエンジンが提供したブート・リストがノードのローカル・リストと一致しなければ、ローカル・ブート・リストが更新され（４２４）、ノードはリブートされる（４０２）。

図２および図３に示されるとおり、クラスタ環境内の各ノードは動的レプリカ・ボリューム・スワップ動作を支援するように変更されている。図５は、クラスタ環境の各ノードのユーザおよびカーネル・スペースの両方に組込まれているツールを示す、コンピュータ・システムのブロック図（５００）である。例示および説明の目的のために、クラスタ内の１つのノードだけを示して説明する。図示されるとおり、少なくとも２つの記憶サブシステム（５５０）および（５６０）と通信するノード（５０２）が提供される。ノード（５０２）は、バス（５０６）を通じてメモリ（５０８）と通信するプロセッサ（５０４）とともに示される。プロセッサ（５０４）は、ユーザ・スペース（５２０）およびカーネル・スペース（５３０）の両方を含むオペレーティング・システム（５１０）と通信する。ユーザ・スペース（５２０）は、ユーザ・プロセスを実行および支援するオペレーティング・システムの部分である。ここに図示されるとおり、ユーザ・スペース（５２０）はアプリケーション（５２２）およびライブラリ（５２４）を含む。これに対し、カーネル・スペース（５３０）はオペレーティング・システム（５１０）の中央モジュールであって、最初にロードして主メモリに残るオペレーティング・システムの部分である。一実施形態において、カーネル（５３０）はメモリ管理（５３２）と、プロセスおよびタスク管理（５３４）と、ディスク管理（５３６）とを担う。さらに、動的レプリカ・ボリューム・スワップ動作を支援するために、カーネル・スペース（５３０）はデバイス・ドライバ（５３８）を含むように変更され、ユーザ・スペース（５２０）はアービトレーション・エンジン（５２６）を含むように変更される。アプリケーション（５２２）およびアービトレーション・エンジン（５２６）は、どちらもデバイス・ドライバ（５３８）を介して記憶サブシステム（５５０）および（５６０）と通信する。ノード（５０２）は、ブート・ボリュームのリスト（５１５ａ）を保存するためのフラッシュ・メモリ（５２５）を備えて構成される。フラッシュ・メモリ（５２５）は、少なくとも２つの記憶サブシステム（５５０）および（５６０）における優先ブート・ボリュームおよび非優先ブート・ボリュームの両方を識別する。

ノード・クラスタ・メンバの変更に加えて、動的レプリカ・ボリューム・スワップ動作を支援するために、管理構成要素（５７０）、（５７２）および（５７４）の組が、個々のノード・クラスタ・メンバからは離れてクラスタと通信するように設けられる。この管理構成要素の組は、Ｏｐｅｎｓｗａｐマネージャ（５７０）と、順序付けエンジン（５７２）と、ＲＭプロキシ（５７４）とを含むがそれに限定されない。管理構成要素の支援の役割の詳細は、図３に関連して記載されている。一実施形態において、管理構成要素（５７０）〜（５７４）は記憶クラスタの外側に存在し、ユーザ・スペース（５２０）のアービトレーション・エンジン（５２６）ならびに記憶サブシステム（５５０）および（５６０）の両方と通信するように構成される。管理構成要素（５７０）〜（５７４）はメモリに対してローカルなソフトウェア構成要素の形で提供されてもよいし、メモリの外部に存在するハードウェア構成要素の形で提供されてもよい。アービトレーション・エンジン（５２６）およびデバイス・ドライバ（５３８）は、オペレーティング・システムのそれぞれの層に存在するソフトウェア構成要素として示されている。しかし、本発明はソフトウェア実施形態に限定されるべきではない。たとえば、一実施形態において、アービトレーション・エンジン（５２６）もしくはデバイス・ドライバ（５３８）またはその両方がハードウェア・ツールの形であってもよい。したがって、動的レプリカ・ボリューム・スワップ動作を支援するために提供されるツールは、ソフトウェア・ツール、ハードウェア・ツール、またはソフトウェアおよびハードウェア・ツールの組合わせの形となってもよい。

本発明の範囲内の実施形態は、その中にコード化されたプログラム・コードを有するプログラム記憶手段を含む製造品も含む。こうしたプログラム記憶手段は、汎用または専用コンピュータによるアクセスが可能な任意の利用可能な媒体であってもよい。たとえば、限定としてではなく、こうしたプログラム記憶手段はＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、またはその他の光ディスク記憶装置、磁気ディスク記憶装置もしくはその他の磁気記憶デバイス、または所望のプログラム・コード手段を保存するために使用可能であって汎用もしくは専用コンピュータによるアクセスが可能な任意のその他の媒体を含んでもよい。上記の組合わせもプログラム記憶手段の範囲に含まれるべきである。

媒体は電子、磁気、光学、電磁気、または赤外の媒体であっても、半導体システム（または装置もしくはデバイス）であってもよい。コンピュータ読取り可能媒体の例は、半導体または固体メモリ、磁気テープ、取外し可能なコンピュータ・ディスケット、ランダム・アクセス・メモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ：ＲＡＭ）、読取り専用メモリ（ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ：ＲＯＭ）、剛性磁気ディスク、および光ディスクを含む。光ディスクの現行例は、コンパクト・ディスクＢ読取り専用（ｃｏｍｐａｃｔ ｄｉｓｋ Ｂ ｒｅａｄ ｏｎｌｙ：ＣＤ−ＲＯＭ）、コンパクト・ディスクＢ読取り／書込み（ｃｏｍｐａｃｔ ｄｉｓｋ Ｂ ｒｅａｄ／ｗｒｉｔｅ：ＣＤ−Ｒ／Ｗ）およびＤＶＤを含む。

プログラム・コードを保存もしくは実行するか、またはその両方を行なうために好適なデータ処理システムは、システム・バスを通じて記憶素子に直接的または間接的に結合された少なくとも１つのプロセッサを含む。記憶素子は、プログラム・コードの実際の実行の際に用いられるローカル・メモリ、大容量記憶装置、および実行の際に大容量記憶装置からコードを取得しなければならない回数を減らすために少なくともいくつかのプログラム・コードの一時的保存を提供するキャッシュ・メモリを含み得る。

入力／出力（Ｉｎｐｕｔ／ｏｕｔｐｕｔ）またはＩ／Ｏデバイス（キーボード、ディスプレイ、ポインティング・デバイスなどを含むがそれに限定されない）は、システムに直接結合されてもよいし、介在するＩ／Ｏコントローラを通じて結合されてもよい。システムにネットワーク・アダプタを結合して、私的または公的ネットワークを介在することによってデータ処理システムが他のデータ処理システムまたは遠隔プリンタまたは記憶デバイスに結合できるようにしてもよい。

ソフトウェアの実装は、コンピュータまたは任意の命令実行システムによる使用またはそれに関連する使用のためのプログラム・コードを提供するコンピュータ使用可能またはコンピュータ読取り可能な媒体からアクセス可能な、コンピュータ・プログラム製品の形を取ってもよい。

代替的な実施形態
本明細書においては例示の目的のために本発明の特定の実施形態を説明したが、本発明の趣旨および範囲から逸脱することなくさまざまな修正が行なわれてもよいことが認識されるだろう。したがって、本発明の保護の範囲は以下の請求項およびその同等物のみによって制限される。

Claims (13)

1. クラスタ・システムにおいて、１次記憶サブシステムの故障に対処するための方法であって、前記クラスタ・システムは管理ノード及び、前記管理ノードの外部にあり、且つ、各ノードと通信可能であるマネージャを備えており、前記クラスタ・システム内の各ノードは、２つ又はそれ以上のブート・ボリュームのリストを備えて構成されており、前記方法は、
   各ノードそれぞれが、当該各ノードに対してローカルなフラッシュ・メモリに各ノードに対する前記ブート・ボリュームの前記リストを保存するステップであって、前記ブート・ボリューム・リストは、ノードと前記１次記憶サブシステムとの間の第１の論理パス、および前記ノードと２次記憶サブシステムとの間の第２の論理パスを含むものとして定義し、前記第１の論理パスは前記１次記憶サブシステム上のブート・ボリュームを指し、および前記第２の論理パスは前記２次記憶サブシステム上のブート・ボリュームを指す、前記保存するステップと、
   前記１次記憶サブシステムの故障に応答して、前記管理ノードは、前記マネージャを使用して、前記各ノードそれぞれが、前記第１および第２の論理パスの役割を変更し、前記１次記憶サブシステムと通信する各ノードのアクセスを前記２次記憶サブシステムに切り替えるようにさせるステップと、
   前記切り替えさせる間に非活動状態であった第３のノードのリブートの間に、前記第３のノードに関するブート・ボリュームを得るために前記第２の論理パスを使用するように前記第３のノードに指示することに応答して、前記管理ノードは、前記マネージャを使用して、前記各ノードそれぞれが、前記第３のノードにローカルな２つのブート・ボリュームのリスト中に前記第１および第２の論理パスの順序を変更するようにさせるステップと
   を含む、前記方法。
   
2. 前記切り替えさせる間に非活動状態であった前記第３のノードが、ローカル・フラッシュ・メモリ中のブート・ボリュームの前記リストを調べて、前記フラッシュ・メモリにおいて識別される前記第１の論理パスから当該第３のノードをブートするステップ
   をさらに含む、請求項１に記載の方法。
3. 任意のデータ・ボリュームにアクセスする前に、前記管理ノードは、前記マネージャを使用して、各ノードそれぞれが、ブート・ボリュームへの前記論理パスの識別およびデータ・ボリュームの場所を定めるために前記管理ノードを調べるようにさせるステップ
   をさらに含む、請求項１又は２に記載の方法。
4. 前記管理ノードは、前記マネージャを使用して、各ノードそれぞれが、前記リブートされたノードのフラッシュ・メモリにおけるブート・ボリュームへの論理パスのリストを修正して、前記第１および第２の論理パスの正確な順序を反映するようにさせるステップ
   をさらに含む、請求項１〜３のいずれか一項に記載の方法。
5. ノードに対するブート・ボリュームへの論理パスの誤ったリストに応答して、各ノードそれぞれが、論理パスの前記リストを訂正した後に当該ノードをリブートするステップ
   をさらに含む、請求項１〜４のいずれか一項に記載の方法。
6. 前記管理ノードは、前記マネージャを使用して、前記各ノードそれぞれが、前記クラスタ内の各活動ノードに対する前記第１および第２の論理パスの役割を変更するようにさせるステップ
   をさらに含む、請求項１〜５のいずれか一項に記載の方法。
7. 前記第３のノードが、前記第２の論理パスに割当てられたブート・ボリュームからブートするステップ
   をさらに含む、請求項１に記載の方法。
8. コンピュータ・システムであって、
   管理ノードと、
   少なくとも２つのノードであって、当該各ノードは関連するプロセッサおよびフラッシュ・メモリと通信し、前記各ノードは前記管理ノードと通信する、前記少なくとも２つのノードと、
   １次記憶サブシステム及び２次記憶サブシステムと
   前記管理ノードの外部にあり、且つ、前記各ノードと通信可能であるマネージャと
   を備えており、
   前記各ノードのフラッシュ・メモリは、２つ又はそれ以上のブート・ボリュームのリストを保存し、前記ブート・ボリューム・リストは、ノードと前記１次記憶サブシステムとの間の第１の論理パス、および前記ノードと２次記憶サブシステムとの間の第２の論理パスを含むものとして定義し、前記第１の論理パスは前記１次記憶サブシステム上のブート・ボリュームを指し、および前記第２の論理パスは前記２次記憶サブシステム上のブート・ボリュームを指し、
   前記１次記憶サブシステムの故障に応答して、前記管理ノードは、クラスタ・システム内の前記マネージャを使用して、前記各ノードそれぞれが、前記第１および第２の論理パスの役割を変更し、前記１次記憶サブシステムと通信する各ノードのアクセスを前記２次記憶サブシステムに切り替えるようにさせ、
   前記切り替えさせる間に非活動状態であった第３のノードのリブートの間に、前記第３のノードに関するブート・ボリュームを得るために前記第２の論理パスを使用するように前記第３のノードに指示することに応答して、前記管理ノードは、前記クラスタ・システム内のマネージャを使用して、前記各ノードそれぞれが、前記第３のノードにローカルな２つのブート・ボリュームのリスト中に前記第１および第２の論理パスの順序を変更するようにさせる、
   前記システム。
9. 前記切り替えさせる間に非活動状態であった前記第３のノードが、ローカル・フラッシュ・メモリ中のブート・ボリュームの前記リストを調べて、前記フラッシュ・メモリにおいて識別される前記第１の論理パスから当該第３のノードをブートするステップ
   をさらに含む、請求項８に記載のシステム。
10. 任意のデータ・ボリュームにアクセスする前に、前記管理ノードは、前記クラスタ・システム内のマネージャを使用して、各ノードそれぞれが、ブート・ボリュームへの前記論理パスの識別およびデータ・ボリュームの場所を定めるために前記管理ノードを調べるようにさせるステップ
    をさらに含む、請求項８又は９に記載のシステム。
11. 前記管理ノードは、前記クラスタ・システム内のマネージャを使用して、各ノードそれぞれが、前記リブートされたノードのフラッシュ・メモリにおけるブート・ボリュームへの論理パスのリストを修正して、前記第１および第２の論理パスの正確な順序を反映するようにさせる、請求項８〜１０のいずれか一項に記載のシステム。
12. ノードに対するブート・ボリュームへの論理パスの誤ったリストに応答して、各ノードそれぞれが、論理パスの前記リストを訂正した後に当該ノードをリブートする、請求項８〜１１のいずれか一項に記載のシステム。
13. 前記管理ノードは、前記クラスタ・システム内のマネージャを使用して、前記各ノードそれぞれが、前記クラスタ内の各活動ノードに対する前記第１および第２の論理パスの役割を変更するようにさせる、請求項８〜１２のいずれか一項に記載のシステム。

Images