Upgrade dalle release precedenti | Guida alla distribuzione

documentation.suse.com › Documentazione di SUSE Enterprise Storage 6 › Guida alla distribuzione › Distribuzione e upgrade del cluster › Upgrade dalle release precedenti

ContenutoContenuto

Guida alla distribuzione

Navigazione←→

Si applica a SUSE Enterprise Storage 6

6 Upgrade dalle release precedenti #

6.1 Punti da tenere presente prima dell'upgrade
6.2 Backup dei dati del cluster
6.3 Esecuzione della migrazione da ntpd a chronyd
6.4 Applicazione di patch al cluster prima dell'upgrade
6.5 Verifica dell'ambiente corrente
6.6 Verifica dello stato del cluster
6.7 Upgrade offline dei cluster CTDB
6.8 Upgrade per nodo - Procedura di base
6.9 Esecuzione dell'upgrade del nodo admin
6.10 Esecuzione dell'upgrade dei nodi Ceph Monitor/Ceph Manager
6.11 Esecuzione dell'upgrade dei server di metadati
6.12 Esecuzione dell'upgrade dei Ceph OSD
6.13 Migrazione OSD a BlueStore
6.14 Esecuzione dell'upgrade dei nodi dell'applicazione
6.15 Aggiornamento di policy.cfg e distribuzione del Ceph Dashboard tramite DeepSea
6.16 Migrazione da distribuzioni basate sul profilo ai DriveGroups

Questo capitolo descrive le procedure per eseguire l'upgrade di SUSE Enterprise Storage 5.5 alla versione 6. Tenere presente che la versione 5.5 è sostanzialmente uguale alla versione 5, ma con tutte le patch più recenti applicate.

Nota: upgrade dalle release meno recenti non supportato

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

6.1 Punti da tenere presente prima dell'upgrade #

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.
Dopo aver installato il pacchetto release-notes-ses, individuare localmente le note di rilascio nella directory /usr/share/doc/release-notes o online all'indirizzo https://www.suse.com/releasenotes/.
Se in precedenza è stato eseguito l'upgrade dalla versione 4, verificare che l'upgrade alla versione 5 sia stato completato correttamente:
- Verificare la presenza del file
```
/srv/salt/ceph/configuration/files/ceph.conf.import
```
  Viene creato dal processo di importazione durante l'upgrade dalla SES 4 a SES 5. Inoltre, nel file deve essere impostata l'opzione configuration_init: default-import
```
/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
```
  Avviso: configurazione DeepSea di default
  Se non si unisce la configurazione da ceph.conf.import e si rimuove l'opzione configuration_init: default-import, le impostazioni di configurazione di default integrate in DeepSea (memorizzate in /srv/salt/ceph/configuration/files/ceph.conf.j2) non verranno applicate al cluster.
- Controllare se il cluster utilizza il nuovo tipo di compartimento "straw2":
```
cephadm@adm > ceph osd crush dump | grep straw
```
- Verificare che venga utilizzato il profilo "jewel":
```
cephadm@adm > ceph osd crush dump | grep profile
```
Se sono in uso client del kernel RBD meno recenti (precedenti a SUSE Linux Enterprise Server 12 SP3), consultare questo riferimento: Sezione 12.9, «Mappatura di RBD tramite i client del kernel meno recenti». Se possibile, si consiglia di eseguire l'upgrade dei client del kernel RBD meno recenti.
Se openATTIC si trova sul nodo admin, non sarà disponibile in seguito all'upgrade del nodo. La nuova versione del Ceph Dashboard non sarà disponibile finché non ne viene eseguita la distribuzione tramite DeepSea.
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.
Se è in esecuzione la release di SUSE Linux Enterprise Server precedente, non sarà possibile sottoporre un singolo nodo ad upgrade, ma occorrerà riavviarlo nell'utilità di installazione della nuova versione. Di conseguenza, i servizi forniti da tale nodo non saranno disponibili per qualche tempo. I Cluster Services di base saranno comunque disponibili: ad esempio, se un MON è inattivo durante l'upgrade, vi saranno almeno due MON attivi. Purtroppo, i servizi a istanza singola, come un singolo iSCSI Gateway, non saranno disponibili.
Alcuni tipi di daemon dipendono da altri. Ad esempio, i Ceph Object Gateway dipendono dai daemon Ceph MON e OSD. Si consiglia di eseguire l'upgrade in questo ordine:
1. Nodo admin
2. Ceph Monitor/Ceph Manager
3. Metadata Server
4. Ceph OSD
5. Object Gateway
6. iSCSI Gateway
7. NFS Ganesha
8. Gateway Samba
Se è stato utilizzato AppArmor nella modalità "complain" o "enforce", sarà necessario impostare una variabile salt pillar prima di eseguire l'upgrade. Poiché per default SUSE Linux Enterprise Server 15 SP1 viene fornito con AppArmor, la gestione di tale software è stata integrata nella fase 0 di DeepSea. Per default, SUSE Enterprise Storage 6 rimuove AppArmor e i profili correlati. Se si desidera mantenere il comportamento configurato in SUSE Enterprise Storage 5.5, verificare che una delle righe seguenti sia presente nel file /srv/pillar/ceph/stack/global.yml prima di avviare l'upgrade:
```
apparmor_init: default-enforce
```
oppure
```
apparmor_init: default-complain
```
A partire da SUSE Enterprise Storage 6, i nomi MDS che iniziano con una cifra non sono più consentiti e i daemon MDS non si avvieranno. È possibile verificare se i daemon sono denominati in questo modo eseguendo il comando ceph fs status oppure riavviando un MDS e controllando la presenza del messaggio seguente nei relativi log:
```
deprecation warning: MDS id 'mds.1mon1' is invalid and will be forbidden in
a future version.  MDS names may not start with a numeric digit.
```
Se viene visualizzato il messaggio riportato sopra, sarà necessario eseguire la migrazione dei nomi MDS prima di tentare di eseguire l'upgrade a SUSE Enterprise Storage 6. DeepSea coordina l'automatizzazione di tale migrazione. Nei nomi MDS che iniziano con una cifra verrà anteposto il prefisso "mds.":
```
root@master # salt-run state.orch ceph.mds.migrate-numerical-names
```
Suggerimento: configurazione personalizzata associata ai nomi MDS
Se sono presenti impostazioni di configurazione associate ai nomi MDS e i nomi dei daemon MDS iniziano con una cifra, verificare che le impostazioni di configurazione si applichino anche ai nuovi nomi (con il prefisso "mds."). Consultare la sezione di esempio seguente nel file /etc/ceph/ceph.conf:
```
[mds.123-my-mds] # config setting specific to MDS name with a name starting with a digit
mds cache memory limit = 1073741824
mds standby for name = 456-another-mds
```
L'unità di coordinamento ceph.mds.migrate-numerical-names modificherà il nome del daemon MDS "123-my-mds" in "mds.123-my-mds". È necessario modificare la configurazione per riflettere il nuovo nome:
```
[mds.mds,123-my-mds] # config setting specific to MDS name with the new name
mds cache memory limit = 1073741824
mds standby for name = mds.456-another-mds
```
Questa operazione consente di aggiungere i daemon MDS con i nuovi nomi prima di rimuovere quelli precedenti. Il numero di daemon MDS raddoppierà per un breve intervallo di tempo. I client potranno accedere a CephFS solo dopo una breve pausa per il failover. Pertanto, conviene pianificare la migrazione in orari in cui sono previsti carichi CephFS minimi o nulli.

6.2 Backup dei dati del cluster #

Sebbene la creazione di backup dei dati e della configurazione del cluster non sia obbligatoria, si consiglia di eseguire il backup dei dati del cluster e dei file di configurazione importanti. Per ulteriori dettagli, consultare la pagina all'indirizzo Capitolo 3, Backup della configurazione e dei dati del cluster.

6.3 Esecuzione della migrazione da `ntpd` a `chronyd` #

SUSE Linux Enterprise Server 15 SP1 non utilizza più ntpd per la sincronizzazione dell'ora dell'host locale. Adesso, viene utilizzato chronyd. La migrazione del daemon di sincronizzazione dell'orario deve essere eseguita in ciascun nodo del cluster. La migrazione a chronyd può avvenire prima dell'upgrade del cluster; in alternativa è possibile eseguire la migrazione a chronyd dopo l'upgrade del cluster.

Procedura 6.1: Eseguire la migrazione a `chronyd` prima dell'upgrade del cluster #

Installare il pacchetto chrony :
```
root@minion > zypper install chrony
```
Modificare il file di configurazione di chronyd /etc/chrony.conf e aggiungere le origini NTP della configurazione ntpd corrente in /etc/ntp.conf.
Suggerimento: ulteriori dettagli sulla configurazione di chronyd
Consultare la pagina all'indirizzo https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html per ulteriori dettagli su come includere le origini dell'orario nella configurazione di chronyd.

Disabilitare e interrompere il servizio ntpd:

root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service

Avviare e abilitare il servizio di chronyd:

root@minion > systemctl start chronyd.service && systemctl enable chronyd.service

Verificare lo stato di chrony:
```
root@minion > chronyc tracking
```

Procedura 6.2: Eseguire la migrazione a `chronyd` dopo l'upgrade del cluster #

Durante l'upgrade del cluster, aggiungere i seguenti archivi software:
- SLE-Module-Legacy15-SP1-Pool
- SLE-Module-Legacy15-SP1-Updates
Eseguire l'upgrade del cluster alla versione 6.
Modificare il file di configurazione di chronyd /etc/chrony.conf e aggiungere le origini NTP della configurazione ntpd corrente in /etc/ntp.conf.
Suggerimento: ulteriori dettagli sulla configurazione di chronyd
Consultare la pagina all'indirizzo https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html per ulteriori dettagli su come includere le origini dell'orario nella configurazione di chronyd.

Disabilitare e interrompere il servizio ntpd:

root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service

Avviare e abilitare il servizio di chronyd:

root@minion > systemctl start chronyd.service && systemctl enable chronyd.service

Eseguire la migrazione da ntpd a chronyd.
Verificare lo stato di chrony:
```
root@minion > chronyc tracking
```
Rimuovere gli archivi software esistenti aggiunti per mantenere ntpd nel sistema durante la procedura di upgrade.

6.4 Applicazione di patch al cluster prima dell'upgrade #

Applicare le patch più recenti a tutti i nodi del cluster prima di eseguire l'upgrade.

6.4.1 Archivi software obbligatori #

Verificare che gli archivi obbligatori siano configurati in ciascun nodo del cluster. Per visualizzare un elenco di tutti gli archivi disponibili, eseguire

root@minion > zypper lr

SUSE Enterprise Storage 5.5 richiede:

SLES12-SP3-Installer-Updates
SLES12-SP3-Pool
SLES12-SP3-Updates
SUSE-Enterprise-Storage-5-Pool
SUSE-Enterprise-Storage-5-Updates

Il gateway NFS/SMB su SLE-HA in SUSE Linux Enterprise Server 12 SP3 richiede:

SLE-HA12-SP3-Pool
SLE-HA12-SP3-Updates

6.4.2 Sistemi di gestione provvisoria dell'archivio #

Se si utilizza uno dei sistemi di gestione provvisoria dell'archivio (SMT, RMT o SUSE Manager), creare un nuovo livello di patch bloccato per la versione corrente e per quella nuova di SUSE Enterprise Storage.

Per ulteriori informazioni, vedere:

6.4.3 Applicazione delle patch più recenti a tutto il cluster #

Applicare le patch più recenti di SUSE Enterprise Storage 5.5 e SUSE Linux Enterprise Server 12 SP3 a ciascun nodo del cluster Ceph. Verificare che a ogni nodo del cluster siano connessi gli archivi software corretti (vedere la Sezione 6.4.1, «Archivi software obbligatori») ed eseguire la fase 0 di DeepSea:
```
root@master # salt-run state.orch ceph.stage.0
```
Al completamento della fase 0, verificare che nello stato di ogni nodo del cluster sia incluso il testo "HEALTH_OK". Se non lo è, risolvere il problema prima dei possibili riavvii previsti nelle fasi successive.
Eseguire zypper ps per verificare la presenza di processi in esecuzione con librerie o binari meno recenti e riavviarli.
Verificare che il kernel in esecuzione sia il più recente disponibile e riavviarlo in caso contrario. Controllare gli output dei comandi seguenti:
```
cephadm@adm > uname -a
cephadm@adm > rpm -qa kernel-default
```
Verificare che la versione del pacchetto ceph sia 12.2.12 o precedente. Verificare che la versione del pacchetto deepsea sia 0.8.9 o precedente.
Se in precedenza è stata utilizzata una delle impostazioni bluestore_cache, tenere presente che queste non sono più effettive a partire dalla versione 12.2.10 di ceph. La nuova impostazione bluestore_cache_autotune, configurata su "true" per default, disabilita il dimensionamento manuale della cache. Per attivare il comportamento precedente, è necessario impostare bluestore_cache_autotune=false. Per ulteriori dettagli, vedere Sezione 16.2.1, «Ridimensionamento automatico della cache».

6.5 Verifica dell'ambiente corrente #

Correggere gli eventuali problemi evidenti del sistema prima di avviare l'upgrade. Il processo di upgrade non corregge mai i problemi di sistema esistenti.
Verificare le prestazioni del cluster. È possibile utilizzare comandi come rados bench, ceph tell osd.* bench oppure iperf3.
Verificare l'accesso ai gateway (come iSCSI Gateway oppure Object Gateway) e al dispositivo di blocco RADOS.
Documentare le parti specifiche della configurazione di sistema, come i dettagli della configurazione di rete, del partizionamento o dell'installazione.
Utilizzare supportconfig per raccogliere le informazioni di sistema importanti e salvarle al di fuori dei nodi del cluster. Per ulteriori informazioni, vedere https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_admsupport_supportconfig.html.
Assicurarsi che in ciascun nodo del cluster sia disponibile sufficiente spazio libero su disco. Verificare lo spazio libero su disco con df-h. Se necessario, liberare dello spazio sul disco rimuovendo le directory/i file non necessari o le snapshot del sistema operativo obsolete. Se lo spazio libero sul disco non è sufficiente, non proseguire con l'upgrade finché non si sarà liberato spazio sufficiente.

6.6 Verifica dello stato del cluster #

Verificare il comando cluster health prima di avviare la procedura di upgrade. Non avviare l'upgrade a meno che ogni su ogni nodo del cluster non sia riportato il testo "HEALTH_OK".
Verificare che tutti i servizi siano in esecuzione:
- Salt master e daemon Salt master.
- Ceph Monitor e Ceph Manager Daemon.
- Daemon del server di metadati.
- Daemon Ceph OSD.
- Daemon Object Gateway.
- Daemon iSCSI Gateway.

I comandi seguenti forniscono i dettagli dello stato del cluster e della configurazione specifica:

ceph -s

Stampa un breve riepilogo sullo stato del cluster Ceph, sui servizi in esecuzione, sull'utilizzo dei dati e sulle statistiche I/O. Verificare che sia presente il testo "HEALTH_OK" prima di avviare l'upgrade.

ceph health detail

Stampa i dettagli se lo stato del cluster Ceph non è valido.

ceph versions

Stampa le versioni dei daemon Ceph in esecuzione.

ceph df

Stampa lo spazio totale e libero su disco del cluster. Non avviare l'upgrade se lo spazio libero su disco del cluster è inferiore al 25% dello spazio su disco totale.

salt '*' cephprocesses.check results=true

Stampa i processi Ceph in esecuzione e i relativi PID ordinati in base ai Salt minion.

ceph osd dump | grep ^flags

Verificare che siano presenti i flag "recovery_deletes" e "purged_snapdirs". Se non lo sono, è possibile forzare una pulitura su tutti i gruppi di posizionamento eseguendo il comando seguente. Si tenga presente che questa pulitura forzata ha un impatto negativo sulle prestazioni dei client Ceph.

cephadm@adm > ceph pg dump pgs_brief | cut -d " " -f 1 | xargs -n1 ceph pg scrub

6.7 Upgrade offline dei cluster CTDB #

CTDB fornisce un database gestito in cluster utilizzato dai gateway Samba. Il protocollo CTDB è molto semplice e non supporta i cluster dei nodi che comunicano con versioni di protocollo diverse. Pertanto, occorre impostare i nodi CTDB sullo stato offline prima di eseguire l'upgrade.

6.8 Upgrade per nodo - Procedura di base #

Per assicurarsi che i Cluster Services di base del cluster siano disponibili durante la procedura, è necessario eseguire l'upgrade dei nodi in modo sequenziale. È possibile eseguire l'upgrade di un nodo in due modi diversi: tramite il DVD del programma di installazione o tramite il sistema di migrazione della distribuzione.

Dopo aver eseguito l'upgrade di tutti i nodi, si consiglia di eseguire rpmconfigcheck per verificare la presenza di eventuali file di configurazione modificati in locale. Se il comando restituisce un elenco di nomi di file con un suffisso .rpmnew, .rpmorig o .rpmsave, confrontare tali file con i file di configurazione correnti per assicurarsi che nessuna modifica locale sia andata persa. Se necessario, aggiornare i file interessati. Per ulteriori informazioni su come utilizzare i file .rpmnew, .rpmorig e .rpmsave, consultare la pagina all'indirizzo https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-sw-cl.html#sec-rpm-packages-manage.

Suggerimento: pacchetti orfani

In seguito all'upgrade di un nodo, alcuni pacchetti saranno nello stato orfano ("orphaned") e non disporranno di un archivio superiore. Ciò si verifica perché i pacchetti relativi a python3 non rendono obsoleti i pacchetti python2.

All'indirizzo https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_zypper.html#sec_zypper_softup_orphaned sono disponibili ulteriori informazioni sugli elenchi dei pacchetti orfani.

6.8.1 Esecuzione dell'upgrade manuale dei nodi tramite il DVD del programma di installazione #

Riavviare il nodo dall'immagine o dal DVD del programma di installazione di SUSE Linux Enterprise Server 15 SP1.
Selezionare Upgrade (Esegui l'upgrade) dal menu di avvio.
Nella schermata (Seleziona destinazione di migrazione), verificare che "SUSE Linux Enterprise Server 15 SP1" sia selezionato e attivare la casella di controllo Manually Adjust the Repositories for Migration (Modifica manualmente gli archivi per la migrazione).
Figura 6.1: Selezione della destinazione della migrazione #
Selezionare i moduli seguenti da installare:
- SUSE Enterprise Storage 6 x86_64
- Basesystem Module 15 SP1 x86_64
- Desktop Applications Module 15 SP1 x86_64
- Legacy Module 15 SP1 x86_64
- Server Applications Module 15 SP1 x86_64
Nella schermata Previously Used Repositories (Archivi utilizzati in precedenza), verificare che siano stati selezionati gli archivi corretti. Se il sistema non è registrato su SCC/SMT, è necessario aggiungere gli archivi manualmente.
SUSE Enterprise Storage 6 richiede:
- SLE-Module-Basesystem15-SP1-Pool
- SLE-Module-Basesystem15-SP1-Updates
- SLE-Module-Server-Applications15-SP1-Pool
- SLE-Module-Server-Applications15-SP1-Updates
- SLE-Module-Desktop-Applications15-SP1-Pool
- SLE-Module-Desktop-Applications15-SP1-Updates
- SLE-Product-SLES15-SP1-Pool
- SLE-Product-SLES15-SP1-Updates
- SLE15-SP1-Installer-Updates
- SUSE-Enterprise-Storage-6-Pool
- SUSE-Enterprise-Storage-6-Updates
Se si intende eseguire la migrazione di ntpd a chronyd dopo la migrazione di SES (fare riferimento alla Sezione 6.3, «Esecuzione della migrazione da ntpd a chronyd»), includere gli archivi seguenti:
- SLE-Module-Legacy15-SP1-Pool
- SLE-Module-Legacy15-SP1-Updates
Il gateway NFS/SMB su SLE-HA su SUSE Linux Enterprise Server 15 SP1 richiede:
- SLE-Product-HA15-SP1-Pool
- SLE-Product-HA15-SP1-Updates
Rivedere le impostazioni di installazione e avviare la procedura di installazione facendo clic su Aggiorna.

6.8.2 Esecuzione dell'upgrade del nodo tramite il Distribution Migration System di SUSE #

Il Distribution Migration System (DMS) fornisce un percorso di upgrade per un sistema SUSE Linux Enterprise installato da una versione principale a un'altra. Nella procedura seguente viene utilizzato DMS per eseguire l'upgrade di SUSE Enterprise Storage 5.5 alla versione 6, inclusa la migrazione sottostante da SUSE Linux Enterprise Server 12 SP3 a SUSE Linux Enterprise Server 15 SP1.

Consultare la pagina all'indirizzo https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/distribution-migration-system/ per informazioni generali e dettagliate su DMS.

Installare i pacchetti di migrazione RPM che consentono di impostare il boot loader GRUB sull'attivazione automatica dell'upgrade al riavvio successivo. Installare i pacchetti SLES15-SES-Migration e suse-migration-sle15-activation :
```
root@minion > zypper install SLES15-SES-Migration suse-migration-sle15-activation
```
1. Se il nodo in fase di upgrade è registrato su un sistema di gestione provvisoria dell'archivio come SCC, SMT, RMT o SUSE Manager, creare il file /etc/sle-migration-service.yml con il contenuto seguente:
```
use_zypper_migration: true
preserve:
  rules:
    - /etc/udev/rules.d/70-persistent-net.rules
```
2. Se il nodo in fase di upgrade non è registrato su un sistema di gestione provvisoria dell'archivio come SCC, SMT, RMT o SUSE Manager, apportare le modifiche seguenti:
  1. Creare il file /etc/sle-migration-service.yml con il contenuto seguente:
```
use_zypper_migration: false
preserve:
  rules:
    - /etc/udev/rules.d/70-persistent-net.rules
```
  2. Disabilitare o rimuovere gli archivi SLE 12 SP3 e SES 5 e aggiungere gli archivi SLE 15 SP1 e SES6. Nella Sezione 6.4.1, «Archivi software obbligatori» è riportato l'elenco degli archivi correlati.
Riavviare per eseguire l'upgrade. Mentre l'upgrade è in corso, è possibile eseguire il login al nodo di cui è stato eseguito l'upgrade tramite ssh come utente della migrazione utilizzando la chiave SSH esistente del sistema host, come descritto nella pagina all'indirizzo https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/distribution-migration-system/. Per SUSE Enterprise Storage, se si dispone dell'accesso fisico o dell'accesso diretto alla console sul computer, è possibile inoltre eseguire il login come root alla console di sistema tramite la password sesupgrade. In seguito all'upgrade, il nodo verrà riavviato automaticamente.
Suggerimento: upgrade non riuscito
Se l'upgrade non riesce, esaminare /var/log/distro_migration.log. Risolvere il problema, installare nuovamente i pacchetti RPM di migrazione e riavviare il nodo.

6.9 Esecuzione dell'upgrade del nodo admin #

I comandi seguenti continueranno a funzionare, anche se sui Salt minion sono in esecuzione versioni meno recenti di Ceph e Salt: salt '*' test.ping e ceph status
In seguito all'upgrade del nodo admin, openATTIC non sarà più installato.
Se sul nodo admin è ospitato SMT, completarne la migrazione a RMT (consultare la pagina all'indirizzo https://www.suse.com/documentation/sles-15/book_rmt/data/cha_rmt_migrate.html).
Seguire la procedura descritta nella Sezione 6.8, «Upgrade per nodo - Procedura di base».

Suggerimento: stato dei nodi del cluster

In seguito all'upgrade del nodo admin, è possibile eseguire il comando salt-run upgrade.status per visualizzare informazioni utili sui nodi del cluster. Questo comando elenca le versioni di Ceph e del sistema operativo di tutti i nodi e suggerisce in che ordine eseguire l'upgrade dei nodi su cui sono ancora in esecuzione le versioni meno recenti.

root@master # salt-run upgrade.status
The newest installed software versions are:
  ceph: ceph version 14.2.1-468-g994fd9e0cc (994fd9e0ccc50c2f3a55a3b7a3d4e0ba74786d50) nautilus (stable)
  os: SUSE Linux Enterprise Server 15 SP1

Nodes running these software versions:
  admin.ceph (assigned roles: master)
  mon2.ceph (assigned roles: admin, mon, mgr)

Nodes running older software versions must be upgraded in the following order:
   1: mon1.ceph (assigned roles: admin, mon, mgr)
   2: mon3.ceph (assigned roles: admin, mon, mgr)
   3: data1.ceph (assigned roles: storage)
[...]

6.10 Esecuzione dell'upgrade dei nodi Ceph Monitor/Ceph Manager #

Se il cluster non utilizza i ruoli MDS, eseguire l'upgrade dei nodi MON/MGR uno alla volta.
Se il cluster utilizza i ruoli MDS e i ruoli MON/MGR e MDS sono co-ubicati, è necessario ridurre il cluster MDS e quindi eseguire l'upgrade dei nodi co-ubicati. Per ulteriori dettagli, fare riferimento alla Sezione 6.11, «Esecuzione dell'upgrade dei server di metadati».
Se il cluster utilizza i ruoli MDS e se questi sono in esecuzione su server dedicati, eseguire l'upgrade dei nodi MON/MGR uno alla volta, quindi ridurre il cluster MDS ed eseguirne l'upgrade. Per ulteriori dettagli, fare riferimento alla Sezione 6.11, «Esecuzione dell'upgrade dei server di metadati».

Nota: upgrade di Ceph Monitor

A causa di una limitazione della progettazione di Ceph Monitor, dopo l'upgrade di due MON a Suse Enterprise Storage 6 e la conseguente formazione di un quorum, il terzo MON (ancora su SUSE Enterprise Storage 5.5) non si unirà al cluster MON se quest'ultimo è stato riavviato per qualsiasi motivo, incluso per un riavvio del nodo. Pertanto, in seguito all'upgrade di due MON, è consigliabile eseguire l'upgrade dei MON restanti il prima possibile.

Seguire la procedura descritta nella Sezione 6.8, «Upgrade per nodo - Procedura di base».

6.11 Esecuzione dell'upgrade dei server di metadati #

È necessario ridurre il cluster del server di metadati (MDS) A causa di funzioni incompatibili tra le versioni 5.5 e 6 di SUSE Enterprise Storage, i daemon MDS meno recenti verranno chiusi non appena un MDS singolo del livello SES 6 si unisce al cluster. Di conseguenza, per tutta la durata dei processi di upgrade del nodo MDS, è necessario ridurre il cluster MDS a un MDS singolo attivo (e non di standby). Non appena viene eseguito l'upgrade del secondo nodo, è possibile estendere nuovamente il cluster MDS.

Suggerimento

Sui cluster MDS con carico elevato, potrebbe essere necessario ridurre tale carico (ad esempio interrompendo i client) per fare in modo che un MDS singolo attivo possa gestire il workload.

Notare il valore attuale dell'opzione max_mds:

cephadm@adm > ceph fs get cephfs | grep max_mds

Ridurre il cluster MDS se è presente più di 1 daemon MDS attivo, ad es. max_mds è maggiore di 1. Per ridurre il cluster MDS, eseguire
```
cephadm@adm > ceph fs set FS_NAME max_mds 1
```
dove FS_NAME è il nome dell'istanza CephFS ("cephfs" per default).

Individuare il nodo su cui è ospitato uno dei daemon MDS di standby. Esaminare l'output del comando ceph fs status e avviare l'upgrade del cluster MDS su questo nodo.

cephadm@adm > ceph fs status
cephfs - 2 clients
======
+------+--------+--------+---------------+-------+-------+
| Rank | State  |  MDS   |    Activity   |  dns  |  inos |
+------+--------+--------+---------------+-------+-------+
|  0   | active | mon1-6 | Reqs:    0 /s |   13  |   16  |
+------+--------+--------+---------------+-------+-------+
+-----------------+----------+-------+-------+
|       Pool      |   type   |  used | avail |
+-----------------+----------+-------+-------+
| cephfs_metadata | metadata | 2688k | 96.8G |
|   cephfs_data   |   data   |    0  | 96.8G |
+-----------------+----------+-------+-------+
+-------------+
| Standby MDS |
+-------------+
|    mon3-6   |
|    mon2-6   |
+-------------+

In questo esempio, è necessario avviare la procedura di upgrade sul nodo "mon3-6" o "mon2-6".

Eseguire l'upgrade del nodo con il daemon MDS di standby. In seguito all'avvio dell'upgrade del nodo MDS, i daemon MDS obsoleti verranno chiusi automaticamente. A questo punto, potrebbe verificarsi un breve tempo di fermo del servizio CephFS sui client.
Seguire la procedura descritta nella Sezione 6.8, «Upgrade per nodo - Procedura di base».
Eseguire l'upgrade dei nodi MDS rimanenti.

Reimpostare max_mds alla configurazione desiderata:

cephadm@adm > ceph fs set FS_NAME max_mds ACTIVE_MDS_COUNT

6.12 Esecuzione dell'upgrade dei Ceph OSD #

Per ciascun nodo di storage, seguire la procedura indicata di seguito:

Identificare i daemon OSD in esecuzione su un determinato nodo:
```
cephadm@osd > ceph osd tree
```

Impostare il flag "noout" per ciascun daemon OSD sul nodo in fase di upgrade:

cephadm@osd > ceph osd add-noout osd.OSD_ID

Ad esempio:

cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd add-noout osd.$i; done

Verificare con:

cephadm@osd > ceph health detail | grep noout

oppure

cephadm@osd > ceph –s
cluster:
 id:     44442296-033b-3275-a803-345337dc53da
 health: HEALTH_WARN
      6 OSDs or CRUSH {nodes, device-classes} have {NOUP,NODOWN,NOIN,NOOUT} flags set

Creare i file /etc/ceph/osd/*.json per tutti gli OSD esistenti eseguendo il comando seguente sul nodo su cui verrà eseguito l'upgrade:
```
cephadm@osd > ceph-volume simple scan --force
```
Eseguire l'upgrade del nodo OSD. Seguire la procedura descritta nella Sezione 6.8, «Upgrade per nodo - Procedura di base».

Attivare tutti gli OSD trovati nel sistema:

cephadm@osd > ;ceph-volume simple activate --all

Suggerimento: attivazione individuale delle partizioni dei dati

Se si desidera attivare le partizioni dei dati individualmente, è necessario trovare il comando ceph-volume corretto per ciascuna partizione. Sostituire X1 con la lettera o il numero corretto della partizione:

 cephadm@osd > ceph-volume simple scan /dev/sdX1

Ad esempio:

cephadm@osd > ceph-volume simple scan /dev/vdb1
[...]
--> OSD 8 got scanned and metadata persisted to file:
/etc/ceph/osd/8-d7bd2685-5b92-4074-8161-30d146cd0290.json
--> To take over management of this scanned OSD, and disable ceph-disk
and udev, run:
-->     ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290

L'ultima riga dell'output contiene il comando per l'attivazione della partizione:

cephadm@osd > ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290
[...]
--> All ceph-disk systemd units have been disabled to prevent OSDs
getting triggered by UDEV events
[...]
Running command: /bin/systemctl start ceph-osd@8
--> Successfully activated OSD 8 with FSID
d7bd2685-5b92-4074-8161-30d146cd0290

Verificare che il nodo OSD venga avviato correttamente dopo il riavvio.

Indirizzare il messaggio "Legacy BlueStore stats reporting detected on XX OSD(s)":

cephadm@osd > ceph –s
cluster:
 id:     44442296-033b-3275-a803-345337dc53da
 health: HEALTH_WARN
 Legacy BlueStore stats reporting detected on 6 OSD(s)

Tale avviso viene visualizzato durante l'upgrade di Ceph alla versione 14.2.2. Per disabilitarlo, impostare:

bluestore_warn_on_legacy_statfs = false

La correzione più adatta consiste nell'eseguire il comando indicato di seguito su tutti gli OSD mentre si trovano nello stato di interruzione:

cephadm@osd > ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-XXX

Di seguito è riportato uno script di supporto che esegue ceph-bluestore-tool repair per tutti gli OSD sul nodo NODE_NAME:

OSDNODE=OSD_NODE_NAME;\
 for OSD in $(ceph osd ls-tree $OSDNODE);\
 do echo "osd=" $OSD;\
 salt $OSDNODE cmd.run 'systemctl stop ceph-osd@$OSD';\
 salt $OSDNODE cmd.run 'ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-$OSD';\
 salt $OSDNODE cmd.run 'systemctl start ceph-osd@$OSD';\
 done

Annullare l'impostazione del flag "noout" per ciascun daemon OSD sul nodo in fase di upgrade:

cephadm@osd > ceph osd rm-noout osd.OSD_ID

Ad esempio:

cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd rm-noout osd.$i; done

Verificare con:

cephadm@osd > ceph health detail | grep noout

Nota:

cephadm@osd > ceph –s
cluster:
 id:     44442296-033b-3275-a803-345337dc53da
 health: HEALTH_WARN
 Legacy BlueStore stats reporting detected on 6 OSD(s)

Verificare lo stato del cluster. Sarà analogo all'output seguente:

cephadm@osd > ceph status
cluster:
  id:     e0d53d64-6812-3dfe-8b72-fd454a6dcf12
  health: HEALTH_WARN
          3 monitors have not enabled msgr2

services:
  mon: 3 daemons, quorum mon1,mon2,mon3 (age 2h)
  mgr: mon2(active, since 22m), standbys: mon1, mon3
  osd: 30 osds: 30 up, 30 in

data:
  pools:   1 pools, 1024 pgs
  objects: 0 objects, 0 B
  usage:   31 GiB used, 566 GiB / 597 GiB avail
  pgs:     1024 active+clean

Verificare che tutti i nodi OSD siano stati riavviati e che gli OSD si siano avviati automaticamente in seguito al riavvio.

6.13 Migrazione OSD a BlueStore #

OSD BlueStore è un nuovo back-end per i daemon OSD. È l'opzione predefinita da SUSE Enterprise Storage 5. Rispetto a FileStore, che memorizza gli oggetti come file in un file system XFS, BlueStore è in grado di fornire prestazioni migliori perché memorizza gli oggetti direttamente sul dispositivo di blocco sottostante. BlueStore dispone inoltre di altre funzionalità, come la compressione integrata e sovrascrittura EC, non disponibili in FileStore.

Specificamente per BlueStore, un OSD ha un dispositivo "wal" (Write Ahead Log) e un dispositivo "db" (RocksDB database). Il database RocksDB contiene i metadati per un OSD BlueStore. Questi due dispositivi risiedono di default sullo stesso dispositivo di un OSD, ma è possibile posizionare uno o l'altro su supporti diversi, ad esempio più veloci.

In SUSE Enterprise Storage 5, sono supportati FileStore e BlueStore ed è possibile che gli OSD FileStore e BlueStore coesistano in un singolo cluster. Durante la procedura di upgrade di SUSE Enterprise Storage, gli OSD FileStore non vengono convertiti automaticamente a BlueStore. Ricordare che le funzionalità specifiche di BlueStore non sono disponibili sugli OSD non migrati a BlueStore.

Prima della conversione a BlueStore, gli OSD devono eseguire SUSE Enterprise Storage 5. La conversione è un processo lento, in quanto tutti i dati vengono riscritti due volte. Benché il processo di migrazione possa richiedere molto tempo per il completamento, non vi è interruzione dell'attività del cluster e tutti i client possono continuare ad accedere al cluster durante questo periodo. Tuttavia, durante il processo di migrazione le prestazioni saranno ridotte, perché i dati del cluster vengono ribilanciati e ricostituiti.

Per migrare gli OSD FileStore a BlueStore, utilizzare la procedura seguente:

Suggerimento: disattivare tutte le misure di sicurezza

I comandi Salt necessari per eseguire la migrazione sono bloccati da misure di sicurezza. Per disattivare queste precauzioni, eseguire questo comando:

 root@master # salt-run disengage.safety

Ricompilare i nodi prima di continuare:

 root@master #  salt-run rebuild.node TARGET

È inoltre possibile scegliere di ricompilare ciascun nodo individualmente. Ad esempio:

root@master #  salt-run rebuild.node data1.ceph

rebuild.node consente sempre di rimuovere e creare nuovamente tutti gli OSD sul nodo.

Importante

Se la conversione di un OSD non riesce, l'esecuzione di una nuova ricompilazione distruggerà gli OSD BlueStore già convertiti. Invece di ripetere la ricompilazione, è possibile eseguire:

root@master # salt-run disks.deploy TARGET

Dopo la migrazione a BlueStore, il numero di oggetti rimane lo stesso e l'utilizzo del disco quasi uguale.

6.14 Esecuzione dell'upgrade dei nodi dell'applicazione #

Eseguire l'upgrade dei nodi dell'applicazione nell'ordine seguente:

Object Gateway
- Se gli Object Gateway sono diretti da un servizio di bilanciamento del carico, è possibile eseguire un upgrade in sequenza di questi ultimi senza interruzioni.
- Verificare che i daemon Object Gateway siano in esecuzione dopo ogni upgrade ed effettuare dei test con il client S3/Swift.
- Seguire la procedura descritta nella Sezione 6.8, «Upgrade per nodo - Procedura di base».
iSCSI Gateway
- Se per gli iniziatori iSCSI è attiva la configurazione multipath, è possibile eseguire un upgrade in sequenza degli iSCSI Gateway senza interruzioni.
- Convalidare l'esecuzione del daemon lrbd dopo ogni upgrade ed effettuare il test con l'iniziatore.
- Seguire la procedura descritta nella Sezione 6.8, «Upgrade per nodo - Procedura di base».
NFS Ganesha. Seguire la procedura descritta nella Sezione 6.8, «Upgrade per nodo - Procedura di base».
Gateway Samba. Seguire la procedura descritta nella Sezione 6.8, «Upgrade per nodo - Procedura di base».

6.15 Aggiornamento di `policy.cfg` e distribuzione del Ceph Dashboard tramite DeepSea #

Sul nodo admin, modificare /srv/pillar/ceph/proposals/policy.cfg e applicare le modifiche seguenti:

Importante: nuovi servizi non consentiti

Durante l'upgrade del cluster, non aggiungere nuovi servizi al file policy.cfg. Modificare l'architettura del cluster soltanto al termine dell'upgrade.

Rimuovere role-openattic.
Aggiungere role-prometheus e role-grafana al nodo su cui sono stati installati Prometheus e Grafana, di solito il nodo admin.
Il ruolo profile-PROFILE_NAME viene adesso ignorato. Aggiungere il nuovo ruolo corrispondente, la riga role-storage. Ad esempio, per l'esistente
```
profile-default/cluster/*.sls
```
aggiungere
```
role-storage/cluster/*.sls
```

Sincronizzare tutti i moduli Salt:

root@master # salt '*' saltutil.sync_all

Aggiornare salt pillar eseguendo le fasi 1 e 2 di DeepSea:

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

Ripulire openATTIC:

root@master # salt OA_MINION state.apply ceph.rescind.openattic
root@master # salt OA_MINION state.apply ceph.remove.openattic

Annullare l'impostazione del grain "restart_igw" per impedire che iSCSI Gateway, che non è stato ancora installato, venga riavviato durante la fase 0:
```
Salt mastersalt '*' grains.delkey restart_igw
```
Infine, eseguire le fasi 0-4 di DeepSea:
```
root@master # salt-run state.orch ceph.stage.0
root@master # salt-run state.orch ceph.stage.1
root@master # salt-run state.orch ceph.stage.2
root@master # salt-run state.orch ceph.stage.3
root@master # salt-run state.orch ceph.stage.4
```
Suggerimento: errori "subvolume missing" durante la fase 3
La fase 3 di DeepSea potrebbe generare un errore simile al seguente:
```
subvolume : ['/var/lib/ceph subvolume missing on 4510-2', \
'/var/lib/ceph subvolume missing on 4510-1', \
[...]
'See /srv/salt/ceph/subvolume/README.md']
```
In questo caso, è necessario modificare il file /srv/pillar/ceph/stack/global.yml e aggiungere la riga seguente:
```
subvolume_init: disabled
```
Quindi, aggiornare salt pillar ed eseguire nuovamente la fase 3 di DeepSea:
```
root@master # salt '*' saltutil.refresh_pillar
 root@master # salt-run state.orch ceph.stage.3
```
Al completamento della fase 3 di DeepSea, verrà eseguito il Ceph Dashboard. Per una panoramica dettagliata delle funzioni del Ceph Dashboard, consultare questo riferimento: Capitolo 22, Ceph Dashboard.
Per visualizzare un elenco dei nodi che eseguono il dashboard, eseguire:
```
cephadm@adm > ceph mgr services | grep dashboard
```
Per visualizzare un elenco delle credenziali amministratore, eseguire:
```
root@master # salt-call grains.get dashboard_creds
```
Riavviare in sequenza i servizi Object Gateway per utilizzare il server Web "beast" al posto del server "civetweb" obsoleto:
```
root@master # salt-run state.orch ceph.restart.rgw.force
```
Prima di continuare, si consiglia di abilitare il modulo di telemetria Ceph. Per ulteriori informazioni e istruzioni, consultare questo riferimento: Sezione 10.2, «Modulo di telemetria».

6.16 Migrazione da distribuzioni basate sul profilo ai DriveGroups #

In SUSE Enterprise Storage 5.5, tramite DeepSea erano disponibili i cosiddetti "profili" per la descrizione del layout degli OSD. A partire da SUSE Enterprise Storage 6, viene utilizzato un approccio diverso denominato DriveGroups (ulteriori dettagli nella Sezione 5.5.2, «DriveGroups»).

Nota

La migrazione al nuovo approccio non è immediatamente obbligatoria. Le operazioni distruttive, come salt-run osd.remove, salt-run osd.replace o salt-run osd.purge sono ancora disponibili. Tuttavia, per l'aggiunta di nuovi OSD è necessario l'intervento dell'utente.

Per via del diverso approccio di tali implementazioni, non viene offerto un percorso di migrazione automatico. Tuttavia, per semplificare il più possibile la migrazione, sono disponibili diversi strumenti (strumenti di esecuzione Salt).

6.16.1 Analisi del layout corrente #

Per visualizzare le informazioni sugli OSD attualmente distribuiti, utilizzare il comando seguente:

root@master # salt-run disks.discover

In alternativa, è possibile analizzare il contenuto dei file nelle directory /srv/pillar/ceph/proposals/profile-*/. La struttura è analoga alla seguente:

ceph:
  storage:
    osds:
      /dev/disk/by-id/scsi-drive_name: format: bluestore
      /dev/disk/by-id/scsi-drive_name2: format: bluestore

6.16.2 Creazione di DriveGroups corrispondenti al layout corrente #

Per ulteriori dettagli sulla specifica dei DriveGroups, fare riferimento alla Sezione 5.5.2.1, «Specifica».

La differenza tra una distribuzione da zero e uno scenario di upgrade consiste nel fatto che le unità da migrare sono già "utilizzate". Poiché

root@master # salt-run disks.list

cerca soltanto i dischi non utilizzati, utilizzare

root@master # salt-run disks.list include_unavailable=True

Modificare i DriveGroups finché non viene trovata una corrispondenza con la configurazione corrente. Per una rappresentazione visiva della procedura, utilizzare il comando seguente. Si noti che non verrà restituito alcun output se non sono presenti dischi liberi:

root@master # salt-run disks.report bypass_pillar=True

Se dopo aver verificato che i DriveGroups siano stati configurati correttamente si desidera applicare il nuovo approccio, rimuovere i file dalla directory /srv/pillar/ceph/proposals/profile-PROFILE_NAME/, rimuovere le righe profile-PROFILE_NAME/cluster/*.sls corrispondenti dal file /srv/pillar/ceph/proposals/policy.cfg ed eseguire la fase 2 di DeepSea per aggiornare salt pillar.

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

Verificare i risultati eseguendo i comandi seguenti:

root@master # salt target_node pillar.get ceph:storage
root@master # salt-run disks.report

Avviso: configurazione errata dei DriveGroups

Se i DriveGroups non sono configurati correttamente e se nella configurazione sono presenti dischi di riserva, questi verranno distribuiti nel modo in cui sono stati specificati dall'utente. Si consiglia di eseguire:

root@master # salt-run disks.report

6.16.3 Distribuzione OSD #

Per i casi più semplici, come gli OSD stand-alone, la migrazione verrà eseguita nel tempo. Ogni volta che si rimuove o si sostituisce un OSD nel cluster, il nuovo OSD sarà basato su LVM.

Suggerimento: esecuzione della migrazione al formato LVM

Ogni volta che è necessario sostituire un singolo OSD "esistente" su un nodo, occorre eseguire la migrazione al formato basato su LVM di tutti gli OSD che condividono i dispositivi con l'OSD sostituito.

Per completezza, considerare di eseguire la migrazione degli OSD su tutto il nodo.

6.16.4 Configurazioni più complesse #

Se la configurazione attiva è più complessa rispetto a quella dei semplici OSD stand-alone, se ad esempio sono presenti OSD crittografati o WAL/DB dedicati, è possibile eseguire la migrazione soltanto se tutti gli OSD assegnati al dispositivo WAL/DB specifico vengono rimossi. Ciò dipende dal fatto che il comando ceph-volume crea volumi logici sui dischi prima della distribuzione, impedendo all'utente di combinare le distribuzioni basate sulle partizioni con quelle basate su LV. In questi casi, è consigliabile rimuovere manualmente tutti gli OSD assegnati a un dispositivo WAL/DB e ridistribuirli con l'approccio DriveGroups.

Stampa pagina

Guida alla distribuzione

6 Upgrade dalle release precedenti #

Nota: upgrade dalle release meno recenti non supportato

6.1 Punti da tenere presente prima dell'upgrade #

Avviso: configurazione DeepSea di default

Suggerimento: configurazione personalizzata associata ai nomi MDS

6.2 Backup dei dati del cluster #

6.3 Esecuzione della migrazione da ntpd a chronyd #

Procedura 6.1: Eseguire la migrazione a chronyd prima dell'upgrade del cluster #

Suggerimento: ulteriori dettagli sulla configurazione di chronyd

Procedura 6.2: Eseguire la migrazione a chronyd dopo l'upgrade del cluster #

Suggerimento: ulteriori dettagli sulla configurazione di chronyd

6.4 Applicazione di patch al cluster prima dell'upgrade #

6.4.1 Archivi software obbligatori #

6.4.2 Sistemi di gestione provvisoria dell'archivio #

6.4.3 Applicazione delle patch più recenti a tutto il cluster #

6.5 Verifica dell'ambiente corrente #

6.6 Verifica dello stato del cluster #

6.7 Upgrade offline dei cluster CTDB #

6.8 Upgrade per nodo - Procedura di base #

Suggerimento: pacchetti orfani

6.8.1 Esecuzione dell'upgrade manuale dei nodi tramite il DVD del programma di installazione #

Figura 6.1: Selezione della destinazione della migrazione #

6.8.2 Esecuzione dell'upgrade del nodo tramite il Distribution Migration System di SUSE #

Suggerimento: upgrade non riuscito

6.9 Esecuzione dell'upgrade del nodo admin #

Suggerimento: stato dei nodi del cluster

6.10 Esecuzione dell'upgrade dei nodi Ceph Monitor/Ceph Manager #

Nota: upgrade di Ceph Monitor

6.11 Esecuzione dell'upgrade dei server di metadati #

Suggerimento

6.12 Esecuzione dell'upgrade dei Ceph OSD #

Suggerimento: attivazione individuale delle partizioni dei dati

6.13 Migrazione OSD a BlueStore #

Suggerimento: disattivare tutte le misure di sicurezza

Importante

6.14 Esecuzione dell'upgrade dei nodi dell'applicazione #

6.15 Aggiornamento di policy.cfg e distribuzione del Ceph Dashboard tramite DeepSea #

Importante: nuovi servizi non consentiti

Suggerimento: errori "subvolume missing" durante la fase 3

6.16 Migrazione da distribuzioni basate sul profilo ai DriveGroups #

Nota

6.16.1 Analisi del layout corrente #

6.16.2 Creazione di DriveGroups corrispondenti al layout corrente #

Avviso: configurazione errata dei DriveGroups

6.16.3 Distribuzione OSD #

Suggerimento: esecuzione della migrazione al formato LVM

6.16.4 Configurazioni più complesse #

6.3 Esecuzione della migrazione da `ntpd` a `chronyd` #

Procedura 6.1: Eseguire la migrazione a `chronyd` prima dell'upgrade del cluster #

Suggerimento: ulteriori dettagli sulla configurazione di `chronyd`

Procedura 6.2: Eseguire la migrazione a `chronyd` dopo l'upgrade del cluster #

Suggerimento: ulteriori dettagli sulla configurazione di `chronyd`

6.15 Aggiornamento di `policy.cfg` e distribuzione del Ceph Dashboard tramite DeepSea #