Ceph-Storage in der Praxis - Teil 3

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.

3. Betrieb

Im letzten Teil gehen wir noch kurz auf den Betrieb des Ceph-Clusters ein und geben Anwendungsbeispiele.

3.1 Server Betriebssystem

Der vorliegende Ceph-Cluster mit seinen 3 Nodes wurde auf Basis der derzeit aktuellen Debian 9 „Jessie“ Linux Distribution erstellt. Zudem wurde auf den Nodes die frei verfügbare Virtualisierungsplattform Proxmox VE 5 installiert, das mit seinem Repository u.a. aktuelle Pakete für das Ceph-Dateisystem mitbringt. Der Cluster ließe sich dadurch auch direkt als Virtualisierungsumgebung nutzen, was in diesem Anwendungsfall jedoch nicht relevant ist und daher nicht näher betrachtet werden soll.

Das Ceph-Dateisystem liegt in Version 12 „Luminous“ vor.

3.2 iSCSI-Targets

Wie im Kapitel Grundkonzept ausgeführt, wird die iSCSI-Schnittstelle zum Ceph Storage mittels des Linux SCSItargetframework (TGT) bereitgestellt. Die Bedienung erfolgt auf den einzelnen Nodes per Kommandozeile (Linux Shell, root-Login).

Nachstehend werden einige Standard-Aufgaben und ihre Realisierung beschrieben.

3.2.1targeterstellen

Zum Erstellen eines neuen iSCSI-Targets mit dahinterliegendem Storage sind die folgenden Schritte erforderlich:

Speicherbereich auf dem Ceph-Storage reservieren: der nachstehende Befehl erzeugt einen 100 GB großen Speicherbereich auf dem Ceph-Storage storage_cached mit Namen iscsi-tgt-vm001-disk1
rbd create --size 102400 storage_cached/iscsi-tgt-vm001-disk1
Zur Prüfung kann der Inhalt des Storage-Pools mit dem folgenden Kommando aufgelistet werden:
rbd --pool storage_cached ls -l
Für den Zugriff per iSCSI wird ein iSCSI-Portal benötigt. Hier kann entweder ein bestehendes Portal genutzt oder ein neues Portal erstellt werden. Im nachstehenden Beispiel wird ein neues iSCSI-Portal erzeugt mit Target-ID 1 und der angegebenen Benennung:
tgtadm --lld iscsi --op new --modetarget--tid 1 -T iqn.2017-11.kk-ceph.de:vm001.disk1.shared.tgt
Die Target-ID muss dabei eindeutig sein, darf also noch nicht im System existieren. Die bereits eingerichteten iSCSI-Portale können mit dem folgenden Kommando angezeigt werden:
tgtadm --lld iscsi --modetarget--op show
Das Schema für die zuvor verwendete IQN-Bezeichnungen lautet:
iqn.YYYY-MM.NAMING_AUTHORITY:UNIQUE_NAME
Neben einem iSCSI-Portal wird nun noch eine LUN benötigt. Im nachstehenden Beispiel wird zum iSCSI-Portal mit Target-ID 1 noch die LUN 1 generiert und mit dem in Schritt 1 erstellten Speicherbereich auf dem Ceph-Storage verknüpft:
tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 1 --bstype rbd --backing-store storage_cached/iscsi-tgt-vm001-disk1 --bsopts "conf=/etc/pve/ceph.conf;id=admin"
Zuletzt muss noch dastargetgebunden werden.
Im folgenden Beispiel wieder die Target-ID 1:
tgtadm --lld iscsi --op bind --modetarget--tid 1 -I 10.10.12.0/24
Das angegebene Netzwerksegment 10.10.12.0/24 entspricht dabei dem iSCSI-Netzwerk und bestimmt, dass nur iSCSI-Zugriffe aus diesem IP-Bereich Zugriff erhalten.

Damit iSCSI-Targets auch nach einem Reboot oder Neustart des Dienstes automatisch geladen werden, müssen diese in der Konfigurationsdatei /etc/tgt/conf.d/ceph-tgt-shared.conf fest hinterlegt werden. Für das obige Beispiel sieht der Abschnitt in der Konfiguration wie folgt aus:

<target iqn.2017-11.kk-ceph.de:vm001.disk1.shared.tgt>
driver iscsi
bs-type rbd
backing-store storage_cached/iscsi-tgt-vm001-disk1
initiator-address 10.10.12.0/24
</target>

Zum Erstellen des Konfigurationseintrags hilft das Kommando:
tgt-admin -dump

Allerdings müssen die Eigenschaften „driver“ und „bs-type“ händisch ergänzt werden.

Damit das iSCSI-Target von allen 3 Nodes bereitgestellt wird, muss das beschriebene Verfahren auf jedem Node durchgeführt werden!

3.2.2targetlöschen

Zum Löschen eines Targets müssen die zuvor beschriebenen Schritte in umgekehrter Reihenfolge durchlaufen werden. Für das zuvor beschriebene Beispiel sind dies:

Target-Bindung aufheben:
tgtadm --lld iscsi --op unbind --modetarget--tid 1 -I 10.10.12.0/24
LUN löschen:
tgtadm --lld iscsi --mode logicalunit --op delete --tid 1 --lun 1
iSCSI-Portal löschen (falls nicht mehr anderweitig benötigt):
tgtadm --lld iscsi --op delete --modetarget--tid 1
Ggf. Speicherbereich auf dem Ceph-Storage freigeben (löschen!):
rbd remove storage_cached/iscsi-tgt-vm001-disk1

3.2.3 Speicherbereich vergrößern

Speicherbereiche auf dem Ceph-Storage können mit dem folgenden Kommando vergrößert werden (Fortsetzung des obigen Beispiels, Vergrößerung auf 150 GB Speicherbelegung):

rbd resize –-size 153600 storage_cached/iscsi-tgt-vm001-disk1

Dies darf nur bei inaktiver iSCSI-Verbindung durchgeführt werden und der iSCSI-Dienst des zugehörigen Portal/LUNs muss anschließend neu gestartet werden!

3.2.4 iSCSI-Konfiguration laden

Wie zuvor erläutert müssen dauerhafte iSCSI-Konfigurationen auf jedem Node in der Konfigurationsdatei /etc/tgt/conf.d/ceph-tgt-shared.conf festgelegt werden.

Geänderte Konfiguration können mit dem folgenden Kommando im laufenden Betrieb übernommen werden:

tgt-admin --update ALL

Dies gilt allerdings nur für inaktive Targets! D.h. ein verbundenestargetbleibt weiterhin bestehen und übernimmt die Änderungen erst nach dem nächsten Neustart des iSCSI-Dienstes.

3.2.5 iSCSI-Dienst

Der iSCSI-Dienst wird beim Neustart eines Nodes automatisch geladen.

Im laufenden Betrieb lässt sich der Dienst mit den folgenden Kommandos steuern:

Dienst beenden:
service tgt stop
Dienst starten:
service tgt start
Status prüfen:
service tgt status
Dienst neu starten:
service tgt restart

3.3 Monitoring

Im Betriebsalltag sollte der Überwachung des Ceph-Clusters und seiner Nodes eine feste Rolle eingeräumt werden. Einerseits müssen Störungen und Ausfälle zeitnah erkannt werden, damit eine Fehlerbehebung und Rückkehr zum Normalbetrieb stattfinden kann. Andererseits sollten aber auch möglichst fortlaufend Nutzungs- und Performance-Daten des Ceph-Storages erhoben werden, um die Speicherbelegung und –verteilung zu erfassen sowie – im Idealfall – bei Leistungseinbrüchen und Engpässen Rückschlüsse auf die Auslöser ziehen zu können.

Auf Kommandozeilenebene helfen für die erste Diagnose die folgenden Befehle:

Abfrage des Zustands des Ceph-Dateisystems:
ceph health
bzw. mit Detailinformationen (im Fehlerfall)
ceph health detail
Status-Abfrage Ceph:
ceph status
Auflistung der Ceph OSDs mit aktuellem Status:
ceph osd tree
Latenzzeiten der OSDs:
ceph osd perf
Speicherbeledung der OSDs:
ceph osd df plain
Speicherbeledung des Ceph-Storages (aufgeschlüsselt nach Pools):
ceph df

Darüber hinaus erlaubt Ceph Einblick in hunderte von Laufzeitparametern, die eine Analyse bis hin zu kleinsten Details ermöglichen. Als Einstieg sei hier nur das folgende Abfragekommando beispielhaft genannt, das Details zu den Storage-Pools verrät:
rados df –f json-pretty

Mit Monitoring-Software wie Zabbix und dem Visualisierungstool Grafana lassen sich damit Echtzeit-Dashboards erstellen, die detaillierte Einblicke in Zustand und Lastverhalten des Ceph-Clusters bieten, wie in den nachstehenden Ansichten zu sehen ist.

3.4 Link-Sammlung

Die nachstehende Tabelle listet einige Links zur vertieften Lektüre:

Link	URL
Ceph Homepage	http://ceph.com/
Ceph Dokumentation	http://docs.ceph.com/docs/master/

Proxmox Homepage	https://www.proxmox.com/de/
Proxmox Dokumentation	https://pve.proxmox.com/wiki/Main_Page

Konfiguration VMware ESX iSCSI Initiator (Multipath)	https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/2/html/block_device_guide/using_an_iscsi_gateway_technology_preview#the_iscsi_initiator_for_vmware_esx

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 2

Beitrag vom 13.04.2018

Sidebar