treedown’s Report

システム管理者に巻き起こる様々な事象を読者の貴方へ報告するブログです。会社でも家庭でも"システム"に携わるすべての方の共感を目指しています。

※https化しました。その影響でしばらくリンク切れなどがあるかもしれませんが徐々に修正していきます。 リンク切れなどのお気づきの点がございましたらコメントなどでご指摘いただけますと助かります。

サーバが壊れた?と思ったら助かった話。

サーバの障害の連絡を受けて、あんな深刻な障害対応やこんな深刻な故障対処を思い出して戦々恐々としていたら、アッサリ終わったという話。

連絡は突然に

「サーバに繋がらなくなりましたよ。」
そんな連絡が入ってきたのがある日の午後の14:30過ぎたくらいのこと。
でも実はその10分前にそのサーバにアクセスしていたんですよね…。この10分の間に何があったのかしら?

軽い感じの連絡でしたが、事態は重大さを示していました。

すぐ、同じスイッチに接続されている別のサーバに接続してみます。うーん、特に問題は無し。
向こうでも同じように確認してくれていたらしく、
「スイッチHUBの故障じゃないみたいですね。」
っていうメッセージが同じタイミングでやってきました。

確認してもらった結果、サーバ1台にだけに接続できない、ということが分かりました。
と、なると、サーバ本体の問題ってことに。

繋がらなくなったサーバはDebianをOSにしたsambaサーバ、いわゆるファイルサーバです。
しかし、小規模な事業所にとってファイルサーバが唯一のサーバといってもいいような重要システム、これはなかなかヤバイ状況に思えます。

急いで準備。
最悪本体の故障も考えて、同じ部品を搭載した代替となる本体を携えて現地へ。
代替の用意をするのに、2時間くらい掛かっちゃった。

急いで

重たい代替を抱えてエッチラオッチラ。
頑張って向かった先にサーバが居ました。

さっそく切り分けのため状況確認をします。
サーバの前に行き、画面を付ける、コンソールを切り替えて…、と。
キーボードのEnterキーを押下して、まずコンソールログイン。

f:id:treedown:20190909002046p:plain※画面はイメージです
ん?なんの問題もなくユーザIDとパスワードを聞かれましたよ。
ログイン成功。

故障してまともに動作していないと思っていたサーバでしたが、あっけなく正常にログインできました。
正常にログインできました、ってことは故障じゃない?
なんとなく、期待半分、不安半分という感じがしてきました。サーバ再構築しなくていいのかも、っていう期待です。

ログイン後

正常にログインできた、ということは、ログを確認することができます。
早速ログを確認してみましたが、syslog以下、特にエラーが出ているということはありませんでした。
つまり、OSとしては「正常動作」を示しています。
そこで症状を改めて考えてみました。
「クライアントから共有フォルダへ通信ができなくなった」
「pingも応答を返さない(でもスイッチHUBは正常)」
うーん、ネットワーク関連?
さしあたり、「ifconfig -a」コマンドをを実行すると、サーバのIPアドレスがしっかり割り当てられていることは確認できました。
そこでpingを実行してみることにしました。

pingで切り分け

外部の存在するデフォルトゲートウェイアドレスを指定して実行すると、「Destination Host Unreachable」となってしまいます。

f:id:treedown:20190909002503p:plain※画面はイメージです。
正常なら「64 bytes from 192.168.xx.xx: icmp_seq=1 ttl=64 time=0.056 ms」という具合に実行結果が表示されるところが「Destination Host Unreachable」となるのもあって、通信は問題が起きているようでした。

うーん、ネットワークなのかな。昔の記事

blog.treedown.net

ここから、ちょっと切り分けてみます。

  1. ping 127.0.0.1 (ループバックアドレス)
  2. ping %自分のIPアドレス%
  3. ping %デフォルトゲートウェイのIPアドレス%
  4. ping %通信相手のIPアドレス%

ひとまず1~3をやってみましょう。

  1. ping 127.0.0.1⇒成功しました。応答があります。
  2. ping %自分のIPアドレス%⇒応答がありませんでした。「Destination Host Unreachable」
  3. ping %デフォルトゲートウェイのIPアドレス%⇒さっき試したので「Destination Host Unreachable」となることは確認済です。

うーん、と、いうことは、ですよ。自分の記事を引用すると、
「pingを実行するコンピュータ上で正しくTCP/IPがインストールされロードされているか、またドライバやデバイスに問題はないかも確認します。、またドライバやデバイスに問題はないかも確認します。(ループバックアドレスと多少被り気味)」
だよ、ってことになります。つまり、NICの問題ってことになってきますまいか?

対象をNICに絞ってみる

そこで

「このサーバのNICってオンボードNICなんですか?」

何気なく現地の方からの質問。
いや、これはPCIバス(旧式の)接続のNICを使っていますね。オンボードNICは100Base-Tなので、ギガビットイーサネット(100Base-T)の速度を出すためNICは増設しています。

「てことは、オンボードNICにサーバのIPを割り当てて切り替えたら、切り分けになりませんかね?」

なるほど…、確かに。
早速ネットワーク設定を変更、既存のIP設定を無効にしてオンボードNIC側に同じIPアドレスを割り当てて再度通信を再開してみます。

再起動後…。

何の問題も無く通信出来るじゃないですか。
てことは、増設のこのPCIバス接続のNICが故障したってことですか。

「え?うーん、まー、そうゆうこともありますよね。あまり信じられないけど。」

そこで、持ってきた代替機のPCIバスからNICを取り出し、サーバに搭載しているNICと交換、MACアドレスも変更になるしOSが認識するNIC自体もeth1⇒eth2と変わっちゃうから設定もそれに併せて変更して…と、作業完了後、動作確認を現地PCでお願いすると、無事アクセスが正常確認完了、これで障害対処完了となりました。

「いやぁ、NIC(のボード)そのものが故障する、ってそんなことあるんですね。私はそういうの遭遇したことないんですけど。」

うーん、確かに珍しい壊れ方ですね。でも運が良かったのか、壊れ方もそれほど深刻で無く、代替部品を用意していたからスムーズに故障交換で済んで良かったですね。

数キロはあろう本体の代替機をエッチラオッチラ運んだ労力は(結局NIC一枚交換するだけで正常動作が確認できたために)徒労に終わりましたが、障害がオオゴトにならなかったという安堵感から、重たい代替機を運んだ苦労もそれほど苦にはなっていませんでした。