SE の雑記

久しぶりにクラスタ関連の投稿を。
といっても私はクラスタのエンジニアではないのですが…。

今まで、クラスタの構築は何件か投稿しているのですが、設定項目についてきちんとまとめたことがありませんでした。
いくつか調べたいことがあったので、小出しにクラスタの設定項目を確認していきたいと思います。

[構築ができる = 知っている] と思われることって多々ありますよね。会社の技術レベルによるのでしょうか？？
構築は事前に検証して、手順書があれば対応できるパターンが多いとおもいますので、構築だけで終わってしまうと、
その技術を知っていると言えるレベルには達しないですよね…。
このあたりの考え方の違いが今の会社とのスキルレベルに関して埋まらな溝なんだろうな～と最近ひしひしと感じます。
# 最近、自分のスキルレベルについて不安がいっぱいです。

まずは、リソース モニターについて。

リソース モニター関連の設定として
– [このリソースを別のリソース モニターで実行する]
という項目があります。

– Windows Server 2003 R2 –

– Windows Server 2008 R2 –
?

リソース モニターは各クラスタリソースの制御 / 監視をするためのもので、この設定はリソース単位で設定することができます。
SysInternals の Process Explorer を使用して、クラスタのプロセスの階層を見てみます。
Process Explorer

– Windows Server 2003 R2 –

– Windows Server 2008 R2 –

2003 と 2008 ではプロセス名が違うのですが、[resrcmon.exe] / [rhs.exe] がリソース モニターのプロセスとなります。
[このリソースを別の リソースモニターで実行する] が有効になっているとそのリソース単位でリソースモニターの
プロセスが起動されることになります。
# クラスタのサービスは [clussvc.exe] で制御がされていますので、各リソースモニターの親プロセスが [clussvc.exe] となっています。

各リソース モニターが対象リソースのリソース DLL をロードして、リソースの制御 / 監視が行われるという仕組みのようです。
2008 のプロセスを確認していたところ、リソース DLL をロードしているのが確認できたものがありました。

上の画像だと、[clusres.dll] がリソース DLL となります。
この DLL は標準で用意されているリソースのリソース DLL ですね。

ためしにこのプロセスを強制終了させてみました。
するとイベントビューアにエラーが出力され、一部のリソースがオフライン→自動でオンラインとなりました。

終了させたプロセスで制御されていたリソースだけがオフラインになったようですね。
別のリソースモニターで制御されているリソースには影響は無かったようです。

各リソースで独立したモニターを起動させることで、プロセスのハングアップした際の影響を分散させることができそうですね。
ただし、複数のプロセスが起動する分オーバーヘッドはあるのでしょうが。
後は一つのプロセス モニターではリソース DLL が競合してしまうような場合に設定を変更することもあるのかと。

リソースによっては、別のリソース モニターは使わないことが推奨されている場合もあったはずなので、この辺はリソースに
合わせて柔軟に設定する必要がありそうです。
# 別のリソース モニターを使うことが推奨される場合もあったはずです。

SQL Server のクラスタ構成では Is Alive のチェックで定期的な間隔 (デフォルトは 1 分) で

SELECT @@servername

が実行され、クラスタリソースの起動状況の確認がされます。

Windows Server 2003 上で SQL Server を MSCS で構築した場合は、Is Alive のチェックには、
クラスタサービスのサービスアカウント (ドメインユーザー) が使用されていました。
そのため、SQL Server のログインからクラスタのサービスアカウントを消してしまうとリソースが
起動できなくなります。

Windows Server 2008 の WSFC では、クラスタのサービスの起動アカウントはドメインユーザーではなく、
ローカルシステムアカウントで起動されます。

Windows Server 2008 だと、Is Alive のチェックはローカルシステムアカウントで実行されているのか
気になって調べてみました。

手っ取り早く調べるため、SQL Server Profiler を実行して確認してみました。

WSFC + SQL Server ではローカルシステムアカウントで Is Alive のチェックが実行されているようですね。

クラスタのサービスアカウントでチェックがされるという動作は WSFC でも変わらないようです。

今回、Windows Server 2008 R2 で SQL Server を 3 インスタンス起動させた Active / Active / Active / Passive (AAAP) の
クラスタを構築したのは Windows Server 2008 の WSFC で AntiAffinityClassNames プロパティが動くことの検証を
したかったためです。

[AntiAffinityClassNames] は 3 ノード以上のクラスタでクラスタグループに設定するプロパティになります。
サーバー クラスタ : Windows Server 2003 のクラスタ構成の推奨事例
ホット スペア サポートのための Windows クラスタ グループ構成方法

3 ノード以上のクラスタの場合、1 ノードを待機ノードとして設定するのが一般的な構成です。

ノード 1	ノード 2	ノード 3
Active (稼働ノード)	Active (稼働ノード)	Passive (待機ノード)
サービス A	サービス B	N/A

この状態でノード障害が起きた時にリソースがどのように配置されるかというと、

ノード 1	ノード 2	ノード 3
Active (稼働ノード)	障害	Active (稼働ノード)
サービス A	N/A	サービス B

となることもありますが、

ノード 1	ノード 2	ノード 3
Active (稼働ノード)	障害	Passive (待機ノード)
サービス A / サービス B	N/A	N/A

となることもあります。
優先所有者が設定されている場合は、優先所有者にフェールオーバーされますが、障害はどのノードで発生するか
わかりませんので、優先所有者の設定で 1 ノードでサービスが 2 つ起動しないようにするのは大変です。
# 優先所有者がすべて障害だった場合は、実行可能なノード内でランダムにリソースが配置されます。

このような時に使用するのが、[AntiAffinityClassNames] になります。
[AntiAffinityClassNames] を設定すると、リソースを実行していないノードがある場合はそのノードに
優先的にリソースの移動をさせることができるようになります。
この設定は優先所有者より優先されます。

設定はクラスタグループに以下のように行います。

クラスタグループ	サービス A	サービス B
AntiAffinityClassNames	MSSQL	MSSQL

[サービス A] と [サービス B] に [MSSQL] という [AntiAffinityClassNames] を設定しています。
これにより、リソースが移動する際に [MSSQL] という [AntiAffinityClassNames] が設定されているグループを
実行しているノードには、同一の [AntiAffinityClassNames] の移動を優先的には行わないようになります。

ノード 1	ノード 2	ノード 3
Active (稼働ノード)	Active (稼働ノード)	Passive (待機ノード)
サービス A	サービス B	?

の状態で [ノード 2] で障害が発生した場合、リソースの移動先は [ノード 1] / [ノード 3] のどちらかになります。
[サービス B] の [AntiAffinityClassNames] には [MSSQL] という値が設定されています。
[サービス A] の [AntiAffinityClassNames] にも [MSSQL] が設定されているため、このグループが動いているノード
[ノード 1] は優先的な移動対象から外し、[ノード 3] で [サービス B] が実行されます。
# 同一の [AntiAffinityClassNames] が設定されているノードは排他で考え、優先的な移動先から外します。
　ただし、厳密な排他ではありませんので、他に稼働できるノードがない場合は、同一の [AntiAffinityClassNames] が
　設定されているグループを複数実行する形になります。

この設定により、3 ノード以上のクラスタで、待機ノードを有効に使用できるようにすることが可能です。

今回の検証環境では SQL Server のインスタンスは以下のように配置しています。

この状態で [2008R-NODE-03] のクラスタサービスが停止した場合、インスタンスを起動していない、
[2008R2-NODE-04] にリソースが移動するでしょうか？

[2008R2-NODE-04] に移動してしまいました…。
5,6 回試したのですが、リソースが動いていないノードに移動してくれていました。

何回か試していると、既にリソースが動いているノードにも移動される予定だったのですが、
待機系のノードにリソースが移動されてしまいました。
2008 のクラスタになってこの辺りの制御ロジックって変わったのでしょうか？？

これだと [AntiAffinityClassNames] の挙動が確認できないので [INSTANCE3] の優先所有者として
[2008R2-NODE-01] を設定して、各グループに [AntiAffinityClassNames] を設定してみました。

[AntiAffinityClassNames] は以下のコマンドで設定できます。

cluster group “<グループ名>” /prop AntiAffinityClassNames=”<一意の識別名>” 例) cluster group “SQL Server (INSTANCE1)” /prop AntiAffinityClassNames=”MSSQL” cluster group “SQL Server (INSTANCE2)” /prop AntiAffinityClassNames=”MSSQL” cluster group “SQL Server (INSTANCE3)” /prop AntiAffinityClassNames=”MSSQL”

?

優先所有者だけが設定されている場合、[2008R2-NODE-03] を停止すると、[2008R2-NODE-04] にリソースが移動し、
[2008R2-NODE-03] 起動後に [2008R2-NODE-04] を停止すると、[2008R2-NODE-01] でリソースが実行されました。
# なんだか納得いかない動きですが…。

[AntiAffinityClassNames] を設定すると、[2008R2-NODE-03] が停止すると、[2008R2-NODE-04] にリソースが移動し、
[2008R2-NODE-03] 起動後に [2008R2-NODE-04] を停止すると、[2008R2-NODE-03] でリソースが実行されました。

停止時の動きが変わっているの [AntiAffinityClassNames] の設定により、リソースの移動先が選定されているように見えます。

3 ノード以上は Windows Server 2008 でも [AntiAffinityClassNames] の設定は必要そうですね。

その 2 でノードの追加手順を書こうと思っていたのですが、クラスタのインストールで補足して書いておきたい
内容がありましたので 1.5 として補足編を。

[インストール時に使用できるディスク]

クラスタの共有ディスクはインストーラーを実行しているノードがリソースを保有している必要があります。
ノードがディスクを保有していない場合、セットアップのルールチェックで以下のエラーとなります。

事前に SQL Server をインストールしているグループを作って、ディスクリソースをグループに割り当てている場合は、
ノードの移動で、インストーラーを起動しているノードにグループを移動します。

ただし、グループにディスクを割り当てていない時にディスクが割り当てられている [使用可能記憶域] に
ディスクが存在している場合は GUI からはディスクを特定のノードに移動させることができません。

今は [2008R2-NODE-02] にディスクが割り当てられていますが、インストーラーは [2008R2-NODE-01] で実行しています。
ディスクを移動させるためにはコマンドで移動させます。
# コマンドプロンプトは管理者として実行する必要があります。

>cluster group "使用可能記憶域" /MOVETO:%COMPUTERNAME% リソース グループ ‘使用可能記憶域’ を移動しています… グループ???????????? ノード????????? 状態 ——————– ————— —— 使用可能記憶域????????????? 2008R2-NODE-01? オンライン

使用可能記憶域の実体はクラスタグループなので、グループの移動をすることで未割当の共有ディスクを
所有しているノードが変更できます。

[SQL Server 仮想ホストのコンピュータアカウント]

事前にコンピュータアカウントを作成していない場合、SQL Server の仮想ホストは [Computers] に作成されます。
?

このとき、コンピュータアカウントは WSFC の仮想コンピュータが作成を行っています。
今回、クラスタは [2008R2-WSFC-01] としていますので、[SQL-WSFC-01] の作成者は [2008R2-WSFC-01] になります。
作成者は、属性エディタや ADSI Edit で [mS-DS-CreatorSID] を表示すると確認できます。
[mS-DS-CreatorSID] に表示されている SID が作成者の SID ですので [objectSid] が表示内容になっているものが
作成に使われたアカウントになります。

2008 のクラスタを構築する際にコンピュータアカウントを事前に作成しておく場合は、コンピュータアカウントに
クラスタを構築する際に使用しているドメインユーザーのフルコントロールを付与しますが、SQL Server の
クラスタの場合には、WSFC の仮想コンピュータ名のフルコントロールを付与しておきます。

事前にコンピュータアカウントを作成していない場合に、自動で作成されるコンピュータアカウントにはフルコントロールは
付与されていないのですが、事前に作成する場合はフルコントロールがないと、コンピュータ名のリソースがオンラインにできませんでした。
自動作成の時と同じ権限を付与して試したのですが、コンピュータアカウントのパスワードリセットができずにエラーとなっていました。
コンピュータアカウントのパスワード関連の権限も付与してはいたのですが。

以下の画像が事前にコンピュータアカウントを作成した場合に、WSFC の仮想コンピュータアカウントにフルコントロールを
付与した設定になります。
コンピュータアカウントに権限を付与しているのでユーザー名は [2008R2-WSFC-01$] となっています。
# コンピュータアカウントを指定する場合は最後に [$] が入ります。

[サービス SID とドメイングループ]

インストールするときにサービス SID を使うかドメイングループを使うかの選択がありますが、どこに使われているかというと
フォルダのアクセス権やディレクトリのアクセス権で使用されています。

左がサービス SID を使用する設定でインストールしたインスタンスのデータディレクトリのアクセス権、
右がドメイングループを使用する設定でインストールしたインスタンスのデータディレクトリのアクセス権になります。
# ドメイン名は塗りつぶしています。

[MSSQL$INSTANCE1] となっていますが実際には、[NT ServiceMSSQL$INSTANCE1] となります。
Windows サービス アカウントの設定

Vista ごとはサービスも SID が持て、特定のサービスがアクセスできる領域を制限することができます。
今まではサービスの起動アカウントに対して権限が付与されていましたが、サービス自体にセキュリティを
付与することができるようになっています。

サービス SID はイベントビューアの evt ファイルのセキュリティなどにも使われており、以下はアプリケーションログの
ファイルのセキュリティですが、[eventlog] という [Windows Event Log] サービスのサービス SID にアクセス権が
設定されています。

サービスをさらに低い権限で動かすためにサービス SID は使われているようです。

ドメイングループを使用する場合、ドメイングループの中に SQL Server のサービス起動アカウントを事前に
メンバとして追加しておくとよいかと思います。
インストールをしているユーザーにメンバの変更権限がない場合、インストール中にエラーとなるためです。
プロダクション環境にインストールする際、Active Directory の管理者権限を持つユーザーでインストールが
できないのであれば、検証時にも低い権限のユーザーでインストールを試した方がよいかと。

次の投稿でノードの追加をまとめてみたいと思います。

MSDTC のセキュリティの設定ですが、構築の度にいつもどう設定しているか忘れてしまいます…。

SQL Server のクラスタ環境を構築する場合、クライアントコンポーネントをインストールする際に
MSDTC のクラスタリソースがないとエラーになってしまうので、SQL Server のクラスタ環境を
構築する場合は通例的に設定はしているのですが。
# 1 ノードずつ、クライアントコンポーネントをインストールすれば MSDTC のリソースを作らなくても
　インストールできたはずですが。

以下の画像は私がクラスタの MSDTC を作成する際に設定している内容です。
Windows Server 2008 R2 のクラスタリソースとして作成した MSDTC のセキュリティです。

以下の情報を参考に設定をしています。

Windows Server 2003 でネットワーク DTC アクセスを有効にする方法
Windows Server 2003 クラスタで Microsoft 分散トランザクション コーディネータを構成する方法
MSDTC を使用した問題のトラブルシューティング

分散トランザクションでがりがり何か処理をしたことってないので、MSDTC の使い方っていまいちわかっていないんですよね…。
設定のたびに情報をひっくり返して探していたのでメモとして投稿しておきたいと思います。

ディスク署名の変更時の修復作業で MSDTC のリソースを使用して修復検証をしていたところ、
ディスクを再作成した際に MSDTC のリソースが起動しなくなりましたので、修復手順を
まとめてみたいと思います。

以下の 2 パターンで検証をしてみました。

1. バックアップが存在しない
2. Windows Server バックアップでバックアップが取得されている

[バックアップが存在しない]

ディスクを復旧しても MSDTC のリソースをオンラインにすることができません。

バックアップが存在しない場合は、復旧元のデータが存在しませんので、MSDTC のリソースのみを
再作成することでリソースをオンラインにすることができるようになります。

1. MSDTC のリソースを [右クリック] → [削除] をクリックします。
   
2. [はい] をクリックします。
   
3. [操作] → [リソースの追加] → [その他のリソース] → [分散トランザクション コーディネータ の追加] を
   クリックします。
   
4. MSDTC のリソースが作成されます。
   この状態ではリソースの依存関係がなにも設定されていないのでオンラインにすることはできません。
   
5. MSDTC のリソースを [右クリック] → [プロパティ] をクリックします。
   
6. [依存関係] タブで、MSDTC で使用する [コンピュータ名] と [クラスタ ディスク] の依存関係を設定し、
   [OK] をクリックします。
   

これでリソースをオンラインにすることができます。

コンピュータ名の再作成が発生すると AD 上のコンピュータアカウントに対しての作業が発生する可能性がありますので、
MSDTC のリソースだけを再作成してあげるのがシンプルではないかと思います。

[Windows Server バックアップでバックアップが取得されている]

続いて MSDTC で使用しているディスクを Windows Server バックアップで取得していた場合を検証してみます。

1. [Windows Server バックアップ] で MSDTC で使用しているディスクの情報を復元します。
   
2. MSDTC のリソースをオンラインにします。
   

バックアップが存在している場合は簡単にオンラインにすることができました。
[msdtc ?resetlog] は実行しなくてもエラーは発生しませんでした。

?

実際の運用ではバックアップを取得していない状態は基本的にない (と信じたいです…。) ので、
バックアップから復元してからオンラインにするパターンになると思いますが、バックアップがなくても
リソースの再作成だけで対応することができそうです。

Windows Server 2003 までの MSCS では、クラスタで使用しているディスクを交換して、ディスク署名が変わると
ClusterRecovery でドライブの変更または、dumpcfg でディスク署名を変更して、交換したディスクを交換前の
ディスクと同じようにするという作業を実施していました。

Windows Server 2008 の WSFC (MSFC) で、ディスク署名が変更されるとどのような動きになり、どのような修復
作業が必要になるのかを調べてみました。

Windows Server 使い倒し塾 の以下の記事を自分なりにまとめてみた形です。
Windows Server 2008 フェールオーバー クラスタで、clusterrecovery.exe によるディスク署名の変更は必要か？

Windows Server 2008 では、DISKPART コマンドからディスク署名の確認 / 変更ができます。
# ディスク署名の確認は以前の OS の DISKPART でもできますね。

ディスク署名の確認 / 変更の操作は以下のコマンドになります。

DISKPART LIST DISK または LIST VOL SELECT DISK <ディスク ID> または SELECT VOL <ボリューム ID> [ディスク署名の確認] UNIQUEID DISK [ディスク署名の変更] UNIQUEID DISK ID=xxxxxxxx

DISKPART を実行して UNIQUEID コマンドから、ディスク署名の確認 / 変更が行えます。

ディスクに対して署名を変更しますので最初に [LIST DISK] または、[LIST VOL] で対象のディスクを確認しています。

LIST VOL ではボリュームの確認になりますが、[SELECT VOL] でボリュームを選択すると、ボリュームを作成している
ディスクが選択されますので、ドライブレターからディスクを判断する場合は、[LIST VOL] で調べて [SELECT VOL] で
ボリュームからディスクを選択するのが使いやすいと思います。

[ディスク署名が変更された場合の修復]

まずはディスク署名だけを変更して、クラスタのディスクがどのようになるかを確認してみました。
H ドライブのディスクが今回、ディスク署名を変更したディスクなのですが、正常にオンラインになっていますね。
Windows Server 2003 以前では、ディスク署名が変わっているとオンラインにすることができませんでした。

以下のログが、イベントビューアに出力されています。
単純なディスク署名の変更だと、クラスタが自動的に署名の修復作業を実施し、最新のディスク署名の値で、
クラスタの構成情報を更新してくれているようです。

[ディスク再作成後の修復]

次は、ディスクを再作成した時にどのような動きになるのか確認してみたいと思います。

何かのリソースで使っているディスクでテストをしたほうがよいと思いますので、DTC で使用しているディスクで
検証してみたいと思います。

一度 iSCSI のディスクを削除し、ターゲット側で新規に作成したディスクを H ドライブとして割り当ててから、
クラスタを起動してみました。

ディスクを再作成した場合、イベントビューアに以下のエラーが出力されていました。

署名の再設定がされなかったみたいですね。

ドライブ文字は一緒にしていますので、MSDTC のディスクとして認識はしていますが、オンラインにはなっていません。

オンラインにすると以下のエラーになります。

この場合は、ディスクの修復をすることでオンラインにすることができます。
ディスクの修復は [フェールオーバー クラスタ管理] から対象のディスクを右クリック → [その他のアクション]
→ [修復] で実行することができます。

ディスクの修復をすることで、代替ディスクとして別のディスクを対象のクラスタディスクとして割り当てることができます。

これでディスクはオンライにできます。

MSDTC のリソースを新規に作成したディスクでオンラインにするためには別の手順が必要になりそうです。
こちらについては別途調べてみたいと思います。
# MSDTC をオンラインにしようとすると以下のエラーが発生します。

2008 になってクラスタのディスク復旧が標準の GUI からできるようになったので復旧手順もシンプルになりそうですね。

WSFC / MSFC のログについて調べたことをまとめてみました。
久しぶりのクラスタ関連の投稿です。

検証環境が 2008 無印のものしか用意できていなかったため Windows Server 2008 SP1 で確認しています。
そろそろ R2 のクラスタ検証環境も構築しておきたいと思います。

WSFC のログ (状態を把握する情報) は以下の種類があります。

1. イベントビューア
2. Cluster.log
3. Event Tracing for Windows (ETW)

まずはイベントビューアのログから。

[イベントビューア]

以下の 2 個所からクラスタ関連のイベントビューアのログを確認することができます。

1. システムログ
2. アプリケーションとサービスログ

それぞれのログの表示の仕方は以下の通りです。

システムログ

1. サーバー マネージャを実行します。
2. [診断] → [イベント ビューア] → [Windows ログ] → [システム] を開きます。
   ?
3. WSFC のログのみを表示するにはソースを [FailoverClustering] でログをフィルタリングします。
   フィルタリングは [操作] の [現在のログをフィルタ] で行います。
   
4. [フェールオーバー クラスタ管理] の [クラスタ イベント] で表示される内容もイベントビューアと同様の内容のようですね。
   こちらは直近 24 時間以内の内容でフィルタリングされています。
   ?

アプリケーションとサービスログ

1. サーバー マネージャを実行します。
2. [診断] → [アプリケーションとサービス ログ] → [Microsoft] → [Windows] → [FailoverClustering] → [Operational] を開きます。
   

こちらのログはクラスタの操作ログが出力されるようですね。
細かな動作の内容に関しては [Windows ログ] ではなく、こちらのログを確認したほうがよいかと思います。

[Cluster.log]

Windows Server 2003 まではデフォルトで出力されていたログですね。
Windows Server 2008 ではこのログはデフォルトでは出力されていません。

以下のコマンドを実行して、必要に応じて都度出力する必要があります。

cluster log /generate または cluster log /g

?

このコマンドを実行すると [Cluster.log] が [C:WindowsClusterReports] に出力されます。
[/node:] オプションを指定しない場合は、クラスタを構成する各ノード上にログが出力されています。

このファイルは以前からクラスタを触られている方であれば馴染みのある形式ですよね。
クラスタのログは Tech Center の以下の投稿がとても参考になります。
Cluster Log Level

クラスタのログのレベルは 1 ～ 5 までの 5 段階で設定ができ、デフォルトでは 3 となっています。

Level	Error	Warning	Info	Verbose	Debug
0	?	?	?	?	?
1	○	?	?	?	?
2	○	○	?	?	?
3	○	○	○	?	?
4	○	○	○	○	?
5	○	○	○	○	○

?
以下は [Cluster log] コマンドのヘルプになります。
[/LEVEL] は [0 ～ 10] となっていますが、6 以上は将来の予約値となっているようで現在はまだ使われていないようです。
# R2 になって使用されるようになっているかまではまだ調べられていません。

>cluster log /? このコマンドの構文は次のとおりです: CLUSTER [[/CLUSTER:]クラスタ名] LOG <オプション> <オプション> = ? /G[EN[ERATE]] [/COPY[:"ディレクトリ"]] [/NODE:"ノード名"] ? [/SPAN[MIN[UTE[S]]]:分] ] ? /SIZE:MB 単位のログ サイズ ? /LEVEL:ログ レベル 注意: ? /SIZE は 8 ～ 1024 MB の間である必要があります。 ? /LEVEL は 0 ～ 10 の間である必要があります。 CLUSTER LOG /? CLUSTER LOG /HELP

ログのレベルを変更したいときは、[Cluster log /LEVEL:<レベル>] で変更します。
サイズはデフォルトでは [100 MB] になっていますので変更したい場合は [Cluster log /LEVEL:<サイズ>] で変更します。
現在の設定値を確認したい場合は、[Cluster prop] コマンドで確認することができます。
以下は、コマンドの出力結果です。
[ClusterLogLevel] [ClusterLogSize] が現在の設定値になります。

T? クラスタ???????????? 名前?????????????????????????? 値 — ——————– —————————— ———————– M? 2008-wsfc-01???????? AdminExtensions D? 2008-wsfc-01???????? DefaultNetworkRole???????????? 2 (0x2) S? 2008-wsfc-01???????? Description B? 2008-wsfc-01???????? Security Descriptor??????????? 01 00 14 80 … (288 バイト) M? 2008-wsfc-01???????? GroupsAdminExtensions M? 2008-wsfc-01???????? NetworksAdminExtensions M? 2008-wsfc-01???????? NetworkInterfacesAdminExtensions M? 2008-wsfc-01???????? NodesAdminExtensions M? 2008-wsfc-01???????? ResourcesAdminExtensions M? 2008-wsfc-01???????? ResourceTypesAdminExtensions D? 2008-wsfc-01???????? QuorumArbitrationTimeMax?????? 20 (0x14) D? 2008-wsfc-01???????? QuorumArbitrationTimeMin?????? 7 (0x7) D? 2008-wsfc-01???????? DisableGroupPreferredOwnerRandomization 0 (0x0) D? 2008-wsfc-01???????? ClusSvcHangTimeout???????????? 60 (0x3c) D? 2008-wsfc-01???????? ClusSvcRegroupStageTimeout???? 7 (0x7) D? 2008-wsfc-01???????? ClusSvcRegroupOpeningTimeout?? 5 (0x5) D? 2008-wsfc-01???????? ClusSvcRegroupPruningTimeout?? 5 (0x5) D? 2008-wsfc-01???????? ClusSvcRegroupTickInMilliseconds 300 (0x12c) D? 2008-wsfc-01???????? HangRecoveryAction???????????? 3 (0x3) D? 2008-wsfc-01???????? SameSubnetDelay??????????????? 1000 (0x3e8) D? 2008-wsfc-01???????? CrossSubnetDelay?????????????? 1000 (0x3e8) D? 2008-wsfc-01???????? SameSubnetThreshold??????????? 5 (0x5) D? 2008-wsfc-01???????? PlumbAllCrossSubnetRoutes????? 0 (0x0) D? 2008-wsfc-01???????? CrossSubnetThreshold?????????? 5 (0x5) D? 2008-wsfc-01???????? BackupInProgress?????????????? 0 (0x0) D? 2008-wsfc-01???????? RequestReplyTimeout??????????? 60 (0x3c) D? 2008-wsfc-01???????? WitnessRestartInterval???????? 15 (0xf) D? 2008-wsfc-01???????? SecurityLevel????????????????? 1 (0x1) D? 2008-wsfc-01???????? ClusterLogLevel??????????????? 3 (0x3) D? 2008-wsfc-01???????? ClusterLogSize???????????????? 100 (0x64) D? 2008-wsfc-01???????? WitnessDatabaseWriteTimeout??? 300 (0x12c)

[Cluster.log] はコマンドの実行の都度、生成されますがその情報は Event Tracing for Windows (ETW) で出力された
情報がベースになっているようです。

[Cluster log /g] コマンドを実行すると、[CPrepSrv.exe] が [C:WindowsSystem32winevtLogs] ディレクトリにある、
[ClusterLog.etl.001] [ClusterLog.etl.002] [ClusterLog.etl.003] を読み込み、[Cluster.log] を生成しています。

[Event Tracing for Windows (ETW) ]

最後に ETW のログです。

ETW は Event Tracing for Windows の略で、OS で提供されている汎用トレース機能になります。
この機能により、クラスタの状態が ETL ファイルに出力がされています。
ETW は OS の内部状態を確認するために使用することがあるようなのですが、私は全然詳しくありません･･･。
IT Pro 向けの ETW / XPerf 関連の情報を集めたいなと思っているのですが手付かずです。

ETW によりデバッグおよびパフォーマンス調整を改善する

クラスタの ETW はイベントトレースセッションで自動的に実行されるようになっています。

イベントトレースセッションの設定は以下から確認することができます。

1. サーバー マネージャを実行します。
2. [診断] → [信頼性とパフォーマンス] → [データ コレクタ セット] → [イベント トレース セッション] を開きます。

?

[FailoverClustering] がクラスタのイベントトレースセッションの設定になります。

自動的に実行されているのは [スタートアップ イベント トレース] で [FailoverClustering] が [自動] で設定されているからのようですね。

この機能で出力されているのが、[Cluster.log] のベースになっている、[C:WindowsSystem32winevtLogs] に出力さている、
[ClusterLog.etl.xxx] ファイルになります。

このファイルを直接開いて内容を確認することはできないのですが、[tracerpt] というコマンドを使用すると、CSV や XML で
出力することができます。
以下はコマンドの例になります。

tracerpt ClusterLog.etl.001 ClusterLog.etl.002 ClusterLog.etl.003 -o log.txt ?of CSV tracerpt ClusterLog.etl.001 ClusterLog.etl.002 ClusterLog.etl.003 -of XML

クラスタの場合は ETW を開くより、cluster.log にして開くことのほうが多いと思いますので、使用する機会は
多くないかも知れないですね。

ETL ファイルですので、xperf や xperfview で開くことも可能です。
xperf / xpwerfview は以下のリンクから WPT Kit をダウンロードすることで入手可能です。

Windows Performance Analysis

パフォーマンス系の情報が入っていないからなのか、開いても寂しい表示ですが。

?

以上が、クラスタのログになります。
クラスタで障害が発生した場合は、これらのログを使用して状況を把握していくことになります。
ETW は Cluster.log で確認ができるので、実際にはイベントビューアと cluster.log の 2 種類を使用することになりますね。

この記事はずっと下書きに入っていたのですが、ようやく投稿まで持っていくことができました。

Tech･Ed Japan 2009 で Windows Server 2008 のハートビート用 NIC のチーミングサポートについての
話がありましたの調べてみました。

以下の KB に 2008 についての情報が記載されていました。

Network adapter teaming and server clustering

Note In Windows Server 2008 and Windows Server 2008 R2, there are no restrictions that are associated with NIC Teaming and the Failover Clustering feature. In Windows Server 2008, the new Microsoft Failover Cluster Virtual Adapter is compatible with NIC Teaming and allows it to be used on any network interface in a Failover Cluster.

この KB の日本語のものはよく見ていたのですが、英語版にしか記載がないということに気づいていませんでした。

2008 ではハートビート用 NIC にチーミングを使用した場合の制約はないみたいですね。