{"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 Server abgeschaltet werden, wenn der Smoke-Test des Rechenzentrums \u201ealarmiert\u201c?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Was w\u00fcrden Sie f\u00fchlen, wenn an einem sch\u00f6nen Sommertag das Rechenzentrum mit Ihrer Ausr\u00fcstung so aussehen w\u00fcrde?<\/p>\n

\"Sollten
\n
\nHallo zusammen! Mein Name ist Dmitri Samsonov, ich arbeite als leitender Systemadministrator bei \u201eOdnoklassniki<\/a><\/noindex>\u201c. Auf dem Foto sehen Sie eines der vier Rechenzentren, in denen die Ausr\u00fcstung f\u00fcr unser Projekt installiert ist. Hinter diesen W\u00e4nden befinden sich etwa 4.000 Ger\u00e4te: Server, Speichersysteme, Netzwerkausr\u00fcstung usw. \u2013 fast ein Drittel unserer gesamten Ausr\u00fcstung.
\nDie meisten Server laufen mit Linux. Es gibt auch mehrere Dutzend Server mit Windows (MS SQL) \u2013 unser Erbe, von dem wir uns seit vielen Jahren schrittweise trennen.
\nAm 5. Juni 2019 um 14:35 Uhr berichteten die Ingenieure eines unserer Rechenzentren von einem Feueralarm.
\n<\/a><\/noindex><\/p>\n

Leugnung<\/h4>\n

\n14:45 Uhr. Kleinere Vorf\u00e4lle mit Rauchentwicklung in Rechenzentren passieren h\u00e4ufiger, als man denkt. Die Werte in den S\u00e4len waren normal, deshalb war unsere erste Reaktion relativ ruhig: wir haben die Arbeiten im Produktivbetrieb, also alle \u00c4nderungen an der Konfiguration und die Bereitstellung neuer Versionen usw. untersagt, au\u00dfer f\u00fcr Arbeiten zur Behebung von Problemen.<\/p>\n

Wut<\/h4>\n

\nHaben Sie jemals versucht, die Feuerwehr zu fragen, wo genau auf dem Dach das Feuer ausgebrochen ist, oder selbst auf das brennende Dach zu gelangen, um die Situation einzusch\u00e4tzen? Wie hoch w\u00e4re das Vertrauen in Informationen, die \u00fcber f\u00fcnf Personen weitergeleitet wurden?<\/p>\n

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

Derzeit sind die Fronten aller unserer Dienste in drei Rechenzentren redundant, es wird ein DNS-Level-Balancing verwendet, was es erm\u00f6glicht, die Adressen eines Rechenzentrums aus dem DNS zu entfernen und somit die Benutzer vor potenziellen Problemen mit dem Zugriff auf die Dienste zu sch\u00fctzen. Falls im Rechenzentrum bereits Probleme aufgetreten sind, wird es automatisch aus der Rotation entfernt. Mehr dazu k\u00f6nnen Sie hier lesen: Lastverteilung und Ausfallsicherheit bei \u201eOdnoklassniki\u201c.<\/a><\/noindex><\/p><\/blockquote>\n

\nBisher hat das Feuer uns nicht beeinflusst \u2013 weder Benutzer noch Ausr\u00fcstung wurden besch\u00e4digt. Handelt es sich um einen Notfall? Der erste Abschnitt des Dokuments \u201eNotfallaktionsplan\u201c definiert den Begriff \u201eNotfall\u201c und endet mit den Worten:
\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 Koordinator f\u00fcr den Notfall wird ernannt.<\/p>\n

Der Koordinator ist die Person, die die Kommunikation zwischen allen Beteiligten koordiniert, das Ausma\u00df des Notfalls bewertet, den \u201eNotfallaktionsplan\u201c anwendet, das erforderliche Personal einbezieht, die Beendigung der Reparatur \u00fcberwacht und vor allem Aufgaben delegiert. Mit anderen Worten, es ist die Person, die den gesamten Prozess der Notfallbew\u00e4ltigung managt.<\/p><\/blockquote>\n

<\/p>\n

Auktion<\/h4>\n

\n15:01. Wir beginnen mit dem Ausschalten der Server, die nicht mit der Produktion verbunden sind.
\n15:03. Wir schalten alle reservierten Dienste ordnungsgem\u00e4\u00df aus.
\nHierzu geh\u00f6ren nicht nur die Frontends (auf die zu diesem Zeitpunkt keine Benutzer mehr zugreifen), sowie ihre unterst\u00fctzenden Dienste (Gesch\u00e4ftslogik, Caches usw.), sondern auch verschiedene Datenbanken mit einem Replikationsfaktor von 2 und mehr (Cassandra<\/a><\/noindex>, Speicher f\u00fcr Bin\u00e4rdaten<\/a><\/noindex>, kalter Speicher<\/a><\/noindex>, NewSQL<\/a><\/noindex> und andere).
\n15:06. Es gab Informationen, dass ein Feuer einen der S\u00e4le des Rechenzentrums bedroht.<\/b> In diesem Saal haben wir keine Ausr\u00fcstung, aber die M\u00f6glichkeit, dass das Feuer vom Dach auf die S\u00e4le \u00fcbergreift, \u00e4ndert die gesamte Situation erheblich.
\n(Sp\u00e4ter stellte sich heraus, dass es keine physische Bedrohung f\u00fcr den Saal gab, da er hermetisch vom Dach isoliert ist. Die Bedrohung bestand nur f\u00fcr das K\u00fchlsystem dieses Saals.)
\n15:07. Wir erlauben die Ausf\u00fchrung von Befehlen auf den Servern in beschleunigtem Modus ohne zus\u00e4tzliche Pr\u00fcfungen (ohne unseren Lieblingsrechner<\/a><\/noindex>).
\n15:08. Die Temperatur in den S\u00e4len liegt im normalen Bereich.
\n15:12. Es wurde ein Anstieg der Temperatur in den S\u00e4len festgestellt.<\/b>
\n15:13. Mehr als die H\u00e4lfte der Server im Rechenzentrum ist abgeschaltet. Wir machen weiter.
\n15:16. Es wurde beschlossen, die gesamte Ausr\u00fcstung abzuschalten.
\n15:21. Wir beginnen, die Stromversorgung der zustandslosen Server ohne korrekte Abschaltung der Anwendung und des Betriebssystems auszuschalten.
\n15:23. Eine Gruppe von Verantwortlichen f\u00fcr MS SQL wird gebildet (es gibt nur wenige von ihnen, die Abh\u00e4ngigkeit der Dienste von ihnen ist nicht gro\u00df, aber das Verfahren zur Wiederherstellung der Betriebsf\u00e4higkeit dauert l\u00e4nger und ist komplizierter als beispielsweise bei Cassandra).<\/p>\n

Depression<\/h4>\n

\n15:25. Es gab Informationen \u00fcber die Abschaltung der Stromversorgung in vier S\u00e4len von 16 (Nr. 6, 7, 8, 9).<\/b> In den S\u00e4len 7 und 8 befindet sich unsere Ausr\u00fcstung. \u00dcber zwei weitere S\u00e4le von uns (Nr. 1 und 3) liegen keine Informationen vor.
\nNormalerweise wird bei Br\u00e4nden die Stromversorgung sofort abgeschaltet, aber in diesem Fall wurde sie dank der koordinierten Arbeit der Feuerwehr und des technischen Personals des Rechenzentrums nicht \u00fcberall und nicht sofort, sondern nach Bedarf abgeschaltet.
\n(Sp\u00e4ter stellte sich heraus, dass die Stromversorgung in den Hallen 8 und 9 nicht unterbrochen 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 auf der gesamten Strecke aus?
\n15:37. Es wurde eine Unterbrechung einiger Netzwerksegmente festgestellt.<\/b>
\nDas Management-Netzwerk 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 OS ausschalten. Wenn es nicht verf\u00fcgbar ist, k\u00f6nnen Sie \u00fcber IPMI auf den Server zugreifen, die Anwendung stoppen und das OS ausschalten. Wenn keines der Netzwerke funktioniert, k\u00f6nnen Sie nichts tun. \u201eDanke, Kapit\u00e4n!\u201c, werden Sie sich denken.
\n\u201eUnd \u00fcberhaupt, das ist ja ganz sch\u00f6n viel Aufregung\u201c, denken Sie vielleicht auch.
\nDie Sache ist die, dass Server, selbst ohne Feuer, eine enorme Menge an W\u00e4rme erzeugen. Genauer gesagt, wenn K\u00fchlung vorhanden ist, erzeugen sie W\u00e4rme, und wenn keine K\u00fchlung vorhanden ist, schaffen sie die H\u00f6lle, die im besten Fall einen Teil der Hardware schmelzen und einen anderen Teil abschalten kann, und im schlimmsten Fall\u2026 einen Brand im Raum ausl\u00f6st, der praktisch garantiert alles zerst\u00f6rt.<\/p>\n

\"Sollten
\n
\n15:39. Wir stellen Probleme mit der Konfigurationsdatenbank fest.<\/p>\n

Die Konfigurationsdatenbank ist das Backend f\u00fcr den gleichnamigen Dienst, der von allen Produktionsanwendungen zur sofortigen \u00c4nderung von Einstellungen verwendet wird. Ohne diese Datenbank k\u00f6nnen wir die Portalnutzung nicht steuern, aber das Portal selbst kann weiterhin funktionieren.<\/p><\/blockquote>\n

\n15:41. Die Temperatursensoren am Core-Netzwerkger\u00e4t zeigen Werte, die nahe an den maximal zul\u00e4ssigen Werten liegen. Das ist ein Kasten, der eine ganze Rack-Einheit einnimmt und den Betrieb aller Netzwerke im Rechenzentrum sicherstellt.<\/p>\n

\"Sollten
\n
\n15:42. Issue Tracker und Wiki sind nicht verf\u00fcgbar, wir schalten auf Standby um.
\nDas ist kein Produktionsnetzwerk, aber bei einem Ausfall kann die Verf\u00fcgbarkeit jeder Wissensdatenbank kritisch sein.
\n15:50. Eines der \u00dcberwachungssysteme ist ausgefallen.
\nEs gibt mehrere, und sie sind f\u00fcr verschiedene Aspekte des Betriebs der Dienste verantwortlich. Einige davon sind auf einen autarken Betrieb innerhalb jedes Rechenzentrums eingestellt (d. h. sie \u00fcberwachen nur ihr Rechenzentrum), andere bestehen aus verteilten Komponenten, die transparent den Verlust eines beliebigen Rechenzentrums \u00fcberstehen.
\nIn diesem Fall hat das System zur Erkennung von Anomalien in den Gesch\u00e4ftsdaten<\/a><\/noindex>, das im Master-Standby-Modus arbeitet, aufgeh\u00f6rt zu funktionieren. Wir sind auf Standby umgeschaltet.<\/p>\n

Abschluss<\/h4>\n

\n15:51. \u00dcber IPMI haben wir alle Server ohne ordnungsgem\u00e4\u00dfe Beendigung der Arbeiten ausgeschaltet, mit Ausnahme von MS SQL.
\nSind Sie bereit, die Server im Falle eines Bedarfs \u00fcber IPMI massenhaft zu verwalten?<\/p>\n

Der Moment, in dem die Rettung der Ausr\u00fcstung im Rechenzentrum an dieser Stelle abgeschlossen ist. Alles, was getan werden konnte, wurde getan. Einige Kollegen k\u00f6nnen sich ausruhen.<\/i>
\n16:13. Es wurde informiert, dass auf dem Dach die K\u00fchlmittelrohre der Klimaanlagen geplatzt sind \u2013 dies wird den Start des Rechenzentrums nach der Brandbek\u00e4mpfung verz\u00f6gern.<\/b>
\n16:19. Laut Informationen des technischen Personals des Rechenzentrums hat die Temperatur in den R\u00e4umen zu steigen aufgeh\u00f6rt.
\n17:10. Die Arbeit der Datenbank conf wurde wiederhergestellt. Jetzt k\u00f6nnen wir die Einstellungen der Anwendungen \u00e4ndern.
\nWarum ist das so wichtig, wenn alles ausfallsicher ist und auch ohne ein Rechenzentrum funktioniert?
\nErstens, nicht alles ist ausfallsicher. Es gibt verschiedene sekund\u00e4re Dienste, die bisher nicht gut genug mit dem Ausfall eines Rechenzentrums umgehen k\u00f6nnen, und es gibt Datenbanken im Master-Standby-Modus. Die M\u00f6glichkeit, die Einstellungen zu verwalten, erm\u00f6glicht es, alles Notwendige zu tun, um selbst unter schwierigen Bedingungen die Auswirkungen einer St\u00f6rung auf die Benutzer zu minimieren.
\nZweitens wurde klar, dass die Arbeit des Rechenzentrums in den n\u00e4chsten Stunden nicht vollst\u00e4ndig wiederhergestellt wird, daher mussten Ma\u00dfnahmen ergriffen werden, damit die langfristige Unzug\u00e4nglichkeit der Replikate nicht zu weiteren unangenehmen \u00dcberraschungen wie Festplattenspeicher\u00fcberl\u00e4ufen 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. In den R\u00e4umen Nr. 8 (unser), 9, 10 und 11 hat sich die Temperatur stabilisiert. In einem der ausgeschalteten R\u00e4ume (Nr. 7) befindet sich unsere Ausr\u00fcstung, und die Temperatur dort steigt weiter.
\n18:31. Wir haben gr\u00fcnes Licht f\u00fcr den Start der Ausr\u00fcstung in den R\u00e4umen Nr. 1 und 3 gegeben \u2013 diese R\u00e4ume wurden nicht vom Feuer betroffen.<\/p>\n

Derzeit wird der Start der Server in den R\u00e4umen Nr. 1, 3, 8 durchgef\u00fchrt, beginnend mit den kritischsten. Die Funktionsf\u00e4higkeit aller gestarteten Dienste wird \u00fcberpr\u00fcft. Es gibt weiterhin Probleme mit dem Raum Nr. 7.<\/i><\/p>\n

18:44. Das technische Personal des Rechenzentrums hat festgestellt, dass in Raum Nr. 7 (wo nur unsere Ausr\u00fcstung steht) viele Server nicht abgeschaltet sind. Nach unseren Informationen sind dort 26 Server eingeschaltet. Nach einer erneuten \u00dcberpr\u00fcfung stellen wir 58 Server fest.
\n20:18. Das technische Personal des Rechenzentrums bl\u00e4st die Luft in den Raum ohne Klimaanlagen \u00fcber mobile Luftkan\u00e4le, die durch die Flure verlegt wurden.
\n23:08. Der erste Administrator wurde nach Hause geschickt. Jemand muss nachts schlafen, um morgen mit den Arbeiten fortzufahren. Dann lassen wir noch einige Administratoren und Entwickler nach Hause gehen.
\n02:56. Wir haben alles gestartet, was gestartet werden konnte. Wir f\u00fchren eine umfassende \u00dcberpr\u00fcfung aller Dienste mit automatisierten Tests durch.<\/p>\n

\"Sollten
\n
\n03:02. Die Klimaanlage im letzten, 7. Raum wurde wiederhergestellt.
\n03:36. Wir haben die Fronten im Rechenzentrum in DNS rotieren lassen. Ab diesem Moment beginnt der Benutzerverkehr zu flie\u00dfen.
\nWir entlassen den Gro\u00dfteil des Administratorenteams nach Hause. Aber einige Personen bleiben.<\/p>\n

Kleines FAQ:
\nQ: Was geschah von 18:31 bis 02:56?
\nA: Gem\u00e4\u00df dem 'Notfallplan' starten wir alle Dienste, beginnend mit den wichtigsten. Dabei teilt der Koordinator im Chat einen Dienst einem freien Administrator zu, der \u00fcberpr\u00fcft, ob das OS und die Anwendung gestartet wurden, ob es Fehler gibt und ob die Werte in Ordnung sind. Nach Abschluss des Starts informiert er den Chat, dass er frei ist, und erh\u00e4lt vom Koordinator einen neuen Dienst.
\nDer Prozess wird zus\u00e4tzlich durch ausgefallene Hardware verlangsamt. Selbst wenn das Stoppen des OS und das Ausschalten der Server korrekt durchgef\u00fchrt wurden, kehren einige Server aufgrund pl\u00f6tzlich ausgefallener Festplatten, Speicher oder Geh\u00e4use nicht zur\u00fcck. Bei Stromausfall erh\u00f6ht sich die Ausfallquote.
\nQ: Warum kann man nicht einfach alles auf einmal starten und dann das reparieren, was im Monitoring auftaucht?
\nA: Alles muss schrittweise erfolgen, da zwischen den Diensten Abh\u00e4ngigkeiten bestehen. Und man sollte alles sofort \u00fcberpr\u00fcfen, ohne auf das Monitoring zu warten \u2014 denn Probleme sollte man sofort l\u00f6sen, um deren Versch\u00e4rfung zu vermeiden.<\/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 der Wiederherstellung des Raumes Nr. 7 (des letzten) begonnen.
\nParallel dazu setzen wir die Wiederherstellung dessen fort, was in anderen R\u00e4umen nicht fertiggestellt wurde: Austausch von Festplatten\/Speicher\/Servern, Reparatur von allem, was im Monitoring 'brennt', R\u00fcckschaltung der Rollen in den Master-Standby-Schemata und andere Kleinigkeiten, von denen es dennoch genug gibt.
\n17:08. Wir genehmigen alle regul\u00e4ren Arbeiten mit der Produktion.
\n21:45. Die Arbeiten des zweiten Tages sind abgeschlossen.
\n09:45. Heute ist Freitag. Im Monitoring gibt es nach wie vor zahlreiche kleine Probleme. Das Wochenende steht vor der T\u00fcr, jeder m\u00f6chte sich ausruhen. Wir setzen die umfangreichen Reparaturen aller m\u00f6glicher Komponenten fort. Die administrativen Aufgaben, die aufgeschoben werden konnten, sind aufgeschoben. Ein neuer Koordinator ist im Einsatz.
\n15:40. Pl\u00f6tzlich hat sich die H\u00e4lfte des Stacks der Core-Netzwerkausr\u00fcstung in einem ANDEREN Rechenzentrum neu gestartet. Wir haben die Frontends aus dem Betrieb genommen, um Risiken zu minimieren. Die Nutzer haben keine Auswirkungen versp\u00fcrt. Sp\u00e4ter stellte sich heraus, dass es sich um ein fehlerhaftes Chassis handelte. Der Koordinator arbeitet daran, gleich zwei St\u00f6rungen zu beheben.
\n17:17. Der Netzbetrieb im anderen Rechenzentrum wurde wiederhergestellt, alles wurde \u00fcberpr\u00fcft. Das Rechenzentrum wurde wieder in den Betrieb genommen.
\n18:29. Die Arbeiten des dritten Tages und die allgemeine Wiederherstellung nach dem Vorfall sind abgeschlossen.<\/p>\n

Nachwort<\/h4>\n

\n04.04.2013, am Tag des 404-Fehlers<\/a><\/noindex>, \"Od\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0438\" erlebte den gr\u00f6\u00dften Ausfall<\/a><\/noindex> \u2014 w\u00e4hrend drei Tagen war das Portal vollst\u00e4ndig oder teilweise nicht verf\u00fcgbar. In dieser Zeit haben \u00fcber 100 Personen aus verschiedenen St\u00e4dten, aus verschiedenen Unternehmen (nochmals vielen Dank!), remote und direkt in den Rechenzentren, manuell und automatisch tausende Server repariert.
\nWir haben Lehren daraus gezogen. Damit sich so etwas nicht wiederholt, haben wir umfassende Ma\u00dfnahmen ergriffen und setzen diese bis heute fort.<\/p>\n

Was sind die Hauptunterschiede des aktuellen Vorfalls im Vergleich zum 404?<\/p>\n