Wir haben - endlich - einen der größten Performance-Engpässe unserer Geschichte gefunden, an einer Stelle, die niemand von uns erwartet hätte. Fieserweise hat er uns derart schleichend über 2,5 Jahre hinweg beeinträchtigt, dass er kaum von eben allgemein gestiegenem Ressourcenbedarf zu unterscheiden war.

Die Stromversorgung in Rechenzentren ist stabil - das ist unsere Erfahrung, die wir in den letzten 15 Jahren machen durften. Am Freitag den 14. September gegen 12:50 Uhr erlebten wir dann einen für uns bis dato unbekannten Zwischenfall, der uns bewies, dass es mehr gibt als Strom an/Strom aus. Wenn das lokale Versorgungsunternehmen doch mal Schwierigkeiten mit der Stromversorgung hat, stehen redundante Dieselgeneratoren zur Stelle, die den Standort permanent mit Strom versorgen können.

Gestern haben wir uns daran begeben, zwei neue Router in Betrieb zu nehmen und standen vor einer Blockade. Aus der Ferne konnten wir nur per serieller Konsole auf die Geräte zugreifen, weil der der Netzwerkanschluss noch nicht funktionierte.

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.

Als wir mit Uberspace angefangen haben, haben wir bekanntermaßen nicht damit gerechnet, dass das so groß wird. Das führte zu ein paar Fehlkalkulationen unsererseits, die verschiedene Probleme aufgeworfen haben, wovon die meisten aber schon lange gelöst sind. Ein hartnäckigeres Problem war das mit dem Plattenplatz. Zu Anfang hatten wir unseren VMs jeweils nur 400 GB Speicher zugewiesen, was sich im Verhältnis zu der Menge an Usern die wir auf die Server gelassen haben als Fehlkalkulation bei der Mischkalkulation herausgestellt hat (Rimshot).

Am Mittwochabend des 9. März meldete unser Monitoring, dass einer unserer Backupserver nicht mehr zu erreichen ist. Nachdem auch Loginversuche über die Remote-Management-Karte (IPMI) nicht möglich waren, blieb uns nur der Weg des Neustarts des Systems. Auf diesem Backupserver befanden sich zum Zeitpunkt des Ausfalls die Dateisystem-Backups von 11 Uberspace-Hosts. Nach dem Reboot haben wir festgestellt, dass eine der vier Backuppartitionen Fehler aufwies, weshalb die Partition dann wieder ausgehängt wurde um eine Überprüfung des Dateisystems durchzuführen.

In der letzten und der laufenden Woche gab es bei uns mehrere Ausfälle, bei denen jeweils KVM-Wirte, auf denen wir in der Regel drei bis vier Uberspace-Hosts betreiben, spontan weggebrochen sind. Vorgestern gab es dann noch einen vollkommen bizarren Fuckup auf gleich sieben KVM-Wirten gleichzeitig, der über Stunden zu sehr langsamem I/O auf den betroffenen Systemen geführt hat und dabei nicht nur die direkt darauf laufenden Uberspace-Hosts beeinträchtigt hat, sondern auch die der Failover-Partner nebendran.

Vor einigen Wochen ist uns in unserem Rechenzentrum eine über das Netz schaltbare Steckdosenleiste abgeraucht und hat dabei 24 Server abgeschaltet. Die Folgen waren: Downtime der Server für mehrere Stunden (wobei ein Großteil Server mit Failover-Partner waren), 4 kaputte Festplatten und der damit verbundene Ärger und zu guter Letzt der Nachteinsatz mehrerer Kollegen, und das alles nur weil eine Steckdosenleiste von jetzt auf gleich den Betrieb einstellen wollte. Alleine den Ausfall der Steckdose halte ich persönlich für eine Unding - es handelt sich schließlich um ein 1000-Euro-Gerät einer namenhaften Firma.