Servicestörungen

/de

Second Life ist ein komplexes System mit vielen Komponenten, die miteinander interagieren, von den Simulatoren und Datenbanken zu dem Viewer, den Sie am Laufen haben und den Internetverbindungen, über welche die Daten fliessen. Obwohl es als so lose gekoppelt wie möglich und robust gegen Probleme ausgedacht ist, können immer noch Ereignisse auftreten, die zu Störungen bei den Diensten führen.

In manchen Fällen befinden sich die Fehler außerhalb der Kontrolle von Linden Lab. Allerdings wird in fast allen Fällen aktiv daran gearbeitet, Störungen abzuschwächen - entweder sie gar nicht auftreten zu lassen oder die Auswirkung beträchtlich zu reduzieren.

Wenn eine Störung auftritt, tritt normalerweise folgender Ablauf in Kraft:

• ein System hört auf, zu reagieren
• automatische Mitteilungen gehen los, die unser Team, das für den Betrieb verantwortlich ist (Operationsteam), alarmieren
• Oft werden Residents sofort informiert und der inworld Support alarmiert, der unserem Operationsteam das Problem bestätigt
• das Operationsteam erkennt das System, das die Ursache des Problems ist
• das Kommunikationsteam wird benachrichtigt und darum gebeten, die Information über die Störung im Blog bereitzustellen
• wenn die Störung länger als ein paar Minuten dauert, wird das Blog regelmässig aktualisiert
• wenn das Problem dann einmal gelöst ist, wird eine "Alles Klar" Meldung im Blog veröffentlicht

Bitte beachten Sie, daß in vielen Fällen eine Störung behoben sein kann, bevor es möglich ist, eine Information im Blog zu veröffentlichen, um die Einzelheiten des Problems zu erklären. Ein Zweck dieses Dokumentes ist es, ein "Dokumentationszentrum" für Arten von Störungen in den Diensten bereitzustellen, damit das Blogposting sich auf diese Seite beziehen kann, wenn sich ein Systemfehler ereignet.

Zum Zeitpunkt der Erstellung dieses Dokumentes und in keiner besonderen Reihenfolge, sind das die Systeme, von denen bekannt wurde, dass sie Störungen in den Diensten auslösen:

Assetspeichercluster

Was es ist: Ein Cluster von Maschinen, die einen riesigen WebDAV (stellen Sie sich eine "webbasierte Festplatte" vor) Speichermechanismus mit Terabytes von Platz zum Speichern von Beständen, einschliesslich hochgeladener Texturen, Snapshots, Skripten, Objekten, die ins Inventar aufgenommen wurden, Skriptzuständen, gespeicherten Zuständen von Regionen (Simstates), usw., die Second Life ausmachen. Die Technologie dafür (Software und Hardware) ist von einem Drittanbieter lizenziert.

Wie ein Fehler auftreten kann: Das System sollte gegen Ausfälle einzelner Knoten robust sein. In dem Fall dass mehrere Festplatten ausfallen, bei Softwareaktualisierungen, beim Entfernen fehlerhafter Knoten oder dem Hinzufügen neuer Knoten können einige oder alle der Cluster offline gehen. Wenn das passiert, scheitern das Hoch- und Herunterladen von Beständen - das führt dazu, dass Uploads von Texturen und das Abspeichern von Simstates fehlschlagen. Weil die vorübergehenden Daten beim Überqueren von Regionen (Zustände von Attachmants usw.) als Assets weggeschrieben werden, wird oft auch das Überqueren von Regionen scheitern.

Wie wir das beheben: Wenn dieser Fehler festgestellt wird, schalten wir oft die Logins ab und schicken inworld eine Nachricht (wenn möglich), um dabei zu helfen, Datenverluste zu vermeiden. Knoten, bei denen Fehler auftraten, können aus der Rotation genommen werden. Ein Neustart von anderen Knoten kann notwendig sein. Wenn die Software auf den Knoten aktualisiert wird, ist der Grid normalerweise geschlossen, um Datenverluste während irgendwelchen ungewollten Ausfällen zu verhindern. Ein Fehler im Assetsystem, der einen Neustart erforderlich machte, trat am 28. März 2008(en) und am 14. Mai 2008(en) auf.

Zentraler Datenbankcluster

Was es ist: Ein Cluster von Datenbanken, der die grundlegenden, gleichbleibenden Informationen über Second Life speichert - einschliesslich den Profilen von Residents, Gruppen, Regionen, Grundstücke, L$ Transaktionen und Kleinanzeigen.

Wie ein Fehler auftreten kann: Die Datenbank kann während dem Normalbetrieb ausgelastet werden, sodass ein Teil von Transaktionen fehlschlägt und entweder von Hand erneut versucht werden muss oder automatisch erneut versucht werden. Hardwareausfälle oder Softwarefehler im Programmcode der Datenbank können auch dazu führen, daß die Datenbank abstürzt oder aufhört, zu reagieren. Logins werden fehlschlagen, Transaktionen inworld und auf der Website werden scheitern und so weiter.

Wie wir das beheben: Wenn die primäre Datenbank ausfällt, wechseln wir auf eine der sekundären. Wenn die Belastung der Datenbank zu hoch ist, sie aber nicht ausgefallen ist, können wir Dienste abschalten, um zu versuchen, die Belastung zu reduzieren.

Das Eliminieren dieses Clusters als Flaschenhals bei der Skalierbarkeit und Ausfallpunkt hat eine sehr hohe Priorität für Linden Lab. Während das in Arbeit ist, tritt eine Abmilderung der Belastung auf. Behaltet das Second Life Blog(en) im Auge, um aktuelle Informationen zu bekommen

Agenten- ("Inventar-") Datenbankcluster

Was es ist: Speicher für die meisten agentenspezifischen Daten wie den Inventarbaum ist über eine Reihe von Datenbanken verteilt. Jeder Agent ist einem bestimmten Inventarspeicherbereich (einer primären Datenbank und ihren sekundären Sicherungen) zugeordnet. Zum Zeitpunkt, als dieses Dokument geschrieben wird, haben wir ungefähr 15 Speicherbereiche für Agentendatenbanken.

Die ursprüngliche Verwendung dieser nach Agenten unterteilten Datenbanken war für das Inventar, so dass sie von Lindens oft als "Inventardatenbanken" bezeichnet werden, aber das ist nicht mehr länger ein Ausdruck dafür, welche agentenspezifischen Daten in ihnen gespeichert werden.

Wie ein Fehler auftreten kann: Hardware- oder Softwareausfälle können die primäre Datenbank innerhalb eines Speicherbereiches beeinflussen, sodass sie entweder nicht mehr auf Anfragen reagiert oder überaus langsam wird.

Wie wir das beheben: Wenn eine Agentendatenbank ausfällt, können wir auf die Sicherung innerhalb dieses Speicherbereiches umschalten, was einige Minuten dauert. Wenn das nicht sofort passiert oder wenn Probleme festgestellt werden, wird dieser bestimmte Agentenspeicherbereich vorübergehend "auf eine schwarze Liste gesetzt"; das führt dazu, daß Logins von Agents, die diesem Speicherbereich zugeordnet sind, blockiert werden und alle eingeloggten Agents "gekickt" werden, während die Behebung des Fehlers in Arbeit ist. Das beeinträchtigt einige Teile des Grids, aber nicht jeden.

Das ist ein Beispiel für ein System, das in der Vergangenheit dafür bekannt war, eine globale Störung der Dienste auszulösen. Es wurde neu entworfen, um die Auswirkung auf die Residents auch in Anbetracht eines Hardwareausfalles zu begrenzen; nur Residents, die einem bestimmten Speicherbereich zugeordnet sind, werden während eines solchen Ausfalles beeinträchtigt

Andere Datenbankcluster

Was es ist: Es gibt eine Handvoll weiterer Datenbankcluster, die in Verwendung sind. Einer davon wird für die Logdateien (Protokolldateien) verwendet.

Wie ein Fehler auftreten kann: Hardware- oder Softwareausfälle können einen Datenbankcluster dazu bringen, offline zu gehen. Es sollten keine Auswirkungen inworld davon zu spüren sein, wenn einer dieser Datenbankcluster ausfällt, aber gelegentlich führt eine Unaufmerksamkeit im Softwareentwurf zu einer Abhängigkeit, die nicht abgefangen wird. Zum Beispiel haben Logins üblicherweise eine erfolgreiche Verbindung zu der Logindatenbank erfordert, um die Login- und Viewerstatistik aufzuzeichnen, aber diese Abhängigkeit wurde entfernt.

Wie wir das beheben: Alle Datenbanken in Clustern laufen auf einer Primärmaschine und verschiedenen Sekundärmaschinen. Im Fall eines Fehlers kann eine Sekundärmaschine an die Stelle der Primärmaschine gesetzt werden.

Unser Datawarehousing Team hat innerhalb des letzten Jahres eine bedeutende Arbeit geleistet, um sicherzustellen, dass die ständig anwachsende Menge an Daten über die Performance von Simulatoren und anderen Systemen, die aufgezeichnet werden, analysiert werden kann und dass die Sammlung dieser Daten "transparent" für die anderen Systeme geschieht - der Ausfall von Protokolldatenbanken sollte nicht mehr länger zu Ausfällen der Dienste führen.

Dienste für vorübergehende Daten

Was es ist: Ein Cluster von Maschinen (derzeit: 16), die Daten im Gedächtnis halten, die "flüchtiger" Natur sind. Das beinhaltet Dinge wie die Gegenwart von Agents ("Wer ist eingeloggt?"), Teilnahme an Gruppenchats, die Umsetzung von eingehenden Emails in Skripten und so weiter. Diese Daten werden nicht in einer Datenbank gespeichert und werden entweder ständig aufgefrischt (zum Beispiel aktualisiert der Simulator alle paar Minuten die Gegenwart von Agents) oder aber wiederherstellbar (zum Beispiel durch das erneute Aufrufen eines Gruppenchats).

Wie ein Fehler auftreten kann: Hardwareausfälle können das Fassungsvermögen dieser Maschinen vermindern oder sie auch komplett offline nehmen. Softwarefehler können auch eine sehr schwache Performance verursachen - zum Beispiel führt ein Speicherleck in einem Dienst dazu, daß die Dienste insgesamt anfangen, langsam zu reagieren. Wenn ein bestimmter Dienst unterbrochen ist, werden die anderen Dienste insgesamt weiterhin funktionsfähig bleiben.

Wie wir das beheben: Weil der Status vorübergehend und flüchtig ist, kann eine Ersatzmaschine schnell online gebracht werden und die Daten "heilen" sich selbst mit der Zeit. Wenn der Fehler softwareseitig ist, können die Dienste einfach mit wenig Auswirkungen für die Residents neu gestartet werden, sobald eine Fehlerbehebung für das Problem gefunden ist.

Simulatoren

Was es ist: Eine sim(en) ist eine Maschine, auf der Simulatoren(en) laufen, welche wiederum Computerprozesse sind, auf denen Regionen(en) laufen. (Stellen Sie sich eine Region wie ein Dokument vor, den Simulator wie ein Textverarbeitungsprogramm und die Sim als den Computer selbst, auf dem das Programm läuft.) Weil es sich dabei um eng verwandte Konzepte handelt, tendiert der Jargon/die Terminologie und Ausdrucksweise dazu, etwas unklar zu sein, zum Beispiel sollte der "Simstatus" in Wirklichkeit "Status der Region" sein. Der Simulator teilt seine Zeit auf die Kommunikation mit Viewern, die Kommunikation mit anderen Systemkomponenten, das Simulieren von physikalischen Vorgängen und das Ausführen von Skripten auf.

Wie ein Fehler auftreten kann: Ein Fehler im Programmcode des Simulators kann einen Absturz verursachen. Die meisten Abstürze führen dazu, daß der Simstatus einer Region abgespeichert wird und ein anderer Simulator diesen Simstatus nach ein paar Minuten laden wird. Oft wird der Fehler auch durch einige bestimmte Arten von Inhalten einer Region ausgelöst - einem Skript oder einem physikalischen Objekt.

Andere Probleme teilen sich in zwei Kategorien auf - Probleme mit einer bestimmten Sim oder gridweite Probleme. Probleme mit einer bestimmten Sim können aus einer Überlastung (zum Beispiel 4 Regionen mit hohem Traffic auf einer Sim) oder Fehlern (Speicherplatz erschöpft, Netzwerkkarte verloren, Hardwarefehler) bestehen. Gridweite Probleme sind gewöhnlich durch andere Faktoren ausgelöst, als sie hier aufgelistet sind, so zum Beispiel Verlust der Netzwerkanbindung oder Datenbankfehler oder Fehler im Assetcluster (welche zum Beispiel dazu führen können, dass Simulatoren daran gehindert werden, Simstati zu laden. Neue Programmcodes für die Simulatoren bringen manchmal Fehler mit gridweiten Auswirkungen ein (zum Beispiel verursacht übermässiges Protokollieren eine Überlastung durch den Netzwerkverkehr.)

Wie wir das beheben: Simulatorabstürze werden genauso wie Viewerabstürze berichtet. Wir können die Daten dazu nutzen, das grundlegende Untersystem festzulegen, das den Absturz ausgelöst hat (die Initialisierung, Physikengine, Skripte, Nachrichtenübermittlung usw.). Wenn der Absturz durch Inhalte (Skripten oder physikalische Objekte) ausgelöst wurde, können wir die Absturzdaten dazu verwenden, festzustellen, warum er aufgetreten ist. In der Zwischenzeit (da eine Fehlerbehebung auch einige Tage dauern kann oder im Fall von Problemen mit der Physikengine ein Projekt wie der Umzug auf Havok4 notwendig ist), wird die Region wieder mit deaktivierten Skripten/physikalischen Eigenschaften und nach dem Entfernen der auslösenden Objekte online gebracht.

Probleme mit einer bestimmten Sim können durch das Neustarten der Regionen in den Griff bekommen werden, was dazu führt, dass ein Simulatorprozess auf einer anderen Sim sie laufen lässt. Gridweite Probleme werden vorzugsweise an der Quelle behoben (zum Beispiel durch die Reparatur des Netzwerks). Bugs in Veröffentlichungen von neuem Programmcode erfordern entweder eine Änderung der Konfiguration (um ein neues Feature abzuschalten) oder einen rolling Restart mit aktualisiertem Code.

Die Reduzierung von Simulatorabstürzen war die Hauptmotivation hinter dem Umstieg auf Havok4(en) für die Physiksimulation und den bevorstehenden Umstieg auf Mono(en) für die Skriktausführung.

Datenserver

Was es ist: Die meiste Kommunikation zwischen dem Simulator zur Datenbank wird durch einen Prozess, der "Datenserver" heißt, zwischengespeichert; es gibt einige wenige Datenserverprozesse auf jedem Simhost. Das verhindert eine direkte Abhängigkeit von der Datenbank und erlaubt es dem Datenserver, auch eine längere Abfrage zu blockieren, während der Simulator eine bestimmte Framerate zu erreichen versucht.

Wie ein Fehler auftreten kann: Der Datenserverprozess kann aufgrund von Bugs abstürzen, die in Bezug zu unvorhergesehenen Umständen stehen. Zum Beispiel, wenn ein kurzer Netzwerkausfall auftritt, kann die Verbindung zu einer Datenbank verlorengehen. Normalerweise erholt sich das System gutmütig und transparent von einem Fehler mit dem Datenserver, aber bei einem bestimmten Simulator können einige Transaktionen vorübergehend scheitern. Die Unterbrechung der Dienste ist auf den bestimmten Simulator beschränkt. Es ist auch möglich, dass ein Softwareupdate Bugs mit einbringen kann, die gridweite Effekte auslösen können (zum Beispiel erhöhte Last auf den zentralen Datenbanken oder einfach häufigere Abstürze). Wenn eine Datenbank nicht auf Verbindungsanfragen reagiert, wird der Überwachungsdienst den Datenservers automatisch anhalten und den Datenserver neu starten, damit neue Anfragen bearbeitet werden können.

Wie wir das beheben: Wenn ein einzelner Datenserver abstürzt, wird er automatisch wieder hergestellt. Wenn ein Bug einbracht wurde, der gridweite Effekte auslöst, können die Datenserverprozesse normalerweise ohne Downtime ersetzt werden.

Die Datenserverkomponente ist dabei, ausgeschaltet und durch webbasierte Datenserverdienste ersetzt zu werden; Simulatoren werden HTTP verwenden, um mit einer neuen Art von Hosts zu reden, die als Relaisstation für Anfragen an die Datenbank dienen. Das wird uns dir Möglichkeit geben, das System leichter zu modifizieren, um die Performance zu verbessern und Unterbrechungen auszuschalten.

Login Server Cluster

Was es ist: Ein Cluster von Servern, der den ersten Dienst bereitstellt, mit dem der Viewer sich verbindet, wenn versucht wird, sich einzuloggen. Dieser überprüft die Benutzerdaten des Residents, prüft die Viewerversion auf mögliche Updates und stellt sicher, dass die neuesten Benutzerbestimmungen (Terms of Service) aktualisiert wurden. Angenommen, alle Überprüfungen verlaufen positiv, sendet der Cluster eine erste Übersicht über die Inventarordner des Residents und einige wenige weitere Teile von Daten. Schliesslich verhandelt er mit dem Simulator für die gewünschte Startregion und lässt den Viewer wissen, mit welchem Simulator er zu reden hat.

Wie ein Fehler auftreten kann: Wenn ein Server offline geht, wird ein gewisser Prozentsatz an Logins scheitern. Zusätzlich werden Logins auch scheitern, wenn wenn die zentrale Datenbank oder der Cluster der Inventardatenbank Probleme haben, da der Ablauf des Logins sehr datenbankintensiv ist. Schliesslich kann es auch passieren, dass nach einer grösseren Unterbrechung die dazu führte, dass die Mehrzahl der Residents ausgeloggt wurde oder sich nicht einloggen konnte, mehr Residents versuchen, sich einzuloggen, als unser Second Life verarbeiten kann (ungefähr 1000 Logins/Minute); das kann dann für Residents, die versuchen, sich einzuloggen, so aussehen, als ob der Logindienst fehlerhaft ist, obwohl er voll einsatzbereit ist und nur bei maximaler Kapazität läuft.

Wie wir das beheben: Wenn ein Loginserver selbst ausfällt, nehmen wir diesen aus der Rotation der Server. Wenn das Problem in einem anderen System oder Dienst begründet liegt, beheben wir es dort.

Web Site

Was es ist: Ein Cluster von Maschinen, die die Webseiten und Webdienste bedienen, die der Öffentlichkeit zur Verfügung stehen - diese enthalten secondlife.com, lindenlab.com, slurl.com, usw.

Wie ein Fehler auftreten kann: Hardwareausfälle können eine Maschine im Webcluster verlangsamen oder herunterfahren. In diesem Fall sollten Lastverteiler den Webtraffic von der Maschine, die langsam arbeitet, umleiten, aber der Lastverteiler selbst kann auch Fehler haben (zum Beispiel solche Ausfälle nicht sauber erkennen oder selbst blockiert werden). Fehler in den Websites können durch Codeaktualisierungen an den Websites, die täglich passieren, eingebracht werden. Ausserdem beruht die Website für viele Aktionen der Dienste auf dem zentralen Datenbankcluster, deshalb werden Fehler dort sich auch auf Tätigkeiten und Dienste auf der Website wie LindeX und Transaktionsverlauf, Landstore, Freunde online und so weiter auswirken.

Wie wir das beheben: Problematische Hardware kann aus der Rotation genommen werden, um die Reaktionsfähigkeit der Website wieder herzustellen. Probleme in anderen Systemen wie dem zentralen Datenbankcluster müssen dort in den Griff bekommen werden.

Linden Netzwerk

Was es ist: Die Leitungen, durch die das Zeug reist. Vor Allem die Verbindungen zwischen unseren Zweigniederlassungen (co-location facilities = "colos"), zum Beispiel San Francisco und Dallas. aber auch die Leitungen innerhalb der Colos. Das beinhaltet "VPNs", Switches, Router und andere esoterische Dinge. Manches davon ist Ausstattung, die Linden gehört, manches ist gemietete Ausrüstung (zum Beispiel bezahlen wir einen Drittanbieter dafür, dass wir seine "Leitungen" zwischen unseren Colos alleine benutzen können) und es werden auch öffentliche Internetverbindungen genutzt.

Wie ein Fehler auftreten kann: Eine Komponente kann ausfallen; zum Beispiel kann ein Router damit beginnen, Pakete zu verwerfen (aufhören, Daten zu senden). Das sieht dann oft so aus, als ob ein anderes System (Assetspeicher, Datenbank, Simulatoren, Logins) fehlerhaft wäre, da die Systeme nicht mehr länger miteinander kommunizieren können. Der Ausfall am 05. April 2008(en) ist ein Beispiel für diese Art von Fehler.

Wir wir es beheben: Die fehlerhafte Komponente so schnell wie möglich herausfinden und außer Betrieb nehmen oder ersetzen. Wenn es sich um eine gemietete Komponente handelt, müssen wir mit unserem Anbieter reden.

Internet

Was es ist: Eine Reihe von Leitungen(en), die Second Life zu Ihrem Computer bringen, von den großen transatlantischen und transkontinentalen Leitungen, die die Welt verbinden, bis hinunter zu der Breitbandverbindung von Ihrem Internetanbieter (Internet Service Provider (ISP)) zu Ihrem Zuhause.

Wie ein Fehler auftreten kann: Fehler können auf verschiedenen Ebenen auftreten. Wenn es auf einen hohen Level passiert - zum Beispiel wenn eine Hauptverbindung nach Europa offline geht - können Tausende von Residents die Verbindung zu Second Life verlieren.

Wie wir es beheben: Das ist normalerweise außerhalb unserer Kontrolle. Wenn wir das Problem isolieren können, können wir es an Netzwerkkontakte weitermelden, aber ansonsten müssen wir warten, bis das Problem behoben worden ist, genauso wie die Residents.