Proxmoxでコンテナ on コンテナして自鯖落とした話
概要
心臓に悪いJournalctlのログからこんにちは。知ってる人は知ってると思いますが、僕は自宅のサーバー用自作PCにProxmoxを入れてVMだのLXCだのを建てて遊んでいます。今回は、そんな自宅サーバーで僕の怠慢と理解不足が原因で起こった悲劇とその対応なんかについて失敗談日記を詳しく書こうかなと思います。
序章
2024年夏ごろに、ついに夢だった自宅サーバーを完成させた僕はとてもハッピーでした。最初はUbuntu server 24.04 LTSを入れて遊んでいたのですが、フォロワーからProxmoxの存在を教えてもらいました。VMやLinuxコンテナ（LXC）（今回の主役）を使ったwebアプリやその他諸々なんかを同時に隔離した環境で動かせるうえに、webGUIから全てを管理できると見た時には衝撃を受けた覚えがあります。
そんなこんなで色々動かして学ぶ中で、当時の僕は「VMはカーネルごとホストと分離してるけど、その分RAMなどリソース消費量が多い。一方でLXCはカーネルはホストと共有だけど、その分リソース消費量が少なくて、しかも初期設定がVMに比べて楽だ。」という認識を持っていました。当時の弊サーバー機はRAMの搭載量がそれほど多くなく、VMを乱立すると使用量がカツカツになるという問題点があったので、バカオタク（僕）は「これ、わざわざVM建てないでも全部LXCで良くね？」と考え、マイクラサーバーが動いているVM以外のほぼすべてのサービスをLXC環境に移しました。この移行したものや新規で動かしたサービスの大半はDockerで動いていたものでした。
もちろんこの対応で、VMによってカツカツだったRAM使用量にかなり余裕ができたのも事実です。しかし、その後しばらくしてあれほどキモイからやめておけと言われたコンテナ on コンテナをしたことを僕は後悔することになります。
発端
前述した「新規で動かしたサービス」に含まれる、Uptime Kumaというセルフホスト用のステータスページ管理ツールがあります。
このツール、ただページを作るだけではなく、連携サービスを色々設定してあげると、下の画像のような感じでサービスが落ちたり復旧したりしたときにdiscordに通知を送ってくれるようにできます。
ネットワークが一瞬途切れたとか、少しロード時間が長かったみたいな症状でも通知を送ってくるのですが、そういった実際には落ちていないような場面ではdown通知のあとにすぐupの通知が来ます。これは割とよくある現象で、down通知がきても実際のところは全く問題がない場合がほとんどだったので、このdown通知を真剣とらえるということはしていませんでした。
ある日のこと、朝8時ごろに起きてdiscordを見てみると「lxc上のdockerコンテナで動かしているwiki-jsが落ちてるよ！」と通知が来ていました。その日はちょうど午前中からバイトだった上に、前述の通りdown通知があってもたいていの場合すぐ復旧していたことから、「またいつものパターンだろう」と考えた僕は通知とサーバーを放置してバイトに行きました。
障害
上の通知の送信時間をよく見てください。朝起きた時点でこの通知は最新、そして通知の送信時間はその日の午前3時。つまり、これはいつものdown→upという挙動ではなく、実は起床時点で既にこのwikiシステムがダウンしてから5時間経過していたということになります。送信時間を全く見ていなかった僕は勝手にいつものパターンだと思って放置しましたが、実際にはこの時点でガッツリ障害が起きていたというわけです。
バイトから帰宅して色々やった僕は、自サーバーでホストしているMisskey(SNS)のインスタンスから502 Bad gatewayが返されてアクセスできないことに気付きました。down通知は出ていないのに、です。他のwebサービスについても同様で、マイクラサーバーも何故か止まっていました。流石におかしいと感じProxmoxのwebGUIにアクセスしたところ、エラーは出ずにアクセスはできるものの、いつものログイン画面や管理画面が一切表示されず真っ白になるか、他と同様502が返されるかが更新するたびに変わるという状況になっていました。
webGUIからアクセスできない＆その後試したsshも通らない以上、残された手段はサーバー機にHDMI挿して直接コンソール叩くだけとなりました。そして画面に映し出されたコンソールが……
お祈りと原因究明
これです。
完全に異常ですね。もうこれは再起動しかないだろうと即座に判断した僕は、サーバー機の電源を長押しして再起動をかけました。いや本当に気が気ではなかったです。当時はバックアップ体制も一切なかったので、データが飛んだりサーバーの何かの故障だったりした場合復旧手段が一切ない状態でした。神に祈りながら画面の出力をしたところ………復活しました！
あの瞬間地球上の誰よりも安堵していた自信があります（何）。全体的に動作に問題がなさそうなことを確認したらやることは原因究明です。早速chatGPTくんに「Debianでシステムのログを見る方法を教えてください」と聞いたところ、journalctlなるコマンドを教えてもらいました。この記事をここまで読んでくれている方なら恐らくどういったコマンドかはわかると思うので説明は割愛させていただきますが、それを使用して前回起動時のエラーログだけを絞って確認したところ以下のログが得られました。
1～3行目に答えが書いてありますね。
Fixing recursive fault but reboot is needed!
BUG: scheduling while atomic: dockerd/579097/0x00000000
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks
まあ要するにdockerdによってカーネルパニックが起きていたわけです。先ほどのログと再起動前に何故か表示されていたプロセスリストを見たりしながら推測したのは
- dockerがコンテナ作成時にruncを動かす
- runcがproxmoxホストのカーネル機能を使おうとするものの、バグによりカーネル内で応答不能に陥る
- runcの実行に失敗したdockerが再試行を何度も繰り返す
- 応答不能のruncがプロセスリストに残り続け、システムのリソースを使いつくすレベルの山ができる
- 山からCPUが解放されず後続プロセスが詰まり、カーネルのスケジューラが破綻する
- それにより、本来割り込み禁止（atomic）になっている状態にスケジュール処理（scheduling）を行おうとしてしまう
- 上記の割り込み処理の矛盾により、カーネルパニック
- 結果全てのVMとLXC、ProxmoxVE自体が停止
という流れです。前述したステータスページで恐らく本件の犯人であろうwiki-js以外のダウンを一切検知できていないのも、LXCがProxmoxホストごと巻き込んでダウンしたという部分に起因します。ステータスページも同じマシン上の他のLXCで動かしていたため、ホストごと落ちてしまうと障害を検知できません。
上記1,2の部分がまさにそうですが、この障害はdockerをLXCで動かしているから起きたものと言えます。もしVMで動かしていたなら、仮にこういった症状が起きていたとしてもそれはVMのカーネルパニックを引き起こしてVM単体でダウンするだけで、今回のようにホストマシンと他VM, LXCを全て巻き込むということにはなりません。今回のdockerに起因するバグがコンテナ on コンテナ状態だったから起きたのかは定かではありませんが、防げたものを起こしてしまったという点でコンテナにコンテナ乗せるな！という先人の言葉は素直に受け取っておくべきだったなと思います。
おわり
今回は障害に気付くのが遅くても大丈夫なパターンだったから良かったものの、仮に発見が遅れたことが原因でデータが消えるなんてことがあったらたまったものじゃないので、通知と時間はしっかり見ようと思いました。あと、停電や物理マシン自体の破損だとか、自宅サーバーは安定稼働の点で色々と課題があるので、本来ならステータスページは別ネットワークで動かした方がいいなと思いました（お金がないのでキツイんですが）。自宅サーバーにはオーバースペックな上にほぼギャグになってますが、先日のCloudflare大規模障害で発掘されていたDownDetector's DownDetector's DownDetector's DownDetectorみたいなのも面白いですよね。
今現在はサーバーのリソースに余裕ができたこともあり、以前LXCに全移行したdockerのあれこれはVMに移しました。以降一度もこういった大規模な障害は起きていません（夏に冷却不足で落ちたことはありましたが…）。この障害対応と原因究明から学んだのは、先人が言ってることには素直に従えということはもちろん、ログさえ残っていれば大体何でもわかるんだなということ、あとは障害は心臓に悪いということですかね…
ここまで読んでくれてありがとうございました。良ければ下のいいねボタン押してください。僕が喜びます！障害対応万歳！！！
