[LL BLOG] - EINE SCHRITT-FÜR-SCHRITT BESCHREIBUNG DER DOWNTIME VON 23.8
Linden Lab am 24.08.2016 um 12:01pm PDT
(21:01 Uhr MESZ) - Blogübersetzung -
Hallo allerseits!
Wie viele Einwohner mitbekommen haben,
hatten wir gestern (23. August) einen ziemlich harten Tag im Grid.
Ich will mir ein paar Minuten Zeit nehmen und erklären, was passiert
ist. Alle Zeiten in diesem Blogbeitrag werden in Pazifik Zeit
angegeben, auch bekannt als SLT. (Anm.: Ich gebe hier nicht
zusätzlich die MESZ an. Einfach immer neun Stunden dazu zählen.)
Kurz nach 10:30 Uhr, stürzte der
Master-Knoten von einer der zentralen Datenbanken ab. Dies war die
gleiche Ursache eines Absturzes, die wir schon einmal erlebt hatten
und wir haben es auch auf die gleiche Weise behandelt. Wir haben eine
Vielzahl von Diensten heruntergefahren (einschließlich der
Anmeldungen) und so konnten wir die Dienste dann wieder in einer
geordneten Reihenfolge starten, um danach umgehend einen neuen
Master-Knoten auszuwählen und ihn die Dienstkette einzufügen. Das
dauerte etwa eine Stunde, wie gewöhnlich auch.
Wenige Minuten vor 11.30 Uhr, begannen
wir mit dem Prozess, alle Dienstleistungen für das Grid
wiederherzustellen. Als wir die Anmeldungen wieder aktivierten, haben
wir das nach unserer üblichen Methode gemacht - wir haben etwa die
Hälfte der Server auf einmal eingeschaltet. Normalerweise
funktioniert das als kontrolliertes Hochfahren ziemlich gut, aber in
diesem Fall befanden wir uns gerade in einem sehr belebten Abschnitt
des Tages. Der Bedarf an Anmeldungen war sehr hoch und die Anzahl der
Bewohner, die zur gleichen Zeit versucht haben, sich einzuloggen, war
höher als der neue Master-Datenbankknoten verkraften konnte.
Gegen Mittag haben wir dann den Auftrag
zum erneuten Schließen der Logins veranlasst und dem System die
Gelegenheit gegeben, sich abzukühlen. Während wir darauf warteten,
dass sich die Sache langsam beruhigte, haben wir versucht
herauszufinden, was an diesem Fehler so einzigartig war und was wir
tun müssen, um ihn beim nächsten Mal vermeiden.
Wir haben dann erneut versucht, um etwa
12:30 Uhr jeweils ein Drittel der Login-Server auf einmal zu
aktivieren, aber auch das war wieder zu viel. Wir mussten diesen
Versuch erneut stoppen und alle Logins um 13:00 Uhr wieder schließen.
Bei unserem dritten Versuch, den wir
gestartet haben, nachdem das System wieder abgekühlt war, haben wir
es dann wirklich langsam angehen lassen und schalteten jeden
Login-Server nacheinander einzeln wieder ein. Das funktionierte und
alles war gegen 14:30 Uhr wieder normal.
Mein Team versucht herauszufinden,
warum wir die Login-Server viel langsamer als in der Vergangenheit
zurückbringen mussten. Wir sind immer noch nicht sicher, warum das
der Fall war. Es ist eine ziemlich interessante Herausforderung und
das Lösen von harten Problemen ist Teil des Spaßes beim Betreiben
von Second Life.
Die Sprachdienste sind ebenfalls zu
dieser Zeit ausgefallen, aber aus einem völlig anderen Grund. Es war
einfach nur Pech und schlechtes Timing.
Einen Lichtblick hatten wir aber auch!
Unser Status Blog hat die Last von tausenden Bewohnern, die alle
gleichzeitig die Seite aufgerufen haben, viel besser bewältigt als
zuvor. Wir wissen, dass es nicht perfekt war, aber es zeigte eine
deutliche Verbesserung gegenüber dem letzten zentralen
Datenbank-Fehler und wir werden weiter an einer Verbesserung
arbeiten.
Mein Team nimmt die Stabilität von
Second Life sehr ernst und dieser Ausfall tut uns leid. Wir haben
jetzt ein neues, herausforderndes Problem zu lösen und wir sind
bereits dabei.
April Linden
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
Kommentare
Kommentar veröffentlichen