Wir haben eine Reihe von Xen-virtualisierten Servern, die alle Debian 6 64bit ausführen. Wir haben ein zeitweiliges Problem, bei dem ein Server gelegentlich nicht mehr über das Netzwerk antwortet. In diesem Fall können wir den Server nicht anpingen und unsere App-Protokolle zeigen an, dass er keine Verbindung zu anderen Servern im Netzwerk herstellen kann.
Dies ist jetzt bei einigen verschiedenen, unabhängigen Servern passiert, und die einzigen gemeinsamen Faktoren sind der VPS-Host und die zugehörige Infrastruktur, das Betriebssystem und unsere Betriebssystemeinstellungen. Ich verfolge dies mit dem Host, muss der Sache aber wirklich auf den Grund gehen.
Ich habe im Moment nicht wirklich viel, womit ich weitermachen kann. Die einzigen OS-Protokolleinträge, die ich finden kann und die mit dem Ereignis übereinstimmen, sind eine Zeile im Syslog:
Nov 21 19:36:10 xxxxxx ntpd[2460]: xxxx:4f8:xxx:xxx:1:2:3:4 interface xxxx:7e00::xxxx:91ff:xxxx:1bd4 -> (null)
Ich glaube jedoch, dass dies eher auf die Unterbrechung der Netzwerkverbindung zurückzuführen ist und kein Hinweis auf die Ursache dafür ist.
MTR-Berichte von einem funktionierenden Server zeigen nichts Nützliches.
Also,wie soll ich vorgehen, um zu verstehen, was hier passiert? Gibt es netzwerkspezifische Protokolle, die ich nicht kenne und die ich überprüfen sollte?
Danke schön!
Antwort1
Ich gehe davon aus, dass Sie keinen Zugriff auf Ihren VPS-Host haben und nur innerhalb der VM debuggen können. Das würde ich also tun.
Ich würde versuchen herauszufinden, wo der Fehler auftritt – zwischen VM und Host, VM und Gateway oder vielleicht irgendwo im Netzwerk Ihres Anbieters.
Richten Sie ein Skript ein, das Ihren ersten Hop anpingt, also Ihr Gateway. Wenn Sie andere VMs in derselben Broadcast-Domäne haben, können Sie diese anstelle von GW anpingen. Sie könnten screen/tmux ausführen und ping drin lassen:
$ ping IP_OF_GW_OR_OTHER_VM | tee -a mytest.log
Wenn der Ausfall eintritt, das Gateway noch aktiv ist und Pings durchgehen, liegt ein Problem vor. Führen Sie in diesem Fall ein Traceroute durch und pingen Sie die nächsten 2-3 Hops, bis Sie herausgefunden haben, wo der Ausfall auftritt. Wenn das Gateway sofort nicht verfügbar ist, richten Sie möglicherweise einen Cron ein, der beim Auftreten des Ausfalls einen Snapshot der Netzwerkinformationen erstellt:
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
Sie können das Skript mit zusätzlichen Informationen wie Betriebszeit (um die aktuelle Auslastung zu ermitteln), lsof oder netstat erweitern, wenn Sie der Meinung sind, dass Sie diese Informationen auch benötigen.
Manchmal bricht die Verbindung des Gast-DHClients ab oder die Leasing-Verlängerung schlägt fehl. Alle während der Unterbrechung gesammelten Informationen können daher hilfreich sein.