Single-Shard MMOG EVE online
Werbung
Single‐Shard MMOG EVE online Gründe, Architektur, Zukunft Isolde Scheurer (is037@hdm‐stuttgart.de) Hochschule der Medien 25.09.09 Inhalt 1 Einführung .......................................................................................................................... 3 2 EVE Online .......................................................................................................................... 5 3 2.1 EVE online Kurzinfo ...................................................................................................... 5 2.2 Die Architektur dahinter .............................................................................................. 5 2.2.1 Ausstattung .......................................................................................................... 6 2.2.2 Problemherde ....................................................................................................... 8 2.2.3 Neuausstattung .................................................................................................... 9 2.2.4 Warum nicht immer Single‐Shard? .................................................................... 12 Weiteres Load‐Balancing .................................................................................................. 13 Literaturverzeichnis .................................................................................................................. 15 2 1 Einführung Nichts fordert einen Spieleentwickler so lange wie ein MMOG (massively multiplayer online game). Für erschienene Spiele im kleineren Format, was die Multiplayer‐Spieler angeht, müssen ab und zu nur noch kleine Patches entwickelt werden, aber ein gut laufendes MMOG ist nie wirklich fertig und die Benutzer erwarten auch ständig neue Inhalte und Verbesserungen. Während sich die Programmierer nach einer frisch erschienenen und laufenden Erweiterung meistens kurz auf ihren Lorbeeren ausruhen können, sind die Server Administratoren rund um die Uhr beschäftigt. Spielermassen, die bei manchen MMOGs bis in die Millionen gehen 1 , wollen ein stabiles, perfomant laufendes Programm und möglichst auch keine Wartungszeiten. Lastverteilung ist somit ein wichtiger Bestandteil von MMOGs und das Netzwerk mit den Servern muss bestimmten Anforderungen an Technik als auch Struktur entsprechen. Last in Spielen kommt von der Anzahl der Einheiten in einem Spiel, also Benutzer als auch NPCs (Nicht‐Spieler‐/computergesteuerte Charaktere). Gerade auf viele Benutzer muss das System reagieren können und skalierbar sein. Auf oberster Ebene, um die Gesamtanzahl an Spielern zunächst aufzuteilen, nutzen die meisten MMOGs „Shards“. Dieser Begriff, der heutzutage seinen Weg auch in die Datenbankterminologie gefunden hat, stammt tatsächlich ursprünglich aus der MMOG‐Welt. Die Macher von Ultima Online überlegten sich einen Begriff für die einzelnen Kopien des Spiels, die sie auf verschiedenen Servern laufen ließen, um so die Benutzerlast zu verteilen. Sie kamen auf den Namen Shard folgendermaßen: The evil wizard Mondain had attempted to gain control over Sosaria (die Spielwelt) by trapping its essence in a crystal. When the Stranger at the end of Ultima I defeated Mondain and shattered the crystal, the crystal shards each held a refracted copy of Sosaria. 2 Das heißt also ein Spieler muss zu Beginn für einen Server entscheiden und spielt dort getrennt von den anderen Servern in einer eigenen Parallelwelt. Er kann sich natürlich später auch entscheiden einen neuen Charakter auf einem anderen Shard anzufangen oder einen kostenpflichtigen Transfer in Anspruch zu nehmen. Jedoch fällt sofort der große Nachteil ins Auge: man kann nicht so einfach mit Freunden spielen, die auf einem anderen Shard ihre Charaktere haben. Wenn man schon länger auf einem Shard gespielt hat, kommen Transfers eh selten in Frage, da man schon in die Community dort eingebunden ist. Trotzdem geht 1 http://www.mmogchart.com/Chart1.html 2 http://www.raphkoster.com/2009/01/08/database‐sharding‐came‐from‐uo/ 3 zum Beispiel das MMORPG (RPG=Roleplay game) mit den meisten Abonnenten, World of Warcraft, diesen Weg. Hier ist das Spielermaximum eines Shards ca. 7000. Andere versuchen das Problem mit Instanzierung aller Zonen/Bereiche des Spiels zu umgehen: in Champions Online kann man sich stets aussuchen in welcher Instanz einer Zone man sein will bzw. kann aufgrund von Freundschaftslisten automatisch in die richtige versetzt werden. Trotzdem kann man sich insgesamt nur mit wenigen Spielern in der Welt oder einer Zone davon befinden. Für das Spielerlebnis wäre ein einziger Shard/World‐Server sicher zuträglich, vor allem im Zuge des PvP (Player versus Player) sowie der Wirtschaft im Spiel. Riesige Schlachten wären theoretisch möglich, die Wirtschaft würde blühen und schlaue Händler könnten viel „Geld“ machen. Insgesamt müsste ein Spieler strategischer und bedachter handeln, denn es ist nicht möglich bei Problemen den Shard oder die Instanz zu wechseln. Genau das versucht EVE online zu bieten, welches sich gezielt für den Single‐Shard‐Ansatz entschied. In diesem Paper wird die Architektur von EVE vorgestellt und gezeigt wie die Entwickler in den letzten Jahren gegen den Lag gekämpft haben sowie worauf sie hinarbeiten. Zum Schluss wird noch eine feingranularere Designentscheidung angesprochen, die der Zonen. 4 2 EVE Online 2.1 EVE online Kurzinfo EVE online 3 ist ein Science‐Fiction MMOG, welches 2003 offiziell startete und seitdem von Crowd Control Production (CCP) ständig weiterentwickelt wird. 20.000 Jahre in der Zukunft übernimmt der Spieler die Rolle eines sogenannten Capsuleers, eines Raumschiffpiloten, und versucht seinen Platz in dem Universum aus über 5000 Sonnensystemen in einer der vielfältigen Möglichkeiten wie Pirat, Händler oder Allianzleiter zu finden. Anders als die meisten MMOs ist EVE nach dem Sandbox‐Prinzip designt: ein Teil des Universums wird von den Spielern bestimmt, z.B. welche Territorien eingenommen werden, wer den größten Marktanteil hat etc. Die Entwickler unterstützen sie nur dabei und bieten weiterhin auch ähnlich wie in anderen MMOs vorgegebenen Content und Missionen (sonst als Quests bekannt). Genau deshalb entschieden sich die Entwickler auch für den Single‐Shard Ansatz, der das ganze Spielerlebnis und ‐design prägt und damit dieses MMO von anderen abhebt. EVE hat inzwischen über 300.000 Abonnenten und der bisher größte Supercomputercluster, der je in der Spielindustrie eingesetzt wurde, ermöglicht es laut dem Newsletter im März 2009 53.850 Spielern 4 gleichzeitig durch das Universum zu düsen. Bei Kämpfen können über 1000 Raumschiffe teilnehmen bevor es zu Performance‐Einbußen und Lags kommt. Wie kann EVE solche Zahlen auf einem einzigen „Shard“ halten? Die Antwort: Investition in neueste Technik, ständige Verbesserungen und geschickter Umgang mit IO. 2.2 Die Architektur dahinter Wie jedes MMOG heutzutage nutzt EVE online eine Client/Server‐Architektur. Der zentralisierte Servercluster nennt sich Tranqulity (TQ) und befindet sich in London. Allerdings gibt es noch einen namens Serenity in China, da das Spiel wegen chinesischer Gesetze leicht abgeändert werden musste und ein MMO dort auch nur auf einem in China befindlichen Server angeboten werden darf. In diesem Paper werde ich natürlich nur auf Tranquility eingehen. Die grundlegende Architektur veränderte sich bei EVE seit 2007 nicht, allerdings kommen immer wieder neue Maschinen und Techniken hinzu, um der stetig wachsenden Spielerzahl 3 http://www.eveonline.com 4 http://www.eveonline.com/community/newsletters/vol027.html 5 gerecht zu werden. Zunächst wird kurz die Grundstruktur angesprochen, auf Einzelheiten wie die verwendete Technik wird im nächsten Unterkapitel eingegangen. EVEs Infrastruktur besteht aus drei Ebenen: • Proxy Blades: Vor diese Ebene sind noch Load‐Balancer gespannt. Die Benutzer kommunizieren nur „direkt“ mit diesen Geräten, hier wird die Verbindung aufgebaut und Pakete vom Benutzer weitergeleitet sowie welche an ihn zu ihm gereicht. Die Proxies wissen auf welchem SOL Server sich der User befindet und leiten bei einem Sprung in ein anderes Sonnensystem, wenn nötig, die Versetzung auf den zugehörigen anderen Server ein. So kann man sagen, dass sie spezialisierte Router zwischen dem Client und dem Cluster sind. Solche „Gateways“ haben außerdem folgende Vorteile o Sie schützen das interne Netzwerk besser vor Angriffen o es kommt zu weniger Verbindungsoverhead, da sich nur die Proxies mit dem Rest des Netzwerkes verbinden und nicht alle Clients o klare Aufgabenverteilung 5 • SOL Blades: Das Arbeitstier der Architektur, wo die Berechnung stattfindet und es zu den meisten Problemen kommen kann. Auf den Prozessorkernen laufen sogenannte Nodes, einzelne Serverprozesse. Die Sonnensysteme werden auf die Server geladen, viel besuchte erhalten einen einzelnen dedizierten. Eine weitere SOL Blade hält die EVE Anwendung selbst, auch Node genannt. • Database Cluster: Die Datenbank kümmert sich um Schiffsverwaltung, Handel und so weiter und stellt damit die Persistenzebene dar, mit der ständig kommuniziert wird. Als Programmiersprache dient stackless Python. 2.2.1 Ausstattung Skalieren heißt bei CCP vor allem neue Techniken ausprobieren, immer auf möglichst aktuellste Hardware zu setzen und auch ständig Infrastruktur sowie das Spiel zu verbessern. Mit jeder neuen kostenlosen Expansion verändert sich ein Großteil der Features und in Patches wird der Code optimiert. Im Jahre 2007 sah der Aufbau noch wie folgt aus (Anmerkung: die Bilder spiegeln nicht die genaue Anzahl an Maschinen wider, sie wurden denen der Präsentation hier 5 http://onlinegametechniques.blogspot.com/2009/04/why‐would‐you‐want‐gateway‐boxes.html 6 http://www.eveonline.com/download/videos/Default.asp?a=download&vid=214 nachempfunden): Abbildung 1: Architektur 2007 Load Balancers JetByte Network Layer Proxy Blades AMD Opteron 2.8 GHz SOL Blades Windows 2003 32Bit EVE Nodes Database Cluster MS SQL Server 2005 JetByte, über das die Proxies sowie die SOLs miteinander kommunizierten, war schon seit 2003 im Einsatz. Da diese Ebene nicht besonders stabil war, benötigte man redundante Blades. Auf jedem der 90‐100 SOL Blades mit 4GB DDR1 RAM liefen 2 Nodes (je eine pro Core) mit nur 32Bit. Dedizierte Server haben eine Node im Leerlauf. Da stackless Python verwendet wird, befindet sich auf jeder Node nur ein Thread und somit kann nur ein Core pro Node verwendet werden. Die SQL Server Datenbank verarbeitete bei Stoßzeiten bis zu 2.000 Transaktionen und verwendete 2 RamSan 400 SSDs sowie ein DS4800 Glasfaser‐Speichersystem. Im internen Netzwerk wurde noch normales Gigabit Ethernet verwendet. 7 2.2.2 Problemherde CCP behauptet selber einen ständigen Krieg gegen Lag zu führen, dabei gibt es in EVE unterschiedliche Lagursachen und Probleme: • Jita, das vielbesuchte Handelszentrum. Lag kommt hier durch Überpopulation zu Stande. • Missionszentren, dort wo Quests ausgeführt werden können kommt es zum Module delay. • Kämpfe mit Hunderten von Schiffen. Mit so vielen Leuten auf einem Shard und freiem PvP (player versus player) werden große Schlachten gefördert, führen aber auch ab einer bestimmten Schiffsanzahl immer wieder zum Crash. Einen Überblick, wo in der Architektur welcher Lag auftritt, gibt folgendes Schaubild von 2005. Heute können dieselben Ursachen auftreten, allerdings hat man sich um die „Yarrdware“ gekümmert und die drei oben beschriebenen Lagarten wurden reduziert (siehe nächstes Unterkapitel). Abbildung 2: Lag in EVE 6 6 http://www.eveonline.com/devblog.asp?a=blog&bid=286 8 Jeden Tag hat EVE eine Stunde kontrollierte Downtime. Währenddessen wird sich vor allem auf anstehende Kämpfe oder Ähnliches vorbereitet indem das betroffene Sonnensystem einen dedizierten Server bekommt. Spieler können sich hierfür auch rechtzeitig melden und Schlachten oder andere Raumschiffansammlungen CCP ankündigen. 2.2.3 Neuausstattung Ab 2008 entschied sich CCP ihr Equipment grundzu erneuern und auf High Performance Computing vorzubereiten. Sie nehmen am Microsoft Technical Adoption Program (TAP) 7 teil, um gemeinsam die beste Technik für EVE zusammen zu stellen und zu testen, denn HPC ist nicht auf MMOGs, bei denen es wichtig ist keine Unterbrechungen zu haben, ausgerichtet. Auf jeder Ebene soll es zur Vorbereitung auf HPC zu folgenden Veränderungen kommen, manche davon wurden schon umgesetzt: Abbildung 3: HPC Architektur Load Balancers StacklessIO Network Layer Proxy Blades Intel Xeon 3.3GHz SOL Blades Windows 2008 64Bit EVE Nodes 20GBps Infiniband MS SQL Server 2008 Database Cluster 7 http://msdn.microsoft.com/en‐us/isv/bb190413.aspx 9 Die Proxy‐Ebene stellte den größten Engpass dar. Bei vielen eingeloggten Benutzern hatte JetByte einige Instabilitätsprobleme, die Proxy‐Server ausfallen ließen. Um ein stabileres und verlässlicheres Netzwerk zu haben, entwickelte CCP StacklessIO, welches das Scheduling besser managete 8 . Damit konnten außerdem die redundanten Proxies eingespart werden, so dass nun nur noch 8 übrig sind. Am 16. September 2008 wurde es erstmals live eingesetzt und vor allem die maximale Spieleranzahl in dem meistbesuchtesten Sonnensystem Jita, wo sich der Markt befindet, zeigt die deutliche Verbesserung: zuvor hielt der Knoten nur 800‐ 900 Spielern stand, kurz danach schon bis zu 1400. Zum Test wurde die Verbindung von Client zum Netzwerk/Jita, mit ca. 800 Spielern auf der Node, gemessen, indem ein Dienst auf dem Server angesendet wurde und dieser mit der globalen Zeit antwortete. Manche Pings brauchten sehr lange während gleichzeitige, andere schnell ankamen. JetByte hielt anscheinend manchmal ohne Grund Pakete auf. Abbildung 4: Ping von Node zu Client (y: seconds) 9 Mit der Restrukturierung der IO‐Verwaltung durch StacklessIO sieht das Diagramm unter Verwendung derselben Spieleranzahl dann so aus: 8 http://pycon.blip.tv/file/1949701/ 9 http://www.eveonline.com/devblog.asp?a=blog&bid=584 10 Abbildung 5: Ping von Node zu Client mit StacklessIO Nur wenige kleine Spitzen sind zu erkennen, die auch durch Internet‐Delay zustande gekommen sein könnten. Auch der interne Ping im Cluster verringerte sich um den Faktor 2 und der Speicherverbrauch der Proxy‐Server wurde reduziert. Nachdem Jita mit StacklessIO weniger Lags hatte, kam ein völlig neues Problem hinzu: bei 1400 Piloten ging der Node der Speicher aus. Die Entwickler nahmen das als zusätzlichen Anstoß EVE auf 64Bit umzustellen, um mehr Speicher adressieren zu können, was auch nun erst mit StacklessIO möglich war. Zunächst wurden einige der Server im SOL‐Cluster durch dual core Intel Xeon 3.0Ghz Woodcrest Blades ersetzt und der Cluster lief so gemischt mit Nodes teils unter 32Bit, teils 64Bit. Die dedizierten Server laufen allerdings nur mit 64Bit Code und haben inzwischen 16GB RAM. Wegen den 2 dual‐core CPUs der neuen Server, können 4 EVE Nodes mit Sonnensystemen darauf geladen werden. Inzwischen, seit Anfang 2009, wurden weitere Geräte durch 34 Intel Xeon 3.3Ghz Wolfdale Blades ersetzt, von denen 8 als Proxy Server laufen. Werden die Administratoren vorgewarnt, dass eine Schlacht stattfinden soll, so können sie das betroffene Sonnensystem auf einen dedizierten Server laden und mit den neuen Blades konnten schon bis zu 1000 Raumschiffe sich lagfrei bekriegen. Ab 1200 gibt die Node allerdings auf. Die Verbindungen zwischen Cluster und Datenbank sollen außerdem bald Infiniband nutzen um nur noch eine Latenz von Mikrosekunden innerhalb des Netzwerkes zu haben und den Zugriff auf die Datenbank, die nun eine SQL Server 2008 DB ist, somit noch schneller zu 11 machen. Zu guter Letzt wurden nur die 2 RamSan 400 behalten und ein zusätzliches RamSan 500 mit 2TB gekauft um die Daten des Fiber Channel Drives nun aufzunehmen. Mit dieser Infrastruktur und Ausstattung ist EVE bereit für Windows HPC Server 2008, was dem MMOG mit Unterstützung von Microsoft sicher helfen wird weitere Rekorde zu brechen. 2.2.4 Warum nicht immer Single-Shard? Die Entwickler scheinen im Lagkrieg im Moment die Oberhand zu haben und EVEs steigende Abonnentenzahlen zeigen, dass ihr Konzept aufgeht. EVE ist immernoch ein einzigartiges MMOG mit einem einzigartigen Spielerlebnis für seine Abonnenten. Trotzdem ist diese Herangehensweise, wie nach den vorangegangenen Kapiteln deutlich wird, mit viel Aufwand und vor allem Kosten verbunden, welche andere MMOG‐Entwickler scheuen. Vielleicht mit fortschreitender und günstig werdender Technik werden sich andere anschließen, wobei man das von bestehenden MMOGs eher nicht erwarten kann, denn diese müssten ihre bestehende Architektur neu ausrichten oder ganz ersetzen. EVEs Architektur könnte außerdem nicht Spielerzahlen, wie sie World of Warcraft hat, standhalten. Denn wie Max Skibinsky allerdings in seinem Artikel „The Quest for Holy Scale“ in dem Buch Massively Multiplayer Game Development (siehe Quellen) schreibt, liegt nämlich das Knackpunkt vor allem bei der Client/Server Architektur, die nicht Millionen Benutzer unterstützt egal wie schnell und gut die Verbindung zu den Servern ist. Die Synchronität zwischen so vielen Clients und die damit verbundene Masse an IP‐Paketen werden bei größeren Spielerzahlen zum Problem. Es gibt aber noch einen weiteren organisatorischen Faktor, der für Sharding spricht. In den meisten MMOGs gibt es extra Server für PvP, wo neben Kampf gegen die computergesteuerten Gegner auch Spieler gegeneinander antreten. Manche Spieler „questen“ lieber in Ruhe alleine oder mit anderen ohne ständig Ausschau nach „menschlichen“ Feinden halten zu müssen. Des weiteren bieten MMORPGs meist auch noch Rollenspiel‐Server an, auf denen sich Spieler in ihre Charaktere hineinversetzen, ihnen passende Namen geben und Geschichten ausspielen. Solche Spieler möchten fern der mit Kürzeln um sich werfenden Menge sein, die selten ihre Spielweise toleriert. Bei EVE gibt es noch eher wenig Rollenspielpotenzial, auch wenn sich Spieler dafür einsetzen, aber bei anderen MMORPGs macht so eine Einteilung mehr Sinn. 12 3 Weiteres Load-Balancing Zuletzt sollte noch ein häufiger Kritikpunkt/Vorschlag von Spielern angesprochen werden: Schaut man sich das Load‐Balancing aber etwas feingranularer an, fällt auf, dass ein Sonnensystem nicht multithreaded auf verschiedenen Nodes läuft, sondern ein System bzw. meistens sogar viele davon auf maximal einer Node. Bei MMOs gibt es auf dieser Ebene verschiedene Ansätze Last geschickt zu verteilen. Die meistverwendeten Techniken sind Zonen/shattered World oder eine kontinuierliche Welt/seamless. Der große Unterschied zwischen beiden ist, ob der Spieler bei Erkundung und Interaktion mit der Welt eingeschränkt ist oder nicht/kaum. EVE zum Beispiel ist eindeutig zoned: ein Sonnensystem ist eine abgeschlossene Zone, die sich auf einem Server befindet. Will man zu einem anderen muss man durch ein Sprungtor, man bekommt einen Ladebalken zu sehen und es dauert ein paar Sekunden bis man dort ist. An der Dauer merkt man, ob das Pilotobjekt auf eine andere Node verfrachtet werden musste. Man erkennt gleich, warum die Entwickler bisher dieses System beibehalten haben: in einer Massenschlacht den Server wechseln zu müssen wäre für einen Spieler fatal, denn Lag bedeutet in dem Fall vielleicht Tod seines Piloten. Des weiteren passen Sprungtore und eine solche Fortbewegung zwischen Sonnensystemen zu der Welt, so dass sie den Spieler nicht irritieren oder stören. Bei einer durchgehenden Welt hingegen, wie sie z.B. Herr der Ringe online hat, kann ein Spieler die ganze Welt zu Fuß ablaufen mit kaum merkbarer Trennung, wenn ein neues Stück Welt geladen wird. Dafür wird die Welt geometrisch in Stücke eingeteilt und jeder Host bekommt eines zugeteilt. Die Einteilung hängt von der Art der Welt ab, beim typischen Fantasy RPG kann hier eine flache Welt angenommen werden, über die ein Gitter gelegt wird. Bei EVE, wo das Schiff in alle möglichen Richtungen sich bewegen kann, wäre z.B. ein Oct‐Tree geeigneter um zu unterteilen, zeigt aber auch gleich die höhere Komplexität. So oder so ist es im nächsten Schritt wichtig auf die Grenzen zu achten und vor allem noch auf eine Region um die Grenze herum. Innnerhalb einer bestimmten Breite haben/kennen beide Server die Gegenstände, geometrischen Eigenschaften und Einheiten, die sich dort befinden und tauschen sich darüber aus. Ein Spieler muss ja, wenn er sich auf der Grenze zwischen den Flächenstücken befindet, in einem bestimmten Sichtradius, was um ihn rum ist, sehen können. Somit muss die Fläche mindestens so breit wie sein Sichtradius sein. Probleme können nun aber noch bei großen Models wie Häusern auftreten, die über die Grenze hinausgehen. Abbildung 6 zeigt diese Situation. Ein Gebäude befindet sich auf Server A und innerhalb der gemeinsamen Grenze, welche genau so groß ist wie die Sichtweite des Spielers. Dieser befindet sich jedoch auf Server B und kann das Objekt somit nicht sehen, 13 aber es kann trotzdem passieren, dass er mit dem Gebäude kollidiert. Bei EVE mit seinen riesigen Raumstationen wäre es schwierig eine angemessene gemeinsame Grenzengröße zu finden. Abbildung 6: Grenzen und große Objekte, der Spieler sieht nur die Pflanze rechts unten 14 Literaturverzeichnis EVE online developer’s blog – Lag in EVE http://www.eveonline.com/devblog.asp?a=blog&bid=286 Architektur updates http://www.eveonline.com/devblog.asp?a=blog&bid=589 StacklessIO http://www.eveonline.com/devblog.asp?a=blog&bid=584 EVE64 http://www.eveonline.com/devblog.asp?a=blog&bid=588 neue RamSans http://www.eveonline.com/devblog.asp?a=blog&bid=632 EVE Wiki Eintrag zu Tranquility http://wiki.eveonline.com/wiki/Tranquility Fanfest 2008 Präsentation zu Tranquility http://www.eveonline.com/download/videos/Default.asp?a=download&vid=214 Microsoft HPC EVE case study ‐ http://www.eveonline.com/externalLink.aspx?l=http%3A%2F%2Fdownload%2Emicrosoft%2 Ecom%2Fdownload%2F9%2F6%2F2%2F962a6c52%2Da7ba%2D4bf2%2D8464%2Dcc8a6a8a7 dc3%2FCCP%5FHPC%2Edoc Stackless Python ‐ 2 EVE news http://zope.stackless.com/news Massively – EVE evolved: server model http://www.massively.com/2008/09/28/eve‐evolved‐eve‐ onlines‐server‐model/ High Scalability ‐ http://highscalability.com/eve‐online‐architecture 15 Game Set Watch – Wie man Single‐Shard MMOGs designen sollte http://www.gamesetwatch.com/2009/05/opinion_designing_a_single_ser.php Alexander, Thor: Massively Multiplayer Game Development 1, ISBN:1‐58450‐243‐6 Massively Multiplayer Game Development 2 ISBN: 1‐58450‐390‐4 16
