Saltar al contenutoSaltar alla navigazione delle pagine: pagina precedente [chiave d’accesso p]/pagina successiva [chiave d’accesso n]
Si applica a SUSE Enterprise Storage 6

12 RADOS Block Device

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.

Protocollo RADOS
Figura 12.1: Protocollo RADOS

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.

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

12.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 11, Gestione di pool di memorizzazione):

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

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

cephadm@adm > rbd create --size 1024 mypool/myimage
Suggerimento
Suggerimento: unità di dimensioni immagine

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

12.1.2 Creazione di un'immagine del dispositivo di blocco in un pool con codice di cancellazione

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

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

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

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

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

12.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:

cephadm@adm > rbd ls mypool

12.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:

cephadm@adm > rbd info mypool/myimage

12.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:

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

12.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:

cephadm@adm > rbd rm mypool/myimage

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

  1. 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
  2. Mappare l'immagine nel nuovo dispositivo di blocco.

    cephadm@adm > rbd map --pool mypool myimage
    Suggerimento
    Suggerimento: nome e 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:

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

    Suggerimento
    Suggerimento: percorso di dispositivo RBD

    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
  4. 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
  5. Montare il dispositivo e verificare che sia montato correttamente. Sostituire /mnt con il proprio punto di montaggio.

    root # mount /dev/rbd0 /mnt
    root # 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
    Suggerimento: aumento delle dimensioni del dispositivo RBD

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

    1. 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.
    2. Accrescere il file system in modo da riempire le nuove dimensioni del dispositivo.

      root # xfs_growfs /mnt
       [...]
       data blocks changed from 2097152 to 2560000
  6. Una volta terminato l'accesso al dispositivo, è possibile annullare la mappatura e smontarlo.

    cephadm@adm > rbd unmap /dev/rbd0
    root # unmount /mnt
Suggerimento
Suggerimento: montaggio/smontaggio manuale

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

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

12.2.2 aumento delle dimensioni del dispositivo RBD

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

  1. 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.
  2. Accrescere il file system in modo da riempire le nuove dimensioni del dispositivo.

    root # xfs_growfs /mnt
     [...]
     data blocks changed from 2097152 to 2560000

12.3 Istantanee

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.

Nota
Nota

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.

12.3.1 Note su 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 8, Autenticazione con cephx. È inoltre possibile aggiungere la variabile di ambiente CEPH_ARGS per evitare di immettere di nuovo i seguenti parametri.

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

Ad esempio:

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

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

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

12.3.2.1 Creazione di snapshot

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-name
cephadm@adm > rbd snap create pool-name/image-name@snap-name

Ad esempio:

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

12.3.2.2 Elenchi di snapshot

Per elencare gli snapshot di un'immagine, specificare il nome pool e il nome immagine.

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

Ad esempio:

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

12.3.2.3 Rollback di snapshot

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

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

Ad esempio:

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

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

12.3.2.4 Eliminazione di uno snapshot

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

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

Ad esempio:

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

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

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

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

Ad esempio:

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

12.3.3 Layering

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

Nota
Nota

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

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

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

Nota
Nota: --image-format 1 non supportata

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

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

12.3.3.2 Protezione di uno snapshot

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

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

Ad esempio:

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

Non è possibile eliminare uno snapshot protetto.

12.3.3.3 Clonazione di uno snapshot

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

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

Ad esempio:

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

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

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

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

Ad esempio:

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

12.3.3.5 Elenco degli elementi secondari di uno snapshot

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-name
cephadm@adm > rbd children pool-name/image-name@snapshot-name

Ad esempio:

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

12.3.3.6 Appiattimento di un'immagine clonata

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

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

Ad esempio:

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

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

12.4 Esecuzione di copia speculare

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

Nota
Nota: daemon rbd-mirror

Per utilizzare la copia speculare RBD, è necessario disporre di due cluster Ceph, su ciascuno dei quali è in esecuzione il daemon rbd-mirror.

Importante
Importante: dispositivi di blocco RADOS esportati tramite iSCSI

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.

12.4.1 daemon rbd-mirror

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

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

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

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

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

Suggerimento
Suggerimento: cluster multipli

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

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

image

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 pool
cephadm@adm > rbd --cluster remote mirror pool enable POOL_NAME pool

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

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

12.4.2.3 Aggiunta di un peer del cluster

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@remote
cephadm@adm > rbd --cluster remote mirror pool peer add POOL_NAME client.local@local

12.4.2.4 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):

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

12.4.3 Configurazione dell'immagine

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

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

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

12.4.3.1 Supporto del journaling dell'immagine

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

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

cephadm@adm > rbd --cluster local feature enable POOL_NAME/IMAGE_NAME journaling
Nota
Nota: dipendenza dell'opzione

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

Avviso
Avviso: journaling su tutte le immagini nuove

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

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

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

12.4.3.2 Abilitazione della copia speculare dell'immagine

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

12.4.3.3 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:

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

12.4.3.4 Promozione e abbassamento di livello dell'immagine

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

Nota
Nota: promozione forzata

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

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

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

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

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

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

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

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

cephadm@adm > rbd --cluster local mirror pool promote POOL_NAME
Suggerimento
Suggerimento: suddivisione del carico I/O

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

12.4.3.5 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:

cephadm@adm > rbd mirror image resync POOL_NAME/IMAGE_NAME

12.4.4 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:

cephadm@adm > rbd mirror image status POOL_NAME/IMAGE_NAME

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

cephadm@adm > rbd mirror pool status POOL_NAME
Suggerimento
Suggerimento:

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

12.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, 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".

12.6 Impostazioni QoS

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.

Importante
Importante: non supportate da iSCSI

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.

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

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.

12.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
Nota
Nota: funzioni non supportate da iSCSI

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

12.9 Mappatura di RBD tramite i client del 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 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
Avviso
Avviso: la modifica dei tipi di compartimento della mappa CRUSH causa un significativo ribilanciamento

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.

  1. Disabilitare le funzioni dell'immagine RBD non supportate. Ad esempio:

    cephadm@adm > rbd feature disable pool1/image1 object-map
    cephadm@adm > rbd feature disable pool1/image1 exclusive-lock
  2. Modificare il tipo di compartimento della mappa CRUSH da "straw2" a "straw":

    1. Salvare la mappa CRUSH:

      cephadm@adm > ceph osd getcrushmap -o crushmap.original
    2. Decompilare la mappa CRUSH:

      cephadm@adm > crushtool -d crushmap.original -o crushmap.txt
    3. Modificare la mappa CRUSH e sostituire "straw2" con "straw".

    4. Ricompilare la mappa CRUSH:

      cephadm@adm > crushtool -c crushmap.txt -o crushmap.new
    5. Impostare la nuova mappa CRUSH:

      cephadm@adm > ceph osd setcrushmap -i crushmap.new
Stampa pagina