{"id":84108,"date":"2020-06-05T07:42:44","date_gmt":"2020-06-05T05:42:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/tushit-li-servera-esli-zagorelsya-smouk-test-dataczentra"},"modified":"2020-06-05T07:42:44","modified_gmt":"2020-06-05T05:42:44","slug":"tushit-li-servera-esli-zagorelsya-smouk-test-dataczentra","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/tushit-li-servera-esli-zagorelsya-smouk-test-dataczentra","title":{"rendered":"Sollten die Server abgeschaltet werden, wenn der Rauchtest des Rechenzentrums \"anschl\u00e4gt\"?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Was w\u00fcrden Sie empfinden, wenn an einem sch\u00f6nen Sommertag Ihr Rechenzentrum so aussehen w\u00fcrde?<\/p>\n

\"Sollten
\n
\nHallo zusammen! Mein Name ist Dmitrij Samsonov, ich arbeite als leitender Systemadministrator bei \u201eOdnoklassniki<\/a><\/noindex>\u201c. Auf dem Foto sehen Sie eines von vier Rechenzentren, in denen die Hardware f\u00fcr unser Projekt untergebracht ist. Hinter diesen Mauern befinden sich etwa 4.000 Ger\u00e4te: Server, Speicherl\u00f6sungen, Netzwerktechnologie usw. \u2013 fast ein Drittel unserer gesamten Hardware.
\nDie meisten Server laufen unter Linux. Es gibt auch einige Dutzend Windows-Server (MS SQL) \u2013 unser Erbe, von dem wir uns \u00fcber die Jahre schrittweise verabschieden.
\nAm 5. Juni 2019 um 14:35 Uhr meldeten die Ingenieure eines unserer Rechenzentren einen Brandalarm.
\n<\/a><\/noindex><\/p>\n

Leugnung<\/h4>\n

\n14:45 Uhr. Kleine Rauchvorf\u00e4lle in Rechenzentren kommen h\u00e4ufiger vor, als man denkt. Die Werte in den R\u00e4umen waren normal, daher war unsere erste Reaktion relativ ruhig: Wir verh\u00e4ngten ein Verbot f\u00fcr Arbeiten im Produktionsumfeld, also f\u00fcr \u00c4nderungen an Konfigurationen, das Einspielen neuer Versionen usw., mit Ausnahme von Arbeiten, die mit der Reparatur von Ger\u00e4ten in Zusammenhang standen.<\/p>\n

Wut<\/h4>\n

\nHaben 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\u00fcnf Personen stammen?<\/p>\n

14:50. Es gibt Informationen, dass das Feuer sich dem K\u00fchlsystem n\u00e4hert.<\/b>. Aber wird es tats\u00e4chlich dazu kommen? Der diensthabende Systemadministrator leitet den externen Datenverkehr von den Fronten dieses Rechenzentrums um.<\/p>\n

Derzeit sind die Fronten aller unserer Dienste in drei Rechenzentren dupliziert, und es wird ein DNS-Balancing verwendet, das es erm\u00f6glicht, die Adressen eines Rechenzentrums aus dem DNS zu entfernen, sodass die Benutzer vor potenziellen Zugriffsproblemen auf die Dienste gesch\u00fctzt werden. Falls im Rechenzentrum bereits Probleme aufgetreten sind, wird es automatisch aus der Rotation entfernt. Weitere Informationen finden Sie hier: Lastverteilung und Ausfallsicherheit in \u201eOdnoklassniki\u201c.<\/a><\/noindex><\/p><\/blockquote>\n

\nDer Brand hat uns bisher nicht beeintr\u00e4chtigt \u2014 weder Benutzer noch Hardware haben gelitten. Handelt es sich um einen Vorfall? Der erste Abschnitt des Dokuments \u201eNotfallplan\u201c gibt eine Definition f\u00fcr den Begriff \u201eVorfall\u201c und endet mit folgendem Abschnitt:
\n\u00abWenn Zweifel bestehen, ob es sich um einen Notfall handelt oder nicht, dann ist es ein Notfall!<\/u>\u00bb<\/b><\/p>\n

14:53. Ein Notfallkoordinator wird ernannt.<\/p>\n

Der Koordinator ist die Person, die die Kommunikation zwischen allen Beteiligten \u00fcberwacht, den Umfang des Notfalls bewertet, den \"Notfallaktionsplan\" verwendet, notwendiges Personal einsetzt, die Beendigung der Reparatur \u00fcberwacht und vor allem Aufgaben delegiert. Mit anderen Worten, er ist die Person, die den gesamten Prozess der Notfallbew\u00e4ltigung leitet.<\/p><\/blockquote>\n

<\/p>\n

Verhandlung<\/h4>\n

\n15:01. Wir beginnen mit der Abschaltung der Server, die nicht mit der Produktion verbunden sind.
\n15:03. Wir schalten alle reservierten Dienste korrekt ab.
\nDazu geh\u00f6ren nicht nur die Frontend-Services (auf die die Benutzer zu diesem Zeitpunkt nicht mehr zugreifen) und ihre unterst\u00fctzenden Dienste (Gesch\u00e4ftslogik, Caches usw.), sondern auch verschiedene Datenbanken mit einem Replikationsfaktor von 2 oder mehr (Cassandra,<\/a><\/noindex>, Datenbinarienlager<\/a><\/noindex>, Kaltes Lager<\/a><\/noindex>, NewSQL<\/a><\/noindex> und mehr).
\n15:06. Es gibt Informationen, dass ein Feuer einen der R\u00e4ume des Rechenzentrums bedroht.<\/b> In diesem Raum haben wir keine Ausr\u00fcstung, aber die M\u00f6glichkeit, dass das Feuer von der Decke auf die R\u00e4ume \u00fcbergreift, ver\u00e4ndert drastisch die Situation.
\n(Sp\u00e4ter stellte sich heraus, dass keine physische Bedrohung f\u00fcr den Raum bestand, da er luftdicht vom Dach isoliert war. Die Bedrohung galt nur f\u00fcr das K\u00fchlsystem dieses Raumes.)
\n15:07. Wir erlauben die Ausf\u00fchrung von Befehlen auf den Servern im beschleunigten Modus ohne zus\u00e4tzliche \u00dcberpr\u00fcfungen (ohne unseren geliebten Rechner<\/a><\/noindex>).
\n15:08. Die Temperatur in den R\u00e4umen ist im Normbereich.
\n15:12. Ein Anstieg der Temperatur in den R\u00e4umen wurde festgestellt.<\/b>
\n15:13. Mehr als die H\u00e4lfte der Server im Rechenzentrum sind ausgeschaltet. Wir machen weiter.
\n15:16. Es wurde beschlossen, alle Ger\u00e4te abzuschalten.
\n15:21. Wir beginnen mit der Abschaltung der Stromversorgung an stateless-Servern ohne ordnungsgem\u00e4\u00dfe herunterfahren der Anwendungen und des Betriebssystems.
\n15:23. Eine Gruppe von Verantwortlichen f\u00fcr MS SQL wird gebildet (es sind nicht viele, die Abh\u00e4ngigkeit der Dienste von ihnen ist nicht gro\u00df, aber der Wiederherstellungsprozess ben\u00f6tigt mehr Zeit und ist komplizierter als zum Beispiel bei Cassandra).<\/p>\n

Depression<\/h4>\n

\n15:25. Es kam die Information \u00fcber die Abschaltung der Stromversorgung in vier R\u00e4umen von 16 (Nr. 6, 7, 8, 9).<\/b> In den R\u00e4umen 7 und 8 befindet sich unsere Hardware. \u00dcber zwei weitere unserer R\u00e4ume (Nr. 1 und 3) liegen keine Informationen vor.
\nNormalerweise wird die Stromversorgung bei Br\u00e4nden sofort abgeschaltet, doch in diesem Fall wurde sie dank der koordinierten Arbeit der Feuerwehr und des technischen Personals des Rechenzentrums nicht \u00fcberall und nicht sofort abgeschaltet, sondern nach Bedarf.
\n(Sp\u00e4ter stellte sich heraus, dass die Stromversorgung in den R\u00e4umen 8 und 9 nicht abgeschaltet wurde.)
\n15:28. Wir beginnen mit der Wiederherstellung der MS SQL-Datenbanken aus Backups in anderen Rechenzentren.
\nWie viel Zeit wird daf\u00fcr ben\u00f6tigt? Reicht die Bandbreite des Netzwerks f\u00fcr die gesamte Strecke aus?
\n15:37. Es wurde eine Unterbrechung einiger Netzwerkabschnitte festgestellt.<\/b>
\nDas Management und das Produktionsnetzwerk sind physisch voneinander isoliert. Wenn das Produktionsnetzwerk verf\u00fcgbar ist, k\u00f6nnen Sie auf den Server zugreifen, die Anwendung stoppen und das Betriebssystem ausschalten. Wenn es nicht verf\u00fcgbar ist, k\u00f6nnen Sie \u00fcber IPMI auf den Server zugreifen, die Anwendung stoppen und das Betriebssystem ausschalten. Wenn keines der Netzwerke verf\u00fcgbar ist, k\u00f6nnen Sie nichts tun. 'Danke, Captain!', denken Sie sich vielleicht.
\n'Ganz ehrlich, es ist irgendwie viel Aufregung', denken Sie sich m\u00f6glicherweise auch.
\nEs ist so, dass Server selbst ohne Feuer enorme Mengen W\u00e4rme erzeugen. Genauer gesagt, wenn K\u00fchlung vorhanden ist, erzeugen sie W\u00e4rme, und wenn sie keine K\u00fchlung haben, schaffen sie die H\u00f6lle, die im besten Fall einen Teil der Ausr\u00fcstung schmelzen und einen anderen Teil ausschalten kann, und im schlimmsten Fall... einen Brand im Raum ausl\u00f6sen kann, der praktisch alles zerst\u00f6rt.<\/p>\n

\"Sollten
\n
\n15:39. Wir dokumentieren Probleme mit der conf-Datenbank.<\/p>\n

Die conf-Datenbank ist das Backend f\u00fcr den gleichnamigen Service, der von allen Produktionsanwendungen f\u00fcr die sofortige \u00c4nderung von Einstellungen genutzt wird. Ohne diese Datenbank k\u00f6nnen wir den Betrieb des Portals nicht steuern, aber das Portal selbst kann trotzdem funktionieren.<\/p><\/blockquote>\n

\n15:41. Temperaturf\u00fchler an der Core-Netzwerkausr\u00fcstung erfassen Werte, die nahe an den zul\u00e4ssigen H\u00f6chstwerten liegen. Es handelt sich um ein Ger\u00e4t, das einen gesamten Rackplatz ausf\u00fcllt und den Betrieb aller Netzwerke innerhalb des Rechenzentrums sichert.<\/p>\n

\"Sollten
\n
\n15:42. Issue Tracker und Wiki sind nicht verf\u00fcgbar, wir schalten auf Standby.
\nDies ist keine Produktionsumgebung, aber im Falle eines Vorfalls kann die Verf\u00fcgbarkeit jeder Wissensdatenbank kritisch sein.
\n15:50. Eines der \u00dcberwachungssysteme hat sich abgeschaltet.
\nEs gibt mehrere, und sie sind f\u00fcr verschiedene Aspekte der Funktionsweise der Dienste verantwortlich. Ein Teil von ihnen ist so konfiguriert, dass er autonom in jedem Rechenzentrum arbeitet (das hei\u00dft, sie \u00fcberwachen nur ihr eigenes Rechenzentrum), andere bestehen aus verteilten Komponenten, die transparent den Ausfall eines beliebigen Rechenzentrums \u00fcberstehen.
\nIn diesem Fall ist ausgefallen das System zur Erkennung von Anomalien in der Gesch\u00e4ftslogik<\/a><\/noindex>, das im Master-Standby-Modus funktioniert. Wir haben auf Standby umgeschaltet.<\/p>\n

Entscheidung<\/h4>\n

\n15:51. \u00dcber IPMI wurden ohne ordnungsgem\u00e4\u00dfe Beendigung alle Server au\u00dfer MS SQL heruntergefahren.
\nSind Sie bereit f\u00fcr das Massamanagement von Servern \u00fcber IPMI im Bedarfsfall?<\/p>\n

Der Moment, in dem die Rettung der Ger\u00e4te im Rechenzentrum zu diesem Zeitpunkt abgeschlossen ist. Alles, was m\u00f6glich war, wurde getan. Einige Kollegen k\u00f6nnen sich ausruhen.<\/i>
\n16:13. Es gab Informationen, dass die Freonrohre der Klimaanlagen auf dem Dach geplatzt sind \u2014 das wird den Start des Rechenzentrums nach der Behebung des Brandes verz\u00f6gern.<\/b>
\n16:19. Laut Informationen des technischen Personals des Rechenzentrums hat der Temperaturanstieg in den R\u00e4umen aufgeh\u00f6rt.
\n17:10. Die Verf\u00fcgbarkeit der Konfigurationsdatenbank wurde wiederhergestellt. Jetzt k\u00f6nnen wir die Einstellungen der Anwendungen \u00e4ndern.
\nWarum ist das so wichtig, wenn alles ausfallsicher ist und selbst ohne ein Rechenzentrum funktioniert?
\nErstens ist nicht alles ausfallsicher. Es gibt verschiedene sekund\u00e4re Dienste, die die Ausf\u00e4lle eines Rechenzentrums bisher nicht gut \u00fcberstehen, und es gibt Datenbanken im Master-Standby-Modus. Die M\u00f6glichkeit, Einstellungen zu verwalten, erm\u00f6glicht es, alles Notwendige zu tun, um selbst unter schwierigen Bedingungen die Auswirkungen von St\u00f6rungen auf die Nutzer zu minimieren.
\nZweitens wurde klar, dass das Rechenzentrum in den n\u00e4chsten Stunden nicht vollst\u00e4ndig wiederhergestellt wird, deshalb mussten Ma\u00dfnahmen ergriffen werden, damit die langfristige Nichtverf\u00fcgbarkeit von Replikaten nicht zu weiteren Problemen wie der \u00dcberf\u00fcllung von Festplatten in den verbleibenden Rechenzentren f\u00fchrt.
\n17:29. Zeit f\u00fcr Pizza! Bei uns arbeiten Menschen, keine Roboter.<\/p>\n

\"Sollten
\n<\/p>\n

Rehabilitation<\/h4>\n

\n18:02. Die Temperatur in den R\u00e4umen Nummer 8 (unser), 9, 10 und 11 hat sich stabilisiert. In einem der R\u00e4ume, die weiterhin abgeschaltet sind (Nr. 7), befindet sich unsere Ausr\u00fcstung, und die Temperatur dort steigt weiter an.
\n18:31. Genehmigung zur Inbetriebnahme der Ausr\u00fcstung in den R\u00e4umen Nr. 1 und 3 \u2014 diese R\u00e4ume wurden von dem Feuer nicht betroffen.<\/p>\n

Derzeit werden Server in den R\u00e4umen Nr. 1, 3 und 8 gestartet, beginnend mit den kritischsten. Die Funktionsf\u00e4higkeit aller gestarteten Dienste wird \u00fcberpr\u00fcft. Im Raum Nr. 7 gibt es nach wie vor Probleme.<\/i><\/p>\n

18:44. Technisches Personal des Rechenzentrums stellte fest, dass im Raum Nr. 7 (in dem nur unsere Ger\u00e4te stehen) viele Server nicht abgeschaltet sind. Nach unseren Angaben bleiben dort 26 Server eingeschaltet. Nach einer erneuten \u00dcberpr\u00fcfung stellen wir fest, dass 58 Server aktiv sind.
\n20:18. Technisches Personal des Rechenzentrums bel\u00fcftet den Raum ohne Klimaanlage mit mobilen Luftkan\u00e4len, die durch die Flure verlegt sind.
\n23:08. Der erste Administrator wurde nach Hause entlassen. Jemand muss nachts schlafen, um morgen die Arbeiten fortzusetzen. Au\u00dferdem lassen wir weitere Administratoren und Entwickler nach Hause gehen.
\n02:56. Wir haben alles gestartet, was gestartet werden konnte. Wir f\u00fchren eine umfassende Pr\u00fcfung aller Dienste mit automatisierten Tests durch.<\/p>\n

\"Sollten
\n
\n03:02. Die Klimatisierung im letzten, 7. Raum wurde wiederhergestellt.
\n03:36. Die Fronten im Rechenzentrum wurden in die DNS-Rotation eingebunden. Ab diesem Moment beginnt der Benutzerverkehr hereinzukommen.
\nWir entlassen den Gro\u00dfteil des Administrator-Teams nach Hause. Aber einige Leute bleiben.<\/p>\n

Kleines FAQ:
\nQ: Was geschah zwischen 18:31 und 02:56?
\nA: Gem\u00e4\u00df dem \u201eNotfallma\u00dfnahmenplan\u201c starten wir alle Dienste, beginnend mit den wichtigsten. Dabei weist der Koordinator im Chat den Dienst einem verf\u00fcgbaren Administrator zu, der \u00fcberpr\u00fcft, 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\u00fcgbar ist, und erh\u00e4lt vom Koordinator einen neuen Dienst.
\nDer Prozess wird zus\u00e4tzlich durch ausgefallene Hardware verlangsamt. Selbst wenn das Stoppen des Betriebssystems und das Abschalten der Server korrekt durchgef\u00fchrt wurden, kehren einige Server aufgrund pl\u00f6tzlich ausgefallener Festplatten, Speicher oder Geh\u00e4use nicht zur\u00fcck. Bei einem Stromausfall steigt der Ausfallprozentsatz.
\nQ: Warum kann man nicht einfach alles auf einmal starten und dann beheben, was im Monitoring sichtbar wird?
\nA: Alles muss schrittweise erfolgen, da es Abh\u00e4ngigkeiten zwischen den Diensten gibt. Zudem sollte alles sofort \u00fcberpr\u00fcft werden, ohne auf das Monitoring zu warten \u2014 denn es ist besser, Probleme sofort zu l\u00f6sen, anstatt auf eine Versch\u00e4rfung zu warten.<\/p><\/blockquote>\n

\n7:40. Der letzte Administrator (Koordinator) ist schlafen gegangen. Die Arbeiten des ersten Tages sind abgeschlossen.
\n8:09. Die ersten Entwickler, Ingenieure in den Rechenzentren und Administratoren (einschlie\u00dflich des neuen Koordinators) haben mit den Wiederherstellungsarbeiten begonnen.
\n09:37. Wir haben mit dem Hochheben von Saal Nr. 7 (dem letzten) begonnen.
\nParallel setzen wir die Wiederherstellung dessen fort, was in anderen S\u00e4len nicht abgeschlossen wurde: Austausch von Festplatten\/Speicher\/Servern, Reparatur von allem, was in der \u00dcberwachung als 'kritisch' angezeigt wird, R\u00fcckumstellung der Rollen in den Master-Standby-Schemata und andere Kleinigkeiten, die dennoch zahlreich sind.
\n17:08. Wir erlauben alle regul\u00e4ren Arbeiten mit dem Produktionssystem.
\n21:45. Die Arbeiten des zweiten Tages sind abgeschlossen.
\n09:45. Heute ist Freitag. In der \u00dcberwachung gibt es nach wie vor viele kleine Probleme. Das Wochenende steht bevor, und alle m\u00f6chten sich ausruhen. Wir reparieren weiterhin massenhaft alles, was m\u00f6glich ist. Regulierungsaufgaben, die aufgeschoben werden konnten, sind aufgeschoben. Der Koordinator ist neu.
\n15:40. Pl\u00f6tzlich hat sich die H\u00e4lfte 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\u00fcr die Nutzer. Sp\u00e4ter stellte sich heraus, dass es ein fehlerhaftes Chassis war. Der Koordinator arbeitet an der Reparatur von gleich zwei Ausf\u00e4llen.
\n17:17. Die Netzwerkoperationen in einem anderen Rechenzentrum wurden wiederhergestellt, alles wurde \u00fcberpr\u00fcft. Das Rechenzentrum ist nun im Rotationseinsatz.
\n18:29. Die Arbeiten am dritten Tag und insgesamt die Wiederherstellung nach dem Vorfall sind abgeschlossen.<\/p>\n

Nachwort<\/h4>\n

\n04.04.2013, am Tag des 404-Fehlers<\/a><\/noindex>, \u201eOdnoklassniki\u201c erlebte den gr\u00f6\u00dften Vorfall<\/a><\/noindex> \u2014 der Portal war f\u00fcr drei Tage vollst\u00e4ndig oder teilweise nicht verf\u00fcgbar. W\u00e4hrend dieser gesamten Zeit haben \u00fcber 100 Personen aus verschiedenen St\u00e4dten und Unternehmen (nochmals vielen Dank!) tausende Server remote und direkt in den Rechenzentren, sowohl manuell als auch automatisch, repariert.
\nWir haben Lehren daraus gezogen. Um Wiederholungen zu vermeiden, haben wir umfassende Arbeiten durchgef\u00fchrt und setzen sie bis heute fort.<\/p>\n

Was sind die Hauptunterschiede zwischen dem aktuellen Vorfall und dem 404?<\/p>\n