Vai al contenutoNaviga tra le pagine: pagina precedente [tasto di scelta p]/pagina successiva [tasto di scelta n]
documentation.suse.com / Documentazione di SUSE Enterprise Storage 7 / Guida alle operazioni e all'amministrazione / Memorizzazione dei dati in un cluster / Gestione dei dati memorizzati
Si applica a SUSE Enterprise Storage 7

17 Gestione dei dati memorizzati

L'algoritmo CRUSH determina la modalità di storage e recupero dei dati mediante il calcolo delle ubicazioni di memorizzazione dati. CRUSH consente ai client Ceph di comunicare direttamente con gli OSD piuttosto che tramite un server centralizzato o un broker. Grazie ad un sistema per lo storage e il recupero dei dati basato su algoritmi, Ceph consente di evitare single point of failure, colli di bottiglia delle prestazioni e limiti fisici alla rispettiva scalabilità.

Per CRUSH è richiesta una mappa del cluster e viene utilizzata la mappa CRUSH per memorizzare e recuperare dati negli OSD in modo pressoché casuale, con una distribuzione uniforme dei dati nel cluster.

Le mappe CRUSH contengono: un elenco di OSD, un elenco di "compartimenti" per aggregare i dispositivi in ubicazioni fisiche e un elenco di regole che indicano a CRUSH come replicare i dati nei pool di un cluster Ceph. Riflettendo l'organizzazione fisica dell'installazione sottostante, CRUSH è in grado di modellare, e quindi di risolvere, potenziali origini di errori dei dispositivi correlati. Tra le origini tipiche sono incluse la prossimità fisica, un'alimentazione condivisa e una rete condivisa. Mediante la codifica di queste informazioni nella mappa del cluster, le policy di posizionamento di CRUSH possono separare le repliche di oggetti in vari domini di errore, continuando a mantenere la distribuzione desiderata. Ad esempio, per risolvere la possibilità di errori simultanei, può essere necessario assicurare che le repliche dei dati siano su dispositivi che utilizzano scaffali, rack, alimentatori, controller e/o ubicazioni fisiche.

Dopo aver distribuito un cluster Ceph cluster, viene generata una mappa CRUSH di default. Questa è adatta per l'ambiente sandbox Ceph. Quando tuttavia si distribuisce un cluster di dati su larga scala, considerare attentamente lo sviluppo di una mappa CRUSH personalizzata da utilizzare per gestire il cluster, migliorare le prestazioni e garantire la sicurezza dei dati.

Se ad esempio un OSD si interrompe, può essere utile una mappa CRUSH per individuare il data center fisico, la stanza, la fila e il rack dell'host con l'OSD non riuscito nel caso in cui sia necessario utilizzare un supporto on site o sostituire l'hardware.

In modo analogo, CRUSH può consentire di identificare gli errori più rapidamente. Ad esempio, se tutti gli OSD in un determinato rack si interrompono simultaneamente, è possibile che l'errore risieda in un interruttore di rete o nell'alimentazione del rack oppure nell'interruttore di rete piuttosto che negli OSD stessi.

Una mappa CRUSH personalizzata consente inoltre di identificare le ubicazioni fisiche in cui Ceph memorizza le copie ridondanti dei dati quando i gruppi di posizionamento (consultare Sezione 17.4, «Gruppi di posizionamento») associati a un host con errori si trovano in stato danneggiato.

In una mappa CRUSH sono presenti tre sezioni principali.

  • Dispositivi OSD: qualsiasi Object Storage Device corrispondente a un daemon ceph-osd.

  • Compartimenti: aggregazione gerarchica delle ubicazioni di memorizzazione (ad esempio file, rack, host e così via) e i rispettivi pesi assegnati.

  • Set di regole: modo in cui vengono selezionati i compartimenti.

17.1 Dispositivi OSD

Per mappare i gruppi di posizionamento negli OSD, per la mappa CRUSH è richiesto un elenco di dispositivi OSD (il nome del daemon OSD). L'elenco dei dispositivi viene visualizzato prima nella mappa CRUSH.

#devices
device NUM osd.OSD_NAME class CLASS_NAME

Esempio:

#devices
device 0 osd.0 class hdd
device 1 osd.1 class ssd
device 2 osd.2 class nvme
device 3 osd.3class ssd

Come regola generale, un daemon OSD viene mappato in un disco singolo.

17.1.1 Classi di dispositivi

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.

OSD con classi di dispositivi miste
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.

17.1.1.2 Classi di dispositivi

Una comoda soluzione offerta da Ceph è la possibilità di aggiungere una proprietà denominata device class a ciascun OSD. Per default, gli OSD impostano automaticamente le relative classi di dispositivi su "hdd", "ssd" o "nvme" in base alle proprietà hardware esposte dal kernel Linux. Queste classi di dispositivi sono indicate in una nuova colonna dell'output del comando ceph osd tree:

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

Se il rilevamento automatico della classe di dispositivi non riesce, ad esempio perché il driver del dispositivo non espone correttamente le informazioni sul dispositivo tramite sys/block, è possibile modificare le classi di dispositivi dalla riga di comando:

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'

17.1.1.3 Impostazione delle regole di posizionamento CRUSH

Tramite le regole CRUSH, è possibile limitare il posizionamento a una classe di dispositivi specifica. Ad esempio, è possibile creare un pool replicato "fast" per distribuire i dati soltanto sui dischi SSD tramite l'esecuzione del comando seguente:

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

Esempio:

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

Creare un pool denominato "fast_pool" e assegnarlo alla regola "fast":

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

La procedura di creazione delle regole del codice di cancellazione è leggermente diversa. Innanzitutto, occorre creare un profilo con codice di cancellazione che includa una proprietà per la classe di dispositivi desiderata. Quindi, utilizzare tale profilo durante la creazione del pool con codice di cancellazione:

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

Se occorre modificare manualmente la mappa CRUSH per personalizzare la regola, è possibile specificare la classe di dispositivi tramite la sintassi estesa. Ad esempio, la regola CRUSH generata dai comandi riportati sopra è la seguente:

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
}

La differenza fondamentale qui è che il comando "take" include il suffisso aggiuntivo "class CLASS_NAME".

17.1.1.4 Comandi aggiuntivi

Per visualizzare un elenco delle classi di dispositivi utilizzate in una mappa CRUSH, eseguire:

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

Per visualizzare un elenco delle regole CRUSH esistenti, eseguire:

cephuser@adm > ceph osd crush rule ls
replicated_rule
fast

Per visualizzare i dettagli della regola CRUSH denominata "fast", eseguire:

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"
						}
		]
}

Per visualizzare un elenco degli OSD appartenenti a una classe "ssd", eseguire:

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

17.1.1.5 Esecuzione della migrazione da una regola SSD esistente alle classi di dispositivi

Nelle versioni di SUSE Enterprise Storage precedenti alla 5, occorreva modificare manualmente la mappa CRUSH e mantenere una gerarchia parallela per ogni tipo di dispositivo specializzato (ad esempio SSD) se si volevano scrivere le regole applicabili a tali dispositivi. Da SUSE Enterprise Storage 5 in poi, la funzione della classe di dispositivi ha reso possibile questa procedura in modo invisibile all'utente.

Tramite il comando crushtool, è possibile trasformare una regola e una gerarchia esistenti nelle nuove regole basate sulla classe. Sono possibili diversi tipi di trasformazione:

crushtool --reclassify-root ROOT_NAME DEVICE_CLASS

Questo comando include tutti gli elementi della gerarchia al di sotto di ROOT_NAME e modifica le regole che fanno riferimento a tale radice tramite

take ROOT_NAME

in

take ROOT_NAME class DEVICE_CLASS

Rinumera i compartimenti per fare in modo che gli ID obsoleti vengano utilizzati per lo "shadow tree" della classe specificata. Di conseguenza, non si verificano spostamenti di dati.

Esempio 17.1: crushtool --reclassify-root

Prendere in considerazione la seguente regola esistente:

rule replicated_ruleset {
   id 0
   type replicated
   min_size 1
   max_size 10
   step take default
   step chooseleaf firstn 0 type rack
   step emit
}

Se si riclassifica la radice "default" come classe "hdd", la regola diventerà

rule replicated_ruleset {
   id 0
   type replicated
   min_size 1
   max_size 10
   step take default class hdd
   step chooseleaf firstn 0 type rack
   step emit
}
crushtool --set-subtree-class BUCKET_NAME DEVICE_CLASS

Questo metodo contrassegna ogni dispositivo nel sottoalbero con radice BUCKET_NAME con la classe di dispositivi specificata.

L'opzione --set-subtree-class viene in genere utilizzata insieme all'opzione --reclassify-root per assicurarsi che tutti i dispositivi in tale radice siano etichettati con la classe corretta. Tuttavia, alcuni di questi dispositivi possono avere intenzionalmente una classe diversa e pertanto non è necessario etichettarli nuovamente. In questi casi, escludere l'opzione --set-subtree-class. Tenere presente che la nuova mappatura non sarà perfetta, perché la regola precedente è distribuita ai dispositivi di più classi, ma le regole modificate effettueranno la mappatura soltanto ai dispositivi della classe specificata.

crushtool --reclassify-bucket MATCH_PATTERN DEVICE_CLASS DEFAULT_PATTERN

Questo metodo consente di unire una gerarchia parallela specifica del tipo con la gerarchia normale. Ad esempio, molti utenti dispongono di mappe CRUSH simili alla seguente:

Esempio 17.2: crushtool --reclassify-bucket
host node1 {
   id -2           # do not change unnecessarily
   # weight 109.152
   alg straw
   hash 0  # rjenkins1
   item osd.0 weight 9.096
   item osd.1 weight 9.096
   item osd.2 weight 9.096
   item osd.3 weight 9.096
   item osd.4 weight 9.096
   item osd.5 weight 9.096
   [...]
}

host node1-ssd {
   id -10          # do not change unnecessarily
   # weight 2.000
   alg straw
   hash 0  # rjenkins1
   item osd.80 weight 2.000
   [...]
}

root default {
   id -1           # do not change unnecessarily
   alg straw
   hash 0  # rjenkins1
   item node1 weight 110.967
   [...]
}

root ssd {
   id -18          # do not change unnecessarily
   # weight 16.000
   alg straw
   hash 0  # rjenkins1
   item node1-ssd weight 2.000
   [...]
}

Questa funzione riclassifica ogni compartimento corrispondente a un modello specificato. Il modello può essere simile a %suffix o a prefix%. Nell'esempio riportato sopra, è utilizzato il modello %-ssd. Per ciascun compartimento corrispondente, la porzione rimanente del nome che corrisponde al carattere jolly "%" specifica il compartimento di base. Tutti i dispositivi nel compartimento corrispondente vengono etichettati con la classe di dispositivi specificata e quindi spostati nel compartimento di base. Se quest'ultimo non esiste (ad esempio se "node12-ss" esiste, ma "node12" non esiste), viene creato e collegato al di sotto del compartimento superiore di default specificato. Gli ID dei compartimenti obsoleti vengono conservati per i nuovi compartimenti replicati al fine di impedire il trasferimento dei dati. Le regole con i passaggi take che fanno riferimento ai compartimenti obsoleti vengono modificate.

crushtool --reclassify-bucket BUCKET_NAME DEVICE_CLASS BASE_BUCKET

È possibile utilizzare l'opzione --reclassify-bucket senza caratteri jolly per mappare un compartimento singolo. Nell'esempio precedente, si intende mappare il compartimento "ssd" al compartimento di default.

Il comando finale per la conversione della mappa, compresi i frammenti riportati sopra, è il seguente:

cephuser@adm > ceph osd getcrushmap -o original
cephuser@adm > crushtool -i original --reclassify \
  --set-subtree-class default hdd \
  --reclassify-root default hdd \
  --reclassify-bucket %-ssd ssd default \
  --reclassify-bucket ssd ssd default \
  -o adjusted

Per verificare la correttezza della conversione, è disponibile l'opzione --compare che consente di testare un ampio campione di input della mappa CRUSH e di verificare che vengano restituiti gli stessi risultati. Questi input sono controllati dalle stesse opzioni che si applicano all'opzione --test. Per l'esempio riportato sopra, il comando è il seguente:

cephuser@adm > crushtool -i original --compare adjusted
rule 0 had 0/10240 mismatched mappings (0)
rule 1 had 0/10240 mismatched mappings (0)
maps appear equivalent
Suggerimento
Suggerimento

In caso di differenze, tra parentesi viene indicata la percentuale degli input di cui è stata ripetuta la mappatura.

Dopo aver apportato tutte le modifiche desiderate alla mappa CRUSH, sarà possibile applicarla al cluster:

cephuser@adm > ceph osd setcrushmap -i adjusted

17.1.1.6 Ulteriori informazioni

Nella Sezione 17.5, «Modifica della mappa CRUSH» sono disponibili ulteriori dettagli sulle mappe CRUSH.

Nel Capitolo 18, Gestione dei pool di memorizzazione sono disponibili ulteriori informazioni generali sui pool Ceph.

Nel Capitolo 19, Pool con codice di cancellazione sono disponibili ulteriori dettagli sui pool con codice di cancellazione.

17.2 Compartimenti

Le mappe CRUSH contengono un elenco di OSD che è possibile organizzare in una struttura ad albero di compartimenti, in modo da aggregare i dispositivi in ubicazioni fisiche. I singoli OSD comprendono le foglie dell'albero.

0

osd

Un dispositivo specifico oppure OSD (osd.1, osd.2 ecc).

1

host

Nome di un host contenente uno o più OSD.

2

chassis

Identificatore dello chassis del rack contenente l'host.

3

rack

Un rack per computer. L'impostazione di default è unknownrack.

4

row

Una fila in una serie di rack.

5

pdu

Abbreviazione di "Power Distribution Unit" (unità di distribuzione di alimentazione).

6

pod

Abbreviazione di "Point of Delivery" (punto di consegna): in questo contesto, un gruppo di PDU o un gruppo di righe di rack.

7

room

Una stanza contenente righe di rack.

8

datacenter

Un data center fisico contenente uno o più stanze.

9

region

Area geografica del mondo (ad esempio, NAM, LAM, EMEA, APAC ecc).

10

root

Il nodo radice dell'albero dei compartimenti OSD (in genere impostato su default).

Suggerimento
Suggerimento

È possibile modificare i tipi di compartimenti esistenti e crearne altri personalizzati.

Gli strumenti di distribuzione di Ceph generano una mappa CRUSH contenente un compartimento per ciascun host e una radice denominata "default", utile per il pool rbd di default. I tipi di compartimenti rimanenti sono un mezzo per memorizzare le informazioni sull'ubicazione fisica di nodi/compartimenti, che rende l'amministrazione del cluster molto più semplice in caso di malfunzionamento degli OSD, degli host o dell'hardware di rete e l'amministratore deve accedere all'hardware fisico.

I compartimenti dispongono di un tipo, un nome univoco (stringa), un ID univoco espresso come numero intero negativo, un peso relativo alla capacità totale/capacità degli elementi corrispondenti, un algoritmo di compartimento (straw2 per default) e l'hash (0 per default, che riflette l'hash CRUSH rjenkins1). Un compartimento può contenere uno o più elementi. Gli elementi possono essere costituiti da altri compartimenti o OSD. Gli elementi possono avere un peso che riflette quello relativo dell'elemento.

[bucket-type] [bucket-name] {
  id [a unique negative numeric ID]
  weight [the relative capacity/capability of the item(s)]
  alg [the bucket type: uniform | list | tree | straw2 | straw ]
  hash [the hash type: 0 by default]
  item [item-name] weight [weight]
}

Nell'esempio seguenti è illustrato come utilizzare i compartimenti per aggregare un pool e ubicazioni fisiche come un data center, una stanza, un rack e una fila.

host ceph-osd-server-1 {
        id -17
        alg straw2
        hash 0
        item osd.0 weight 0.546
        item osd.1 weight 0.546
}

row rack-1-row-1 {
        id -16
        alg straw2
        hash 0
        item ceph-osd-server-1 weight 2.00
}

rack rack-3 {
        id -15
        alg straw2
        hash 0
        item rack-3-row-1 weight 2.00
        item rack-3-row-2 weight 2.00
        item rack-3-row-3 weight 2.00
        item rack-3-row-4 weight 2.00
        item rack-3-row-5 weight 2.00
}

rack rack-2 {
        id -14
        alg straw2
        hash 0
        item rack-2-row-1 weight 2.00
        item rack-2-row-2 weight 2.00
        item rack-2-row-3 weight 2.00
        item rack-2-row-4 weight 2.00
        item rack-2-row-5 weight 2.00
}

rack rack-1 {
        id -13
        alg straw2
        hash 0
        item rack-1-row-1 weight 2.00
        item rack-1-row-2 weight 2.00
        item rack-1-row-3 weight 2.00
        item rack-1-row-4 weight 2.00
        item rack-1-row-5 weight 2.00
}

room server-room-1 {
        id -12
        alg straw2
        hash 0
        item rack-1 weight 10.00
        item rack-2 weight 10.00
        item rack-3 weight 10.00
}

datacenter dc-1 {
        id -11
        alg straw2
        hash 0
        item server-room-1 weight 30.00
        item server-room-2 weight 30.00
}

root data {
        id -10
        alg straw2
        hash 0
        item dc-1 weight 60.00
        item dc-2 weight 60.00
}

17.3 Set di regole

Le mappe CRUSH supportano la nozione delle "regole CRUSH", che sono regole che determinano il posizionamento dei dati per un pool. Per i cluster di grandi dimensioni è probabile che vengano creati numerosi pool, ciascuno dei quali presenta set di regole e regole CRUSH propri. Per default, la mappa CRUSH dispone di una regola per la radice di default. Se sono necessarie più radici e più regole, occorre crearle in un secondo momento. In alternativa, queste verranno create automaticamente insieme ai nuovi pool.

Nota
Nota

Nella maggior parte dei casi non sarà necessario modificare le regole di default. Quando si crea un nuovo pool, il rispettivo set di regole di default è 0.

Una regola è strutturata nel modo seguente:

rule rulename {

        ruleset ruleset
        type type
        min_size min-size
        max_size max-size
        step step

}
ruleset

Un numero intero. Classifica una regola come appartenente a un set di regole. Attivato mediante l'impostazione del set di regole in un pool. Questa opzione è obbligatoria. Il valore di default è 0.

tipo

Stringa. Descrive una regola per un pool con codice "replicated" o "coded". Questa opzione è obbligatoria. L'impostazione di default è replicated.

min_size

Un numero intero. Se un gruppo di pool crea un numero di repliche inferiore a questo numero, CRUSH NON selezionerà questa regola. Questa opzione è obbligatoria. Il valore di default è 2.

max_size

Un numero intero. Se un gruppo di pool crea un numero di repliche superiore a questo numero, CRUSH NON selezionerà questa regola. Questa opzione è obbligatoria. Il valore di default è 10.

step take bucket

Prende un compartimento specificato tramite nome e avvia l'iterazione lungo l'albero. Questa opzione è obbligatoria. Per una spiegazione sull'iterazione nell'albero, vedere Sezione 17.3.1, «Iterazione dell'albero di nodi».

step targetmodenum type bucket-type

target può essere sia choose sia chooseleaf. Quando impostata su choose, viene selezionato un numero di compartimenti. chooseleaf seleziona direttamente gli OSD (nodi foglia) dal sottoalbero di ciascun compartimento nel set di compartimenti.

mode può essere sia firstn sia indep. Vedere Sezione 17.3.2, «firstn e indep».

Seleziona il numero di compartimenti di un determinato tipo. Dove N è il numero delle opzioni disponibili, se num > 0 && < N, scegliere tale numero di compartimenti; se num < 0, significa N - num; e se num == 0, scegliere N compartimenti (tutti disponibili). Segue step take o step choose.

step emit

Genera il valore corrente e svuota lo stack. Di norma utilizzata alla fine di una regola, ma può essere impiegata per formare alberi diversi nell'ambito della stessa regola. Segue step choose.

17.3.1 Iterazione dell'albero di nodi

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

Albero di esempio
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
}

17.3.2 firstn e indep

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.

Metodi di sostituzione dei nodi
Figura 17.3: Metodi di sostituzione dei nodi

17.4 Gruppi di posizionamento

Ceph mappa gli oggetti ai gruppi di posizionamento (PG). I gruppi di posizionamento sono partizionamenti o frammenti di un pool di oggetti logico che posizionano gli oggetti sotto forma di gruppi negli OSD. I gruppi di posizionamento riducono la quantità di metadati per oggetto quando Ceph memorizza i dati negli OSD. Più è alto il numero di gruppi di posizionamento (ad esempio 100 per OSD), migliore sarà il bilanciamento.

17.4.1 Utilizzo dei gruppi di posizionamento

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.

Gruppi di posizionamento in un pool
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:

Gruppi di posizionamento e 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.

17.4.2 Determinazione del valore di PG_NUM

Nota
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:

Meno di 5 OSD:

Impostare PG_NUM su 128.

Tra 5 e 10 OSD:

Impostare PG_NUM su 512.

Tra 10 e 50 OSD:

Impostare PG_NUM su 1024.

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.

17.4.2.1 Calcolo dei gruppi di posizionamento per più di 50 OSD

Se si hanno meno di 50 OSD, utilizzare la preselezione descritta nella Sezione 17.4.2, «Determinazione del valore di PG_NUM». Se si hanno più di 50 OSD, si consiglia di utilizzare circa 50-100 gruppi di posizionamento per OSD per bilanciare l'uso delle risorse, la durata dei dati e la distribuzione. Per un pool di oggetti singolo, è possibile utilizzare la formula seguente per ottenere una linea di base:

total PGs = (OSDs * 100) / POOL_SIZE

Dove POOL_SIZE rappresenta il numero di repliche dei pool replicati o la somma "k"+"m" dei pool con codice di cancellazione restituita dal comando ceph osd erasure-code-profile get. Arrotondare il risultato alla potenza più vicina di 2. Si consiglia di arrotondare l'algoritmo CRUSH per bilanciare equamente il numero di oggetti tra i gruppi di posizionamento.

Ad esempio, per un cluster con 200 OSD e con una dimensione pool di 3 repliche, calcolare il numero di gruppi di posizionamento come segue:

          (200 * 100) / 3 = 6667

La potenza più vicina di 2 è 8192.

Se si utilizzano più pool di dati per la memorizzazione degli oggetti, occorre assicurarsi di bilanciare il numero di gruppi di posizionamento per ogni pool con il numero di gruppi di posizionamento per ogni OSD. Occorre raggiungere un numero totale di gruppi di posizionamento ragionevole che fornisca una varianza abbastanza ridotta per OSD senza gravare sulle risorse di sistema o rallentare troppo il processo di peering.

Ad esempio, un cluster di 10 pool, ciascuno con 512 gruppi di posizionamento in 10 OSD, ha un totale di 5120 gruppi di posizionamento suddivisi in più di 10 OSD, ovvero 512 gruppi di posizionamento per OSD. In una configurazione di questo tipo non viene utilizzato un numero elevato di risorse. Tuttavia, se venissero creati 1000 pool con 512 gruppi di posizionamento ciascuno, gli OSD gestirebbero circa 50.000 gruppi di posizionamento ciascuno e sarebbero necessari molte più risorse e molto più tempo per il peering.

17.4.3 Impostazione del numero di gruppi di posizionamento

Nota
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

17.4.4 Individuazione del numero di gruppi di posizionamento

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

17.4.5 Individuazione delle statistiche dei gruppi di posizionamento di un cluster

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

17.4.6 Individuazione delle statistiche dei gruppi di posizionamento bloccati

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

17.4.7 Ricerca della mappa di un gruppo di posizionamento

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]

17.4.8 Recupero delle statistiche dei gruppi di posizionamento

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

root # ceph pg PG_ID query

17.4.9 Pulitura di un gruppo di posizionamento

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.

17.4.10 Assegnazione della priorità al backfill e al recupero dei gruppi di posizionamento

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.

17.4.11 Ripristino degli oggetti persi

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

17.4.12 Abilitazione dell'utilità di dimensionamento automatico del gruppo di posizionamento

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à:

off

Per disabilitare il dimensionamento automatico per il pool selezionato. L'amministratore dovrà scegliere un numero di gruppi di posizionamento adeguato per ogni pool.

on

Per abilitare le regolazioni automatiche del numero di gruppi di posizionamento per un determinato pool.

warn

Per inviare avvisi sull'integrità quando occorre regolare il numero di gruppi di posizionamento.

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

17.5 Modifica della mappa CRUSH

In questa sezione vengono presentati i modi con cui apportare modifiche di base alla mappa CRUSH, come la modifica di una mappa CRUSH, dei parametri della mappa CRUSH e l'aggiunta, lo spostamento o la rimozione di un OSD.

17.5.1 Modifica di una mappa CRUSH

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

  1. Ottenere una mappa CRUSH. Per ottenere la mappa CRUSH per il cluster, eseguire quanto riportato di seguito:

    cephuser@adm > ceph osd getcrushmap -o compiled-crushmap-filename

    L'output Ceph (-o) sarà una mappa CRUSH compilata nel nome file specificato. Poiché la mappa CRUSH è compilata, è necessario decompilarla prima di poterla modificare.

  2. Decompilare una mappa CRUSH. Per decompilare una mappa CRUSH, eseguire quanto riportato di seguito:

    cephuser@adm > crushtool -d compiled-crushmap-filename \
     -o decompiled-crushmap-filename

    Ceph decompilerà (-d) la mappa CRUSH compilata e la genererà (-o) nel nome file specificato.

  3. Modificare almeno uno dei parametri di dispositivi, compartimenti e regole.

  4. Compilare una mappa CRUSH. Per compilare una mappa CRUSH, eseguire quanto riportato di seguito:

    cephuser@adm > crushtool -c decompiled-crush-map-filename \
     -o compiled-crush-map-filename

    Ceph memorizzerà la mappa CRUSH compilata nel nome file specificato.

  5. Impostare una mappa CRUSH. Per impostare la mappa CRUSH per il cluster, eseguire quanto riportato di seguito:

    cephuser@adm > ceph osd setcrushmap -i compiled-crushmap-filename

    Ceph immetterà la mappa CRUSH compilata del nome file specificato come mappa CRUSH per il cluster.

Suggerimento
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
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

17.5.2 Aggiunta o spostamento di un OSD

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

Un numero intero. L'ID numerico dell'OSD. Questa opzione è obbligatoria.

nome

Stringa. Indica il nome completo dell'OSD. Questa opzione è obbligatoria.

weight

Valore doppio. Il peso CRUSH per l'OSD. Questa opzione è obbligatoria.

root

Una coppia di chiavi/valori. Per default, la gerarchia CRUSH contiene il default del pool come rispettiva radice. Questa opzione è obbligatoria.

bucket-type

Coppia di chiavi/valori. È possibile specificare l'ubicazione dell'OSD nella gerarchia CRUSH.

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

17.5.3 Differenza tra ceph osd reweight e ceph osd crush reweight

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

17.5.3.2 ceph osd crush reweight

Utilizzo:

cephuser@adm > ceph osd crush reweight OSD_NAME NEW_WEIGHT

ceph osd crush reweight imposta il peso CRUSH dell'OSD. Si tratta di un valore arbitrario, che in genere corrisponde alle dimensioni del disco in TB, e controlla la quantità di dati che il sistema tenta di allocare sull'OSD.

17.5.4 Rimozione di un OSD

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

17.5.5 Aggiunta di un compartimento

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

17.5.6 Spostamento di un compartimento

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

17.5.7 Rimozione di un compartimento

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

cephuser@adm > ceph osd crush remove BUCKET_NAME
Nota
Nota: soltanto compartimenti vuoti

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

17.6 Pulitura dei gruppi di posizionamento

Oltre alla creazione di più copie di oggetti, Ceph assicura l'integrità dei dati tramite la pulitura dei gruppi di posizionamento. Per ulteriori informazioni su questi gruppi, consultare questo riferimento: Sezione 1.3.2, «Gruppi di posizionamento». La pulitura Ceph è analoga all'esecuzione di fsck nel strato di memorizzazione degli oggetti. Per ciascun gruppo di posizionamento, Ceph genera un catalogo di tutti gli oggetti e confronta ciascun oggetto e le rispettive repliche per assicurare che non vi siano oggetti mancanti o non corrispondenti. Con la pulitura durante il giorno, vengono verificati le dimensioni e gli attributi degli oggetti, mentre con una pulitura settimanale più approfondita si effettua la lettura dei dati e mediante l'uso di checksum ne garantisce l'integrità.

La pulitura è importante per mantenere l'integrità dei dati, ma può ridurre le prestazioni. È possibile regolare le impostazioni seguenti per aumentare o diminuire le operazioni di pulitura:

osd max scrubs

Numero massimo di operazioni di pulitura simultanee per un Ceph OSD. Il valore di default è 1.

osd scrub begin hour, osd scrub end hour

Ore del giorno (da 0 a 24) che definiscono una finestra temporale durante cui può avvenire la pulitura. Per default, questa finestra inizia alle ore 0 e termina alle ore 24.

Importante
Importante

Se l'intervallo di pulitura del gruppo di posizionamento supera il valore dell'impostazione osd scrub max interval, la pulitura verrà eseguita indipendentemente dalla finestra temporale definita per la stessa.

osd scrub during recovery

Consente le operazioni di pulitura durante il recupero. Se si imposta su 'false' la pianificazione di nuove operazioni di pulitura verrà disabilitata durante un recupero attivo. Le operazioni di pulitura già in esecuzione continueranno normalmente. Questa opzione è utile per ridurre il carico di cluster trafficati. L'impostazione di default è "true".

osd scrub thread timeout

Numero massimo di secondi prima del timeout della pulitura. Il valore di default è 60.

osd scrub finalize thread timeout

Intervallo di tempo massimo espresso in secondi prima del time out del thread di completamento della pulitura. Il valore di default è 60*10.

osd scrub load threshold

Carico massimo normalizzato. Ceph non eseguirà la pulitura quando il carico del sistema (come definito dal rapporto getloadavg()/numero di online cpus) supera tale numero. Il valore di default è 0,5.

osd scrub min interval

Intervallo minimo espresso in secondi per la pulitura di Ceph OSD quando il carico del cluster Ceph è basso. Il valore di default è 60*60*24 (una volta al giorno).

osd scrub max interval

Intervallo massimo espresso in secondi per la pulitura del Ceph OSD, a prescindere dal carico del cluster. Il valore di default è 7*60*60*24 (una volta alla settimana).

osd scrub chunk min

Numero minimo di porzioni di archivio dati da pulire durante un'operazione singola. Ceph blocca le operazioni di scrittura su una porzione singola mentre è in corso la pulitura. Il valore di default è 5.

osd scrub chunk max

Numero massimo di porzioni di archivio dati da pulire durante un'operazione singola. Il valore di default è 25.

osd scrub sleep

Tempo di inattività prima della pulitura del gruppo successivo di porzioni. Se questo valore viene aumentato, l'operazione di pulitura risulta rallentata, mentre le operazioni del client sono meno influenzate. Il valore di default è 0.

osd deep scrub interval

Intervallo per la pulitura "approfondita" (lettura completa di tutti i dati). L'opzione osd scrub load threshold non influisce su questa impostazione. Il valore di default è 60*60*24*7 (una volta alla settimana).

osd scrub interval randomize ratio

Consente di aggiungere un ritardo casuale al valore osd scrub min interval quando si pianifica il lavoro di pulitura successivo per un gruppo di posizionamento. Il ritardo è un valore casuale più piccolo rispetto al risultato di osd scrub min interval * osd scrub interval randomized ratio. Pertanto, l'impostazione di default distribuisce le puliture praticamente in modo casuale nella finestra temporale consentita di [1, 1,5] * osd scrub min interval. Il valore di default è 0,5.

osd deep scrub stride

Consente di leggere le dimensioni quando si effettua una pulitura approfondita. Il valore di default è 524288 (512 kB).