昨年(2024年)末からESXi機が絶不調になり、そのうちリセットしても一週間も経たないうちに固まったりリセットがかかったり、ということが続いていた。
結局ホスト機のマザーとかの不調というよりも、どうもmiscmemo blogを運用していた何でもubuntu VMの一部コンテナであるこのblogのコンテナのどれかが触られると固まるような気がしてきた。他のVM動かしても止まらないし。
そんなこんなでストレージも取り替え、ようやくこのblogをホストしているwordpress containerが復活したのでその顛末。
ESXi機不調
昨年(2024年)末ごろ、ESXi機に不調になり、突然反応がなくなる、突然リブートしてたり(ESXiコントロール画面で見ると、全VMが落ちている)といった事象が頻発していた。
熱暴走かな？と思ってある日本体を開けてみると、CPUファン近辺にホコリがみっしり。辛うじてファンは回っていたもののあまりの驚きに写真を撮るさえ忘れてしまった。これはエアダスターなどを駆使して除去し、一安心。
しかしその後も同じような不具合は頻発する。
- ACアダプタにはおそらく通電時には光るであろうLEDがついているが、全く光っていない。が、通常通り通電はしているように見える。もし不具合があるのだとしたら、出力が足りないのかもしれない
- ハードウェアの不具合だとすると、メモリが壊れている可能性もある。memtest86という世間でよく使われているらしいメモリテストソフトを使ってみた。これは特定のOSの上で動くアプリではなくこれごとbootしてメモリテストだけを行う。64GBに対して8時間ほどかかった。が、特に異常なし。
- 負荷がかかったに落ちるのかと、FreeBSD VMでyesをbackgroundで実行。このHWでこんなにファンが回るのかというくらいまで周り、消費電力も増えていることを確認したが、落ちなかった。
これらをやってもやはり数日で落ちる。
しばらくして分かったことは、しばらく落ちてなくても、どうやらubuntuを立ち上げて、この日記用コンテナをあげると、翌日くらいには落ちてるパターンが多かった、ということだ。
特定のVMがストレージの特定の場所(ここはきっとこの特定のVMに占有されているだろう)にアクセスするとハードウェア的に不安定になって落ちたりリセットがかかるのかもしれない。通常ストレージの一部が読めなくなったとしても、動いているVMにはエラーで読めなかったというステータスが返ってきてそのVMが不安定になるだけだが、今回の場合は何かハードウェア的な秘孔を突いた、ということなのかもしれぬ。
その傍証として、ホストハードウェアの交換も視野に入れてVMのイメージを別の場所にコピーしていた時、他のVMのイメージは時間はかかったとしても比較的リーズナブルな時間でコピーまたは移動は完了するのだが、ubuntu imageだけはなかなか終わらず、最後にはホストのUIも反応しなくなったということがあった。
このホスト機を導入した経緯はESXi機アップデートにあり。
Ununtuの必要データをサルベージ
ubuntuをはじめとするいくつかのVMは本体内のM.2 SSDに入っていたのだが、ubuntu以外は正常に外部のストレージに引越できた。
ubuntuはセッション繋ぎっぱなし用デスクトップとして使ったり、何も入っていないgitlabやkernel build専用のコンテナをホストしたりしていたが、これらはともかく、このブログは個人的に有用かもしれないメモとかあるので、何とかして救いたかった。救うべきものは三つ
- wordpress コンテナ
- wordpressコンテナが永続化ファイルとしてマウントしているwordpress用の各種ファイル
- mysqlコンテナ
- mysqlが持っている永続化されたデータ
コンテナ系はdocker saveで保存。復帰後にdocker loadでイメージを戻す。
永続ファイルとしてあるホストにあるファイルは、wordpressの方は単純にtarで固める。mysqlはデータファイルを復活できるかが自信なかったので、mysql dumpで全データをmysqlのコマンドとして吐き出す。
$ mysqldump -h localhost -u root --ssl-mode=DISABLE -p<password> wordpress > mysql-backup.sql
これらの過程でシステム不安定化させている秘孔をつかないとも限らないが、今回は何とか乗り切ったようだった。
VMホスト機再構築へ
ストレージ調達
とりあえずストレージが怪しいということで、新しいのを調達することとした。今使っているのはCrucialのやつだが、結構安めのものを選んでいた。もしかしてTBWの値も小さかったのかもしれない。
この反省を生かして、もっとよさそうなデータセンタークオリティということになっているWestern DigitalのWD Redにすることとした。(あれ、データセンタークオリティを謳っているのはWD Red Proだったかな)
買ったのはこれ。WDS100T1R0C [WD Red SN700 NVMe SSD（1TB M.2(2280) PCIe Gen3 x4 NVMe 2000TBW 5年保証）] [Amazon]
OS選定とインストール
何とか掬い上げたVM達を何とかそのまま使いたいということで、できればESXiを使いたいところだが、ESXiは去年のbroadcomの方針により無料バージョンがなくなった。
今使っていたESXi7のインストールメディアを探し出してそれを使うかと思っていたがそういえば一時期の不用品大パージのおりに使わないCD-ROMとか纏めて捨てたんだった。せめてイメージだけでも残っていないかとそれっぽいところも探したが、intel NIC対応インストールメディアを作る時の残骸があっただけだった。これでESXiの目はなくなった。Proxmoxにするかなあと思っていたところへESXi8.0u3が派手なアナウンスもなく、さらっと無料化復活へ、という情報が。
これはbroadcomで会員アカウントを作ればあとは無料でDLできるらしい。しかもIntel 226vドライバも対応。早速インストールしてみる。ちゃんとNICも認識した。webのデザインもだいぶフラット化というのかそんな感じだ。外部NASのiscsiも認識した。iscsiまたはNFSに置いたVMもあらかた復活できた。
ただ、今回も突然ホストごと固まるという事象が何回か散見された。ディスプレイが繋がっていないため、固まるとどうにもわからないので、ディスプレイは繋ぎっぱなしにしておく。
何回かはESXiの待機画面のまま固まっていた。後はいわゆるPSOD(Purple Screen Of Damage)の画面。
これをよくみると、PCPU 11: no heartbeatとある。何だかよくわからないが、PCPU(Performance CPU?)11が死んでるということのようにもみえる。もしかしたらC-StateとかでCPUが一旦寝てしまうと起きてこないのかもしれない。
BIOS設定画面でP-StateとかC-Stateっぽい設定があったので、それらをdisableしてみる。ただ同じ筐体のデフォルト設定でESXi7は何年も動いていたのに？
ただ、これらの設定で、とりあえずは今はまだ理不尽なリセットは起きていない。
最悪この理不尽リセットが続くようであれば、機種移行も検討しなければならない。今考えているのがhttps://amzn.to/4dF8tTO 8C16T AMD Ryzen 7 PRO 6850H。amazonでは度々セールをしていて5万円弱。AliExpressだとベアボーンでもっと安く売っている。
ubuntu復活
前述のように他のVMはvmx右クリックですぐ復活できたが、ubuntu imageはサルベージできなかったので、OSインストールからやり直す必要がある。
desktopの設定、dockerのインストールは通常通り。
その先の設定、実はこのblogの最初の記事に書いてあるので、このblogを復活させないと設定方法がわからないという実に缶切りは缶詰の中状態。サルベージしたsqlファイルの中身を見たり、何とか思い出して設定を行なった。
ここのdockerホストはcontainer networkに対してNATではなくL3 networkを提供するようにしているので、このdockerdに対してはiptablesを無効化し、提供するIPv6のprefixを指定する。
ExecStart=/usr/bin/dockerd --iptables=FALSE --ipv6 --fixed-cidr-v6="2001:2c0:cc17:c301::/64" -H fd://
各コンテナはまずバックアップしたファイルからimageをrestoreする。
sudo docker load < mysql5.7.21.tar.gz sudo docker load < miscmemo-wordpress-latest.tar.gz
これでimageは入った。
$ sudo docker images [sudo] momose のパスワード: REPOSITORY TAG IMAGE ID CREATED SIZE miscmemo-wordpress-latest latest 40af751e8d84 2 months ago 725MB hello-world latest 74cc54e27dc4 4 months ago 10.1kB mysql 5.7.21 5195076672a7 7 years ago 371MB
mysql containerを作成、DBを復旧させる。
sudo docker run -d --name wp-mysql -v /var/lib/mysql -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=mysql -e MYSQL_USER=wordpress -e MYSQL_PASSWORD=wordpress -p 3306:3306 mysql:5.7.21 mysql -h 127.0.0.1 -P 3306 -u root -p --ssl-mode=DISABLED < miscmemo-wordpress.backup/mysql-backup.sql
WordPressの永続化部分を展開。いろいろわかってなくて変なところに展開する
cd /var/www/html tar xfz <somewhere>/wordpress-data.tar.gz cd wp-content/wp-uploads tar xfz <somewhere>/wordpresss-uploads.tar.gv
しかたないので、そこ(/var/www/html)を永続化のvolumeとしてマウントすることにする。でもその前に、どうやらWordpressに登録してあるDBの接続情報が違っていたようなのでwp_config.php内のdefine( ‘DB_NAME’, ‘wordpress’ ), define( ‘DB_USER’, ‘root’ ), define( ‘DB_PASSWORD’, ‘root’ ); define( ‘DB_HOST’, ‘172.17.0.1’ ); を修正する。
で、wordpress containerを立ち上げる。
sudo docker run -v /var/www/html/:/var/www/html --name momose-wordpress -d miscmemo-wordpress-latest
ここにhttp://172.17.0.3/で繋げられればめでたしめでたし。
今後
- ここらへんのcontainerをdocker compose対応にする
- 定期的に止めて、中の埃を掃除する