Ausfall am 29.06.2021
Wenn wir einen Ausfall mit einem zusätzlichen Blogpost begleiten, dann, weil er groß war - so groß, dass wir so etwas in unserer Geschichte noch nicht erlebt haben. Inzwischen gibt es einige Details dazu, die wir gerne mit euch teilen möchten.
Wie du auf unserer Statusseite schon lesen konntest, ging es um einen Stromausfall, der die naheliegende Frage aufwirft, die uns auch von vielen bereits erreicht hat: Gibt es denn keine Unterbrechungsfreie Stromversorgung (USV)? Doch, die gibt es natürlich, und wie es sich derzeit darstellt, war genau diese das Problem.
Wir haben inzwischen erste Stellungnahmen zu dem gestrigen Vorfall erhalten, aus denen wir weiter unten ziteren. Sie legen die Details des Vorfalls dar. Diese Stellungnahmen sind erst heute bei uns eingetroffen; wir konnten gestern insofern keine Details verkünden, die qualitativ über “irgendwas mit Strom” hinausgingen.
Rechenzentren - ein wenig Kontext
Es nicht so unüblich, dass das, was man so als “Rechenzentrum” bezeichnet, oftmals zwei Parteien sind: Eine, die sich um das Gebäude, Strom, Klimatisierung, Zutrittsüberwachung etc. kümmert, und eine andere, die in die bereitgestellten Räume dann Racks und Netzwerk-Equipment stellt, um Leuten wie uns dann eben jene Racks sowie IP-Uplink anzubieten.
Wir sind derzeit in drei Rechenzentren zu Gast; dabei befinden sich zwei allerdings auf dem Campus des gleichen Betreibers, Telehouse Deutschland in Frankfurt am Main. Für Uberspace setzen wir nur einen der beiden Standorte ein, sowie noch einen weiteren in einem anderen Teil von Frankurt, der vom gestrigen Vorfall insofern nicht betroffen war.
Als praktisch unser gesamtes Equipment an beiden Rechenzentrumsstandorten gleichzeitig komplett down war, ahnten wir schon, dass das hier eine Nummer größer ist - zumal auch die Websites und Kundenportale, teils auch die Telefonanbindung der Rechenzentren ebenfalls down war. Da wir kein direkter Kunde von Telehouse Deutschland sind, sondern nur über Bande, war es auch nicht ganz leicht, an sowas wie ein “offizielles Statement” zu kommen. Wir haben am Vormittag dann diese knappe Aussage bekommen:
Wir hatten einen Spannungsschwankung an der FTS2.1 und suchen derzeit nach der Ursache.
Zur Sicherheit laufen noch die Diesel-Generatoren um Ihre Infrastruktur zu unterstützen.
Sobald wir mehr Information haben, melden wir bei Ihnen.
TELEHOUSE DEUTSCHLAND
Eine “Spannungschwankung” mag sich nun erstmal recht niedlich anhören, bedeutet aber flapsig gesagt: Fast alle Geräte - Router, Switche, Stromleisten, Server, … - gehen einmal aus und wieder an. Und das ist ein ziemliches Problem, denn egal wieviel Redundanz wir so in unserem Storagecluster haben, Daten dreifach speichern, Hosts extra auf separate Stromfeeds verteilen: Das nützt alles nichts, wenn allem kurz der Stecker gezogen wird.
Schadensanalyse
Wir haben bisher mit Ceph als Cluster-Dateisystem sehr robuste Erfahrungen gemacht. Der aktuelle Vorfall hat aber zum ersten Mal dazu geführt, dass es im Storage einige sogenannte unfound objects gibt, also Datenblöcke, von denen Ceph zwar anhand seines Index weiß, dass sie existieren; es findet aber keine einzige Kopie der Daten vor. Das solle eigentlich nicht passieren, wenn alle drei verfügbaren OSDs (die Datenspeicher von Ceph) verfügbar sind, was sie sind, aber offenbar hat der Stromausfall diese Situation herbeigeführt. In absoluten Zahlen sind es nicht viele; es geht um eine niedrige zweistellige Zahl von rund 18 Mio. Datenblöcken.
Den Großteil der VMs konnten wir insofern relativ zügig wieder starten; die durch den Stromausfall verursachten unfound objects führten allerdings zum ersten Mal zu einer Situation, wo auch einige XFS-Dateisysteme Fehler aufwiesen. In diesem Fällen muss eine Dateisystem-Reparatur durchgeführt werden. Und das ist leider nicht so ganz ohne, denn erstens dauert das lange, wir reden hier von 1-3 Stunden. Zweitens kann eine solche Reparatur nicht magisch wiederherstellen, was fehlt - denn wenn ein Datenblock weg ist, dann ist er eben weg. Drittens findet nach durchgeführter Reparatur - zwangsläufig - ein Quotacheck statt, der seinerseits auch wieder 1-3 Stunden dauern kann. Und wenn besonderes Pech vorliegt, möchte SELinux noch ein komplettes Relabeling durchführen, was auch sehr lange dauern kann. Aus diesem Grund ziehen sich die letzten auf is.uberspace.online genannten Hosts viel länger als andere hin. Das heißt nicht, dass wir ihnen nicht genug Aufmerksamkeit widmen würden; eher ganz im Gegenteil: Dieses Hosts fordern sie ganz besonders und bekommen sie auch ganz besonders.
Bei einem großen Teil der VMs gelang der Reparaturvorgang zumindest einigermaßen zügig und vor allem: Ohne größere Datenverluste.
Besondere Problemfälle
Bei einem anderen Teil aber führt der Repair-Vorgang dazu, dass am Ende einige Dinge, die das Dateisystem nicht mehr sauber reparieren konnte, schlicht fehlen - und zwar teilweise sowas wie /opt oder /usr, sprich, in diesem Zustand kann das System nicht einmal mehr Booten. In diesen Fällen stellen wir den gestrigen Stand aus unseren außerhalb des Clusters lagernden Backups wieder her. Je nachdem wie viele Daten fehlen, kann das leider eben auch dauern.
In einem besonders ärgerlichen Fall, dem Host bergelmir.uberspace.de, stellt sich die Situation noch anders dar: Das xfs_repair ist durchgelaufen, meldet keine Fehler (mehr), und dennoch crasht der betreffende Host beim Booten sofort mit einem XFS-Fehler und der Aufforderung, xfs_repair einzusetzen. Was wir ja nun schon getan haben. Wir probieren hier noch verschiedene Dinge aus; unter Umständen müssen wir diesen Host aber auch komplett neu aufsetzen und aus dem Backup bespielen. Auf unserer Statusseite halten wir euch auf dem Laufenden.
Stellungnahmen
Hier nun die Stellungnahme unseres Rechenzentrumspartners Plus.line (FRA1):
Sehr geehrte Kunden,
am gestrigen Tage kam es zu einem Ausfall in Teilen eines unserer
Rechenzentren. Für die aufgetretenen Unannehmlichkeiten bitten wir um
Verzeihung und möchten Sie in dieser E-Mail über die Gründe des Ausfalls
und unsere getroffenen Maßnahmen informieren.
Sie waren direkt oder indirekt betroffen:
- Falls Sie Server oder Netzwerkgeräte im Raum EG11.6 in Gebäude I in
Telehouse untergebracht haben oder
- ein von uns (für Sie) betriebener Dienst (ob dediziert oder nicht)
dort lief.
Gegen 10:17 Uhr kam es bei angekündigten Wartungsarbeiten des
RZ-Betreibers an der unterbrechungsfreien Stromversorgung (USV) zu einem
Spannungseinbruch an der USV-Anlage. Die Anlage war zu diesem Zeitpunkt
für die Arbeiten auf zwei Blöcke aufgeteilt. Bei der Inbetriebnahme des
ersten, bereits gewarteten Blockes in den USV-Betrieb hat die Anlage
ohne Vorwarnung auf den internen Bypass geschaltet und somit einen
Spannungseinbruch von ca. 70ms ausgelöst. Zu diesem Zeitpunkt sind
Server und Netzwerkgeräte in den angeschlossenen Räumen kurz stromlos
gewesen und dann je nach Konfiguration entweder neu gestartet worden
oder abgeschaltet geblieben.
Wir haben bereits kurz nach dem Erkennen des Ausfalls mit der Analyse
und Entstörung begonnen. Ebenso wurden parallel Mitarbeiter für den
Vor-Ort-Einsatz im Rechenzentrum aktiviert, da hier Geräte wieder
anzuschalten oder gegebenenfalls Hardware (wie Netzteile) auszutauschen
wäre. Leider war zu diesem Zeitpunkt auch die Erreichbarkeit unseres
Supports eingeschränkt, so dass Sie uns unter Umständen nicht erreichen
konnten. Wir haben daraufhin proaktiv und soweit wie möglich betroffene
Kunden informiert.
Direkt nach dem Fehler bei der USV-Umschaltung wurden die
Netzersatzgeneratoren gestartet, zur Paralleleinspeisung und
Stabilisierung der Stromversorgung. Anschließend wurde der Block 1
wieder abgeschaltet. Die gesamte USV wurde daraufhin erneut überprüft
und ein defekter Wechselrichter getauscht. Nach einem erneuten
Funktionstest wurden die USV-Anlage schließlich wieder in Betrieb
genommen und die Netzersatzanlagen wieder abgeschaltet.
Die Vielzahl unserer eigenen betroffenen Dienste und auch die von Kunden
standen bereits im Laufe des späten Vormittages wieder zur Verfügung und
falls Hardware ausgetauscht werden musste, ist dies entweder bereits
geschehen oder geschieht in Absprache mit dem Kunden.
Wir bedauern den Vorfall sehr und werden den Anlass nutzen, eigene
betroffene Dienste auf Ihre Redundanz hin zu überprüfen und diese
gegebenenfalls anzupassen.
Sowie die Stellungnahme von uvensys (FRA3):
Sehr geehrte Kunden und Geschäftspartner,
zuallererst möchte ich mich an dieser Stelle für die Ausfälle und Nichterreichbarkeiten Ihrer Systeme am 29.06.2021 entschuldigen.
Direkt nach der kurzen Stromunterbrechung hat das gesamte Team der uvensys damit begonnen, unsere 3 betroffenen Räume in Gebäude I wieder anzufahren.
Hierbei mussten ca 400-500 Systeme auf Funktion geprüft werden und gegebenenfalls Dienste nachjustiert werden.
Einen Großteil der Systeme konnten wir innerhalb der ersten zwei Stunden wieder live bringen, ein Großteil ist eigenständig wieder angelaufen.
Die weitere Bearbeitung einzelner Systeme hat auf unserer Seite bis ca 18:00 Uhr gedauert, so dass diese Systeme leider eine Downtime von bis zu 7 Stunden hatten.
Aktuell ist die Aussage vom Rechenzentrum Telehouse, dass es bei geplanten Wartungsarbeiten an einem USV Block beim Rückschalten zu einem Netzwischer von ca 70ms gekommen ist.
Hierdurch sind in Gebäude I beide USV Feeds betroffen gewesen.
Während der weiteren Reparaturarbeiten des dann defekten Blocks wurden die Stromkreise per Generator unterstützt.
Gegen 15:30 Uhr wurden dann die reparierten Blöcke wieder in Betrieb genommen.
Für mich erschließt sich aktuell noch nicht, warum beide USV Feeds von diesem Problem betroffen waren.
Ich habe den Geschäftsführer der Telehouse Deutschland GmbH um eine transparente Aufklärung und Erklärung zu dem Vorfall gebeten.
Ein gemeinsames Telefonat ist für heute, 30.06.2021, um 14:00 Uhr angesetzt.
Sobald mir hier weitere Informationen vorliegen bekommen Sie noch ein weiteres Update.
Ich bitte die entstandenen Unannehmlichkeiten zu entschuldigen
Wenn Sie weitere Fragen oder Rückmeldungen haben geben Sie mir gerne Bescheid.
Update am 01.07.2021 von uvensys (FRA3):
Sehr geehrte Kunden und Geschäftspartner, wie angekündigt habe ich gestern mit dem GF der Telehouse Deutschland GmbH telefoniert.
Das Gebäude I ist nach Tier3 (bei den meisten großen RZs in Frankfurt der Fall) mit n+1 und teilweise n+2 gesichert. Dies bedeutet es gibt eine Wartungsredundanz, aber keine Fehlerredundanz auf den notwendigen Komponenten (was n+n entspräche) Für das Gebäude I sind vier USV Steuerungen verantwortlich, unter Volllast würden davon drei benötigt, eine ist für die Redundanz (n+1). Aufgrund der Auslastung des Gebäude I werden im Livebetrieb aktuell nur zwei Systeme benötigt. Bei einer geplanten und notwendigen Wartungsmaßnahme wurden zwei der Systeme ausser Betrieb genommen und mit neuen Controllerboards ausgestattet. Die neue Generation Controllerboards kann nicht mit den alten Systemen kommunizieren, so dass entsprechend zwei Systeme direkt neu ausgestattet werden mussten. Die beiden getauschten Systeme wurden dann vom Team Telehouse entsprechend getestet und für den Livegang vorbereitet. Im Moment der Umschaltung ist ein Wechselrichter defekt gegangen, dies hat dazu geführt, dass die Sinuskurven noch nicht angeglichen waren und die USV Anlage kurzfristig auf den Bypass geschalten hat, wobei es zu einer Unterbrechung auf beiden Phasen von ca 70ms gekommen ist. Dies hat gereicht um einen großteil der Systeme neu starten zu lassen. Telehouse hat im Nachgang den Wechselrichter erneuert und die verbleibenden zwei Controllerboards ausgetauscht, um 15:20 Uhr sind dann alle vier USV Steuerungen wieder in Betrieb gegangen. Nach Rücksprache mit Telehouse können wir sagen, dass die Ursache somit behoben ist und die n+1 Redundanz wieder gegeben ist.
Ich kann mich an dieser Stelle nur noch einmal entschuldigen. Für eigene Dienste (z.B. ucloud) sind wir bereits in der Umsetzung, diese redundant auf ein anderes Gebäude weiter zu verteilen. Falls Ihrerseits im Housingbereich dazu Gesprächsbedarf besteht können wir gerne darüber sprechen.
Es ist vielleicht nur ein schwacher Trost, in Gebäude I war mir über die letzten 15 Jahre kein Stromausfall bekannt. Ich hoffe mal dass ich das in 15 Jahren wieder sagen kann.
Update 02.07.2021 18:30 Uhr
Was für eine Woche… Wie ihr sicher bemerkt sind wir immer noch dabei, unsere Server zu fixen, kommen aber gut voran. Hier ein kleines Update bevor wir ins Wochenende gehen, an dem wir (fast) alles stehen und liegen lassen müssen weil wir ehrlich gesagt alle am Rande unserer Leistungsfähigkeit sind und dringend eine Pause brauchen.
The Good
Alle vom Ausfall betroffenen Server haben eine eigene Partition auf SSDs für MySQL. Lt. den Daten unseres Ceph sind hier keine Daten verloren gegangen.
Das Re-Deployment auf allen betroffenen Systemen läuft gerade und wird auch übers Wochenende weiter laufen, da das relativ wenig Aufmerksamkeit benötigt und gut vorankommt. Zum jetzigen Zeitpunkt sind wir bereits bei rund 50% angekommen.
Unsere Priorität liegt vor allem darauf, die Server und “unsere” Dienste wie Web- und Mailserver wieder online zu bekommen.
Das letzte Backup vor dem Crash werden wir für alle User zugänglich für ein Jahr vorhalten, ihr findet es unter /backup.
The Bad
Einige Server benötigen viel Aufmerksamkeit, hier fehlten komplette Verzeichnisbäume wie /usr oder /home. Bis auf bergelmir laufen die Systeme zumindest wieder und sind online, hier haben wir die desaster recovery aufgegeben und werden die VM am Montagmorgen komplett neu aufsetzen und dabei das letzte Backup vom 28.06. einspielen.
Wir sind in der Geschwindigkeit unseres Vorgehens nicht zuletzt durch den HDD-Pool, auf dem die VMs liegen, begrenzt und arbeiten so schnell es geht.
The Ugly
Bei allen Servern auf dem HDD-Pool können wir einen Datenverlust nicht ausschließen. Bei unseren bisherigen Checks und im Support sind bisher einzelne Server aufgefallen auf denen wir Reparaturen durchgeführt oder eingeplant haben. Der Vollständigkeit halber folgt eine Liste mit allen Servern die von einem Datenverlust betroffen sein könnten:
adrastea.uberspace.de
aegaeon.uberspace.de
aegir.uberspace.de
aitne.uberspace.de
albiorix.uberspace.de
alnilam.uberspace.de
alpheca.uberspace.de
amalthea.uberspace.de
ananke.uberspace.de
ankaa.uberspace.de
aoede.uberspace.de
arche.uberspace.de
belinda.uberspace.de
bergelmir.uberspace.de
bernardi.uberspace.de
bestla.uberspace.de
bianca.uberspace.de
boethin.uberspace.de
brewington.uberspace.de
brorsen.uberspace.de
bus.uberspace.de
caliban.uberspace.de
callirrhoe.uberspace.de
carpo.uberspace.de
chaldene.uberspace.de
charon.uberspace.de
chiron.uberspace.de
ciffreo.uberspace.de
clark.uberspace.de
cordelia.uberspace.de
cressida.uberspace.de
crommelin.uberspace.de
cupid.uberspace.de
cyllene.uberspace.de
gacrux.uberspace.de
gale.uberspace.de
giacobini.uberspace.de
gibbs.uberspace.de
giclas.uberspace.de
harrington.uberspace.de
helin.uberspace.de
hergenrother.uberspace.de
hernmann.uberspace.de
howell.uberspace.de
jedicke.uberspace.de
johnson.uberspace.de
klemola.uberspace.de
kojima.uberspace.de
kopff.uberspace.de
kowal.uberspace.de
kushida.uberspace.de
longmore.uberspace.de
lovas.uberspace.de
machholz.uberspace.de
maury.uberspace.de
mcnaught.uberspace.de
mrkos.uberspace.de
neujmin.uberspace.de
rasalhague.uberspace.de
russel.uberspace.de
sanguin.uberspace.de
shaula.uberspace.de
taylor.uberspace.de
vanness.uberspace.de
whipple.uberspace.de
wirtanen.uberspace.de
wolf.uberspace.de
yeung.uberspace.de
Für alle diese Server gibt es natürlich die üblichen Backups, mehr Infos dazu in unserem Manual.
Kleines Schlusswort
Die Situation ist für alle nicht schön und uns ist völlig klar, dass wir nicht alle Erwartungshaltungen erfüllen können. Um so schöner ist das Feedback, das wir von euch bekommen und wir sind für eure Geduld wirklich dankbar. Wir stellen mal wieder fest, dass wir die tollsten Kund:innen der Welt haben und setzen alles daran, alle Server wieder in einen stabilen Zustand versetzen zu können - in unserem wie in eurem Interesse.
Wir updaten natürlich jeden Eintrag auf der Statusseite sobald es etwas Neues zu berichten gibt.
Updates folgen kommende Woche, bis dahin erstmal
Header: CC-BY mzeuner