Was würden Sie fühlen, wenn an einem schönen Sommertag ein Rechenzentrum mit Ihrer Ausrüstung so aussehen würde?
Hallo allerseits! Mein Name ist Dmitry Samsonov, ich arbeite als führender Systemadministrator bei
Odnoklassniki . Das Foto zeigt eines der vier Rechenzentren, in denen die Geräte installiert sind, die unser Projekt bedienen. Hinter diesen Mauern befinden sich ungefähr 4.000 Geräteeinheiten: Server, Datenspeichersystem, Netzwerkgeräte usw. - fast ⅓ unserer gesamten Ausrüstung.
Die meisten Server sind Linux. Es gibt mehrere Dutzend Windows-Server (MS SQL) - unser Vermächtnis, das wir seit vielen Jahren systematisch ablehnen.
Am 5. Juni 2019 um 14:35 Uhr meldeten die Ingenieure eines unserer Rechenzentren einen Feueralarm.
Ablehnung
14:45. Kleinere rauchige Vorfälle in Rechenzentren sind häufiger als sie scheinen. Die Anzeigen in den Hallen waren normal, daher war unsere erste Reaktion relativ ruhig: Wir haben ein Verbot der Arbeit mit der Produktion eingeführt, dh jegliche Konfigurationsänderungen, die Einführung neuer Versionen usw., mit Ausnahme von Arbeiten im Zusammenhang mit der Reparatur von Problemen.
Wut
Haben Sie jemals versucht, von Feuerwehrleuten genau herauszufinden, wo auf dem Dach ein Feuer brannte, oder selbst auf ein brennendes Dach zu steigen, um die Situation einzuschätzen? Wie hoch wird das Vertrauen in die Informationen sein, die von fünf Personen erhalten werden?
14:50.
Es wurde die Information erhalten, dass sich das Feuer dem Kühlsystem nähert . Aber wird es kommen? Der diensthabende Systemadministrator zeigt externen Datenverkehr von den Fronten dieses Rechenzentrums an.
Derzeit werden die Fronten aller unserer Dienste in drei Rechenzentren dupliziert. Dabei wird ein Ausgleich auf DNS-Ebene verwendet, mit dem Sie die Adressen eines Rechenzentrums aus dem DNS entfernen und Benutzer so vor potenziellen Problemen beim Zugriff auf Dienste schützen können. Falls im Rechenzentrum bereits Probleme aufgetreten sind, verlässt es automatisch die Rotation. Weitere Details finden Sie hier: Lastausgleich und Fehlertoleranz in Odnoklassniki.
Das Feuer hat uns noch in keiner Weise getroffen - weder Benutzer noch Ausrüstung sind betroffen. Ist es ein Unfall? Der erste Abschnitt des Dokuments „Unfallaktionsplan“ definiert das Konzept „Unfall“ und der Abschnitt endet wie folgt:
„ Im Zweifelsfall ein Unfall oder nicht, dann ist dies ein Unfall! ""14:53. Ein Unfallkoordinator wird ernannt.
Ein Koordinator ist eine Person, die die Kommunikation zwischen allen Teilnehmern kontrolliert, das Ausmaß des Unfalls schätzt, den „Unfallaktionsplan“ verwendet, 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 Beseitigung des Unfalls verwaltet.
Verhandeln
15:01. Wir beginnen, Server zu trennen, die nicht an die Produktion gebunden sind.
15:03. Schalten Sie alle reservierten Dienste korrekt aus.
Dies umfasst nicht nur Fronten (an denen sich Benutzer zu diesem Zeitpunkt nicht mehr anmelden) und deren Zusatzdienste (Geschäftslogik, Caches usw.), sondern auch verschiedene Datenbanken mit Replikationsfaktor 2 oder mehr (
Cassandra ,
binärer Datenspeicher) ,
Kühlhaus ,
NewSQL usw.).
15:06.
Es wurde die Information erhalten, dass ein Brand eine der Hallen des Rechenzentrums bedroht. Wir haben keine Ausrüstung in dieser Halle, aber die Tatsache, dass sich Feuer vom Dach auf die Hallen ausbreiten kann, verändert das Bild des Geschehens erheblich.
(Später stellte sich heraus, dass die Halle nicht physisch bedroht war, da sie hermetisch vom Dach isoliert war. Die Bedrohung betraf nur das Kühlsystem dieser Halle.)
15:07. Wir erlauben die Ausführung von Befehlen auf Servern im beschleunigten Modus ohne zusätzliche Überprüfungen (
ohne unseren Lieblingsrechner ).
15:08. Die Temperatur in den Räumen liegt innerhalb normaler Grenzen.
15:12.
Ein Temperaturanstieg in den Hallen wurde verzeichnet.15:13. Mehr als die Hälfte der Server im Rechenzentrum ist ausgeschaltet. Wir fahren fort.
15:16. Es wurde beschlossen, alle Geräte auszuschalten.
15:21 Uhr Wir beginnen, die Stromversorgung auf zustandslosen Servern auszuschalten, ohne die Anwendung und die Betriebssysteme ordnungsgemäß herunterzufahren.
15:23. Eine Gruppe von Verantwortlichen für MS SQL wird herausgegriffen (es gibt nur wenige von ihnen, die Abhängigkeit der Dienste von ihnen ist nicht groß, aber das Verfahren zur Wiederherstellung der Gesundheit dauert länger und ist komplizierter als beispielsweise Cassandra).
Depression
15:25.
In vier der 16 Räume (Nr. 6, 7, 8, 9) gingen Informationen zum Ausschalten ein. In der 7. und 8. Halle befinden sich unsere Geräte. Es gibt keine weiteren Informationen zu unseren beiden Zimmern (Nr. 1 und 3).
Normalerweise wird die Stromversorgung bei Bränden sofort abgeschaltet. In diesem Fall wurde sie jedoch dank der koordinierten Arbeit der Feuerwehrleute und des technischen Personals des Rechenzentrums nicht überall und nicht sofort, sondern nach Bedarf ausgeschaltet.
(Später stellte sich heraus, dass der Strom in den Hallen 8 und 9 nicht abgeschaltet wurde.)
15:28. Wir beginnen mit der Bereitstellung von MS SQL-Datenbanken aus Sicherungen in anderen Rechenzentren.
Wie lange wird es dauern? Gibt es genügend Netzwerkbandbreite für die gesamte Route?
15:37.
Einige Teile des Netzwerks gesperrt.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 IPMI durchlaufen, die Anwendung stoppen und das Betriebssystem ausschalten. Wenn kein Netzwerk vorhanden ist, können Sie nichts tun. "Danke Mütze!" Sie werden denken.
"Wie auch immer, es gibt viel Verwirrung", könnte man auch denken.
Die Sache ist, dass Server auch ohne Feuer eine große Menge Wärme erzeugen. Genauer gesagt, wenn es kühlt, erzeugen sie Wärme, und wenn es keine gibt, erzeugen sie eine höllische Hölle, die im besten Fall einen Teil der Ausrüstung zum Schmelzen bringt und den anderen ausschaltet, und im schlimmsten Fall ... ein Feuer in der Halle verursacht, das mit ziemlicher Sicherheit alles zerstört.
15:39. Wir beheben Probleme mit der conf-Datenbank.
Die conf-Datenbank ist das Backend für den gleichnamigen Dienst, der von allen Produktionsanwendungen verwendet wird, um Einstellungen schnell zu ändern. Ohne diese Basis können wir das Portal nicht steuern, aber das Portal selbst kann funktionieren.
15:41. Temperatursensoren an Kernnetzwerkgeräten zeichnen Messwerte auf, die nahe dem maximal zulässigen Wert liegen. Dies ist eine Box, die ein ganzes Rack einnimmt und den Betrieb aller Netzwerke im Rechenzentrum sicherstellt.
15:42. Issue Tracker und Wiki sind nicht verfügbar. Wechseln Sie in den Standby-Modus.
Dies ist keine Produktion, aber bei einem Unfall kann die Verfügbarkeit einer Wissensbasis von entscheidender Bedeutung sein.
15:50. Eines der Überwachungssysteme wurde getrennt.
Es gibt mehrere von ihnen, und sie sind für verschiedene Aspekte der Arbeit von Dienstleistungen verantwortlich. Einige von ihnen sind so konfiguriert, dass sie in jedem Rechenzentrum autonom arbeiten (dh sie überwachen nur ihr Rechenzentrum), während andere aus verteilten Komponenten bestehen, die den Verlust eines Rechenzentrums transparent überstehen.
In diesem Fall
funktioniert das
System zur Erkennung von Anomalien in Geschäftslogikindikatoren , das im Master-Standby-Modus arbeitet, nicht mehr. In den Standby-Modus wechseln.
Akzeptanz
15:51. Über IPMI wurden alle Server außer MS SQL ohne korrektes Herunterfahren deaktiviert.
Sind Sie bei Bedarf für die Verwaltung von Massenservern über IPMI bereit?
Der Moment, in dem die Rettung der Geräte im Rechenzentrum zu diesem Zeitpunkt abgeschlossen ist. Alles was getan werden konnte wurde getan. Einige Kollegen können sich entspannen.
16:13.
Es gab Informationen, dass Freon-Röhren von den Klimaanlagen auf dem Dach platzten - dies wird den Start des Rechenzentrums verzögern, nachdem das Feuer beseitigt wurde.16:19. Nach Angaben des technischen Personals des Rechenzentrums wurde der Temperaturanstieg in den Hallen gestoppt.
17:10. Die Arbeit 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 den Ausfall des Rechenzentrums nicht gut genug überstehen, und es gibt Basen im Master-Standby-Modus. Durch die Verwaltung der Einstellungen können Sie alles Notwendige tun, um die Auswirkungen der Unfallfolgen auf die Benutzer auch unter schwierigen Bedingungen zu minimieren.
Zweitens wurde klar, dass das Rechenzentrum in den nächsten Stunden nicht vollständig wiederhergestellt werden kann. Daher mussten Maßnahmen ergriffen werden, damit die langfristige Nichtverfügbarkeit von Replikaten nicht zu zusätzlichen Problemen wie Festplattenüberläufen in den verbleibenden Rechenzentren führte.
17:29. Pizzazeit! Wir haben Leute, die arbeiten, keine Roboter.
Rehabilitation
18:02. In den Räumen Nr. 8 (unsere), 9, 10 und 11 stabilisierte sich die Temperatur. In einem der Geräte, die nicht angeschlossen sind (Nr. 7), befindet sich unser Gerät, und die Temperatur steigt dort weiter an.
18:31. Sie gaben grünes Licht, um Ausrüstung in den Hallen Nr. 1 und 3 zu starten - das Feuer hatte keinen Einfluss auf diese Hallen.
Derzeit werden Server in den Hallen Nr. 1, 3, 8 gestartet, beginnend mit den kritischsten. Überprüft den korrekten Betrieb aller laufenden Dienste. Es gibt immer noch Probleme mit Raum 7.
18:44. Das technische Personal des Rechenzentrums stellte fest, dass in der Halle 7 (in der sich nur unsere Geräte befinden) viele Server nicht ausgeschaltet sind. Nach unseren Angaben verbleiben dort 26 Server. Nach erneuter Überprüfung finden wir 58 Server.
20:18. Das technische Personal des Rechenzentrums bläst Luft in den Raum ohne Klimaanlage durch mobile Kanäle, die durch die Korridore verlegt werden.
23:08. Sie ließen den ersten Administrator nach Hause gehen. Jemand muss nachts schlafen, um morgen weiterarbeiten zu können. Als nächstes veröffentlichen wir einen weiteren Teil der Administratoren und Entwickler.
02:56. Wir haben alles gestartet, was gestartet werden konnte. Wir überprüfen alle Dienste mit Autotests.
03:02 Uhr Klimaanlage in der letzten, 7. Halle restauriert.
03:36. Sie haben die Fronten im Rechenzentrum im DNS in Rotation gebracht. Ab diesem Moment beginnt der Benutzerverkehr anzukommen.
Wir lösen den größten Teil des Heimadministratorteams auf. Aber wir lassen ein paar Leute.
Kleine FAQ:
F: Was ist von 18:31 bis 02:56 passiert?
A: Nach dem „Unfallaktionsplan“ starten wir alle Dienste, beginnend mit den wichtigsten. Gleichzeitig bietet der Koordinator im Chat einem kostenlosen Administrator einen Dienst an, der prüft, ob das Betriebssystem und die Anwendung gestartet wurden, ob Fehler vorliegen oder die Anzeigen normal sind. Nach Abschluss des Starts informiert er den Chat darüber, dass er frei ist und erhält einen neuen Service vom Koordinator.
Der Prozess wird zusätzlich durch das ausgefallene Eisen gehemmt. Selbst wenn das Herunterfahren des Betriebssystems und das Herunterfahren der Server korrekt waren, kehren einige der Server aufgrund plötzlich ausgefallener Laufwerke, Speicher oder Gehäuse nicht zurück. Bei einem Stromausfall steigt die Ausfallrate.
F: Warum können Sie nicht einfach alles auf einmal starten und dann reparieren, was sich aus der Überwachung ergibt?
A: Alles muss schrittweise erledigt werden, da es Abhängigkeiten zwischen den Diensten gibt. Und alles sollte sofort überprüft werden, ohne auf die Überwachung zu warten - denn es ist besser, Probleme sofort zu lösen und nicht auf ihre Verschärfung zu warten.
7:40 Uhr Der letzte Administrator (Koordinator) ging ins Bett. Die Arbeit des ersten Tages ist abgeschlossen.
8:09 Uhr Die ersten Entwickler, Ingenieure in den Rechenzentren und Administratoren (einschließlich des neuen Koordinators) begannen mit den Restaurierungsarbeiten.
09:37. Wir fingen an, die Halle Nummer 7 (die letzte) zu erhöhen.
Gleichzeitig stellen wir weiterhin das wieder her, was wir in anderen Räumen nicht fertiggestellt haben: Ersetzen von Festplatten / Speicher / Servern, Beheben von Problemen bei der Überwachung, Umschalten der Rollen in Master-Standby-Schaltkreisen und andere kleine Dinge, die dennoch ziemlich viel sind.
17:08. Erlaube 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. Vor dem Wochenende wollen sich alle entspannen. Wir reparieren weiterhin massiv alles, was möglich ist. Regelmäßige Verwaltungsaufgaben, die verschoben werden könnten, werden verschoben. Der Koordinator ist neu.
15:40. Plötzlich wurde die Hälfte des Kernstapels der Netzwerkgeräte im ANDEREN Rechenzentrum neu gestartet. Fronten aus der Rotation entfernt, um Risiken zu minimieren. Es gibt keine Auswirkung für Benutzer. Später stellte sich heraus, dass es sich um ein schlechtes Chassis handelte. Der Koordinator behebt zwei Abstürze gleichzeitig.
17:17. Das Netzwerk in einem anderen Rechenzentrum wird wiederhergestellt, alles wird überprüft. Das Rechenzentrum ist in Rotation.
18:29. Die Arbeiten des dritten Tages und im Allgemeinen die Wiederherstellung nach dem Unfall sind abgeschlossen.
Nachwort
Am 04.04.2013,
am Tag des 404. Fehlers ,
überlebte Odnoklassniki
einen schweren Unfall - drei Tage lang war das Portal ganz oder teilweise nicht verfügbar. Während dieser Zeit wurden mehr als 100 Personen aus verschiedenen Städten und Unternehmen (nochmals vielen Dank!) Tausende von Servern manuell und automatisch aus der Ferne und direkt in Rechenzentren repariert.
Wir haben Schlussfolgerungen gezogen. Um dies zu verhindern, haben wir bis heute umfangreiche Arbeiten durchgeführt und führen diese fort.
Was sind die Hauptunterschiede zwischen dem aktuellen Unfall und 404?
- Wir haben einen „Notfallplan“. Einmal im Quartal führen wir Übungen durch - wir spielen einen Notfall aus, den eine Gruppe von Administratoren (alle wiederum) mithilfe des „Notfallaktionsplans“ beseitigen muss. Führende Systemadministratoren erarbeiten abwechselnd die Rolle des Koordinators.
- Isolieren Sie im Testmodus vierteljährlich Rechenzentren (alle nacheinander) über LAN und WAN, damit Sie Engpässe rechtzeitig erkennen können.
- Weniger schlechte Laufwerke, weil wir die Standards verschärft haben: weniger Betriebsstunden, strengere Schwellenwerte für SMART,
- BerkeleyDB wurde vollständig aufgegeben - eine alte und instabile Datenbank, deren Wiederherstellung nach einem Neustart des Servers viel Zeit in Anspruch nahm.
- Reduzieren Sie die Anzahl der Server mit MS SQL und die Abhängigkeit von den verbleibenden.
- Wir haben unsere eigene Cloud - One-Cloud , in der wir seit zwei Jahren alle Dienste aktiv migrieren. Die Cloud vereinfacht den gesamten Arbeitszyklus mit der Anwendung erheblich und bietet im Falle eines Unfalls einzigartige Tools wie:
- Richtig Stoppen Sie alle Anwendungen mit einem Klick.
- einfache Anwendungsmigration von ausgefallenen Servern;
- Automatisches Ranking (in der Reihenfolge der Priorität der Dienste) Starten eines gesamten Rechenzentrums.
Der in diesem Artikel beschriebene Unfall wurde der größte seit Tag 404. Natürlich lief nicht alles reibungslos. Während der Nichtverfügbarkeit des Rechenzentrumsbrenners in einem anderen Rechenzentrum stürzte beispielsweise eine Festplatte auf einem der Server ab, dh nur eine der drei Replikate im Cassandra-Cluster war verfügbar, wodurch sich 4,2% der Benutzer mobiler Anwendungen nicht anmelden konnten . Gleichzeitig arbeiteten bereits verbundene Benutzer weiter. Insgesamt wurden nach den Ergebnissen des Unfalls mehr als 30 Probleme festgestellt - von banalen Fehlern bis hin zu Fehlern in der Servicearchitektur.
Der Hauptunterschied zwischen dem aktuellen und dem 404. Unfall besteht jedoch darin, dass die Benutzer zwar die Folgen des Brandes beseitigt haben, die Benutzer jedoch in
Tamtam korrespondierten und Videoanrufe
tätigten , Spiele spielten, Musik hörten, sich gegenseitig Geschenke gaben, Videos, Fernsehsendungen und Fernsehkanäle sahen
OK und auch auf
OK Live gestreamt.
Wie laufen deine Unfälle?