Cluster umziehen für Einsteiger – ein Praxisbericht

Was in unserem eMagazin bisher eindeutig zu kurz kommt, sind Praxisberichte aus unserer Technik. Neben Zimbra und Nextcloud beschäftigen wir uns nämlich vor allem mit Servern. Am liebsten sind uns dabei viele Server, die wir für unsere Kunden in einem hochverfügbaren Cluster betreiben. In diesem Artikel geht es um den Umzug eines Clusters, der birgt nämlich fast immer Überraschungen, da „große“ Webseiten meist über eine lange Zeit gewachsen sind.

Der Anfang der meisten Cluster-Projekte ist ein harmloser Anruf

Irgendwann im letzten Herbst ruft uns eine Agentur an, mit der wir gern und gut zusammenarbeiten.

„Wir haben da im Sommer ja schon über diese eine Website von einem Kunden geredet, die möchten wir jetzt gern zu euch umziehen.“

„Ja klar, gerne. Wie sieht das Projekt denn aus?“

„Hmm – so genau weiß ich das auch nicht, aber der Kunde hat mir eine Liste der Server gegeben, die laufen in einem Server Cluster, ich schicke die mal rüber.“

Es kommt eine Liste mit ca. ein bis zwei 19″-Schränken voll Hardware an. Aus den Hostnamen lässt sich so grob die Funktion des Systems ableiten, RAM und HDD stehen auch dabei, der Rest bleibt unklar. Erfragen lässt sich das auch nicht so ohne Weiteres, denn Kunde und alte Agentur mögen wohl nicht mehr so gern miteinander reden. Immerhin gibt es den Hoster der Systeme, der ist ansprechbar, kompetent und kooperativ.

Ein paar Tage später bekommen wir OpenVPN-Zugangsdaten und Kontaktdaten des Hosters. Zeit also, sich auf dem System umzusehen.

Überraschung – die ganze Hardware aus der Liste gibt es gar nicht mehr. Was es gibt, sind zwei Xeon-Server, auf denen ein Stapel VMs die Anwendung abbilden.

Das Setup sah erst mal so aus:

PFSense-Firewall ‚vorn‘ am Netz, die HTTP und HTTPs auf die nachgelagerten
Webserver verteilt.
Zwei Nodes mit Varnish als Cache, NginX zum SSL-Offloading und als
Webserver. PHP in der FPM-Variante bedient PHP.
Zwei Nodes mit MySQL im Master/Slave-Betrieb, auf denen auch noch Redis als
Cache läuft.

Ein wesentliches Problem des Kunden war die Datenbankperformance.

Hier existieren Zeiten, zu denen relativ viele Zugriffe erfolgen, die auf die Datenbank durchgehen, also nicht von Varnish oder Redis abgefangen werden können. Regelmäßig zu diesen Zeiten machte die Datenbank ‚zu‘. Im Ergebnis lief dann die Anzahl der PHP-Prozesse hoch, bis hin zu dem Punkt, wo keine neuen Prozesse mehr geforkt werden konnten und die Website dann nur noch einen 503er-Serverfehler anzeigte.

Auf Bitte unserer Kollegen haben wir uns die Performancecounter der Datenbank angeschaut. Als Tabellentyp wird im Wesentlichen InnoDB genutzt, so weit, so gut. Neben diversen kleineren Optimierungsmöglichkeiten stach heraus, dass der InnoDB Buffer Pool viel zu klein war. Die Datenbankserver nutzten also die ganzen schönen 64 GB überhaupt nicht, sondern lasen die Daten immer von der Festplatte. Nach Abgleich mit dem sonstigen Speicherbedarf des Servers (Redis war ja auch noch aktiv) haben wir den Innodb_buffer_pool auf 24 GB gesetzt. Im Ergebnis wurde die Antwortzeit der Datenbank massiv besser, Master-Slave-Lags traten kaum noch auf, und das Zulaufen der Datenbank bis hin zum Zusammenbruch der Anwendung war Geschichte.

Danger Danger!

Oh, wo liegen sie denn, die Bilder? Das war eine Frage, die uns lange beschäftigt hat. Die Anwendung ist in PHP mit dem Symphony Framework geschrieben und sehr bildlastig. Als die Anwendung geschrieben wurde, hatte man sich dazu entschieden, die Bilddateien in einem Object Store abzulegen. Dafür wurde MogileFS ausgewählt. MogileFS wurde von Danga Interactive entwickelt. Das waren die Leute, die livejournal.com gemacht haben und z. B. auch Memcached entwickelt haben. Die Firma gab es von 1998 bis 2007. Die Domain läuft noch, und es gibt ein paar Infos zu der dort entwickelten Open-Source-Software.
– http://www.danga.com/

Die MogileFS-Server liefen auch als KVM-VMs auf den beiden Servern. Als wir uns dort einloggen konnten, war klar, dass es sich um einen Ausflug in die Vergangenheit handelt. Ubuntu 12.04 mit ein paar Hundert Packages, die nicht aktualisiert worden waren. Virtuell klebte an der Tür ein Sticker mit den Worten „nix anfassen um Gottes willen“. MogileFS ist eine Object Storage ähnlich wie Amazon S3 oder Openstack Swift. Als wir im letzten Herbst da reingeschaut haben, war der letzte Eintrag im Changelog von 2014. Um so überraschter bin ich gerade, dass hier im Januar wieder jemand an dem Projekt gearbeitet hat.

Wer mag – https://github.com/mogilefs.

Aber zum damaligen Zeitpunkt war die Software definitiv Abandonware und keine Option für die Zukunft. Das Problem war nun, dass uns niemand sagen konnte, ob diese Daten überhaupt noch gebraucht werden – denn in der Konfiguration der Anwendung standen die
Server noch drin. Es gab zwar die Aussage, dass die Daten zu Amazon S3 migriert worden seien, aber eben auch keine Gewähr dafür. Hinzu kamen üble Anekdoten über Unfälle, die bei Versuchen der Migration dieser Daten geschehen waren, wir waren also gewarnt.

Also haben wir uns Tools gebaut, die uns gezeigt haben, ob Zugriffe auf die MogileFS-Server stattfanden. Da auf den Servern die Devise „nur gucken, nicht anfassen“ galt, haben wir die entsprechenden Netzwerkports überwacht. Nachdem nach 14 Tage keinerlei Zugriffe auf die MogileFS-Daten erfolgt waren, konnten wir ausreichend sicher sein, dass diese nicht mehr gebraucht wurden.

Das neue Server Cluster Setup

Wir haben folgende Komponenten verwendet:

HKN managed Firewall auf Basis Juniper SRX,
2 VMs als Proxy-Systeme:
- HA-Proxy zur Termination von HTTP und HTTPs und MySQL. Die SSL/TLS-Implementierung von HA-Proxy ist so gut, dass wir diesen Job gern vom HA-Proxy erledigen lassen und den NginX später als reinen Webserver laufen lassen.
- Varnish als In-Memory-Cache. Die beiden Server laufen im Active-Passive-Modus, das Umschalten der virtuellen IP-Adresse im Bedarfsfall wird durch keepalived mit entsprechenden Scripten realisiert.
2 VMs als Webserver, Redis und PHP-FPM.
- Als Webserver kommt NginX zum Einsatz, PHP als FPM derzeit noch in Version 7.0.
3 Systeme für den Mysql Galera Cluster.
- Wir haben uns für die Nutzung von MariaDB 10.2 und Galera als Cluster entschieden. Mit der Galera-Clustererweiterung gibt es folgende Goodies für eine MySQL Umgebung:
  - echte Active Active Cluster, Multi-Master,
  - synchrone Replikation, kein Master-Slave-Lag mehr,
  - transparent für die Anwendung,
  - Innodb wird unterstützt,
  - keine Downtime bei Wartungen,
  - kein Read-Write-Split in der Anwendung erforderlich,
  - weit skalierbar,
  - weitere Nodes im laufenden Betrieb hinzunehmbar und entfernbar.

Die Datenmigration

Da die Remoteadministration im alten System über die OpenVPN-Verbindung der dortigen PFSense-Firewall erfolgte, war der initiale Plan, hierüber auch die Datenmigration zu machen. Bandbreite war genug vorhanden, und der Netzwerkpfad war kurz. Aber das OpenVPN ließ gerade mal so irgendwas im Bereich von 20 Mbit/s durch. Da wären wir wahrscheinlich jetzt noch nicht fertig. Ob das nun eine QoS-Einstellung auf der PFSense war oder andere Ursachen hatte, haben wir nicht weiter ergründet. Wir haben dann ein IPSec-VPN aufgesetzt, das lief problemlos und hat auch so 600 Mbit/s an Durchsatz gebracht, ausreichend, um die Datenmengen in akzeptabler Zeit übertragen zu können. IPSec zwischen Juniper SRX und PFSense ist stressfrei einzurichten und läuft gut, auch als IKE-v2.

Planung? Weg damit, wir machen jetzt die Datenbank

Eigentlich hatten wir geplant, zuerst die HA-Proxys bei uns in Betrieb zu nehmen. Danach wollten wir Varnish, die Webserver und zuletzt dann Redis und die Datenbanken umziehen. Leider machte die Datenbank mit dem Master-Slave-Setup auf der alten Site dann doch wieder Probleme. Queries schaukelten sich auf, und die ganze Site hing. Mit wenig Zeitaufwand war die Ursache dafür dann auch nicht auszumachen.

„Sagt mal, können wir nicht die Datenbank schon mal auf den Galera-Cluster migrieren?“

Einige Stunden später waren wir dann übereingekommen, den ganzen Migrationsplan auf den Kopf zu stellen. Wir haben also die Webserver der alten Site gegen den neuen Galera-Cluster bei HKN laufen lassen, die Daten gingen über den IPSec-Tunnel. Da der Netzwerkpfad ziemlich kurz war, eigentlich hingen nur zwei Router von uns und der ECIX dazwischen, waren die Netzwerklatenzen kein Problem. Nachdem dieses Setup drei Tage lang inkl. eines Wochenendes störungsfrei und schnell gelaufen ist, konnten wir daran gehen, die weiteren Komponenten zu migrieren.

An Weihnachten? Echt jetzt?

Die Migration der weiteren Komponenten ging gut voran, und kurz vor Weihnachten war die Anwendung dann komplett bei uns lauffähig. Wir hätten gern noch einige Tests durchgeführt und Failoverszenarieren ausprobiert. Leider kamen dann „äußere Umstände“ hinzu, die eine sofortige Umstellung erforderlich machten. So mussten wir dann Anpassungen an der Varnish- und Redis-Konfiguration im laufenden Betrieb vornehmen, und auch einige Datenbankparameter mussten noch nachgeregelt werden. Am Ende haben wir Weihnachen und auch die Feiertage gut hinbekommen, und das System hat noch einiges an Reserven. Seitdem läuft das Server Cluster ohne Probleme (schnell auf Holz klopfen).