Ich betreibe einen Server mit Debian Squeeze mit mehreren OpenVZ-Containern. Die Container laufen meistens Squeeze, einige Lenny und einige bereits auf Wheezy aktualisiert. Der Host macht nicht viel mehr als iptables und DHCP. Dateiserver, Proxies, Mailserver, Kerberos, LDAP usw. werden alle in Container abgelegt. Das System lief viele Jahre stabil und hatte keine größeren Änderungen, außer einigen Firewall-Regeln für mehr als ein Jahr.
Vor 2 Tagen brach das System plötzlich zusammen. Ich hatte eine Menge Probleme, es wieder aufzurufen. Zunächst ließ ich mich nicht über ssh einloggen. Root-Login wurde von 'Sie sind nicht vorhanden' abgelehnt. Geh weg!' Lokale Anmeldung war in Ordnung. Einige Zeit später funktionierte ssh wieder. Zufällig habe ich die Zeile aus der Bash-Historie nicht wiederverwendet, sondern einen neuen Befehl eingegeben, der mit dem Triply-Befehl identisch war mit der Zeile, die vorher nicht funktioniert hat, aber vor dem Absturz funktioniert hat.
Dann lief das System, aber der Netzwerkverkehr auf den meisten Protokollen wurde nach SYN ACK blockiert. DNS, Telnet und SSH waren in Ordnung, aber der Rest war ein Durcheinander. Nachdem wir ein paar Stunden im Dunkeln gefischt und die Brandmauer mehrmals nachgeladen hatten, ging alles wieder gut. Ich konnte nichts Verdächtiges in den Protokollen finden - aber ich bin kein forensischer Experte.
Heute hat der nscd des Dateiservers wegen der Container-Quote keine Sockets mehr zur Kontaktaufnahme mit LDAP. Etwas, das noch nie passiert ist. Ich habe auch viele (> 30) Steckdosen gesehen, die von smbd beansprucht wurden.
/ var / log / messages sah genauso aus wie syslog . /var/log/kern.log enthielt diese zusätzlichen Informationen zu Absturzgründen:
/var/log/kern.log:2950:Sep 19 10:46:57 asgard kernel: [6529441.320086] INFO: task sendmail:32181 blocked for more than 120 seconds. /var/log/kern.log:2982:Sep 19 10:48:57 asgard kernel: [6529561.324525] INFO: task kdmflush:1932 blocked for more than 120 seconds. /var/log/kern.log:3005:Sep 19 10:48:57 asgard kernel: [6529561.324694] INFO: task xfssyncd:10162 blocked for more than 120 seconds. /var/log/kern.log:3027:Sep 19 10:48:57 asgard kernel: [6529561.324934] INFO: task postgres:16827 blocked for more than 120 seconds. /var/log/kern.log:3060:Sep 19 10:49:51 asgard kernel: [6529561.325129] INFO: task imapd:31749 blocked for more than 120 seconds. /var/log/kern.log:3084:Sep 19 10:49:51 asgard kernel: [6529561.325248] INFO: task cleanup:32194 blocked for more than 120 seconds. /var/log/kern.log:3106:Sep 19 10:50:57 asgard kernel: [6529681.324028] INFO: task flush-253:3:3216 blocked for more than 120 seconds. /var/log/kern.log:3142:Sep 19 10:50:57 asgard kernel: [6529681.324224] INFO: task kjournald:6859 blocked for more than 120 seconds. /var/log/kern.log:3166:Sep 19 10:50:57 asgard kernel: [6529681.324366] INFO: task syslogd:11720 blocked for more than 120 seconds. /var/log/kern.log:3198:Sep 19 10:50:57 asgard kernel: [6529681.324574] INFO: task postgres:16827 blocked for more than 120 seconds. /var/log/kern.log:7152:Sep 19 19:29:41 asgard kernel: [ 1440.617090] INFO: task sendmail:11892 blocked for more than 120 seconds.
Der letzte 'sendmail'-Absturz war nach dem Neustart der Maschine. Seitdem sind keine derartigen Ereignisse mehr aufgetreten. 'imapd' und 'postgres' laufen definitiv in verschiedenen Containern.
Ich sehe keine rauchende Waffe, aber ich bin wahrscheinlich nur blind. Das Einrichten des Systems aus bekannten / vermuteten guten Sicherungen würde mich zu sehr treffen, um es ohne sehr gute Gründe zu versuchen.
Ich würde mich über einen Rat freuen, was ich als nächstes prüfen sollte.
Danke für Ihre Hilfe.
Update : Bei der Suche nach einem Pre-Cursor des Absturzes wurde mehr Aufwand gefunden. In syslog wurde Folgendes gefunden:
Ich weiß, dass dies als unkritisch angesehen wird, aber es scheint ein seltenes Ereignis zu sein. Paketabschneidung ist nur am Tag des zweiten Absturzes vorhanden. Nirgendwo sonst in allen verfügbaren Protokolldateien.
Dies sieht aus wie DoS, das höchstwahrscheinlich aus Nework oder aus einem beschädigten Container stammt.
Ich würde in vmstat nachschauen und es alle 5 Sekunden kontinuierlich ausführen: vmstat 5 und mir eine Notiz machen, wo Ressourcen verbraucht werden. Sie können den Bildschirm auch verwenden und vmstat 60 (jede Minute) in einem separaten Fenster ausführen. Auf diese Weise können Sie Spitzen bemerken, wenn diese über einen längeren Zeitraum auftreten.
In dieser Situation zeigen die System-CPU (sy) mit hoher / Spitzenleistung, die hohe Kontextwechselrate (cs) und die hohe IO (es zeigt sowohl das Netzwerk als auch die Festplatte an) DoS an:
$ vmstat 5 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 9584 6820 132432 23256 1 1 136 12 1 1 83 1 15 0 0 0 0 9584 6696 132432 23256 0 0 0 0 20 32 0 0 99 0 1
Zur gleichen Zeit den Netzwerkverkehr auf dem Host überwachen, empfehle ich ntop, dh:
$ nload -t 10000 -u H eth0
0
Shain Padmajan
Es sieht aus wie ein Festplatten-E / A-Fehler. Führen Sie fsck aus und prüfen Sie auf Fehler.
Ich werde versuchen, Ausfallzeiten dafür zu planen. Es gibt jedoch nirgendwo Protokolle, die sich auf E / A-Festplattenfehler beziehen. Oder hast du welche gesehen?
Lars Hanke vor 10 Jahren
0
0
c4f4t0r
Vielleicht haben Sie keine Dateisystemfehler, aber ich bin mir sicher, dass Sie diese Warnungen in Ihrem Protokoll sehen, da sich viele Prozesse im Status D befinden (auf E / A warten) und der Kernel Sie über die lange Wartezeit informiert.
Ich denke, das war der Fall. Aber warum? Unter normalen Bedingungen gibt es keine Prozesse im D-Zustand. Wenn das Netzwerk tatsächlich ausfiel, könnte dies das erklären. Aber warum sollte es nur für einige Dienste ausfallen? Warum überlebte diese Bedingung einen Neustart? Und warum ist es wieder aufgetaucht?
Lars Hanke vor 10 Jahren
0
0
Armin
Der Fehler zeigt an, dass Ihre Prozesse zu lange (120 Sekunden) auf den Zugriff auf Festplatten warten. Dies geschieht auf stark überfüllten Servern, auf denen Festplatten zu beschäftigt sind, um auf Prozesse zu reagieren.
Sie können dies überprüfen, indem Sie unter vmstat "Waiting" markieren.