Saltar al contenutoSaltar alla navigazione delle pagine: pagina precedente [chiave d’accesso p]/pagina successiva [chiave d’accesso n]
Si applica a SUSE Enterprise Storage 5

6 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 algoritimi, 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 al sistema 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 può consentire inoltre di identificare le ubicazioni fisiche in cui vengono memorizzate da Ceph le copie ridondanti dei dati quando i gruppi di posizionamento associati a un host non riuscito sono danneggiati.

In una mappa CRUSH sono presenti tre sezioni principali.

  • Dispositivi: qualsiasi dispositivo di memorizzazione degli oggetti, vale a dire il disco rigido che corrisponde 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.

6.1 Dispositivi

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

Ad esempio:

#devices
device 0 osd.0
device 1 osd.1
device 2 osd.2
device 3 osd.3

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

6.2 Compartimenti

Le mappe CRUSH contengono un elenco di OSD, che è possibile organizzare in "compartimenti" in modo da aggregare i dispositivi in ubicazioni fisiche.

0

OSD

Un daemon OSD (osd.1, osd.2 e così via).

1

Host

Un nome host contenente uno o più OSD.

2

Telaio

Telaio di cui è composto il rack.

3

Rack

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

4

Fila

Una fila in una serie di rack.

5

Pdu

Unità di distribuzione dell'alimentazione

6

Pod

7

Stanza

Una stanza contenente i rack e le file di host.

8

Data center

Data center fisico contenente le stanze.

9

Regione

10

Radice

Suggerimento
Suggerimento

È possibile rimuovere questi tipi e creare tipi di compartimenti propri.

Gli strumenti di distribuzione Ceph generano una mappa CRUSH che contiene un compartimento per ciascun ho e un pool denominato "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.

Un compartimento è dotato di un tipo, un nome univoco (stringa), un ID univoco espresso come numero intero negativo, un peso relativo alla capacità/funzionalità totale degli elementi, algoritmo del compartimento (straw per default) e 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 | 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 straw
        hash 0
        item osd.0 weight 1.00
        item osd.1 weight 1.00
}

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

rack rack-3 {
        id -15
        alg straw
        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 straw
        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 straw
        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 straw
        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 straw
        hash 0
        item server-room-1 weight 30.00
        item server-room-2 weight 30.00
}

pool data {
        id -10
        alg straw
        hash 0
        item dc-1 weight 60.00
        item dc-2 weight 60.00
}

6.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. La mappa CRUSH di default ha una regola per ogni pool e un set di regole assegnato a ciascuno dei pool di default.

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.

Importante
Importante

È necessario aumentare continuamente il numero del set di regole rispetto al valore di default 0, altrimenti il monitoraggio correlato potrebbe bloccarsi.

type

Stringa. Descrive una regola per un disco rigido (replicato) o un RAID. Questa opzione è obbligatoria. L'impostazione di default è replicated.

min_size

Un numero intero. Se un gruppo di posizionamento effettua meno repliche rispetto al numero specificato, questa regola NON verrà selezionata da CRUSH. Questa opzione è obbligatoria. Il valore di default è 2.

max_size

Un numero intero. Se un gruppo di posizionamento effettua più repliche rispetto al numero specificato, questa regola NON verrà selezionata da CRUSH. Questa opzione è obbligatoria. Il valore di default è 10.

step take bucket

Assume un nome di compartimento e inizia a eseguire l'iterazione lungo l'albero. Questa opzione è obbligatoria. Per una spiegazione sull'iterazione nell'albero, vedere Sezione 6.3.1, «Iterazione nell'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 6.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.

Importante
Importante

Per attivare una o più regole con un numero di set di regole comune in un pool, impostare il numero del set di regole nel pool.

6.3.1 Iterazione nell'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 6.1, «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 6.1: 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
}

6.3.2 firstn e indep

Una regola CRUSH definisce le sostituzioni per i nodi o gli OSD non riusciti (vedere Sezione 6.3, «Set di regole»). Per lo step della parola chiave è richiesto firstn o indep come parametro. Nella figura Figura 6.2, «Metodi di sostituzione dei nodi» è riportato 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.

Nota
Nota: pool di cancellazione

Assicurarsi che sia impostata una regola che utilizzi indep per ciascun pool con codice di cancellazione.

Metodi di sostituzione dei nodi
Figura 6.2: Metodi di sostituzione dei nodi

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

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

    root # 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:

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

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

    root # ceph osd setcrushmap -i compiled-crushmap-filename

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

6.4.2 Aggiunta/Spostamento di un OSD

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

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

name

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

weight

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

pool

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 degli OSD nella gerarchia CRUSH.

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

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

6.4.3 Regolazione del peso CRUSH di un OSD

Per regolare il peso CRUSH di un OSD nella mappa CRUSH di un cluster in esecuzione, eseguire quanto riportato di seguito:

root # ceph osd crush reweight name weight
name

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

weight

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

6.4.4 Rimozione di un OSD

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

root # ceph osd crush remove name
name

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

6.4.5 Spostamento di un compartimento

Per spostare un compartimento in un'ubicazione o posizione diversa nella gerarchia di mappe CRUSH, eseguire quanto riportato di seguito:

root # ceph osd crush move bucket-name bucket-type=bucket-name, ...
bucket-name

Stringa. Il nome del compartimento da spostare/riposizionare. Questa opzione è obbligatoria.

bucket-type

Coppia di chiavi/valori. È possibile specificare l'ubicazione del compartimento nella gerarchia CRUSH.

6.5 Pulitura

Oltre a creare più copie di oggetti, Ceph assicura l'integrità dei dati mediante la pulitura di 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 Ceph OSD. Il valore di default è 1.

osd scrub begin hour, osd scrub end hour

Le ore del giorno (da 0 a 24) che definiscono la finestra temporale in cui può essere eseguita la pulitura. Per default inizia alle ore 0 e termina alle 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

Numero massimo di secondi prima del timeout 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 di Ceph OSD indipendentemente dal carico del cluster. 7*60*60*24 (una volta alla settimana).

osd scrub chunk min

Numero minimo di porzioni dell'archivio dati da ripulire durante una singola operazione. I blocchi Ceph eseguono la scrittura in un singola porzione durante la pulitura. Il valore di default è 5.

osd scrub chunk max

Numero massimo di porzioni dell'archivio dati da ripulire durante una singola operazione. Il valore di default è 25.

osd scrub sleep

Tempo di inattività prima della pulitura del gruppo di porzioni successivo. Se si aumenta questo valore si rallenta l'intera operazione di pulitura con un impatto minore sulle operazioni del client. 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).

6.6 Combinazione di SSD e HDD sullo stesso nodo

Si potrebbe desiderare di configurare un cluster Ceph in modo tale che su ciascun nodo sia presente una combinazione di SSD e HDD, con un pool di memorizzazione sugli SSD veloci e uno sugli HDD più lenti. A tal fine, è necessario modificare la mappa CRUSH.

La mappa CRUSH di default presenterà una gerarchia semplice, in cui la radice di default contiene gli host e questi a loro volta contengono gli OSD, ad esempio:

root # 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

In tal modo non vi è alcuna distinzione tra i tipi di dischi. Per suddividere gli OSD in SSD e HDD, è necessario creare una seconda gerarchia nella mappa CRUSH:

root # ceph osd crush add-bucket ssd root

Avendo creato la nuova radice per gli SSD, è necessario aggiungervi gli host. Vale a dire che occorre creare nuove voci di host. Ma poiché non è possibile che lo stesso nome host compaia più di una volta in una mappa CRUSH, questa utilizza nomi host falsi. Tali nomi falsi non devono essere risolvibili da DNS. Per CRUSH i nomi host non hanno importanza, servono solo per creare le gerarchie corrette. La modifica che deve essere apportata per supportare i nomi host falsi consiste nell'impostare

osd crush update on start = false

nel file /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf e quindi eseguire la fase 3 di DeepSea per distribuire la modifica (per ulteriori informazioni fare riferimento a Sezione 1.11, «File ceph.conf personalizzato»):

root@master # salt-run state.orch ceph.stage.3

Altrimenti, gli OSD spostati verranno reimpostati successivamente alla rispettiva ubicazione originale nella radice di default e il cluster non si comporta come previsto.

Una volta modificata tale impostazione, aggiungere i nuovi host falsi nella radice SSD:

root # ceph osd crush add-bucket node1-ssd host
root # ceph osd crush move node1-ssd root=ssd
root # ceph osd crush add-bucket node2-ssd host
root # ceph osd crush move node2-ssd root=ssd
root # ceph osd crush add-bucket node3-ssd host
root # ceph osd crush move node3-ssd root=ssd

Infine, per ciascun OSD SSD, spostare l'OSD nella radice SSD. Nell'esempio, si presuppone che osd.0, osd.1 e osd.2 siano ospitati fisicamente negli SSD:

root # ceph osd crush add osd.0 1 root=ssd
root # ceph osd crush set osd.0 1 root=ssd host=node1-ssd
root # ceph osd crush add osd.1 1 root=ssd
root # ceph osd crush set osd.1 1 root=ssd host=node2-ssd
root # ceph osd crush add osd.2 1 root=ssd
root # ceph osd crush set osd.2 1 root=ssd host=node3-ssd

La gerarchia CRUSH adesso deve avere il seguente aspetto:

root # ceph osd tree
ID WEIGHT  TYPE NAME                   UP/DOWN REWEIGHT PRIMARY-AFFINITY
-5 3.00000 root ssd
-6 1.00000     host node1-ssd
 0 1.00000         osd.0                    up  1.00000          1.00000
-7 1.00000     host node2-ssd
 1 1.00000         osd.1                    up  1.00000          1.00000
-8 1.00000     host node3-ssd
 2 1.00000         osd.2                    up  1.00000          1.00000
-1 0.11096 root default
-2 0.03699     host node1
 3 0.01849         osd.3                    up  1.00000          1.00000
 6 0.01849         osd.6                    up  1.00000          1.00000
-3 0.03699     host node2
 4 0.01849         osd.4                    up  1.00000          1.00000
 7 0.01849         osd.7                    up  1.00000          1.00000
-4 0.03699     host node3
 5 0.01849         osd.5                    up  1.00000          1.00000
 8 0.01849         osd.8                    up  1.00000          1.00000

Ora, creare una regola CRUSH che ha come destinazione la radice SSD:

root # ceph osd crush rule create-simple ssd_replicated_ruleset ssd host

L'impostazione di default originale replicated_ruleset (con ID 0) avrà come destinazione gli HDD. La nuova impostazione ssd_replicated_ruleset (con ID 1) avrà come destinazione gli SSD.

Tutti i pool esistenti continueranno a utilizzare gli HDD perché rientrano nella gerarchia di default nella mappa CRUSH. È possibile creare un nuovo pool per utilizzare solo gli SSD:

root # ceph osd pool create ssd-pool 64 64
root # ceph osd pool set ssd-pool crush_rule ssd_replicated_ruleset
Stampa pagina