今回のサーバー障害の直接的な原因は、どうやらシステムファイルの破損?だったらしい。
GMOクラウド社側で、サーバー起動時のエラーログを分析して、
ベンダーの回答待ちだったために、土・日は何もできずに週明けにならない対応できません!
ということだったらしい。
結局、月曜日になっても復旧目途の連絡は来なかったが、きちんと対応してくれていたらしく、
夜になって復旧していたことが確認できた。
次の日になって、以下の連絡をいただいた。
+
+ VPSサーバー内に設置されていたライブラリ(lib)ファイル、およびそのシンボリックリンクの影響により、
+ VPSが起動できない状態となっておりました。
+
+ そのため、該当のファイルおよびシンボリックリンクへの対処を行いましたところ、
+ 正常に起動可能な状態となりました。
+ 原因となったファイルにつきましては、一時的にVPSの「/root」配下へ移動いたしております。
+
+ 対象ファイル : /root/ld-linux.so.2
+
サーバーは起動したけれども、Plesk側でシステムエラーを吐いていたので、すぐには回復しなかった。
障害になる直前、Pleskのアップデート失敗のログも出ていたので、Pleskのシステムも破損していたらしい。
Pleskは自動修復機能も充実しているので、サーバーコンポーネントの[更新] 等をやったら、回復した。
それにしても、数日間にわたるサーバーの停止というのは、とてもダメージが大きい。
一時的な障害とは違って、受信メールもエラー返送されてしまうので、心象も悪くなるだろう。
システムファイルの破損が原因でサーバーが起動しないトラブルは、
20年くらい前にも一度経験しているが、
今回のようにマシン本体が起動しないと、どうにも対処できないので辛い。
Raq550サーバーで cce が起動しない問題が解決!
https://shunichi.hosono.com/?p=133
サーバー障害をゼロにすることを目指すのは当然ではあるが、
想定外の事態が起きて、やむなく障害になってしまうケースも、残念ながら、ある。
「想定外もあり得る」ということを否定していたら、現実的な対応はできない。
今後は、
「サーバーが落ちても、困らないサービス」を最優先にしようと思う。
そのヒントは、
「サーバーが落ちていたのに、このブログはなぜ生きていたのか?」というところにある。
サーバーが物理的にダウンして、WEBもメールも何にも機能しなくなっても、
DNSだけは冗長化されているので、別のサーバーでサービスを継続することができるのだ。
このブログは、Google社のBloggerというサービスを利用しているので影響を受けなかった。
外部サービスとうまく連携しながら、DNSの冗長性を生かして、
サーバー障害が起きても、慌てず騒がず、安心して使えるサービスを提供しようと思う。
0 件のコメント:
コメントを投稿