Vai al contenutoNaviga tra le pagine: pagina precedente [tasto di scelta p]/pagina successiva [tasto di scelta n]
documentation.suse.com / Documentazione di SUSE Enterprise Storage 7 / Guida alla distribuzione / Upgrade dalle release precedenti / Upgrade da una release precedente
Si applica a SUSE Enterprise Storage 7

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-salt e cephadm.

Avvertimento
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
Importante

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.

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-notes oppure online all'indirizzo https://www.suse.com/releasenotes/.

  • Leggere il Capitolo 5, Distribuzione con cephadm 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 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
      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 patch

Dopodiché, verificare l'integrità del cluster:

cephuser@adm > ceph -s

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

  1. 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 dup seguito da reboot.

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

    Salvare il file e applicare le modifiche:

    root@master # salt '*' saltutil.refresh_pillar
  4. Assimilare la configurazione esistente:

    cephuser@adm > ceph config assimilate-conf -i /etc/ceph/ceph.conf
  5. 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 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:

  1. 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
    [...]
  2. 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 dup seguito da reboot.

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

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

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.

Nota
Nota

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 status
root@master # ceph versions
root@master # salt-run upgrade.status
  1. 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
  2. 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
  3. Disinstallare DeepSea e installare ceph-salt sul Salt Master:

    root@master # zypper remove 'deepsea*'
    root@master # zypper install ceph-salt
  4. Riavviare il Salt Master e sincronizzare i moduli Salt:

    root@master # systemctl restart salt-master.service
    root@master # salt \* saltutil.sync_all
  5. Importare la configurazione del cluster di DeepSea in ceph-salt:

    root@master # ceph-salt import ceph-salt-config.json
  6. Generare le chiavi SSH per la comunicazione tra i nodi e il cluster:

    root@master # ceph-salt config /ssh generate
    Suggerimento
    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 5.3.2, «Configurazione delle proprietà del cluster».

  7. Applicare la configurazione e abilitare cephadm:

    root@master # ceph-salt apply
  8. Se è 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».

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

    Esempio:

    root@master # ceph config set global container_image 192.168.121.1:5000/my/ceph/image
  10. 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

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

  1. Sospendere l'utilità di coordinamento:

    cephuser@adm > ceph orch pause
  2. 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
    Suggerimento

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

  3. Rimuovere Node-Exporter. Non è necessario eseguire la migrazione di tale utilità, che verrà reinstallata come container quando verrà applicato il file specs.yaml.

    tux > sudo zypper rm golang-github-prometheus-node_exporter
  4. Applicare le specifiche del servizio esportate in precedenza da DeepSea:

    cephuser@adm > ceph orch apply -i specs.yaml
  5. Riprendere 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.

  1. Creare un nuovo dominio:

    cephuser@adm > radosgw-admin realm create --rgw-realm=REALM_NAME --default
  2. 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
  3. 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
  4. 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.

    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
  5. 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 5.4.3.4, «Distribuzione degli Object Gateway» e applicarlo.

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

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

Avvertimento
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 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.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 il servizio NFS Ganesha esistente e sostituirlo con un container gestito da cephadm.

  1. Interrompere e disabilitare il servizio NFS Ganesha esistente:

    cephuser@adm > systemctl stop nfs-ganesha
    cephuser@adm > systemctl disable nfs-ganesha
  2. 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 la Sezione 5.4.2, «Specifica del servizio e del posizionamento».

  3. Applicare la specifica di posizionamento:

    cephuser@adm > ceph orch apply -i FILENAME.yaml
  4. 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/ceph/ceph:latest  8b4be7c42abd  c8b75d7c8f0d
  5. 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 7.1: Copia manuale delle esportazioni nel file di configurazione comune di NFS Ganesha
  1. 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-')
  2. 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
  3. 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"
  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
  5. Inviare una notifica al daemon NFS Ganesha:

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

    Tramite questa azione, il daemon ricaricherà la configurazione.

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

  1. 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
  2. Rimuovere 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.

  1. 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 ]
  2. 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 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
  3. Eseguire il comando ceph orch apply -i mds.yml per 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.

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

    tux > sudo systemctl stop rbd-target-gw
    tux > sudo systemctl disable rbd-target-gw
    tux > sudo systemctl stop rbd-target-api
    tux > sudo systemctl disable rbd-target-api
  2. Creare 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_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
    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).

  3. Eseguire il comando ceph orch apply -i iscsi.yml per applicare la specifica del servizio e avviare i daemon iSCSI Gateway.

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

  1. Verificare che l'upgrade del cluster sia riuscito correttamente controllando la versione corrente di Ceph:

    cephuser@adm > ceph versions
  2. Assicurarsi che nessun OSD precedente si unisca al cluster:

    cephuser@adm > ceph osd require-osd-release octopus
  3. Abilitare il modulo dell'utilità di dimensionamento automatico:

    cephuser@adm > ceph mgr module enable pg_autoscaler
    Importante
    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, 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».

  4. Impedire i client precedenti a Luminous:

    cephuser@adm > ceph osd set-require-min-compat-client luminous
  5. 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».

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