Proxmox VE und Ceph
Eigenschaften von Open-Source-Storage
Open-Source-Lösungen für Hardware-Virtualisierung und Container können mit hoher Verfügbarkeit und flexibler Verwaltung mit zentralem Konfigurationsmanagement punkten. Doch ist dabei auch die Storage-Anbindung relevant.
Seit mehr als zehn Jahren kommt Ceph als verteiltes Open-Source-basiertes Storage-System zum Einsatz. Das Ziel der Entwicklung war eine skalierbare Technologie zum Speichern von unstrukturierten Daten. Dafür ist Ceph ideal als Unified Storage geeignet. Dieser technologische Ansatz bringt einige Vorteile mit sich. So ist insbesondere der Einsatz von „Commodity Hardware“ möglich – ein entsprechendes Cluster-Sizing von Experten ist dennoch zu empfehlen.
Darüber hinaus ist Ceph selbstheilend und selbstverwaltend: Fällt ein Datenträger aus, so sorgt Ceph automatisch und eigenständig dafür, dass die nun fehlenden Daten wiederhergestellt werden – self healing. Und da Ceph beziehungsweise dessen Dienste miteinander kommunizieren, kennen sie sich und agieren miteinander. Fällt etwa ein Dienst aus, übernimmt ein anderer automatisch. Das System agiert autonom unter der Prämisse, dass Datenintegrität an erster Stelle steht. Auf dieser Basis lassen sich mit Ceph hochverfügbare Lösungen einrichten.
Diese sind auch flexibel: Der Einbau zusätzlicher sowie das Herausnehmen vorhandener Festplatten sind wegen des „Self Balancing“ jederzeit möglich. Tiered Storage zwischen unterschiedlichen Arten von Datenträgern ist ebenfalls eine Option, genauso wie das Hinzufügen von Hosts und die Einbindung in das Cluster, das sich per Dashboard zudem überwachen lässt. Pools werden automatisch vergrößert. Darüber hinaus gibt es mehrere Arten der Verschlüsselung. Ein Ceph Storage ist „always on“, und mit den passenden Storage Policies ist eine ortsbasierte Datenablage möglich: Administratoren können bei Bedarf selbst bestimmen, wie Daten zwischen Racks, Datacentern oder Hosts aufgeteilt werden.
Logische Ebenen innerhalb eines Ceph-Clusters
Für Ceph sind die Dienste auf der Storage Ebene RADOS (Reliable Autonomic Distributed Object Store) erforderlich. Die Object Storage Daemons (OSDs) sind für die Speicherung der Objekte im RADOS zuständig. Zur Kommunikation mit Clients und Apps oder anderen Objekt-Speichern gibt es mit den Libraries eine Zwischenebene namens LIBRADOS. Sie schafft eine Schnittstelle zum Ceph-Speicher und wird auf dem Client installiert, sodass dieser direkt mit RADOS kommunizieren kann. Denn Objekte werden bei Ceph direkt vom Client auf die OSDs geschrieben. Durch LIBRADOS können nun die Objekte im RADOS unterschiedlich verwendet werden.
So lassen sich die Objekte für den Gebrauch in anderen Objektspeichern übersetzen. Damit können S3 oder Swift-Speicher auf RADOS-Objekte zugreifen. Das übernimmt das RADOS-Gateway (RADOSGW). Zudem kann der Speicher auch Clients beziehungsweise Hosts als Block Storage zur Verfügung gestellt werden (RADOS Block Device, kurz RBD) – und genau das ist der Zugang zur Nutzung von Proxmox VE und seinen virtuellen Maschinen zum Ceph-Speicher. Schließlich ist es auch möglich, die Objekte als File Storage bereitzustellen, was ebenfalls für die Verwendung mit Proxmox VE relevant ist; das Dateisystem nennt sich hier CephFS und ist über jede Art von Client oder App erreichbar, wenn es im Client eingebunden ist.
Die Dienste im Überblick
Der Dienst Monitor ermöglicht, betriebskritische Abbildungen (Maps) verschiedener Teile eines Clusters anzulegen. Sie zeigen, wo sich die jeweiligen Dienste physisch befinden. Bereitgestellt werden etwa eine Manager-Map, eine OSD-Map und eine Monitor-Map – also die Lokationen der anderen Dienste – und die wichtige CRUSH-Map. Kommen weitere Dienste hinzu, erzeugt der Monitor auch von diesen eine Map oder updatet die bestehende Map entsprechend. Zudem dienen Monitore im Cluster als Quorum. Es muss daher mindestens drei geben; die Anzahl sollte möglichst immer ungerade sein, zudem ist eine Verteilung auf unterschiedlichen Cluster-Nodes ratsam. Zu guter Letzt verwaltet der Ceph-Monitor die Authentifizierung zwischen Diensten und Clients.
Der zweite wichtige Dienst ist der Ceph-Manager. Er überwacht die Kennzahlen des Clusters. Deren Anzeige erfolgt im Dashboard; hier ist auch die Einbindung externer Monitoring-Tools möglich. Der dritte wichtige Dienst, der in jedem Ceph-Cluster vorhanden sein muss, sind die OSDs. Diese Daemons abstrahieren den physischen Datenträger und wandeln ihn zu einem logischen Speicherelement, damit die Einbindung ins RADOS funktioniert. Sie sind damit das logische Pendant eines Datenträgers.
Datenspeicherung im Ceph-Cluster
Eine typische Konfiguration mit einem beliebigen Client, auf dem LIBRADOS installiert ist, kann demnach so aussehen: RADOS mit Diensten, Monitore mit Abbildungen des Clusters, Manager zur Überwachung und OSDs zur Speicherung der Ceph-Objekte. Wird der Storage dem Client als RBD zur Verfügung gestellt, müssen die Blöcke nun also in Objekte umgewandelt und an die OSDs verteilt werden.
Damit das funktioniert, muss der Client seine Daten an die richtigen OSDs senden. Diese und weitere Informationen – zum Beispiel die Regeln zur Verteilung der Daten oder die dazugehörigen Lokationen der OSDs – kann sich der Client anhand der vom Monitor übermittelten Maps errechnen.
Die CRUSH-Map kann der Client über LIBRADOS übersetzen. Der Client kalkuliert jetzt mithilfe der CRUSH-Map, an welche OSD die Daten gehen sollen, wandelt den Block mit LIBRADOS in ein Objekt um und überträgt es an die entsprechende OSD. Dort angekommen gibt die OSD ein Acknowledge an den Client zurück und verteilt gleichzeitig die Daten an zwei weitere OSDs, nach den in der CRUSH-Map festgelegten Regeln. Nach erfolgreichem Write folgt von diesen ebenfalls ein Acknowledge an den OSD.
Pools und Placement Groups
Es kommt jedoch nicht nur darauf an, dass die Daten gespeichert sind, sondern auch darauf, wie und wo. Andernfalls bestünde die Gefahr, dass auf einem Host sehr viele Objekte gespeichert sind und sich dadurch ein Hot-Spot mit Risiko bis hin zum Datenverlust entwickelt. Demnach sind Regeln (Crush Rules) zur sinnvollen Verteilung erforderlich. Hier kommen Ceph-Pools und Placement Groups ins Spiel. Sie sind auch für das Tiering wichtig.
Ein typisches Szenario: Ein Cluster mit NVMe und HDDs soll Regeln erhalten, die zwischen beiden Device-Klassen unterscheiden. Der erste Schritt ist hierbei, zur logischen Trennung je einen Pool pro Klasse zu erstellen. Innerhalb der Pools sorgen wiederum Crush Rules dafür, die Daten richtig zu verteilen – also möglichst gleichmäßig über alle relevanten Devices im Cluster. Hierfür nutzen sie einen pseudo-zufälligen Algorithmus, sodass die Objekte mit der gewünschten Verteilung in die OSD gelangen und von dort an zwei weitere OSDs verteilt werden. Die zu verwendenden OSDs werden von den jeweiligen Placement Groups, dem Pool und den Policies (also Crush Rules in der CRUSH-Map) bestimmt.
Jonas Sterr, Senior Solutions Engineer bei Thomas-Krenn
Lesen Sie mehr zum Thema
