Windows クラスタリング技術 : クラスタサービスアーキテクチャ

Windows クラスタリング技術 : クラスタサービスアーキテク...

最終更新日: 2000年3月27日

オペレーティングシステム

概要
クラスタサービスとは、Microsoft® Windows® 2000 (以下 Windows 2000) および Microsoft Windows NT® (以下 Windows NT) ファミリのサーバー製品で使われる 2 つのクラスタリング技術のうちの 1 つです。クラスタサービスを実行する Windows 2000 と Windows NT ベースのサーバーには、高度な可用性とデータの整合性を必要とするバックエンドアプリケーションとサービスに対するフェールオーバーサポートが備わっています。これらのバックエンドアプリケーションの中には、データベース、ファイルサーバー、エンタプライズリソースプランニング (ERP)、およびメールシステムなどのエンタプライズアプリケーションがあります。このホワイトペーパーでは、クラスタサービスのアーキテクチャと機能に焦点を当てて、その用語、概念、設計目標、主要構成要素、および今後の計画予定について説明します。

トピック

はじめに
 クラスタの専門用語
 クラスタサービスのアーキテクチャ
 クラスタリソース
 クラスタの管理
 クラスタの形成と操作
 今後の方向
 詳細の参照先

はじめに

クラスタサービスは、当初 Windows NT Server 4.0 オペレーティングシステム用に設計されたものですが、Windows 2000 Server オペレーティングシステムに引き継がれ、強化されています。クラスタサービスを使用すると、複数のサーバーをサーバークラスタに接続して、クラスタ内で操作されるデータとプログラムを自由に使用し、簡単に管理できます。クラスタサービスには、クラスタリング技術が持つ 3 つの主要な利点があります。

可用性の強化 サーバークラスタ内のサービスとアプリケーションは、ハードウェアまたはソフトウェアの障害時や予定された保守中でも引き続きサービスを提供できます。
拡張性の強化 複数のプロセッサ (最大 4 個のプロセッサ) を追加して拡張できるサーバーをサポートします。
管理の強化 管理者は、1 台のコンピュータを管理する場合のように、クラスタ全体のデバイスとリソースを管理できます。

クラスタサービスは、Windows 2000 および Windows NT オペレーティングシステムの拡張機能として提供される、2 つの追加 Windows クラスタリング技術の 1 つです。もう 1 つのクラスタリング技術であるネットワーク負荷分散は、インターネットまたはイントラネットのサイトなどのフロントエンドアプリケーションとサービス、Web ベースのアプリケーション、および Microsoft ターミナルサービスを対象とする可用性と拡張性の高いクラスタをサポートすることによって、クラスタ技術を補強するものです。

このホワイトペーパーでは、クラスタサービスのアーキテクチャと機能にのみ焦点を当てて、その用語、概念、設計目標、主要構成要素、および今後の計画予定について説明します。このホワイトペーパーの最後にある「追加情報」には、クラスタサービスとネットワーク負荷バランスの技術に関する詳細の参照先のリストを示してあります。

開発の背景

コンピュータクラスタは、10 年以上にわたって構築され使用されてきました。クラスタリング技術の初期設計者の 1 人である G.Pfister は、クラスタを、「1 つの統一されたコンピューティングリソースとして利用される、相互接続されたコンピュータ全体の集合からなるパラレルシステムまたは分散システム」と定義しています。

いくつかのサーバーコンピュータを 1 つの統一されたクラスタにまとめることによって、ユーザーや管理者は、複数のサーバーが関与していることを知らなくてもコンピューティングの負荷を共有できます。たとえば、サーバークラスタ内のいずれかのコンポーネントに障害が発生した場合、そのクラスタ全体は、クラスタ内にあるほかのサーバー上のコンポーネントを使用して、引き続きユーザーに対してサービスを提供できます。これは、障害が発生したコンポーネントがハードウェアであるかソフトウェアであるかに関係なく可能です。

サーバークラスタに接続しているユーザーは、一時的にパフォーマンスの低下を経験する場合がありますが、サービスに完全にアクセスできなくなることはありません。より高い処理能力が求められる場合は、管理者は、アップグレードプロセスで新しいコンポーネントを追加できます。プロセス中、クラスタ全体はオンラインの状態を維持し、ユーザーにとって使用可能ですが、アップグレード後のクラスタのパフォーマンスは向上します。

クラスタ技術に対するユーザーおよび業務上の要件が、クラスタサービスのデザインと開発を形成しました。主要設計目標は、当初から、特定の小さなマーケット区分ではなく、広範なビジネスおよび組織のクラスタの必要性に対応可能なオペレーティングシステムサービスの開発に置かれていました。

Microsoft のマーケティング調査では、データベースと電子メールが中小規模企業の日常業務に欠かせないものになるにつれて、これらの企業における可用性の高いシステムへの需要が日増しに高くなってきていることがわかっています。一般的に中小規模企業では情報技術に携わる人材が限られているため、インストールと管理の容易さは重要な要件として認識されています。同時に、Microsoft の調査では、大企業における Windows ベースのサーバーに対する需要が高くなり、高いパフォーマンスと可用性が要求されていることもわかっています。

このマーケット調査の結果がクラスタサービスのデザインに影響を与えて、クラスタサービスは、Windows 2000 および Windows NT オペレーティングシステムの統合拡張機能として開発されました。このサービスを使用すると、複数のサーバーとデータ記憶コンポーネントを、管理が簡単な単位であるサーバークラスタに結合できます。サーバークラスタを使用することによって、あらゆる規模の企業が、Windows 2000 および Windows NT ベースのアプリケーションを実行する、可用性が高く管理の容易なシステムを実現できます。クラスタサービスは、クラスタ対応の新しいアプリケーションを開発するために必要なアプリケーションインターフェイスとツールも提供します。

ページのトップへ

クラスタの専門用語

クラスタサービスとは Windows 2000 の用語であり、当初 Windows NT Server 4.0 Enterprise Edition の Microsoft Clustering Server (MSCS) として使用する Microsoft の技術のことでした。クラスタを構成するコンポーネントを指す場合、個々のコンピュータは、ノードまたはシステムと呼ばれます。クラスタサービスとは、クラスタ特定の動作を実行する各ノード上の主要コンポーネントの集合をいいます。またリソースとは、クラスタサービスによって管理されるクラスタ内のハードウェアおよびソフトウェアコンポーネントをいいます。リソースは、使用可能なクラスタに対してサービスを提供している場合、オンライン状態と呼ばれます。

リソースには、ディスクドライブやネットワークカードなどの物理的なハードウェアデバイス、またはインターネットプロトコル (IP) アドレス、アプリケーション、およびアプリケーションデータベースなどの論理アイテムが含まれます。リソースグループとは、クラスタサービスによって 1 つの論理単位として管理されるリソースの集合をいいます。これには、特定のアプリケーションサーバーとクライアントがアプリケーションを正しく使用するために必要なすべての要素が含まれます。クラスタサービスの操作が、あるリソースグループに対して実行される場合、この操作はそのグループ内に含まれるすべてのリソースに影響を与えます。

サーバークラスタ

クラスタサービスの設計に使用するモデルは、クラスタアーキテクチャの何も共有しないモデルを基にしました。このモデルは、クラスタ内のサーバーがローカルシステムとクラスタデバイスおよびリソースをどのように管理するかを示すものです。何も共有しないクラスタでは、各サーバーがそのローカルデバイスを所有して管理します。共通ディスクドライブや接続メディアなどのクラスタに共通するデバイスは、どの時点でも 1 つのサーバーが選択し、所有、管理します。

何も共有しないモデルを使用すると、ディスクデバイスと標準アプリケーションの管理が容易になります。このモデルでは、特殊な配線やアプリケーションが不要であり、クラスタサービスで、標準の Windows 2000 および Windows NT ベースのアプリケーションとディスクリソースをサポートできます。

クラスタサービスは、ローカルサーバー記憶デバイスおよびメディア接続用に、標準の Windows 2000 および Windows NT Server のドライバをサポートします。ただし、クラスタに共通する外部記憶デバイスには、小型コンピュータシステムインターフェイス (SCSI) デバイスが必要です。クラスタサービスは、ファイバーチャネル、および複数のイニシエータを持つ SCSI バスによる、SCSI を含む標準の PCI ベース SCSI 接続をサポートしています。このことは、実際には、クラスタサービスがデバイスおよびメディア接続を使用する方法を、基本的に変更しません。ファイバー接続とは、SCSI バスではなく、単純にファイバーチャネルバスをホストとする SCSI デバイスをいいます。概念上、ファイバーチャネル技術は、SCSI コマンドをファイバーチャネル内にカプセル化します。クラスタサービスは、この SCSI コマンドに従って、予約と解除およびバスのリセットなどを行います。これらのコマンドは、標準の (つまりファイバーではない) SCSI を介して実行される場合でも機能します。

次の図は、SCSI またはファイバーチャネルによる SCSI を使用する共有記憶デバイス接続によって、Windows 2000 Advanced Server または Windows NT Server 4.0 Enterprise Edition のどちらかを実行するサーバーから構成される、2 ノードのサーバークラスタのコンポーネントを示しています。

図 1: Windows 2000 Advanced Server または Windows NT Server 4.0 Enterprise Edition を実行する 2 ノードサーバークラスタ

Windows 2000 Datacenter Server は、ファイバーチャネルスイッチを使用する 4 ノードのクラスタとデバイス接続をサポートしています。次の図は、4 ノードクラスタのコンポーネントを示しています。

図 2: Windows 2000 Datacenter Server を実行する 4 ノードのサーバークラスタ

仮想サーバー

サーバークラスタ内のノードで実行されるアプリケーションとサービスは、ユーザーおよびワークステーションに対して仮想サーバーとして示されます。ユーザーとクライアントにとって、サーバークラスタで実行されるアプリケーションまたはサービスへの接続は、1 台の物理サーバーへの接続と同じプロセスのように見えます。この接続は、実際には、クラスタ内のいずれかのノードをホストとする仮想サーバーに対して行われます。

クラスタ内の各ノードで実行されるアプリケーションは、クラスタサービスによって唯一の仮想サーバーとして表示され管理されます。複数のアプリケーションを示す複数の仮想サーバーは、次の図に示すように、クラスタにホストを置くことができます。

図 3: クラスタサービスのもとでの仮想サーバーの物理的ビュー

TCP/IP ネットワークでの仮想サーバーに対するアプリケーションクライアント接続は、クラスタサービスが仮想サーバーのアドレスとして公開する IP アドレスだけを知っているクライアントセッションによって行われます。クラスタサービスは、アプリケーションリソースグループに属するリソースとして IP アドレスを管理します。次の図は、このクライアントによる仮想サーバーのビューを示しています。

図 4: クラスタサービス仮想サーバーのクライアントビュー

アプリケーションまたはサーバーの障害時に、クラスタサービスは、リソースグループ全体をクラスタ内の別のノードに移動します。このような障害が発生すると、クライアントはアプリケーションとのそのセッションで障害を検出し、元の接続とまったく同じ方法で再接続しようとします。クラスタサービスでは、単に仮想サーバーの IP アドレスがクラスタ内に存続するノードに対して再び割り当てられるだけなので、クライアントセッションは、アプリケーションが現在クラスタ内の別のノードをホストにしていることを認識しなくても、アプリケーションへの接続を再確立できます。

この処理によってアプリケーションまたはサービスの高い可用性が実現される一方で、元のセッションに関連するすべての情報が失われることに注意する必要があります。つまり、クラスタサービスを使用すると、高度な可用性が実現できますが、アプリケーションのフォールトトレランスは得られません。アプリケーションのフォールトトレランスを実現するには、フォールトトレランスセマンティックを使用するサーバーデータベースにクライアントデータが確実にコミットされるトランザクション論理を、アプリケーションで使用する必要があります。

リソースグループ

クラスタサービスの仮想サーバーはリソースグループです。リソースグループを所有できるのは一度に 1 つのノードだけであり、グループ内の個々のリソースは、現在そのグループを所有しているノード上になければなりません。特定のインスタンスで、クラスタ内の異なる複数のサーバーが同じリソースグループ内の異なるリソースを所有することはできません。

各グループには、そのグループが実行されるサーバーと、障害時にそのグループの移動先となるサーバーを指定する、クラスタ全体のポリシーがあります。また、各グループには、リソースグループが提供するサービスへのバインドに使用する、ネットワーククライアント用の独自のネットワークサービス名とアドレスもあります。障害発生時にリソースグループは、原子単位として、障害が発生したノードからクラスタ内の使用可能な別のノードへフェイルオーバーまたは移動できます。

ページのトップへ

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

クラスタサービスは、オペレーティングシステムとともに動作する、個別の独立したコンポーネントの集合として設計されています。この設計は、クラスタサービスとオペレーティングシステムの間の複雑な処理システムスケジュールの依存関係を回避するものです。ただし、クラスタ機能を実現するには、基本オペレーティングシステムにいくつかの変更が必要になります。変更は以下のとおりです。

ネットワーク名とアドレスの動的な作成と削除のサポート
ディスクドライブディスマウント中に開いているファイルを閉じられるようにするためのファイルシステムの変更
複数のノード間でのディスクとボリュームセットの共有を可能にするための I/O サブシステムの変更

上記の変更とその他のマイナー修正とは別に、クラスタサービスのクラスタ機能は、Windows 2000 および Windows NT オペレーティングシステムの技術基盤の上に構築されています。

クラスタコンポーネント

クラスタサービスは、以下のコンポーネントとプロセスから構成され、互いに密接に関連しています。

ノードマネージャ クラスタメンバシップを処理して、クラスタ内のほかのノードの状態を監視します。
構成データベースマネージャ クラスタ構成データベースを保守します。
ログマネージャ クォーラムリソースに保存された回復ログに変更を書き込みます。
チェックポイントマネージャ クォーラムリソースによって保持されるログファイルにデータを保存します。
リソースマネージャ すべてのリソースおよびリソースグループの管理上の決定を行い、スタートアップ、再起動、フェールオーバーなどの適切な操作を開始します。
フェールオーバーマネージャ リソースマネージャとともに動作して、リソースおよびリソースグループを管理し、フェールオーバー操作を開始します。
イベントプロセッサ クラスタサービスのすべてのコンポーネントを接続し、共通の操作を処理して、クラスタサービスの初期化を制御します。
通信マネージャ クラスタのほかのノードすべてとの通信を管理します。
グローバル更新マネージャ クラスタサービス内のほかのコンポーネントによって使用されるグローバル更新サービスを提供します。
リソースモニタ 独立した 1 つまたは複数のプロセスで実行され、リモートプロシージャ呼び出し (RPC) を介してクラスタサービスと通信して、リソースへのコールバックを使用して各クラスタリソースの状態を監視します。

ノードマネージャ

ノードマネージャは各ノードで実行され、クラスタに属しているノードのローカルリストを保持します。ノードマネージャは、クラスタ内の別ノードで実行されるノードマネージャに、ハートビートと呼ばれるメッセージを送信して、ノードの障害を検出します。クラスタ内のすべてのノードが常にクラスタメンバシップの同じビューを持つことが重要です。

あるノードが別のクラスタノードとの通信障害を検出した場合、そのノードは、クラスタ全体にメッセージをブロードキャストして、すべてのメンバにそれぞれの現在のクラスタメンバシップのビューを確認させます。これは、再グループ化イベントと呼ばれます。クラスタサービスでは、メンバシップが安定するまで、クラスタ内のすべてのノードに共通するディスクデバイスへの書き込み操作が禁止されます。あるノード上のノードマネージャが応答しない場合、これはクラスタから削除されて、そのアクティブリソースグループがアクティブノードに移動します。

メモクラスタサービスとそのコンポーネントプロセスに障害が発生した場合、障害が発生したノードに接続されたリソースは、クラスタ内のアクティブで使用可能なノードで再起動されることを前提にして停止されます。

構成データベースマネージャ

構成データベースマネージャは、クラスタ構成データベースの維持に必要な機能を実装します。構成データベースには、クラスタ内の物理的および論理的実体すべてに関する情報が含まれます。これらの実体には、クラスタそのもの、クラスタノードメンバシップ、リソースの種類、およびディスクや IP アドレスなどの特定リソースの記述があります。

構成データベースに保存された固定情報と揮発性情報は、クラスタの現在の状態と理想の状態を追跡するために使用されます。クラスタ内の各ノードで実行される構成データベースマネージャは、相互に協力して、クラスタ全体で一貫して構成情報を維持します。1 フェーズコミットは、すべてのノード上にある構成データベースのコピーの一貫性を保証するために使用されます。構成データベースマネージャは、ほかのクラスタサービスコンポーネントによって使用される構成データベースへのインターフェイスも提供します。このインターフェイスは、Win32 アプリケーションプログラミングインターフェイス (API) セットによって提示されるレジストリインターフェイスに似ています。クラスタサービスでの主な違いは、クラスタ内のあるノードで行われた変更が、クラスタサービスのチェックポイントマネージャによって、クラスタ内の影響を受けるすべてのノードに対してアトミックに分配される点にあります。

ログマネージャ

ログマネージャは、各ノードのクラスタデータベースのコピーを定期的に確認して、一貫性を確保します。ログマネージャは、チェックポイントマネージャとともに、クォーラムリソースの回復ログに、最新のクラスタデータベース情報が確実に含まれるようにします。

チェックポイントマネージャ

クラスタ対応アプリケーションは、構成データベースを使用して情報を保存します。しかし、クラスタ対応ではないアプリケーションは、ノードレジストリに情報を保存できます。チェックポイントマネージャは、ノードレジストリ情報をクォーラム回復ログに保持します。この情報はチェックポイントと呼ばれます。チェックポイントマネージャは、指定リソースのレジストリリソースキーからクォーラムディスクへチェックポイントを書き込みます。これにより、クォーラムリソースの回復ログに、最新のクラスタデータベース情報が確実に含まれます。

リソースマネージャ

リソースマネージャは、リソースの停止と開始、リソースの依存関係の管理、およびリソースグループのフェールオーバーの開始を行います。これは、リソースモニタとノードマネージャから、リソースおよびシステムの状態情報を受け取ります。リソースマネージャは、これらの情報を使用して、リソースグループに関する決定を下します。

フェールオーバーマネージャ

フェールオーバーマネージャは、クラスタ内の各ノードがどのリソースグループを所有するかを決定します。リソースグループの調停が終了すると、個々のリソースグループを所有するノードは、リソースグループ内のリソースの制御を対応する各リソースマネージャに渡します。あるリソースグループを所有するノードがそのグループ内のリソースの障害を処理できない場合、クラスタ内の各ノードのフェ－ルオーバーマネージャはともに動作して、リソースグループの所有権を再調停します。

リソースに障害が発生すると、リソースマネージャはそのリソースを再起動するか、またはそのリソースとそれに依存するリソースをオフラインにします。リソースをオフラインにする場合、リソースマネージャは、フェールオーバーマネージャに対して、そのリソースの所有権をもう 1 つのノードに移動して、新しいノードの所有権のもとで再起動する必要があることを知らせます。これはフェールオーバーと呼ばれます。

フェールオーバー
フェールオーバーは、予期しないハードウェアまたはアプリケーションの障害が原因で自動的に発生することもあれば、クラスタを管理するユーザーによって手動でひきおこされることもあります。どちらの状況でもアルゴリズムは同じですが、手動で開始されたフェールオーバーの場合はリソースが正常にシャットダウンされるのに対し、障害の場合はリソースが強制的にシャットダウンされる点が異なります。

クラスタ内のあるノード全体に障害が発生した場合、そのリソースグループはクラスタ内の 1 つまたは複数の使用可能なサーバーに移動します。自動フェールオーバーは、予定されたリソース所有権の管理再割り当てに似ています。ただし、通常のシャットダウンフェーズは障害が発生したノードに対して徐々に実行されるわけではないため、自動フェールオーバーはより複雑です。

自動フェ－ルオーバーでは、障害が発生したノードで実行されていたグループは何か、また、各種のリソースグループの所有権を持つノードはどれか、判断する必要があります。リソースグループのホストになれるクラスタ内のノードはすべて、それらの間で所有権をネゴシエートします。このネゴシエーションは、ノードの機能、現在の負荷、アプリケーションのフィードバック、またはノードへのリソースグループの割り当てに使用されるノード優先リストに基づいて行われます。リソースグループのネゴシエーションが完了すると、クラスタ内のノードすべてがそのデータベースを更新して、どのノードがリソースグループを所有するかを追跡します。

複数のノードを持つクラスタでは、各リソースグループのノード優先リストによって、優先サーバーと 2 つ以上の優先される代替サーバーを指定できます。これにより、複数のサーバー障害があってもリソースグループが存続できるカスケードフェールオーバーが可能になり、毎回そのノード優先リスト上の次のサーバーにカスケード、つまりフェールオーバーします。クラスタ管理者は、この機能を使用してサーバーの各リソースグループに異なる複数のノード優先リストを設定し、サーバーの障害時に、クラスタの存続するサーバー間でグループを分散させることができます。

この設定の代わりとなる、一般的には N+1 フェールオーバーと呼ばれる設定では、すべてのクラスタグループのノード優先リストが設定されます。ノード優先リストは、最初のフェールオーバー中にリソースを移動するスタンバイクラスタノードを識別します。スタンバイノードとは、ほとんど待機状態であるクラスタ内のサーバーのこと、または、障害が発生したサーバーの作業負荷をスタンバイノードに移動する必要がある場合に、各自の作業負荷を簡単にプリエンプトさせることができるようなクラスタ内のサーバーのことをいいます。

カスケードフェールオーバーと N+1 フェールオーバーのどちらかを選択するときに、クラスタ管理者にとって重要な問題となるのは、サーバーのロスに対応するためのクラスタの超過容量の場所です。カスケードフェールオーバーでは、クラスタ内のほかのサーバーすべてに、障害が発生したほかのすべてのサーバーの作業負荷部分を吸収する超過容量があることが前提とされます。N+1 フェールオーバーでは、"+1" スタンバイサーバーが、超過容量の主要な場所であることが前提とされます。

フェールバック
ノードがオンラインに戻ったら、フェールオーバーマネージャは、いくつかのリソースグループを回復されたノードに移動することができます。これは、フェールバックと呼ばれます。リソースグループには、回復されたノードまたは再起動されたノードにフェールバックするために優先所有者を定義する必要があります。回復されたノードまたは再起動されたノードが優先所有者であるリソースグループは、現在の所有者から回復されたノードまたは再起動されたノードに移動されます。クラスタサービスには、ピークの処理時間のリソースグループのフェールバックに対する保護機能、または正常に回復または再起動されていないノードに対する保護機能があります。リソースグループのフェールバックプロパティには、フェールバックが許容される時刻と、フェールバックが試行される回数の制限が含まれます。

イベントプロセッサ

イベントプロセッサは、クラスタ内のノードで実行されるアプリケーションとクラスタサービスのコンポーネントの間でイベントをやりとりする電子配電盤として機能します。イベントプロセッサは、クラスタ対応アプリケーションにシグナルイベントを配信したり、クラスタオブジェクトを維持したりといった、多方面にわたるサービスを実行します。イベントプロセッサは、サーバークラスタに参加するための最初のエントリポイントです。クラスタサービスがノードで開始すると、イベントプロセッサがノードマネージャを呼び出して、クラスタに参加またはクラスタを形成する処理を開始するまで、ノードの外部状態はオフラインになります。

クラスタ内のほかのノードやクラスタサービス管理インターフェイスの視点から見ると、ノードは以下の 3 つの状態のどれかに明確に分類できます。これらの状態は、クラスタ内のほかのノードに表示され、イベントプロセッサによって管理されます。これらのクラスタサービスの状態は、以下のとおりです。

オフライン ノードは、クラスタの完全にアクティブなメンバではありません。ノードとそのクラスタサービスは、実行されている場合も実行されていない場合もあります。
オンライン ノードは、クラスタの完全にアクティブなメンバです。クラスタデータベースの更新を行い、クォーラムアルゴリズムに対して票決を提供し、ハートビートを維持し、リソースグループを所有して実行することができます。
一時停止 ノードは、クラスタの完全にアクティブなメンバです。クラスタデータベースの更新を行い、クォーラムアルゴリズムに対して票決を提供し、ハートビートを維持しますが、リソースグループを所有して実行することはできません。一時停止状態は、特定の保守を実行できるようにするためのものです。オンライン状態と一時停止状態は、大半のクラスタサービスコンポーネントによって、同等の状態として扱われます。

通信マネージャ

クラスタの各ノードのクラスタサービスは、ほかのノードで実行されるクラスタサービスと継続的に通信を行います。2 方向または 4 方向クラスタでの通信は、完全に接続されています。つまり、すべてのノードがほかのノードすべてと直接通信します。クラスタ内通信では、RPC メカニズムを使用して、各メッセージの信頼できる配信を保証します。

グローバル更新マネージャ

構成データベースマネージャは、グローバル更新マネージャによって提供される更新サービスを使用して、クラスタデータベースへの変更をすべてのノードで一貫して複製します。

リソースモニタ

リソースモニタは受動的な通信層であり、操作の開始はしませんが、クラスタサービスとリソース DLL の間の媒介として機能します。クラスタサービスがリソースの要求を行う場合、リソースモニタは、その要求を該当するリソース DLL に転送します。リソース DLL が状態を報告しなければならないか、またはクラスタサービスにイベントを通知しなければならない場合、リソースモニタは情報が確実に正しく配信されるようにします。

リソースモニタはクラスタサービスをリソースの障害から保護し、クラスタサービスに障害が発生した場合に対処するため、クラスタサービスとは別のプロセスで実行されます。リソースモニタは、クラスタサービスの障害を検出し、影響を受けるノードのリソースとグループすべてをオフラインに切り替えて対応します。

クラスタノードはすべて、1 つまたは複数のリソースモニタを実行します。既定の設定で、クラスタサービスは、ノードがホストであるすべてのリソースと対話する場合、1 つのリソースモニタだけを開始します。

メモ既定の単一のリソースモニタは、管理者が、クラスタアドミニストレータまたは別の管理アプリケーションのどちらかを使用して上書きできます。

ページのトップへ

クラスタリソース

クラスタサービスは、ダイナミックリンクライブラリ (DLL) として実装された同じ非透過オブジェクトとして、すべてのリソースを管理します。リソースをサーバークラスタで実行するためには、リソース DLL を介して、2、3の単純なインターフェイスとプロパティだけを提示する必要があります。Microsoft リソース DLL ファイルは、クラスタ対応アプリケーションとクラスタ非対応アプリケーションの両方をサポートするために用意されています。

リソースモニタは、システムアカウントの下で実行される特権コードとして、そのアドレス空間に特定のリソース DLL を読み込みます。システムアカウントとは、オペレーティングシステムおよび基本オペレーティングシステムに統合されたサービスによってのみ使用されるアカウントをいいます。システムアカウントを使用すると、クラスタサービスはオペレーティングシステムのコンテキスト内で各種の機能を実行できます。Windows 2000 または Windows NT の各システムのサービス、アドレスの指定、およびアカウントセキュリティのアーキテクチャについては、 http://www.microsoft.com/ntserver/nts/exec/prodstrat/nt_foundation.asp (英語)を参照してください。

Microsoft クラスタ対応アプリケーション用に Microsoft によって提供されているすべてのリソース DLL は、リソースモニタと呼ばれる単一のプロセスで実行されます。ISV またはサードパーティのリソース DLL は、クラスタアドミニストレータによって設定された、少なくとも 1 つのほかのリソースモニタで実行されます。リソースモニタは、リソースがクラスタノードにインストールされるか起動されると、必要に応じてクラスタサービスによって作成されます。

リソースがほかのリソースの可用性に依存して機能する場合、これらの依存関係をリソース DLL の一部にすることができます。クラスタサービスは、リソース DLL を使用してリソースをオンラインにし、クラスタ内のほかのリソースとの対話を管理します。あるリソースがほかのリソースに依存する場合、クラスタサービスは、依存対象のリソースが正しい順序でオンラインになって初めて、そのリソースをオンラインにします。

リソースは、同様の方法でオフラインになります。クラスタサービスは、依存するリソースすべてがオフラインになって初めてリソースをオフラインにします。これにより、リソースを読み込むときに依存関係が循環するのを防ぐことができます。

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

Windows NT Server 4.0 Enterprise Edition に提供されているリソース DLL を使用すると、クラスタサービスは以下のリソースをサポートできます。

ファイルおよび印刷共有
汎用サービスまたはアプリケーション
物理ディスク
Microsoft 分散トランザクションコーディネータ (MSDTC)
インターネット情報サービス (IIS)
メッセージキューイング
ネットワークアドレスと名前

Windows 2000 Advanced Server および Windows 2000 Datacenter Server には、以下の追加サービス用のリソース DLL が含まれます。

分散ファイルシステム (Dfs)
動的ホスト構成プロトコル (DHCP サービス)
ネットワークニュース転送プロトコル (NNTP)
簡易メッセージ転送プロトコル (SMTP)
Windows インターネットサービス (WINS)

独立したソフトウェアベンダ (ISV) のリソース DLL を使用すると、クラスタサービスはより広い範囲のアプリケーションをサポートできます。リソース DLL のインターフェイスは、以前にクラスタサービスソフトウェア開発キット (SDK) の一部として指定され発行されています。このインターフェイスを使用すると、アプリケーション開発者は、クラスタサービスベースのサーバークラスタで各自のアプリケーションの実行をサポートするリソース DLL を開発できます。クラスタサービスにリソース DLL を提供するアプリケーションは、クラスタ対応アプリケーションと呼ばれます。クラスタ対応アプリケーションを使用すると、高度な拡張性とフェ－ルオーバー機能が得られます。

たとえばデータベースサーバーアプリケーションでは、データベースリソース DLL を提供して、クラスタサービスがクラスタ内のあるノードから別のノードへ個々のデータベースをフェールオーバーできるようにすることが可能です。アプリケーション特定のデータベースリソース DLL がない場合、クラスタサービスは汎用サーバーアプリケーション (およびそのすべてのデータベース) 全体をフェ－ルオーバーすることしかできません。

アプリケーション特定のデータベースリソース DLL を提供すると、データベースはサーバープログラムではなく、フェ－ルオーバーの基本単位となります。サーバーアプリケーションがクラスタサービスによって管理されるリソースではなくなると、複数のサーバーを、それぞれ独自のデータベースセットを使用して、クラスタ内の異なる複数のノードで同時に実行できます。アプリケーションリソース DLL を提供することは、クラスタ全体の拡張を可能にするための最初のステップであり、すべてのクラスタ対応アプリケーションの要件となります。

アプリケーション特定のリソース DLL がないと、クラスタサービスは、クラスタサービスに提供された汎用サーバーリソース DLL しか使用できません。この汎用サーバー DLL は、サーバーアプリケーション全体とそのデータベースすべてをフェ－ルオーバーします。リソースはクラスタ内の 1 つのノードでしかアクティブにできないため、この場合クラスタは、アプリケーションサーバープログラムの単一の実行インスタンスとその関連データファイルに制限されてしまいます。クラスタサービスのリソース DLL を提供するサーバーアプリケーションの現在のリストについては、

(英語) を参照してください。

ページのトップへ

クラスタの管理

クラスタサービスには、クラスタリソース、ノード、およびクラスタそのものを管理するためのオートメーションインターフェイスがあります。クラスタアドミニストレータなどのアプリケーションおよび管理ツールは、クラスタ内のノードまたは外部コンピュータのどちらで実行されているかに関係なく、リモートプロシージャ呼び出しを使用して、このインターフェイスにアクセスできます。管理インターフェイスはいくつかのカテゴリに分けられ、それぞれにノード、リソース、リソースグループ、およびクラスタそのものなどの特定のクラスタコンポーネントが対応します。

オートメーションインターフェイスを使用して管理ツールをクラスタサービスに追加する方法については、Platform Software Developer Kit (SDK) の基本サービス、クラスタ管理の使用方法については、Windows 2000 Advanced Server と Windows 2000 Datacenter の各製品のヘルプを参照してください。

ページのトップへ

クラスタの形成と操作

次の項では、クラスタの作成と操作中のノードの動作について簡単に説明します。クラスタサービスをインストールする方法の詳細については、Windows 2000 および Windows NT Server 4.0 Enterprise Edition 製品のヘルプと導入ガイドを参照してください。

クラスタの作成

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

クラスタを作成する次のステップでは、管理者がクラスタのすべてのメンバが使用できる共通のデバイスを追加します。これにより、単一のノードと独自のローカルデータ記憶デバイス、およびクラスタ共通のリソースを持つ新しいクラスタが確立されます。これは通常、ディスクまたはデータ記憶装置と接続メディアリソースです。

クラスタ作成の最後のステップでは、クラスタのメンバとなる各追加コンピュータでインストールユーティリティを実行します。新しい各ノードがクラスタに追加されるたびに、クラスタの元のメンバから既存クラスタデータベースのコピーが自動的に渡されます。

クラスタへの参加

クラスタサービスは、Windows 2000 または Windows NT のサービス制御マネージャによって、各ノードで開始されます。クラスタサービスが開始されると、そのローカルの非共有デバイスが構成、マウントされます。スタートアッププロセス中、ノードはクラスタ全体のデバイスをオフラインにします。これは、ほかのノードがデバイスを使用する可能性があるからです。各ノードは検出プロセスを使用して、クラスタのほかのメンバを検出します。ノードはクラスタのメンバを発見すると、認証シーケンスを実行します。

最初のクラスタメンバは、新しいサーバーを認証し、新しいサーバーを正常に認証できた場合は、成功を示すステータスを返します。新しいノードがメンバとして認識されない、または無効なアカウントパスワードが検出された場合、クラスタへの参加要求は拒否されます。認証が正常に行われると、新しいノード上のクラスタデータベースが確認されます。このデータベースが最新のものではない場合、新しいサーバーを認証するクラスタノードは、そこにデータベースの更新されたコピーを送信します。複製されたデータベースを受信した参加ノードは、それを使用して共有リソースを検出し、必要に応じてそれらのリソースをオンラインにできます。

クラスタの形成

どのクラスタでも、1 つのリソースがクォーラムリソースとして指定されます。クォーラムリソースはデータの整合性とクラスタの統一性を維持し、クラスタ操作で重要な役割を果たします。これはクラスタの形成や参加などのノード操作を可能にするために必要です。

クォーラムリソースは、クラスタの作成時、またはクラスタ内のノード間のネットワーク通信が同じノードグループによる複数クラスタの形成を一時的に防止できない場合に、結合を禁止するものとして使用されます。クラスタを形成するために、ノードはクォーラムリソースを調整して所有する必要があります。たとえば、あるノードが発見プロセス中にクラスタを発見できない場合、そのノードはクォーラムリソースへアクセスすることによって、独自のクラスタを形成しようとします。

現在、クォーラムリソースとして使用可能なリソースの種類は、以下の属性をもつ物理ディスクだけです。

単一のノードがクォーラムリソースの物理的制御を獲得して保護できるようにする持続的な調整方法。たとえば、SCSI ディスクの予約および解除コマンドを使用すると、持続的な調整ができます。
クラスタ内のすべてのノードがアクセスできる物理記憶域。
NTFS の使用可能性。

メモ今後は、サードパーティの開発者は、上記の要件を満たしていれば、固有のクラスタ対応クォーラムリソースを作成できます。クラスタ対応製品の開発方法については、"Platform SDK Components for Windows Base Services Developers" MSDN オンラインを参照してください。

クォーラムリソースは、最新バージョンの構成データベースを、クラスタの構成と状態に関するデータのノードに依存しない記憶域を含む回復ログの形式で保存します。ノードがクラスタに参加する、またはクラスタを形成する場合、クラスタサービスは、ノードの構成データベースの専用コピーを更新します。ノードが既存のクラスタに参加する場合、クラスタサービスは、ほかのアクティブノードからデータを取得できます。ただし、ノードが最初にクラスタを形成する場合、ほかのノードは使用できません。

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

1 組のアクティブな通信ノードだけがクラスタとして動作できるように保証する。
ノードが、クォーラムリソースを制御できる場合にのみクラスタを形成できるようにする。
ノードが、クォーラムリソースを制御するノードと通信できる場合にのみ、既存クラスタに参加または存続できるようにする。

クラスタの終了

予定のシャットダウンが発生した場合、ノードはクラスタを終了すると、クラスタ内のほかのメンバすべてにClusterExit メッセージを送信して、終了することを通知します。ノードは応答を待機しないですぐにリソースのシャットダウンに進んで、すべてのクラスタ接続を閉じます。残りのノードは終了メッセージを受信しているため、ノードに予期しない障害が発生した場合、またはネットワーク通信が停止した場合に起こるクラスタメンバシップを再確立するための再グループ化プロセスを実行しません。

ページのトップへ

今後の方向

Windows ベースの製品が進化するにつれて、クラスタサービスは今後、以下の主要領域に焦点をおいて開発される予定です。

より大きな複数ノードクラスタ構成のための認証とサポート
新しい種類のハードウェアに対するサポートを含む、クラスタ構成のインストールと検査の簡略化
スクリプト化、リモート、および "ライトアウト (簡易式)" 管理に引き続き焦点を当てた、クラスタベースのアプリケーションおよびサービスの管理の簡素化と強化
クラスタベースの可用性と拡張性をより多くのシステムサービスに拡張
パフォーマンス、柔軟性、および管理を強化するために、Windows ベースのクラスタリング技術の基盤とインターフェイスをより密接に統合
高度な可用性および拡張性の両方の実現に向けて、クラスタ対応アプリケーションの開発、インストール、サポートを簡素化するためのサードパーティ ISV と企業の開発者に対するサポート