17 Gestione dei dati memorizzati #

La flessibilità della mappa CRUSH in termini di controllo del posizionamento dei dati è uno dei punti di forza di Ceph. È anche uno degli aspetti più complessi da gestire del cluster. Le classi di dispositivi automatizzano le modifiche più comuni apportate alle mappe CRUSH che l'amministratore in precedenza doveva eseguire manualmente.

17.1.1.1 Il problema della gestione CRUSH #

 

Spesso, i cluster Ceph sono compilati con più tipi di dispositivi di memorizzazione: HDD, SSD, NVMe o persino con classi miste delle tipologie appena elencate. Questi diversi tipi di dispositivi di memorizzazione sono chiamati classi di dispositivi per evitare confusione tra la proprietà type dei compartimenti CRUSH (ad esempio host, rack, row; vedere la Sezione 17.2, «Compartimenti» per ulteriori dettagli). I Ceph OSD supportati dai dispositivi SSD sono molto più veloci di quelli supportati dai dischi a rotazione e sono pertanto più adatti per determinati carichi di lavoro. Ceph semplifica la creazione di pool RADOS per dataset o carichi di lavoro diversi e l'assegnazione di regole CRUSH differenti per il controllo del posizionamento dei dati per questi pool.

Figura 17.1: OSD con classi di dispositivi miste #

 

La configurazione delle regole CRUSH per il posizionamento dei dati soltanto su una determinata classe di dispositivi è tuttavia un'operazione lunga e noiosa. Le regole si basano sulla gerarchia CRUSH, ma se negli stessi host o rack sono presenti dispositivi di diversi tipi (come nella gerarchia di esempio riportata sopra), tali dispositivi verranno (per default) mescolati e visualizzati negli stessi sottoalberi della gerarchia. Nelle versioni precedenti di SUSE Enterprise Storage, la separazione manuale dei dispositivi in alberi diversi comportava la creazione di più versioni di ciascun nodo intermedio per ogni classe di dispositivi.

cephuser@adm > ceph osd tree
 ID CLASS WEIGHT   TYPE NAME      STATUS REWEIGHT PRI-AFF
 -1       83.17899 root default
 -4       23.86200     host cpach
 2   hdd  1.81898         osd.2      up  1.00000 1.00000
 3   hdd  1.81898         osd.3      up  1.00000 1.00000
 4   hdd  1.81898         osd.4      up  1.00000 1.00000
 5   hdd  1.81898         osd.5      up  1.00000 1.00000
 6   hdd  1.81898         osd.6      up  1.00000 1.00000
 7   hdd  1.81898         osd.7      up  1.00000 1.00000
 8   hdd  1.81898         osd.8      up  1.00000 1.00000
 15  hdd  1.81898         osd.15     up  1.00000 1.00000
 10  nvme 0.93100         osd.10     up  1.00000 1.00000
 0   ssd  0.93100         osd.0      up  1.00000 1.00000
 9   ssd  0.93100         osd.9      up  1.00000 1.00000

cephuser@adm > ceph osd crush rm-device-class osd.2 osd.3
done removing class of osd(s): 2,3
cephuser@adm > ceph osd crush set-device-class ssd osd.2 osd.3
set osd(s) 2,3 to class 'ssd'

cephuser@adm > ceph osd crush rule create-replicated RULE_NAME ROOT FAILURE_DOMAIN_TYPE DEVICE_CLASS

cephuser@adm > ceph osd crush rule create-replicated fast default host ssd

cephuser@adm > ceph osd pool create fast_pool 128 128 replicated fast

cephuser@adm > ceph osd erasure-code-profile set myprofile \
 k=4 m=2 crush-device-class=ssd crush-failure-domain=host
cephuser@adm > ceph osd pool create mypool 64 erasure myprofile

rule ecpool {
  id 2
  type erasure
  min_size 3
  max_size 6
  step set_chooseleaf_tries 5
  step set_choose_tries 100
  step take default class ssd
  step chooseleaf indep 0 type host
  step emit
}

cephuser@adm > ceph osd crush class ls
[
  "hdd",
  "ssd"
]

cephuser@adm > ceph osd crush rule ls
replicated_rule
fast

cephuser@adm > ceph osd crush rule dump fast
{
		"rule_id": 1,
		"rule_name": "fast",
		"ruleset": 1,
		"type": 1,
		"min_size": 1,
		"max_size": 10,
		"steps": [
						{
										"op": "take",
										"item": -21,
										"item_name": "default~ssd"
						},
						{
										"op": "chooseleaf_firstn",
										"num": 0,
										"type": "host"
						},
						{
										"op": "emit"
						}
		]
}

cephuser@adm > ceph osd crush class ls-osd ssd
0
1

È possibile visualizzare la struttura definita nei compartimenti sotto forma di albero di nodi. I compartimenti sono nodi e gli OSD sono foglie nell'albero.

Le regole nella mappa CRUSH definiscono il modo in cui gli OSD vengono selezionati dall'albero. Una regola inizia con un nodo, quindi effettua un'iterazione lungo l'albero per restituire un set di OSD. Non è possibile definire quale diramazione selezionare. L'algoritmo CRUSH assicura invece che il set di OSD soddisfi i requisiti di replica e distribuisca uniformemente i dati.

Con step take bucket l'iterazione nell'albero di noti inizia in un determinato compartimento (non in un tipo di compartimento). Se gli OSD provenienti da tutte le diramazioni nell'albero vengono restituiti, il compartimento deve essere il compartimento radice. Altrimenti per gli "step" seguenti l'iterazione ha luogo tramite un sottoalbero.

Dopo step take nella definizione della regola seguono una o più voci step choose. Ogni step choose sceglie un numero definito di nodi (o diramazioni) dal nodo superiore selezionato precedentemente.

Alla fine gli OSD selezionati vengono restituiti con step emit.

step chooseleaf è una pratica funzione che consente di selezionare direttamente gli OSD dalle diramazioni del compartimento specificato.

La Figura 17.2, «Albero di esempio» è un esempio di come viene utilizzato step per l'iterazione in un albero. Le frecce e i numeri arancioni corrispondono a example1a e example1b, mentre quelli blu corrispondono a example2 nelle seguenti definizioni delle regole.

Figura 17.2: Albero di esempio #

 

# orange arrows
rule example1a {
        ruleset 0
        type replicated
        min_size 2
        max_size 10
        # orange (1)
        step take rack1
        # orange (2)
        step choose firstn 0 host
        # orange (3)
        step choose firstn 1 osd
        step emit
}

rule example1b {
        ruleset 0
        type replicated
        min_size 2
        max_size 10
        # orange (1)
        step take rack1
        # orange (2) + (3)
        step chooseleaf firstn 0 host
        step emit
}

# blue arrows
rule example2 {
        ruleset 0
        type replicated
        min_size 2
        max_size 10
        # blue (1)
        step take room1
        # blue (2)
        step chooseleaf firstn 0 rack
        step emit
}

Una regola CRUSH definisce le sostituzioni per i nodi o gli OSD non riusciti (vedere Sezione 17.3, «Set di regole»). Per lo step della parola chiave è richiesto firstn o indep come parametro. Figura 17.3, «Metodi di sostituzione dei nodi» fornisce un esempio.

firstn aggiunge i nodi di sostituzione alla fine dell'elenco dei nodi attivi. Nel caso di un nodo non riuscito, i seguenti nodi integri vengono spostati a sinistra per colmare il vuoto lasciato dal nodo non riuscito. Questo è il metodo di default e desiderato per i pool replicati, perché un nodo secondario contiene già tutti i dati e può essere impiegato immediatamente per svolgere i compiti del nodo primario.

indep seleziona i nodi di sostituzione per ciascun nodo attivo. La sostituzione di un nodo non riuscito non cambia l'ordine dei nodi rimanenti. Ciò è adatto per i pool con codice di cancellazione. Nei pool con codice di cancellazione, i dati memorizzati in un nodo dipendono dalla rispettiva posizione nella selezione del nodo. Quando l'ordine dei nodi cambia, tutti i dati nei nodi interessati devono essere trasferiti.

Figura 17.3: Metodi di sostituzione dei nodi #

 

Un gruppo di posizionamento (PG) aggrega gli oggetti all'interno di un pool. Il motivo principale risiede nel fatto che il controllo del posizionamento degli oggetti e dei metadati per i singoli oggetti è un'attività onerosa per le risorse di elaborazione. Ad esempio, un sistema con milioni di oggetti non è in grado di controllare direttamente il posizionamento di ciascuno di questi oggetti.

Figura 17.4: Gruppi di posizionamento in un pool #

 

Il client Ceph calcola il gruppo di posizionamento a cui apparterrà un oggetto. Per farlo, esegue l'hashing dell'ID dell'oggetto e applica un'operazione basata sul numero di gruppi di posizionamento presenti nel pool specificato e sull'ID del pool.

I contenuti dell'oggetto all'interno di un gruppo di posizionamento sono memorizzati in un set di OSD. Ad esempio, in un pool replicato di dimensione due, ogni gruppo di posizionamento memorizzerà gli oggetti su due OSD:

Figura 17.5: Gruppi di posizionamento e OSD #

 

Se sull'OSD num. 2 si verificano degli errori, un altro OSD verrà assegnato al gruppo di posizionamento num. 1 e verrà compilato con le copie di tutti gli oggetti nell'OSD num. 1. Se la dimensione del pool viene modificata da due a tre, al gruppo di posizionamento verrà assegnato un altro OSD che riceverà le copie di tutti gli oggetti nel gruppo di posizionamento.

I gruppi di posizionamento non possiedono l'OSD, ma lo condividono con altri gruppi di posizionamento dello stesso pool o persino di altri pool. Se si verificano degli errori sull'OSD num. 2, il gruppo di posizionamento num. 2 dovrà ripristinare le copie degli oggetti utilizzando l'OSD num. 3.

Se il numero di gruppi di posizionamento aumenta, i nuovi gruppi verranno assegnati agli OSD. Anche il risultato della funzione CRUSH cambierà e alcuni oggetti dei gruppi di posizionamento precedenti verranno copiati sui nuovi gruppi di posizionamento e rimossi da quelli precedenti.

Nota

A partire da Ceph Nautilus (v14.x), è possibile utilizzare il modulo pg_autoscaler di Ceph Manager per il dimensionamento automatico dei gruppi di posizionamento in base alle esigenze. Se si desidera abilitare questa funzione, fare riferimento a Sezione 6.1.1.1, «Default PG and PGP counts».

Durante la creazione di un nuovo pool, è comunque possibile impostare manualmente il valore di PG_NUM:

root # ceph osd pool create POOL_NAME PG_NUM

PG_NUM non può essere calcolato automaticamente. Di seguito sono elencati alcuni valori utilizzati di frequente, a seconda del numero di OSD nel cluster:

Via via che il numero di OSD aumenta, diventa sempre più importante scegliere un valore corretto per PG_NUM. PG_NUM influisce sul comportamento del cluster e sulla durata dei dati in caso di errore dell'OSD.

total PGs = (OSDs * 100) / POOL_SIZE

          (200 * 100) / 3 = 6667

Nota

A partire da Ceph Nautilus (v14.x), è possibile utilizzare il modulo pg_autoscaler di Ceph Manager per il dimensionamento automatico dei gruppi di posizionamento in base alle esigenze. Se si desidera abilitare questa funzione, fare riferimento a Sezione 6.1.1.1, «Default PG and PGP counts».

Se occorre tuttavia specificare manualmente il numero di gruppi di posizionamento all'interno di un pool, è necessario farlo al momento della creazione di quest'ultimo (vedere la Sezione 18.1, «Creazione di un pool»). Dopo aver impostato i gruppi di posizionamento per un pool, è possibile aumentarne il numero con il comando seguente:

root # ceph osd pool set POOL_NAME pg_num PG_NUM

Dopo aver aumentato il numero di gruppi di posizionamento, è necessario aumentare anche il numero di gruppi di posizionamento per il posizionamento (PGP_NUM) per ribilanciare il cluster. PGP_NUM corrisponderà al numero di gruppi di posizionamento che verranno calcolati per il posizionamento dall'algoritmo CRUSH. L'aumento di PG_NUM comporta la suddivisione dei gruppi di posizionamento, ma la migrazione dei dati nei nuovi gruppi di posizionamento non sarà eseguita finché non verrà aumentato il valore di PGP_NUM. PGP_NUM deve essere uguale a PG_NUM. Per aumentare il numero dei gruppi di posizionamento per il posizionamento, eseguire quanto riportato di seguito:

root # ceph osd pool set POOL_NAME pgp_num PGP_NUM

Per individuare il numero dei gruppi di posizionamento in un pool, eseguire il comando get seguente:

root # ceph osd pool get POOL_NAME pg_num

Per individuare le statistiche dei gruppi di posizionamento nel cluster, eseguire il comando seguente:

root # ceph pg dump [--format FORMAT]

I formati validi sono "plain" (default) e "json".

Per individuare le statistiche di tutti i gruppi di posizionamento bloccati in uno stato specifico, eseguire quanto riportato di seguito:

root # ceph pg dump_stuck STATE \
 [--format FORMAT] [--threshold THRESHOLD]

STATE può indicare uno stato tra "inactive" (i gruppi di posizionamento non sono in grado di elaborare le operazioni di lettura o scrittura perché sono in attesa di un OSD con i dati più recenti), "unclean" (i gruppi di posizionamento contengono oggetti non replicati per il numero di volte desiderato), "stale" (i gruppi di posizionamento si trovano in uno stato sconosciuto; gli OSD che li ospitano non hanno informato il cluster di monitoraggio entro l'intervallo di tempo specificato dall'opzione mon_osd_report_timeout), "undersized" o "degraded".

I formati validi sono "plain" (default) e "json".

La soglia definisce il numero minimo di secondi in cui il gruppo di posizionamento resta bloccato prima di essere incluso nelle statistiche (l'impostazione di default è 300 secondi).

Per cercare la mappa di un determinato gruppo di posizionamento, eseguire quanto riportato di seguito:

root # ceph pg map PG_ID

Ceph restituirà la mappa del gruppo di posizionamento, il gruppo di posizionamento e lo stato dell'OSD:

root # ceph pg map 1.6c
osdmap e13 pg 1.6c (1.6c) -> up [1,0] acting [1,0]

Per recuperare le statistiche di un determinato gruppo di posizionamento, eseguire quanto riportato di seguito:

root # ceph pg PG_ID query

Per pulire (Sezione 17.6, «Pulitura dei gruppi di posizionamento») un gruppo di posizionamento, eseguire quanto riportato di seguito:

root # ceph pg scrub PG_ID

Ceph controlla il nodo primario e di replica, genera un catalogo di tutti gli oggetti del gruppo di posizionamento e li confronta per verificare che non ci siano oggetti mancanti o non corrispondenti e che i contenuti siano coerenti. Presupponendo la corrispondenza di tutte le repliche, una pulizia semantica finale assicura che tutti i metadati di oggetto relativi alla snapshot siano coerenti. Gli errori vengono segnalati tramite i log.

In alcune situazioni può capitare di dover recuperare e/o eseguire il backfill di più gruppi di posizionamento, alcuni dei quali contengono dati più importanti di altri. Ad esempio, questi gruppi di posizionamento possono contenere dati di immagini utilizzati dai computer in esecuzione, mentre altri gruppi possono essere utilizzati da computer inattivi o da dati meno pertinenti. In questo caso, è consigliabile assegnare la priorità al recupero di questi gruppi per ripristinare per prime la disponibilità e le prestazioni dei dati memorizzati in questi gruppi. Per contrassegnare determinati gruppi di posizionamento come prioritari durante il backfill o il recupero, eseguire quanto riportato di seguito:

root # ceph pg force-recovery PG_ID1 [PG_ID2 ... ]
root # ceph pg force-backfill PG_ID1 [PG_ID2 ... ]

In questo modo, Ceph eseguirà innanzitutto il recupero o il backfill dei gruppi di posizionamento specificati prima di passare agli altri gruppi. Questa impostazione non interrompe i processi di recupero o backfill in corso, ma fa in modo che i gruppi di posizionamento specificati vengano elaborati il prima possibile. Se si cambia idea o si assegna priorità ai gruppi errati, annullare la definizione della priorità:

root # ceph pg cancel-force-recovery PG_ID1 [PG_ID2 ... ]
root # ceph pg cancel-force-backfill PG_ID1 [PG_ID2 ... ]

I comandi cancel-* rimuovono il flag "force" dai gruppi di posizionamento che vengono quindi elaborati nell'ordine di default. Di nuovo, questa impostazione non influisce sui gruppi di posizionamento in corso di elaborazione, ma soltanto su quelli che si trovano in coda. Il flag "force" viene cancellato automaticamente al termine del processo di recupero o backfill del gruppo.

Se il cluster ha perso uno o più oggetti e l'utente ha deciso di abbandonare la ricerca dei dati persi, occorre contrassegnare gli oggetti non trovati come "lost".

Se gli oggetti ancora non si trovano dopo aver interrogato tutte le ubicazioni disponibili, è possibile che non si possano individuare. Ciò è possibile date le insolite combinazioni di errori che consentono al cluster di raccogliere informazioni sulle operazioni di scrittura effettuate prima del loro recupero.

Attualmente, l'unica opzione supportata è "revert", che consente di ripristinare una versione precedente dell'oggetto o di eliminarla completamente se si tratta di un nuovo oggetto. Per contrassegnare gli oggetti "unfound" come "lost", eseguire quanto riportato di seguito:

  cephuser@adm > ceph pg PG_ID mark_unfound_lost revert|delete

I gruppi di posizionamento rappresentano un dettaglio di implementazione interno della modalità di distribuzione dei dati da parte di Ceph. Abilitando il dimensionamento automatico dei gruppi di posizionamento, si consente al cluster di creare oppure ottimizzare automaticamente i gruppi di posizionamento in base alla modalità di utilizzo del cluster stesso.

Ogni pool nel sistema dispone di una proprietà pg_autoscale_mode che può essere impostata su off, on o warn:

L'utilità di dimensionamento automatico è configurata per ogni singolo pool e può essere eseguita in tre modalità:

Per impostare la modalità di dimensionamento automatico per i pool esistenti:

cephuser@adm > ceph osd pool set POOL_NAME pg_autoscale_mode mode

È inoltre possibile configurare la modalità pg_autoscale_mode di default da applicare ai pool creati in futuro con:

cephuser@adm > ceph config set global osd_pool_default_pg_autoscale_mode MODE

È possibile visualizzare ciascun pool, il relativo utilizzo e le eventuali modifiche del numero di gruppi di posizionamento suggerite con questo comando:

cephuser@adm > ceph osd pool autoscale-status

Per modificare una mappa CRUSH esistente, procedere come indicato di seguito:

Suggerimento: utilizzo di un sistema di controllo versioni

Utilizzare un sistema di controllo versioni, come git o svn, per i file della mappa CRUSH esportati e modificati per semplificare un possibile rollback.

Suggerimento: test della nuova mappa CRUSH

Testare la nuova mappa CRUSH modificata tramite il comando crushtool --test e confrontarla con lo stato prima di applicarla. Le seguenti opzioni di comando potrebbero risultare utili: --show-statistics, --show-mappings, --show-bad-mappings, ‑‑show-utilization, --show-utilization-all, --show-choose-tries

Per aggiungere o spostare un OSD nella mappa CRUSH di un cluster in esecuzione, eseguire quanto riportato di seguito:

cephuser@adm > ceph osd crush set id_or_name weight root=pool-name
bucket-type=bucket-name ...

Nell'esempio seguente viene aggiunto osd.0 alla gerarchia o viene spostato l'OSD da un'ubicazione precedente.

cephuser@adm > ceph osd crush set osd.0 1.0 root=data datacenter=dc1 room=room1 \
row=foo rack=bar host=foo-bar-1

Vi sono due comandi simili che cambiano la variabile "weight" di un Ceph OSD. Il loro contesto d'uso è diverso e può generare confusione.

17.5.3.1 ceph osd reweight #

 

Utilizzo:

cephuser@adm > ceph osd reweight OSD_NAME NEW_WEIGHT

ceph osd reweight imposta il peso sostitutivo sul Ceph OSD. Questo valore è compreso tra 0 e 1 e forza CRUSH a riposizionare i dati che altrimenti risiederebbero in questa unità. Non cambia i pesi assegnati ai compartimenti sopra l'OSD ed è una misura correttiva in caso di cattivo funzionamento della normale distribuzione CRUSH. Ad esempio, se uno degli OSD si trova al 90% e gli altri al 40%, è possibile ridurre il peso per provare a compensarlo.

Nota: il peso dell'OSD è temporaneo

Tenere presente che ceph osd reweight non è un'impostazione permanente. Quando un OSD non viene contrassegnato, il suo peso viene impostato a 0 e cambia su 1 quando il dispositivo viene contrassegnato nuovamente.

cephuser@adm > ceph osd crush reweight OSD_NAME NEW_WEIGHT

Per rimuovere un OSD dalla mappa CRUSH di un cluster in esecuzione, eseguire quanto riportato di seguito:

cephuser@adm > ceph osd crush remove OSD_NAME

Per aggiungere un compartimento alla mappa CRUSH di un cluster in esecuzione, eseguire il comando ceph osd crush add-bucket:

cephuser@adm > ceph osd crush add-bucket BUCKET_NAME BUCKET_TYPE

Per spostare un compartimento in un'altra ubicazione o posizione nella gerarchia della mappa CRUSH, eseguire quanto riportato di seguito:

cephuser@adm > ceph osd crush move BUCKET_NAME BUCKET_TYPE=BUCKET_NAME [...]

Esempio:

cephuser@adm > ceph osd crush move bucket1 datacenter=dc1 room=room1 row=foo rack=bar host=foo-bar-1

Per rimuovere un compartimento dalla gerarchia della mappa CRUSH, eseguire quanto riportato di seguito:

cephuser@adm > ceph osd crush remove BUCKET_NAME

Nota: soltanto compartimenti vuoti

I compartimenti devono essere vuoti per poter essere rimossi dalla gerarchia CRUSH.