Autor: Armin Krauß - K&K Software AG
Zentrale, Shared Storage Systeme haben im Serverumfeld einen festen Platz. Mit wachsenden Anforderungen an Kapazität, Skalierbarkeit und Ausfallsicherheit spielen verteilte Storage-Lösungen dabei eine immer größere Rolle. Nicht zuletzt durch die Aussicht auf Kostenersparnis sowie einen hohen Grad an Flexibilität wächst die Anwenderzahl des Ceph-Dateisystem stetig und rasant an, weshalb wir nachfolgend einen Anwendungsfall aus der Praxis betrachten wollen.
In Teil 2 stellen wir nun am Beispiel eines kleinen Ceph-Clusters Konzeptionierung und Aufbau eines Ceph-Storages mit iSCSI-Anbindung vor. Letztere ermöglicht die Nutzung des Storages auch durch fremde Systeme, wie z.B. eine VMware Umgebung. Dabei befassen wir uns zunächst mit dem Grundaufbau und Netzwerkanforderungen und anschließend der Konfiguration von Festplatten und OSDs.
Das hier vorgestellte Beispiel demonstriert einen kleinen Anwendungsfall und stellt daher keinen allgemeinen Ratgeber für den Aufbau eines Ceph-Storages dar. Es zeigt aber die grundsätzlichen Komponenten und Aspekte, die zur Planung eines eigenen Einsatzes von Ceph nötig sind.
Der Ceph-Cluster besteht initial aus 3 Nodes, die gemeinsam den Ceph-Storage aufspannen wie in der nachstehenden Abbildung veranschaulicht:
Wie dargestellt sind die Nodes untereinander über unterschiedliche Netzwerke verbunden:
Zum Schutz gegen äußere Einflüsse sind die 3 Ceph-Nodes in unterschiedlichen Rechenzentren bzw. Gebäudeteilen untergebracht, um den Betrieb auch im Fall von Störungen und Ausfällen einzelner Einrichtungen fortführen zu können.
Die zuvor genannten Netzwerkverbindungen zwischen den Nodes sind innerhalb der Netzwerk-Infrastruktur wie nachstehend realisiert:
Typ |
VLAN |
IP-Bereich |
Geschwindigkeit |
Management |
101 |
10.1.1.0 / 255.255.255.0 |
1 GBit/s |
iSCSI |
12 |
10.10.12.0 / 255.255.255.0 |
10 GBit/s (Standby: 1 GBit/s) |
Ceph/SAN |
11 |
10.10.11.0 / 255.255.255.0 |
10 GBit/s (Standby: 1 GBit/s) |
Jeder Node verfügt aus Gründen der Redundanz jeweils über mehrfache Schnittstellen in die obenstehenden Netzwerke. Diese sind teilweise in Form von LAGs sowie als Standby-Schnittstellen (zum Failover-Betrieb) konfiguriert.
Im konkreten Beispiel verfügen die Ceph-Nodes über die nachstehende Schnittstellenkonfiguration:
Schnittstelle |
Bandbreite |
VLAN |
Verwendung |
eno1 |
1 GBit/s |
101 |
Management (LAG) |
eno2 |
1 GBit/s |
101 |
Management (LAG) |
ens2f0 |
10 GBit/s |
12 |
iSCSI (LAG) |
ens2f1 |
10 GBit/s |
12 |
iSCSI (LAG) |
ens3f0 |
10 GBit/s |
11 |
Ceph/SAN (LAG) |
ens3f1 |
10 GBit/s |
11 |
Ceph/SAN (LAG) |
ens7f0 |
1 GBit/s |
11 |
Ceph/SAN (LAG, Stby.) |
ens7f1 |
1 GBit/s |
12 |
iSCSI (LAG, Stby.) |
Die oben vorgestellten 3 Ceph-Nodes sind alle nach identischem Schema aufgebaut und konfiguriert.
Wie nachstehend abgebildet erfüllen Sie jeweils die folgenden Aufgaben:
Jeder Ceph-Node verfügt jeweils über
Außerdem bietet jeder Node eine iSCSI-Schnittstelle zum Zugriff auf den Ceph-Storage.
Die IP-Adressen der Nodes in den unterschiedlichen Netzwerken sind in der nachstehenden Tabelle zusammengefasst:
|
kk-ceph01 |
kk-ceph02 |
kk-ceph03 |
Management |
10.1.1.11 |
10.1.1.12 |
10.1.1.13 |
iSCSI |
10.10.12.11 |
10.10.12.12 |
10.10.12.13 |
Ceph/SAN |
10.10.11.11 |
10.10.11.12 |
10.10.11.13 |
Die Ceph-Nodes verfügen über identische Hardware. Die Festplatten-Bestückung und Organisation folgt jeweils dem nachstehend abgebildeten Schema:
Das Betriebssystem nutzt 2 SSDs, die zu einem Raid-1 (Linux Software Raid) zusammengefasst sind.
Die restlichen SSDs (4 Stück) sowie konventionellen SAS-Festplatten (6 Stück) werden exklusiv als Ceph-Storage genutzt. D.h. jede dieser SSDs und SAS-Festplatten bildet ein OSD im Ceph-Storage.
Die genaue Zuordnung in einem Ceph-Node zeigt die nachstehende Tabelle:
Device |
Typ |
Verwendung |
/dev/sda |
SAS-Festplatte |
Ceph-Storage |
/dev/sdb |
SAS-Festplatte |
Ceph-Storage |
/dev/sdc |
SAS-Festplatte |
Ceph-Storage |
/dev/sdd |
SAS-Festplatte |
Ceph-Storage |
/dev/sde |
SAS-Festplatte |
Ceph-Storage |
/dev/sdf |
SAS-Festplatte |
Ceph-Storage |
/dev/sdg |
SSD |
Linux OS |
/dev/sdh |
SSD |
Linux OS |
/dev/sdi |
SSD |
Ceph-Cache |
/dev/sdj |
SSD |
Ceph-Cache |
/dev/sdk |
SSD |
Ceph-Cache |
/dev/sdl |
SSD |
Ceph-Cache |
Bei der Auswahl der SSDs wurde außerdem zwischen dem Einsatz als Betriebssystem-Datenträger und der Verwendung als Ceph OSD (Ceph-Cache) unterschieden. An letztere sind deutlich höhere Anforderungen hinsichtlich Geschwindigkeit, Durchsatz (insbesondere IOPS, d.h. Input/Output Operations Per Second) und Haltbarkeit zu stellen.
Wie zuvor dargestellt, setzt sich der Ceph-Storage aus den OSDs der 3 Ceph-Nodes zusammen. Die OSDs sind dabei abhängig von ihrem Typ (SSD oder konventionelle Festplatte, nachstehend als HDD bezeichnet) zu unterschiedlichen Gruppen zusammengefasst. Dies hat den Sinn, schnelle und speichermäßig beschränkte SSDs sowie HDDs mit höherer Speicherkapazität aber langsamer Zugriffszeit als separate Storages mit unterschiedlichem Anwendungsprofil einsetzen zu können.
Die OSD-Organisation der 3 Ceph-Nodes und ihre Zuordnung zu Storage-Pools zeigt die nachstehende Abbildung:
Im Storage-Pool ssd-cache sind alle Ceph zugeordneten SSDs zusammengefasst. Dieser Storage-Pool ist nicht zur direkten Nutzung vorgesehen. Er ist vielmehr transparent dem nachfolgenden Pool storage_cached vorgeschaltet und wirkt als schneller Zwischenspeicher (Cache), um Schreibzugriffe, wiederkehrende Anfragen und parallele Prozesse schneller verarbeiten zu können und die mögliche Bandbreite des Storages zu erhöhen.
Der Storage-Pool storage_cached umfasst alle Ceph zugeordneten HDDs und dient als eigentlicher Ablageort für Daten im Ceph-Storage.
Die Namensnennung von Firmen oder Markennamen dient lediglich der redaktionellen Verwendung, zur Abgrenzung und zur Kenntlichmachung der Kompatibilität im Rahmen des jeweiligen Geschäftsumfanges. Die Zeichen, Begriffe und Namen sind gegebenenfalls geschützte Marken- und Warenzeichen der jeweiligen Rechteinhaber. Die angebotene Ware ist zu vielen Produkten namhafter Marken kompatibel, es handelt sich aber keinesfalls um Produkte der betreffenden Firmen und Marken! Autor: Armin Krauß - K&K Software AG - eine Serie in 3 Teilen Lesen Sie hier: Teil 1 und Teil 3
Beitrag vom 09.04.2018