Si applica a SUSE Enterprise Storage 7

12 Determinazione dello stato del cluster #

Quando un cluster è in esecuzione, è possibile utilizzare lo strumento ceph per monitorarlo. Per determinare lo stato del cluster, in genere occorre verificare lo stato dei Ceph OSD, di Ceph Monitor, dei gruppi di posizionamento e dei server di metadati.

Suggerimento: modalità interattiva

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

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

12.1 Verifica dello stato di un cluster #

È possibile individuare lo stato immediato del cluster mediante ceph status o ceph -s:

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

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

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

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

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
Stato di Ceph Manager
Stato di Object Gateway
Versione della mappa del gruppo di posizionamento
Numero di gruppi di posizionamento e pool
Quantità nozionale di dati memorizzati e numero di oggetti memorizzati
Quantità totale di dati memorizzati.

Suggerimento: calcolo dell'utilizzo dei dati da parte di Ceph

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 le informazioni aggiornate in tempo reale, inserire uno di questi comandi (incluso ceph -s) come argomento del comando watch:

root # watch -n 10 'ceph -s'

Premere Ctrl–C quando non si desidera più visualizzare le informazioni.

12.2 Verifica dell'integrità del cluster #

Dopo l'avvio del cluster e prima della lettura e/o scrittura dei dati, verificare lo stato di integrità del cluster:

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

Suggerimento

Se sono state specificate ubicazioni non di default per la configurazione o il portachiavi, è possibile specificarne le ubicazioni:

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

Il cluster Ceph restituisce uno dei seguenti codici di stato di integrità:

OSD_DOWN

Uno o più OSD sono contrassegnati. È possibile che il daemon 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.

OSD_crush type_DOWN, ad esempio OSD_HOST_DOWN

Tutti gli OSD in un determinato sottoalbero CRUSH vengono contrassegnati, ad esempio tutti gli OSD in un host.

OSD_ORPHAN

Un OSD è un riferimento nella gerarchia della mappa CRUSH, ma non esiste. È possibile rimuovere l'OSD dalla gerarchia CRUSH con:

cephuser@adm > ceph osd crush rm osd.ID

OSD_OUT_OF_ORDER_FULL

Le soglie di utilizzo per backfillfull (il valore di default è 0,90), nearfull (il valore di default è 0,85), full (il valore di default è 0,95) e/o failsafe_full non sono crescenti. In particolare, ci si aspetta backfillfull < nearfull, nearfull < full e full < failsafe_full.

Per leggere i valori attuali, eseguire:

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%

È possibile modificare le soglie con i comandi seguenti:

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

OSD_FULL

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:

cephuser@adm > ceph df

È possibile visualizzare il rapporto full attualmente definito con:

cephuser@adm > ceph osd dump | grep full_ratio

Una soluzione immediata per ripristinare la disponibilità di scrittura consiste nell'aumentare leggermente la soglia completa (full):

cephuser@adm > 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.

OSD_BACKFILLFULL

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:

cephuser@adm > ceph df

OSD_NEARFULL

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:

cephuser@adm > ceph df

OSDMAP_FLAGS

Sono stati impostati uno o più flag del cluster interessato. Ad eccezione di full, è possibile impostare o eliminare i flag con:

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

Tali flag includono:

full: Il cluster è contrassegnato come full (pieno) e non può fornire servizi di scrittura.
pauserd, pausewr: Letture o scritture in pausa
noup: Viene impedito l'avvio degli OSD.
nodown: I rapporti sugli errori degli OSD vengono ignorati, ad esempio quando i monitoraggi non contrassegnano gli OSD come down (inattivi).
noin: Gli OSD contrassegnati precedentemente come out non verranno contrassegnati di nuovo come in all'avvio.
noout: Gli OSD down (inattivi) non verranno contrassegnati automaticamente come out dopo l'intervallo configurato.
nobackfill, norecover, norebalance: Il recupero o il ribilanciamento dei dati è sospeso.
noscrub, nodeep_scrub: La pulitura (vedere Sezione 17.6, «Pulitura dei gruppi di posizionamento») è disabilitata.
notieragent: L'attività di suddivisione in livelli di cache è sospesa.

OSD_FLAGS

Uno o più OSD presentano un flag per OSD del set di interesse. Tali flag includono:

noup: All'OSD non è consentito l'avvio.
nodown: I rapporti di errore per l'OSD specificato verranno ignorati.
noin: Se precedentemente questo OSD è stato contrassegnato automaticamente come out in seguito a un errore, non verrà contrassegnato come in al suo avvio.
noout: Se l'OSD è inattivo, non verrà contrassegnato automaticamente come out dopo l'intervallo configurato.

È possibile impostare ed eliminare i flag per OSD con:

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

OLD_CRUSH_TUNABLES

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.

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

CACHE_POOL_NO_HIT_SET

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:

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

OSD_NO_SORTBITWISE

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:

cephuser@adm > ceph osd set sortbitwise

POOL_FULL

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:

cephuser@adm > ceph df detail

È possibile aumentare la quota del pool con

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

o eliminare alcuni dati esistenti per ridurre l'utilizzo.

PG_AVAILABILITY

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 I/O. 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:

cephuser@adm > 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:

cephuser@adm > ceph tell pgid query

PG_DEGRADED

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:

cephuser@adm > 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:

cephuser@adm > ceph tell pgid query

PG_DEGRADED_FULL

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

PG_DAMAGED

In seguito alla pulitura dei dati (vedere Sezione 17.6, «Pulitura dei gruppi di posizionamento»), 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.

OSD_SCRUB_ERRORS

Dalle puliture dell'OSD sono state rilevate incoerenze.

CACHE_POOL_NEAR_FULL

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:

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

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

TOO_FEW_PGS

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.

TOO_MANY_PGS

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.

È possibile ridurre il valore pgp_num, ma non il valore pg_num per i pool esistenti. 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:

cephuser@adm > ceph osd pool set pool pgp_num value

SMALLER_PGP_NUM

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:

cephuser@adm > ceph osd pool set pool pgp_num pg_num_value

MANY_OBJECTS_PER_PG

Uno o più pool presentano un numero medio 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.

POOL_APP_NOT_ENABLED

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:

cephuser@adm > rbd pool init pool_name

Se il pool viene utilizzato da un'applicazione personalizzata "foo", è inoltre possibile etichettarla con il comando di livello basso:

cephuser@adm > ceph osd pool application enable foo

POOL_FULL

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:

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

Impostando il valore di quota a 0, questa verrà disabilitata.

POOL_NEAR_FULL

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:

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

Impostando il valore di quota a 0, questa verrà disabilitata.

OBJECT_MISPLACED

Uno o più oggetti nel cluster non vengono memorizzati nel nodo specificato dal cluster. Ciò indica che la migrazione dei dati causata da una modifica recente del cluster non è stata ancora completata. 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).

OBJECT_UNFOUND

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 attivi non è stata trovata una copia di tale versione dell'oggetto. Le richieste di lettura o scrittura negli oggetti "non trovati" verranno bloccate. Idealmente, è possibile riattivare l'OSD inattivo in cui è presente 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:

cephuser@adm > ceph tell pgid query

REQUEST_SLOW

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:

cephuser@adm > ceph daemon osd.id ops

È possibile visualizzare un riepilogo delle richieste recenti più lente:

cephuser@adm > ceph daemon osd.id dump_historic_ops

È possibile individuare l'ubicazione di un OSD con:

cephuser@adm > ceph osd find osd.id

REQUEST_STUCK

Una o più richieste OSD sono state bloccate per un intervallo di tempo relativamente lungo, ad esempio 4.096 secondi. Ciò indica che lo stato del cluster non è integro da un periodo di tempo prolungato (ad esempio il numero di OSD in esecuzione o di gruppi di posizionamento inattivi non è sufficiente) o che sono presenti alcuni problemi interni dell'OSD.

PG_NOT_SCRUBBED

Di recente non è stata eseguita la pulitura di uno o più gruppi di posizionamento (vedere la Sezione 17.6, «Pulitura dei gruppi di posizionamento»). 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:

cephuser@adm > ceph pg scrub pgid

PG_NOT_DEEP_SCRUBBED

Di recente non è stata eseguita la pulitura approfondita di uno o più gruppi di posizionamento (vedere Sezione 17.6, «Pulitura dei gruppi di posizionamento»). 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:

cephuser@adm > ceph pg deep-scrub pgid

Suggerimento

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

12.3 Verifica delle statistiche sull'utilizzo di un cluster #

Per verificare l'utilizzo e la distribuzione dei dati del cluster nei diversi pool, utilizzare il comando ceph df. Per ottenere ulteriori dettagli, utilizzare ceph df detail.

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

Nella sezione RAW STORAGE dell'output è fornita una panoramica dello spazio di storage utilizzato dal cluster per i dati.

CLASS: classe di storage del dispositivo. Per ulteriori dettagli sulle classi di dispositivi, fare riferimento alla Sezione 17.1.1, «Classi di dispositivi».
SIZE: capacità di memorizzazione complessiva del cluster.
AVAIL: quantità di spazio libero disponibile nel cluster.
USED: spazio (accumulato su tutti gli OSD) allocato esclusivamente per gli oggetti dati conservati nel dispositivo di blocco.
RAW USED: somma tra lo spazio utilizzato ("USED") e quello allocato/riservato sul dispositivo di blocco per Ceph, ad esempio la parte BlueFS per BlueStore.
% 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. Per ulteriori dettagli, vedere la Sezione 12.8, «Capacità di memorizzazione».
Nota: livello di riempimento del cluster
Quando il livello di riempimento dello spazio di storage nominale si avvicina al 100%, è necessario aggiungere ulteriore spazio di storage 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.

POOL: nome del pool.
ID: ID del pool.
STORED: quantità di dati memorizzati dall'utente.
OBJECTS: numero nozionale di oggetti memorizzati per pool.
USED: quantità di spazio allocato esclusivamente ai dati da tutti i nodi OSD, indicato in KB.
%USED: percentuale nozionale di spazio di memorizzazione utilizzato per ciascun pool.
MAX AVAIL: spazio massimo disponibile nel pool specificato.

Nota

I numeri nella sezione POOLS sono nozionali. Non includono il numero di repliche, snapshot o cloni. Ne risulta che la somma delle quantità USED e %USED non verrà aggiunta alle quantità RAW USED e %RAW USED nella sezione RAW STORAGE dell'output.

12.4 Verifica dello stato degli OSD #

È possibile verificare lo stato degli OSD per assicurarsi che siano attivi e funzionanti eseguendo:

cephuser@adm > ceph osd stat

oppure

cephuser@adm > ceph osd dump

È inoltre possibile visualizzare gli OSD in base alla rispettiva posizione nella mappa CRUSH.

ceph osd tree eseguirà la stampa di un albero CRUSH con un host, i rispettivi OSD, se attivi, e il relativo peso:

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

12.5 Verifica degli OSD pieni #

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:

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

oppure

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%

Il modo migliore per gestire un cluster pieno consiste nell'aggiungere nuovi host/dischi OSD che consentano al cluster di ridistribuire dati nello spazio di storage che si è appena reso disponibile.

Suggerimento: esclusione degli OSD pieni

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.

12.6 Verifica dello stato del monitor #

Dopo aver avviato il cluster e precedentemente alla prima lettura e/o scrittura dei dati, verificare lo stato del quorum dei Ceph Monitor. Se il cluster sta già provvedendo alle richieste, controllare periodicamente lo stato dei Ceph Monitor per assicurarsi che siano in esecuzione.

Per visualizzare la mappa del monitoraggio, eseguire quanto riportato di seguito:

cephuser@adm > ceph mon stat

oppure

cephuser@adm > ceph mon dump

Per verificare lo stato del quorum per il cluster di monitoraggio, eseguire quanto riportato di seguito:

cephuser@adm > 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": "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 Verifica degli stati dei gruppi di posizionamento #

Oggetti della mappa dei gruppi di posizionamento negli OSD. Quando si monitorano i gruppi di posizionamento, questi dovranno essere active e clean. Per una discussione dettagliata, fare riferimento alla Sezione 12.9, «Monitoraggio di OSD e gruppi di posizionamento».

12.8 Capacità di memorizzazione #

Quando un cluster di memorizzazione Ceph si avvicina alla capacità massima, Ceph impedisce la scrittura o la lettura dai Ceph OSD come misura di sicurezza per evitare perdite di dati. Pertanto, non è consigliabile far avvicinare un cluster di produzione al rapporto di riempimento. Questa situazione andrebbe infatti a discapito dell'elevata disponibilità. Per default il rapporto di riempimento è impostato su 0,95, ovvero il 95% della capacità. Si tratta di un valore molto aggressivo per un cluster di test contenente un numero ridotto di OSD.

Suggerimento: aumento della capacità di storage

Durante il monitoraggio del cluster, prestare attenzione agli avvisi relativi alla percentuale nearfull. Ciò indica che nel caso di errori su alcuni OSD, potrebbe verificarsi una temporanea interruzione del servizio. Valutare la possibilità di aggiungere altri OSD per aumentare la capacità di storage.

In uno scenario comune per i cluster di prova, l'amministratore di sistema rimuove un Ceph OSD dal cluster di memorizzazione Ceph per osservare il ribilanciamento del cluster. Quindi, rimuove un altro Ceph OSD e così via fin quando il cluster non raggiunge il rapporto di riempimento e si blocca. Si consiglia di eseguire la pianificazione della capacità anche per il cluster di prova. In questo modo, sarà possibile calcolare la capacità di riserva necessaria per mantenere un'elevata disponibilità. Idealmente, è consigliabile pianificare una serie di errori dei Ceph OSD durante cui sia possibile recuperare il cluster e ripristinarlo allo stato active + clean senza sostituire immediatamente i Ceph OSD con errori. Anche se è possibile eseguire un cluster nello stato active + degraded, non è l'ideale per un normale funzionamento.

Nel diagramma seguente viene illustrato un cluster di memorizzazione Ceph semplificato che contiene 33 nodi Ceph e un Ceph OSD per host, ciascuno in grado di eseguire operazioni di lettura e scrittura su un'unità da 3 TB. La capacità effettiva di questo cluster di esempio è di 99 TB. L'opzione mon osd full ratio è impostata a 0,95. Se il cluster raggiunge i 5 TB di capacità rimanente, non consentirà ai client di leggere e scrivere dati. Di conseguenza, la capacità operativa del cluster di memorizzazione è 95 TB, non 99 TB.

Figura 12.1: Cluster Ceph #

In tale cluster, è normale che si verifichino errori su uno o due OSD. In uno scenario meno frequente ma possibile, può verificarsi un errore del router o dell'alimentazione del rack che causa la disattivazione simultanea di più OSD (ad esempio degli OSD da 7 a 12). In tale scenario, è consigliabile comunque puntare ad avere un cluster in grado di restare operativo e raggiungere lo stato active + clean, anche se ciò comporta l'aggiunta di alcuni host con ulteriori OSD in tempi brevi. Se l'utilizzo della capacità è troppo elevato, potrebbero verificarsi perdite di dati. Tuttavia, se l'utilizzo della capacità del cluster supera il rapporto di riempimento, è comunque preferibile scendere a compromessi sulla disponibilità dei dati per risolvere un'interruzione all'interno di un dominio di errore. Per questo motivo, si consiglia di effettuare una pianificazione seppur approssimativa della capacità.

Identificare due numeri per il cluster:

Il numero di OSD.
La capacità complessiva del cluster.

Se si divide la capacità totale del cluster per il numero di OSD contenuti, è possibile individuare la capacità media di un OSD del cluster. Moltiplicare questo numero per il numero di OSD su cui si prevede che si verificheranno errori in simultanea durante il normale funzionamento (un numero relativamente ridotto). Moltiplicare poi la capacità del cluster per il rapporto di riempimento fino a raggiungere la capacità operativa massima. Infine, sottrarre la quantità di dati degli OSD su cui si prevede che si verificheranno errori fino a raggiungere un rapporto di riempimento ragionevole. Ripetere la procedura indicata con un numero più elevato di errori sugli OSD (un rack di OSD) fino a ottenere un numero ragionevole per un rapporto di riempimento quasi completo.

Le impostazioni seguenti si applicano soltanto durante la creazione del cluster e vengono quindi memorizzate nella mappa OSD:

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

Suggerimento

Queste impostazioni si applicano soltanto durante alla creazione del cluster. In seguito, è necessario modificarle nella mappa OSD utilizzando i comandi ceph osd set-nearfull-ratio e ceph osd set-full-ratio.

mon osd full ratio: Percentuale di spazio su disco utilizzata prima che un OSD venga considerato pieno (full). Il valore di default è 0,95
mon osd backfillfull ratio: Percentuale di spazio su disco utilizzata prima che un OSD venga considerato troppo pieno (full) per il backfill. Il valore di default è 0,90
mon osd nearfull ratio: Percentuale di spazio su disco utilizzata prima che un OSD venga considerato quasi pieno (nearfull). Il valore di default è 0,85

Suggerimento: verifica del peso dell'OSD

Se alcuni OSD sono nearfull, ma in altri è invece disponibile una capacità elevata, potrebbero verificarsi dei problemi con il peso CRUSH per gli OSD nearfull.

12.9 Monitoraggio di OSD e gruppi di posizionamento #

Per ottenere un'elevata disponibilità e un'alta affidabilità occorre adottare un approccio a tolleranza di errore nella gestione dei problemi hardware e software. Ceph non dispone di un single point of failure ed è in grado di provvedere alle richieste di dati nella modalità "degraded" (danneggiata). Il posizionamento dei dati di Ceph introduce un livello di riferimento indiretto per fare in modo che i dati non vengano direttamente associati a specifici indirizzi OSD. Vale a dire che per il controllo degli errori di sistema occorre individuare il gruppo di posizionamento e gli OSD sottostanti alla radice del problema.

Suggerimento: accesso in caso di errore

Gli errori che si verificano in una parte del cluster possono impedire l'accesso a un determinato oggetto, ma non ad altri oggetti. Quando si verifica un errore, seguire la procedura di monitoraggio degli OSD e dei gruppi di posizionamento. Quindi, procedere con la risoluzione dei problemi.

Ceph in genere esegue il ripristino automatico. Tuttavia, se i problemi continuano a verificarsi, il monitoraggio degli OSD e dei gruppi di posizionamento consentirà di identificare il problema.

12.9.1 Monitoraggio degli OSD #

Un OSD può essere nello stato "in" (dentro il cluster) o nello stato "out" (fuori dal cluster). Contemporaneamente, può essere "up" (attivo e in esecuzione) o "down" (disattivato e non in esecuzione). Se un OSD è nello stato "up", può trovarsi dentro il cluster (sarà possibile leggere e scrivere i dati) o al di fuori di esso. Se si trovava all'interno del cluster e di recente è stato spostato al di fuori, Ceph eseguirà la migrazione dei gruppi di posizionamento in altri OSD. Se un OSD si trova fuori dal cluster, CRUSH non gli assegnerà alcun gruppo di posizionamento. Se un OSD è nello stato "down", deve essere anche "out".

Nota: stato non integro

Se un OSD è "down" e "in", è presente un problema e il cluster si trova nello stato non integro.

Se si esegue un comando come ceph health ceph -s o ceph -w, è possibile notare che il cluster non rimanda sempre lo stato HEALTH OK. Per quanto riguarda gli OSD, è prevedibile che il cluster non rimanderà lo stato HEALTH OK se:

Il cluster non è stato ancora avviato (non risponderà).
Il cluster è stato avviato o riavviato e non è ancora pronto, poiché è in corso la creazione dei gruppi di posizionamento e gli OSD sono in fase di peering.
Un OSD è stato aggiunto o rimosso.
La mappa del cluster è stata modificata.

Un aspetto importante del monitoraggio degli OSD consiste nell'assicurarsi che tutti gli OSD dentro il cluster siano attivi e in esecuzione quando lo è il cluster. Per verificare se tutti gli OSD sono in esecuzione, eseguire:

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

Il risultato dovrebbe indicare il numero totale di OSD (x), quanti di questi sono nello stato "up" (y) e nello stato "in" (z) e l'epoca della mappa (eNNNN). Se il numero di OSD dentro il cluster ("in") superiore al numero di OSD attivi ("up"), eseguire il comando seguente per individuare i daemon ceph-osd non in esecuzione:

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

Ad esempio, se un OSD con ID 1 è inattivo, avviarlo:

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

Per informazioni sui problemi associati agli OSD interrotti o che non verranno riavviati, vedere il Sezione 4.3, «OSDs not running».

12.9.2 Assegnazione di insiemi di gruppi di posizionamento #

Quando CRUSH assegna i gruppi di posizionamento agli OSD, osserva il numero di repliche del pool e assegna il gruppo di posizionamento agli OSD in modo che ogni replica di tale gruppo venga assegnata a un OSD diverso. Ad esempio, se il pool richiede tre repliche di un gruppo di posizionamento, CRUSH potrebbe assegnarle rispettivamente a osd.1, osd.2 e osd.3. CRUSH in realtà individua un posizionamento pseudo-casuale che tiene conto dei domini di errore impostati nella mappa CRUSH. Di conseguenza, in un cluster di grandi dimensioni sarà raro vedere gruppi di posizionamento assegnati agli OSD più vicini. Il set di OSD che deve contenere le repliche di un determinato gruppo di posizionamento viene chiamato acting set. In alcuni casi, un OSD dell'acting set è disattivato oppure non è in grado di provvedere alle richieste relative agli oggetti nel gruppo di posizionamento. In queste situazioni, gli scenari potrebbero essere i seguenti:

Un OSD è stato aggiunto o rimosso. Quindi, CRUSH ha riassegnato il gruppo di posizionamento agli altri OSD e ha pertanto modificato la composizione dell'acting set, causando la migrazione dei dati con una procedura di "backfill".
Un OSD era nello stato "down", è stato riavviato ed è in corso di recupero.
Un OSD nell'acting set si trova nello stato "down" o non è in grado di provvedere alle richieste e un altro OSD ne assume provvisoriamente i compiti.
Ceph elabora una richiesta client tramite l'up set, ovvero il set degli OSD che provvederanno effettivamente alle richieste. Nella maggior parte dei casi, l'up set e l'acting set sono praticamente identici. Se differiscono, potrebbe significare che Ceph sta eseguendo la migrazione dei dati, che è in corso il recupero di un OSD o che si è verificato un problema (ad esempio, in tali scenari generalmente Ceph rimanda uno stato HEALTH WARN con il messaggio "stuck stale").

Per recuperare un elenco dei gruppi di posizionamento, eseguire:

cephuser@adm > ceph pg dump

Per visualizzare gli OSD che si trovano all'interno dell'acting set o dell'up set per un determinato gruppo di posizionamento, eseguire:

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

Il risultato dovrebbe indicare l'epoca di osdmap (eNNN), il numero di gruppi di posizionamento (PG_NUM), gli OSD nell'up set ("up") e quelli nell'acting set ("acting"):

Suggerimento: indicatore di problemi nel cluster

Una mancata corrispondenza tra l'up set e l'acting set potrebbe indicare che è in corso il ribilanciamento del cluster o un suo potenziale problema.

12.9.3 Peering #

Prima che sia possibile scrivere dati su un gruppo di posizionamento, quest'ultimo deve essere negli stati active e clean. Affinché Ceph possa determinare lo stato corrente di un gruppo di posizionamento, l'OSD primario di tale gruppo (il primo OSD nell'acting set) esegue il peering con gli OSD secondario e terziario per accordarsi sullo stato corrente del gruppo di posizionamento (presupponendo che si tratti di un pool con tre repliche del gruppo di posizionamento).

Figura 12.2: Schema di peering #

12.9.4 Monitoraggio degli stati del gruppo di posizionamento #

Se si esegue un comando come ceph health, ceph -s o ceph -w, è possibile notare che il cluster non rimanda sempre il messaggio HEALTH OK. Dopo aver verificato che tutti gli OSD siano in esecuzione, controllare anche gli stati del gruppo di posizionamento.

È prevedibile che il cluster non rimanderà lo stato HEALTH OK in alcune circostanze correlate al peering del gruppo di posizionamento:

È stato creato un pool e non è stato ancora eseguito il peering dei gruppi di posizionamento.
È in corso il recupero dei gruppi di posizionamento.
Un OSD è stato aggiunto al cluster o rimosso da quest'ultimo.
La mappa CRUSH è stata modificata ed è in corso la migrazione dei gruppi di posizionamento.
Sono presenti dati incoerenti in repliche diverse di un gruppo di posizionamento.
Ceph sta eseguendo la pulitura delle repliche di un gruppo di posizionamento.
Ceph non dispone di sufficiente capacità di storage per il completamento delle operazioni di backfill.

Se a causa di una di queste circostanze Ceph rimanda il messaggio HEALTH WARN, non preoccuparsi. In molti casi, il cluster si ripristinerà automaticamente. In alcuni casi, può essere necessario intervenire. Un aspetto importante del monitoraggio dei gruppi di posizionamento consiste nell'assicurarsi che quando un cluster è attivo e in esecuzione, tutti i gruppi di posizionamento siano nello stato "active" e preferibilmente anche in quello "clean state". Per visualizzare lo stato di tutti i gruppi di posizionamento, eseguire:

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

Il risultato dovrebbe indicare il numero totale di gruppi di posizionamento (x), quanti di questi si trovano in un determinato stato, ad esempio "active+clean" (y), e la quantità di dati memorizzati (z).

Oltre agli stati del gruppo di posizionamento, Ceph rimanderà anche la capacità di storage utilizzata (aa), quella rimanente (bb) e la capacità di storage totale del gruppo di posizionamento. Tali valori possono essere importanti nei casi in cui:

Ci si sta avvicinando al valore impostato per near full ratio o full ratio.
I dati non vengono distribuiti nel cluster a causa di un errore nella configurazione CRUSH.

Suggerimento: ID dei gruppi di posizionamento

Gli ID dei gruppi di posizionamento sono costituiti dal numero del pool (e non dal nome) seguito da un punto (.) e dall'ID del gruppo di posizionamento (un numero esadecimale). È possibile visualizzare il numero e il nome del pool dall'output di ceph osd lspools. Ad esempio, il pool di default rbd corrisponde al numero di pool 0. Un ID del gruppo di posizionamento completo è strutturato nel modo seguente:

POOL_NUM.PG_ID

E in genere ha il seguente aspetto:

0.1f

Per recuperare un elenco dei gruppi di posizionamento, eseguire quanto riportato di seguito:

cephuser@adm > ceph pg dump

È inoltre possibile formattare l'output in formato JSON e salvarlo in un file:

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

Per interrogare un determinato gruppo di posizionamento, eseguire quanto riportato di seguito:

cephuser@adm > ceph pg POOL_NUM.PG_ID query

L'elenco seguente descrive in modo dettagliato gli stati dei gruppi di posizionamento più comuni.

CREATING

Quando si crea un pool, quest'ultimo creerà il numero di gruppi di posizionamento specificato. Ceph rimanderà lo stato "creating" durante la creazione di uno o più gruppi di posizionamento. In seguito alla creazione, verrà avviato il peering degli OSD che fanno parte dell'acting set del gruppo di posizionamento. Al completamento del peering, lo stato del gruppo di posizionamento deve essere "active+clean", per indicare che un client Ceph può avviare la scrittura su tale gruppo.

Figura 12.3: Stato dei gruppi di posizionamento #

PEERING

Quando Ceph esegue il peering di un gruppo di posizionamento fa in modo che gli OSD che ne memorizzano le repliche concordino sullo stato degli oggetti e dei metadati contenuti nel gruppo. Quando Ceph completa il peering, vuol dire che gli OSD che memorizzano il gruppo di posizionamento concordano sullo stato corrente del gruppo di posizionamento. Tuttavia, il completamento del processo di peering non implica che in ogni replica siano presenti i contenuti più recenti.

Nota: cronologia autorevole

Ceph non riconoscerà le operazioni di scrittura su un client finché tutti gli OSD dell'acting set non le salvano in modo permanente. Questa pratica consente di assicurare che almeno un membro dell'acting set conterrà un record di tutte le operazioni di scrittura riconosciute dall'ultima operazione di peering riuscita.

Tramite un record accurato delle operazioni di scrittura riconosciute, Ceph è in grado di creare e ampliare una nuova cronologia autorevole del gruppo di posizionamento, un set di operazioni completo e in corretta sequenza che, se eseguito, consente di aggiornare la copia dell'OSD di un gruppo di posizionamento.

ACTIVE

Quando Ceph completa il processo di peering, il gruppo di posizionamento può passare allo stato active. Lo stato active indica che i dati nel gruppo di posizionamento sono di norma disponibili all'interno del gruppo di posizionamento primario e nelle repliche delle operazioni di lettura e scrittura.

CLEAN

Quando un gruppo di posizionamento si trova nello stato clean, l'OSD primario e gli OSD di replica hanno eseguito correttamente il peering e non sono presenti repliche residue relative al gruppo di posizionamento. Ceph ha eseguito la replica di tutti gli oggetti nel gruppo di posizionamento per il numero corretto di volte.

DEGRADED

Quando un client scrive un oggetto nell'OSD primario, questo è responsabile della scrittura delle repliche sugli OSD di replica. Quando l'OSD primario scrive l'oggetto nello storage, il gruppo di posizionamento rimane nello stato danneggiato ("degraded") finché gli OSD di replica non confermano all'OSD primario la riuscita della creazione degli oggetti di replica da parte di Ceph.

Il motivo per cui un gruppo di posizionamento può avere lo stato "active+degraded" è il fatto che un OSD può essere nello stato "active" anche se non contiene ancora tutti gli oggetti. Se un OSD diventa disattivato, Ceph contrassegna ciascun gruppo di posizionamento assegnato a tale OSD come "degraded". Quando l'OSD ritorna attivo, gli altri OSD devono ripetere il peering. Tuttavia, un client può comunque scrivere un nuovo oggetto in un gruppo di posizionamento danneggiato se si trova nello stato "active".

Se un OSD è nello stato "down" e la condizione "degraded" persiste, Ceph può contrassegnare l'OSD disattivato come esterno al cluster ("out") e rimappare i dati da questo OSD a un altro OSD. L'intervallo di tempo in cui un OSD viene contrassegnato dallo stato "down" a quello "out" è controllato dall'opzione mon osd down out interval, impostata per default su 600 secondi.

Inoltre, un gruppo di posizionamento può trovarsi nello stato "degraded" se Ceph non riesce a trovare uno o più oggetti al suo interno. Sebbene non sia possibile eseguire operazioni di lettura o scrittura sugli oggetti non trovati, sarà comunque possibile accedere a tutti gli altri oggetti nel gruppo di posizionamento nello stato "degraded".

RECOVERING

Ceph è stato progettato per garantire una tolleranza agli errori su vasta scala in caso di problemi hardware e software. Quando un OSD diventa disattivato, i relativi contenuti potrebbero non essere aggiornati rispetto allo stato corrente delle altre repliche nei gruppi di posizionamento. Quando l'OSD ritorna attivo, i contenuti dei gruppi di posizionamento devono essere aggiornati per riflettere lo stato corrente. Durante questo intervallo di tempo, l'OSD potrebbe riportare lo stato "recovering".

La procedura di recupero non è sempre semplice, perché errori dell'hardware potrebbero causare errori a cascata in più OSD. Ad esempio, potrebbero verificarsi errori su uno switch di rete di un rack o di uno schedario a causa dei quali l'aggiornamento degli OSD di più computer host rispetto allo stato corrente del cluster non va a buon fine. Quando l'errore viene risolto, è necessario recuperare tutti gli OSD.

Ceph fornisce diverse impostazioni per bilanciare il conflitto delle risorse tra le nuove richieste di servizio e la necessità di recuperare gli oggetti dati e ripristinare i gruppi di posizionamento allo stato corrente. L'impostazione osd recovery delay start consente a un OSD di riavviarsi, ripetere il peering e persino elaborare alcune richieste di riproduzione prima di avviare il processo di recupero. L'impostazione osd recovery thread timeout consente di impostare un timeout del thread, poiché più OSD potrebbero generare errori, riavviarsi e ripetere il peering a frequenza sfalsata. L'impostazione osd recovery max active consente di limitare il numero di richieste di recupero che verranno elaborate contemporaneamente da un OSD per impedire errori di gestione delle richieste su tale OSD. L'impostazione osd recovery max chunk consente di limitare le dimensioni delle porzioni di dati recuperate per evitare un traffico eccessivo sulla rete.

BACK FILLING

Se viene aggiunto un nuovo OSD al cluster, CRUSH riassegnerà i gruppi di posizionamento dagli OSD già nel cluster a quello appena aggiunto. Se si forza il nuovo OSD ad accettare immediatamente i gruppi di posizionamento riassegnati, si può generare un carico eccessivo su quest'ultimo. Tramite il backfill dell'OSD con i gruppi di posizionamento, è possibile avviare questa procedura in background. Al completamento del backfill, il nuovo OSD inizierà a provvedere alle richieste quando sarà pronto.

Durante le operazioni di backfill, potrebbero essere visualizzati diversi stati: "backfill_wait" indica che un'operazione di backfill è in sospeso, ma non ancora in corso; "backfill" indica che un'operazione di backfill è in corso; "backfill_too_full" indica che un'operazione di backfill è stata richiesta, ma non è stato possibile completarla perché la capacità di storage è insufficiente. Se non è possibile eseguire il backfill di un gruppo di posizionamento, questo potrebbe essere considerato come incompleto ("incomplete").

In Ceph sono disponibili diverse impostazioni per la gestione del carico associato alla riassegnazione dei gruppi di posizionamento a un OSD (soprattutto ai nuovi OSD). Per default, osd max backfills consente di impostare su 10 il numero massimo di operazioni di backfill simultanee verso o da un OSD. Con backfill full ratio un OSD può rifiutare una richiesta di backfill se sta raggiungendo la percentuale di riempimento (90% per default) e apportare modifiche con il comando ceph osd set-backfillfull-ratio. Se un OSD rifiuta una richiesta di backfill, tramite osd backfill retry interval l'OSD può ripetere la richiesta (per default dopo 10 secondi). Gli OSD possono inoltre impostare i valori osd backfill scan min e osd backfill scan max per gestire gli intervalli di scansione (impostati su 64 e 512 per default).

REMAPPED

Se l'acting set che gestisce un gruppo di posizionamento cambia, viene eseguita la migrazione dei dati dall'acting set precedente all'acting set nuovo. La gestione delle richieste da parte del nuovo OSD primario può richiedere del tempo. Il processo potrebbe quindi chiedere al precedente OSD primario di continuare a provvedere alle richieste fino al completamento della migrazione del gruppo di posizionamento. Al termine della migrazione dei dati, la mappatura utilizza l'OSD primario del nuovo acting set.

STALE

Mentre Ceph utilizza gli heartbeat per verificare che gli host e i daemon siano in esecuzione, i daemon ceph-osd possono passare anche allo stato "stuck" e non segnalare statistiche in modo puntuale (ad esempio, in caso di un errore di rete temporaneo). Per default, i daemon OSD segnalano il relativo gruppo di posizionamento e le statistiche di avvio ed errori ogni mezzo secondo (0,5), ovvero con maggiore frequenza rispetto alle soglie di heartbeat. Se l'OSD primario dell'acting set di un gruppo di posizionamento non riesce a inviare segnalazioni al monitor o se gli altri OSD hanno segnalato l'OSD primario come disattivato, i monitor contrassegneranno il gruppo di posizionamento come inattivo ("stale").

All'avvio del cluster, è normale visualizzare lo stato "stale" fino al completamento del processo di peering. Se il cluster è in esecuzione da un po' di tempo ma i gruppi di posizionamento continuano a essere nello stato "stale", vuol dire che l'OSD primario di tali gruppi di posizionamento è disattivato o non segnala al cluster monitoraggio le statistiche relative al gruppo.

12.9.5 Individuazione dell'ubicazione di un oggetto #

Per memorizzare i dati oggetto nel Ceph Object Store, il client Ceph deve impostare un nome oggetto e specificare un pool correlato. Il client Ceph recupera la mappa del cluster più recente, mentre l'algoritmo CRUSH calcola in che modo mappare l'oggetto a un gruppo di posizionamento e in che modo assegnare tale gruppo in modo dinamico a un OSD. Per individuare l'ubicazione dell'oggetto, servono solo il nome dell'oggetto e quello del pool. Esempio:

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

Esempio 12.1: Individuazione di un oggetto #

Procedere con la creazione di un oggetto di esempio. Specificare il nome oggetto "test-object-1", il percorso di un file di esempio "testfile.txt" contenente alcuni dati oggetto e il nome pool "data" tramite il comando rados put nella riga di comando:

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

Per verificare che Ceph Object Store abbia memorizzato l'oggetto, eseguire quanto riportato di seguito:

cephuser@adm > rados -p data ls

Adesso, individuare l'ubicazione dell'oggetto. L'output restituito da Ceph sarà l'ubicazione dell'oggetto:

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)

Per rimuovere l'oggetto di esempio, basta eliminarlo tramite il comando rados rm:

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