Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
Bezieht sich auf SUSE Enterprise Storage 6

12 RADOS-Blockgerät Edit source

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. Ceph's RADOS Block Devices (RBD) interagieren mit OSDs über Kernel-Module oder die librbd-Bibliothek.

RADOS-Protokoll
Abbildung 12.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.

12.1 Kommandos für Blockgeräte Edit source

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.

12.1.1 Erstellen eines Blockgeräte-Images in einem reproduzierten Pool Edit source

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 11, Verwalten von Speicher-Pools):

cephadm@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:

cephadm@adm > rbd create --size 1024 mypool/myimage
Tipp
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.

12.1.2 Erstellen eines Blockgeräte-Images in einem Erasure Coded Pool Edit source

Ab SUSE Enterprise Storage 5 ist es möglich, Daten eines Blockgeräte-Images direkt in Pools mit Löschcodierung (EC-Pools) zu speichern. Ein RADOS Block Device-Image besteht aus einem Data- und einem metadata-Teil. Sie können lediglich den „data“-Teil eines RADOS Block Device-Images in einem EC-Pool speichern. Die Flagge „overwrite“ des Pools muss auf true eingestellt sein, und dies ist nur möglich, wenn alle OSDs, auf denen der Pool gespeichert ist, mit BlueStore arbeiten.

Es ist nicht möglich, den „metadata“-Teil des Images in einem EC-Pool zu speichern. Zum Speichern der Metadaten des Images müssen Sie den reproduzierten Pool mit der Option --pool= des Kommandos rbd create angeben.

So erstellen Sie ein RBD-Image in einem soeben erstellten EC-Pool:

cephadm@adm > ceph osd pool create POOL_NAME 12 12 erasure
cephadm@adm > ceph osd pool set POOL_NAME allow_ec_overwrites true

#Metadata will reside in pool "OTHER_POOL", and data in pool "POOL_NAME"
cephadm@adm > rbd create IMAGE_NAME --size=1G --data-pool POOL_NAME --pool=OTHER_POOL

12.1.3 Auflisten von Blockgeräte-Images Edit source

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

cephadm@adm > rbd ls mypool

12.1.4 Abrufen von Image-Informationen Edit source

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

cephadm@adm > rbd info mypool/myimage

12.1.5 Ändern der Größe eines Blockgeräte-Image Edit source

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:

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

12.1.6 Entfernen eines Blockgeräte-Image Edit source

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

cephadm@adm > rbd rm mypool/myimage

12.2 Ein- und Aushängen Edit source

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.

  1. 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.

    cephadm@adm > rbd list mypool
  2. Ordnen Sie das Image einem neuen Blockgerät zu.

    cephadm@adm > rbd map --pool mypool myimage
    Tipp
    Tipp: Benutzername und -authentifizierung

    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:

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

    oder

    cephadm@adm > rbd map --pool rbd myimage --id admin --keyfile /path/to/file
  3. Listen Sie alle zugeordneten Geräte auf:

    cephadm@adm > rbd showmapped
     id pool   image   snap device
     0  mypool myimage -    /dev/rbd0

    Das Gerät, mit dem wir arbeiten möchten, heißt /dev/rbd0.

    Tipp
    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
  4. Erstellen Sie am Gerät namens /dev/rbd0 ein XFS-Dateisystem.

    root # 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
  5. Hängen Sie das Gerät ein und prüfen Sie, ob es korrekt eingehängt wurde. Ersetzen Sie /mnt durch Ihren Einhängepunkt.

    root # mount /dev/rbd0 /mnt
    root # 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
    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

      cephadm@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.

      root # xfs_growfs /mnt
       [...]
       data blocks changed from 2097152 to 2560000
  6. Wenn Sie Ihre Arbeit an dem Gerät beenden, können Sie dessen Zuordnung aufheben und das Gerät aushängen.

    cephadm@adm > rbd unmap /dev/rbd0
    root # unmount /mnt
Tipp
Tipp: Manuelles Einhängen und Aushängen

Da die manuelle Zuordnung und das Einhängen von RBD-Images nach dem Start sowie das Aushängen und Aufheben der Zuordnung vor dem Herunterfahren sehr mühsam sein kann, wird ein Skript rbdmap und eine systemd-Einheit zur Verfügung gestellt. Weitere Informationen finden Sie in Abschnitt 12.2.1, „rbdmap: Zuordnen von RBD-Geräten beim Booten“.

12.2.1 rbdmap: Zuordnen von RBD-Geräten beim Booten Edit source

Das Shell-Skript rbdmap automatisiert die Operationen rbd map und rbd 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 Umgebungsvariable 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 zugrundeliegende Kommando rbd 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:

cephadm@adm > rbd 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:

cephadm@adm > rbdmap 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 angegebenen RBD-Image zunächst das Image zuzuordnen (mit dem Kommando the rbd 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 ordnet der Vorgang „rbd map“ das Image einem /dev/rbdX-Gerät zu. 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).

12.2.2 Vergrößern des RBD-Geräts Edit source

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

    cephadm@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.

    root # xfs_growfs /mnt
     [...]
     data blocks changed from 2097152 to 2560000

12.3 Aufnahmen Edit source

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
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.

12.3.1 Hinweise zu Cephx Edit source

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 unter Kapitel 8, Authentifizierung mit cephx. Es ist auch möglich, die Umgebungsvariable CEPH_ARGS hinzuzufügen, um die erneute Eingabe der folgenden Parameter zu verhindern.

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

Beispiel:

cephadm@adm > rbd --id admin --keyring=/etc/ceph/ceph.keyring commands
cephadm@adm > rbd --name client.admin --keyring=/etc/ceph/ceph.keyring commands
Tipp
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.

12.3.2 Allgemeine Informationen zu Snapshots Edit source

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

12.3.2.1 Erstellen von Snapshots Edit source

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

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

Beispiel:

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

12.3.2.2 Auflisten von Snapshots Edit source

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

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

Beispiel:

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

12.3.2.3 Snapshot Rollbacks Edit source

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.

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

Beispiel:

cephadm@adm > rbd --pool pool1 snap rollback --snap snapshot1 image1
cephadm@adm > rbd snap rollback pool1/image1@snapshot1
Anmerkung
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.

12.3.2.4 Löschen eines Snapshots Edit source

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

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

Beispiel:

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

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

12.3.2.5 Entfernen aller Snapshots Edit source

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

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

Beispiel:

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

12.3.3 Layering Edit source

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
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
Anmerkung: Keine Unterstützung für --image-format 1

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.

12.3.3.1 Erste Schritte mit Layering Edit source

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.

12.3.3.2 Schützen von Snapshots Edit source

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.

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

Beispiel:

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

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

12.3.3.3 Klonen von Snapshots Edit source

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.

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

Beispiel:

cephadm@adm > rbd clone pool1/image1@snapshot1 pool1/image2
Anmerkung
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.

12.3.3.4 Aufheben des Schutzes von Snapshots Edit source

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.

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

Beispiel:

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

12.3.3.5 Auflisten der untergeordneten Klone von Snapshots Edit source

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

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

Beispiel:

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

12.3.3.6 Vereinfachen eines geklonten Image Edit source

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.

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

Beispiel:

cephadm@adm > rbd --pool pool1 flatten --image image1
cephadm@adm > rbd flatten pool1/image1
Anmerkung
Anmerkung

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

12.4 Spiegelung Edit source

RBD-Images können asynchron zwischen zwei Ceph Clustern gespiegelt werden. Dazu wird die Funktion des RBD-Journaling-Image verwendet, um die absturzkonsistente Reproduktion zwischen Clustern sicherzustellen. Die Spiegelung wird pro Pool in Peer-Clustern konfiguriert. Sie kann so konfiguriert werden, dass alle Images in einem Pool oder nur eine bestimmte Teilmenge der Images automatisch gespiegelt werden. Die Spiegelung wird mit dem rbd-Kommando ausgeführt. Der rbd-mirror Daemon ist dafür zuständig, Image-Updates aus dem Remote-Peer-Cluster zu entnehmen und diese auf das Image im lokalen Cluster anzuwenden.

Anmerkung
Anmerkung: rbd-mirror Daemon

Für die RBD-Spiegelung benötigen Sie zwei Ceph Cluster. Auf jedem von beiden muss der rbd-mirror Daemon ausgeführt werden.

Wichtig
Wichtig: Export von RADOS Block Devices über iSCSI

Sie können keine RBD-Geräte spiegeln, die über iSCSI mit einem kernelbasierten iSCSI-Gateway exportiert wurden.

Weitere Informationen zu iSCSI finden Sie in Kapitel 18, Ceph iSCSI Gateway.

12.4.1 rbd-mirror Daemon Edit source

Die beiden rbd-mirror Daemons sind dafür zuständig, Image-Protokolle am Remote-Peer-Cluster zu beobachten und die Protokollereignisse im Vergleich zum lokalen Cluster wiederzugeben. Die Journaling-Funktion für RBD-Images zeichnet alle Änderungen am Image in der Reihenfolge auf wie sie vorgenommen werden. Dadurch wird sichergestellt, dass ein absturzkonsistenter Spiegel des Remote-Image lokal verfügbar ist.

Der rbd-mirror-Daemon ist im Paket rbd-mirror enthalten. Sie können das Paket auf OSD Nodes, Gateway Nodes und sogar auf dedizierten Nodes installieren. Die Installation des Pakets rbd-mirror auf dem Admin Node wird nicht empfohlen. Installieren, aktivieren und starten Sie rbd-mirror:

root@minion > zypper install rbd-mirror
root@minion > systemctl enable ceph-rbd-mirror@server_name.service
root@minion > systemctl start ceph-rbd-mirror@server_name.service
Wichtig
Wichtig

Jeder rbd-mirror Daemon muss gleichzeitig eine Verbindung zu beiden Clustern herstellen können.

12.4.2 Pool-Konfiguration Edit source

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 („local“ 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
Tipp: Mehrere Cluster

Der Cluster-Name in den folgenden Beispielen entspricht einer Ceph-Konfigurationsdatei des selben Namens /etc/ceph/remote.conf.

12.4.2.1 Aktivieren der Spiegelung für einen Pool Edit source

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:

pool

Alle Images im Pool mit aktivierter Journaling-Funktion werden gespiegelt.

image

Die Spiegelung muss auf jedem Image explizit aktiviert werden. Weitere Informationen finden Sie in Abschnitt 12.4.3.2, „Aktivieren der Image-Spiegelung“.

Beispiel:

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

12.4.2.2 Deaktivieren der Spiegelung Edit source

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.

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

12.4.2.3 Hinzufügen des Cluster Peers Edit source

Damit der rbd-mirror Daemon seinen Peer Cluster ermitteln kann, muss der Peer im Pool registriert sein. Geben Sie zum Hinzufügen des Peer Clusters für die Spiegelung das Unterkommando mirror pool peer add, den Pool-Namen und eine Cluster-Spezifikation an:

cephadm@adm > rbd --cluster local mirror pool peer add POOL_NAME client.remote@remote
cephadm@adm > rbd --cluster remote mirror pool peer add POOL_NAME client.local@local

12.4.2.4 Entfernen des Cluster Peers Edit source

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:

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

12.4.3 Image-Konfiguration Edit source

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 12.4.3.2, „Aktivieren der Image-Spiegelung“) mit dem rbd-Kommando).

12.4.3.1 Unterstützung für Image Journaling Edit source

Bei der RBD-Spiegelung wird immer die RBD Journaling-Funktion verwendet, um sicherzustellen, dass das reproduzierte Image immer absturzkonsistent bleibt. Die Journaling-Funktion muss aktiviert werden, bevor ein Image zu einem Peer Cluster gespiegelt werden kann. Die Funktion kann bei der Image-Erstellung aktiviert werden, indem die Option --image-feature exclusive-lock,journaling für das rbd-Kommando angegeben wird.

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:

cephadm@adm > rbd --cluster local feature enable POOL_NAME/IMAGE_NAME journaling
Anmerkung
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.

Warnung
Warnung: Journaling an allen neuen Images

Sie können das Journaling für alle neuen Images standardmäßig aktivieren. Ergänzen Sie hierzu die Option rbd default features in der Ceph-Konfigurationsdatei mit dem Wert journaling. Beispiel:

rbd default features = layering,exclusive-lock,object-map,deep-flatten,journaling

Bevor Sie eine solche Änderung vornehmen, prüfen Sie sorgfältig, ob sich die Aktivierung des Journalings für alle neuen Images positiv auf die Implementierung auswirkt, da sie unter Umständen die Leistung beeinträchtigen kann.

12.4.3.2 Aktivieren der Image-Spiegelung Edit source

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 das Unterkommando mirror image enable zusammen mit dem Pool- und Image-Namen an:

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

12.4.3.3 Deaktivieren der Image-Spiegelung Edit source

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

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

12.4.3.4 Hochstufen und Herabstufen eines Image Edit source

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
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:

cephadm@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:

cephadm@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:

cephadm@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:

cephadm@adm > rbd --cluster local mirror pool promote POOL_NAME
Tipp
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.

12.4.3.5 Erzwingen der erneuten Synchronisierung eines Image Edit source

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:

cephadm@adm > rbd mirror image resync POOL_NAME/IMAGE_NAME

12.4.4 Spiegelstatus Edit source

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:

cephadm@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:

cephadm@adm > rbd mirror pool status POOL_NAME
Tipp
Tipp:

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

12.5 Cache-Einstellungen Edit source

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. Zum Aktivieren fügen Sie

[client]
...
rbd cache = true

in den Abschnitt [client] der Datei ceph.conf ein. 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. Zum Festlegen des Durchschreiben-Modus geben Sie Folgendes an:

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 ceph.conf-Dateieinstellungen für RBD müssen im Abschnitt [client] in der Konfigurationsdatei festgelegt werden. Einstellungen:

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“.

12.6 QoS-Einstellungen Edit source

„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
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.

12.7 Read-Ahead-Einstellungen Edit source

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.

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.

12.8 Erweiterte Funktionen Edit source

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
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 12.3.3.6, „Vereinfachen eines geklonten Image“) 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 12.4, „Spiegelung“) reproduziert anhand des Journals ein absturzkonsistentes Image auf einem Remote-Cluster.

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

12.9 RBD-Zuordnung mit älteren Kernel-Clients Edit source

Ältere Clients (z. B. SLE11 SP4) können RBD-Images unter Umständen nicht zuordnen, da ein mit SUSE Enterprise Storage 6 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
Warnung: Änderung der CRUSH-Zuordnung-Bucket-Typen 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.

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

    cephadm@adm > rbd feature disable pool1/image1 object-map
    cephadm@adm > rbd feature disable pool1/image1 exclusive-lock
  2. Stellen Sie die CRUSH-Zuordnung-Bucket-Typen von „straw2“ auf „straw“ um:

    1. Speichern Sie die CRUSH-Zuordnung:

      cephadm@adm > ceph osd getcrushmap -o crushmap.original
    2. Dekompilieren Sie die CRUSH-Zuordnung:

      cephadm@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:

      cephadm@adm > crushtool -c crushmap.txt -o crushmap.new
    5. Legen Sie die neue CRUSH-Zuordnung fest:

      cephadm@adm > ceph osd setcrushmap -i crushmap.new
Diese Seite drucken