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.
How it can fail: Hardware or software failures can take a database cluster offline. There should be no in-world effect from one of these other database clusters failing, but occasionally a software design flaw does introduce a dependency that is not caught. For example, logins used to require a successful connection to the login database to record the login and viewer statistics, but this dependency has been removed.
How we fix it: All databases act in clusters with a primary machine and several secondaries. In case of failure, a secondary can be swapped into place as the new primary.
Our data warehousing team has been doing significant work over the past year to ensure that the ever increasing amount of data being logged about simulator and other system performance can be analyzed, and that the collection of this data is "transparent" to the other systems - logging database failures should no longer cause service disruptions.
Transient Data Services
What is it: A cluster of machines (currently: 16) that store data in memory for "transient" state. This includes things like agent presence ("who is logged on?"), group chat participation, inbound email to script mapping, and so forth. This data is not stored in a database and is either constantly refreshed (e.g. simulators update agent presence every few minutes) or otherwise recoverable (e.g. rejoining a group chat).
How it can fail: Hardware failure can reduce the capacity of these machines, or take them offline entirely. Software bugs can also cause poor performance - for example, a memory leak in a service could cause the services to start responding slowly. While the specific service is disrupted, the overall service remains functional.
How we fix it: Because the state is transient, a replacement host can be brought online quickly and the data "heals" itself over time. If the error is software-side the services can be restarted as soon as a fix for the bug is found, with little impact to residents.
Simulators
What is it: A sim is a machine that runs simulators, which are the computer processes that runs regions. (Think of a region like a document, the simulator like a word processor, and the sim as the computer itself that runs the program.) Since these are closely coupled concepts, jargon/terminology tends to be somewhat loose, e.g. "simstate" should really be "region state". The simulator divides its time between communicating with viewers, communicating with other system components, simulating physics and executing scripts.
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.