Gilt für SUSE Enterprise Storage 7.1

18 Verwalten von Speicher-Pools #

Ceph speichert Daten in Pools. Pools sind logische Gruppen für Speicherobjekte. Wenn Sie zunächst einen Cluster bereitstellen, ohne einen Pool zu erstellen, verwendet Ceph die Standard-Pools zum Speichern von Daten. Für Ceph-Pools gelten die folgenden wichtigen Punkte:

Stabilität: Mit Ceph-Pools wird Stabilität erreicht, da die darin enthaltenen Daten reproduziert oder verschlüsselt werden. Jeder Pool kann auf reproduziert oder mit Löschcodierung festgelegt werden. Bei reproduzierten Pools legen Sie außerdem die Anzahl der Reproduktionen oder Kopien für jedes Datenobjekt innerhalb des Pools fest. Die Anzahl der Kopien (OSDs, CRUSH-Buckets/Blätter), die verloren gehen können, ist eins weniger als die Anzahl der Reproduktionen. Bei der Löschcodierung legen Sie die Werte von k und m fest, wobei k die Anzahl der Datenblöcke und m die Anzahl der Datenblöcke für die Codierung darstellt. Bei Pools mit Löschcodierung bestimmt die Anzahl der Datenblöcke für die Codierung, wie viele OSDs (CRUSH-Buckets/Blätter) ohne Datenverlust verloren gehen können.
Platzierungsgruppen: Sie können die Anzahl der Platzierungsgruppen für den Pool festlegen. Bei einer normalen Konfiguration sind etwa 100 Placement Groups pro OSD vorhanden. Dadurch wird ein optimaler Ausgleich ermöglicht, ohne zu viel Rechnerressourcen zu verbrauchen. Achten Sie bei der Einrichtung von mehreren Pools sorgfältig darauf, dass Sie eine vernünftige Anzahl von Placement Groups sowohl für den Pool als auch den Cluster insgesamt festlegen.
CRUSH-Regeln: Wenn Sie Daten in einem Pool speichern, werden die Objekte und deren Reproduktionen (bzw. Blöcke bei Pools mit Löschcodierung) gemäß dem CRUSH-Regelsatz platziert, der dem Pool zugeordnet ist. Es ist auch möglich, eine benutzerdefinierte CRUSH-Regel für Ihren Pool zu erstellen.
Snapshots: Wenn Sie einen Snapshot mit ceph osd pool mksnap erstellen, machen Sie im Grunde einen Snapshot von einem bestimmten Pool.

Zum Strukturieren der Daten in Pools können Sie Pools auflisten, erstellen und entfernen. Es ist auch möglich, die Auslastungsstatistik für jeden Pool anzuzeigen.

18.1 Erstellen eines Pools #

Ein Pool kann entweder als reproduziert erstellt werden, um eine Wiederherstellung verlorener OSDs durch Beibehaltung mehrerer Kopien von Objekten zu ermöglichen, oder als Löschcodierung, um eine Art von genereller RAID5/6-Funktion zu erhalten. Reproduzierte Pools belegen mehr Rohspeicher, Pools mit Löschcodierung dagegen weniger Rohspeicher. Die Standardeinstellung lautet reproduziert. Weitere Informationen zu Pools mit Löschcodierung finden Sie in Kapitel 19, Erasure Coded Pools.

Führen Sie zum Erstellen eines reproduzierten Pools Folgendes aus:

cephuser@adm > ceph osd pool create POOL_NAME

Anmerkung

Die Autoskalierung verarbeitet die restlichen optionalen Argumente. Weitere Informationen finden Sie Abschnitt 17.4.12, „Aktivieren der PG-Autoskalierung“.

Führen Sie zum Erstellen eines Erasure Coded Pools Folgendes aus:

cephuser@adm > ceph osd pool create POOL_NAME erasure CRUSH_RULESET_NAME \
EXPECTED_NUM_OBJECTS

Das Kommando ceph osd pool create wird möglicherweise nicht ausgeführt, wenn Sie die zulässige Anzahl der Platzierungsgruppen pro OSD überschreiten. Der Grenzwert wird mit der Option mon_max_pg_per_osd festgelegt.

POOL_NAME: Der Name des Pools. Er muss eindeutig sein. Diese Option muss aktiviert sein.
POOL_TYPE: Der Pool-Typ, entweder replicated (reproduziert), um eine Wiederherstellung verlorener OSDs durch Beibehaltung mehrerer Kopien von Objekten zu ermöglich, oder erasure, um eine Art von genereller RAID5-Funktion zu erhalten. Reproduzierte Pools benötigen zwar mehr Basisspeicher, implementieren jedoch alle Ceph-Operationen. Erasure Pools benötigen weniger Basisspeicher, implementieren jedoch nur eine Teilmenge der verfügbaren Operationen. Die Standardeinstellung für POOL_TYPE lautet reproduziert.
CRUSH_RULESET_NAME: Der Name des CRUSH-Regelsatzes für diesen Pool. Wenn der angegebene Regelsatz nicht vorhanden ist, werden die reproduzierten Pools nicht erstellt und -ENOENT wird ausgegeben. Bei reproduzierten Pools ist es der Regelsatz, der in der Konfigurationsvariablen osd pool default CRUSH replicated ruleset angegeben ist. Dieser Regelsatz muss vorhanden sein. Bei Erasure Pools ist dies „erasure-code“, wenn das standardmäßige Löschcode-Profil verwendet, wird, ansonsten POOL_NAME. Falls dieser Regelsatz nicht bereits vorhanden ist, wird er implizit erstellt.
erasure_code_profile=profile: Nur für Erasure Coded Pools. Verwenden Sie das Erasure Code Profil. Es muss ein vorhandenes Profil sein, das durch osd erasure-code-profile set definiert wurde.
Anmerkung
Wenn aus irgendeinem Grund die Autoskalierung in einem Pool deaktiviert wurde (pg_autoscale_mode auf „off“ festgelegt), können Sie die PG-Nummern manuell berechnen und festlegen. Unter Abschnitt 17.4, „Platzierungsgruppen“ finden Sie detaillierte Informationen zur Berechnung einer angemessenen Anzahl von Placement Groups für Ihren Pool.
EXPECTED_NUM_OBJECTS: Die erwartete Anzahl von Objekten für diesen Pool. Wenn Sie diesen Wert festlegen (zusammen mit einem negativen Wert für filestore merge threshold), wird der PG-Ordner zum Zeitpunkt der Pool-Erstellung aufgeteilt. Dadurch werden die negativen Auswirkungen der Latenz vermieden, die bei einer Aufteilung bei Laufzeit auftritt.

18.2 Auflisten der Pools #

Führen Sie zum Auflisten der Pools Ihres Clusters Folgendes aus:

cephuser@adm > ceph osd pool ls

18.3 Umbenennen eines Pools #

Führen Sie zum Umbenennen eines Pools folgendes Kommando aus:

cephuser@adm > ceph osd pool rename CURRENT_POOL_NAME NEW_POOL_NAME

Wenn Sie einen Pool umbenennen und Capabilities pro Pool für einen authentifizierten Benutzer festgelegt haben, müssen Sie die Capabilities des Benutzer mit dem neuen Pool-Namen aktualisieren.

18.4 Löschen eines Pools #

Warnung: Die Löschung eines Pools lässt sich nicht rückgängig machen

Pools enthalten möglicherweise wichtige Daten. Durch Löschen eines Pools gehen alle Daten im Pool verloren und es gibt keine Möglichkeit, sie wiederherzustellen.

Da die unbeabsichtigte Löschung von Pools eine echte Gefahr darstellt, implementiert Ceph zwei Mechanismen, durch die eine Löschung verhindert wird. Beide Mechanismen müssen deaktiviert werden, bevor ein Pool gelöscht werden kann.

Der erste Mechanismus ist das Flag NODELETE. Diese Flagge ist bei jedem Pool gesetzt und der Standardwert ist „false“. Führen Sie folgendes Kommando aus, um den Wert dieser Flagge an einem Pool festzustellen:

cephuser@adm > ceph osd pool get pool_name nodelete

Wenn das Kommando nodelete: true ausgibt, ist es erst möglich, den Pool zu löschen, wenn Sie das Flag mit folgendem Kommando ändern:

cephuser@adm > ceph osd pool set pool_name nodelete false

Der zweite Mechanismus ist der Cluster-weite Konfigurationsparameter mon allow pool delete, der standardmäßig auf „false“ festgelegt ist. Dies bedeutet, dass es standardmäßig nicht möglich ist, einen Pool zu löschen. Die angezeigte Fehlermeldung sieht folgendermaßen aus:

Error EPERM: pool deletion is disabled; you must first set the
mon_allow_pool_delete config option to true before you can destroy a pool

Zum Löschen des Pools trotz der Sicherheitseinstellung legen Sie vorübergehend mon allow pool delete auf „true“ fest, löschen den Pool und legen den Parameter dann wieder auf „false“ fest:

cephuser@adm > ceph tell mon.* injectargs --mon-allow-pool-delete=true
cephuser@adm > ceph osd pool delete pool_name pool_name --yes-i-really-really-mean-it
cephuser@adm > ceph tell mon.* injectargs --mon-allow-pool-delete=false

Das Kommando injectargs zeigt die folgende Meldung an:

injectargs:mon_allow_pool_delete = 'true' (not observed, change may require restart)

Dadurch wird einfach nur bestätigt, dass das Kommando erfolgreich ausgeführt wurde. Dies ist kein Fehler.

Wenn Sie für einen erstellten Pool eigene Regelsätze und Regeln festgelegt haben, sollten Sie diese entfernen, wenn Sie den Pool nicht länger benötigen.

18.5 Sonstige Vorgänge #

18.5.1 Verknüpfen von Pools mit einer Anwendung #

Bevor Sie Pools verwenden, müssen Sie sie mit einer Anwendung verknüpfen. Mit dem CephFS verwendete Pools oder automatisch von Object Gateway erstellte Pools werden automatisch verknüpft.

In anderen Fällen können Sie manuell einen frei formulierten Anwendungsnamen mit einem Pool verknüpfen:

cephuser@adm > ceph osd pool application enable POOL_NAME APPLICATION_NAME

Tipp: Standardanwendungsnamen

CephFS verwendet den Anwendungsnamen cephfs, RADOS Block Device verwendet rbd und Object Gateway verwendet rgw.

Ein Pool kann mit mehreren Anwendungen verknüpft werden und jede Anwendung kann eigene Metadaten enthalten. Listen Sie die mit einem Pool verknüpften Anwendungen mit folgendem Kommando auf:

cephuser@adm > ceph osd pool application get pool_name

18.5.2 Festlegen von Pool-Kontingenten #

Pool-Kontingente können für die maximale Anzahl von Byte und/oder die maximale Anzahl von Objekten pro Pool festgelegt werden.

cephuser@adm > ceph osd pool set-quota POOL_NAME MAX_OBJECTS OBJ_COUNT MAX_BYTES BYTES

Beispiel:

cephuser@adm > ceph osd pool set-quota data max_objects 10000

Zum Entfernen eines Kontingents legen Sie den entsprechenden Wert auf 0 fest.

18.5.3 Anzeigen von Pool-Statistiken #

Führen Sie zum Anzeigen der Auslastungsstatistik eines Pools folgendes Kommando aus:

cephuser@adm > rados df
 POOL_NAME                    USED OBJECTS CLONES COPIES MISSING_ON_PRIMARY UNFOUND DEGRADED  RD_OPS      RD  WR_OPS      WR USED COMPR UNDER COMPR
 .rgw.root                 768 KiB       4      0     12                  0       0        0      44  44 KiB       4   4 KiB        0 B         0 B
 cephfs_data               960 KiB       5      0     15                  0       0        0    5502 2.1 MiB      14  11 KiB        0 B         0 B
 cephfs_metadata           1.5 MiB      22      0     66                  0       0        0      26  78 KiB     176 147 KiB        0 B         0 B
 default.rgw.buckets.index     0 B       1      0      3                  0       0        0       4   4 KiB       1     0 B        0 B         0 B
 default.rgw.control           0 B       8      0     24                  0       0        0       0     0 B       0     0 B        0 B         0 B
 default.rgw.log               0 B     207      0    621                  0       0        0 5372132 5.1 GiB 3579618     0 B        0 B         0 B
 default.rgw.meta          961 KiB       6      0     18                  0       0        0     155 140 KiB      14   7 KiB        0 B         0 B
 example_rbd_pool          2.1 MiB      18      0     54                  0       0        0 3350841 2.7 GiB     118  98 KiB        0 B         0 B
 iscsi-images              769 KiB       8      0     24                  0       0        0 1559261 1.3 GiB      61  42 KiB        0 B         0 B
 mirrored-pool             1.1 MiB      10      0     30                  0       0        0  475724 395 MiB      54  48 KiB        0 B         0 B
 pool2                         0 B       0      0      0                  0       0        0       0     0 B       0     0 B        0 B         0 B
 pool3                     333 MiB      37      0    111                  0       0        0 3169308 2.5 GiB   14847 118 MiB        0 B         0 B
 pool4                     1.1 MiB      13      0     39                  0       0        0 1379568 1.1 GiB   16840  16 MiB        0 B         0 B

Beschreibung der einzelnen Spalten:

USED: Speicherplatz (in Byte), der durch den Pool belegt wird.
OBJECTS: Anzahl der im Pool gespeicherten Objekte.
CLONES: Anzahl der im Pool gespeicherten Klone. Wenn Sie einen Snapshot erstellen und in ein Objekt schreiben, wird nicht das ursprüngliche Objekt geändert, sondern es wird ein Klon erstellt, sodass der ursprünglich im Snapshot festgehaltene Objektinhalt nicht geändert wird.
KOPIEN: Anzahl der Objektreproduktionen. Wenn beispielsweise ein reproduzierter Pool mit dem Reproduktionsfaktor 3 „x“ Objekte umfasst, enthält er in der Regel 3 * x Exemplare.
MISSING_ON_PRIMARY: Anzahl von Objekten im eingeschränkt leistungsfähigen Status (nicht alle Exemplare vorhanden), wobei das Exemplar auf dem primären OSD fehlt.
UNFOUND: Anzahl der nicht gefundenen Objekte.
DEGRADED: Anzahl der eingeschränkt leistungsfähigen Objekte.
RD_OPS: Gesamtanzahl der für diesen Pool angeforderten Leseoperationen.
RD: Datenmenge (in Byte), die aus diesem Pool ausgelesen wurde.
WR_OPS: Gesamtanzahl der für diesen Pool angeforderten Schreiboperationen.
WR: Datenmenge (in Byte), die in diesen Pool geschrieben wurde. Dieser Wert ist nicht mit der Auslastung des Pools identisch, da Sie mehrfach in ein einzelnes Objekt schreiben können. Die Pool-Auslastung bleibt dabei unverändert, die in den Pool geschriebene Datenmenge (in Byte) steigt jedoch an.
USED COMPR: Speicherplatz (in Byte), der für komprimierte Daten zugewiesen ist.
UNDER COMPR: Speicherplatz (in Byte), den die komprimierten Daten belegen, wenn sie nicht komprimiert sind.

18.5.4 Abrufen von Pool-Werten #

Rufen Sie einen Wert von einem Pool mit folgendem get-Kommando ab:

cephuser@adm > ceph osd pool get POOL_NAME KEY

Sie können die Werte für Schlüssel abrufen, die in Abschnitt 18.5.5, „Festlegen von Pool-Werten“ aufgelistet sind, und zudem folgende Schlüssel:

PG_NUM: Die Anzahl der Placement Groups für den Pool.
PGP_NUM: Die effektive Anzahl von Placement Groups zum Berechnen der Datenplatzierung. Der gültige Bereich ist gleich oder kleiner PG_NUM.

Tipp: Alle Werte eines Pools

Mit folgendem Kommando rufen Sie alle Werte für einen bestimmten Pool ab:

 cephuser@adm > ceph osd pool get POOL_NAME all

18.5.5 Festlegen von Pool-Werten #

Führen Sie zum Festlegen des Werts für einen Pool folgendes Kommando aus:

cephuser@adm > ceph osd pool set POOL_NAME KEY VALUE

Die folgende Liste zeigt die Pool-Werte sortiert nach Pool-Typ:

Allgemeine Pool-Werte #

crash_replay_interval: Der Zeitraum in Sekunden, für den Clients bestätigte, aber noch nicht zugewiesene Anforderungen erneut wiedergeben können.
pg_num: Die Anzahl der Placement Groups für den Pool. Wenn Sie neue OSDs in den Cluster aufnehmen, prüfen Sie den Wert für die Platzierungsgruppen in allen Pools, die für die neuen OSDs vorgesehen sind.
pgp_num: Die effektive Anzahl von Placement Groups zum Berechnen der Datenplatzierung.
crush_ruleset: Der zu verwendende Regelsatz für die Zuordnung der Objektplatzierung im Cluster.
hashpspool: Setzen Sie das Flag HASHPSPOOL an einem angegebenen Pool (1) oder entfernen Sie sie (0). Durch Aktivieren dieses Flags wird der Algorithmus geändert, um PGs besser auf OSDs zu verteilen. Nach Aktivierung dieses Flags für einen Pool, dessen HASHPSPOOL-Flag auf den Standardwert 0 festgelegt wurde, beginnt der Cluster einen Abgleich, um erneut eine korrekte Platzierung aller PGs zu erreichen. Dies kann zu einer erheblichen E/A-Belastung auf einem Cluster führen. Aktivieren Sie diese Flagge daher nicht in stark ausgelasteten Produktions-Clustern (Umstellung von 0 auf 1).
nodelete: Verhindert, dass der Pool entfernt wird.
nopgchange: Verhindert, dass die Werte pg_num und pgp_num des Pools geändert werden.
noscrub,nodeep-scrub: Deaktiviert (umfassendes) Scrubbing der Daten für den entsprechenden Pool, um eine vorübergehend hohe E/A-Last zu vermeiden.
write_fadvise_dontneed: Legt das Flag WRITE_FADVISE_DONTNEED bei Lese-/Schreibanforderungen eines bestimmten Pools fest oder entfernt sie, um das Ablegen von Daten in den Cache zu umgehen. Die Standardeinstellung ist false. Gilt sowohl für reproduzierte als auch für EC-Pools.
scrub_min_interval: Das Mindestintervall in Sekunden für ein Pool Scrubbing, wenn die Cluster-Last gering ist. Der Standardwert 0 bedeutet, dass der Wert osd_scrub_min_interval aus der Ceph-Konfigurationsdatei verwendet wird.
scrub_max_interval: Das maximale Intervall in Sekunden für ein Pool Scrubbing, unabhängig von der Cluster-Last. Der Standardwert 0 bedeutet, dass der Wert osd_scrub_max_interval aus der Ceph-Konfigurationsdatei verwendet wird.
deep_scrub_interval: Das Intervall in Sekunden für einen umfassenden Scrub des Pools. Der Standardwert 0 bedeutet, dass der Wert osd_deep_scrub aus der Ceph-Konfigurationsdatei verwendet wird.

Reproduzierte Pool-Werte #

Größe: Legt die Anzahl der Reproduktionen für Objekte im Pool fest. Weitere Informationen finden Sie in Abschnitt 18.5.6, „Festlegen der Anzahl der Objektreproduktionen“. Nur reproduzierte Pools.
min_size: Legt die Mindestanzahl von Reproduktionen fest, die für E/A benötigt werden. Weitere Informationen finden Sie in Abschnitt 18.5.6, „Festlegen der Anzahl der Objektreproduktionen“. Nur reproduzierte Pools.
nosizechange: Verhindert, dass die Größe des Pools geändert wird. Beim Erstellen eines Pools wird der Standardwert aus dem Wert des Parameters osd_pool_default_flag_nosizechange übernommen, der standardmäßig false lautet. Gilt nur für reproduzierte Pools, da Sie die Größe für EC-Pools nicht ändern können.
hit_set_type: Aktiviert die Treffersatz-Verfolgung für Cache Pools. Weitere Informationen finden Sie unter Bloomfilter. Für diese Option sind die folgenden Werte möglich: bloom, explicit_hash, explicit_object. Der Standardwert ist bloom, die anderen Werte sind nur für Testzwecke vorgesehen.
hit_set_count: Die Anzahl der Treffersätze, die für Cache Pools gespeichert werden sollen. Je höher die Anzahl, desto mehr RAM wird vom ceph-osd-Daemon belegt. Der Standardwert ist 0.
hit_set_period: Die Dauer einer Treffersatz-Periode in Sekunden für Cache Pools. Je höher die Anzahl, desto mehr RAM wird vom ceph-osd-Daemon belegt. Beim Erstellen eines Pools wird der Standardwert aus dem Wert des Parameters osd_tier_default_cache_hit_set_period übernommen, der standardmäßig 1200 lautet. Gilt nur für reproduzierte Pools, da EC-Pools nicht als Cache-Ebene verwendet werden können.
hit_set_fpp: Die falsch positive Wahrscheinlichkeit für den Bloom-Treffersatz-Typ. Weitere Informationen finden Sie unter Bloomfilter. Der gültige Bereich ist 0,0 bis 1,0. Der Standardwert ist 0,05.
use_gmt_hitset: Erzwingen Sie bei Erstellung eines Treffersatzes für das Cache Tiering, dass OSDs die MGZ-Zeitstempel (mittlere Greenwich-Zeit) verwenden. Dadurch wird sichergestellt, dass Knoten in verschiedenen Zeitzonen dasselbe Ergebnis zurückgeben. Der Standardwert ist 1. Dieser Wert darf nicht geändert werden.
cache_target_dirty_ratio: Der Prozentsatz der bearbeiteten (fehlerhaften) Objekte im Cache Pool, der erreicht sein muss, bevor der Cache Tiering Agent diese Objekte in den Hintergrundspeicher-Pool verschiebt. Der Standardwert ist 0.4.
cache_target_dirty_high_ratio: Der Prozentsatz der bearbeiteten (fehlerhaften) Objekte im Cache Pool, der erreicht sein muss, bevor der Cache Tiering Agent diese Objekte mit höherer Geschwindigkeit in den Hintergrundspeicher-Pool verschiebt. Der Standardwert ist 0.6.
cache_target_full_ratio: Der Prozentsatz der unbearbeiteten (intakten) Objekte im Cache Pool, der erreicht sein muss, bevor der Cache Tiering Agent diese Objekte aus dem Cache Pool entfernt. Der Standardwert ist 0.8.
target_max_bytes: Ceph beginnt mit dem Verschieben oder Entfernen von Objekten, wenn der Grenzwert max_bytes ausgelöst wird.
target_max_objects: Ceph beginnt mit dem Verschieben oder Entfernen von Objekten, wenn der Grenzwert max_objects ausgelöst wird.
hit_set_grade_decay_rate: Temperaturzerfallsrate zwischen zwei aufeinanderfolgenden hit_set. Der Standardwert ist 20.
hit_set_search_last_n: Anzahl der meisten N-Vorkommen in hit_sets für die Temperaturberechnung. Der Standardwert ist 1.
cache_min_flush_age: Die Zeit (in Sekunden), bevor der Cache Tiering Agent ein Objekt vom Cache Pool in den Speicher-Pool verschiebt.
cache_min_evict_age: Die Zeit (in Sekunden), bevor der Cache Tiering Agent ein Objekt aus dem Cache Pool entfernt.

Werte der Pools mit Löschcodierung #

fast_read: Wenn dieses Flag bei Erasure Coding Pools aktiviert wird, stellt die Leseanforderung Teil-Lesevorgänge an alle Shards aus und wartet, bis sie genügend Shards zum Decodieren erhält, die für den Client verarbeitet werden. Wenn im Fall von jerasure- und isa-Erasure-Plugins die ersten K-Antworten zurückgegeben werden, dann wird die Anforderung des Clients sofort anhand der von diesen Antworten decodierten Daten verarbeitet. Diese Vorgehensweise erhöht die CPU-Auslastung und senkt die Datenträger-/Netzwerkauslastung. Diese Flagge wird aktuell nur für Erasure Coded Pools unterstützt. Der Standardwert ist 0.

18.5.6 Festlegen der Anzahl der Objektreproduktionen #

Führen Sie folgendes Kommando aus, um die Anzahl der Objektreproduktionen in einem reproduzierten Pool festzulegen:

cephuser@adm > ceph osd pool set poolname size num-replicas

In num-replicas ist das Objekt selbst enthalten. Geben Sie 3 an, wenn Sie beispielsweise das Objekt und zwei Kopien des Objekts für insgesamt drei Instanzen des Objekts wünschen.

Warnung: Legen Sie nicht weniger als 3 Reproduktionen fest

Wenn Sie num-replicas auf 2 festlegen, wird nur eine Kopie Ihrer Daten erstellt. Wenn Sie eine Objektinstanz verlieren, müssen Sie sich darauf verlassen, dass die andere Kopie seit dem letzten Scrubbing bei der Wiederherstellung nicht beschädigt wurde (ausführliche Informationen siehe Abschnitt 17.6, „Scrubbing von Platzierungsgruppen“).

Wenn der Pool auf eine Reproduktion festgelegt wird, bedeutet dies, dass genau eine Instanz des Datenobjekts im Pool vorhanden ist. Wenn der OSD ausfällt, verlieren Sie die Daten. Ein Pool mit einer Reproduktion wird normalerweise verwendet, wenn temporäre Daten für kurze Zeit gespeichert werden.

Tipp: Festlegen von mehr als 3 Reproduktionen

Wenn Sie 4 Reproduktionen für einen Pool festlegen, erhöht dies die Zuverlässigkeit um 25 %.

Bei zwei Rechenzentren müssen Sie mindestens 4 Reproduktionen für einen Pool festlegen, damit sich je zwei Exemplare in jedem Rechenzentrum befinden. Sollte dann ein Rechenzentrum ausfallen, sind weiterhin zwei Exemplare vorhanden, sodass noch ein weiterer Datenträger verloren gehen kann, ohne dass Datenverlust eintritt.

Anmerkung

Ein Objekt akzeptiert möglicherweise E/As im eingeschränkt leistungsfähigen Modus mit weniger als pool size Reproduktionen. Sie sollten die Einstellung min_size verwenden, um eine Mindestanzahl erforderlicher Reproduktionen für E/A festzulegen. Beispiel:

cephuser@adm > ceph osd pool set data min_size 2

Dadurch wird sichergestellt, dass kein Objekt im Daten-Pool E/A mit weniger Reproduktionen als min_size erhält.

Tipp: Rufen Sie die Anzahl der Objektreproduktionen ab

Führen Sie folgendes Kommando aus, um die Anzahl der Objektreproduktionen abzurufen:

cephuser@adm > ceph osd dump | grep 'replicated size'

Ceph listet die Pools mit hervorgehobenem Attribut replicated size auf. Standardmäßig erstellt Ceph zwei Reproduktionen eines Objekts (insgesamt drei Kopien oder eine Größe von 3).

18.6 Pool-Migration #

Beim Erstellen eines Pools (Informationen hierzu finden Sie in Abschnitt 18.1, „Erstellen eines Pools“) müssen Sie die ersten Parameter wie den Pool-Typ oder die Anzahl der Placement Groups angeben. Wenn Sie sich später entscheiden, diese Parameter zu ändern (z. B. einen reproduzierten Pool in einen Pool mit Löschcodierung umwandeln oder die Anzahl der Platzierungsgruppen verringern), müssen Sie die Pool-Daten zu einem anderen Pool migrieren, dessen Parameter zur gewünschten Implementierung passen.

In diesem Abschnitt werden zwei Migrationsmethoden beschrieben: eine Cache-Ebene-Methode für die allgemeine Pool-Datenmigration und eine Methode, die rbd migrate-Unterkommandos verwendet, um RBD-Images in einen neuen Pool zu migrieren. Jede Methode hat ihre Eigenheiten und Grenzen.

18.6.1 Nutzungsbeschränkungen #

Mit der Cache-Ebene-Methode können Sie einen reproduzierten Pool entweder zu einem Pool mit Löschcodierung oder zu einem anderen reproduzierten Pool migrieren. Die Migration von einem Pool mit Löschcodierung wird nicht unterstützt.
Sie können keine RBD-Images und CephFS-Exporte aus einem reproduzierten Pool zu einem EC-Pool migrieren. Der Grund ist, dass EC-Pools omap nicht unterstützen, während RBD und CephFS omap zum Speichern ihrer Metadaten verwenden. Beispielsweise kann das Header-Objekt des RBD nicht geleert werden. Sie können jedoch Daten in den EC-Pool migrieren und die Metadaten im reproduzierten Pool belassen.
Mit der rbd migration-Methode können Images mit minimaler Client-Ausfallzeit migriert werden. Sie müssen den Client lediglich vor dem prepare-Schritt anhalten und danach wieder starten. Hierbei ist zu beachten, dass nur ein librbd-Client, der diese Funktion unterstützt (Ceph Nautilus oder höher), das Image direkt nach dem prepare-Schritt öffnen kann, ältere librbd-Clients oder die krbd-Clients dagegen erst nach dem commit-Schritt.

18.6.2 Migrieren mit der Cache-Ebene #

Das Prinzip ist einfach: Stellen Sie den Pool, der migriert werden soll, in umgekehrter Reihenfolge in eine Cache-Schicht. Das folgende Beispiel zeigt die Migration des reproduzierten Pools „testpool“ zu einem Pool mit Löschcodierung:

Vorgehen 18.1: Migrieren eines reproduzierten Pools zu einem Pool mit Löschcodierung #

Erstellen Sie einen neuen Pool mit Löschcodierung mit der Bezeichnung „newpool“. Eine ausführliche Erläuterung der Parameter für die Pool-Erstellung finden Sie in Abschnitt 18.1, „Erstellen eines Pools“.
```
 cephuser@adm > ceph osd pool create newpool erasure default
```
Prüfen Sie, ob der verwendete Client-Schlüsselbund für „newpool“ mindestens dieselben Funktionen bietet wie für „testpool“.
Nun verfügen Sie über zwei Pools: den ursprünglichen reproduzierten „testpool“ mit Daten und den neuen leeren Erasure Coded „newpool“:
Abbildung 18.1: Pools vor der Migration #
Richten Sie die Cache-Schicht ein und konfigurieren Sie den reproduzierten „testpool“ als Cache Pool. Mit der Option -force-nonempty können Sie selbst dann eine Cache-Schicht hinzufügen, wenn der Pool bereits Daten enthält:
```
cephuser@adm > ceph tell mon.* injectargs \
 '--mon_debug_unsafe_allow_tier_with_nonempty_snaps=1'
cephuser@adm > ceph osd tier add newpool testpool --force-nonempty
cephuser@adm > ceph osd tier cache-mode testpool proxy
```
Abbildung 18.2: Einrichtung der Cache-Ebene #
Erzwingen Sie, dass der Cache Pool alle Objekte in den neuen Pool verschiebt:
```
cephuser@adm > rados -p testpool cache-flush-evict-all
```
Abbildung 18.3: Leeren von Daten #
Solange nicht alle Daten geleert und zum neuen Erasure Coded Pool verschoben sind, müssen Sie eine Überlagerung angeben, sodass Objekte noch im alten Pool gesucht werden:
```
cephuser@adm > ceph osd tier set-overlay newpool testpool
```
Bei einer Überlagerung werden alle Operationen an den alten reproduzierten „testpool“ weitergeleitet:
Abbildung 18.4: Festlegen der Überlagerung #

Nun können Sie alle Clients auf den Zugriff von Objekten im neuen Pool umstellen.
Wenn alle Daten zum Erasure Coded „newpool“ migriert sind, entfernen Sie die Überlagerung und den alten Cache Pool „testpool“:
```
cephuser@adm > ceph osd tier remove-overlay newpool
cephuser@adm > ceph osd tier remove newpool testpool
```
Abbildung 18.5: Migration abgeschlossen #

Führen Sie folgendes Kommando aus:

cephuser@adm > ceph tell mon.* injectargs \
 '--mon_debug_unsafe_allow_tier_with_nonempty_snaps=0'

18.6.3 Migrieren von RBD-Images #

Für die Migration von RBD-Images aus einem reproduzierten Pool zu einem anderen reproduzierten Pool wird folgende Vorgehensweise empfohlen:

Beenden Sie den Zugriff von Clients (z. B. von einer virtuellen Maschine) auf das RBD-Image.
Erstellen Sie ein neues Image im Ziel-Pool und legen Sie das Quell-Image als übergeordnetes Image fest:
```
cephuser@adm > rbd migration prepare SRC_POOL/IMAGE TARGET_POOL/IMAGE
```
Tipp: Migrieren Sie nur Daten zu einem Pool mit Löschcodierung
Sollen lediglich die Image-Daten zu einem neuen EC-Pool migriert werden und die Metadaten im ursprünglichen reproduzierten Pool verbleiben, führen Sie stattdessen folgendes Kommando aus:
```
cephuser@adm > rbd migration prepare SRC_POOL/IMAGE \
 --data-pool TARGET_POOL/IMAGE
```
Geben Sie den Clients den Zugriff auf das Image im Ziel-Pool.

Migrieren Sie die Daten zum Ziel-Pool:

cephuser@adm > rbd migration execute SRC_POOL/IMAGE

Entfernen Sie das bisherige Image:

cephuser@adm > rbd migration commit SRC_POOL/IMAGE

18.7 Pool Snapshots #

Pool Snapshots sind Snapshots vom Zustand des gesamten Ceph Pools. Mit Pool Snapshots behalten Sie den Verlauf des Pool-Zustands bei. Die Erstellung von Pool Snapshots belegt Speicherplatz proportional zur Pool-Größe. Prüfen Sie immer zunächst, ob im betreffenden Speicher genügend Festplattenspeicherplatz vorhanden ist, bevor Sie einen Snapshot eines Pools erstellen.

18.7.1 Erstellen eines Pool Snapshots #

Mit folgendem Kommando erstellen Sie einen Snapshot eines Pools:

cephuser@adm > ceph osd pool mksnap POOL-NAME SNAP-NAME

Beispiel:

cephuser@adm > ceph osd pool mksnap pool1 snap1
created pool pool1 snap snap1

18.7.2 Auflisten der Snapshots eines Pools #

Mit folgendem Kommando rufen Sie die vorhandenen Snapshots eines Pools ab:

cephuser@adm > rados lssnap -p POOL_NAME

Beispiel:

cephuser@adm > rados lssnap -p pool1
1	snap1	2018.12.13 09:36:20
2	snap2	2018.12.13 09:46:03
2 snaps

18.7.3 Entfernen eines Snapshots eines Pools #

Mit folgendem Kommando entfernen Sie einen Snapshot eines Pools:

cephuser@adm > ceph osd pool rmsnap POOL-NAME SNAP-NAME

18.8 Datenkomprimierung #

BlueStore (siehe Abschnitt 1.4, „BlueStore“) bietet eine direkte Datenkomprimierung, mit der Sie Speicherplatz sparen. Das Komprimierungsverhältnis ist abhängig von den im System gespeicherten Daten. Beachten Sie, dass für die Komprimierung/die Dekomprimierung zusätzliche CPU-Leistung erforderlich ist.

Sie können die Datenkomprimierung global konfigurieren (siehe Abschnitt 18.8.3, „Globale Komprimierungsoptionen“) und dann bestimmte Komprimierungseinstellungen für die einzelnen Pools überschreiben.

Sie können die Komprimierung der Pool-Daten aktivieren oder deaktivieren und auch jederzeit den Komprimierungsalgorithmus und -modus ändern, unabhängig davon, ob der Pool Daten enthält oder nicht.

Vorhandene Daten werden nach Aktivierung der Pool-Komprimierung nicht komprimiert.

Wenn Sie die Komprimierung für einen Pool deaktivieren, werden dessen Daten alle dekomprimiert.

18.8.1 Aktivieren der Komprimierung #

Mit folgendem Kommando aktivieren Sie die Datenkomprimierung für den Pool POOL_NAME:

cephuser@adm > ceph osd pool set POOL_NAME compression_algorithm COMPRESSION_ALGORITHM
cephuser@adm > ceph osd pool set POOL_NAME compression_mode COMPRESSION_MODE

Tipp: Deaktivieren der Pool-Komprimierung

Zum Deaktivieren der Datenkomprimierung für einen Pool geben Sie „none“ als Komprimierungsalgorithmus an:

cephuser@adm > ceph osd pool set POOL_NAME compression_algorithm none

18.8.2 Optionen der Pool-Komprimierung #

Eine vollständige Liste der Komprimierungseinstellungen:

compression_algorithm

Zulässige Werte sind none, zstd und snappy. Die Standardeinstellung lautet snappy.

Der zu verwendende Komprimierungsalgorithmus hängt vom einzelnen Anwendungsfall ab. Einige Empfehlungen:

Behalten Sie die Standardeinstellung snappy bei, sofern es keinen guten Grund gibt, diese Einstellung zu ändern.
zstd bietet ein gutes Komprimierungsverhältnis, verursacht jedoch beim Komprimieren kleiner Datenmengen einen hohen CPU-Overhead.
Vergleichen Sie diese Algorithmen anhand eines Beispiels Ihrer realen Daten und beobachten Sie dabei die CPU- und Arbeitsspeicherauslastung Ihres Clusters.

compression_mode

Zulässige Werte sind none, aggressive, passive und force. Die Standardeinstellung lautet none.

none: Niemals komprimieren
passive: Komprimieren bei Hinweis auf COMPRESSIBLE
aggressive: Komprimieren, falls kein Hinweis auf INCOMPRESSIBLE
force: Immer komprimieren

compression_required_ratio

Wert: Gleitkomma „double“, Grad = SIZE_COMPRESSED / SIZE_ORIGINAL. Der Standardwert lautet 0,875; wenn die Komprimierung also den belegten Speicherplatz um mindestens 12,5 % verringert, wird das Objekt nicht komprimiert.

Objekte mit einem höheren Grad werden nicht komprimiert gespeichert, weil der Nutzen insgesamt sehr gering ist.

compression_max_blob_size

Wert: Ganzzahl ohne Vorzeichen, Größe in Byte. Standardeinstellung: 0

Maximale Größe der Objekte, die komprimiert werden.

compression_min_blob_size

Wert: Ganzzahl ohne Vorzeichen, Größe in Byte. Standardeinstellung: 0

Mindestgröße der Objekte, die komprimiert werden.

18.8.3 Globale Komprimierungsoptionen #

Die folgenden Konfigurationsoptionen können in der Ceph-Konfiguration festgelegt werden und gelten für alle OSDs und nicht nur für einen einzelnen Pool. Die in Abschnitt 18.8.2, „Optionen der Pool-Komprimierung“ aufgelistete für den Pool spezifische Konfiguration hat Vorrang.

bluestore_compression_algorithm

Siehe compression_algorithm.

bluestore_compression_mode

Siehe compression_mode.

bluestore_compression_required_ratio

Siehe compression_required_ratio.

bluestore_compression_min_blob_size

Wert: Ganzzahl ohne Vorzeichen, Größe in Byte. Standardeinstellung: 0

Mindestgröße der Objekte, die komprimiert werden. Die Einstellung wird standardmäßig zugunsten von bluestore_compression_min_blob_size_hdd und bluestore_compression_min_blob_size_ssd ignoriert. Wenn ein Wert ungleich null festgelegt ist, erhält sie Vorrang.

bluestore_compression_max_blob_size

Wert: Ganzzahl ohne Vorzeichen, Größe in Byte. Standardeinstellung: 0

Maximale Größe von komprimierten Objekten, bevor sie in kleinere Blöcke aufgeteilt werden. Die Einstellung wird standardmäßig zugunsten von bluestore_compression_max_blob_size_hdd und bluestore_compression_max_blob_size_ssd ignoriert. Wenn ein Wert ungleich null festgelegt ist, erhält sie Vorrang.

bluestore_compression_min_blob_size_ssd

Wert: Ganzzahl ohne Vorzeichen, Größe in Byte. Standardeinstellung: 8K

Mindestgröße der Objekte, die komprimiert und auf Festkörperlaufwerk gespeichert werden.

bluestore_compression_max_blob_size_ssd

Wert: Ganzzahl ohne Vorzeichen, Größe in Byte. Standardeinstellung: 64K

Maximale Größe von komprimierten, auf einem Solid-State-Laufwerk gespeicherten Objekten, bevor sie in kleinere Blöcke aufgeteilt werden.

bluestore_compression_min_blob_size_hdd

Wert: Ganzzahl ohne Vorzeichen, Größe in Byte. Standardeinstellung: 128K

Mindestgröße der Objekte, die komprimiert und auf Festplatten gespeichert werden.

bluestore_compression_max_blob_size_hdd

Wert: Ganzzahl ohne Vorzeichen, Größe in Byte. Standardeinstellung: 512K

Maximale Größe von komprimierten, auf einer Festplatte gespeicherten Objekten, bevor sie in kleinere Blöcke aufgeteilt werden.