Das Titelthema im ADMIN 04/14 "Vernetzt speichern" sind Netzwerkdateisysteme, etwa Samba 4, verteilter Storage mit Ceph & GlusterFS und der Unix-Klassiker ... (mehr)

Binäre Objekte

Object Stores setzen auf binäre Objekte, weil diese sich problemlos in viele kleine Teile aufspalten lassen  – setzt man die einzelnen Teile zu einem späteren Zeitpunkt wieder in der originären Reihenfolge zusammen, so ergibt sich exakt dieselbe Datei wie zuvor. Bis zum Zeitpunkt, an dem die Objekte wieder zusammengesetzt werden, lassen sich die einzelnen Teile des binären Objekts dabei verteilt abspeichern, also beispielsweise über mehrere Festplatten verteilt, die auch in unterschiedlichen Servern beheimatet sein können. Auf diese Weise umgehen Object Stores den größten Nachteil, mit dem klassische Storage-Lösungen zu kämpfen haben: Der starren Einteilung in Blöcke.

Grundsätzlich gilt: Jeder Datenträger (mit Ausnahme von Magnetbändern), den Otto Normalverbraucher beim Hardware-Shop des Vertrauens kaufen kann, funktioniert blockbasiert. Die Aufteilung in Blöcke ist dabei per se weder positiv noch negativ, aber sie sorgt für einen unschönen Nebeneffekt: Ab Werk lässt sich ein Datenträger auf Block-Basis nämlich nicht effektiv nutzen. Es ließen sich zwar Daten auf ihm ablegen, doch wäre es unmöglich, diese koordiniert später wieder zu lesen, ohne den gesamten Datenträger nach der gespeicherten Information erst abzusuchen. Dateisysteme helfen dabei, das Problem zu lösen. Sie machen einen Datenträger effektiv nutzbar und sorgen quasi für die Grundstruktur. Der Pferdefuß bei diesem System ist, dass Dateisysteme sehr eng mit dem dazu gehörenden Datenträger verbunden sind. Ein Dateisystem auf einem Datenträger lässt sich nicht ohne Weiteres in Streifen schneiden und auf andere Platten verteilen.

Ceph als Object Store umgeht die Einschränkung, indem es auf die genutzen Blockdevices eine zusätzliche Verwaltungsschicht legt. Auch Ceph benutzt Blockdatenspeicher, doch sind die einzelnen Festplatten mit den Dateisystemen für Ceph jeweils nur Mittel zum Zweck; die interne Verwaltung passiert in Ceph ausschließlich auf Basis eines eigenen Algorithmus und der binären Objekte; die Grenzen beteiligter Datenträger interessieren nicht mehr.

Die Ceph-Komponenten stellen sich vor

Ceph besteht im Wesentlichen aus dem eigentlichen Objektspeicher, der dem einen oder anderen Leser noch unter seinem alten Namen Rados (Redundant Autonomic Distributed Object Store) bekannt sein dürfte, und mehreren Schnittstellen für Anwender. Der Objektspeicher besteht wiederum aus zwei Kernkomponenten, nämlich den OSDs sowie den MONs. OSD steht für Object Storage Device, gemeint ist damit jede einzelne Platte, die zu einem Ceph-Verbund gehört. OSDs sind in Ceph die Datensilos, die am Ende die binären Objekte speichern. Anwender kommunizieren direkt mit OSDs, um Daten in den Cluster hochzuladen. Im Hintergrund sind es auch die OSDs, die sich um Themen wie Replikation selbstständig kümmern. Damit Clients und OSDs gleichermaßen stets wissen, welche OSDs eigentlich im Augenblick zum Cluster gehören, gibt es die Monitoring-Server, abgekürzt MON: Sie pflegen Listen aller vorhandenen Monitoring-Server und OSDs und geben sie auf Befehl an Clients und OSDs weiter. MONs erzwingen obendrein ein Cluster-weites Quorum: Bricht ein Ceph-Cluster auseinander, so darf nur jene Cluster-Partition aktiv bleiben, die die Mehrheit der MON-Server hinter sich vereint weiß – sonst könnte es zu einer Split-Brain-Situation kommen.

Maßgeblich für das Verständnis der Funktionalität von Ceph ist, dass keine der zuvor genannten Komponenten zentral ist; alle Komponenten in Ceph müssen dezentral funktionieren. Es gibt kein einzelnes OSD, dem eine besondere Priorität zukäme, und auch die MONs sind untereinander grundsätzlich gleichberechtigt. Jederzeit ist es möglich, den Cluster um zusätzliche OSDs oder MONs auszubauen, ohne dabei auf die Zahl vorhandener Computer oder das Layout der OSDs Rücksicht zu nehmen. Ob in Ceph drei Server mit jeweils 12 Festplatten oder 10 Server mit ganz unterschiedlichen Platten in unterschiedlichen Größen werkeln, ist für die angebotenen Funktionen des Clusters ohne jeden Belang. Dank des von Inktank ausgerufenen Unified-Storage-Prinzips sehen Nutzer des Speichersystems immer dasselbe Interface, egal, was der Objektspeicher im Hintergrund tut.

Drei Schnittstellen sind in Ceph von Bedeutung: CephFS ist ein Linux-Dateisystemtreiber, der den Zugriff auf einen Ceph-Speicher wie auf ein normales Dateisystem ermöglicht. Das RBD (Rados Block Device) bietet den Zugriff auf Rados über eine Kompatibilitätsschnittstelle für Blöcke und das Rados-Gateway offeriert RESTful-Speicher in Ceph, der per Amazon-S3-Client oder OpenStack-Swift-Client ansprechbar ist. Zusammen bilden die Komponenten von Ceph ein umfassendes Speichersystem, das in der Theorie zu überzeugen vermag – doch hält die Praxis, was die Theorie verspricht?

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2021