JP4457184B2 - ストレージシステムにおけるフェイルオーバー処理 - Google Patents

Description

（関連出願の相互参照）
本出願は、以下の米国仮特許出願からの優先権を主張する。２００１年２月１３日に出願された、全ての目的のために本願において参照として援用される「Ｖｉｒｔｕａｌ Ｓｔｏｒａｇｅ Ｓｙｓｔｅｍ」と称する米国出願第６０／２６８，６９４号。
（連邦政府によって後援される研究または開発の下に行われた発明の権利に対する陳述）
適用されない
（コンパクトディスクで提出される「シーケンスリスティング」、表、または、コンピュータプログラムリスティング付録の参照。
ＣＤ、複製物、および、個々のＣＤ上のファイルの総数を含む、コンパクトディスク上の材料の参照による援用。）
適用されない

（本発明の背景）
本発明は、一般的に、ストレージエリアネットワークにおけるフェイルオーバーに関し、さらに特に、クラスターに配列された一団の仮想化デバイスに関する。

知識は、あらゆるビジネスにとって重要で競争力のある利点である。知識の蓄えを発展させ、かつ、ストレージハードウェアの容量を改良するための意欲は、ストレージおよびコンピューティングリソースにおける爆発的な成長を導いた。ビジネスがアプリケーションおよびその根底にあるデータにますます依存する結果、絶え間なく、信頼でき、かつ、高速のデータへのアクセスは、重大な意味を持つようになった。失われたデータのオンラインアクセスと迅速な回復とを保証することは重要である。ストレージ技術の発展は市場の要求に合致し続けるので、大量のストレージシステムがますます複雑になっていく。

必要なのは、ストレージシステムの信頼性を保証し、かつ、ストレージシステムの可用性を保持することである。

（本発明の要旨）
本発明に従うストレージサーバシステムの実施形態は、規約に基づくソフトウェア管理を使用して、ユーザに構成可能なレベルのフォルトトレランスと高可用性とを提供する。ストレージサーバシステムにおけるフェイルオーバーソフトウェアは、フェイルオーバーセットと呼ばれる、フォルトトレラント（ＦＴ）および高可用性（ＨＡ）構成を管理するための規約を利用する。

フェイルオーバーセットは、コンポーネントのコレクションにおいて編成を義務付け、単一のコンポーネントでは必要のない特性を含む構成を提供する。コレクションもしくはセットは、様々な方法で組織化され、信頼性および／または可用性のようなコンポーネントの様々な特性を強調するように調整され得る。

個々のコンポーネントは、１つの編成のタイプで指定されたエンティティである。１つのフェイルオーバー構成の制御下には、数個のコンポーネントが存在し得る。この文脈では、コンポーネントは、メンバと呼ばれる。メンバは、シャーシ上のポートやカードのような単一のリソースであり得る。メンバはまた、スタックにおける数個のボックスのような物理的なコンポーネントの複雑な階層、または、シャーシ全体であり得る。最も一般的な場合は、メンバは、他のフェイルオーバーセットであり得る。

フェイルオーバーセットのメンバ構成は、メンバが接続されている方法を理解している。例えば、階層的構成は、ネットワークストレージサーバシステム内およびネットワークストレージサーバシステム外と同様にフェイルオーバーを接続することを可能にする。前記構成は、根底にあるネットワークストレージシステムまたはフェイルオーバーセットから、セットが確立される方法に関連する規則からなる。メンバユニットは、関与するコンポーネントを識別する。

フェイルオーバーセットにおけるメンバは、プライマリ、バックアップ、または、代替の役割を果たす。フェイルオーバーセットの範囲では、１つのプライマリメンバ、および、ひとつのバックアップメンバだけが存在する。いくつかの数の代替メンバが存在し得る。プライマリメンバが失われると、フェイルオーバーが発生し、バックアップメンバが新しいプライマリメンバになる。新しいバックアップメンバは代替バックアップメンバのセットから選ばれる。前記代替が故障すると、エラー報告が誘発される。

フェイルオーバーソフトウェアは、規約管理を提供するために、規則ベースのエンジンを利用する。メンバ構成、メンバ互換性、メンバ障害検知および呼応、メンバ障害の訂正アクション、メンバ再スタート、全てのメンバにわたる構成データの複製、選択メンバフェイルオーバー、メンバリソース管理、および、フェイルオーバーセットフェイルストップ規約が、ストレージシステム内およびストレージシステム間のコンポーネントの間のフェイルオーバー回復の知識をカプセル化するために、規則は確立される。この知識は、どのコンポーネントがフェイルオーバーセットに加わっているのか、それらのコンポーネントはフェイルオーバーのためにどのように構成されているのか、フェイルストップ規約とは何か、コンポーネントを「フェイルオーバーする」際に実行されるステップは何かについての情報を含む。フェイルストップ規約は、コンポーネントが、障害に応じて、他のコンポーネントに障害が発生し、その後、停止する許可を与える状態に変化する規約である。

（本発明の詳細な記述）
図３６は、本発明に従ったストレージエリアネットワーク（ＳＡＮ）の実施形態の一般化されたブロック図を示す。ＳＡＮは、１つ以上のストレージサーバ３６００を含む。この図はまた、コミュニケーションネットワーク（スイッチングファブリック）３６０２、多くの物理ストレージデバイス３６０４、および、多くのホストコンピュータ３６０６を示す。ストレージサーバ３６００は、仮想ストレージエクスチェンジ（ＶＳＸ）とも呼ばれ、さらに図３７に詳細が示される。ＶＳＸの主要な機能は、ＳＡＮにおいて管理層を中央に集めることである。ＶＳＸは、接続、ストレージエレメント、およびコンピュータシステムを、抽象的な関係に組織化して、安全かつ頑強なデータ転送を促進する。このデバイスは、一団の仮想化デバイスと呼ばれる。一団の仮想化デバイスは、データパスにおける機能またはサービスを提供する。一団の仮想化を実装するシステムにおいて、アドレスマッピングなどの仮想化サービスは、データの読み書きに利用される同様の機能的なコンポーネントによって実行される。

物理ストレージデバイス３６０４は、テープデバイス、ディスクアレイ、ＪＢＯＤ（Ｊｕｓｔ ａ ｂｕｎｃｈ ｏｆ ｄｉｓｋｓ）、または、他のタイプのデータストレージデバイスを含む。物理ストレージデバイス３６０４は、ＳＡＮ３６０２を介してホストコンピュータ３６０６に直接的に接続され得る、または、ＳＡＮ３６０２およびストレージサーバ３６００を介してホストコンピュータ３６０６に間接的に接続され得る。ストレージデバイス３６０４がＳＡＮ３６０２を介して直接的にホストコンピュータ３６０６に接続されると、ストレージの仮想化の管理に負荷がかかることが観測されている。本発明は、ストレージサーバ３６００を利用することによってストレージの仮想化の管理を改良し、間接的にストレージデバイス３６０４をホストコンピュータ３６０６に接続する。

図３６Ａは、二つのＶＳＸが高可用性運用のために一緒にケーブル接続された（ＶＳＸ−ＨＡ）典型的な構成を示す。このような構成にはいくつかのバリエーションがある。図３６Ａでは、ＶＳＸはプライベートネットワークを利用して一緒に接続されている。ＶＳＸとホストコンピュータ（例えばサーバ）との間のファイバチャネル接続は、顧客のファブリック３６０２Ａを利用する。管理ステーションは、パブリックまたはプライベートネットワークを利用して、イーサネット（Ｒ）接続を介し、ＶＳＸに接続される。

図３６Ｂは、ＶＳＸを一緒に接続する同様のネットワークを利用して管理ステーションがＶＳＸに接続されていること以外は同様の構成を示す。

図３６Ｃの構成は、プライベートネットワークを介してＶＳＸに接続されている管理ステーションを示す。しかし、ＶＳＸは、ポイントトゥポイントファイバチャネルまたはファイバチャネルスイッチファブリックを利用して互いに接続される。

図３６Ｄの構成は、ファブリックが冗長なファブリックに分けられていること以外は図３６Ａの構成と同様である。ストレージデバイスおよびコンピュータサーバは二重ポートである。

図３７は、ストレージサーバ３６００の一般化されたブロック図であり、本発明の実施形態に関連するハードウェアコンポーネントを示し、ストレージプロセッサ３７１０、ラインカード３７１２、仮想サービスカード３７１４、および、スイッチファブリック３７１６を含む。

ストレージサーバ３６００は、１つ以上のストレージプロセッサ３７１０（ＳＰ）を含み得る。ストレージプロセッサ３７１０は、ホストコンピュータ３６０６とストレージデバイス３６０４との間で情報フローとして保存されるストレージコマンドとデータを処理する。１つ以上のストレージプロセッサ３７１０は、個々のラインカード３７１２（ＬＣ）に含まれ得る。ストレージサーバ３６００は、多数ラインカード３７１２のためのスペースを含み、そのためストレージサーバ３６００の性能は、より多くのラインカード３７１２またはより多くのストレージプロセッサ３７１０を加えることによって、モジュール性により増加され得る。各ストレージプロセッサ３７１０は、ストレージサーバ３６００の１つ以上のポートに接続される。

ストレージサーバ３６００は、１つ以上の仮想サーバカード３７１４（ＶＳＣ）を含み得る。仮想サーバカードは、ストレージサーバ３６００の動作を制御し、かつ、ラインカード３７１２を制御する。ラインカード３７１２は、コマンドおよびデータの転送という実際の仕事を実行する。

スイッチファブリック３７１６は、ストレージプロセッサ３７１０に接続する。スイッチファブリックは、１つのポートで受信した情報を、ストレージサーバ３６００の別のポートへスイッチする。例えば、ホストコンピュータ３６０６がストレージエリアネットワーク３６０２上に保存されているデータを読み込みたいとき、その要求は、そのホストコンピュータ３６０６に接続するポートに接続するストレージプロセッサ３７１０によって処理される。上流のストレージプロセッサ３７１０は、スイッチファブリック３７１６を介して、読み込まれるべきデータを保存しているストレージサーバ３６０４に接続しているポートに接続している下流のストレージプロセッサ３７１０と通信する。次に、スイッチファブリック３７１６は、下流および上流のストレージサーバ３７１０を介して、ストレージデバイスからホストコンピュータ３６０６に読み込まれたデータを転送する。

ストレージサーバ３６００の付加的な詳細は、米国仮出願第６０／２６８，６９４および以下の同時係属、共願の米国特許出願で開示されている。２００２年２月１３日に出願され（代理人判決第２０９４９Ｐ−０００２００ＵＳ）「Ｓｉｌｉｃｏｎ Ｂａｓｅｄ Ｓｔｏｒａｇｅ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ Ｓｅｒｖｅｒ」と称される米国出願第ｘｘ／−−−，−−−号、２００２年２月１３日に出願され（代理人判決第２０９４９Ｐ−０００３００ＵＳ）「Ｓｔｏｒａｇｅ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ ａｎｄ Ｓｔｏｒａｇｅ Ｍａｎａｇｅｍｅｎｔ ｔｏ Ｐｒｏｖｉｄｅ Ｈｉｇｈｅｒ Ｌｅｖｅｌ Ｓｔｏｒａｇｅ Ｓｅｒｉｖｉｃｅ」と称されるｘｘ／−−−，−−−、２００２年２月１３日に出願され（代理人判決第２０９４９Ｐ−０００５００ＵＳ）「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｉｄｅｎｔｉｆｙｉｎｇ Ｓｔｏｒａｇｅ」と称される米国出願第ｘｘ／−−−，−−−号、２００２年２月１３日に出願され（代理人判決第２０９４９Ｐ−０００６００ＵＳ）「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｐｏｌｉｃｙ Ｂａｓｅｄ Ｓｔｏｒａｇｅ Ｐｒｏｖｉｓｉｏｎｉｎｇ ａｎｄ Ｍａｎａｇｅｍｅｎｔ」と称される米国出願第ｘｘ／−−−，−−−号、２００２年２月１３日に出願され（代理人判決第２０９４９Ｐ−０００７００ＵＳ）「Ｖｉｒｔｕａｌ Ｄａｔａ Ｃｅｎｔｅｒ」と称される米国出願第ｘｘ／−−−，−−−号、２００２年２月１３日に出願され（代理人判決第２０９４９Ｐ−０００８００ＵＳ）「Ｆａｉｌｏｖｅｒ Ｐｒｏｃｅｓｓｉｎｇ ｉｎ ａ Ｓｔｏｒａｇｅ Ｓｙｓｔｅｍ」と称される米国出願第ｘｘ／−−−，−−−号、２００２年２月１３日に出願され（代理人判決第２０９４９Ｐ−０００９００ＵＳ）「ＲＡＩＤ ａｔ Ｗｉｒｅ Ｓｐｅｅｄ」と称される米国出願第ｘｘ／−−−，−−−号、２００２年２月１３日に出願され（代理人判決第２０９４９Ｐ−００１０００ＵＳ）「Ｍｅｔｈｏｄ ｆｏｒ Ｄｅｖｉｃｅ Ｓｅｃｕｒｉｔｙ ｉｎ ａ Ｈｅｔｅｒｏｇｅｎｅｏｕｓ Ｓｔｏｒａｇｅ Ｎｅｔｗｏｒｋ Ｅｎｖｉｒｏｎｍｅｎｔ」と称される米国出願第ｘｘ／−−−，−−−号。以上全ての出願は、全ての目的のために本明細書において参照として援用される。

以下は、前述の図の本発明の実施形態に従ったフェイルオーバー処理の説明である。

（エラー回復）
フェイルオーバーは、冗長なコンポーネントのサービスが停止したときに取られる回復アクションである。フェイルオーバーは、生きたコードが更新された場合は任意であり得、ハードウェア故障の場合は、不任意である。一般に、ユーザは、任意のフェイルオーバーを開始させるのに責任がある。任意のフェイルオーバーは、命令による操作である。反対に不任意のフェイルオーバーは突然発生し、常にストレージシステムソフトウェアによって内部的に開始する。

不任意のフェイルオーバーは、エラー回復および回復管理のより大きな内容の範囲内で発生する回復アクションである。フェイルオーバーサービスは、フェイルオーバーし得るオブジェクト、フェイルオーバーのためのオブジェクトの構成、フェイルオーバーが発生したときに取るべきステップ、および、フェイルオーバーイベントの構成要素を管理するインフラを提供する。フェイルオーバーによるエラーから回復するための検知は、エラー分析の結果である。

エラー回復の目的のために、リソースは、エラーのトラック、エラー分析、エラー統計量コレクション、および、エラー回復の能力を備えるエンティティとして定義される。一般に、リソースは、ハードウェアオブジェクトであるが、リソースは、ＲＡＩＤグループなどのソフトウェア構造物でもあり得る。リソースマネージャは、リソースのためにエラーのタイプおよび回復アクションを定義するための責任がある。

エラー訂正は、大まかには、ＶＳＸ全体の至る所に用意される層状のソフトウェアである。エラー訂正は、様々なソフトウェア層からエラーイベントをコレクションし、かつ、リソースマネージャにイベントをルーティングするための標準的なメカニズムを提供する。リソースマネージャは、エラーイベントの発生に伴って取るべき行動を決定するために、エラー分析からのヘルプを要求する。

エラー分析は、エラーイベントおよびエラーイベントに関連するデータを記録し、かつ、エラー回復シーケンスを開始させる。エラー回復シーケンスは、エラーコードおよび訂正アクションのシーケンスとして定義される。例えば、エラーコードｅ１が時間ｔ１に回復アクションａ１を引き起こし、そしてｅ１が時間ｔ２で回復アクションａ２とともに別のエラーコードｅ２を引き起こした場合、ｔ１＜ｔ２であり、かつ、時間的にｔ１はｔ２より前に発生する。前記シーケンスは、回復アクションが成功して終了したときに終了する。回復アクションが失敗した場合、シーケンスは、回復処理の次のレベルへ進み、より徹底的な回復を試みる。入れ子の回復は、根底にあるシーケンスのフォルトトレランスによって制限される。所与のエラーに対して全ての回復アクションが失敗に終わったとき、前記シーケンスは、フェイルストップパラダイムを取って、終了する。

エラーは、所与のリソースに対する統計として記録される。ハードウェアリソースの信頼性の割合は、エラー統計を基にして計算され得る。エラー分析は、閾値を利用し得る。閾値によって、ある時間間隔の範囲内である時間量に対するエラー発生後にのみ回復アクションを開始させる。エラー分析は、エラー回復表を利用して、所与のエラーコードおよびエラー回復シーケンスに対応するエラーアクションを決定する。エラー回復表は、１つより多いリソースによって使用され得る。

回復管理は、訂正アクションの倉庫である。回復管理は、訂正アクション要求に同期を取り、その結果、衝突する訂正アクションは解決される、もしくは、順番に並べられる。訂正アクション操作は、所与のエラー回復シーケンスから回復するために用いられるリソース特定手順を含む。ひとつの訂正アクションは、多くのエラー回復シーケンスによって利用され得る。

エラー報告は、カスタマーログへエラーのログを取ること、ＳＮＭＰトラップの生成、および、アラームの設定を含む。エラー報告は、エラー分析に基づき、かつ、ユーザの注意へエラーを導く。

最後に、リソースマネージャは、訂正アクションの結果に基づいて、リソースの状況または状態の変更に対する責任がある。エラー分析および回復管理アーキテクチャは、図１に示されるエラー回復アーキテクチャである。

（フォルトトレランスおよび高可用性）
個々のＶＳＸモデルは、フォルトトレランスのあるレベルを提供するように構成され得る。仮想ストレージコントローラ（ＶＳＣ）、ラインカード（ＬＣ）、スイッチファブリック（ＳＦ）、ストレージプロセッサ（ＳＰ）、または、ファイバチャネルポートにおける冗長性は、全体としてＶＳＸが故障し得るよりも長い時間を意味する。ＶＳＸ内のコンポーネントの重複は、ＶＳＸの全体的障害間隔平均時間（ＭＴＢＦ）を改善する。そのような構成は、ＶＳＸにコンポーネントのいくつかに欠損があってでさえ正確に作動することを許すので、フォルトトレランス（ＦＴ）である。しかし、そのような構成が提供するのは、高可用性ではなく、より高い信頼性である。棚に火事が発生すれば、データの可用性は失われる。このような状況下でデータの可用性を維持するためには、高可用性セットとして機能するように構成された付加的なＶＳＸを必要とする。

今日、利用されている多くのエンタープライズクラスストレージ構成は、ハイレベルの可用性を必要とする。この要求のために、基礎のＶＳＸシステムは、１つの障害のポイントを評価するのを助ける多くの特性を必要とする。高可用性（ＨＡ）ＶＳＸの構成は、ハードウェアおよびソフトウェアの冗長性を特徴とする。ハードウェアおよびソフトウェアの冗長性は、単一のＶＳＸには用意されない破滅的な障害に対する追加の保護を提供する。ＶＳＸを高可用性（ＨＡ）セットへ編成するときに、いくつかの構成が可能である。これらの構成は、２ノード、４ノード、Ｎ＋１ノード、および、ＮノードＨＡセットを含む。

フェイルオーバーサービスは、フォルトトレランス（ＦＴ）および高可用性（ＨＡ）の両方を提供するために重要な役割を担う。フェイルオーバーサービスは、ＶＳＸ内とＶＳＸ自体間とのコンポーネント間のフェイルオーバー回復の知識をカプセル化する。この知識は、フェイルオーバーセットに参加しているコンポーネント、フェイルオーバーのためのコンポーネントの構成、フェイルストップの規約、および、コンポーネントをフェイルオーバーする際の実行ステップについての情報を含む。

例えば、「ディレクター」モデルＶＳＸは、８つのラインカードを有する。個々のラインカードは、冗長性のために構成されており、その結果、ラインカードのいずれかに欠損が発生すると対のラインカードにフェイルオーバーする。「ディレクター」アーキテクチャはシャーシに基盤を置き、ここで全ての８枚のカードはシャーシ内のスロットを占有する。

他の例では、スタックベースのＶＳＸは、ファイバチャネルもしくはインフィニバンドのようなネットワークを利用して一緒に接続された１つ以上のボックスを含む。ボックスは、論理「シャーシ」へ結合される。その結果、１つ以上のボックスは、シャーシに基づくモデルと全く同じ方法で機能する。積み重ね可能なアーキテクチャでは、ＶＳＣはボックスに内臓され、ここのＬＣはボックスに内臓される。

以下の表は、ＶＳＸアーキテクチャに適用するように、フォルトトレランスと高可用性との間の違いを要約している。

フェイルオーバーサービスの主な責任は、重複コンポーネントのセットの範囲でデータ可用性を維持することである。データ可用性は、必要とされるときにサーバがそのストレージにアクセスする能力として定義される。ＶＳＸに対しては、このことは、二つ以上のコンポーネントが以下の情報に対して正確な相互の一致に到達し得る手段を必要とする。

局面１．いつフェイルオーバー発生し得る、および、発生し得ないのか
局面２．どんな状況がフェイルオーバーを引き起こすのか
局面３．どんなリソースが個々のコンポーネントに支配されているのか
障害のあるコンポーネントの振舞いに対して、明白な前提は作られない。障害の発生したコンポーネントは好きなように振舞い得る。前記コンポーネントは非常に奇妙に振舞う。前記コンポーネントは自身をリレーした情報を変更し得る。前記コンポーネントは、そのようなリレーされている情報をブロックし得る。前記コンポーネントは、不正確に情報をルートし得る。そして、最悪の場合は、システムの異なる部分に衝突する情報を送り得る。

明らかに、いくつかの制限が、ＶＳＸが許容し得る多くの障害に対して必要とされる。フォルトトレランスにおける上限は、全てのフォルトトレランスシステムの形式に必要である。そうでなければ、そのようなシステムのコストは、コンポーネント上のコンポーネントが重複するので、非常に高価である。ハードウェアコンポーネントエラーの場合、何か１つのボード上の上限は、１つであると仮定される。もし二つのメンバのフェイルオーバーセットが、個々のコンポーネントにおける１つより多いハードウェアエラーを含む場合、どのコンポーネントが使用されたかどうかは、もはや関係がない。フェイルストップ規約が適用されるべきである。

上述の所与の局面１〜３に一致する必要性を満足させるために、以下のストラテジーが採用される。
局面１．いつフェイルオーバーが発生し得る、または、発生し得ないのかを決定するために、
・コンポーネントが有効なフェイルオーバーセットのメンバであるとき、フェイルオーバーは発生し得るのみである。
局面２．どんな状況がフェイルオーバーを引き起こすのかを検知するとき、
・閾値を用いるイベント報告は、フェイルオーバーを要求し得る。
・障害の発生したハードウェアを検出し得る機能的なコード（例えば、デバイスドライバ）は、フェイルオーバーを要求し得る。
・ハートビートプロトコル障害は、フェイルオーバーを要求し得る。
局面３．どんなリソースが個々のメンバに支配されているのかを決定するために、
・メンバ状態マシンは、リソースの所有権を決定する。

（目的）
以下の２つの一般的な条件で構成されている前のセクションで述べられた設計の特徴１〜３における相互の整合性を実現することが、フェイルオーバーの目的である。
１．整合性；全ての正確に機能するコンポーネントが、同様の情報で正確に一致する。
２．有意性；正確に機能するコンポーネントに一致する情報が、そのコンポーネントの実際の情報となる。

条件１および２は、どのコンポーネントに欠陥があるか明らかにする必要はない。それらの条件により、非欠陥成分は、フェイルオーバーセットにおける他の全てのメンバーによって維持された情報の一貫した観点になり得る。一旦、相互の整合性が達成されると、各非欠陥メンバーは、決定機能を情報に適用し得る。各非欠陥メンバーは、同様の情報に対して決定機能を利用するので、正確な一致が必然的に達成される。

（サポートされた構成）
このセクションは、フェイルオーバーについての様々な提供された構成を記載する。注釈：これらの図表は、有益になるようにのみ意図されている。一般に、コンポーネント上で生じる任意の警告によって、他の警告は、包含するコンポーネント上で警告を与える。

（非フェイルオーバーサポートを用いる根拠）
図２は、最低有効性の構成の一般的なブロック図を示す。この構成によって提供された冗長だけが、ＲＡＩＤアルゴリズムを介するディスク欠陥に対しての保護である。

表１−ノンにおけるデータ可用性−欠陥トラレント構成
（単一のホスト、単一の記憶装置、単一のＶＳＸ、マルチパス）
図３は、上流および下流ポートの両方にマルチパスを追加することによって、図２に示される「基本構造」上に設計された構成を示す。パスが欠陥になると、データは冗長パスを介して利用可能になる。

表２−欠陥トラレント構成におけるデータ可用性
（単一のホスト、単一の記憶装置、デュアルアダプタ、デュアルＶＳＸ）
図４に示される構成は、高い有効性の他のＶＳＸを追加することによって「基本構造」に依存する。ＶＳＸが失敗すると、冗長ＶＳＸを介してデータが利用可能になる。図４に示される構成は、単一のＶＳＸを用いて検出されない破壊的な失敗に対するさらなる保護を提供するハードウェアおよびソフトウェアの冗長性を特徴とする。ＶＳＸを高い有効性のセットに組織化すると、いくつかの構成が可能になる。これらは、２−ノード、４−ノード、Ｎ＋１ノード、およびＮ−１ノードを含む。消費者は、ＨＡ構成においてＶＳＸの数を単に選択することによって、消費者が好む有効量を選択し得る。

ＶＳＸのクラスター化によって、独立したＶＳＸを超える多数の利点がある。ある重要な利点は、クラスターにおける各ＶＳＸ上で起動するクラスターソフトウェアが、クラスターにおいてアプリケーションの欠陥または他のＶＳＸの欠陥を自動的に検出することである。そのような欠陥を検出する上で、欠陥アプリケーションなどは、存続するＶＳＸ上で終了され、再起動され得る。

他の利点は、クラスターリソースの状態を検査するような管理能力を含み、その結果、クラスターにおいて、異なるＶＳＸ間の負担のバランスを保って性能を向上させる。動的負担のバランスもまた使用できる。そのような管理性能は、さらに重要なデータおよびサーバアプリケーションのオフラインを得ることなくクラスターにおいて、１つのＶＳＸを更新するような機能を管理者に提供する。十分理解され得るように、ＶＳＸクラスターは、重要なデータベース管理、ファイルおよびイントラネットデータの共有、メッセージ作成、一般的なビジネスアプリケーションなどに使用される。

従って、クラスターにおいて、あるＶＳＸから他のＶＳＸへのアプリケーションのフェイルオーバーは、第１のＶＳＸ上のソフトウェアの欠陥またはハードウェアの欠陥に応答して自動的であり得るか、または、それに代わって、管理者によって手動で開始され得る。手動のフェイルオーバーは、装置の実際のサービスを可能にして、それにより、ダウンタイムを削減する。

表３−高可用性構成におけるデータ可用性
（フェイルオーバーサービスのアーキテクチャ）
フェイルオーバーサービスのアーキテクチャは、サービスのフレームワーク、仮想サービス、各カードでのローカルなサービス、アービタ、およびデータベースのジャーナルコントロールプロセス（Ｊｏｕｒｎａｌ Ｃｏｎｔｒｏｌ Ｐｒｏｃｅｓｓ）で構成されている。図２１Ａは、サンプルの双方向階層の構成を示している。

（サービスのフレームワーク）
図２１Ａに示されるアーキテクチャは、サービスのフレームワークの要素を示す。図２１Ｂによると、サービスのフレームワークは、ソフトウェアバスが元になっている。ソフトウェアバスは、いくつかのプロセッサ、カード、およびＶＳＸシステムにわたって潜在的に分散された均一の環境に全てのＶＳＸサービスを共に密着させている。フレームワークのインスタンスは、図２１Ｂに示されるように、その環境内で全ての論理的な場所（プロセッサ、カード、ＶＳＸ）におけるＯＳの最上部で実行し、複数の分散化した断片を一緒に密着させる。

フレームワークは、以下の機能を提供する：
・ロバスト（ｒｏｂｕｓｔ）モジュールのインジェクション／イジェクションスキームにより、新しいサービスは、統合され、使用されなかったものは、編集時に取り除かれ得る。
・マルチタスキング環境において実行する効率的な単一のタスクソフトウェアモジュール−つを生成する方法が確立され、これにより、サービス発展プロセスから全てのマルチタスキング関連事項（ｉｓｓｕｅ）が増加される。さらに、フレームワークは、所望ならばスラッシング（ｔｈｒａｓｈｉｎｇ）を避けるために同様のタスク上で実行されるサービスの数を制御するための手段を提供する。
・サービス状態統合順序、促進ブート、およびプロセスのシャットダウンタイプを制御するためのシステム広域基準値。
・内部サービス通信機構。フレームワークは、２つの概念的に別個の通信スキーム（「要求応答」および「公開署名」）を助長する。要求応答により、サービスのインスタンスは、応答を必要とする他のインスタンスにおいて方法を呼び出すことが可能になる。一方、公開署名により、サービスの事例は、非応答型の通知を当事者に送達することが可能になる。
・どのサービスが実行時に所与の要求を実行し得るかを解決し得るフォールトトレラントネーミングサービス。本質的に、ネーミングサービスは、ロケーション結合サービスおよびロケーション独立サービスを共に設計するように必要とされた機能性を提供する。前者のタイプは、サービスが実行するロケーション（例えば、サービスが管理／制御するハードウェアの断片）に物理的に結合される機能性を持つサービスを定義する。一方、後者のタイプは、任意のロケーションにおいて潜在的に実行し、サービスレベルのフェイルオーバーを実行し得るフォールトトレラントサービスを表すために使用される。
・カードの欠陥を切り抜け、サービスレベルのフェイルオーバーを実施することが可能な冗長サービスを設計およびインプリメントするためのシステム広域基準。
・組み込まれたデータベースに／から自動的に導かれ、強力なフィルタベースのクエリ機構を用いて照会され得るオブジェクトをモデリングし、発展させるための標準的な方法。
・オブジェクトの導出および内蔵型のクエリサポートに加えて、フレームワークは、標準イベントサービス（サーバのデータモデルに対する変更を反映する自動生成イベントへのロバスト機構）を提供する。
・フレームワークにおける複数の論理ロケーション（プロセッサ、カード、ＶＳＸ）間で通信可能になるＩＰＣ機構。
・要求／イベントフローを動的に制御する機能を伴うサービスを提供する要求およびイベントフロー制御機構。

フェイルオーバーサービスは、フェイルオーバーセットの生成、供給フェイルオーバーセットの管理を引き起こす。ローカルなフェイルオーバーサービスは、メンバー状態機械を起動する。メンバー状態機械は、フェイルオーバーセットにおけるメンバーに対してされた変更を、アービタを介してサービスフレームワークに通知する。アービタは、サービスフレームワークおよびＪＣＰ（Ｊｏｕｒｎａｌ Ｃｏｎｔｒｏｌ Ｐｒｏｃｅｓｓ）とインタフェースを取って、メンバーの状態における変更およびそれに続くデータベースの役割変更を通知する。ユーザ要求は、管理サービスを介して仮想フェイルオーバーサービスに直接進む。リカバリ管理要求は、ローカルフェイルオーバーサービスに進む。

フェイルオーバーサービスは、サービスフレームワークおよびデータベースソフトウェアと組み合わさって作動し、ＶＳＸフェイルオーバーを管理する。通常動作の間、ＨＡセットにおけるノード（例えば、デバイス、通信パス、および他のそのようなコンポーネント）は、サーバと格納デバイスとの間でクライアントまたはデータパスへサービスを提供する。計画されたシャットダウンのイベント（すなわち、ノードの欠陥）において、このノード上で動作するサービスは、構成において別のノードに転換され、同様のロジカルエンティティとして同様のクライアントに提供される。クライアントに対して、サービスは、フェイルオーバーの前後で同じになるようにみえる。フェイルオーバー中、サービスは、短期間だけ利用できない。フェイルオーバーが生じた後、ホストは、存続するＶＳＸメンバーに対するＩ／Ｏ要求のリダイレクトを引き起こす。

（フェイルオーバーサービス）
フェイルオーバーサービスは、全体的なフェイルオーバー処理を制御する。フェイルオーバーサービスは、
１．フェイルオーバーセットの生成
２．フェイルオーバーセットに対するメンバー構成変更の管理
３．フェイルオーバー調整
ａ．リカバリ動作としてのフェイルオーバーの調整
ｂ．任意の操作としてのフェイルオーバーの調整
４．状態および警告報告を含む他のユーザインタフェース動作
５．フェイルオーバーのイネーブルおよびディセーブル
を提供する。

（ＶＳＣフェイルオーバーサービス）
ＶＳＣフェイルオーバーサービスは、
１．メンバー管理
ａ．メンバー構成
ｂ．メンバー状態管理
２．ＶＳＣの中枢部動作の起動および停止
３．リカバリ管理イベントの再生（ｌｉｓｔｅｎ）
４．フェイルオーバーサービスとメンバー役割変更に関するＶＳＣとの間のインタフェース
ａ．データベースモードを変更するためのアービタへの指示
ｂ．ＶＳＣ上のＳＰに対するインタフェース
５．フェイルストップ処理の実行
を管理する。

（ＬＣフェイルオーバーサービス）
ＶＳＣフェイルオーバーサービスは、
１．メンバー管理
ａ．メンバー構成
ｂ．メンバー状態管理
２．ＬＣの中枢部動作の起動および停止
３．リカバリ管理イベントの再生（ｌｉｓｔｅｎ）
４．フェイルオーバーサービスとメンバー変更に関するＬＣとの間のインタフェース
ａ．ＬＣ上のＳＰに対するインタフェース
５．フェイルストップ処理の実行
を管理する。

（アービタ）
図２２は、データベース用のアービタを示す。アービタは、フェイルオーバーサービスによって提供されたフェイルオーバー機能性に接続する必要があり、それと協同して、ジャーナルコントロールプロセス（ＪＣＰ）を介してデータベースに対して調停サービスを提供する。アービタは、アービタの状態をマスターに変更するとき、および立ち上げるときにスタンバイということが分かるので、データベースフォールトトレラント構成の本質的なコンポーネントである。アービタは、内部中枢部に関与している。アービタは、エラー分析中枢部の欠陥を通知する。それは、さらに、メンバー状態の変更が生じると、サービスフレームワークへの情報通知を担う。

上述するように、ＶＳＸにおけるフェイルオーバーに関連した構成および管理機能を担うソフトウェアモジュールが、フェイルオーバーサービスである。フェイルオーバーサービスは、仮想サービスである。

仮想サービスは、プライマリＶＳＣでイネーブルになり、バックアップＶＳＣおよび代替ＶＳＣでディセーブルになる。従って、管理要求は、常にプライマリＶＳＣに進む。対照的に、Ｉ／Ｏ要求は、情報収集中は任意のＶＳＣまたはＬＣを介して進み得る。従って、Ｉ／Ｏパスモデルは、管理モデルとは無関係に作動し、動作時（すなわちプライマリ）は全てのメンバーを処理する。

サービスフレームワークは、ＶＳＣで仮想サービスをイネーブルまたはディセーブルにする時を決定するためにアービタを使用する。サービスフレームワークは、メンバーの状態に基づいて仮想サービスをイネーブルおよびディセーブルにする。メンバーがプライマリ状態であるとき、仮想サービスは、そのノードでイネーブルとなる。メンバーがバックアップまたは代替の状態にあるとき、仮想サービスは、そのノードでディセーブルとなる。メンバーがプライマリ状態に変遷するとき、またはプライマリ状態から変遷するときはいつでも、そのメンバーでの仮想サービスが影響される。ＶＳＸが操作可能後、この仮想サービスのイネーブルおよびディセーブル状態は、サービスブートおよび任意のフェイルオーバー中は重要になる。

サービスフレームワークブートは、データベースを起動するためにはどのモードかを決定するために、ＶＳＸ構成機能の説明で記載されるように起動パラメータブロックを使用する必要がある。サービスブート中、サービスフレームワークは、そのロケーションでの全てのサービスを引き起こし、イネーブルにする。それが生じる前に、データベースは起動される必要がある。データベースを起動するために、メンバーの状態は、既に決定されている必要がある。ここで、問題がある。データベースの役割を決定するために、メンバーの状態を決定し、そのためには、データベースを起動する必要がある。それ故、データベースは再起動を必要とするので、サービスブートは二フェーズブートである必要がある。

サービスフレームワークブートは、メンバーの状態が調停されているかどうかを決定するために、起動パラメータブロックを検査する。既に調停された状態である場合、以下の規則にしたがってデータベースを開始し得る：
ａ）プライマリ状態が、マスターとしてデータベースを開始することを意味する
ｂ）バックアップ状態が、スタンバイとしてデータベースを開始することを意味する
ｃ）代替状態が、レプリカとしてデータベースを開始することを意味する。

その後、ＶＳＣロケーションのサービスは、以下のように初期化され、イネーブルにされ得る：
ａ）プライマリ状態が、仮想サービスをイネーブルにすることを意味する
ｂ）バックアップ状態が、仮想サービスをイネーブルにしないことを意味する
ｃ）代替状態が仮想サービスをイネーブルにしないことを意味する。

状態が調停中でなかった場合、次に第１のサービスブートフェーズは、フォールトトレランスなしでデータベースモードをマスターに設定し、ならびに、ＶＳＣフェイルオーバーサービスだけを開始する。次に、ＶＳＣフェイルオーバーサービスは、メンバーの役割を決定するために３．８．１における規則に続いて３．８．３における状態機械を実行する。メンバーの役割が決定された後で、状態は、ＶＳＸ構成機能の説明に記載されるようにスタートアップパラメータブロックに保存される必要がある。最後のステップは、新しいパラメータブロック有するＶＳＣを再起動することである。

フレームワークはさらに、内部フレームワークの中枢部を管理する。他のサービスフレームワークロケーションへの接続が損失する毎にエラー分析を通知する。
（フェイルオーバーセットの管理）
フェイルオーバーセットは、単一のコンポーネントに必ずしも存在しない特性を含むコンフィギュレーションを提供するために、同様のコンポーネントの収集に編成をもたらす。この収集またはセットは、種々の方法で編成され、かつ信頼性および可用性といったコンポーネントの種々の特徴を強調するように調整され得る。個々のコンポーネントは、単一タイプの編成を有する指定されたエンティティである。種々のコンポーネントが単一のフェイルオーバーコンフィギュレーションの制御下にあり得る。このようなわけで、コンポーネントは、メンバーと呼ばれる。

メンバーは、ＶＳＣ等のカードであり得るか、または、これはＶＳＸ全体であり得る。ＨＡセットにおけるメンバーは、プライマリ、バックアップ、またはオルタネイトの役割を演じる。ＨＡおよびＦＴタイプのフェイルオーバーセット内には、１つのプライマリメンバーおよび１つのバックアップメンバーのみがある。任意の数のオルタネイトメンバーが存在し得る。プライマリメンバーが失われた場合、フェイルオーバーが生じる。フェイルオーバーサービスは、データベース、ＩＯパス、およびサービスフレームワークを介して自動的に新しいプライマリメンバーに切替える。バックアップメンバーが落ちた場合、オルタネイトバックアップメンバーのセットから新しいバックアップメンバーが選択される。オルタネイトメンバーが落ちた場合、エラー報告がトリガされる。

フェイルオーバーセットにおけるすべてのカードは、同じデータベースを共有する。データベース故障許容差は、マスター、冗長待機、および冗長複製データベースサーバがクラスタで構成される。マスターデータベースは、クライアントアプリケーションが読み出しおよび書きプライマリシステムである。待機データベースは、マスターデータベース内でＪｏｕｒｎａｌ Ｃｏｎｔｒｏｌ Ｐｒｏｃｅｓｓ（ＪＣＰ）を介して生じる変化に従う。複製されたデータベースは、マスターまたは待機からの更新を受取るように構成される。待機データベースは、マスターが落ちた場合、マスターになり得る。複製されたデータベースは、バックアップが落ちた場合、またはバックアップがマスターになった場合にバックアップになり得る。データベースは、フェイルオーバービタの指示に従う。データベースの外側で維持される任意のコンフィギュレーションデータは、コンフィギュレーションの完全性（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｉｎｔｅｇｒｉｔｙ）を保つためにデータベースの一部をなさなければならない。

フェイルオーバーセットに含まれるＶＳＣポピュレーション内の各ＶＳＣは、プライマリ、バックアップおよびオルタネイトの３つのセットのうちの１つに属する。正確に１つのＶＳＣがプライマリとして機能し、かつ１つのＶＣＳがバックアップとして機能する一方で、残りのＶＳＣは、オルタネイトとして機能する。プライマリＶＳＣを収容するＶＳＸは、プライマリメンバーであるとみなされ、かつデータベースマスターである。バックアップＶＳＣを収容するＶＳＸは、バックアップメンバーであるとみなされ、かつデータベースバックアップである。オルタネイトＶＳＣを収容するバックアップＶＳＸは、オルタネイトメンバーであるとみなされ、かつデータベースの複製である。ＶＳＸがプライマリＶＳＣおよびバックアップＶＳＣの両方を収容する場合、これはプライマリメンバーであるとみなされる。１つ以上のＶＳＣがＶＳＸに収容され、これらの両方が動作可能であり、ＶＳＣの１つがバックアップＶＳＣである場合、他のＶＳＣはバックアップである。１つ以上のＶＳＣがＶＳＸに収容され、かつ、これらの両方が動作可能であり、ＶＳＣの１つがバックアップＶＳＣである場合、他のＶＳＣは、プライマリまたはオルタネイトである。ＶＳＣセットを決定する決定方法がフェイルオーバー機能である。ＶＳＣセットは、計画された保守およびシャットダウンのために手動で変更され得る。

仮想サービスがプライマリＶＳＣ上でイネーブルされ、かつバックアップおよびオルタネイトＶＳＣ上でディセーブルされる。従って、管理リクエストは、常に、プライマリＶＳＣに進む。対照的に、Ｉ／Ｏリクエストは、収集内の任意のＶＳＣまたはＬＣを通過し得る。従って、Ｉ／Ｏパスモデルは、管理モデルに依存せずに動作し、すべてのメンバーをアクティブまたはプライマリとして扱う。

フェイルオーバーサービスは、サービスフレームワークとデータベースソフトウェアとの組み合わせで機能して、ＶＳＸフェイルオーバーを管理する。正常な動作の間、ＨＡセットにおけるノードは、クライアントにサービスを提供するか、または、サーバからのパスを格納デバイスに提供する。計画されたシャットダウン、またはノードの障害の場合、このノード上で実行するサービスは、コンフィギュレーション内の別のノードに転送され、同じ論理エンティティと同じクライアントに再び提供される。フェイルオーバーの前後では、クライアントにはサービスが同一であると思われる。フェイルオーバーの間、サービスが利用可能でない期間がある。フェイルオーバーが生じた後、ホストは、残ったＶＳＸメンバーにＩ／Ｏリクエストを再指示する責任を負う。

ラインカード、格納プロセッサ、ＦＣ ＡＳＩＣおよびＦＣポートは、障害の回復がマルチパスポリシーを用いて管理されるため、フェイルオーバーセットではないことに留意されたい。７のＩＯパスフェイルオーバーを参照。

（フェイルオーバーセットのポリシー）
各フェイルオーバーセットは、以下の点について、固有の規則およびポリシーの支配下にある。

１．メンバーコンフィギュレーション−どのコンポーネントがセットに関与し、かつ、これらがどのように識別され、そしてフェイルオーバーのために構成されるか？ どの再構成オプションが支援されるか？
２．条件の組み合わせ−コンポーネント間の互換性のために必要とされる条件は何か？
３．故障の検出−コンポーネント障害を検出するために用いられる方法は何か？ 重い故障と軽い故障はどのように分離され得るか？
４．障害解析および協定−コンポーネント障害を引き起こした条件は何か、正しく動作するコンポーネントのすべてがその障害とどのように一致するか？
５．修正処置−コンポーネントがサービスから除去された場合、どの回復処置が取られるか？
６．再スタートポリシー−落ちたコンポーネントがフェイルオーバーセットに戻ることを可能にする状況は何か？ ＨＡセットのメンバーがどのように修理され、かつ再統合されるか？ 再統合された後に、リソースの自動フェイルバックは支援されるか？ 再統合は自動か手動か？
７．コンフィギュレーションの複製−メンバーの置き換えを支援するために、フェイルオーバーセットメンバーが複製されることを必要とするのはどのコンフィギュレーション情報か？
８．選択的フェイルオーバーフェイルオーバーセットのメンバーを規則正しくサービスから除去するために用いられるのはどの方法およびアルゴリズムか？ メンバーはフェイルオーバーセットに再統合されたサービスからどのように除去されるか？
９．リソース管理−フェイルオーバーセットメンバー間で共有されるリソースを分割する場合のために、どのリソースが調停されなければならないか？
１０．フェイルストップポリシー−フェイルオーバーセットの最後に残ったメンバーは、落ちたメンバー（単数または複数）が修復され得る前に落ちる。フェイルストップポリシーは、メンバーが障害に応答して、障害が発生したことを他のコンポーネントが検出し、その後、停止することを可能にする状態を変更する際に用いられるポリシーである。

（フェイルオーバーセットのタイプ）
上述のように、フェイルオーバーセットは、２つのカテゴリー、故障許容差フェイルオーバーセットおよび高可用性フェイルオーバーセットに分類される。これらのカテゴリーに加えて、フェイルオーバーセットは、さらに、これらの挙動によって区別される。いくつかのセットが能動／待機挙動を行う一方で、他のセットは、能動／能動挙動を行う。

すべてのフェイルオーバーセットは、ｔ故障許容差である。すなわち、フェイルオーバーセットは、これがｔ障害を被り得、かつ、依然としてその動作要件を満たす場合、これはｔ故障許容差である。

（故障許容差フェイルオーバーセット）
（ＶＳＣフェイルオーバーセット）
ＶＳＣフェイルオーバーセットは、能動／受動モードで構成される２つのＶＳＣである。ＶＳＣは、同じＶＳＸ（Ｔ＝１）内に配置される。

（スイッチファブリックフェイルオーバーセット）
スイッチファブリックフェイルオーバーセットは、能動／受動モードで構成される２つのスイッチファブリックである。ＳＦは、同じＶＳＸ（Ｔ＝１）内に配置される。

（高可用性フェイルオーバーセット）
（ＶＳＸフェイルオーバーセット）
ＶＳＸフェイルオーバーセットは、能動／能動モードで構成される２つ以上のＶＳＸである。ＶＳＸは、互いに、および格納デバイスの共通のセットと物理的に接続される。各ＶＳＸは、ＨＡセットコンフィギュレーションに依存する１つ以上のＶＳＣ（Ｔ＝ｎ）を有し得る。以下の６節を参照。

（メンバーコンポジション）
フェイルオーバーセットのメンバーコンポジションは、メンバーが組み合わされる態様を理解する。フェイルオーバーセットのコンポジションは、以下の情報のいくつかを含む。

１．タイプ（２ウェイ、４ウェイ、Ｎウェイ、階層的）
２．メンバーのカウント発見
３．構成されたメンバーのカウント
４．冗長限界（持続的なメンバーの障害の数）
階層的コンポジションは、ＶＳＸ（故障許容差）内およびＶＳＸ（高可用性）の外部にてフェイルオーバーを組み合わせることを可能にする。上述のように、メンバーの役割は、階層的コンポジションのＶＳＣによって決定される。

図５は、フェイルオーバーコンフィギュレーションのコンポーネントを示す。コンポジションは、セットが下に位置するＶＳＸまたはフェイルオーバーセットから形成される態様に関する規則からなる。

メンバーユニットは、コンポジションのメンバーとして関与するコンポーネントを識別する。メンバーユニットは、下に位置するコンポーネントのすべてを識別する。これは、１つ以上のコンフィギュレーションが関与することを防止する。

フェイルオーバーセットと、そのコンポジションとの間を区別する目的は、それらの挙動を分離することである。例えば、ＨＡセットは、そのメンバーＶＳＸの１つがユーザのリクエストに応答できない場合であっても、それに応答することができ得る。ＨＡセットのコンポジションの方法は、ＶＳＸの機能性から分離される。

（メンバーユニット）
コンポーネント状態は、コンポーネントの状態を表す。しかしながら、これらは、フェイルオーバーコンフィギュレーションによってそれらの上にマッピングされるメンバーの状態を反映しない。このタスクは、メンバーユニットによって達成され、これは、メンバーの状況を反映する。

（状態）
メンバーユニットはスレッドを必要としない。コンポーネント障害または置換といったコンポジションの状況に影響を及ぼすプロセスがメンバーユニットに作用する。図６は、メンバーユニット状態の図を示す。

（アンマッピング（Ｕｎｍａｐｐｅｄ））
この状態は、メンバーユニットが下に位置するコンポーネントのいずれにもマッピングされない状態を示す。この状況は、下に位置するコンポーネントに障害が生じた後に生じる。この状態において、メンバー内で複製されたデータベースは無効であり、もはや用いられない。いずれのＩＯサービスもアンマップドメンバーによって利用され得ない。これは、故障したコンポーネントをフィールドサービスが置換するまで永久に続く状態である。

（部分的マッピング（Ｐａｒｔｉａｌｌｙ Ｍａｐｐｅｄ））
この状態において、メンバーユニットは、これに割り当てられるメンバーの部分にマッピングされる。これは、前に落ちたコンポーネントが置換され、プライマリメンバーからのデータベース／コンフィギュレーションが置換コンポーネントに書き込まれる場合に生じる。部分的にマッピングされたメンバーのすべてのコンフィギュレーションデータ
は、データベース同期化動作が完了するまで無効である。

（マッピング）
この状態において、メンバーユニット上のすべてのデータベースコンフィギュレーションは、アクセスするために利用可能である。ＩＯサービスは、メンバーによって実行され得る。いくつかの重要なメンバー状態は、以下のとおりである。

１．プライマリ−メンバーの仮想サービスがアクティブコールプロセシングを実行する（イネーブル）。データベースはマスターモードである。

２．バックアップ−メンバーの仮想サービスは、アクティブコールプロセシングを実行しない（ディセーブル）。データベースはスレーブモードである。

３．オルタネイト−メンバーの仮想サービスは、アクティブコールプロセシングを実行しない（ディセーブル）。データベースはレプリカモードである。

メンバー状態については、３．８．にて十分に議論される。

（イベント）

（フェイルオーバーセットの作成）
コンフィギュレーションは、フェイルオーバーサービスにおけるフェイルオーバーセットのすべてのパラメータの設定である。これは、フェイルオーバーセットの部分の構成およびそのコンポジション、ならびにメンバーの挙動を支配する個別に管理可能な設定のすべてを含む。

フェイルオーバーセットの作成段階は、「ユーザ」からパラメータを受取り、フェイルオーバーコンフィギュレーションのデータ構造および永久データベース入力を生成する。ユーザが実際に行うか（ｒｅａｌ）または自動化され得る。このプロセスは、その差を理解しない。図７は、フェイルオーバーセットを作成する可能な状態マシンを示す。

（状態）
図７に示される状態マシンを含む状態の状態説明は、以下の節において見出される。

（フェイルオーバーセットの作成）
この状態は、このフェイルオーバーセットのために必要とされるリソースを決定し、そのリソースを割り当て、かつフェイルオーバーセットデータを初期化する。

１．パラメータに従ってフェイルオーバーセット構造の割り当ておよび初期化。

２．「フェイルオーバーセット初期化」の生成。

（未定義（ｕｎｄｅｆｉｎｅｄ））
この状態は、フェイルオーバーセットの検証が失敗したことを示す。定義するために改変が必要とされる。

（フェイルオーバーセットの検証）
この状態は、フェイルオーバーセットの定義が、ユーザによって定義されたものとして完了したことを検証する。

１．フェイルオーバーセットコンポジションおよびタイプの検証
２．メンバーカウントおよびデフォルトの役割の検証
３．メンバーの互換性の検証
４．格納の可視性を検証
５．ノードおよびポートワールドワイドネームの検証
６．有効である場合、「定義は完成」を生成。そうでない場合、「定義は未完成」を生成。

（フェイルオーバーセット定義）
この状態は、フェイルオーバーセットが正確に定義されて、メモリ内に存在することを示す。これは、この時点にてユーザによって改変され得るか、またはデータベースにコミットされ得る。

１．コミットまたは更新を待つ
（コンポーネントの追加）
この状態は、メンバーコンポジションユニットを割り当ておよび初期化する。

１．メンバーコンポジションユニットの割り当ておよび初期化
２．「コンポーネントの追加」を生成
（コンポーネントの除去）
この状態は、メンバーコンポーネントユニットを除去および解放（ｄｅ−ａｌｌｏｃａｔｅ）する。

１．メンバーコンポジションユニットの解放および構造の更新
２．「コンポーネントの除去」を生成
（フェイルオーバーセット定義を更新）
この状態は、ユーザがフェイルオーバーセットのいくつかの属性を変更したことを示す。例えば、ユーザは、デフォルトプライマリメンバーを変更することを所望し得る。これはコンポジションの変更を含まない。

１．ユーザによって供給されたパラメータからのすべての属性を更新する
２．「フェイルオーバーセットの更新」を生成
（作成の完了）
この状態は、フェイルオーバーセットのメモリ内コピーをデータベースにコミットする。

１．トランザクションのコミット
２．「定義のコミット」を生成
（作成完了）
これは、フェイルオーバーセットを作成するスレッドのデリート状態である。完了した場合、データベース内のデータからフェイルオーバーセットを持ち出すことを強いる。

１．フェイルオーバーセット形成構造を解放
２．「フェイルオーバーセット検出」を生成
（イベント）
本節は、作成状態マシンにおけるイベントを記載する。

（フェイルオーバーセットの再構成）
カスタマがフェイルオーバーコンフィギュレーションを変更することを可能にすることが所望され得る。例えば、カスタマは、シングルＶＳＸからＨＡセットにアップグレードすることを所望し得る。再構成は、既存のフェイルオーバーコンフィギュレーションを改変するプロセスを支配する一方で、格納はクライアントとオンラインの状態である。

（コンポーネントの増加）
故障許容差コンフィギュレーションの興味深い特徴のうちの１つは、フェイルオーバーセットがオンラインである一方で、冗長性を追加するという能力である。必要とされるのは、メンバーがアクセスされないこと、および、ユーザは、動作が、影響されたコンフィギュレーションデータを１つ以上のメンバーからアクセス可能にすることを理解することだけである。

（コンポーネントの低減）
フェイルオーバーセット内のメンバーの数を低減することもまた好適な特徴である。これは、これらが正確にどれだけの可用性を必要とするかを知る前に、ユーザがＨＡセットをセットアップすることを可能にする。その後、ユーザデータをＨＡコンフィギュレーションにマッピングした後、ユーザは、他のもののための空間を作るためにＨＡセットのサイズを低減することができ得る。ＨＡセットのサイズを低減するために、必要とされるのは、永久的に除去されるＶＳＸがアクセスされないこと、および、ユーザは、動作が、メンバーがデリートされると、影響を受けたコンフィギュレーションデータをアクセス不可能にすることを理解することだけである。

（フェイルオーバーセットの提示）
フェイルオーバーセットのブリングアップは、各個別メンバーの提示（ｂｒｉｎｇ−ｕｐ）から達成される。各メンバーは、
１．ハードウェアおよびソフトウェアの初期化および可用性チェックに首尾よく合格し、
２．フェイルオーバーセットにおけるその役割を決定し
３．それ自体でフェイルオーバーセットにアナウンス
しなければならない。

ブリングアッププロセスの目的は、フェイルオーバーセットとメンバーとの間の関係を生成することである。ブリングアップの範囲は、フェイルオーバーセットがＶＳＸによって最初に発見された時間と、フェイルオーバーセットのすべてのコンポーネントが配置および認識された時間との間の時間である。この範囲が限定された理由は、フェイルオーバーセットの動作機能を制御する状態マシンの複雑性を低減することである（機能するフェイルオーバーセット状態マシン）。一旦ブリングアッププロセスが完了すると、セットの制御は機能するフェイルオーバーセット状態マシンに引き渡される。

メンバーのブリングアップは、次節に記載される。機能するフェイルオーバーセットセット状態マシンは、節３．１０に記載される。

（メンバー状態）
コンポジションユニットがマッピングされた状態であるメンバーは、ＶＳＸおよびＶＳＣベースのフェイルオーバーセットの以下のフェイルオーバー状態を用いる。図８に示される状態の図は、以下の表によって説明される。

すべてのメンバーは、最初に使用不能状態に割り当てられる。メンバーがブリングアップ診断、ブートおよび初期化に合格すると、メンバーは、使用不能状態から除去され、そして使用可能状態に配置される。メンバーがコンフィギュレーションかつ可用性のチェックを通過した後、メンバーは、それがフェイルオーバーセット内でプライマリ、バックアップまたはオルタネイトのいずれであるかを決定する。

使用不能状態から除去され、使用可能状態に配置されたメンバーが修復されたイベントによってもたらされる。このイベントは、メンバーのスタートアップが成功したことであると定義され、遂行（ｐａｓｓｉｎｇ ｇｏ）、遂行しない（ｎｏ−ｇｏ）診断、ＯＳ初期化およびアプリケーションの初期化を含む。

メンバーは、利用可能状態から除去され、そして構成されたイベントによってプライマリ、バックアップまたはオルタネイト状態に配置される。構成されたイベントは、以下のことを示す。

すべてのハードウェアおよびソフトウェアの初期化の完了が成功
・すべての構成可能パラメータは有効
・ハードウェアおよびソフトウェアの改正（ｒｅｖｉｓｉｏｎ）は互換性をもつ
・メンバーのデータベースコンフィギュレーションは、プライマリ、バックアップまたはオルタネイトであることが決定される
プライマリまたはバックアップ状態から除去され、かつ使用不能状態に配置されたメンバーは、失敗したイベントによってもたらされる。失敗したイベントは、メンバーがデータの利用可能性を提供することを防止する状況であると定義される。失敗したイベントは、エラーを示す。いくつかの一般的な障害状況は、
・ハードウェア障害がメンバーを動作不可能にする。
・ソフトウェアは、クラッシュが原因で、一次的な使用不能性を引き起こす。
・メンバーは、まだ構成されない
・ブリングアップ診断が回復不能のエラーを検出
・メンバーは、パワーオフされ、場合によっては、シャーシから除去される。
予定された保守のために、除去イベントが用いられる。保守動作が完了した後、メンバーを再スタートさせるために追加イベントが用いられる。

使用不能状態に割り当てられるメンバーは、フェイルオーバーし得ず、かつ近い将来にフェイルオーバーできることが期待されない。利用可能セットに割り当てられたメンバーは、フェイルオーバーし得ないが、コンフィギュレーションが検証され、メンバーの役割が決定された後、近い将来にフェイルオーバーすることができる。プライマリまたはバックアップ状態に割り当てられたメンバーのみがフェイルオーバーし得る。

（プライマリ／バックアップの役割定義）
メンバーの役割を決定する場合、２つの基本的な取り扱いの場合がある。第１に、プライマリメンバーがすでに存在し、第２に、プライマリメンバーは決定されていない。第１の場合は単純である。プライマリメンバーがフェイルオーバーセット内にすでに存在する場合、任意の新しいメンバーが自動的に待機メンバーになる。待機メンバーがすでに存在する場合、メンバーはオルタネイトになる。第２の場合は、いくらか複雑なアルゴリズムを必要とし、どのメンバーがプライマリメンバーであるべきかを決定する。詳細は、以下の節にて見出される。

（単一のメンバーのブート）
単一メンバーフェイルオーバーセットは、それ自体が構成された場合、自動的にプライマリメンバーになる。以下の節は、単一メンバーがフェイルオーバーコンフィギュレーションの一部分としてブートする場合について議論する。

（ライブシステムへのブート）
予定された保守またはシャットダウンの後、メンバーは、再スタートし、そして再びフェイルオーバーセットに結合する。プライマリメンバーは、すでに存在する。この場合、メンバーは、バックアップメンバーになり得る。バックアップがすでに存在する場合、メンバーは、オルタネイトになり得る。

（障害後のブート）
破壊的なエラーの後、メンバーがフェイルオーバーセットへの再結合（ｒｅｊｏｉｎ）を試みることが可能である。エラーが持続的なハードウェアエラーである場合、メンバーは、単に、「使用不能」状態に留まり、置換されることを待つ。ソフトウェアエラーが再スタートを引き起こした場合、メンバーは、フェイルオーバーセットに再結合することを可能にし得る。

（複数メンバーのブート）
２ノードＨＡセットにおける両方のメンバーが同時にブートされることが可能である。これらの状況を理解するために、最初にいくつかの新しい用語が定義される。

コールドブート（ＣＯＬＤ ブート）は、パワーサイクル状況からの再スタートであると定義される。パワーサイクル状況は、
１．ハードリセットボタンが押され
２．電源スイッチがオフからオンに切替えられる
３．規則的にシャットダウンされる
コールドブートは、通常、ＰＲＯＭコードへのジャンプ、ＯＳおよび機能コードの再ロード、およびハードウェアの完全な再初期化として特徴付けられる。メンバーは、パワーオフの時点にて正規のメンバーでなければならない。

ウォームブート（ＷＡＲＭ ブート）は、任意の他の状況からの再スタートであると定義され、
１．システムトラップまたは例外
２．ソフトリセットボタンが押される
を含む。ウォームブートは、通常、ＯＳおよび機能コードの再ロード、およびハードウェアの部分的再初期化と特徴付けられる。ウォームブートは、さらに、再スタートの時点にて進行中の動作、例えば、キャッシュ内のデータ、ＲＡＩＤ書き込み−進行中等の回復を必要とし得る。メンバーは、ウォーム再ブート回復をするのに適切であるように再スタートの時点にて正規のメンバーでなければならない。そうでない場合、コールドブートが宣言される。

３つの基本的なブート状況が存在する。

１．メンバー「Ａ」は、コールドブートし、メンバー「Ｂ」は、コールドブートする（コールドブート）。

ａ．両方のメンバーがそのデフォルトメンバー状態を想定すべきである。

２．メンバー「Ａ」またはメンバー「Ｂ」は、ウォームブートであり、他のメンバーはコールドブートである（ウォームブート）。

ａ．ウォームブートメンバーは、その前のメンバー状態を想定し、コールドブートメンバーは残った方を想定する。

３．メンバー「Ａ」は、ウォームブートであり、メンバー「Ｂ」は、ウォームブート（混合ブート（ＭＩＸＥＤ ｂｏｏｔ））
ａ．両方のメンバーは、それらの前のメンバー状態を想定する
図９〜図１１に示される以下の順序図は、アービトレーションアルゴリズムを示す。図９は、コールドブートのアービトレーションアルゴリズムを示す。図１０は、ウォームブートのアービトレーションシーケンスを示す。図１１は、混合ブートのシーケンスを示す。

（代替的役割の決定）
代替的役割の決定は単純である。プライマリおよびバックアップメンバーが識別された後、フェイルオーバーセットに参加する任意のメンバーはオルタネイトになる。新しいバックアップの選択は、すべてのオルタネイトを数値的識別子またはメンバーの数に基づいて順序付ける等、単純なスキームを用い得る。

（サンプル２ノード状態マシン）
図１２の表式で示される状態マシンは、２ノードフェイルオーバーセットに対して有効であり、これは、プライマリ／バックアップ挙動に追従する。アクションルーチンは、図１３に示されるアクション表にまとめられる。状態５は、結果として生じるプライマリまたはバックアップ状態の決定に依存して５ａおよび５ｂに分離されることに留意されたい。

（互換性チェック）
メンバー（Ｍｅｍｂｅｒ）の役割（すなわち、どのメンバーが「一次（Ｐｒｉｍａｒｙ）」であるかどうか、ならびに、「スタンバイ」であるか）を決定する前に、メンバーは、その構成中の他のメンバー全てとの互換性のためにチェックされなければならない。各メンバーに対して、情報の以下のカテゴリがチェックされる。

・ＨＷ−ＨＷ
・そのメモリは全てのメンバーで同じでなければならない。この条件は、データベースおよびＳＡＮエレメントを含むことが可能であり、両方のメンバーの全ての動作を支援することが可能でなければならないことを説明するために緩和され得る。

・ポートの数は全てのメンバーで同じでなければならない。再度、この条件が緩和され得る。デバイスが両方のシステムから可視である限り、ポートの番号は、実際に重要ではない。

・各メンバーのハードウエアバージョンは、それぞれ他のメンバーのハードウエアバージョンと互換性がなければならない。

・全てのストレージは、全てのメンバーに接続され、可視でなければならない。カスタマーがそのように望む場合、あるポリシーが、「Ａｌｌ Ｓｔｏｒａｇｅ」文節（ｃｌａｕｓｅ）を無効にするために提供される。利用可能なオプションは、
・アラームを発生させる
・１つ以上のＬＵＮがオンラインになることを妨げる
・コンポーネントがメンバーになることを妨げる
ことである。

・このポート構成はメンバー内で整合しなければならない。ファイバチャンネル（Ｆｉｂｒｅ Ｃｈａｎｎｅｌ）は、ファイバチャンネルと整合されなければならず、ｉＳＣＳＩは、ｉＳＣＳＩと整合されなければならない。

・ＳＷ−ＨＷ
・ＳＷバージョンは、ローカルおよびリモート両方のＨＷバージョンと互換性がなければならない。

・ＳＷ−ＳＷ
・ＳＷバージョンは、ローカルおよびリモート両方のＳＷバージョンと互換性がなければならない。

・クロックはメンバー間のエラーのいくつかのマージン内で同期化されなければならない。メンバークロック間の最大の差は、ハートビート（Ｈｅａｒｔｂｅａｔ）プロトコルによって決定される。

（フェイルオーバーセットの管理）
メンバー状態マシンがメンバーの役割を決定した後、提供されたフェイルオーバーセットのオブジェクトがフェイルオーバーセットとメンバーとの間の関係を定義するために作成される。このメンバー状態マシンは、フェイルオーバーセットが特定のコンポーネントにコミットするようになり、この排他的な関係を制御するために提供されたフェイルオーバーセットの作成を引き起こすのはいつかを決定する。

この提供されたフェイルオーバーセットは、いくつかの責任を有する。第１には、構成の統合性を維持することである。これは、イベントの注意深い処理、構成の変化の制御、およびデータベースの適時な同期化によって達成される。この提供されたフェイルオーバーセットはまた、全ての欠陥の、提供されたフェイルオーバーセットへの通知を処理し、フェイルオーバーセット構成の更新を適切に管理することに対して責任がある。

提供されたフェイルオーバーセットはまた、セットのパラメータへの全ての通知を管理しなければならない。この現在の状態マシンは、この特徴をインプリメントしないが、将来的にはこれをインプリメントする。フェイルオーバーセットパラメータの改変は、設定状態に関する影響の理解を必要とし、同様にメタデータの同期化を必要とする。容量の増大または低減等の改変はまた、このパスを介して管理されなければならない。

（状態）
図１４は、上述のタスクを達成する提供されたフェイルオーバーセット状態マシンを示す。この状態は以下に説明される。

（提供されたフェイルオーバーセットの作成）
この状態は、提供されたフェイルオーバーセットリソースを割り当て、初期化する。
１．提供されたフェイルオーバーセットリソースを割り当て、初期化する。
２．「作成され提供されたフェイルオーバーセット」を生成する。

（オフライン）
この状態は、すべての挿入されたクライアントにオフラインフェイルオーバーセットを提示する。フェイルオーバーは、オフライン状態でディセーブルされる。
１．「ディセーブルされたフェイルオーバー」を生成する。

（オンラインの検証）
フェイルオーバーセットを検証するこの状態は、オンラインでクライアントに進み得る。
１．冗長度＜冗長限界になる場合、「オンライン欠陥」を生成する。
２．フェイルオーバーセット状態＝オンラインに設定する。
３．変化をデータベースにコミットする。

（オンライン）
この状態は、オンラインフェイルオーバーセットを全ての挿入されたクライアントに提示する。これは、フェイルオーバー復元動作が提供され得る有効な状態のみである。
１．「イネーブルされたフェイルオーバー」を生成する。

（失ったコンポーネントの除去）
この状態は、構成から失ったメンバーを除去し、データベースを更新する。
１．構成からコンポーネントを除去するために「失ったメンバー（Ｌｏｓｔ Ｍｅｍｂｅｒ）」を生成する。
２．フェイルオーバーセットのシーケンス番号を更新する。
３．変化をデータベースにコミットする。
４．失ったコンポーネントが一次メンバーである場合、「一時的な欠陥（Ｐｒｉｍａｒｙ Ｆａｉｌｅｄ）」を生成する。
５．失ったコンポーネントがバックアップメンバーである場合、「バックアップ欠陥（Ｂａｃｋｕｐ Ｆａｉｌｅｄ）」を生成する。
６．失ったコンポーネントが代替のメンバーである場合、「代替的な欠陥（Ａｌｔｅｒａｔｅ Ｆａｉｌｅｄ）」を生成する。

（オフラインへの移行）
この状態はフェイルオーバーセットをオフラインに移行する。
１．任意の現在のリクエストを終了する。
２．シーケンス番号および状態を更新する。
３．変更をデータベースにコミットする。

（提供されたフェイルオーバーセットの削除）
この状態は、提供されたフェイルオーバーセットを削除する。

（イベント）
提供されたフェイルオーバーセットに関するイベントの説明は以下に見出される。

表７−提供されたフェイルオーバーセットイベント
（欠陥検出アーキテクチャ）
信頼できる分散されたストレージシステムを構成する主な挑戦の内の１つは、「フェイルオーバー可能な」条件を適時に検出する。検出は時間が重要である。なぜなら、データの格納または取り出しのような要求は、欠陥の時間で顕著であり得る。エラーと競合することがシステムの異なる部分から報告された場合に、この検出問題はさらに悪化されることにより、エラー特有の復元を困難にする。所定のエラーが与えられると、フェイルオーバーがリクエストされるべきであるかどうかを決定することが可能であり得ない。しかし、エラーの組み合わせが与えられると、フェイルオーバーは可能な復元のみであり得る。フォールオーバー可能な条件の検出は５〜１０秒かかるべきではない。

一旦、あるコンポーネントをフェイルオーバーするための決定がなされると、概念的に、当面のタスクは、比較的直線的な逐次的プログラミング問題である。一旦開始されると、このフェイルオーバーを行うためにかかる時間は、時間を検出すること自体と同じくらい重要である。フェイルオーバーするのに時間がかかりすぎる場合、ホストファイルシステム、ボリュームマネージャ、およびアプリケーションがタイムアウトされ、ハングされる（ｈａｎｇ）。このセクションは、フェイルオーバーに対する欠陥を信頼可能に検出するための一般的なアプローチの概略を示す。図１５は、本発明の実施形態による欠陥検出および分析の一般化されたブロック図を示す。欠陥検出は、ＶＳＸを介して分配される。概して、２つの欠陥検出シナリオは、以下のように説明される。
１．自己検出された欠陥−検出ソフトウエアが欠陥しそうなメンバー上で実行されている欠陥がある。自己モニタリングアルゴリズムは、以下の欠陥の主要な原因である。

ａ．ハードウエアエラー
ｂ．ＩＯパスエラー
ｃ．タスクモニタリング
ｄ．ＲＴＯＳ拡張
ｅ．ローカル診断テスト結果
ｆ．広いレベルのハートビート
２．パートナーに検出された欠陥−パートナーが欠陥を検出する欠陥がある。

ａ．パートナーレベルのハートビート
ｂ．サービスフレームワークＩＰＣ欠陥
ｃ．データベースＪＰＣ／ＪＰＣ欠陥
ｄ．パートナー診断テスト結果
これらの欠陥検出方法は以下のセクションでより詳細に説明される。

（ハードウエアエラー）
ハードウエアエラーは、最も顕著なデバイスドライバである種々のソースによって検出される。広いレベルのデバイスから生じる任意のデバイスレベルエラーは、フェイルオーバーをリクエストすべきである。

（ＩＯパスエラー）
ＩＯパスエラーは、典型的にはＩＯパスフェイルオーバーのみを含む。しかし、ＩＯパスエラーの組み合わせは、しばしば広いレベルの欠陥を示し得る。パスの欠陥はまた、広いエラーによって引き起こされ得る。このような欠陥が発生する場合、フェイルオーバーがリクエストされるべきである。一般的には、モジュールレベルのコンポーネント上のハードウエアエラーは、フェイルオーバーをリクエストすべきである。

別のＩＯパスエラー、リンクエラーがあり、これらは別個に処理される必要がある。例えば、誰かが下流ポートからファイバチャンネルを引っ張る場合、全体のＶＳＸではなく、ＩＯパスのみがフェイルオーバーすべきである。

（タスクモニタリング）
全てのプロセッサ（ＰＰＣ、ｅＰＰＣ、ＰＩＣＯ、およびＦＣ）のタスクおよびスレッドは、正確な動作のためにモニタリングされるべきである。ＶｘＷｏｒｋのために、２つの最も一般的なタスクレベルのエラーは、コードの無限ループであり、タスクがＲＴＯＳによって一時停止される例外（ｅｘｃｅｐｔｉｏｎ）がある。いくつかの例は、
１．フリーリスト上にすでに存在するタスクフリーメモリ
２．ゼロによる分割
３．ページ欠陥
４．満たされないループ終了条件
である。

機構は、これらの特定のシナリオをチェックするための場所に置かれるべきである。一実施形態では、復元がリブートをリクエストすべきであり得る。

（ＲＴＯＳ拡張）
エラー解析がリソース上のエラーを解析かつトラッキングすることに対して責任がある。全てのエラーがエラー解析で発生することが重要である。しかし、これは、いくつかのエラーがハードウエアの例外およびトラップを引き起こす場合には、常に可能ではない。従って、タスクレベルで処理され得ない。これらの種類のエラーに対して、ＲＴＯＳへのインターフェースが必要とされる。

（ＲＴＯＳ例外ハンドラー）
プロセッサにその例外ハンドラーを入れる例外がプロセッサにおいて発生する度に、永久的なまたは過渡的なエラーが発生したかどうかを決定するために、例外が解析される必要がある。このような解析は、さらなるテストを行うために診断をスケジューリングすることを必要とし得るため、このエラーが永久的または過渡的であるとして正確に特徴付けられ得る。

最初に、検出された任意の永久的なエラーは、フェイルオーバー復元動作を生じるべきである。任意の永久的なエラーは、フェイルオーバーセットから除去されるメンバーを生じるべきである。このエラーが過渡的である場合、メンバーは、フェイルオーバーセットから永久的に除去されるべきではない。この情報は、エラー解析に通信されるべきであり、それにより生じたハートビートが無視される。

（診断テスト結果）
カードの永久的なハードウエアエラーの検出を生じる診断テスト結果は、フェイルオーバーのためのリクエストに直接的に結合されるべきある。任意のカードレベルのハードウエアエラーは、カードレベルフェイルオーバーの要求を生じる。後で、より高度なエラー復元（ＳＰのディセーブル等）が追加され得る。

（欠陥の報告）
フェイルオーバーサービスは、アラームマネージャおよびログサービスを介してＵＩに欠陥を報告する。残っているメンバーは、パートナーのメンバーの欠陥を報告する。欠陥したメンバーのログが取り出される。

パートナーの状態は、以下のように利用可能である。

表８−ＵＩに可視のパートナーの状態
ソフトウエアエラーのためにフェイルオーバーが発生することが可能である。しかし、あるメンバーは、ハードウエア欠陥のために置換されるのみであるべきある。フェイルオーバーを引き起こすソフトウエアエラーにメンバーを置換させるべきではない。これは、持続的なストレージにエラーを記録することが可能であるべき欠陥報告機能を必要とすることにより、アービターはレコードを読み出し得る。

（フェイルオーバーアラーム）
フェイルオーバーが発生する場合、フェイルオーバーサービスがデータベースおよびサービスフレームワークによって新しい一次メンバーに自動的に切り替える。以下の状態は、フェイルオーバーに対して引き起こされる。

・計画されたメンテナンスおよびシャットダウン−フェイルオーバーセットの最良の利点の内の１つは、クライアントへのサービスを妨害することなく、定期的なメンテナンスを実行するためにサービスをメンバーから離れて移動させ得る。例えば、これは、最新のリリースにソフトウエアをアップグレードすることを可能にするか、またはサイトを動作的に維持する一方でシステムにメモリを追加する。

・システムクラッシュ−メンバーがクラッシュし、そのメンバーが一次メンバーである場合、別のメンバーは、サービスおよびデータ利用可能性が維持されるように、速やかに一次メンバーに作成されるべきである。ソフトウエアエラーがクラッシュを生じ、そのメンバーがその構成から永久的に除去されないことを決定し得る。そのクラッシュは、ハードウエア欠陥によるものであった場合、メンバーは、永久的に除去される。

・通信欠陥−各メンバーは、ハートビートプロトコルに関与する。このハートビートプロトコルは、メンバーの健康を確立する。このプロトコルは、この構成で各メンバーを相互接続する冗長の二方向ラインを介して実行すべきである。このプロトコルは、メンバーの欠陥間の１つ以上の通信方法が落ちる場合に、ある欠陥が存在することを結論付け得る。通信欠陥は、
・アダプタ欠陥
・このシステムは、通常のハブに接続されるか、またはその欠陥を切り替える。

・通信ケーブル欠陥
・システムハング
によって発生する。

・システムハング−システムハングは、通信欠陥を引き起こすが、そのシステムハングはまた、データベース不正への扉を開く。データ完全性の妥協（すなわち、システムキャッシュまたは無効データ）に対して保護するために、メンバーは、欠陥モードのサービスを継ぐ前に落ちるノードがデータベースを修正することを確実にする。これは、一般的には、Ｉ／ＯフェンシングまたはＩ／Ｏバリアと呼ばれる。

・ソフトウエアによって定義された達成された閾値−所定の閾値条件は、メンバーの欠陥を引き起こし得る。繰り返し再起動するメンバーは、メンバーを欠陥させる閾値の例である。

・ハードウエア欠陥−時には、ソフトウエアがハードウエア欠陥を直接的に検出することが可能である。これが発生する場合、メンバーは、欠陥の範囲に依存して置換される必要があり得る。ＳＰまたはＦＣポート欠陥は、独立して管理され得、メンバーの欠陥を引き起こす必要がない。しかし、ＶＳＣに関するＩＤＥドライブ欠陥は、全体のメンバーを利用不可能にする。

・データベース欠陥−データベースによって提供されたこの欠陥許容差は、欠陥の単一ポイントのみ許容するように設計される。これらは、以下に分類される。

・ソフトウエア欠陥
・以下のソフトウエア欠陥は、システムによって許容される
・ＲＴＲＤＢは、非予測的に終了する
・ＲＴＲＤＢをハングする
・以下の欠陥の所定の例が許容される
・ＲＴＲＤＢは誤った内部状態を示す
・ハードウエア欠陥
・以下のハードウエア欠陥は、システムによって許容される
・プロセッサの停止
・ディスクエラー
・ネットワークエラー
・システム欠陥
・以下のシステム欠陥は、システムによって許容され得る
・ダイナミックストレージ消耗（不十分なメモリ）
・安定なストレージ消耗（不十分なディスク空間）
・これらの欠陥が過渡的な欠陥である場合に許容されるのみであり得、特に、スタンバイシステムに関して直ぐに明らかにならない。

・フレームワーク欠陥−サービスフレームワークによって提供されたこの欠陥許容差は、また単一の欠陥のポイントのみを確認するように設計される。これらは、以下に分類される。

（ハートビートアルゴリズム）
ハードウエアエラーを特徴付けることは困難なプロセスである。これは、欠陥挙動が低減されて、プロトコルを終了するために、不能プロセッサになる場合、ＶＳＸにおいて簡略化され得る。これは、ハートビートプロトコルの目的である。

ＶＳＸにおける各カードは、それ自体の独立ハートビートアルゴリズムを実行する。マルチカードハートビートが必要とされない。ＪＣＰおよびサービスフレームワークの各々がそれ自体のハートビートアルゴリズムを有するからである。ハートビート欠陥は、エラー解析に報告されるべきである。

（基板内部のハートビートアルゴリズム）
ハートビートプロトコルは、署名されたメッセージの概念を使用し、実質的に以下に従う。各カード上のプロセッサは、トランスミッタおよびレシーバの２つのグループに分割される。このトランスミッタグループは１つのプロセッサを含み、レシーバグループは、残りのプロセッサを含む。このトランスミッタは、値を各レシーバに送信することによってハートビートを開始する。次いで各レシーバは、その値を送信し、その値はトランスミッタから各他のレシーバまでにおいて獲得される。最後に、各レシーバは、
ＩＣ１．全ての非欠陥レシーバは、同じ値を獲得する
ＩＣ２．トランスミッタが欠陥していない場合、各欠陥していないレシーバは、トランスミッタの値を使用する
ようにトランスミッタによって送信された値に対して決定する。このアルゴリズムは、同期的に終了する。各々に関与しているプロセッサは、同時に合意に達する。

このハートビートアルゴリズムは、値ｖｉのマジョリティがｖに等しい場合、マジョリティ（ｖ１，．．．，ｖｎ−１）がｖに等しくなる特性を用いて１セットの値に適用されたマジョリティ関数を想定する。

実際には、これはこのような関数の順序（ｎの各々に対して１つ）を想定する。マジョリティ値が存在しない場合、マジョリティは０に等しい。

以下の説明では、ｎはプロトコル内で関与しているプロセッサの数とする。ｍは欠陥の数を許容可能にする数とする。ｎ＞＝ｍと仮定する。

（アルゴリズムＨＢ（０））
１．このトランスミッタは、その値を各レシーバに署名かつ送信する
２．各レシーバはその値を使用し、各レシーバはトランスミッタから獲得するか、あるいは、レシーバが値を獲得しないかまたはその値が認証されることができない場合に、値０を使用する
（アルゴリズムＨＢ（ｍ）、ｍ＞０）
１．トランスミッタは、その値を各レシーバに署名かつ送信する
２．各レシーバに対して、ｖｉをトランスミッタから獲得するレシーバｉの値とするか、あるいは、レシーバｉがトランスミッタからの値を獲得しないかまたはその値が認証されることができない場合は０とする。次いでレシーバＩは、アルゴリズムＨＢ（ｍ−１）を用いて値ｖｉをｎ−２の他のレシーバに送信するようためのトランスミッタとして動作する
３．各レシーバに対して、ステップ２において、Ｖｊをレシーバｉから獲得されたレシーバｉの値とするか、あるいは、レシーバがこのような値を獲得しないかまたはその値が認証されることができない場合は０とする。レシーバｉは、マジョリティ（ｖ１，．．．，ｖｎ−１）の値を使用する。

任意のｍに対して、アルゴリズムＨＢ（ｍ）の証明は、以下の参照において見出され得る。

認証符号ａはａ＝Ａｐ［ｄ］であるように、データアイテムｄに対して、プロセッサｐによって構築される。プロセッサｐがその値とｒとを通信する場合、メッセージは、ａ＝Ａｐ［ｖ］である３種類＜ｐ，ａ，ｖ＞からなる。レシーバｒは、そのａ＝Ａｐ［ｖ］をチェックするメッセージを獲得する。実際には、データを適切にランダム化する任意の関数Ａは十分である。なぜなら、カード内の欠陥は、故意のインテリジェンスではないランダムエラーによるものである。「左にシフト」または「右に回転」等の簡単な認証アルゴリズムは、ＰＩＣＯプロセッサの命令セットを保持する場合に選択されるべきである。

ＨＢ（１）のインプリメンテーションは、タイマーを使用して、以下のように外部イベントをアルゴリズムに駆動する。

ステップ０
同期クロック（４．９．２参照）。次いでアルゴリズムを開始するためにタイマーを設定し（ステップ１，Ｃ）、ここで、Ｃ＝アルゴリズム的に決定された所定の日時である。

ステップ１
タイマーポップ。トランスミッタの場合は、値ｖを［（ｎ−１）＝２］の他のプロセッサに署名かつ送信する。レシーバの場合は何もしない。タイマーを設定する（ステップ２、１秒）。

ステップ２
タイマーポップ。レシーバが全て受信されたメッセージを読み出す場合、受信された各メッセージに対して、その署名を確証し、送信された値をメッセージに記録し、そしてメッセージを［（ｎ−１）＝１］の他のプロセッサに署名かつリレーさせる。受信されていないかまたは認証されていない各メッセージに対して、デフォルト値を置換し、リレーメッセージの代わりにデフォルトメッセージを送信する。タイマーを設定する（ステップ３、１秒）
ステップ３
タイマーポップ。リレーされた値を確証する。マジョリティ（ｖ１，．．．，ｖｎ−１）を使用する双方向性一貫性ベクトルを計算する。０である場合、適切な欠陥イベントをフェイルオーバー状態マシンに生成させる。他の場合では、ゼロベクトルおよびタイマーを再度設定する（ステップ１、１秒）。フェーズ間のこの単一の秒の間にプログラム可能であるべきである。

（インプリメンテーションの例）
欠陥ではない場合において、アルゴリズムがどのようにして働くかを理解するために、ｍ＝１、ｎ＝３の場合を考慮する。ＰＰＣ＝パワーＰＣ、ＥＰＰＣ＝埋め込まれたパワーＰＣ、およびＰＣＩＯ＝ネットワークプロセッサとする。図１６は、メッセージ履歴を示す。ＨＢ（１）の第１のステップでは、トランスミッタＰＰＣは、ｖを全てのレシーバｅＰＰＣおよびＰＩＣＯに送信する。第２のステップでは、ｅＰＰＣは、値ｖをＰＩＣＯに送信し、ＰＩＣＯは、簡単なアルゴリズムＨＢ（０）を用いて値をｅＰＰＣに送信する。ステップ３では、ＰＰＣ、ｅＰＰＣ、およびＰＩＣＯの全ては、ａ１＝ａ２＝ａ３＝ｖを有し、これらは全て正確な値ｖ＝マジョリティ（ｖ，ｖ，ｖ）を獲得する。

次に、トランスミッタが故障する場合に起こることを理解する。図１７は、故障プロセッサが値ｘおよびｙを送信する場合のメッセージ履歴を示す。これらは認証されない。各レシーバは、Ｖ１＝ｘまたはｙ、Ｖ２＝０、Ｖ３＝０を獲得し、それによりレシーバの全ては、任意の値ｘおよびｙが等しいかどうかにかかわらず、ステップ（３）において、同じ値のマジョリティ（ｘまたはｙ、０、０）を獲得する。

故障トランスミッタに関連する別のシナリオは、トランスミッタがメッセージを送信する場合に発生する。図１８は、故障プロセッサがメッセージを送信しない場合のメッセージ履歴を示す。各レシーバは、その値がトランスミッタから獲得された場合に値０を使用する。従って、Ｖ１＝０、Ｖ２＝０、Ｖ３＝０であり、それらはステップ（３）において同じ値のマジョリティ（０，０，０）を獲得する。

このアルゴリズムが欠陥レシーバの存在においてどのようにしてアルゴリズムが働くかを理解するために、図１９におけるメッセージ履歴を考慮する。ＨＢ（１）の第１のステップでは、トランスミッタＴ１は、以前のように全てのレシーバにｖを送信する。第２のステップでは、ｅＰＰＣは、簡単なアルゴリズムＨＢ（０）を用いて値ｙをリレーする。ステップ３では、ＰＰＣおよびＰＩＣＯは、Ｖ１＝Ｖ３＝ｖおよびＶ２＝ｙを有し、それらは、正確な値ｖ＝マジョリティ（ｖ，ｖ，ｙ）を獲得する。

図２０に示された次の例は、以前の例に関する変更である。ｅＰＰＣは、Ｔ１の値ｖをリレーする。

（データベースハートビートアルゴリズム）
アービトレータ（ａｒｂｉｔｒａｔｏｒ）およびＪＣＰは、メッセージを介してプロトコルを定期的に交換し、データベースが正確に機能するかどうかを決定する。アービトレータとＪＣＰとの間のストリームが閉じるかまたは破壊される場合、アービトレータは、ＪＣＰ（アービトレータが制御するデータベースと共に）が停止されたことを想定するように権利が与えられる。ハートビートメッセージがいくつかの時間の間に受け取られた場合（すなわち、二倍のハートビート間隔）、アービトレータサービスは、ＪＣＰがデッドであると想定し得る。しかし、このアービトレータは自由であり、ハートビートメッセージを無視するか、またはハートビート間隔を０または非常に大きい値に設定する。

エラーがＪＣＰハートビートにおいて検出される場合、エラーイベントは、エラー解析に対してコンポーネント（ＶＳＣ）上に生成されるべきである。エラー解析は、そのメンバーがフェイルオーバーセットから除去されるべきかどうかを決定するために代替のパスを使用する。

（フレームワークハートビートアルゴリズム）
サービスフレームワークは、サービス間の通信のための場所間でプラットフォームを維持する。ハートビートアルゴリズムであるか、または他の場合では、通信欠陥を検出するための同様なアルゴリズムである。

エラーがサービスフレームハートビートにおいて検出される場合、エラーイベントは、エラー解析のために場所コンポーネント（ＶＳＣまたはＬＣ）上に生成されるべきである。ＶＳＣ場所の欠陥に対して、エラー解析は、メンバーがフェイルオーバーセットから除去されるべきであるかどうかを決定するために、代替の経路を使用する。

（クロック同期化）
双方向的一貫性は、いくつかのエラーのマージン内部で互いに同期化されるプロセッサ保守クロックを必要とする。物理クロックは、完全な時間を保持しない。これらのクロックは、互いに関してドリフトし得る。従って、これらのクロックは、定期的に再同期化されなければならない。

ＶＳＸにおける物理クロックは、同期化されることを必要とする。第１に、リアルタイムクロック（ＲＴＣ）は、ＶＳＸシステム内の各基板上に存在する。第２に、ハードウエアタイマーの妨害を生成するために使用された２つのコンポーネントが各基板自体の内部に存在する。これらのクロックの全ては、双方向性の一貫性が発生するある最大差内に同期化される必要がある。このセクションは、そうするために戦略を議論する。

このクロック同期化アルゴリズムは、以下の仮定を作成する。

１．任意の２つのカード上のリアルタイムクロックの値は、ほとんどの最大クロック差によって各々互いに異なる。

２．この２つのカードは、セクション３．３において説明されたようにＨＡにおける全メンバーである。

（リアルタイムクロック同期）
このアルゴリズムは、最初に、任意の２つのメンバーによって使用されたＲＴＣ値の間の差が最大クロック差の秒数を越えることができないと仮定する。Ｍ１をメンバー＃１およびＭ２をメンバー＃２とする。Ｍ１がプライマリであり、Ｍ２がバックアップであると仮定する。Ｍ１とＭ２との間のリアルタイムクロックを同期化するための方法は、以下のようである。

Ｍ１のクロックを読み出すために、Ｍ２は、両方のメンバーが十分にアクセス可能であり、フェイルオーバーセットがオンラインである後に、クロックリクエストメッセージをＭ１に送信する。Ｍ２は、その現在のＲＴＣ値を用いてこのメッセージに最終的に応答する。次いで、Ｍ１は、２つの値（自身のクロックおよびＭ２のクロック）を利用する。Ｍ１の値がそれ自身の値から最大クロック差より大きい分だけ異なる場合、平均を形成する場合、その値は、自身の値をＭ１のクロック値に置換する。

これがなぜ働くかを理解するために、アルゴリズムを実行する間にエラーが発生しないことを想定する。言い換えると、両方のメンバーは、セクション３．３において説明されたフェイルオーバーセットにおけるフルメンバーでなければならない。メンバーがフェイルオーバーセットから除去される場合、アルゴリズムはアボートされる。

Ｍ１およびＭ２をフェイルオーバーセットにおけるメンバーにさせ、ＣＭ１およびＣＭ２を、そのＲＴＣに対するアルゴリズムの開始において、それぞれＭ１およびＭ２によって使用されたＲＴＣクロック値にする。Ｍ１の観点から、ＣＭ１＝ＣＭ２である場合、（ＣＭ１＋ＣＭ２）／２＝ＣＭ１であり、アルゴリズムが終了する。ＣＭ１＞ＣＭ２またはＣＭ１＜ＣＭ２である場合、（ＣＭ１＋ＣＭ２）／２＝ＣＭ１＋ｎであり（ここで、ｎ＝（ＣＭ１−ＣＭ２）／２）、アルゴリズムが終了する。各連続的な反復のために、ＣＭ１−ＣＭ２）／２だけブロックを互いに近づける。

従って、十分頻繁に再同期化することによって互いの最大ドリフト内で同期化されたクロックを維持し得、それにより、互いの最大クロック差内部に最初に存在するクロックは、最大ドリフト以外のところに離れてドリフトしない。

この同期化アルゴリズムは、ブート同期化の後、そしてその後、２４時間毎に一回等のプログラム可能な間隔において実行され得る。

（チック（ｔｉｃ）カウンター同期化）
チックカウンタの同期化は、ＲＴＣを同期化するよりも簡単なプロセスである。これは、チック値が共有されたメモリで維持されるためである。従って、このチック値がいずれかのプロセッサによって直接読み出され得る。送るためのメッセージは必要ではない。

このアルゴリズムは、ＰＰＣによって使用された最初のチック値と各クロックコンポーネントをプログラムするためのｅＰＰＣとの間の差が同じであり、ドリフト速度が１秒当たりの最大クロック差のチックをすでに越えることができないことを想定する。ＰＰＣおよびｅＰＰＣは、１秒当たり同じ数のチックにおいてチックにプログラムされることが想定される。この最大ドリフトレートは、１／４秒を越えるべきではない。

クロックチックを同期化するためのアルゴリズムは、実質的に以下のとおりである。

１．ｐ＝「他の」プロセッサのチックカウンタ。タイマー（ｑチック）を設定する。

２．タイマーポップ。ｒ＝「他の」プロセッサのチックカウンタ。ｓ＝｜ｒ−ｐ｜
３．最大クロック差＞（ｑ−ｓ）＞最大ドリフトである場合、（ｑ−ｓ）／２だけｔを低減させ、新しいｔを用いてクロックチップを再プログラムする。ここでｔ＝クロックチップをプログラムするために使用されたチック／ｓｅｃの数である。

この働きを理解するために、アルゴリズムを実行する間にエラーが発生し得しないことを想定する。プロセッサがアクティブセットから除去される場合、アルゴリズムは、タイマーをキャンセルすることによってアボートされる（利用不可能なプロセッサを用いてクロックを同期させる必要がない）。

ＨＰおよびＥＰを、それぞれホストプロセッサおよび埋め込まれたプロセッサとし、Ｃ_ＨＰ１およびＣ_ＥＰ１を、そのチックカウンタに対するアルゴリズムの開始においてＨＰおよびＥＰによって使用された値とする。ＨＰ_ｎおよびＥＰ_ｎを、ＤＵＡＲＴチップをプログラムするために使用された、１秒当たりのチックの数とする。Ｃ_ＥＰ２およびＣ_ＨＰ２を、タイマーがポップされる場合のチックカウンタ値とする。

（（Ｃ_ＥＰ２−Ｃ_ＥＰ１）−（Ｃ_ＨＰ２−Ｃ_ＨＰ１））＞最大ドリフトである場合、Ｃ_ＨＰｎ＝Ｃ_ＨＰｎ−（（Ｃ_ＥＰ２−Ｃ_ＥＰ１）−（Ｃ_ＨＰ２−Ｃ_ＨＰ１））である。ＤＵＡＲＴチップチックが、（（Ｃ_ＥＰ２−Ｃ_ＥＰ１）−（Ｃ_ＨＰ２−Ｃ_ＨＰ１））／２だけ低減される周波数の場合、２つのクロックを互いに接近させるとき、アルゴリズムが進む。従って、十分頻繁に再同期化することによって互いの最大ドリフト内で同期化されたクロックを維持し得、それにより、互いの最大クロック差内部に最初に存在するクロックは、最大ドリフト以外のところに離れてドリフトしない。

繰り返された再同期化によって、この再同期化の各々は、クロックを（（Ｃ_ＥＰ２−Ｃ_ＥＰ１）−（Ｃ_ＨＰ２−Ｃ_ＨＰ１））／２だけ互いに接近させ、このアルゴリズムは、任意の所望の同期化の程度を達成し得るように見える。しかし、２つのファクタが無視されている。

１．アルゴリズムを実行するのにかかる時間
２．他のプロセッサのクロックを読み出す際のエラー
クロックが同期化され得る接近性を制限する２つのファクタが存在する。このように、最大ドリフト値は、読み出しクロックのエラーおよびアルゴリズムを実行するのにかかる時間を含まなければならない。

例えば、３秒のフェイルオーバーを有するために、１秒のハートビートを有することを望む。ＤＵＡＲＴを想定することは、６０チック／秒の間プログラムされ、最大ドリフト値は、３０チックで安全に設定され得る。この同期化アルゴリズムは、ブート同期化の後、およびその後２４時間毎に一回で実行され得る。

（ＶＳＸおよびＶＳＣフェイルオーバー）
このセクションは、ＶＳＸボックス間のフェイルオーバーを記載する。以前に言及されたように、ＶＳＸボックス間のフェイルオーバーは、高い利用度がある。それ自体、フェイルオーバーセットの構成要素は、２以上のＶＳＸシャーシまたはスタックにある。この種のフェイルオーバーはまた、高利用度（Ｈｉｇｈ−Ａｖａｉｌａｂｉｌｉｔｙ）（ＨＡ）セットとして知られている。

記述される場合を除き、以下のセクションにおいて概要説明されるステップは、ＶＳＸフェイルオーバーに適合する。

（システム要件）
このセクションは、ＨＡセットを作成する場合の２つのＶＳＸ間の物理的なセットアップを記載する。ＨＡ対構成では、以下のトラフィックタイプが識別される。ＶＳＸ対間のトラフィックは、帯域幅要件にしたがって分類される。

低帯域幅のアプリケーション（Ｌｏｗ Ｂａｎｄｗｉｄｔｈ Ａｐｐｌｉｃａｔｉｏｎｓ）
・サービスフレームワークメッセージ
・データベース更新
・ハートビートメッセージ
高帯域幅のアプリケーション（Ｈｉｇｈ Ｂａｎｄｗｉｄｔｈ Ａｐｐｌｉｃａｔｉｏｎ）
・保存、リリース、リセット、オーダーされたタグ
・キャッシュデータ
・キャッシング
（ＶＳＸとＶＳＸとの接続）
ＨＡセットにおける２つのＶＳＸは、冗長高速相互接続を用いて接続される。インフィニバンド（ｉｎｆｉｎｉＢａｎｄ）、ファイバーチャンネル、またはＧＩＧｅは、この目的にかなう。この相互接続は、各ＶＳＸシャーシ上の解体スイッチ構成を統合する。受信用ＳＰは、一つのスイッチ構成から別のスイッチ構成にメッセージを送るためのリレープロセッサとして作動する。本発明の実施形態では、ファイバーチャンネルは、図２３に示されるように、共用リンク構成において用いられる。

（輸送機構）
Ｉ／Ｏパスは、独自の拡張リンクサービス（ＥＬＳ）コマンドを使用して、メッセージをリモートＳＰに輸送し得る。ＥＬＳは、小量のデータのために高性能パスを提供する。ＥＬＳコマンドのペイロードは、２ｋのデータに制限される。

より大きい輸送に対して、ＳＣＳＩプロトコルが用いられ得る。いずれかの機構は、全ファイバチャンネルのトポロジおよびＳＡＮとＷＡＮとのトポロジにわたって働く。ＳＥＮＤ ＤＩＡＧＮＯＣＳコマンドは、ＶＳＸ間にメッセージを輸送するために用いられる。エラーからの回復は、適切な規格に従う。

インターリンクのいずれかの端部上の各ポートは、発動因子およびターゲットの両方であるように構成される。ネットワーク層におけるディスカバリエージェント（Ｄｉｓｃｏｖｅｒｙ Ａｇｅｎｔ）は、ポートおよびプロセスログインを行う。ＬＵＮ ０のみがサポートされ、それは、管理ＬＵＮになる。コンフルーエンスマネージメント（Ｃｏｎｆｌｕｅｎｃｅ Ｍａｎａｇｅｍｅｎｔ）ＶＬＵＮは、ＳＰへのサービスによって加えられる。Ｓｐは、ＶＳＸを共に接続する。ＳＣＳＩデバイスマネジャー（Ｄｅｖｉｃｅ Ｍａｎａｇｅｒ）は、パートナーＶＳＸからのＳＣＳＩコマンドに応答する。

ＣＮＩ ＶＳＸデバイスに対する標準ＩＮＱＵＩＲＹデータは、以下であるべきである。

コマンドの送信および返答の受信のための完全なプロトコルが、図２４に示されるシーケンス図に示される。

メッセージ通過インターフェースは、リモートＶＳＸポート上のｐＬＵＮへの書き込みと同程度の簡単な様式でインプリメントされ得る。

（フェイルセーフ通信）
ＶＳＸソフトウェアエンティティ間の正常な通信は、共有リンクを通じて生じる。データベーストランザクションはまた、正常な通信のために共有リンクを使用する。共有リンクが失敗する場合、代替のパスがＶＳＸ間の問題を決定するために必要とされる。

ＶＳＸボックス間のさらなる相互接続がエラーリカバリのみのために使用されて、インターリンクフェイラー（ｆａｉｌｕｒｅ）のための正しいリカバリアクションを決定する。データベーストランザクションは、フェイルセーフパスを通じて再ルーティングされず、データベースのリンクは失敗する。代替のインターリンクは、パートナーのＶＳＸが任意であるかを確認するためのみに使用され、インターリンクは、失敗する。別のハートビートパスまたはＶＳＸインターリンクを介するメッセージ通過方法は、将来においてインプリメントされ得る。

フェイルセーフコマンドは、「ＳＥＬＦ−ＴＥＳＴ」オペレーションのみを指定する。このコマンドがエラー解析に送達される場合、インターリンクは、正しいオペレーションのためにテストされる。リンクが動かせるようになっている場合、そのコマンドは、ＧＯＯＤ状態に戻る。リンクが動かせるようになっていない場合、そのコマンドは、ＢＡＤ状態に戻る。そのコマンドがタイムアウトするかまたは他の方法で失敗した場合、ＶＳＸが動かせるようになっていないことおよびその結果のイベントがエラー解析に対して利用可能になされることが想定される。

（フェイルセーフ技術）
このフェイルセーフ接続を提供するために２つの基本的な方法がある。図２５は、管理リンクであり、ＶＳＸを一緒に接続するために各ＶＳＸからの管理ポートを使用する。図２６は、共有ディスクであり、格納デバイスがデュアルポート機能である２つのＶＳＸ間でのみ作用し得る。

（管理リンクアプローチ）
各ＶＳＣカードは、管理のためにイーサネット（Ｒ）ポートに備えられるべきである。サービスフレームワークによって確立された論理的ＴＣＰ接続は、２つのＶＳＸを接続する物理的なリンクの一つの損失によって影響されないままであるべきである。完全な冗長相互接続は、２つのイーサネット（Ｒ）ポートおよびスイッチ、２つのイーサネット（Ｒ）スイッチおよび２つの独立のパスを利用する。

（共有ディスクアプローチ）
共有ディスクアプローチは、ＶＳＸシステム間にメッセージを通すために用いられるＲＥＡＤ ＢＵＦＦＥＲおよびＷＲＩＴＥ ＢＵＦＦＥＲコマンドを使用する。各ＶＳＸ上のソフトウェアエンティティは、入来するメッセージに対して一致するデバイス位置をポーリングする。メッセージが見出される場合、それは、宛先エンティティに送達される。この宛先エンティティは、次いで、イーサネット（Ｒ）リンク状態が決定されるようにさせる。イーサネット（Ｒ）リンク状態は、共有ディスクに書き込まれる。他のＶＳＸ上のポーリングエンティティは、イーサネット（Ｒ）状態を検索し、それをエラー解析に広める。プロトコルが図２７に示される配列に示される。

以下のテーブルは、２つのアプローチを要約する。管理リンクは、より拡張性があり、より柔軟性がある。共有ディスクは、デュアルポート格納を使用することを必要とする。

（ノードネーム（Ｎｏｄｅ Ｎａｍｅ）およびポートネーム（Ｐｏｒｔ Ｎａｍｅ））
ＨＡ Ｓｅｔ ＷＷＮは、そのメンバー（Ｍｅｍｂｅｒ）のＷＷＮの一つから選択される。これは、ＨＡ Ｓｅｔが論理的に一つのノードであるからである。ＨＡ Ｓｅｔにおけるすべてのポートは、それらのポート構成において同一のノードネーム（Ｎｏｄｅ Ｎａｍｅ）を使用すべきである。ＨＡ Ｓｅｔを作成する場合、ＦＣ ＰｏｒｔのＰＬＯＧＩ情報は、ノードネーム（Ｎｏｄｅ Ｎａｍｅ）としてのＨＡ Ｓｅｔ ＷＷＮを用いて再プログラミングされるために必要とされる。

（ＶＳＸ ＨＡ構成（Ｃｏｎｆｉｇｕｒａｔｉｏｎ））
このセクションは、図２８〜３１に示されるいくつかのＨＡ構成を記載する。以前に言及されたように、ＨＡ Ｓｅｔは、特別な種類のフェイルオーバー（Ｆａｉｌｏｖｅｒ）セットである。ＨＡ Ｓｅｔは、ＶＳＸの論理的な組み合わせから、または、他のフェイルオーバー（Ｆａｉｌｏｖｅｒ Ｓｅｔ）から作成される。

（ＨＡ構成（Ｃｏｎｆｉｇｕｒａｔｉｏｎ）上の制約（Ｃｏｎｓｔｒａｉｎｔ））
サポートされたＨＡ構成の数についての制限は、以下の通りである。

１．ポートネーム（Ｐｏｒｔ Ｎａｍｅ）制限−各ポートは、ＨＡ Ｓｅｔであり、標準に特定化されたＰｏｒｔ Ｎａｍｅ ＩＥＥＥ Ｅｘｔｅｎｄｅｄフォーマットを使用する。これは、ノードあたり４０９６ポートをサポートする。各ＨＡ Ｓｅｔが１ノードとして提示される場合、制限は、４０９６ポートである。３２のポートボックスに対して、これは、１２８ボックスの制限である。

２．通過するメッセージ数およびサービスフレームワーク（Ｓｅｒｖｉｃｅｓ Ｆｒａｍｅｗｏｒｋ）が位置間でサポートするハートビート「接続」についての制限がある。３つのカードＶＳＸに対して、６つの接続が要求される。２３カードのＶＳＸに対しては、それは３０接続である。

３．サイズ制限−データベースは、インメモリ（ｉｎ−ｍｅｍｏｒｙ）データベースである。データベースのサイズは、どれだかの量のメインメモリがカード上にあるかによって限定される。

４．レプリカ制限−データベースのソフトウェアは、データベースレプリカの数についての制限を有し得る。

５．複数インスタンス制限−単一のプロセッサ上でサポートされるデータベースの数についての限定があり得る。

これらの制限が与えられて、以下のセクションは、いくつかのＨＡ構成を提示する。これは、それほど遠くない将来において実行可能に思われる。

最も一般的な構成であるＮ−Ｎｏｄｅが最初に設計するように促される。これは、２−Ｎｏｄｅおよび４−ＮｏｄｅがＮ−Ｎｏｄｅの特別な場合であるからである。階層的な構成がＮ−Ｎｏｄｅが完了した後に設計され得る。

（２−Ｎｏｄｅ ＨＡ構成）
図２８に示される２−ノードの接続形態（ｔｏｐｏｌｏｇｙ）は、ＶＳＸがパートナー対で構成されることを要求する。全ての記憶装置（ｓｔｒａｇｅ）は、両方のＶＳＸに接続される。一つのみのＶＳＣが、ＶＳＸ内に存在する。フェイルオーバーは、パートナー間でのみ可能である。一方のＶＳＸはプライマリＶＳＸとして機能し、他方のＶＳＸはＢａｃｋｕｐとして機能する。失敗の数は、ｔ＝１である。

（２−Ｎｏｄｅ階層）
図２９に示される階層的な接続形態は、ＶＳＸが対で構成されることを要求する。ＶＳＸ自体は、２つのＶＳＣを含む。１つのＶＳＣは、プライマリであり、一つのＶＳＣは、バックアップであり、他の２つのＶＳＣは、代替（Ａｌｔｅｒｎａｔｅ）である。失敗の数は、ｔ＝１である。

（４Ｎｏｄｅ ＨＡ構成）
この構成は、２、３、または４ノード組織化をサポートし得る。全記憶装置は、厳密にすべてのノードに物理的に接続される。一つのみのＶＳＣがＶＳＸ内に存在する。単一のＶＳＸはバックアップとして設計され、単一のＶＳＸはプライマリ（Ｐｒｉｍａｒｙ）として設計される。全ての他のＶＳＸは、代替（Ａｌｔｅｒｎａｔｅ）と考えられる。フェイルオーバーカスケーディングがこの構成において可能である。失敗の数は、ｔ＝３である。

（ＶＳＸ Ｎ Ｎｏｄｅ）
この構成では、全ての格納装置がＨＡ構成（Ｃｏｎｆｉｇｕｌａｔｉｏｎ）内の全てのＶＳＸにアクセス可能である。接続形態は、スイッチを用いて構築され得る。一つのみのＶＳＣがＶＳＸ内に存在する。全てのＶＳＸは、データベースにアクセスする。フェイルオーバーは、ＨＡ構成（Ｃｏｎｆｉｇｕｌａｔｉｏｎ）においてあるノードから任意の他のノードに発生し得る。ＶＳＸが別のＶＳＸにフェイルオーバーし、その後、ＨＡ Ｓｅｔサイズが１になるまで別のＶＳＸにフェイルオーバーする、カスケーディングフェイルオーバーを構成することも可能である。失敗の数は、ｔ＝ｎ−１である。

（ＨＡ Ｓｅｔへの記憶装置の支援）
１より多いＨＡセットをＳＡＮに有することが可能である。例えば、Ｎ＝１０とおくと、Ｎ−Ｎｏｄｅ構成は、２つの５−Ｎｏｄｅ ＨＡ Ｓｅｔに分割され得る。記憶装置が両方のＨＡ Ｓｅｔに物理的に接続される場合、所与のＨＡ Ｓｅｔに対する排他的な使用のために支援されることが必要である。他の場合には、いくつかの潜在的なデータ腐敗（ｃｏｒｒｕｐｔｉｏｎ）がある。

記憶装置が物理的レベルにおいてＨＡ Ｓｅｔ間で分割されると、ユーザは、それぞれの発見された格納デバイスに対してＨＡ Ｓｅｔ ＩＤを割り当て得、多くの同じ方法において、ユーザのドメインが、格納デバイスに対して割り当てられる。次いで、管理サーバは、その構成における所与のＨＡ Ｓｅｔによって「所有された」デバイスのリストを分散させるために用いられ得る。

実施形態において、スイッチレベルのポートゾーニング（ｐｏｒｔ ｚｏｉｎｇ）またはＬＵＮマスキングが、ＨＡ Ｓｅｔ記憶装置を隔離するために用いられ得る
（調整的アクション）
このセクションは、ある種のキーメンバー（Ｍｅｍｂｅｒ）状態機構イベント用に利用するための工程をリストする。これらのアクションはにフェイルオーバーサービス（Ｆａｉｌｏｖｅｒ Ｓｅｒｖｉｃｅ）によってすべて利用されるのではなく、全体のＶＳＸから要求されるアクションを表わすことに留意することは重要である。

留意：以下のアルゴリズムでは、メンバー（Ｍｅｍｂｅｒ）が２つのＬＣおよび１つのＶＳＣから作成されるＶＳＸである場合、ＶＳＣフェイルオーバーサービス（Ｆａｉｌｏｖｅｒ Ｓｅｒｖｉｃｅ）およびＬＣフェイルオーバーサービス（Ｆａｉｌｏｖｅｒ Ｓｅｒｖｉｃｅ）の両方が、メンバー（Ｍｅｍｂｅｒ）のアクションを実行する。例えば、「プライマリフェイル（Ｐｒｉｍａｒｙ Ｆａｉｌ）」は、「ＦＣポート（Ｐｏｒｔ）がオフィスに行く」を呼び出す。ＶＳＣおよびＬＣフェイルオーバー（Ｆａｉｌｏｖｅｒ）サービスは、双方とも、ＦＣポート（Ｐｏｒｔ）オフィスを押すことを起動する。

（プライマリフェイル）
図３２を参照して、プライマリ（Ｐｒｉｍａｒｙ）フェイルの場合、本発明の実施形態により以下が生じる。

プライマリ（Ｐｒｉｍａｒｙ）フェイルの場合、プライマリ（Ｐｒｉｍａｒｙ）は、以下のアクションを実行する。

１．フェイルイベントを検証する。

２．フェイル理由コードを記録する。

３．可能であれば、フェイルストップする。

ａ．ＪＣＰを不活性にする。

ｂ．ＦＣポートがオフィスに行く。

プライマリ（Ｐｒｉｍａｒｙ）フェイルが失敗した場合、バックアップ（Ｂａｃｋｕｐ）は、以下のアクションを実行する。

１．進行中のフェイルオーバーを記録する。

２．フェイルオーバー試行の数を記録する。

３．試行の数が閾値を超える場合には、フェイルストップする。

４．マスター（Ｍａｓｔｅｒ）モード内のＪＣＰを活性にする。

５．新しい位置上の全てのバーチャルサービス（Ｖｉｒｔｕａｌ Ｓｅｒｖｉｃｅ）をイネーブルする。

６．フェイルオーバーによって影響されるダウンストリームデバイスをリセットする。

７．影響されたデバイス用のリザーブ／リリース（Ｒｅｓｅｒｖｅ／Ｒｅｌｅａｓｅ）をクリーンアップする。

ａ．アップストリーム−クリアなアップストリーム留保（ｒｅｓｅｒｖａｔｉｏｎ）。

ｂ．ダウンストリーム−リセットが留保をクリアにする。

８．影響されたデバイス用のパーシステントリザベーション（Ｐｅｒｓｉｓｔｅｎｔ Ｒｅｓｅｒｖａｔｉｏｎ）をクリーンアップする。

ａ．アップストリーム−プレエンプト（Ｐｒｅｅｍｐｔ）およびクリア（Ｃｌｅａｒ）サービスアクション。

ｂ．ダウンストリーム−プレエンプト（Ｐｒｅｅｍｐｔ）およびクリア（Ｃｌｅａｒ）サービスアクションを用いる。

９．影響されたデバイス用にスパンライト（Ｓｐａｎ Ｗｒｉｔｅ）ロックをクリーンアップする。

１０．全ての影響されたデュアルポートされたｖＬＵＮが、ｈＬＵＮ（０×２９）上にパワーオンリセット（Ｐｏｗｅｒ−ｏｎ Ｒｅｓｅｔ）状態を有するユニットの注意を設定する。

１１．任意の管理要求を再スタートさせる。

１２．再構築またはフォーマット等の長い実行オペレーションを再スタートさせる。

１３．成功したフェイルオーバーを記録する。

１４．メンバー（Ｍｅｍｂｅｒ）状態を更新する。

１５．新しいバックアップ（Ｂａｃｋｕｐ）を選択する。

ａ．他のバックアップ（Ｂａｃｋｕｐ）が存在しない場合、「Ｆａｉｌｏｖｅｒ Ｄｉｓａｂｌｅｄ」を生成する。

プライマリ（Ｐｒｉｍａｒｙ）が失敗した場合、代替（Ａｌｔｅｒｎａｔｅ）が以下のアクションを実行する。

１．選択された場合、バックアップ（Ｂａｃｋｕｐ）のために再構成する。

ａ．スタンバイ（Ｓｔａｎｄｂｙ）モード内のＪＣＰを活性にする。

２．「Ｃｏｎｆｉｇｕｒｅｄ ｆｏｒ Ｂａｃｋｕｐ」を生成する。

３．メンバー（Ｍｅｍｂｅｒ）状態を更新する。

（バックアップフェイル）
バックアップ（Ｂａｃｋｕｐ）が失敗する場合、プライマリ（Ｐｒｉｍａｒｙ）は、以下のアクションを実行する。

１．ＪＣＰにスタンバイデータベースが失敗したことを知らせる。

２．新しいバックアップ（Ｂａｃｋｕｐ）を選択する。

ａ．他のバックアップ（Ｂａｃｋｕｐ）が存在しない場合、「Ｆａｉｌｏｖｅｒ Ｄｉｓａｂｌｅｄ」を生成する。

バックアップ（Ｂａｃｋｕｐ）が失敗した場合、バックアップ（Ｂａｃｋｕｐ）は、以下のアクションを実行する。

１．フェイルイベントを検証する。

２．フェイル理由コードを記録する。

３．可能であればフェイルストップする。

ａ．ＪＣＰを不活性にする。

ｂ．ＦＣポート（Ｐｏｒｔ）オフラインを進む。

バックアップ（Ｂａｃｋｕｐ）が失敗した場合、代替（Ａｌｔｅｒｎｅｔｅ）は、以下のアクションを実行する。

１．選択される場合、バックアップ（Ｂａｃｋｕｐ）のために再構成する。

ａ．スタンバイ（Ｓｔａｎｄｂｙ）モードにおいてＪＣＰを活性にする。

２．「Ｃｏｎｆｉｇｕｒｅｄ ｆｏｒ Ｂａｃｋｕｐ」を生成する。

３．メンバー（Ｍｅｍｂｅｒ）状態を更新する。

（代替フェイル）
代替（Ａｌｔｅｒｎａｔｅ）が失敗する場合、プライマリ（Ｐｒｉｍａｒｙ）は以下のアクションを実行する。

１．アクション不必要。

代替（Ａｌｔｅｒｎａｔｅ）が失敗する場合、バックアップ（Ｂａｃｋｕｐ）は、以下のアクションを実行する。

１．失敗した代替（Ａｌｔｅｒｎａｔｅ）に複製（Ｒｅｐｌｉｃａｔｉｎｇ）を停止させる。

代替（Ａｌｔｅｒｎａｔｅ）が失敗した場合、代替（Ａｌｔｅｒｎａｔｅ）は、以下のアクションを実行する。

１．失敗イベントを検証する。

２．失敗理由コードを記録する。

３．可能であればフェイルストップする。

ａ．ＪＣＰを不活性にする。

ｂ．ＦＣポート（Ｐｏｒｔ）は、オフィスに行く。

（バックアップ（Ｂａｃｋｕｐ）のための構成）
バックアップ（Ｂａｃｋｕｐ）が構成される場合、プライマリ（Ｐｒｉｍａｒｙ）は、以下のアクションを実行する。

１．スタンバイデータベースが活性化されることをＪＣＰに知らせる。

２．クロックをバックアップと同調させる。

３．「Ｆａｉｌｏｖｅｒ ｅｎａｂｌｅｄ」を生成する。

バックアップ（Ｂａｃｋｕｐ）が構成されるとき、バックアップ（Ｂａｃｋｕｐ）は、以下のアクションを実行する。

１．スタンバイモードにおいてＪＣＰを活性にする。これは、バックアップ（Ｂａｃｋｕｐ）にデータベースおよび履歴ファイルをコピーする。

２．データベースからのＩＰアドレスのようなサイト固有のデータベース情報を新しいＭｅｍｂｅｒに移動させる。

３．メンバー（Ｍｅｍｂｅｒ）状態を更新する。

バックアップ（Ｂａｃｋｕｐ）が構成されるとき、代替（Ａｌｔｅｒｎｅｔｅ）は、以下のアクションを実行する。

１．バックアップ（Ｂａｃｋｕｐ）が失敗した場合に、選択するために次のバックアップ（Ｂａｃｋｕｐ）を決定する。

（イレクティブフェイルオーバー（Ｅｌｅｃｔｉｖｅ Ｆａｉｌｏｖｅｒ））
このセクションは、整然としてサービスからのＨＡ Ｓｅｔのメンバーを除去するために用いられる方法およびアルゴリズムを詳述する。

（逸脱プライマリ（Ｐｒｉｍａｒｙ））
プライマリ（Ｐｒｉｍａｒｙ）が除去される場合、プライマリ（Ｐｒｉｍａｒｙ）は、以下のアクションを実行する。

１．プライマリ（Ｐｒｉｍａｒｙ）を含む全てのマネージメント（Ｍａｎａｇｅｍｅｎｔ）要求を静止させる。

２．再構成またはフォーマットおよび任意の他の内部ＩＯ等のプライマリ（Ｐｒｉｍａｒｙ）上の全ての長い実行プロセスを停止させる。

３．プライマリ（Ｐｒｉｍａｒｙ）上のＦＣポート（Ｐｏｒｔ）を静止させる。これは、全てのホストＩＯをランダウンさせる。

４．ＦＣポート（Ｐｏｒｔ）をオフィスに行かせる。

５．全てのｖＬＵＮをイクスポート停止する。

６．全てのバーチャルサービス（Ｖｉｒｔｕａｌ Ｓｅｒｖｉｃｅ）をディセーブルする。

７．ＪＣＰを不活性にする。

８．メンバー（Ｍｅｍｂｅｒ）状態を更新する。

プライマリ（Ｐｒｉｍａｒｙ）が除去される場合、バックアップ（Ｂａｃｋｕｐ）は、以下のアクションを実行する。

１．ＪＣＰをアクティブ（Ａｃｔｉｖｅ）モードにスイッチする。

２．全てのバーチャルサービス（Ｖｉｒｔｕａｌ Ｓｅｒｖｉｃｅ）をイネーブルする。

３．新しいバックアップ（Ｂａｃｋｕｐ）を選択する。

ａ．バックアップ（Ｂａｃｋｕｐ）が存在しない場合、「Ｆａｉｌｏｖｅｒ Ｄｉｓａｂｌｅｄ」を生成する。

４．メンバー（Ｍｅｍｂｅｒ）状態を更新する。

プライマリ（Ｐｒｉｍａｒｙ）が除去される場合、代替（Ａｌｔｅｒｎａｔｅ）は、以下のアクションを実行する。

１．選択された場合バックアップ（Ｂａｃｋｕｐ）のために再構成する。

ａ．スタンバイ（Ｓｔａｎｄｂｙ）モードにおいてＪＣＢを活性にする。

２．「ｃｏｎｆｉｇｕｒｅｄ ｆｏｒ Ｂａｃｋｕｐ」を生成する。

３．メンバー（Ｍｅｍｂｅｒ）状態を更新する。

（バックアップの逸脱）
バックアップ（Ｂａｃｋｕｐ）が除去される場合、プライマリ（Ｐｒｉｍａｒｙ）は、以下のアクションを実行する。

１．スタンバイデータベースが失敗したことをＪＣＰに知らせる。

２．新しいバックアップ（Ｂａｃｋｕｐ）を選択する。

ａ．他のバックアップ（Ｂａｃｋｕｐ）が存在しない場合、「Ｆａｉｌｏｖｅｒ Ｄｉｓａｂｌｅｄ」を生成する。

バックアップ（Ｂａｃｋｕｐ）が除去される場合、バックアップ（Ｂａｃｋｕｐ）は、以下のアクションを実行する。

１．バックアップ（Ｂａｃｋｕｐ）を含む全てのマネージメント（Ｍａｎａｇｅｍｅｎｔ）要求を静止させる。

２．フォーマットおよび任意の他の内部ＩＯの再構築等のバックアップ（Ｂａｃｋｕｐ）上の全ての長い走行プロセスを停止させる。

３．バックアップ（Ｂａｃｋｕｐ）上のＦＣポート（Ｐｏｒｔ）を静止させる。これは、全てのホストＩＯをランダウンするべきである。

４．ＦＣポート（Ｐｏｒｔ）をオフィスに行かせる。

５．全てのｖＬＵＮをイクスポート停止する。

６．ＪＣＰを不活性にする。

７．メンバー（Ｍｅｍｂｅｒ）状態を更新する。

バックアップ（Ｂａｃｋｕｐ）が除去される場合、代替（Ａｌｔｅｒｎａｔｅ）は、以下のアクションを実行する。

１．選択された場合バックアップ（Ｂａｃｋｕｐ）のために再構成する。

ａ．スタンバイ（Ｓｔａｎｄｂｙ）モードにおいてＪＣＰを活性化する。

２．「ｃｏｎｆｉｇｕｒｅｄ ｆｏｒ Ｂａｃｋｕｐ」を生成する。

３．メンバー（Ｍｅｍｂｅｒ）状態を更新する。

（代替の逸脱）
代替（Ａｌｔｅｒｎａｔｅ）が除去される場合、プライマリ（Ｐｒｉｍａｒｙ）は、以下のアクションを実行する。

１．アクション不必要
代替（Ａｌｔｅｒｎａｔｅ）が除去される場合、バックアップ（Ｂａｃｋｕｐ）は、以下のアクションを実行する。

１．失敗した代替（Ａｌｔｅｒｎａｔｅ）への複製（Ｒｅｐｌｉｃａｔｉｎｇ）を停止する。

代替（Ａｌｔｅｒｎａｔｅ）が除去される場合、代替（Ａｌｔｅｒｎａｔｅ）は、以下のアクションを実行する。

１．代替（Ａｌｔｅｒｎａｔｅ）を含む全てのマネージメント（Ｍａｎａｇｅｍｅｎｔ）要求を静止させる。

２．再構成またはフォーマットおよび代替（Ａｌｔｅｒｎａｔｅ）を含む任意の他の内部ＩＯ等の全ての長い走行プロセスを停止させる。

３．代替（Ａｌｔｅｒｎａｔｅ）上のＦＣポート（Ｐｏｒｔ）を静止させる。これは、全てのホストＩＯをランダウンするべきである。

４．ＦＣポート（Ｐｏｒｔ）をオフィスに行かせる。

５．全てのｖＬＵＮをイクスポート停止する。

６．ＪＣＰを不活性にする。

７．メンバー（Ｍｅｍｂｅｒ）状態を更新する。

（フェイルストップポリシー）
一般に、ＨＡ Ｓｅｔが寛容であり得る持続性の失敗の数は、ｎ−１である。ここで、ｎは、ＨＡ Ｓｅｔにおけるメンバーの数である。ｎ個の失敗のイベントでは、ＨＡ Ｓｅｔは、正しく動作させるためにもはや信頼され得ない。ポリシーは、失敗し、その後停止することであるべきである。

２−Ｗａｙ ＨＡ Ｓｅｔでは、プライマリ（Ｐｒｉｍａｒｙ）ＶＳＸが失敗した場合、バックアップ（Ｂａｃｋｕｐ）ＶＳＸは、構成の制御を引き継ぐ。新しいプライマリ（Ｐｒｉｍａｒｙ）ＶＳＸがその後に失敗すると、冗長性制限が超えられる。ＶＳＸ失敗を構成するものは、エラー分析（Ｅｒｒｏｒ Ａｎａｌｙｓｉｓ）の対象である。いくつかの考えがその中に言及される。

Ｆａｉｌ−Ｓｔｏｐプロセシングは、エラーおよびどんな性能がＶＳＸ上に残るのかの正確な性質に部分的に依存する。以下の目的は、可能なリカバリーアクションを考慮する場合のガイドラインとして機能すべきである。

１．最初のリスポンシビリティは、ホスト（Ｈｏｓｔ）に対してである。外部のインターフェイスは、オフィスに置かれるべきである。チェック状態が、全ての顕著なＩＯおよび任意のＩＯリクエスト上で報告されるべきである。

２．データベースは、ディスクにコミットされるべきである。進行中のトランザクションは、ロールバックされるべきである。データベースに対する変更は、防止されるべきである。

３．全てのトレースおよびログが、持続性の記憶装置にコミットされるべきである。

４．ＧＵＩは、重大な状態を反映するべきである。

（ＩＯパスフェイルオーバ）
前述されたように、フェイルオーバは、冗長的なコンポーネントがサービスから取り除かれる場合に行われる回復動作である。前述の節は、ＶＳＸ間のフェイルオーバ、ある程度までは、ＶＳＣ間のフェイルオーバを議論した。この節は、ラインカード、ＳＰまたはＡＳＩＣおよびＦＣ ポート間のフェイルオーバを提示する。

技術的に言えば、実際、フェイルオーバは、ラインカード、ＳＰまたはＡＳＩＣ間で直接には生じない。しかし、フェイルオーバは、上記のコンポーネントと関連付けられたポートを用いて実行するＩＯリクエストを介して間接的に生じる。上記のコンポーネントのそれぞれは、（すなわち１以上の）ポートの集合としてみなされ得る。ポートが「共通のデノミネータ（ｄｅｎｏｍｉｎａｔｏｒ）」であるので、ＬＣフェイルオーバ、ＳＰフェイルオーバ、ＦＣ ＡＳＩＣフェイルオーバおよびＦＣポートフェイルオーバは、全て同じようにみなされ得る。１以上のポートフェイルオーバ。いくつかのマルチポートポリシーを用いて、上記のコンポーネントを用いずにフェイルオーバを行うことがＩＯリクエストである。この種のフェイルオーバはマルチパシング（ｍｕｌｔｉ−ｐａｔｈｉｎｇ）と呼ばれる場合が多い。

二つの基礎タイプのマルチパシング、アクティブ−パッシブおよびアクティブ−アクティブがある。アクティブ−パッシブマルチパッシングは、イニシエータに、任意の時間に、ストレージデバイスに対して一つのパスのみを用いることを要求する。アクティブ−パッシブマルチパッシングは、Ｐｒｅｆｅｒｒｅｄ Ｐａｔｈと呼ばれる場合が多い。アクティブ−アクティブマルチパッシングは、イニシエータを制限することは決してしない。イニシエータは、ストレージデバイスへのどちらかの（ｅｉｔｈｅｒ）パスを用いて同時発生のＩＯリクエストを送り得る。

マルチパッシングを用いて、ラインカード、ストレージプロセッサ、ＦＣ ＡＳＩＣまたはＦＣポートがサービスから取り除かれる場合にＶＳＸ全体を落とす（ｆａｉｌ）必要はない。実際、ＶＳＸ全体を落とすことは全く望まれていない。例えば、ケーブルがＶＳＸとダウンストリームデバイスとの間で取り除かれるだけで、どうしてＶＳＸ全体がフェイルオーバするのか？
一般には、マルチパッシングを支援するために、要求されることの全ては以下の通りである。

１．イニシエータは、ストレージデバイスへのＩＯパスグループについて知らなければならない。

ａ．これは、動的な発見（ｄｙｎａｍｉｃ ｄｉｓｃｏｖｅｒｙ）を介して為され得る。

ｂ．これはまた、ユーザ供給静的テーブル（ｕｓｅｒ−ｓｕｐｐｌｉｅｄ ｓｔａｔｉｃ ｔａｂｌｅ）について為され得る。

２．イニシエータは、パスエラーを検出できなければならない。

３．イニシエータは、落とされたパス（ｆａｉｌｅｄ ｐａｔｈ）を不活性にでき、冗長なパスを活性化にでき、パッシブパスを活性化するために、ベンダーユニークなコマンドを用いることを要求する場合でさえ、新しく活性化されたパスにＩＯリクエストを再発行できなければならない。

４．イニシエータは、落とされたパスをモニタリングし、落とされたパスが修復されると、このパスを再統合する。

ＶＳＸにおいて、イニシエータは、内部的または外部的であり得る。ポートが落ちる時の当面の主なタスクは、ＶＳＸソフトウェアがパス障害（ｆａｉｌｕｒｅ）についてイニシエータに知らせることである。

（パス障害）
ＬＣ、ＳＰ、ＦＣ ＡＳＩＣおよびＦＣ ポート障害は、以下のアルゴリズムを用いて取り扱われ得る。

アルゴリズム１：アップストリームポート障害アルゴリズム
１．可能な場合、ポートをオフラインにする
２．不可能な場合、ポートを再初期化する
３．再初期化が作用しない場合、ポートをリセットする
アルゴリズム２：ダウンストリームポート障害アルゴリズム
１．落とされたポートに付加された任意のデバイスに対する任意の内部ＩＯをアボートする。内部ＩＯを初期化するサービスは、代替的なパス上にＩＯリクエストを再発行する。

２．全ての影響されるアップストリームｈＬＵＮにＣＨＥＣＫ ＣＯＮＤＩＴＩＯＮを設定する。アップストリームｈＬＵＮは落とされたポートに付加されたダウンストリームｐＬＵＮを有する。

４．可能な場合、落とされたポートをオフラインにする。

ＡＳＩＣが落ちる場合、
１．ＡＳＩＣ上のそれぞれのアップストリームポートに対して、
ａ．アルゴリズム１を実行する
２．ＡＳＩＣ上のそれぞれのダウンストリームに対して、
ａ．アルゴリズム２を実行する
ＳＰが落ちる場合、
２．ＳＰ上のそれぞれのアップストリームポートに対して、
ａ．アルゴリズム１を実行する
３．ＳＰ上のそれぞれのダウンストリームポートに対して、
ａ．アルゴリズム２を実行する
Ｌｉｎｅ Ｃａｒｄが落ちる場合、
４．ＬＣ上のそれぞれのＳＰに対して、
ａ．ＳＰ上のそれぞれのアップストリームポートに対して、
ｉ．アルゴリズム１を実行する
ｂ．ＳＰ上のそれぞれのダウンストリームポートに対して、
ｉ．アルゴリズム２を実行する
図３３〜３５は、様々なＩＯパスフェイルオーバシナリオを例示する。

図１は、本発明の実施形態に従った、エラー回復アーキテクチャのハイレベル図を示す。 図２は、ノンフォルトトレラント構成の一般的なブロック図を示す。 図３は、本発明の実施形態に従った、フォルトトレラント構成の一般的なブロック図を示す。 本発明の実施形態に従った、高可溶性構成の一般的なブロック図を示す。 図５は、フェイルオーバーセットのコンポーネントを示す。 図６は、メンバユニット状態遷移図を示す。 図７は、フェイルオーバーセットを生成するための本発明の実施形態に従った、典型的な処理を示す。 図８は、メンバ状態図を示す。 図９は、コールドブートのための調停シーケンスを示す。 図１０は、ウォームブートのための調停シーケンスを示す。 図１１は、混成ブートのための調停シーケンスを示す。 図１２は、本発明の実施形態に従った、２つのメンバの状態遷移図を示す。 図１３は、図１２の状態遷移図の作用である。 図１４は、ｓｅｒｖｅｄフェイルオーバーセットのステートチャート図を示す。 図１５は、本発明の実施形態に従った、フォルト検出および分析の一般的なブロック図を示す。 図１６は、フォルトのない状況でのハートビートアルゴリズムの例を示す。 図１７は、送信側フォルト状況でのハートビートアルゴリズムの例を示す。 図１８は、他の送信側フォルト状況でのハートビートアルゴリズムの例を示す。 図１９は、受信者側フォルト状況でのハートビートアルゴリズムの例を示す。 図２０は、受信者側フォルト状況でのハートビートアルゴリズムの例を示す。 図２１Ａは、本発明の実施形態に従った、フェイルオーバーサービスアーキテクチャの一般的なブロック図を示す。 図２１Ｂは、サービスフレームワーク処理の一般的なブロック図を示す。 図２２は、データベースの決定者のための一般的なブロック図を示す。 図２３は、シェアリンク構成を示す。 図２４は、本発明の実施形態に従った、ＶＳＸ間の典型的なメッセージのやりとりを示す。 図２５は、管理リンク構成を示す。 図２６は、シェアディスク構成を示す。 図２７は、本発明の実施形態に従うシェアディスクを利用したＶＳＸ間の典型的なメッセージのやりとりを示す。 図２８は、ノードハブアダプタ構成を示す。 図２９は、階層ハブアダプタ構成を示す。 図３０は、Ｎ＋１ノード構成を示す。 図３１は、Ｎノード構成を示す。 図３２は、本発明の実施形態に従った、障害の発生したプライマリの典型的なフェイルオーバー処理を示す。 図３３は、本発明の実施形態に従った、障害の発生したＬＣの典型的なフェイルオーバー処理を示す。 図３４は、本発明の実施形態に従った、障害の発生したファイバチャネル（ＦＣ）の典型的なフェイルオーバー処理を示す。 図３５は、本発明の実施形態に従った、接続がダウンした状況下での典型的なフェイルオーバー処理を示す。 図３６は、本発明の実施形態に従った、ストレージサーバシステムのハイレベルシステムアーキテクチャを示す。 図３６Ａは、本発明の実施形態に従った、ストレージサーバシステムの典型的な構成を示す。 図３６Ｂは、本発明の実施形態に従った、ストレージサーバシステムの典型的な構成を示す。 図３６Ｃは、本発明の実施形態に従った、ストレージサーバシステムの典型的な構成を示す。 図３６Ｄは、本発明の実施形態に従った、ストレージサーバシステムの典型的な構成を示す。 図３７は、図３６のコンポーネントの付加的な詳細を示す。

Claims (10)

1. 複数のネットワーク化されたストレージシステムの間でフェイルオーバをサポートする方法であって、該複数のネットワーク化されたストレージシステムは、第１のストレージシステムと第２のストレージシステムと１つ以上のストレージシステムのセットとの間で接続されており、複数の冗長ネットワークリンクが、該複数のネットワーク化されたストレージシステムの間で用いられ、
   該方法は、
   複数のプロセッサと複数のカードと複数のストレージシステムとによって共有される単一のソフトウェア環境を提供することであって、該複数のストレージシステムは、該複数のプロセッサと該複数のカードとを含む、ことと、
   スタンダードプロトコルを用いて、フェイルオーバセットの複数のメンバー候補を識別することであって、該フェイルオーバセットの該複数のメンバー候補は、ストレージシステム内の個々のコンポーネントと、該ストレージシステム内のコンポーネントの階層とを含む、ことと、
   複数のフェイルオーバセットを作成することであって、該複数のフェイルオーバセットのそれぞれは、該複数のメンバー候補のうちの１つ以上を含む、ことと、
   該複数のフェイルオーバセットの該複数のメンバー候補のコンフィギュレーションを少なくとも１つの冗長データベースに格納するためにマスターデータベースを用い、ハートビートを有するジャーナルコントロールプロセスを用いて、該マスターデータベース内の該複数のフェイルオーバセットの該複数のメンバー候補のコンフィギュレーションと該少なくとも１つの冗長データベース内の該複数のフェイルオーバセットの該複数のメンバー候補のコンフィギュレーションとを同期させることと、
   各フェイルオーバセットに対して、該複数のメンバー候補のうちの１つをプライマリメンバー候補として指定し、該複数のメンバー候補のうちの１つをセカンダリメンバー候補として指定し、残りのメンバー候補を代替メンバー候補として指定することであって、該プライマリメンバー候補に障害が生じた場合には、該セカンダリメンバー候補が新しいプライマリメンバー候補となり、該セカンダリメンバー候補に障害が生じた場合には、該代替メンバー候補のうちの１つが新しいセカンダリメンバー候補となる、ことと、
   複数のメンバー候補が該複数のフェイルオーバセットの複数のメンバーとなるように、該複数のメンバー候補のすべてのスタートアップ処理を実行することと、
   各フェイルオーバセットにおける実行時のメンバーの振る舞いについてのポリシーを該ソフトウェア環境に提供することであって、該ポリシーは、故障の特徴づけおよび検出、ヘルスモニタリング、互換性要件、該フェイルオーバセットから該セカンダリメンバー候補を該プライマリメンバー候補として起動することと、該代替メンバー候補のうちの１つを該新しいセカンダリメンバー候補として起動することとを含むフェイルオーバの間の訂正動作、該フェイルオーバセットからの障害が生じたメンバーが修復された場合において、スタートアップ処理が該修復されたメンバーについて再実行され、該修復されたメンバーが該フェイルオーバセットに統合されるための条件、冗長な限界条件を超えるフェイルオーバ試行の回数を含む、ことと
   を包含する、方法。
2. 前記複数のストレージシステムは、単一のシャーシベースの製品を含む、請求項１に記載の方法。
3. 前記複数のストレージシステムは、単一のスタックベースの製品を含む、請求項１に記載の方法。
4. 前記複数のストレージシステムは、２つ以上のシャーシベースの製品を含む、請求項１に記載の方法。
5. 前記複数のストレージシステムは、２つ以上のスタックベースの製品を含む、請求項１に記載の方法。
6. 前記複数のネットワーク化されたストレージシステムの間の前記複数の冗長ネットワークリンクは、
   前記複数のメンバー候補を識別し、各ネットワークにおいて交換された情報を確認することにより接続性を検証するディスカバリサービスと、
   各ネットワークにおいて交換された情報を介してメンバーの役割をメンバー候補に割り当てることにより、あるメンバー候補の役割がプライマリメンバー候補であり、あるメンバー候補の役割がセカンダリメンバー候補であり、残りのメンバー候補の役割が代替メンバー候補であることを保証するアービトレーションサービスと、
   メンバーの役割がメンバー候補に割り当てられたか否かを決定するブートサービスであって、該メンバーの役割が割り当てられている場合には、該ブートサービスは、該メンバーの役割に応じたタイプのブートを実行し、該メンバーの役割が割り当てられていない場合には、該ブートサービスは、該アービトレーションサービスがメンバーの役割を該メンバー候補に割り当てるようにさせる、ブートサービスと、
   フェイルオーバサービス内のポリシーマネージャであって、該メンバー候補が仕様に従って機能しているか否かを決定するために冗長ネットワークを用いてセルフテストを送信することによって、複数のメンバー候補の間での通信リンク障害とメンバー候補のハードウェア障害とを区別するポリシーマネージャと
   によって用いられ、
   該フェイルオーバセットは、ユーザリクエストおよび管理リクエストを受信する、請求項１に記載の方法。
7. 前記複数のネットワークリンクは、複数の異なるネットワークプロトコルを含む、請求項６に記載の方法。
8. 前記ユーザリクエストおよび前記管理リクエストは、前記フェイルオーバセットの前記複数のメンバー候補のすべてにわたって均衡がとれた負荷である、請求項６に記載の方法。
9. 付加されたホストおよびストレージデバイスに対するマルチパスプログラミングは、前記複数のメンバー候補のすべてにわたって均衡がとれた負荷であり、
   該マルチパスプログラミングは、サーバストレージリクエストが互換可能なストレージデバイスに対応するように用いられるポートフェイルオーバポリシーを含み、
   該ポートフェイルポリシーは、
   仮想ストレージデバイスへのすべてのパスがコマンドおよびデータを同時に転送することが可能なアクティブ−アクティブポリシーと、
   仮想ストレージデバイスへの１つのパスのみがコマンドおよびデータを一度に転送することが可能なアクティブ−パッシブポリシーと
   を含む、請求項６に記載の方法。
10. 複数のネットワーク化されたストレージシステムの間でフェイルオーバをサポートするシステムであって、該複数のネットワーク化されたストレージシステムは、第１のストレージシステムと第２のストレージシステムと１つ以上のストレージシステムのセットとの間で接続されており、
    該システムは、
    複数のプロセッサと複数のカードと複数のストレージシステムとによって共有される単一のソフトウェア環境を提供するサービスフレームワークであって、該複数のストレージシステムは、該複数のプロセッサと該複数のカードとを含む、サービスフレームワークと、
    該サービスフレームワークの上で実行されるサービスと呼ばれるコンフィギュレーションおよび管理ソフトウェアのセットと
    を備え、
    該サービスは、
    スタンダードプロトコルを用いて、フェイルオーバセットの複数のメンバー候補を識別するディスカバリサービスであって、該フェイルオーバセットの該複数のメンバー候補は、ストレージシステム内の個々のコンポーネントと、該ストレージシステム内のコンポーネントの階層とを含む、ディスカバリサービスと、
    該複数のメンバーを複数のフェイルオーバセットと呼ばれる様々なコンポジッションに編成するフェイルオーバサービスと、
    該複数のフェイルオーバセットの該複数のメンバー候補のコンフィギュレーションを少なくとも１つの冗長データベースに格納するマスターデータベース管理システムと、
    ハートビートを有するジャーナルコントロールプロセスであって、該マスターデータベース内の該複数のフェイルオーバセットの該複数のメンバー候補のコンフィギュレーションと該少なくとも１つの冗長データベース内の該複数のフェイルオーバセットの該複数のメンバー候補のコンフィギュレーションとを同期させるジャーナルコントロールプロセスと、
    あるメンバーの役割がプライマリメンバー候補であり、あるメンバーの役割がセカンダリメンバー候補であり、残りのメンバーの役割が代替メンバー候補であることを決定するアービトレーションサービスと、
    スタートアップの間に、あるタイプのブートを用いて該メンバーの役割を調整するブートサービスと、
    該フェイルオーバサービス内のポリシーマネージャであって、各フェイルオーバセットにおける実行時のメンバーの振る舞いについてのポリシーを該ソフトウェア環境に提供するポリシーマネージャと
    を含み、
    該ポリシーは、故障の特徴づけおよび検出、ヘルスモニタリング、互換性要件、該フェイルオーバセットから該セカンダリメンバー候補を該プライマリメンバー候補として起動することと、該代替メンバー候補のうちの１つを該新しいセカンダリメンバー候補として起動することとを含むフェイルオーバの間の訂正動作、該フェイルオーバセットからの障害が生じたメンバーが修復された場合において、スタートアップ処理が該修復されたメンバーについて再実行され、該修復されたメンバーが該フェイルオーバセットに統合されるための条件、冗長な限界条件を超えるフェイルオーバ試行の回数を含む、システム。

Images