Wie würden Sie sich fühlen, wenn das Rechenzentrum mit Ihrer Ausrüstung an einem schönen Sommertag so aussehen würde?
Hallo alle! Mein Name ist Dmitry Samsonov, ich arbeite als führender Systemadministrator in „". Das Foto zeigt eines der vier Rechenzentren, in dem die Ausrüstung für unser Projekt installiert ist. Hinter diesen Mauern befinden sich etwa 4 Geräte: Server, Datenspeichersysteme, Netzwerkgeräte usw. — fast ⅓ unserer gesamten Ausrüstung.
Die meisten Server sind Linux. Es gibt auch mehrere Dutzend Server auf Windows (MS SQL) – unser Erbe, von dem wir uns seit vielen Jahren systematisch verabschieden.
Am 5. Juni 2019 um 14:35 Uhr meldeten Ingenieure in einem unserer Rechenzentren einen Feueralarm.
Verweigerung
14:45. Kleinere Rauchvorfälle in Rechenzentren kommen häufiger vor, als Sie denken. Die Indikatoren in den Hallen waren normal, daher war unsere erste Reaktion relativ ruhig: Sie verhängten ein Arbeitsverbot für die Produktion, also für jegliche Konfigurationsänderungen, für die Einführung neuer Versionen usw., mit Ausnahme von Arbeiten im Zusammenhang mit der Reparatur.
Zorn
Haben Sie schon einmal versucht, von den Feuerwehrleuten genau herauszufinden, wo auf dem Dach der Brand ausgebrochen ist, oder sich selbst auf das brennende Dach zu begeben, um die Lage zu beurteilen? Wie hoch wird das Vertrauen in die von fünf Personen erhaltenen Informationen sein?
14:50 Uhr Es liegen Informationen vor, dass sich das Feuer dem Kühlsystem nähert. Aber wird es kommen? Der diensthabende Systemadministrator zeigt den externen Datenverkehr von den Fronten dieses Rechenzentrums an.
Derzeit sind die Fronten aller unserer Dienste in drei Rechenzentren dupliziert, wobei ein Ausgleich auf DNS-Ebene verwendet wird, der es ermöglicht, die Adressen eines Rechenzentrums aus dem DNS zu entfernen und so Benutzer vor potenziellen Problemen beim Zugriff auf Dienste zu schützen . Für den Fall, dass im Rechenzentrum bereits Probleme aufgetreten sind, verlässt es die Rotation automatisch. Mehr können Sie hier lesen:
Der Brand hat uns bisher in keiner Weise beeinträchtigt – weder Benutzer noch Geräte sind betroffen. Ist es ein Unfall? Der erste Abschnitt des Dokuments „Unfallaktionsplan“ definiert den Begriff „Unfall“ und der Abschnitt endet wie folgt:
«Wenn es irgendwelche Zweifel gibt, ein Unfall oder nicht, dann ist es ein Unfall!»
14:53. Es wird ein Unfallkoordinator bestellt.
Der Koordinator ist eine Person, die die Kommunikation zwischen allen Beteiligten steuert, das Ausmaß des Unfalls einschätzt, den „Unfall-Aktionsplan“ anwendet, das erforderliche Personal anzieht, den Abschluss der Reparatur überwacht und vor allem alle Aufgaben delegiert. Mit anderen Worten: Dies ist die Person, die den gesamten Prozess der Unfallbeseitigung leitet.
Handel
15:01. Wir beginnen damit, Server abzuschalten, die nicht an die Produktion gebunden sind.
15:03. Deaktivieren Sie alle reservierten Dienste ordnungsgemäß.
Dazu gehören nicht nur die Fronten (auf die Benutzer zu diesem Zeitpunkt nicht mehr zugreifen können) und deren Hilfsdienste (Geschäftslogik, Caches usw.), sondern auch verschiedene Datenbanken mit einem Replikationsfaktor von 2 oder mehr (, , , usw.).
15:06 Uhr Es gingen Informationen ein, dass in einer der Hallen des Rechenzentrums ein Feuer drohte. Wir haben in dieser Halle keine Ausrüstung, aber die Tatsache, dass Feuer vom Dach auf die Hallen übergreifen kann, verändert das Bild des Geschehens erheblich.
(Später stellte sich heraus, dass für die Halle keine physische Gefahr bestand, da sie vom Dach hermetisch abgedichtet war. Die Gefahr bestand lediglich für das Kühlsystem dieser Halle.)
15:07. Wir ermöglichen die Ausführung von Befehlen auf Servern im beschleunigten Modus ohne zusätzliche Prüfungen ().
15:08. Die Temperatur in den Räumen liegt im normalen Bereich.
15:12 Uhr Es wurde ein Temperaturanstieg in den Hallen registriert.
15:13. Mehr als die Hälfte der Server im Rechenzentrum sind abgeschaltet. Wir machen weiter.
15:16. Es wurde beschlossen, alle Geräte abzuschalten.
15:21. Wir fangen an, zustandslose Server auszuschalten, ohne die Anwendung und das Betriebssystem ordnungsgemäß herunterzufahren.
15:23. Eine Gruppe von Personen, die für MS SQL verantwortlich sind, wird herausgegriffen (es gibt nur wenige davon, die Abhängigkeit der Dienste von ihnen ist nicht groß, aber der Wiederherstellungsvorgang nimmt mehr Zeit in Anspruch und ist komplizierter als beispielsweise bei Cassandra).
Депрессия
15:25 Uhr In vier von 16 Sälen (Nr. 6, 7, 8, 9) wurde ein Stromausfall gemeldet. Unsere Ausstattung befindet sich in der 7. und 8. Halle. Zu unseren beiden Hallen (Nr. 1 und 3) liegen keine Informationen vor.
Normalerweise wird bei Bränden die Stromversorgung sofort abgeschaltet, aber in diesem Fall wurde sie dank der koordinierten Arbeit von Feuerwehrleuten und technischem Personal des Rechenzentrums nicht überall und nicht sofort, sondern aus Notwendigkeit abgeschaltet.
(Später stellte sich heraus, dass der Strom in den Räumen 8 und 9 nicht abgeschaltet war.)
15:28. Wir beginnen mit der Bereitstellung von MS SQL-Datenbanken aus Backups in anderen Rechenzentren.
Wie lange wird es dauern? Ist für die gesamte Strecke ausreichend Netzwerkbandbreite vorhanden?
15:37 Uhr Die Unterbrechung einiger Abschnitte des Netzwerks wurde behoben.
Management- und Produktionsnetzwerk sind physisch voneinander isoliert. Wenn das Produktionsnetzwerk verfügbar ist, können Sie zum Server gehen, die Anwendung stoppen und das Betriebssystem ausschalten. Wenn es nicht verfügbar ist, können Sie über IPMI gehen, die Anwendung stoppen und das Betriebssystem ausschalten. Wenn es keines der Netzwerke gibt, können Sie nichts tun. „Danke, Cap!“, denkst du.
„Ja, und generell herrscht irgendwie viel Aufruhr“, könnte man auch denken.
Tatsache ist, dass Server auch ohne Feuer eine enorme Hitze erzeugen. Genauer gesagt, wenn Kühlung vorhanden ist, erzeugen sie Wärme, und wenn keine vorhanden ist, erzeugen sie ein höllisches Inferno, das im besten Fall einen Teil der Ausrüstung zum Schmelzen bringt und den anderen Teil abschaltet und im schlimmsten Fall ... einen Brand im Inneren verursacht Halle, die fast garantiert alles zerstört.
15:39. Wir beheben Probleme mit der Conf-Basis.
Die conf base ist ein Backend für den gleichnamigen Dienst, der von allen Produktionsanwendungen zum schnellen Ändern von Einstellungen verwendet wird. Ohne diese Basis können wir den Betrieb des Portals nicht bewältigen, aber das Portal selbst kann gleichzeitig funktionieren.
15:41. Temperatursensoren an Core-Netzwerkgeräten zeichnen Messwerte auf, die nahe am zulässigen Höchstwert liegen. Hierbei handelt es sich um eine Box, die ein ganzes Rack einnimmt und den Betrieb aller Netzwerke im Rechenzentrum gewährleistet.
15:42. Issue-Tracker und Wiki sind nicht verfügbar, wechseln Sie in den Standby-Modus.
Dies ist keine Produktion, aber im Falle eines Unfalls kann die Verfügbarkeit jeglicher Wissensdatenbank von entscheidender Bedeutung sein.
15:50. Eines der Überwachungssysteme wurde deaktiviert.
Es gibt mehrere davon und sie sind für verschiedene Aspekte der Dienste verantwortlich. Einige von ihnen sind so konfiguriert, dass sie autonom in jedem Rechenzentrum arbeiten (das heißt, sie überwachen nur ihr eigenes Rechenzentrum), andere bestehen aus verteilten Komponenten, die den Verlust eines Rechenzentrums transparent überstehen.
In diesem Fall funktionierte es nicht mehr. , das im Master-Standby-Modus funktioniert. Auf Standby geschaltet.
Adoption
15:51. Durch IPMI wurden alle Server außer MS SQL ohne ordnungsgemäßes Herunterfahren abgeschaltet.
Sind Sie bereit, Server bei Bedarf massenhaft über IPMI zu verwalten?
Genau der Moment, in dem die Rettung der Geräte im Rechenzentrum zu diesem Zeitpunkt abgeschlossen ist. Es wurde alles getan, was getan werden konnte. Manche Kollegen können sich eine Pause gönnen.
16:13 Uhr Es gab Informationen, dass Freonrohre von Klimaanlagen auf dem Dach geplatzt seien – dies würde den Start des Rechenzentrums nach der Löschung des Feuers verzögern.
16:19. Nach Angaben des technischen Personals des Rechenzentrums ist der Temperaturanstieg in den Hallen gestoppt.
17:10. Die Funktion der conf-Datenbank wurde wiederhergestellt. Jetzt können wir die Anwendungseinstellungen ändern.
Warum ist es so wichtig, wenn alles fehlertolerant ist und auch ohne ein Rechenzentrum funktioniert?
Erstens ist nicht alles fehlertolerant. Es gibt verschiedene sekundäre Dienste, die noch nicht gut genug sind, um den Ausfall des Rechenzentrums zu überstehen, und es gibt Stützpunkte im Master-Standby-Modus. Durch die Möglichkeit, Einstellungen zu verwalten, können Sie alles Notwendige tun, um die Auswirkungen der Unfallfolgen auf Benutzer auch unter schwierigen Bedingungen zu minimieren.
Zweitens wurde klar, dass die Arbeit des Rechenzentrums in den nächsten Stunden nicht vollständig wiederhergestellt sein würde. Daher mussten Maßnahmen ergriffen werden, damit die langfristige Nichtverfügbarkeit von Replikaten nicht zu zusätzlichen Problemen wie überfüllten Festplatten führte in den übrigen Rechenzentren.
17:29. Pizza Zeit! Wir beschäftigen Menschen, keine Roboter.
Rehabilitation
18:02. In den Hallen Nr. 8 (unser), 9, 10 und 11 hat sich die Temperatur stabilisiert. Einer von denen, die offline bleiben (Nr. 7), enthält unsere Ausrüstung, und die Temperatur steigt dort weiter an.
18:31. Sie gaben grünes Licht für die Inbetriebnahme der Anlagen in den Hallen Nr. 1 und 3 – diese Hallen waren vom Brand nicht betroffen.
Derzeit werden in den Hallen Nr. 1, 3, 8 Server in Betrieb genommen, beginnend mit den kritischsten. Der korrekte Betrieb aller laufenden Dienste wird überprüft. Es gibt immer noch Probleme mit Halle Nummer 7.
18:44. Das technische Personal des Rechenzentrums stellte fest, dass in Raum Nummer 7 (in dem sich nur unsere Geräte befinden) viele Server nicht ausgeschaltet waren. Nach unseren Angaben verbleiben dort noch 26 Server. Nach erneuter Überprüfung finden wir 58 Server.
20:18. Das technische Personal des Rechenzentrums bläst die Luft in den Raum ohne Klimaanlage durch mobile, durch die Flure verlegte Luftkanäle.
23:08. Lassen Sie den ersten Administrator nach Hause gehen. Jemand muss nachts schlafen, um morgen weiterarbeiten zu können. Als nächstes geben wir einen weiteren Teil der Admins und Entwickler frei.
02:56. Wir haben alles gestartet, was gestartet werden konnte. Wir führen einen umfassenden Check aller Dienste mit Autotests durch.
03:02. Die Klimaanlage im letzten, 7. Saal wurde restauriert.
03:36. Wir haben die Fronten im Rechenzentrum im DNS in Rotation gebracht. Von diesem Moment an beginnt der Benutzerverkehr zu kommen.
Wir schicken den Großteil des Admin-Teams nach Hause. Aber wir lassen ein paar Leute zurück.
Kleine FAQ:
F: Was ist von 18:31 bis 02:56 passiert?
A: Gemäß dem Katastrophenschutzplan starten wir alle Dienste, beginnend mit den wichtigsten. Gleichzeitig übergibt der Koordinator im Chat den Dienst an einen freien Administrator, der prüft, ob das Betriebssystem und die Anwendung gestartet sind, ob Fehler vorliegen und ob die Indikatoren normal sind. Nachdem der Start abgeschlossen ist, meldet er im Chat, dass er frei ist, und erhält vom Koordinator eine neue Leistung.
Der Prozess wird durch das ausgefallene Eisen zusätzlich gehemmt. Selbst wenn das Herunterfahren des Betriebssystems und das Herunterfahren der Server gut verliefen, kehren einige Server aufgrund plötzlicher Festplatten-, Speicher- und Gehäuseausfälle nicht zurück. Bei einem Stromausfall steigt die Ausfallrate.
F: Warum können Sie nicht einfach alles auf einmal ausführen und dann korrigieren, was bei der Überwachung herauskommt?
A: Alles sollte schrittweise erfolgen, da es Abhängigkeiten zwischen Diensten gibt. Und alles sollte sofort überprüft werden, ohne auf eine Überwachung zu warten – denn es ist besser, Probleme sofort zu beheben und nicht darauf zu warten, dass sie sich verschlimmern.
7:40. Der letzte Admin (Koordinator) ging schlafen. Die Arbeit des ersten Tages ist abgeschlossen.
8:09. Die ersten Entwickler, Rechenzentrumsingenieure und Administratoren (einschließlich des neuen Koordinators) haben mit den Wiederherstellungsarbeiten begonnen.
09:37. Wir haben mit dem Ausbau der Halle Nummer 7 (der letzten) begonnen.
Gleichzeitig stellen wir weiterhin wieder her, was in anderen Räumen nicht abgeschlossen wurde: Festplatten / Speicher / Server austauschen, alles reparieren, was bei der Überwachung „brennt“, Rollenwechsel in Master-Standby-Schemata umkehren und andere Kleinigkeiten, die dennoch recht sind eine Menge.
17:08. Wir erlauben alle regulären Arbeiten mit der Produktion.
21:45. Die Arbeit des zweiten Tages ist abgeschlossen.
09:45. Heute ist Freitag. Es gibt noch einige kleinere Probleme bei der Überwachung. Das Wochenende steht vor der Tür und jeder möchte entspannen. Wir reparieren weiterhin massiv alles, was wir können. Regelmäßige Verwaltungsaufgaben, die hätten verschoben werden können, wurden verschoben. Neuer Koordinator.
15:40. Plötzlich wurde die Hälfte des Core-Stacks der Netzwerkausrüstung in EINEM ANDEREN Rechenzentrum neu gestartet. Um Risiken zu minimieren, wurden die Fronten aus der Rotation genommen. Es gibt keine Auswirkungen für Benutzer. Später stellte sich heraus, dass es sich um ein defektes Fahrwerk handelte. Der Koordinator arbeitet daran, zwei Unfälle gleichzeitig zu beheben.
17:17. Der Netzwerkbetrieb in einem anderen Rechenzentrum wurde wiederhergestellt, alles wurde überprüft. Das Rechenzentrum ist in Rotation.
18:29. Die Arbeit des dritten Tages und allgemein die Genesung nach dem Unfall ist abgeschlossen.
Nachwort
04.04.2013 , "Klassenkameraden" – Drei Tage lang war das Portal ganz oder teilweise nicht erreichbar. Während dieser ganzen Zeit haben mehr als 100 Menschen aus verschiedenen Städten, von verschiedenen Unternehmen (nochmals vielen Dank!), aus der Ferne und direkt in Rechenzentren Tausende von Servern manuell und automatisch repariert.
Wir haben Schlussfolgerungen gezogen. Damit so etwas nicht noch einmal passiert, haben wir umfangreiche Maßnahmen durchgeführt und führen diese bis heute fort.
Was sind die Hauptunterschiede zwischen dem aktuellen Unfall und 404?
- Wir haben einen Unfallaktionsplan. Einmal im Quartal führen wir eine Übung durch – wir spielen einen Notfall durch, den eine Gruppe von Administratoren (jeder der Reihe nach) mithilfe des „Disaster Response Plan“ lösen muss. Führende Systemadministratoren übernehmen abwechselnd die Rolle des Koordinators.
- Vierteljährlich isolieren wir im Testmodus Rechenzentren (alle nacheinander) über die LAN- und WAN-Netzwerke, wodurch wir Engpässe rechtzeitig erkennen können.
- Weniger schlechte Fahrten, weil wir unsere Vorschriften verschärft haben: weniger Betriebsstunden, strengere SMART-Grenzwerte,
- Wir haben BerkeleyDB komplett aufgegeben, eine alte und instabile Datenbank, deren Wiederherstellung nach einem Serverneustart viel Zeit in Anspruch nahm.
- Wir haben die Anzahl der Server mit MS SQL reduziert und die Abhängigkeit von den verbleibenden Servern verringert.
- Wir haben unser eigenes , wo wir seit zwei Jahren aktiv alle Dienste migrieren. Die Cloud vereinfacht den gesamten Arbeitszyklus mit der Anwendung erheblich und bietet im Falle eines Unfalls einzigartige Tools wie:
- korrekter Stopp aller Anwendungen mit einem Klick;
- einfache Migration von Anwendungen von ausgefallenen Servern;
- Automatischer, nach Dienstpriorität geordneter Start des gesamten Rechenzentrums.
Der in diesem Artikel beschriebene Unfall war der größte seit dem 404. Tag. Natürlich verlief nicht alles reibungslos. Während der Nichtverfügbarkeit des durch einen Brand beschädigten Rechenzentrums in einem anderen Rechenzentrum stürzte beispielsweise eine Festplatte auf einem der Server ab, d Anwendungsbenutzer konnten sich nicht anmelden. Gleichzeitig arbeiteten bereits verbundene Benutzer weiter. Insgesamt wurden infolge des Unfalls mehr als 4,2 Probleme festgestellt – von banalen Fehlern bis hin zu Mängeln in der Architektur der Dienste.
Der wichtigste Unterschied zwischen dem aktuellen Unfall und dem 404. besteht jedoch darin, dass die Benutzer, während wir die Folgen des Brandes beseitigten, weiterhin SMS schrieben und Videoanrufe tätigten , Spiele gespielt, Musik gehört, sich gegenseitig Geschenke gemacht, Videos, Serien und Fernsehsender geschaut , und auch gestreamt .
Wie läuft es mit Ihren Unfällen?
Source: habr.com