Betriebs- und Verwaltungshandbuch
- Informationen über dieses Handbuch
- I Ceph Dashboard
- 1 Infos zum Ceph Dashboard
- 2 Dashboard-Webbenutzeroberfläche
- 3 Verwalten von Ceph-Dashboard-Benutzern und -Rollen
- 4 Anzeigen von Cluster-internen Elementen
- 5 Verwalten von Pools
- 6 Verwalten von RADOS-Blockgeräten
- 7 Verwalten von NFS Ganesha
- 8 Verwalten von CephFS
- 9 Verwalten des Object Gateways
- 10 Manuelle Konfiguration
- 11 Verwalten von Benutzern und Rollen über die Kommandozeile
- II Clustervorgang
- III Speichern von Daten in einem Cluster
- IV Zugreifen auf Cluster-Daten
- V Integration in Virtualisierungstools
- VI Konfigurieren eines Clusters
- A Ceph-Wartungsaktualisierungen auf der Grundlage von vorgeschalteten „Octopus“-Unterversionen
- B Aktualisierungen für die Dokumentation
- Glossar
12 Ermitteln des Clusterzustands #Edit source
- 12.1 Überprüfen des Status eines Clusters
- 12.2 Überprüfen der Clusterintegrität
- 12.3 Überprüfen der Nutzungsstatistik eines Clusters
- 12.4 Überprüfen des OSD-Status
- 12.5 Suchen nach vollen OSDs
- 12.6 Prüfen des Monitorstatus
- 12.7 Überprüfen des Zustands von Platzierungsgruppen
- 12.8 Speicherkapazität
- 12.9 Überwachen der OSDs und Platzierungsgruppen
Die Überwachung eines aktiven Clusters ist mit dem Werkzeug ceph möglich. Zur Ermittlung des Cluster-Zustands wird in der Regel der Status der Ceph OSDs, Ceph Monitors, Platzierungsgruppen und Metadatenserver geprüft.
Tipp: Interaktiver Modus
Geben Sie zur Ausführung des Werkzeugs ceph im interaktiven Modus ceph in der Kommandozeile ohne Argumente ein. Der interaktive Modus ist praktischer, wenn Sie vorhaben, mehrere ceph-Kommandos in einer Zeile einzugeben. Beispiel:
cephuser@adm > ceph
ceph> health
ceph> status
ceph> quorum_status
ceph> mon stat12.1 Überprüfen des Status eines Clusters #Edit source
Mit ceph -s oder ceph -s rufen Sie den aktuellen Zustand des Clusters ab:
cephuser@adm > ceph -s
cluster:
id: b4b30c6e-9681-11ea-ac39-525400d7702d
health: HEALTH_OK
services:
mon: 5 daemons, quorum ses-min1,ses-master,ses-min2,ses-min4,ses-min3 (age 2m)
mgr: ses-min1.gpijpm(active, since 3d), standbys: ses-min2.oopvyh
mds: my_cephfs:1 {0=my_cephfs.ses-min1.oterul=up:active}
osd: 3 osds: 3 up (since 3d), 3 in (since 11d)
rgw: 2 daemons active (myrealm.myzone.ses-min1.kwwazo, myrealm.myzone.ses-min2.jngabw)
task status:
scrub status:
mds.my_cephfs.ses-min1.oterul: idle
data:
pools: 7 pools, 169 pgs
objects: 250 objects, 10 KiB
usage: 3.1 GiB used, 27 GiB / 30 GiB avail
pgs: 169 active+cleanDie Ausgabe bietet die folgenden Informationen:
Cluster-ID
Cluster-Zustand
Die Monitor-Zuordnungsepoche und den Status des Monitor-Quorums
Die OSD-Zuordnungsepoche und den Status der OSDs
Status der Ceph Managers
Status der Object Gateways
Die Version der Placement-Group-Zuordnung
Die Anzahl der Placement Groups und Pools
Die nominelle Menge der gespeicherten Daten und die Anzahl der gespeicherten Objekte
Die Gesamtmenge der gespeicherten Daten
Tipp: Wie Ceph die Datennutzung berechnet
Der Wert used bezeichnet den tatsächlich belegten Basisspeicherplatz. Der Wert xxx GB / xxx GB bezeichnet den verfügbaren Speicherplatz (der kleinere Wert) der gesamten Speicherkapazität des Clusters. Die nominelle Menge spiegelt die Menge der gespeicherten Daten wider, bevor diese reproduziert oder geklont werden oder ein Snapshot davon erstellt wird. Daher übersteigt die Menge der tatsächlich gespeicherten Daten normalerweise die nominelle gespeicherte Menge, weil Ceph Reproduktionen der Daten erstellt und die Speicherkapazität möglicherweise auch zum Klonen und für Snapshots verwendet.
Mit den folgenden Kommandos werden die Statusinformationen ebenfalls sofort angezeigt:
ceph pg statceph osd pool statsceph dfceph df detail
Sollen die Angaben in Echtzeit aktualisiert werden, geben Sie diese Kommandos (auch ceph ‑s) als Argument für das Kommando watch an:
root # watch -n 10 'ceph -s'Drücken Sie Strg–C, wenn Sie den Vorgang nicht länger beobachten möchten.
12.2 Überprüfen der Clusterintegrität #Edit source
Überprüfen Sie den Zustand Ihres Clusters nach dessen Start und bevor Sie mit dem Lesen und/oder Schreiben von Daten beginnen:
cephuser@adm > ceph health
HEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \
node-1,node-2,node-3Tipp
Wenn Sie nicht standardmäßige Standorte für Ihre Konfiguration oder Ihren Schlüsselbund angegeben haben, können Sie diese angeben mit:
cephuser@adm > ceph -c /path/to/conf -k /path/to/keyring healthDer Ceph-Cluster gibt einen der folgenden Zustandscodes zurück:
- OSD_DOWN
Einer oder mehrere OSDs sind als inaktiv gekennzeichnet. Der OSD Daemon wurde möglicherweise gestoppt oder Peer-OSDs erreichen den OSD möglicherweise nicht über das Netzwerk. Üblicherweise handelt es sich dabei um einen gestoppten oder abgestürzten Daemon, einen inaktiven Host oder einen Netzwerkausfall.
Verifizieren Sie, dass sich der Host in einem ordnungsgemäßen Zustand befindet, der Daemon gestartet ist und das Netzwerk funktioniert. Falls der Daemon abgestürzt ist, enthält die Protokolldatei des Daemon (
/var/log/ceph/ceph-osd.*) möglicherweise Informationen zur Fehlersuche.- OSD_CRUSH-Typ_DOWN, beispielsweise OSD_HOST_DOWN
Alle OSDs in einem bestimmten CRUSH-Teilbaum sind als inaktiv gekennzeichnet, wie zum Beispiel alle OSDs auf einem Host.
- OSD_ORPHAN
In der CRUSH Map-Hierarchie wird auf einen OSD verwiesen, er ist jedoch nicht vorhanden. Der OSD kann aus der CRUSH-Hierarchie entfernt werden mit:
cephuser@adm >ceph osd crush rm osd.ID- OSD_OUT_OF_ORDER_FULL
Die Auslastungsgrenzwerte für backfillfull (Standardwert 0,90), nearfull (Standardwert 0,85), full (Standardwert 0,95) und/oder failsafe_full sind nicht aufsteigend. Insbesondere erwarten wir backfillfull < nearfull, nearfull < full und full < failsafe_full.
Mit folgendem Kommando lesen Sie die aktuellen Werte aus:
cephuser@adm >ceph health detail HEALTH_ERR 1 full osd(s); 1 backfillfull osd(s); 1 nearfull osd(s) osd.3 is full at 97% osd.4 is backfill full at 91% osd.2 is near full at 87%Die Grenzwerte können mit folgenden Kommandos angepasst werden:
cephuser@adm >ceph osd set-backfillfull-ratio ratiocephuser@adm >ceph osd set-nearfull-ratio ratiocephuser@adm >ceph osd set-full-ratio ratio- OSD_FULL
Einer oder mehrere OSDs haben den Grenzwert full überschritten, was verhindert, dass der Cluster Schreibvorgänge ausführt. Die Auslastung pro Pool wird überprüft mit:
cephuser@adm >ceph dfDer zurzeit definierte Grad full wird angezeigt mit:
cephuser@adm >ceph osd dump | grep full_ratioEine kurzfristige Behelfslösung zum Wiederherstellen der Schreibverfügbarkeit ist die geringfügige Erhöhung des Grenzwerts:
cephuser@adm >ceph osd set-full-ratio ratioFügen Sie neuen Speicherplatz zum Cluster hinzu, indem Sie weitere OSDs bereitstellen, oder löschen Sie bestehende Daten, um Speicherplatz freizugeben.
- OSD_BACKFILLFULL
Einer oder mehrere OSDs haben den Grenzwert backfillfull überschritten, wodurch verhindert wird, dass auf diesem Gerät ein Datenausgleich stattfindet. Hierbei handelt es sich um eine frühzeitige Warnung, dass der Ausgleich möglicherweise nicht durchgeführt werden kann und der Cluster fast voll ist. Die Auslastung pro Pool wird überprüft mit:
cephuser@adm >ceph df- OSD_NEARFULL
Einer oder mehrere OSDs haben den Grenzwert nearfull überschritten. Hierbei handelt es sich um eine frühzeitige Warnung, dass der Cluster fast voll ist. Die Auslastung pro Pool wird überprüft mit:
cephuser@adm >ceph df- OSDMAP_FLAGS
Eine oder mehrere interessante Cluster-Flags wurden gesetzt. Mit Ausnahme von full können diese Flags festgelegt oder gelöscht werden mit:
cephuser@adm >ceph osd set flagcephuser@adm >ceph osd unset flagDie folgenden Flags sind verfügbar:
- Vollständig
Der Cluster wird als voll gekennzeichnet und kann keine Schreibvorgänge mehr bedienen.
- pauserd, pausewr
Lese- und Schreibvorgänge werden ausgesetzt.
- noup
OSDs dürfen nicht gestartet werden.
- nodown
OSD-Fehlerberichte werden ignoriert, sodass die Monitors keine OSDs mit down kennzeichnen.
- noin
OSDs, die vorher mit out gekennzeichnet wurden, werden beim Starten nicht wieder mit in gekennzeichnet.
- noout
Down OSDs werden nach dem konfigurierten Intervall nicht automatisch mit out gekennzeichnet.
- nobackfill, norecover, norebalance
Wiederherstellung oder Datenausgleich ist angehalten.
- noscrub, nodeep_scrub
Scrubbing (Informationen hierzu finden Sie in Abschnitt 17.6, „Scrubbing von Platzierungsgruppen“) ist deaktiviert.
- notieragent
Die Cache-Tiering-Aktivität ist angehalten.
- OSD_FLAGS
Für eine oder mehrere OSDs wurde eine Interessensflagge pro OSD gesetzt. Die folgenden Flags sind verfügbar:
- noup
Der OSD darf nicht starten.
- nodown
Fehlerberichte für diesen OSD werden ignoriert.
- noin
Wenn dieser OSD vorher automatisch nach einem Fehler mit out markiert wurde, wird er beim Start nicht mit in gekennzeichnet.
- noout
Wenn dieser OSD inaktiv ist, wird er nach dem konfigurierten Intervall nicht automatisch mit out gekennzeichnet.
Pro-OSD-Flags werden gesetzt oder gelöscht mit:
cephuser@adm >ceph osd add-flag osd-IDcephuser@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_versionfestgelegt.- OLD_CRUSH_STRAW_CALC_VERSION
Die CRUSH Map verwendet eine ältere, nicht optimale Methode zur Berechnung von Gewichtungszwischenwerten für Straw Buckets. Die CRUSH Map sollte aktualisiert werden, um die neuere Methode zu verwenden (
straw_calc_version=1).- CACHE_POOL_NO_HIT_SET
Einer oder mehrere Cache Pools wurden nicht mit einem Treffersatz zum Verfolgen der Auslastung konfiguriert. Dadurch wird verhindert, dass der Tiering-Agent unbenutzte Objekte erkennt, die aus dem Cache entfernt werden müssen. Treffersätze werden im Cache Pool konfiguriert mit:
cephuser@adm >ceph osd pool set poolname hit_set_type typecephuser@adm >ceph osd pool set poolname hit_set_period period-in-secondscephuser@adm >ceph osd pool set poolname hit_set_count number-of-hitsetscephuser@adm >ceph osd pool set poolname hit_set_fpp target-false-positive-rate- OSD_NO_SORTBITWISE
Es werden keine OSDs vor Luminous Version 12 ausgeführt, doch das Flag
sortbitwisewurde nicht gesetzt. Das Flagsortbitwisemuss gesetzt werden, damit OSDs ab Luminous Version 12 starten:cephuser@adm >ceph osd set sortbitwise- POOL_FULL
Einer oder mehrere Pools haben das Kontingent erreicht und lassen keine weiteren Schreibvorgänge zu. Pool-Kontingente und Auslastungswerte werden mit folgendem Kommando festgelegt:
cephuser@adm >ceph df detailLegen Sie entweder das Pool-Kontingent mit
cephuser@adm >ceph osd pool set-quota poolname max_objects num-objectscephuser@adm >ceph osd pool set-quota poolname max_bytes num-bytesfest oder löschen Sie einige vorhandene Daten, um die Auslastung zu verringern.
- PG_AVAILABILITY
Die Datenverfügbarkeit ist reduziert. Dies bedeutet, dass der Cluster potenzielle Lese- oder Schreibanforderungen für einige Daten im Cluster nicht bedienen kann. Dies ist insbesondere dann der Fall, wenn sich mindestens eine PG in einem Zustand befindet, der die Ausführung von E/A-Anforderungen nicht zulässt. Problematische PG-Zustände sind peering, stale, incomplete und das Fehlen von active (wenn diese Zustände nicht schnell gelöscht werden). Detaillierte Informationen dazu, welche PGs betroffen sind, erhalten Sie durch Ausführen von:
cephuser@adm >ceph health detailIn den meisten Fällen besteht die Ursache darin, dass einer oder mehrere OSDs aktuell inaktiv sind. Der Zustand bestimmter problematischer PGs kann abgefragt werden mit:
cephuser@adm >ceph tell pgid query- PG_DEGRADED
Die Datenredundanz ist für einige Daten reduziert. Dies bedeutet, dass der Cluster nicht über die gewünschte Anzahl der Reproduktionen für alle Daten (für reproduzierte Pools) oder Erasure Code-Fragmente (für Erasure Coded Pools) verfügt. Dies ist insbesondere dann der Fall, wenn bei einer oder mehreren PGs das Flag degraded oder undersized gesetzt wurde (es sind nicht genügend Instanzen dieser Placement Group im Cluster vorhanden) oder wenn einige Zeit das Flag clean nicht gesetzt war. Detaillierte Informationen dazu, welche PGs betroffen sind, erhalten Sie durch Ausführen von:
cephuser@adm >ceph health detailIn den meisten Fällen besteht die Ursache darin, dass einer oder mehrere OSDs aktuell inaktiv sind. Der Zustand bestimmter problematischer PGs kann abgefragt werden mit:
cephuser@adm >ceph tell pgid query- PG_DEGRADED_FULL
Die Datenredundanz ist möglicherweise für einige Daten reduziert oder in Gefahr, weil freier Speicherplatz im Cluster fehlt. Dies ist insbesondere dann der Fall, wenn für eine oder mehrere PGs das Flag backfill_toofull oder recovery_toofull gesetzt wurde. Dies bedeutet, dass der Cluster keine Daten migrieren oder wiederherstellen kann, weil einer oder mehrere OSDs den Grenzwert backfillfull überschritten haben.
- PG_DAMAGED
Beim Daten-Scrubbing (weitere Informationen hierzu finden Sie in Abschnitt 17.6, „Scrubbing von Platzierungsgruppen“) wurden einige Probleme bezüglich der Datenkonsistenz im Cluster erkannt. Dies ist insbesondere dann der Fall, wenn für eine oder mehrere PGs das Flag inconsistent oder snaptrim_error gesetzt wurde. Dadurch wird angegeben, dass bei einem früheren Scrubbing-Vorgang ein Problem gefunden wurde. Möglicherweise wurde auch das Flag repair gesetzt, was bedeutet, dass eine derartige Inkonsistenz gerade repariert wird.
- OSD_SCRUB_ERRORS
Bei kürzlich durchgeführten OSD-Scrubbing-Vorgängen wurden Inkonsistenzen erkannt.
- CACHE_POOL_NEAR_FULL
Ein Cache-Schicht-Pool ist fast voll. In diesem Kontext wird „full“ durch die Eigenschaften target_max_bytes und target_max_objects des Caches Pools bestimmt. Wenn der Pool den Grenzwert erreicht, werden Schreibanforderungen an den Pool möglicherweise blockiert und Daten aus dem Cache entfernt und gelöscht. Dieser Zustand führt normalerweise zu sehr hohen Latenzen und schlechter Leistung. Der Grenzwert für die Größe des Pools kann angepasst werden mit:
cephuser@adm >ceph osd pool set cache-pool-name target_max_bytes bytescephuser@adm >ceph osd pool set cache-pool-name target_max_objects objectsDie normale Aktivität zum Leeren des Caches wird möglicherweise auch gedrosselt durch die reduzierte Verfügbarkeit oder Leistung der Basisschicht oder durch die Cluster-Last insgesamt.
- TOO_FEW_PGS
Die Anzahl der verwendeten PGs liegt unterhalb des konfigurierbaren Grenzwerts der
mon_pg_warn_min_per_osd-PGs pro OSD. Dies führt eventuell dazu, dass die Daten nicht optimal auf die OSDs im Cluster verteilt und ausgeglichen werden und die Leistung insgesamt verschlechtert wird.- TOO_MANY_PGS
Die Anzahl der verwendeten PGs liegt oberhalb des konfigurierbaren Grenzwerts der
mon_pg_warn_min_per_osd-PGs pro OSD. Dies führt möglicherweise zu höherer Arbeitsspeicherauslastung für OSD-Daemons, langsamerem Peering nach Änderungen des Cluster-Zustands (beispielsweise OSD-Neustarts, Hinzufügen oder Entfernen) sowie höherer Last für Ceph Managers und Ceph Monitors.Der Wert
pg_numfür bestehende Pools kann nicht reduziert werden, der Wertpgp_numjedoch schon. Dadurch werden einige PGs effizient auf denselben Gruppen von OSDs angeordnet, wodurch einige der oben beschriebenen negativen Auswirkungen abgeschwächt werden. Derpgp_num-Wert kann angepasst werden mit:cephuser@adm >ceph osd pool set pool pgp_num value- SMALLER_PGP_NUM
Bei einem oder mehreren Pools ist der
pgp_num-Wert kleiner als derpg_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, dasspgp_nummitpg_numabgeglichen wird, was die Datenmigration auslöst. Verwenden Sie hierzu:cephuser@adm >ceph osd pool set pool pgp_num pg_num_value- MANY_OBJECTS_PER_PG
Bei mindestens einem Pool ist die durchschnittliche Anzahl von Objekten pro PG erheblich höher als der Durchschnitt im Cluster insgesamt. Der spezifische Grenzwert wird gesteuert durch den Konfigurationswert
mon_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 Konfigurationsoptionmon_pg_warn_max_object_skewan den Monitors erhöht werden.- POOL_APP_NOT_ENABLED¶
Es ist zwar ein Pool mit einem oder mehreren Objekten vorhanden, wurde jedoch nicht für die Verwendung durch eine bestimmte Anwendung gekennzeichnet. Heben Sie diese Warnmeldung auf, indem Sie den Pool für die Verwendung durch eine Anwendung kennzeichnen. Beispiel, wenn der Pool von RBD verwendet wird:
cephuser@adm >rbd pool init pool_nameWenn der Pool durch eine benutzerdefinierte Anwendung „foo“ verwendet wird, können Sie ihn auch mit dem Kommando der untersten Ebene kennzeichnen:
cephuser@adm >ceph osd pool application enable foo- POOL_FULL
Einer oder mehrere Pools haben das Kontingent erreicht (oder erreichen es bald). Der Grenzwert zum Auslösen dieser Fehlerbedingung wird durch die Konfigurationsoption
mon_pool_quota_crit_thresholdgesteuert. Pool-Kontingente werden nach oben oder unten angepasst (oder entfernt) mit:cephuser@adm >ceph osd pool set-quota pool max_bytes bytescephuser@adm >ceph osd pool set-quota pool max_objects objectsDurch 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_thresholdgesteuert. Pool-Kontingente werden nach oben oder unten angepasst (oder entfernt) mit:cephuser@adm >ceph osd osd pool set-quota pool max_bytes bytescephuser@adm >ceph osd osd pool set-quota pool max_objects objectsDurch Festlegen des Kontingentwerts auf 0 wird das Kontingent deaktiviert.
- OBJECT_MISPLACED
Mindestens ein Objekt im Cluster ist nicht auf dem Knoten gespeichert, auf dem es laut Cluster gespeichert werden soll. Dies ist ein Anzeichen dafür, dass die Datenmigration aufgrund einer kürzlich vorgenommenen Änderung am Cluster noch nicht abgeschlossen ist. Falsch platzierte Daten stellen an sich keine Gefahr dar. Die Datenkonsistenz ist niemals in Gefahr und alte Kopien von Objekten werden niemals entfernt, bevor die gewünschte Anzahl an neuen Kopien (an den gewünschten Speicherorten) vorhanden ist.
- OBJECT_UNFOUND
Ein oder mehrere Objekte im Cluster werden nicht gefunden. Dies ist insbesondere dann der Fall, wenn die OSDs wissen, dass eine neue oder aktualisierte Kopie eines Objekts vorhanden sein sollte, jedoch keine Kopie dieser Version des Objekts auf OSDs gefunden wurden, die zurzeit aktiv sind. Lese- oder Schreibanforderungen an die „unfound“-Objekte werden blockiert. Im Idealfall kann das inaktive OSD, auf dem sich das aktuelle Exemplar des nicht gefundenen Objekts befindet, wieder aktiviert werden. Dafür in Frage kommende OSDs können anhand des Peering-Zustands für die PGs identifiziert werden, die für das nicht gefundene Objekt zuständig sind:
cephuser@adm >ceph tell pgid query- REQUEST_SLOW
Die Verarbeitung einer oder mehrerer OSD-Anforderungen dauert sehr lange. Dies ist möglicherweise ein Anzeichen für eine extreme Last, ein langsames Speichergerät oder einen Softwarefehler. Mit folgendem Kommando, das auf dem OSD-Host ausgeführt wird, fragen Sie die Anforderungswarteschlange auf den in Frage kommenden OSDs ab:
cephuser@adm >ceph daemon osd.id opsSie sehen eine Zusammenfassung der langsamsten kürzlich vorgenommenen Anforderungen:
cephuser@adm >ceph daemon osd.id dump_historic_opsSie finden den Standort eines OSDs mit:
cephuser@adm >ceph osd find osd.id- REQUEST_STUCK
Mindestens eine OSD-Anforderung wurde relativ lange Zeit blockiert, z. B. 4.096 Sekunden. Dies ist ein Anzeichen dafür, dass sich entweder der Cluster für einen längeren Zeitraum in einem fehlerhaften Zustand befindet (beispielsweise wenn nicht genügend OSDs ausgeführt werden oder inaktive PGs vorliegen) oder wenn interne Probleme am OSD aufgetreten sind.
- PG_NOT_SCRUBBED
Es wurde länger kein Scrubbing bei mindestens einer PG durchgeführt (weitere Informationen hierzu finden Sie in Abschnitt 17.6, „Scrubbing von Platzierungsgruppen“). Bei PGs wird normalerweise alle
mon_scrub_intervalSekunden ein Scrubbing durchgeführt und diese Warnmeldung wird ausgelöst, wenn diesemon_warn_not_scrubbed-Intervalle ohne Scrubbing abgelaufen sind. Bei PGs wird kein Scrubbing durchgeführt, wenn sie nicht als intakt („clean“) gekennzeichnet sind. Dies kann vorkommen, wenn sie falsch platziert wurden oder eingeschränkt leistungsfähig sind (weitere Informationen hierzu finden Sie oben unter PG_AVAILABILITY und PG_DEGRADED). Ein Scrubbing einer intakten PG wird manuell initiiert mit:cephuser@adm >ceph pg scrub pgid- PG_NOT_DEEP_SCRUBBED
Bei einer oder mehreren PGs wurden länger kein Deep Scrubbing durchgeführt (weitere Informationen hierzu finden Sie in Abschnitt 17.6, „Scrubbing von Platzierungsgruppen“). Bei PGs wird normalerweise alle
osd_deep_mon_scrub_intervalSekunden ein Scrubbing durchgeführt und diese Warnmeldung wird ausgelöst, wenn diesermon_warn_not_deep_scrubbed-Zeitraum ohne Scrubbing abgelaufen ist. Bei PGs wird kein (Deep) Scrubbing durchgeführt, wenn sie nicht als intakt („clean“) gekennzeichnet sind. Dies kann vorkommen, wenn sie falsch platziert wurden oder eingeschränkt leistungsfähig sind (weitere Informationen hierzu finden Sie oben unter PG_AVAILABILITY und PG_DEGRADED). Ein Scrubbing einer intakten PG wird manuell initiiert mit:cephuser@adm >ceph pg deep-scrub pgid
Tipp
Wenn Sie nicht standardmäßige Standorte für Ihre Konfiguration oder Ihren Schlüsselbund angegeben haben, können Sie diese angeben mit:
root # ceph -c /path/to/conf -k /path/to/keyring health12.3 Überprüfen der Nutzungsstatistik eines Clusters #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.
cephuser@adm > ceph df
--- RAW STORAGE ---
CLASS SIZE AVAIL USED RAW USED %RAW USED
hdd 30 GiB 27 GiB 121 MiB 3.1 GiB 10.40
TOTAL 30 GiB 27 GiB 121 MiB 3.1 GiB 10.40
--- POOLS ---
POOL ID STORED OBJECTS USED %USED MAX AVAIL
device_health_metrics 1 0 B 0 0 B 0 8.5 GiB
cephfs.my_cephfs.meta 2 1.0 MiB 22 4.5 MiB 0.02 8.5 GiB
cephfs.my_cephfs.data 3 0 B 0 0 B 0 8.5 GiB
.rgw.root 4 1.9 KiB 13 2.2 MiB 0 8.5 GiB
myzone.rgw.log 5 3.4 KiB 207 6 MiB 0.02 8.5 GiB
myzone.rgw.control 6 0 B 8 0 B 0 8.5 GiB
myzone.rgw.meta 7 0 B 0 0 B 0 8.5 GiB
Der Abschnitt RAW STORAGE der Ausgabe gibt einen Überblick über den Speicherplatz, den Ihr Cluster für die Daten nutzt.
CLASS: Die Speicherklasse des Geräts. Weitere detaillierte Informationen zu Geräteklassen finden Sie in Abschnitt 17.1.1, „Geräteklassen“.SIZE: Die gesamte Speicherkapazität des Clusters.AVAIL: Der verfügbare freie Speicherplatz im Cluster.USED: Der Speicherplatz (über alle OSDs akkumuliert), der ausschließlich für Datenobjekte auf dem Blockgerät zugewiesen ist.RAW USED: Summe des belegten Speicherplatzes („USED“) und des Speicherplatzes auf dem Blockgerät, der für Ceph-Zwecke zugewiesen/reserviert ist, z. B. der BlueFS-Bereich für BlueStore.% RAW USED: Der Prozentsatz des genutzten Basisspeicherplatzes. Verwenden Sie diese Zahl in Verbindung mitfull ratioundnear full ratio, um sicherzustellen, dass die Kapazität des Clusters nicht voll ausgelastet wird. Weitere Informationen finden Sie in Abschnitt 12.8, „Speicherkapazität“.
Anmerkung: Füllstand des Clusters
Wenn sich der Rohspeicherfüllstand dem Wert 100 % nähert, müssen Sie neuen Speicher in den Cluster aufnehmen. Eine höhere Auslastung führt möglicherweise zu einzelnen vollen OSDs und Problemen mit dem Cluster-Zustand.
Listen Sie mit dem Kommando
ceph osd df treeden Füllstand aller OSDs auf.
Im Abschnitt POOLS der Ausgabe finden Sie eine Liste der Pools und die nominelle Auslastung der einzelnen Pools. Die Ausgabe in diesem Abschnitt umfasst keine Reproduktionen, Klone oder Snapshots. Beispiel: Wenn Sie ein Objekt mit 1 MB Daten speichern, beträgt die nominelle Auslastung 1 MB. Die tatsächliche Auslastung beträgt jedoch möglicherweise 2 MB oder mehr, je nach Anzahl der Reproduktionen, Klone und Snapshots.
POOL: Der Name des Pools.ID: Die Pool-ID.STORED: Die vom Benutzer gespeicherte Datenmenge.OBJECTS: Die nominelle Anzahl der pro Pool gespeicherten Objekte.USED: Der Speicherplatz (in kB), der von allen OSD-Knoten ausschließlich für Daten zugewiesen ist.%USED: Der nominelle Prozentsatz des genutzten Speichers pro Pool.MAX AVAIL: Der maximal verfügbare Speicherplatz im jeweiligen Pool.
Anmerkung
Die Zahlen im Abschnitt POOLS sind nominell. Sie sind nicht inklusive der Anzahl der Reproduktionen, Snapshots oder Klone zu verstehen. Folglich entspricht die Summe der Zahlen unter USED und %USED nicht den Zahlen unter RAW USED und %RAW USED im Abschnitt RAW STORAGE der Ausgabe.
12.4 Überprüfen des OSD-Status #Edit source
Mit folgenden Kommandos prüfen Sie die OSDs, um sicherzustellen, dass sie aktiv sind:
cephuser@adm > ceph osd statoder
cephuser@adm > ceph osd dumpOSDs lassen sich auch entsprechend ihrer Position in der CRUSH-Map anzeigen.
Mit ceph osd tree werden ein CRUSH-Baum mit einem Host und dessen OSDs, der Status der Aktivität und deren Gewicht ausgegeben:
cephuser@adm > ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 3 0.02939 root default
-3 3 0.00980 rack mainrack
-2 3 0.00980 host osd-host
0 1 0.00980 osd.0 up 1.00000 1.00000
1 1 0.00980 osd.1 up 1.00000 1.00000
2 1 0.00980 osd.2 up 1.00000 1.0000012.5 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-Knoten werden durch ceph health gemeldet:
cephuser@adm > ceph health
HEALTH_WARN 1 nearfull osds
osd.2 is near full at 85%oder
cephuser@adm > ceph health
HEALTH_ERR 1 nearfull osds, 1 full osds
osd.2 is near full at 85%
osd.3 is full at 97%Am besten fügen Sie bei einem vollen Cluster neue OSD-Hosts/-Datenträger hinzu. Dadurch kann der Cluster Daten auf dem neu verfügbaren Speicherplatz verteilen.
Tipp: Verhindern voller OSDs
Wenn ein OSD voll wird, also 100 % der Festplattenkapazität nutzt, stürzt er normalerweise schnell und ohne Warnmeldung ab. Nachfolgend sehen Sie einige Tipps, die Sie beim Verwalten von OSD-Knoten beachten sollten.
Der Festplattenspeicherplatz der einzelnen OSDs (normalerweise eingehängt unter
/var/lib/ceph/osd/osd-{1,2..}) muss jeweils auf eine dedizierte zugrundeliegende Festplatte oder Partition gestellt werden.Überprüfen Sie die Ceph-Konfigurationsdateien und stellen Sie sicher, dass Ceph die Protokolldatei nicht auf den Festplatten/Partitionen speichert, die explizit für die OSDs vorgesehen sind.
Vergewissern Sie sich, dass kein anderer Prozess auf die Festplatten/Partitionen schreibt, die explizit für die OSDs vorgesehen sind.
12.6 Prüfen des Monitorstatus #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:
cephuser@adm > ceph mon statoder
cephuser@adm > ceph mon dumpFühren Sie zum Prüfen des Quorum-Status für den Monitor-Cluster Folgendes aus:
cephuser@adm > ceph quorum_statusCeph gibt den Quorum-Status zurück. Beispielsweise gibt ein Ceph-Cluster, der aus drei Monitors besteht, möglicherweise Folgendes zurück:
{ "election_epoch": 10,
"quorum": [
0,
1,
2],
"monmap": { "epoch": 1,
"fsid": "444b489c-4f16-4b75-83f0-cb8097468898",
"modified": "2011-12-12 13:28:27.505520",
"created": "2011-12-12 13:28:27.505520",
"mons": [
{ "rank": 0,
"name": "a",
"addr": "192.168.1.10:6789\/0"},
{ "rank": 1,
"name": "b",
"addr": "192.168.1.11:6789\/0"},
{ "rank": 2,
"name": "c",
"addr": "192.168.1.12:6789\/0"}
]
}
}12.7 Überprüfen des Zustands von Platzierungsgruppen #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 12.9, „Überwachen der OSDs und Platzierungsgruppen“.
12.8 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: Erhöhen der Speicherkapazität
Achten Sie bei der Überwachung des Clusters auf Warnmeldungen zur nearfull-Quote. Dies bedeutet, dass ein Ausfall eines (oder mehrerer) OSDs zu einer Serviceunterbrechung führen würde. Ziehen Sie in Erwägung, weitere OSDs einzufügen und damit die Speicherkapazität zu erhöhen.
In einem gängigen Szenario für Test-Cluster entfernt ein Systemadministrator ein Ceph OSD aus dem Ceph-Speicher-Cluster und beobachtet dann den Neuausgleich des Clusters. Anschließend wird ein weiterer Ceph OSD entfernt usw., bis der Cluster schließlich die „full“-Quote erreicht und zum Stillstand kommt. Selbst bei einem Test-Cluster wird eine gewisse Kapazitätsplanung empfohlen. Durch die Planung können Sie einschätzen, wie viel Ersatzkapazität Sie benötigen, damit die Hochverfügbarkeit aufrechterhalten werden kann. Im Idealfall sollten Sie eine ganze Reihe von Ceph OSD-Ausfällen einplanen, bei der Cluster wieder den Status active + clean erreichen kann, ohne die betreffenden Ceph OSDs austauschen zu müssen. Sie können einen Cluster im Status active + degraded ausführen, doch unter normalen Betriebsbedingungen ist dies nicht ideal.
Das nachfolgende Diagramm zeigt einen vereinfachten Ceph-Speicher-Cluster mit 33 Ceph Knoten und je einem Ceph OSD pro Host, die jeweils Lese- und Schreibvorgänge auf einem 3-TB-Laufwerk ausführen. Dieser Beispiel-Cluster besitzt eine maximale Istkapazität von 99 TB. Die Option mon osd full ratio ist auf 0,95 eingestellt. Sobald der Speicherplatz im Cluster unter 5 TB der Restkapazität fällt, werden Lese- und Schreibvorgänge der Clients unterbunden. Die Betriebskapazität des Speicher-Clusters liegt also bei 95 TB, nicht bei 99 TB.
Abbildung 12.1: Ceph-Cluster #
In einem solchen Cluster ist ein Ausfall von einem oder zwei OSDs durchaus normal. In einem weniger häufigen, jedoch denkbaren Szenario fällt der Router oder die Netzversorgung eines Racks aus, sodass mehrere OSDs gleichzeitig ausfallen (z. B. OSDs 7–12). In einem solchen Szenario muss der Cluster dennoch weiterhin betriebsbereit bleiben und den Status active + clean erreichen – selbst wenn dafür einige Hosts mit zusätzlichen OSDs in kürzester Zeit eingefügt werden müssen. Wenn die Kapazitätsauslastung zu hoch ist, verlieren Sie unter Umständen keine Daten. Doch beim Beheben eines Ausfalls in einer Fehlerdomäne ist die Datenverfügbarkeit dennoch beeinträchtigt, wenn die Kapazitätsauslastung des Clusters die für Code übersteigt. Aus diesem Grund wird zumindest eine grobe Kapazitätsplanung empfohlen.
Ermitteln Sie zwei Zahlen für Ihren Cluster:
die Anzahl der OSDs,
die Gesamtkapazität des Clusters.
Wenn Sie die Gesamtkapazität des Clusters durch die Anzahl der OSDs im Cluster dividieren, erhalten Sie die Durchschnittskapazität eines OSDs im Cluster. Multiplizieren Sie diese Zahl ggf. mit der Anzahl der OSDs, die laut Ihren Erwartungen im Normalbetrieb gleichzeitig ausfallen könnten (relativ kleine Zahl). Multiplizieren Sie schließlich die Kapazität des Clusters mit der „full“-Quote. Damit erhalten Sie die maximale Betriebskapazität. Subtrahieren Sie dann die Datenmenge der OSDs, die vermutlich ausfallen werden, und Sie erhalten eine angemessene „full“-Quote. Wenn Sie den obigen Vorgang mit einer größeren Anzahl an OSD-Ausfällen (einem OSD-Rack) wiederholen, erhalten Sie eine angemessene Zahl für die „near full“-Quote.
Die folgenden Einstellungen gelten nur bei der Cluster-Erstellung und werden dann in der OSD-Karte gespeichert:
[global] mon osd full ratio = .80 mon osd backfillfull ratio = .75 mon osd nearfull ratio = .70
Tipp
Diese Einstellungen gelten nur bei der Cluster-Erstellung. Später müssen sie mit den Kommandos ceph osd set-nearfull-ratio und ceph osd set-full-ratioin der OSD-Karte geändert werden.
- mon osd full ratio
Prozentsatz des belegten Datenträgerspeichers, bevor ein OSD als
fullgilt. Der Standardwert lautet 0,95.- mon osd backfillfull ratio
Prozentsatz des belegten Datenträgerspeichers, bevor ein OSD als zu
fullfür einen Abgleich gilt. Der Standardwert lautet 0,90.- mon osd nearfull ratio
Prozentsatz des belegten Datenträgerspeichers, bevor ein OSD als
nearfullgilt. Der Standardwert lautet 0,85.
Tipp: Prüfen des OSD-Gewichts
Wenn einige OSDs nearfull sind, andere aber noch reichlich Kapazität besitzen, liegt eventuell ein Problem mit dem CRUSH-Gewicht für die nearfull-OSDs vor.
12.9 Überwachen der OSDs und Platzierungsgruppen #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: Zugriff im Fehlerfall
Bei einem Fehler in einem Teil des Clusters können Sie unter Umständen nicht auf ein bestimmtes Objekt zugreifen. Dies bedeutet nicht, dass Sie nicht auf andere Objekte zugreifen können. Wenn ein Fehler auftritt, befolgen Sie die Anweisungen für die Überwachung Ihrer OSDs und Platzierungsgruppen. Nehmen Sie dann die Fehlerbehebung vor.
Ceph repariert sich im Allgemeinen selbst. Bleiben Probleme jedoch längere Zeit bestehen, trägt die Überwachung der OSDs und Platzierungsgruppen dazu bei, das Problem zu erkennen.
12.9.1 Überwachen der OSDs #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: Fehlerhafter Zustand
Ist ein OSD „down“ und „in“, liegt ein Problem vor und der Cluster ist nicht in einem einwandfreien Zustand.
Wenn Sie ein Kommando wie ceph health, ceph -s oder ceph -w ausführen, meldet der Cluster nicht immer HEALTH OK. Im Hinblick auf OSDs ist unter den folgenden Umständen zu erwarten, dass der Cluster nicht die Meldung HEALTH OK zurückgibt:
Sie haben den Cluster noch nicht gestartet (er kann nicht antworten).
Sie haben den Cluster gestartet oder neu gestartet. Er ist jedoch noch nicht betriebsbereit, da die Platzierungsgruppen noch erstellt werden und die OSDs gerade den Peering-Prozess durchlaufen.
Sie haben ein OSD hinzugefügt oder entfernt.
Sie haben die Clusterzuordnung geändert.
Bei der Überwachung der OSDs ist in jedem Fall darauf zu achten, dass alle OSDs im Cluster betriebsbereit und aktiv sind, wenn der Cluster selbst betriebsbereit und aktiv ist. Mit folgendem Kommando prüfen Sie, ob alle OSDs aktiv sind:
root # ceph osd stat
x osds: y up, z in; epoch: eNNNN
Das Ergebnis umfasst die Gesamtanzahl der OSDs (x), die Anzahl der OSDs mit dem Status „up“ (y), die Anzahl der OSDs mit dem Status „in“ (z) sowie die Zuordnungsepoche (eNNNN). Wenn die Anzahl der „in“-OSDs höher ist als die Anzahl der „up“-OSDs, ermitteln Sie die nicht aktiven ceph-osd-Daemons mit folgendem Kommando:
root # ceph osd tree
#ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 2.00000 pool openstack
-3 2.00000 rack dell-2950-rack-A
-2 2.00000 host dell-2950-A1
0 ssd 1.00000 osd.0 up 1.00000 1.00000
1 ssd 1.00000 osd.1 down 1.00000 1.00000Wenn beispielsweise ein OSD mit ID 1 inaktiv ist, starten Sie es mit:
cephuser@osd > sudo systemctl start ceph-CLUSTER_ID@osd.0.serviceWeitere Informationen zu Problemen im Zusammenhang mit OSDs, die angehalten wurden oder sich nicht neu starten lassen, finden Sie im Section 4.3, “OSDs not running”.
12.9.2 Zuweisen von Platzierungsgruppen #Edit source
Beim Zuweisen von Platzierungsgruppen zu den OSDs prüft CRUSH die Anzahl der Reproduktionen für den Pool und weist die Platzierungsgruppe den OSDs so zu, dass jede Reproduktion dieser Platzierungsgruppe einem anderen OSD zugeordnet wird. Wenn der Pool beispielsweise drei Reproduktionen einer Platzierungsgruppe benötigt, weist CRUSH die Reproduktionen beispielsweise osd.1, osd.2 und osd.3 zu. CRUSH strebt dabei eine pseudozufällige Platzierung an, bei der die in der CRUSH-Zuordnung festgelegten Fehlerdomänen berücksichtigt werden, sodass Platzierungsgruppen nur in seltenen Fällen den jeweils nächstgelegenen OSDs in einem großen Cluster zugewiesen werden. Der OSD-Satz, in dem sich die Reproduktion einer bestimmten Platzierungsgruppe befinden soll, wird als „acting“-Satz bezeichnet. In einigen Fällen ist ein OSD im „acting“-Satz nicht betriebsbereit oder kann anderweitig keine Anforderungen nach Objekten in der Platzierungsgruppe verarbeiten. In diesen Situationen liegt eines der folgenden Szenarien vor:
Sie haben ein OSD hinzugefügt oder entfernt. CRUSH hat die Platzierungsgruppe dann anderen OSDs zugewiesen und damit die Zusammensetzung des agierenden Satzes verändert, sodass die Migration der Daten im Rahmen eines „backfill“-Prozesses ausgelöst wurde.
Ein OSD war „down“, wurde neu gestartet und wird nunmehr wiederhergestellt.
Ein OSD im „acting“-Satz ist „down“ oder kann keine Anforderungen verarbeiten und ein anderer OSD hat vorübergehend dessen Aufgaben übernommen.
Ceph verarbeitet eine Client-Anforderung mit dem „up“-Satz, also dem Satz der OSDs, die die Anforderungen tatsächlich verarbeiten. In den meisten Fällen sind der „up“-Satz und der „acting“-Satz praktisch identisch. Ist dies nicht der Fall, kann dies darauf hinweisen, dass Ceph gerade Daten migriert, ein OSD wiederhergestellt wird oder ein Problem vorliegt (in diesen Szenarien gibt Ceph in der Regel den Status
HEALTH WARNmit der Meldung „stuck stale“ zurück).
Mit folgendem Kommando rufen Sie eine Liste der Platzierungsgruppen ab:
cephuser@adm > ceph pg dumpMit folgendem Kommando stellen Sie fest, welche OSDs sich im „acting“-Satz oder im „up“-Satz einer bestimmten Platzierungsgruppe befinden:
cephuser@adm > ceph pg map PG_NUM
osdmap eNNN pg RAW_PG_NUM (PG_NUM) -> up [0,1,2] acting [0,1,2]Das Ergebnis umfasst die osdmap-Epoche (eNNN), die Nummer der Platzierungsgruppe (PG_NUM), die OSDs im „up“-Satz („up“) sowie die OSDs im „acting“-Satz („acting“):
Tipp: Hinweis auf Clusterprobleme
Wenn der „up“-Satz und der „acting“-Satz nicht übereinstimmen, kann dies darauf hinweisen, dass der Cluster sich gerade ausgleicht oder dass ein potenzielles Problem mit dem Cluster vorliegt.
12.9.3 Peering #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).
Abbildung 12.2: Peering-Schema #
12.9.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 einen Pool erstellt, und die Platzierungsgruppen haben noch nicht das Peering durchgeführt.
Die Platzierungsgruppen werden wiederhergestellt.
Sie haben einen OSD in einen Cluster eingefügt oder daraus entfernt.
Sie haben die CRUSH-Zuordnung geändert, und Ihre Platzierungsgruppen werden migriert.
Die verschiedenen Reproduktionen einer Platzierungsgruppe enthalten inkonsistente Daten.
Ceph führt das Scrubbing der Reproduktionen einer Platzierungsgruppe durch.
Die Speicherkapazität reicht nicht für die Ausgleichsoperationen von Ceph aus.
Wenn Ceph aus den obigen Gründen die Meldung HEALTH WARN ausgibt, ist dies kein Grund zur Sorge. In zahlreichen Fällen kann sich der Cluster selbst wiederherstellen. In bestimmten Fällen müssen Sie jedoch selbst gewisse Maßnahmen ergreifen. Bei der Überwachung der OSDs ist in jedem Fall darauf zu achten, dass alle Platzierungsgruppen den Status „active“ und nach Möglichkeit auch den Status „clean“ besitzen, wenn der Cluster selbst betriebsbereit und aktiv ist. Mit folgendem Kommando rufen Sie den Status aller Platzierungsgruppen ab:
cephuser@adm > ceph pg stat
x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB availDas 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 ratiooderfull ratio.Die Daten werden aufgrund eines Fehlers in der CRUSH-Konfiguration nicht im Cluster verteilt.
Tipp: Platzierungsgruppen-IDs
Die Platzierungsgruppen-IDs bestehen aus der Pool-Nummer (nicht dem Pool-Namen), gefolgt von einem Punkt (.) und der eigentlichen Platzierungsgruppen-ID (eine hexadezimale Zahl). Die Pool-Nummern und zugehörige Namen sind in der Ausgabe des Kommandos ceph osd lspools ersichtlich. Der Standard-Pool rbd entspricht beispielsweise der Pool-Nummer 0. Eine vollständige Platzierungsgruppen-ID weist das folgende Format auf:
POOL_NUM.PG_ID
und sieht in der Regel wie folgt aus:
0.1f
Mit folgendem Kommando rufen Sie eine Liste der Platzierungsgruppen ab:
cephuser@adm > ceph pg dumpSie können auch die Ausgabe im JSON-Format formatieren und in einer Datei speichern:
cephuser@adm > ceph pg dump -o FILE_NAME --format=jsonMit folgendem Kommando fragen Sie eine bestimmte Platzierungsgruppe ab:
cephuser@adm > ceph pg POOL_NUM.PG_ID queryIn der nachfolgenden Liste werden die gängigen Statusangaben für Platzierungsgruppen näher beschrieben.
- CREATING
Beim Erstellen eines Pools wird die angegebene Anzahl der Platzierungsgruppen erstellt. Ceph gibt „creating“ zurück, während eine Platzierungsgruppe erstellt wird. Beim Erstellen führen die OSDs im „acting“-Satz der Platzierungsgruppe das Peering durch. Nach dem Peering sollte die Platzierungsgruppe den Status „active+clean“ aufweisen, sodass ein Ceph-Client in die Platzierungsgruppe schreiben kann.
Abbildung 12.3: Statusangaben für Platzierungsgruppen #
- PEERING
Beim Peering einer Platzierungsgruppe stimmt Ceph die OSDs, auf denen die Reproduktionen der Platzierung gespeichert sind, hinsichtlich des Status der Objekte und Metadaten in der Platzierungsgruppe ab. Nach dem Peering zeigen also alle OSDs, auf denen die Platzierungsgruppe gespeichert ist, den aktuellen Status dieser Gruppe. Der Abschluss des Peering-Prozesses bedeutet jedoch nicht, dass jede Reproduktion den aktuellen Inhalt enthält.
Anmerkung: Maßgeblicher Verlauf
Ceph bestätigt nur dann einen Schreibvorgang auf einen Client, wenn alle OSDs im „acting“-Satz den Schreibvorgang dauerhaft speichern. Auf diese Weise ist sichergestellt, dass mindestens ein Mitglied des „acting“-Satzes einen Datensatz pro bestätigtem Schreibvorgang seit dem letzten erfolgreichen Peering-Vorgang besitzt.
Anhand der sorgfältigen Aufzeichnungen der einzelnen bestätigten Schreiboperationen kann Ceph einen neuen maßgeblichen Verlauf der Platzierungsgruppe aufstellen und fortführen – also einen vollständigen, geordneten Satz von Operationen, mit dem das Exemplar einer Platzierungsgruppe, die sich auf einem OSD befindet, auf den neuesten Stand gebracht werden kann.
- AKTIV
Nach Abschluss des Peering-Prozesses kann eine Platzierungsgruppe den Status
activeerhalten. Im Statusactivestehen 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
cleanaufweist, 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 intervalgesteuert (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 Einstellungosd recovery thread timeoutlegt eine Thread-Zeitüberschreitung fest, da mehrere OSDs gestaffelt ausfallen, neu starten und das Peering erneut durchführen können. Die Einstellungosd recovery max activebeschränkt die Anzahl der Wiederherstellungsanforderungen, die ein OSD gleichzeitig verarbeitet, damit der OSD nicht ausfällt. Die Einstellungosd recovery max chunkbeschrä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 backfillsdie Anzahl gleichzeitiger Ausgleichsvorgänge mit einem OSD auf maximal 10 Vorgänge. Mitbackfill full ratiokann ein OSD eine Ausgleichsanforderung verweigern, wenn der OSD sich seiner „full“-Quote nähert (standardmäßig 90 %). Dieser Wert kann mit dem Kommandoceph osd set-backfillfull-ratiogeändert werden. Wenn ein OSD eine Ausgleichsanforderung verweigert, kann der OSD die Anforderung mitosd backfill retry intervalwiederholen (standardmäßig nach 10 Sekunden). Die OSDs können außerdem die Scanintervalle (standardmäßig 64 und 512) mitosd backfill scan minundosd backfill scan maxverwalten.- REMAPPED
Wenn sich der „acting“-Satz ändert, der für eine Platzierungsgruppe zuständig ist, werden die Daten vom bisherigen „acting“-Satz zum neuen „acting“-Satz migriert. Ein neuer primärer OSD kann unter Umständen erst nach einiger Zeit die ersten Anforderungen verarbeiten. In diesem Fall weist er den bisherigen primären OSD an, weiterhin die Anforderungen zu verarbeiten, bis die Migration der Platzierungsgruppe abgeschlossen ist. Nach erfolgter Datenmigration greift die Zuordnung auf den primären OSD des neuen „acting“-Satzes zurück.
- INAKTIV
Obwohl Ceph mithilfe von Heartbeats prüft, ob die Hosts und Daemons ausgeführt werden, können die
ceph-osd-Daemons in den Status „stuck“ gelangen, in dem sie die Statistiken nicht zeitnah melden (z. B. bei einem vorübergehenden Netzwerkfehler). Standardmäßig melden die OSD-Daemons in Abständen von einer halben Sekunde (0,5) ihre Statistiken zu Platzierungsgruppen, Startvorgängen und Fehlern, also in deutlich kürzeren Abständen als die Heartbeat-Grenzwerte. Wenn der primäre OSD im „acting“-Satz keine Meldung an den Monitor übergibt oder wenn andere OSDs den primären OSD als „down“ gemeldet haben, kennzeichnen die Monitors die Platzierungsgruppe als „stale“.Beim Starten des Clusters wird häufig der Status „stale“ angezeigt, bis der Peering-Prozess abgeschlossen ist. Wenn der Cluster eine Weile aktiv war, weisen Platzierungsgruppen mit dem Status „stale“ darauf hin, dass der primäre OSD dieser Platzierungsgruppen ausgefallen ist oder keine Platzierungsgruppenstatistiken an den Monitor meldet.
12.9.5 Auffinden des Speicherorts eines Objekts #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:
cephuser@adm > ceph osd map POOL_NAME OBJECT_NAME [NAMESPACE]Beispiel 12.1: Auffinden eines Objekts #
Erstellen Sie für dieses Beispiel zunächst ein Objekt. Geben Sie den Objektnamen „test-object-1“, den Pfad zur Beispieldatei „testfile.txt“ mit einigen Objektdaten sowie den Poolnamen „data“ mit dem Kommando rados put in der Kommandozeile an:
cephuser@adm > rados put test-object-1 testfile.txt --pool=dataPrüfen Sie mit folgendem Kommando, ob das Objekt im Ceph Object Store gespeichert wurde:
cephuser@adm > rados -p data lsErmitteln Sie nun den Objektspeicherort. Ceph gibt den Speicherort des Objekts zurück:
cephuser@adm > ceph osd map data test-object-1
osdmap e537 pool 'data' (0) object 'test-object-1' -> pg 0.d1743484 \
(0.4) -> up ([1,0], p0) acting ([1,0], p0)
Löschen Sie das Beispielobjekt mit dem Kommando rados rm:
cephuser@adm > rados rm test-object-1 --pool=data