サーバ・クラスタの機能については第1回のサーバ・クラスタの用語説明において触れたが、ここではもう少し詳しく解説する。
■クラスタ・サービス
クラスタ・サービスはMSCSの中核となるサービスである。実体はClussvc.exeという実行ファイルだ。クラスタ・サービスはさまざまな役割を持っているが、主な役割として下記のようなものがある。
クラスタ・サービスは内部的には複数のコンポーネントで構成されている。例えば、フェイルオーバー処理を制御するFailover Managerや、イベント・ログの記録を行うEvent Log Replication Managerなどだ。これらのコンポーネントの理解は障害時などのログ解析などに役立つ。詳細は次回説明する。
■クラスタ・データベース
クラスタの各種構成はクラスタ・データベースと呼ばれるデータベースで構成される。クラスタ・データベースでは、クラスタのノード構成情報をはじめ、すべての構成が管理されている。
クラスタ・データベースはレジストリとして管理され、実体は「CLUSDB」というファイルだ。なお、クラスタ・データベースの構成はMSCSの管理ツールであるクラスタ・アドミニストレータのツリーに近い構造となっているため、比較的読みやすい。
レジストリ | HKLM\Cluster |
---|---|
ファイル | %Systemroot%\Cluster\CLUSDB |
■クォーラム・リソース
クォーラム・リソースは、チェックポイント・ファイル、クォーラム・ログの保持などを行う場所である。また、クラスタ構成時の調停処理に利用される。なお、クォーラム・リソースを持つ共有ディスクをクォーラム・ディスクと呼ぶ。
チェックポイント・ファイルは、世代管理された(履歴管理された)クラスタ・データベースだ。クラスタはフェイルオーバーすることで、クラスタ全体を管理するノードが切り替わる。ノードが切り替わった際のクラスタ再構成時に、このチェックポイント・ファイルを使用してクラスタ・データベースを最新の構成情報に復元する。チェックポイント・ファイルの物理ファイルは、「%QuorumDisk%\MSCS\chk*****.tmp」だ。ファイル名の * には世代番号が入り、レジストリにて最新の世代番号が管理されている。チェックポイント・ファイルのCLUSDBファイルと同じものだ。チェックポイント・ファイルは次のタイミングでローカルからクォーラムへコピーされて最新化される。
クォーラム・ログは、最新のチェックポイント・ファイル以降の更新履歴を保持するログ・ファイルだ。SQL Serverなどのデータベースで利用されるトランザクション・ログと同様の位置付けと思ってもらえればイメージしやすいだろう。クォーラム・ログの物理ファイルは「%QuorumDisk%\MSCS\quolog.log」ファイルで、標準で64Kbytesが最大サイズとなっている。この設定はクラスタの管理ツールであるクラスタ・アドミニストレータで変更可能だ。
クォーラム・リソースは、チェックポイント・ファイルやクォーラム・ログのような物理情報のほかに、クラスタ構成の調停作業に用いられ、「スプリット・ブレイン・シンドローム」の回避を行っている。スプリット・ブレイン・シンドロームとは、例えばクラスタ起動時や障害発生時にノード間での通信が切断されている場合、それぞれのノード自身が稼働系のノードとして認識してしまい、それぞれのノードでクラスタを構成し始め分裂状態に陥ることだ。MSCSではこの分裂状態を避けるために、クォーラム・リソースを所有できるかどうかで稼働系ノードを制御する。つまりクォーラム・リソースを保持しているノードだけがクラスタ・サービスを形成できる。
■クォーラム・リソースの種類
クォーラム・リソースには次の3つの種類がある。
種類 | 内容 |
---|---|
スタンダード・クォーラム | スタンダード・クォーラムは通常のクォーラム構成で、各ノードからアクセス可能な共有ディスクにクォーラムを配置する。クォーラム・リソースは共有ディスク上で1つだけ管理される |
ローカル・クォーラム | ローカル・クォーラムはノードのローカル・ディスクにクォーラムを保持する構成で、ほかのノードとはクォーラム・リソースを共有しないシングル・ノードのクラスタだ。障害時にフェイルオーバーすることもない。基本的には開発環境やクラスタ上で動作するアプリケーションなどの検証環境を目的として構成する |
マジョリティ・ノード・セット・クォーラム | マジョリティ・ノード・セット・クォーラムは、Windows Server 2003から追加されたクォーラム・リソースの構成だ。通常のクォーラム・リソースは共有ディスクに配置し、各クラスタ・ノードは単一のデータを参照するのに対し、マジョリティ・ノード・セット・クォーラムは共有ディスクを持たず、各ノードでクォーラム・リソースを管理し、ノード間で同期を取りながらクラスタを構成する。主に、遠隔地における物理的に離れたノード間でクラスタを構成するMirrored Disksクラスタ・モデルで利用される。構成するには、ノード間の通信が500msec以内で行える必要がある。さらに、「(クラスタの構成メンバー数/2)+1」以上の稼働ノードが必要となる。例えば、2台構成の場合は(2/2)+1で2台稼働、同様に3台構成の場合2台稼働、5台構成の場合3台稼働が必要となる |
■リソース
リソースとはクラスタ・サービスによって管理される物理的あるいは論理的な要素だ。物理的要素の例としてはディスク、論理的要素の例としては、IPアドレス、仮想サーバ、アプリケーション(サービス)などが挙げられる。リソースはそれぞれが何らかの機能(役割)を持っていて、リソース・モニタとリソースDLLによって管理/形成される。
■グループ
グループはファイル・システムでいうところのフォルダのようなもので、リソースの入れ物のようなものだ。グループはフェイルオーバーの単位でもあり、提供するサービスや、アプリケーションの単位ともいえる。依存関係の有効範囲などの境界線でもある。
■依存関係
依存関係は、必要とするリソースと必要とされるリソースの関係であり、ほかのリソースを開始するにはどのリソースを開始して利用しなければならないかを示す。Windowsのサービスの依存関係と同様だ。例えば、ネットワーク名リソースは、IPアドレス・リソースに依存しているため、IPアドレス・リソースがオンラインにならない限り、ネットワーク名リソースもオンラインになれない。つまりIPアドレスが存在しないのに、名前だけが存在することはできないわけだ。
Windows 2000 ServerのMSCSではリソース依存関係をある程度自分で定義する必要があったが、Windows Server 2003のMSCSからは適切なリソース依存関係が形成されていない場合は、何が足らないかを警告するようになっている。
そのほか、依存関係は以下のルールが成り立つ。
なお、依存関係をツリー構造で示したものを「Dependency Tree」という。
■フェイルオーバー
フェイルオーバーについては、第1回で障害発生時などに別のノードにサービスを切り替えることとして説明してきた。実際には一言で語れる単純な動作ではなく、フェイルオーバー時に行われる挙動にはいくつか理解するべきことがある。
まず、フェイルオーバーにはプッシュ型とプル型がある。プッシュ型は計画停止による手動フェイルオーバー、プル型は障害時による突発的なフェイルオーバーだ。プッシュ型でもプル型でもフェイルオーバーのアルゴリズムは変わらないが、突発的なフェイルオーバーは予定されていた処理が行えない可能性があるため、メモリ情報が破棄されデータを損なう可能性が、手動による計画停止に比べて高い。
次にMSCSではフェイルオーバーを実行する前に、リソースの再起動処理が設定可能だ。リソースが障害を起こした際には、いきなりフェイルオーバーを行うのではなく、定義された時間内に指定回数、同じノードでリソースを再起動して復旧できるか試みる。それでも復旧しない場合にのみ、フェイルオーバーが行われる。
そのほか、当然だが以下のような挙動をすることを理解する必要がある。
■フェイルバック
フェイルバックとは、障害を起こしてフェイルオーバーしたリソースが、ノード復旧後に、元のノードにリソースを戻す処理のことだ。基本的には、決められたノードでサービスを提供したい場合にフェイルバックの設定を行う。
フェイルバックを行うということは、再度フェイルオーバーを行うことと同じだ。そのため、ノードが復旧したからといって即時にフェイルオーバーされると、利用者にサービスを提供できない状態が数分間発生することになる。フェイルバックは時間帯の指定ができるので、夜間に実施するようスケジュールするか、24時間稼働のシステムの場合、フェイルバックの機能を用いずに計画的なフェイルオーバーを実施するのが好ましい。
Copyright© Digital Advantage Corp. All Rights Reserved.