Azure 上でフェールオーバー クラスターを構築する際の留意事項について
こんにちは。Windows プラットフォーム サポートの加藤です。
本日は、Azure 上でフェールオーバー クラスターを構築する際の留意事項についてご案内します。
最近、Azure 上の仮想マシンで構築したフェールオーバー クラスターがハートビート通信のダウンでフェールオーバーが発生する報告がございました。
ハートビート通信とは、ノード間で実施される通信で、目的はノード間ネットワークの死活監視です。
全てのハートビート通信がダウンすると相手ノードが停止したと判断します。
フェールオーバー クラスターのハートビート通信のタイムアウトの閾値の既定値は 5 秒であり、これを超えてもハートビート通信ができない場合には、相手ノードのダウンと判断され、
停止したノードがアプリケーションのオーナーノードであった場合には、そのアプリケーションは他のノードへフェールオーバーされます。
- 参考
フェールオーバー クラスターのハートビートについて
https://blogs.technet.com/b/askcorejp/archive/2012/03/22/3488080.aspx
Azure 環境では、後述の計画的なメンテナンス時に 30 秒ほど仮想マシンが一時停止する場合がございます。
30 秒間クラスター ノードが停止すると、もう一方のクラスター ノードは、一時停止しているノードとハートビート通信が実施できない状況に陥り、上述の事象が発生します。
========================================
Azure Virtual Machines に対する計画的なメンテナンス
https://azure.microsoft.com/ja-jp/documentation/articles/virtual-machines-planned-maintenance/
該当箇所を抜粋します。
Microsoft Azure の更新のクラスの場合、実行中の仮想マシンに何らかの影響があってもお客様にはわかりません。これらの更新の多くは、実行中のインスタンスに干渉することがなく更新可能なコンポーネントまたはサービスを対象にしています。これらの更新の一部は、ホスト オペレーティング システムのプラットフォーム インフラストラクチャに対する更新であり、仮想マシンの完全な再起動を必要とせずに適用できます。
これらの更新は、ライブ移行 ("メモリ保護" 更新) を実現するテクノロジによって達成されます。更新時、仮想マシンは "一時停止" 状態になり、RAM 内のメモリは保護されます。この状態で、基礎となるホスト オペレーティング システムが必要な更新プログラムと修正プログラムを受信します。仮想マシンは、30 秒以内の一時停止で再開されます。再開後、仮想マシンのクロックは自動的に同期されます。
このメカニズムを使用してすべての更新をデプロイできるわけではありませんが、一時停止の期間が短い場合、この方法で更新をデプロイすることにより、仮想マシンへの影響が大幅に軽減されます。
複数インスタンスの更新 (可用性セット内の仮想マシンの場合) が、一度に 1 つの更新ドメインに適用されます。
========================================
フェールオーバーの発生自体は、クラスター上のアプリケーションを救うための正常な動作ですが、Azure メンテナンス時に極力フェールオーバーの発生を抑えたい場合には、このハートビートの閾値を事前に延長しておくことをお勧めいたします。
具体的な設定値につきましては、クラスター上のアプリケーションの停止時間がどの程度まで許容できるかによって異なります。
例えば 20 秒間の停止では、クラスター上のアプリケーションを使用したシステムに影響を及ぼさないのであれば、ハートビートの閾値を 21 秒に延長することで、Azure のメンテナンスにより、20 秒程度の停止が発生したとしても、フェールオーバーは発生しません。
逆に、20 秒間の停止が許容できないアプリケーションであれば、閾値を延長するよりは、既定値のままで、素早く切り替えたほうが良い場合もございます。
また、起動に時間のかかるアプリケーションをクラスター化している場合も、閾値の延長が有効な場合があります。
例えば、起動完了に 1 分かかるアプリケーションであれば、フェールオーバー先での起動完了に 1 分間要することになるため、30 秒の仮想マシンの停止でフェールオーバーさせたくない場合もあるかもしれません。
そのため、設定する値はお客様の環境にあわせてチューニングしていただければ幸いに存じます。
なお Windows Server 2012 以降のクラスターでは、同じサブネット間のハートビート通信は 240 秒まで延長可能ですが、Windows Server 2008 R2 のクラスターでは、20 秒までしか延長できません。
- 参考
クラスターのハートビート通信の設定値の範囲について
https://blogs.technet.com/b/askcorejp/archive/2015/08/12/3653013.aspx
ハートビートの閾値の変更手順
========================================
WSFC 環境のハートビートの既定の設定は以下となります。
ハートビート間隔 ： 1 秒
切断検知までのしきい値 ： 5 回
1 秒間隔にハートビート パケットを送付し、このパケットが連続して 5 回失敗するとネットワークが切断されたと判断し、「パーティション分割」の状態となります。ネットワークが不安定な環境では、上記ハートビートの設定を 1 秒間隔で 5 回ではなく、2 秒間隔で 10 回まで、などに変更する事によってこのネットワークの問題に対応できる場合があります。
この設定値は、以下のクラスター プロパティ値として管理されています。
•クラスターが同じサブネット構成されている場合
◦SameSubnetDelay (単位：ミリ秒)
◦SameSubnetThreshold (単位：回数)
•クラスターが異なるサブネットで構成されている場合
◦CrossSubnetDelay (単位：ミリ秒)
◦CrossSubnetThreshold (単位：回数)
上記プロパティ値の変更手順は OS のバージョンによってことなります。
Windows Server 2008 R2 のクラスター
----------------------------------------------------------------
1.クラスタ ノードにてコマンド プロンプトを開きます。
2.以下のコマンドを実行すると、現在の設定値が確認できます
cluster /prop:SameSubnetDelay
cluster /prop:SameSubnetThreshold
3.以下のコマンドを実行し、設定を既定の状態から変更します( 2 秒 x 10 回 の場合)
cluster /prop SameSubnetDelay=2000
cluster /prop SameSubnetThreshold=10
4.再度 2 のコマンドを実行し、変更が反映されていることを確認します。
この設定は 1 台のノードで実行することによりクラスター全体に即時に反映されます
Windows Server 2012 以降のクラスター
----------------------------------------------------------------
1) クラスタ ノードにて PowerShell コンソールを開きます。
2) 以下のコマンドレットを実行すると、現在の設定値が確認できます。
Get-Cluster | select SameSubnet*
Get-Cluster | select CrossSubnet*
3) 以下のコマンドレットを実行し、設定を既定の状態から変更します( 2 秒 x 10 回 の場合)
(Get-Cluster).SameSubnetDelay = 2000
(Get-Cluster).SameSubnetThreshold = 10
(Get-Cluster).CrossSubnetDelay = 2000
(Get-Cluster).CrossSubnetThreshold = 10
4.再度 2 のコマンドレットを実行し、変更が反映されていることを確認します。
この設定は 1 台のノードで実行することによりクラスター全体に即時に反映されます
このブログが皆様のお役に立てれば幸いです。
※ 本ドキュメントは2016年1月6日時点の情報をもとにしています。将来的には変更となる可能性がございますので、ご了承ください