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.
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
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.
Der Name des Pools. Er muss eindeutig sein. Diese Option muss aktiviert sein.
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
.
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.
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.
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.
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.
Führen Sie zum Auflisten der Pools Ihres Clusters Folgendes aus:
cephuser@adm >
ceph osd pool ls
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.
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=truecephuser@adm >
ceph osd pool delete pool_name pool_name --yes-i-really-really-mean-itcephuser@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.
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
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
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.
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:
Speicherplatz (in Byte), der durch den Pool belegt wird.
Anzahl der im Pool gespeicherten Objekte.
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.
Anzahl der Objektreproduktionen. Wenn beispielsweise ein reproduzierter Pool mit dem Reproduktionsfaktor 3 „x“ Objekte umfasst, enthält er in der Regel 3 * x Exemplare.
Anzahl von Objekten im eingeschränkt leistungsfähigen Status (nicht alle Exemplare vorhanden), wobei das Exemplar auf dem primären OSD fehlt.
Anzahl der nicht gefundenen Objekte.
Anzahl der eingeschränkt leistungsfähigen Objekte.
Gesamtanzahl der für diesen Pool angeforderten Leseoperationen.
Datenmenge (in Byte), die aus diesem Pool ausgelesen wurde.
Gesamtanzahl der für diesen Pool angeforderten Schreiboperationen.
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.
Speicherplatz (in Byte), der für komprimierte Daten zugewiesen ist.
Speicherplatz (in Byte), den die komprimierten Daten belegen, wenn sie nicht komprimiert sind.
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:
Die Anzahl der Placement Groups für den Pool.
Die effektive Anzahl von Placement Groups zum Berechnen der Datenplatzierung. Der gültige Bereich ist gleich oder kleiner PG_NUM
.
Mit folgendem Kommando rufen Sie alle Werte für einen bestimmten Pool ab:
cephuser@adm >
ceph osd pool get POOL_NAME all
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:
Der Zeitraum in Sekunden, für den Clients bestätigte, aber noch nicht zugewiesene Anforderungen erneut wiedergeben können.
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.
Die effektive Anzahl von Placement Groups zum Berechnen der Datenplatzierung.
Der zu verwendende Regelsatz für die Zuordnung der Objektplatzierung im Cluster.
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).
Verhindert, dass der Pool entfernt wird.
Verhindert, dass die Werte pg_num
und pgp_num
des Pools geändert werden.
Deaktiviert (Deep-)Scrubbing der Daten für den entsprechenden Pool, um eine vorübergehend hohe E/A-Last zu vermeiden.
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.
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.
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.
Das Intervall in Sekunden für ein deep Scrubbing des Pools. Der Standardwert 0
bedeutet, dass der Wert osd_deep_scrub
aus der Ceph-Konfigurationsdatei verwendet wird.
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.
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.
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.
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.
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
.
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.
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
.
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.
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
.
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
.
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
.
Ceph beginnt mit dem Verschieben oder Entfernen von Objekten, wenn der Grenzwert max_bytes
ausgelöst wird.
Ceph beginnt mit dem Verschieben oder Entfernen von Objekten, wenn der Grenzwert max_objects
ausgelöst wird.
Temperaturzerfallsrate zwischen zwei aufeinanderfolgenden hit_set
. Der Standardwert ist 20
.
Anzahl der meisten N
-Vorkommen in hit_set
s für die Temperaturberechnung. Der Standardwert ist 1
.
Die Zeit (in Sekunden), bevor der Cache Tiering Agent ein Objekt vom Cache Pool in den Speicher-Pool verschiebt.
Die Zeit (in Sekunden), bevor der Cache Tiering Agent ein Objekt aus dem Cache Pool entfernt.
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
.
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.
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.
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.
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.
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).
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.
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.
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:
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“:
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-nonemptycephuser@adm >
ceph osd tier cache-mode testpool proxy
Erzwingen Sie, dass der Cache Pool alle Objekte in den neuen Pool verschiebt:
cephuser@adm >
rados -p testpool cache-flush-evict-all
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:
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 newpoolcephuser@adm >
ceph osd tier remove newpool testpool
Führen Sie folgendes Kommando aus:
cephuser@adm >
ceph tell mon.* injectargs \
'--mon_debug_unsafe_allow_tier_with_nonempty_snaps=0'
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
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
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.
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
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
Mit folgendem Kommando entfernen Sie einen Snapshot eines Pools:
cephuser@adm >
ceph osd pool rmsnap POOL-NAME SNAP-NAME
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.
Mit folgendem Kommando aktivieren Sie die Datenkomprimierung für den Pool POOL_NAME:
cephuser@adm >
ceph
osd pool set POOL_NAME compression_algorithm COMPRESSION_ALGORITHMcephuser@adm >
ceph
osd pool set POOL_NAME compression_mode COMPRESSION_MODE
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
Eine vollständige Liste der Komprimierungseinstellungen:
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.
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
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.
Wert: Ganzzahl ohne Vorzeichen, Größe in Byte. Standardeinstellung: 0
Maximale Größe der Objekte, die komprimiert werden.
Wert: Ganzzahl ohne Vorzeichen, Größe in Byte. Standardeinstellung: 0
Mindestgröße der Objekte, die komprimiert werden.
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.
Siehe compression_algorithm.
Siehe compression_mode.
Siehe compression_required_ratio.
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.
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.
Wert: Ganzzahl ohne Vorzeichen, Größe in Byte. Standardeinstellung: 8K
Mindestgröße der Objekte, die komprimiert und auf Festkörperlaufwerk gespeichert werden.
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.
Wert: Ganzzahl ohne Vorzeichen, Größe in Byte. Standardeinstellung: 128K
Mindestgröße der Objekte, die komprimiert und auf Festplatten gespeichert werden.
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.