ntpd
a chronyd
policy.cfg
e distribuzione del Ceph Dashboard tramite DeepSeaQuesto 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.
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.
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
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:
Nodo admin
Ceph Monitor/Ceph Manager
Metadata Server
Ceph OSD
Object Gateway
iSCSI Gateway
NFS Ganesha
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
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.
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.
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.
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
.
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
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
.
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.
Applicare le patch più recenti a tutti i nodi del cluster prima di eseguire l'upgrade.
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
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:
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 -acephadm@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».
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.
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
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.
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.
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.
Riavviare il nodo dall'immagine o dal DVD del programma di installazione di SUSE Linux Enterprise Server 15 SP1.
Selezionare
(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
(Modifica manualmente gli archivi per la 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
(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
e avviare la procedura di installazione facendo clic su .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
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
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:
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
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.
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.
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».
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)
[...]
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».
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».
È 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.
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
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
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.
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:
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.
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.
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».
policy.cfg
e distribuzione del Ceph Dashboard tramite DeepSea #
Sul nodo admin, modificare /srv/pillar/ceph/proposals/policy.cfg
e applicare le modifiche seguenti:
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.1root@master #
salt-run state.orch ceph.stage.2
Ripulire openATTIC:
root@master #
salt OA_MINION state.apply ceph.rescind.openatticroot@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.0root@master #
salt-run state.orch ceph.stage.1root@master #
salt-run state.orch ceph.stage.2root@master #
salt-run state.orch ceph.stage.3root@master #
salt-run state.orch ceph.stage.4
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_pillarroot@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».
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»).
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).
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
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:storageroot@master #
salt-run disks.report
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
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.
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.
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.