ソース: FailoverClustering, イベント ID :1135, イベント ID :1177 が記録されクラスター サービスが停止してしまう
平素より弊社製品をご愛顧くださいまして、誠にありがとうございます。
日本マイクロソフトの加藤です。
クラスター サービスでは、ノード間通信が失敗するとクラスター サービスが停止してしまう障害が発生することがございます。クラスター サービスが停止した原因がノード間通信やクォーラム ディスクへのアクセス遅延の場合にはシステム ログに下記のようなログが記録されます。
■ ログ: システム, ソース: FailoverClustering, イベント ID :1135
(ノード間通信のハートビートの疎通が失敗してしまい、クラスターを構成するノードがクラスター サービスから除外されたことを示すエラー)
■ ログ: システム, ソース: FailoverClustering,イベント ID :1177
(クラスターの起動時にクォーラム ディスクへの接続が遅くクラスター サービスが何度も再起動を繰り返す際に記録されるエラー)
上述のような障害は、クラスターを構成するノードの負荷が生じていたりディスクやノード間のアクセス経路に問題があったりと原因はさまざまです。しかしながら、原因はお客様環境に依存する問題であることがほとんどとなります。原因を調査し、その原因への対処策を実施することが根本的な解決ではございますが、原因への対処策を実施いただくまでの暫定的な対処として、障害を検知するまでの時間を遅らせる方法がございます。クラスターのパラメーターである QuorumArbitrationTimeMax や SameSubnetDelay, SameSubnetThreshold, CrossSubnetDelay, CrossSubnetThreshold の値の変更が障害を検知するまでの時間を遅らせる方法としては有効です。これらのパラメーターの値は GUI で変更することができないため、変更する方法をこの Blog でご紹介させていただきます。
GUI で設定の変更ができない理由としては、一般的な環境では変更する必要がなく、変更することによりクラスター サービス全体に影響を与える恐れがあるためでございます。そのため、設定及び設定変更いただく場合には十分影響について考慮いただいた上で実施くださいますようお願いいたします。
本項では、クラスターのパラメーターである QuorumArbitrationTimeMax や SameSubnetDelay, SameSubnetThreshold, CrossSubnetDelay, CrossSubnetThreshold についてご紹介させていただきます。
1. QuorumArbitrationTimeMax
2. SameSubnetDelay, SameSubnetThreshold, CrossSubnetDelay, CrossSubnetThreshold
1. QuorumArbitrationTimeMax
-----------------------------------------------------------------------------------------------------------------------
QuorumArbitrationTimeMax はクラスター サービスでクォーラムが失われた状態を障害として検知するまでの時間となります。一般的には、クラスターの起動時もしくは再起動時にクォーラム ディスクへの接続が遅くクラスター サービスが何度も再起動を繰り返す等の問題が生じた際にこのパラメーターの値を変更することで回避できる可能性がございます。具体的には以下のようなログがシステム ログに記録されます。
ログの名前: システム
ソース: FailoverClustering
イベント ID: 1177
レベル: 重大
説明: クォーラムが失われたためにクラスター サービスがシャットダウンしています。クラスター内の一部またはすべてのノードとのネットワーク接続が失われたか、監視ディスクのフェールオーバーが原因となっている可能性があります。
<クラスターの基本的な動き>
クラスター サービスでは、クラスターを構成するノード間で通信障害が発生するとすなわち自身以外のクラスターを構成するノードの状態が確認できない場合、クラスターを構成するノードは自身がオーナーとなりクラスターを提供しようといたします。上記の動作は下記の 2 点のいずれかの状態になるまで、継続いたします。
1. クォーラムの過半数以上を取得したノードが現れ、そのノードが提供するクラスターに所属していないノードのクラスター サービスは再起動され、クラスターに再参加する。
2. 全てのノードがクォーラムの過半数を取得できず、全てのノードでクラスター サービスが再起動される。
クォーラムを過半数以上維持するノードが出現するとクラスター サービスは再提供されますが、この時クォーラムを取得できなかったノードはクラスターへの再参加 (メンバーシップの再確立) を試みるため、クラスター サービスを再起動いたします。この再起動までの時間が、Death Timer (QuorumArbitrationTimeMax) の値となり
ます。すべてのノードがクォーラムの過半数を取得できず、全てのノードでクラスター サービスが再起動されるまでの時間も、Death Timer (QuorumArbitrationTimeMax) の値となります。また、クラスター サービスが停止するまで、該当ノードで役割が動作しますので、ディスクのような排他的に保有されるリソースを含む役割のオーナーであった場合、ディスク等のリソースをリリースするまでの時間も Death Timer (QuorumArbitrationTimeMax) の値でございます。
例えば、ノードが 2 台でクォーラム ディスクを保有する環境があるといたします。クラスターを構成するノード間で通信障害が発生すると、排他制御の観点からクラスターを構成するノードは自身がオーナーとなりクラスターを提供しようといたします。
しかしながら、何らかの要因によりクォーラム ディスクへの接続が遅い場合など、Death Timer (QuorumArbitrationTimeMax) の時間以内にいずれかのノードがクォーラム ディスクを取得できないと、すべてのノードでクラスター サービスの再起動が実施され
クラスター サービスを提供できません。そのため、Death Timer (QuorumArbitrationTimeMax) の時間を延長し、いずれかのノードがクォーラム ディスクを取得できる可能性を増やすことがひとつの対処策となります。
しかしながら、上述から、QuorumArbitrationTimeMax の値を変更する場合はクラスター サービスを再提供するまでの時間やその他のパラメーターの値との関連等考慮いただき、まずは極力短い値から設定いただきますようお願いいたします。
<Death Timer (QuorumArbitrationTimeMax) の値 のメリット・デメリット>
メリット : 値を大きくすることにより、何らかの要因によりクォーラム ディスクへの接続が遅い場合など、クォーラム ディスクへの接続確率を上げ、クラスター サービスの提供確率を上げることを試みることができる。
デメリット : 値を大きくすることにより、クラスター内でクォーラムが失われた状態を障害として検知するまでの時間が遅れ、クォーラムを失ったノードがクラスターへ再参加するための再起動が遅れる。また、クラスター サービスを停止するまで該当ノードで役割が動作するため、障害が発生した際にディスクなどの (排他的に制御される) リソースの状態を手動で変更する、例えば手動でオンライン状態へ変更できるまでの時間が既定値で運用している場合と比べ (変更した値 マイナス 20) 秒遅くなる。
以下、QuorumArbitrationTimeMax の値の確認及び変更方法についてご紹介させていただきます。
------------------------------
・PowerShell コマンドレット
------------------------------
1. 管理者権限で PowerShell を実行します。
2. ローカル クラスターの状態およびプロパティに関する情報を一覧
形式で表示し、QuorumArbitrationTimeMax の値を確認します。
(既定では 20 (秒) になっています)
> Get-Cluster | fl *
3. QuorumArbitrationTimeMax の値を変更します。
今回は例として、30 秒で設定する場合でご紹介いたします。
> (Get-Cluster). QuorumArbitrationTimeMax = 30
4. ローカル クラスターの状態およびプロパティに関する情報を一覧
形式で表示し、QuorumArbitrationTimeMax の値が変更されているか確認します。
> Get-Cluster | fl *
------------------------------
・コマンド プロンプトでの Cluster.exe コマンド
------------------------------
1. 管理者権限でコマンド プロンプトを実行します。
2. ローカル クラスターの状態およびプロパティに関する情報を一覧
形式で表示し、QuorumArbitrationTimeMax の値を確認します。
(既定では 20 (秒) になっています)
> Cluster /prop
3. QuorumArbitrationTimeMax の値を変更します。
今回は例として、30 秒で設定する場合でご紹介いたします。
> cluster /prop QuorumArbitrationTimeMax = "30"
4. ローカル クラスターの状態およびプロパティに関する情報を一覧
形式で表示し、QuorumArbitrationTimeMax の値が変更されているか確認します。
> Cluster /prop
2. SameSubnetDelay, SameSubnetThreshold, CrossSubnetDelay, CrossSubnetThreshold
-----------------------------------------------------------------------------------------------------------------------
SameSubnetDelay, SameSubnetThreshold, CrossSubnetDelay, CrossSubnetThreshold の4 点はハートビートの間隔や、障害検知までのしきい値に関するパラメーターでございます。一般的には、ノード間通信のハートビートの疎通が失敗してしまい、クラスターを構成するノードがクラスター サービスから除外されエラーを記録しているこのパラメーターの値を変更し対処をいたします。具体的には以下のようなログがシステム ログに記録されます。
_
ログの名前: システム
ソース: FailoverClustering
イベント ID: 1135
レベル: 重大
説明: クラスター ノード 'ノード名' がアクティブなフェールオーバー クラスター メンバーシップから削除されました。クラスター サービスがこのノードで停止されている可能性があります。また、このノードがフェールオーバー クラスター内の別のアクティブなノードと通信できないことが原因である可能性もあります。構成の検証ウィザードを実行して、ネットワーク構成を確認してください。状況が変化しない場合は、このノードのネットワーク アダプターに関連するハードウェアまたはソフトウェアのエラーがないか確認してください。また、ハブ、スイッチ、ブリッジのような、ノードが接続されている他のネットワーク コンポーネントにエラーがないか確認してください。
WSFC 環境のハートビートの既定の設定は以下となります。
ハートビート間隔 ： 1 秒
切断検知までのしきい値 ： 5 回
1 秒間隔にハートビート パケットを送付し、このパケットが連続して 5 回失敗するとネットワークが切断されたと判断し、「パーティション分割」の状態となります。ネットワークが不安定な環境では、上記ハートビートの設定を 1 秒間隔で 5 回ではなく、2 秒間隔で 10 回まで、などに変更する事によってこのネットワークの問題に対応できる場合があります。この設定値は、以下のクラスター プロパティ値として管理されています。
■ クラスターが同じサブネット構成されている場合
SameSubnetDelay (単位：ミリ秒)
SameSubnetThreshold (単位：回数)
■ クラスターが異なるサブネットで構成されている場合
CrossSubnetDelay (単位：ミリ秒)
CrossSubnetThreshold (単位：回数)
負荷の高いネットワークであったり、 WAN 環境などのパケット遅延が発生しうる環境では、これらの値を変更することで一時的なハートビート通信遅延などによる障害検知の影響を軽減することができます。しかしながら、ハートビート通信の閾値を必要以上に延長すると、クラスター ノードにおける障害検知 (例えばブルースクリーンでノードが落ちた場合等) が遅くなるリスクがあります。そのため、TCP/IP やアプリケーションがもつ各種タイムアウト等を考慮に入れ、お客様の運用方針に合わせた適切な値を設定いただければと思います。
< SameSubnetDelay, SameSubnetThreshold, CrossSubnetDelay, CrossSubnetThreshold の値 メリット・デメリット>
メリット : 負荷の高いネットワークであったり、 WAN 環境などのパケット遅延が発生しうる環境では、値を大きく設定することで一時的なハートビート通信遅延などによる障害検知の影響が軽減できる。
デメリット : クラスター ノードにおける障害 (例えば ブルースクリーンでノードが落ちた場合の) 検知が遅くなる。
以下、SameSubnetDelay, SameSubnetThreshold, CrossSubnetDelay, CrossSubnetThreshold の値の確認及び変更方法についてご紹介させていただきます。
------------------------------
・PowerShell コマンドレット
------------------------------
1. 管理者権限で、Powershell を実行します。
2. 以下の Powershell コマンドレットを実行して、現在の設定状況を確認します。
(CrossSubnetDelay, CrossSubnetThreshold の値について確認する場合は fl 以下を変更することで確認が可能です)
PS C:\> Get-Cluster | fl SameSubnetDelay, SameSubnetThreshold
3. 以下のコマンドレッドを実行し、SameSubnetDelay, SameSubnetThreshold の設定変更をします。
今回は例として、2 秒 10 回で設定します。
PS C:\> (Get-Cluster). SameSubnetDelay = 2000
PS C:\> (Get-Cluster).SameSubnetThreshold = 10
4. 以下の Powershell コマンドレットを実行して、変更が反映されているか確認します。
(CrossSubnetDelay, CrossSubnetThreshold の値について確認する場合は fl 以下を変更することで確認が可能です)
PS C:\> Get-Cluster | fl SameSubnetDelay, SameSubnetThreshold
これにより、ハートビート通信の切断の閾値が、2 秒間隔で 10 回失敗した場合まで拡張されます。
※ コマンドレットで設定いただいた後に再起動いただく必要はございません。
<参考情報>
[タイトル] フェールオーバー クラスターのハートビートについて
https://blogs.technet.com/b/askcorejp/archive/2012/03/22/3488080.aspx
[Title] Tuning Failover Cluster Network Thresholds
https://blogs.msdn.com/b/clustering/archive/2012/11/21/10370765.aspx
------------------------------
・コマンド プロンプトでの Cluster.exe コマンド
------------------------------
1. 管理者権限でコマンド プロンプトを実行します。
2. SameSubnetDelay, SameSubnetThreshold の値を確認します。
(CrossSubnetDelay, CrossSubnetThreshold の値について確認する場合は Prop : 以下を変更することで確認が可能です。)
> cluster /prop:SameSubnetDelay
> cluster /prop:SameSubnetThreshold
3. SameSubnetDelay, SameSubnetThreshold の値を変更します。
今回は例として、2 秒 10 回で設定します。
> cluster /prop:SameSubnetDelay = 2000
> cluster /prop:SameSubnetThreshold =10
4. 再度 SameSubnetDelay, SameSubnetThreshold の値を確認し変更が反映されているか確認します。
> cluster /prop:SameSubnetDelay
> cluster /prop:SameSubnetThreshold
これにより、ハートビート通信の切断の閾値が、2 秒間隔で 10 回失敗した場合まで拡張されます。
※コマンドで設定いただいた後に再起動いただく必要はございません。
<参考情報>
[Title] QuorumArbitrationTimeMax
https://msdn.microsoft.com/en-us/library/aa369123(v=vs.85).aspx
[タイトル] クラスターのハートビート通信の設定値の範囲について
https://blogs.technet.com/b/askcorejp/archive/2015/08/12/3653013.aspx