cephx
Un blocco è una sequenza di byte, ad esempio un blocco di dati da 4 MB. Le interfacce di memorizzazione basate su blocchi rappresentano il modo più comune per memorizzare i dati con supporti rotanti, come dischi rigidi, CD, dischi floppy. L'ubiquità delle interfacce dei dispositivi di blocco rende un dispositivo di blocco virtuale un candidato ideale per interagire con un sistema di memorizzazione di massa come Ceph.
I dispositivi di blocco Ceph consentono la condivisione di risorse fisiche e sono ridimensionabili. Questi dispositivi memorizzano i dati suddivisi in più OSD in un cluster Ceph. I dispositivi di blocco Ceph sfruttano le funzionalità RADOS come la creazione di snapshot, replica e coerenza. I RADOS Block Device (RBD, dispositivi di blocco RADOS) di Ceph interagiscono con gli OSD utilizzando i moduli del kernel o la libreria librbd
.
I dispositivi di blocco Ceph offrono prestazioni elevate con scalabilità infinita ai moduli del kernel. Supportano soluzioni di virtualizzazione come QEMU o sistemi di calcolo basati su cloud come OpenStack che fanno affidamento su libvirt
. È possibile utilizzare lo stesso cluster per attivare Object Gateway, CephFS e RADOS Block Device (dispositivi di blocco RADOS) simultaneamente.
Il comando rbd
consente di creare, elencare, analizzare e rimuovere immagini dei dispositivi di blocco. È inoltre possibile utilizzarlo per clonare immagini, creare snapshot, eseguire il rollback di un'immagine in uno snapshot o visualizzare uno snapshot.
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
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 erasurecephadm@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 increasecephadm@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
Dopo aver creato un dispositivo di blocco RADOS, è possibile utilizzarlo come qualsiasi altro dispositivo disco: formattarlo, montarlo in modo che sia in grado di scambiare file e smontarlo al termine dell'operazione.
Accertarsi che nel cluster Ceph sia incluso un pool con l'immagine disco che si desidera mappare. Presupporre che il pool sia denominato mypool
e l'immagine myimage
.
cephadm@adm >
rbd list mypool
Mappare l'immagine nel nuovo dispositivo di blocco.
cephadm@adm >
rbd map --pool mypool myimage
Per specificare un nome utente, utilizzare --id user-name
. Se si utilizza l'autenticazione cephx
, è necessario specificare anche un segreto. Quest'ultimo potrebbe essere ricavato da un portachiavi o da un file contenente il segreto:
cephadm@adm >
rbd map --pool rbd myimage --id admin --keyring /path/to/keyring
oppure
cephadm@adm >
rbd map --pool rbd myimage --id admin --keyfile /path/to/file
Elencare tutti i dispositivi mappati:
cephadm@adm >
rbd showmapped
id pool image snap device
0 mypool myimage - /dev/rbd0
Il dispositivo che si desidera utilizzare è /dev/rbd0
.
Al posto di /dev/rbdDEVICE_NUMBER
, è possibile utilizzare /dev/rbd/POOL_NAME/IMAGE_NAME
come percorso di dispositivo permanente. Ad esempio:
/dev/rbd/mypool/myimage
Creare un file system XFS sul dispositivo /dev/rbd0
.
root #
mkfs.xfs /dev/rbd0
log stripe unit (4194304 bytes) is too large (maximum is 256KiB)
log stripe unit adjusted to 32KiB
meta-data=/dev/rbd0 isize=256 agcount=9, agsize=261120 blks
= sectsz=512 attr=2, projid32bit=1
= crc=0 finobt=0
data = bsize=4096 blocks=2097152, imaxpct=25
= sunit=1024 swidth=1024 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal log bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=8 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
Montare il dispositivo e verificare che sia montato correttamente. Sostituire /mnt
con il proprio punto di montaggio.
root #
mount /dev/rbd0 /mntroot #
mount | grep rbd0 /dev/rbd0 on /mnt type xfs (rw,relatime,attr2,inode64,sunit=8192,...
Adesso è possibile spostare i dati nel e dal dispositivo come se questo fosse una directory locale.
Se le dimensioni del dispositivo RBD non sono più sufficienti, è possibile aumentarle.
Aumentare le dimensioni dell'immagine RBD, ad esempio fino a 10 GB.
cephadm@adm >
rbd resize --size 10000 mypool/myimage
Resizing image: 100% complete...done.
Accrescere il file system in modo da riempire le nuove dimensioni del dispositivo.
root #
xfs_growfs /mnt
[...]
data blocks changed from 2097152 to 2560000
Una volta terminato l'accesso al dispositivo, è possibile annullare la mappatura e smontarlo.
cephadm@adm >
rbd unmap /dev/rbd0root #
unmount /mnt
Poiché mappare e montare manualmente le immagini RBD dopo l'avvio e annullare tali operazioni prima dello spegnimento può essere tedioso, vengono forniti uno script rbdmap
e un'unità systemd
. Vedere Sezione 12.2.1, «rbdmap: mappatura dei dispositivi RBD all'avvio».
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
image_specification
Percorso di un'immagine in un pool. Specificare come pool_name/image_name.
rbd_options
Elenco di parametri opzionale da passare al comando sottostante rbd map
. Questi parametri e i rispettivi valori devono essere specificati come stringa separata da virgola, ad esempio:
PARAM1=VAL1,PARAM2=VAL2,...
Nell'esempio con lo script rbdmap
viene eseguito il seguente comando:
cephadm@adm >
rbd map POOL_NAME/IMAGE_NAME --PARAM1 VAL1 --PARAM2 VAL2
Nell'esempio seguente è possibile vedere come specificare un nome utente e un portachiavi con un segreto corrispondente:
cephadm@adm >
rbdmap map mypool/myimage id=rbd_user,keyring=/etc/ceph/ceph.client.rbd.keyring
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.
Aumentare le dimensioni dell'immagine RBD, ad esempio fino a 10 GB.
cephadm@adm >
rbd resize --size 10000 mypool/myimage
Resizing image: 100% complete...done.
Accrescere il file system in modo da riempire le nuove dimensioni del dispositivo.
root #
xfs_growfs /mnt
[...]
data blocks changed from 2097152 to 2560000
Uno snapshot RBD è uno snapshot di un'immagine del RADOS Block Device (dispositivo di blocco RADOS). Gli snapshot consentono di conservare la cronologia dello stato dell'immagine. Ceph supporta anche il layering di snapshot, che consente di clonare rapidamente e facilmente immagini VM. Ceph supporta gli snapshot dei dispositivi di blocco mediante l'uso del comando rbd
e molte interfacce di livello superiore, tra cui QEMU, libvirt
, OpenStack e CloudStack.
Interrompere le operazioni di input e output e svuotare tutte le operazioni di scrittura in sospeso prima di creare una snapshot di un'immagine. Se l'immagine contiene un file system, questo deve presentare uno stato coerente al momento della creazione della snapshot.
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 commandscephadm@adm >
rbd --name username --keyring=/path/to/secret commands
Ad esempio:
cephadm@adm >
rbd --id admin --keyring=/etc/ceph/ceph.keyring commandscephadm@adm >
rbd --name client.admin --keyring=/etc/ceph/ceph.keyring commands
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.
Per creare uno snapshot con rbd
, specificare l'opzione snap create
, il nome pool e il nome immagine.
cephadm@adm >
rbd --pool pool-name snap create --snap snap-name image-namecephadm@adm >
rbd snap create pool-name/image-name@snap-name
Ad esempio:
cephadm@adm >
rbd --pool rbd snap create --snap snapshot1 image1cephadm@adm >
rbd snap create rbd/image1@snapshot1
Per elencare gli snapshot di un'immagine, specificare il nome pool e il nome immagine.
cephadm@adm >
rbd --pool pool-name snap ls image-namecephadm@adm >
rbd snap ls pool-name/image-name
Ad esempio:
cephadm@adm >
rbd --pool rbd snap ls image1cephadm@adm >
rbd snap ls rbd/image1
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-namecephadm@adm >
rbd snap rollback pool-name/image-name@snap-name
Ad esempio:
cephadm@adm >
rbd --pool pool1 snap rollback --snap snapshot1 image1cephadm@adm >
rbd snap rollback pool1/image1@snapshot1
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.
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-namecephadm@adm >
rbd snap rm pool-name/image-name@snap-name
Ad esempio:
cephadm@adm >
rbd --pool pool1 snap rm --snap snapshot1 image1cephadm@adm >
rbd snap rm pool1/image1@snapshot1
Nei Ceph OSD i dati vengono eliminati in modo asincrono, quindi con l'eliminazione di uno snapshot non si libera immediatamente spazio su disco.
Per eliminare tutti gli snapshot di un'immagine con rbd
, specificare l'opzione snap purge
e il nome immagine.
cephadm@adm >
rbd --pool pool-name snap purge image-namecephadm@adm >
rbd snap purge pool-name/image-name
Ad esempio:
cephadm@adm >
rbd --pool pool1 snap purge image1cephadm@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.
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.
--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.
Il layering dei dispositivi di blocco Ceph è un processo semplice. È necessario disporre di un'immagine, creare uno snapshot dell'immagine, proteggere lo snapshot. Dopo aver eseguito questi passaggi, è possibile iniziare la clonazione dello snapshot.
L'immagine clonata fa riferimento allo snapshot superiore e include l'ID pool, l'ID immagine e l'ID snapshot. L'inclusione dell'ID pool significa che è possibile clonare snapshot da un pool nelle immagini in un altro pool.
Modello di immagine: un caso comune di layering dei dispositivi di blocco consiste nel creare un'immagine master e uno snapshot che funge da modello per i cloni. Ad esempio, un utente può creare un'immagine per una distribuzione Linux (ad esempio, SUSE Linux Enterprise Server) e creare uno snapshot corrispondente. Periodicamente, l'utente può aggiornare l'immagine e creare un nuovo snapshot (ad esempio, zypper ref && zypper patch
seguito da rbd snap create
). Ma mano che l'immagine matura, l'utente può clonare qualsiasi snapshot.
Modello esteso: un caso più avanzato consiste nell'estensione di un'immagine modello che fornisce ulteriori informazioni rispetto all'immagine di base. Ad esempio, un utente può clonare un'immagine (un modello VM) e installare un software diverso (ad esempio un database, un sistema di gestione di contenuti o un sistema di analisi) ed eseguire quindi lo snapshot dell'immagine estesa, che a sua volta è possibile aggiornare allo stesso modo dell'immagine di base.
Pool di modelli: un metodo per utilizzare il layering dei dispositivi di blocco consiste nel creare un pool contenente immagini master che fungono da modelli e snapshot di tali modelli. È quindi possibile estendere i privilegi di sola lettura agli utenti in modo che possano clonare gli snapshot senza doverli scrivere o eseguire nel pool.
Migrazione/recupero dell'immagine: un metodo per utilizzare il layering dei dispositivi di blocco consiste nell'eseguire la migrazione o il recupero dei dati da un pool in un altro.
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-namecephadm@adm >
rbd snap protect pool-name/image-name@snapshot-name
Ad esempio:
cephadm@adm >
rbd --pool pool1 snap protect --image image1 --snap snapshot1cephadm@adm >
rbd snap protect pool1/image1@snapshot1
Non è possibile eliminare uno snapshot protetto.
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-imagecephadm@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
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.
Prima di poter eliminare uno snapshot, è necessario annullarne la protezione. Inoltre, non è possibile eliminare snapshot con riferimenti dai cloni. È necessario appiattire ciascun clone di uno snapshot prima di poter eliminare quest'ultimo.
cephadm@adm >
rbd --pool pool-name snap unprotect --image image-name \ --snap snapshot-namecephadm@adm >
rbd snap unprotect pool-name/image-name@snapshot-name
Ad esempio:
cephadm@adm >
rbd --pool pool1 snap unprotect --image image1 --snap snapshot1cephadm@adm >
rbd snap unprotect pool1/image1@snapshot1
Per elencare gli elementi secondari di uno snapshot, eseguire quanto riportato di seguito:
cephadm@adm >
rbd --pool pool-name children --image image-name --snap snap-namecephadm@adm >
rbd children pool-name/image-name@snapshot-name
Ad esempio:
cephadm@adm >
rbd --pool pool1 children --image image1 --snap snapshot1cephadm@adm >
rbd children pool1/image1@snapshot1
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-namecephadm@adm >
rbd flatten pool-name/image-name
Ad esempio:
cephadm@adm >
rbd --pool pool1 flatten --image image1cephadm@adm >
rbd flatten pool1/image1
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.
È possibile eseguire la copia speculare delle immagini RBD in modo asincrono tra due cluster Ceph. Questa funzionalità utilizza la funzione journaling dell'immagine RBD per assicurare la replica con coerenza per arresto anomalo tra cluster. La copia speculare è configurata per ogni singolo pool nei cluster peer e può essere configurata in modo che venga eseguita automaticamente la copia speculare di tutte le immagini in un pool o solo di un sottoinsieme specifico di immagini. Per la configurazione della copia speculare si utilizza il comando rbd
. Il daemon rbd-mirror
è responsabile del pull degli aggiornamenti delle immagini dal cluster peer remoto e della loro applicazione all'immagine nel cluster locale.
Per utilizzare la copia speculare RBD, è necessario disporre di due cluster Ceph, su ciascuno dei quali è in esecuzione il daemon rbd-mirror
.
Non è possibile eseguire la copia speculare dei dispositivi RBD esportati tramite iSCSI con l'iSCSI Gateway basato sul kernel.
Per ulteriori dettagli su iSCSI, fare riferimento al Capitolo 18, Ceph iSCSI Gateway.
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-mirrorroot@minion >
systemctl enable ceph-rbd-mirror@server_name.serviceroot@minion >
systemctl start ceph-rbd-mirror@server_name.service
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.
Il nome cluster negli esempi seguenti corrisponde a un file di configurazione Ceph omonimo /etc/ceph/remote.conf
.
Per abilitare la copia speculare su un pool, specificare il sottocomando mirror pool enable
, il nome pool e la modalità di esecuzione di copia speculare. La modalità di esecuzione di copia speculare può essere "pool" oppure "image":
Tutte le immagini nel pool in cui è abilitata la funzione di journaling vengono sottoposte a copia speculare.
La copia speculare deve essere abilitata esplicitamente su ciascuna immagine. Per ulteriori informazioni, vedere Sezione 12.4.3.2, «Abilitazione della copia speculare dell'immagine».
Ad esempio:
cephadm@adm >
rbd --cluster local mirror pool enable POOL_NAME poolcephadm@adm >
rbd --cluster remote mirror pool enable POOL_NAME pool
Per disabilitare la copia speculare su un pool, specificare il sottocomando mirror pool disable
e il nome pool. Quando si disabilita la copia speculare su un pool in questo modo, questa verrà disabilitata anche su qualsiasi immagine (nel pool) per la quale è stata abilitata esplicitamente la copia speculare.
cephadm@adm >
rbd --cluster local mirror pool disable POOL_NAMEcephadm@adm >
rbd --cluster remote mirror pool disable POOL_NAME
Affinché il daemon rbd-mirror
rilevi il rispettivo cluster peer, è necessario registrare il peer nel pool. Per aggiungere un cluster peer in copia speculare, specificare il sottocomando mirror pool peer add
, il nome pool e una specifica del cluster:
cephadm@adm >
rbd --cluster local mirror pool peer add POOL_NAME client.remote@remotecephadm@adm >
rbd --cluster remote mirror pool peer add POOL_NAME client.local@local
Per rimuovere un cluster peer in copia speculare, specificare il sottocomando mirror pool peer remove
, il nome pool e l'UUID peer (reso disponibile dal comando rbd mirror pool info
):
cephadm@adm >
rbd --cluster local mirror pool peer remove POOL_NAME \ 55672766-c02b-4729-8567-f13a66893445cephadm@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
).
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
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
.
È 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.
Se la copia speculare è configurata in modalità "image", è necessario abilitare esplicitamente la copia speculare per ciascuna immagine nel pool. Per abilitare la copia speculare per un'immagine specifica, specificare il sottocomando mirror image enable
insieme al nome del pool e dell'immagine:
cephadm@adm >
rbd --cluster local mirror image enable POOL_NAME/IMAGE_NAME
Per disabilitare la copia speculare per un'immagine specifica, specificare il sottocomando mirror image disable
insieme al nome del pool e dell'immagine:
cephadm@adm >
rbd --cluster local mirror image disable POOL_NAME/IMAGE_NAME
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.
È 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
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.
Se viene rilevato un evento split brain dal daemon rbd-mirror
, non verrà effettuato alcun tentativo di copia speculare dell'immagine interessata finché non viene corretto. Per riprendere la copia speculare di un'immagine, prima abbassare di livello l'immagine definita obsoleta, quindi richiedere una risincronizzazione all'immagine primaria. Per richiedere una risincronizzazione dell'immagine, specificare il sottocomando mirror image resync
insieme al nome del pool e dell'immagine:
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
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.
L'implementazione dello spazio utente del dispositivo di blocco Ceph (librbd
) non può servirsi della cache delle pagine Linux. Pertanto, dispone di memorizzazione nella cache integrata. Il comportamento della memorizzazione nella cache RBD è simile a quello della memorizzazione nella cache del disco rigido. Quando il sistema operativo invia una richiesta di sbarramento o di svuotamento, tutti i dati modificati vengono scritti sugli OSD. Ciò significa che la memorizzazione nella cache Write-back garantisce gli stessi livelli di sicurezza di un disco rigido fisico integro con una macchina virtuale che invia correttamente gli svuotamenti. La cache utilizza un algoritmo Least Recently Used (LRU) e, in modalità Write-back, è in grado di unire le richieste adiacenti per migliorare la velocità effettiva.
Ceph supporta la memorizzazione nella cache Write-back per RBD. Per abilitarla, aggiungere
[client] ... rbd cache = true
alla sezione [client]
del file ceph.conf
. Per default, librbd
non esegue alcuna memorizzazione nella cache. Le operazioni di scrittura e lettura vanno direttamente al cluster di memorizzazione e le operazioni di scrittura vengono restituite solo quando i dati si trovano sul disco in tutte le repliche. Se la memorizzazione nella cache è abilitata, le operazioni di scrittura vengono subito restituite, a meno che il numero di byte non svuotati non sia superiore a quello impostato nell'opzione rbd cache max dirty
. In questo caso, l'operazione di scrittura attiva il writeback e si blocca finché non viene svuotato un numero sufficiente di byte.
Ceph supporta la memorizzazione nella cache Write-through per RBD. È possibile impostare le dimensioni della cache e le destinazioni e i limiti per passare dalla memorizzazione nella cache Write-back a quella Write-through. Per abilitare la modalità Write-through, impostare
rbd cache max dirty = 0
Ciò vuol dire che le operazioni di scrittura vengono restituite solo quando i dati si trovano sul disco in tutte le repliche, ma che le operazioni di lettura possono provenire dalla cache. La cache si trova nella memoria del client e ogni immagine RBD dispone della propria cache. Dal momento che la cache si trova in locale sul client, se altri accedono all'immagine, non vi è alcuna coerenza. Se la memorizzazione nella cache è abilitata, non sarà possibile eseguire OCFS o GFS su RBD.
È necessario configurare le impostazioni del file ceph.conf
per RBD nella sezione [client]
del file di configurazione. Le impostazioni includono:
rbd cache
Per abilitare la memorizzazione nella cache per il dispositivo di blocco RADOS (RBD). L'impostazione di default è "true".
rbd cache size
Dimensioni in byte della cache RBD. Il valore di default è 32 MB.
rbd cache max dirty
Limite di dati modificati espresso in byte in corrispondenza del quale la cache attiva il Write-back. Il valore di rbd cache max dirty
deve essere inferiore a rbd cache size
. Se è impostato a 0, utilizza la memorizzazione nella cache Write-through. Il valore di default è 24 MB.
rbd cache target dirty
Destinazione modificata prima che la cache inizi le operazioni di scrittura dei dati nel relativo storage. Non blocca le operazioni di scrittura nella cache. Il valore di default è 16 MB.
rbd cache max dirty age
Numero di secondi in cui i dati modificati si trovano nella cache prima dell'avvio del writeback. Il valore di default è 1.
rbd cache writethrough until flush
Si avvia in modalità Write-through e passa alla modalità Write-back in seguito alla ricezione della prima richiesta di svuotamento. Si tratta di un'impostazione prudente ma sicura se le macchine virtuali in esecuzione su rbd
sono troppo obsolete per inviare richieste di svuotamento (ad esempio, nel caso del driver virtio in Linux prima del kernel 2.6.32). L'impostazione di default è "true".
In genere, la qualità di servizio (QoS, Quality of Service) fa riferimento ai metodi di prioritizzazione del traffico e di prenotazione delle risorse. È particolarmente importante per il trasporto del traffico con requisiti speciali.
Le impostazioni QoS seguenti sono utilizzate solo dall'implementazione dello spazio utente RBD librbd
e non sono utilizzate dall'implementazione kRBD
. Poiché iSCSI utilizza kRBD
, non usa le impostazioni QoS. Tuttavia, per iSCSI è possibile configurare la QoS sul livello del dispositivo di blocco del kernel tramite le facility del kernel standard.
rbd qos iops limit
Limite desiderato delle operazioni I/O al secondo. Il valore di default è 0 (nessun limite).
rbd qos bps limit
Limite desiderato dei byte I/O al secondo. Il valore di default è 0 (nessun limite).
rbd qos read iops limit
Il limite desiderato di operazioni di lettura al secondo. Il valore di default è 0 (nessun limite).
rbd qos write iops limit
Il limite desiderato di operazioni di scrittura al secondo. Il valore di default è 0 (nessun limite).
rbd qos read bps limit
Il limite desiderato di byte letti al secondo. Il valore di default è 0 (nessun limite).
rbd qos write bps limit
Il limite desiderato di byte scritti al secondo. Il valore di default è 0 (nessun limite).
rbd qos iops burst
Limite di burst desiderato delle operazioni I/O. Il valore di default è 0 (nessun limite).
rbd qos bps burst
Limite di burst desiderato dei byte I/O. Il valore di default è 0 (nessun limite).
rbd qos read iops burst
Il limite di burst desiderato delle operazioni di lettura. Il valore di default è 0 (nessun limite).
rbd qos write iops burst
Il limite di burst desiderato delle operazioni di scrittura. Il valore di default è 0 (nessun limite).
rbd qos read bps burst
Il limite di burst desiderato dei byte letti. Il valore di default è 0 (nessun limite).
rbd qos write bps burst
Il limite di burst desiderato dei byte scritti. Il valore di default è 0 (nessun limite).
rbd qos schedule tick min
Tick di pianificazione minimo (in millisecondi) per QoS. Il valore di default è 50.
Il dispositivo di blocco RADOS supporta la lettura in avanti/prelettura per l'ottimizzazione delle operazioni di lettura piccole e sequenziali. Nel caso di una macchina virtuale, queste operazioni di lettura sono in genere gestite dal sistema operativo guest, anche se i boot loader potrebbero non generare letture efficaci. Se la memorizzazione nella cache è disabilitata, la lettura in avanti viene disabilitata automaticamente.
rbd readahead trigger requests
Numero di richieste di lettura sequenziali necessarie per attivare la lettura in avanti. Il valore di default è 10.
rbd readahead max bytes
Dimensioni massime della richiesta di lettura in avanti. Se è impostata su 0, la lettura in avanti è disabilitata. Il valore di default è 512 kB.
rbd readahead disable after bytes
In seguito alla lettura di questo numero di byte da un'immagine RBD, la lettura in avanti è disabilitata per tale immagine fino alla chiusura. In questo modo, il sistema operativo guest può subentrare alla lettura in avanti al momento dell'avvio. Se è impostata su 0, la lettura in avanti rimane abilitata. Il valore di default è 50 MB.
Il dispositivo di blocco RADOS supporta le funzioni avanzate che consentono di migliorare la funzionalità delle immagini RBD. È possibile specificare le funzioni sulla riga di comando durante la creazione di un'immagine RBD oppure nel file di configurazione Ceph tramite l'opzione rbd_default_features
.
È possibile specificare i valori dell'opzione rbd_default_features
in due modi:
Come somma dei valori interni delle funzioni. Ogni funzione dispone di un proprio valore interno; ad esempio il valore di "layering" è 1 e quello di "fast-diff" è 16. Di conseguenza, per attivare queste due funzioni per default, includere quanto segue:
rbd_default_features = 17
Come elenco di funzioni separate da virgole. L'esempio precedente avrà l'aspetto seguente:
rbd_default_features = layering,fast-diff
Le immagini RBD con le funzioni seguenti non saranno supportate da iSCSI: deep-flatten
, object-map
, journaling
, fast-diff
, striping
Di seguito è riportato un elenco delle funzioni RBD avanzate:
layering
Il layering consente di utilizzare la funzione di clonazione.
Il valore interno è 1; quello di default è "yes".
striping
Lo striping consente di distribuire i dati tra più oggetti e agevola il parallelismo dei workload sequenziali di lettura/scrittura. Consente di evitare la formazione di colli di bottiglia sui singoli nodi per dispositivi di blocco RADOS di grandi dimensioni oppure occupati.
Il valore interno è 2; quello di default è "yes".
exclusive-lock
Quando abilitata, necessita di un client per ottenere un blocco su un oggetto prima di eseguire un'operazione di scrittura. Abilitare il blocco esclusivo solo quando un client singolo sta effettuando l'accesso a un'immagine nello stesso momento. Il valore interno è 4. L'impostazione di default è "yes".
object-map
Il supporto della mappa oggetti dipende dal supporto del blocco esclusivo. I dispositivi di blocco sono soggetti a thin provisioning e di conseguenza memorizzano soltanto i dati effettivamente esistenti. Il supporto della mappa oggetti consente di monitorare gli oggetti effettivamente esistenti (con dati memorizzati su un'unità). L'abilitazione del supporto della mappa oggetti consente di velocizzare le operazioni I/O per la clonazione, l'importazione e l'esportazione di un'immagine compilata in modo sparse e per l'eliminazione.
Il valore interno è 8; quello di default è "yes".
fast-diff
Il supporto di fast-diff dipende dal supporto della mappa oggetti e del blocco esclusivo. Aggiunge un'altra proprietà alla mappa oggetti che la rende notevolmente più rapida nella creazione delle differenze tra le snapshot di un'immagine e l'utilizzo effettivo dei dati di una snapshot.
Il valore interno è 16; quello di default è "yes".
deep-flatten
La funzione deep-flatten attiva l'opzione rbd flatten
(vedere la Sezione 12.3.3.6, «Appiattimento di un'immagine clonata») su tutte le snapshot di un'immagine oltre che sull'immagine stessa. Senza di essa, le snapshot di un'immagine continueranno a dipendere da quella superiore e di conseguenza non sarà possibile eliminare tale immagine superiore finché non vengono eliminate anche le snapshot. Con l'impostazione deep-flatten, l'elemento superiore è reso indipendente dai cloni, anche se dispongono di snapshot.
Il valore interno è 32; quello di default è "yes".
Journaling
Il supporto del journaling dipende dal supporto del blocco esclusivo. La funzione di journaling consente di registrare tutte le modifiche apportate a un'immagine nell'ordine in cui si verificano. La copia speculare RBD (vedere la Sezione 12.4, «Esecuzione di copia speculare») utilizza il journal per replicare un'immagine coerente con l'arresto anomalo in un cluster remoto.
Il valore interno è 64; quello di default è "yes".
I client meno recenti (ad esempio SLE11 SP4) potrebbero non essere in grado di mappare le immagini RBD poiché un cluster distribuito con SUSE Enterprise Storage 6 forza alcune funzioni (sia le funzioni a livello di immagine RBD che quelle a livello RADOS) non supportate dai client meno recenti. In questo caso, sui log OSD vengono visualizzati dei messaggi simili al seguente:
2019-05-17 16:11:33.739133 7fcb83a2e700 0 -- 192.168.122.221:0/1006830 >> \ 192.168.122.152:6789/0 pipe(0x65d4e0 sd=3 :57323 s=1 pgs=0 cs=0 l=1 c=0x65d770).connect \ protocol feature mismatch, my 2fffffffffff < peer 4010ff8ffacffff missing 401000000000000
Se si intende passare dal tipo di compartimento della mappa CRUSH "straw" a quello "straw2" e viceversa, procedere secondo una pianificazione. È prevedibile che questa operazione causi un impatto significativo sul carico del cluster, poiché la modifica del tipo di compartimento causerà un significativo ribilanciamento.
Disabilitare le funzioni dell'immagine RBD non supportate. Ad esempio:
cephadm@adm >
rbd feature disable pool1/image1 object-mapcephadm@adm >
rbd feature disable pool1/image1 exclusive-lock
Modificare il tipo di compartimento della mappa CRUSH da "straw2" a "straw":
Salvare la mappa CRUSH:
cephadm@adm >
ceph osd getcrushmap -o crushmap.original
Decompilare la mappa CRUSH:
cephadm@adm >
crushtool -d crushmap.original -o crushmap.txt
Modificare la mappa CRUSH e sostituire "straw2" con "straw".
Ricompilare la mappa CRUSH:
cephadm@adm >
crushtool -c crushmap.txt -o crushmap.new
Impostare la nuova mappa CRUSH:
cephadm@adm >
ceph osd setcrushmap -i crushmap.new