*1 2013/8/27 Windows Server 2008 以降の動作についての補足を追記しました。
こんにちは。Windows プラットフォーム サポートの戸田です。
日々のサポート業務の中で、よくお問い合わせを頂く内容についてご紹介します。
今回は MSCS や WSFC でときどきお問い合わせを頂く「ハートビート」についての記事となります。新旧クラスター関連の記事で使用されている 「ハートビート (Heart beat)」 という表現について、この場を借りて一旦整理したいと思います｡また、ハートビートに関する設定値についてもご紹介します。
まず、一般的にコンピューター用語のハートビートとは分散コンピューティングにおいて相手コンピュータの生存確認を行うための仕組みです。フェールオーバー クラスターの用語では、ハートビート ネットワークとハートビート パケットがあります。混同しやすいところがありますのでまずは簡単に違いを説明します。
なお、この文書内で使用するプライベート ネットワーク、パブリック ネットワークという表現は、それぞれ以下のイメージを指しています。
-
プライベート ネットワーク … クラスター ノード間を結ぶ Closed なネットワーク。
-
パブリック ネットワーク … クラスター ノード間を結び、クライアント アクセス ポイントが割り当てられたネットワーク。一般的にはネットワーク クライアントからのアクセスが可能な構成となります。
ハートビート ネットワークについて
MSCS においてノードの正常性確認のための専用ネットワークを指す用語です。
クラスターを構成するノードでは随時ステータスの同期を行っており、もし同期に失敗するノードが見つかった場合には、そのノードはクラスターから切り離されます(切り離されたノードはクラスター サービスの再起動が行われ、あらためてクラスターに参加を試みます)。
この同期処理のために用意する専用のプライベート ネットワークのことをハートビート ネットワークと呼びます。
このハートビート ネットワークはクラスターの安定動作のために非常に重要視されており、固有の設定が必要とされています。詳細については以下の KB をご一読ください。
クラスター サーバーでのプライベート "ハートビート" の推奨構成
http://support.microsoft.com/kb/258750/ja
(WSFC 環境ではこの KB に記載されたハートビート固有の設定は行わない様にしてください。)
このハートビート ネットワークの推奨設定は Windows Serrver 2003 MSCS までは必要でしたが Windows Server 2008 WSFC 以降ではこの特別なネットワーク設定を行う必要がなくなりました。もちろん Windows Server 2008 WSFC でもこの同期処理が重要である点は同じですので、ノード間で相互接続が可能なネットワークは必要です (ノード間の相互ネットワークは単一障害点を避けるため、複数の経路を用意頂くことを強く推奨しています)。しかし、MSCS からのデザイン変更によって、「(特別な設定を持つ) ハートビート ネットワーク」を用意する必要がなくなったため、他のクラスター ネットワークとの設定差がなくなり、冗長性を高く保つことができるようになっています。
ハートビート パケットについて
ノード間を結ぶ相互ネットワークが疎通可能であるかどうかを確認するために定期的に送受信を行うパケットのことをハートビート パケットまたは単にハートビートと呼びます。
ハートビートは即時応答性を重要視するため UDP プロトコルが使用され、クラスター サービスとして予約されたポート 3343 を使用し、クラスターで使用可能なすべてのネットワーク毎に送受信が行われます。
ハートビート パケットの送受信の間隔は以下のとおりです。
-
Windows Server 2003 までは 1.2 秒毎
-
Windows Server 2008 以降では 1 秒毎
補足
Windows NT Server をベースにした MSCS では内部通信専用のプライベート ネットワークでのみ、ハートビート パケットの送受信が行われていました。そのため相手ノードの生存確認のためのネットワークとして、言葉通り「ハートビート ネットワーク」の意味合いが強いものでした。Windows 2000 Advanced Server 以降の MSCS ではネットワーク毎の疎通確認を目的として、クラスターで使用するネットワーク全てにおいて、ハートビート パケットの送受信が行われるようにデザインが変更されています。
定期的に送受信が行われるハートビートが一定の数(時間)応答が無い場合に、クラスターはハートビートの遅延、または切断として、そのネットワーク上でノード間の疎通に問題があることを認識します｡しかし、ノード間の疎通に失敗することがわかっても、送受信相手からの応答がないことがわかるのみで、障害発生箇所が途中のネットワーク経路なのか、相手ノードの問題なのかを確認することができません。そのため、クラスターはパブリック ネットワークでこのような状況が検知された場合にはさらに障害箇所の特定の為に、「外部ホスト」に対して、疎通確認を行い、障害箇所の特定を試みます。この「外部ホスト」とは各ノード共通でアクセス可能なネットワーク上の "第三者" のコンピュータで、デフォルト ゲートウェイなどです。疎通確認は ping を実行し、ICMP 応答の有無を以て障害箇所を探します。
この動作は、簡単にまとめると以下のような流れになります。
-
ハートビートの応答がなくなったことを検出したら、お互いのノードでネットワークの状態を「パーティション分割」に、各ネットワーク接続を「到達不能」の状態にセットします。
-
各ノードで「外部ホスト」への ping を実施し、その応答を確認します。
-
ping の結果に差があった場合・・・
-
応答があったらこのノードのネットワークは正常なので、ネットワーク接続を「稼働中」の状態にセットします。
-
応答がないときは、このノードのネットワークは問題があるとしてネットワーク接続を「失敗」の状態にセットし、関連づけられた IP アドレス リソースを所有していたら失敗にしてフェールオーバーを促します。
-
もし、ノード間で差がない場合には障害箇所の特定ができないので両ノードで「到達不能」のまま、状態の変化は発生しません (外部ホストが存在しないネットワークは常にこの状態となります)。この場合、相手ノードが正常であるとの確信もないので、フェールオーバーは行いません。
-
ハートビートの送受信は常に試行しているため、疎通が正常に戻った場合には、ネットワークの状態、各ネットワーク接続のステータスを「稼働中」の状態にセットします。
この動作は Windows Server 2000 を対象とした KB242600 にも詳細が説明されていますが、基本的な動作は Windows Server 2008 WSFC でも同様となります。
2 ノードのサーバー クラスタにおけるネットワーク障害の検出と回復
http://support.microsoft.com/kb/242600/ja
*1
Windows Server 2003 MSCS と Windows Server 2008 WSFC との動作の違いについて以下のBlogが公開されています。
2 ノードのサーバー クラスタにおけるネットワーク障害の検出とフェールオーバー動作について
http://blogs.technet.com/b/askcorejp/archive/2013/06/21/3580380.aspx
なお、ネットワーク ケーブルの切断 (リンク ダウンの検出) が行われた場合には、上記の様な障害箇所の特定を行うまでもなく、クラスターはネットワーク インターフェースの障害としてこれを検知します。この場合にはどのノードの、どのネットワーク インターフェースの問題であるかは即時にわかるため、関連づけられた IP アドレス リソースは失敗のステータスからフェールオーバーの動作となります。またこの様なパブリック ネットワークの状態変化もクラスター内で同期が行われ、各ノードでステータスを共有します。ここでもし、他に正常な相互接続ネットワークが存在しない場合にはこの同期が失敗するため、前述の通り(同期ができない)クラスター サービスが再起動します。
ハートビートが遅延してしまう場合には・・・
ご利用のクラスター環境でこのようなハートビートの失敗が発生する様な場合にはネットワーク障害の有無についての調査を検討してみてください。ご利用のネットワークで障害が発生していた場合にはその対処を優先すべきですが、負荷の高いネットワークであったり、 WAN 環境などでパケット遅延が発生しうる可能性がある場合、Windows Server 2008 WSFC 以降ではハートビートの間隔や、障害検知までのしきい値を変更することができます。
WSFC 環境のハートビートの既定の設定は以下となります。
ハートビート間隔 ： 1 秒
切断検知までのしきい値 ： 5 回
1 秒間隔にハートビート パケットを送付し、このパケットが連続して 5 回失敗するとネットワークが切断されたと判断し、「パーティション分割」の状態となります。ネットワークが不安定な環境では、上記ハートビートの設定を 1 秒間隔で 5 回ではなく、2 秒間隔で 10 回まで、などに変更する事によってこのネットワークの問題に対応できる場合があります。
この設定値は、以下のクラスター プロパティ値として管理されています。
- クラスターが同じサブネット構成されている場合
- SameSubnetDelay (単位：ミリ秒)
- SameSubnetThreshold (単位：回数)
- クラスターが異なるサブネットで構成されている場合
- CrossSubnetDelay (単位：ミリ秒)
- CrossSubnetThreshold (単位：回数)
値の変更は cluster.exe コマンドで行うことができます。コマンド例をご紹介しますので状況に応じてお試し下さい。
- クラスタ ノードにてコマンド プロンプトを開きます。
- 以下のコマンドを実行すると、現在の設定値が確認できます
cluster /prop:SameSubnetDelay
cluster /prop:SameSubnetThreshold - 以下のコマンドを実行し、設定を既定の状態から変更します( 2 秒 x 10 回 の場合)
cluster /prop SameSubnetDelay=2000
cluster /prop SameSubnetThreshold=10 - 再度 2 のコマンドを実行し、変更が反映されていることを確認します。
この設定は 1 台のノードで実行することによりクラスター全体に即時に反映されます。
また、Windows Server 2003 MSCS では 1.2 秒毎のハートビート間隔は変更できませんが、SP1 以降ではハートビート遅延、切断の検知に関するしきい値を変更出来る様になっています。
An update is available that adds a file share witness feature and a configurable cluster heartbeats feature to Windows Server 2003 Service Pack 1-based server clusters
http://support.microsoft.com/kb/921181/en-us
MSCS では 3 回のハートビートを受信しなかった場合にネットワークの切断が検出(イベント ID 1123 が記録) され、6 回を超えて受信しなかった場合には相手ノードとの切断と検出されます。
これらの値はそれぞれプロパティ値 HeartBeatLostInterfaceTicks、HeartBeatLostNodeTicks で変更が可能で、以下の cluster.exe コマンドで変更を行うことができます。
cluster /priv HeartBeatLostInterfaceTicks=<回数>
cluster /priv HeartBeatLostNodeTicks=<回数>
MSCS では値の反映にはクラスター サービスの再起動が必要です。これらの詳細については、以下の公開情報をご確認ください。
Windows 2000 ベースおよび Windows Server 2003 ベースのサーバー クラスタにおけるイベント ID 1123 とイベント ID 1122 のログの概要
http://support.microsoft.com/kb/892422/ja
ご利用頂いているクラスター環境でネットワークが安定しない等の問題をお持ちの場合には、これらハートビートに関する設定変更についてもご検討をいただければと思います。
また、ネットワーク経路に問題が無い場合にも疎通が不安定となる事象などもありますので、以下も併せてご確認をいただければと思います。
クラスタのネットワークが不安定になる?
http://blogs.technet.com/b/askcorejp/archive/2010/06/16/3338445.aspx
