Gilt für SUSE Enterprise Storage 7

12 Ermitteln des Clusterzustands #

Die Überwachung eines aktiven Clusters ist mit dem Werkzeug ceph möglich. Zur Ermittlung des Cluster-Zustands wird in der Regel der Status der Ceph OSDs, Ceph Monitors, Platzierungsgruppen und Metadatenserver geprüft.

Tipp: Interaktiver Modus

Geben Sie zur Ausführung des Werkzeugs ceph im interaktiven Modus ceph in der Kommandozeile ohne Argumente ein. Der interaktive Modus ist praktischer, wenn Sie vorhaben, mehrere ceph-Kommandos in einer Zeile einzugeben. Beispiel:

cephuser@adm > ceph
ceph> health
ceph> status
ceph> quorum_status
ceph> mon stat

12.1 Überprüfen des Status eines Clusters #

Mit ceph -s oder ceph -s rufen Sie den aktuellen Zustand des Clusters ab:

cephuser@adm > ceph -s
cluster:
    id:     b4b30c6e-9681-11ea-ac39-525400d7702d
    health: HEALTH_OK

  services:
    mon: 5 daemons, quorum ses-min1,ses-master,ses-min2,ses-min4,ses-min3 (age 2m)
    mgr: ses-min1.gpijpm(active, since 3d), standbys: ses-min2.oopvyh
    mds: my_cephfs:1 {0=my_cephfs.ses-min1.oterul=up:active}
    osd: 3 osds: 3 up (since 3d), 3 in (since 11d)
    rgw: 2 daemons active (myrealm.myzone.ses-min1.kwwazo, myrealm.myzone.ses-min2.jngabw)

  task status:
    scrub status:
        mds.my_cephfs.ses-min1.oterul: idle

  data:
    pools:   7 pools, 169 pgs
    objects: 250 objects, 10 KiB
    usage:   3.1 GiB used, 27 GiB / 30 GiB avail
    pgs:     169 active+clean

Die Ausgabe bietet die folgenden Informationen:

Cluster-ID
Cluster-Zustand
Die Monitor-Zuordnungsepoche und den Status des Monitor-Quorums
Die OSD-Zuordnungsepoche und den Status der OSDs
Status der Ceph Managers
Status der Object Gateways
Die Version der Placement-Group-Zuordnung
Die Anzahl der Placement Groups und Pools
Die nominelle Menge der gespeicherten Daten und die Anzahl der gespeicherten Objekte
Die Gesamtmenge der gespeicherten Daten

Tipp: Wie Ceph die Datennutzung berechnet

Der Wert used bezeichnet den tatsächlich belegten Basisspeicherplatz. Der Wert xxx GB / xxx GB bezeichnet den verfügbaren Speicherplatz (der kleinere Wert) der gesamten Speicherkapazität des Clusters. Die nominelle Menge spiegelt die Menge der gespeicherten Daten wider, bevor diese reproduziert oder geklont werden oder ein Snapshot davon erstellt wird. Daher übersteigt die Menge der tatsächlich gespeicherten Daten normalerweise die nominelle gespeicherte Menge, weil Ceph Reproduktionen der Daten erstellt und die Speicherkapazität möglicherweise auch zum Klonen und für Snapshots verwendet.

Mit den folgenden Kommandos werden die Statusinformationen ebenfalls sofort angezeigt:

ceph pg stat
ceph osd pool stats
ceph df
ceph df detail

Sollen die Angaben in Echtzeit aktualisiert werden, geben Sie diese Kommandos (auch ceph ‑s) als Argument für das Kommando watch an:

root # watch -n 10 'ceph -s'

Drücken Sie Strg–C, wenn Sie den Vorgang nicht länger beobachten möchten.

12.2 Überprüfen der Clusterintegrität #

Überprüfen Sie den Zustand Ihres Clusters nach dessen Start und bevor Sie mit dem Lesen und/oder Schreiben von Daten beginnen:

cephuser@adm > ceph health
HEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \
node-1,node-2,node-3

Tipp

Wenn Sie nicht standardmäßige Standorte für Ihre Konfiguration oder Ihren Schlüsselbund angegeben haben, können Sie diese angeben mit:

cephuser@adm > ceph -c /path/to/conf -k /path/to/keyring health

Der Ceph-Cluster gibt einen der folgenden Zustandscodes zurück:

OSD_DOWN

Einer oder mehrere OSDs sind als inaktiv gekennzeichnet. Der OSD Daemon wurde möglicherweise gestoppt oder Peer-OSDs erreichen den OSD möglicherweise nicht über das Netzwerk. Üblicherweise handelt es sich dabei um einen gestoppten oder abgestürzten Daemon, einen inaktiven Host oder einen Netzwerkausfall.

Verifizieren Sie, dass sich der Host in einem ordnungsgemäßen Zustand befindet, der Daemon gestartet ist und das Netzwerk funktioniert. Falls der Daemon abgestürzt ist, enthält die Protokolldatei des Daemon (/var/log/ceph/ceph-osd.*) möglicherweise Informationen zur Fehlersuche.

OSD_CRUSH-Typ_DOWN, beispielsweise OSD_HOST_DOWN

Alle OSDs in einem bestimmten CRUSH-Teilbaum sind als inaktiv gekennzeichnet, wie zum Beispiel alle OSDs auf einem Host.

OSD_ORPHAN

In der CRUSH Map-Hierarchie wird auf einen OSD verwiesen, er ist jedoch nicht vorhanden. Der OSD kann aus der CRUSH-Hierarchie entfernt werden mit:

cephuser@adm > ceph osd crush rm osd.ID

OSD_OUT_OF_ORDER_FULL

Die Auslastungsgrenzwerte für backfillfull (Standardwert 0,90), nearfull (Standardwert 0,85), full (Standardwert 0,95) und/oder failsafe_full sind nicht aufsteigend. Insbesondere erwarten wir backfillfull < nearfull, nearfull < full und full < failsafe_full.

Mit folgendem Kommando lesen Sie die aktuellen Werte aus:

cephuser@adm > ceph health detail
HEALTH_ERR 1 full osd(s); 1 backfillfull osd(s); 1 nearfull osd(s)
osd.3 is full at 97%
osd.4 is backfill full at 91%
osd.2 is near full at 87%

Die Grenzwerte können mit folgenden Kommandos angepasst werden:

cephuser@adm > ceph osd set-backfillfull-ratio ratio
cephuser@adm > ceph osd set-nearfull-ratio ratio
cephuser@adm > ceph osd set-full-ratio ratio

OSD_FULL

Einer oder mehrere OSDs haben den Grenzwert full überschritten, was verhindert, dass der Cluster Schreibvorgänge ausführt. Die Auslastung pro Pool wird überprüft mit:

cephuser@adm > ceph df

Der zurzeit definierte Grad full wird angezeigt mit:

cephuser@adm > ceph osd dump | grep full_ratio

Eine kurzfristige Behelfslösung zum Wiederherstellen der Schreibverfügbarkeit ist die geringfügige Erhöhung des Grenzwerts:

cephuser@adm > ceph osd set-full-ratio ratio

Fügen Sie neuen Speicherplatz zum Cluster hinzu, indem Sie weitere OSDs bereitstellen, oder löschen Sie bestehende Daten, um Speicherplatz freizugeben.

OSD_BACKFILLFULL

Einer oder mehrere OSDs haben den Grenzwert backfillfull überschritten, wodurch verhindert wird, dass auf diesem Gerät ein Datenausgleich stattfindet. Hierbei handelt es sich um eine frühzeitige Warnung, dass der Ausgleich möglicherweise nicht durchgeführt werden kann und der Cluster fast voll ist. Die Auslastung pro Pool wird überprüft mit:

cephuser@adm > ceph df

OSD_NEARFULL

Einer oder mehrere OSDs haben den Grenzwert nearfull überschritten. Hierbei handelt es sich um eine frühzeitige Warnung, dass der Cluster fast voll ist. Die Auslastung pro Pool wird überprüft mit:

cephuser@adm > ceph df

OSDMAP_FLAGS

Eine oder mehrere interessante Cluster-Flags wurden gesetzt. Mit Ausnahme von full können diese Flags festgelegt oder gelöscht werden mit:

cephuser@adm > ceph osd set flag
cephuser@adm > ceph osd unset flag

Die folgenden Flags sind verfügbar:

Vollständig: Der Cluster wird als voll gekennzeichnet und kann keine Schreibvorgänge mehr bedienen.
pauserd, pausewr: Lese- und Schreibvorgänge werden ausgesetzt.
noup: OSDs dürfen nicht gestartet werden.
nodown: OSD-Fehlerberichte werden ignoriert, sodass die Monitors keine OSDs mit down kennzeichnen.
noin: OSDs, die vorher mit out gekennzeichnet wurden, werden beim Starten nicht wieder mit in gekennzeichnet.
noout: Down OSDs werden nach dem konfigurierten Intervall nicht automatisch mit out gekennzeichnet.
nobackfill, norecover, norebalance: Wiederherstellung oder Datenausgleich ist angehalten.
noscrub, nodeep_scrub: Scrubbing (Informationen hierzu finden Sie in Abschnitt 17.6, „Scrubbing von Platzierungsgruppen“) ist deaktiviert.
notieragent: Die Cache-Tiering-Aktivität ist angehalten.

OSD_FLAGS

Für eine oder mehrere OSDs wurde eine Interessensflagge pro OSD gesetzt. Die folgenden Flags sind verfügbar:

noup: Der OSD darf nicht starten.
nodown: Fehlerberichte für diesen OSD werden ignoriert.
noin: Wenn dieser OSD vorher automatisch nach einem Fehler mit out markiert wurde, wird er beim Start nicht mit in gekennzeichnet.
noout: Wenn dieser OSD inaktiv ist, wird er nach dem konfigurierten Intervall nicht automatisch mit out gekennzeichnet.

Pro-OSD-Flags werden gesetzt oder gelöscht mit:

cephuser@adm > ceph osd add-flag osd-ID
cephuser@adm > ceph osd rm-flag osd-ID

OLD_CRUSH_TUNABLES

Die CRUSH Map verwendet sehr alte Einstellungen und sollte aktualisiert werden. Die ältesten Tunables, die verwendet werden können (d. h. die älteste Client-Version, die eine Verbindung zum Cluster herstellen kann), ohne diese Zustandswarnung auszulösen, werden durch die Konfigurationsoption mon_crush_min_required_version festgelegt.

OLD_CRUSH_STRAW_CALC_VERSION

Die CRUSH Map verwendet eine ältere, nicht optimale Methode zur Berechnung von Gewichtungszwischenwerten für Straw Buckets. Die CRUSH Map sollte aktualisiert werden, um die neuere Methode zu verwenden (straw_calc_version=1).

CACHE_POOL_NO_HIT_SET

Einer oder mehrere Cache Pools wurden nicht mit einem Treffersatz zum Verfolgen der Auslastung konfiguriert. Dadurch wird verhindert, dass der Tiering-Agent unbenutzte Objekte erkennt, die aus dem Cache entfernt werden müssen. Treffersätze werden im Cache Pool konfiguriert mit:

cephuser@adm > ceph osd pool set poolname hit_set_type type
cephuser@adm > ceph osd pool set poolname hit_set_period period-in-seconds
cephuser@adm > ceph osd pool set poolname hit_set_count number-of-hitsets
cephuser@adm > ceph osd pool set poolname hit_set_fpp target-false-positive-rate

OSD_NO_SORTBITWISE

Es werden keine OSDs vor Luminous Version 12 ausgeführt, doch das Flag sortbitwise wurde nicht gesetzt. Das Flag sortbitwise muss gesetzt werden, damit OSDs ab Luminous Version 12 starten:

cephuser@adm > ceph osd set sortbitwise

POOL_FULL

Einer oder mehrere Pools haben das Kontingent erreicht und lassen keine weiteren Schreibvorgänge zu. Pool-Kontingente und Auslastungswerte werden mit folgendem Kommando festgelegt:

cephuser@adm > ceph df detail

Legen Sie entweder das Pool-Kontingent mit

cephuser@adm > ceph osd pool set-quota poolname max_objects num-objects
cephuser@adm > ceph osd pool set-quota poolname max_bytes num-bytes

fest oder löschen Sie einige vorhandene Daten, um die Auslastung zu verringern.

PG_AVAILABILITY

Die Datenverfügbarkeit ist reduziert. Dies bedeutet, dass der Cluster potenzielle Lese- oder Schreibanforderungen für einige Daten im Cluster nicht bedienen kann. Dies ist insbesondere dann der Fall, wenn sich mindestens eine PG in einem Zustand befindet, der die Ausführung von E/A-Anforderungen nicht zulässt. Problematische PG-Zustände sind peering, stale, incomplete und das Fehlen von active (wenn diese Zustände nicht schnell gelöscht werden). Detaillierte Informationen dazu, welche PGs betroffen sind, erhalten Sie durch Ausführen von:

cephuser@adm > ceph health detail

In den meisten Fällen besteht die Ursache darin, dass einer oder mehrere OSDs aktuell inaktiv sind. Der Zustand bestimmter problematischer PGs kann abgefragt werden mit:

cephuser@adm > ceph tell pgid query

PG_DEGRADED

Die Datenredundanz ist für einige Daten reduziert. Dies bedeutet, dass der Cluster nicht über die gewünschte Anzahl der Reproduktionen für alle Daten (für reproduzierte Pools) oder Erasure Code-Fragmente (für Erasure Coded Pools) verfügt. Dies ist insbesondere dann der Fall, wenn bei einer oder mehreren PGs das Flag degraded oder undersized gesetzt wurde (es sind nicht genügend Instanzen dieser Placement Group im Cluster vorhanden) oder wenn einige Zeit das Flag clean nicht gesetzt war. Detaillierte Informationen dazu, welche PGs betroffen sind, erhalten Sie durch Ausführen von:

cephuser@adm > ceph health detail

In den meisten Fällen besteht die Ursache darin, dass einer oder mehrere OSDs aktuell inaktiv sind. Der Zustand bestimmter problematischer PGs kann abgefragt werden mit:

cephuser@adm > ceph tell pgid query

PG_DEGRADED_FULL

Die Datenredundanz ist möglicherweise für einige Daten reduziert oder in Gefahr, weil freier Speicherplatz im Cluster fehlt. Dies ist insbesondere dann der Fall, wenn für eine oder mehrere PGs das Flag backfill_toofull oder recovery_toofull gesetzt wurde. Dies bedeutet, dass der Cluster keine Daten migrieren oder wiederherstellen kann, weil einer oder mehrere OSDs den Grenzwert backfillfull überschritten haben.

PG_DAMAGED

Beim Daten-Scrubbing (weitere Informationen hierzu finden Sie in Abschnitt 17.6, „Scrubbing von Platzierungsgruppen“) wurden einige Probleme bezüglich der Datenkonsistenz im Cluster erkannt. Dies ist insbesondere dann der Fall, wenn für eine oder mehrere PGs das Flag inconsistent oder snaptrim_error gesetzt wurde. Dadurch wird angegeben, dass bei einem früheren Scrubbing-Vorgang ein Problem gefunden wurde. Möglicherweise wurde auch das Flag repair gesetzt, was bedeutet, dass eine derartige Inkonsistenz gerade repariert wird.

OSD_SCRUB_ERRORS

Bei kürzlich durchgeführten OSD-Scrubbing-Vorgängen wurden Inkonsistenzen erkannt.

CACHE_POOL_NEAR_FULL

Ein Cache-Schicht-Pool ist fast voll. In diesem Kontext wird „full“ durch die Eigenschaften target_max_bytes und target_max_objects des Caches Pools bestimmt. Wenn der Pool den Grenzwert erreicht, werden Schreibanforderungen an den Pool möglicherweise blockiert und Daten aus dem Cache entfernt und gelöscht. Dieser Zustand führt normalerweise zu sehr hohen Latenzen und schlechter Leistung. Der Grenzwert für die Größe des Pools kann angepasst werden mit:

cephuser@adm > ceph osd pool set cache-pool-name target_max_bytes bytes
cephuser@adm > ceph osd pool set cache-pool-name target_max_objects objects

Die normale Aktivität zum Leeren des Caches wird möglicherweise auch gedrosselt durch die reduzierte Verfügbarkeit oder Leistung der Basisschicht oder durch die Cluster-Last insgesamt.

TOO_FEW_PGS

Die Anzahl der verwendeten PGs liegt unterhalb des konfigurierbaren Grenzwerts der mon_pg_warn_min_per_osd-PGs pro OSD. Dies führt eventuell dazu, dass die Daten nicht optimal auf die OSDs im Cluster verteilt und ausgeglichen werden und die Leistung insgesamt verschlechtert wird.

TOO_MANY_PGS

Die Anzahl der verwendeten PGs liegt oberhalb des konfigurierbaren Grenzwerts der mon_pg_warn_min_per_osd-PGs pro OSD. Dies führt möglicherweise zu höherer Arbeitsspeicherauslastung für OSD-Daemons, langsamerem Peering nach Änderungen des Cluster-Zustands (beispielsweise OSD-Neustarts, Hinzufügen oder Entfernen) sowie höherer Last für Ceph Managers und Ceph Monitors.

Der Wert pg_num für bestehende Pools kann nicht reduziert werden, der Wert pgp_num jedoch schon. Dadurch werden einige PGs effizient auf denselben Gruppen von OSDs angeordnet, wodurch einige der oben beschriebenen negativen Auswirkungen abgeschwächt werden. Der pgp_num-Wert kann angepasst werden mit:

cephuser@adm > ceph osd pool set pool pgp_num value

SMALLER_PGP_NUM

Bei einem oder mehreren Pools ist der pgp_num-Wert kleiner als der pg_num-Wert. Dies ist normalerweise ein Anzeichen dafür, dass die PG-Anzahl erhöht wurde, ohne auch das Platzierungsverhalten zu erhöhen. Dieses Problem wird normalerweise dadurch behoben, dass pgp_num mit pg_num abgeglichen wird, was die Datenmigration auslöst. Verwenden Sie hierzu:

cephuser@adm > ceph osd pool set pool pgp_num pg_num_value

MANY_OBJECTS_PER_PG

Bei mindestens einem Pool ist die durchschnittliche Anzahl von Objekten pro PG erheblich höher als der Durchschnitt im Cluster insgesamt. Der spezifische Grenzwert wird gesteuert durch den Konfigurationswertmon_pg_warn_max_object_skew. Dies ist normalerweise ein Anzeichen dafür, dass die Pools mit den meisten Daten im Cluster zu wenige PGs enthalten und/oder dass andere Pools mit weniger Daten zu viele PGs enthalten. Um die Zustandswarnung abzustellen, kann der Grenzwert durch Anpassen der Konfigurationsoption mon_pg_warn_max_object_skew an den Monitors erhöht werden.

POOL_APP_NOT_ENABLED¶

Es ist zwar ein Pool mit einem oder mehreren Objekten vorhanden, wurde jedoch nicht für die Verwendung durch eine bestimmte Anwendung gekennzeichnet. Heben Sie diese Warnmeldung auf, indem Sie den Pool für die Verwendung durch eine Anwendung kennzeichnen. Beispiel, wenn der Pool von RBD verwendet wird:

cephuser@adm > rbd pool init pool_name

Wenn der Pool durch eine benutzerdefinierte Anwendung „foo“ verwendet wird, können Sie ihn auch mit dem Kommando der untersten Ebene kennzeichnen:

cephuser@adm > ceph osd pool application enable foo

POOL_FULL

Einer oder mehrere Pools haben das Kontingent erreicht (oder erreichen es bald). Der Grenzwert zum Auslösen dieser Fehlerbedingung wird durch die Konfigurationsoption mon_pool_quota_crit_threshold gesteuert. Pool-Kontingente werden nach oben oder unten angepasst (oder entfernt) mit:

cephuser@adm > ceph osd pool set-quota pool max_bytes bytes
cephuser@adm > ceph osd pool set-quota pool max_objects objects

Durch Festlegen des Kontingentwerts auf 0 wird das Kontingent deaktiviert.

POOL_NEAR_FULL

Einer oder mehrere Pools haben bald das Kontingent erreicht. Der Grenzwert zum Auslösen dieser Fehlerbedingung wird durch die Konfigurationsoption mon_pool_quota_warn_threshold gesteuert. Pool-Kontingente werden nach oben oder unten angepasst (oder entfernt) mit:

cephuser@adm > ceph osd osd pool set-quota pool max_bytes bytes
cephuser@adm > ceph osd osd pool set-quota pool max_objects objects

Durch Festlegen des Kontingentwerts auf 0 wird das Kontingent deaktiviert.

OBJECT_MISPLACED

Mindestens ein Objekt im Cluster ist nicht auf dem Knoten gespeichert, auf dem es laut Cluster gespeichert werden soll. Dies ist ein Anzeichen dafür, dass die Datenmigration aufgrund einer kürzlich vorgenommenen Änderung am Cluster noch nicht abgeschlossen ist. Falsch platzierte Daten stellen an sich keine Gefahr dar. Die Datenkonsistenz ist niemals in Gefahr und alte Kopien von Objekten werden niemals entfernt, bevor die gewünschte Anzahl an neuen Kopien (an den gewünschten Speicherorten) vorhanden ist.

OBJECT_UNFOUND

Ein oder mehrere Objekte im Cluster werden nicht gefunden. Dies ist insbesondere dann der Fall, wenn die OSDs wissen, dass eine neue oder aktualisierte Kopie eines Objekts vorhanden sein sollte, jedoch keine Kopie dieser Version des Objekts auf OSDs gefunden wurden, die zurzeit aktiv sind. Lese- oder Schreibanforderungen an die „unfound“-Objekte werden blockiert. Im Idealfall kann das inaktive OSD, auf dem sich das aktuelle Exemplar des nicht gefundenen Objekts befindet, wieder aktiviert werden. Dafür in Frage kommende OSDs können anhand des Peering-Zustands für die PGs identifiziert werden, die für das nicht gefundene Objekt zuständig sind:

cephuser@adm > ceph tell pgid query

REQUEST_SLOW

Die Verarbeitung einer oder mehrerer OSD-Anforderungen dauert sehr lange. Dies ist möglicherweise ein Anzeichen für eine extreme Last, ein langsames Speichergerät oder einen Softwarefehler. Mit folgendem Kommando, das auf dem OSD-Host ausgeführt wird, fragen Sie die Anforderungswarteschlange auf den in Frage kommenden OSDs ab:

cephuser@adm > ceph daemon osd.id ops

Sie sehen eine Zusammenfassung der langsamsten kürzlich vorgenommenen Anforderungen:

cephuser@adm > ceph daemon osd.id dump_historic_ops

Sie finden den Standort eines OSDs mit:

cephuser@adm > ceph osd find osd.id

REQUEST_STUCK

Mindestens eine OSD-Anforderung wurde relativ lange Zeit blockiert, z. B. 4.096 Sekunden. Dies ist ein Anzeichen dafür, dass sich entweder der Cluster für einen längeren Zeitraum in einem fehlerhaften Zustand befindet (beispielsweise wenn nicht genügend OSDs ausgeführt werden oder inaktive PGs vorliegen) oder wenn interne Probleme am OSD aufgetreten sind.

PG_NOT_SCRUBBED

Es wurde länger kein Scrubbing bei mindestens einer PG durchgeführt (weitere Informationen hierzu finden Sie in Abschnitt 17.6, „Scrubbing von Platzierungsgruppen“). Bei PGs wird normalerweise alle mon_scrub_interval Sekunden ein Scrubbing durchgeführt und diese Warnmeldung wird ausgelöst, wenn diese mon_warn_not_scrubbed-Intervalle ohne Scrubbing abgelaufen sind. Bei PGs wird kein Scrubbing durchgeführt, wenn sie nicht als intakt („clean“) gekennzeichnet sind. Dies kann vorkommen, wenn sie falsch platziert wurden oder eingeschränkt leistungsfähig sind (weitere Informationen hierzu finden Sie oben unter PG_AVAILABILITY und PG_DEGRADED). Ein Scrubbing einer intakten PG wird manuell initiiert mit:

cephuser@adm > ceph pg scrub pgid

PG_NOT_DEEP_SCRUBBED

Bei einer oder mehreren PGs wurden länger kein Deep Scrubbing durchgeführt (weitere Informationen hierzu finden Sie in Abschnitt 17.6, „Scrubbing von Platzierungsgruppen“). Bei PGs wird normalerweise alle osd_deep_mon_scrub_interval Sekunden ein Scrubbing durchgeführt und diese Warnmeldung wird ausgelöst, wenn dieser mon_warn_not_deep_scrubbed-Zeitraum ohne Scrubbing abgelaufen ist. Bei PGs wird kein (Deep) Scrubbing durchgeführt, wenn sie nicht als intakt („clean“) gekennzeichnet sind. Dies kann vorkommen, wenn sie falsch platziert wurden oder eingeschränkt leistungsfähig sind (weitere Informationen hierzu finden Sie oben unter PG_AVAILABILITY und PG_DEGRADED). Ein Scrubbing einer intakten PG wird manuell initiiert mit:

cephuser@adm > ceph pg deep-scrub pgid

Tipp

Wenn Sie nicht standardmäßige Standorte für Ihre Konfiguration oder Ihren Schlüsselbund angegeben haben, können Sie diese angeben mit:

root # ceph -c /path/to/conf -k /path/to/keyring health

12.3 Überprüfen der Nutzungsstatistik eines Clusters #

Mit dem Kommando ceph df prüfen Sie die Datenauslastung und Datenverteilung auf die Pools in einem Cluster. Mit ceph df detail erhalten Sie weitere Details.

cephuser@adm > ceph df
--- RAW STORAGE ---
CLASS  SIZE    AVAIL   USED     RAW USED  %RAW USED
hdd    30 GiB  27 GiB  121 MiB   3.1 GiB      10.40
TOTAL  30 GiB  27 GiB  121 MiB   3.1 GiB      10.40

--- POOLS ---
POOL                   ID  STORED   OBJECTS  USED     %USED  MAX AVAIL
device_health_metrics   1      0 B        0      0 B      0    8.5 GiB
cephfs.my_cephfs.meta   2  1.0 MiB       22  4.5 MiB   0.02    8.5 GiB
cephfs.my_cephfs.data   3      0 B        0      0 B      0    8.5 GiB
.rgw.root               4  1.9 KiB       13  2.2 MiB      0    8.5 GiB
myzone.rgw.log          5  3.4 KiB      207    6 MiB   0.02    8.5 GiB
myzone.rgw.control      6      0 B        8      0 B      0    8.5 GiB
myzone.rgw.meta         7      0 B        0      0 B      0    8.5 GiB

Der Abschnitt RAW STORAGE der Ausgabe gibt einen Überblick über den Speicherplatz, den Ihr Cluster für die Daten nutzt.

CLASS: Die Speicherklasse des Geräts. Weitere detaillierte Informationen zu Geräteklassen finden Sie in Abschnitt 17.1.1, „Geräteklassen“.
SIZE: Die gesamte Speicherkapazität des Clusters.
AVAIL: Der verfügbare freie Speicherplatz im Cluster.
USED: Der Speicherplatz (über alle OSDs akkumuliert), der ausschließlich für Datenobjekte auf dem Blockgerät zugewiesen ist.
RAW USED: Summe des belegten Speicherplatzes („USED“) und des Speicherplatzes auf dem Blockgerät, der für Ceph-Zwecke zugewiesen/reserviert ist, z. B. der BlueFS-Bereich für BlueStore.
% RAW USED: Der Prozentsatz des genutzten Basisspeicherplatzes. Verwenden Sie diese Zahl in Verbindung mit full ratio und near full ratio, um sicherzustellen, dass die Kapazität des Clusters nicht voll ausgelastet wird. Weitere Informationen finden Sie in Abschnitt 12.8, „Speicherkapazität“.
Anmerkung: Füllstand des Clusters
Wenn sich der Rohspeicherfüllstand dem Wert 100 % nähert, müssen Sie neuen Speicher in den Cluster aufnehmen. Eine höhere Auslastung führt möglicherweise zu einzelnen vollen OSDs und Problemen mit dem Cluster-Zustand.
Listen Sie mit dem Kommando ceph osd df tree den Füllstand aller OSDs auf.

Im Abschnitt POOLS der Ausgabe finden Sie eine Liste der Pools und die nominelle Auslastung der einzelnen Pools. Die Ausgabe in diesem Abschnitt umfasst keine Reproduktionen, Klone oder Snapshots. Beispiel: Wenn Sie ein Objekt mit 1 MB Daten speichern, beträgt die nominelle Auslastung 1 MB. Die tatsächliche Auslastung beträgt jedoch möglicherweise 2 MB oder mehr, je nach Anzahl der Reproduktionen, Klone und Snapshots.

POOL: Der Name des Pools.
ID: Die Pool-ID.
STORED: Die vom Benutzer gespeicherte Datenmenge.
OBJECTS: Die nominelle Anzahl der pro Pool gespeicherten Objekte.
USED: Der Speicherplatz (in kB), der von allen OSD-Knoten ausschließlich für Daten zugewiesen ist.
%USED: Der nominelle Prozentsatz des genutzten Speichers pro Pool.
MAX AVAIL: Der maximal verfügbare Speicherplatz im jeweiligen Pool.

Anmerkung

Die Zahlen im Abschnitt POOLS sind nominell. Sie sind nicht inklusive der Anzahl der Reproduktionen, Snapshots oder Klone zu verstehen. Folglich entspricht die Summe der Zahlen unter USED und %USED nicht den Zahlen unter RAW USED und %RAW USED im Abschnitt RAW STORAGE der Ausgabe.

12.4 Überprüfen des OSD-Status #

Mit folgenden Kommandos prüfen Sie die OSDs, um sicherzustellen, dass sie aktiv sind:

cephuser@adm > ceph osd stat

oder

cephuser@adm > ceph osd dump

OSDs lassen sich auch entsprechend ihrer Position in der CRUSH-Map anzeigen.

Mit ceph osd tree werden ein CRUSH-Baum mit einem Host und dessen OSDs, der Status der Aktivität und deren Gewicht ausgegeben:

   cephuser@adm > ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME              STATUS  REWEIGHT  PRI-AFF
-1      3  0.02939  root default
-3      3  0.00980    rack mainrack
-2      3  0.00980            host osd-host
0       1  0.00980                    osd.0   up   1.00000   1.00000
1       1  0.00980                    osd.1   up   1.00000   1.00000
2       1  0.00980                    osd.2   up   1.00000   1.00000

12.5 Suchen nach vollen OSDs #

Ceph verhindert, dass Sie an einen vollen OSD schreiben, damit Sie keine Daten verlieren. In einem betriebsbereiten Cluster sollten Sie eine Warnmeldung erhalten, wenn der Cluster annähernd voll ist. Der Wert für mon osd full ratio beträgt standardmäßig 0,95 bzw. 95 % der Kapazität. Wenn dieser Wert erreicht ist, werden die Clients davon abgehalten, Daten zu schreiben. Der Wert mon osd nearfull ratio beträgt standardmäßig 0,85 bzw. 85 % der Kapazität. Wenn dieser Wert erreicht ist, wird eine Zustandswarnung generiert.

Volle OSD-Knoten werden durch ceph health gemeldet:

cephuser@adm > ceph health
  HEALTH_WARN 1 nearfull osds
  osd.2 is near full at 85%

oder

cephuser@adm > ceph health
  HEALTH_ERR 1 nearfull osds, 1 full osds
  osd.2 is near full at 85%
  osd.3 is full at 97%

Am besten fügen Sie bei einem vollen Cluster neue OSD-Hosts/-Datenträger hinzu. Dadurch kann der Cluster Daten auf dem neu verfügbaren Speicherplatz verteilen.

Tipp: Verhindern voller OSDs

Wenn ein OSD voll wird, also 100 % der Festplattenkapazität nutzt, stürzt er normalerweise schnell und ohne Warnmeldung ab. Nachfolgend sehen Sie einige Tipps, die Sie beim Verwalten von OSD-Knoten beachten sollten.

Der Festplattenspeicherplatz der einzelnen OSDs (normalerweise eingehängt unter/var/lib/ceph/osd/osd-{1,2..}) muss jeweils auf eine dedizierte zugrundeliegende Festplatte oder Partition gestellt werden.
Überprüfen Sie die Ceph-Konfigurationsdateien und stellen Sie sicher, dass Ceph die Protokolldatei nicht auf den Festplatten/Partitionen speichert, die explizit für die OSDs vorgesehen sind.
Vergewissern Sie sich, dass kein anderer Prozess auf die Festplatten/Partitionen schreibt, die explizit für die OSDs vorgesehen sind.

12.6 Prüfen des Monitorstatus #

Nachdem Sie den Cluster gestartet haben und bevor die ersten Daten gelesen und/oder geschrieben werden, prüfen Sie die Kontingentstatus der Ceph Monitors. Wenn der Cluster bereits Anforderungen verarbeitet, prüfen Sie den Status der Ceph Monitors regelmäßig, ob sie tatsächlich ausgeführt werden.

Führen Sie zum Anzeigen der Monitor-Zuordnung Folgendes aus:

cephuser@adm > ceph mon stat

oder

cephuser@adm > ceph mon dump

Führen Sie zum Prüfen des Quorum-Status für den Monitor-Cluster Folgendes aus:

cephuser@adm > ceph quorum_status

Ceph gibt den Quorum-Status zurück. Beispielsweise gibt ein Ceph-Cluster, der aus drei Monitors besteht, möglicherweise Folgendes zurück:

{ "election_epoch": 10,
  "quorum": [
        0,
        1,
        2],
  "monmap": { "epoch": 1,
      "fsid": "444b489c-4f16-4b75-83f0-cb8097468898",
      "modified": "2011-12-12 13:28:27.505520",
      "created": "2011-12-12 13:28:27.505520",
      "mons": [
            { "rank": 0,
              "name": "a",
              "addr": "192.168.1.10:6789\/0"},
            { "rank": 1,
              "name": "b",
              "addr": "192.168.1.11:6789\/0"},
            { "rank": 2,
              "name": "c",
              "addr": "192.168.1.12:6789\/0"}
           ]
    }
}

12.7 Überprüfen des Zustands von Platzierungsgruppen #

Placement Groups ordnen Objekte zu OSDs zu. Bei der Überwachung Ihrer Placement Groups sollten diese active (aktiv) und clean (intakt) sein. Ausführliche Informationen finden Sie in Abschnitt 12.9, „Überwachen der OSDs und Platzierungsgruppen“.

12.8 Speicherkapazität #

Wenn sich ein Ceph-Speicher-Cluster seiner maximalen Kapazität annähert, unterbindet Ceph aus Sicherheitsgründen weitere Schreib- oder Lesevorgänge auf Ceph OSDs, damit kein Datenverlust eintritt. Es wird daher nicht empfohlen, die Quote eines Produktions-Clusters voll auszuschöpfen, da damit die Hochverfügbarkeit nicht mehr gewährleistet ist. Die standardmäßige „full“-Quote ist auf 0,95 eingestellt, also auf 95 % der Kapazität. Für einen Test-Cluster mit nur wenigen OSDs ist dies eine äußerst aggressive Einstellung.

Tipp: Erhöhen der Speicherkapazität

Achten Sie bei der Überwachung des Clusters auf Warnmeldungen zur nearfull-Quote. Dies bedeutet, dass ein Ausfall eines (oder mehrerer) OSDs zu einer Serviceunterbrechung führen würde. Ziehen Sie in Erwägung, weitere OSDs einzufügen und damit die Speicherkapazität zu erhöhen.

In einem gängigen Szenario für Test-Cluster entfernt ein Systemadministrator ein Ceph OSD aus dem Ceph-Speicher-Cluster und beobachtet dann den Neuausgleich des Clusters. Anschließend wird ein weiterer Ceph OSD entfernt usw., bis der Cluster schließlich die „full“-Quote erreicht und zum Stillstand kommt. Selbst bei einem Test-Cluster wird eine gewisse Kapazitätsplanung empfohlen. Durch die Planung können Sie einschätzen, wie viel Ersatzkapazität Sie benötigen, damit die Hochverfügbarkeit aufrechterhalten werden kann. Im Idealfall sollten Sie eine ganze Reihe von Ceph OSD-Ausfällen einplanen, bei der Cluster wieder den Status active + clean erreichen kann, ohne die betreffenden Ceph OSDs austauschen zu müssen. Sie können einen Cluster im Status active + degraded ausführen, doch unter normalen Betriebsbedingungen ist dies nicht ideal.

Das nachfolgende Diagramm zeigt einen vereinfachten Ceph-Speicher-Cluster mit 33 Ceph Knoten und je einem Ceph OSD pro Host, die jeweils Lese- und Schreibvorgänge auf einem 3-TB-Laufwerk ausführen. Dieser Beispiel-Cluster besitzt eine maximale Istkapazität von 99 TB. Die Option mon osd full ratio ist auf 0,95 eingestellt. Sobald der Speicherplatz im Cluster unter 5 TB der Restkapazität fällt, werden Lese- und Schreibvorgänge der Clients unterbunden. Die Betriebskapazität des Speicher-Clusters liegt also bei 95 TB, nicht bei 99 TB.

Abbildung 12.1: Ceph-Cluster #

In einem solchen Cluster ist ein Ausfall von einem oder zwei OSDs durchaus normal. In einem weniger häufigen, jedoch denkbaren Szenario fällt der Router oder die Netzversorgung eines Racks aus, sodass mehrere OSDs gleichzeitig ausfallen (z. B. OSDs 7–12). In einem solchen Szenario muss der Cluster dennoch weiterhin betriebsbereit bleiben und den Status active + clean erreichen – selbst wenn dafür einige Hosts mit zusätzlichen OSDs in kürzester Zeit eingefügt werden müssen. Wenn die Kapazitätsauslastung zu hoch ist, verlieren Sie unter Umständen keine Daten. Doch beim Beheben eines Ausfalls in einer Fehlerdomäne ist die Datenverfügbarkeit dennoch beeinträchtigt, wenn die Kapazitätsauslastung des Clusters die für Code übersteigt. Aus diesem Grund wird zumindest eine grobe Kapazitätsplanung empfohlen.

Ermitteln Sie zwei Zahlen für Ihren Cluster:

die Anzahl der OSDs,
die Gesamtkapazität des Clusters.

Wenn Sie die Gesamtkapazität des Clusters durch die Anzahl der OSDs im Cluster dividieren, erhalten Sie die Durchschnittskapazität eines OSDs im Cluster. Multiplizieren Sie diese Zahl ggf. mit der Anzahl der OSDs, die laut Ihren Erwartungen im Normalbetrieb gleichzeitig ausfallen könnten (relativ kleine Zahl). Multiplizieren Sie schließlich die Kapazität des Clusters mit der „full“-Quote. Damit erhalten Sie die maximale Betriebskapazität. Subtrahieren Sie dann die Datenmenge der OSDs, die vermutlich ausfallen werden, und Sie erhalten eine angemessene „full“-Quote. Wenn Sie den obigen Vorgang mit einer größeren Anzahl an OSD-Ausfällen (einem OSD-Rack) wiederholen, erhalten Sie eine angemessene Zahl für die „near full“-Quote.

Die folgenden Einstellungen gelten nur bei der Cluster-Erstellung und werden dann in der OSD-Karte gespeichert:

[global]
 mon osd full ratio = .80
 mon osd backfillfull ratio = .75
 mon osd nearfull ratio = .70

Tipp

Diese Einstellungen gelten nur bei der Cluster-Erstellung. Später müssen sie mit den Kommandos ceph osd set-nearfull-ratio und ceph osd set-full-ratioin der OSD-Karte geändert werden.

mon osd full ratio: Prozentsatz des belegten Datenträgerspeichers, bevor ein OSD als full gilt. Der Standardwert lautet 0,95.
mon osd backfillfull ratio: Prozentsatz des belegten Datenträgerspeichers, bevor ein OSD als zu full für einen Abgleich gilt. Der Standardwert lautet 0,90.
mon osd nearfull ratio: Prozentsatz des belegten Datenträgerspeichers, bevor ein OSD als nearfull gilt. Der Standardwert lautet 0,85.

Tipp: Prüfen des OSD-Gewichts

Wenn einige OSDs nearfull sind, andere aber noch reichlich Kapazität besitzen, liegt eventuell ein Problem mit dem CRUSH-Gewicht für die nearfull-OSDs vor.

12.9 Überwachen der OSDs und Platzierungsgruppen #

Voraussetzung für Hochverfügbarkeit und hohe Zuverlässigkeit ist eine fehlertolerante Bearbeitung von Hardware- und Softwareproblemen. Ceph enthält keinen Single-Point-of-Failure und kann Anforderungen nach Daten in einem eingeschränkt leistungsfähigen Modus („degraded“) verarbeiten. Die Datenplatzierung bei Ceph umfasst eine Dereferenzierungsschicht, mit der gewährleistet wird, dass die Daten nicht direkt an bestimmte OSD-Adressen binden. Bei der Suche nach Systemfehlern bedeutet dies, dass die richtige Platzierungsgruppe und die zugrunde liegenden OSDs als Problemursache ermittelt werden müssen.

Tipp: Zugriff im Fehlerfall

Bei einem Fehler in einem Teil des Clusters können Sie unter Umständen nicht auf ein bestimmtes Objekt zugreifen. Dies bedeutet nicht, dass Sie nicht auf andere Objekte zugreifen können. Wenn ein Fehler auftritt, befolgen Sie die Anweisungen für die Überwachung Ihrer OSDs und Platzierungsgruppen. Nehmen Sie dann die Fehlerbehebung vor.

Ceph repariert sich im Allgemeinen selbst. Bleiben Probleme jedoch längere Zeit bestehen, trägt die Überwachung der OSDs und Platzierungsgruppen dazu bei, das Problem zu erkennen.

12.9.1 Überwachen der OSDs #

Ein OSD befindet sich entweder im Cluster (Status „in“) oder außerhalb des Clusters („out“). Gleichzeitig ist er entweder betriebsbereit und aktiv („up“) oder nicht betriebsbereit und inaktiv („down“). Wenn ein OSD „up“ ist, befindet er sich entweder im Cluster (Sie können Daten lesen und schreiben) oder außerhalb des Clusters. Wenn er sich bis vor Kurzem im Cluster befand und dann aus dem Cluster heraus verschoben wurde, migriert Ceph die Platzierungsgruppen zu anderen OSDs. Befindet sich ein OSD außerhalb des Clusters, weist CRUSH diesem OSD keine Platzierungsgruppen zu. Wenn ein OSD „down“ ist, sollte er auch „out“ sein.

Anmerkung: Fehlerhafter Zustand

Ist ein OSD „down“ und „in“, liegt ein Problem vor und der Cluster ist nicht in einem einwandfreien Zustand.

Wenn Sie ein Kommando wie ceph health, ceph -s oder ceph -w ausführen, meldet der Cluster nicht immer HEALTH OK. Im Hinblick auf OSDs ist unter den folgenden Umständen zu erwarten, dass der Cluster nicht die Meldung HEALTH OK zurückgibt:

Sie haben den Cluster noch nicht gestartet (er kann nicht antworten).
Sie haben den Cluster gestartet oder neu gestartet. Er ist jedoch noch nicht betriebsbereit, da die Platzierungsgruppen noch erstellt werden und die OSDs gerade den Peering-Prozess durchlaufen.
Sie haben ein OSD hinzugefügt oder entfernt.
Sie haben die Clusterzuordnung geändert.

Bei der Überwachung der OSDs ist in jedem Fall darauf zu achten, dass alle OSDs im Cluster betriebsbereit und aktiv sind, wenn der Cluster selbst betriebsbereit und aktiv ist. Mit folgendem Kommando prüfen Sie, ob alle OSDs aktiv sind:

root # ceph osd stat
x osds: y up, z in; epoch: eNNNN

Das Ergebnis umfasst die Gesamtanzahl der OSDs (x), die Anzahl der OSDs mit dem Status „up“ (y), die Anzahl der OSDs mit dem Status „in“ (z) sowie die Zuordnungsepoche (eNNNN). Wenn die Anzahl der „in“-OSDs höher ist als die Anzahl der „up“-OSDs, ermitteln Sie die nicht aktiven ceph-osd-Daemons mit folgendem Kommando:

root # ceph osd tree
#ID CLASS WEIGHT  TYPE NAME             STATUS REWEIGHT PRI-AFF
-1       2.00000 pool openstack
-3       2.00000 rack dell-2950-rack-A
-2       2.00000 host dell-2950-A1
0   ssd 1.00000      osd.0                up  1.00000 1.00000
1   ssd 1.00000      osd.1              down  1.00000 1.00000

Wenn beispielsweise ein OSD mit ID 1 inaktiv ist, starten Sie es mit:

cephuser@osd > sudo systemctl start ceph-CLUSTER_ID@osd.0.service

Weitere Informationen zu Problemen im Zusammenhang mit OSDs, die angehalten wurden oder sich nicht neu starten lassen, finden Sie im Section 4.3, “OSDs not running”.

12.9.2 Zuweisen von Platzierungsgruppen #

Beim Zuweisen von Platzierungsgruppen zu den OSDs prüft CRUSH die Anzahl der Reproduktionen für den Pool und weist die Platzierungsgruppe den OSDs so zu, dass jede Reproduktion dieser Platzierungsgruppe einem anderen OSD zugeordnet wird. Wenn der Pool beispielsweise drei Reproduktionen einer Platzierungsgruppe benötigt, weist CRUSH die Reproduktionen beispielsweise osd.1, osd.2 und osd.3 zu. CRUSH strebt dabei eine pseudozufällige Platzierung an, bei der die in der CRUSH-Zuordnung festgelegten Fehlerdomänen berücksichtigt werden, sodass Platzierungsgruppen nur in seltenen Fällen den jeweils nächstgelegenen OSDs in einem großen Cluster zugewiesen werden. Der OSD-Satz, in dem sich die Reproduktion einer bestimmten Platzierungsgruppe befinden soll, wird als „acting“-Satz bezeichnet. In einigen Fällen ist ein OSD im „acting“-Satz nicht betriebsbereit oder kann anderweitig keine Anforderungen nach Objekten in der Platzierungsgruppe verarbeiten. In diesen Situationen liegt eines der folgenden Szenarien vor:

Sie haben ein OSD hinzugefügt oder entfernt. CRUSH hat die Platzierungsgruppe dann anderen OSDs zugewiesen und damit die Zusammensetzung des agierenden Satzes verändert, sodass die Migration der Daten im Rahmen eines „backfill“-Prozesses ausgelöst wurde.
Ein OSD war „down“, wurde neu gestartet und wird nunmehr wiederhergestellt.
Ein OSD im „acting“-Satz ist „down“ oder kann keine Anforderungen verarbeiten und ein anderer OSD hat vorübergehend dessen Aufgaben übernommen.
Ceph verarbeitet eine Client-Anforderung mit dem „up“-Satz, also dem Satz der OSDs, die die Anforderungen tatsächlich verarbeiten. In den meisten Fällen sind der „up“-Satz und der „acting“-Satz praktisch identisch. Ist dies nicht der Fall, kann dies darauf hinweisen, dass Ceph gerade Daten migriert, ein OSD wiederhergestellt wird oder ein Problem vorliegt (in diesen Szenarien gibt Ceph in der Regel den Status HEALTH WARN mit der Meldung „stuck stale“ zurück).

Mit folgendem Kommando rufen Sie eine Liste der Platzierungsgruppen ab:

cephuser@adm > ceph pg dump

Mit folgendem Kommando stellen Sie fest, welche OSDs sich im „acting“-Satz oder im „up“-Satz einer bestimmten Platzierungsgruppe befinden:

cephuser@adm > ceph pg map PG_NUM
osdmap eNNN pg RAW_PG_NUM (PG_NUM) -> up [0,1,2] acting [0,1,2]

Das Ergebnis umfasst die osdmap-Epoche (eNNN), die Nummer der Platzierungsgruppe (PG_NUM), die OSDs im „up“-Satz („up“) sowie die OSDs im „acting“-Satz („acting“):

Tipp: Hinweis auf Clusterprobleme

Wenn der „up“-Satz und der „acting“-Satz nicht übereinstimmen, kann dies darauf hinweisen, dass der Cluster sich gerade ausgleicht oder dass ein potenzielles Problem mit dem Cluster vorliegt.

12.9.3 Peering #

Bevor Sie Daten in eine Platzierungsgruppe schreiben können, muss sie den Status active und auch den Status clean aufweisen. Damit Ceph den aktuellen Status einer Fertigungsgruppe feststellen kann, führt der primäre OSD der Platzierungsgruppe (der erste OSD im „acting“-Satz) ein Peering mit dem sekundären und dem tertiären OSD durch, sodass sie sich über den aktuellen Status der Platzierungsgruppe abstimmen können (unter der Annahme eines Pools mit drei Reproduktionen der PG).

Abbildung 12.2: Peering-Schema #

12.9.4 Überwachen des Zustands von Platzierungsgruppen #

Wenn Sie ein Kommando wie ceph health, ceph -s oder ceph -w ausführen, gibt der Cluster nicht immer die Meldung HEALTH OK zurück. Sobald Sie geprüft haben, ob die OSDs aktiv sind, prüfen Sie auch den Status der Platzierungsgruppen.

Unter verschiedenen, mit dem Platzierungsgruppen-Peering zusammenhängenden Umständen ist zu erwarten, dass der Cluster nicht die Meldung HEALTH OK zurückgibt:

Sie haben einen Pool erstellt, und die Platzierungsgruppen haben noch nicht das Peering durchgeführt.
Die Platzierungsgruppen werden wiederhergestellt.
Sie haben einen OSD in einen Cluster eingefügt oder daraus entfernt.
Sie haben die CRUSH-Zuordnung geändert, und Ihre Platzierungsgruppen werden migriert.
Die verschiedenen Reproduktionen einer Platzierungsgruppe enthalten inkonsistente Daten.
Ceph führt das Scrubbing der Reproduktionen einer Platzierungsgruppe durch.
Die Speicherkapazität reicht nicht für die Ausgleichsoperationen von Ceph aus.

Wenn Ceph aus den obigen Gründen die Meldung HEALTH WARN ausgibt, ist dies kein Grund zur Sorge. In zahlreichen Fällen kann sich der Cluster selbst wiederherstellen. In bestimmten Fällen müssen Sie jedoch selbst gewisse Maßnahmen ergreifen. Bei der Überwachung der OSDs ist in jedem Fall darauf zu achten, dass alle Platzierungsgruppen den Status „active“ und nach Möglichkeit auch den Status „clean“ besitzen, wenn der Cluster selbst betriebsbereit und aktiv ist. Mit folgendem Kommando rufen Sie den Status aller Platzierungsgruppen ab:

cephuser@adm > ceph pg stat
x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail

Das Ergebnis umfasst die Gesamtanzahl der Platzierungsgruppen (x), die Anzahl der Platzierungsgruppen in einem bestimmten Status, z. B. „active+clean“ (y) sowie die gespeicherte Datenmenge (z).

Neben dem Status der Platzierungsgruppen gibt Ceph außerdem die belegte Speicherkapazität (aa), die verbleibende Speicherkapazität (bb) und die Gesamtspeicherkapazität für die Platzierungsgruppe zurück. Diese Zahlen sind in einigen Fällen von großer Bedeutung:

Sie nähern sich dem Wert für near full ratio oder full ratio.
Die Daten werden aufgrund eines Fehlers in der CRUSH-Konfiguration nicht im Cluster verteilt.

Tipp: Platzierungsgruppen-IDs

Die Platzierungsgruppen-IDs bestehen aus der Pool-Nummer (nicht dem Pool-Namen), gefolgt von einem Punkt (.) und der eigentlichen Platzierungsgruppen-ID (eine hexadezimale Zahl). Die Pool-Nummern und zugehörige Namen sind in der Ausgabe des Kommandos ceph osd lspools ersichtlich. Der Standard-Pool rbd entspricht beispielsweise der Pool-Nummer 0. Eine vollständige Platzierungsgruppen-ID weist das folgende Format auf:

POOL_NUM.PG_ID

und sieht in der Regel wie folgt aus:

0.1f

Mit folgendem Kommando rufen Sie eine Liste der Platzierungsgruppen ab:

cephuser@adm > ceph pg dump

Sie können auch die Ausgabe im JSON-Format formatieren und in einer Datei speichern:

cephuser@adm > ceph pg dump -o FILE_NAME --format=json

Mit folgendem Kommando fragen Sie eine bestimmte Platzierungsgruppe ab:

cephuser@adm > ceph pg POOL_NUM.PG_ID query

In der nachfolgenden Liste werden die gängigen Statusangaben für Platzierungsgruppen näher beschrieben.

CREATING

Beim Erstellen eines Pools wird die angegebene Anzahl der Platzierungsgruppen erstellt. Ceph gibt „creating“ zurück, während eine Platzierungsgruppe erstellt wird. Beim Erstellen führen die OSDs im „acting“-Satz der Platzierungsgruppe das Peering durch. Nach dem Peering sollte die Platzierungsgruppe den Status „active+clean“ aufweisen, sodass ein Ceph-Client in die Platzierungsgruppe schreiben kann.

Abbildung 12.3: Statusangaben für Platzierungsgruppen #

PEERING

Beim Peering einer Platzierungsgruppe stimmt Ceph die OSDs, auf denen die Reproduktionen der Platzierung gespeichert sind, hinsichtlich des Status der Objekte und Metadaten in der Platzierungsgruppe ab. Nach dem Peering zeigen also alle OSDs, auf denen die Platzierungsgruppe gespeichert ist, den aktuellen Status dieser Gruppe. Der Abschluss des Peering-Prozesses bedeutet jedoch nicht, dass jede Reproduktion den aktuellen Inhalt enthält.

Anmerkung: Maßgeblicher Verlauf

Ceph bestätigt nur dann einen Schreibvorgang auf einen Client, wenn alle OSDs im „acting“-Satz den Schreibvorgang dauerhaft speichern. Auf diese Weise ist sichergestellt, dass mindestens ein Mitglied des „acting“-Satzes einen Datensatz pro bestätigtem Schreibvorgang seit dem letzten erfolgreichen Peering-Vorgang besitzt.

Anhand der sorgfältigen Aufzeichnungen der einzelnen bestätigten Schreiboperationen kann Ceph einen neuen maßgeblichen Verlauf der Platzierungsgruppe aufstellen und fortführen – also einen vollständigen, geordneten Satz von Operationen, mit dem das Exemplar einer Platzierungsgruppe, die sich auf einem OSD befindet, auf den neuesten Stand gebracht werden kann.

AKTIV

Nach Abschluss des Peering-Prozesses kann eine Platzierungsgruppe den Status active erhalten. Im Status active stehen die Daten in der Platzierungsgruppe im Allgemeinen in der primären Platzierungsgruppe zur Verfügung, die Reproduktionen dagegen für Lese- und Schreiboperationen.

CLEAN

Wenn eine Platzierungsgruppe den Status clean aufweist, haben der primäre OSD und die Reproduktions-OSDs das Peering erfolgreich beendet, und es gibt keine nicht zugeordneten Reproduktionen für die Platzierungsgruppe. Ceph hat alle Objekte in der Platzierungsgruppe so oft wie gefordert reproduziert.

DEGRADED

Wenn ein Client ein Objekt in den primären OSD schreibt, ist der primäre OSD dafür zuständig, die Reproduktionen in die Reproduktions-OSDs zu schreiben. Sobald der primäre OSD das Objekt in den Speicher geschrieben hat, verbleibt die Platzierungsgruppe so lange im Status „degraded“, bis der primäre OSD eine Bestätigung von den Reproduktions-OSDs erhält, dass Ceph die Reproduktionsobjekte erfolgreich erstellt hat.

Eine Platzierungsgruppe kann dann den Status „active+degraded“ aufweisen, wenn ein OSD den Status „active“ besitzt, obwohl er noch nicht alle Objekte enthält. Wenn ein OSD ausfällt, kennzeichnet Ceph die einzelnen Platzierungsgruppen, die diesem OSD zugewiesen sind, als „degraded“. Sobald der OSD wieder funktionsfähig ist, müssen die OSDs das Peering wiederholen. Wenn eine eingeschränkt leistungsfähige Platzierungsgruppe den Status „active“ aufweist, kann ein Client jedoch weiterhin in ein neues Objekt in dieser Gruppe schreiben.

Wenn ein OSD den Status „down“ aufweist und die Bedingung „degraded“ weiterhin vorliegt, kennzeichnet Ceph den ausgefallenen OSD als außerhalb des Clusters („out“) und ordnet die Daten des „down“-OSDs einem anderen OSD zu. Der Zeitraum zwischen der Kennzeichnung als „down“ und der Kennzeichnung als „out“ wird durch die Option mon osd down out interval gesteuert (Standardwert 600 Sekunden).

Eine Platzierungsgruppe kann auch dann den Status „degraded“ erhalten, wenn Ceph mindestens ein Objekt, das sich in der Platzierungsgruppe befinden sollte, nicht auffinden kann. Es ist zwar nicht möglich, in nicht gefundenen Objekten zu lesen oder zu schreiben, doch Sie können weiterhin auf alle anderen Objekte in der „degraded“-Platzierungsgruppe zugreifen.

RECOVERING

Ceph ist für die Fehlertoleranz in Situationen mit anhaltenden Hardware- und Softwareproblemen ausgelegt. Wenn ein OSD ausfällt („down“), bleibt sein Inhalt hinter dem Status anderer Reproduktionen in den Platzierungsgruppen zurück. Sobald der OSD wieder funktionsfähig ist („up“), muss der Inhalt der Platzierungsgruppen gemäß dem aktuellen Stand aktualisiert werden. In diesem Zeitraum befindet sich der OSD im Status „recovering“.

Die Wiederherstellung ist nicht unbedingt trivial, da ein Hardwarefehler durchaus eine Kettenreaktion mit Ausfall mehrerer OSDs auslösen kann. Wenn beispielsweise ein Netzwerkschalter für ein Rack oder einen Schrank ausfällt, können die OSDs zahlreicher Hostmaschinen unter Umständen hinter den aktuellen Status des Clusters zurückfallen. Sobald der Fehler behoben wurde, muss jeder einzelne OSD wiederhergestellt werden.

Ceph bietet verschiedene Einstellungen für den Ausgleich der Ressourcenkonflikte zwischen neuen Serviceanforderungen und der Notwendigkeit, Datenobjekte wiederherzustellen und die Platzierungsgruppen wieder auf den neuesten Stand zu bringen. Mit der Einstellung osd recovery delay startkann ein OSD vor Beginn des Wiederherstellungsprozesses neu starten, das Peering erneut durchführen und sogar einige Wiederholungsanforderungen verarbeiten. Die Einstellung osd recovery thread timeout legt eine Thread-Zeitüberschreitung fest, da mehrere OSDs gestaffelt ausfallen, neu starten und das Peering erneut durchführen können. Die Einstellung osd recovery max active beschränkt die Anzahl der Wiederherstellungsanforderungen, die ein OSD gleichzeitig verarbeitet, damit der OSD nicht ausfällt. Die Einstellung osd recovery max chunk beschränkt die Größe der wiederhergestellten Datenblöcke, sodass eine Überlastung des Netzwerks verhindert wird.

BACK FILLING

Wenn ein neuer OSD in den Cluster eintritt, weist CRUSH die Platzierungsgruppen von den OSDs im Cluster zum soeben hinzugefügten OSD zu. Wird die sofortige Annahme der neu zugewiesenen Platzierungsgruppen durch den neuen OSD erzwungen, kann dies den OSD immens belasten. Durch den Ausgleich des OSD mit den Platzierungsgruppen kann dieser Prozess im Hintergrund beginnen. Nach erfolgtem Ausgleich verarbeitet der neue OSD die ersten Anforderungen, sobald er dazu bereit ist.

Während des Ausgleichs werden ggf. verschiedene Statusangaben angezeigt: „backfill_wait“, bedeutet, dass ein Ausgleichsvorgang aussteht, jedoch noch nicht gestartet wurde; „backfill“ bedeutet, dass ein Ausgleichsvorgang läuft; „backfill_too_full“ bedeutet, dass ein Ausgleichsvorgang angefordert wurde, jedoch aufgrund unzureichender Speicherkapazität nicht ausgeführt werden konnte. Wenn der Ausdruck einer Platzierungsgruppe nicht durchgeführt werden kann, gilt sie als „unvollständig“.

Ceph bietet verschiedene Einstellungen für die Bewältigung der Belastung im Zusammenhang mit der Neuzuweisung von Placement Groups zu einem OSD (insbesondere zu einem neuen OSD). Standardmäßig beschränkt osd max backfills die Anzahl gleichzeitiger Ausgleichsvorgänge mit einem OSD auf maximal 10 Vorgänge. Mit backfill full ratio kann ein OSD eine Ausgleichsanforderung verweigern, wenn der OSD sich seiner „full“-Quote nähert (standardmäßig 90 %). Dieser Wert kann mit dem Kommando ceph osd set-backfillfull-ratio geändert werden. Wenn ein OSD eine Ausgleichsanforderung verweigert, kann der OSD die Anforderung mit osd backfill retry interval wiederholen (standardmäßig nach 10 Sekunden). Die OSDs können außerdem die Scanintervalle (standardmäßig 64 und 512) mit osd backfill scan min und osd backfill scan max verwalten.

REMAPPED

Wenn sich der „acting“-Satz ändert, der für eine Platzierungsgruppe zuständig ist, werden die Daten vom bisherigen „acting“-Satz zum neuen „acting“-Satz migriert. Ein neuer primärer OSD kann unter Umständen erst nach einiger Zeit die ersten Anforderungen verarbeiten. In diesem Fall weist er den bisherigen primären OSD an, weiterhin die Anforderungen zu verarbeiten, bis die Migration der Platzierungsgruppe abgeschlossen ist. Nach erfolgter Datenmigration greift die Zuordnung auf den primären OSD des neuen „acting“-Satzes zurück.

INAKTIV

Obwohl Ceph mithilfe von Heartbeats prüft, ob die Hosts und Daemons ausgeführt werden, können die ceph-osd-Daemons in den Status „stuck“ gelangen, in dem sie die Statistiken nicht zeitnah melden (z. B. bei einem vorübergehenden Netzwerkfehler). Standardmäßig melden die OSD-Daemons in Abständen von einer halben Sekunde (0,5) ihre Statistiken zu Platzierungsgruppen, Startvorgängen und Fehlern, also in deutlich kürzeren Abständen als die Heartbeat-Grenzwerte. Wenn der primäre OSD im „acting“-Satz keine Meldung an den Monitor übergibt oder wenn andere OSDs den primären OSD als „down“ gemeldet haben, kennzeichnen die Monitors die Platzierungsgruppe als „stale“.

Beim Starten des Clusters wird häufig der Status „stale“ angezeigt, bis der Peering-Prozess abgeschlossen ist. Wenn der Cluster eine Weile aktiv war, weisen Platzierungsgruppen mit dem Status „stale“ darauf hin, dass der primäre OSD dieser Platzierungsgruppen ausgefallen ist oder keine Platzierungsgruppenstatistiken an den Monitor meldet.

12.9.5 Auffinden des Speicherorts eines Objekts #

Zum Speichern von Objektdaten im Ceph Object Store muss ein Ceph-Client einen Objektnamen festlegen und einen zugehörigen Pool angeben. Der Ceph-Client ruft die aktuelle Cluster-Zuordnung ab. Der CRUSH-Algorithmus berechnet, wie das Objekt einer Platzierungsgruppe zugeordnet werden soll, und dann, wie die Platzierungsgruppe dynamisch einem OSD zugewiesen werden soll. Zum Auffinden des Objektspeicherorts benötigen Sie lediglich den Objektnamen und den Poolnamen. Beispiel:

cephuser@adm > ceph osd map POOL_NAME OBJECT_NAME [NAMESPACE]

Beispiel 12.1: Auffinden eines Objekts #

Erstellen Sie für dieses Beispiel zunächst ein Objekt. Geben Sie den Objektnamen „test-object-1“, den Pfad zur Beispieldatei „testfile.txt“ mit einigen Objektdaten sowie den Poolnamen „data“ mit dem Kommando rados put in der Kommandozeile an:

cephuser@adm > rados put test-object-1 testfile.txt --pool=data

Prüfen Sie mit folgendem Kommando, ob das Objekt im Ceph Object Store gespeichert wurde:

cephuser@adm > rados -p data ls

Ermitteln Sie nun den Objektspeicherort. Ceph gibt den Speicherort des Objekts zurück:

cephuser@adm > ceph osd map data test-object-1
osdmap e537 pool 'data' (0) object 'test-object-1' -> pg 0.d1743484 \
(0.4) -> up ([1,0], p0) acting ([1,0], p0)

Löschen Sie das Beispielobjekt mit dem Kommando rados rm:

cephuser@adm > rados rm test-object-1 --pool=data