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.

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

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
}

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

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

}

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.

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: pool di cancellazione

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

Figura 6.2: Metodi di sostituzione dei nodi #

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.

root # ceph osd crush set id_or_name weight root=pool-name
bucket-type=bucket-name ...

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

root # ceph osd crush reweight name weight

root # ceph osd crush remove name

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

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:

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