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

6 Verwaltung gespeicherter Daten

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 Map zum pseudozufälligen Speichern und Abrufen von Daten in OSDs gleichmäßiger Datenverteilung im Cluster.

CRUSH Maps 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 Map 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 Map 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 Map 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 Map kann Ihnen auch dabei helfen, die physischen Standorte zu finden, an denen Ceph redundante Kopien der Daten speichert, wenn sich die Placement Groups, die mit einem fehlerhaften Host verknüpft sind, in einem eingeschränkt leistungsfähigen Zustand befinden.

Eine CRUSH Map setzt sich aus drei Hauptabschnitten zusammen.

  • Geräte sind beliebige Objektspeichergeräte oder genauer gesagt die Festplatte zu einem ceph-osd-Daemon.

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

  • Regelsätze bezeichnen die Art und Weise wie Buckets ausgewählt werden.

6.1 Geräte

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

#devices
device num osd.name

Beispiel:

#devices
device 0 osd.0
device 1 osd.1
device 2 osd.2
device 3 osd.3

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

6.2 Buckets

CRUSH Maps enthalten eine Liste von OSDs, die in "Buckets" angeordnet werden können, um die Geräte an physischen Standorten zu aggregieren.

0

OSD

Ein OSD-Daemon (osd.1, osd.2 usw.).

1

Host

Ein Hostname, der einen oder mehrere OSDs enthält.

2

Gehäuse

Gehäuse, aus denen sich das Rack zusammensetzt.

3

Rack

Ein Computer-Rack. Der Standardwert ist unknownrack.

4

Reihe

Eine Reihe in einer Serie von Racks.

5

Pdu

Stromverteilungseinheit.

6

Pod

7

Raum

Ein Raum mit Racks und Reihen von Hosts.

8

Rechenzentrum

Ein physisches Rechenzentrum mit Räumen.

9

Region

10

Root

Tipp
Tipp

Sie können diese Typen entfernen und eigene Bucket-Typen erstellen.

Die Bereitstellungswerkzeuge von Ceph generieren eine CRUSH Map, die einen Bucket für jeden Host und einen Pool namens "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 Nodes/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 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 | 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 straw
        hash 0
        item osd.0 weight 1.00
        item osd.1 weight 1.00
}

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

rack rack-3 {
        id -15
        alg straw
        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 straw
        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 straw
        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 straw
        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 straw
        hash 0
        item server-room-1 weight 30.00
        item server-room-2 weight 30.00
}

pool data {
        id -10
        alg straw
        hash 0
        item dc-1 weight 60.00
        item dc-2 weight 60.00
}

6.3 Regelsätze

CRUSH Maps 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 Map hat eine Regel für jeden Pool und ein bestimmter Regelsatz ist jedem einzelnen der Standard-Pools zugewiesen.

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.

Wichtig
Wichtig

Sie müssen die Regelsatznummer kontinuierlich ab dem Standardwert 0 erhöhen, weil andernfalls der entsprechende Monitor möglicherweise abstürzt.

type

Eine Zeichenkette. Bezeichnet eine Regel für eine Festplatte (reproduziert) oder ein RAID. Diese Option muss aktiviert sein. Die Standardeinstellung ist replicated.

min_size

Eine Ganzzahl. CRUSH wählt diese Regel NICHT aus, wenn eine Placement Group 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 Placement Group mehr Reproduktionen erstellt als diese Zahl. Diese Option muss aktiviert sein. Die Standardeinstellung ist 10.

step take bucket

Nimmt einen Bucket-Namen und beginnt, den Baum nach unten zu durchlaufen. Diese Option muss aktiviert sein. Eine Erläuterung zum Durchlaufen des Baums finden Sie in Abschnitt 6.3.1, „Durchlaufen des Node-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-Nodes) aus dem Teilbaum der einzelnen Buckets in der Gruppe der Buckets aus.

mode ist entweder firstn oder indep. Weitere Informationen hierzu finden Sie in Abschnitt 6.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.

Wichtig
Wichtig

Legen Sie zum Aktivieren einer oder mehrerer Regeln mit einer gemeinsamen Regelsatznummer für einen Pool die Regelsatznummer auf den Pool fest.

6.3.1 Durchlaufen des Node-Baums

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

Die Regeln in der CRUSH Map definieren, wie OSDs aus diesem Baum ausgewählt werden. Eine Regel beginnt mit einem Node 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 Node-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 Nodes (oder Zweigen) aus dem vorher ausgewählten oberen Node 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 6.1, „Beispielbaum“ zeigt ein Beispiel, wie step zum Durchlaufen eines Baums verwendet wird. In den folgenden Regeldefinitionen entsprechen die orangefarbenen Pfeile und Zahlen example1a und example1b und die blauen Pfeile entsprechen example2.

Beispielbaum
Abbildung 6.1: 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
}

6.3.2 firstn und indep

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

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

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

Anmerkung
Anmerkung: Erasure Pools

Vergewissern Sie sich, dass eine Regel mit indep für jeden Erasure Coded Pool festgelegt ist.

Methoden für den Austausch von Nodes
Abbildung 6.2: Methoden für den Austausch von Nodes

6.4 Umgang mit der CRUSH Map

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

6.4.1 Bearbeiten einer CRUSH Map

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

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

    root # ceph osd getcrushmap -o compiled-crushmap-filename

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

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

    cephadm > crushtool -d compiled-crushmap-filename \
     -o decompiled-crushmap-filename

    Ceph dekompiliert (-d) die kompilierte CRUSH Map 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 Map. Führen Sie zum Kompilieren einer CRUSH Map folgendes Kommando aus:

    cephadm > crushtool -c decompiled-crush-map-filename \
     -o compiled-crush-map-filename

    Ceph speichert eine kompilierte CRUSH Map an den angegebenen Dateinamen.

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

    root # ceph osd setcrushmap -i compiled-crushmap-filename

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

6.4.2 Hinzufügen/Verschieben eines OSD

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

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

pool

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.

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

6.4.3 Anpassen des CRUSH-Gewichts eines OSD

Führen Sie zum Anpassen des CRUSH-Gewichts eines OSD in der CRUSH Map eines aktiven Clusters folgendes Kommando aus:

root # ceph osd crush reweight name weight
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.

6.4.4 Entfernen eines OSD

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

root # ceph osd crush remove name
name

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

6.4.5 Verschieben eines Buckets

Führen Sie zum Verschieben eines Buckets an einen anderen Standort oder eine andere Position in der CRUSH Map-Hierarchie folgendes Kommando aus:

root # ceph osd crush move bucket-name bucket-type=bucket-name, ...
bucket-name

Eine Zeichenkette. Der Name des Buckets, der verschoben oder neu positioniert werden soll. Diese Option muss aktiviert sein.

bucket-type

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

6.5 Scrubbing

Zusätzlich zum Erstellen mehrerer Kopien eines Objekts stellt Ceph die Datenintegrität durch ein Scrubbing der Placement Groups sicher. 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-Vorgänge für 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 Placement Group die Einstellung osd scrub max interval überschreitet, wird das Scrubbing ungeachtet des für ein Scrubbing definiertes 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 lautet 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. 7*60*60*24 (einmal pro Woche).

osd scrub chunk min

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

osd scrub chunk max

Die maximale Anzahl 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).

6.6 Mischung aus SSDs und HDDs im selben Node

Es ist eventuell vorteilhaft, einen Ceph Cluster so zu konfigurieren, dass jeder Node eine Mischung aus SSDs und HDDs umfasst. Dabei sollte ein Speicher-Pool auf den schnellen SSDs und ein Speicher-Pool auf den langsameren HDDs vorhanden sein. Dazu muss die CRUSH Map bearbeitet werden.

Die standardmäßige CRUSH Map weist eine einfache Hierarchie auf, in der im Standard-Root die Hosts enthalten sind und an den Hosts die OSDs. Beispiel:

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

Hier wird noch kein Unterschied zwischen den Festplattentypen gemacht. Wir müssen eine zweite Hierarchie in der CRUSH Map erstellen, um die OSDs in SSDs und HDDs aufzuteilen:

root # ceph osd crush add-bucket ssd root

Nach Erstellung des neuen Root für SSDs müssen wir Hosts hinzufügen: Dies bedeutet, dass neue Host-Einträge erstellt werden. Dazu werden fingierte Hostnamen verwendet, weil derselbe Hostname in einer CRUSH Map nicht mehr als einmal erscheinen darf. Diese fingierten Hostnamen müssen nicht im DNS auflösbar sein. Für CRUSH sind die Hostnamen nicht von Belang. Sie müssen nur die richtigen Hierarchien bilden. Allerdings muss doch etwas geändert werden, damit fingierte Hostnamen unterstützt werden. Sie müssen nämlich

osd crush update on start = false

in der Datei /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf festlegen und dann die DeepSea-Phase 3 durchführen, um die Veränderung zu verteilen (weitere Informationen finden Sie in Abschnitt 1.11, „Benutzerdefinierte Datei ceph.conf):

root@master # salt-run state.orch ceph.stage.3

Andernfalls werden die verschobenen OSDs später zu ihrem ursprünglichen Standort am Standard-Root zurückgesetzt und der Cluster verhält sich nicht wie erwartet.

Fügen Sie die neuen fingierten Hosts zum SSD-Root hinzu, nachdem Sie diese Einstellung geändert haben:

root # ceph osd crush add-bucket node1-ssd host
root # ceph osd crush move node1-ssd root=ssd
root # ceph osd crush add-bucket node2-ssd host
root # ceph osd crush move node2-ssd root=ssd
root # ceph osd crush add-bucket node3-ssd host
root # ceph osd crush move node3-ssd root=ssd

Verschieben Sie schließlich für jeden SSD-OSD den OSD zum SSD-Root. In diesem Beispiel nehmen wir an, dass osd.0, osd.1 und osd.2 physisch auf SSDs gehostet werden:

root # ceph osd crush add osd.0 1 root=ssd
root # ceph osd crush set osd.0 1 root=ssd host=node1-ssd
root # ceph osd crush add osd.1 1 root=ssd
root # ceph osd crush set osd.1 1 root=ssd host=node2-ssd
root # ceph osd crush add osd.2 1 root=ssd
root # ceph osd crush set osd.2 1 root=ssd host=node3-ssd

Die CRUSH-Hierarchie sollte nun wie folgt aussehen:

root # ceph osd tree
ID WEIGHT  TYPE NAME                   UP/DOWN REWEIGHT PRIMARY-AFFINITY
-5 3.00000 root ssd
-6 1.00000     host node1-ssd
 0 1.00000         osd.0                    up  1.00000          1.00000
-7 1.00000     host node2-ssd
 1 1.00000         osd.1                    up  1.00000          1.00000
-8 1.00000     host node3-ssd
 2 1.00000         osd.2                    up  1.00000          1.00000
-1 0.11096 root default
-2 0.03699     host node1
 3 0.01849         osd.3                    up  1.00000          1.00000
 6 0.01849         osd.6                    up  1.00000          1.00000
-3 0.03699     host node2
 4 0.01849         osd.4                    up  1.00000          1.00000
 7 0.01849         osd.7                    up  1.00000          1.00000
-4 0.03699     host node3
 5 0.01849         osd.5                    up  1.00000          1.00000
 8 0.01849         osd.8                    up  1.00000          1.00000

Erstellen Sie nun eine CRUSH-Regel, die den SSD-Root adressiert:

root # ceph osd crush rule create-simple ssd_replicated_ruleset ssd host

Die ursprüngliche Standardeinstellung replicated_ruleset (mit ID 0) adressiert die HDDs. Die neue Einstellung ssd_replicated_ruleset (mit ID 1) adressiert die SSDs.

Bestehende Pools verwenden weiterhin die HDDs, da diese in der Standardhierarchie in der CRUSH Map vorhanden sind. Ein neuer Pool kann so erstellt werden, dass er nur SSDs verwendet:

root # ceph osd pool create ssd-pool 64 64
root # ceph osd pool set ssd-pool crush_rule ssd_replicated_ruleset
Diese Seite drucken