Windows クラスタのアーキテクチャ

Microsoft Windows NT Server 4.0 Enterprise Edition の Microsoft Cluster Server (MSCS) は、Microsoft の提供による最初のサーバー クラスタ テクノロジです。クラスタを構成する個々のサーバーをノードと呼びます。クラスタ サービスは、クラスタ固有のタスクを実行する、各ノード上のコンポーネントの集合です。クラスタ サービスによって管理されるハードウェアおよびソフトウェア コンポーネントは、リソースと呼ばれます。サーバー クラスタは、リソースの DLL を通じてリソースを管理する手段としてのメカニズムを提供します。これは、リソースの抽出 (つまり、特定の物理ノードからクラスタ化されたリソースを抽出することによって、リソースが 1 つのノードから別のノードに移動できるようにすること)、通信インターフェイス、および管理操作を定義します。

リソースとは、クラスタ内の次のような要素です。

• オンラインになり (サービスの実行)、オフラインになる (サービスの停止)
• サーバー クラスタ内で管理される
• 一度に 1 つだけのノードによって所有される

リソース グループとは、クラスタ サービスによって単一の論理ユニットとして管理されるリソースの集合です。この論理ユニットは、グループ全体がノード間を単一のユニットとして移動するため、フェールオーバー ユニットとも呼ばれます。リソースやクラスタ要素は、リソース グループに追加されたリソースに基づいて、論理的にグループ化されます。リソース グループに対してクラスタ サービス操作が実行されると、操作の影響はグループ内のすべてのリソースに及びます。通常、リソース グループには、クラスタ化されたプログラムによって必要とされる個々のリソースが含まれます。

クラスタ リソースに含まれるものとして、ディスク ドライブやネットワーク カードなどの物理的なハードウェア デバイスと、IP アドレス、ネットワーク名、アプリケーション コンポーネントなどの論理的なアイテムを挙げることができます。

また、クラスタには、外部のデータ ストレージ アレイやプライベート クラスタ ネットワークなどの共通リソースも含まれます。共通リソースには、クラスタ内の各ノードからアクセスできます。共通リソースの 1 つにクォーラム リソースがあります。これは、クラスタ操作において重要な役割を果たします。クラスタの作成、参加、変更などのすべてのノード操作で、クォーラム リソースにアクセスできる必要があります。

サーバー クラスタ

Windows Server 2003 Enterprise Edition には、Exchange Server 2003 Enterprise Edition と共に使用するためのクラスタ テクノロジが 2 種類用意されています。1 つ目はクラスタ サービスで、高レベルの可用性が必要とされるバックエンドのメールボックス サーバーに対して、フェールオーバー サポートを提供します。2 つ目はネットワーク負荷分散 (NLB) で、フロントエンドの Exchange プロトコル仮想サーバー (HTTP、IMAP4、POP3 など) の、可用性と拡張性が高いクラスタをサポートすることにより、サーバー クラスタを補完します。

サーバー クラスタは、非共有モデルを使用します。モデルの種類は、クラスタ内のサーバーが、ローカルおよび共通のクラスタ デバイスやりソースを、どのように管理し使用するかを定義します。非共有クラスタでは、各サーバーがそのローカル デバイスを所有し管理します。共通ディスク アレイや接続メディアなど、クラスタに共通のデバイスは、一度に 1 つのノードによって選択的に所有され、管理されます。

サーバー クラスタは、標準の Windows ドライバを使用して、ローカルのストレージ デバイスおよびメディアに接続します。サーバー クラスタは、クラスタ内のすべてのサーバーからアクセスできる必要がある外部の共通デバイスについて、複数の接続メディアをサポートしています。外部ストレージ デバイスは、標準の PCI ベースの SCSI 接続、ファイバ チャネルによる SCSI、および複数のイニシエータを持つ SCSI バスをサポートしています。ファイバ接続は、SCSI バスの代わりにファイバ チャネル バス上でホストされる SCSI デバイスです。

次の図に、2 ノードのサーバー クラスタのコンポーネントを示します。これは、Windows Server 2003 Enterprise Edition を実行するサーバーによって構成され、SCSI またはファイバ チャネルによる SCSI を使用して共有ストレージ デバイスに接続されます。

サーバー クラスタのアーキテクチャ

サーバー クラスタは、Windows Server 2003 と緊密に連携する独立したコンポーネントのセットとして設計されています。クラスタ サービスがインストールされると、オペレーティング システムの変更が可能になります。これらの変更には、次のものが含まれます。

• ネットワーク名およびネットワーク アドレスの動的な作成と削除がサポートされる。
• ファイル システムに変更が加えられ、ディスク ドライブのマウント解除中に、開いているファイルを閉じることができるようになる。
• 記憶域サブシステムに変更が加えられ、複数のノード間でディスクとボリュームを共有できるようになる。

上記の変更およびその他の部分的な変更が加えられることを除けば、Windows クラスタ サービスを実行しているサーバーは、Windows クラスタ サービスを実行していないサーバーと同じように動作します。

クラスタ サービスは、サーバー クラスタの中心的な機能です。クラスタ サービスは、ノード マネージャ、フェールオーバー マネージャ、データベース マネージャ、グローバル更新マネージャ、チェックポイント マネージャ、ログ マネージャ、イベント ログ レプリケーション マネージャ、バックアップ/復元マネージャなどの複数の機能ユニットで構成されます。

クラスタ サービスのコンポーネント

クラスタ サービスは、Windows Server 2003 Enterprise Edition 上で実行され、サーバー クラスタとそのコンポーネント プロセス用に設計されたネットワーク ドライバ、デバイス ドライバ、およびリソース使用プロセスを使用します。クラスタ サービスには、次のコンポーネントが含まれます。

• チェックポイント マネージャ   このコンポーネントは、クォーラム リソース上に格納されたクラスタ ディレクトリ内に、アプリケーション レジストリ キーを保存します。リソース エラーからクラスタ サービスが確実に回復できるようにするには、リソースがオンラインになったときにチェックポイント マネージャによってレジストリ キーをチェックし、リソースがオフラインになったときにチェックポイント データをクォーラム リソースに書き込むようにします。またチェックポイント マネージャは、リソースがオンラインになった場合は、クラスタ ノードでインスタンス化されているアプリケーション固有のレジストリ ツリーを持つリソースもサポートします。リソースには、1 つまたは複数のレジストリ ツリーを関連付けることができます。リソースがオンラインのとき、チェックポイント マネージャはこれらのレジストリ ツリーの変更を監視します。チェックポイント マネージャが変更を検出すると、リソースの所有者のノードにレジストリ ツリーを転送します。次にチェックポイント マネージャは、クォーラム リソースの所有者のノードに、そのファイルを転送します。チェックポイント マネージャはバッチ転送を実行するため、レジストリ ツリーに頻繁に変更を加えてもクラスタ サービスに大きな負荷がかかることはありません。

• データベース マネージャ   データベース マネージャは、クラスタ内のすべての物理エンティティと論理エンティティに関するクラスタ構成情報を管理します。これらのエンティティには、クラスタ自体、クラスタ ノード メンバシップ、リソース グループ、リソースの種類、ディスクや IP アドレスのような特定のリソースに関する詳細などがあります。
  構成データベースに格納されている持続性や揮発性の情報は、クラスタの現在の状態と、望ましい状態を追跡します。クラスタ内の各ノード上で実行されているデータベース マネージャの各インスタンスは、クラスタ間で一貫した構成情報を共同管理し、構成データベースの整合性がすべてのノードに確実にコピーされるようにします。
  また、データベース マネージャは、フェールオーバー マネージャやノード マネージャなど、他のクラスタ コンポーネントが使用するインターフェイスを提供します。このインターフェイスは、Microsoft Win32 API のレジストリ インターフェイスに似ています。ただし、データベース マネージャのインターフェイスは、クラスタのエンティティに加えられた変更を、レジストリとクォーラム リソースの両方に書き込みます。
  データベース マネージャは、クラスタ レジストリ ハイブのトランザクションの更新をサポートし、内部クラスタ サービス コンポーネントにのみインターフェイスを提供します。通常、フェールオーバー マネージャとノード マネージャは、このトランザクション サポートを使用してレプリケートされたトランザクションを取得します。クラスタ API は、トランザクション サポート機能以外のすべてのデータベース マネージャ機能をクライアントに提供します。クラスタ API の詳細については、MSDN の「Cluster API」(英語) を参照してください。

  注 :
  アプリケーション レジストリ キーのデータと変更は、チェックポイント マネージャによってクォーラム リソース内のクォーラム ログ ファイルに記録されます。

• イベント サービス   イベント サービスは、交換台として動作して、アプリケーションとの間でイベントを送受信し、各ノード上のクラスタ サービス コンポーネントにイベントを送ります。イベント サービスのイベント プロセッサ コンポーネントは、クラスタ サービス コンポーネントが重要なイベント情報を他のすべてのコンポーネントに伝達できるよう支援します。イベント プロセッサ コンポーネントは、クラスタ API のイベント メカニズムをサポートします。また、クラスタ対応のアプリケーションに対するシグナル イベントの送信や、クラスタ オブジェクトの管理など、さまざまなサービスを実行します。

• イベント ログ レプリケーション マネージャ   イベント ログ レプリケーション マネージャは、クラスタ内の 1 つのノードから他のすべてのノードに、イベント ログ エントリをレプリケートします。既定では、クラスタ サービスは、クラスタ内の Windows イベント ログ サービスと対話して、各ログ エントリをすべてのクラスタ ノードにレプリケートします。ノード上でクラスタ サービスが開始されると、ローカル イベント ログ サービス内のプライベート API が呼び出され、イベント ログ サービスをクラスタ サービスにバインドするように要求します。これにより、イベント ログ サービスは、ローカル リモート プロシージャ コール (RPC) を使用して、CLUSAPI インターフェイスにバインドされます。イベント ログ サービスは、記録する必要があるイベントをが受け取ると、そのイベントをローカルでログ出力してから継続的なバッチ キューにドロップし、既にアクティブなタイマ スレッドがない場合は、次の 20 秒以内にタイマ スレッドが実行されるようにスケジュールします。タイマ スレッドは、起動されるとバッチ キューを処理し、イベント ログ サービスが以前にバインドされたクラスタ API に、イベントを 1 つの統合バッファとして送信します。クラスタ API インターフェイスは次に、イベントをクラスタ サービスに送信します。
  クラスタ サービスがイベント ログ サービスから受け取ったバッチ イベントは、ローカルの送信キューにドロップされ、RPC から返されます。次にクラスタ サービス内のイベント ブロードキャスタ スレッドは、このキューを処理し、内部クラスタの RPC を使用して、すべてのアクティブなクラスタ ノードに対してこのイベントを送信します。すると、サーバー側の API は、このイベントを受信キューにドロップします。イベント ログの書き込みスレッドは、ローカル イベント ログ サービスがローカルでイベントを書き込むプライベート RPC を通じて、このキューと要求を処理します。
  クラスタ サービスは、簡易版のリモート プロシージャ コール (LRPC) を使用して、イベント ログ サービスのプライベート RPC インターフェイスを呼び出します。イベント ログ サービスも LRPC を使用してクラスタ API インターフェイスを呼び出し、次に、クラスタ サービスによるイベントのレプリケーションを要求します。

• フェールオーバー マネージャ   フェールオーバー マネージャは、リソースを管理し、起動、再起動、フェールオーバーなどの適切なアクションを開始します。フェールオーバー マネージャは、リソースの停止と起動、リソースの依存関係の管理、リソース グループのフェールオーバーなどを行います。これらのアクションを実行するために、フェールオーバー マネージャはリソース モニタとクラスタ ノードから、リソースとシステム状態の情報を受け取ります。
  またフェールオーバー マネージャは、クラスタ内のどのノードがどのリソース グループを所有するかを決定します。リソース グループの調整が完了すると、個々のリソース グループを所有しているノードは、リソース グループ内のリソースの制御をノード マネージャに返します。ノードが、そのリソース グループ内のエラーを処理できなかった場合、各ノード上のフェールオーバー マネージャが共同でリソース グループの所有者を再度割り当てます。
  リソースでエラーが発生すると、フェールオーバー マネージャがリソースを再起動するか、依存関係があるリソースと共にそのリソースをオフラインにします。フェールオーバー マネージャによってリソースがオフラインにされると、リソースの所有者は別のノードに移されます。次に、このリソースが新しいノードの所有の下で再起動されます。これをフェールオーバーと呼びます。詳細については、このトピックの後半の「クラスタのフェールオーバー」で説明します。

• グローバル更新マネージャ   グローバル更新マネージャは、クラスタ コンポーネントが使用するグローバル更新サービスを提供します。グローバル更新マネージャは、クラスタ データベースへの変更をすべてのノードにレプリケートするために、フェールオーバー マネージャ、ノード マネージャ、データベース マネージャなどの内部クラスタ コンポーネントによって使用されます。グローバル更新マネージャは、通常はクラスタ API 呼び出しの結果として起動されます。グローバル更新マネージャによる更新がクライアント ノードで開始されると、グローバル更新マネージャは、まずグローバル ロックを取得するために、ロッカー ノードを要求します。ロックを使用できない場合、クライアントは使用可能になるまで待機します。
  ロックが使用可能になると、ロッカーはロックをクライアントに許可し、ロッカー ノード上でローカルに更新を発行します。次にクライアントは、自分自身を含めたすべての正常なノードに対して更新を発行します。更新がロッカー上で成功しても、別のノード上で失敗すると、失敗したノードは現在のクラスタ メンバシップから削除されます。ロッカー ノード自体で更新が失敗すると、ロッカーは失敗をクライアントに返すだけです。

• ログ マネージャ   ログ マネージャは、クォーラム リソースに格納されている回復ログに変更を書き込みます。ログ マネージャはチェックポイント マネージャと共同で、クォーラム リソース上の回復ログに最も新しい構成データと変更チェックポイントが確実に含まれるようにします。1 つ以上のクラスタ ノードが停止した場合も、残りのノードに対して構成変更を行うことができます。これらのノードが停止すると、データベース マネージャはログ マネージャを使用して構成変更をクォーラム リソースに記録します。
  障害が発生したノードがサービスに復帰すると、これらはローカル クラスタのレジストリ ハイブからクォーラム リソースの場所を読み取ります。ハイブ データが古くなっている場合があるため、古いクラスタ構成データベースから読み取られた無効なクォーラム リソースを検出するメカニズムが使用されています。次にデータベース マネージャは、ログ マネージャに対して、クォーラム リソースのチェックポイント ファイルを使用して、クラスタ ハイブのローカル コピーを更新するように要求します。これにより、ログ ファイルはクォーラム ディスク内で、チェックポイント ログのシーケンス番号から再生されます。この結果、クラスタ ハイブは完全に更新されます。クラスタ ハイブのスナップショットは、クォーラム ログがリセットされたときおよび 4 時間に 1 回取得されます。

• メンバシップ マネージャ   メンバシップ マネージャは、クラスタ メンバシップと、クラスタ内のすべてのノードの状態を監視します。メンバシップ マネージャ (再グループ化エンジンとも言う) は、どのノードが現在稼働中か、または停止しているかを示す、一貫性があるビューを維持します。メンバシップ マネージャの中核コンポーネントは、1 つ以上のノードでエラーが発生したという証拠が見つかるたびに起動される、再グループ化アルゴリズムです。アルゴリズムが完了すると、すべての参加ノードは、新しいクラスタ メンバシップ上で、同一の結果に到達します。

• ノード マネージャ   ノード マネージャは、グループの優先順位一覧とノードの可用性に基づいて、リソース グループの所有者をノードに割り当てます。ノード マネージャは、各ノード上で実行され、クラスタに属するローカルのノード一覧を管理します。ノード マネージャは定期的に、メッセージ (名前付きハートビート) をクラスタ内の他のノード上で実行されているノード マネージャに送信することで、ノード エラーを検出します。クラスタ内のすべてのノードは、完全に同一なクラスタ メンバシップのビューを持っている必要があります。
  クラスタ ノードは、他のクラスタ ノードとの通信エラーを検出すると、クラスタ全体にマルチキャスト メッセージを送信します。このグループ イベントにより、すべてのメンバが現在のクラスタ メンバシップのビューを検証することになります。再グループ化イベントの間、メンバシップが安定するまで、クラスタ サービスはクラスタ内のすべてのノードに共通するディスク デバイスへの書き込み操作を禁止します。個々のノード上のノード マネージャのインスタンスが応答しない場合、そのノードはクラスタから削除され、そのアクティブなリソース グループは別のアクティブなノードに移動されます。この変更を行うために、ノード マネージャは個々のリソースを所有できる可能性のある所有者 (ノード) と、リソース グループを実行しやすいノードを識別します。次にノード マネージャはノードを選択し、リソース グループを移動します。2 ノードのクラスタの場合、ノード マネージャは、エラーが発生したノードから残りのノードにリソース グループを移動します。クラスタが 3 つ以上のノードで構成されている場合、ノード マネージャは残りのノード間で選択的にリソース グループを分散します。
  また、ノード マネージャはゲートキーパーとしても動作し、クラスタへのノードの結合を許可し、ノードの追加や削除などの要求も処理します。

• リソース モニタ   リソース モニタは、リソース DLL へのコールバックを使用して、各クラスタ リソースの状態を検証します。リソース モニタは、独立したプロセスとして動作し、RPC を通じてクラスタ サーバーと通信します。これにより、クラスタ サービスは個々のクラスタ リソースのエラーから保護されます。
  リソース モニタは、リソース DLL とクラスタ サービスの間の通信インターフェイスを提供します。クラスタ サービスがリソースからデータを取得する必要がある場合、リソース モニタは要求を受け取り、それを適切なリソース DLL に転送します。これとは逆に、リソース DLL がその状態をレポートするか、またはクラスタ サービスにイベントを通知する必要がある場合、リソース モニタはリソースからの情報をクラスタ サービスに転送します。
  リソース モニタ プロセス (RESRCMON.EXE) は、クラスタ サービス プロセス (CLUSSVC.EXE) の子プロセスです。リソース モニタは、そのプロセス空間でクラスタ リソースを監視するリソース DLL を読み取ります。エラーを隔離するために、リソース DLL の読み取りは、クラスタ サービス プロセスとは別のプロセスで行われます。複数のリソース モニタを同時にインスタンス化できます。
  各リソース モニタは、クラスタ サービス プロセスの LRPC サーバーとして機能します。クラスタ サービスは、リソース DLL との対話が必要なクラスタ API 呼び出しを受け取ると、LRPC インターフェイスを使用してリソース モニタ RPC を呼び出します。クラスタ サービスはリソース モニタから応答を受け取るために、リソース モニタ プロセスごとに 1 つの通知スレッドを作成します。この通知スレッドは、リソース モニタに永続的に配置されている RPC を呼び出します。このスレッドは、生成されたときに通知を取得します。このスレッドは、リソース モニタに障害が発生した場合、またはクラスタ サービスからのシャットダウン コマンドによってスレッドが手動で停止された場合にのみ開放されます。
  リソース モニタは、それ自体の継続的な状態を維持しません。リソース モニタはリソースの制限されたメモリ内での状態を保持しますが、初期状態の情報を提供するのは、クラスタ サービスです。リソース モニタは、DLL が存在することが必要な正しく定義されたエントリ ポイントを通じて、リソース DLL と通信します。リソース モニタは、次の操作をそれ自体で実行します。

  • IsAlive および LooksAlive エントリ ポイントを通じて、リソース DLL をポーリングするか、またはリソース DLL によって通知されたエラー イベントをチェックします。
  • リソース DLL の待ちのタイムアウトを監視するために、DLL のオンラインまたはオフライン エントリ ポイントから ERROR_IO_PENDING を返すタイマ スレッドを生成します。
  • これは、クラスタ サービスのクラッシュとリソースのシャット ダウンを検出します。
    リソース モニタのその他のアクションは、RPC インターフェイスを通じてクラスタ サービスが要求した操作の結果として実行されます。クラスタ サービスは、切断の検出は実行しません。ただし、クラスタ サービスはクラッシュを監視し、プロセスのクラッシュを検出した場合は、モニタを再起動します。
    クラスタ サービスとリソース モニタは、ページング ファイルによってバックアップされているメモリ マップ セクションを共有します。このセクションへのハンドルは、リソース モニタの起動時にリソース モニタに渡されます。リソース モニタは、リソース DLL エントリ ポイントを呼び出す直前にハンドルをレプリケートし、エントリ ポイント番号とリソース名をこのセクションに記録します。リソース モニタがクラッシュすると、クラスタ サービスは共有セクションを読み取って、クラッシュの原因になったリソースとエントリ ポイントを検出します。

• バックアップ/復元マネージャ   バックアップ/復元マネージャは、フェールオーバー マネージャおよびデータベース マネージャと共同で、クォーラム ログ ファイルとすべてのチェックポイント ファイルをバックアップおよび復元します。クラスタ サービスは、データベースのバックアップに BackupClusterDatabase API を使用します。まず、BackupClusterDatabase API は、フェールオーバー マネージャ層に接続します。フェールオーバー マネージャ層は、現在クォーラム リソースを所有しているノードに要求を転送します。これにより、ノードは、クォーラム ログ ファイルおよびすべてのチェックポイント ファイルのバックアップを作成するデータベース マネージャを呼び出します。
  また、クラスタ サービスは、起動時に自分自身をバックアップ ライターとしてボリューム シャドウ コピー サービスに登録します。バックアップ クライアントは、ボリューム シャドウ コピー サービスを呼び出してシステム状態のバックアップを実行する際、一連のエントリ ポイント呼び出しを通じてクラスタ サービスも呼び出し、クラスタ データベースのバックアップを実行します。クラスタ サービスのサーバー コードは、フェールオーバー マネージャを呼び出してバックアップを実行します。残りの操作は BackupClusterDatabase API を通じて実行されます。
  クラスタ サービスは、RestoreClusterDatabase API を使用してバックアップ パスからクラスタ データベースを復元します。この API は、クラスタ ノードの 1 つからのみローカルに呼び出すことができます。RestoreClusterDatabase API が呼び出されると、クラスタ サービスが停止され、バックアップからクラスタ データベースが復元され、バックアップ パスが含まれるレジストリ値が設定され、最後にクラスタ サービスが再開されます。クラスタ サービスは、復元が要求されていることを開始時に検出すると、バックアップ パスからクォーラム リソースにクラスタ データベースを復元します。

クラスタのフェールオーバー

フェールオーバーは、ハードウェアまたはソフトウェアに予想外の障害が発生すると自動的に実行されますが、管理者が手動で開始して実行することもできます。どちらの状況でも、アルゴリズムと動作はほとんど同一です。ただし、手動で開始したフェールオーバーの場合、リソースは順序正しくシャット ダウンされますが、停電、重要なハードウェア コンポーネントの障害などによって予想外のフェールオーバーが発生した場合、リソースは突然にシャットダウンされます。

クラスタ内のノード全体で障害が発生すると、そのリソース グループはクラスタ内の 1 つまたは複数の使用可能なノードに転送されます。自動フェールオーバーは、管理者による計画的なリソース所有者の再割り当てと似ています。ただし、順序正しい計画されたシャットダウンが中断されたり実行されなかったりする可能性もあるため、実際はもう少し複雑です。したがって、障害発生時には、クラスタの状態を評価する特別なステップが必要になります。

ネットワークに自動フェールオーバーが発生した場合、障害が発生したノードで実行されていたグループを特定し、どのノードにさまざまなリソース グループの所有権を渡すかを判断することが重要です。クラスタ内で、リソース グループのホスティングが可能なすべてのノードは、所有権をネゴシエートします。このネゴシエーションは、ノードの機能、現在の負荷、アプリケーションのフィードバック、ノードの優先順位一覧、または AntiAffinityClassNames プロパティに基づいて行われます。このプロパティについては、「クラスタ固有の構成」で説明します。リソース グループに関するネゴシエーションが完了すると、クラスタ内のすべてのノードは、ノードがリソース グループを所有しているデータベースおよびトラックを更新します。

2 つ以上のノードを持つクラスタでは、各リソース グループのノードの優先順位一覧によって、使用するサーバーと、1 つ以上の優先代替サーバーを指定できます。これにより、カスケード フェールオーバーが可能になります。カスケード フェールオーバーでは、カスケードやノード優先順位一覧の次のサーバーへのフェールオーバーを行い、複数のサーバーで障害が発生してもリソース グループが存続できるようになっています。

自動フェールオーバーの代替となる方法は、一般に N+I フェールオーバーと呼ばれます。この方法では、すべてのクラスタ グループに対してノード優先順位を確立します。ノード優先順位一覧には、最初のフェールオーバーでリソースが移動される予備のクラスタ ノードが指定されています。予備のノードは、クラスタ内のサーバーで、障害が発生したサーバーの負荷を予備のノードに移動できるように、ほとんどの場合はアイドル状態になっているか、または容易に事前に排除できる負荷が与えられています。

カスケード フェールオーバーは、クラスタ内の他のすべてのサーバーに、なんらかの余裕容量があることを想定しており、障害が発生したサーバーの負荷を部分的に吸収できるようになっています。N+I フェールオーバーでは、+I の予備のサーバーが、余裕容量の主な受け取り先になることを想定しています。

クラスタのフェールバック

ノードがオンラインに復帰すると、フェールオーバー マネージャは、回復したノードに 1 つ以上のリソース グループを移動することを決定できます。これをフェールバックと呼びます。リソース グループの優先順位には、回復または再起動されるノードに対して、フェールバックするための優先的な所有者が定義されている必要があります。回復または再起動されるノードが優先的な所有者になっているリソース グループは、現在の所有者から回復または再起動されたノードに移動されます。

リソース グループのフェールバック プロパティには、1 日の中でフェールバックを許可する時間と、フェールバックを試行する回数の上限を含めることができます。これにより、クラスタ サービスが、処理がピークに達する時間にリソース グループのフェールバックを行ったり、正しく回復または再起動されていないノードにフェールバックを行ったりすることを防ぐことができます。

クラスタのクォーラム

各クラスタには、クォーラム リソースと呼ばれる特別なリソースがあります。クォーラム リソースとは、次のことを実行するリソースのことです。

• メンバシップとクラスタ状態を決定する方法を提供する
• 構成情報を保持するための物理記憶域を提供する

クォーラム ログは、サーバー クラスタ全体の構成データベースです。クォーラム ログには、クラスタ構成情報が含まれています。これには、クラスタの一部であるサーバー、クラスタ内にインストールされているリソース、これらのリソースの状態 (たとえば、オンラインかオフラインか) などがあります。

クォーラムがクラスタ内で重要である理由は、次の 2 つです。

• 整合性   クラスタは、複数の物理サーバーが単一の仮想サーバーとして動作することによって成り立っています。各物理サーバーが、クラスタ構成の一貫性があるビューを持っていることが重要になります。クォーラムは、クラスタに関連するすべての構成情報の最終リポジトリとして動作します。クラスタ サービスは、クォーラムにアクセスして読み取ることができないと、起動することはできません。
• タイ ブレーク   クォーラムは、クラスタ分割シナリオを回避するためのタイ ブレーカとして使用されます。クラスタ分割シナリオは、2 つ以上のクラスタ ノード間のすべてのネットワーク通信リンクに障害が起きた場合に発生します。これが発生すると、クラスタは互いに通信できない 2 つ以上のパーティションに分割されます。クォーラムは、必ず 1 つのノード上でのみ、クラスタ リソースがオンラインに復帰するようにします。これは、クォーラムを所有するパーティションが継続されると共に、他のパーティションがクラスタから排除されることで実行されます。

標準クォーラム

このセクションで前述したように、クォーラムは、クォーラム ログ ファイルに格納されているクラスタ サービスの構成データベースです。標準クォーラムは、クラスタのすべてのメンバがアクセス可能な、共有されたストレージ アレイにホストされているディスク上に配置されたクォーラム ログ ファイルを使用します。

各メンバは、SCSI またはファイバ チャネルを使用して共有ストレージに接続します。記憶域は、外部ハード ディスク (通常は RAID ディスクとして構成されている)、または SAN によって構成されています。SAN では、SAN の論理スライスが物理ディスクとして表示されます。

注 :
フェールオーバー時には物理ディスク リソース全体が移動されるため、クォーラムがディスク パーティションではなく、物理ディスク リソースを使用することが重要です。また、サーバー クラスタを、サーバー上のローカル ハード ディスクを使用してクォーラムを格納するように構成することもできます。この種類の実装はローン ウルフ クラスタと呼ばれ、テストや開発目的でのみサポートされます。ローン ウルフ クラスタは、単独であることからフェールオーバーを提供できないため、運用環境では Exchange 2003 をクラスタ化するために使用しないでください。

Majority Node Set クォーラム

サーバー クラスタの観点からは、Majority Node Set (MNS) クォーラムは単一のクォーラム リソースです。このデータは、既定でクラスタ内の各ノードのローカル ディスクに格納されます。MNS リソースは、MNS リソースに格納されているクラスタ構成データと、別のディスクのデータとの一貫性を確保します。Windows Server 2003 によって提供される MNS 実装は、クォーラム データの格納に各ノードのローカル ディスクのディレクトリを使用します。クラスタの構成が変更されると、その変更は各ノードのローカル ディスク全体に反映されます。この変更は、(ノードの数/2) + 1 の数のノードに対して行われた場合のみ、コミットされたと見なされるか、または永続的なものになります。

MNS クォーラムは、ほとんどのノードがデータの最新のコピーを確実に持つようにします。クラスタの部分として構成されているノードの大多数が稼働中で、クラスタ サービスを実行している場合のみ、クラスタ サービスが起動し、リソースがオンラインになります。大多数のノードが存在しないと MNS クォーラムが判断すると、クラスタにはクォーラムがないと見なされ、さらに多くのノードが参加を試みるまで、クラスタ サービスは再起動ループで待機します。大多数のノードまたはクォーラムノードが使用可能になると、クラスタ サービスが起動され、リソースがオンラインになります。ノードの障害には関係なく、最新の構成がほとんどのノードに書き込まれるため、クラスタの起動時には常に最新の構成を持っていることが保証されます。

クラスタの障害が発生するか、またはなんらかの原因でクラスタが分割クラスタ シナリオに入ると、大多数のノードを含まないすべてのパーティションはオフラインになります。これにより、ノードの大多数が含まれているパーティションが実行されていると、これがクラスタ内でリソースを実行している唯一のパーティションになるため、そのパーティションで実行されていない任意のリソースを安全に起動することができます。

共有ディスク クォーラム クラスタと、MNS クォーラム クラスタを比較した場合の動作は異なっているため、どのモデルを使用するかについては、注意深く検討する必要があります。たとえば、クラスタ内のノードが 2 つだけの場合、MNS モデルは推奨されません。この場合、ノードの大多数が使用できなくなるため、1 つのノードの障害がクラスタ全体の障害に進行します。

Majority Node Set (MNS) クォーラムは、Windows Server 2003 Enterprise Edition および Windows Server 2003 Datacenter Edition のクラスタでのみ使用できます。MNS クラスタが Exchange クラスタに提供する唯一の利点は、クォーラム リソースが格納されている共有ストレージ アレイ内の専用ディスクの必要性がなくなることです。

クラスタ リソース

クラスタ サービスは、リソース モニタおよびリソース DLL を使用して、すべてのリソース オブジェクトを管理します。リソース モニタ インターフェイスは、クラスタ サービスがリソース管理コマンドを起動し、リソース状況のデータを取得できるようにする標準通信インターフェイスを提供します。リソース モニタは、リソース DLL を通じて実際のコマンド機能とデータを取得します。クラスタ サービスは、リソース DLL を使用してリソースをオンラインにし、これらとクラスタ内の他のリソースとの相互動作を管理し、これらの状態を監視します。

リソース管理を使用可能にするために、リソース DLL はいくつかの簡単なリソース インターフェイスおよびプロパティを使用します。リソース モニタは、SYSTEM アカウント下で実行される特権コードとして、特定のリソース DLL をそのアドレス スペースに読み込みます。SYSTEM アカウント (つまり、LocalSystem) は、オペレーティング システムを表すセキュリティ プリンシパル アカウントです。ユーザー セキュリティ コンテキスト下で実行されるクラスタ サービスは、SYSTEM アカウントを使用してオペレーティング システム内のセキュリティ機能を実行します。

リソースの機能が、他のリソースの可用性に依存している場合、これらの依存関係はリソース DLL で定義されます。あるリソースが他のリソースに依存している場合、クラスタ サービスは依存されているリソースを正しい順序でオンラインにした後で、依存しているリソースをオンラインにします。

リソースをオフラインにするときも、同じ方法で行われます。クラスタ サービスは、依存しているリソースがオフラインになった後でのみ、リソースをオフラインにします。これにより、リソースの読み取り時に循環的な依存関係が発生することを防止できます。

また各リソース DLL は、リソースが必要とするコンピュータの種類やデバイス接続を定義します。たとえば、ディスク リソースは、物理的にそのディスク デバイスに接続されているノードによってのみ所有される必要があります。ローカル再起動ポリシー、およびフェールオーバー中に必要なアクションも、リソース DLL で定義されます。

クラスタ管理

クラスタは、クラスタ アドミニストレータによって管理されます。クラスタ アドミニストレータはグラフィカルな管理者用ツールで、コマンド ライン ツールの Cluster.exe を使用して、管理、監視、およびフェールオーバー管理を実行できます。またサーバー クラスタは、オートメーション インターフェイスを提供します。このインターフェイスは、クラスタ リソース、ノード、およびクラスタ自体を管理するためのカスタム スクリプト ツールを作成するために使用できます。クラスタ アドミニストレータのようなアプリケーションおよび管理ツールは、このツールがクラスタ内のノードで実行されている場合も、外部のコンピュータ上で実行されている場合も、RPC を使用してこのインターフェイスにアクセスできます。

クラスタのフォーメーションと操作

クラスタ サービスがサーバーにインストールされ、実行されると、このサーバーはクラスタに参加します。クラスタ操作は、単一障害点を低減し、クラスタ リソースの高可用性を可能にします。以降のセクションでは、クラスタ作成時および操作時のノードの動作について簡単に説明します。

クラスタの作成

サーバー クラスタには、クラスタ ソフトウェアをサーバーにインストールし、新しいクラスタを作成するためのクラスタ インストール ユーティリティが含まれています。新しいクラスタを作成するときに、ユーティリティはクラスタの最初のメンバとして選択されたコンピュータ上で実行されます。最初のステップでは、クラスタ名を確立し、クラスタ データベースと初期クラスタ メンバシップの一覧を作成することによって新しいクラスタが定義されます。

クラスタ作成の次のステップでは、クラスタのすべてのメンバが使用できる共通のデータ ストレージ デバイスを追加します。これにより、単一ノードの新しいクラスタと、そのローカル データ ストレージ デバイスおよびクラスタの共通リソースが確立されます (一般に、ディスクまたはデータ ストレージと接続メディア リソース)。

クラスタ作成の最後のステップでは、クラスタのメンバにする各追加コンピュータ上で、インストール ユーティリティを実行します。新しいノードをクラスタに追加するたびに、そのノードはクラスタのオリジナル メンバから自動的に既存のクラスタ データベースのコピーを受け取ります。ノードがクラスタに参加するかまたはクラスタを形成すると、クラスタ サービスがそのノードにある構成データベースのプライベート コピーを更新します。

クラスタの形成

クラスタ サービスを実行しているサーバーは、クラスタを形成できますが、クラスタ内の他のノードを特定することはできません。クラスタを形成するためには、ノードはクォーラム リソースの排他的な所有権を取得できる必要があります。

クラスタが形成されると、クラスタ内の最初のノードにクラスタ構成データベースが含められます。追加ノードがクラスタに参加するたびに、クラスタ構成データベースのローカル コピーを受け取り、独自に保持します。クォーラム リソースは、最も新しいバージョンの構成データベースを回復ログとして格納します。ログには、ノードに依存しないクラスタ構成と状態データが含まれます。

クラスタ操作中に、クラスタ サービスはクォーラム回復ログを使用して、次のことを実行します。

• アクティブなノードの 1 つのセットのみがクラスタを形成できるようにします。
• ノードがクォーラム リソースの制御権を得られる場合にのみ、そのノードがクラスタ形成できるようにします。
• ノードがクォーラム リソースを制御するノードと通信できる場合にのみ、そのノードが既存のクラスタに参加または残ることができるようにします。

クラスタが形成されると、クラスタ内の各ノードは、3 つの異なる状態のいずれかになっています。これらの状態は、イベント プロセッサ (後述) によって記録され、イベント ログ マネージャによってクラスタ内の別のノードにレプリケートされます。3 つのクラスタ サービス状態は、次のとおりです。

• オフライン   このノードは、クラスタのアクティブなメンバではありません。このノードとそのクラスタ サービスは、実行されている場合と実行されていない場合があります。
• オンライン   このノードは、クラスタのアクティブなメンバです。これはクラスタ データベースの更新に従い、クォーラム アルゴリズムへの入力に寄与し、クラスタ ネットワークと記憶域のハートビートを保持し、リソース グループを所有および実行できます。
• 一時停止   このノードは、クラスタのアクティブなメンバです。これはクラスタ データベースの更新に従い、クォーラム アルゴリズムへの入力に寄与し、ネットワークと記憶域のハートビートを保持しますが、リソース グループを受け入れることはできません。これは、現在所有しているリソース グループのみをサポートできます。一時停止状態では、保守を実行することができます。オンライン状態と一時停止状態は、大半のサーバー クラスタ コンポーネントからは同等の状態として扱われます。

クラスタへの参加

既存のクラスタに参加するために、サーバーはクラスタ サービスを実行している必要があり、またクラスタ内の別のノードを正しく特定できる必要があります。クラスタ内の他のノードを見つけると、参加サーバーは、クラスタ内のメンバシップの認証を受け、クラスタ構成データベースのレプリケーション コピーを受け取る必要があります。

既存のクラスタへの参加プロセスは、Windows サービス コントロール マネージャがノード上でクラスタ サービスを開始することから始まります。開始プロセス中に、クラスタ サービスはノードのローカル データ デバイスを構成およびマウントします。既存のクラスタがデバイスを使用している可能性があるため、共通のクラスタ データ デバイスをノードとしてオンラインにすることはありません。

他のノードを特定するために、検出プロセスが開始されます。ノードがクラスタのメンバを検出すると、認証手順が実行されます。最初のクラスタ メンバが新しいノードを認証し、新しいノードが正しく認証されると、成功の状態を返します。参加ノードがクラスタ メンバとして認識されないか、またはアカウント パスワードが無効であるなどの理由で認証が成功しない場合、クラスタへの参加要求は拒否されます。

認証が成功すると、クラスタ内でオンラインになっている最初のノードは、参加ノードの構成データベースのコピーをチェックします。もしそれが古い場合、クラスタ ノードは参加ノードにデータベースの更新のコピーを送信します。レプリケーション データベースを受け取ると、クラスタに参加したノードは共有リソースを探すためにそれを使用し、必要に応じてそれをオンラインにすることができます。

クラスタからの離脱

ノードは、シャット ダウン時やクラスタ サービスが停止したときに、クラスタを離脱できます。ただし、ノードがクラスタ操作を失敗したときにも、ノードはクラスタから削除されます (クラスタ構成データベースの更新の送信が失敗した場合など)。

計画されたシャット ダウンでノードがクラスタを離脱する場合、ノードはクラスタ内のすべての他のメンバに ClusterExit メッセージを送信し、離脱することを通知します。ノードは応答を待たずに、直ちにリソースのシャット ダウンを行い、すべてのクラスタ接続を解除します。残りのノードは、この終了メッセージを受け取っているため、ノードに突発的な障害や、ネットワーク接続の停止が発生した場合でも、クラスタ メンバシップを再確立するための再グループ化プロセスは実行しません。

障害の検出

障害の検出と防止は、サーバー クラスタによって提供される重要な利点です。クラスタ内のノードまたはアプリケーションに障害が発生すると、サーバー クラスタは障害が発生したアプリケーションを再起動するか、障害が発生したシステムからクラスタ内の残りのノードに作業を分散してそれに対処します。サーバー クラスタが障害の検出と防止を行う方法には、双方向フェールオーバー、アプリケーション フェールオーバー、パラレル リカバリ、および自動フェールバックがあります。

クラスタ サービスが個々のリソースまたはノード全体の障害を検出すると、アプリケーション、データ、およびファイル リソースを、クラスタ内の使用可能な健全なサーバーに動的に移動します。これにより、ユーザーやクライアント アプリケーションにとって、データベース、ファイル共有、アプリケーションなどのリソースの可用性が高く維持されます。

サーバー クラスタには、次の 2 つの障害検出メカニズムが組み込まれています。

• ノードの障害を検出するためのハートビート   各ノードは、定期的にユーザー データグラム プロトコル ベースのメッセージを、クラスタ内の他のノードとプライベート クラスタ ネットワーク上で交換します。これらのメッセージは、ハートビートと呼ばれます。ハートビートの交換により、各ノードは他のノードとそのリソースの可用性をチェックできます。サーバーがハートビート交換の応答に失敗すると、存続しているサーバーがフェールオーバー プロセスを開始し、障害が起きたサーバーが所有しているリソースとアプリケーションの所有権が決定されます。この決定は、チャレンジおよびディフェンス プロトコルを使用して実行されます。障害が発生したと思われるノードには、いくつかの方法のうちの 1 つ方法で、まだ正しく実行されており、他の存続しているノードと通信できるかどうかを示すデモンストレーションを行う時間枠が与えられます。ノードが応答できない場合は、クラスタから削除されます。
  ハートビート メッセージへの応答が失敗する原因には、コンピュータの障害、ネットワーク インターフェイスの障害、ネットワークの障害、アクティビティが非常に多く発生する時間帯などがあります。一般に、すべてのノードが通信を行っているときには、構成データベース マネージャによって、グローバルな構成データベースの更新が各ノードに送信されます。ハートビート交換の失敗が発生すると、ログ マネージャは構成データベースの変更をクォーラム リソースに保存します。これにより、残りのノードは回復のプロセス中に、最も新しい構成とローカル ノードのレジストリ データにアクセスできます。
  この障害検出アルゴリズムは、非常に慎重です。ハートビート応答の失敗が一時的なものである場合、フェールオーバーによって発生し得る中断をできる限り回避します。ただし、ノードが次のミリ秒で応答するかどうかは不明であり、また致命的な障害が発生しないとも限りません。したがって、フェールオーバーは、タイムアウト期間が満了してから開始されます。
• リソース エラーの検出のためのリソース モニタとリソース DLL   フェールオーバー マネージャとリソース モニタは共同でリソース エラーを検出し、回復作業を行います。リソース モニタは、リソース DLL を使用して定期的にリソースをポーリングすることで、リソース状況を追跡します。ポーリングは、LooksAlive クエリと、より長く限定的な IsAlive クエリという 2 つのステップで行われます。リソース モニタは、リソース エラーを検出するとそれをフェールオーバー マネージャに通知し、そのリソースの監視を続けます。
  フェールオーバー マネージャは、リソースとリソース グループの状態を保持します。また、リソース エラーが発生すると回復を実行し、ユーザー アクションまたは障害に対応してリソース モニタを呼び出します。
  リソース エラーが検出されると、フェールオーバー マネージャは、リソースおよびその依存リソースを再起動するか、またはリソース グループ全体を別のノードに移動するという回復操作を実行します。実行される回復操作は、ノードの可用性およびリソースとリソース グループのプロパティによって決定されます。
  フェールオーバー時に、リソース グループはフェールオーバーの単位として扱われます。これにより、リソースの依存関係が正しく回復されます。リソースがエラーから回復すると、リソース モニタはフェールオーバー マネージャに通知します。フェールオーバー マネージャは、リソース グループのフェールバック プロパティの構成に基づいて、リソース グループの自動フェールバックを実行します。