研究室内等のネットワーク系統の障害対応(弊研究室の某課題について考える16日目)
はじめに
この記事は3年間私が研究室で生活してきて、その際に起きた障害、それに対する対応を私なりにまとめたものです。
そのため今回の障害対応は基本的には小規模(要は研究室等の障害)であり第三者への不利益等は考えていないものです。
利益あたりが絡むのであればサービスの持続性等や対応等があるのでこの通りではありません。参考にしないでください。
アウトライン
- サンプルのネットワーク構図
- 日頃やること
- 障害が発生した時の対応
- 原因究明
- 再発防止
サンプルのネットワーク構図
この構図を元に説明していこうと思います
障害の定義
この記事での障害とは
- 計算機が利用できなくなる
- 計算機の動作が重い
- 特定のサービスが利用できない
といったことを指します
日頃やること
サーバで動いているサービスの把握はしておいてください。あるサービスを動かしているときにそのサービスが複数のデーモンで動いていないか等を確認しておくことは対応で役に立ちます。
障害発生した際にすぐやってはいけないこと
再起動する
再起動して解決する問題もあるかもしれませんが、「障害が発生した」⇒「再起動しよう」は何も解決してないのでやめましょう
障害が発生した時
障害がどこまでの範囲で発生しているのかを把握します。
例えばサンプルの構図では島の中の計算機だけなのか、それともサーバのスイッチ周りなのか、おおもとのスイッチ周りがダメでサンプル構図の全体で発生しているのかを確認しましょう。
例えば島の中の計算機だけが同じ障害を発生しており別の島で発生していなければ、その島だけの問題なので「スイッチの故障」「大本のスイッチから島のスイッチまでのLANケーブルの破損」等が考えられます。
小さいところから大きいところに確認していくのがいいと思います。「自分の島」⇒「ほかの島」⇒「サーバのデーモン確認」⇒「大本のスイッチ」⇒「建物全体」みたいな感じです。建物全体になるともう一研究室の一人としては何もできないのでスルー
切り分けた障害における対応
小さい範囲から大きい範囲まで順に対応方法を説明します。
個人の端末のみ
考えられる原因
- 大量のパケット処理による遅延
- 島のスイッチから計算機のLANケーブルの破損
- スイッチの端末とつながってるところだけが壊れてる(ほぼない)
- NICの破損(まずない)
大体上の2つが原因として考えられそう
島の中の障害
考えられる原因
- スイッチ本体の障害
- 大本のスイッチから島のスイッチまでのLANケーブルの破損
サーバの周りの障害
考えられる原因
- サービスのデーモンが死んでる
- サービスを動かすサーバの負荷が大きい
全体
大本のスイッチ、まぁ要は研究室内の障害ですね。
考えられる原因
- どこかでループを起こしている
- さらに上のほうで障害(例えば研究室であれば大学のネットワークの障害とか)
正直2つ目に関してはどうしようもありません。
障害対応
LANケーブルの破損とスイッチの破損は取り換えてくださいってことでスルー、ループに関してはやらかしたら即座に止まるのでなにかネットワーク周りをいじってた人の配線を確認しておしまい。ということで下の2点の対応について書く
- サービスのデーモン死亡
- サーバの負荷が大きい
サービスのデーモン死亡
まずはサービスの状況を確認します
systemctl status <サービス名>です。サービスで異常が発生している際はこれで確認することができます。
このためにサービスの名前を確認しておく必要があるんですよね。デーモンの再起動にはsystemctl restart <サービス名>なのですがエラーにそもそも解決策が載ってたりします。
デーモンの再起動やエラーメッセージから根本の原因を特定できます。
サーバの負荷が大きい
正直研究室という小さい枠組みで負荷が大きくなるなんてめったにないのですが一応解決策を
tcpdumpもしくはwiresharkでトラフィック監視してください。で飛んできているパケットのipアドレスを探して端末所有者に原因を聞きましょう。
おわり
この記事書いてた時に研究室に障害起きたんだが何か悪いことしたのか？
ちなみに原因はサーバの電源がなぜか落ちていました。普通に電源ボタンを押して再起動して解決です。
