Servicestörungen
Second Life ist ein komplexes System mit vielen Komponenten, die miteinander interagieren, von den Simulatoren und Datenbanken zu dem Viewer, den Du am laufen hast 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 ausserhalb 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 beachte, dass in vielen Fällen eine Störung behoben sein kann, bevor eine Information im Blog veröffentlicht werden kann, um die Einzelheiten des Problems zu erklären. Ein Zweck dieses Dokumentes ist es, ein "Dokumentationszentrum" für Arten von Störungen n den Diensten bereitzustellen, damit das Blogposting sich auf diese Seite beziehen kann, wenn sich ein Systemfeheler 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 (stell' Dir 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, bein 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 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, dass die Datenbank abstürtzt 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 Belsatung der Datenbank zu hoch ist, sie aber nicht ausgefallen ist, können wir Dienste anschalten, um zu versuchen, die Belastung zu reduzieren.
Das Eleminieren 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 im Auge, um aktuelle Informationen zu bekommen
Agenten- ("Inventar-") Datenbankcluster
Was es ist: Speicher for die meisten agentenspezifischen Daten wie dem Inventarbaum ist über eine Reihe von Datenbanken verteilt. Jeder Agent ist einem bestimmten Inventarpspeicherbereich (einer primären Datenbank und ihreer 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 dazuu, dass Logins von Agents, die diesem Speicherbereich zugeprdnet 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 geen. 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 auszuzeichnen, 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 an 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, dass 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 is: Eine sim ist eine Maschine, auf der Simulatoren laufen, welche wiederum Computerprozesse sind, auf denen Regionen laufen. (Stelle Dir 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, der Kommunikation mit anderen Systemkomponenten, dem Simulieren von physikalischen Vorgängen und dem Ausführen von Skripten auf.
How it can fail: A bug in the simulator code can cause a crash. Most crashes cause a region simstate to be saved, and another simulator will load that simstate after a few minutes. Often, the bug is triggered by some of the region content - a script or physical object.
Other problems fall into two categories - problems with a specific sim, or grid-wide. Problems with a specific sim may include overloading (e.g. 4 high-traffic regions on the same sim) or failures (disk full, network interfaces lost, hardware failure). Grid-wide problems are usually caused by the other factors listed here, such as loss of network or database or asset cluster failure (either of which, for example, could prevent simulators from loading simstates. New simulator code releases occasionally introduce bugs with grid-wide consequences (e.g. excessive logging causing network traffic congestion)
How we fix it: Simulator crashes are reported just as viewer crashes are. We can use the data to determine the general subsystem that caused the crash (initialization, physics, scripts, messaging, etc.) If the crash is caused by content (script or physical object) we can use the crash data to determine why this occurred. In the mean time (since the fix may take several days or, in the case of physics, a project like the move to Havok 4) the region is brought up with scripts/physics disabled and the offending objects removed.
Problems with a specific sim can be addressed by restarting the regions, which causes a simulator process on a different sim to run it. Grid-wide problems are fixed either at the source (e.g. repair the network). Bugs from new code releases require either a configuration change (to turn off a new feature) or a rolling restart with updated code.
Reducing simulator crashes was the main motivation behind the movement to Havok4 for physics simulation, and the upcoming move to Mono for script execution.
Dataservers
What is it: Most of the simulator to database communication proxies through a process called "dataserver"; there are a few dataserver processes on each sim host. This eliminates a direct dependency on the database and allows the dataserver to block on a lengthy query while the simulator targets a fixed frame rate.
How it can fail: The dataserver process can crash as a result of bugs related to unforseen circumstances. For example, if the network hiccups, a connection to a database may be lost. Usually the system recovers gracefully and transparently from a dataserver failure, but on a particular simulator some transactions may fail temporarily. The service disruption is localized to the specific simulator. It is also possible that a software update could introduce bugs that cause grid-wide effects (for example, increased load on the central database cluster, or just more frequent crashes.) When a database is not responding to connections, the dataserver process watcher will automatically stop and restart the dataserver so new requests can be services.
How we fix it: When an individual dataserver crashes, it is automatically restored. If a bug is introduced that causes grid-wide effects the dataserver processes can usually be replaced without downtime.
The dataserver component is being phased out and replaced with web dataservices; simulators will use HTTP to talk to a new set of hosts that in turn relay queries to the database. This will allow us to more easily tweak the system to improve performance and eliminate disruptions.
Login Server Cluster
What is it: A cluster of servers which represent the first service that the viewer connects to when attempting to log in. This validates the resident's credentials, checks the viewer version for possible updates, ensures the latest Terms of Service have been updated. Assuming those check out, it sends the viewer an initial overview of the resident's inventory folders and a few other chunks of data. Finally, it negotiates with the simulator for the requested start location and lets the viewer know which simulator to talk to.
How it can fail: If one drops offline, some percentage of logins will fail. Additionally, since the login sequence is database-intensive, if the central database or inventory database cluster are having problems then logins will also fail. Finally, after a major disruption that leads to many Residents being kicked or unable to connect, there may be more Residents trying to connect than our Second Life can handle (roughly 1000 logins/minute); this can appear to Residents trying to log in as though the login service is failing, even though it is fully functional and just at maximum capacity.
How we fix it: If a login server itself fails, we take it out of rotation. If the problem is in another system or service, we fix it there.
Web Site
What is it: A cluster of machines that serve the web pages and web services exposed to the public - including secondlife.com, lindenlab.com, slurl.com, etc.
How it can fail: Hardware failures can slow down or shut down a machine in the web cluster. In that case, a load balancer should automatically redirect web traffic away from machines that are performing poorly, but the load balancer itself may have bugs (e.g. it may not detect such failures properly, or itself become blocked up). Web site bugs can be introduced by code updates to the web site, which are made daily. In addition, the web site relies on the central database cluster for many service actions, so failures there will affect web site actions such as the LindeX and transaction history, land store, friends online, and so forth.
How we fix it: Problematic hardware can be taken out of rotation to restore the responsiveness of the web site. Problems in other systems such as the central database cluster need to be addressed there.
Linden Network
What is it: The tubes through which stuff travels. Most notably, the connections between our co-location facilities ("colos"), e.g. SF and Dallas, but also the plumbing within colos. This includes "VPNs", switches, routers, and other esoteric stuff. Some of this is Linden equipment, some of this is leased equipment (e.g. we pay a third party to have dedicated use of their "tubes" between our colos), and public Internet pipes are also used.
How it can fail: A component can go bad, for example, a router can start dropping packets. This often appears as one of the other problems (asset storage, database, simulators, logins) since the systems can no longer talk to each other. The failure on April 5th, 2008 is an example of this kind of failure.
How we fix it: isolate the affected component and take it out of service or replace it as quickly as possible. If this is a leased component we need to talk to our provider.
Internet
What is it: A series of tubes that bring Second Life to your computer, from the large trans-oceanic and trans-continental pipes that link the world down to high-speed connection to your home from your Internet Service Provider (ISP).
How it can fail: Failures occur on several levels. If this happens at a high level - for example, a major Internet trunk to Europe drops offline - thousands of residents can be disconnected from Second Life.
How we fix it: This is usually beyond our control. If we can isolate the problem we can report it to network contacts, but otherwise we just need to wait for the issue to get fixed, like the residents.