20 Dispositivo di blocco RADOS (RADOS Block Device, RBD) #
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.
20.1 Comandi dei dispositivi di blocco #
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.
20.1.1 Creazione di un'immagine del dispositivo di blocco in un pool replicato #
Prima che sia possibile aggiungere un dispositivo di blocco a un client, è necessario creare un'immagine correlata in un pool esistente (vedere il Capitolo 18, Gestione dei pool di memorizzazione):
cephuser@adm > rbd create --size MEGABYTES POOL-NAME/IMAGE-NAMEAd 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:
cephuser@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.
20.1.2 Creazione di un'immagine del dispositivo di blocco in un pool con codice di cancellazione #
È possibile memorizzare i dati dell'immagine di un dispositivo di blocco direttamente nei pool con codice di cancellazione (EC, Erasure Coded). 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 (RADOS Block Device, RBD) in un pool EC. Il flag overwrite del pool deve essere impostato su true e ciò è 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 oppure aggiungendo pool/ come prefisso del nome dell'immagine.
Creare un pool EC:
cephuser@adm >ceph osd pool create EC_POOL 12 12 erasurecephuser@adm >ceph osd pool set EC_POOL allow_ec_overwrites true
Specificare il pool replicato per la memorizzazione dei metadati:
cephuser@adm > rbd create IMAGE_NAME --size=1G --data-pool EC_POOL --pool=POOLOppure:
cephuser@adm > rbd create POOL/IMAGE_NAME --size=1G --data-pool EC_POOL20.1.3 Elenco delle immagini dei dispositivi di blocco #
Per visualizzare un elenco dei dispositivi di blocco in un pool denominato "mypool", eseguire quanto riportato di seguito:
cephuser@adm > rbd ls mypool20.1.4 Recupero delle informazioni sull'immagine #
Per recuperare le informazioni da un'immagine "myimage" in un pool denominato "mypool", eseguire quanto riportato di seguito:
cephuser@adm > rbd info mypool/myimage20.1.5 Ridimensionamento di un'immagine del dispositivo di blocco #
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:
cephuser@adm >rbd resize --size 2048 POOL_NAME/IMAGE_NAME # to increasecephuser@adm >rbd resize --size 2048 POOL_NAME/IMAGE_NAME --allow-shrink # to decrease
20.1.6 Rimozione di un'immagine del dispositivo di blocco #
Per rimuovere un dispositivo di blocco che corrisponde a un'immagine "myimage" in un pool denominato "mypool", eseguire quanto riportato di seguito:
cephuser@adm > rbd rm mypool/myimage20.2 Montaggio e smontaggio #
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.
L'impostazione di default del comando rbd è configurata sull'accesso al cluster tramite l'account utente admin di Ceph, che dispone dell'accesso amministrativo completo al cluster. Con questa impostazione vi è il rischio che gli utenti possano causare involontariamente danni, come quando si esegue il login come root a una workstation Linux. Pertanto, è preferibile creare account utente con meno privilegi e utilizzare tali account per il normale accesso in lettura/scrittura al dispositivo di blocco RADOS (RADOS Block Device, RBD).
20.2.1 Creazione di un account utente Ceph #
Per creare un nuovo account utente con le funzionalità Ceph Manager, Ceph Monitor e Ceph OSD, utilizzare il comando ceph con il sottocomando auth get-or-create:
cephuser@adm > ceph auth get-or-create client.ID mon 'profile rbd' osd 'profile profile name \
[pool=pool-name] [, profile ...]' mgr 'profile rbd [pool=pool-name]'Ad esempio, per creare un utente denominato qemu con accesso in lettura-scrittura al pool vms e accesso in sola lettura al pool images, eseguire quanto riportato di seguito:
ceph auth get-or-create client.qemu mon 'profile rbd' osd 'profile rbd pool=vms, profile rbd-read-only pool=images' \ mgr 'profile rbd pool=images'
L'output del comando ceph auth get-or-create sarà il portachiavi dell'utente specificato ed è possibile scriverlo in /etc/ceph/ceph.client.ID.keyring.
Quando si utilizza il comando rbd, è possibile specificare l'ID utente fornendo l'argomento facoltativo --id
ID.
Per ulteriori dettagli sulla gestione degli account utente Ceph, fare riferimento al Capitolo 30, Autenticazione con cephx.
20.2.2 Autenticazione utente #
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:
cephuser@adm > rbd device map --pool rbd myimage --id admin --keyring /path/to/keyringoppure
cephuser@adm > rbd device map --pool rbd myimage --id admin --keyfile /path/to/file20.2.3 Preparazione di un dispositivo di blocco RADOS (RADOS Block Device, RBD) per l'uso #
Accertarsi che nel cluster Ceph sia incluso un pool con l'immagine disco che si desidera mappare. Presupporre che il pool sia denominato
mypoole l'immaginemyimage.cephuser@adm >rbd list mypoolMappare l'immagine nel nuovo dispositivo di blocco:
cephuser@adm >rbd device map --pool mypool myimageElencare tutti i dispositivi mappati:
cephuser@adm >rbd device list id pool image snap device 0 mypool myimage - /dev/rbd0Il dispositivo che si desidera utilizzare è
/dev/rbd0.Suggerimento: percorso di dispositivo RBDAl posto di
/dev/rbdDEVICE_NUMBER, è possibile utilizzare/dev/rbd/POOL_NAME/IMAGE_NAMEcome percorso di dispositivo permanente. Esempio:/dev/rbd/mypool/myimage
Creare un file system XFS sul dispositivo
/dev/rbd0:#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=0Sostituire
/mntcon il proprio punto di montaggio, montare il dispositivo e verificare che sia montato correttamente:#mount /dev/rbd0 /mnt#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.
Suggerimento: aumento delle dimensioni del dispositivo RBDSe le dimensioni del dispositivo RBD non sono più sufficienti, è possibile aumentarle.
Aumentare le dimensioni dell'immagine RBD, ad esempio fino a 10 GB.
cephuser@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:
#xfs_growfs /mnt [...] data blocks changed from 2097152 to 2560000
Una volta terminato l'accesso al dispositivo, è possibile annullare la mappatura e smontarlo.
cephuser@adm >rbd device unmap /dev/rbd0#unmount /mnt
Per semplificare i processi di mappatura e montaggio degli RBD dopo l'avvio e di smontaggio dopo l'arresto, vengono forniti uno script rbdmap e un'unità systemd. Vedere Sezione 20.2.4, «rbdmap: mappatura dei dispositivi RBD all'avvio».
20.2.4 rbdmap: mappatura dei dispositivi RBD all'avvio #
rbdmap è uno script della shell che consente di automatizzare le operazioni rbd map e rbd device 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_specificationPercorso di un'immagine in un pool. Specificare come pool_name/image_name.
rbd_optionsElenco di parametri facoltativo da passare al comando
rbd device mapsottostante. 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
rbdmapviene eseguito il seguente comando:cephuser@adm >rbd device map POOL_NAME/IMAGE_NAME --PARAM1 VAL1 --PARAM2 VAL2Nell'esempio seguente è possibile vedere come specificare un nome utente e un portachiavi con un segreto corrispondente:
cephuser@adm >rbdmap device 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 rbd device 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 device map mappa l'immagine a un dispositivo /dev/rbdX, 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).
20.2.5 Aumento delle dimensioni dei dispositivi RBD #
Se le dimensioni del dispositivo RBD non sono più sufficienti, è possibile aumentarle.
Aumentare le dimensioni dell'immagine RBD, ad esempio fino a 10 GB.
cephuser@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.
#xfs_growfs /mnt [...] data blocks changed from 2097152 to 2560000
20.3 Snapshot #
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.
20.3.1 Abilitazione e configurazione di cephx #
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 30, Autenticazione con cephx. È inoltre possibile aggiungere la variabile di ambiente CEPH_ARGS per evitare di immettere di nuovo i seguenti parametri.
cephuser@adm >rbd --id user-ID --keyring=/path/to/secret commandscephuser@adm >rbd --name username --keyring=/path/to/secret commands
Ad esempio:
cephuser@adm >rbd --id admin --keyring=/etc/ceph/ceph.keyring commandscephuser@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.
20.3.2 Nozioni di base sugli snapshot #
Nelle procedure seguenti è dimostrato come creare, elencare e rimuovere snapshot mediante l'uso del comando rbd sulla riga di comando.
20.3.2.1 Creazione di snapshot #
Per creare uno snapshot con rbd, specificare l'opzione snap create, il nome pool e il nome immagine.
cephuser@adm >rbd --pool pool-name snap create --snap snap-name image-namecephuser@adm >rbd snap create pool-name/image-name@snap-name
Esempio:
cephuser@adm >rbd --pool rbd snap create --snap snapshot1 image1cephuser@adm >rbd snap create rbd/image1@snapshot1
20.3.2.2 Elenco di snapshot #
Per elencare gli snapshot di un'immagine, specificare il nome pool e il nome immagine.
cephuser@adm >rbd --pool pool-name snap ls image-namecephuser@adm >rbd snap ls pool-name/image-name
Esempio:
cephuser@adm >rbd --pool rbd snap ls image1cephuser@adm >rbd snap ls rbd/image1
20.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.
cephuser@adm >rbd --pool pool-name snap rollback --snap snap-name image-namecephuser@adm >rbd snap rollback pool-name/image-name@snap-name
Esempio:
cephuser@adm >rbd --pool pool1 snap rollback --snap snapshot1 image1cephuser@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.
20.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.
cephuser@adm >rbd --pool pool-name snap rm --snap snap-name image-namecephuser@adm >rbd snap rm pool-name/image-name@snap-name
Esempio:
cephuser@adm >rbd --pool pool1 snap rm --snap snapshot1 image1cephuser@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.
20.3.2.5 Eliminazione definitiva di snapshot #
Per eliminare tutti gli snapshot di un'immagine con rbd, specificare l'opzione snap purge e il nome immagine.
cephuser@adm >rbd --pool pool-name snap purge image-namecephuser@adm >rbd snap purge pool-name/image-name
Esempio:
cephuser@adm >rbd --pool pool1 snap purge image1cephuser@adm >rbd snap purge pool1/image1
20.3.3 Layering degli snapshot #
Ceph supporta la creazione di più 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.
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.
20.3.3.1 Introduzione al layering #
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 patchseguito darbd 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.
20.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.
cephuser@adm >rbd --pool pool-name snap protect \ --image image-name --snap snapshot-namecephuser@adm >rbd snap protect pool-name/image-name@snapshot-name
Esempio:
cephuser@adm >rbd --pool pool1 snap protect --image image1 --snap snapshot1cephuser@adm >rbd snap protect pool1/image1@snapshot1
Non è possibile eliminare uno snapshot protetto.
20.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.
cephuser@adm >rbd clone --pool pool-name --image parent-image \ --snap snap-name --dest-pool pool-name \ --dest child-imagecephuser@adm >rbd clone pool-name/parent-image@snap-name \ pool-name/child-image-name
Esempio:
cephuser@adm > rbd clone pool1/image1@snapshot1 pool1/image2Si 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.
20.3.3.4 Annullamento della protezione di uno snapshot #
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.
cephuser@adm >rbd --pool pool-name snap unprotect --image image-name \ --snap snapshot-namecephuser@adm >rbd snap unprotect pool-name/image-name@snapshot-name
Esempio:
cephuser@adm >rbd --pool pool1 snap unprotect --image image1 --snap snapshot1cephuser@adm >rbd snap unprotect pool1/image1@snapshot1
20.3.3.5 Elenco degli elementi secondari di uno snapshot #
Per elencare gli elementi secondari di uno snapshot, eseguire quanto riportato di seguito:
cephuser@adm >rbd --pool pool-name children --image image-name --snap snap-namecephuser@adm >rbd children pool-name/image-name@snapshot-name
Esempio:
cephuser@adm >rbd --pool pool1 children --image image1 --snap snapshot1cephuser@adm >rbd children pool1/image1@snapshot1
20.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.
cephuser@adm >rbd --pool pool-name flatten --image image-namecephuser@adm >rbd flatten pool-name/image-name
Esempio:
cephuser@adm >rbd --pool pool1 flatten --image image1cephuser@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.
20.4 Copie speculari delle immagini RBD #
È possibile eseguire la copia speculare delle immagini RBD in modo asincrono tra due cluster Ceph. Questa funzionalità è disponibile in due modalità:
- Basata sul journal
Questa modalità utilizza la funzione di journaling dell'immagine RBD per assicurare la replica temporizzata e con coerenza per arresto anomalo tra cluster. Prima di modificare l'immagine effettiva, ogni operazione di scrittura sull'immagine RBD viene innanzitutto registrata sul journal associato. Il cluster
remoteleggerà dal journal e riprodurrà gli aggiornamenti nella relativa copia locale dell'immagine. Dal momento che ogni operazione di scrittura sull'immagine RBD risulta in due operazioni di scrittura sul cluster Ceph, prevedere un raddoppiamento delle latenze di scrittura quando si utilizza la funzione di journaling dell'immagine RBD.- Basata su snapshot
Questa modalità utilizza snapshot di copia speculare dell'immagine RBD pianificati periodicamente o creati manualmente per eseguire la replica delle immagini RBD con coerenza per arresto anomalo tra cluster. Il cluster
remotedeterminerà la presenza di eventuali aggiornamenti dei dati o dei metadati tra due snapshot di copia speculare e copierà i valori differenziali nella relativa copia locale dell'immagine. Con la funzione fast-diff dell'immagine RBD, è possibile calcolare rapidamente i blocchi di dati aggiornati senza dover effettuare la scansione dell'intera immagine RBD. Dal momento che questa modalità non garantisce coerenza temporizzata, sarà necessario sincronizzare il valore differenziale completo dello snapshot prima dell'uso in uno scenario di failover. Gli eventuali valori differenziali dello snapshot applicati parzialmente verranno sottoposti a rollback sull'ultimo snapshot di cui è stata completata la sincronizzazione.
La copia speculare è configurata per ogni singolo pool nei cluster peer e può essere configurata su un sottoinsieme specifico di immagini all'interno del pool o in modo che venga eseguita automaticamente la copia speculare di tutte le immagini di un pool quando è in uso soltanto la copia speculare basata sul journal. 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 remote e della loro applicazione all'immagine nel cluster local.
A seconda delle necessità di replica, è possibile configurare la copia speculare RBD sulla replica a una o a due vie:
- Replica a una via
Quando la copia speculare dei dati avviene soltanto da un cluster primario a uno secondario, il daemon
rbd-mirrorviene eseguito solo sul cluster secondario.- Replica a due vie
Quando la copia speculare dei dati avviene dalle immagini primarie su un cluster alle immagini non primarie su un altro cluster (e viceversa), il daemon
rbd-mirrorviene eseguito su entrambi i cluster.
Ogni istanza del daemon rbd-mirror deve essere in grado di connettersi contemporaneamente a entrambi i cluster local e remote Ceph. Ad esempio, a tutti i monitor e agli host OSD. Inoltre, la larghezza di banda della rete tra i due data center deve essere sufficiente per gestire il workload della copia speculare.
20.4.1 Configurazione del pool #
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 del cluster negli esempi seguenti corrisponde a un file di configurazione Ceph omonimo /etc/ceph/remote.conf e al file del portachiavi Ceph omonimo /etc/ceph/remote.client.admin.keyring.
20.4.1.1 Abilitazione della copia speculare su un pool #
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":
- pool
Tutte le immagini nel pool in cui è abilitata la funzione di journaling vengono sottoposte a copia speculare.
- immagine
La copia speculare deve essere abilitata esplicitamente su ciascuna immagine. Consultare Sezione 20.4.2.1, «Abilitazione della copia speculare dell'immagine» per maggiori informazioni.
Esempio:
cephuser@adm >rbd --cluster local mirror pool enable POOL_NAME poolcephuser@adm >rbd --cluster remote mirror pool enable POOL_NAME pool
20.4.1.2 Disabilitazione della copia speculare #
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.
cephuser@adm >rbd --cluster local mirror pool disable POOL_NAMEcephuser@adm >rbd --cluster remote mirror pool disable POOL_NAME
20.4.1.3 Esecuzione del bootstrap dei peer #
Affinché il daemon rbd-mirror rilevi il rispettivo cluster peer, è necessario registrare il peer nel pool e creare un account utente. Questo processo può essere automatizzato con rbd e i comandi mirror pool peer bootstrap create e mirror pool peer bootstrap import.
Per creare manualmente un nuovo token di bootstrap con rbd, specificare il comando mirror pool peer bootstrap create, il nome del pool e un nome descrittivo facoltativo del sito per la descrizione del cluster local:
cephuser@local > rbd mirror pool peer bootstrap create \
[--site-name LOCAL_SITE_NAME] POOL_NAME
L'output di mirror pool peer bootstrap create sarà un token che dovrà essere fornito al comando mirror pool peer bootstrap import. Ad esempio, sul cluster local:
cephuser@local > rbd --cluster local mirror pool peer bootstrap create --site-name local image-pool
eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW1pcnJvci1wZWVyIiwia2V5I \
joiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1vbl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==
Per importare manualmente il token di bootstrap creato da un altro cluster con il comando rbd, utilizzare la sintassi seguente:
rbd mirror pool peer bootstrap import \ [--site-name LOCAL_SITE_NAME] \ [--direction DIRECTION \ POOL_NAME TOKEN_PATH
Dove:
- LOCAL_SITE_NAME
Nome descrittivo facoltativo del sito per la descrizione del cluster
local.- DIRECTION
Direzione della copia speculare. L'impostazione di default è
rx-txper la copia speculare bidirezionale, ma è possibile configurare questa impostazione anche surx-onlyper la copia speculare unidirezionale.- POOL_NAME
Nome del pool.
- TOKEN_PATH
Percorso del file al token creato (o
-per leggerlo dall'input standard).
Ad esempio, sul cluster remote:
cephuser@remote > cat <<EOF > token
eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1vbl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==
EOFcephuser@adm > rbd --cluster remote mirror pool peer bootstrap import \
--site-name remote image-pool token20.4.1.4 Aggiunta manuale di un peer del cluster #
Come alternativa all'esecuzione del bootstrap dei peer descritta nella Sezione 20.4.1.3, «Esecuzione del bootstrap dei peer», è possibile specificare i peer manualmente. Per eseguire la copia speculare, il daemon rbd-mirror remoto necessita dell'accesso al cluster locale. Creare un nuovo utente Ceph locale che verrà utilizzato dal daemon rbd-mirror remoto, ad esempio rbd-mirror-peer:
cephuser@adm > ceph auth get-or-create client.rbd-mirror-peer \
mon 'profile rbd' osd 'profile rbd'
Utilizzare la sintassi seguente per aggiungere un cluster Ceph peer in copia speculare con il comando rbd:
rbd mirror pool peer add POOL_NAME CLIENT_NAME@CLUSTER_NAME
Esempio:
cephuser@adm >rbd --cluster site-a mirror pool peer add image-pool client.rbd-mirror-peer@site-bcephuser@adm >rbd --cluster site-b mirror pool peer add image-pool client.rbd-mirror-peer@site-a
Per default, il daemon rbd-mirror deve disporre dell'accesso al file di configurazione Ceph ubicato in /etc/ceph/.CLUSTER_NAME.conf, in cui sono specificati gli indirizzi IP dei MON del cluster peer e il portachiavi relativo a un client denominato CLIENT_NAME e ubicato nel percorso di ricerca del portachiavi di default o predefinito, ad esempio /etc/ceph/CLUSTER_NAME.CLIENT_NAME.keyring.
In alternativa, è possibile memorizzare in modo sicuro la chiave client e/o il MON del cluster peer nell'archivio config-key Ceph. Per specificare gli attributi di connessione del cluster peer durante l'aggiunta di un peer in copia speculare, utilizzare le opzioni --remote-mon-host e --remote-key-file. Esempio:
cephuser@adm >rbd --cluster site-a mirror pool peer add image-pool \ client.rbd-mirror-peer@site-b --remote-mon-host 192.168.1.1,192.168.1.2 \ --remote-key-file /PATH/TO/KEY_FILEcephuser@adm >rbd --cluster site-a mirror pool info image-pool --all Mode: pool Peers: UUID NAME CLIENT MON_HOST KEY 587b08db... site-b client.rbd-mirror-peer 192.168.1.1,192.168.1.2 AQAeuZdb...
20.4.1.5 Rimozione di un peer del cluster #
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):
cephuser@adm >rbd --cluster local mirror pool peer remove POOL_NAME \ 55672766-c02b-4729-8567-f13a66893445cephuser@adm >rbd --cluster remote mirror pool peer remove POOL_NAME \ 60c0e299-b38f-4234-91f6-eed0a367be08
20.4.1.6 Pool di dati #
Durante la creazione di immagini nel cluster di destinazione, rbd-mirror seleziona un pool di dati come segue:
Se presente, verrà utilizzato il pool di dati di default configurato (con l'opzione di configurazione
rbd_default_data_pool) del cluster di destinazione.In caso contrario, se l'immagine di origine utilizza un pool di dati separato e sul cluster di destinazione esiste già un pool con lo stesso nome, verrà utilizzato tale pool.
Se nessuna delle due condizioni descritte sopra è applicabile, non verrà impostato alcun pool di dati.
20.4.2 Configurazione dell'immagine RBD #
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 20.4.2.1, «Abilitazione della copia speculare dell'immagine») mediante il comando rbd).
20.4.2.1 Abilitazione della copia speculare dell'immagine #
Se la copia speculare è configurata in modalità image, è necessario abilitarla esplicitamente per ciascuna immagine nel pool. Per abilitare la copia speculare per un'immagine specifica con rbd, specificare il sottocomando mirror image enable insieme al nome del pool e dell'immagine:
cephuser@adm > rbd --cluster local mirror image enable \
POOL_NAME/IMAGE_NAME
È possibile eseguire la copia speculare dell'immagine in modalità journal o snapshot:
- journal (default)
Se configurata nella modalità
journal, la copia speculare utilizzerà la funzione di journaling dell'immagine RBD per replicarne il contenuto. Tale funzione verrà abilitata automaticamente se non è stata ancora abilitata sull'immagine.- istantanea
Se configurata nella modalità
snapshot, la copia speculare utilizzerà gli snapshot di copia speculare dell'immagine RBD per replicarne il contenuto. Dopo l'abilitazione, verrà automaticamente creato un primo snapshot di copia speculare dell'immagine RBD e sarà possibile crearne altri con il comandorbd.
Esempio:
cephuser@adm >rbd --cluster local mirror image enable image-pool/image-1 snapshotcephuser@adm >rbd --cluster local mirror image enable image-pool/image-2 journal
20.4.2.2 Abilitazione della funzione di 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. Se si utilizza la modalità di copia speculare image, la funzione di journaling sarà abilitata automaticamente se sull'immagine è abilitata la copia speculare. Se si utilizza la modalità di copia speculare pool, prima che sia possibile sottoporre a copia speculare un'immagine su un cluster peer, occorre abilitare la funzione di journaling dell'immagine RBD. È possibile abilitare tale funzione al momento della creazione dell'immagine specificando l'opzione --image-feature exclusive-lock,journaling nel 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:
cephuser@adm >rbd --cluster local feature enable POOL_NAME/IMAGE_NAME exclusive-lockcephuser@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 rbd default features = layering,exclusive-lock,object-map,deep-flatten,journaling al file di configurazione Ceph.
20.4.2.3 Creazione di snapshot di copia speculare dell'immagine #
Se si utilizza la copia speculare basata su snapshot, sarà necessario creare snapshot di copia speculare ogni volta che si desidera eseguire la copia speculare dei contenuti modificati dell'immagine RBD. Per creare manualmente uno snapshot di copia speculare con rbd, specificare il comando mirror image snapshot insieme al nome del pool e dell'immagine:
cephuser@adm > rbd mirror image snapshot POOL_NAME/IMAGE_NAMEEsempio:
cephuser@adm > rbd --cluster local mirror image snapshot image-pool/image-1
Per default, vengono creati solo tre snapshot di copia speculare per immagine. Se questo limite viene raggiunto, lo snapshot di copia speculare più recente viene eliminato automaticamente. Se necessario, è possibile ignorare questo limite con l'opzione di configurazione rbd_mirroring_max_mirroring_snapshots. Inoltre, gli snapshot di copia speculare vengono eliminati automaticamente quando l'immagine viene rimossa o quando la copia speculare viene disabilitata.
È inoltre possibile definire una pianificazione per la creazione automatica e periodica degli snapshot di copia speculare. Questi ultimi possono essere pianificati a livello globale, di singolo pool o di singola immagine. È possibile definire più pianificazioni di snapshot di copia speculare su qualsiasi livello, ma verranno eseguite soltanto le pianificazioni più specifiche corrispondenti a una singola immagine in copia speculare.
Per creare una pianificazione di snapshot di copia speculare con rbd, specificare il comando mirror snapshot schedule add insieme a un nome facoltativo del pool o dell'immagine, a un intervallo e a un'ora di inizio facoltativa.
L'intervallo può essere espresso in giorni, ore o minuti utilizzando rispettivamente i suffissi d, h o m. L'ora di inizio facoltativa può essere specificata utilizzando il formato di ora ISO 8601. Esempio:
cephuser@adm >rbd --cluster local mirror snapshot schedule add --pool image-pool 24h 14:00:00-05:00cephuser@adm >rbd --cluster local mirror snapshot schedule add --pool image-pool --image image1 6h
Per rimuovere una pianificazione di snapshot di copia speculare con rbd, specificare il comando mirror snapshot schedule remove con le opzioni corrispondenti al comando per l'aggiunta della pianificazione equivalente.
Per elencare tutte le pianificazioni di snapshot per un livello specifico (globale, pool o immagine) con rbd, immettere il comando mirror snapshot schedule ls insieme a un nome facoltativo del pool o dell'immagine. Inoltre, tramite l'opzione --recursive, è possibile elencare tutte le pianificazioni del livello specificato e dei livelli sottostanti. Esempio:
cephuser@adm > rbd --cluster local mirror schedule ls --pool image-pool --recursive
POOL NAMESPACE IMAGE SCHEDULE
image-pool - - every 1d starting at 14:00:00-05:00
image-pool image1 every 6h
Per verificare con rbd quando saranno creati i successivi snapshot per le immagini RBD con copia speculare basata su snapshot, specificare il comando mirror snapshot schedule status insieme a un nome facoltativo del pool o dell'immagine. Esempio:
cephuser@adm > rbd --cluster local mirror schedule status
SCHEDULE TIME IMAGE
2020-02-26 18:00:00 image-pool/image120.4.2.4 Disabilitazione della copia speculare dell'immagine #
Per disabilitare la copia speculare per un'immagine specifica, specificare il sottocomando mirror image disable insieme al nome del pool e dell'immagine:
cephuser@adm > rbd --cluster local mirror image disable POOL_NAME/IMAGE_NAME20.4.2.5 Promozione e abbassamento di livello delle immagini #
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:
cephuser@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:
cephuser@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:
cephuser@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:
cephuser@adm > rbd --cluster local mirror pool promote POOL_NAMEPoiché 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.
20.4.2.6 Risincronizzazione forzata dell'immagine #
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:
cephuser@adm > rbd mirror image resync POOL_NAME/IMAGE_NAME20.4.3 Verifica dello stato della copia speculare #
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:
cephuser@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:
cephuser@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.
20.5 Impostazioni della cache #
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, eseguire
cephuser@adm > ceph config set client rbd_cache true
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, eseguire
cephuser@adm > ceph config set client rbd_cache_max_dirty 0Ciò 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.
I parametri seguenti influiscono sul comportamento dei dispositivi di blocco RADOS (RADOS Block Device, RBD). Per impostarli, utilizzare la categoria client:
cephuser@adm > ceph config set client PARAMETER VALUErbd cachePer abilitare la memorizzazione nella cache per il dispositivo di blocco RADOS (RBD). L'impostazione di default è "true".
rbd cache sizeDimensioni in byte della cache RBD. Il valore di default è 32 MB.
rbd cache max dirtyLimite di dati modificati espresso in byte in corrispondenza del quale la cache attiva il Write-back. Il valore di
rbd cache max dirtydeve essere inferiore arbd cache size. Se è impostato a 0, utilizza la memorizzazione nella cache Write-through. Il valore di default è 24 MB.rbd cache target dirtyDestinazione 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 ageNumero 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 flushSi 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
rbdsono 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".
20.6 Impostazioni QoS #
In genere, la Qualità di servizio (QoS, Quality of Service) fa riferimento ai metodi per la definizione della priorità del traffico e per la 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 limitLimite desiderato delle operazioni I/O al secondo. Il valore di default è 0 (nessun limite).
rbd qos bps limitLimite desiderato dei byte I/O al secondo. Il valore di default è 0 (nessun limite).
rbd qos read iops limitIl limite desiderato di operazioni di lettura al secondo. Il valore di default è 0 (nessun limite).
rbd qos write iops limitIl limite desiderato di operazioni di scrittura al secondo. Il valore di default è 0 (nessun limite).
rbd qos read bps limitIl limite desiderato di byte letti al secondo. Il valore di default è 0 (nessun limite).
rbd qos write bps limitIl limite desiderato di byte scritti al secondo. Il valore di default è 0 (nessun limite).
rbd qos iops burstLimite di burst desiderato delle operazioni I/O. Il valore di default è 0 (nessun limite).
rbd qos bps burstLimite di burst desiderato dei byte I/O. Il valore di default è 0 (nessun limite).
rbd qos read iops burstIl limite di burst desiderato delle operazioni di lettura. Il valore di default è 0 (nessun limite).
rbd qos write iops burstIl limite di burst desiderato delle operazioni di scrittura. Il valore di default è 0 (nessun limite).
rbd qos read bps burstIl limite di burst desiderato dei byte letti. Il valore di default è 0 (nessun limite).
rbd qos write bps burstIl limite di burst desiderato dei byte scritti. Il valore di default è 0 (nessun limite).
rbd qos schedule tick minTick di pianificazione minimo (in millisecondi) per QoS. Il valore di default è 50.
20.7 Impostazioni di lettura in avanti #
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.
Le impostazioni di lettura in avanti 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 di lettura in avanti. Tuttavia, per iSCSI è possibile configurare la lettura in avanti sullo strato del dispositivo di blocco del kernel tramite le facility del kernel standard.
rbd readahead trigger requestsNumero di richieste di lettura sequenziali necessarie per attivare la lettura in avanti. Il valore di default è 10.
rbd readahead max bytesDimensioni 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 bytesIn 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.
20.8 Funzioni avanzate #
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:
layeringIl layering consente di utilizzare la funzione di clonazione.
Il valore interno è 1; quello di default è "yes".
stripingLo 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-lockQuando 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-mapIl 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-diffIl 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-flattenLa funzione deep-flatten attiva l'opzione
rbd flatten(vedere la Sezione 20.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".
journalingIl 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 20.4, «Copie speculari delle immagini RBD») utilizza il journal per replicare un'immagine coerente con l'arresto anomalo in un cluster remoto.
Il valore interno è 64; quello di default è "yes".
20.9 Mappatura di RBD tramite i client kernel meno recenti #
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 7.1 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. Esempio:
cephuser@adm >rbd feature disable pool1/image1 object-mapcephuser@adm >rbd feature disable pool1/image1 exclusive-lockModificare il tipo di compartimento della mappa CRUSH da "straw2" a "straw":
Salvare la mappa CRUSH:
cephuser@adm >ceph osd getcrushmap -o crushmap.originalDecompilare la mappa CRUSH:
cephuser@adm >crushtool -d crushmap.original -o crushmap.txtModificare la mappa CRUSH e sostituire "straw2" con "straw".
Ricompilare la mappa CRUSH:
cephuser@adm >crushtool -c crushmap.txt -o crushmap.newImpostare la nuova mappa CRUSH:
cephuser@adm >ceph osd setcrushmap -i crushmap.new
20.10 Abilitazione dei dispositivi di blocco e di Kubernetes #
È possibile utilizzare i dispositivi di blocco RADOS Ceph con Kubernetes v1.13 e versioni successive tramite il driver ceph-csi, che esegue il provisioning dinamico delle immagini RBD sui volumi Kubernetes sottostanti e la mappatura di tali immagini sotto forma di dispositivi di blocco (facoltativamente montando un file system contenuto all'interno dell'immagine) ai nodi di lavoro su cui sono in esecuzione i pod che fanno riferimento a un volume con supporto RBD.
Per utilizzare i dispositivi di blocco Ceph con Kubernetes, è necessario installare e configurare ceph-csi all'interno dell'ambiente Kubernetes.
ceph-csi utilizza per default i moduli del kernel RBD, che potrebbero non supportare tutti gli elementi ottimizzabili CRUSH di Ceph o le funzioni dell'immagine RBD.
Per default, i dispositivi di blocco Ceph utilizzano il pool RBD. Creare un pool per la memorizzazione del volume Kubernetes. Assicurarsi che il cluster Ceph sia in esecuzione e creare il pool:
cephuser@adm >ceph osd pool create kubernetesUtilizzare lo strumento RBD per inizializzare il pool:
cephuser@adm >rbd pool init kubernetesCreare un nuovo utente per Kubernetes e
ceph-csi. Eseguire quanto riportato di seguito e registrare la chiave generata:cephuser@adm >ceph auth get-or-create client.kubernetes mon 'profile rbd' osd 'profile rbd pool=kubernetes' mgr 'profile rbd pool=kubernetes' [client.kubernetes] key = AQD9o0Fd6hQRChAAt7fMaSZXduT3NWEqylNpmg==Per definire gli indirizzi del Ceph Monitor per il cluster Ceph,
ceph-csinecessita di un oggetto ConfigMap memorizzato in Kubernetes. Raccogliere l'FSID e gli indirizzi del monitor univoci del cluster Ceph:cephuser@adm >ceph mon dump <...> fsid b9127830-b0cc-4e34-aa47-9d1a2e9949a8 <...> 0: [v2:192.168.1.1:3300/0,v1:192.168.1.1:6789/0] mon.a 1: [v2:192.168.1.2:3300/0,v1:192.168.1.2:6789/0] mon.b 2: [v2:192.168.1.3:3300/0,v1:192.168.1.3:6789/0] mon.cGenerare un file
csi-config-map.yamlsimile all'esempio riportato di seguito, sostituendo l'FSID perclusterIDe gli indirizzi dei monitor permonitors:kubectl@adm >cat <<EOF > csi-config-map.yaml --- apiVersion: v1 kind: ConfigMap data: config.json: |- [ { "clusterID": "b9127830-b0cc-4e34-aa47-9d1a2e9949a8", "monitors": [ "192.168.1.1:6789", "192.168.1.2:6789", "192.168.1.3:6789" ] } ] metadata: name: ceph-csi-config EOFQuindi, memorizzare il nuovo oggetto ConfigMap in Kubernetes:
kubectl@adm >kubectl apply -f csi-config-map.yamlPer la comunicazione con il cluster Ceph tramite
ceph-csi, sono necessarie le credenziali cephx. Generare un filecsi-rbd-secret.yamlsimile a quello nell'esempio riportato di seguito utilizzando l'ID utente Kubernetes e la chiave cephx appena creati:kubectl@adm >cat <<EOF > csi-rbd-secret.yaml --- apiVersion: v1 kind: Secret metadata: name: csi-rbd-secret namespace: default stringData: userID: kubernetes userKey: AQD9o0Fd6hQRChAAt7fMaSZXduT3NWEqylNpmg== EOFQuindi, memorizzare il nuovo oggetto segreto in Kubernetes:
kubectl@adm >kubectl apply -f csi-rbd-secret.yamlCreare il ServiceAccount e gli oggetti Kubernetes RBAC ClusterRole/ClusterRoleBinding richiesti. Questi oggetti non devono essere necessariamente personalizzati per il proprio ambiente Kubernetes e pertanto è possibile utilizzarli direttamente dai file YAML di distribuzione di
ceph-csi.kubectl@adm >kubectl apply -f https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-provisioner-rbac.yamlkubectl@adm >kubectl apply -f https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-nodeplugin-rbac.yamlCreare lo strumento di provisioning e i plug-in del nodo
ceph-csi:kubectl@adm >wget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin-provisioner.yamlkubectl@adm >kubectl apply -f csi-rbdplugin-provisioner.yamlkubectl@adm >wget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin.yamlkubectl@adm >kubectl apply -f csi-rbdplugin.yamlImportantePer default, i file YAML dello strumento di provisioning e del plug-in del nodo eseguiranno il pull della release di sviluppo del container
ceph-csi. È necessario aggiornare i file YAML per utilizzare la versione della release.
20.10.1 Uso dei dispositivi di blocco Ceph in Kubernetes #
La StorageClass Kubernetes definisce una classe di storage. È possibile creare più oggetti StorageClass per eseguire la mappatura a diversi livelli di qualità del servizio e funzioni. Si pensi ad esempio ai pool NVMe rispetto a quelli basati su HDD.
Per creare una StorageClass ceph-csi che mappi al pool Kubernetes creato sopra, è possibile utilizzare il file YAML seguente, dopo aver verificato che la proprietà clusterID corrisponda all'FSID del cluster Ceph:
kubectl@adm >cat <<EOF > csi-rbd-sc.yaml --- apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: csi-rbd-sc provisioner: rbd.csi.ceph.com parameters: clusterID: b9127830-b0cc-4e34-aa47-9d1a2e9949a8 pool: kubernetes csi.storage.k8s.io/provisioner-secret-name: csi-rbd-secret csi.storage.k8s.io/provisioner-secret-namespace: default csi.storage.k8s.io/node-stage-secret-name: csi-rbd-secret csi.storage.k8s.io/node-stage-secret-namespace: default reclaimPolicy: Delete mountOptions: - discard EOFkubectl@adm >kubectl apply -f csi-rbd-sc.yaml
Una PersistentVolumeClaim è una richiesta di risorse di memorizzazione astratte effettuata da un utente. La richiesta PersistentVolumeClaim viene quindi associata a una risorsa pod per il provisioning di un PersistentVolume, supportato da un'immagine del dispositivo di blocco Ceph. È possibile includere un valore volumeMode facoltativo per scegliere tra un file system montato (default) o un volume non elaborato basato sul dispositivo di blocco.
Con ceph-csi, specificando Filesystem per volumeMode, verranno supportate sia le richieste ReadWriteOnce che quelle ReadOnlyMany accessMode, mentre specificando Block per volumeMode, verranno supportate le richieste ReadWriteOnce, ReadWriteMany e ReadOnlyMany accessMode.
Ad esempio, per creare una richiesta PersistentVolumeClaim basata su blocchi in cui venga utilizzata la ceph-csi-based StorageClass creata sopra, è possibile usare il file YAML seguente per richiedere la memorizzazione del blocco non elaborato di csi-rbd-sc StorageClass:
kubectl@adm >cat <<EOF > raw-block-pvc.yaml --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: raw-block-pvc spec: accessModes: - ReadWriteOnce volumeMode: Block resources: requests: storage: 1Gi storageClassName: csi-rbd-sc EOFkubectl@adm >kubectl apply -f raw-block-pvc.yaml
Di seguito è riportato un esempio di associazione della richiesta PersistentVolumeClaim descritta sopra a una risorsa pod sotto forma di dispositivo di blocco non elaborato:
kubectl@adm >cat <<EOF > raw-block-pod.yaml --- apiVersion: v1 kind: Pod metadata: name: pod-with-raw-block-volume spec: containers: - name: fc-container image: fedora:26 command: ["/bin/sh", "-c"] args: ["tail -f /dev/null"] volumeDevices: - name: data devicePath: /dev/xvda volumes: - name: data persistentVolumeClaim: claimName: raw-block-pvc EOFkubectl@adm >kubectl apply -f raw-block-pod.yaml
Per creare una richiesta PersistentVolumeClaim basata su file system in cui venga utilizzata la ceph-csi-based StorageClass creata sopra, è possibile utilizzare il file YAML seguente per richiedere un file system montato (supportato da un'immagine RBD) di csi-rbd-sc StorageClass:
kubectl@adm >cat <<EOF > pvc.yaml --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: rbd-pvc spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 1Gi storageClassName: csi-rbd-sc EOFkubectl@adm >kubectl apply -f pvc.yaml
Di seguito è riportato un esempio di associazione della richiesta PersistentVolumeClaim descritta sopra a una risorsa pod sotto forma di file system montato:
kubectl@adm >cat <<EOF > pod.yaml --- apiVersion: v1 kind: Pod metadata: name: csi-rbd-demo-pod spec: containers: - name: web-server image: nginx volumeMounts: - name: mypvc mountPath: /var/lib/www/html volumes: - name: mypvc persistentVolumeClaim: claimName: rbd-pvc readOnly: false EOFkubectl@adm >kubectl apply -f pod.yaml