Si applica a SUSE Enterprise Storage 7.1

10 Upgrade da SUSE Enterprise Storage 6 a 7.1 #

Questo capitolo descrive le procedure per eseguire l'upgrade di SUSE Enterprise Storage 6 alla versione 7.1.

L'upgrade include i task seguenti:

Esecuzione dell'upgrade da Ceph Nautilus a Pacific.
Passaggio dall'installazione ed esecuzione di Ceph tramite pacchetti RPM all'esecuzione in container.
Rimozione completa di DeepSea e sostituzione con ceph-salt e cephadm.

Avvertimento

Le informazioni sull'upgrade contenute in questo capitolo si applicano soltanto agli upgrade da DeepSea a cephadm. Non seguire queste istruzioni se si desidera distribuire SUSE Enterprise Storage sulla piattaforma SUSE CaaS.

Importante

L'upgrade dalle versioni di SUSE Enterprise Storage precedenti alla 6 non è supportato. Innanzitutto, è necessario eseguire l'upgrade alla versione più recente di SUSE Enterprise Storage 6, quindi seguire le procedure descritte in questo capitolo.

10.1 Attività preparatorie all'upgrade #

Prima di avviare l'upgrade, occorre completare i task seguenti. È possibile eseguire l'upgrade da SUSE Enterprise Storage 6 in qualsiasi momento.

La migrazione dell'OSD da FileStore a BlueStore deve avvenire prima dell'aggiornamento poiché FileStore non è supportato in SUSE Enterprise Storage 7.1. Ulteriori dettagli su BlueStore e su come migrare da FileStore sono disponibili all'indirizzo https://documentation.suse.com/ses/6/single-html/ses-deployment/#filestore2bluestore.
Se è in esecuzione una versione precedente del cluster in cui sono ancora utilizzati OSD ceph-disk, è necessario passare a ceph-volume prima dell'upgrade. Ulteriori dettagli sono disponibili in https://documentation.suse.com/ses/6/single-html/ses-deployment/#upgrade-osd-deployment.

10.1.1 Aspetti da considerare #

Prima di eseguire l'upgrade, leggere per intero le sezioni seguenti per comprendere tutti i task che devono essere completati.

Lettura delle note di rilascio. Nelle note, è possibile trovare informazioni aggiuntive sulle modifiche apportate rispetto alla release precedente di SUSE Enterprise Storage. Controllare le note di rilascio per vedere se:
- l'hardware necessita di considerazioni speciali;
- i pacchetti software utilizzati hanno subito modifiche significative;
- è necessario adottare precauzioni speciali per l'installazione.
Le note di rilascio forniscono inoltre informazioni che non si è fatto in tempo a riportare nel manuale. Contengono anche alcune note su problemi noti.
All'indirizzo https://www.suse.com/releasenotes/ è possibile trovare le note di rilascio di SES 7.1.
Inoltre, dopo aver installato il pacchetto release-notes-ses dall'archivio di SES 7.1, individuare localmente le note di rilascio nella directory /usr/share/doc/release-notes oppure online all'indirizzo https://www.suse.com/releasenotes/.
Leggere la Parte II, «Distribuzione del cluster Ceph» per acquisire dimestichezza con ceph-salt e con l'utilità di coordinamento Ceph, in particolare con le informazioni sulle specifiche del servizio.
L'upgrade del cluster può richiedere diverso tempo, circa lo stesso necessario per eseguire l'upgrade di un computer moltiplicato per il numero di nodi del cluster.
Eseguire innanzitutto l'upgrade del Salt Master, quindi sostituire DeepSea con ceph-salt e cephadm. Finché non sarà stato completato l'upgrade di almeno tutti i nodi di Ceph Manager, non sarà possibile iniziare a utilizzare il modulo dell'utilità di coordinamento cephadm.
L'aggiornamento dall'utilizzo degli RPM di Nautilus all'utilizzo dei container di Pacific deve avvenire in un unico passaggio. Pertanto, occorre eseguire l'upgrade di un intero nodo alla volta, e non di un daemon alla volta.
I servizi di base (MON, MGR, OSD) vengono aggiornati per ordine e rimangono disponibili durante l'upgrade. Al termine dell'operazione, occorre ripetere la distribuzione dei servizi del gateway (Metadata Server, Object Gateway, NFS Ganesha, iSCSI Gateway). Ciascuno dei servizi riportati di seguito subirà un tempo di fermo:
- Importante
  I Metadata Server e gli Object Gateway sono disattivi dall'inizio dell'upgrade dei nodi da SUSE Linux Enterprise Server 15 SP1 a SUSE Linux Enterprise Server 15 SP3 fino alla ridistribuzione dei servizi al termine della procedura di upgrade. È un aspetto particolarmente importante da tenere presente se questi servizi sono in co-location con MON, MGR oppure OSD, poiché potrebbero essere inattivi per tutta la durata dell'upgrade del cluster. Se questo rappresenta un problema, valutare di distribuire separatamente tali servizi su nodi aggiuntivi prima di procedere con l'upgrade, in modo che rimangano inattivi per il minor tempo possibile, ovvero per la durata dell'upgrade dei nodi del gateway, e non dell'intero cluster.
- NFS Ganesha e gli iSCSI Gateway sono inattivi solo per il riavvio dei nodi durante l'upgrade da SUSE Linux Enterprise Server 15 SP1 a SUSE Linux Enterprise Server 15 SP3 e nuovamente per breve tempo durante la ridistribuzione di ciascun servizio nella modalità in container.

10.1.2 Backup della configurazione e dei dati del cluster #

Si consiglia vivamente di eseguire il backup completo della configurazione e dei dati del cluster prima di avviare l'upgrade a SUSE Enterprise Storage 7.1. Per istruzioni su come eseguire il backup di tutti i dati, vedere https://documentation.suse.com/ses/6/single-html/ses-admin/#cha-deployment-backup.

10.1.3 Verifica dei passaggi dell'upgrade precedente #

Se in precedenza è stato eseguito l'upgrade dalla versione 5, verificare che l'upgrade alla versione 6 sia stato completato correttamente:

Controllare se il file /srv/salt/ceph/configuration/files/ceph.conf.import è presente.

Questo file è creato dal processo engulf durante l'upgrade da SUSE Enterprise Storage 5 a 6. L'opzione configuration_init: default-import è impostata in /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml.

Se l'opzione configuration_init è ancora impostata su default-import, come file di configurazione il cluster utilizza ceph.conf.import e non la configurazione ceph.conf di default di DeepSea, compilata dai file in /srv/salt/ceph/configuration/files/ceph.conf.d/.

Pertanto, è necessario analizzare ceph.conf.import per rilevare eventuali configurazioni personalizzate e possibilmente spostare la configurazione in uno dei file in /srv/salt/ceph/configuration/files/ceph.conf.d/.

Quindi, rimuovere la riga configuration_init: default-import da /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml.

10.1.4 Aggiornamento dei nodi del cluster e verifica dell'integrità del cluster #

Verificare che tutti gli ultimi aggiornamenti di SUSE Linux Enterprise Server 15 SP1 e SUSE Enterprise Storage 6 siano stati applicati a tutti i nodi del cluster:

# zypper refresh && zypper patch

Suggerimento

Per informazioni dettagliate sull'aggiornamento dei nodi del cluster, fare riferimento a https://documentation.suse.com/ses/6/html/ses-all/storage-salt-cluster.html#deepsea-rolling-updates.

Dopo aver applicato gli aggiornamenti, riavviare il Salt Master, sincronizzare i nuovi moduli Salt e controllare l'integrità del cluster:

root@master # systemctl restart salt-master.service
root@master # salt '*' saltutil.sync_all
cephuser@adm > ceph -s

10.1.4.1 Disabilitazione dei client non sicuri #

Dalla versione v14.2.20 di Nautilus, è stato introdotto un nuovo avviso sullo stato di integrità che informa che i client non sicuri possono unirsi al cluster. Per default, questo avviso è attivo. Il Ceph Dashboard mostrerà il cluster nello stato HEALTH_WARN. La riga di comando verifica lo stato del cluster nel modo seguente:

 cephuser@adm > ceph status
 cluster:
   id:     3fe8b35a-689f-4970-819d-0e6b11f6707c
   health: HEALTH_WARN
   mons are allowing insecure global_id reclaim
 [...]

L'avviso indica che i Ceph Monitor stanno ancora consentendo ai client meno recenti, e privi di patch, di connettersi al cluster. Questo assicura la possibilità di connessione dei client esistenti durante l'upgrade del cluster, ma segnala la presenza di un problema che deve essere risolto. Dopo aver completato l'upgrade del cluster e di tutti i client all'ultima versione di Ceph, disattivare i client privi di patch mediante il seguente comando:

cephuser@adm > ceph config set mon auth_allow_insecure_global_id_reclaim false

10.1.5 Verifica dell'accesso agli archivi software e alle immagini del container #

Verificare che ogni nodo del cluster disponga dell'accesso agli archivi software di SUSE Linux Enterprise Server 15 SP3 e SUSE Enterprise Storage 7.1, oltre che al registro delle immagini del container.

10.1.5.1 Archivi software #

Se tutti i nodi sono registrati su SCC, sarà possibile eseguire l'upgrade con il comando zypper migration. Per ulteriori dettagli, fare riferimento a https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-upgrade-online.html#sec-upgrade-online-zypper.

Se i nodi non sono registrati su SCC, disabilitare tutti gli archivi software esistenti e aggiungere gli archivi Pool e Updates per ciascuna delle estensioni seguenti:

SLE-Product-SLES/15-SP3
SLE-Module-Basesystem/15-SP3
SLE-Module-Server-Applications/15-SP3
SUSE-Enterprise-Storage-7.1

10.1.5.2 Immagini del container #

Tutti i nodi del cluster necessitano dell'accesso al registro delle immagini del container. Nella maggior parte dei casi, viene utilizzato il registro SUSE pubblico all'indirizzo registry.suse.com. Sono necessarie le immagini seguenti:

registry.suse.com/ses/7.1/ceph/ceph
registry.suse.com/ses/7.1/ceph/grafana
registry.suse.com/ses/7.1/ceph/prometheus-server
registry.suse.com/ses/7.1/ceph/prometheus-node-exporter
registry.suse.com/ses/7.1/ceph/prometheus-alertmanager

In alternativa, ad esempio per le distribuzioni Air-gap, configurare un registro locale e verificare di disporre dell'insieme di immagini del container corretto. Fare riferimento alla Sezione 7.2.10, «Utilizzo del registro del container» per ulteriori dettagli sulla configurazione di un registro delle immagini del container locale.

10.2 Esecuzione dell'upgrade del Salt Master #

Di seguito è descritta la procedura di upgrade del Salt Master:

Eseguire l'upgrade del sistema operativo sottostante a SUSE Linux Enterprise Server 15 SP3:
- Per i cluster con i nodi registrati su SCC, eseguire zypper migration.
- Per i cluster i cui nodi dispongono di archivi software assegnati manualmente, eseguire zypper dup seguito da reboot.

Disabilitare le fasi di DeepSea per evitare usi accidentali. Aggiungere il contenuto seguente a /srv/pillar/ceph/stack/global.yml:

stage_prep: disabled
stage_discovery: disabled
stage_configure: disabled
stage_deploy: disabled
stage_services: disabled
stage_remove: disabled

Salvare il file e applicare le modifiche:

root@master # salt '*' saltutil.pillar_refresh

Se le immagini del container in uso non provengono da registry.suse.com, ma dal registro configurato in locale, modificare /srv/pillar/ceph/stack/global.yml per comunicare a DeepSea quale immagine del container e registro Ceph utilizzare. Ad esempio, per utilizzare 192.168.121.1:5000/my/ceph/image aggiungere le righe seguenti:
```
ses7_container_image: 192.168.121.1:5000/my/ceph/image
ses7_container_registries:
  - location: 192.168.121.1:5000
```
Se è necessario specificare le informazioni di autenticazione per il registro, aggiungere il blocco ses7_container_registry_auth:; ad esempio:
```
ses7_container_image: 192.168.121.1:5000/my/ceph/image
ses7_container_registries:
  - location: 192.168.121.1:5000
ses7_container_registry_auth:
  registry: 192.168.121.1:5000
  username: USER_NAME
  password: PASSWORD
```
Salvare il file e applicare le modifiche:
```
root@master # salt '*' saltutil.refresh_pillar
```

Assimilare la configurazione esistente:

cephuser@adm > ceph config assimilate-conf -i /etc/ceph/ceph.conf

Verificare lo stato dell'upgrade. L'output potrebbe essere diverso a seconda della configurazione del cluster:

root@master # salt-run upgrade.status
The newest installed software versions are:
 ceph: ceph version 16.2.7-640-gceb23c7491b (ceb23c7491bd96ab7956111374219a4cdcf6f8f4) pacific (stable)
 os: SUSE Linux Enterprise Server 15 SP3

Nodes running these software versions:
 admin.ceph (assigned roles: master, prometheus, grafana)

Nodes running older software versions must be upgraded in the following order:
 1: mon1.ceph (assigned roles: admin, mon, mgr)
 2: mon2.ceph (assigned roles: admin, mon, mgr)
 3: mon3.ceph (assigned roles: admin, mon, mgr)
 4: data4.ceph (assigned roles: storage, mds)
 5: data1.ceph (assigned roles: storage)
 6: data2.ceph (assigned roles: storage)
 7: data3.ceph (assigned roles: storage)
 8: data5.ceph (assigned roles: storage, rgw)

10.3 Esecuzione dell'upgrade dei nodi MON, MGR e OSD #

Eseguire l'upgrade dei nodi Ceph Monitor, Ceph Manager e OSD uno alla volta. Per ogni servizio, seguire la procedura indicata di seguito:

Prima di adottare eventuali nodi OSD, effettuare una conversione di formato dei nodi OSD per migliorare la gestione dei dati OMAP. A tale scopo, eseguire il seguente comando sul nodo admin:
```
cephuser@adm > ceph config set osd bluestore_fsck_quick_fix_on_mount true
```
I nodi OSD verranno convertiti automaticamente al termine della relativa adozione.
Nota
La conversione può richiedere un tempo variabile da minuti a ore, a seconda della quantità di dati OMAP contenuti nel relativo disco rigido. Per ulteriori informazioni, fare riferimento al https://docs.ceph.com/en/latest/releases/pacific/#upgrading-non-cephadm-clusters.

Durante l'upgrade di un nodo OSD, fare in modo che l'OSD non sia contrassegnato con out eseguendo il comando seguente:

cephuser@adm > ceph osd add-noout SHORT_NODE_NAME

Sostituire SHORT_NODE_NAME con il nome abbreviato del nodo così come viene visualizzato nell'output del comando ceph osd tree. Nell'input seguente, i nomi host abbreviati sono ses-min1 e ses-min2.

root@master # ceph osd tree
ID   CLASS  WEIGHT   TYPE NAME       STATUS  REWEIGHT  PRI-AFF
 -1         0.60405  root default
-11         0.11691      host ses-min1
  4    hdd  0.01949          osd.4       up   1.00000  1.00000
  9    hdd  0.01949          osd.9       up   1.00000  1.00000
 13    hdd  0.01949          osd.13      up   1.00000  1.00000
[...]
 -5         0.11691      host ses-min2
  2    hdd  0.01949          osd.2       up   1.00000  1.00000
  5    hdd  0.01949          osd.5       up   1.00000  1.00000
[...]

Eseguire l'upgrade del sistema operativo sottostante a SUSE Linux Enterprise Server 15 SP3:
- Se tutti i nodi del cluster sono registrati su SCC, eseguire zypper migration.
- Se i nodi del cluster dispongono di archivi software assegnati manualmente, eseguire zypper dup seguito da reboot.
In seguito al riavvio del nodo, inserire in container tutti i daemon MON, MGR e OSD esistenti sul nodo eseguendo il comando seguente sul Salt Master:
```
root@master # salt MINION_ID state.apply ceph.upgrade.ses7.adopt
```
Sostituire MINION_ID con l'ID del minion di cui si sta eseguendo l'upgrade. È possibile ottenere l'elenco degli ID dei minion eseguendo il comando salt-key -L sul Salt Master.
Suggerimento
Per vedere lo stato e l'avanzamento del processo di adozione, controllare il Ceph Dashboard o eseguire uno dei comandi seguenti sul Salt Master:
```
root@master # ceph status
root@master # ceph versions
root@master # salt-run upgrade.status
```
Al termine dell'adozione, annullare l'impostazione del flag noout se il nodo di cui si sta eseguendo l'upgrade è un nodo OSD:
```
cephuser@adm > ceph osd rm-noout SHORT_NODE_NAME
```

10.4 Esecuzione dell'upgrade dei nodi del gateway #

Successivamente, eseguire l'upgrade dei nodi del gateway separati (gateway Samba, Metadata Server, Object Gateway, NFS Ganesha o iSCSI Gateway). Eseguire l'upgrade del sistema operativo sottostante a SUSE Linux Enterprise Server 15 SP3 per ogni nodo:

Se tutti i nodi del cluster sono registrati su SUSE Customer Center, eseguire il comando zypper migration.
Se i nodi del cluster dispongono di archivi software assegnati manualmente, eseguire il comando zypper dup seguito dal comando reboot.

Questo passaggio si applica anche ai nodi che fanno parte del cluster, ma a cui non è stato ancora assegnato nessun ruolo (in caso di dubbi, controllare l'elenco degli host sul Salt Master fornito dal comando salt-key -L e confrontarlo con l'output del comando salt-run upgrade.status).

Dopo che l'upgrade del sistema operativo è stato eseguito su tutti i nodi del cluster, il passaggio successivo consiste nell'installare il pacchetto ceph-salt e nell'applicare la configurazione del cluster. I servizi del gateway effettivi vengono ridistribuiti nella modalità in container alla fine della procedura di upgrade.

Nota

I servizi Metadata Server e Object Gateway non sono disponibili dall'inizio dell'upgrade a SUSE Linux Enterprise Server 15 SP3 fino alla ridistribuzione al termine della procedura di upgrade.

10.5 Installazione di `ceph-salt` e applicazione della configurazione del cluster #

Prima di avviare la procedura di installazione di ceph-salt e di applicazione della configurazione del cluster, verificare lo stato del cluster e dell'upgrade eseguendo i comandi seguenti:

root@master # ceph status
root@master # ceph versions
root@master # salt-run upgrade.status

Rimuovere i processi cron rbd_exporter e rgw_exporter creati da DeepSea. Sul Salt Master con il ruolo di root, eseguire il comando crontab -e per modificare la crontab. Eliminare gli elementi seguenti, se presenti:

# SALT_CRON_IDENTIFIER:deepsea rbd_exporter cron job
*/5 * * * * /var/lib/prometheus/node-exporter/rbd.sh > \
 /var/lib/prometheus/node-exporter/rbd.prom 2> /dev/null
# SALT_CRON_IDENTIFIER:Prometheus rgw_exporter cron job
*/5 * * * * /var/lib/prometheus/node-exporter/ceph_rgw.py > \
 /var/lib/prometheus/node-exporter/ceph_rgw.prom 2> /dev/null

Esportare la configurazione del cluster da DeepSea eseguendo i comandi seguenti:

root@master # salt-run upgrade.ceph_salt_config > ceph-salt-config.json
root@master # salt-run upgrade.generate_service_specs > specs.yaml

Disinstallare DeepSea e installare ceph-salt sul Salt Master:

root@master # zypper remove 'deepsea*'
root@master # zypper install ceph-salt

Riavviare il Salt Master e sincronizzare i moduli Salt:

root@master # systemctl restart salt-master.service
root@master # salt \* saltutil.sync_all

Importare la configurazione del cluster di DeepSea in ceph-salt:
```
root@master # ceph-salt import ceph-salt-config.json
```
Generare le chiavi SSH per la comunicazione tra i nodi e il cluster:
```
root@master # ceph-salt config /ssh generate
```
Suggerimento
Verificare che la configurazione del cluster sia stata importata da DeepSea e specificare le potenziali opzioni ignorate:
```
root@master # ceph-salt config ls
```
Per una descrizione completa della configurazione del cluster, fare riferimento alla Sezione 7.2, «Configurazione delle proprietà del cluster».
Applicare la configurazione e abilitare cephadm:
```
root@master # ceph-salt apply
```
Se è necessario specificare l'URL del registro del container locale e le credenziali di accesso, seguire la procedura descritta nella Sezione 7.2.10, «Utilizzo del registro del container».
Se le immagini del container in uso non provengono da registry.suse.com, ma dal registro configurato in locale, comunicare a Ceph quale immagine del container utilizzare eseguendo
```
root@master # ceph config set global container_image IMAGE_NAME
```
Ad esempio:
```
root@master # ceph config set global container_image 192.168.121.1:5000/my/ceph/image
```
Interrompere e disabilitare i daemon ceph-crash di SUSE Enterprise Storage 6. I nuovi moduli in container di tali daemon saranno avviati automaticamente in un secondo momento.
```
root@master # salt '*' service.stop ceph-crash
root@master # salt '*' service.disable ceph-crash
```

10.6 Esecuzione dell'upgrade e adozione dello stack di monitoraggio #

La procedura descritta di seguito adotta tutti i componenti dello stack di monitoraggio (vedere Capitolo 16, Monitoraggio e creazione di avvisi per ulteriori dettagli).

Sospendere l'utilità di coordinamento:
```
cephuser@adm > ceph orch pause
```

Eseguire i comandi seguenti su qualsiasi nodo su cui sono in esecuzione Prometheus, Grafana e Alertmanager (il Salt Master di default):

cephuser@adm > cephadm adopt --style=legacy --name prometheus.$(hostname)
cephuser@adm > cephadm adopt --style=legacy --name alertmanager.$(hostname)
cephuser@adm > cephadm adopt --style=legacy --name grafana.$(hostname)

Suggerimento

Se non è in esecuzione il registro delle immagini del container di default registry.suse.com, è necessario specificare l'immagine da utilizzare per ogni comando, ad esempio:

cephuser@adm > cephadm --image 192.168.121.1:5000/ses/7.1/ceph/prometheus-server:2.32.1 \
  adopt --style=legacy --name prometheus.$(hostname)
cephuser@adm > cephadm --image 192.168.121.1:5000/ses/7.1/ceph/prometheus-alertmanager:0.21.0 \
  adopt --style=legacy --name alertmanager.$(hostname)
cephuser@adm > cephadm --image 192.168.121.1:5000/ses/7.1/ceph/grafana:7.5.12 \
 adopt --style=legacy --name grafana.$(hostname)

Le immagini del container richieste e le relative versioni sono elencate in Sezione 16.1, «Configurazione di immagini personalizzate o locali».

Rimuovere il node-exporter da tutti i nodi. Non è necessario eseguire la migrazione del node-exporter, che verrà reinstallato come container quando verrà applicato il file specs.yaml.
```
> sudo zypper rm golang-github-prometheus-node_exporter
```
In alternativa, è possibile rimuovere il node-exporter contemporaneamente da tutti i nodi usando Salt sul nodo admin:
```
root@master # salt '*' pkg.remove golang-github-prometheus-node_exporter
```
Applicare le specifiche del servizio esportate in precedenza da DeepSea:
```
cephuser@adm > ceph orch apply -i specs.yaml
```
Suggerimento
Se non è in esecuzione il registro delle immagini del container di default registry.suse.com, ma un registro del container locale, prima di distribuire il node-exporter, configurare cephadm in modo che utilizzi l'immagine del container dal registro locale per la distribuzione del node-exporter. Diversamente, è possibile saltare questo passaggio e ignorare l'avviso successivo.
```
cephuser@adm > ceph config set mgr mgr/cephadm/container_image_node_exporter QUALIFIED_IMAGE_PATH
```
Assicurarsi che tutte le immagini del container per i servizi di monitoraggio puntino al registro locale, non solo a quello per il node-exporter. Il precedente passaggio di verifica è richiesto solo per il node-exporter, ma a questo punto si consiglia di impostare tutte le immagini del container di monitoraggio in cephadm in modo che puntino al registro locale.
In caso contrario, le nuove distribuzioni dei servizi di monitoraggio, nonché le ridistribuzioni, utilizzeranno la configurazione cephadm di default ed è possibile che non si sia in grado di distribuire i servizi (nel caso di distribuzioni con air gap) o che si distribuiscano servizi con versioni miste.
La modalità con cui cephadm deve essere configurato per utilizzare le immagini del container provenienti dal registro locale è descritta nel Sezione 16.1, «Configurazione di immagini personalizzate o locali».
Riprendere l'utilità di coordinamento:
```
cephuser@adm > ceph orch resume
```

10.7 Ridistribuzione del servizio del gateway #

10.7.1 Esecuzione dell'upgrade di Object Gateway #

In SUSE Enterprise Storage 7.1, gli Object Gateway sono sempre configurati con un dominio per consentire l'uso della funzionalità multisito (vedere Sezione 21.13, «Object Gateway multisito» per ulteriori dettagli) in un secondo momento. Se Object Gateway è stato configurato in modalità sito singolo in SUSE Enterprise Storage 6, seguire la procedura indicata di seguito per aggiungere un dominio. Se non si prevede di utilizzare la funzionalità multisito, è possibile utilizzare il valore default per il nome del dominio, del gruppo di zone e della zona.

Creare un nuovo dominio:

cephuser@adm > radosgw-admin realm create --rgw-realm=REALM_NAME --default

Facoltativamente, rinominare il gruppo di zone e la zona di default.

cephuser@adm > radosgw-admin zonegroup rename \
 --rgw-zonegroup default \
 --zonegroup-new-name=ZONEGROUP_NAME
cephuser@adm > radosgw-admin zone rename \
 --rgw-zone default \
 --zone-new-name ZONE_NAME \
 --rgw-zonegroup=ZONEGROUP_NAME

Configurare il gruppo di zone master:

cephuser@adm > radosgw-admin zonegroup modify \
 --rgw-realm=REALM_NAME \
 --rgw-zonegroup=ZONEGROUP_NAME \
 --endpoints http://RGW.EXAMPLE.COM:80 \
 --master --default

Configurare la zona master: A tale scopo, saranno necessarie la chiave di accesso (ACCESS_KEY) e la chiave segreta (SECRET_KEY) dell'utente Object Gateway con il flag system abilitato. In genere, si tratta dell'utente admin. Per ottenere la chiave di accesso (ACCESS_KEY) e la chiave segreta (SECRET_KEY), eseguire radosgw-admin user info --uid admin --rgw-zone=ZONE_NAME.
```
cephuser@adm > radosgw-admin zone modify \
 --rgw-realm=REALM_NAME \
 --rgw-zonegroup=ZONEGROUP_NAME \
 --rgw-zone=ZONE_NAME \
 --endpoints http://RGW.EXAMPLE.COM:80 \
 --access-key=ACCESS_KEY \
 --secret=SECRET_KEY \
 --master --default
```

Eseguire il commit della configurazione aggiornata:

cephuser@adm > radosgw-admin period update --commit

Per inserire il servizio Object Gateway in container, creare il file della specifica corrispondente come descritto nella Sezione 8.3.4, «Distribuzione degli Object Gateway» e applicarlo.

cephuser@adm > ceph orch apply -i RGW.yml

10.7.2 Esecuzione dell'upgrade di NFS Ganesha #

Importante

NFS Ganesha supporta NFS versione 4.1 e versioni successive. Non supporta NFS versione 3.

Di seguito viene mostrato come eseguire la migrazione di un servizio NFS Ganesha esistente su cui è in esecuzione Ceph Nautilus a un container NFS Ganesha su cui è in esecuzione Ceph Octopus.

Avvertimento

Nella documentazione seguente si presuppone che l'utente abbia già eseguito correttamente l'upgrade dei servizi Ceph di base.

NFS Ganesha memorizza la configurazione aggiuntiva di ogni daemon e la esporta in un pool RADOS. È possibile individuare il pool RADOS configurato nella riga watch_url del blocco RADOS_URLS nel file ganesha.conf. Per default, questo pool sarà denominato ganesha_config.

Prima di tentare qualsiasi migrazione, si consiglia vivamente di eseguire una copia degli oggetti di configurazione del daemon e dell'esportazione ubicati nel pool RADOS. Per individuare il pool RADOS configurato, eseguire il seguente comando:

cephuser@adm > grep -A5 RADOS_URLS /etc/ganesha/ganesha.conf

Per elencare i contenuti del pool RADOS:

cephuser@adm > rados --pool ganesha_config --namespace ganesha ls | sort
  conf-node3
  export-1
  export-2
  export-3
  export-4

Per copiare gli oggetti RADOS:

cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
cephuser@adm > OBJS=$(rados $RADOS_ARGS ls)
cephuser@adm > for obj in $OBJS; do rados $RADOS_ARGS get $obj $obj; done
cephuser@adm > ls -lah
total 40K
drwxr-xr-x 2 root root 4.0K Sep 8 03:30 .
drwx------ 9 root root 4.0K Sep 8 03:23 ..
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node2
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node3
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-1
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-2
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-3
-rw-r--r-- 1 root root 358 Sep 8 03:30 export-4

Su ogni singolo nodo, occorre interrompere eventuali servizi NFS Ganesha esistenti e sostituirli con un container gestito da cephadm.

Interrompere e disabilitare il servizio NFS Ganesha esistente:

cephuser@adm > systemctl stop nfs-ganesha
cephuser@adm > systemctl disable nfs-ganesha

In seguito all'interruzione del servizio NFS Ganesha esistente, è possibile distribuirne uno nuovo in un container tramite cephadm. A tale scopo, è necessario creare una specifica del servizio contenente un service_id che verrà utilizzato per identificare questo nuovo cluster NFS, il nome host del nodo di cui si sta eseguendo la migrazione indicato come host nella specifica di posizionamento e lo spazio dei nomi e il pool RADOS contenente gli oggetti di esportazione NFS configurati. Esempio:
```
service_type: nfs
service_id: SERVICE_ID
placement:
  hosts:
  - node2
  pool: ganesha_config
  namespace: ganesha
```
Per ulteriori informazioni sulla creazione di una specifica di posizionamento, vedere Sezione 8.2, «Specifica del servizio e del posizionamento».

Applicare la specifica di posizionamento:

cephuser@adm > ceph orch apply -i FILENAME.yaml

Verificare che il daemon NFS Ganesha sia in esecuzione sull'host:

cephuser@adm > ceph orch ps --daemon_type nfs
NAME           HOST   STATUS         REFRESHED  AGE  VERSION  IMAGE NAME                                IMAGE ID      CONTAINER ID
nfs.foo.node2  node2  running (26m)  8m ago     27m  3.3      registry.suse.com/ses/7.1/ceph/ceph:latest  8b4be7c42abd  c8b75d7c8f0d

Ripetere questi passaggi per ogni nodo NFS Ganesha. Non è necessario creare una specifica del servizio separata per ogni nodo. È sufficiente aggiungere il nome host di ciascun nodo alla specifica del servizio NFS esistente e riapplicarla.

È possibile eseguire la migrazione delle esportazioni esistenti in due modi diversi:

Ricrearle manualmente o riassegnarle tramite il Ceph Dashboard.
Copiare manualmente i contenuti di ogni oggetto RADOS di ciascun daemon nella configurazione comune di NFS Ganesha appena creata.

Procedura 10.1: Copia manuale delle esportazioni nel file di configurazione comune di NFS Ganesha #

Creare l'elenco degli oggetti RADOS di ciascun daemon:

cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
cephuser@adm > DAEMON_OBJS=$(rados $RADOS_ARGS ls | grep 'conf-')

Creare una copia degli oggetti RADOS di ciascun daemon:

cephuser@adm > for obj in $DAEMON_OBJS; do rados $RADOS_ARGS get $obj $obj; done
cephuser@adm > ls -lah
total 20K
drwxr-xr-x 2 root root 4.0K Sep 8 16:51 .
drwxr-xr-x 3 root root 4.0K Sep 8 16:47 ..
-rw-r--r-- 1 root root 90 Sep 8 16:51 conf-nfs.SERVICE_ID
-rw-r--r-- 1 root root 90 Sep 8 16:51 conf-node2
-rw-r--r-- 1 root root 90 Sep 8 16:51 conf-node3

Ordinare e fondere gli elementi in un singolo elenco di esportazioni:

cephuser@adm > cat conf-* | sort -u > conf-nfs.SERVICE_ID
cephuser@adm > cat conf-nfs.foo
%url "rados://ganesha_config/ganesha/export-1"
%url "rados://ganesha_config/ganesha/export-2"
%url "rados://ganesha_config/ganesha/export-3"
%url "rados://ganesha_config/ganesha/export-4"

Scrivere sul nuovo file di configurazione comune di NFS Ganesha:

cephuser@adm > rados $RADOS_ARGS put conf-nfs.SERVICE_ID conf-nfs.SERVICE_ID

Inviare una notifica al daemon NFS Ganesha:
```
cephuser@adm > rados $RADOS_ARGS notify conf-nfs.SERVICE_ID conf-nfs.SERVICE_ID
```
Nota
Tramite questa azione, il daemon ricaricherà la configurazione.

Al termine della migrazione, è possibile rimuovere il servizio NFS Ganesha basato su Nautilus.

Rimuovere NFS Ganesha:

cephuser@adm > zypper rm nfs-ganesha
Reading installed packages...
Resolving package dependencies...
The following 5 packages are going to be REMOVED:
  nfs-ganesha nfs-ganesha-ceph nfs-ganesha-rados-grace nfs-ganesha-rados-urls nfs-ganesha-rgw
5 packages to remove.
After the operation, 308.9 KiB will be freed.
Continue? [y/n/v/...? shows all options] (y): y
(1/5) Removing nfs-ganesha-ceph-2.8.3+git0.d504d374e-3.3.1.x86_64 .................................................................................................................................................................................................................................................................................................[done]
(2/5) Removing nfs-ganesha-rgw-2.8.3+git0.d504d374e-3.3.1.x86_64 ..................................................................................................................................................................................................................................................................................................[done]
(3/5) Removing nfs-ganesha-rados-urls-2.8.3+git0.d504d374e-3.3.1.x86_64 ...........................................................................................................................................................................................................................................................................................[done]
(4/5) Removing nfs-ganesha-rados-grace-2.8.3+git0.d504d374e-3.3.1.x86_64 ..........................................................................................................................................................................................................................................................................................[done]
(5/5) Removing nfs-ganesha-2.8.3+git0.d504d374e-3.3.1.x86_64 ......................................................................................................................................................................................................................................................................................................[done]
Additional rpm output:
warning: /etc/ganesha/ganesha.conf saved as /etc/ganesha/ganesha.conf.rpmsave

Rimuovere le impostazioni esistenti del cluster dal Ceph Dashboard:

cephuser@adm > ceph dashboard reset-ganesha-clusters-rados-pool-namespace

10.7.3 Esecuzione dell'upgrade del Metadata Server #

Diversamente dai servizi MON, MGR e OSD, il Metadata Server non può essere adottato sul posto. Al contrario, è necessario ridistribuirlo in container tramite l'utilità di coordinamento Ceph.

Eseguire il comando ceph fs ls per ottenere il nome del file system, ad esempio:

cephuser@adm > ceph fs ls
name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]

Creare un nuovo file della specifica del servizio mds.yml, come descritto nella Sezione 8.3.3, «Distribuzione dei Metadata Server», utilizzando il nome del file system come service_id e specificando gli host su cui verranno eseguiti i daemon MDS. Esempio:
```
service_type: mds
service_id: cephfs
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
```
Eseguire il comando ceph orch apply -i mds.yml per applicare la specifica del servizio e avviare i daemon MDS.

10.7.4 Esecuzione dell'upgrade di iSCSI Gateway #

Per eseguire l'upgrade di iSCSI Gateway, è necessario ridistribuire tale servizio nei container tramite l'utilità di coordinamento Ceph. Se sono presenti più iSCSI Gateway, occorre ridistribuirli uno per uno per ridurre il tempo di fermo del servizio.

Interrompere e disabilitare i daemon iSCSI esistenti su ciascun nodo iSCSI Gateway:

> sudo systemctl stop rbd-target-gw
> sudo systemctl disable rbd-target-gw
> sudo systemctl stop rbd-target-api
> sudo systemctl disable rbd-target-api

Creare una specifica del servizio per l'iSCSI Gateway come descritto nella Sezione 8.3.5, «Distribuzione di iSCSI Gateway». A tale scopo, sono necessarie le impostazioni pool, trusted_ip_list e api_* del file /etc/ceph/iscsi-gateway.cfg esistente. Se il supporto per SSL è abilitato (api_secure = true), sono necessari inoltre il certificato (/etc/ceph/iscsi-gateway.crt) e la chiave (/etc/ceph/iscsi-gateway.key) SSL.
Ad esempio, se /etc/ceph/iscsi-gateway.cfg contiene quanto segue:
```
[config]
cluster_client_name = client.igw.ses-min5
pool = iscsi-images
trusted_ip_list = 10.20.179.203,10.20.179.201,10.20.179.205,10.20.179.202
api_port = 5000
api_user = admin
api_password = admin
api_secure = true
```
È necessario creare il file della specifica del servizio iscsi.yml seguente:
```
service_type: iscsi
service_id: igw
placement:
  hosts:
  - ses-min5
spec:
  pool: iscsi-images
  trusted_ip_list: "10.20.179.203,10.20.179.201,10.20.179.205,10.20.179.202"
  api_port: 5000
  api_user: admin
  api_password: admin
  api_secure: true
  ssl_cert: |
    -----BEGIN CERTIFICATE-----
    MIIDtTCCAp2gAwIBAgIYMC4xNzc1NDQxNjEzMzc2MjMyXzxvQ7EcMA0GCSqGSIb3
    DQEBCwUAMG0xCzAJBgNVBAYTAlVTMQ0wCwYDVQQIDARVdGFoMRcwFQYDVQQHDA5T
    [...]
    -----END CERTIFICATE-----
  ssl_key: |
    -----BEGIN PRIVATE KEY-----
    MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5jdYbjtNTAKW4
    /CwQr/7wOiLGzVxChn3mmCIF3DwbL/qvTFTX2d8bDf6LjGwLYloXHscRfxszX/4h
    [...]
    -----END PRIVATE KEY-----
```
Nota
Le impostazioni pool, trusted_ip_list, api_port, api_user, api_password, api_secure sono identiche a quelle del file /etc/ceph/iscsi-gateway.cfg. I valori ssl_cert e ssl_key possono essere copiati dai file di chiave e certificato SSL esistenti. Verificare che il rientro sia corretto e che il carattere della barra verticale | venga visualizzato alla fine delle righe ssl_cert: e ssl_key: (vedere il contenuto del file iscsi.yml riportato sopra).
Eseguire il comando ceph orch apply -i iscsi.yml per applicare la specifica del servizio e avviare i daemon iSCSI Gateway.
Rimuovere il pacchetto ceph-iscsi meno recente da ciascuno dei nodi iSCSI Gateway esistenti:
```
cephuser@adm > zypper rm -u ceph-iscsi
```

10.8 Pulizia successiva all'upgrade #

In seguito all'upgrade, seguire la procedura di pulizia indicata di seguito:

Verificare che l'upgrade del cluster sia riuscito correttamente controllando la versione corrente di Ceph:
```
cephuser@adm > ceph versions
```
Assicurarsi che nessun OSD precedente si unisca al cluster:
```
cephuser@adm > ceph osd require-osd-release pacific
```
Se necessario, impostare l'opzione pg_autoscale_mode dei pool esistenti:
Importante
Per default, in SUSE Enterprise Storage 6, l'opzione pg_autoscale_mode era impostata su warn per i pool. L'opzione generava un messaggio di avviso se il numero dei gruppi di posizionamento non era ottimale, senza però avviare il dimensionamento automatico. Per default, in SUSE Enterprise Storage 7.1, l'opzione pg_autoscale_mode è impostata su on per i nuovi pool e i gruppi di posizionamento vengono effettivamente sottoposti a dimensionamento automatico. Il processo di upgrade non modifica automaticamente l'opzione pg_autoscale_mode dei pool esistenti. Se si desidera modificarla su on per sfruttare tutti i vantaggi dell'utilità di dimensionamento automatico, vedere le istruzioni nel Sezione 17.4.12, «Abilitazione dell'utilità di dimensionamento automatico del gruppo di posizionamento».
Ulteriori dettagli sono disponibili nel Sezione 17.4.12, «Abilitazione dell'utilità di dimensionamento automatico del gruppo di posizionamento».

Impedire i client precedenti a Luminous:

cephuser@adm > ceph osd set-require-min-compat-client luminous

Abilitare il modulo dell'utilità di bilanciamento:
```
cephuser@adm > ceph balancer mode upmap
cephuser@adm > ceph balancer on
```
Ulteriori dettagli sono disponibili nel Sezione 29.1, «Servizio di bilanciamento».
Facoltativamente, abilitare il modulo di telemetria:
```
cephuser@adm > ceph mgr module enable telemetry
cephuser@adm > ceph telemetry on
```
Ulteriori dettagli sono disponibili nel Sezione 29.2, «Abilitazione del modulo di telemetria».

10 Upgrade da SUSE Enterprise Storage 6 a 7.1 #

10.1 Attività preparatorie all'upgrade #

10.1.1 Aspetti da considerare #

10.1.2 Backup della configurazione e dei dati del cluster #

10.1.3 Verifica dei passaggi dell'upgrade precedente #

10.1.4 Aggiornamento dei nodi del cluster e verifica dell'integrità del cluster #

10.1.4.1 Disabilitazione dei client non sicuri #

10.1.5 Verifica dell'accesso agli archivi software e alle immagini del container #

10.1.5.1 Archivi software #

10.1.5.2 Immagini del container #

10.2 Esecuzione dell'upgrade del Salt Master #

10.3 Esecuzione dell'upgrade dei nodi MON, MGR e OSD #

10.4 Esecuzione dell'upgrade dei nodi del gateway #

10.5 Installazione di ceph-salt e applicazione della configurazione del cluster #

10.6 Esecuzione dell'upgrade e adozione dello stack di monitoraggio #

10.7 Ridistribuzione del servizio del gateway #

10.7.1 Esecuzione dell'upgrade di Object Gateway #

10.7.2 Esecuzione dell'upgrade di NFS Ganesha #

10.7.3 Esecuzione dell'upgrade del Metadata Server #

10.7.4 Esecuzione dell'upgrade di iSCSI Gateway #

10.8 Pulizia successiva all'upgrade #

10.5 Installazione di `ceph-salt` e applicazione della configurazione del cluster #