追記： 7.0.0d で修正済み
本件の修正を含んだ 7.0.0d がリリースされました。
Resolved Issues にも本件と思われる問題が記載されています。
After an upgrade to vCenter Server 7.0.0c, you see high CPU usage
VMware vCenter Server 7.0.0d Release Notes
After you upgrade your vCenter Server system to vCenter Server 7.0.0c, CPU usage continuously stays high. On a single core, CPU usage might spike up to 100% for hours. The Workload Control Plane service causes the issue, even if you do not have Workload Management enabled in your environment.
This issue is resolved in this release.
手元の環境でも、ワークアラウンドを元に戻して事象を再現させた状態で 7.0.0d にアップデートし、事象が再現しなくなったことが確認できました。
TL;DR
- vCenter Server のワークロード制御プレーン（Workload Control Plane, WCP）サービスの既知の問題
- 今後リリースされる Express Patch 1（EP1）で修正される予定
- 以下の二つの条件が許容できるなら、問題のサービスを止めれば抑制できる
- vSphere with Kubernetes 関連の機能が使えなくなる
- ホストをメンテナンスモードにできなくなる
- 上記の二つの条件が許容できない場合は、EP1 のリリースまで
7.0.0bのままにするか、CPU の高騰を許容する必要がある
7.0.0c 化後、突然の CPU 使用率の高騰
vCenter Server を 7.0.0c にしてしばらく放っておいたら、どうにも空冷ファンがいつもよりもうるさいままで、おかしいなあ、みたいな。見たらこうなっていました。
top で SHIFT + P するとこんな。
/usr/lib/vmware-wcp/wcpsvc なるプロセスが張り付いていました。
top - 01:00:58 up 1:43, 1 user, load average: 1.49, 1.73, 1.72
Tasks: 290 total, 1 running, 289 sleeping, 0 stopped, 0 zombie
%Cpu0 : 99.3/0.7 100[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||]
%Cpu1 : 4.7/3.4 8[|||||||| ]
GiB Mem : 73.5/11.7 [ ]
GiB Swap: 0.3/26.0 [ ]
PID USER PR NI VIRT RES %CPU %MEM TIME+ S COMMAND
29354 root 20 0 505.5m 84.2m 98.7 0.7 81:36.55 S /usr/lib/vmware-wcp/wcpsvc --port 8920 --logfile /var/log/vmware/wcp/wcpsvc.l+
1196 root 20 0 2495.5m 30.6m 2.6 0.3 4:39.03 S /usr/java/jre-vmware/bin/java -XX:+UseStringDeduplication -XX:+OptimizeString+
1318 vdtc 20 0 181.4m 3.2m 0.7 0.0 0:32.24 S /usr/lib/vmware-vdtc/vdtc
7965 vsphere+ 20 0 2683.7m 851.8m 0.7 7.1 1:53.38 S /usr/java/jre-vmware/bin/vsphere-ui.launcher -Xmx597m -XX:CompressedClassSpac+
10455 root 20 0 133.3m 14.3m 0.7 0.1 0:21.22 S /usr/lib/vmware-vmon/vapi/vmon-vapi-provider -p 8900 -l info
1 root 20 0 92.6m 7.7m 0.0 0.1 0:01.54 S /lib/systemd/systemd --switched-root --system --deserialize 17
2 root 20 0 0.0m 0.0m 0.0 0.0 0:00.00 S [kthreadd]
...
原因と暫定対策
調べると、既知の問題のようです。
vSphere with Kubernetes 関係のサービスのようですね。VAMI から止められるとのことなので、止めてみます。
日本語だと ワークロード制御プレーン、英語だと Workload Control Plane のようです。選択していちばん上の [停止] を押すだけ。シェルで vmon-cli -k wcp でもよいですね。
きれいにおさまりました。
なお、この方法でのサービス停止は一時的なものなので、vCenter Server が再起動するとこの問題は再発するようです。
つまり、再起動後もこのサービスを止めたままにするには、シェルに入って、
root@record [ ~ ]# vmon-cli -s wcp
Name: wcp
Starttype: AUTOMATIC
RunState: STOPPED
RunAsUser: root
CurrentRunStateDuration(ms): 885398
HealthState: UNHEALTHY
FailStop: FALSE
MainProcessId: N/A
root@record [ ~ ]# vmon-cli -S DISABLED -U wcp
Completed Service State Update request.
root@record [ ~ ]# vmon-cli -s wcp
Name: wcp
Starttype: DISABLED
RunState: STOPPED
RunAsUser: root
CurrentRunStateDuration(ms): 910637
HealthState: UNHEALTHY
FailStop: FALSE
な感じで、自動起動をオフにする必要があります。オンに戻すときは DISABLED を指定しているところで AUTOMATIC にします。
暫定対策の副作用
vSphere with Kubernetes 関連のサービスなので、K8s 関連の機能は動かなくなりそうです（どこまで動かなくなるのかは試していません……）。
また、それだけでなく、先のリンク先には、WCP を止めると メンテナンスモードにできなくなる と書いてあります。試してみたら、確かに以下のエラーでメンテナンスモードへの切り替えに失敗しました。
その操作は、現在の状態では実行できません。
ノードで名前空間のメンテナンス モードへの切り替えに失敗したため、ホストをメンテナンス モードに切り替えることができません。
メンテナンスモードにできないとなると、vLCM（旧 VUM）でのアップデートの時などに困りそうです。となると、必要な時は一時的にサービスを上げるのがよいのかもですね。もしくはおとなしく 7.0.0b の頃のバックアップをリストアするか……。
恒久対策
コミュニティでのやりとりしか情報がないですが、次に出る EP1（Express Patch 1）での修正が予定されているようです。待ちましょう。わりと近いうちに出そうな気はするけれど、どうでしょう。
修正されるまでは、7.0.0c の適用は見送る（7.0.0b のままにしておく）判断もアリになりそうです。
