2020localYouserオンプレミス-技術のお話し俺はな、ESXiのバージョンアップがしたかっただけなんだ全てはこれが始まりでして、現在稼働しているESXiサーバの内1台をESXi6.5->6.7にバージョンアップしようと考えました。影響が出そうなVMを停止の上で、とある一台のESXiサーバに対して6.7最新パッチを適用する形でのアップグレードを実施しました。すると、以下のような感じで芋づる式というか、次々とトラブルが起きました。メモリが減ってる起動してみるとあら不思議、それまで128GBメモリを積んでいたサーバ、改めて見返してみると96GBしかメモリが認識されていない・・・そんなバカなとiLOを開いてみるとメモリが1枚ご臨終召されてました。加えて、デュアルチャネル構成のために道連れでさらにもう1枚メモリが「不使用」状態になり、合計32GBのメモリ容量を失って居るではないですか・・・とは言え、動作は継続できそうなので、その内メモリは買い換えるとして、サーバは継続稼働させることにしたのです。サーバが落ちるなにやらサーバを立ち上げてる過程で、空耳?と言うレベルで「ピーピーピー」という音がサーバ設置部屋から聞こえてきたのです。んん?と気になって、実機を見てみるとなんと言うことでしょう・・・・・サーバがPOST画面になってるじゃないですか。Warningを出したメモリが悪さをしてCPUにエラーを吐かせて、結果としてPanicRebootが走ったようです。慌てて電源OFFして、ヘロヘロの体で嫁様の助けを借りながら障害発生したメモリを取り外して起動。動作できそうだというのは分かりました。Mastodonのデータベースが起動しないその次が悲惨で、なんとストレージも一通り上げたところでMastodonのインスタンスを起動するのですが、全く起動する気配がない。調べてみると、いつまでたってもMastodonのデータベースが開局しなさそうで。Kubernetes上で動かすPostgreSQLは、その起動途中でディレクトリのオーナー権をホストから奪取するためにデータディレクトリ全体に対してchownコマンドを実行するのですが、どーもこれに時間がかかりすぎていると。Cephの応答がおかしいで、バックエンドストレージであるCephを確認してみると、えらく応答が遅い。これはどういうことだと調べるところから、長い戦いが始まったわけでありますね。Cephで吐き出されていたエラードタバタしていてDashboardの画面は拾えませんでしたが、後に何とかログを拾えたのでこれを転載します。(SLOW_OPS)主に出ていたのは上記のようなエラーです。眺めてみるとmonプロセスがどっかのOSDがスタックしてるよと言うのを出しているようでした。この時点で、ESXiやVMの負荷を眺めてみたり、各ノードのvmstatを見たりiostatを見たりするわけですが、負荷は至っておとなしく。メモリ使用量が全体的に増大していたのでスワッピングが発生しており、これが原因か?と言う気もしたので、全ノードのswapをoffに設定した上で、fstabからもswap設定を解除したりしましたが、現象は改善せず。その後、色々あの手この手ストレージの移し替え等やるのですが、これまた改善の気配なし。chown処理は終わったけどchown処理が終わったのがどうやら午前6:30頃だったようで、その後はPostgreSQLも立ち上がってきたのですが、やっぱりどーも処理が遅い。データベースなんてまともに動いてる気配がしない上、下手すると一部のストレージオペレーションが5分以上スタックしている・・・・こりゃスローダウンとか言うカワイイ言葉じゃ済まないぞ?と思いながら、引き続きトラブルシュートを継続する私。「原因は4号機か?」って気づき始める私。v1157)いまいちどことどこの間で不具合が起きてるの?というのは流れるログの中ではよく分からず、ログを一度出力させてテキストエディタに吐き出させ、そして並べて見るとあることに気づくわけでして。「処理が全部192.168.100.114上で止まってる?」的な。4号機の配置先は最初にESXi6.7へバージョンアップさせた仮想ホスト上で動作しているVMです。msあら?全体的な統計を見たら5%もパケットロス起こしてるじゃないのさ。我が家仮想基盤の接続構成は上記の通りとなっています。太線が10GbE、細線が1GbE接続となっています。Ceph4号機のサービスセグメント側との疎通がうまくいってないぽいことが分かったので、仮想スイッチの切り替えを行いました。言う形に一気に変わりました。おお、これはサービスセグメント側にある10GbEラインのどっかで不具合が起きてるな?と言うのがこの時点ですぐに分かった次第です。考えられる問題パターンとしては以下のような感じですね。ドライバの問題・・・・ESXi6.7へ引き上げたことでドライバの不具合が発生した?NICの問題・・・・・・NICのハード障害が起きて通信断が発生するようになった?スイッチに問題・・・・アライドスイッチもしくはMikrotikのスイッチに何らかの不具合が出た?ケーブルに問題・・・・ケーブルの物理故障?で、切り分けをやった結果は以下の通りとなりました。3やっぱりパケット欠落あり。あり上記の結果から、どうやら2号機側のサービスLANに接続された10GbE側に何らかの問題がある・・・と言うのが分かりました。Mikrotikスイッチに接続してる側は全く問題ないことから、恐らくはNICそれ自体の問題ではなさそうに見えます。そこで、最終的には10GbEで使用しているDACに何らかの問題があるかもと言うことで、これをGbEのSFPと余ってたOM-2ケーブルに切り替えて接続し直したところ、最終的な不具合(断続的にvSphereHAエージェントエラーも出てる状況があった)も解消され、これが故障箇所だと言うことが明白となりました。暫定復旧として、色々周辺のハード周りを修理していこうと思うわけですが、いやはやこんだけいくつも色々壊れてるとちょっと辛いですなー・・・とか感じたり。それでも何とか破損箇所が洗い出せたのは良かったです。Linuxのping応答には気をつけよう。今回、ping応答を確認しながらトラブルシュートをしてた訳なんですが、ping応答の時ちょっと気をつけるポイントがあります。ロスった所が明示的に出てこないのです。msよくよく考えたらそもそも同一セグメント通信でこんだけばらつきがあるってどうなん?と言うのに気づくわけですが・・ハイライトしているところを見れば分かるんですが、2パケットほど応答が出来てないことが分かります。Replyが来るまで待つため、そこの応答遅延で異常に気づくんですが、Linuxだとこのような感じで、意外と目立ちません。実際の仕事でも、ping応答させながらvMotionしてみたりといったテストをすることはあるんですが、その時も意外とこれを見落として「パケットロストなし」と判定して、後でログ証跡を眺めたときに「あれあれ?」ってなることも多く、こうした出力特性はきちんと押さえておいて損はないかもです。