und ich endlich mehr Entlastung!!
Seit geraumer Zeit „verschwende“ ich mehr und mehr Zeit damit unsere Storageserver zu verwalten und zu überwachen. Selbst unser eigens Entwickeltes Datacenter System hat mehr mit der Verwaltung zu tun als alles andere. Das größte Problem ist und bleibt aber die Redundanz. Keines der Filesysteme auf unseren Storageservern kommt mit Redundanz daher, mal vom Raid Array abgesehen. Wenn die Maschine aber weg bricht bringt einem das beste Raid auch nichts mehr.
Redundanz muss man Extern da zubauen und ist meist auch nicht wirklich die Optimale Lösung. Gerade bei Systemen die über mehrere Standorte verteilt sind. Daher MUSS ein Ersatz her, aber welcher??
Meine Wahl fiel auf Ceph, einem Filesystem was nicht wie herkömmliche Systeme Arbeitet sondern einen Objekt Speicher darstellt. Ich hatte schon mal vor Jahren einige System mit OpenAFS, einem der Großväter der Objekt Speicher Systeme, am laufen. Aber OpenAFS ist nicht Perfekt und man hat schon mal mit einer Splitbrain Situation zu kämpfen und auch die Skalierbarkeit hat bei OpenAFS so seine Tücken.
Also WARUM Ceph?? Obwohl es doch noch nicht für den Produktiv betrieb geeignet sein soll???
Weil ich gern Wege gehe die ich nicht kenne da Sie das Leben meist viel Interessanter machen.
Ceph hat diverse Eigenschaften die andere Objektspeicher Systeme nicht haben. Zum einen gibt es keine Splitbrain Situationen mehr bzw. Ceph weiß dies zu verhindern. Das System kann sehr weit in die Breite Skalieren und man kann die Redundanz gut kontrollieren und Steuern. Somit ist Ceph ein wirkliches Cluster Storage System, zudem sind viele Bestandteile schon seit langem im Kernel enthalten was die Sache einfacher macht und nicht dazu zwingt einen eigenen Kernel zu Bauen.
Um Ceph auch mal auch Herz und Nieren zu Testen hab ich auf einem VirtualBox System einen kleinen Testcluster aufgesetzt um damit eine bisschen zu „Spielen“. In VirtualBox eine Virtuelle Maschinen aufzusetzen ist einfach und geht schnell von der Hand.
Da ich auch gern mal sehen wollte wie man OSD´s (Objekt Storage) dazu holt um den Ceph zu erweitern hab ich für jede der 4 Maschinen auch 8 Virtuelle Platten erzeugt und diese auf ein separates Raid 1+0 Array ausgelagert. Damit wird das Storagesystem ein bisschen entlastet und stellt nicht ein so wirkliche großes Nadelöhr da. Was zum Testen auf VirtualBox eigentlich nicht ganz so wichtig ist.
Die Installation und Konfiguration von Ceph geht leicht von der Hand, da es für diverse Systeme schon fertige Pakete gibt die alle Teile mitbringen. Die Konfiguration dagegen ist ein wenig Komplex da man sich mit den Begrifflichkeiten wie MDS, OSD, MON erst einmal auseinander setzen muss. Aber durch die Erfahrungen mit OpenAFS ist das Funktionsprinzip von Ceph nichts wirklich neues und die Bestandteile haben nur andere Namen.
Der OSD ist der Objektspeicher der eigentliche Datenspeicher in dem Ceph alle Daten ablegt, darunter liegt aber ein normales Storagesystem. Also ein oder mehrere Festplatten mit Filesystem. Im übrigen, so die Empfehlung, soll man keine Raids dafür nehmen da diese die Effektivität von Ceph behindern. Außerdem ist Ceph selbst in der Lage die Daten in mehreren Kopien vor zuhalten was einem Raid gleich kommt. Als Filesystem für Ceph liegt da meist XFS, Ext4 oder BTRFS. Ich verwende aber bisher dafür XFS.
Der MDS ist der Metadatenspeicher und ist das Kernstück von Ceph was dafür sorgt das alle Objekte die auf den OSD´s liegen auch wieder zu einer Datei zusammen gesetzt werden können.
Der MON ist der Monitor von Ceph und sorgt dafür das die Stabilität der Daten erhalten bleibt und auch beim Ausfall eines MDS, eines OSD´s oder sogar eines MON die Daten Konsistent bleiben. Das Funktioniert aber nur wenn man genügend Reserve MDS´s, OSD´s und MON´s hat.
Um die Stabilität noch höher zu setzen kann man Ceph sagen wie er die Daten vorhalten soll und welche Dienste wo Laufen und wer für welche Daten überhaupt zuständig ist. Der Standard ist das Ceph die Daten in zweifacher Form vorhält, man kann aber auch die Daten in 4 facher oder 5 facher Form vorhalten. Wobei die Sache irgendwann absurdum geführt wird.
So kann man z. B. die OSD´s separieren um den Cluster in Gruppen zu Teilen um diese z. B. nach Rechenzentren zu Gruppieren. Auch kann man das Backup auf diese weise ganz einfach gestalten, in dem man einer oder, zur besseren Redundanz, zwei OSD´s Nodes alle Daten die im Cluster vorhanden sind übergibt und diese dann in einem Rutsch auf Band schiebt. In einem Rutsch HAHA guter Witz!! Bei LTO6 mit 160 MB/Sek.!! Jedenfalls kann man damit das so gefürchtet Shoeshine ausbügeln.
Der Vorteil ist auch das man damit Vorgaben für SLA Verträge erzeugen kann die dem Kunden die Sicherheit geben das seine Daten, in einem Separierten Cluster, n mal vorhanden sind und n Nodes weg brechen dürfen ohne das die Redundanz darunter leidet.
Das hört sich komplizierter an als es ist, aber Ceph bringt auf Grund seiner Natur alle diese Funktionen mit was die Sache, wenn man erst mal Verstanden hat wie Ceph „Tickt“, sich einfach umsetzen lassen.
Zurück zum Test Cluster!
Wenn die 4 Virtuellen Ceph Nodes laufen und sich Synchronisiert haben, ähnlich der Synchronisation eines Raid Array, kann man den Ceph Cluster mit Mount einfach einhängen und schon kann man Ceph benutzten.
Bei größeren Clustern ist jedoch eine Ordentliche Bandbreite von Vorteil damit die Synchronisation innerhalb des Ceph Clusters auch schnell über die Bühne geht. Denn die Daten gelten erst dann als gespeichert wenn alle OSD´s auf denen die Daten liegen sollen auch dort Physisch liegen!
Auch das Erweitern oder das Reduzieren des Ceph Clusters lässt sich im laufenden Betrieb bewerkstelligen was die Sache bei Kaputten Festplatten oder Migrieren von größeren Maschinen vereinfacht. Der weitere Vorteil ist das jeder Dienst, sei es der MON, die OSD´s oder die MDS´s auf jeder Maschinen laufen dürfen auch außerhalb des Clusters, was aber eigentlich dann die Maschinen zu einem Teil des Clusters werden lässt.