あいさつ
お久しぶりです。ｙｋｇｒです。
記事自体を書くのもかなり久しぶりです。私事ですが、就職して退職するというサイクルを行ったりと身近で色々あったからという表向きの理由を置いておきながら単純に記事を書くのをめんどくさく途中で書き止まっている記事がたくさんあったりします。仕事で触っていたWindowsServer系の記事は、動画化したあと記事にしてもっと詳しくメモとして残しておこうと考えていたもののそれも途中で力尽きていました…今度いつか必ず頑張ると思う。
本題
さっそく今回のトラブルの状況を説明していきます。
舞台となった鍵鯖マイクラ
今回の舞台というほどでも無いのですが、最近 vaultroom というアジア最大級規模のゲーミングコミュニティーが主催するDiscordサーバー、「鍵鯖-Vaultroom」で一般ユーザーも参加出来るイベント「鍵鯖マイクラ」にｙｋｇｒも参加しており、たくさん遊ばせてもらった。
このイベントで複数のユーザーと関わりを持つこともでき、小学生時代に知り合ったゲーム友達とずっとフレンドの輪を広げずに遊んで生きた自分としてはとても体験したことのない経験だった。
ここでの交流によって出来た繋がりを活かし、数日間限定でマイクラ交流鯖をホストすることになった。
（なんなら使ってもらえるように無料で売り込んだ）
１.問題発生
この鯖をホストすることが決定したのが大体2026年6月23日の24:30頃らしい。
翌日の24日に動き出していたと思う。
そんな中、とあるアラートが飛んでくる。
２.アラートの内容
今回アラートが飛んできたのは、自宅でバックアップ用として使用しているBuffaloの法人向け製品NASシリーズ（TeraStation）のTS5410RHというもの。
前述した通り、VMのboot領域には他の製品を使用しているためすぐに影響があるというものではなかったが、それでもバックアップ領域が吹き飛んだということでこの豚のように結構焦ったものです。
そしてキキNavi（純正のリモート管理サービス）から届いたアラートの内容は、１つ目がおそらく「電源異常による異常切断」、２つ目が「ドライブ３のエラー」。
２つ目のアラートについては、１つ目の電源異常によるものだと考えられる。
これにより、２TBのHDD４台でRAID５を構築しているバックアップNASがデグレードモードに移行した。
だがこの障害は、ディスク４本をすべてフォーマットしRAIDを再構築することですぐに復帰した。
３.稼働中のVMからバックアップを取得
RAIDの再構築自体は、ディスクフォーマットですぐに復旧したため特に問題はなかったのだが、再構築したということはデータが消えているため、自分としてはすぐにでも稼働中のVMからバックアップを取得したいと考えていました。
NAS自体の速度も最新のものに比べるとかなり遅いため、２TBのデータをコピーするにも毎秒４０MB／ｓで単純計算すると１５時間かかる事になる。長い。。。
４.突然の再起動
その時は突然きた。（以下、サーバーログ一部抜粋）
[09:34:52] [Server thread/INFO]: <MCID> tried to swim in lava
[09:35:01] [Server thread/INFO]: Stopping the server
[09:35:01] [Server thread/INFO]: Stopping server
[09:35:01] [Server thread/INFO]: Saving players
[09:35:01] [Server thread/INFO]: <MCID> lost connection: Server closed
[09:35:01] [Server thread/INFO]: <MCID> left the game
[09:35:01] [Server thread/INFO]: <MCID> lost connection: Server closed
[09:35:01] [Server thread/INFO]: <MCID> left the game
[09:35:01] [Server thread/INFO]: <MCID> lost connection: Server closed
[09:35:01] [Server thread/INFO]: <MCID> left the game
[09:35:01] [Server thread/INFO]: <MCID> lost connection: Server closed
[09:35:01] [Server thread/INFO]: <MCID> left the game
[09:35:01] [Server thread/INFO]: Saving worlds
[09:35:01] [Server thread/INFO]: Saving chunks for level 'ServerLevel[world]'/minecraft:overworld処理としては正しく実行されているものの、誰一人として停止操作は行っていない。
タイミングとしては、自分が溶岩に飛び込み死亡した９秒後であった為なにかしてしまったのかと非常に焦りました。とりあえずサーバーが落ちた場合も systemd にサービスとして登録しているため、自動復帰はするのだがそれだけでは可用性が高いとは言えないだろう。
幸い、日曜の朝９時という事もありログイン人数は自分を含めた４人のみで最小限の被害とも言える。
現在もはっきりとした原因がわかっているわけではないが恐らく、Proxmox上で行ったVMのフルバックアップが原因なのではないかと考えている。とりあえず結論付けるとするなら、「バックアップ時のフリーズスキップが原因で、じわじわとJVMに不整合（データの歪み）が蓄積し、17時間後の朝、特定のデータ処理が走った瞬間に限界を迎えてサーバーが停止した」というのが一番しっくり来るのかなぁといったところです。。。（by gemini）
５.対策
早い話、Proxmox環境なのでVMバックアップ時のフリーズ処理に「QEMU Guest Agent」を導入すれば解決する。ファイルシステムのフリーズ以外にも導入メリットがある。
- VMのファイルシステムのフリーズ
- Proxmox管理画面でのIP情報の表示
- シャットダウン時の動作がしっかりとOSに指示してくれる
など
Step.１ー管理画面からエージェントの有効化
管理画面ログイン後、対象のVMを選択 → オプション → 「QEMU Guest Agent」
「編集」をクリック → 「Qemuゲストエージェントを使用」にチェック → OK
Step.２ーゲストにエージェントをインストール
ゲストOSのコンソールからapt経由でインストール
apt-get update
apt-get upgrade -y
apt-get install qemu-guest-agent
systemctl start qemu-guest-agent
systemctl enable qemu-guest-agentStep.３ー確認
systemctl statusなどでステータスを確認し、activeになっていれば成功
正しく導入できていれば管理画面からIPやMACアドレスの確認ができるようになっていると思います。
