Server Virtualisierung mit Ganeti

Auf der Suche nach einer für uns passenden Virtualisierungslösung haben wir uns in den letzten Jahren verschiedene Möglichkeiten angeschaut. Folgende Bedingungen haben wir dafür definiert:

• es soll Open Source sein
• es soll keinen zentralen Storage verwenden
• die Wiederherstellungszeit im Fehlerfall soll kurz sein

Evaluiert haben wir verschiedene Varianten, wie z.B. Ceph oder GlusterFS in Verbindung mit KVM und libvirt. Hängen geblieben sind wir aber schlussendlich bei Ganeti – das bündelt KVM, LVM und DRBD zu einem skalierenden Virtualisierungscluster. Ein Ganeti-Cluster besteht dabei aus zwei oder mehr Servern („Nodes“ in Ganeti-Sprech). Für eine virtuelle Maschine (Instance) reserviert Ganeti immer auf zwei Nodes im Cluster die zugehörigen virtuellen Festplatten in Form von LVM-Volumes und hält sie per DRBD synchron. Wenn also ein Node ausfällt, kann die Instance auf ihrem jeweiligen Ersatz-Node weiter betrieben werden. Das ist jetzt nicht direkt „High-Availibility“, aber für unseren Einsatzzweck nah genug dran. Steuern lässt es sich über die Kommandozeile oder über eine REST-API – auf diese Weise können Instances erstellt, verwaltet, (live-)migriert werden oder auch auf einen anderen Node verschoben werden.

Ganeti Control Center

Um das Management eines oder mehrerer Ganeti-Cluster etwas einfacher zu gestalten, ist an einem Openfriday als kleine Fingerübung ein Web-Frontend rund um grundlegende Funktionen der REST-API entstanden. Orientiert haben wir uns dabei natürlich stark an unserem Einsatz-Szenario von Ganeti. Das bedeutet konkret, dass wir die Netzwerk-Anbindung über Linux Bridge Interfaces regeln, die Instances per DRBD auf einen zweiten Node spiegeln und dass diese eigenständige virtuelle Maschinen mit Partitions-Tabelle/GRUB sind. Alternativ kann Ganeti auch das Netzwerk-Management übernehmen, Instances als “standalone” Systeme (also ohne DRBD) betreiben und einen auf dem Node liegenden Kernel booten, so dass die Instances nur noch aus einem Dateisystem bestehen. Da wir allerdings eigenständige virtuelle Maschinen mit verschiedenen Debian Versionen von einem existierenden libvirt Setup migrieren mussten, haben wir dieses Format einfach beibehalten.

Nachdem sich das Frontend intern bewährt hat lag die Entscheidung nahe, es für alle zugänglich zu machen und bei Github zu veröffentlichen. Natürlich stellt sich sofort die Frage: “Hat das nicht schon mal jemand gebaut?” Und hier lautet die Antwort wie so oft: Ja. Allerdings sind die vorhandenen Frontends entweder unmaintained und in aktuellen Umgebungen nicht mehr so leicht aufzusetzen oder zielen auf einen gänzlich anderen Usecase von Ganeti ab.

Pitfalls?

Es ist relativ leicht, mit Ganeti einfach mal zu starten. Wenn ihr jetzt auch Spaß daran bekommen habt, geben wir euch hier mal einige Dinge mit, die wir auf dem Weg so gelernt haben.

Verteilung der Instances

Während man wenige Instances noch relativ gut „frei Schnauze“ verteilen kann, wird es jenseits der 30 Stück irgendwann nicht mehr so leicht. Das gilt vor allem, wenn man gewährleisten will, dass der Ausfall einer Node nicht zu einer Überlastung der verbleibenden Nodes führt. Um diesem Anspruch gerecht zu werden, liefert Ganeti ein Tools namens ‘hbal’ mit, das nach einem deterministischen Algorithmus die Instances automatisch im Cluster verteilt. Somit kann man eine neue Node mit in das Cluster aufnehmen und hbal anschließend die Aufgabe überlassen, alles neu auszubalancieren. Die Verteilung erfolgt anhand einiger “hard facts”, beispielsweise wie viele Instances man pro physikalischer Disk erlauben möchte, wie das Verhältnis von virtuellen zu echten CPUs sein darf, ob der Arbeitsspeicher für die aktiven sowie passiven Instances ausreicht und so weiter. Optional kann man auch noch die aktuelle CPU Auslastung hinzu ziehen – dadurch variieren aber die Ergebnisse von hbal in jedem Durchlauf und es ist eben nicht mehr deterministisch.

Unterschiedliche Hardware

Wann immer man mit DRBD in Verbindung kommt, spielt die Gleichheit der Hardware (oder im Minimum die der I/O Systeme) eine große Rolle. Das gilt für einen “einfachen” Active/Standby Datenbank Cluster, ebenso wie für einen Cluster mit 15 Ganeti Nodes, die sich alle untereinander ihre Volumes spiegeln. Da man nicht unbedingt mit 15 gleichen Nodes startet, sondern der Cluster ggf. zu verschiedenen Zeitpunkten wächst, hat man früher oder später unterschiedliche Hardware im Cluster. Um die Instances nicht unnötig zu bremsen, kann man sich mit dem Gruppen-Feature von Ganeti behelfen: Wir fassen ähnliche Hardware in einer Gruppe zusammen und hbal wird anschließend vorhandene Instances nur innerhalb einer Gruppe ausbalancieren und neue nur Nodes aus der selben Gruppe zuweisen.

Dimensionierung von Nodes und Instances?

Bei Ganeti zahlt es sich aus, nicht die “ganz große” Hardware zu kaufen. Wer 40 Instances auf einer Node betreiben möchte, muss auch einen entsprechenden Zeitaufwand bei Maintenance Tasks einplanen, um den Node leer zu räumen (oder eben bei einem Totalausfall den Rebuild sämtlicher DRBD Devices abzuwarten). Wenn man sich dagegen mit 10-15 aktiven Instances pro Node zufrieden gibt, schmerzt ein Ausfall nicht so sehr. Wir versuchen es ebenfalls zu vermeiden, große Instances in Bezug auf ihre Disk(s) zu konfigurieren – in der Regel reichen 40 Gigabyte pro Instance aus, die sich dann auch entsprechend zügig im Cluster verschieben lassen.