Neue HA-Speicherinfrastruktur: Ceph

Am vergangenen Wochenende haben wir mal wieder fleißig in unserem kleinen Rechenzentrum gearbeitet, es stand der lang ersehnte große Umbau unserer Speicherkomponenten an. Wie ihr euch vielleicht erinnert haben wir bisher NFS eingesetzt, um Netzwerkspeicher für interne Dienste zur Verfügung zu stellen. Dieses Setup hat uns aber nie wirklich zufrieden gestellt, weder hinsichtlich der Ausfallsicherheit, noch der Performance.Da wir stets den Ansatz verfolgen unsere Dienste redundant auszulegen, haben wir zuvor auch einige Zeit investiert dies mit NFS umzusetzen. Hierzu gibt es eigentlich verschiedene, etablierte Strategien, z.B. die Replikation der Daten auf einen zweiten NFS (z.B. mit Hilfe von DRBD) und dem Wechsel einer virtuellen IP, die den Speicherdienst anbietet (z.B. mit Heartbeat). Leider haben wir diese Variante nie wirklich stabil zum Laufen bekommen, einiges lag dabei im Argen. Eventuell waren auch unsere sehr inhomogenen Server ein Grund dafür.

Zu der Zeit dieser Spielereien haben wir uns bereits Gedanken über Alternativen gemacht und nach verteilten Dateisystemen Ausschau gehalten. Schon damals sprang uns Ceph ins Auge, das mit einer einheitlichen Mischung aus Object- und Blockstorage sowie einem POSIX kompatiblen Dateisystem punktet. Vor zwei Jahren war Ceph (insbesondere CephFS) noch nicht voll produktionstauglich, was sich mit dem Release von „Jewel“ aber geändert hat und uns den Anlass gab unsere Migration nun durchzuführen.

Vorbereitende Maßnahmen

Man kann es eigentlich nicht oft genug wiederholen: Backups müssen von einer Produktivumgebung existieren und auch funktionieren (sonst steht man am Ende dumm da, so wie GitLab im Februar 2017). Dies gilt schon im alltäglichen Betrieb und natürlich umso mehr, wenn man an einer so zentralen Komponenten wie dem Speicherserver arbeitet. Daher haben wir zunächst einmal den Moment genutzt und ein kleines Nebenprojekt durchgezogen, nämlich eine neue Maschine für Backup und Archivierung aufzusetzen.

Mit einem vollständigen Backup auf eine externe Festplatte konnte der Umzug dann losgehen. Als zentrales Element in unserem Cluster hostet der Speicherdienst nicht nur Userverzeichnisse unserer Vereinsmitglieder, um sich an unseren Bürorechnern anzumelden, sondern auch Webseiten, Code-Repositories und vieles mehr. Alle unsere Dienste sind down, wenn der Speicher offline geht, deswegen wurde für den Zeitraum des Umbaus auch nur unsere Wartungsseite angezeigt.

Umzug

Als erstes haben wir unsere beiden Speichermaschinen heruntergefahren und mit Debian Jessie in der aktuellsten Version neu installiert. Die Konfiguration der beiden Kisten könnt ihr unter der Hardwareseite einsehen. Das Besondere an ihnen ist natürlich die Ausstattung mit vielen Festplatten, insgesamt 8TB auf jeweils vier, bzw. acht Festplatten sind darin verbaut. Wir haben uns dazu entschieden die Festplatten als einzelne OSDs zu betrachten und in Ceph zu verwenden, daher haben wir die RAID-Konfiguration in den Adaptern gelöscht und alle Platten einfach nur durchgeschleift. Jeweils eine Platte wurde als dedizierte Partition für die Ceph-Journals vorgehalten. Dies ist uns aktuell ein größerer Dorn im Auge, da sowohl viel Speicher dafür verloren geht, als auch die Performance nicht ideal ist. Mit zwei SSD-Festplatten, wie etwa die Intel S3610, ließe sich noch ordentlich an der Performanceschraube drehen. Das Betriebssystem wurde jeweils auf kleinen 160er Platten im RAID1 installiert, diese sind nur gebraucht und könnten uns jederzeit kaputt gehen, daher die Absicherung.

Nach der Installation (welche Dank unserer PXE-Konfiguration sehr einfach geht) mussten wir nun also Ceph installieren und konfigurieren. Da Ceph jedoch nicht nur Speicherknoten benötigt, sondern auch Metadatenserver, haben wir unsere drei VM-Hosts mit einbezogen und uns entschieden die Metadaten darauf abzulegen, denn diese „bare metal“ Maschinen besitzen als einzige genügend Leistung für die Berechnung der Hashes. Die Ceph-Entwickler empfehlen dringend, dies nicht auf VMs durchzuführen.

Die eigentliche Installation und Konfiguration von Ceph ist außerordentlich gut dokumentiert (zu finden unter http://docs.ceph.com/docs/jewel/rados/deployment/) und dank des Tools ceph-deploy mit wenigen Kommandos vollständig aufgesetzt.

Nach dem Setup der OSDs und der Metadatenserver stand anschließend noch die Installation von CephFS auf den Clients an, welche den Netzwerkspeichern als Filesystem einbinden wollen. Hier gab es jedoch zunächst lange Gesichter beim Bootvorgang, denn unsere Kisten wollten zunächst nicht wieder ordentlich starten. Der Fix war jedoch denkbar einfach, wir mussten in der Dateisystemtabelle (/etc/fstab) nur festlegen, dass das CephFS ein Netzwerkdateisystem ist, hier ein Beispieleintrag:

# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/vda1 during installation
UUID=6e7e7026-0cc7-4c1f-9d75-257924d6c9fe /               ext4    errors=remount-ro 0       1
# swap was on /dev/vda5 during installation
UUID=df68ee0d-e717-45cb-a8e1-b47f69a4da9a none            swap    sw              0       0
# CephFS
mon1.olydorf.mhn.de,mon2.olydorf.mhn.de,mon3.olydorf.mhn.de:/test        /var/test      ceph    name=build,secretfile=/etc/ceph/test.secret,_netdev    0       2

Die entscheidende Einstellung ist hierbei das _netdev Flag, welches dem Betriebssystem mitteilt, dass der Mount erst erfolgen soll, wenn die „unteren“ Schichten sauber gestartet sind (ohne NIC wird es z.B. schwer die Namen aufzulösen :-)).

UPDATE 03.11.2017:

Ceph läuft mittlerweile seit fast sechs Monaten produktiv bei uns und wir haben bisher nur ein einziges Problem gehabt. Unsere Mailserver basierend auf Dovecot hatten unter Debian Jessie noch arge Probleme mit dem mbox-Format auf CephFS. Wir hatten dauerhaft steigende CPU- und RAM-Auslastung, bis die Services nicht mehr reagierten. Nach dem Update auf Debian Stretch ist dies jedoch gefixt und wir genießen seitdem unseren störungsfreien Storage-Service. Lasttests haben jedoch unsere initialen Eindrücke bestätigt, der Cluster gerät beim Schreiben größerer Datenmengen schnell an sein Limit, weil unser Journal sehr klein/langsam und unsere Platten recht schwach sind. Neben der Installation von SSDs wird eventuell auch ein Upgrade des Caches auf den RAID-Karten eine Maßnahme sein.

 

Veröffentlicht in News, Projekte