Ausfall von aries, columba, octans und sagitta
Heute morgen gegen halb acht begann dietrich, einer unserer KVM-Wirte, folgende Meldungen nach /var/log/messages zu spucken:
Mar 2 07:28:22 dietrich kernel: mce: [Hardware Error]: Machine check events logged
Mar 2 07:28:23 dietrich kernel: EDAC MC1: 1 CE memory read error on CPU_SrcID#1_Ha#0_Chan#0_DIMM#0 (channel:0 slot:0 page:0x186f358 offset:0x500 grain:32 syndrome:0x0 - area:DRAM err_code: 0001:0090 socket:1 ha:0 channel_mask:1 rank:1)
Mar 2 07:29:35 dietrich kernel: mce: [Hardware Error]: Machine check events logged
Mar 2 07:29:35 dietrich kernel: EDAC MC1: 1 CE memory read error on CPU_SrcID#1_Ha#0_Chan#0_DIMM#0 (channel:0 slot:0 page:0x186f358 offset:0x500 grain:32 syndrome:0x0 - area:DRAM err_code: 0001:0090 socket:1 ha:0 channel_mask:1 rank:1)
Mar 2 07:30:45 dietrich kernel: EDAC MC1: 1 CE memory read error on CPU_SrcID#1_Ha#0_Chan#0_DIMM#0 (channel:0 slot:0 page:0x186f358 offset:0x500 grain:32 syndrome:0x0 - area:DRAM err_code:0001:0090 socket:1 ha:0 channel_mask:1 rank:1)
Mar 2 07:31:25 dietrich kernel: mce: [Hardware Error]: Machine check events logged
Mar 2 07:31:26 dietrich kernel: EDAC MC1: 1 CE memory read error on CPU_SrcID#1_Ha#0_Chan#0_DIMM#0 (channel:0 slot:0 page:0x186f358 offset:0x500 grain:32 syndrome:0x0 - area:DRAM err_code:0001:0090 socket:1 ha:0 channel_mask:1 rank:1)
Mar 2 07:31:32 dietrich kernel: EDAC MC1: 1 CE memory read error on CPU_SrcID#1_Ha#0_Chan#0_DIMM#0 (channel:0 slot:0 page:0x186f358 offset:0x500 grain:32 syndrome:0x0 - area:DRAM err_code:0001:0090 socket:1 ha:0 channel_mask:1 rank:1)
Was schon nicht ganz so schön aussah, mündete dann kurz darauf in ein komplettes Einfrieren der Maschine, und damit auch der vier darauf laufenden Gäste aries, columba, octans und sagitta.
Ein erster Reboot-Versuch über das IPMI-Modul von dietrich verlief wenig zufriedenstellend - nachdem das Gerät einmal vom Strom getrennt und wieder verbunden war und erste Bootmeldungen der Hardware zu sehen waren, fror es wieder ein. Erst nach einem weiteren Trennen und wieder Verbinden des Stroms bootete es komplett hoch. Wir haben aufgrund der RAM-Meldungen aber darauf verzichtet, die vier Gäste direkt auf dietrich wieder zu booten, um zu vermeiden, dass hier ein erneut auftretendes Problem sie direkt noch einmal abstürzen lässt.
Stattdessen haben wir die vier Gäste auf Replikationspartnern gebootet, die jeweils den kompletten Datenbestand vorhielten. Wir haben dabei in der Kette der KVM-Wirte einige weitere, nicht ausgefallene Gäste auf andere Wirte migriert, um die zusätzliche Belastung durch die temporär durch den dietrich-Ausfall mitzutragenden Systeme so gering wie möglich zu halten. Dadurch stemmen jetzt die in der KVM-Kette neben dietrich liegenden Systeme vorübergehend 5 statt wie sonst 3-4 Gastsysteme. Alle Wirte sind generell mit ausreichend RAM bestückt, um im Zweifelsfall noch zwei Gastsysteme mehr als üblich aufnehmen zu können; damit konnten wir hier entsprechend handeln.
dietrich läuft nun aktuell wieder, aber nur als Replikationspartner für die nebenliegenden KVM-Wirte. Gastsysteme beherbergt er nun aktuell nicht; so haben wir die Möglichkeit, den RAM-Vorfall zu prüfen, Speicherriegel zu testen und ggf. durch Ersatz auszutauschen.
Der erste Host - octans - war seit 8:01 Uhr wieder erreichbar; der letzte Host - columba - seit 8:41 Uhr. Ein ungeplanter Crash durch einen Hardwaredefekt zieht in der Regel einen Filesystem-Check (fsck) und einen Quota-Check nach sich, was den Bootvorgang gegenüber einem geplanten, sauberen Reboot verlängert; auch führt MySQL nach einem Crash einen Recovery-Vorgang durch, was dazu führt, dass MySQL noch einige Minuten länger nicht erreichbar ist, während alles andere schon wieder läuft. Inzwischen sind aber alle Recovery-Prozesse durch und im Monitoring alle Checks wieder grün. Solltet ihr noch Probleme beobachten, meldet euch bitte bei hallo@uberspace.de.