当社には、Debian 6 64 ビットで稼働する Xen 仮想化サーバーが多数あります。ときどきサーバーがネットワーク経由で応答しなくなるという断続的な問題が発生しています。この問題が発生すると、サーバーに ping を実行できず、アプリケーション ログにはネットワーク上の他のサーバーに接続できないことが示されます。
これは、現在、無関係ないくつかのサーバーで発生しており、唯一の共通要因は、VPS ホストと関連インフラストラクチャ、OS、および OS 設定です。ホストでこの問題を追跡していますが、真相を突き止める必要があります。
現時点では、あまり手がかりがありません。イベントと一致する OS ログ エントリは、syslog の 1 行だけです。
Nov 21 19:36:10 xxxxxx ntpd[2460]: xxxx:4f8:xxx:xxx:1:2:3:4 interface xxxx:7e00::xxxx:91ff:xxxx:1bd4 -> (null)
しかし、これは原因の手がかりではなく、ネットワーク接続が切断された結果であると思います。
稼働中のサーバーからの MTR レポートには、役立つ情報は何も表示されません。
それで、ここで何が起こっているのか理解するにはどうすればいいでしょうか? 確認する必要がある、私が知らないネットワーク固有のログはありますか?
ありがとう！
答え1
VPS ホストにアクセスできず、VM 内からしかデバッグできないと想定します。そのため、次の操作を実行します。
どこで破損が発生しているかを調べます。VM とホストの間なのか、VM とゲートウェイの間なのか、それともプロバイダー ネットワーク内のどこかなのか。
最初のホップ、つまりゲートウェイに ping するスクリプトを設定します。同じブロードキャスト ドメイン内に他の VM がある場合は、GW の代わりにそれらの VM に ping できます。screen/tmux を実行し、ping を内部に残しておくことができます。
$ ping IP_OF_GW_OR_OTHER_VM | tee -a mytest.log
停止が発生したときに、ゲートウェイがまだ動作していて ping が通る場合、問題は完全に解決しています。その場合は、traceroute を実行して次の 2 ～ 3 ホップに ping し、停止が発生した場所を特定します。ゲートウェイがすぐに使用できなくなった場合は、停止が発生したときにネットワーク情報のスナップショットを取得する cron を設定するとよいでしょう。
ping -c 3 gateway
if [ $? -ne 0 ]; then
ifconfig eth0 2>&1 >> /tmp/ifconfig-$(date +"%Y-%m-%d_%H:%M").log
ethtool eth0 >> /tmp/ethtool-$(date +"%Y-%m-%d_%H:%M").log
fi
必要と思われる場合は、uptime (現在の負荷を取得するため)、lsof、netstat などの追加情報を使用してスクリプトを拡張できます。
ゲストの dhclient が接続を切断したり、リースの更新に失敗したりすることがあるため、停止時に収集された情報があれば役立つことがあります。