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

6 Ermitteln des Cluster-Zustands Edit source

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

cephadm@adm > ceph
ceph> health
ceph> status
ceph> quorum_status
ceph> mon_status

6.1 Überprüfen des Status eines Clusters Edit source

Führen Sie zum Überprüfen des Status eines Clusters Folgendes aus:

cephadm@adm > ceph status

oder

cephadm@adm > ceph -s

Geben Sie im interaktiven Modus status ein und drücken Sie auf Eingabetaste.

ceph> status

Ceph gibt den Cluster-Status aus. Beispielsweise gibt ein sehr kleiner Cluster bestehend aus einem Monitor und zwei OSDs möglicherweise Folgendes aus:

cluster b370a29d-9287-4ca3-ab57-3d824f65e339
 health HEALTH_OK
 monmap e1: 1 mons at {ceph1=10.0.0.8:6789/0}, election epoch 2, quorum 0 ceph1
 osdmap e63: 2 osds: 2 up, 2 in
  pgmap v41332: 952 pgs, 20 pools, 17130 MB data, 2199 objects
        115 GB used, 167 GB / 297 GB avail
               1 active+clean+scrubbing+deep
             951 active+clean

6.2 Überprüfen des Cluster-Zustands Edit source

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

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

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

cephadm@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:

cephadm@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:

cephadm@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:

cephadm@adm > ceph osd set-backfillfull-ratio ratio
cephadm@adm > ceph osd set-nearfull-ratio ratio
cephadm@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:

cephadm@adm > ceph df

Der zurzeit definierte Grad full wird angezeigt mit:

cephadm@adm > ceph osd dump | grep full_ratio

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

cephadm@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:

cephadm@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:

cephadm@adm > ceph df
OSDMAP_FLAGS

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

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

Die folgenden Flaggen sind verfügbar:

full

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 9.6, „Scrubbing“) 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 Flaggen 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-Flaggen werden gesetzt oder gelöscht mit:

cephadm@adm > ceph osd add-flag osd-ID
cephadm@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:

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

Weitere Informationen zum Cache Tiering finden Sie in Kapitel 14, Cache Tiering.

OSD_NO_SORTBITWISE

Es werden keine OSDs vor Luminous Version 12 ausgeführt, doch die Flagge sortbitwise wurde nicht gesetzt. Die Flagge sortbitwise muss gesetzt werden, damit OSDs ab Luminous Version 12 starten:

cephadm@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:

cephadm@adm > ceph df detail

Legen Sie entweder das Pool-Kontingent mit

cephadm@adm > ceph osd pool set-quota poolname max_objects num-objects
cephadm@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:

cephadm@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:

cephadm@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 die Flagge degraded oder undersized gesetzt wurde (es sind nicht genügend Instanzen dieser Placement Group im Cluster vorhanden) oder wenn einige Zeit die Flagge clean nicht gesetzt war. Detaillierte Informationen dazu, welche PGs betroffen sind, erhalten Sie durch Ausführen von:

cephadm@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:

cephadm@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 die Flagge 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 9.6, „Scrubbing“) wurden einige Probleme bezüglich der Datenkonsistenz im Cluster erkannt. Dies ist insbesondere dann der Fall, wenn für eine oder mehrere PGs die Flagge inconsistent oder snaptrim_error gesetzt wurde. Dadurch wird angegeben, dass bei einem früheren Scrubbing-Vorgang ein Problem gefunden wurde. Möglicherweise wurde auch die Flagge 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 Cache 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:

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

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

Weitere Informationen zum Cache Tiering finden Sie in Kapitel 14, Cache Tiering.

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.

Während sich der pg_num-Wert für bestehende Pools nicht verkleinern lässt, ist dies beim pgp_num-Wert durchaus möglich. 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:

cephadm@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:

cephadm@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:

cephadm@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:

cephadm@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:

cephadm@adm > ceph osd pool set-quota pool max_bytes bytes
cephadm@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:

cephadm@adm > ceph osd osd pool set-quota pool max_bytes bytes
cephadm@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 sie laut Cluster gespeichert werden sollen. 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:

cephadm@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:

cephadm@adm > ceph daemon osd.id ops

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

cephadm@adm > ceph daemon osd.id dump_historic_ops

Sie finden den Standort eines OSDs mit:

cephadm@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 9.6, „Scrubbing“). 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:

cephadm@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 9.6, „Scrubbing“). 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:

cephadm@adm > ceph pg deep-scrub pgid
Tipp
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

6.3 Beobachten eines Clusters Edit source

Mit ceph -s rufen Sie den aktuellen Zustand des Clusters ab. Beispielsweise gibt ein sehr kleiner Ceph Cluster bestehend aus einem Monitor und zwei OSDs Folgendes aus, wenn ein Workload ausgeführt wird:

cephadm@adm > ceph -s
cluster:
  id:     ea4cf6ce-80c6-3583-bb5e-95fa303c893f
  health: HEALTH_WARN
          too many PGs per OSD (408 > max 300)

services:
  mon: 3 daemons, quorum ses5min1,ses5min3,ses5min2
  mgr: ses5min1(active), standbys: ses5min3, ses5min2
  mds: cephfs-1/1/1 up  {0=ses5min3=up:active}
  osd: 4 osds: 4 up, 4 in
  rgw: 1 daemon active

data:
  pools:   8 pools, 544 pgs
  objects: 253 objects, 3821 bytes
  usage:   6252 MB used, 13823 MB / 20075 MB avail
  pgs:     544 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
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 StrgC, wenn Sie den Vorgang nicht länger beobachten möchten.

6.4 Überprüfen der Nutzungsstatistik Edit source

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.

cephadm@adm > ceph df
RAW STORAGE:
    CLASS     SIZE       AVAIL      USED        RAW USED     %RAW USED
    hdd       40 GiB     32 GiB     137 MiB      8.1 GiB         20.33
    TOTAL     40 GiB     32 GiB     137 MiB      8.1 GiB         20.33
POOLS:
    POOL             ID     STORED     OBJECTS    USED       %USED    MAX AVAIL
    iscsi-images      1     3.9 KiB          8    769 KiB        0       10 GiB
    cephfs_data       2     1.6 KiB          5    960 KiB        0       10 GiB
    cephfs_metadata   3      54 KiB         22    1.5 MiB        0       10 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 9.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 6.10, „Speicherkapazität“.

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

6.5 Überprüfen des OSD-Status Edit source

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

cephadm@adm > ceph osd stat

oder

cephadm@adm > ceph osd dump

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

cephadm@adm > ceph osd tree

Ceph gibt einen CRUSH-Baum mit einem Host und dessen OSDs, den Status der Aktivität und deren Gewicht aus.

# id    weight  type name       up/down reweight
-1      3       pool default
-3      3               rack mainrack
-2      3                       host osd-host
0       1                               osd.0   up      1
1       1                               osd.1   up      1
2       1                               osd.2   up      1

6.6 Suchen nach vollen OSDs Edit source

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-Nodes werden durch ceph health gemeldet:

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

oder

cephadm@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
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 Nodes 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.

6.7 Überprüfen des Monitor-Status Edit source

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:

cephadm@adm > ceph mon stat

oder

cephadm@adm > ceph mon dump

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

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

6.8 Überprüfen des Zustands von Placement Groups Edit source

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 6.11, „Überwachen der OSDs und Platzierungsgruppen“.

6.9 Verwenden des Admin Socket Edit source

Mit einem Ceph Admin Socket haben Sie die Möglichkeit, einen Daemon über eine Socket-Schnittstelle abzufragen. Ceph Sockets befinden sich standardmäßig unter /var/run/ceph. Melden Sie sich für den Zugriff auf einen Daemon über den Admin Socket beim Host an, auf dem der Daemon ausgeführt wird, und führen Sie folgendes Kommando aus:

cephadm@adm > ceph --admin-daemon /var/run/ceph/socket-name

Führen Sie folgendes Kommando aus, um die verfügbaren Admin Socket-Kommandos anzuzeigen:

cephadm@adm > ceph --admin-daemon /var/run/ceph/socket-name help

Mit dem Admin Socket-Kommando können Sie Ihre Konfiguration während der Laufzeit anzeigen und festlegen. Weitere Informationen finden Sie unter Abschnitt 16.1, „Konfiguration zur Laufzeit“.

Außerdem können Sie die Konfigurationswerte während der Laufzeit direkt festlegen (der Admin Socket umgeht den Monitor, im Gegensatz zum Kommando ceph tell daemon-type.id injectargs, das sich auf den Monitor verlässt. Dazu brauchen Sie sich jedoch nicht direkt beim betreffenden Host anzumelden).

6.10 Speicherkapazität Edit source

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

Ceph Cluster
Abbildung 6.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:

  1. die Anzahl der OSDs,

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

6.11 Überwachen der OSDs und Platzierungsgruppen Edit source

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

6.11.1 Überwachen der OSDs Edit source

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
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 gerade gestartet oder neu gestartet und er ist noch nicht betriebsbereit, da die Platzierungsgruppen noch erstellt werden und die OSDs gerade den Peering-Prozess durchlaufen.

  • Sie haben gerade ein OSD hinzugefügt oder entfernt.

  • Sie haben gerade die Cluster-Zuordnung 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

Ist beispielsweise der OSD mit der ID 1 nicht betriebsbereit, starten Sie ihn:

cephadm@osd > sudo systemctl start ceph-osd@1.service

Weitere Informationen zu Problemen im Zusammenhang mit OSDs, die angehalten wurden oder sich nicht neu starten lassen, finden Sie in Abschnitt 6.12, „OSD ist nicht aktiv“.

6.11.2 Platzierungsgruppensätze Edit source

Beim Zuweisen von Platzierungsgruppen zu den OSDs prüft CRUSH die Anzahl der Reproduktionen für den Pool und weist die Platzierungsgruppe so zu den OSDs 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:

cephadm@adm > ;ceph pg dump

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

cephadm@adm > ceph pg mapPG_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
Tipp: Hinweis auf Cluster-Probleme

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.

6.11.3 Peering Edit source

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

Peering-Schema
Abbildung 6.2: Peering-Schema

6.11.4 Überwachen des Zustands von Platzierungsgruppen Edit source

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 gerade einen Pool erstellt und die Platzierungsgruppen haben noch nicht das Peering durchgeführt.

  • Die Platzierungsgruppen werden wiederhergestellt.

  • Sie haben gerade einen OSD in einen Cluster eingefügt oder daraus entfernt.

  • Sie haben gerade 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:

cephadm@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
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:

cephadm@adm > ceph pg dump

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

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

Mit folgendem Kommando fragen Sie eine bestimmte Platzierungsgruppe ab:

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

Statusangaben für Platzierungsgruppen
Abbildung 6.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
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.

ACTIVE

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.

6.11.5 Erkennen problematischer Platzierungsgruppen Edit source

Wie bereits erwähnt, ist bei einer Platzierungsgruppe, die nicht den Status „active+clean“ aufweist, nicht in jedem Fall ein Problem aufgetreten. Im Allgemeinen kann sich Ceph nicht selbst reparieren, wenn Platzierungsgruppen hängen bleiben. Folgende Statusangaben sind möglich:

  • Unclean: Die Platzierungsgruppen enthalten Objekte, die nicht so oft wie gefordert reproduziert wurden. Hier sollte eine Wiederherstellung möglich sein.

  • Inactive: Die Platzierungsgruppen können keine Lese- oder Schreibvorgänge verarbeiten, da sie darauf warten, dass ein OSD mit den aktuellen Daten wieder funktionsfähig wird.

  • Stale: Die Platzierungsgruppen befinden sich in einem unbekannten Status, da die OSDs, auf denen sie gehostet werden, seit einiger Zeit keine Meldung mehr an den Monitor-Cluster übermittelt haben (konfiguriert mit der Option mon osd report timeout).

Mit folgendem Befehl erkennen Sie hängen gebliebene Platzierungsgruppen:

cephadm@adm > ceph pg dump_stuck [unclean|inactive|stale|undersized|degraded]

6.11.6 Auffinden des Speicherorts eines Objekts Edit source

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:

cephadm@adm > ceph osd map POOL_NAME OBJECT_NAME [NAMESPACE]
Beispiel 6.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:

cephadm@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:

cephadm@adm > rados -p data ls

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

cephadm@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:

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

6.12 OSD ist nicht aktiv Edit source

Unter normalen Umständen lässt sich der ceph-osd-Daemon durch einfaches Neustarten wieder in den Cluster aufnehmen und wiederherstellen.

6.12.1 Ein OSD startet nicht Edit source

Wenn Sie Ihren Cluster starten und ein OSD nicht gestartet werden kann, prüfen Sie Folgendes:

  • Konfigurationsdatei: Falls sie OSDs aus einer neuen Installation nicht starten können, prüfen Sie, ob die Konfigurationsdatei den Anforderungen entspricht (z. B. host und nicht hostname).

  • Pfade: Prüfen Sie die Pfade in ihrer Konfiguration und stellen Sie fest, ob sich in den eigentlichen Pfaden die erwarteten Daten und Journale befinden. Wenn Sie die OSD-Daten von den Journaldaten trennen und die Konfiguration oder die eigentlichen Einschränkungen fehlerhaft sind, kann es beim Starten der OSDs zu Problemen kommen. Wenn Sie das Journal wieder auf einem Blockgerät speichern möchten, müssen Sie den Journaldatenträger partitionieren und den einzelnen OSDs jeweils eine Partition zuweisen.

  • Max. Thread-Anzahl: Wenn ein Knoten zahlreiche OSDs enthält, erreichen Sie möglicherweise die standardmäßige maximale Anzahl der Threads (in der Regel 32.000), insbesondere bei der Wiederherstellung. Sie können die Anzahl der Threads mit dem Kommando sysctl erhöhen und dann prüfen, ob die Erhöhung der maximalen Thread-Anzahl auf den maximal zulässigen Wert (z. B. 4.194.303) hilft:

    root # sysctl -w kernel.pid_max=4194303

    Wenn das Problem durch Erhöhung der maximalen Thread-Anzahl behoben ist, können Sie diese Lösung dauerhaft festhalten. Fügen Sie hierzu die Einstellung kernel.pid_max in die Datei /etc/sysctl.conf ein:

    kernel.pid_max = 4194303

6.12.2 Ein OSD ist ausgefallen Edit source

Wenn der ceph-osd-Prozess abgebrochen wird, wird der Monitor von den verbleibenden ceph-osd-Daemons über den Absturz informiert. Der Monitor meldet den Abbruch dann mit dem Kommando ceph health:

cephadm@adm > ceph health
HEALTH_WARN 1/3 in osds are down

Insbesondere erhalten Sie eine Warnung, wenn ceph-osd-Prozesse als „in“ und „down“ gekennzeichnet sind. Mit folgendem Kommando erkennen Sie die ceph-osds mit dem Status „down“:

cephadm@adm > ceph health detail
HEALTH_WARN 1/3 in osds are down
osd.0 is down since epoch 23, last address 192.168.106.220:6800/11080

Falls ceph-osd wegen eines Datenträgerausfalls oder eines anderen Fehlers nicht mehr funktionsfähig ist oder nicht neu gestartet werden kann, sollte in der zugehörigen Protokolldatei unter /var/log/ceph eine entsprechende Fehlermeldung eingetragen sein.

Wurde der Daemon wegen eines Heartbeat-Fehlers angehalten, reagiert das zugrunde liegende Kernel-Dateisystem möglicherweise nicht. Prüfen Sie die Ausgabe des Kommandos dmesg auf Datenträger- oder andere Kernel-Fehler.

6.12.3 Kein freier Speicherplatz Edit source

Ceph verhindert das Schreiben auf einen vollen OSD, damit kein Datenverlust eintritt. In einem betriebsbereiten Cluster sollten Sie eine Warnmeldung erhalten, wenn der Cluster annähernd voll ist. Der Wert für die Option mon osd full ratio ist standardmäßig 0,95 bzw. 95 % der Kapazität. Wenn dieser Wert erreicht ist, werden die Clients davon abgehalten, Daten zu schreiben. Der Wert für mon osd backfillfull ratio liegt standardmäßig bei 0,90 bzw. 90 % der Kapazität. Ab diesem Wert wird das Starten von Ausgleichsvorgängen blockiert. Der Wert für die OSD-„nearfull“-Quote liegt standardmäßig bei 0,85 bzw. 85 % der Kapazität. Wenn dieser Wert erreicht ist, wird eine Zustandswarnung generiert. Mit folgendem Kommando können Sie den Wert für „nearfull“ ändern:

cephadm@adm > ceph osd set-nearfull-ratio 0.0 to 1.0

Probleme mit einem vollen Cluster treten in der Regel auf, wenn die Verarbeitung eines OSD-Ausfalls in einem kleinen Cluster durch Ceph getestet wird. Wenn sich ein großer Anteil der Cluster-Daten auf einem einzelnen Knoten befindet, kann der Cluster durchaus sofort die „nearfull“- und „full“-Quote überschreiten. Wenn Sie erproben, wie Ceph auf OSD-Ausfälle in einem kleinen Cluster reagiert, lassen Sie ausreichend Speicherplatz frei und senken Sie ggf. vorübergehend die OSD-„full“-Quote, die OSD-„backfillfull“-Quote und die OSD-„nearfull“-Quote mit folgenden Kommandos:

cephadm@adm > ceph osd set-nearfull-ratio 0.0 to 1.0
cephadm@adm > ceph osd set-full-ratio 0.0 to 1.0
cephadm@adm > ceph osd set-backfillfull-ratio 0.0 to 1.0

Volle Ceph OSDs werden durch ceph health gemeldet:

cephadm@adm > ceph health
HEALTH_WARN 1 nearfull osd(s)

oder

cephadm@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%

Am besten fügen Sie bei einem vollen Cluster neue Ceph OSDs hinzu. Dadurch kann der Cluster Daten auf den neu verfügbaren Speicherplatz verteilen.

Wenn sich ein OSD nicht starten lässt, weil er voll ist, können Sie einige Daten löschen, indem Sie einige Placement Group-Verzeichnisse im vollen OSD löschen.

Wichtig
Wichtig: Löschen eines Platzierungsgruppenverzeichnisses

Soll ein Platzierungsgruppenverzeichnis auf einem vollen OSD dauerhaft gelöscht werden, löschen Sie dieses Platzierungsgruppenverzeichnis nicht auch dauerhaft auf einem anderen vollen OSD; ansonsten kann Datenverlust eintreten. Sie müssen mindestens ein Exemplar der Daten auf mindestens einem OSD beibehalten.

Diese Seite drucken