Gilt für SUSE Enterprise Storage 7.1

20 RADOS-Blockgerät #

Ein Block ist eine Folge von Byte, beispielsweise ein 4-MB-Datenblock. Blockbasierte Speicherschnittstellen werden am häufigsten zum Speichern von Daten auf rotierenden Medien wie Festplatten, CDs, Disketten verwendet. Angesichts der Omnipräsenz von Blockgeräteschnittstellen ist ein virtuelles Blockgerät für ein Massenspeichersystem wie Ceph hervorragend zur Interaktion geeignet.

Ceph-Blockgeräte lassen die gemeinsame Nutzung physischer Ressourcen zu und ihre Größe kann geändert werden. Sie speichern Daten auf mehreren OSDs in einem Ceph-Cluster verteilt. Ceph-Blockgeräte nutzen die RADOS-Funktionen wie Snapshotting, Reproduktion und Konsistenz. Cephs RADOS Block Devices (RBD) interagieren mit OSDs über Kernel-Module oder die librbd-Bibliothek.

Abbildung 20.1: RADOS-Protokoll #

Die Blockgeräte von Ceph sind sehr leistungsfähig und unbegrenzt auf Kernel-Module skalierbar. Sie unterstützen Virtualisierungslösungen wie QEMU oder Cloud-basierte Rechnersysteme wie OpenStack, die auf libvirt basieren. Sie können Object Gateway, CephFS und RADOS Block Devices gleichzeitig am selben Cluster ausführen.

20.1 Kommandos für Blockgeräte #

Mit dem Kommando rbd werden Blockgeräte-Images erstellt, aufgelistet, intern geprüft und entfernt. Sie können es beispielsweise auch zum Klonen von Images, zum Erstellen von Snapshots, für ein Rollback eines Image zu einem Snapshot oder zum Anzeigen eines Snapshots verwenden.

20.1.1 Erstellen eines Blockgeräte-Image in einem reproduzierten Pool #

Bevor Sie ein Blockgerät in einen Client aufnehmen können, müssen Sie ein zugehöriges Image in einem vorhandenen Pool erstellen (siehe Kapitel 18, Verwalten von Speicher-Pools):

cephuser@adm > rbd create --size MEGABYTES POOL-NAME/IMAGE-NAME

Mit folgendem Kommando erstellen Sie beispielsweise das 1-GB-Image „myimage“, in dem Informationen aus dem Pool „mypool“ gespeichert werden:

cephuser@adm > rbd create --size 1024 mypool/myimage

Tipp: Image-Größeneinheiten

Wenn Sie die Abkürzung einer Größeneinheit („G“ oder „T“) auslassen, wird die Größe des Images in Megabyte angegeben. Mit „G“ oder „T“ nach der Zahl geben Sie Gigabyte oder Terabyte an.

20.1.2 Erstellen eines Blockgeräte-Image in einem Pool mit Löschcodierung #

Daten eines Blockgeräte-Image können direkt in Pools mit Löschcodierung (EC-Pools) gespeichert werden. Ein RADOS-Block-Device-Image besteht aus einem Data- und einem metadata-Teil. Sie können lediglich den Datenteil eines RADOS Blockgeräte-Image in einem EC-Pool speichern. Das Flag overwrite des Pools muss auf true festgelegt sein. Dies ist nur möglich, wenn alle OSDs, auf denen der Pool gespeichert ist, mit BlueStore arbeiten.

Es ist nicht möglich, den Metadaten-Teil des Image in einem EC-Pool zu speichern. Sie können den reproduzierten Pool zum Speichern der Metadaten des Image mit der Option --pool= des Kommandos rbd create angeben oder pool/ als Präfix vor dem Imagenamen angeben.

Erstellen Sie einen EC-Pool:

cephuser@adm > ceph osd pool create EC_POOL 12 12 erasure
cephuser@adm > ceph osd pool set EC_POOL allow_ec_overwrites true

Geben Sie den reproduzierten Pool zum Speichern von Metadaten an:

cephuser@adm > rbd create IMAGE_NAME --size=1G --data-pool EC_POOL --pool=POOL

oder:

cephuser@adm > rbd create POOL/IMAGE_NAME --size=1G --data-pool EC_POOL

20.1.3 Auflisten von Blockgeräte-Images #

Mit folgendem Kommando rufen Sie die Blockgeräte im Pool „mypool“ ab:

cephuser@adm > rbd ls mypool

20.1.4 Abrufen von Image-Informationen #

Mit folgendem Kommando rufen Sie Informationen aus dem Image „myimage“ im Pool „mypool“ ab:

cephuser@adm > rbd info mypool/myimage

20.1.5 Ändern der Größe eines Blockgeräte-Image #

RADOS-Block-Device-Images werden schlank bereitgestellt, was bedeutet, dass Sie erst physischen Speicherplatz belegen, wenn Sie damit beginnen, Daten darin zu speichern. Ihre Kapazität ist jedoch auf den Wert beschränkt, den Sie mit der Option --size festlegen. Führen Sie folgendes Kommando aus, wenn Sie die maximale Größe des Image erhöhen (oder verringern) möchten:

cephuser@adm > rbd resize --size 2048 POOL_NAME/IMAGE_NAME # to increase
cephuser@adm > rbd resize --size 2048 POOL_NAME/IMAGE_NAME --allow-shrink # to decrease

20.1.6 Entfernen eines Blockgeräte-Image #

Mit folgendem Kommando entfernen Sie ein Blockgerät, das dem Image „myimage“ im Pool „mypool“ entspricht:

cephuser@adm > rbd rm mypool/myimage

20.2 Ein- und Aushängen #

Nach Erstellung eines RADOS Block Device können Sie es wie jedes andere Datenträgergerät nutzen: Sie können es formatieren, für den Dateiaustausch einhängen und danach wieder aushängen.

Das Kommando rbd greift standardmäßig mit dem Ceph-Admin-Benutzerkonto auf den Cluster zu. Dieses Konto hat vollen Verwaltungszugriff auf den Cluster. Dadurch besteht die Gefahr, dass versehentlich Schaden angerichtet wird, ähnlich wie bei der Anmeldung an einem Linux-Arbeitsplatzrechner als root. Daher ist es vorzuziehen, Benutzerkonten mit weniger Rechten zu erstellen und diese Konten für den normalen Lese-/Schreibzugriff auf RADOS-Blockgeräte zu verwenden.

20.2.1 Erstellen eines Ceph-Benutzerkontos #

Erstellen Sie ein neues Benutzerkonto mit Ceph-Manager-, Ceph-Monitor- und Ceph-OSD-Funktionen über das Kommando ceph mit dem Unterkommando auth get-or-create:

cephuser@adm > ceph auth get-or-create client.ID mon 'profile rbd' osd 'profile profile name \
  [pool=pool-name] [, profile ...]' mgr 'profile rbd [pool=pool-name]'

Erstellen Sie beispielsweise einen Benutzer namens qemu mit Lese- und Schreibzugriff auf die Pool-vms und Nur-Lese-Zugriff auf die Pool-Images mit folgendem Kommando:

ceph auth get-or-create client.qemu mon 'profile rbd' osd 'profile rbd pool=vms, profile rbd-read-only pool=images' \
  mgr 'profile rbd pool=images'

Die Ausgabe des Kommandos ceph auth get-or-create ist der Schlüsselring für den angegebenen Benutzer, der in /etc/ceph/ceph.client.Id.keyring.keyring geschrieben werden kann.

Anmerkung

Wenn Sie das Kommando rbd verwenden, können Sie die Benutzer-ID mit dem optionalen Argument --id ID angeben.

Weitere Details zur Verwaltung von Ceph-Benutzerkonten finden Sie in Kapitel 30, Authentifizierung mit cephx.

20.2.2 Benutzerauthentifizierung #

Geben Sie einen Benutzernamen mit --id user-name an. Bei der cephx-Authentifizierung müssen Sie außerdem ein Geheimnis angeben. Es kann von einem Schlüsselbund stammen oder aus einer Datei, die das Geheimnis enthält:

cephuser@adm > rbd device map --pool rbd myimage --id admin --keyring /path/to/keyring

oder

cephuser@adm > rbd device map --pool rbd myimage --id admin --keyfile /path/to/file

20.2.3 Vorbereiten eines RADOS-Blockgeräts für den Einsatz #

Stellen Sie sicher, dass Ihr Ceph-Cluster einen Pool mit dem Festplatten-Image enthält, das zugeordnet werden soll. Nehmen wir an, der Name des Pools lautet mypool und das Image ist myimage.
```
cephuser@adm > rbd list mypool
```

Ordnen Sie das Image einem neuen Blockgerät zu:

cephuser@adm > rbd device map --pool mypool myimage

Listen Sie alle zugeordneten Geräte auf:
```
cephuser@adm > rbd device list
id pool   image   snap device
0  mypool myimage -    /dev/rbd0
```
Das Gerät, mit dem wir arbeiten möchten, heißt /dev/rbd0.
Tipp: RBD-Gerätepfad
Statt /dev/rbdDEVICE_NUMBER können Sie /dev/rbd/POOL_NAME/IMAGE_NAME als dauerhaften Gerätepfad verwenden. Beispiel:
```
       /dev/rbd/mypool/myimage
```

Erstellen Sie am Gerät namens /dev/rbd0 ein XFS-Dateisystem:

# mkfs.xfs /dev/rbd0
      log stripe unit (4194304 bytes) is too large (maximum is 256KiB)
      log stripe unit adjusted to 32KiB
      meta-data=/dev/rbd0              isize=256    agcount=9, agsize=261120 blks
      =                       sectsz=512   attr=2, projid32bit=1
      =                       crc=0        finobt=0
      data     =                       bsize=4096   blocks=2097152, imaxpct=25
      =                       sunit=1024   swidth=1024 blks
      naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
      log      =internal log           bsize=4096   blocks=2560, version=2
      =                       sectsz=512   sunit=8 blks, lazy-count=1
      realtime =none                   extsz=4096   blocks=0, rtextents=0

Ersetzen Sie /mnt durch Ihren Einhängepunkt, hängen Sie das Gerät ein und prüfen Sie, ob es korrekt eingehängt ist:
```
# mount /dev/rbd0 /mnt
      # mount | grep rbd0
      /dev/rbd0 on /mnt type xfs (rw,relatime,attr2,inode64,sunit=8192,...
```
Nun können Sie Daten auf das und vom Gerät verschieben, als wäre es ein lokales Verzeichnis.
Tipp: Vergrößern des RBD-Geräts
Wenn sich herausstellt, dass die Größe des RBD-Geräts nicht mehr ausreicht, lässt es sich leicht vergrößern.
1. Vergrößern Sie das RBD-Image, beispielsweise auf 10 GB.
  cephuser@adm > rbd resize --size 10000 mypool/myimage Resizing image: 100% complete...done.
2. Erweitern Sie das Dateisystem, bis es die neue Größe des Geräts ausfüllt:
  # xfs_growfs /mnt [...] data blocks changed from 2097152 to 2560000
Wenn Sie Ihre Arbeit an dem Gerät beenden, können Sie dessen Zuordnung aufheben und das Gerät aushängen.
```
cephuser@adm > rbd device unmap /dev/rbd0
# unmount /mnt
```

Tipp: Manuelles Einhängen und Aushängen

Ein rbdmap-Skript und eine systemd-Einheit werden bereitgestellt, um den Prozess des Zuordnens und Einhängens von RBDs nach dem Booten und des Aushängens vor dem Herunterfahren reibungsloser zu gestalten. Weitere Informationen finden Sie unter Abschnitt 20.2.4, „Rbdmap – Zuordnen von RBD-Geräten beim Booten“.

20.2.4 `Rbdmap` – Zuordnen von RBD-Geräten beim Booten #

Das Shell-Skript rbdmap automatisiert die Operationen rbd map und rbd device unmap an einem oder mehreren RBD-Images. Obwohl Sie das Skript jederzeit manuell ausführen können, ist sein wichtigster Vorteil, es automatisch zuordnen und die RBD-Images beim Booten einhängen (und sie beim Herunterfahren aushängen und die Zuordnung aufheben) zu können. Dieser Vorgang wird vom Init-System ausgelöst. Zu diesem Zweck ist eine Datei für die systemd-Einheit (rbdmap.service) im Paket ceph-common enthalten.

Das Skript nimmt ein einzelnes Argument, entweder map oder unmap. In beiden Fällen analysiert das Skript eine Konfigurationsdatei. Die Standardeinstellung /etc/ceph/rbdmap kann mit der Umgebungsvariablen RBDMAPFILE überschrieben werden. Jede Zeile der Konfigurationsdatei entspricht einem RBD-Image, das zugeordnet oder dessen Zuordnung aufgehoben werden soll.

Die Konfigurationsdatei hat das folgende Format:

image_specification rbd_options

image_specification

Pfad zu einem Image in einem Pool. Geben Sie diesen als pool_name/image_name an.

rbd_options

Eine optionale Liste der Parameter, die an das zugrunde liegende Kommando rbd device map weitergegeben werden sollen. Diese Parameter und ihre Werte sollten als durch Komma getrennte Zeichenkette angegeben werden, wie zum Beispiel:

PARAM1=VAL1,PARAM2=VAL2,...

Im Beispiel führt das Skript rbdmap folgendes Kommando aus:

cephuser@adm > rbd device map POOL_NAME/IMAGE_NAME --PARAM1 VAL1 --PARAM2 VAL2

Im folgenden Beispiel wird erläutert, wie Sie einen Benutzernamen und einen Schlüsselbund mit zugehörigem Geheimnis angeben:

cephuser@adm > rbdmap device map mypool/myimage id=rbd_user,keyring=/etc/ceph/ceph.client.rbd.keyring

Wenn das Skript als rbdmap map ausgeführt wird, analysiert es die Konfigurationsdatei und versucht, für jedes angegebene RBD-Image zunächst das Image zuzuordnen (mit dem Kommando rbd device map) und dann das Image einzuhängen.

Wenn es als rbdmap unmap ausgeführt wird, werden die in der Konfigurationsdatei aufgelisteten Images ausgehängt und ihre Zuordnungen werden aufgehoben.

rbdmap unmap-all versucht, alle aktuell zugeordneten RBD-Images auszuhängen und danach deren Zuordnungen aufzuheben, unabhängig davon, ob sie in der Konfigurationsdatei aufgelistet sind.

Bei erfolgreicher Ausführung wird mit dem Vorgang rbd device map das Image einem /dev/rbdX-Gerät zugeordnet. Zu diesem Zeitpunkt wird eine udev-Regel ausgelöst, um einen symbolischen Link zu einem Geräteanzeigenamen /dev/rbd/pool_name/image_name zu erstellen, der auf das reale zugeordnete Gerät zeigt.

Damit das Einhängen und Aushängen erfolgreich ausgeführt wird, muss der Anzeigename des Geräts einen entsprechenden Eintrag in /etc/fstab haben. Geben Sie beim Schreiben von /etc/fstab-Einträgen für RBD-Images die Einhängeoption „noauto“ (oder „nofail“) an. Dadurch wird verhindert, dass das Init-System das Gerät zu früh einhängt, also noch bevor das betreffende Gerät überhaupt vorhanden ist, weil rbdmap.service normalerweise ziemlich spät in der Boot-Sequenz ausgelöst wird.

Eine vollständige Liste der rbd-Optionen finden Sie auf der rbd-Handbuchseite (man 8 rbd).

Beispiele zur Anwendung von rbdmap finden Sie auf der rbdmap-Handbuchseite (man 8 rbdmap).

20.2.5 Vergrößern von RBD-Geräten #

Wenn sich herausstellt, dass die Größe des RBD-Geräts nicht mehr ausreicht, lässt es sich leicht vergrößern.

Vergrößern Sie das RBD-Image, beispielsweise auf 10 GB.

cephuser@adm > rbd resize --size 10000 mypool/myimage
 Resizing image: 100% complete...done.

Erweitern Sie das Dateisystem, bis es die neue Größe des Geräts ausfüllt.
```
# xfs_growfs /mnt
 [...]
 data blocks changed from 2097152 to 2560000
```

20.3 Aufnahmen #

Ein RBD-Image ist eine Snapshot eines RADOS-Block-Device-Image. Mit Snapshots behalten Sie den Verlauf des Zustands eines Image bei: Ceph unterstützt auch ein Snapshot Layering zum schnellen und einfachen Klonen von VM-Images. Ceph unterstützt Blockgeräte-Snapshots mit dem Kommando rbd sowie viele übergeordnete Schnittstellen wie QEMU, libvirt, OpenStack und CloudStack.

Anmerkung

Halten Sie die Eingabe- und Ausgabeoperationen an und entfernen Sie alle ausstehenden Schreibvorgänge, bevor Sie einen Snapshot eines Images anfertigen. Wenn das Image ein Dateisystem enthält, muss sich das Dateisystem zum Zeitpunkt der Snapshot-Erstellung in einem konsistenten Zustand befinden.

20.3.1 Aktivieren und Konfigurieren von `cephx` #

Wenn cephx aktiviert ist, dann müssen Sie einen Benutzernamen oder eine ID und einen Pfad zum Schlüsselbund mit dem entsprechenden Schlüssel für den Benutzer angeben. Weitere Einzelheiten finden Sie im Kapitel 30, Authentifizierung mit cephx. Es ist auch möglich, die Umgebungsvariable CEPH_ARGS hinzuzufügen, um die erneute Eingabe der folgenden Parameter zu verhindern.

cephuser@adm > rbd --id user-ID --keyring=/path/to/secret commands
cephuser@adm > rbd --name username --keyring=/path/to/secret commands

Beispiel:

cephuser@adm > rbd --id admin --keyring=/etc/ceph/ceph.keyring commands
cephuser@adm > rbd --name client.admin --keyring=/etc/ceph/ceph.keyring commands

Tipp

Fügen Sie den Benutzer und das Geheimnis zur Umgebungsvariable CEPH_ARGS hinzu, damit Sie diese Informationen nicht jedes Mal neu eingeben müssen.

20.3.2 Allgemeine Informationen zu Snapshots #

Das folgende Verfahren zeigt, wie Snapshots mit dem Kommando rbd in der Kommandozeile erstellt, aufgelistet und entfernt werden.

20.3.2.1 Erstellen von Snapshots #

Geben Sie zum Erstellen eines Snapshots mit rbd die Option snap create, den Pool-Namen und den Image-Namen an.

cephuser@adm > rbd --pool pool-name snap create --snap snap-name image-name
cephuser@adm > rbd snap create pool-name/image-name@snap-name

Beispiel:

cephuser@adm > rbd --pool rbd snap create --snap snapshot1 image1
cephuser@adm > rbd snap create rbd/image1@snapshot1

20.3.2.2 Auflisten von Snapshots #

Geben Sie zum Auflisten von Snapshots eines Image den Pool-Namen und den Image-Namen an.

cephuser@adm > rbd --pool pool-name snap ls image-name
cephuser@adm > rbd snap ls pool-name/image-name

Beispiel:

cephuser@adm > rbd --pool rbd snap ls image1
cephuser@adm > rbd snap ls rbd/image1

20.3.2.3 Rollback von Snapshots #

Geben Sie zur Durchführung eines Rollbacks zu einem Snapshot mit rbd die Option snap rollback, den Pool-Namen, den Image-Namen und den Namen des Snapshots an.

cephuser@adm > rbd --pool pool-name snap rollback --snap snap-name image-name
cephuser@adm > rbd snap rollback pool-name/image-name@snap-name

Beispiel:

cephuser@adm > rbd --pool pool1 snap rollback --snap snapshot1 image1
cephuser@adm > rbd snap rollback pool1/image1@snapshot1

Anmerkung

Bei einem Rollback eines Image zu einem Snapshot wird die aktuelle Version des Image mit den Daten aus einem Snapshot überschrieben. Ein Rollback dauert umso länger je größer das Image ist. Einen Snapshot zu klonen ist schneller als ein Rollback eines Image zu einem Snapshot durchzuführen und ist die bevorzugte Methode, wenn zu einem früheren Zustand zurückgekehrt werden soll.

20.3.2.4 Löschen eines Snapshots #

Geben Sie zum Löschen eines Snapshots mit rbd die Option snap rm, den Pool-Namen, den Image-Namen und den Benutzernamen an.

cephuser@adm > rbd --pool pool-name snap rm --snap snap-name image-name
cephuser@adm > rbd snap rm pool-name/image-name@snap-name

Beispiel:

cephuser@adm > rbd --pool pool1 snap rm --snap snapshot1 image1
cephuser@adm > rbd snap rm pool1/image1@snapshot1

Anmerkung

Ceph OSDs löschen Daten asynchron. Daher wird beim Löschen eines Snapshots nicht sofort Festplattenspeicherplatz frei.

20.3.2.5 Bereinigen von Snapshots #

Geben Sie zum Entfernen aller Snapshots für ein Image mit rbd die Option snap purge und den Image-Namen an.

cephuser@adm > rbd --pool pool-name snap purge image-name
cephuser@adm > rbd snap purge pool-name/image-name

Beispiel:

cephuser@adm > rbd --pool pool1 snap purge image1
cephuser@adm > rbd snap purge pool1/image1

20.3.3 Snapshot-Layering #

Ceph unterstützt die Möglichkeit zur Erstellung mehrerer COW(copy-on-write)-Klone eines Blockgeräte-Snapshots. Durch ein Snapshot Layering können Ceph-Blockgeräte-Clients Images sehr schnell erstellen. Beispielsweise könnten Sie ein Blockgeräte-Image mit einem darauf geschriebenen Linux VM und danach einen Snapshot von diesem Image erstellen, dann den Snapshot schützen und beliebig viele COW-Klone erstellen. Ein Snapshot ist schreibgeschützt. Daher vereinfacht ein Snapshot die Semantik und ermöglicht es, Klone schnell zu erstellen.

Anmerkung

Die im folgenden Kommandozeilenbeispiel genannten Elemente „parent“ (übergeordnet) und „child“ (untergeordnet) beziehen sich auf einen Ceph-Blockgeräte-Snapshot (parent) und das entsprechende Image, das vom Snapshot geklont wurde (child).

Jedes geklonte Image (child) speichert einen Verweis auf das übergeordnete Image (parent), wodurch das geklonte Image den übergeordneten Snapshot (parent) öffnen und lesen kann.

Ein COW-Klon eines Snapshots verhält sich exakt genauso wie jedes andere Ceph-Blockgeräte-Image. Geklonte Images können gelesen, geschrieben und geklont werden und ihre Größe lässt sich ändern. Geklonte Images haben keine besonderen Einschränkungen. Der COW-Klon eines Snapshots verweist jedoch auf den Snapshot. Daher müssen Sie den Snapshot schützen, bevor Sie ihn klonen.

Anmerkung: --image-format 1 wird nicht unterstützt

Sie können keine Snapshots von Images anfertigen, die mit der veralteten Option rbd create --image-format 1 erstellt wurden. Ceph unterstützt lediglich das Klonen der standardmäßigen format 2-Images.

20.3.3.1 Erste Schritte mit Layering #

Ceph-Blockgeräte-Layering ist ein einfacher Prozess. Sie benötigen ein Image. Sie müssen einen Snapshot vom Image erstellen. Sie müssen den Snapshot schützen. Nach Ausführung dieser Schritte beginnen Sie mit dem Klonen des Snapshots.

Das geklonte Image verweist auf den übergeordneten Snapshot und enthält Pool-ID, Image-ID und Snapshot-ID. Durch die enthaltene Pool-ID können Snapshots von einem Pool zu Images in einem anderen Pool geklont werden.

Image-Schablone: Bei einem üblichen Anwendungsfall für Blockgeräte-Layering wird ein Master Image erstellt und ein Snapshot, der als Schablone für Klone dient. Beispielsweise erstellt ein Benutzer ein Image für eine Linux-Distribution (zum Beispiel SUSE Linux Enterprise Server) und dann einen Snapshot dafür. Der Benutzer aktualisiert möglicherweise das Image regelmäßig und erstellt einen neuen Snapshot (zum Beispiel zypper ref && zypper patch gefolgt von rbd snap create). So wie sich das Image weiterentwickelt, kann der Benutzer beliebige einzelne Snapshots klonen.
Erweiterte Schablone: Bei einem anspruchsvolleren Anwendungsfall wird ein Schablonen-Image erweitert, das mehr Informationen als eine Basis-Image enthält. Beispielsweise könnte ein Benutzer ein Image (eine VM-Schablone) klonen und weitere Software installieren (beispielsweise eine Datenbank, ein Content-Management-System oder ein Analysesystem) und dann einen Snapshot des erweiterten Image erstellen, das genauso wie das Basis-Image aktualisiert wird.
Schablonen-Pool: Eine Methode des Blockgeräte-Layerings ist die Erstellung eines Pools, der Master-Images enthält, die als Schablonen fungieren, sowie Snapshots dieser Schablonen. Sie könnten dann Nur-Lesen-Berechtigungen an Benutzer verteilen. Die Benutzer haben dadurch die Möglichkeit, die Snapshots zu klonen, dürfen jedoch nicht im Pool schreiben oder Vorgänge ausführen.
Image-Migration/Wiederherstellung: Eine Methode des Blockgeräte-Layerings ist die Migration oder Wiederherstellung von Daten von einem Pool in einen anderen Pool.

20.3.3.2 Schützen eines Snapshots #

Klone greifen auf die übergeordneten Snapshots zu. Alle Klone würden zerstört werden, wenn ein Benutzer versehentlich den übergeordneten Snapshot löscht. Sie müssen den Snapshot schützen, bevor Sie ihn klonen, um Datenverlust zu verhindern.

cephuser@adm > rbd --pool pool-name snap protect \
 --image image-name --snap snapshot-name
cephuser@adm > rbd snap protect pool-name/image-name@snapshot-name

Beispiel:

cephuser@adm > rbd --pool pool1 snap protect --image image1 --snap snapshot1
cephuser@adm > rbd snap protect pool1/image1@snapshot1

Anmerkung

Geschützte Snapshots können nicht gelöscht werden.

20.3.3.3 Klonen eines Snapshots #

Zum Klonen eines Snapshots müssen Sie den übergeordneten Pool, das Image, den Snapshot, den untergeordneten Pool und den Image-Namen angeben. Der Snapshot muss vor dem Klonen geschützt werden.

cephuser@adm > rbd clone --pool pool-name --image parent-image \
 --snap snap-name --dest-pool pool-name \
 --dest child-image
cephuser@adm > rbd clone pool-name/parent-image@snap-name \
pool-name/child-image-name

Beispiel:

cephuser@adm > rbd clone pool1/image1@snapshot1 pool1/image2

Anmerkung

Ein Snapshot kann von einem Pool zu einem Image in einem anderen Pool geklont werden. Sie könnten beispielsweise schreibgeschützte Images und Snapshots als Schablonen in einem Pool beibehalten und beschreibbare Klone in einem anderen Pool.

20.3.3.4 Aufheben des Schutzes eines Snapshots #

Vor dem Löschen eines Snapshots muss zunächst dessen Schutz aufgehoben werden. Außerdem dürfen Sie keine Snapshots löschen, die Verweise von Klonen enthalten. Sie müssen jeden Klon eines Snapshots vereinfachen, bevor Sie den Snapshot löschen.

cephuser@adm > rbd --pool pool-name snap unprotect --image image-name \
 --snap snapshot-name
cephuser@adm > rbd snap unprotect pool-name/image-name@snapshot-name

Beispiel:

cephuser@adm > rbd --pool pool1 snap unprotect --image image1 --snap snapshot1
cephuser@adm > rbd snap unprotect pool1/image1@snapshot1

20.3.3.5 Auflisten der untergeordneten Klone eines Snapshots #

Führen Sie zum Auflisten der untergeordneten Klone eines Snapshots folgendes Kommando aus:

cephuser@adm > rbd --pool pool-name children --image image-name --snap snap-name
cephuser@adm > rbd children pool-name/image-name@snapshot-name

Beispiel:

cephuser@adm > rbd --pool pool1 children --image image1 --snap snapshot1
cephuser@adm > rbd children pool1/image1@snapshot1

20.3.3.6 Vereinfachen eines geklonten Images #

Geklonte Images behalten einen Verweis auf den übergeordneten Snapshot bei. Wenn Sie den Verweis vom untergeordneten Klon zum übergeordneten Snapshot entfernen, wird das Image tatsächlich „vereinfacht“, indem die Informationen vom Snapshot zum Klon kopiert werden. Die Vereinfachung eines Klons dauert umso länger je größer der Snapshot ist. Zum Löschen eines Snapshots müssen Sie zunächst die untergeordneten Images vereinfachen.

cephuser@adm > rbd --pool pool-name flatten --image image-name
cephuser@adm > rbd flatten pool-name/image-name

Beispiel:

cephuser@adm > rbd --pool pool1 flatten --image image1
cephuser@adm > rbd flatten pool1/image1

Anmerkung

Da ein vereinfachtes Image alle Informationen des Snapshots enthält, belegt ein vereinfachtes Image mehr Speicherplatz als ein Layering-Klon.

20.4 RBD-Image-Spiegel #

RBD-Images können asynchron zwischen zwei Ceph-Clustern gespiegelt werden. Diese Funktion ist in zwei Modi verfügbar:

Journal-basiert: Bei diesem Modus wird die Funktion des RBD-Journaling-Image verwendet, um die absturzkonsistente Reproduktion zwischen Clustern sicherzustellen. Jeder Schreibvorgang in das RBD-Image wird zunächst im zugehörigen Journal aufgezeichnet, bevor das eigentliche Image geändert wird. Der Remote-Cluster liest aus dem Journal und gibt die Aktualisierungen in seiner lokalen Kopie des Image wieder. Da jeder Schreibvorgang auf das RBD-Image zu zwei Schreibvorgängen auf dem Ceph-Cluster führt, müssen Sie bei Verwendung der RBD-Journaling-Image-Funktion mit nahezu doppelt so langen Schreiblatenzen rechnen.
Snapshot-basiert: Dieser Modus verwendet periodisch geplante oder manuell erstellte RBD-Image-Spiegel-Snapshots, um absturzsichere RBD-Images zwischen Clustern zu reproduzieren. Der Remote-Cluster ermittelt alle Daten- oder Metadaten-Aktualisierungen zwischen zwei Spiegel-Snapshots und kopiert die Deltas in seine lokale Kopie des Image. Mit Hilfe der RBD-Image-Funktion „fast-diff“ können aktualisierte Datenblöcke schnell berechnet werden, ohne dass das gesamte RBD-Image abgesucht werden muss. Da dieser Modus nicht zeitpunktkonsistent ist, muss das vollständige Snapshot-Delta vor der Verwendung in einem Failover-Szenario synchronisiert werden. Alle teilweise angewendeten Snapshot-Deltas werden vor der Verwendung auf den letzten vollständig synchronisierten Snapshot zurückgesetzt.

Die Spiegelung wird pro Pool in den Peer-Clustern konfiguriert. Dies kann für eine bestimmte Untergruppe von Images innerhalb des Pools konfiguriert werden oder so, dass alle Images innerhalb eines Pools automatisch gespiegelt werden, wenn nur die Journal-basierte Spiegelung verwendet wird. Die Spiegelung wird mit dem rbd-Kommando ausgeführt. Der rbd-mirror-Daemon ist dafür zuständig, Image-Aktualisierungen aus dem Remote-Peer-Cluster zu entnehmen und sie auf das Image im lokalen Cluster anzuwenden.

Abhängig von den gewünschten Anforderungen an die Reproduktion kann die RBD-Spiegelung entweder für eine ein- oder zweiseitige Reproduktion konfiguriert werden:

Einseitige Reproduktion: Wenn Daten nur von einem primären Cluster auf einen sekundären Cluster gespiegelt werden, läuft der rbd-mirror-Daemon nur auf dem sekundären Cluster.
Zweiseitige Reproduktion: Wenn Daten von primären Images auf einem Cluster auf nicht primäre Images auf einem anderen Cluster gespiegelt werden (und umgekehrt), wird der rbd-mirror-Daemon auf beiden Clustern ausgeführt.

Wichtig

Jede Instanz des rbd-mirror-Daemons muss in der Lage sein, sich gleichzeitig mit dem lokalen und dem Remote-Ceph-Cluster zu verbinden, beispielsweise mit allen Überwachungs- und OSD-Hosts. Außerdem muss das Netzwerk über eine ausreichende Bandbreite zwischen den beiden Rechenzentren verfügen, um die Spiegelung des Workloads zu bewältigen.

20.4.1 Pool-Konfiguration #

Die folgenden Verfahren zeigen, wie einfache Verwaltungsaufgaben zum Konfigurieren der Spiegelung mit dem rbd-Kommando ausgeführt werden. Die Spiegelung wird pro Pool in den Ceph-Clustern konfiguriert.

Sie müssen die Schritte zur Pool-Konfiguration an beiden Peer-Clustern ausführen. Bei diesen Verfahren wird der Einfachheit halber angenommen, dass von einem einzelnen Host aus auf zwei Cluster (lokal und Remote) zugegriffen werden kann.

Weitere detaillierte Informationen zum Herstellen einer Verbindung zu verschiedenen Ceph-Clustern finden Sie auf der rbd-Handbuchseite (man 8 rbd).

Tipp: Mehrere Cluster

Der Clustername in den folgenden Beispielen entspricht einer Ceph-Konfigurationsdatei mit dem gleichen Namen /etc/ceph/remote.conf und einer Ceph-Schlüsselbunddatei mit dem gleichen Namen /etc/ceph/remote.client.admin.keyring.

20.4.1.1 Aktivieren der Spiegelung für einen Pool #

Geben Sie zum Aktivieren der Spiegelung in einem Pool das Unterkommando mirror pool enable, den Pool-Namen und den Spiegelungsmodus an. Der Spiegelungsmodus kann entweder „pool“ oder „image“ lauten:

Speicherplatz auf dem Pool: Alle Images im Pool mit aktivierter Journaling-Funktion werden gespiegelt.
Image: Die Spiegelung muss auf jedem Image explizit aktiviert werden. Weitere Informationen zu diesem Thema finden Sie unter dem Stichwort Abschnitt 20.4.2.1, „Aktivieren der Image-Spiegelung“.

Beispiel:

cephuser@adm > rbd --cluster local mirror pool enable POOL_NAME pool
cephuser@adm > rbd --cluster remote mirror pool enable POOL_NAME pool

20.4.1.2 Deaktivieren der Spiegelung #

Geben Sie zum Deaktivieren der Spiegelung in einem Pool das Unterkommando mirror pool disable und den Pool-Namen an. Wenn die Spiegelung auf diese Weise in einem Pool deaktiviert wird, dann wird sie auch in anderen Images (im Pool) deaktiviert, für die eine Spiegelung explizit aktiviert wurde.

cephuser@adm > rbd --cluster local mirror pool disable POOL_NAME
cephuser@adm > rbd --cluster remote mirror pool disable POOL_NAME

20.4.1.3 Bootstrapping von Peers #

Damit der rbd-mirror-Daemon seinen Peer-Cluster erkennen kann, muss der Peer im Pool registriert und ein Benutzerkonto angelegt werden. Dieser Vorgang kann mit rbd und den Kommandos mirror pool peer bootstrap create und mirror pool peer bootstrap import automatisiert werden.

Um ein neues Bootstrap-Token mit rbd manuell zu erstellen, geben Sie das Kommando mirror pool peer bootstrap create, einen Pool-Namen sowie einen optionalen Anzeigenamen für den Standort zur Beschreibung des lokalen Clusters an:

cephuser@local > rbd mirror pool peer bootstrap create \
 [--site-name LOCAL_SITE_NAME] POOL_NAME

Die Ausgabe von mirror pool peer bootstrap create ist ein Token, das dem Kommando mirror pool peer bootstrap import übergeben werden sollte, beispielsweise am lokalen Cluster:

cephuser@local > rbd --cluster local mirror pool peer bootstrap create --site-name local image-pool
eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW1pcnJvci1wZWVyIiwia2V5I \
joiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1vbl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==

Importieren Sie über folgende Syntax mit dem Kommando rbd das von einem anderen Cluster erstellte Bootstrap-Token manuell:

rbd mirror pool peer bootstrap import \
 [--site-name LOCAL_SITE_NAME] \
 [--direction DIRECTION \
 POOL_NAME TOKEN_PATH

Ort:

LOCAL_SITE_NAME: Ein optionaler Anzeigename für den Standort zum Beschreiben des lokalen Clusters.
DIRECTION: Eine Spiegelrichtung. Die Standardeinstellung ist rx-tx für die zweiseitige Spiegelung, kann aber auch auf rx-only für die einseitige Spiegelung festgelegt werden.
POOL_NAME: Name des Pools.
TOKEN_PATH: Ein Dateipfad zum erstellten Token (oder -, um es von der Standardeingabe zu lesen),

beispielsweise am Remote-Cluster:

cephuser@remote > cat <<EOF > token
eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1vbl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==
EOF

cephuser@adm > rbd --cluster remote mirror pool peer bootstrap import \
 --site-name remote image-pool token

20.4.1.4 Manuelles Hinzufügen eines Cluster-Peers #

Alternativ zum Bootstrapping von Peers, wie in Abschnitt 20.4.1.3, „Bootstrapping von Peers“ beschrieben, können Sie Peers auch manuell angeben. Der entfernte rbd-mirror-Daemon benötigt zur Durchführung der Spiegelung Zugriff auf den lokalen Cluster. Erstellen Sie einen neuen lokalen Ceph-Benutzer, den der entfernte rbd-mirror-Daemon verwendet, z. B. rbd-mirror-peer:

cephuser@adm > ceph auth get-or-create client.rbd-mirror-peer \
 mon 'profile rbd' osd 'profile rbd'

Verwenden Sie die folgende Syntax, um einen Spiegelungs-Peer-Ceph-Cluster mit dem Kommando rbd hinzuzufügen:

rbd mirror pool peer add POOL_NAME CLIENT_NAME@CLUSTER_NAME

Beispiel:

cephuser@adm > rbd --cluster site-a mirror pool peer add image-pool client.rbd-mirror-peer@site-b
cephuser@adm > rbd --cluster site-b mirror pool peer add image-pool client.rbd-mirror-peer@site-a

Standardmäßig muss der rbd-mirror-Daemon Zugriff auf die Ceph-Konfigurationsdatei haben, die sich unter /etc/ceph/.CLUSTER_NAME.conf befindet. Es stellt IP-Adressen der MONs des Peer-Clusters und einen Schlüsselring für einen Client namens CLIENT_NAME bereit, der sich in den Standard- oder benutzerdefinierten Schlüsselring-Suchpfaden befindet, z. B. /etc/ceph/CLUSTER_NAME.CLIENT_NAME.keyring.

Alternativ kann der MON- und/oder Client-Schlüssel des Peer-Clusters sicher im lokalen config-Schlüsselspeicher von Ceph gespeichert werden. Geben Sie die Verbindungsattribute des Peer-Clusters beim Hinzufügen eines Spiegelungs-Peers mit den Optionen --remote-mon-host und --remote-key-file an. Beispiel:

cephuser@adm > rbd --cluster site-a mirror pool peer add image-pool \
 client.rbd-mirror-peer@site-b --remote-mon-host 192.168.1.1,192.168.1.2 \
 --remote-key-file /PATH/TO/KEY_FILE
cephuser@adm > rbd --cluster site-a mirror pool info image-pool --all
Mode: pool
Peers:
  UUID        NAME   CLIENT                 MON_HOST                KEY
  587b08db... site-b client.rbd-mirror-peer 192.168.1.1,192.168.1.2 AQAeuZdb...

20.4.1.5 Entfernen des Cluster-Peers #

Geben Sie zum Entfernen eines Peer Clusters für die Spiegelung das Unterkommando mirror pool peer remove, den Pool-Namen und die Peer-UUID (verfügbar über das Kommando rbd mirror pool info) an:

cephuser@adm > rbd --cluster local mirror pool peer remove POOL_NAME \
 55672766-c02b-4729-8567-f13a66893445
cephuser@adm > rbd --cluster remote mirror pool peer remove POOL_NAME \
 60c0e299-b38f-4234-91f6-eed0a367be08

20.4.1.6 Datenpools #

Beim Erstellen von Images im Zielcluster wählt rbd-mirror einen Datenpool wie folgt aus:

Wenn der Ziel-Cluster einen Standard-Datenpool konfiguriert hat (mit der Konfigurationsoption rbd_default_data_pool), wird dieser verwendet.
Andernfalls, wenn das Quell-Image einen separaten Datenpool verwendet und ein Pool mit demselben Namen auf dem Ziel-Cluster vorhanden ist, wird dieser Pool verwendet.
Wenn keiner der beiden oben genannten Punkte zutrifft, wird kein Datenpool festgelegt.

20.4.2 RBD-Image-Konfiguration #

Im Gegensatz zur Pool-Konfiguration muss die Image-Konfiguration nur für einen einzigen für die Spiegelung vorgesehenen Peer Ceph-Cluster durchgeführt werden.

Gespiegelte RBD-Images werden entweder als primär oder nicht primär ausgewiesen. Dies ist eine Eigenschaft des Image und nicht des Pools. Als nicht primär ausgewiesene Images können nicht bearbeitet werden.

Images werden automatisch zu primären Images hochgestuft, wenn die Spiegelung zuvor für ein Image aktiviert wird (entweder implizit mit dem Pool-Spiegelungsmodus „pool“ und durch Aktivieren der Journaling-Funktion für das Image oder explizit (Informationen hierzu finden Sie in Abschnitt 20.4.2.1, „Aktivieren der Image-Spiegelung“) mit dem rbd-Kommando).

20.4.2.1 Aktivieren der Image-Spiegelung #

Wenn eine Spiegelung im Modus Image konfiguriert ist, muss die Spiegelung für jedes Image im Pool explizit aktiviert werden. Geben Sie zum Aktivieren der Spiegelung für ein bestimmtes Image mit rbd das Unterkommando mirror image enable zusammen mit dem Pool- und dem Image-Namen an:

cephuser@adm > rbd --cluster local mirror image enable \
 POOL_NAME/IMAGE_NAME

Der Spiegel-Image-Modus kann entweder Journal oder Snapshot lauten:

Journal (Standardeinstellung): Wenn die Spiegelung im Journal-Modus konfiguriert ist, wird mit der RBD-Journaling-Image-Funktion der Image-Inhalt reproduziert. Wenn die RBD-Journaling-Image-Funktion noch nicht für das Image aktiviert ist, wird sie automatisch aktiviert.
Snapshot: Wenn die Spiegelung im Snapshot-Modus konfiguriert ist, verwendet sie RBD-Image-Spiegel-Snapshots zum Reproduzieren des Image-Inhalts. Wenn diese Option aktiviert ist, wird automatisch ein erster Spiegel-Snapshot erstellt. Zusätzliche RBD-Image-Spiegel-Snapshots können mit dem Kommando rbd erstellt werden.

Beispiel:

cephuser@adm > rbd --cluster local mirror image enable image-pool/image-1 snapshot
cephuser@adm > rbd --cluster local mirror image enable image-pool/image-2 journal

20.4.2.2 Aktivieren der Image-Journaling-Funktion #

Bei der RBD-Spiegelung wird immer die RBD Journaling-Funktion verwendet, um sicherzustellen, dass das reproduzierte Image immer absturzkonsistent bleibt. Bei Verwendung des Image-Spiegelungsmodus wird die Journaling-Funktion automatisch aktiviert, wenn die Spiegelung auf dem Image aktiviert ist. Wenn Sie den Pool-Spiegelungsmodus verwenden, muss die RBD-Image-Journaling-Funktion aktiviert sein, bevor ein Image auf einen Peer-Cluster gespiegelt werden kann. Die Funktion kann bei der Image-Erstellung durch Angabe der Option --image-feature exclusive-lock,journaling für das rbd-Kommando aktiviert werden.

Alternativ kann die Journaling-Funktion für bereits vorhandene RBD-Images dynamisch aktiviert werden. Geben Sie zum Aktivieren des Journaling den Unterbefehl feature enable, den Pool-Namen, den Image-Namen und den Namen der Funktion an:

cephuser@adm > rbd --cluster local feature enable POOL_NAME/IMAGE_NAME exclusive-lock
cephuser@adm > rbd --cluster local feature enable POOL_NAME/IMAGE_NAME journaling

Anmerkung: Abhängigkeit der Option

Die Funktion journaling hängt von der Funktion exclusive-lock ab. Wenn die Funktion exclusive-lock nicht bereits aktiviert ist, müssen Sie diese vor Aktivierung der Funktion journaling aktivieren.

Tipp

Sie können das Journaling für alle neuen Images standardmäßig aktivieren, indem Sie rbd default features = layering,exclusive-lock,object-map,deep-flatten,journaling zu Ihrer Ceph-Konfigurationsdatei hinzufügen.

20.4.2.3 Erstellen von Image-Spiegel-Snapshots #

Bei der Snapshot-basierten Spiegelung müssen immer dann Spiegel-Snapshots erstellt werden, wenn der geänderte Inhalt des RBD-Image gespiegelt werden soll. Geben Sie zum manuellen Erstellen eines Spiegel-Snapshots mit rbd das Kommando mirror image snapshot zusammen mit dem Pool- und dem Image-Namen an:

cephuser@adm > rbd mirror image snapshot POOL_NAME/IMAGE_NAME

Beispiel:

cephuser@adm > rbd --cluster local mirror image snapshot image-pool/image-1

Standardmäßig werden nur drei Spiegel-Snapshots pro Image erstellt. Der letzte Spiegel-Snapshot wird automatisch entfernt, wenn das Limit erreicht ist. Das Limit kann bei Bedarf über die Konfigurationsoption rbd_mirroring_max_mirroring_snapshots außer Kraft gesetzt werden. Außerdem werden Spiegel-Snapshots automatisch gelöscht, wenn das Image entfernt oder die Spiegelung deaktiviert wird.

Spiegel-Snapshots können auch automatisch auf periodischer Basis erstellt werden, wenn Spiegel-Snapshot-Zeitpläne definiert sind. Der Spiegel-Snapshot kann auf globaler Ebene, pro Pool oder pro Image geplant werden. Es können zwar mehrere Zeitpläne für Spiegel-Snapshots auf jeder Ebene definiert werden, doch nur die spezifischsten Snapshot-Zeitpläne, die zu einem einzelnen gespiegelten Image passen, werden ausgeführt.

Geben Sie zum Erstellen eines Spiegel-Snapshot-Zeitplans mit rbd das Kommando mirror snapshot schedule add zusammen mit einem optionalen Pool- oder Image-Namen, einem Intervall und einer optionalen Startzeit an.

Das Intervall kann in Tagen, Stunden oder Minuten mit den entsprechenden Suffixen d, h oder m angegeben werden. Die optionale Startzeit wird im ISO 8601-Zeitformat angegeben. Beispiel:

cephuser@adm > rbd --cluster local mirror snapshot schedule add --pool image-pool 24h 14:00:00-05:00
cephuser@adm > rbd --cluster local mirror snapshot schedule add --pool image-pool --image image1 6h

Geben Sie zum Entfernen eines Spiegel-Snapshot-Zeitplans mit rbd das Kommando mirror snapshot schedule remove mit Optionen an, die dem entsprechenden Kommando „add schedule“ entsprechen.

Geben Sie zum Auflisten aller Snapshot-Zeitpläne für eine bestimmte Ebene (global, Pool oder Image) mit rbd das Kommando mirror snapshot schedule ls zusammen mit einem optionalen Pool- oder Image-Namen an. Zusätzlich kann die Option --recursive angegeben werden, um alle Zeitpläne auf der angegebenen Ebene und darunter aufzulisten. Beispiel:

cephuser@adm > rbd --cluster local mirror schedule ls --pool image-pool --recursive
POOL        NAMESPACE IMAGE  SCHEDULE
image-pool  -         -      every 1d starting at 14:00:00-05:00
image-pool            image1 every 6h

Um herauszufinden, wann die nächsten Snapshots für die Snapshot-basierte Spiegelung von RBD-Images mit rbd erstellt werden, geben Sie das Kommando mirror snapshot schedule status zusammen mit einem optionalen Pool- oder Image-Namen an. Beispiel:

cephuser@adm > rbd --cluster local mirror schedule status
SCHEDULE TIME       IMAGE
2020-02-26 18:00:00 image-pool/image1

20.4.2.4 Aktivieren der Image-Spiegelung #

Geben Sie zum Deaktivieren der Spiegelung für ein bestimmtes Image das Unterkommando mirror image disable zusammen mit dem Pool- und Image-Namen an:

cephuser@adm > rbd --cluster local mirror image disable POOL_NAME/IMAGE_NAME

20.4.2.5 Hoch- und Herabstufen von Images #

In einem Failover-Szenario, in dem die primäre Bezeichnung zum Image im Peer Cluster verschoben werden muss, müssen Sie den Zugriff auf das primäre Image stoppen, das aktuelle primäre Image herabstufen, das neue primäre Image hochstufen und den Zugriff auf das Image am alternativen Cluster wieder aufnehmen.

Anmerkung: Erzwungene Hochstufung

Die Hochstufung wird mit der Option --force erzwungen. Die erzwungene Hochstufung ist erforderlich, wenn die Herabstufung nicht auf den Peer Cluster übertragen werden kann (beispielsweise im Fall eines Cluster-Fehlers oder Kommunikationsausfalls). Dies führt zu einem Split-Brain-Szenario zwischen den beiden Peers und das Image wird nicht mehr synchronisiert, bis ein Unterkommando resync ausgestellt wird.

Geben Sie zum Herabstufen eines bestimmten Image zu „nicht primär“ das Unterkommando mirror image demote zusammen mit dem Pool- und Image-Namen an:

cephuser@adm > rbd --cluster local mirror image demote POOL_NAME/IMAGE_NAME

Geben Sie zum Herabstufen aller primären Images in einem Pool zu „nicht primär“ das Unterkommando mirror pool demote zusammen mit dem Pool-Namen an:

cephuser@adm > rbd --cluster local mirror pool demote POOL_NAME

Geben Sie zum Hochstufen eines bestimmten Image zu „primär“ das Unterkommando mirror image promote zusammen mit dem Pool- und Image-Namen an:

cephuser@adm > rbd --cluster remote mirror image promote POOL_NAME/IMAGE_NAME

Geben Sie zum Hochstufen aller primären Images in einem Pool zu „primär“ das Unterkommando mirror pool promote zusammen mit dem Pool-Namen an:

cephuser@adm > rbd --cluster local mirror pool promote POOL_NAME

Tipp: Aufteilen der E/A-Last

Da der Status „primär“ oder „nicht primär“ pro Image gilt, ist es möglich, die E/A-Last auf zwei Cluster aufzuteilen und dort ein Failover oder Failback durchzuführen.

20.4.2.6 Erzwingen der erneuten Image-Synchronisierung #

Wenn der rbd-mirror-Daemon ein Split Brain-Szenario erkennt, versucht er erst wieder, das betreffende Image zu spiegeln, wenn das Problem behoben ist. Um die Spiegelung für ein Image wieder aufzunehmen, müssen Sie zunächst das Image, das als veraltet ermittelt wurde, herabstufen und dann eine erneute Synchronisierung mit dem primären Image anfordern. Geben Sie zum Anfordern einer erneuten Synchronisierung des Image das Unterkommando mirror image resync zusammen mit dem Pool- und Image-Namen an:

cephuser@adm > rbd mirror image resync POOL_NAME/IMAGE_NAME

20.4.3 Prüfen des Spiegelungsstatus #

Der Reproduktionsstatus des Peer Clusters wird für jedes primäre gespiegelte Image gespeichert. Dieser Status wird mit den Unterkommandos mirror image status und mirror pool status abgerufen:

Geben Sie zum Anfordern des Spiegel-Image-Status das Unterkommando mirror image status zusammen mit dem Pool- und Image-Namen an:

cephuser@adm > rbd mirror image status POOL_NAME/IMAGE_NAME

Geben Sie zum Anfordern einer Übersicht zum Spiegel-Pool-Status das Unterkommando mirror pool status zusammen mit dem Pool-Namen an:

cephuser@adm > rbd mirror pool status POOL_NAME

Tipp:

Durch Hinzufügen der Option --verbose zum Unterkommando mirror pool status werden zusätzlich Statusdetails für jedes Spiegel-Image im Pool ausgegeben.

20.5 Cache-Einstellungen #

Die Implementierung des Benutzerbereichs auf dem Ceph-Blockgerät (librbd) kann den Linux-Seiten-Cache nicht nutzen. Sie umfasst daher ein eigenes Caching im Speicher. Das RBD-Caching läuft ähnlich ab wie das Festplatten-Caching. Wenn das Betriebssystem eine Sperre oder eine Verschiebungsanforderung sendet, werden alle kürzlich bearbeiteten („dirty“) Daten auf die OSDs geschrieben. Dies bedeutet, dass das Caching mit Zurückschreiben ebenso sicher ist wie eine wohldefinierte physische Festplatte mit einer VM, die ordnungsgemäß Verschiebungen sendet. Der Cache beruht auf einem Least-Recently-Used(LRU)-Algorithmus; im Zurückschreiben-Modus kann er nebeneinanderliegende Anforderungen zusammenführen und damit den Durchsatz erhöhen.

Ceph unterstützt das Caching mit Zurückschreiben für RBD. Aktivieren Sie es mit

cephuser@adm > ceph config set client rbd_cache true

Standardmäßig nimmt librbd kein Caching vor. Schreib- und Lesevorgänge gehen direkt in den Speicher-Cluster und Schreibvorgänge werden nur dann zurückgegeben, wenn sich die Daten in allen Reproduktionen auf dem Datenträger befinden. Bei aktiviertem Caching werden Schreibvorgänge sofort zurückgegeben, außer die Menge der nicht verschobenen Daten (in Byte) ist höher als der Wert der Option rbd cache max dirty. Der Schreibvorgang löst in diesem Fall das Zurückschreiben aus und bleibt so lange gesperrt, bis eine ausreichende Datenmenge verschoben wurde.

Ceph unterstützt das Caching mit Durchschreiben für RBD. Sie können die Größe des Caches festlegen und auch die Ziele und Einschränkungen vom Caching mit Zurückschreiben auf das Caching mit Durchschreiben umstellen. Aktivieren Sie den Durchschreiben-Modus mit

cephuser@adm > ceph config set client rbd_cache_max_dirty 0

Dies bedeutet, dass Schreibvorgänge nur dann zurückgegeben werden, wenn sich die Daten in allen Reproduktionen auf dem Datenträger befinden; Lesevorgänge können dagegen aus dem Cache stammen. Der Cache befindet sich im Speicher auf dem Client und jedes RBD-Image umfasst einen eigenen Cache. Da sich der Cache lokal auf dem Client befindet, ist keine Kohärenz gegeben, wenn andere auf das Image zugreifen. Bei aktiviertem Caching können GFS oder OCFS nicht zusätzlich zu RBD ausgeführt werden.

Die folgenden Parameter beeinflussen das Verhalten von RADOS-Blockgeräten. Legen Sie sie mit der Client-Kategorie fest:

cephuser@adm > ceph config set client PARAMETER VALUE

rbd cache: Caching für RADOS Block Device (RBD) aktivieren. Die Standardeinstellung ist „true“.
rbd cache size: Größe des RBD-Caches (in Byte). Standardwert ist 32 MB.
rbd cache max dirty: Grenzwert für die Menge der kürzlich bearbeiteten („dirty“) Daten, bei dem der Cache das Zurückschreiben auslöst. rbd cache max dirty muss kleiner als rbd cache size sein. Beim Wert 0 wird das Caching mit Durchschreiben herangezogen. Standardwert ist 24 MB.
rbd cache target dirty: Das kürzlich bearbeitete Ziel („dirty target“), bevor der Cache die ersten Daten in den Datenspeicher schreibt. Blockiert keine Schreibvorgänge in den Cache. Standardwert ist 16 MB.
rbd cache max dirty age: Zeitraum (in Sekunden), über den soeben bearbeitete Daten im Cache verbleiben, bevor das Zurückschreiben beginnt. Der Standardwert ist 1.
rbd cache writethrough until flush: Der Vorgang beginnt im Durchschreiben-Modus und wechselt zum Zurückschreiben, sobald die erste Verschiebungsanforderung eingeht. Dies ist eine konservative, jedoch sichere Einstellung für den Fall, dass virtuelle Maschinen mit rbd zu alt sind, um Verschiebungen zu senden (z. B. der Virtio-Treiber in Linux vor Kernel 2.6.32). Die Standardeinstellung ist „true“.

20.6 QoS-Einstellungen #

„Quality of Service“ (QoS) bezeichnet im Allgemeinen verschiedene Methoden, mit denen der Datenverkehr priorisiert und Ressourcen reserviert werden. Dies ist insbesondere für Datenverkehr mit besonderen Anforderungen von Bedeutung.

Wichtig: Keine Unterstützung durch iSCSI

Die folgenden QoS-Einstellungen werden ausschließlich durch die Benutzerbereichs-RBD-Implementierung librbd verwendet, nicht jedoch von der kRBD-Implementierung. iSCSI greift auf kRBD zurück und nutzt daher nicht die QoS-Einstellungen. Für iSCSI können Sie jedoch QoS mit den standardmäßigen Kernel-Funktionen in der Kernel-Blockgeräteschicht konfigurieren.

rbd qos iops limit: Gewünschter Grenzwert für die E/A-Operationen pro Sekunde. Der Standardwert ist 0 (keine Einschränkung).
rbd qos bps limit: Gewünschter Grenzwert für die E/A-Datenmenge (in Byte) pro Sekunde. Der Standardwert ist 0 (keine Einschränkung).
rbd qos read iops limit: Gewünschter Grenzwert für die Leseoperationen pro Sekunde. Der Standardwert ist 0 (keine Einschränkung).
rbd qos write iops limit: Gewünschter Grenzwert für die Schreiboperationen pro Sekunde. Der Standardwert ist 0 (keine Einschränkung).
rbd qos read bps limit: Gewünschter Grenzwert für die gelesene Datenmenge (in Byte) pro Sekunde. Der Standardwert ist 0 (keine Einschränkung).
rbd qos write bps limit: Gewünschter Grenzwert für die geschriebene Datenmenge (in Byte) pro Sekunde. Der Standardwert ist 0 (keine Einschränkung).
rbd qos iops burst: Gewünschter Blockgrenzwert für E/A-Operationen. Der Standardwert ist 0 (keine Einschränkung).
rbd qos bps burst: Gewünschter Blockgrenzwert für die E/A-Datenmenge (in Byte). Der Standardwert ist 0 (keine Einschränkung).
rbd qos read iops burst: Gewünschter Blockgrenzwert für Leseoperationen. Der Standardwert ist 0 (keine Einschränkung).
rbd qos write iops burst: Gewünschter Blockgrenzwert für Schreiboperationen. Der Standardwert ist 0 (keine Einschränkung).
rbd qos read bps burst: Gewünschter Blockgrenzwert für die gelesene Datenmenge (in Byte). Der Standardwert ist 0 (keine Einschränkung).
rbd qos write bps burst: Gewünschter Blockgrenzwert für die geschriebene Datenmenge (in Byte). Der Standardwert ist 0 (keine Einschränkung).
rbd qos schedule tick min: Minimaler Zeitplanimpuls (in Millisekunden) für QoS. Der Standardwert ist 50.

20.7 Read-Ahead-Einstellungen #

RADOS Block Device unterstützt das Read-Ahead/Prefetching zur Optimierung kleiner, sequenzieller Lesevorgänge. Bei einer virtuellen Maschine wird dies in der Regel durch das Gast-Betriebssystem abgewickelt, doch Bootloader geben unter Umständen keine effizienten Lesevorgänge aus. Das Read-Ahead wird automatisch deaktiviert, wenn das Caching aktiviert ist.

Wichtig: Keine Unterstützung durch iSCSI

Die folgenden Read-Ahead-Einstellungen werden ausschließlich durch die Benutzerbereichs-RBD-Implementierung librbd verwendet, nicht jedoch von der kRBD-Implementierung. iSCSI greift auf kRBD zurück und nutzt daher nicht die Read-Ahead-Einstellungen. Für iSCSI können Sie jedoch Read-Ahead mit den standardmäßigen Kernel-Funktionen in der Kernel-Blockgeräteschicht konfigurieren.

rbd readahead trigger requests: Anzahl der sequenziellen Leseanforderungen, die zum Auslösen des Read-Ahead erforderlich sind. Der Standardwert ist 10.
rbd readahead max bytes: Maximale Größe einer Read-Ahead-Anforderung. Beim Wert 0 ist das Read-Ahead deaktiviert. Der Standardwert ist 512 KB.
rbd readahead disable after bytes: Sobald die angegebene Datenmenge (in Byte) aus einem RBD-Image gelesen wurde, wird das Read-Ahead für dieses Image deaktiviert, bis es geschlossen wird. Damit kann das Gast-Betriebssystem das Read-Ahead beim Starten übernehmen. Beim Wert 0 bleibt das Read-Ahead aktiviert. Der Standardwert ist 50 MB.

20.8 Erweiterte Funktionen #

RADOS Block Device unterstützt erweiterte Funktionen, die den Funktionsumfang von RBD-Images vergrößern. Sie können die Funktionen entweder in der Kommandozeile beim Erstellen eines RBD-Images angeben oder in der Ceph-Konfigurationsdatei mit der Option rbd_default_features.

Die Werte für die Option rbd_default_features können auf zwei Arten angegeben werden:

als Summe der internen Werte der Funktion. Jede Funktion besitzt einen eigenen internen Wert – „layering“ beispielsweise den Wert 1 und „fast-diff“ den Wert 16. Sollen diese beiden Funktionen standardmäßig aktiviert werden, geben Sie daher Folgendes an:
```
rbd_default_features = 17
```
als durch Komma getrennte Liste mit Funktionen. Das obige Beispiel sieht wie folgt aus:
```
rbd_default_features = layering,fast-diff
```

Anmerkung: Funktionen ohne Unterstützung durch iSCSI

RBD-Images mit den folgenden Funktionen werden nicht durch iSCSI unterstützt: deep-flatten, object-map, journaling, fast-diff, striping

Liste der erweiterten RBD-Funktionen:

layering

Mit dem Layering können Sie Elemente klonen.

Der interne Wert ist gleich 1, die Standardeinstellung lautet „yes“.

striping

Das Striping verteilt Daten auf mehrere Objekte und bewirkt Parallelität für sequenzielle Lese-/Schreib-Workloads. Damit werden Engpässe durch einzelne Knoten bei großen oder stark ausgelasteten RADOS Block Devices verhindert.

Der interne Wert ist gleich 2, die Standardeinstellung lautet „yes“.

exclusive-lock

Wenn diese Option aktiviert ist, muss ein Client eine Sperre für ein Objekt erwirken, bevor ein Schreibvorgang ausgeführt werden kann. Aktivieren Sie die exklusive Sperre nur dann, wenn nur ein einzelner Client auf ein bestimmtes Image zugreift, nicht mehrere Clients gleichzeitig. Der interne Wert ist gleich 4. Die Standardeinstellung lautet „yes“.

object-map

Die Objektzuordnungsunterstützung ist abhängig von der Unterstützung der exklusiven Sperre. Blockgeräte werden per Thin Provisioning bereitgestellt; dies bedeutet, dass lediglich Daten auf diesen Geräten gespeichert werden, die tatsächlich vorhanden sind. Die Objektzuordnungsunterstützung hilft bei der Ermittlung, welche Objekte tatsächlich vorhanden sind (für welche Objekte also Daten auf einem Server gespeichert sind). Wird die Objektzuordnungsunterstützung aktiviert, beschleunigt dies die E/A-Operationen beim Klonen, Importieren und Exportieren eines kaum gefüllten Images sowie den Löschvorgang.

Der interne Wert ist gleich 8, die Standardeinstellung lautet „yes“.

fast-diff

Die Fast-diff-Unterstützung ist abhängig von der Objektzuordnungsunterstützung und der Unterstützung der exklusiven Sperre. Hiermit wird eine zusätzliche Eigenschaft in die Objektzuordnung aufgenommen, die die Erzeugung von Vergleichen zwischen Snapshots eines Images und der tatsächlichen Datennutzung eines Snapshots erheblich beschleunigt.

Der interne Wert ist gleich 16, die Standardeinstellung lautet „yes“.

deep-flatten

„deep-flatten“ sorgt dafür, dass rbd flatten (siehe Abschnitt 20.3.3.6, „Vereinfachen eines geklonten Images“) für alle Snapshots eines Images und zusätzlich für das Image selbst ausgeführt werden kann. Ohne diese Option beruhen Snapshots eines Images weiterhin auf dem übergeordneten Image, sodass Sie das übergeordnete Image erst dann löschen können, wenn die Snapshots gelöscht wurden. Mit „deep-flatten“ wird die Abhängigkeit eines übergeordneten Elements von seinen Klonen aufgehoben, selbst wenn sie Snapshots umfassen.

Der interne Wert ist gleich 32, die Standardeinstellung lautet „yes“.

Journal

Die Journaling-Unterstützung ist abhängig von der Unterstützung der exklusiven Sperre. Mit dem Journaling werden alle Änderungen an einem Image in der Reihenfolge festgehalten, in der sie vorgenommen wurden. Die RBD-Spiegelung (siehe Abschnitt 20.4, „RBD-Image-Spiegel“) reproduziert anhand des Journals ein absturzkonsistentes Image auf einem Remote-Cluster.

Der interne Wert ist gleich 64, die Standardeinstellung lautet „yes“.

20.9 RBD-Zuordnung mit älteren Kernel-Clients #

Ältere Clients (z. B. SLE11 SP4) können RBD-Images unter Umständen nicht zuordnen, da ein mit SUSE Enterprise Storage 7.1 bereitgestellter Cluster bestimmte Funktionen erzwingt (sowohl auf Ebene der RBD-Images als auch auf RADOS-Ebene), die diese älteren Clients nicht unterstützen. In diesem Fall enthalten die OSD-Protokolle die folgenden oder ähnliche Meldungen:

2019-05-17 16:11:33.739133 7fcb83a2e700  0 -- 192.168.122.221:0/1006830 >> \
192.168.122.152:6789/0 pipe(0x65d4e0 sd=3 :57323 s=1 pgs=0 cs=0 l=1 c=0x65d770).connect \
protocol feature mismatch, my 2fffffffffff < peer 4010ff8ffacffff missing 401000000000000

Warnung: Eine Änderung der Bucket-Typen für die CRUSH-Zuordnung löst einen massiven Ausgleich aus

Sollen die CRUSH-Zuordnung-Bucket-Typen zwischen „straw“ und „straw2“ gewechselt werden, gehen Sie dabei wohlgeplant vor. Erwarten Sie erhebliche Auswirkungen auf die Cluster-Last, da eine Änderung des Bucket-Typs einen massiven Cluster-Ausgleich auslöst.

Deaktivieren Sie alle nicht unterstützten RBD-Image-Funktionen. Beispiel:

cephuser@adm > rbd feature disable pool1/image1 object-map
cephuser@adm > rbd feature disable pool1/image1 exclusive-lock

Stellen Sie die CRUSH-Zuordnung-Bucket-Typen von „straw2“ auf „straw“ um:
1. Speichern Sie die CRUSH-Zuordnung:
```
cephuser@adm > ceph osd getcrushmap -o crushmap.original
```
2. Dekompilieren Sie die CRUSH-Zuordnung:
```
cephuser@adm > crushtool -d crushmap.original -o crushmap.txt
```
3. Bearbeiten Sie die CRUSH-Zuordnung und ersetzen Sie „straw2“ durch „straw“.
4. Kompilieren Sie die CRUSH-Zuordnung neu:
```
cephuser@adm > crushtool -c crushmap.txt -o crushmap.new
```
5. Legen Sie die neue CRUSH-Zuordnung fest:
```
cephuser@adm > ceph osd setcrushmap -i crushmap.new
```

20.10 Aktiveren von Blockgeräten und Kubernetes #

Sie können Ceph RBD mit Kubernetes v1.13 und höher über den ceph-csi-Treiber verwenden. Dieser Treiber stellt RBD-Images dynamisch für Kubernetes-Volumes bereit und ordnet diese RBD-Images als Blockgeräte (und optionales Einhängen eines im Image enthaltenen Dateisystems) zu Arbeitsknoten zu, auf denen Pods ausgeführt werden, die auf ein RBD-gestütztes Volume verweisen.

Um Ceph-Blockgeräte mit Kubernetes zu verwenden, müssen Sie ceph-csi in Ihrer Kubernetes-Umgebung installieren und konfigurieren.

Wichtig

ceph-csi verwendet standardmäßig die RBD-Kernelmodule, die möglicherweise nicht alle Ceph CRUSH-Tunables oder RBD-Image-Funktionen unterstützen.

Ceph-Blockgeräte verwenden standardmäßig den RBD-Pool. Erstellen Sie einen Pool für Kubernetes-Volume-Speicher. Stellen Sie sicher, dass Ihr Ceph-Cluster ausgeführt wird, und erstellen Sie dann den Pool:
```
cephuser@adm > ceph osd pool create kubernetes
```
Initialisieren Sie den Pool mit dem RBD-Werkzeug:
```
cephuser@adm > rbd pool init kubernetes
```

Erstellen Sie einen neuen Benutzer für Kubernetes und ceph-csi. Führen Sie folgendes Kommando aus und zeichnen Sie den generierten Schlüssel auf:

cephuser@adm > ceph auth get-or-create client.kubernetes mon 'profile rbd' osd 'profile rbd pool=kubernetes' mgr 'profile rbd pool=kubernetes'
[client.kubernetes]
    key = AQD9o0Fd6hQRChAAt7fMaSZXduT3NWEqylNpmg==

Für ceph-csi ist ein in Kubernetes gespeichertes ConfigMap-Objekt erforderlich, um die Ceph-Monitoradressen für den Ceph-Cluster zu definieren. Erfassen Sie sowohl die eindeutige FSID des Ceph-Clusters als auch die Monitoradressen:

cephuser@adm > ceph mon dump
<...>
fsid b9127830-b0cc-4e34-aa47-9d1a2e9949a8
<...>
0: [v2:192.168.1.1:3300/0,v1:192.168.1.1:6789/0] mon.a
1: [v2:192.168.1.2:3300/0,v1:192.168.1.2:6789/0] mon.b
2: [v2:192.168.1.3:3300/0,v1:192.168.1.3:6789/0] mon.c

Generieren Sie eine csi-config-map.yaml-Datei ähnlich dem folgenden Beispiel und ersetzen Sie die FSID durch clusterID und die Monitoradressen durch monitors:

kubectl@adm > cat <<EOF > csi-config-map.yaml
---
apiVersion: v1
kind: ConfigMap
data:
  config.json: |-
    [
      {
        "clusterID": "b9127830-b0cc-4e34-aa47-9d1a2e9949a8",
        "monitors": [
          "192.168.1.1:6789",
          "192.168.1.2:6789",
          "192.168.1.3:6789"
        ]
      }
    ]
metadata:
  name: ceph-csi-config
EOF

Speichern Sie nach der Generierung das neue ConfigMap-Objekt in Kubernetes:
```
kubectl@adm > kubectl apply -f csi-config-map.yaml
```
Für ceph-csi ist der cephx-Berechtigungsnachweis für die Kommunikation mit dem Ceph-Cluster erforderlich. Generieren Sie eine csi-rbd-secret.yaml-Datei ähnlich dem folgenden Beispiel mit der neu erstellten Kubernetes-Benutzer-ID und dem cephx-Schlüssel:
```
kubectl@adm > cat <<EOF > csi-rbd-secret.yaml
---
apiVersion: v1
kind: Secret
metadata:
  name: csi-rbd-secret
  namespace: default
stringData:
  userID: kubernetes
  userKey: AQD9o0Fd6hQRChAAt7fMaSZXduT3NWEqylNpmg==
EOF
```
Speichern Sie das generierte neue geheime Objekt in Kubernetes:
```
kubectl@adm > kubectl apply -f csi-rbd-secret.yaml
```
Erstellen Sie die erforderlichen Kubernetes-Objekte ServiceAccount und RBAC ClusterRole/ClusterRoleBinding. Diese Objekte müssen nicht unbedingt für Ihre Kubernetes-Umgebung angepasst werden und können daher direkt aus den ceph-csi-YAML-Bereitstellungsdateien verwendet werden:
```
kubectl@adm > kubectl apply -f https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-provisioner-rbac.yaml
kubectl@adm > kubectl apply -f https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-nodeplugin-rbac.yaml
```

Erstellen Sie das ceph-csi-Bereitstellungsprogramm und die Knoten-Plugins:

kubectl@adm > wget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin-provisioner.yaml
kubectl@adm > kubectl apply -f csi-rbdplugin-provisioner.yaml
kubectl@adm > wget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin.yaml
kubectl@adm > kubectl apply -f csi-rbdplugin.yaml

Wichtig

Standardmäßig wird mit den YAML-Dateien des Bereitstellungsprogramms und des Knoten-Plugins die Entwicklungsversion des ceph-csi-Containers abgerufen. Die YAML-Dateien sollten zur Verwendung einer Freigabeversion aktualisiert werden.

20.10.1 Verwenden von Ceph-Blockgeräten in Kubernetes #

Die Kubernetes StorageClass definiert eine Speicherklasse. Es können mehrere StorageClass-Objekte erstellt werden, um verschiedene Quality-of-Service-Stufen und Funktionen zuzuordnen. Zum Beispiel NVMe- versus HDD-basierte Pools.

Um eine ceph-csi-StorageClass zu erstellen, die auf den oben erstellten Kubernetes-Pool zugeordnet wird, kann die folgende YAML-Datei verwendet werden, nachdem sichergestellt wurde, dass die Eigenschaft clusterID mit der FSID Ihres Ceph-Clusters übereinstimmt:

kubectl@adm > cat <<EOF > csi-rbd-sc.yaml
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: csi-rbd-sc
provisioner: rbd.csi.ceph.com
parameters:
   clusterID: b9127830-b0cc-4e34-aa47-9d1a2e9949a8
   pool: kubernetes
   csi.storage.k8s.io/provisioner-secret-name: csi-rbd-secret
   csi.storage.k8s.io/provisioner-secret-namespace: default
   csi.storage.k8s.io/node-stage-secret-name: csi-rbd-secret
   csi.storage.k8s.io/node-stage-secret-namespace: default
reclaimPolicy: Delete
mountOptions:
   - discard
EOF
kubectl@adm > kubectl apply -f csi-rbd-sc.yaml

Ein PersistentVolumeClaim ist eine Anforderung von abstrakten Speicherressourcen durch einen Benutzer. Der PersistentVolumeClaim würde dann einer Pod-Ressource zugeordnet werden, um ein PersistentVolume bereitzustellen, das durch ein Ceph-Block-Image gesichert wird. Ein optionaler volumeMode kann eingeschlossen werden, um zwischen einem eingehängten Dateisystem (Standard) oder einem Volume auf Basis eines Basisblockgeräts zu wählen.

Bei ceph-csi kann die Angabe von Filesystem für volumeMode die Forderungen ReadWriteOnce und ReadOnlyMany accessMode unterstützen. Die Angabe von Block für volumeMode kann die Forderungen ReadWriteOnce, ReadWriteMany und ReadOnlyMany accessMode unterstützen.

Um beispielsweise einen blockbasierten PersistentVolumeClaim zu erstellen, der die oben erstellte ceph-csi-basierte StorageClass verwendet, kann die folgende YAML-Datei verwendet werden, um Basisblockspeicher von der csi-rbd-sc StorageClass anzufordern:

kubectl@adm > cat <<EOF > raw-block-pvc.yaml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: raw-block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Block
  resources:
    requests:
      storage: 1Gi
  storageClassName: csi-rbd-sc
EOF
kubectl@adm > kubectl apply -f raw-block-pvc.yaml

Im Folgenden wird ein Beispiel für die Bindung des obigen PersistentVolumeClaim an eine Pod-Ressource als Basisblockgerät gezeigt:

kubectl@adm > cat <<EOF > raw-block-pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-with-raw-block-volume
spec:
  containers:
    - name: fc-container
      image: fedora:26
      command: ["/bin/sh", "-c"]
      args: ["tail -f /dev/null"]
      volumeDevices:
        - name: data
          devicePath: /dev/xvda
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: raw-block-pvc
EOF
kubectl@adm > kubectl apply -f raw-block-pod.yaml

Um einen dateisystembasierten PersistentVolumeClaim zu erstellen, der die oben erstellte ceph-csi-basierte StorageClass verwendet, kann die folgende YAML-Datei verwendet werden, um ein eingehängtes (von einem RBD-Image gesichertes) Dateisystem von der csi-rbd-sc StorageClass anzufordern:

kubectl@adm > cat <<EOF > pvc.yaml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rbd-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi
  storageClassName: csi-rbd-sc
EOF
kubectl@adm > kubectl apply -f pvc.yaml

Im Folgenden wird ein Beispiel für die Bindung des obigen PersistentVolumeClaim an eine Pod-Ressource als eingehängtes Dateisystem gezeigt:

kubectl@adm > cat <<EOF > pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: csi-rbd-demo-pod
spec:
  containers:
    - name: web-server
      image: nginx
      volumeMounts:
        - name: mypvc
          mountPath: /var/lib/www/html
  volumes:
    - name: mypvc
      persistentVolumeClaim:
        claimName: rbd-pvc
        readOnly: false
EOF
kubectl@adm > kubectl apply -f pod.yaml

20 RADOS-Blockgerät #

20.1 Kommandos für Blockgeräte #

20.1.1 Erstellen eines Blockgeräte-Image in einem reproduzierten Pool #

20.1.2 Erstellen eines Blockgeräte-Image in einem Pool mit Löschcodierung #

20.1.3 Auflisten von Blockgeräte-Images #

20.1.4 Abrufen von Image-Informationen #

20.1.5 Ändern der Größe eines Blockgeräte-Image #

20.1.6 Entfernen eines Blockgeräte-Image #

20.2 Ein- und Aushängen #

20.2.1 Erstellen eines Ceph-Benutzerkontos #

20.2.2 Benutzerauthentifizierung #

20.2.3 Vorbereiten eines RADOS-Blockgeräts für den Einsatz #

20.2.4 Rbdmap – Zuordnen von RBD-Geräten beim Booten #

20.2.5 Vergrößern von RBD-Geräten #

20.3 Aufnahmen #

20.3.1 Aktivieren und Konfigurieren von cephx #

20.3.2 Allgemeine Informationen zu Snapshots #

20.3.2.1 Erstellen von Snapshots #

20.3.2.2 Auflisten von Snapshots #

20.3.2.3 Rollback von Snapshots #

20.3.2.4 Löschen eines Snapshots #

20.3.2.5 Bereinigen von Snapshots #

20.3.3 Snapshot-Layering #

20.3.3.1 Erste Schritte mit Layering #

20.3.3.2 Schützen eines Snapshots #

20.3.3.3 Klonen eines Snapshots #

20.3.3.4 Aufheben des Schutzes eines Snapshots #

20.3.3.5 Auflisten der untergeordneten Klone eines Snapshots #

20.3.3.6 Vereinfachen eines geklonten Images #

20.4 RBD-Image-Spiegel #

20.4.1 Pool-Konfiguration #

20.4.1.1 Aktivieren der Spiegelung für einen Pool #

20.4.1.2 Deaktivieren der Spiegelung #

20.4.1.3 Bootstrapping von Peers #

20.4.1.4 Manuelles Hinzufügen eines Cluster-Peers #

20.4.1.5 Entfernen des Cluster-Peers #

20.4.1.6 Datenpools #

20.4.2 RBD-Image-Konfiguration #

20.4.2.1 Aktivieren der Image-Spiegelung #

20.4.2.2 Aktivieren der Image-Journaling-Funktion #

20.4.2.3 Erstellen von Image-Spiegel-Snapshots #

20.4.2.4 Aktivieren der Image-Spiegelung #

20.4.2.5 Hoch- und Herabstufen von Images #

20.4.2.6 Erzwingen der erneuten Image-Synchronisierung #

20.4.3 Prüfen des Spiegelungsstatus #

20.5 Cache-Einstellungen #

20.6 QoS-Einstellungen #

20.7 Read-Ahead-Einstellungen #

20.8 Erweiterte Funktionen #

20.9 RBD-Zuordnung mit älteren Kernel-Clients #

20.10 Aktiveren von Blockgeräten und Kubernetes #

20.10.1 Verwenden von Ceph-Blockgeräten in Kubernetes #

20.2.4 `Rbdmap` – Zuordnen von RBD-Geräten beim Booten #

20.3.1 Aktivieren und Konfigurieren von `cephx` #