Determinare i valori bluestore block db size e bluestore block wal size per la distribuzione e aggiungerli al file /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf nel Salt master. I valori devono essere specificati in byte.

[global]
bluestore block db size = 48318382080
bluestore block wal size = 2147483648

Per ulteriori informazioni sulla personalizzazione di ceph.conf, consultare Sezione 1.11, «File ceph.conf personalizzato».

Eseguire DeepSea Stage 3 per distribuire le modifiche:

root@master # salt-run state.orch ceph.stage.3

Verificare che il file ceph.conf sia aggiornato sui relativi nodi OSD:

root@minion > cat /etc/ceph/ceph.conf

Modificare i file *.yml nella directory /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions pertinenti agli OSD che vengono cifrati. Verificare attentamente il percorso con quello definito nel file /srv/pillar/ceph/proposals/policy.cfg per accertare di modificare i file *.yml corretti.

Importante: identificativi di disco lunghi

Quando si identificano i dischi OSD nei file /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions/*.yml, utilizzare identificativi di disco lunghi.

Di seguito viene fornito un esempio di configurazione OSD. Poiché è richiesta la cifratura, tenere presente che le opzioni db_size e wal_size sono eliminate:

ceph:
 storage:
   osds:
     /dev/disk/by-id/scsi-SDELL_PERC_H730_Mini_007027b1065faa972100d34d7aa06d86:
       format: bluestore
       encryption: dmcrypt
       db: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
       wal: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
     /dev/disk/by-id/scsi-SDELL_PERC_H730_Mini_00d146b1065faa972100d34d7aa06d86:
       format: bluestore
       encryption: dmcrypt
       db: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
       wal: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN

Distribuire i nuovi Block Storage OSD con la cifratura eseguendo le fasi 2 e 3 di DeepSea:

root@master # salt-run state.orch ceph.stage.2
root@master # salt-run state.orch ceph.stage.3

È possibile controllare l'avanzamento con ceph -s o ceph osd tree. È fondamentale lasciare ribilanciare il cluster prima di ripetere il processo sul successivo nodo OSD.

Impostare il nuovo ordinamento degli oggetti interni, eseguire:

root # ceph osd set sortbitwise

Suggerimento

Per verificare che il comando sia stato eseguito, si consiglia di eseguire

root # ceph osd dump --format json-pretty | grep sortbitwise
 "flags": "sortbitwise,recovery_deletes,purged_snapdirs",

Con rpm -q deepsea, verificare che la versione del pacchetto DeepSea sul nodo Salt master inizi almeno con 0.7. Ad esempio:

root # rpm -q deepsea
deepsea-0.7.27+git.0.274c55d-5.1

Se il numero di versione del pacchetto DeepSea inizia con 0.6, verificare di aver eseguito correttamente la migrazione del nodo Salt master a SUSE Linux Enterprise Server 12 SP3 e SUSE Enterprise Storage 5 (consultare Importante: requisiti del software all'inizio di questa sezione). Si tratta di un prerequisito da completare prima di avviare la procedura di upgrade.

1. Se i sistemi sono stati registrati con SUSEConnect e si utilizza SCC/SMT, non sono richieste ulteriori azioni. Continuare con Passo 4.

2. Se non si utilizza SCC/SMT ma un Media-ISO o altra sorgente del pacchetto, aggiungere i seguenti repository manualmente: SLE12-SP3 Base, SLE12-SP3 Update, SES5 Base e SES5 Update. Per questo scopo, è possibile utilizzare il comando zypper. Rimuovere prima tutti i repository software esistenti, quindi aggiungere quelli nuovi richiesti e infine aggiornare le sorgenti dei repository:

   root # zypper sd {0..99}
   root # zypper ar \
    http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOL
   root # zypper ar \
    http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATES
   root # zypper ar \
    http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOL
   root # zypper ar \
    http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATES
   root # zypper ref

   Cambiare quindi i dati di Pillar per utilizzare una diversa strategia. Modificare

   /srv/pillar/ceph/stack/name_of_cluster/cluster.yml

   e aggiungere la riga seguente:

   upgrade_init: zypper-dup

   

   Suggerimento

   La strategia zypper-dup richiede di aggiungere manualmente i repository software più recenti, mentre zypper-migration di default si basa sui repository forniti da SCC/SMT.

Aggiornare il Pillar:

root@master # salt target saltutil.sync_all

Per informazioni sull'indirizzamento dei Salt minion, vedere Sezione 4.2.2, «Indirizzamento dei minion».

Verificare che la scrittura su Pillar sia riuscita:

root@master # salt target pillar.get upgrade_init

Il risultato del comando dovrebbe rispecchiare la voce aggiunta.

Eseguire l'upgrade dei Salt minion:

root@master # salt target state.apply ceph.updates.salt

Verificare che sia stato eseguito l'upgrade di tutti i Salt minion:

root@master # salt target test.version

Includere i Salt minion del cluster. Per ulteriori dettagli, fare riferimento a Sezione 4.2.2, «Indirizzamento dei minion» di Procedura 4.1, «Esecuzione delle fasi di distribuzione».

Avviare l'upgrade di SUSE Linux Enterprise Server e Ceph:

root@master # salt-run state.orch ceph.maintenance.upgrade

Suggerimento: rieseguire all'avvio

Se il processo determina il riavvio del Salt master, rieseguire il comando per avviare il processo di upgrade per i Salt minion.

Verificare che dopo l'upgrade, AppArmor sia disattivato e arrestato su tutti i nodi:

root # systemctl disable apparmor.service
systemctl stop apparmor.service

Dopo l'upgrade, i Ceph Manager non sono ancora installati. Per ottenere uno stato migliore del cluster, attenersi a questa procedura:

1. Eseguire la Fase 0 per attivare l'API REST Salt:

   root@master # salt-run state.orch ceph.stage.0

2. Eseguire la Fase 1 per creare la sottodirectory role-mgr/:

   root@master # salt-run state.orch ceph.stage.1

3. Modificare policy.cfg come descritto in Sezione 4.5.1, «Il file policy.cfg» e aggiungere un ruolo Ceph Manager dove sono distribuiti i Ceph Monitor. Inoltre, aggiungere il ruolo openATTIC a uno dei nodi cluster. Per ulteriori dettagli, fare riferimento a Capitolo 15, openATTIC.

4. Eseguire la Fase 2 per aggiornare il Pillar:

   root@master # salt-run state.orch ceph.stage.2

5. DeepSea utilizza un diverso approccio per generare ora il file di configurazione ceph.conf, per ulteriori informazioni, consultare Sezione 1.11, «File ceph.conf personalizzato».

6. Per distribuire i Ceph Manager, eseguire la Fase 3:

   root@master # salt-run state.orch ceph.stage.3

7. Per configurare correttamente openATTIC, eseguire la Fase 4:

   root@master # salt-run state.orch ceph.stage.4

Nota: errata corrispondenza capacità chiave Ceph

Se si verifica un errore di ceph.stage.3 con "Error EINVAL: entity client.bootstrap-osd exists but caps do not match", le capacità (cap) chiave per la chiave esistente client.bootstrap.osd del cluster non corrispondono alle cap che DeepSea sta cercando di impostare. Sopra il messaggio di errore, in testo rosso, è possibile vedere un dump del comando ceph auth non riuscito. Osservare il comando per verificare il file e ID chiave in uso. In caso di client.bootstrap-osd, il comando sarà

root # ceph auth add client.bootstrap-osd \
 -i /srv/salt/ceph/osd/cache/bootstrap.keyring

Per risolvere le cap chiave non corrispondenti, controllare il contenuto del file portachiavi che DeepSea cerca di distribuire, ad esempio:

cephadm > cat /srv/salt/ceph/osd/cache/bootstrap.keyring
[client.bootstrap-osd]
     key = AQD6BpVZgqVwHBAAQerW3atANeQhia8m5xaigw==
     caps mgr = "allow r"
     caps mon = "allow profile bootstrap-osd"

Confrontarlo con il risultato di ceph auth get client.bootstrap-osd:

root # ceph auth get client.bootstrap-osd
exported keyring for client.bootstrap-osd
[client.bootstrap-osd]
     key = AQD6BpVZgqVwHBAAQerW3atANeQhia8m5xaigw==
     caps mon = "allow profile bootstrap-osd"

Notare nell'ultima chiave la mancanza di caps mgr = "allow r". Per risolvere, eseguire:

root # ceph auth caps client.bootstrap-osd mgr \
 "allow r" mon "allow profile bootstrap-osd"

L'esecuzione di ceph.stage.3 dovrebbe ora riuscire.

Lo stesso problema può verificarsi con i portachiavi di Metadata Server e Object Gateway quando si esegue ceph.stage.4. Applicare la stessa procedura precedente: verificare il comando non riuscito, il file portachiavi distribuito e le cap della chiave esistente. Eseguire quindi ceph auth caps per aggiornare le cap della chiave esistenti in modo che corrispondano a quanto viene distribuito da DeepSea.

Installare il pacchetto salt da SLE-12-SP2/SES4:

root # zypper install salt

Installare il pacchetto salt-minion da SLE-12-SP2/SES4, quindi attivare e avviare il servizio correlato:

root # zypper install salt-minion
root # systemctl enable salt-minion
root # systemctl start salt-minion

Accertare che il nome host "salt" si risolva nell'indirizzo IP del nodo Salt master. Se il Salt master non è raggiungibile dal nome host salt, modificare il file /etc/salt/minion oppure creare un nuovo file /etc/salt/minion.d/master.conf con il seguente contenuto:

master: host_name_of_salt_master

Suggerimento

Nei Salt minion esistenti l'opzione master: è già impostata in /etc/salt/minion.d/calamari.conf. Il nome del file di configurazione è ininfluente, la directory /etc/salt/minion.d/ è importante.

Se sono state apportate modifiche ai file di configurazione menzionati sopra, riavviare il servizio Salt su tutti i Salt minion:

root@minion > systemctl restart salt-minion.service

1. Se i sistemi sono stati registrati con SUSEConnect e si utilizza SCC/SMT, non sono richieste ulteriori azioni.

2. Se non si utilizza SCC/SMT ma un Media-ISO o altra sorgente del pacchetto, aggiungere i seguenti repository manualmente: SLE12-SP3 Base, SLE12-SP3 Update, SES5 Base e SES5 Update. Per questo scopo, è possibile utilizzare il comando zypper. Rimuovere prima tutti i repository software esistenti, quindi aggiungere quelli nuovi richiesti e infine aggiornare le sorgenti dei repository:

   root # zypper sd {0..99}
   root # zypper ar \
    http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOL
   root # zypper ar \
    http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATES
   root # zypper ar \
    http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOL
   root # zypper ar \
    http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATES
   root # zypper ref

Impostare il nuovo ordinamento degli oggetti interni, eseguire:

root@master # ceph osd set sortbitwise

Suggerimento

Per verificare che il comando sia stato eseguito, si consiglia di eseguire

root@master # ceph osd dump --format json-pretty | grep sortbitwise
 "flags": "sortbitwise,recovery_deletes,purged_snapdirs",

Eseguire l'upgrade del nodo Salt master a SUSE Linux Enterprise Server 12 SP3 e SUSE Enterprise Storage 5. Per i sistemi con registrazione SCC, utilizzare zypper migration. Se i repository software richiesti sono forniti manualmente, utilizzare zypper dup. Dopo l'upgrade, verificare che solo i repository per SUSE Linux Enterprise Server 12 SP3 e SUSE Enterprise Storage 5 siano attivi (e aggiornati) sul nodo Salt master prima di continuare.

Se non è già presente, installare il pacchetto salt-package, quindi attivare e avviare il servizio correlato:

root@master # zypper install salt-master
root@master # systemctl enable salt-master
root@master # systemctl start salt-master

Verificare la presenza di tutti i Salt minion elencandone le chiavi:

root@master # salt-key -L

Aggiungere tutte le chiavi dei Salt minion al Salt master compreso il minion master:

root@master # salt-key -A -y

Verificare che tutte le chiavi dei Salt minion siano state accettate:

root@master # salt-key -L

Verificare che il software sul nodo Salt master sia aggiornato:

root@master # zypper migration

Installare il pacchetto deepsea:

root@master # zypper install deepsea

Includere i Salt minion del cluster. Per ulteriori dettagli, fare riferimento a Sezione 4.2.2, «Indirizzamento dei minion» di Procedura 4.1, «Esecuzione delle fasi di distribuzione».

Importare il cluster installato ceph-deploy esistente:

root@master # salt-run populate.engulf_existing_cluster

Il comando esegue quanto indicato di seguito:

Il comando salt-run populate.engulf_existing_cluster non gestisce l'importazione della configurazione openATTIC. È necessario modificare manualmente il file policy.cfg e aggiungere una riga role-openattic. Per ulteriori dettagli, fare riferimento a Sezione 4.5.1, «Il file policy.cfg».

Il comando salt-run populate.engulf_existing_cluster non gestisce l'importazione delle configurazioni dei Gateway iSCSI. Se il cluster comprende iSCSI Gateway, importarne manualmente le configurazioni:

1. Su uno dei nodi iSCSI Gateway, esportare il lrbd.conf corrente e copiarlo nel nodo Salt master:

   root@minion > lrbd -o >/tmp/lrbd.conf
   root@minion > scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf

2. Sul nodo Salt master, aggiungere la configurazione iSCSI Gateway predefinita alla configurazione di DeepSea:

   root@master # mkdir -p /srv/pillar/ceph/stack/ceph/
   root@master # echo 'igw_config: default-ui' >> /srv/pillar/ceph/stack/ceph/cluster.yml
   root@master # chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml

3. Aggiungere i ruoli iSCSI Gateway a policy.cfg e salvare il file:

   role-igw/stack/default/ceph/minions/ses-1.ses.suse.yml
   role-igw/cluster/ses-1.ses.suse.sls
   [...]

Eseguire la Fase 1 per creare tutti i ruoli possibili:

root@master # salt-run state.orch ceph.stage.1

Generare le sottodirectory richieste in /srv/pillar/ceph/stack:

root@master # salt-run push.proposal

Verificare che sia presente un cluster operativo gestito da DeepSea con i ruoli assegnati correttamente:

root@master # salt target pillar.get roles

Confrontare il risultato con il layout effettivo del cluster.

Calamari lascia un lavoro Salt pianificato in esecuzione per controllare lo stato del cluster. Rimuovere il lavoro:

root@minion > salt target schedule.delete ceph.heartbeat

Da questo punto in avanti, seguire la procedura descritta in Sezione 5.4, «Eseguire l'upgrade da SUSE Enterprise Storage 4 (distribuzione DeepSea) a 5».

Per ciascun nodo Ceph (compreso il nodo Calamari), arrestare e disabilitare tutti i servizi relativi a Crowbar:

root@minion > sudo systemctl stop chef-client
root@minion > sudo systemctl disable chef-client
root@minion > sudo systemctl disable crowbar_join
root@minion > sudo systemctl disable crowbar_notify_shutdown

Per ciascun nodo Ceph (compreso il nodo Calamari), verificare che i repository software puntino ai prodotti SUSE Enterprise Storage 5 e SUSE Linux Enterprise Server 12 SP3. Se sono ancora presenti repository che puntano a versioni dei prodotti precedenti, disabilitarli.

Per ciascun nodo Ceph (compreso il nodo Calamari), verificare che salt-minion sia installato. In caso contrario, installarlo:

root@minion > sudo zypper in salt salt-minion

Per i nodi Ceph che non hanno il pacchetto salt-minion installato, creare il file /etc/salt/minion.d/master.conf con l'opzione master che punta al nome host del nodo Calamari completo:

master: full_calamari_hostname

Suggerimento

Nei Salt minion esistenti l'opzione master: è già impostata in /etc/salt/minion.d/calamari.conf. Il nome del file di configurazione è ininfluente, è importante la directory /etc/salt/minion.d/.

Abilitare e avviare il servizio salt-minion:

root@minion > sudo systemctl enable salt-minion
root@minion > sudo systemctl start salt-minion

Nel nodo Calamari, accettare eventuali chiavi salt minion rimanenti:

root@master # salt-key -L
[...]
Unaccepted Keys:
d52-54-00-16-45-0a.example.com
d52-54-00-70-ac-30.example.com
[...]

root@master # salt-key -A
The following keys are going to be accepted:
Unaccepted Keys:
d52-54-00-16-45-0a.example.com
d52-54-00-70-ac-30.example.com
Proceed? [n/Y] y
Key for minion d52-54-00-16-45-0a.example.com accepted.
Key for minion d52-54-00-70-ac-30.example.com accepted.

Se Ceph è stato installato sulla rete pubblica ma non è presente alcuna interfaccia VLAN, aggiungere al nodo Calamari un'interfaccia (VLAN) sulla rete pubblica di Crowbar.

Eseguire l'upgrade del nodo Calamari a SUSE Linux Enterprise Server 12 SP3 e SUSE Enterprise Storage 5, utilizzando zypper migration o il metodo prescelto. Da questo punto in avanti, il nodo Calamari diventa il Salt master. Dopo l'upgrade, riavviare il Salt master.

Installare DeepSea sul Salt master:

root@master # zypper in deepsea

Specificare l'opzione deepsea_minions per includere il gruppo corretto di Salt minion nelle fasi di distribuzione. Per ulteriori dettagli, fare riferimento a Sezione 4.2.2.3, «Impostare l'opzione deepsea_minions».

DeepSea si aspetta che tutti i nodi Ceph abbiano un identico /etc/ceph/ceph.conf. Crowbar distribuisce un ceph.conf leggermente diverso su ciascun nodo, quindi occorre consolidarli:

Se si stava eseguendo l'Object Gateway, Crowbar ha distribuito un file /etc/ceph/ceph.conf.radosgw separato per mantenere i segreti keystone separati dal file ceph.conf standard. Crowbar aggiunge anche un file /etc/systemd/system/ceph-radosgw@.service personalizzato. Poiché DeepSea non lo supporta, occorre rimuoverlo:

Verificare che ceph status funzioni quando eseguito dal Salt master:

root@master # ceph status
cluster a705580c-a7ae-4fae-815c-5cb9c1ded6c2
health HEALTH_OK
[...]

Importare il cluster esistente:

root@master # salt-run populate.engulf_existing_cluster
root@master # salt-run state.orch ceph.stage.1
root@master # salt-run push.proposal

Il comando salt-run populate.engulf_existing_cluster non gestisce l'importazione delle configurazioni dei Gateway iSCSI. Se il cluster comprende iSCSI Gateway, importarne manualmente le configurazioni:

1. Su uno dei nodi iSCSI Gateway, esportare il lrbd.conf corrente e copiarlo nel nodo Salt master:

   root@minion > lrbd -o > /tmp/lrbd.conf
   root@minion > scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf

2. Sul nodo Salt master, aggiungere la configurazione iSCSI Gateway predefinita alla configurazione di DeepSea:

   root@master # mkdir -p /srv/pillar/ceph/stack/ceph/
   root@master # echo 'igw_config: default-ui' >> /srv/pillar/ceph/stack/ceph/cluster.yml
   root@master # chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml

3. Aggiungere i ruoli iSCSI Gateway a policy.cfg e salvare il file:

   role-igw/stack/default/ceph/minions/ses-1.ses.suse.yml
   role-igw/cluster/ses-1.ses.suse.sls
   [...]

1. Se i sistemi sono stati registrati con SUSEConnect e si utilizza SCC/SMT, non sono richieste ulteriori azioni.

2. Se non si utilizza SCC/SMT ma un Media-ISO o altra sorgente del pacchetto, aggiungere i seguenti repository manualmente: SLE12-SP3 Base, SLE12-SP3 Update, SES5 Base e SES5 Update. Per questo scopo, è possibile utilizzare il comando zypper. Rimuovere prima tutti i repository software esistenti, quindi aggiungere quelli nuovi richiesti e infine aggiornare le sorgenti dei repository:

   root # zypper sd {0..99}
   root # zypper ar \
    http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOL
   root # zypper ar \
    http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATES
   root # zypper ar \
    http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOL
   root # zypper ar \
    http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATES
   root # zypper ref

   Cambiare quindi i dati di Pillar per utilizzare una diversa strategia. Modificare

   /srv/pillar/ceph/stack/name_of_cluster/cluster.yml

   e aggiungere la riga seguente:

   upgrade_init: zypper-dup

   

   Suggerimento

   La strategia zypper-dup richiede di aggiungere manualmente i repository software più recenti, mentre zypper-migration di default si basa sui repository forniti da SCC/SMT.

Modificare i "grain" (piccoli elementi di dati) host affinché DeepSea utilizzi nomi host brevi sulla rete pubblica per gli ID istanza del daemon Ceph. Per ciascun nodo, occorre eseguire grains.set con il nuovo nome (breve) host. Prima di eseguire grains.set, verificare le istanze del monitor corrente eseguendo ceph status. Viene fornito un esempio per "prima" e "dopo":

root@master # salt target grains.get host
d52-54-00-16-45-0a.example.com:
    d52-54-00-16-45-0a
d52-54-00-49-17-2a.example.com:
    d52-54-00-49-17-2a
d52-54-00-76-21-bc.example.com:
    d52-54-00-76-21-bc
d52-54-00-70-ac-30.example.com:
    d52-54-00-70-ac-30

root@master # salt d52-54-00-16-45-0a.example.com grains.set \
 host public.d52-54-00-16-45-0a
root@master # salt d52-54-00-49-17-2a.example.com grains.set \
 host public.d52-54-00-49-17-2a
root@master # salt d52-54-00-76-21-bc.example.com grains.set \
 host public.d52-54-00-76-21-bc
root@master # salt d52-54-00-70-ac-30.example.com grains.set \
 host public.d52-54-00-70-ac-30

root@master # salt target grains.get host
d52-54-00-76-21-bc.example.com:
    public.d52-54-00-76-21-bc
d52-54-00-16-45-0a.example.com:
    public.d52-54-00-16-45-0a
d52-54-00-49-17-2a.example.com:
    public.d52-54-00-49-17-2a
d52-54-00-70-ac-30.example.com:
    public.d52-54-00-70-ac-30

Eseguire l'upgrade:

root@master # salt target state.apply ceph.updates
root@master # salt target test.version
root@master # salt-run state.orch ceph.maintenance.upgrade

Ogni nodo si riavvia. Il cluster si riattiva rilevando l'assenza dell'istanza attiva di Ceph Manager. Questa situazione è normale. A questo punto, Calamari non deve essere più installato/in esecuzione.

Eseguire tutte le fasi di distribuzione richieste per portare il cluster a uno stato funzionale:

root@master # salt-run state.orch ceph.stage.0
root@master # salt-run state.orch ceph.stage.1
root@master # salt-run state.orch ceph.stage.2
root@master # salt-run state.orch ceph.stage.3

Per distribuire openATTIC (vedere Capitolo 15, openATTIC), aggiungere una riga role-openattic (vedere Sezione 4.5.1.2, «Assegnazione ruolo») appropriata a /srv/pillar/ceph/proposals/policy.cfg, quindi eseguire:

root@master # salt-run state.orch ceph.stage.2
root@master # salt-run state.orch ceph.stage.4

Durante l'upgrade, è possibile ricevere errori come/del tipo "Error EINVAL: entity [...] exists but caps do not match". Per risolverli, consultare Sezione 5.4, «Eseguire l'upgrade da SUSE Enterprise Storage 4 (distribuzione DeepSea) a 5».

Eseguire la pulizia rimanente: