Windows Server 2012 R2 の Hyper-V クラスターの環境で Clussvc.exe の CPU 使用率が増える

こんにちは。Windows プラットフォーム サポートの加藤です。
本日は、最近お問い合わせのあった Windows Server 2012 R2 の Hyper-V クラスター + SCVMM の環境で Clussvc.exe の CPU 使用率が増える現象についてご紹介します。

<現象>
Windows Server 2012 R2 の Hyper-V クラスター + SCVMM の環境で、全ノードの Clussvc.exe の CPU 使用率が 15 ~ 20 % まで増加します。

<原因>
この現象は Windows Server 2012 R2 の Hyper-V クラスター環境では "Global Update Manager" (GUM) の動作が以前のクラスターとは異なるために発生します。

※ "Global Update Manager" (GUM) はクラスターのノード間の同期とクラスター データベースの更新を実施するコンポーネントです。

"Global Update Manager" (GUM) の基本的な動作は、あるノードが更新の通知を送信し、更新通知を受け取ったノードはアップデートを実施後に、通知元のノードに応答を返します。
Windows Server 2012 以前のクラスターでは、すべてのノードから応答を受け取ったタイミングでクラスター データベースにコミットし、更新完了となっておりました。
つまりすべてのノードが更新を受け取り、応答を返さなければ、クラスター データベースにコミットできないため、更新を通知したノードはすべてのノードが処理を完了するまで待ち続けます。
この方法ですと 1 台でも更新処理に時間のかかるノードが存在していた場合、応答をすぐに返せず、その結果、当該処理の更新完了はまたされることになります。

Windows Server 2012 R2 では、この動作を変更できるようになり、DatabaseReadWriteMode が 1 の場合には、過半数のノードからの更新完了の応答を受け取れば、クラスター データベースにコミット可能としました。
これによりすべてのノードの更新完了を待ち続ける必要がないためパフォーマンスが向上します。(データベースの変更処理が待たされなくなります。)

※ 既定では Hyper-V クラスター環境は、1 に設定されます。その他の構成では 0 に設定されます。
※ DatabaseReadWriteMode の値が 0 の場合は従来のモードで動作します。

データベースの更新の速度を向上させるために機能ですが、環境によっては逆に CPU やネットワークの負荷を上昇させる可能性が報告されておりました。
弊社事例では、SCVMM、または SCOM の環境で Clussvc.exe の CPU 使用率やネットワークの負荷が上昇する事例が多数報告されておりました。
また、弊社製品以外では、ハードウェアに添付の管理ソフトなどでも同様の事象が発生した報告もございます。
これは、DatabaseReadWriteMode が 1 の場合には、クエリを受け取ったノードは、自身のデータベースの情報が最新ではない可能性があるため、他のノードとタイムスタンプを比較する処理が発生します。
特にノード数が多く、多数の仮想マシンがある環境では、全ての仮想マシンの情報の取得を試みると、非常に多くのクエリが要求されるため、負荷が上がりやすいと考えられます。

What's New in Failover Clustering in Windows Server
Configure the Global Update Manager mode
https://msdn.microsoft.com/en-us/library/dn265972(v=ws.11).aspx#BKMK_GUM
When a database read request occurs, the cluster compares the latest timestamp from a majority of the running nodes, and uses the data with the latest timestamp.

また、上記の現象が発生すると、イベントログに以下の Microsoft-Windows-FailoverClustering ID:5377 のエラーが記録され、クラスター サービスが突然停止する障害も報告されております。

---------------------
エラー Microsoft-Windows-FailoverClustering 5377 グローバル更新マネージャー 内部のクラスター サービスが、定義されたしきい値である '110' 秒よりも長時間動作しました。このクラスター サービスは回復のために終了されました。このクラスター サービスがサービス コントロール マネージャーによって再起動された後、ノードがクラスターに再度参加します。
---------------------

<回避策>
この現象はクラスターへのクエリを停止していただくか DatabaseReadWriteMode の値を 0 に変更していただくことで回避されます。(従来の GUM モード)
そのため、同様の構成で Clussvc.exe の CPU 使用率が増加する場合には、管理者権限で以下の PowerShell のコマンドで値の変更をお願いいたします。
なお Windows Server 2016  では既定で 0 のため、同様の事象は発生しません。

- 変更手順
(Get-Cluster). DatabaseReadWriteMode = 0

※ 再起動は不要です。

本 Blog が少しでも皆様のお役に立てれば幸いです。