17 Verwaltung gespeicherter Daten #

Die flexible Steuerung der Datenplatzierung mithilfe der CRUSH-Zuordnung zählt zu Cephs Stärken. Gleichzeitig ist dies mit der schwierigste Teil bei der Clusterverwaltung. Geräteklassen automatisieren die häufigsten Änderungen an CRUSH-Zuordnungen, die der Administrator bisher manuell vornehmen musste.

17.1.1.1 Das CRUSH-Verwaltungsproblem #

 

Ceph-Cluster setzen sich häufig aus verschiedenen Typen von Speichergeräten zusammen, also HDD, SSD, NVMe oder sogar gemischten Klassen dieser Geräte. Diese unterschiedlichen Speichergerättypen werden hier als Geräteklassen bezeichnet, sodass eine Verwechslung mit der Eigenschaft type der CRUSH-Buckets verhindert wird (z. B. „host“, „rack“, „row“; siehe Abschnitt 17.2, „Buckets“). SSD-gestützte Ceph-OSDs sind deutlich schneller als OSDs mit drehbaren Scheiben und damit für bestimmte Workloads besser geeignet. Mit Ceph können Sie ganz einfach RADOS-Pools für unterschiedliche Datenmengen oder Workloads erstellen und unterschiedliche CRUSH-Regeln für die Datenplatzierung in diesen Pools zuweisen.

Abbildung 17.1: OSDs mit gemischten Geräteklassen #

 

Es ist jedoch mühsam, die CRUSH-Regeln so einzurichten, dass die Daten nur auf eine bestimmte Geräteklasse platziert werden. Die Regeln folgen der CRUSH-Hierarchie, doch wenn die Geräte in den Hosts oder Racks gemischt angeordnet sind (wie in der Beispielhierarchie oben), werden sie (standardmäßig) miteinander vermischt, sodass sie in den gleichen Unterbäumen der Hierarchie auftreten. In früheren Versionen von SUSE Enterprise Storage mussten sie manuell in separate Bäume sortiert werden, wobei für jede Geräteklasse mehrere Versionen der einzelnen Zwischen-Knoten erstellt werden mussten.

cephuser@adm > ceph osd tree
 ID CLASS WEIGHT   TYPE NAME      STATUS REWEIGHT PRI-AFF
 -1       83.17899 root default
 -4       23.86200     host cpach
 2   hdd  1.81898         osd.2      up  1.00000 1.00000
 3   hdd  1.81898         osd.3      up  1.00000 1.00000
 4   hdd  1.81898         osd.4      up  1.00000 1.00000
 5   hdd  1.81898         osd.5      up  1.00000 1.00000
 6   hdd  1.81898         osd.6      up  1.00000 1.00000
 7   hdd  1.81898         osd.7      up  1.00000 1.00000
 8   hdd  1.81898         osd.8      up  1.00000 1.00000
 15  hdd  1.81898         osd.15     up  1.00000 1.00000
 10  nvme 0.93100         osd.10     up  1.00000 1.00000
 0   ssd  0.93100         osd.0      up  1.00000 1.00000
 9   ssd  0.93100         osd.9      up  1.00000 1.00000

cephuser@adm > ceph osd crush rm-device-class osd.2 osd.3
done removing class of osd(s): 2,3
cephuser@adm > ceph osd crush set-device-class ssd osd.2 osd.3
set osd(s) 2,3 to class 'ssd'

cephuser@adm > ceph osd crush rule create-replicated RULE_NAME ROOT FAILURE_DOMAIN_TYPE DEVICE_CLASS

cephuser@adm > ceph osd crush rule create-replicated fast default host ssd

cephuser@adm > ceph osd pool create fast_pool 128 128 replicated fast

cephuser@adm > ceph osd erasure-code-profile set myprofile \
 k=4 m=2 crush-device-class=ssd crush-failure-domain=host
cephuser@adm > ceph osd pool create mypool 64 erasure myprofile

rule ecpool {
  id 2
  type erasure
  min_size 3
  max_size 6
  step set_chooseleaf_tries 5
  step set_choose_tries 100
  step take default class ssd
  step chooseleaf indep 0 type host
  step emit
}

cephuser@adm > ceph osd crush class ls
[
  "hdd",
  "ssd"
]

cephuser@adm > ceph osd crush rule ls
replicated_rule
fast

cephuser@adm > ceph osd crush rule dump fast
{
		"rule_id": 1,
		"rule_name": "fast",
		"ruleset": 1,
		"type": 1,
		"min_size": 1,
		"max_size": 10,
		"steps": [
						{
										"op": "take",
										"item": -21,
										"item_name": "default~ssd"
						},
						{
										"op": "chooseleaf_firstn",
										"num": 0,
										"type": "host"
						},
						{
										"op": "emit"
						}
		]
}

cephuser@adm > ceph osd crush class ls-osd ssd
0
1

Die mit den Buckets definierte Struktur kann als Knoten-Baum angezeigt werden. Buckets sind Knoten und OSDs sind Blätter an diesem Baum.

Die Regeln in der CRUSH-Zuordnung definieren, wie OSDs aus diesem Baum ausgewählt werden. Eine Regel beginnt mit einem Knoten und durchläuft dann den Baum nach unten, um eine Reihe von OSDs zurückzugeben. Es ist nicht möglich, zu definieren, welcher Zweig ausgewählt werden muss. Stattdessen wird durch den CRUSH-Algorithmus sichergestellt, dass die Gruppe der OSDs die Reproduktionsanforderungen erfüllt und die Daten gleichmäßig verteilt.

Bei step take bucket beginnt der Durchlauf des Knoten-Baums am angegebenen Bucket (nicht am Bucket-Typ). Wenn OSDs aus allen Zweigen am Baum zurückgegeben werden müssen, dann muss der Bucket der Root Bucket sein. Andernfalls durchlaufen die folgenden Schritte nur einen Teilbaum.

In der Regeldefinition folgen nach step take ein oder zwei step choose-Einträge. Mit jedem step choose wird eine definierte Anzahl von Knoten (oder Zweigen) aus dem vorher ausgewählten oberen Knoten gewählt.

Am Ende werden die ausgewählten OSDs mit step emit zurückgegeben.

step chooseleaf ist eine praktische Funktion, mit der OSDs direkt aus Zweigen des angegebenen Buckets ausgewählt werden.

Abbildung 17.2, „Beispielbaum“ zeigt ein Beispiel, wie step zum Durchlaufen eines Baums verwendet wird. In den folgenden Regeldefinitionen entsprechen die orangen Pfeile und Zahlen example1a und example1b und die blauen Pfeile example2.

Abbildung 17.2: Beispielbaum #

 

# orange arrows
rule example1a {
        ruleset 0
        type replicated
        min_size 2
        max_size 10
        # orange (1)
        step take rack1
        # orange (2)
        step choose firstn 0 host
        # orange (3)
        step choose firstn 1 osd
        step emit
}

rule example1b {
        ruleset 0
        type replicated
        min_size 2
        max_size 10
        # orange (1)
        step take rack1
        # orange (2) + (3)
        step chooseleaf firstn 0 host
        step emit
}

# blue arrows
rule example2 {
        ruleset 0
        type replicated
        min_size 2
        max_size 10
        # blue (1)
        step take room1
        # blue (2)
        step chooseleaf firstn 0 rack
        step emit
}

Eine CRUSH-Regel definiert den Ersatz für fehlerhafte Knoten oder OSDs (weitere Informationen finden Sie in Abschnitt 17.3, „Regelsatz“). Für das Schlüsselwort step ist entweder firstn oder indep als Parameter erforderlich. Abbildung 17.3, „Methoden für den Austausch von Knoten“ zeigt ein Beispiel.

firstn fügt Ersatz-Knoten am Ende der Liste der aktiven Knoten hinzu. Im Fall eines fehlerhaften Knotens werden die folgenden fehlerfreien Knoten nach links verschoben, um die Lücke der fehlerhaften Knoten zu schließen. Dies ist die standardmäßige und erwünschte Methode für reproduzierte Pools, weil ein sekundärer Knoten bereits alle Daten enthält und daher die Aufgaben des primären Knoten sofort übernehmen kann.

indep wählt feste Ersatz-Knoten für jeden aktiven Knoten aus. Der Ersatz für einen fehlerhaften Knoten ändert nicht die Reihenfolge der anderen Knoten. Dies ist die erwünschte Methode für Erasure Coded Pools. In Erasure Coded Pools hängen die in einem Knoten gespeicherten Daten von ihrer Position in der Knoten-Auswahl ab. Wenn sich die Reihenfolge der Knoten ändert, müssen alle Daten in den betroffenen Knoten neu platziert werden.

Abbildung 17.3: Methoden für den Austausch von Knoten #

 

Eine Platzierungsgruppe (PG) aggregiert Objekte in einem Pool. Der wichtigste Grund: Die Nachverfolgung der Objektplatzierung und der Metadaten für einzelne Objekte ist rechnerisch aufwendig. In einem System mit Millionen von Objekten ist es beispielsweise nicht möglich, die Platzierung einzelner Objekte direkt zu verfolgen.

Abbildung 17.4: Platzierungsgruppen in einem Pool #

 

Der Ceph-Client berechnet die Platzierungsgruppe, zu der ein Objekt gehört. Hierzu erhält die Objekt-ID ein Hash und es wird eine Aktion aufgeführt, die auf der Anzahl der PGs im definierten Pool und auf der ID des Pools beruht.

Der Inhalt des Objekts in einer Platzierungsgruppe wird in einer Gruppe von OSDs gespeichert. In einem reproduzierten Pool der Größe 2 werden Objekte durch die Platzierungsgruppen beispielsweise auf zwei OSDs gespeichert:

Abbildung 17.5: Platzierungsgruppen und OSDs #

 

Wenn OSD 2 ausfällt, wird der Platzierungsgruppe 1 ein anderes OSD zugewiesen, auf dem dann Kopien aller Objekte auf OSD 1 abgelegt werden. Wird die Poolgröße von 2 auf 3 erhöht, wird der Platzierungsgruppe ein zusätzliches OSD zugewiesen, das dann Kopien aller Objekte in der Platzierungsgruppe erhält.

Platzierungsgruppen fungieren nicht als Eigentümer des OSD, sondern nutzen es gemeinsam mit anderen Platzierungsgruppen aus demselben Pool oder sogar aus anderen Pools. Wenn OSD 2 ausfällt, muss die Platzierungsgruppe 2 ebenfalls Kopien der Objekte wiederherstellen, wobei OSD 3 herangezogen wird.

Wenn die Anzahl der Platzierungsgruppen wächst, werden den neuen Platzierungsgruppen entsprechend OSDs zugewiesen. Auch das Ergebnis der CRUSH-Funktion ändert sich und einige Objekte aus den bisherigen Platzierungsgruppen werden in die neuen Platzierungsgruppen kopiert und aus den bisherigen Gruppen entfernt.

Anmerkung

Seit Ceph Nautilus (v14.x) können Sie das Ceph-Manager-Modul pg_autoscaler verwenden, um die PGs bei Bedarf automatisch zu skalieren. Wenn Sie diese Funktion aktivieren möchten, lesen Sie im Section 8.1.1.1, “Default PG and PGP counts” nach.

Beim Erstellen eines neuen Pools können Sie den Wert von PG_NUM noch manuell wählen:

# ceph osd pool create POOL_NAME PG_NUM

PG_NUM kann nicht automatisch berechnet werden. Die folgenden Werte kommen häufig zum Einsatz, je nach Anzahl der OSDs im Cluster:

Mit wachsender Anzahl der OSDs wird die Auswahl des richtigen Werts für PG_NUM immer wichtiger. PG_NUM wirkt sich stark auf das Verhalten des Clusters und auf die Haltbarkeit der Daten bei einem OSD-Fehler aus.

total PGs = (OSDs * 100) / POOL_SIZE

          (200 * 100) / 3 = 6667

Anmerkung

Seit Ceph Nautilus (v14.x) können Sie das Ceph-Manager-Modul pg_autoscaler verwenden, um die PGs bei Bedarf automatisch zu skalieren. Wenn Sie diese Funktion aktivieren möchten, lesen Sie im Section 8.1.1.1, “Default PG and PGP counts” nach.

Wenn Sie die Anzahl der Platzierungsgruppen in einem Pool noch manuell festlegen müssen, müssen Sie sie zum Zeitpunkt der Poolerstellung angeben (weitere Informationen finden Sie in Abschnitt 18.1, „Erstellen eines Pools“). Die festgelegte Anzahl der Platzierungsgruppen für einen Pool kann mit folgendem Kommando erhöht werden:

# ceph osd pool set POOL_NAME pg_num PG_NUM

Wenn Sie die Anzahl der Platzierungsgruppen erhöhen, müssen Sie auch die Anzahl der zu platzierenden Platzierungsgruppen (PGP_NUM) erhöhen, damit der Cluster neu ausgeglichen werden kann. PGP_NUM ist die Anzahl der Platzierungsgruppen, die der CRUSH-Algorithmus zur Platzierung berücksichtigt. Wird PG_NUM erhöht, werden die Platzierungsgruppen geteilt; die Daten werden allerdings erst dann zu den neueren Platzierungsgruppen migriert, wenn PGP_NUM erhöht wird. PGP_NUM muss gleich PG_NUM sein. Mit folgendem Kommando erhöhen Sie die Anzahl der Platzierungsgruppen zur Platzierung:

# ceph osd pool set POOL_NAME pgp_num PGP_NUM

Führen Sie folgendes get-Kommando aus, um die Anzahl der Platzierungsgruppen in einem Pool festzustellen:

# ceph osd pool get POOL_NAME pg_num

Mit folgendem Kommando stellen Sie die Statistik für die Platzierungsgruppen in Ihrem Cluster fest:

# ceph pg dump [--format FORMAT]

Zulässige Formate sind „plain“ (Standard) und „json“.

Mit folgendem Kommando stellen Sie die Statistiken für alle Platzierungsgruppen fest, die in einem bestimmten Status hängen geblieben sind:

# ceph pg dump_stuck STATE \
 [--format FORMAT] [--threshold THRESHOLD]

STATE lautet „inactive“ (PGs können keine Lese- oder Schreibvorgänge verarbeiten, da sie darauf warten, dass ein OSD die jeweils neuesten Daten bereitstellt), „unclean“ (PGs enthalten Objekte, die nicht so oft wie gefordert reproduziert wurden), „stale“ (PGs besitzen einen unbekannten Status – die OSDs, auf denen sie gehostet werden, haben den Status nicht im Zeitraum zurückgegeben, der in der Option mon_osd_report_timeout festgelegt ist), „undersized“ oder „degraded“.

Zulässige Formate sind „plain“ (Standard) und „json“.

Der Schwellwert definiert den Mindestzeitraum (in Sekunden), über den die Platzierungsgruppe hängen geblieben sein muss, bevor sie in die zurückgegebenen Statistiken aufgenommen wird (standardmäßig 300 Sekunden).

Mit folgendem Kommando suchen Sie die Platzierungsgruppenzuordnung für eine bestimmte Platzierungsgruppe:

# ceph pg map PG_ID

Ceph gibt die Platzierungsgruppenzuordnung, die Platzierungsgruppe und den OSD-Status zurück:

# ceph pg map 1.6c
osdmap e13 pg 1.6c (1.6c) -> up [1,0] acting [1,0]

Mit folgendem Kommando rufen Sie die Statistiken für eine bestimmte Platzierungsgruppe ab:

# ceph pg PG_ID query

Mit folgendem Kommando führen Sie das Scrubbing (Abschnitt 17.6, „Scrubbing von Platzierungsgruppen“) einer Platzierungsgruppe aus:

# ceph pg scrub PG_ID

Ceph prüft die primären Knoten und die Reproduktionsknoten, erzeugt einen Katalog aller Objekte der Platzierungsgruppe und führt einen Vergleich aus, mit dem gewährleistet wird, dass keine Objekte fehlen oder fehlerhaft zugeordnet wurden und dass die Inhalte der Objekte konsistent sind. Unter der Voraussetzung, dass alle Reproduktionen übereinstimmen, wird mit einem abschließenden semantischen Durchlauf geprüft, ob alle snapshotspezifischen Objekt-Metadaten konsistent sind. Fehler werden in Protokollen erfasst.

Unter Umständen müssen mehrere Platzierungsgruppen wiederhergestellt und/oder abgeglichen werden, deren Daten unterschiedlich wichtig sind. Die PGs enthalten beispielsweise Daten für Images, die auf derzeit laufenden Computern verwendet werden, andere PGs dagegen werden von inaktiven Computern herangezogen oder enthalten weniger relevante Daten. In diesem Fall muss die Wiederherstellung der betreffenden Gruppen priorisiert werden, sodass die Leistung und Verfügbarkeit der in diesen Gruppen gespeicherten Daten rascher wieder bereitstehen. Mit folgendem Kommando markieren Sie bestimmte Platzierungsgruppen bei einem Abgleich oder einer Wiederherstellung als priorisiert:

# ceph pg force-recovery PG_ID1 [PG_ID2 ... ]
# ceph pg force-backfill PG_ID1 [PG_ID2 ... ]

Hiermit führt Ceph zuerst die Wiederherstellung oder den Abgleich der angegebenen Platzierungsgruppen durch und verarbeitet dann erst andere Platzierungsgruppen. Laufende Abgleich- oder Wiederherstellungsvorgänge werden nicht unterbrochen, sondern die angegebenen PGs werden so rasch wie möglich verarbeitet. Wenn Sie Ihre Meinung ändern oder nicht die richtigen Gruppen priorisiert haben, können Sie die Priorisierung abbrechen:

# ceph pg cancel-force-recovery PG_ID1 [PG_ID2 ... ]
# ceph pg cancel-force-backfill PG_ID1 [PG_ID2 ... ]

Mit den Kommandos cancel-* wird das Flag „force“ aus den PGs entfernt, sodass sie in der standardmäßigen Reihenfolge verarbeitet werden. Auch dieser Vorgang wirkt sich nicht auf die derzeit verarbeiten Platzierungsgruppen aus, sondern lediglich auf Gruppen, die sich noch in der Warteschlange befinden. Nach der Wiederherstellung oder dem Abgleich der Gruppe wird das Flag „force“ automatisch gelöscht.

Wenn mindestens ein Objekt im Cluster verloren gegangen ist und Sie nicht mehr weiter nach den verlorenen Daten suchen möchten, müssen Sie die nicht gefundenen Objekte als „verloren“ markieren.

Können die Objekte auch nach Abfrage aller denkbaren Speicherorte nicht abrufen werden, müssen Sie die verlorenen Objekte ggf. aufgeben. Dieser Fall kann bei außergewöhnlichen Fehlerkombinationen auftreten, bei denen Informationen über Schreibvorgänge an den Cluster weitergegeben werden, bevor die Schreibvorgänge selbst wiederhergestellt werden.

Derzeit wird ausschließlich die Option „revert“ unterstützt, mit der entweder ein Abgleich mit einer früheren Version des Objekts erfolgt oder das Objekt „vergessen“ wird (sofern ein neues Objekt vorliegt). Mit folgendem Kommando markieren Sie die nicht gefundenen („unfound“) Objekte als verloren („lost“):

  cephuser@adm > ceph pg PG_ID mark_unfound_lost revert|delete

Platzierungsgruppen (PGs) sind ein internes Implementierungsdetail zur Verteilung der Daten durch Ceph. Wenn Sie die PG-Autoskalierung aktivieren, können Sie zulassen, dass der Cluster PGs entweder selbst erstellt oder automatisch einstellt, je nachdem, wie der Cluster genutzt wird.

Jeder Pool im System verfügt über eine Eigenschaft pg_autoscale_mode, die auf off, on oder warn festgelegt werden kann:

Die Autoskalierung wird auf einer Pro-Pool-Basis konfiguriert und kann in drei Modi ausgeführt werden:

So legen Sie den Autoskalierungsmodus für bestehende Pools fest:

cephuser@adm > ceph osd pool set POOL_NAME pg_autoscale_mode mode

Mit folgendem Kommando können Sie auch den Standardmodus pg_autoscale_mode konfigurieren, der auf alle zukünftig erstellten Pools angewendet wird:

cephuser@adm > ceph config set global osd_pool_default_pg_autoscale_mode MODE

Mit diesem Kommando können Sie jeden Pool, seine relative Auslastung und alle vorgeschlagenen Änderungen an der PG-Anzahl anzeigen:

cephuser@adm > ceph osd pool autoscale-status

Gehen Sie zum Bearbeiten einer bestehenden CRUSH-Zuordnung folgendermaßen vor:

Tipp: Verwenden Sie ein Versionierungssystem

Verwenden Sie ein Versionierungssystem (z. B. git oder svn) für die exportierten und bearbeiteten CRUSH-Zuordnung-Dateien. Damit wird ein etwaiger Abgleich vereinfacht.

Tipp: Testen Sie die neue CRUSH-Zuordnung

Testen Sie die neue, angepasste CRUSH-Zuordnung mit dem Kommando crushtool --test und vergleichen Sie sie mit dem Status vor Anwendung der neuen CRUSH-Zuordnung. Nützliche Kommandoschalter: --show-statistics, --show-mappings, --show-bad-mappings, --show-utilization, --show-utilization-all, --show-choose-tries

Führen Sie zum Hinzufügen eines OSD in der CRUSH-Zuordnung des aktiven Clusters folgendes Kommando aus:

cephuser@adm > ceph osd crush set id_or_name weight root=pool-name
bucket-type=bucket-name ...

Im folgenden Beispiel wird osd.0 zur Hierarchie hinzugefügt oder der OSD wird von einem vorigen Standort verschoben.

cephuser@adm > ceph osd crush set osd.0 1.0 root=data datacenter=dc1 room=room1 \
row=foo rack=bar host=foo-bar-1

Das „Gewicht“ eines Ceph OSD kann mit zwei ähnlichen Kommandos geändert werden. Die Kommandos unterscheiden sich durch ihren Nutzungskontext, was zu Verwirrung führen kann.

17.5.3.1 ceph osd reweight #

 

Wert:

cephuser@adm > ceph osd reweight OSD_NAME NEW_WEIGHT

Mit ceph osd reweight wird ein überschreibendes Gewicht für das Ceph OSD festgelegt. Dieser Wert im Bereich 0 bis 1 zwingt CRUSH, die Daten zu verlagern, die sich ansonsten auf diesem Laufwerk befinden würden. Das Gewicht, das den Buckets oberhalb des OSD zugewiesen ist, wird hiermit nicht geändert. Dieser Vorgang fungiert als Korrekturmaßnahme für den Fall, dass die normale CRUSH-Distribution nicht ordnungsgemäß funktioniert. Wenn beispielsweise ein OSD bei 90 % steht und die anderen bei 40 %, können Sie dieses Gewicht senken und das Ungleichgewicht damit beheben.

Anmerkung: OSD-Gewicht ist temporär

Beachten Sie, dass ceph osd reweight keine dauerhafte Einstellung ist. Wird ein OSD als „out“ gekennzeichnet, wird sein Gewicht auf 0 festgelegt; sobald es wieder als „in“ gekennzeichnet wird, erhält das Gewicht den Wert 1.

cephuser@adm > ceph osd crush reweight OSD_NAME NEW_WEIGHT

Führen Sie zum Entfernen eines OSD in der CRUSH-Zuordnung eines aktiven Clusters folgendes Kommando aus:

cephuser@adm > ceph osd crush remove OSD_NAME

Mit dem Kommando ceph osd crush add-bucket fügen Sie der CRUSH-Zuordnung eines aktiven Clients einen Bucket hinzu:

cephuser@adm > ceph osd crush add-bucket BUCKET_NAME BUCKET_TYPE

Mit folgendem Kommando verschieben Sie einen Bucket an einen anderen Standort oder eine andere Position in der CRUSH-Zuordnung-Hierarchie:

cephuser@adm > ceph osd crush move BUCKET_NAME BUCKET_TYPE=BUCKET_NAME [...]

Beispiel:

cephuser@adm > ceph osd crush move bucket1 datacenter=dc1 room=room1 row=foo rack=bar host=foo-bar-1

Mit folgendem Kommando entfernen Sie einen Bucket:

cephuser@adm > ceph osd crush remove BUCKET_NAME

Anmerkung: Nur leere Buckets

Ein Bucket kann nur dann aus der CRUSH-Hierarchie entfernt werden, wenn er leer ist.