7 Upgrade da una release precedente #
Questo capitolo descrive le procedure per eseguire l'upgrade di SUSE Enterprise Storage 6 alla versione 7.
L'upgrade include i task seguenti:
Esecuzione dell'upgrade da Ceph Nautilus a Octopus.
Passaggio dall'installazione ed esecuzione di Ceph tramite pacchetti RPM all'esecuzione in container.
Rimozione completa di DeepSea e sostituzione con
ceph-salte cephadm.
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.
L'upgrade dalle versioni di SUSE Enterprise Storage precedenti alla 6 non è supportato. Prima di seguire le procedure descritte in questo capitolo, è necessario eseguire l'upgrade alla versione più recente di SUSE Enterprise Storage 6.
7.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 degli OSD da FileStore a BlueStore deve essere eseguita prima dell'upgrade, poiché FileStore non è supportato in SUSE Enterprise Storage 7. All'indirizzo https://documentation.suse.com/ses/6/html/ses-all/cha-ceph-upgrade.html#filestore2bluestore sono disponibili ulteriori dettagli su BlueStore e su come eseguire la migrazione da FileStore.
Se è in esecuzione una versione precedente del cluster in cui sono ancora utilizzati OSD
ceph-disk, è necessario passare aceph-volumeprima dell'upgrade. Ulteriori dettagli sono disponibili in https://documentation.suse.com/ses/6/html/ses-all/cha-ceph-upgrade.html#upgrade-osd-deployment.
7.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.
Per altre informazioni sulle modifiche apportate rispetto alla release precedente di SUSE Enterprise Storage, leggere le note di rilascio. 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.
Inoltre, dopo aver installato il pacchetto release-notes-ses dall'archivio di SES 7, individuare localmente le note di rilascio nella directory
/usr/share/doc/release-notesoppure online all'indirizzo https://www.suse.com/releasenotes/.Leggere il Capitolo 5, Distribuzione con cephadm per acquisire dimestichezza con
ceph-salte 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 e sostituire DeepSea con
ceph-salt, quindi passare a cephadm. Finché non sarà stato completato l'upgrade di almeno tutti i Ceph Manager, non sarà possibile iniziare a utilizzare il modulo dell'utilità di coordinamento cephadm.L'upgrade dai pacchetti RPM Nautilus ai container Octopus deve essere eseguito 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 SP2 fino alla ridistribuzione dei servizi al termine della procedura di upgrade. Questo è un aspetto particolarmente importante da tenere presente se questi servizi sono in co-location con MON, MGR oppure OSD, dal momento che in questo caso potrebbero essere inattivi per tutta la durata dell'upgrade del cluster. Se ciò rappresenta un problema, valutare di distribuire separatamente tali servizi su nodi aggiuntivi prima di procedere con l'upgrade per fare 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 SP2 e nuovamente per breve tempo durante la ridistribuzione di ciascun servizio nella modalità in container.
7.1.2 Backup della configurazione e dei dati del cluster #
Si consiglia di eseguire il backup della configurazione e dei dati del cluster prima di avviare l'upgrade a SUSE Enterprise Storage 7. Per istruzioni su come eseguire il backup di tutti i dati, vedere https://documentation.suse.com/ses/6/html/ses-all/cha-deployment-backup.html.
7.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.
7.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:ulti
root # zypper refresh && zypper patchDopodiché, verificare l'integrità del cluster:
cephuser@adm > ceph -s7.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 SP2 e SUSE Enterprise Storage 7, oltre che al registro delle immagini del container.
7.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 alla https://documentation.suse.com/sles/15-SP2/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-SP2
SLE-Module-Basesystem/15-SP2
SLE-Module-Server-Applications/15-SP2
SUSE-Enterprise-Storage-7
7.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/ceph/ceph
registry.suse.com/ses/7/ceph/grafana
registry.suse.com/caasp/v4.5/prometheus-server
registry.suse.com/caasp/v4.5/prometheus-node-exporter
registry.suse.com/caasp/v4.5/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 5.3.2.11, «Configurazione del registro del container» per ulteriori dettagli sulla configurazione di un registro delle immagini del container locale.
7.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 SP2:
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 dupseguito dareboot.
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_refreshSe le immagini del container in uso non provengono da
registry.suse.com, ma dal registro configurato in locale, modificare/srv/pillar/ceph/stack/global.ymlper comunicare a DeepSea quale immagine del container e registro Ceph utilizzare. Ad esempio, per utilizzare192.168.121.1:5000/my/ceph/imageaggiungere le righe seguenti:ses7_container_image: 192.168.121.1:5000/my/ceph/image ses7_container_registries: - location: 192.168.121.1:5000
Salvare il file e applicare le modifiche:
root@master #salt '*' saltutil.refresh_pillarAssimilare la configurazione esistente:
cephuser@adm >ceph config assimilate-conf -i /etc/ceph/ceph.confVerificare 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 15.2.2-60-gf5864377ab (f5864377abb5549f843784c93577980aa264b9bc) octopus (stable) os: SUSE Linux Enterprise Server 15 SP2 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)
7.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:
Durante l'upgrade di un nodo OSD, fare in modo che l'OSD non sia contrassegnato con
outeseguendo il comando seguente:cephuser@adm >ceph osd add-noout SHORT_NODE_NAMESostituire 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 sonoses-min1eses-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 SP2:
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 dupseguito dareboot.
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.adoptSostituire 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 -Lsul Salt Master.
SuggerimentoPer 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 statusroot@master #ceph versionsroot@master #salt-run upgrade.statusAl termine dell'adozione, annullare l'impostazione del flag
nooutse il nodo di cui si sta eseguendo l'upgrade è un nodo OSD:cephuser@adm >ceph osd rm-noout SHORT_NODE_NAME
7.4 Esecuzione dell'upgrade dei nodi del gateway #
Adesso, eseguire l'upgrade dei nodi del gateway separati (Metadata Server, Object Gateway, NFS Ganesha o iSCSI Gateway). Eseguire l'upgrade del sistema operativo sottostante a SUSE Linux Enterprise Server 15 SP2 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 dupseguito dal comandoreboot.
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).
In seguito all'upgrade del sistema operativo su tutti i nodi del cluster, installare il pacchetto ceph-salt e applicare la configurazione del cluster. I servizi del gateway effettivi vengono ridistribuiti nella modalità in container alla fine della procedura di upgrade.
I servizi Metadata Server e Object Gateway non sono disponibili dall'inizio dell'upgrade a SUSE Linux Enterprise Server 15 SP2 fino alla ridistribuzione al termine della procedura di upgrade.
7.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 statusroot@master #ceph versionsroot@master #salt-run upgrade.status
Rimuovere i processi cron
rbd_exporterergw_exportercreati da DeepSea. Sul Salt Master con il ruolo diroot, eseguire il comandocrontab -eper 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.jsonroot@master #salt-run upgrade.generate_service_specs > specs.yamlDisinstallare DeepSea e installare
ceph-saltsul Salt Master:root@master #zypper remove 'deepsea*'root@master #zypper install ceph-saltRiavviare il Salt Master e sincronizzare i moduli Salt:
root@master #systemctl restart salt-master.serviceroot@master #salt \* saltutil.sync_allImportare la configurazione del cluster di DeepSea in
ceph-salt:root@master #ceph-salt import ceph-salt-config.jsonGenerare le chiavi SSH per la comunicazione tra i nodi e il cluster:
root@master #ceph-salt config /ssh generateSuggerimentoVerificare che la configurazione del cluster sia stata importata da DeepSea e specificare le potenziali opzioni ignorate:
root@master #ceph-salt config lsPer una descrizione completa della configurazione del cluster, fare riferimento alla Sezione 5.3.2, «Configurazione delle proprietà del cluster».
Applicare la configurazione e abilitare cephadm:
root@master #ceph-salt applySe è necessario specificare l'URL del registro del container locale e le credenziali di accesso, seguire la procedura descritta nella Sezione 5.3.2.11, «Configurazione 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 eseguendoroot@master #ceph config set global container_image IMAGE_NAMEEsempio:
root@master #ceph config set global container_image 192.168.121.1:5000/my/ceph/imageInterrompere e disabilitare i daemon
ceph-crashdi 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-crashroot@master #salt '*' service.disable ceph-crash
7.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 pauseEseguire 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)SuggerimentoSe non è in esecuzione il registro delle immagini del container di default
registry.suse.com, è necessario specificare l'immagine da utilizzare, ad esempio:cephuser@adm >cephadm --image 192.168.121.1:5000/caasp/v4.5/prometheus-server:2.18.0 \ adopt --style=legacy --name prometheus.$(hostname)cephuser@adm >cephadm --image 192.168.121.1:5000/caasp/v4.5/prometheus-alertmanager:0.16.2 \ adopt --style=legacy --name alertmanager.$(hostname)cephuser@adm >cephadm --image 192.168.121.1:5000/ses/7/ceph/grafana:7.0.3 \ adopt --style=legacy --name grafana.$(hostname)Per ulteriori dettagli sull'uso delle immagini del container personalizzate o locali, fare riferimento a Sezione 16.1, «Configurazione di immagini personalizzate o locali».
Rimuovere Node-Exporter. Non è necessario eseguire la migrazione di tale utilità, che verrà reinstallata come container quando verrà applicato il file
specs.yaml.tux >sudozypper rm golang-github-prometheus-node_exporterApplicare le specifiche del servizio esportate in precedenza da DeepSea:
cephuser@adm >ceph orch apply -i specs.yamlRiprendere l'utilità di coordinamento:
cephuser@adm >ceph orch resume
7.7 Ridistribuzione del servizio del gateway #
7.7.1 Esecuzione dell'upgrade di Object Gateway #
In SUSE Enterprise Storage 7, 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 delle zone.
Creare un nuovo dominio:
cephuser@adm >radosgw-admin realm create --rgw-realm=REALM_NAME --defaultFacoltativamente, rinominare il gruppo di zone e la zona di default.
cephuser@adm >radosgw-admin zonegroup rename \ --rgw-zonegroup default \ --zonegroup-new-name=ZONEGROUP_NAMEcephuser@adm >radosgw-admin zone rename \ --rgw-zone default \ --zone-new-name ZONE_NAME \ --rgw-zonegroup=ZONEGROUP_NAMEConfigurare 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 --defaultConfigurare 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
systemabilitato. In genere, si tratta dell'utenteadmin. Per ottenere la chiave di accesso (ACCESS_KEY) e la chiave segreta (SECRET_KEY), eseguireradosgw-admin user info --uid admin.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 --defaultEseguire 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 5.4.3.4, «Distribuzione degli Object Gateway» e applicarlo.
cephuser@adm > ceph orch apply -i RGW.yml7.7.2 Esecuzione dell'upgrade di NFS Ganesha #
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.
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 provare a eseguire la migrazione, si consiglia di creare una copia dell'esportazione e degli oggetti di configurazione del daemon ubicati nel pool RADOS. Per individuare il pool RADOS configurato, eseguire il comando seguente:
cephuser@adm > grep -A5 RADOS_URLS /etc/ganesha/ganesha.confPer 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-4Per 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; donecephuser@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 il servizio NFS Ganesha esistente e sostituirlo con un container gestito da cephadm.
Interrompere e disabilitare il servizio NFS Ganesha esistente:
cephuser@adm >systemctl stop nfs-ganeshacephuser@adm >systemctl disable nfs-ganeshaIn 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_idche 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 la Sezione 5.4.2, «Specifica del servizio e del posizionamento».
Applicare la specifica di posizionamento:
cephuser@adm >ceph orch apply -i FILENAME.yamlVerificare 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/ceph/ceph:latest 8b4be7c42abd c8b75d7c8f0dRipetere 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.
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; donecephuser@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-node3Ordinare e fondere gli elementi in un singolo elenco di esportazioni:
cephuser@adm >cat conf-* | sort -u > conf-nfs.SERVICE_IDcephuser@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_IDInviare una notifica al daemon NFS Ganesha:
cephuser@adm >rados $RADOS_ARGS notify conf-nfs.SERVICE_ID conf-nfs.SERVICE_IDNotaTramite 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.rpmsaveRimuovere le impostazioni esistenti del cluster dal Ceph Dashboard:
cephuser@adm >ceph dashboard reset-ganesha-clusters-rados-pool-namespace
7.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 lsper 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 5.4.3.3, «Distribuzione dei Metadata Server», utilizzando il nome del file system comeservice_ide 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.ymlper applicare la specifica del servizio e avviare i daemon MDS.
7.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:
tux >sudosystemctl stop rbd-target-gwtux >sudosystemctl disable rbd-target-gwtux >sudosystemctl stop rbd-target-apitux >sudosystemctl disable rbd-target-apiCreare una specifica del servizio per l'iSCSI Gateway come descritto nella Sezione 5.4.3.5, «Distribuzione di iSCSI Gateway». A tale scopo, sono necessarie le impostazioni
pool,trusted_ip_listeapi_*del file/etc/ceph/iscsi-gateway.cfgesistente. 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.cfgcontiene 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.ymlseguente: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-----NotaLe impostazioni
pool,trusted_ip_list,api_port,api_user,api_password,api_securesono identiche a quelle del file/etc/ceph/iscsi-gateway.cfg. I valorissl_certessl_keypossono 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 righessl_cert:essl_key:(vedere il contenuto del fileiscsi.ymlriportato sopra).Eseguire il comando
ceph orch apply -i iscsi.ymlper applicare la specifica del servizio e avviare i daemon iSCSI Gateway.Rimuovere il pacchetto ceph-iscsi precedente da ciascuno dei nodi iSCSI Gateway esistenti:
cephuser@adm >zypper rm -u ceph-iscsi
7.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 versionsAssicurarsi che nessun OSD precedente si unisca al cluster:
cephuser@adm >ceph osd require-osd-release octopusAbilitare il modulo dell'utilità di dimensionamento automatico:
cephuser@adm >ceph mgr module enable pg_autoscalerImportantePer default, in SUSE Enterprise Storage 6, l'opzione
pg_autoscale_modeera impostata suwarnper 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, l'opzionepg_autoscale_modeè impostata suonper i nuovi pool e i gruppi di posizionamento vengono effettivamente sottoposti a dimensionamento automatico. Il processo di upgrade non modifica automaticamente l'opzionepg_autoscale_modedei pool esistenti. Se si desidera modificarla suonper 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 luminousAbilitare il modulo dell'utilità di bilanciamento:
cephuser@adm >ceph balancer mode upmapcephuser@adm >ceph balancer onUlteriori dettagli sono disponibili nel Sezione 29.1, «Servizio di bilanciamento».
Facoltativamente, abilitare il modulo di telemetria:
cephuser@adm >ceph mgr module enable telemetrycephuser@adm >ceph telemetry onUlteriori dettagli sono disponibili nel Sezione 29.2, «Abilitazione del modulo di telemetria».