サーバーの可用性の計画、実装、保守 - パソコンとパソコンをつなぐものですね

■　 /changepass[word][:new_password[,old_password]] を使用してCluster.exe を実行すると、ドメインコントローラとすべてのクラスタノードのクラスタサービスアカウントのパスワードが old_password から new_password に変更されます。コマンドの一部として入力しないと、new_password と old_password のいずれかまたは両方の入力を求めるメッセージが表示されます。2 つの二重引用符 ("") を入力すると、空のパスワードを指定できます。

■すべてのノードが正常であるが、クォーラムディスクが機能しない場合、クラスタノードを起動することはできますが、どのノードでもクラスタサービスを起動することができません。　ドライブ自体が故障している場合は、クォーラムディスクを取り替えます。
fixquorum フラグを使用してクラスタサービスを起動し (fixquorum を使用すると、クォーラムディスクが壊れていてオンラインに出来ないクラスタサービスを起動することが出来ますが、データを修正することは出来ません)、それから代替のクォーラムディスクを選択します (予備のディスクがない場合には、ローカルクォーラムを使用することができます)。　新しいクォーラムを設定することにより、そのクォーラム上に新しいクォーラムログファイルが作成されます。　しかし、レジストリチェックポイントファイルは復元されません。古いクォーラムを利用できないからです。

■アプリケーションごとに、そのアプリケーションがどのCPUを使用するかという関係付けのことを「アフィニティ（affinity、関係とか有縁性などという意味）」といい、日本語Windows OSでは「関係」という用語で呼んでいる。またアプリケーションとCPUの対応状況をアフィニティ・マスクと呼ぶ。

■Windows Server 2003 では、IGMP サポートという新機能を提供しています。この機能は、フラッディングを NLB マシンが接続されているスイッチのポートのみに制限する場合に役立ちます。これにより、NLB ではないマシンは NLB クラスタのみに向けられたトラフィックを無視します。一方、全ての NLB マシンはクラスタに向けられたトラフィックを認識し、NLB アルゴリズムの要求を満たします。ただし、IGMP サポートは NLB がマルチキャストモードに構成されている場合のみに有効になります。

マルチキャストサポートを有効にするには

・ネットワーク負荷分散マネージャを開きます。
・ネットワーク負荷分散マネージャにクラスタが表示されていない場合は、クラスタに接続します。
・クラスタを右クリックし、[クラスタのプロパティ] をクリックします。
・ [クラスタパラメータ] タブの [クラスタ操作モード] で、[マルチキャスト] を選択します。
必要に応じて、[IGMP マルチキャスト] チェックボックスをオンにして、インターネットグループ管理プロトコル (IGMP) サポートを有効にするができます。

■Active Directory データの Authoritative Restore を行うには、システム状態データを復元した後でサーバーを再起動する前に、Ntdsutil ユーティリティを実行する必要があります。Ntdsutil ユーティリティを使用すると、Active Directory オブジェクトを Authoritative Restore としてマークできます。オブジェクトが Authoritative Restore としてマークされているとき、Active Directory レプリケーションシステム内にあるその他の更新シーケンス番号よりも大きくなるように、その更新シーケンス番号が変更されます。これによって、復元するすべてのレプリケートされたデータや配布データを組織全体に適切にレプリケートまたは配布できるようになります。

たとえば、Active Directory ディレクトリサービスに格納されたオブジェクトを誤って削除または変更し、これらのオブジェクトが他のサーバーにレプリケートされるか配布されていた場合、これらのオブジェクトの Authoritative Restore を行い、他のサーバーにレプリケートまたは配布されるようにする必要があります。オブジェクトの Authoritative Restore を行わない場合、オブジェクトは他のサーバーにレプリケートまたは配布されることはありません。これは、他のサーバー上に現在存在するオブジェクトより古いオブジェクトであると見なされるためです。Ntdsutil ユーティリティを使用して Authoritative Restore のオブジェクトをマークすると、復元するデータを組織内でレプリケートまたは配布できるようになります。

■/redirect
このスイッチは、Windows Server 2003 Enterprise Edition ベースのコンピュータ上で緊急管理サービス (EMS) を有効にするために使用します。EMS の詳細については、Windows のヘルプとサポートで「緊急管理サービス」を検索してください。

x86 ベースのコンピュータ上で Boot.ini を編集して EMS を有効にするには、以下のように、Boot.ini ファイルの [boot loader] セクションと [operating systems] セクションを編集します。

■[緊急管理サービス] のコンソールのリダイレクトをサポートするコンポーネント

[緊急管理サービス] のコンソールのリダイレクトをサポートするコンポーネントは、セットアップローダー、テキストモードセットアップ、回復コンソール、リモートインストールサービス (RIS)、ローダー、および STOP エラーメッセージです。　[緊急管理サービス] を使って実行するようにオペレーティングシステムが構成されている場合、これらのコンポーネントは、帯域外管理ポートとビデオカード (接続されている場合) に出力をリダイレクトします。　ただし、[緊急管理サービス] は、ビデオカードと共に使用することも、ビデオカードなしで使用することもできます。　すべての [緊急管理サービス] の出力には、ターミナルエミュレータを使用してアクセスできます。

Windows Server 2003 オペレーティングシステムをセットアップした後に緊急管理サービスを有効にするためには、WindowsローダコンソールリダイレクトおよびSpecial Administration Console（SAC）を有効にするために、boot.iniファイルを編集する必要があります。　Boot.iniファイルによって、スタートアップを制御します。

Unattend.txtおよびWinnt.sifファイルは、リモートでWindows Server 2003をインストールするプロセスを完全に自動化するために必要です。　EMSBaudRateは、シリアルポートの容量によって設定します。　デフォルトは9600です。　このパラメータは、EMSPortとともに使用されます。

■今回のMSCS構成シナリオでは、クラスタ構成で一番スタンダードな共有ディスクを持つ2ノードのクラスタ構成を作成する。この構成では、クラスタ構成ノードとして2つのサーバとActive Directory ドメイン・コントローラの合計3台のサーバが最低限必要となる（各ノードをドメイン・コントローラにすることで、2台のサーバのみで構築することも可能）。

■リソースの再起動処理が設定可能だ。リソースが障害を起こした際には、いきなりフェイルオーバーを行うのではなく、定義された時間内に指定回数、同じノードでリソースを再起動して復旧できるか試みる。それでも復旧しない場合にのみ、フェイルオーバーが行われる。

そのほか、当然だが以下のような挙動をすることを理解する必要がある。

・メモリ情報は基本的にクリアされて引き継がれない
・リソースDLLで定義されていないレジストリ情報は失われる
・コミットされていないディスク情報は失われる
・クライアントとの接続は切断される

■クォーラム・リソースは、チェックポイント・ファイルやクォーラム・ログのような物理情報のほかに、クラスタ構成の調停作業に用いられ、「スプリット・ブレイン・シンドローム」の回避を行っている。スプリット・ブレイン・シンドロームとは、例えばクラスタ起動時や障害発生時にノード間での通信が切断されている場合、それぞれのノード自身が稼働系のノードとして認識してしまい、それぞれのノードでクラスタを構成し始め分裂状態に陥ることだ。MSCSではこの分裂状態を避けるために、クォーラム・リソースを所有できるかどうかで稼働系ノードを制御する。つまりクォーラム・リソースを保持しているノードだけがクラスタ・サービスを形成できる。

■クォーラム・ログは、最新のチェックポイント・ファイル以降の更新履歴を保持するログ・ファイルだ。SQL Serverなどのデータベースで利用されるトランザクション・ログと同様の位置付けと思ってもらえればイメージしやすいだろう。クォーラム・ログの物理ファイルは「%QuorumDisk%\MSCS\quolog.log」ファイルで、標準で64Kbytesが最大サイズとなっている。この設定はクラスタの管理ツールであるクラスタ・アドミニストレータで変更可能だ。

■チェックポイント・ファイルを使用してクラスタ・データベースを最新の構成情報に復元する。チェックポイント・ファイルの物理ファイルは、「%QuorumDisk%\MSCS\chk*****.tmp」だ。ファイル名の * には世代番号が入り、レジストリにて最新の世代番号が管理されている。チェックポイント・ファイルのCLUSDBファイルと同じものだ。チェックポイント・ファイルは次のタイミングでローカルからクォーラムへコピーされて最新化される。

・クラスタを形成したとき
・ノードがダウンしたとき
・クォーラム・ログのサイズが制限まで達したとき（デフォルトは64Kbytes）
・定期的なチェックポイント（デフォルトは4時間）

■クラスタ・データベースはレジストリとして管理され、実体は「CLUSDB」というファイルだ。
レジストリHKLM\Cluster
ファイル%Systemroot%\Cluster\CLUSDB

■次に各ノードにSCSIアダプタを用意する。なお、Windows Server 2008からはパラレルSCSIのサポートが行われなくなった。加えて1台以上のSCSI共有ディスク、またはSANなどのネットワーク共有ディスクが必要となる。

■準備が必要なハードウェア要件としては、すべてのノードで2枚以上のネットワーク・アダプタが必要である。1つはクライアント・アクセスのために使用し、もう1つはノード間のハート・ビート用に用意する。クライアント・アクセスのためのネットワークだけでもハート・ビートのやりとりは可能だが、障害の誤認識のもととなるため、専用に用意するのが一般的だ。また、その際にはクロス・ケーブルを使用してノード間を直接接続する。ハブなどを経由するとそこがSPOF（単一障害ポイント）となり得る可能性が増すからだ。

■また、前述したようにMSCSはクラスタへの参加という形でクラスタ・ノードを構成できるため、障害が発生したノードを切り離し、新しいノードを加えるなどで暫定対応し、その間に落ち着いて障害の分析などを行えばよいという利点もある。

■MSCSの実態はサービスであるため、Windowsのサービスから確認できるなど、Windowsの管理に慣れていれば、比較的受け入れやすい。

■Windows 2000 ServerのMSCSとWindows Server 2003のMSCSの混在環境がサポートされているため、Windowsのアップデートでさえローリング・アップグレードで対応可能であった。ただしWindows Server 2008は、ほかのWindowsバージョンとのMSCSの互換性がないため、ローリング・アップグレードはサポートされない。これは、Windows Server 2008が共有ディスクにSCSIをサポートしなくなったことによる考慮と思われる。

■ローリング・アップグレードは、メンテナンスを行うノードをフェイルオーバーさせ、待機系ノードがサービスを提供しているうちに、メンテナンスを行う手法だ。メンテナンスが終わったら同じようにフェイルオーバーして切り替え、順番にメンテナンスすることで最小限のダウンタイムでメンテナンスが可能になる。