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

17 Verwaltung gespeicherter Daten Edit source

Der CRUSH-Algorithmus bestimmt, wie Daten gespeichert und abgerufen werden, indem er die Datenspeicherorte berechnet. CRUSH ist die Grundlage für die direkte Kommunikation der Ceph-Clients mit OSDs, ansonsten müssten sie über einen zentralen Server oder Broker kommunizieren. Mit einer algorithmisch festgelegten Methode zum Speichern und Abrufen von Daten vermeidet Ceph einen Single-Point-of-Failure, einen Leistungsengpass und eine physische Beschränkung der Skalierbarkeit.

CRUSH benötigt eine Zuordnung Ihres Clusters und verwendet die CRUSH-Zuordnung zum pseudozufälligen Speichern und Abrufen von Daten in OSDs gleichmäßiger Datenverteilung im Cluster.

CRUSH-Zuordnungen enthalten eine Liste von OSDs, eine Liste der „Buckets“ zum Aggregieren der Geräte an physischen Standorten sowie eine Liste der Regeln, die CRUSH anweisen, wie es Daten in den Pools eines Ceph-Clusters reproduzieren soll. Durch Widerspiegeln der zugrundeliegenden physischen Struktur der Installation kann CRUSH potenzielle Ursachen von korrelierten Gerätefehlern nachbilden und somit eine Lösung suchen. Zu den typischen Ursachen zählen die physische Umgebung, eine gemeinsame Energiequelle und ein gemeinsames Netzwerk. Durch Verschlüsseln dieser Informationen in die Cluster-Zuordnung können CRUSH-Platzierungsrichtlinien Objektreproduktionen auf verschiedene Fehlerdomänen auslagern und gleichzeitig die gewünschte Verteilung beibehalten. Um beispielsweise für den Fall gleichzeitig auftretender Fehler vorzusorgen, sollte am besten sichergestellt werden, dass sich Datenreproduktionen auf Geräten mit unterschiedlichen Ablagefächern, Racks, Netzanschlüssen, Controllern und/oder physischen Speicherorten befinden.

Nach Bereitstellung eines Ceph-Clusters wird eine standardmäßige CRUSH-Zuordnung generiert. Sie eignet sich sehr gut für Ihre Ceph Sandbox-Umgebung. Wenn Sie jedoch einen sehr großen Daten-Cluster bereitstellen, sollten Sie die Entwicklung einer benutzerdefinierten CRUSH-Zuordnung ernsthaft in Erwägung ziehen, weil sie Ihnen die Verwaltung Ihres Ceph-Clusters erleichtert, die Leistung verbessert und die Datensicherheit gewährleistet.

Wenn beispielsweise ein OSD ausfällt, können Sie anhand der CRUSH-Zuordnung das physische Rechenzentrum, den Raum, die Reihe und das Rack des Hosts mit dem fehlerhaften OSD finden, für den Fall, dass Sie Support vor Ort benötigen oder die Hardware austauschen müssen.

Entsprechend kann CRUSH Ihnen auch dabei helfen, Fehler schneller zu finden. Wenn beispielsweise alle OSDs in einem bestimmten Rack gleichzeitig ausfallen, liegt der Fehler möglicherweise bei einem Netzwerkschalter oder der Energiezufuhr zum Rack bzw. am Netzwerkschalter statt an den OSDs selbst.

Eine benutzerdefinierte CRUSH-Zuordnung kann Ihnen auch dabei helfen, die physischen Standorte zu finden, an denen Ceph redundante Kopien der Daten speichert, wenn sich die Platzierungsgruppen (siehe Abschnitt 17.4, „Platzierungsgruppen“), die mit einem fehlerhaften Host verknüpft sind, in einem eingeschränkt leistungsfähigen Zustand befinden.

Eine CRUSH-Zuordnung setzt sich aus drei Hauptabschnitten zusammen.

  • OSD-Geräte umfassen alle Objektspeichergeräte, die einem ceph-osd-Daemon entsprechen.

  • Buckets sind eine hierarchische Ansammlung von Speicherorten (beispielsweise Reihen, Racks, Hosts etc.) und deren zugewiesenem Gewicht.

  • Regelsatz bezeichnen die Art und Weise, wie Buckets ausgewählt werden.

17.1 OSD-Geräte Edit source

Zum Zuordnen von Platzierungsgruppen zu OSDs benötigt eine CRUSH-Zuordnung eine Liste von OSD-Geräten (den Namen des OSD Daemons). Die Liste der Geräte erscheint in der CRUSH-Zuordnung an erster Stelle.

#devices
device NUM osd.OSD_NAME class CLASS_NAME

Beispiel:

#devices
device 0 osd.0 class hdd
device 1 osd.1 class ssd
device 2 osd.2 class nvme
device 3 osd.3class ssd

In der Regel wird ein OSD-Daemon einer einzelnen Festplatte zugeordnet.

17.1.1 Geräteklassen Edit source

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 Edit source

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.

17.1.1.2 Geräteklassen Edit source

Für diese Situation bietet Ceph eine elegante Lösung: Jedem OSD wird eine Geräteklasse als Eigenschaft zugewiesen. Standardmäßig stellen die OSDs ihre jeweilige Geräteklasse automatisch auf „hdd“, „ssd“ oder „nvme“ ein, abhängig von den Hardware-Eigenschaften, die der Linux-Kernel bereitstellt. Diese Geräte werden in der Ausgabe des Kommandos ceph osd tree in einer neuen Spalte aufgeführt:

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

Wenn die automatische Erkennung der Geräteklasse fehlschlägt, da beispielsweise der Gerätetreiber die Daten zum Gerät nicht ordnungsgemäß über /sys/block bereitstellt, können Sie die Geräteklassen über die Kommandozeile anpassen:

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'

17.1.1.3 Festlegen von CRUSH-Platzierungsregeln Edit source

CRUSH-Regeln beschränken die Platzierung auf eine bestimmte Geräteklasse. Mit folgendem Kommando können Sie beispielsweise einen „schnell“ reproduzierten Pool erstellen, der die Daten ausschließlich auf SSD-Datenträger verteilt:

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

Beispiel:

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

Erstellen Sie einen Pool mit der Bezeichnung „fast_pool“ und weisen Sie ihn der Regel „fast“ zu:

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

Die Erstellung von Löschcode-Regeln läuft geringfügig anders ab. Zunächst erstellen Sie ein Löschcode-Profil mit einer Eigenschaft für die gewünschte Geräteklasse. Anschließend legen Sie den Pool mit Löschcodierung an:

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

Die Syntax wurde erweitert, sodass Sie die Geräteklasse auch manuell eingeben können, falls die CRUSH-Zuordnung manuell bearbeitet werden muss. Die obigen Kommandos erzeugen beispielsweise die folgende CRUSH-Regel:

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
}

Der wichtige Unterschied: Das Kommando „take“ umfasst hier das zusätzliche Suffix „class CLASS_NAME“.

17.1.1.4 Zusätzliche Kommandos Edit source

Mit folgendem Kommando rufen Sie eine Liste der Geräte in einer CRUSH-Zuordnung ab:

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

Mit folgendem Kommando rufen Sie eine Liste der vorhandenen CRUSH-Regeln ab:

cephuser@adm > ceph osd crush rule ls
replicated_rule
fast

Mit folgendem Kommando rufen Sie Details zur CRUSH-Regel „+++fast“ ab:

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"
						}
		]
}

Mit folgendem Kommando rufen Sie eine Liste der OSDs ab, die zur Klasse „ssd“ gehören:

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

17.1.1.5 Migration von einer Legacy-SSD-Regel zu Geräteklassen Edit source

In SUSE Enterprise Storage vor Version 5 mussten Sie die CRUSH-Zuordnung manuell bearbeiten und parallele Hierarchien für jeden einzelnen Gerätetyp (z. B. SSD) pflegen, damit Sie überhaupt Regeln für diese Regeln schreiben konnten. Seit SUSE Enterprise Storage 5 ist dies mit der Geräteklassenfunktion transparent möglich.

Mit dem Kommando crushtool wandeln Sie eine Legacy-Regel und -Hierarchie in die neuen klassenbasierten Regeln um. Für die Umwandlung stehen mehrere Möglichkeiten zur Auswahl:

crushtool --reclassify-root ROOT_NAME DEVICE_CLASS

Dieses Kommando erfasst alle Elemente in der Hierarchie unterhalb von ROOT_NAME und ersetzt alle Regeln, die mit

take ROOT_NAME

auf diesen Root verweisen, durch

take ROOT_NAME class DEVICE_CLASS

Die Buckets werden neu nummeriert, so dass die bisherigen IDs in den „Schattenbaum“ der jeweiligen Klasse übernommen werden. Somit werden keine Daten verschoben.

Beispiel 17.1: crushtool --reclassify-root

Betrachten Sie die folgende vorhandene Regel:

rule replicated_ruleset {
   id 0
   type replicated
   min_size 1
   max_size 10
   step take default
   step chooseleaf firstn 0 type rack
   step emit
}

Wenn Sie den Root „default“ als Klasse „hdd“ neu klassifizieren, lautet die Regel nunmehr

rule replicated_ruleset {
   id 0
   type replicated
   min_size 1
   max_size 10
   step take default class hdd
   step chooseleaf firstn 0 type rack
   step emit
}
crushtool --set-subtree-class BUCKET_NAME DEVICE_CLASS

Mit dieser Methode werden alle Geräte im Teilbaum mit dem Root BUCKET_NAME und der angegebenen Geräteklasse gekennzeichnet.

--set-subtree-class wird in der Regel gemeinsam mit der Option --reclassify-root herangezogen, damit alle Geräte im betreffenden Root mit der richtigen Klasse gekennzeichnet werden. Einige Geräte, denen bewusst eine andere Klasse zugewiesen wurde, sollen jedoch nicht neu gekennzeichnet werden. In diesen Fällen lassen Sie die Option --set-subtree-class weg. Beachten Sie, dass diese Neuzuordnung nicht völlig einwandfrei ist, da die bisherige Regel auf Geräte mehrerer Klassen verteilt ist, während die angepassten Regeln lediglich Geräten der angegebenen Geräteklasse zugeordnet werden.

crushtool --reclassify-bucket MATCH_PATTERN DEVICE_CLASS DEFAULT_PATTERN

Mit dieser Methode lässt sich eine parallele typenspezifische Hierarchie mit der normalen Hierarchie zusammenführen. Bei vielen Benutzern sehen die CRUSH-Zuordnungen beispielsweise so oder ähnlich aus:

Beispiel 17.2: crushtool --reclassify-bucket
host node1 {
   id -2           # do not change unnecessarily
   # weight 109.152
   alg straw
   hash 0  # rjenkins1
   item osd.0 weight 9.096
   item osd.1 weight 9.096
   item osd.2 weight 9.096
   item osd.3 weight 9.096
   item osd.4 weight 9.096
   item osd.5 weight 9.096
   [...]
}

host node1-ssd {
   id -10          # do not change unnecessarily
   # weight 2.000
   alg straw
   hash 0  # rjenkins1
   item osd.80 weight 2.000
   [...]
}

root default {
   id -1           # do not change unnecessarily
   alg straw
   hash 0  # rjenkins1
   item node1 weight 110.967
   [...]
}

root ssd {
   id -18          # do not change unnecessarily
   # weight 16.000
   alg straw
   hash 0  # rjenkins1
   item node1-ssd weight 2.000
   [...]
}

Mit dieser Funktion werden alle Buckets neu klassifiziert, die mit einem bestimmten Muster übereinstimmen. Dieses Muster lautet beispielsweise %suffix oder prefix%. Im obigen Beispiel würden Sie das Muster %-ssd heranziehen. Bei jedem passenden Bucket bezeichnet der verbleibende Teil des Namens, also der Teil im Platzhalter „%“, den Basis-Bucket. Alle Geräte im passenden Bucket werden mit der angegebenen Geräteklasse gekennzeichnet und dann in den Basis-Bucket verschoben. Wenn der Basis-Bucket noch nicht vorhanden ist („node12-ssd“ liegt beispielsweise vor, „node12“ dagegen nicht), wird er erstellt und unter dem angegebenen standardmäßigen übergeordneten Bucket verknüpft. Die bisherigen Bucket-IDs werden für die neuen Shadow-Buckets beibehalten, wodurch keine Daten verschoben werden müssen. Regeln mit take-Schritten, die auf die bisherigen Buckets verweisen, werden angepasst.

crushtool --reclassify-bucket BUCKET_NAME DEVICE_CLASS BASE_BUCKET

Mit der Option --reclassify-bucketohne Platzhalter können Sie einen einzelnen Bucket zuordnen. Im obigen Beispiel soll beispielsweise der Bucket „ssd“ dem Standard-Bucket zugeordnet werden.

Das Kommando, mit dem die Zuordnung mit den obigen Fragmenten endgültig konvertiert wird, lautet dann:

cephuser@adm > ceph osd getcrushmap -o original
cephuser@adm > crushtool -i original --reclassify \
  --set-subtree-class default hdd \
  --reclassify-root default hdd \
  --reclassify-bucket %-ssd ssd default \
  --reclassify-bucket ssd ssd default \
  -o adjusted

Mit der Option --compare können Sie prüfen, ob die Konvertierung fehlerfrei durchgeführt wurde. Hiermit wird eine große Anzahl von Eingaben in die CRUSH-Zuordnung getestet und es wird verglichen, ob wieder das gleiche Ergebnis erzielt wird. Diese Eingaben werden mit denselben Optionen gesteuert wie --test. Im obigen Beispiel lautet das Kommando dann:

cephuser@adm > crushtool -i original --compare adjusted
rule 0 had 0/10240 mismatched mappings (0)
rule 1 had 0/10240 mismatched mappings (0)
maps appear equivalent
Tipp
Tipp

Bei Abweichungen würde das Verhältnis der neu zugeordneten Eingaben in Klammern angegeben.

Wenn Sie mit der angepassten CRUSH-Zuordnung zufrieden sind, können Sie sie auf den Cluster anwenden:

cephuser@adm > ceph osd setcrushmap -i adjusted

17.1.1.6 Weitere Informationen Edit source

Weitere Informationen zu CRUSH-Zuordnungen finden Sie in Abschnitt 17.5, „Umgang mit der CRUSH-Zuordnung“.

Weitere Informationen zu Ceph Pools im Allgemeinen finden Sie in Kapitel 18, Verwalten von Speicher-Pools.

Weitere Informationen zu Pools mit Löschcodierung finden Sie in Kapitel 19, Erasure Coded Pools.

17.2 Buckets Edit source

CRUSH-Zuordnungen enthalten eine Liste von OSDs, die in einer Baumstruktur von Buckets angeordnet werden können, um die Geräte an physischen Standorten zu aggregieren. Die einzelnen OSDs stellen die Blätter am Baum dar.

0

osd

Ein spezifisches Gerät oder OSD (osd.1, osd.2 usw.).

1

Host

Der Name eines Hosts mit einem oder mehreren OSDs.

2

chassis

Kennung dafür, welches Chassis im Rack den Host enthält.

3

rack

Ein Computer-Rack. Der Standardwert ist unknownrack.

4

row

Eine Reihe in einer Serie von Racks.

5

pdu

Abkürzung für „Power Distribution Unit“ (Stromversorgungseinheit).

6

pod

Abkürzung für „Point of Delivery“ (Zustellort): in diesem Zusammenhang eine Gruppe von PDUs oder eine Gruppe von Rackreihen.

7

room

Ein Raum mit Rackreihen.

8

Rechenzentrum

Ein physisches Rechenzentrum mit einem oder mehreren Räumen.

9

region

Geografische Region der Welt (z. B. NAM, LAM, EMEA, APAC usw.)

10

root

Der Stammknoten des Baums der OSD-Buckets (normalerweise auf default festgelegt).

Tipp
Tipp

Sie können die vorhandenen Typen bearbeiten und eigene Bucket-Typen erstellen.

Die Bereitstellungswerkzeuge von Ceph generieren eine CRUSH-Zuordnung, die einen Bucket für jeden Host sowie den Pool „default“ enthält, was für den standardmäßigen rbd-Pool nützlich ist. Die restlichen Bucket-Typen dienen zum Speichern von Informationen zum physischen Standort von Knoten/Buckets. Dadurch wird die Cluster-Verwaltung erheblich erleichtert, wenn bei OSDs, Hosts oder Netzwerkhardware Störungen auftreten und der Administrator Zugriff auf die physische Hardware benötigt.

Ein Bucket umfasst einen Typ, einen eindeutigen Namen (Zeichenkette), eine eindeutige als negative Ganzzahl ausgedrückte ID, ein Gewicht relativ zur Gesamtkapazität/Capability seiner Elemente, den Bucket-Algorithmus (standardmäßig straw) sowie den Hash (standardmäßig 0, was dem CRUSH Hash rjenkins1 entspricht). Ein Bucket kann ein oder mehrere Elemente enthalten. Die Elemente bestehen möglicherweise aus anderen Buckets oder OSDs. Elemente können ein Gewicht aufweisen, das dem relativen Gewicht des Elements entspricht.

[bucket-type] [bucket-name] {
  id [a unique negative numeric ID]
  weight [the relative capacity/capability of the item(s)]
  alg [the bucket type: uniform | list | tree | straw2 | straw ]
  hash [the hash type: 0 by default]
  item [item-name] weight [weight]
}

Das folgende Beispiel veranschaulicht, wie Sie Buckets zum Aggregieren eines Pools und der physischen Standorte wie Rechenzentrum, Raum, Rack und Reihe verwenden.

host ceph-osd-server-1 {
        id -17
        alg straw2
        hash 0
        item osd.0 weight 0.546
        item osd.1 weight 0.546
}

row rack-1-row-1 {
        id -16
        alg straw2
        hash 0
        item ceph-osd-server-1 weight 2.00
}

rack rack-3 {
        id -15
        alg straw2
        hash 0
        item rack-3-row-1 weight 2.00
        item rack-3-row-2 weight 2.00
        item rack-3-row-3 weight 2.00
        item rack-3-row-4 weight 2.00
        item rack-3-row-5 weight 2.00
}

rack rack-2 {
        id -14
        alg straw2
        hash 0
        item rack-2-row-1 weight 2.00
        item rack-2-row-2 weight 2.00
        item rack-2-row-3 weight 2.00
        item rack-2-row-4 weight 2.00
        item rack-2-row-5 weight 2.00
}

rack rack-1 {
        id -13
        alg straw2
        hash 0
        item rack-1-row-1 weight 2.00
        item rack-1-row-2 weight 2.00
        item rack-1-row-3 weight 2.00
        item rack-1-row-4 weight 2.00
        item rack-1-row-5 weight 2.00
}

room server-room-1 {
        id -12
        alg straw2
        hash 0
        item rack-1 weight 10.00
        item rack-2 weight 10.00
        item rack-3 weight 10.00
}

datacenter dc-1 {
        id -11
        alg straw2
        hash 0
        item server-room-1 weight 30.00
        item server-room-2 weight 30.00
}

root data {
        id -10
        alg straw2
        hash 0
        item dc-1 weight 60.00
        item dc-2 weight 60.00
}

17.3 Regelsatz Edit source

CRUSH-Zuordnungen unterstützen das Konzept der „CRUSH-Regeln“. Dabei handelt es sich um die Regeln, die die Datenplatzierung für einen Pool bestimmen. Bei großen Clustern erstellen Sie wahrscheinlich viele Pools und jeder Pool verfügt über einen eigenen CRUSH-Regelsatz und Regeln. Die standardmäßige CRUSH-Zuordnung umfasst eine Regel für den Standard-Root. Wenn Sie weitere Roots und Regeln benötigen, erstellen Sie sie später. Ansonsten werden sie automatisch angelegt, sobald neue Pools eingerichtet werden.

Anmerkung
Anmerkung

In den meisten Fällen müssen Sie die Standardregeln nicht ändern. Beim Erstellen eines neuen Pools lautet der Standardregelsatz 0.

Eine Regel sieht folgendermaßen aus:

rule rulename {

        ruleset ruleset
        type type
        min_size min-size
        max_size max-size
        step step

}
ruleset

Eine Ganzzahl. Klassifiziert eine Regel als Teil einer Gruppe von Regeln. Wird dadurch aktiviert, dass der Regelsatz in einem Pool festgelegt wird. Diese Option muss aktiviert sein. Der Standardwert ist 0.

type

Eine Zeichenkette. Beschreibt eine Regel für einen „reproduzierten“ oder einen „Erasure“ Coded Pool. Diese Option muss aktiviert sein. Die Standardeinstellung ist replicated.

min_size

Eine Ganzzahl. CRUSH wählt diese Regel NICHT aus, wenn eine Poolgruppe weniger Reproduktionen erstellt als diese Zahl. Diese Option muss aktiviert sein. Die Standardeinstellung ist 2.

max_size

Eine Ganzzahl. CRUSH wählt diese Regel NICHT aus, wenn eine Poolgruppe mehr Reproduktionen erstellt als diese Zahl. Diese Option muss aktiviert sein. Die Standardeinstellung ist 10.

step take bucket

Nimmt einen Bucket, der durch einen Namen angegeben wird, und beginnt, den Baum nach unten zu durchlaufen. Diese Option muss aktiviert sein. Eine Erläuterung zum Durchlaufen des Baums finden Sie in Abschnitt 17.3.1, „Durchlaufen des Knoten-Baums“.

step targetmodenum type bucket-type

target ist entweder choose oder chooseleaf. Wenn der Wert auf choose festgelegt ist, wird eine Reihe von Buckets ausgewählt. chooseleaf wählt direkt die OSDs (Blatt-Knoten) aus dem Teilbaum der einzelnen Buckets in der Gruppe der Buckets aus.

mode ist entweder firstn oder indep. Siehe Abschnitt 17.3.2, „firstn und indep.

Wählt die Anzahl der Buckets des angegebenen Typs aus. Wenn N die Anzahl der verfügbaren Optionen ist und num > 0 && < N, wählen Sie genauso viele Buckets. num < 0 bedeutet N - num. Bei num == 0 wählen Sie N Buckets (alle verfügbar). Folgt auf step take oder step choose.

step emit

Gibt den aktuellen Wert aus und leert den Stack. Wird normalerweise am Ende einer Regel verwendet, kann jedoch auch zum Erstellen unterschiedlicher Bäume in derselben Regel verwendet werden. Folgt auf step choose.

17.3.1 Durchlaufen des Knoten-Baums Edit source

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.

Beispielbaum
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
}

17.3.2 firstn und indep Edit source

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.

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

17.4 Platzierungsgruppen Edit source

Ceph ordnet die Objekte bestimmten Platzierungsgruppen (PGs) zu. Die Platzierungsgruppen sind Shards oder Fragmente einer logischen Gruppe, mit der Objekte als Gruppe in OSDs platziert werden. Platzierungsgruppen verringern die Menge der Metadaten pro Objekt, wenn Ceph die Daten in OSDs speichert. Eine größere Anzahl von Platzierungsgruppen – beispielsweise 100 pro OSD – bewirkt einen besseren Ausgleich.

17.4.1 Verwenden von Platzierungsgruppen Edit source

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.

Platzierungsgruppen in einem Pool
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:

Platzierungsgruppen und OSDs
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.

17.4.2 Ermitteln des Werts für PG_NUM Edit source

Anmerkung
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 6.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:

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

Weniger als 5 OSDs:

Legen Sie PG_NUM auf 128 fest.

Zwischen 5 und 10 OSDs:

Legen Sie PG_NUM auf 512 fest.

Zwischen 10 und 50 OSDs:

Legen Sie PG_NUM auf 1.024 fest.

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.

17.4.2.1 Berechnen der Platzierungsgruppen für mehr als 50 OSDs Edit source

Wenn Sie weniger als 50 OSDs nutzen, beachten Sie die Vorauswahl unter Abschnitt 17.4.2, „Ermitteln des Werts für PG_NUM. Wenn Sie mehr als 50 OSDs nutzen, werden etwa 50–100 Platzierungsgruppen pro OSD empfohlen, sodass die Ressourcenauslastung, die Datenhaltbarkeit und die Verteilung ausgeglichen sind. Bei einem einzelnen Pool mit Objekten können Sie mit der folgenden Formel einen Referenzwert berechnen:

total PGs = (OSDs * 100) / POOL_SIZE

POOL_SIZE bezeichnet hierbei entweder die Anzahl der Reproduktionen bei reproduzierten Pools oder die Summe aus „k“+„m“ bei Pools mit Löschcodierung, die durch das Kommando ceph osd erasure-code-profile get zurückgegeben wird. Runden Sie das Ergebnis auf die nächste Zweierpotenz auf. Das Aufrunden wird empfohlen, damit der CRUSH-Algorithmus die Anzahl der Objekte gleichmäßig auf die Platzierungsgruppen verteilen kann.

Für einen Cluster mit 200 OSDs und einer Poolgröße von 3 Reproduktionen würden Sie die Anzahl der PGs beispielsweise wie folgt näherungsweise ermitteln:

          (200 * 100) / 3 = 6667

Die nächste Zweierpotenz ist 8.192.

Wenn Objekte in mehreren Daten-Pools gespeichert werden, müssen Sie die Anzahl der Platzierungsgruppen pro Pool in jedem Fall mit der Anzahl der Platzierungsgruppen pro OSD abgleichen. Dabei müssen Sie eine sinnvolle Gesamtanzahl der Platzierungsgruppen erreichen, die eine angemessen niedrige Varianz pro OSD gewährleistet, ohne die Systemressourcen überzustrapazieren oder den Peering-Prozess zu stark zu verlangsamen.

Ein Cluster mit 10 Pools mit je 512 Platzierungsgruppen auf 10 OSDs umfasst beispielsweise insgesamt 5.120 Platzierungsgruppen auf 10 OSDs, also 512 Platzierungsgruppen pro OSD. Eine solche Einrichtung verbraucht nicht allzu viele Ressourcen. Würden jedoch 1.000 Pools mit je 512 Platzierungsgruppen erstellt, müssten die OSDs je etwa 50.000 Platzierungsgruppen verarbeiten, was die Ressourcenauslastung und den Zeitaufwand für das Peering erheblich erhöhen würde.

17.4.3 Festlegen der Anzahl der Platzierungsgruppen Edit source

Anmerkung
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 6.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:

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

root # ceph osd pool set POOL_NAME pgp_num PGP_NUM

17.4.4 Feststellen der Anzahl der Platzierungsgruppen Edit source

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

root # ceph osd pool get POOL_NAME pg_num

17.4.5 Feststellen der PG-Statistiken für einen Cluster Edit source

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

root # ceph pg dump [--format FORMAT]

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

17.4.6 Feststellen von Statistiken für hängen gebliebene PGs Edit source

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

root # 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).

17.4.7 Suchen einer Platzierungsgruppenzuordnung Edit source

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

root # ceph pg map PG_ID

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

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

17.4.8 Abrufen einer Platzierungsgruppenstatistik Edit source

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

root # ceph pg PG_ID query

17.4.9 Scrubbing einer Platzierungsgruppe Edit source

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

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

17.4.10 Priorisierung des Abgleichs und der Wiederherstellung von Platzierungsgruppen Edit source

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:

root # ceph pg force-recovery PG_ID1 [PG_ID2 ... ]
root # 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:

root # ceph pg cancel-force-recovery PG_ID1 [PG_ID2 ... ]
root # 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.

17.4.11 Wiederherstellen verlorener Objekte Edit source

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

17.4.12 Aktivieren der PG-Autoskalierung Edit source

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:

off

Deaktiviert die Autoskalierung für diesen Pool. Es liegt im Ermessen des Administrators, eine geeignete PG-Nummer für jeden Pool zu wählen.

on

Aktiviert die automatische Anpassung der PG-Anzahl für den angegebenen Pool.

warn

Löst Zustandswarnungen aus, wenn die PG-Anzahl angepasst werden sollte.

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

17.5 Umgang mit der CRUSH-Zuordnung Edit source

In diesem Abschnitt werden grundlegende Methoden zum Umgang mit der CRUSH-Zuordnung vorgestellt, wie Bearbeiten einer CRUSH-Zuordnung, Ändern der CRUSH-Zuordnungs-Parameter und Hinzufügen/Verschieben/Entfernen eines OSD.

17.5.1 Bearbeiten einer CRUSH-Zuordnung Edit source

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

  1. Rufen Sie eine CRUSH-Zuordnung ab. Führen Sie folgendes Kommando aus, um die CRUSH-Zuordnung für Ihren Cluster abzurufen:

    cephuser@adm > ceph osd getcrushmap -o compiled-crushmap-filename

    Ceph gibt (-o) eine kompilierte CRUSH-Zuordnung an den angegebenen Dateinamen aus. Da die CRUSH-Zuordnung in kompilierter Form vorliegt, muss sie vor der Bearbeitung zunächst dekompiliert werden.

  2. Dekompilieren Sie eine CRUSH-Zuordnung. Führen Sie zum Dekompilieren einer CRUSH-Zuordnung folgendes Kommando aus:

    cephuser@adm > crushtool -d compiled-crushmap-filename \
     -o decompiled-crushmap-filename

    Ceph dekompiliert (-d) die kompilierte CRUSH-Zuordnung und gibt Sie (-o) an den angegebenen Dateinamen aus.

  3. Bearbeiten Sie mindestens einen der Geräte-, Buckets- und Regel-Parameter.

  4. Kompilieren Sie eine CRUSH-Zuordnung. Führen Sie zum Kompilieren einer CRUSH-Zuordnung folgendes Kommando aus:

    cephuser@adm > crushtool -c decompiled-crush-map-filename \
     -o compiled-crush-map-filename

    Ceph speichert eine kompilierte CRUSH-Zuordnung an den angegebenen Dateinamen.

  5. Legen Sie eine CRUSH-Zuordnung fest. Führen Sie folgendes Kommando aus, um die CRUSH-Zuordnung für Ihren Cluster festzulegen:

    cephuser@adm > ceph osd setcrushmap -i compiled-crushmap-filename

    Ceph gibt die CRUSH-Zuordnung des angegebenen Dateinamens als CRUSH-Zuordnung für den Cluster ein.

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

17.5.2 Hinzufügen oder Verschieben eines OSD Edit source

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

Eine Ganzzahl. Die numerische ID des OSD. Diese Option muss aktiviert sein.

Name

Eine Zeichenkette. Der vollständige Name des OSD. Diese Option muss aktiviert sein.

weight

Der Gleitkomma-Datentyp „double“. Das CRUSH-Gewicht für den OSD. Diese Option muss aktiviert sein.

root

Ein Schlüssel-Wert-Paar. Standardmäßig enthält die CRUSH-Hierarchie den Pool-Standardwert als Root. Diese Option muss aktiviert sein.

bucket-type

Schlüssel-Wert-Paare. Sie haben die Möglichkeit, den Standort des OSD in der CRUSH-Hierarchie anzugeben.

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

17.5.3 Unterschied zwischen ceph osd reweight und ceph osd crush reweight Edit source

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 Edit source

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

17.5.3.2 ceph osd crush reweight Edit source

Wert:

cephuser@adm > ceph osd crush reweight OSD_NAME NEW_WEIGHT

Mit ceph osd crush reweight wird das CRUSH-Gewicht des OSD festgelegt. Dieses Gewicht ist ein willkürlicher Wert (im Allgemeinen die Größe der Festplatte in TB) und steuert die Datenmenge, die das System dem OSD zuordnet.

17.5.4 Entfernen eines OSD Edit source

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

17.5.5 Hinzufügen eines Buckets Edit source

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

17.5.6 Verschieben eines Buckets Edit source

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

17.5.7 Entfernen eines Buckets Edit source

Mit folgendem Kommando entfernen Sie einen Bucket:

cephuser@adm > ceph osd crush remove BUCKET_NAME
Anmerkung
Anmerkung: Nur leere Buckets

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

17.6 Scrubbing von Platzierungsgruppen Edit source

Ceph legt nicht nur mehrere Kopien der Objekte an, sondern schützt die Datenintegrität durch Scrubbing der Platzierungsgruppen (für weitere Informationen zu Platzierungsgruppen, siehe das Abschnitt 1.3.2, „Platzierungsgruppen“). Ceph Scrubbing ist analog zur Ausführung von fsck auf Objektspeicherebene zu verstehen. Ceph generiert für jede Placement Group einen Katalog aller Objekte und vergleicht jedes primäre Objekt und dessen Reproduktionen, um sicherzustellen, dass keine Objekte fehlen oder falsch abgeglichen wurden. Beim täglichen Light Scrubbing werden die Objektgröße und Attribute geprüft. Beim wöchentlichen Deep Scrubbing werden die Daten gelesen und die Datenintegrität wird anhand von Prüfsummen sichergestellt.

Scrubbing ist wichtig zur Sicherung der Datenintegrität, kann jedoch die Leistung beeinträchtigen. Passen Sie die folgenden Einstellungen an, um mehr oder weniger Scrubbing-Vorgänge festzulegen:

osd max scrubs

Die maximale Anzahl der gleichzeitig ausgeführten Scrubbing-Operationen für ein Ceph OSD. Der Standardwert ist 1.

osd scrub begin hour, osd scrub end hour

Die Stunden am Tag (0 bis 24), die ein Zeitfenster für das Scrubbing definieren. Beginnt standardmäßig bei 0 und endet bei 24.

Wichtig
Wichtig

Wenn das Scrubbing-Intervall der Platzierungsgruppe die Einstellung osd scrub max interval überschreitet, wird das Scrubbing ungeachtet des für ein Scrubbing definierten Zeitfensters durchgeführt.

osd scrub during recovery

Lässt Scrubbing-Vorgänge bei der Wiederherstellung zu. Wird diese Option auf „false“ festgelegt, wird die Planung neuer Scrubbing-Vorgänge während einer aktiven Wiederherstellung deaktiviert. Bereits laufende Scrubbing-Vorgänge werden fortgesetzt. Diese Option ist nützlich, um die Last ausgelasteter Cluster zu reduzieren. Die Standardeinstellung ist „true“.

osd scrub thread timeout

Der maximale Zeitraum in Sekunden vor der Zeitüberschreitung eines Scrubbing Threads. Der Standardwert ist 60.

osd scrub finalize thread timeout

Der maximale Zeitraum in Sekunden vor der Zeitüberschreitung eines Scrubbing Finalize Threads. Der Standardwert ist 60*10.

osd scrub load threshold

Die normalisierte Maximallast. Ceph führt kein Scrubbing durch, wenn die Systemlast (definiert durch das Verhältnis von getloadavg() / Anzahl von online cpus) höher ist als dieser Wert. Der Standardwert ist 0.5.

osd scrub min interval

Das Mindestintervall in Sekunden für Scrubbing-Vorgänge am Ceph OSD, wenn die Ceph-Cluster-Last gering ist. Der Standardwert ist 60*60*24 (einmal täglich).

osd scrub max interval

Das maximale Intervall in Sekunden für Scrubbing-Vorgänge am Ceph OSD ungeachtet der Cluster-Last. Der Standardwert ist 7*60*60*24 (einmal pro Woche).

osd scrub chunk min

Die maximale Anzahl der Objektspeicher-Datenblöcke für einen einzelnen Scrubbing-Vorgang. Ceph blockiert Schreibvorgänge an einen einzelnen Datenblock während eines Scrubbing-Vorgangs. Der Standardwert ist 5.

osd scrub chunk max

Die Mindestanzahl der Objektspeicher-Datenblöcke für einen einzelnen Scrubbing-Vorgang. Der Standardwert ist 25.

osd scrub sleep

Ruhezeit vor dem Scrubbing der nächsten Gruppe von Datenblöcken. Durch Erhöhen dieses Werts wird der gesamte Scrubbing-Vorgang verlangsamt. Die Client-Vorgänge insgesamt werden dadurch weniger beeinträchtigt. Der Standardwert ist 0.

osd deep scrub interval

Das Intervall für ein Deep Scrubbing (alle Daten werden vollständig gelesen). Die Option osd scrub load threshold hat keinen Einfluss auf diese Einstellung. Der Standardwert ist 60*60*24*7 (einmal pro Woche).

osd scrub interval randomize ratio

Fügen Sie beim Planen des nächsten Scrubbing-Auftrags für eine Placement Group eine zufällige Verzögerung zum Wert osd scrub min interval hinzu. Die Verzögerung ist ein Zufallswert kleiner als das Ergebnis aus osd scrub min interval * osd scrub interval randomized ratio. Daher werden mit dem Standardwert die Scrubbing-Vorgänge praktisch zufällig auf das zulässige Zeitfenster von [1, 1,5] * osd scrub min interval verteilt. Der Standardwert ist 0.5.

osd deep scrub stride

Lesegröße für ein Deep Scrubbing. Der Standardwert ist 524288 (512 kB).

Diese Seite drucken