Prima che sia possibile aggiungere un dispositivo di blocco a un client, è necessario creare un'immagine correlata in un pool esistente (vedere il Capitolo 11, Gestione di pool di memorizzazione):

cephadm@adm > rbd create --size MEGABYTES POOL-NAME/IMAGE-NAME

Ad esempio, per creare un'immagine da 1 GB denominata "myimage" le cui informazioni vengono memorizzate in un pool denominato "mypool", eseguire quanto riportato di seguito:

cephadm@adm > rbd create --size 1024 mypool/myimage

Suggerimento: unità di dimensioni immagine

Se si omette la scorciatoia dell'unità di dimensioni ("G" o "T"), le dimensioni dell'immagine vengono indicate in megabyte. Utilizzare "G" o "T" dopo le dimensioni per specificare gigabyte o terabyte.

A partire da SUSE Enterprise Storage 5, è possibile memorizzare i dati dell'immagine di un dispositivo di blocco direttamente in pool con codice di cancellazione (EC). L'immagine di un dispositivo di blocco RADOS è costituita da due parti, dati e metadati. È possibile memorizzare solo la parte "dati" dell'immagine di un dispositivo di blocco RADOS in un pool EC. Il flag "overwrite" del pool deve essere impostato su true, una condizioneciò è possibile soltanto se tutti gli OSD in cui è memorizzato il pool utilizzano BlueStore.

Non è possibile memorizzare la parte "metadati" dell'immagine in un pool EC. È necessario specificare il pool replicato per memorizzare i metadati dell'immagine con l'opzione --pool= del comando rbd create.

Seguire la procedura indicata di seguito per creare un'immagine RBD in un pool EC appena creato:

cephadm@adm > ceph osd pool create POOL_NAME 12 12 erasure
cephadm@adm > ceph osd pool set POOL_NAME allow_ec_overwrites true

#Metadata will reside in pool "OTHER_POOL", and data in pool "POOL_NAME"
cephadm@adm > rbd create IMAGE_NAME --size=1G --data-pool POOL_NAME --pool=OTHER_POOL

Per visualizzare un elenco dei dispositivi di blocco in un pool denominato "mypool", eseguire quanto riportato di seguito:

cephadm@adm > rbd ls mypool

Per recuperare le informazioni da un'immagine "myimage" in un pool denominato "mypool", eseguire quanto riportato di seguito:

cephadm@adm > rbd info mypool/myimage

Le immagini del RADOS Block Device (dispositivo di blocco RADOS) sono sottoposte a thin provisioning, non utilizzano effettivamente alcuno spazio di memorizzazione fisico fino a quando non si inizia a salvare i dati in esse. Dispongono tuttavia di una capacità massima che è possibile impostare con l'opzione --size. Se si desidera aumentare (o diminuire) le dimensioni massime di un'immagine, eseguire quanto riportato di seguito:

cephadm@adm > rbd resize --size 2048 POOL_NAME/IMAGE_NAME # to increase
cephadm@adm > rbd resize --size 2048 POOL_NAME/IMAGE_NAME --allow-shrink # to decrease

Per rimuovere un dispositivo di blocco che corrisponde a un'immagine "myimage" in un pool denominato "mypool", eseguire quanto riportato di seguito:

cephadm@adm > rbd rm mypool/myimage

rbdmap è uno script della shell che consente di automatizzare le operazioni rbd map e rbd unmap in una o più immagini RBD. Sebbene sia possibile eseguire manualmente lo script in qualsiasi momento, i principali vantaggi sono la mappatura automatica e il montaggio di immagini RBD all'avvio (e lo smontaggio e l'annullamento della mappatura all'arresto), attivati dal sistema Init. A tal fine è incluso un file di unità systemd, rbdmap.service con il pacchetto ceph-common.

Lo script impiega un singolo argomento, che può essere map o unmap. In entrambi i casi lo script analizza sintatticamente un file di configurazione. Il valore di default è /etc/ceph/rbdmap, ma è possibile ignorarlo tramite una variabile di ambiente RBDMAPFILE. Ciascuna riga del file di configurazione corrisponde a un'immagine RBD che deve anche essere mappata o non mappata.

Il file di configurazione presenta il seguente formato:

image_specification rbd_options

Quando viene eseguito come rbdmap map, lo script analizza sintatticamente il file di configurazione e, per ogni immagine RBD specificata, prima tenta di mappare l'immagine (con il comando the rbd map), quindi ne esegue il montaggio.

Quando eseguito come rbdmap unmap, le immagini elencate nel file di configurazione il montaggio e la mappatura verranno annullati.

rbdmap unmap-all tenta di smontare e successivamente di annullare la mappatura di tutte le immagini RBD attualmente mappate, indipendentemente dalla loro presenza nell'elenco del file di configurazione.

Se ha esito positivo, l'operazione rbd map mappa l'immagine a un dispositivo /dev/rbdX device, quindi viene attivata una regola udev per creare un collegamento simbolico del nome del dispositivo /dev/rbd/pool_name/image_name che punta al dispositivo realmente mappato.

Affinché il montaggio e lo smontaggio abbiano esito positivo, il nome del dispositivo "intuitivo" deve avere una voce corrispondente in /etc/fstab. Quando si scrivono voci /etc/fstab per le immagini RBD, specificare l'opzione di montaggio "noauto" (o "nofail"). In tal modo si impedisce al sistema Init di tentare di montare il dispositivo troppo presto, perfino prima dell'esistenza del dispositivo in questione, poiché di norma rbdmap.service viene attivato piuttosto tardi nella sequenza di avvio.

Per un elenco completo di opzioni rbd, vedere la documentazione relativa a rbd (man 8 rbd).

Per alcuni esempi di utilizzo di rbdmap, vedere la documentazione relativa a rbdmap (man 8 rbdmap).

Se le dimensioni del dispositivo RBD non sono più sufficienti, è possibile aumentarle.

Quando cephx è abilitato, è necessario specificare un nome o un ID utente e un percorso del portachiavi contenente la chiave corrispondente dell'utente. Per ulteriori informazioni, vedere il Capitolo 8, Autenticazione con cephx. È inoltre possibile aggiungere la variabile di ambiente CEPH_ARGS per evitare di immettere di nuovo i seguenti parametri.

cephadm@adm > rbd --id user-ID --keyring=/path/to/secret commands
cephadm@adm > rbd --name username --keyring=/path/to/secret commands

Ad esempio:

cephadm@adm > rbd --id admin --keyring=/etc/ceph/ceph.keyring commands
cephadm@adm > rbd --name client.admin --keyring=/etc/ceph/ceph.keyring commands

Suggerimento

Aggiungere l'utente e il segreto nella variabile di ambiente CEPH_ARGS in modo che non sia necessario immetterli ogni volta.

Nelle procedure seguenti è dimostrato come creare, elencare e rimuovere snapshot mediante l'uso del comando rbd sulla riga di comando.

cephadm@adm > rbd --pool pool-name snap create --snap snap-name image-name
cephadm@adm > rbd snap create pool-name/image-name@snap-name

cephadm@adm > rbd --pool rbd snap create --snap snapshot1 image1
cephadm@adm > rbd snap create rbd/image1@snapshot1

cephadm@adm > rbd --pool pool-name snap ls image-name
cephadm@adm > rbd snap ls pool-name/image-name

cephadm@adm > rbd --pool rbd snap ls image1
cephadm@adm > rbd snap ls rbd/image1

12.3.2.3 Rollback di snapshot #

Per eseguire il rollback a uno snapshot con rbd, specificare l'opzione snap rollback, il nome pool, il nome immagine e il nome snapshot.

cephadm@adm > rbd --pool pool-name snap rollback --snap snap-name image-name
cephadm@adm > rbd snap rollback pool-name/image-name@snap-name

Ad esempio:

cephadm@adm > rbd --pool pool1 snap rollback --snap snapshot1 image1
cephadm@adm > rbd snap rollback pool1/image1@snapshot1

Nota

Eseguire il rollback di un'immagine a uno snapshot significa sovrascrivere la versione attuale dell'immagine con i dati provenienti da uno snapshot. La durata di esecuzione di un rollback aumenta proporzionalmente alle dimensioni dell'immagine. È più rapido eseguire la clonazione da uno snapshot piuttosto che eseguire il rollback di un'immagine a uno snapshot; questo è inoltre il metodo preferito per tornare a uno stato preesistente.

12.3.2.4 Eliminazione di uno snapshot #

Per eliminare uno snapshot con rbd, specificare l'opzione snap rm, il nome pool, il nome immagine e il nome utente.

cephadm@adm > rbd --pool pool-name snap rm --snap snap-name image-name
cephadm@adm > rbd snap rm pool-name/image-name@snap-name

Ad esempio:

cephadm@adm > rbd --pool pool1 snap rm --snap snapshot1 image1
cephadm@adm > rbd snap rm pool1/image1@snapshot1

Nota

Nei Ceph OSD i dati vengono eliminati in modo asincrono, quindi con l'eliminazione di uno snapshot non si libera immediatamente spazio su disco.

cephadm@adm > rbd --pool pool-name snap purge image-name
cephadm@adm > rbd snap purge pool-name/image-name

cephadm@adm > rbd --pool pool1 snap purge image1
cephadm@adm > rbd snap purge pool1/image1

Ceph supporta la creazione di più cloni copia su scrittura (copy-on-write, COW) di una snapshot del dispositivo di blocco. Il layering degli snapshot consente ai client dei dispositivi di blocco Ceph di creare immagini molto rapidamente. Ad esempio, si può creare un'immagine del dispositivo di blocco con una Linux VM scritta al suo interno, quindi eseguire lo snapshot dell'immagine, proteggere lo snapshot e creare tutti i cloni copia su scrittura desiderati. Poiché gli snapshot sono di sola lettura, la clonazione di uno di essi semplifica la semantica e consente quindi di creare i cloni rapidamente.

Nota

I termini "parent" e "child" menzionati negli esempi di riga di comando riportati sotto significano uno snapshot del dispositivo di blocco Ceph (parent) e l'immagine corrispondente clonata dallo snapshot (child).

In ciascuna immagine clonata (child) è memorizzato il rifermento alla rispettiva immagine superiore, che consente all'immagine clonata di aprire e leggere lo snapshot superiore.

Un clone COW di uno snapshot si comporta esattamente come qualsiasi altra immagine del dispositivo di blocco Ceph. Nelle immagini clonate è possibile eseguire operazioni di lettura e scrittura ed è possibile clonarle e ridimensionarle. Con le immagini clonate non esistono restrizioni speciali. Il clone copia su scrittura di uno snapshot si riferisce tuttavia allo snapshot, quindi è necessario proteggere quest'ultimo prima di clonarlo.

Nota: --image-format 1 non supportata

Non è possibile creare snapshot di immagini create con l'opzione rbd create --image-format 1 obsoleta. Ceph supporta soltanto la clonazione delle immagini format 2 di default.

12.3.3.2 Protezione di uno snapshot #

I cloni accedono agli snapshot superiori. Tutti i cloni verrebbero interrotti se un utente eliminasse inavvertitamente lo snapshot superiore. Per impedire la perdita di dati, è necessario proteggere lo snapshot prima di poterlo clonare.

cephadm@adm > rbd --pool pool-name snap protect \
 --image image-name --snap snapshot-name
cephadm@adm > rbd snap protect pool-name/image-name@snapshot-name

Ad esempio:

cephadm@adm > rbd --pool pool1 snap protect --image image1 --snap snapshot1
cephadm@adm > rbd snap protect pool1/image1@snapshot1

Nota

Non è possibile eliminare uno snapshot protetto.

12.3.3.3 Clonazione di uno snapshot #

Per clonare uno snapshot, è necessario specificare il pool superiore, l'immagine e lo snapshot, il pool secondario e il nome immagine. È necessario proteggere lo snapshot prima di poterlo clonare.

cephadm@adm > rbd clone --pool pool-name --image parent-image \
 --snap snap-name --dest-pool pool-name \
 --dest child-image
cephadm@adm > rbd clone pool-name/parent-image@snap-name \
pool-name/child-image-name

Ad esempio:

cephadm@adm > rbd clone pool1/image1@snapshot1 pool1/image2

Nota

Si può clonare uno snapshot da un pool in un'immagine in un altro pool. Ad esempio, si possono mantenere immagini e snapshot di sola lettura come modelli in un pool e cloni scrivibili in un altro pool.

cephadm@adm > rbd --pool pool-name snap unprotect --image image-name \
 --snap snapshot-name
cephadm@adm > rbd snap unprotect pool-name/image-name@snapshot-name

cephadm@adm > rbd --pool pool1 snap unprotect --image image1 --snap snapshot1
cephadm@adm > rbd snap unprotect pool1/image1@snapshot1

cephadm@adm > rbd --pool pool-name children --image image-name --snap snap-name
cephadm@adm > rbd children pool-name/image-name@snapshot-name

cephadm@adm > rbd --pool pool1 children --image image1 --snap snapshot1
cephadm@adm > rbd children pool1/image1@snapshot1

12.3.3.6 Appiattimento di un'immagine clonata #

Le immagini clonate mantengono un riferimento allo snapshot superiore. Quando si rimuove il riferimento dal clone secondario nello parent superiore, di fatto si "appiattisce" l'immagine copiando le informazioni dallo snapshot al clone. La durata di appiattimento di un clone aumenta proporzionalmente alle dimensioni dello snapshot. Per eliminare uno snapshot, prima è necessario appiattire le immagini secondarie.

cephadm@adm > rbd --pool pool-name flatten --image image-name
cephadm@adm > rbd flatten pool-name/image-name

Ad esempio:

cephadm@adm > rbd --pool pool1 flatten --image image1
cephadm@adm > rbd flatten pool1/image1

Nota

Poiché un'immagine appiattita contiene tutte le informazioni provenienti dallo snapshot, questa occuperà uno spazio di memorizzazione maggiore rispetto a un clone su più strati.

I due daemon rbd-mirror sono responsabili dell'osservazione dei journal dell'immagine sul cluster peer remoto e della riproduzione degli eventi del journal a fronte del cluster locale. La funzione di journaling dell'immagine RBD consente di registrare tutte le modifiche dell'immagine nell'ordine in cui vengono apportate. In tal modo si garantisce la disponibilità a livello locale di una copia speculare con coerenza per arresto anomalo dell'immagine remota.

Il daemon rbd-mirror è disponibile nel pacchetto rbd-mirror . È possibile installare il pacchetto sui nodi OSD, sui nodi del gateway o persino sui nodi dedicati. Si sconsiglia di installare il pacchetto rbd-mirror sul nodo admin. Installare, abilitare e avviare rbd-mirror:

root@minion > zypper install rbd-mirror
root@minion > systemctl enable ceph-rbd-mirror@server_name.service
root@minion > systemctl start ceph-rbd-mirror@server_name.service

Importante

Per ciascun daemon rbd-mirror è necessario connettersi a entrambi i cluster simultaneamente.

Nelle procedure seguenti è illustrato come eseguire task amministrativi di base per configurare la copia speculare tramite il comando rbd. La copia speculare è configurata per ogni singolo pool nei cluster Ceph.

È necessario eseguire i passaggi della configurazione del pool su entrambi i cluster peer. Per maggior chiarezza, in queste procedure si presuppone che due cluster, denominati "local" e "remote", siano accessibili da un singolo host.

Vedere la documentazione relativa a rbd (man 8 rbd) per ulteriori dettagli su come connettersi a cluster Ceph diversi.

Suggerimento: cluster multipli

Il nome cluster negli esempi seguenti corrisponde a un file di configurazione Ceph omonimo /etc/ceph/remote.conf.

cephadm@adm > rbd --cluster local mirror pool enable POOL_NAME pool
cephadm@adm > rbd --cluster remote mirror pool enable POOL_NAME pool

cephadm@adm > rbd --cluster local mirror pool disable POOL_NAME
cephadm@adm > rbd --cluster remote mirror pool disable POOL_NAME

cephadm@adm > rbd --cluster local mirror pool peer add POOL_NAME client.remote@remote
cephadm@adm > rbd --cluster remote mirror pool peer add POOL_NAME client.local@local

cephadm@adm > rbd --cluster local mirror pool peer remove POOL_NAME \
 55672766-c02b-4729-8567-f13a66893445
cephadm@adm > rbd --cluster remote mirror pool peer remove POOL_NAME \
 60c0e299-b38f-4234-91f6-eed0a367be08

Diversamente dalla configurazione del pool, la configurazione dell'immagine deve essere eseguita solo a fronte di un singolo cluster Ceph peer in copia speculare.

Le immagini RBD sottoposte a copia speculare sono designate come primarie o non primarie. Questa è una proprietà dell'immagine e non del pool. Non è possibile modificare le immagini designate come non primarie.

Le immagini vengono promosse automaticamente a primarie quando la copia speculare viene prima abilitata su un'immagine (implicitamente, se la modalità di copia speculare del pool è "pool" e la funzione di journaling dell'immagine è abilitata, oppure esplicitamente (vedere Sezione 12.4.3.2, «Abilitazione della copia speculare dell'immagine») mediante il comando rbd).

12.4.3.1 Supporto del journaling dell'immagine #

Nella copia speculare RBD viene utilizzata la funzione di journaling RBD per assicurare che l'immagine replicata mantenga sempre con coerenza per arresto anomalo. Prima di poter eseguire la copia speculare di un'immagine a un cluster peer, è necessario abilitare la funzione di journaling. È possibile abilitare la funzione al momento della creazione dell'immagine fornendo l'opzione --image-feature exclusive-lock,journaling al comando rbd.

In alternativa, è possibile abilitare dinamicamente la funzione di journaling sulle immagini RBD preesistenti. Per abilitare il journaling, specificare il sottocomando feature enable, il nome del pool e dell'immagine e il nome della funzione:

cephadm@adm > rbd --cluster local feature enable POOL_NAME/IMAGE_NAME journaling

Nota: dipendenza dell'opzione

La funzione journaling dipende dalla funzione exclusive-lock. Se la funzione exclusive-lock non è già stata abilitata, è necessario farlo prima di abilitare la funzione journaling.

Avviso: journaling su tutte le immagini nuove

È possibile abilitare per default il journaling su tutte le nuove immagini aggiungendo il valore journaling all'opzione rbd default features nel file di configurazione Ceph. Ad esempio:

rbd default features = layering,exclusive-lock,object-map,deep-flatten,journaling

Prima di applicare tale modifica, ponderare con attenzione se si tratta della scelta più indicata per la propria distribuzione, poiché l'abilitazione del journaling su tutte le nuove immagini potrebbe avere un impatto negativo sulle prestazioni.

cephadm@adm > rbd --cluster local mirror image enable POOL_NAME/IMAGE_NAME

cephadm@adm > rbd --cluster local mirror image disable POOL_NAME/IMAGE_NAME

12.4.3.4 Promozione e abbassamento di livello dell'immagine #

In uno scenario di failover in cui è necessario spostare la designazione primaria all'immagine nel cluster peer, è necessario interrompere l'accesso all'immagine primaria, abbassare di livello l'attuale immagine primaria, promuovere quella nuova e riprendere l'accesso all'immagine sul cluster alternativo.

Nota: promozione forzata

È possibile forzare la promozione utilizzando l'opzione --force. La promozione forzata è necessaria quando è impossibile propagare l'abbassamento di livello al cluster peer (ad esempio, in caso di errore del cluster o di interruzione della comunicazione). Ne risulterà uno scenario split brain tra i due peer e l'immagine non viene più sincronizzata fino all'emissione di un sottocomando resync.

Per abbassare di livello un'immagine specifica a non primaria, specificare il sottocomando mirror image demote insieme al nome del pool e dell'immagine:

cephadm@adm > rbd --cluster local mirror image demote POOL_NAME/IMAGE_NAME

Per abbassare di livello tutte le immagini primarie in un pool a non primarie, specificare il sottocomando mirror pool demote insieme al nome del pool:

cephadm@adm > rbd --cluster local mirror pool demote POOL_NAME

Per promuovere un'immagine specifica a primaria, specificare il sottocomando mirror image promote insieme al nome del pool e dell'immagine:

cephadm@adm > rbd --cluster remote mirror image promote POOL_NAME/IMAGE_NAME

Per promuovere tutte le immagini primarie in un pool a primarie, specificare il sottocomando mirror pool promote insieme al nome del pool:

cephadm@adm > rbd --cluster local mirror pool promote POOL_NAME

Suggerimento: suddivisione del carico I/O

Poiché lo stato di primaria o non primaria si riferisce a un'immagine singola, è possibile fare in modo che il carico I/O e il failover o il failback della fase vengano suddivisi tra due cluster.

cephadm@adm > rbd mirror image resync POOL_NAME/IMAGE_NAME

Lo stato di replica del cluster peer viene memorizzato per ciascuna immagine primaria in copia speculare. È possibile recuperare tale stato mediante i sottocomandi mirror image status e mirror pool status:

Per richiedere lo stato dell'immagine speculare, specificare il sottocomando mirror image status insieme al nome del pool e dell'immagine:

cephadm@adm > rbd mirror image status POOL_NAME/IMAGE_NAME

Per richiedere lo stato di riepilogo del pool speculare, specificare il sottocomando mirror pool status insieme al nome del pool:

cephadm@adm > rbd mirror pool status POOL_NAME

Suggerimento:

Con l'aggiunta dell'opzione --verbose al sottocomando mirror pool status verranno generati ulteriori dettagli sullo stato di ciascuna immagine in copia speculare nel pool.