Was würden Sie empfinden, wenn an einem schönen Sommertag Ihr Rechenzentrum so aussehen würde?
Hallo zusammen! Mein Name ist Dmitrij Samsonov, ich arbeite als leitender Systemadministrator bei „“. Auf dem Foto sehen Sie eines von vier Rechenzentren, in denen die Hardware für unser Projekt untergebracht ist. Hinter diesen Mauern befinden sich etwa 4.000 Geräte: Server, Speicherlösungen, Netzwerktechnologie usw. – fast ein Drittel unserer gesamten Hardware.
Die meisten Server laufen unter Linux. Es gibt auch einige Dutzend Windows-Server (MS SQL) – unser Erbe, von dem wir uns über die Jahre schrittweise verabschieden.
Am 5. Juni 2019 um 14:35 Uhr meldeten die Ingenieure eines unserer Rechenzentren einen Brandalarm.
Leugnung
14:45 Uhr. Kleine Rauchvorfälle in Rechenzentren kommen häufiger vor, als man denkt. Die Werte in den Räumen waren normal, daher war unsere erste Reaktion relativ ruhig: Wir verhängten ein Verbot für Arbeiten im Produktionsumfeld, also für Änderungen an Konfigurationen, das Einspielen neuer Versionen usw., mit Ausnahme von Arbeiten, die mit der Reparatur von Geräten in Zusammenhang standen.
Wut
Haben Sie jemals versucht, bei den Feuerwehrleuten zu erfahren, an welchem genauen Ort auf dem Dach das Feuer ausgebrochen ist, oder selbst auf ein brennendes Dach zu gelangen, um die Situation zu beurteilen? Wie hoch wird das Vertrauen in die Informationen sein, die von fünf Personen stammen?
14:50. Es gibt Informationen, dass das Feuer sich dem Kühlsystem nähert.. Aber wird es tatsächlich dazu kommen? Der diensthabende Systemadministrator leitet den externen Datenverkehr von den Fronten dieses Rechenzentrums um.
Derzeit sind die Fronten aller unserer Dienste in drei Rechenzentren dupliziert, und es wird ein DNS-Balancing verwendet, das es ermöglicht, die Adressen eines Rechenzentrums aus dem DNS zu entfernen, sodass die Benutzer vor potenziellen Zugriffsproblemen auf die Dienste geschützt werden. Falls im Rechenzentrum bereits Probleme aufgetreten sind, wird es automatisch aus der Rotation entfernt. Weitere Informationen finden Sie hier:
Der Brand hat uns bisher nicht beeinträchtigt — weder Benutzer noch Hardware haben gelitten. Handelt es sich um einen Vorfall? Der erste Abschnitt des Dokuments „Notfallplan“ gibt eine Definition für den Begriff „Vorfall“ und endet mit folgendem Abschnitt:
«Wenn Zweifel bestehen, ob es sich um einen Notfall handelt oder nicht, dann ist es ein Notfall!»
14:53. Ein Notfallkoordinator wird ernannt.
Der Koordinator ist die Person, die die Kommunikation zwischen allen Beteiligten überwacht, den Umfang des Notfalls bewertet, den "Notfallaktionsplan" verwendet, notwendiges Personal einsetzt, die Beendigung der Reparatur überwacht und vor allem Aufgaben delegiert. Mit anderen Worten, er ist die Person, die den gesamten Prozess der Notfallbewältigung leitet.
Verhandlung
15:01. Wir beginnen mit der Abschaltung der Server, die nicht mit der Produktion verbunden sind.
15:03. Wir schalten alle reservierten Dienste korrekt ab.
Dazu gehören nicht nur die Frontend-Services (auf die die Benutzer zu diesem Zeitpunkt nicht mehr zugreifen) und ihre unterstützenden Dienste (Geschäftslogik, Caches usw.), sondern auch verschiedene Datenbanken mit einem Replikationsfaktor von 2 oder mehr (, , , und mehr).
15:06. Es gibt Informationen, dass ein Feuer einen der Räume des Rechenzentrums bedroht. In diesem Raum haben wir keine Ausrüstung, aber die Möglichkeit, dass das Feuer von der Decke auf die Räume übergreift, verändert drastisch die Situation.
(Später stellte sich heraus, dass keine physische Bedrohung für den Raum bestand, da er luftdicht vom Dach isoliert war. Die Bedrohung galt nur für das Kühlsystem dieses Raumes.)
15:07. Wir erlauben die Ausführung von Befehlen auf den Servern im beschleunigten Modus ohne zusätzliche Überprüfungen ().
15:08. Die Temperatur in den Räumen ist im Normbereich.
15:12. Ein Anstieg der Temperatur in den Räumen wurde festgestellt.
15:13. Mehr als die Hälfte der Server im Rechenzentrum sind ausgeschaltet. Wir machen weiter.
15:16. Es wurde beschlossen, alle Geräte abzuschalten.
15:21. Wir beginnen mit der Abschaltung der Stromversorgung an stateless-Servern ohne ordnungsgemäße herunterfahren der Anwendungen und des Betriebssystems.
15:23. Eine Gruppe von Verantwortlichen für MS SQL wird gebildet (es sind nicht viele, die Abhängigkeit der Dienste von ihnen ist nicht groß, aber der Wiederherstellungsprozess benötigt mehr Zeit und ist komplizierter als zum Beispiel bei Cassandra).
Depression
15:25. Es kam die Information über die Abschaltung der Stromversorgung in vier Räumen von 16 (Nr. 6, 7, 8, 9). In den Räumen 7 und 8 befindet sich unsere Hardware. Über zwei weitere unserer Räume (Nr. 1 und 3) liegen keine Informationen vor.
Normalerweise wird die Stromversorgung bei Bränden sofort abgeschaltet, doch in diesem Fall wurde sie dank der koordinierten Arbeit der Feuerwehr und des technischen Personals des Rechenzentrums nicht überall und nicht sofort abgeschaltet, sondern nach Bedarf.
(Später stellte sich heraus, dass die Stromversorgung in den Räumen 8 und 9 nicht abgeschaltet wurde.)
15:28. Wir beginnen mit der Wiederherstellung der MS SQL-Datenbanken aus Backups in anderen Rechenzentren.
Wie viel Zeit wird dafür benötigt? Reicht die Bandbreite des Netzwerks für die gesamte Strecke aus?
15:37. Es wurde eine Unterbrechung einiger Netzwerkabschnitte festgestellt.
Das Management und das Produktionsnetzwerk sind physisch voneinander isoliert. Wenn das Produktionsnetzwerk verfügbar ist, können Sie auf den Server zugreifen, die Anwendung stoppen und das Betriebssystem ausschalten. Wenn es nicht verfügbar ist, können Sie über IPMI auf den Server zugreifen, die Anwendung stoppen und das Betriebssystem ausschalten. Wenn keines der Netzwerke verfügbar ist, können Sie nichts tun. 'Danke, Captain!', denken Sie sich vielleicht.
'Ganz ehrlich, es ist irgendwie viel Aufregung', denken Sie sich möglicherweise auch.
Es ist so, dass Server selbst ohne Feuer enorme Mengen Wärme erzeugen. Genauer gesagt, wenn Kühlung vorhanden ist, erzeugen sie Wärme, und wenn sie keine Kühlung haben, schaffen sie die Hölle, die im besten Fall einen Teil der Ausrüstung schmelzen und einen anderen Teil ausschalten kann, und im schlimmsten Fall... einen Brand im Raum auslösen kann, der praktisch alles zerstört.
15:39. Wir dokumentieren Probleme mit der conf-Datenbank.
Die conf-Datenbank ist das Backend für den gleichnamigen Service, der von allen Produktionsanwendungen für die sofortige Änderung von Einstellungen genutzt wird. Ohne diese Datenbank können wir den Betrieb des Portals nicht steuern, aber das Portal selbst kann trotzdem funktionieren.
15:41. Temperaturfühler an der Core-Netzwerkausrüstung erfassen Werte, die nahe an den zulässigen Höchstwerten liegen. Es handelt sich um ein Gerät, das einen gesamten Rackplatz ausfüllt und den Betrieb aller Netzwerke innerhalb des Rechenzentrums sichert.
15:42. Issue Tracker und Wiki sind nicht verfügbar, wir schalten auf Standby.
Dies ist keine Produktionsumgebung, aber im Falle eines Vorfalls kann die Verfügbarkeit jeder Wissensdatenbank kritisch sein.
15:50. Eines der Überwachungssysteme hat sich abgeschaltet.
Es gibt mehrere, und sie sind für verschiedene Aspekte der Funktionsweise der Dienste verantwortlich. Ein Teil von ihnen ist so konfiguriert, dass er autonom in jedem Rechenzentrum arbeitet (das heißt, sie überwachen nur ihr eigenes Rechenzentrum), andere bestehen aus verteilten Komponenten, die transparent den Ausfall eines beliebigen Rechenzentrums überstehen.
In diesem Fall ist ausgefallen , das im Master-Standby-Modus funktioniert. Wir haben auf Standby umgeschaltet.
Entscheidung
15:51. Über IPMI wurden ohne ordnungsgemäße Beendigung alle Server außer MS SQL heruntergefahren.
Sind Sie bereit für das Massamanagement von Servern über IPMI im Bedarfsfall?
Der Moment, in dem die Rettung der Geräte im Rechenzentrum zu diesem Zeitpunkt abgeschlossen ist. Alles, was möglich war, wurde getan. Einige Kollegen können sich ausruhen.
16:13. Es gab Informationen, dass die Freonrohre der Klimaanlagen auf dem Dach geplatzt sind — das wird den Start des Rechenzentrums nach der Behebung des Brandes verzögern.
16:19. Laut Informationen des technischen Personals des Rechenzentrums hat der Temperaturanstieg in den Räumen aufgehört.
17:10. Die Verfügbarkeit der Konfigurationsdatenbank wurde wiederhergestellt. Jetzt können wir die Einstellungen der Anwendungen ändern.
Warum ist das so wichtig, wenn alles ausfallsicher ist und selbst ohne ein Rechenzentrum funktioniert?
Erstens ist nicht alles ausfallsicher. Es gibt verschiedene sekundäre Dienste, die die Ausfälle eines Rechenzentrums bisher nicht gut überstehen, und es gibt Datenbanken im Master-Standby-Modus. Die Möglichkeit, Einstellungen zu verwalten, ermöglicht es, alles Notwendige zu tun, um selbst unter schwierigen Bedingungen die Auswirkungen von Störungen auf die Nutzer zu minimieren.
Zweitens wurde klar, dass das Rechenzentrum in den nächsten Stunden nicht vollständig wiederhergestellt wird, deshalb mussten Maßnahmen ergriffen werden, damit die langfristige Nichtverfügbarkeit von Replikaten nicht zu weiteren Problemen wie der Überfüllung von Festplatten in den verbleibenden Rechenzentren führt.
17:29. Zeit für Pizza! Bei uns arbeiten Menschen, keine Roboter.
Rehabilitation
18:02. Die Temperatur in den Räumen Nummer 8 (unser), 9, 10 und 11 hat sich stabilisiert. In einem der Räume, die weiterhin abgeschaltet sind (Nr. 7), befindet sich unsere Ausrüstung, und die Temperatur dort steigt weiter an.
18:31. Genehmigung zur Inbetriebnahme der Ausrüstung in den Räumen Nr. 1 und 3 — diese Räume wurden von dem Feuer nicht betroffen.
Derzeit werden Server in den Räumen Nr. 1, 3 und 8 gestartet, beginnend mit den kritischsten. Die Funktionsfähigkeit aller gestarteten Dienste wird überprüft. Im Raum Nr. 7 gibt es nach wie vor Probleme.
18:44. Technisches Personal des Rechenzentrums stellte fest, dass im Raum Nr. 7 (in dem nur unsere Geräte stehen) viele Server nicht abgeschaltet sind. Nach unseren Angaben bleiben dort 26 Server eingeschaltet. Nach einer erneuten Überprüfung stellen wir fest, dass 58 Server aktiv sind.
20:18. Technisches Personal des Rechenzentrums belüftet den Raum ohne Klimaanlage mit mobilen Luftkanälen, die durch die Flure verlegt sind.
23:08. Der erste Administrator wurde nach Hause entlassen. Jemand muss nachts schlafen, um morgen die Arbeiten fortzusetzen. Außerdem lassen wir weitere Administratoren und Entwickler nach Hause gehen.
02:56. Wir haben alles gestartet, was gestartet werden konnte. Wir führen eine umfassende Prüfung aller Dienste mit automatisierten Tests durch.
03:02. Die Klimatisierung im letzten, 7. Raum wurde wiederhergestellt.
03:36. Die Fronten im Rechenzentrum wurden in die DNS-Rotation eingebunden. Ab diesem Moment beginnt der Benutzerverkehr hereinzukommen.
Wir entlassen den Großteil des Administrator-Teams nach Hause. Aber einige Leute bleiben.
Kleines FAQ:
Q: Was geschah zwischen 18:31 und 02:56?
A: Gemäß dem „Notfallmaßnahmenplan“ starten wir alle Dienste, beginnend mit den wichtigsten. Dabei weist der Koordinator im Chat den Dienst einem verfügbaren Administrator zu, der überprüft, ob das Betriebssystem und die Anwendung gestartet sind, ob Fehler vorliegen und ob die Werte in Ordnung sind. Nach Abschluss des Starts informiert er im Chat, dass er verfügbar ist, und erhält vom Koordinator einen neuen Dienst.
Der Prozess wird zusätzlich durch ausgefallene Hardware verlangsamt. Selbst wenn das Stoppen des Betriebssystems und das Abschalten der Server korrekt durchgeführt wurden, kehren einige Server aufgrund plötzlich ausgefallener Festplatten, Speicher oder Gehäuse nicht zurück. Bei einem Stromausfall steigt der Ausfallprozentsatz.
Q: Warum kann man nicht einfach alles auf einmal starten und dann beheben, was im Monitoring sichtbar wird?
A: Alles muss schrittweise erfolgen, da es Abhängigkeiten zwischen den Diensten gibt. Zudem sollte alles sofort überprüft werden, ohne auf das Monitoring zu warten — denn es ist besser, Probleme sofort zu lösen, anstatt auf eine Verschärfung zu warten.
7:40. Der letzte Administrator (Koordinator) ist schlafen gegangen. Die Arbeiten des ersten Tages sind abgeschlossen.
8:09. Die ersten Entwickler, Ingenieure in den Rechenzentren und Administratoren (einschließlich des neuen Koordinators) haben mit den Wiederherstellungsarbeiten begonnen.
09:37. Wir haben mit dem Hochheben von Saal Nr. 7 (dem letzten) begonnen.
Parallel setzen wir die Wiederherstellung dessen fort, was in anderen Sälen nicht abgeschlossen wurde: Austausch von Festplatten/Speicher/Servern, Reparatur von allem, was in der Überwachung als 'kritisch' angezeigt wird, Rückumstellung der Rollen in den Master-Standby-Schemata und andere Kleinigkeiten, die dennoch zahlreich sind.
17:08. Wir erlauben alle regulären Arbeiten mit dem Produktionssystem.
21:45. Die Arbeiten des zweiten Tages sind abgeschlossen.
09:45. Heute ist Freitag. In der Überwachung gibt es nach wie vor viele kleine Probleme. Das Wochenende steht bevor, und alle möchten sich ausruhen. Wir reparieren weiterhin massenhaft alles, was möglich ist. Regulierungsaufgaben, die aufgeschoben werden konnten, sind aufgeschoben. Der Koordinator ist neu.
15:40. Plötzlich hat sich die Hälfte des Core-Netzwerk-Stacks in einem ANDEREN Rechenzentrum neu gestartet. Wir haben die Fronten aus der Rotation genommen, um Risiken zu minimieren. Es gab keine Auswirkungen für die Nutzer. Später stellte sich heraus, dass es ein fehlerhaftes Chassis war. Der Koordinator arbeitet an der Reparatur von gleich zwei Ausfällen.
17:17. Die Netzwerkoperationen in einem anderen Rechenzentrum wurden wiederhergestellt, alles wurde überprüft. Das Rechenzentrum ist nun im Rotationseinsatz.
18:29. Die Arbeiten am dritten Tag und insgesamt die Wiederherstellung nach dem Vorfall sind abgeschlossen.
Nachwort
04.04.2013, , „Odnoklassniki“ — der Portal war für drei Tage vollständig oder teilweise nicht verfügbar. Während dieser gesamten Zeit haben über 100 Personen aus verschiedenen Städten und Unternehmen (nochmals vielen Dank!) tausende Server remote und direkt in den Rechenzentren, sowohl manuell als auch automatisch, repariert.
Wir haben Lehren daraus gezogen. Um Wiederholungen zu vermeiden, haben wir umfassende Arbeiten durchgeführt und setzen sie bis heute fort.
Was sind die Hauptunterschiede zwischen dem aktuellen Vorfall und dem 404?
- Wir haben einen „Notfallaktionsplan“ entwickelt. Jedes Quartal führen wir Übungen durch — wir simulieren ein Notfallszenario, das von einer Gruppe von Administratoren (alle abwechselnd) behoben werden muss, indem sie den „Notfallaktionsplan“ verwenden. Die leitenden Systemadministratoren üben abwechselnd die Rolle des Koordinators.
- Quartalsweise isolieren wir testweise die Rechenzentren (alle nacheinander) über das LAN und WAN, um Engpässe rechtzeitig zu identifizieren.
- Weniger defekte Festplatten, da wir die Standards verschärft haben: geringere Betriebsstunden, strengere Schwellenwerte für S.M.A.R.T.
- Wir haben uns vollständig von BerkeleyDB getrennt — der alten und instabilen Datenbank, die viel Zeit für die Wiederherstellung nach einem Serverneustart benötigte.
- Die Anzahl der Server mit MS SQL wurde reduziert und die Abhängigkeit von den verbleibenden verringert.
- Wir haben unsere eigene , in die wir seit zwei Jahren aktiv alle Dienste migrieren. Die Cloud vereinfacht den gesamten Arbeitszyklus mit der Anwendung erheblich und bietet im Falle eines Ausfalls einzigartige Werkzeuge wie:
- die korrekte Stopptaste für alle Anwendungen auf einen Klick;
- einfache Migration von Anwendungen von fehlerhaften Servern;
- automatisches, priorisiertes (in der Reihenfolge der Dienste) Hochfahren eines gesamten Rechenzentrums.
Der Vorfall, der in diesem Artikel beschrieben wird, war der größte seit dem 404. Natürlich lief nicht alles reibungslos. Zum Beispiel fiel während der Nichtverfügbarkeit des ausgebrannten Rechenzentrums eine Festplatte in einem anderen Rechenzentrum aus, sodass nur eine von drei Replikaten im Cassandra-Cluster verfügbar war, was dazu führte, dass 4,2% der Nutzer mobiler Anwendungen sich nicht einloggen konnten. Die bereits verbundenen Nutzer konnten jedoch weiterarbeiten. Insgesamt wurden mehr als 30 Probleme festgestellt — von banalen Bugs bis hin zu Mängeln in der Architektur der Dienste.
Der Hauptunterschied zwischen dem aktuellen Vorfall und dem 404 besteht jedoch darin, dass, während wir die Folgen des Brandes beseitigten, die Nutzer weiterhin chatten und Videoanrufe in , Spiele spielen, Musik hören, Geschenke austauschen, Videos, Serien und Fernsehsender in , sowie in .
streamen. Wie laufen eure Vorfälle ab?
Quelle: habr.com
