WP-Blo[g|ck]

„Was ist denn eigendlich mit dem Toolserver los? Alles ist langsamer und einige Tools gehen gar nicht“ werde ich in letzter Zeit häufiger gefragt. Ich möchte daher in diesem Beitrag mal die Ereignisse zusammenfassen, die zur jetzigen Situation geführt haben.

Vorgeschichte
Alle Projekte der Wikimedia-Foundation sind in (aktuell) 7 Clustern verteilt (die riesige englischsprachige Wikipedia zum Beispiel konsumiert Cluster 1 komplett, die deutschsprachige Wikipedia ist auf Cluster 5 zusammen mit ein paar kleineren Wikis, commons belegt s4). Jeder Cluster besteht aus einem Master- und mehreren Slave-Datenbankservern. Aktuell hat die Foundation dafür 22 Datenbank-Server im Einsatz. Der Toolserver hat 5 Datenbank-Server.
Nun muss man kein mathematisches Genie sein um zu sehen, dass 5 Server nicht für 7 Cluster ausreichen. Daher spiegeln (replicate) wir die Daten von mehreren Foundation-Servern auf 1 Toolserver-Server. Dieser Prozess krankt an mehreren Stellen; z.B. kann das MySQL eigene Replication-Programm gar nicht von mehreren Master-Servern kopieren, sondern nur von einem. Aus diesem Grund haben wir eigene Programme geschrieben, die die Daten kopieren. Das erzeugt seine ganz eigenen Probleme, auf die ich aber hier nicht näher eingehen will.
Da abzusehen ist, dass der Toolserver nicht im erforderlichen Ausmaß mit weiteren Datenbank-Servern ausgestattet wird (dazu müssten mindestens 9 weitere Server angeschafft werden), gleichzeitig aber die aktuelle Lösung unbefriedigend ist, suchten wir nach Alternativlösungen. Eine Idee dazu war es, mehrere MySQL-Instanzen auf einem Server laufen zu lassen. Um dies zu testen, wurde einer der Datenbank-Server (Hyacinth) von seinen normalen Aufgaben entbunden und von River entsprechend konfiguriert. Hyacinths normale Aufgabe ist es, als Ersatz für Cassia zur Verfügung zu stehen. Cassia trägt die Datenbanken s3, s4, s6 und s7. Nachdem River Hyacinth entsprechen aufgesetzt hatte und die Datenbanken alle wieder neu importiert hatte, begann das Testen.

Ausfall
Am 31. Juli versagte überraschend Cassias Hardware. Nun gab es keinen einsatzbereiten Server für die Cluster s3, s4, s6 und s7 mehr. Wir pflegen eine Kopie von s4 (commons) auf jedem Server, so das dieser Ausfall nicht so kritisch war; s3, s6 und s7 waren aber erstmal weg. Hyacinth befand sich noch im Test-Stadium und ein Rückkehr zum Zustand vor dem Testen war auf die Schnelle nicht machbar. Da wir aber keine Alternative hatten, mussten wir Hyacinth so einsetzen wie er war.
Da mehrere MySQL-Instanzen auf Hyacinth laufen, teilen die sich natürlich auch den Arbeitsspeicher; dieser muss also so verteilt werden, dass keine Instanz die Andere aus den Speicher drängt. Da das Testen auf Hyacinth aber noch nicht abgeschlossen war, tun die Instanzen genau das. Zusätzlich kommt noch ein Bug in MySQL dazu, der jede Instanz mehr Arbeitsspeicher verbrauchen lässt als sie eigentlich darf. Um die maximale Menge zu verändern, die eine Instanz verbrauchen darf, zu verändern muss man sie neu starten. Dann muss man einige Stunden (oder besser einen Tag) warten um zu sehen, wie sich der Speicherbedarf entwickelt; das Alles dauert einfach und Alles ist langsamer.
Weiterhin verfügt Hyacinth nicht über genügt Festplatten und Festplattenplatz um alle Datenbank-Instanzen aufnehmen zu können; der kleinste und neuste Cluster (s7) musste daher teilweise mit einem externen Festplattenarray vorlieb nehmen. Ob das ein Problem ist, sollte eigentlich das Testen zeigen.
Ein weiteres Problem betraf das Aufteilen an sich. River hatte bereits 22. Juni die Toolautoren gebeten, zu benennen welche Benutzer-Datenbanken auf welche Instanz gehören. Im alten Setup (also als s3, s4, s6 und s7 in einer Instanz zusammen waren) gab war es egal ob die Toolautoren sich zu s3 oder zu s4 verbanden – ihre Benutzer-Datenbank war da. Durch das Aufteilen macht es aber einen Unterschied ob man sich zu s3 oder zu s4 verbindet; Datenbanken sie auf s3 liegen sind in s4 nicht da. Die Resonanz der Toolautoren war eher verhalten und so wurden 99% der Benutzerdatenbanken auf s3 eingerichtet. Das war erstmal kein Problem, da die Toolautoren ja zumeist Cassia nutzen und so gar nicht merkten, dass es irgendwann auf Hyacinth (nach Ende des Tests) ein Problem geben würde. Nach Cassias Ausfall wurde das Problem aber akut; Tools die eine Benutzerdatenbank auf s4 (commons) benötigen können diese nicht mehr finden, denn sie liegt auf s3. Das ist der Grund für den Ausfall vieler Tools. Es wird einige Zeit dauern, bis die Toolautoren ihren Code angepasst haben.

Ich hoffe, ihr versteht nun etwas Besser, warum der Toolserver (für gewisse) Tools langsamer ist als sonst und warum einige Tools nicht funktionieren. Für Rückfragen könnt ihr gerne die Kommentarfunktion benutzten oder mich im Chat ansprechen.

Der Toolserver hat nun einen bezahlten hauptamtlichen Admin — River Tarnell. River ist der Senior-Admin des Toolservers und seit Anfang an dabei. Möge die weitere Zusammenarbeit genauso gut laufen, wie bisher .

Leider wurde von Seiten des Vereins mal wieder verschlafenvergessen, die Kollegen vorher zu informieren.

Quelle.