vSphere Web Client 6.7 に接続すると「503 Service Unavailable」エラーが発生する

-

2019年9月から稼働し始めたvCenter Server 6.7への接続が503エラーになる障害が起きたので対策。1-2ヶ月順調に稼働していたのですが。v6.7はv6.5のマイナーアップデートだと思って安心していたのにこんな罠があったとは。昨日今日で対策した記録。環境はこんな感じです。

・ホスト HPの2ソケットサーバメモリ64GB x2台 ESXi 6.7.0 Update 3 (Build 14320388)
・vCenter Server 6.7 アプライアンス

症状：

vCenter起動直後はアクセスできるものの、10分ほどで503エラーでアクセスできない。

直接の原因：
vCenterのイベントログ肥大

イベントログ肥大を引き起こした原因：
ESXi6.7.0 Update 3 (Build 14320388)のバージョン不具合?


以下解消手順を順を追って書きます。次のアップデートでこの情報は不要になっていると嬉しいですね。

１．肥大化したログのデータベースを縮小

まず見つかったのがこちら。サービスが立ち上がっているか確認しろというものでした。たしかにサービスはおっしゃるとおり落ちているのですが役に立たず。
https://kb.vmware.com/articleview?docid=2121043&lang=ja
VMware-KB「vSphere Web Client に接続すると「503 サービスを使用できません (503 service unavailable)」エラーが発生する (2121043)」

次に見つかったのがこちら。
http://friendsnow.hatenablog.com/entry/2018/10/07/104435

 VCSA6.7 で「503 Service Unavailable」エラー
＞私が経験した事象では、vpxd を上記手順及び、VCSA 再起動により起動しても、すぐに Stopped になりました。
＞原因はデーターベースの肥大化に起因するものと判明しました。対処方法は以下のとおりです。


これだ。早速確認。
vCenterにSSHで入ってシェルを起動
> shell
サービスvpxdが止まっていたら起動
# service-control --status
# service-control --restart vpxd
# service-control --start vpxd
# service-control --status vpxd


/storage/seat 領域を確認、ほぼ満杯。
# df -h /dev/mapper/seat_vg-seat
Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/seat_vg-seat  9.8G  8.5G  747M  93% /storage/seat


postgresに接続して肥大化しているテーブルを縮小します。
# cd /opt/vmware/vpostgres/current/bin 
# ./psql -d VCDB -U postgres 

テーブルのサイズが大きい順に10個表示させます。元記事では5個表示でしたが結構たくさんありました。
VCDB=# SELECT nspname || '.' || relname AS "relation", pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size" FROM pg_class C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace) WHERE nspname NOT IN ('pg_catalog', 'information_schema') AND C.relkind <> 'i' AND nspname !~ '^pg_toast' ORDER BY pg_total_relation_size(C.oid) DESC LIMIT 10; 

      relation       | total_size 
---------------------+------------
 vc.vpx_event_arg_56 | 250 MB
 vc.vpx_event_arg_60 | 250 MB
 vc.vpx_event_arg_64 | 247 MB
 vc.vpx_event_arg_55 | 244 MB
 vc.vpx_event_arg_59 | 242 MB
・
・
・

VCDB=# truncate table vc.vpx_event_arg_56 cascade;
VCDB=# truncate table vc.vpx_event_arg_60 cascade;
と順に削除していきます。消してもう一度表示させて。を繰り返します。
全部で２０−３０個ほど消したかな。数十MB以上のログのテーブルを消して容量チェックします。


root@photon-machine [ /opt/vmware/vpostgres/current/bin ]# df -h /dev/mapper/seat_vg-seat
Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/seat_vg-seat  9.8G   83M  9.2G   1% /storage/seat

と8.5G→83Mに劇的に減らせました。当分vCenterが落ちることはないでしょう。

vCenterにSYSLOG設定し原因を確認できるようにしていったん終了

またすぐテーブルは満杯になると思われますので、syslogを取ります。
https://vCenterのIPアドレス:5480/　にログインして「syslog → 転送設定」でsyslogホストを指定します。




2.ログが肥大化する原因を解消する

明くる日チェックしていきます。syslogサーバにログがもう300M超たまっています。

vCenterにもSSHログインして見ると83Mまで減っていたログのテーブルが12時間ほどでまた316Mまで増えています。vCenterが重かったのもきっとこのことが原因でしょうか。ログ肥大化の原因をなくさないといけなので、確認していきます。


syslogサーバに多量に出ているログはこれ。hardware sensorアラームって書いてますね。

Nov 11 13:29:35 photon-machine vpxd[4607] Event [38319679] [1-1] [2019-11-11T04:29:35.720596Z] [vim.event.AlarmSnmpCompletedEvent] [info] [] [Datacenter] [38319679] [Alarm 'Host hardware sensor state': an SNMP trap for entity 192.168.xx.yy was sent]
Nov 11 13:29:35 photon-machine vpxd[4607] Event [38319680] [1-1] [2019-11-11T04:29:35.720692Z] [vim.event.EventEx] [error] [] [Datacenter] [38319680] [Alarm 'Host hardware sensor state' on 192.168.xx.yy triggered by event 38319134 'Sensor -1 type , Description Intel Corporation Xeon E7 v3/Xeon E5 v3/Core i7 Integrated Memory Controller 1 Channel 0 Thermal Control #23 state assert for . Part Name/Number N/A N/A Manufacturer N/A']


今度はVMware-KBがマッチ。
https://kb.vmware.com/s/article/74607
Excessive Hardware health alarms being triggered for "Sensor -1 type" on ESXi hosts running vSphere 6.7 U3 (74607)
のページにThis article provides information and workaround for the hardware health alarms getting triggered (for sensor -1 type) on ESX hosts running vSphere 6.7U3 build-14320388. って書いている。ちょうどうちのESXiのバージョンです。SEATパーティションサイズが95%越えるとvCenterが起動しなくなると書いてあるのも、そのまんまです。
Additionally, these events can result in the vCenter database increasing in size leading to insufficient disk space issues such as vCenter unavailability once the SEAT partition size goes above the 95% threshold.


対応は wbemサービスを無効にすればいいと書いてあります。停止してもいいのか？
https://kb.vmware.com/s/article/1025757?lang=ja
注：CIM エージェントはハードウェア健全性情報を提供するプロセスです。このサービスを無効にすると、ハードウェアの健全性ステータスが無効になります。

こーれーは。ずっと止めておくのはまずいんじゃん？でも仕方ないので提案どおり止めます。年末にでもESXiをアップデートしたらまた有効にできるか確認しよう。

vCenterにSSHログインして、shellを起動して次のコマンドを実行。
esxcli system wbem set --enable false

実行直後から多量のログは出なくなりました。vCenterのレスポンスも改善しています。
もとに戻すときは反対にこうしろと書いています。
esxcli system wbem set --enable true


以上です。


コメント

コメントを投稿

このブログの人気の投稿

OfficeのISOダウンロード直リンク

-
Outlookの動作検証用に、各バージョンのOfficeのISOインストーラが必要になりました。以下のMicrosoftサイトのリンクからISOファイルをダウンロードできます。 どれも試用版ではなくリテール製品版です。認証しないでインストールする場合は、5日間試用できるようでした。助かりました。   検証の結果ですが2016以降のバージョンだと、Outlookはどのバージョンのものをインストールしても、もちろんインストール直後のアップデート前の挙動は当然違うのですが、 しばらく放置してアップデートがかかると結局全部同じバージョンの最新版になることがわかりました。Office365のOutlookも同じです。いやほんとびっくりです。そういうものなんですね。 途中までリンクは同じで、最後をProPlus2024Retail.img とか ProPlus2021Retail.img　とかすれば落ちてきます。将来バージョンが上がっても同じでいけそうです。 Office 2024 ProPlus https://officecdn.microsoft.com/db/492350f6-3a01-4f97-b9c0-c7c6ddf67d60/media/ja-jp/ProPlus2024Retail.img https://officecdn.microsoft.com/db/492350f6-3a01-4f97-b9c0-c7c6ddf67d60/media/en-us/ProPlus2024Retail.img Office 2021 ProPlus https://officecdn.microsoft.com/db/492350f6-3a01-4f97-b9c0-c7c6ddf67d60/media/ja-jp/ProPlus2021Retail.img https://officecdn.microsoft.com/db/492350f6-3a01-4f97-b9c0-c7c6ddf67d60/media/en-us/ProPlus2021Retail.img Office 2019 ProPlus https://officecdn.microsoft.com/pr/492350f6-3a01-4f97-b9c0-c7c6ddf...
続きを読む

FortiGateシリーズ 40F/50E/60E/60F/80F/90E/100E/100F/200FのCPU

-
イメージ
FortiGate使いやすくていいですね。でも機種選定するときメーカー公表のファイアウォールスループットだけでは、性能差がわかりにくいんですよね。サイジング難しい。 カタログ値だと50Eと60Eで同じだし。CPUとメモリはどうなってるの？と確認しようと思っても書いてない。。。。 というわけで実機にあたって調べてみたのがこれ。 機種 カタログ FWスループット ASIC CPU コア数 メモリ 40F 5Gbps SOC4 ARMv8 4コア 1918MB 50E 3Gbps なし ARMv7 2コア 2024MB 60E 3Gbps SOC3 ARMv7 4コア 1866MB 60F 10Gbps SOC4 ARMv8 8コア 1919MB 80F 10Gbps SOC4 ARMv8 8コア 3718MB 90E 4.0Gbps なし Atom C2338@1.74GHz 2コア 2010MB 100E 7.4Gbps SOC3 ARMv7 4コア 3039MB 100F 20Gbps SOC4 ARMv8 8コア 3616MB カタログ数値だけだと50Eも60Eも90Eも変わらなそうでしたがCPUが50Eは2コアなのが60Eは4コアに加えてASICも積んでるし！　90EのCPUはAtomの2コアでSOCなしってことはCPUパワーだけでゴリゴリするマッチョな機種。100Eは60Eと構成同じ。。。と興味深いです。世代が変わると60Fはいきなり8コア。100Eのスペック越えてきたけどホントかな。ルータやFWってカタログ値では劣る上位機種の方がやっぱりCPU性能が良くてトラブル発生時や高負荷に耐えられるとかままあるのでカタログ数値だけ鵜呑みにするのは危険だよね。高スループットは専用チップで負荷がオフロードされる時というのを忘れないようにします。 200FもXeonだ！！！D-1627 90Eまではランチボックス形状でファンレス。100Eからはラックマウントでファン付きです。100Eは結構ファン音しますからサーバ室に設置必須です。一方新しい100Fのファンはさすが静音化していて起動が完了するとファン音はほぼ聞こえなくなっています。これなら事務室にも置けますよ。90Eはあっとい...
続きを読む

ネクストのIPv6網内折り返し通信で高速VPN

-
（2021/04/08 ネクストをとりまく状況も変わっていますので書き直しました）  ネクストでは半固定で割り当てられるIPv6アドレスの網内折り返し通信が可能です。西日本では「v6オプション」の申込みが必要だったのが2021年5月11日の新規開通分からはデフォルト有効になり申込みの必要も無くなります。東日本では以前からデフォルト有効。 IPv6アドレス半固定 というのが若干問題 ですが最近のRTXシリーズではFQDNで張れば大丈夫です。 別途ダイナミックDNSを登録してFQDNでVPN、、、という記事もありますが、NTT西日本のサイトをよく読むと「v6ネーム」はIPv6アドレスが変わっても追従すると書いています。うちでも、ひかり電話を契約したり解約したり、IPv6プロバイダーを契約したり解約したり別のプロバイダーからもらい直したりを繰り返しそのたびにIPv6アドレスが変わりましたが、ちゃんと追従してくれていました。安心して「v6ネーム」を使って大丈夫。 以下はいまさらデフォルトゲートウェイがPPPoE設定ですが、汎用性があるということでそのまま残しておきます。いまうちで実際に運用サポートしているユーザ企業は、IPoEプロバイダーと固定IPv4の契約をしてIPv6とIPv4のVPNを2重化する構成で自動切り替え設定もしていますがまたそれは別途。良ければ声をかけてください。 Luaスクリプトの動くヤマハでないとIPoE系プロバイダで固定IP使えないし、古いRTXはこの際一掃して現行モデルを使います。今買うならRTX830/RTX1210。RTX1200もいい機種でしたがEMFS(メモリファイルシステム)使えないからlua入れるのが面倒だしそろそろメインからは引退。 RTXの設定 対向拠点の設定は192.168.1を192.168.0に入れ替えるだけで同じ。ひかり電話なし契約IPv6はRAです。ひかり電話があってもホームゲートウェイのLANポートに接続するのでこの例で大丈夫です。テストではホームゲートウェイの型番が400シリーズ以降なら速度低下はないようです。ひかり電話オフィスは別途。 ＜IPv4LAN関係＞ ip route default gateway pp 1 ip lan1 address 192.168.1.1/24 ip rout...
続きを読む