und ich endlich mehr Entlastung!!<\/p>\n
Seit geraumer Zeit „verschwende“ ich mehr und mehr Zeit damit unsere Storageserver zu verwalten und zu \u00fcberwachen. Selbst unser eigens Entwickeltes Datacenter System hat mehr mit der Verwaltung zu tun als alles andere. Das gr\u00f6\u00dfte 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.<\/p>\n
<\/p>\n
Redundanz muss man Extern da zubauen und ist meist auch nicht wirklich die Optimale L\u00f6sung. Gerade bei Systemen die \u00fcber mehrere Standorte verteilt sind. Daher MUSS ein Ersatz her, aber welcher??<\/p>\n
Meine Wahl fiel auf Ceph, einem Filesystem was nicht wie herk\u00f6mmliche Systeme Arbeitet sondern einen Objekt Speicher darstellt. Ich hatte schon mal vor Jahren einige System mit OpenAFS, einem der Gro\u00dfv\u00e4ter der Objekt Speicher Systeme, am laufen. Aber OpenAFS ist nicht Perfekt und man hat schon mal mit einer Splitbrain<\/a> Situation zu k\u00e4mpfen und auch die Skalierbarkeit hat bei OpenAFS so seine T\u00fccken.<\/p>\n Also WARUM Ceph?? Obwohl es doch noch nicht f\u00fcr den Produktiv betrieb geeignet sein soll???<\/p>\n Weil ich gern Wege gehe die ich nicht kenne da Sie das Leben meist viel Interessanter machen.<\/p>\n Ceph hat diverse Eigenschaften die andere Objektspeicher Systeme nicht haben. Zum einen gibt es keine Splitbrain Situationen mehr bzw. Ceph wei\u00df 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.<\/p>\n 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.<\/p>\n Da ich auch gern mal sehen wollte wie man OSD\u00b4s (Objekt Storage) dazu holt um den Ceph zu erweitern hab ich f\u00fcr 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\u00dfes Nadel\u00f6hr da. Was zum Testen auf VirtualBox eigentlich nicht ganz so wichtig ist.<\/p>\n Die Installation und Konfiguration von Ceph geht leicht von der Hand, da es f\u00fcr 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.<\/p>\n 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 \u00fcbrigen, so die Empfehlung, soll man keine Raids daf\u00fcr nehmen da diese die Effektivit\u00e4t von Ceph behindern. Au\u00dferdem ist Ceph selbst in der Lage die Daten in mehreren Kopien vor zuhalten was einem Raid gleich kommt. Als Filesystem f\u00fcr Ceph liegt da meist XFS, Ext4 oder BTRFS. Ich verwende aber bisher daf\u00fcr XFS.<\/p>\n Der MDS ist der Metadatenspeicher und ist das Kernst\u00fcck von Ceph was daf\u00fcr sorgt das alle Objekte die auf den OSD\u00b4s liegen auch wieder zu einer Datei zusammen gesetzt werden k\u00f6nnen.<\/p>\n Der MON ist der Monitor von Ceph und sorgt daf\u00fcr das die Stabilit\u00e4t der Daten erhalten bleibt und auch beim Ausfall eines MDS, eines OSD\u00b4s oder sogar eines MON die Daten Konsistent bleiben. Das Funktioniert aber nur wenn man gen\u00fcgend Reserve MDS\u00b4s, OSD\u00b4s und MON\u00b4s hat.<\/p>\n Um die Stabilit\u00e4t noch h\u00f6her zu setzen kann man Ceph sagen wie er die Daten vorhalten soll und welche Dienste wo Laufen und wer f\u00fcr welche Daten \u00fcberhaupt zust\u00e4ndig ist. Der Standard ist das Ceph die Daten in zweifacher Form vorh\u00e4lt, man kann aber auch die Daten in 4 facher oder 5 facher Form vorhalten. Wobei die Sache irgendwann absurdum gef\u00fchrt wird.<\/p>\n So kann man z. B. die OSD\u00b4s 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\u00b4s Nodes alle Daten die im Cluster vorhanden sind \u00fcbergibt 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\u00fcrchtet Shoeshine<\/a> ausb\u00fcgeln.<\/p>\n Der Vorteil ist auch das man damit Vorgaben f\u00fcr SLA Vertr\u00e4ge 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\u00fcrfen ohne das die Redundanz darunter leidet.<\/p>\n Das h\u00f6rt 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.<\/p>\n Zur\u00fcck zum Test Cluster!<\/p>\n Wenn die 4 Virtuellen Ceph Nodes laufen und sich Synchronisiert haben, \u00e4hnlich der Synchronisation eines Raid Array, kann man den Ceph Cluster mit Mount einfach einh\u00e4ngen und schon kann man Ceph benutzten.<\/p>\n Bei gr\u00f6\u00dferen Clustern ist jedoch eine Ordentliche Bandbreite von Vorteil damit die Synchronisation innerhalb des Ceph Clusters auch schnell \u00fcber die B\u00fchne geht. Denn die Daten gelten erst dann als gespeichert wenn alle OSD\u00b4s auf denen die Daten liegen sollen auch dort Physisch liegen!<\/p>\n Auch das Erweitern oder das Reduzieren des Ceph Clusters l\u00e4sst sich im laufenden Betrieb bewerkstelligen was die Sache bei Kaputten Festplatten oder Migrieren von gr\u00f6\u00dferen Maschinen vereinfacht. Der weitere Vorteil ist das jeder Dienst, sei es der MON, die OSD\u00b4s oder die MDS\u00b4s auf jeder Maschinen laufen d\u00fcrfen auch au\u00dferhalb des Clusters, was aber eigentlich dann die Maschinen zu einem Teil des Clusters werden l\u00e4sst.<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" und ich endlich mehr Entlastung!! Seit geraumer Zeit „verschwende“ ich mehr und mehr Zeit damit unsere Storageserver zu verwalten und zu \u00fcberwachen. Selbst unser eigens Entwickeltes Datacenter System hat mehr mit der Verwaltung zu tun als alles andere. Das gr\u00f6\u00dfte Problem ist und bleibt aber die Redundanz. Keines der Filesysteme auf unseren Storageservern kommt mit … <\/p>\n