クラスタの構成は、ほとんど（すべて）レジストリに格納されています。このレジストリ情報は各ノードのローカルドライブに保存されています。フェールオーバー時にクォーラムリソースから取得します。
レジストリファイルパス ： %windir%\Cluster\Clusdb
 |
クラスタのレジストリ構成は右図のとおり
HKLM\Cluster 以下に含まれます。
以下の説明では、各エントリの右側には、クラスタアドミニストレータで対応している場所を示しています。 Groups - [クラスタ名] - [グループ] NetworkInterfaces - [クラスタ名] -
[クラスタの構成] - [ネットワーク インターフェース] Network - [クラスタ名] -
[クラスタの構成] - [ネットワーク] Nodes - [クラスタ名] -
<ノード名> Resources - [クラスタ名] -
[リソース] ResourceType - [クラスタ名] -
[クラスタの構成] - [リソースの種類] |
クラスタにはクォーラムリソースという重要なリソースがあります。クォーラムリソースには以下の情報が格納されます。
クォーラムリソース（クォーラムリソースのあるディスク）を所有しているノードのみがクラスタサービスを提供できます。
クォーラムリソースは、次の用件を満たすディスクに保存する必要があります。
クォーラム用の共有ディスクには可能な限り、他のアプリケーションを入れないようにします。アプリケーションの障害と一緒にクォーラムもフェールオーバーしてしまい、ダウンタイムが長くなったり、アプリケーションが障害から復帰しない場合には、クラスタの管理自体ができなくなる可能性があります。
%QuorumDisk%\mscs\qoulog.log
片方のクラスタ上で変更された構成情報を保持しておきます。フェールオーバー時に、別ノードに
quolog.log
ファイルから、更新履歴を読み取りローカルレジストリに反映させます。
Clusdb = chk***.chk + quolog.log になっているはず。
%QuorumDisk%\mscs\chk***.tmp
chk***.tmp の * には、16
進数で示された数値（世代番号）が入ります。このファイルは、レジストリのチェックポイントファイルで、一時前のレジストリ情報を保持しています。regedt32.exe
にて、[ハイブのロード]
を行うと、中身が参照できます。クラスタ構成のリカバリーの時などにも役に立ちます。
HKLM\Cluster\RegistrySequence が最新の世代番号になる。
%QuorumDisk%\mscs\<GUID>\0000001.cpt
ファイル名の数値の部分は随時変わります。これは、ファイルパスに示された
GUID の [汎用アプリケーション] 及び [汎用サービス]
リソースの [レジストリの複製]
で設定されているレジストリ情報を保持しています。フェールオーバー時に、このファイルから別ノードのレジストリへ反映されます。このファイルも、regedt32.exe
の [ハイブのロード] で開くことが可能です。
Ownership
クラスタノードが起動したとき、もし他のノードがクォーラムリソースの所有者であったら、Join（結合/参加）を試みます。所有者がいない場合、自分が所有者になるようにクォーラムリソースを取得します。
| プロパティ クォーラムリソースの格納場所は、クラスタのプロパティから変更できます。クラスタのプロパティでは、クォーラムログのデフォルトサイズ変更や、内部通信用ネットワークの優先度を変更可能です。
|
 |
クラスタでは、パブリックネットワーク（Public Network）とプライベートネットワーク（Private Network）があります。パブリックネットワークは、クライアントからアクセスに応答します。プライベートネットワークは、クラスタノード同士の制御情報のやり取り（ハートビートなど）を行う専用のネットワークです。
ハートビート（Heartbeats）
他ノードが正常に動作しているかを確認する通信です。約
1.2 秒間隔に
バイトのパケットを飛ばします。ハートビートが 6 回連続返ってこないと障害と認識します。UDP ポートの 3343（0x0D0F） を使用します。ネットワーク上に流れるパケットは
82 バイトです。ハートビートは、別ノードが起動したアナウンスを受けたときから、相手のノードに対して行われます。別ノードが起動していないのに、ハートビートを出しつづけるわけではありません。
NIC の構成
クラスタを構成する場合、単一障害ポイント（a single point
of failure）を避けるために、NIC を 2 枚以上用意します。NIC 1
枚でも構成できますが推奨はしません。NIC が 1
枚の場合、その NIC
が故障したら内部通信もできなくなるためです。NIC が 2
枚ある場合は、一枚をプライベートネットワーク専用、もう一枚は全ての通信に使う（プライベートとパブリック）という設定にします。
NetBIOS の必要性
クラスタでは NetBIOS が必須です。Windows NT
との互換を保つためです。クラスタの内部通信にも NetBIOS
を使用します。従ってクラスタを構成する NIC では、「NetBIOS
over TCP/IP
を無効にする」の設定にはしないようにしてください。
NIC の追加
クラスタサービスは Kerberos は使用しません。NTLM
を使用します。したがって、クライアントも NTLM
を有効にする必要があります。
クラスタ構成後 NIC をハードウェアに追加すると、自動検出しパブリックネットワークとして使用します。また、一度 NIC を外して付け替えた場合、別の NIC として再設定して使用します。
IP の設定
仮想サーバー IP
アドレスは静的に設定する必要があります。DHCP
からの設定はできません。各のノードの IP アドレスは DHCP
から取得可能ですが、推奨はしていません。
ブラウジング
各ノード名、及びクラスタ仮想サーバー名はブラウジングの対象になります。クライアントにノード名を公開したくない場合は、"$"
を NetBIOS
名の最後につけてブラウジングの際に隠すようにします。
NIC の設定
ノードの NIC
の設定は、それを使用する仮想サーバーネットワークでも引き継ぎます。ノードの
TCP/IP の設定で、WINS や DNS
を使用する設定の場合、仮想サーバーも WINS や DNS
を使用します。
内部通信
ノード間でやり取りされる、制御通信です。主に以下のことを行っています。
アプリケーション依存ですが、クラスタログ（トランザクションデータ）が大きくなるようなら、回線速度の速いものにした方が安定します。通常クロスケーブルで結びます。
サブネット
全ノードは同一のサブネットに設定する必要があります。ルータを介して別サブネットにノードを作成した場合、IP
アドレスリソースをフェールオーバーしても動作しなくなります。
Fault Tolerant NIC
フォールトトレランス用 NIC
はプライベートネットワークに使用することは推奨しません。クラスタではプライベート
NIC
が障害を起こすと直ちに切り替わりますが、その妨げになったり、誤作動の原因となります。また、FT
用の余計なパケットが流れるので、遅延の原因にもなります。
IP Address リソースのフェールオーバー
IP Address がフェールオーバーした場合、ARP Broad Cast
が流れます。これによりサブネット内の全マシンの ARP
キャッシュが変更されます。セグメントが分かれたクライアントは、ルータのキャッシュが書き換わっているので問題ありません。arp
-a
コマンドで確認できるので、フェールオーバー前後を見比べることが可能です。
Cluster Network Driver
クラスタのネットワークドライバは %systemroot%\system32\drivers\ClusNet.sys
にあります。
リソースとはクラスタサービスによって管理する基本単位です。物理的あるいは論理的な要素です。一つ一つが何らかの機能（役割）を持っています。代表的なリソースとして下記のようなものがあります。
リソースがどういった状態にあるかは、リソースモニタ（Resource Monitor） が監視しています。しかし、リソースモニタは、直接リソースを監視しているわけではなく、リソース DLL（Resource DLL）を通して行っています。つまり、リソースモニタは、クラスタサービスとリソースの仲介役のような役割を果たしています。リソース DLL はクラスタ API を使用して作成されたダイナミックリンクライブラリです。リソースの監視の内容（どうなったらリソースが障害という判断をするか）はこのリソース DLL によって変化します。リソースモニタは、リソース DLL からの報告をまとめて、クラスタサービスに報告します。一つのリソースモニタは、1674 リソースをモニタできます。
汎用アプリケーションや、汎用サービスはリソース DLL を持ちません。障害の検知はプロセスが実行されているかを見て判断します。従って、ハングした場合など実行されているけど処理が停止している場合には、障害とみなせないので、リスタートやフェールオーバーは行われません。
リソースの設定は、両方のノードが起動している状態でｓあれば、リアルタイムに変更が別ノードへ渡されます。片方のノードが落ちている場合は、quolog.log に変更履歴を残します。
| プロパティ
リソースのプロパティではパラメータ以外の項目は、全てのリソースで同じです（設定値は違います）。詳細設定タブの中身を簡単に説明します。 [再開する][再開しない] [グループに適用する] [しきい値][期間] [Looks Alive ポーリング間隔] [Is Alive ポーリング間隔] [待ちのタイムアウト] |
 |
| 依存関係は、必要とするリソースと必要とされるリソースの
2
つのリソースの関係です。依存されているリソースがオンラインでない場合、依存するリソースはオンラインになることはできません。この関係は
Windows のサービスの関係と同じです。例えば、Computer
Browser サービスは、Server サービスと Workstation
サービスが起動してないと起動すことができません。これと同じように、ネットワーク名リソースは
IP アドレスリソースに依存しているので、IP
アドレスリソースがオンラインにならない限り、ネットワーク名リソースもオンラインになることはできません。
依存関係には以下のルールがあります。
|
単一方向のみの依存関係のみ可能 |
フェールオーバーとは、障害発生時に、リソースをあるノードから別のノードに移動する処理のことです。
リソースが障害を起こすと、まずは、そのノード内でリソースのリスタート（ReStart）処理が行われます。設定した時間内で、設定した回数リスタートに失敗した場合、フェールオーバー処理が行われます。
リソースが何を持って障害とみなすかは、リソース DLL にによるので、リソースによって違います。例えば SQL のリソースは SQL Query に追うとするかで判断しています。
フェールオーバー中はクライアントとの接続は切断されます。切断されている時間は、サービスが開始されるまでの時間なので、登録されているリソースによって異なります。クライアントアプリケーションは、自動的に再接続するように開発するか、運用で再接続を行わせるなどの対処が必要になります。IIS などの Web Server は ReLoad を行えばよいので、ユーザーに気付かれにくいです。
フェールオーバー時には、以下のことが発生するので、そのことを考慮して運用を考える必要があります。
フェールバックとは、障害を起こしフェールオーバーしたリソースが、障害復帰後もとのノードに戻る処理のことです。デフォルトではフェールバックの設定は無効になっています。フェールバックを利用したい場合は、優先所有者を決めて、いつフェールバックを行うかを指定します。時間の指定方法は、復帰後直ちに行うか、ある特定の時間帯になったら（深夜など）行うという 2 種類の設定方法があります。フェールバックの設定はグループごとに行います。
| グループのプロパティ
グループのプロパティで、フェールオーバーとフェールバックの設定を行います。 フェールオーバーの設定は [フェールオーバー] タブで行います。[しきい値] と [ 期間] は、そのグループが障害になるまでの時間間隔です。右図では、6 時間以内に 10 回フェールオーバーが行われたら、障害として認識されます。 フェールバックの設定は、まず、[全般] タブで、[優先所有者] を決めます。次に、[フェールバック] タブで、[フェールバックを許可する] にチェックをつけます。[すぐに] を選択すると、優先所有者で設定したノードが起動したら、すぐにフェールバックが行われます。[次の時間帯] でフェールバックを許可する時間帯を指定できます。この時間帯に優先所有者にノードでグループが実行されていなかったら、フェールバック処理が行われます。デフォルトでは [フェールバックを禁止する] にチェックが入っています。 フェールオーバーのしきい値のカウンタを元に戻すには、Cluster Service を再起動させるしか方法はありません。 |
|
SCSI
共有ディスクを選択する場合には SCSI
の規格をよく理解して選択します。詳しくは専門書などを参照してください。ここでは、簡単に用語とポイントなどをご紹介します。
| 規格 | pin | bit | Max Transfer (MB/s) | Internal Transfer Rate (MB/s) |
| SCSI and SCSIⅡ | 50 | 8 | 10 | 4 ～ 8 |
| Wide SCSI | 68 | 16 | 20 | 7 ～ 15.5 |
| Ultra SCSI | 50 | 8 | 20 | 7 ～ 15.5 |
| Ultra Wide | 68 | 16 | 40 | 7 ～ 30 |
| チェックポイント | 説明 |
| Bas Speed | デバイスインターフェースとカードインターフェース間の SCSI ケーブル上のデータ転送速度。Bas Speed が遅いとディスクの速度を生かせない場合がある。 |
| Internal Transfer Rate | ハードディスクの内部転送速度。 |
| Max Bus Length *1 | バスの終端から終端までの長さ。 |
* 1 現在 SCSI で使用されているインターフェース信号形式
1. SE（Single ended）
普通の SCSI インターフェース信号形式。ノイズの影響を受けやすく、規格が高速化する度に最大長が短くなる。
2. HVD（High Volume Differential）
耐ノイズ性向上。バス最大長 25 メートルまで可能。日本では余り使われなかった信号方式。
3. LVD（Low Volume Differential）
耐ノイズ性プラス転送速度も向上。
| ターミネータ（Terminator） | 説明 |
| Passive Termed | SCSIⅠの頃から標準で使用されている。最もシンプルな形式。 |
| Active Temed | SCSIⅡの標準。電圧調整機能付。 |
| FPT | Force Perfect Termination。Active タイプから進化したもの。波形補正機能付。 |
| ターミネータは 4.5v
以上電源がないと機能しないことがあります。ターミネータ用の電源が確保できるとより安全です。 クラスタの場合、オンボードターミネータを使用するか、Yケーブルを使用したほうがよいでしょう。オンボードの場合、電気が通ってないと動作しないものがあるので、全ノードを起動しておき、Boot.ini の画面で片方を止めておくなどの対処が必要な場合があります。 |
|
| SCSI BIOS 設定 | 説明 |
| SCSI ID の重複 | SCSI カードのデフォルト ID は 7 に設定されていることが多い。クラスタ構成の場合、2枚のカードが一つのバス上にあるので、ID が重複する。一般的に一枚を ID6 に変更する。 |
| Bus Reset の無効 | SCSI の機能でディスクの Ownership 情報が不正になる可能性があるので、予め Disabled に設定しておいた方がよい。 |
ファイバーチャネル（Fibre Channel）
ファイバーチャネルはANSI
X3T11（SCSI3)で規定されています。以下に特徴をあげます。
信頼性
共有ディスクは、自動修復や、簡単に CHKDSK
を行えないので、STOP
などで落ちたときに安全性の確保ができません。共有ディスクに
SCSI を使用した場合 Software RAID は使用できません。Hardware
RAID は構成可能なので、データを守るためには Hardware RAID
を使用します。ただし、各ノードのローカルディスクは
Software RAID を使用できます。
ドライブレター
共有ディスクのドライブレターは、最後の方から付けた方がよいです。CD-R
などの追加により、頭の方のドライブレターが加わり、共有ディスクのドライブレターもずれてしまう可能性があります。ドライブレターが変わるとクラスタは動作しなくなってしまいます。
Cluster Disk Driver
クラスタのディスクドライバは、%systemroot%\system32\driveres\ClusDisk.sys
にあります。
Challenge/Define Protocol
クラスタサービスでは、一つのディスクを一台のノードが占有します。その時の制御アルゴリズムを
Challenge/Define Protocol
といいます。ノードがディスクを所有するとセマフォに
"lease"
と書き込みます。セマフォとは、複数のプログラムが協調する際に利用するフラグのようなものです。もしディスク所有者がもう、ディスクにアクセスする必要がないなら、セマフォをクリアして、他のコンピュータが
Reserve できるように Release
コマンドを出します。所有者が障害を起こしている場合には、他のノードが所有者になるために、セマフォをクリアして
10 秒待ちます。10 秒とは、Renewal 要求に 3 秒、SCSI
バスが安定するまでに 2 秒、これを 2 回行った数値です。10
秒たっても、所有者がいないようなら、他のノードが Reserve
コマンドを使用し、ディスクを取得します。
クラスタの内部では以下のコンポーネントが、それぞれ役割を持ち動作しています。
Event Processor
イベントプロセッサは、クラスタサービスで通信の中核となるコンポーネントです。アプリケーションと、クラスタサービスのほかのコンポーネントを結び付けます。また、クラスタサービスの起動や、ノードのオフライン状態にする役割も果たします。クラスタの形成や、参加などの処理を開始するために
Node Manager
を呼び出す役割もあります。その他、下記の機能を有します。
Node Manager
ノードマネージャは、他のノードのエラー検出を行います。具体的にはハートビートのやり取りを行います。別ノードが停止中と判断した場合には、ハードビートの送信を止めます。ハートビートが途切れたら
Failover Manager と Membership Manager に報告をします。
何らかの原因で、ノード間通信のみ普通になり、各ノードは正常に動作しているとします。この場合、お互いのノードで相手のリソースを自分のノードでオンラインにしようと試みます。しかし、これでは両方でオンラインに使用と動作し、整合性が取れなくなるので、クォーラムリソースを制御しているノードで全てのリソースをオンラインにします。
Membership Manager
メンバーシップマネージャは、どのメンバーがクラスタとして動作しているかを把握します。主に以下の処理を行います。このときの通信はユニキャストで行われます。
Global Update Manager
グローバルアップデートマネージャは、変更情報を別のノードにマップ（複製）を行います。また、リソースの状態の変化を、クラスタ内のノードに用意に通知できる仕組みを提供します。
Database Manager
データベースマネージャは、クラスタデータベースの管理を行います。GUM
から通知が来たら、Local DB
に情報を反映させます。他のノードのデータベースと矛盾が生じないように、お互いに協調しています。
Log Manager
ログマネージャはいずれかのノードが動作していないときは、quolog.log
へ構成変更履歴書き込みを行います。また、チェックポイントファイル（chk***.tmp）などとも協調しています。
Resource Manager/Failover Manager
リソースマネージャはリソースをモニタしリスタート処理を行うように手配します。リスタートに失敗し、障害と検知したら、フェールオーバーマネージャに要求を出します。その後、フェールオーバーマネージャが処理を行います。
Pushing a group
リブートなどでノード自らサービスを停止するときは、停止することを他のノードに通知する。自分から押し出すので
Push になります。
Pulling a group
ハードビートが 6 回失敗すると障害になり、Regroup
処理が開始され、他のノードのリソースを引き込みます。相手から引っ張るので
Pull になります。
Communication Manager
コミュニケーションマネージャは他のノードのコミュニケーションマネージャと通信するコンポーネントです。Membership
Manager
から障害通知を受けると、そのノードとはやり取りをしないという制御も行っています。内部通信は
RPC を使用します。
クラスタで使用できる API は大きく 3 種類に分けられ、それぞれに用途があります。
Cluster API
クラスタ管理用の API です。
Resource API
リソース管理を行うためのインターフェースを提供する
API です。
Cluster Administrator Extension API
クラスタアドミニストレータ上で、カスタムリソース DLL
を管理できるようにするインターフェースです。
Extension DLL をレジストリに登録する場合には、下記のコマンドで可能です。
RegClAdm [/Ccvluster] [drive:] [path] <Extension DLL>
* 少々難しいので、説明がわかりにくいかと思います。申し訳ございません。
