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

4 Ermitteln des Cluster-Zustands

Die Überwachung eines aktiven Clusters ist mit dem Werkzeug ceph möglich. Zur Ermittlung des Cluster-Zustands wird normalerweise der Status des OSD, des Monitors, der Placement Group und des Metadata Servers überprü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 > ceph
ceph> health
ceph> status
ceph> quorum_status
ceph> mon_status

4.1 Überprüfen des Cluster-Zustands

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

root # ceph health
HEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \
node-1,node-2,node-3

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:

root # ceph osd crush rm osd.ID
OSD_OUT_OF_ORDER_FULL

Die Auslastungsgrenzwerte für backfillfull, nearfull, full und/oder failsafe_full sind nicht aufsteigend. Insbesondere erwarten wir backfillfull < nearfull, nearfull < full und full < failsafe_full. Die Grenzwerte können angepasst werden mit:

root # ceph osd set-backfillfull-ratio ratio
root # ceph osd set-nearfull-ratio ratio
root # 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:

root # ceph df

Der zurzeit definierte Grad full wird angezeigt mit:

root # ceph osd dump | grep full_ratio

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

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

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

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

root # ceph osd set flag
root # 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 6.5, „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:

root # ceph osd add-flag osd-ID
root # 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:

root # ceph osd pool set poolname hit_set_type type
root # ceph osd pool set poolname hit_set_period period-in-seconds
root # ceph osd pool set poolname hit_set_count number-of-hitsets
root # 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 die Flagge sortbitwise wurde nicht gesetzt. Die Flagge sortbitwise muss gesetzt werden, damit OSDs ab Luminous Version 12 starten:

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

root # ceph df detail

Legen Sie entweder das Pool-Kontingent mit

root # ceph osd pool set-quota poolname max_objects num-objects
root # 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 eine oder mehrere PGs in einem Zustand befinden, 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:

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

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

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

root # 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 6.5, „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:

root # ceph osd pool set cache-pool-name target_max_bytes bytes
root # 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.

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:

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

ceph osd pool set pool pgp_num pg_num_value
MANY_OBJECTS_PER_PG

Bei einem oder mehreren Pools 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:

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

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

root # ceph osd pool set-quota pool max_bytes bytes
root # 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:

root # ceph osd osd pool set-quota pool max_bytes bytes
root # ceph osd osd pool set-quota pool max_objects objects

Durch Festlegen des Kontingentwerts auf 0 wird das Kontingent deaktiviert.

OBJECT_MISPLACED

Ein oder mehrere Objekte im Cluster sind nicht in dem Node gespeichert, in dem der Cluster es erwartet. 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 online sind. Lese- oder Schreibanforderungen an die "unfound"-Objekte werden blockiert. Idealerweise kann ein inaktiver OSD, der die neueste Kopie des nicht gefundenen Objekts enthält, wieder online gehen. 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:

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

root # ceph daemon osd.id ops

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

root # ceph daemon osd.id dump_historic_ops

Sie finden den Standort eines OSDs mit:

root # ceph osd find osd.id
REQUEST_STUCK

Eine oder mehrere OSD-Anforderungen wurden extrem lange blockiert. 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 wenn interne Probleme am OSD aufgetreten sind.

PG_NOT_SCRUBBED

Es wurde länger kein Scrubbing bei einem oder mehreren PGs durchgeführt (weitere Informationen hierzu finden Sie in Abschnitt 6.5, „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:

root # 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 6.5, „Scrubbing“). Bei PGs wird normalerweise alle osd_deep_mon_scrub_interval Sekunden ein Scrubbing durchgeführt und diese Warnmeldung wird ausgelöst, wenn diese mon_warn_not_deep_scrubbed-Intervalle ohne Scrubbing abgelaufen sind. 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:

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

4.2 Beobachten eines Clusters

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:

cluster:
  id:     6586341d-4565-3755-a4fd-b50f51bee248
  health: HEALTH_OK

services:
  mon: 3 daemons, quorum blueshark1,blueshark2,blueshark3
  mgr: blueshark3(active), standbys: blueshark2, blueshark1
  osd: 15 osds: 15 up, 15 in

data:
  pools:   8 pools, 340 pgs
  objects: 537 objects, 1985 MB
  usage:   23881 MB used, 5571 GB / 5595 GB avail
  pgs:     340 active+clean

io:
  client:   100 MB/s rd, 26256 op/s rd, 0 op/s wr

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

  • 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 und schließlich

  • 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

Stellen Sie zum Aktualisieren der Informationen in Echtzeit diese Kommandos (einschließlich ceph -s) in eine Warteschleife, wie zum Beispiel:

rootwhile true ; do ceph -s ; sleep 10 ; done

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

4.3 Überprüfen der Nutzungsstatistik

Die Datennutzung eines Clusters und die Datenverteilung auf die Pools überprüfen Sie mit der Option df. Die Option ist der Linux-Option df ähnlich. Führen Sie Folgendes aus:

root # ceph df
GLOBAL:
    SIZE       AVAIL      RAW USED     %RAW USED
    55886G     55826G       61731M          0.11
POOLS:
    NAME         ID     USED      %USED     MAX AVAIL     OBJECTS
    testpool     1          0         0        17676G           0
    ecpool       2      4077M      0.01        35352G        2102
    test1        3          0         0        17676G           0
    rbd          4         16         0        17676G           3
    rbd1         5         16         0        17676G           3
    ecpool1      6      5708M      0.02        35352G        2871

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

  • SIZE: Die gesamte Speicherkapazität des Clusters.

  • AVAIL: Der verfügbare freie Speicherplatz im Cluster.

  • RAW USED: Der genutzte Basisspeicherplatz

  • % 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 Details finden Sie unter Speicherkapazität.

    Anmerkung
    Anmerkung: Füllstand des Clusters

    Ein Füllstand des Basisspeichers von 70 % bis 80 % gibt an, dass neuer Speicherplatz zum Cluster hinzugefügt werden muss. 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.

  • NAME: Der Name des Pools.

  • ID: Die Pool-ID.

  • USED: Die nominelle Menge der Daten in Kilobyte, falls an die Zahl nicht M für Megabyte oder G für Gigabyte angehängt ist.

  • %USED: Der nominelle Prozentsatz des genutzten Speichers pro Pool.

  • MAX AVAIL: Der maximal verfügbare Speicherplatz im jeweiligen Pool.

  • OBJECTS: Die nominelle Anzahl der pro Pool gespeicherten Objekte.

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 and %USED nicht den Zahlen unter RAW USED und %RAW USED im Abschnitt %GLOBAL der Ausgabe.

4.4 Überprüfen des Status eines Clusters

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

root # ceph status

oder

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

4.5 Überprüfen des OSD-Status

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

root # ceph osd stat

oder

root # ceph osd dump

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

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

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

ceph health
  HEALTH_WARN 1 nearfull osds
  osd.2 is near full at 85%

oder

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

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.

4.7 Überprüfen des Monitor-Status

Wenn Ihr Cluster über mehrere Monitors verfügt (was wahrscheinlich ist), dann sollten Sie nach dem Start des Clusters und vor dem Lesen und/oder Schreiben von Daten den Status des Monitor-Quorums prüfen. Ein Quorum muss vorhanden sein, wenn mehrere Monitors ausgeführt werden. Sie sollten auch regelmäßig den Monitor-Status prüfen, um sicherzustellen, dass sie ausgeführt werden.

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

root # ceph mon stat

oder

root # ceph mon dump

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

root # 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": "127.0.0.1:6789\/0"},
            { "rank": 1,
              "name": "b",
              "addr": "127.0.0.1:6790\/0"},
            { "rank": 2,
              "name": "c",
              "addr": "127.0.0.1:6791\/0"}
           ]
    }
}

4.8 Überprüfen des Zustands von Placement Groups

Placement Groups ordnen Objekte zu OSDs zu. Bei der Überwachung Ihrer Placement Groups sollten diese active (aktiv) und clean (intakt) sein. Eine detaillierte Erläuterung zu diesem Thema finden Sie unter Überwachen von OSDs und Placement Groups.

4.9 Verwenden des Admin Socket

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:

root # ceph --admin-daemon /var/run/ceph/socket-name

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

root # 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 Details finden Sie unter Anzeigen einer Konfiguration während der 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).

Diese Seite drucken