Prima di poter aggiungere un dispositivo di blocco a un nodo, è necessario creare un'immagine correlata nel cluster. Per creare un'immagine del dispostivi di blocco, eseguire quanto riportato di seguito:

root # rbd create --size megabytes pool-name/image-name

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

root # rbd create --size 1024 swimmingpool/bar

Suggerimento: pool di default

Se non si specifica un pool quando si crea un'immagine, questa verrà memorizzata nel pool "rbd" di default.

Nota: creare prima un pool

È necessario creare un pool prima di poterlo specificare come origine. Per ulteriori dettagli, vedere Capitolo 7, Gestione di pool di memorizzazione.

A partire da SUSE Enterprise Storage 5, è possibile memorizzare i dati dell'immagine di un dispositivo di blocco in pool con codice di cancellazione. In un pool con codice di cancellazione è possibile memorizzare solo la parte riguardate i dati di un'immagine RBD. Inoltre, è necessario che il flag "overwrite" di sovrascrittura del pool con codice di cancellazione deve essere impostato su true e ciò è possibile farlo solo se tutti gli OSD utilizzano BlueStore.

I metadati dell'immagine non possono risiedere in un pool con codice di cancellazione. I metadati possono risiedere nel pool "rbd" o nel pool specificato esplicitamente dall'utente con il parametro --pool= nel comando rbd create.

Nota: BlueStore obbligatorio

Per utilizzare i pool con codice di cancellazione per le immagini dei dispositivi di blocco è necessario BlueStore in tutti i nodi.

Seguire i passaggi riportati di seguito per creare un'immagine RBD in un pool con codice di cancellazione:

root # ceph osd pool create POOL_NAME 12 12 erasure
root # ceph osd pool set POOL_NAME allow_ec_overwrites true

# Metadata will reside in pool "rbd", and data in pool "POOL_NAME"
root # rbd create IMAGE_NAME --size=1G --data-pool POOL_NAME

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

Per elencare i dispositivi di blocco nel pool "rbd", eseguire quanto riportato di seguito ("rbd" è il nome pool di default):

root # rbd ls

Per elencare i dispositivi di blocco in un pool denominato "swimmingpool", eseguire quanto riportato di seguito:

root # rbd ls swimmingpool

Per recuperare informazioni da un'immagine "bar" in un pool denominato "swimmingpool", eseguire quanto riportato di seguito:

root # rbd info swimmingpool/bar

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:

root # rbd resize --size 2048 foo # to increase
rbd resize --size 2048 foo --allow-shrink # to decrease

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

root # rbd rm swimmingpool/bar

Quando cephx è abilitato (vedere http://ceph.com/docs/master/rados/configuration/auth-config-ref/ per ulteriori informazioni), è necessario specificare un nome o ID utente e un percorso del portachiavi contenente la chiave corrispondente dell'utente. Per ulteriori dettagli, vedere User Management (in lingua inglese). È inoltre possibile aggiungere la variabile di ambiente CEPH_ARGS per evitare di immettere di nuovo i seguenti parametri.

root # rbd --id user-ID --keyring=/path/to/secret commands
root # rbd --name username --keyring=/path/to/secret commands

Ad esempio:

root # rbd --id admin --keyring=/etc/ceph/ceph.keyring commands
root # 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.

root # rbd --pool pool-name snap create --snap snap-name image-name
root # rbd snap create pool-name/image-name@snap-name

root # rbd --pool rbd snap create --snap snapshot1 image1
root # rbd snap create rbd/image1@snapshot1

root # rbd --pool pool-name snap ls image-name
root # rbd snap ls pool-name/image-name

root # rbd --pool rbd snap ls image1
root # rbd snap ls rbd/image1

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

root # rbd --pool pool-name snap rollback --snap snap-name image-name
root # rbd snap rollback pool-name/image-name@snap-name

Ad esempio:

root # rbd --pool pool1 snap rollback --snap snapshot1 image1
root # 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.

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

root # rbd --pool pool-name snap rm --snap snap-name image-name
root # rbd snap rm pool-name/image-name@snap-name

Ad esempio:

root # rbd --pool pool1 snap rm --snap snapshot1 image1
root # 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.

root # rbd --pool pool-name snap purge image-name
root # rbd snap purge pool-name/image-name

root # rbd --pool pool1 snap purge image1
root # rbd snap purge pool1/image1

Ceph supporta la creazione di molti cloni copia su scrittura (copy-on-write, COW) di uno 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

Ceph supporta la clonazione solo per le immagini format 2 (creata con rbd create --image-format 2).

8.3.3.2 Protezione di uno snapshot #

I cloni accedono agli shapshot 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.

root # rbd --pool pool-name snap protect \
 --image image-name --snap snapshot-name
root # rbd snap protect pool-name/image-name@snapshot-name

Ad esempio:

root # rbd --pool pool1 snap protect --image image1 --snap snapshot1
root # rbd snap protect pool1/image1@snapshot1

Nota

Non è possibile eliminare uno snapshot protetto.

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

root # rbd --pool pool-name --image parent-image \
 --snap snap-name --dest-pool pool-name \
 --dest child-image
root # rbd clone pool-name/parent-image@snap-name \
pool-name/child-image-name

Ad esempio:

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

root # rbd --pool pool-name snap unprotect --image image-name \
 --snap snapshot-name
root # rbd snap unprotect pool-name/image-name@snapshot-name

root # rbd --pool pool1 snap unprotect --image image1 --snap snapshot1
root # rbd snap unprotect pool1/image1@snapshot1

root # rbd --pool pool-name children --image image-name --snap snap-name
root # rbd children pool-name/image-name@snapshot-name

root # rbd --pool pool1 children --image image1 --snap snapshot1
root # rbd children pool1/image1@snapshot1

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

root # rbd --pool pool-name flatten --image image-name
root # rbd flatten pool-name/image-name

Ad esempio:

root # rbd --pool pool1 flatten --image image1
root # 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. Installarlo, abilitarlo e avviarlo su uno dei nodi del cluster:

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. Per la configurazione di più cluster, vedere la documentazione relativa a ceph-conf (in lingua inglese).

root # rbd --cluster local mirror pool enable image-pool pool
root # rbd --cluster remote mirror pool enable image-pool pool

root # rbd --cluster local mirror pool disable image-pool
root # rbd --cluster remote mirror pool disable image-pool

root # rbd --cluster local mirror pool peer add image-pool client.remote@remote
root # rbd --cluster remote mirror pool peer add image-pool client.local@local

root # rbd --cluster local mirror pool peer remove image-pool \
 55672766-c02b-4729-8567-f13a66893445
root # rbd --cluster remote mirror pool peer remove image-pool \
 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 8.5.3.2, «Abilitazione della copia speculare dell'immagine») mediante il comando rbd).

8.5.3.1 Abilitazione del supporto per il 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:

root # rbd --cluster local feature enable image-pool/image-1 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.

Suggerimento: journaling su tutte le immagini nuove

È possibile abilitare per default il journaling su tutte le immagini nuove aggiungendo la seguente riga al file di configurazione Ceph:

rbd default features = 125

root # rbd --cluster local mirror image enable image-pool/image-1

root # rbd --cluster local mirror image disable image-pool/image-1

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

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

root # rbd --cluster local mirror image demote image-pool/image-1

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:

root # rbd --cluster local mirror pool demote image-pool

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

root # rbd --cluster remote mirror image promote image-pool/image-1

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

root # rbd --cluster local mirror pool promote image-pool

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 IO e il failover o il failback della fase venga suddiviso tra due cluster.

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.

root # rbd mirror image resync image-pool/image-1

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:

root # rbd mirror image status image-pool/image-1

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

root # rbd mirror pool status image-pool

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.