Quando un cluster è in esecuzione, è possibile utilizzare lo strumento ceph
per monitorare il cluster. Di norma, per determinare lo stato del cluster è necessario verificare lo stato di OSD, monitoraggio, gruppo di posizionamento e server dei metadati.
Per eseguire lo strumento ceph
in modalità interattiva, digitare ceph
nella riga di comando senza argomenti. La modalità interattiva è più pratica se si devono immettere più comandi ceph
in una riga. Ad esempio:
cephadm >
ceph
ceph> health
ceph> status
ceph> quorum_status
ceph> mon_status
Dopo l'avvio del cluster e prima della lettura e/o scrittura dei dati, verificare lo stato di integrità del cluster:
root #
ceph health
HEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \
node-1,node-2,node-3
Il cluster Ceph restituisce uno dei seguenti codici di stato di integrità:
Uno o più OSD sono contrassegnati. È possibile che il deamon OSD sia stato interrotto o gli OSD peer potrebbero non essere in grado di raggiungere l'OSD nella rete. Tra le cause comuni sono inclusi un'interruzione o crash del daemon, un host inattivo o un'interruzione della rete.
Verificare che l'host sia integro, il daemon avviato e la rete funzionante. Se ha avuto luogo un crash del daemon, è possibile che il file di log del daemon (/var/log/ceph/ceph-osd.*
) contenga informazioni di debug.
Tutti gli OSD in un determinato sottoalbero CRUSH vengono contrassegnati, ad esempio tutti gli OSD in un host.
Un OSD è un riferimento nella gerarchia della mappa CRUSH, ma non esiste. È possibile rimuovere l'OSD dalla gerarchia CRUSH con:
root #
ceph osd crush rm osd.ID
Le soglie di utilizzo per backfillfull, nearfull, full e/o failsafe_full non sono in ordine crescente. In particolare, ci si aspetta backfillfull < nearfull, nearfull < full e full < failsafe_full. È possibile regolare le soglie con:
root #
ceph osd set-backfillfull-ratio ratioroot #
ceph osd set-nearfull-ratio ratioroot #
ceph osd set-full-ratio ratio
Uno o più OSD hanno superato la soglia full e impediscono al cluster di fornire servizi di scrittura. È possibile verificare l'utilizzo da parte del pool con:
root #
ceph df
È possibile visualizzare il rapporto full attualmente definito con:
root #
ceph osd dump | grep full_ratio
Una soluzione immediata per ripristinare la disponibilità di scrittura consiste nell'aumentare leggermente la soglia completa (full):
root #
ceph osd set-full-ratio ratio
Aggiungere un nuovo spazio di memorizzazione al cluster installando più OSD, o eliminare i dati esistenti per liberare spazio.
Uno o più OSD hanno superato la soglia backfillfull, impedendo il ribilanciamento dei dati nel dispositivo. Questo è un avviso preliminare che informa l'utente sull'impossibilità di completare il ribilanciamento e che il cluster è quasi pieno. È possibile verificare l'utilizzo da parte del pool con:
root #
ceph df
Uno o più OSD hanno superato la soglia nearfull. Questo è un avviso preliminare che informa l'utente che il cluster è quasi pieno. È possibile verificare l'utilizzo da parte del pool con:
root #
ceph df
Sono stati impostati uno o più flag del cluster interessato. Ad eccezione di full, è possibile impostare o eliminare i flag con:
root #
ceph osd set flagroot #
ceph osd unset flag
Tali flag includono:
Il cluster è contrassegnato come full (pieno) e non può fornire servizi di scrittura.
Letture o scritture in pausa
Viene impedito l'avvio degli OSD.
I rapporti sugli errori degli OSD vengono ignorati, ad esempio quando i monitoraggi non contrassegnano gli OSD come down (inattivi).
Gli OSD contrassegnati precedentemente come out non verranno contrassegnati di nuovo come in all'avvio.
Gli ODS down (inattivi) non verranno contrassegnati automaticamente come out dopo l'intervallo configurato.
Il recupero o il ribilanciamento dei dati è sospeso.
La pulitura (vedere Sezione 6.5, «Pulitura») è disabilitata.
L'attività di suddivisione in livelli di cache è sospesa.
Uno o più ODS presentano un flag per OSD del set di interesse. Tali flag includono:
All'OSD non è consentito l'avvio.
I rapporti di errore per l'OSD specificato verranno ignorati.
Se precedentemente questo OSD è stato contrassegnato automaticamente come out in seguito a un errore, non verrà contrassegnato come in al suo avvio.
Se l'OSD è inattivo, non verrà contrassegnato automaticamente come out dopo l'intervallo configurato.
È possibile impostare ed eliminare i flag per OSD con:
root #
ceph osd add-flag osd-IDroot #
ceph osd rm-flag osd-ID
Nella mappa CRUSH vengono utilizzate impostazioni molto obsolete e deve essere aggiornata. Gli elementi ottimizzabili più obsoleti (vale a dire la versione client più vecchia in grado di connettersi al cluster) che è possibile utilizzare senza attivare questo avviso di stato di integrità vengono determinati dall'opzione di configurazione mon_crush_min_required_version
.
Nella mappa CRUSH viene utilizzato un metodo precedente, non ottimale per calcolare i valori del peso intermedio per i compartimenti straw. La mappa CRUSH deve essere aggiornata per utilizzare il metodo più recente (straw_calc_version
=1).
Uno o più pool di cache non sono configurati con un set di accessi per controllare l'utilizzo, impedendo all'agente di suddivisione in livelli di identificare gli oggetti a caldo di essere svuotati o rimossi dalla cache. È possibile configurare i set di accessi nel pool di cache con:
root #
ceph osd pool set poolname hit_set_type typeroot #
ceph osd pool set poolname hit_set_period period-in-secondsroot #
ceph osd pool set poolname hit_set_count number-of-hitsetsroot #
ceph osd pool set poolname hit_set_fpp target-false-positive-rate
Nessun OSD di versione precedente a Luminous v12 in esecuzione, ma il flag sortbitwise
non è stato impostato. È necessario impostare il flag sortbitwise
prima di poter avviare gli OSD Luminous v12 o versione più recente:
root #
ceph osd set sortbitwise
Uno o più pool hanno raggiunto la rispettiva quota e non consentono più le scritture. È possibile impostare le quote dei pool e l'utilizzo con:
root #
ceph df detail
È possibile aumentare la quota del pool con
root #
ceph osd pool set-quota poolname max_objects num-objectsroot #
ceph osd pool set-quota poolname max_bytes num-bytes
o eliminare alcuni dati esistenti per ridurre l'utilizzo.
La disponibilità dei dati è ridotta, vale a dire che il cluster non è in grado di fornire servizi di richieste di potenziali letture o scritture per alcuni dati nel cluster. Nello specifico, è impossibile fornire servizi a uno o più gruppi di posizionamento il cui stato non consente richieste IO. Gli stati dei gruppi di posizionamento problematici includono peering, stale (inattivo), incomplete (incompleto) e la mancanza di active (attivo) (se tali condizioni non vengono annullate rapidamente). Informazioni dettagliate sui gruppi di posizionamento interessati sono recuperabili da:
root #
ceph health detail
Nella maggior parte dei casi, la causa radice risiede nell'attuale stato di inattività di uno o più OSD. È possibile interrogare lo stato di specifici gruppi di posizionamento problematici con:
root #
ceph tell pgid query
La ridondanza dei dati è ridotta per alcuni dati, vale a dire che il cluster non dispone del numero desiderato di repliche per tutti i dati (per pool replicati) o di frammenti di codice di cancellazione (per pool con codice di cancellazione). Nello specifico, per uno o più gruppi di posizionamento è impostato il flag degraded o undersized (le istanze di tale gruppo di posizionamento nel cluster non sono sufficienti) oppure non è impostato il flag clean per un periodo di tempo. Informazioni dettagliate sui gruppi di posizionamento interessati sono recuperabili da:
root #
ceph health detail
Nella maggior parte dei casi, la causa radice risiede nell'attuale stato di inattività di uno o più OSD. È possibile interrogare lo stato di specifici gruppi di posizionamento problematici con:
root #
ceph tell pgid query
È possibile che la ridondanza dei dati può sia ridotta o a rischio per alcuni dati a causa della mancanza di spazio libero nel cluster. Nello specifico, per uno o più gruppi di posizionamento è impostato il flag backfill_toofull o recovery_toofull, vale a dire che il cluster non è in grado di eseguire la migrazione o recuperare i dati perché uno o più OSD superano la soglia backfillfull.
In seguito alla pulitura dei dati (vedere Sezione 6.5, «Pulitura»), nel cluster sono stati rilevati alcuni problemi di incoerenza dei dati. Nello specifico, in uno o più gruppi di posizionamento è impostato il flag inconsistent o snaptrim_error, a indicare che a seguito di un'operazione di pulitura precedente è stato individuato un problema, oppure è impostato il flag repair, a indicare che attualmente è in corso una riparazione per tale incoerenza.
Dalle puliture dell'OSD sono state rilevate incoerenze.
Un pool di livelli di cache è quasi pieno. "Pieno" in questo contesto è determinato dalla proprietà target_max_bytes e target_max_objects nel pool di cache. Quando il pool raggiunge la soglia di destinazione, è possibile che le richieste di scrittura nel pool si blocchino quando i dati vengono svuotati e rimossi dalla cache, uno stato che di norma comporta latenze molto elevate e prestazioni scarse. È possibile regolare le dimensioni di destinazione del pool di cache con:
root #
ceph osd pool set cache-pool-name target_max_bytes bytesroot #
ceph osd pool set cache-pool-name target_max_objects objects
È inoltre possibile che le attività di svuotamento e rimozione siano bloccate a causa della disponibilità ridotta, delle prestazioni del livello base o a causa del carico complessivo del cluster.
Il numero di gruppi di posizionamento in uso è sotto la soglia configurabile dei gruppi di posizionamento per OSD mon_pg_warn_min_per_osd
. Ciò può comportare una distribuzione e bilanciamento dei dati non ottimali negli OSD del cluster, riducendo le prestazioni complessive.
Il numero di gruppi di posizionamento in uso supera la soglia configurabile di gruppi di posizionamento per OSD mon_pg_warn_max_per_osd
. Ciò comporta un utilizzo della memoria maggiore per i daemon OSD, un peering più lento dopo le modifiche allo stato del cluster (ad esempio, riavvii, aggiunte o rimozioni di OSD) e un carico più elevato nei Ceph Manager e Ceph Monitor.
Mentre è impossibile ridurre il valore pg_num
per i pool esistenti, il valore pgp_num
può essere ridotto. Ciò colloca effettivamente alcuni gruppi di posizionamento sugli stessi set di OSD, mitigando alcuni impatti negativi descritti sopra. È possibile regolare il valore pgp_num
con:
root #
ceph osd pool set pool pgp_num value
Il valore pgp_num
di uno o più pool è inferiore a pg_num
. Di norma ciò indica che il numero di gruppi di posizionamento è stato incrementato senza incrementare anche comportamento del posizionamento. Di norma questo problema viene risolto impostando pgp_num
in modo che corrisponda a pg_num
, attivando la migrazione dei dati, con:
ceph osd pool set pool pgp_num pg_num_value
Uno o più pool presentano un numero di oggetti per gruppo di posizionamento che è significativamente più elevato della media complessiva del cluster. La soglia specifica è controllata dal valore di configurazione mon_pg_warn_max_object_skew
. Di norma ciò indica che i pool che contengono la maggior parte dei dati nel cluster hanno un numero di gruppi di posizionamento insufficiente e/o che altri pool che non contengono una tale quantità di dati hanno troppi gruppi di posizionamento. È possibile aumentare la soglia per annullare l'avviso di stato di integrità regolando l'opzione di configurazione mon_pg_warn_max_object_skew
nei monitoraggi.
Un pool contiene uno o più oggetti, ma non è stato contrassegnato per l'utilizzo da parte di un'applicazione particolare. Risolvere questo avviso etichettando il pool per l'utilizzo da parte di un'applicazione. Ad esempio, se il pool viene utilizzato da RBD:
root #
rbd pool init pool_name
Se il pool viene utilizzato da un'applicazione personalizzata "foo", è inoltre possibile etichettarla con il comando di livello basso:
root #
ceph osd pool application enable foo
Uno o più pool hanno raggiunto (o sono prossimi a raggiungere) la rispettiva quota. La soglia per attivare questa condizione di errore è controllata dall'opzione di configurazione mon_pool_quota_crit_threshold
. È possibile regolare verso l'alto o verso il basso (o rimuovere) le quote dei pool con:
root #
ceph osd pool set-quota pool max_bytes bytesroot #
ceph osd pool set-quota pool max_objects objects
Impostando il valore di quota a 0, questa verrà disabilitata.
Uno o più pool stanno per raggiungere la rispettiva quota. La soglia per attivare questa condizione di avviso è controllata dall'opzione di configurazione mon_pool_quota_warn_threshold
. È possibile regolare verso l'alto o verso il basso (o rimuovere) le quote dei pool con:
root #
ceph osd osd pool set-quota pool max_bytes bytesroot #
ceph osd osd pool set-quota pool max_objects objects
Impostando il valore di quota a 0, questa verrà disabilitata.
Uno o più oggetti nel cluster non è memorizzato nel nodo indicato dal cluster. Ciò indica che la migrazione dei dati non è stata ancora completata a causa di una modifica recente del cluster. La posizione errata dei dati non rappresenta una condizione pericolosa. La coerenza dei dati non è mai a rischio e le copie precedenti degli oggetti non vengono mai rimosse finché è presente il numero di copie nuove desiderato (nelle ubicazioni desiderate).
Impossibile individuare uno o più oggetti nel cluster. Nello specifico, gli OSD sanno che deve esistere una copia nuova o aggiornata di un oggetto, ma negli OSD attualmente online non è stata trovata una copia di tale versione dell'oggetto. Le richieste di lettura o scrittura negli oggetti "non trovati" verranno bloccate. Idealmente, è possibile riportare online un OSD inattivo con la copia più recente dell'oggetto non trovato. È possibile identificare gli OSD candidati in stato di peering per i gruppi di posizionamento responsabili dell'oggetto non trovato:
root #
ceph tell pgid query
Una o più richieste OSD impiegano molto tempo per l'elaborazione. Ciò può essere un'indicazione di carico estremo, dispositivo di memorizzazione lento o bug del software. È possibile interrogare la coda delle richieste sugli OSD in questione mediante l'esecuzione del seguente comando dall'host OSD:
root #
ceph daemon osd.id ops
È possibile visualizzare un riepilogo delle richieste recenti più lente:
root #
ceph daemon osd.id dump_historic_ops
È possibile individuare l'ubicazione di un OSD con:
root #
ceph osd find osd.id
Una o più richieste OSD sono state bloccate per un periodo estremamente lungo. Ciò indica che lo stato del cluster non è integro da un periodo di tempo prolungato (ad esempio il numero di OSD in esecuzione non è sufficiente) o sono presenti alcuni problemi interni con l'OSD.
Di recente non è stata eseguita la pulitura di uno o più gruppi di posizionamento (vedere Sezione 6.5, «Pulitura»). Di norma la pulitura dei gruppi di posizionamento viene eseguita ogni mon_scrub_interval
secondi e questo avviso si attiva quando sono trascorsi mon_warn_not_scrubbed
secondi senza che abbia avuto luogo una pulitura. La pulitura dei gruppi di posizionamento non verrà eseguita se questi non sono contrassegnati come puliti, il che può verificarsi se sono posizionati male o sono danneggiati (vedere PG_AVAILABILITY e PG_DEGRADED di cui sopra). È possibile avviare manualmente la pulitura di un gruppo di posizionamento pulito con:
root #
ceph pg scrub pgid
Di recente non è stata eseguita la pulitura approfondita di uno o più gruppi di posizionamento (vedere Sezione 6.5, «Pulitura»). Di norma la pulitura dei gruppi di posizionamento viene eseguita ogni osd_deep_mon_scrub_interval
secondi e questo avviso si attiva quando sono trascorsi mon_warn_not_deep_scrubbed
secondi senza che abbia avuto luogo una pulitura. La pulitura (approfondita) dei gruppi di posizionamento non verrà eseguita se questi non sono contrassegnati come puliti, il che può verificarsi se sono posizionati male o sono danneggiati (vedere PG_AVAILABILITY e PG_DEGRADED di cui sopra). È possibile avviare manualmente la pulitura di un gruppo di posizionamento pulito con:
root #
ceph pg deep-scrub pgid
Se sono state specificate ubicazioni non di default per la configurazione o il portachiavi, è possibile specificarne le ubicazioni:
root #
ceph -c /path/to/conf -k /path/to/keyring health
È possibile individuare lo stato immediato del cluster mediante ceph -s
. Ad esempio, un cluster Ceph di piccole dimensioni costituito da un monitoraggio e due OSD può stampare quanto riportato di seguito quando è in esecuzione un workload:
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
L'output fornisce le seguenti informazioni:
ID cluster
Stato di integrità del cluster
Epoca della mappa di monitoraggio e stato del quorum del monitoraggio
Epoca della mappa OSD e stato degli OSD
Versione della mappa del gruppo di posizionamento
Numero di gruppi di posizionamento e pool
Quantità di dati nozionale memorizzati e numero di oggetti memorizzati
Quantità totale di dati memorizzati.
Il valore used
riflette la quantità effettiva di spazio di memorizzazione non elaborato utilizzato. Il valore xxx GB / xxx GB
indica la quantità disponibile (il numero inferiore) della capacità di memorizzazione complessiva del cluster. Il numero nozionale riflette le dimensioni dei dati memorizzati prima che vengano replicati, clonati o che ne venga eseguito lo snapshot. Pertanto, di norma la quantità di dati effettivamente memorizzata supera la quantità nozionale memorizzata, poiché Ceph crea repliche dei dati e può anche utilizzare capacità di memorizzazione per la clonazione e gli snapshot.
Altri comandi che consentono di visualizzare informazioni immediate sullo stato sono:
ceph pg stat
ceph osd pool stats
ceph df
ceph df detail
Per ottenere informazioni aggiornate in tempo reale, inserire uno di questi comandi (tra cui ceph -s
) in un loop di attesa, ad esempio:
root
while true ; do ceph -s ; sleep 10 ; done
Premere Ctrl–C quando non si desidera più visualizzare le informazioni.
Per verificare l'utilizzo dei dati di un cluster e la distribuzione degli stessi nei pool, è possibile utilizzare l'opzione df
. È simile all'opzione df
di Linux. Eseguire le operazioni seguenti:
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
Nella sezione GLOBAL
dell'output è fornita una panoramica della quantità di spazio di memorizzazione utilizzata dal cluster per i dati.
SIZE
: capacità di memorizzazione complessiva del cluster.
AVAIL
: quantità di spazio libero disponibile nel cluster.
RAW USED
: quantità di spazio di memorizzazione non elaborato utilizzato.
% RAW USED
: percentuale di spazio di memorizzazione di dati non elaborati utilizzato. Utilizzare questo numero insieme a full ratio
e near full ratio
per assicurarsi che non si stia raggiungendo la capacità del cluster. Vedere Storage Capacity (in lingua inglese) per ulteriori dettagli.
Il livello di riempimento dello spazio di memorizzazione di dati non elaborati compreso tra 70% e 80% indica che è necessario aggiungere nuovo spazio di memorizzazione al cluster. Un utilizzo più elevato può comportare a singoli OSD pieni e a problemi di integrità del cluster.
Utilizzare il comando ceph osd df tree
per elencare il livello di riempimento di tutti gli OSD.
Nella sezione POOLS
dell'output è fornito un elenco di pool e l'utilizzo nozionale di ciascuno di essi. L'output di questa sezione non riflette repliche, cloni o snapshot. Ad esempio, se si memorizza un oggetto con 1 MB di dati, l'utilizzo nozionale sarà 1 MB, ma quello effettivo può essere di 2 MB o più a seconda del numero di repliche, cloni e snapshot.
NAME
: nome del pool.
ID
: ID del pool.
USED
: quantità di dati nozionale memorizzata, espressa in kilobyte, a meno che al numero non sia aggiunta una M per megabyte o G per gigabyte.
%USED
: percentuale nozionale di spazio di memorizzazione utilizzato per ciascun pool.
MAX AVAIL
: spazio massimo disponibile nel pool specificato.
OBJECTS
: numero nozionale di oggetti memorizzati per pool.
I numeri nella sezione POOLS sono nozionali. Non includono il numero di repliche, snapshot o cloni. Ne risulta che la somma delle quantità di USED e %USED non verrà aggiunta alle quantità di RAW USED e %RAW USED nella sezione %GLOBAL dell'output.
Per verificare lo stato di un cluster, eseguire quanto riportato di seguito:
root #
ceph status
oppure
root #
ceph -s
In modalità interattiva, digitare status
e premereEnter.
ceph> status
Ceph eseguirà la stampa dello stato del cluster. Ad esempio, un cluster Ceph di piccole dimensioni costituito da un monitoraggio e due OSD può stampare quanto riportato di seguito:
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
È possibile verificare lo stato degli OSD per assicurarsi che siano attivi e funzionanti eseguendo:
root #
ceph osd stat
oppure
root #
ceph osd dump
È inoltre possibile visualizzare gli OSD in base alla rispettiva posizione nella mappa CRUSH.
root #
ceph osd tree
Ceph eseguirà la stampa di un albero CRUSH con un host, i rispettivi OSD, se attivi, e il relativo peso.
# 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
Ceph impedisce la scrittura in un OSD pieno in modo da evitare perdite di dati. In un cluster operativo, quando questo è prossimo al rispettivo rapporto di riempimento si riceve un avviso. L'impostazione di default di mon osd full ratio
è 0,95 o 95% della capacità, prima che venga interrotta la scrittura dei dati da parte dei client. L'impostazione di default di mon osd nearfull ratio
è 0,85 o 85% della capacità, quando viene generato avviso sullo stato di integrità.
I nodi OSD pieni verranno segnalati da ceph health
:
ceph health HEALTH_WARN 1 nearfull osds osd.2 is near full at 85%
oppure
ceph health HEALTH_ERR 1 nearfull osds, 1 full osds osd.2 is near full at 85% osd.3 is full at 97%
Il modo migliore per gestire un cluster pieno consiste nell'aggiungere nuovi nodi OSD che consentono al cluster di ridistribuire dati nello spazio di memorizzazione che si è appena reso disponibile.
Se non è possibile avviare un OSD perché è pieno, è possibile eliminare alcuni dati eliminando alcune directory dei gruppi di posizionamento nell'OSD pieno.
Quando un OSD si riempie (utilizza il 100% del rispettivo spazio su disco), di norma questo si blocca rapidamente senza alcun avviso. Di seguito sono riportati alcuni suggerimenti utili per l'amministrazione dei nodi OSD.
È necessario posizionare lo spazio su disco di ciascun OSD (di norma montato in /var/lib/ceph/osd/osd-{1,2..}
) su un disco o una partizione dedicati sottostanti.
Controllare i file di configurazione Ceph e assicurarsi che il log file Ceph non venga memorizzato nei dischi o nelle partizioni dedicati all'uso da parte degli OSD.
Assicurarsi che la scrittura nei dischi o nelle partizioni dedicati all'uso da parte degli OSD non venga eseguita da altri processi.
Se il cluster contiene più monitoraggi (probabile), verificare lo stato di quorum del monitoraggio dopo aver avviato il cluster prima della lettura e/o scrittura dei dati. Quando sono in esecuzione più monitoraggi, deve essere presente un quorum. Periodicamente, verificare anche lo stato dei monitoraggi per assicurarsi che siano in esecuzione.
Per visualizzare la mappa del monitoraggio, eseguire quanto riportato di seguito:
root #
ceph mon stat
oppure
root #
ceph mon dump
Per verificare lo stato del quorum per il cluster di monitoraggio, eseguire quanto riportato di seguito:
root #
ceph quorum_status
Ceph restituirà lo stato del quorum. Ad esempio, un cluster Ceph costituito da tre monitoraggi può restituire quanto riportato di seguito:
{ "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"} ] } }
Oggetti della mappa dei gruppi di posizionamento negli OSD. Quando si monitorano i gruppi di posizionamento, questi dovranno essere active
e clean
. Per informazioni dettagliate, fare riferimento a Monitoring OSDs and Placement Groups (in lingua inglese).
Il socket amministrativo Ceph consente di interrogare un daemon tramite un'interfaccia socket. Per default, i socket Ceph risiedono in /var/run/ceph
. Per accedere a un daemon tramite il socket amministrativo, eseguire il login all'host sul quale è in esecuzione il daemon e utilizzare il seguente comando:
root #
ceph --admin-daemon /var/run/ceph/socket-name
Per visualizzare i comandi del socket amministrativo disponibili, eseguire il seguente comando:
root #
ceph --admin-daemon /var/run/ceph/socket-name help
I comandi del socket amministrativo consentono di mostrare e impostare la configurazione al momento del runtime. Per informazioni dettagliate, fare riferimento a Viewing a Configuration at Runtime (in lingua inglese).
È inoltre possibile impostare i valori di configurazione direttamente in fase di runtime (il socket amministrativo evita il monitoraggio, diversamente dall'injectarg ceph tell
daemon-type.id, che fa affidamento al monitoraggio ma non richiede il login diretto all'host in questione).