DB Server (MySQL) mit SSD ?

[NacKteOmA]

Ich plane momentan ein großes Projekt. Es geht um ein nicht kommerzieles "globales" Gameserverranking System basierend auf HLstatsX. Hierfür wird ein krätiger DB Server verlangt.

Die Ausmaße sind allerdings so beträchtlich das ich eher Quantität als Qualität umsetzen werden könne. Die Datenbank selber wird wohl gerne die 100GB mehr als locker übersteigen (wenn nicht sogar in den TB Bereich).

Ich nutze selber für meinen Clan schon dieses Rankingsystem. Daher kann ich schon mal mit ein paar Daten um mich werfen.

Mein Ranking besteht aus 5 Gameservern in der größe von 12-20 Spieler, insgesamt Platz für 80 Spieler (12-20 Slots sind auch die gänigen größen). Alle 5 Server sind SEHR stark besucht, somit kann man hier von schon fast Maximum/Limit Werten sprechen.

MySQL Wachstum pro Monat
800-900MB (alle 5 Server)
Gerunde 200MB pro Monat pro Server

Queries
20 Queries pro Sekunde (alle 5 Server - schnitt des ganzen Monats)
Gerundet 5 Q/s pro Server

Man rechne es auf einige Hundert oder gar 1000 oder 2000 Server hoch, so entsteht natürlich eine riesige Datenbank. Allerdings wird wohl pro Quartal ein Reset durchgeführt.

Nun steht natürlich die Frage wie die Datenbank am kostengünstigen umgesetzt wird. Von richtiger Serverhardware habe ich daher eher abgesehen. Somit wird wohl Hardware ala Desktop genutzt. Das heißt z.B. ein Core2Quad mit 8GB RAM oder i7 mit 12GB RAM für mehr RAM müsste man wieder in den Serverkomponenten bereich gehen.

Ich hatte eventuell angedacht ein paar SSDs im Raid0 zu schalten und diese als SWAP zu nutzen und es praktisch als "billigen" RAM anzusehen. Natürlich erreicht eine SSD keine Zugriffswerte und Bandbreiten eines RAMs allerdings müssen die Queries auch nicht innerhalb von 20ms beantwortet werden, denn bis zu 1 Sekunde wäre tragbar.

Somit würde es z.B. so aussehen

CPU: Intel i7
RAM: 12GB RAM
HDD: 4x 500GB im Raid0 (zum allgemeinen Speichern der DB)
SSD: 4x 30/40GB im Raid0 (oder wie auch immer eher kleine aber mehrere)
Anbindung: 1Gbit

Von jeder SSD werden 4-6GB als SWAP also praktisch billigen, etwas langsamen RAM genutzt. Der Rest bleibt praktisch von der SSD tot - denn irgendwann kann diese die Anfragen nicht mehr bewältigen. Somit während praktisch bis zu 24GB extra RAM möglich. Könnten sowas die SSDs bewältigen?

Natürlich wird das System jeden Tag einen Backup unterzogen. Sollte z.B. eine Platte mal ausfallen müssen die Spieler mit der Statistik vom vor Tag leben das bringt keinen um. Ebenfalls natürlich bewegt sich ein sollches System natürlich stark vom Optimum weg und im Grunde war es einfach mal so ein Hirngespinnt.

 

[d4f]

Iin der Annahme dass das System linear skaliert, reden wir ueber 5000 Queries aller Art JE SEKUNDE. Inklusive long queries und solcher die nicht ueber Index gehen...
Das schafft imho nicht mal die SSD als Massenspeicher...
Ich betreibe Psychostats-Sponsoring (Opensource-Alternative zu HlStatsX) und das bringt bereits ab 800 Queries/Sekunde einen Dualcore Server in die Knie... (Von der Prozessorlast durch MySQL, nicht Festplatte oder Netzwerk!)

Ich hatte vor einiger Zeit den Entwurf zu einem aehnlichen Projekt skizziert, musste mich aber schnell von den bereits existierenden Loesungen abwenden weil schlicht und ergreifend die Skalierbarkeit und Leistung fuer solche Bereiche fehlte.
Nach paar Tagen Ideenentwicklung hab ich's schliesslich aufgegeben...
Ich wuerde jedoch empfehlen ein System zu entwickeln welches massiv auf Memcached setzt und multiserver-tauglich ist. Sonst wirst du schnell ein Opfer deines eigenen Erfolgs...

 

[NacKteOmA]

Ja gut, bei der Planung so etwas fällt jedem später die Schweißperlen von der Stirn. Spätestens ab 1000 oder 2000 Server wird das ganze zu einem Mamut Projekt.

Fürs erste wird eine Beta gestartet, mit meinen vorhanden freien Ressourcen (Server die bei mir einfach rumdümpeln). Dann wird auch geschaut in wie weit sich das Projekt durch Werberung selber finanzieren lässt.

Pharser + Webfronted
Intel Core2Quad - 2,4GHz
4GB RAM
4x 750GB HW Raid10
100Mbit Bandbreite - ohne Drosselung

DB Server
Intel Core2Quad - 2,4GHz
8GB RAM
4x 750GB HW Raid10
100Mbit Bandbreite - ohne Drosselung

Ggf. Leistungstarker Vserver als Webfronted um den Pharser zu entlasten.

Hiermit erwarte ich realistisch in der Region von 150-500 Gameserver zu packen. Da es natürlich auch gerne einige gibt, die nur eher wenig besucht sind. Ab XXX Servern wird in der BETA dann auch gekappt, sprich es wird nicht möglich sein weitere Hinzuzufügen damit das ganze nicht zum Kollaps führt. Ich warte dann die Schwachstellen des Systems zu entdecken.

Nur was ist danach?

Da komme ich dann ins wanken, vorallem bei meinem Hoster ist fast schon mehr als die oben genannten Kisten nicht drin bzw. das sind dann alles Sonderserver mit langen Vertragslaufzeiten und nicht gerade mehr so günstig - vorallem Bandbreite auf 1Gbit wird ein Problem.

Also was dann?
Clustern?
MEGA DB Server mit 12,16,24,32 oder gar 72GB RAM? (z.B. Dual Quadcore Xenon mit 24GB RAM)
Großer DB Server mit 12-xxGB RAM und zusätzlich per SSD unterstützen (zu den Lastspitzen als Beispiel)
Die DB komplett umschreiben und extrem Optimieren? (wird man wohl später auch nicht drum rum kommen)

@D4F

Naja ein DualCore ist natürlich nicht das gelbe vom Ei für einen sollchen DB Server. Allerdings wie stark ist dieser DualCore, eher ein kleiner mit knapp bzw. knapp über 2GHz oder geht dieser auch schon in die Region von 2,8 - 3,2GHz?

Wie genau meinst du die möglichkeit von Multiserver tauglichkeit? Memcached ist mir noch nicht so der Begriff, kurzes Googlen hat mir noch nicht so viel erklärt über das Memcached.

 

[d4f]

Der Dualcore war ein Core2Duo mit 2.33 Ghz, Bezeichnung ist mir entfallen.
Aktuell schnurrt das ganze, per Openvz (ich weiss, nicht optimal ) vom Rest getrennt, auf einem sonst relativ leeren Core i7.

Als ich von Multiserver sprach meinte ich Clustering.
Frueher oder spaeter wirst du dich, sofern das Projekt erfolgreich wird, mit Clustering auseinander setzen muessen sowie mit Cloudtechniken und Geolokalisierung, eventuell sogar dezentralisierten Kommunikationssystemen, DHT, Replikatoren, DNS-Listen, ...

Memcached ist ein Ram-basierender clusterfaehiger Cache mit hoher Leistung aber ohne Verfuegbarkeitsgarantie. Sprich das System garantiert nicht dass ein EIntrag den du vor 5 Sekunden getaetigt hast noch vorhanden ist oder geloescht wurde um Platz fuer anderes zu schaffen...
Meistens wird er genutzt um das Datenbanksystem von vielen SELECT-Anweisungen zu entlasten.

Allerdings wage ich zu behaupten dass 1000 Server von einer ordentlichen Hardware/Software locker weggesteckt werden sollte. Aktuell laufen ueber 800 einzelne Psychostats-Installationen auf meinem Projekt mit einem durchschnittlichen Update-Intervall von rund 20-30min.
Bei den Tech-Tests zu meiner Eigenentwicklung machten festplatten-basierende MySQL-Datenbanken ab etwa 2-3 Mio Datensaetzen schlapp.
(Test war: finde die 10 insgesamt best-rankenden Spieler (von 1Mio) von einer zufaellign Auswahl aus 5-20 Gameserver (in einer Liste aus 10'000 GameServer ) )

Herausfordernder wird es das ganze -also das Einlesen der UDP-Pakete, Verifizierung des sendenden Hosts und DoS-Schutz, Berechnung der Aktion, und Durchfuehrung der SQL-Kommandos zu Stosszeiten zu bewaeltigen, wobei allerdings geolokalisierte Berechnungsserver einen Grossteil uebernehmen koennten.

Die Bandbreite sollte fuer einkommende Pakete nicht sehr hoch sein muessen, die UDP-Pakete sind relativ klein. Inkl. FTP-Overhead und MySQL-Kommandos durch die externen Frontends liegt die Bandbreite bei meinen Psychostats meistens um 1Mb/s.

Beachte allerdings dass sich ein Spieler sehr schnell hochschummeln kann indem er entweder gefaelschte Pakete schickt (sofern die Border-Gateways UDP-Pakete mit inkorrektem Absender nicht rejecten) oder vom Gameserver-Root (beispielsweise durch Mattie's shell-addon) UDP-Pakete mit inkorrekten Angaben sendet!

 

[NacKteOmA]

An Cluster habe ich ebenfalls gedacht. Ein NDB MySQL Cluster, nachteil nur wie ich gelesen habe ist das der komplette Cluster via RAM arbeitet. Okay das macht natürlich eine wirklich gute Performance. Nur muss man dadurch den Wert der Replikationen innerhalb des Clusters hochsetzen, was ja praktisch eine Spiegelung ist. Was natürlich zur folge hat das man einige Server mehr brauch die einfach nur als Replikator arbeiten. Man benötigt nachher 20... 30 oder wieviel Server auch immer um einfach nur eine 100GB große DB in den RAM der ganzen Cluster Clients zu laden. Das ist dann auch wieder ein enormer Kostenfaktor. Wie man die DB nun richtig Clustert ist mir so einwenig ein rätsel.

Memcached ist eine PHP Erweiterung wenn ich das richtig sehe oder? Damit soll dann der Webfronted Server nicht alt zu sehr die DB Belasten indem die/der Webserver/Webfronted einfach viel Cached, sehe ich richtig oder? Macht natürlich Sinn - zumal das garnicht unbedingt das Problem seit wird später 2-3 Webserver mit einen ticken mehr RAM zu holen und diese dann über Memcached einen großen Cache zu Produzieren.

Angedacht hatte ich nach der BETA Phase die kompletten Server bei OVH einzurichten, denn hier gibts die möglichkeit des VLANs, Interner Traffic Gratis, Server mit 1Gbit Anbindung, ebenso Ungedrosselte 100Mbit Server.

Z.b. könnte es so aussehen.

DB Cluster (1) aus folgenden Servern

SP-10 Hybrid (bezeichnung bei OVH)
Intel Corei5 - 4x 2.66+ GHz
8GB DDR3 RAM
2x 80GB SSD Intel X25-M
2x 750GB SATA2
Bandbreite: 100Mbit - interner Traffic Gratis

Benötigt man mehr CPU, RAM, vorallem mehr Bandbreite wäre für 30€ mehr pro Server folgendes drin

DB Cluster (2)

EG-10 Hybrid
Intel Xeon W3520 - 4x 2x 2.66+ GHz (Turboboost bis 2,93GHz)
12GB DDR3 RAM
2x 80GB SSD Intel X25-M
2x 750GB SATA2
Bandbreite: 1Gbit - interner Traffic Gratis

Beide Systeme sind auch ohne SSD für etwas weniger € im Monat möglich.
Der Cluster würde dann auch via VLAN zusammen gehangen werden.

Der Pharser, sprich der Server der die Logs der Gameserver erhält und diese "Auswertet" bzw. Wertet und diese an die DB weiterleitet. Hier wird unteranderem auch viel Bandbreite nach außen benötigt bzw. bei den meisten Hostern mit Flat wird ab 2TB gedrosselt, was einen guten Flaschenhals macht. Dafür würde dann die Unmetered Serie sehr gut sein.

Pharser
Intel Core2Duo - 2x 2.33+ GHz
2GB RAM
2x 500GB HDD
100Mbit - keine drosselung, allerdings niedrige priorität

Diese könnte man praktisch in Reiheschalten via LoadBalancing IP, somit kann man weiter auf 200,300,400.... Mbit Bandbreite Skalieren.

Fürs Webfronted könnte man den nächst größeren Server aus der Unmetered Serie nehmen und bei Bedarf auch via LoadBalancing IP zusammenschalten oder auch aus der normalen Serie, jenachdem wieviel Traffic die nach außen benötigen.

Als Backupserver kann man natürlich den Storage Server bei den nutzen.

Kostentechnisch liegt man dann wohl bei 300-1000€ Grenze nach oben natürlich offen. Jenachdem wieviel Server z.B. für den DB Cluster benötigt werden.

 

[d4f]

Ein NDB MySQL Cluster

Cluster ja, aber warum MySQL? VErsteh mich nicht falsch, MySQL ist prima und leistungsfaehig - aber fuer solche Groessen schlichtwegs ungeeignet...

Falls dein Projekt worldwide sein soll dann schau dir mal HBase an, welches auf dem BigTable-Whitepaper basiert und auf Hadoop aufsetzt.
http://hadoop.apache.org/hbase/

Mit den aktuellen Ideen - Memcached, no SPOF, HBase, evtl Hphp, ... sind wir hier bedeutend ueber dem urspruenglich von dir skizzierten Arbeitsaufwand. Ein Projekt das solche Techniken benoetigt rechnet man in Wochen, nicht Tagen.

OVH-Server sind schoen und gut, haben aber in der bezahlbaren Version fuer meinen Geschmack mit zu wenig RAM gesegnet...
Mit VLAN, Gigalan und weiteren Optionen bewegst du dich allerdings auch wieder in einen teuren Bereich...

Laut meinen Netzwerksgraphs benoetigen die Parser fast keine Bandbreite - einkommende Pakete haben jeweils nur sehr wenig Nutzlast...

 

[NacKteOmA]

Weise ist der d4f

Also bezüglich des MySQL Clusters, das war nur so meine erste Idee. Da natürlich HLstatsX bzw die Weiterentwicklung HLstatsX:Community Edition (CE) auf MySQL basiert. Tiefe Kenntnisse in die Datenbank(en) besitze ich leider nicht. Leider besitze ich keine Programmierkenntnisse, drum wird auch die Modifizierung von HLstatsX:CE mit einer zweiten Person abgehandelt.

Problem ist natürlich, wer kennt sich mit anderen DB System aus und kann dann das HLstatsX:CE System darauf umschreiben, man wird dort dann wohl den Perl Daemon umschreiben. Was zur heißt das diese Person auch noch Perl beherrschen sollte. Die meisten Personen aus meinem Umfeld kennen MySQL und dann hört es schon fast auf vielleicht nochmal PostgreSQL und dann ist Ende. Somit kommt noch ein hoher Zeitlicher Aufwand für das kennenlernen einer neuen DB. Deswegen kam mir erstmal die Idee bei dem bisherigen System zu bleiben und dieses größer auszubauen - deshalb MySQL Cluster, aber nach 5min lesen schien mir dieser eh total unnützlich für mein vorhaben zu sein.

Nach nun einwenig Lesen von HBase klingt es im Grunde doch recht interessant, nach der Selbstbeschreibung ist es im Prinzip genau das was ich bräuchte, wenn es ähnlich Performant läuft wie Google's BigTable dann aufjedenfall.

Was mich interessiert, wie sieht später ein Cluster mit HBase aus? Wieviel Server sind dort z.B. das Minimum, was für verschiedene Clients/Nodes gibt es. Wie beim MySQL Cluster, dort wird erstmal ein Management Server benötigt, dazu einen SQL Knoten und zwei Datenknoten. Sprich wie würde dort das Schema bzw. der Befehlablauf aussehen?

Mit der Bandbreite des Parsers hast du recht. Ich habe grad mal selber nachgemessen. Bei 1000 Gameserver würde man vielleicht bei 200-500GB liegen, das ist schon wirklich wenig.

Die Frage der Verifizierung der Datenpackete habe ich mich noch nicht so sehr gekümmert. Problem ist, das mir dazu tatsächlich schwer etwas einfällt.

d4f dir aufjedenfall schon mal einen großen Dank. Deine Beiträge in diesem Thema sind mehr als nur Hilfreich

 

[d4f]

Weise ist der d4f

Nicht unbedingt, aber mit einem ausgepraegten Spieltrieb was neue Techniken und Ideen betrifft gesegnet
(Aka: der Resetbutton auf meinen Heimrechnern wird regelmaessig entstaubt und die Macrium/Debian-BootCD werden nie staubig)

Ueber HBase kann ich dir allerdings noch nicht viel aus eigener Erfahrung erzaehlen, mich damit wirklich auseinander setzen wollte ich erst diesen Sommer fuer ein CDN-System.
HBase benoetigt eine einzige Machine am Anfang, ist jedoch in solch einer Konfiguration nicht ausfallsicher. Erst ab 2 Server hast du ein no-SPOF setup.

wenn es ähnlich Performant läuft wie Google's BigTable dann aufjedenfall.

Leider gibt es keine Benchmarkwerte zu Bigtable da Google die Datenbank -der Schluessel zu ihrem Erfolg- unter Verschluss haelt und nur ueber die AppEngine Zugriff auf die API gibt.
Die Skalierbarkeit und Leistungsfaehigkeit beweist jedoch Yahoo defintiv, laut Benchmarks soll die RandomAccess-Zugriffszeit denen von MySQL ebenbuertig sein.

Die Verifizierung der Pakete kannst du zumindest teilweise durchfuehren indem ueberprueft wird ob der Spieler ueberhaupt auf dem Server ist, wie wieviele Kills er erreicht hat und wie lange die Spieldauert ist. Allerdings werden Deathmatch-Server dein Ranking kraeftig durcheinander mischen, es sei du erkennst diesen Fall und verringerst fuer solche Server die Gewichtung enorm.

Man muesste die Performance der PHP-Compiler (Roadsent, Hiphop, bcompiler, ...) mit der von Python und Perl vergleichen um die optimale Scriptingsprache fuer die Backend-Architektur zu finden - allerdings waere reines C/++ die leistungsfaehigste, wenn auch komplizierteste Loesung
(Meine Faehigkeiten in C# begrenzen sich auf das Umbiegen von syscall's ^^)

Deine einzige Bandbreitensorge sollte durch die Datenbank entstehen, wobei HBase wahrscheinlich intelligent genug verteilt um die einzelnen Nodes vor Ueberlastung zu schuetzen.
Allerdings hab ich mich wie gesagt noch nicht vollstaendig damit auseinandergesetzt - ein lokaler Testcluster auf 5-8 Machinen ist erst im Sommer geplant.
(Ich hab noch ein Abi zu schaffen, wenn ich jetzt meinem Spieltrieb nachgebe kann ich zwar den Lehrer genaustens die Datenbankstruktur erklaeren aber nicht die Relatitivaetstheorie ^^)