ceph-deploy
Deployment) a 5Questo capitolo presenta la procedura per l'upgrade di SUSE Enterprise Storage dalle release precedenti a quella attuale.
Nelle note di rilascio è possibile trovare informazioni aggiuntive sulle modifiche apportate rispetto alla release precedente di SUSE Enterprise Storage. Controllare le note di rilascio per vedere se:
l'hardware necessita di considerazioni speciali;
i pacchetti software utilizzati hanno subito modifiche significative;
è necessario adottare precauzioni speciali per l'installazione.
Le note di rilascio forniscono inoltre informazioni che non si è fatto in tempo a riportare nel manuale. Contengono anche alcune note su problemi noti.
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/.
Prima di avviare la procedura di upgrade, considerare quanto segue:
Prima di eseguire l'upgrade del cluster Ceph, si devono registrare entrambi i SUSE Linux Enterprise Server e SUSE Enterprise Storage sottostanti a fronte di SCC o SMT. È possibile eseguire l'upgrade dei daemon nel cluster mentre il cluster è online e in servizio. Alcuni tipi di daemon dipendono da altri. Ad esempio, i Ceph Object Gateway dipendono dai Ceph monitor e dai daemon Ceph OSD. Si consiglia di eseguire l'upgrade in questo ordine:
Ceph Monitor
Ceph Manager
Ceph OSD
Metadata Server
Object Gateway
iSCSI Gateway
NFS Ganesha
Rimuovere le snapshot non necessarie del file system nelle partizioni del sistema operativo dei nodi. Ciò garantisce che durante l'upgrade vi sia spazio libero sufficiente su disco.
Si consiglia di verificare lo stato del cluster prima di avviare la procedura di upgrade.
Si consiglia di eseguire l'upgrade di tutti i daemon di un tipo specifico, ad esempio tutti i daemon monitor o tutti i daemon OSD, uno a uno per garantire che abbiano tutti la stessa release. Consigliamo inoltre di eseguire l'upgrade di tutti i daemon nel cluster prima di poter utilizzare le nuove funzionalità di una release.
Dopo aver eseguito l'upgrade di tutti i daemon di un tipo specifico, verificarne lo stato.
Verificare che dopo l'upgrade di tutti i monitor, ogni monitor abbia raggiunto il quorum:
root #
ceph mon stat
Accertare che ogni daemon Ceph OSD abbia raggiunto il cluster dopo l'upgrade di tutti gli OSD:
root #
ceph osd stat
require-osd-release luminous
Dopo aver eseguito l'upgrade dell'ultimo OSD a SUSE Enterprise Storage 5, i nodi monitor rilevano che tutti gli OSD eseguono la versione "luminous" di Ceph e possono rilevare che il flag osdmap require-osd-release luminous
non è impostato. In tale caso, occorre impostare questo flag manualmente per prendere atto che, dopo aver effettuato l'upgrade del cluster a "luminous", non è possibile ripristinarlo a Ceph "jewel". Impostare il flag eseguendo il comando di seguito:
root@minion >
sudo ceph osd require-osd-release luminous
Al termine dell'esecuzione del comando, l'avvertenza scompare.
Nelle nuove installazioni di SUSE Enterprise Storage 5, questo flag è impostato automaticamente quando i Ceph monitor creano l'osdmap iniziale, quindi non è richiesta alcuna azione dell'utente finale.
A partire da SUSE Enterprise Storage 5, gli OSD sono distribuiti di default tramite BlueStore invece di FileStore. Sebbene BlueStore supporti la cifratura, i Ceph OSD sono distribuiti non cifrati di default. La procedura seguente descrive i passaggi per cifrare gli OSD durante il processo di upgrade. Supponiamo che entrambi i dischi WAL/DB e dati da utilizzare per la distribuzione OSD siano vuoti e senza partizioni. Se il disco è già stato utilizzato, cancellarlo mediante la procedura seguente descritta in Passo 13.
È necessario distribuire gli OSD cifrati uno alla volta, non contemporaneamente. Il motivo è che i dati dell'OSD vengono eliminati e il cluster passa attraverso diverse iterazioni di ribilanciamento.
Determinare i valori bluestore block db size
e bluestore block wal size
per la distribuzione e aggiungerli al file /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf
nel Salt master. I valori devono essere specificati in byte.
[global] bluestore block db size = 48318382080 bluestore block wal size = 2147483648
Per ulteriori informazioni sulla personalizzazione di ceph.conf
, consultare Sezione 1.11, «File ceph.conf
personalizzato».
Eseguire DeepSea Stage 3 per distribuire le modifiche:
root@master #
salt-run state.orch ceph.stage.3
Verificare che il file ceph.conf
sia aggiornato sui relativi nodi OSD:
root@minion >
cat /etc/ceph/ceph.conf
Modificare i file *.yml nella directory /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions
pertinenti agli OSD che vengono cifrati. Verificare attentamente il percorso con quello definito nel file /srv/pillar/ceph/proposals/policy.cfg
per accertare di modificare i file *.yml corretti.
Quando si identificano i dischi OSD nei file /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions/*.yml
, utilizzare identificativi di disco lunghi.
Di seguito viene fornito un esempio di configurazione OSD. Poiché è richiesta la cifratura, tenere presente che le opzioni db_size
e wal_size
sono eliminate:
ceph: storage: osds: /dev/disk/by-id/scsi-SDELL_PERC_H730_Mini_007027b1065faa972100d34d7aa06d86: format: bluestore encryption: dmcrypt db: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN wal: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN /dev/disk/by-id/scsi-SDELL_PERC_H730_Mini_00d146b1065faa972100d34d7aa06d86: format: bluestore encryption: dmcrypt db: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN wal: /dev/disk/by-id/nvme-INTEL_SSDPEDMD020T4D_HHHL_NVMe_2000GB_PHFT642400HV2P0EGN
Distribuire i nuovi Block Storage OSD con la cifratura eseguendo le fasi 2 e 3 di DeepSea:
root@master #
salt-run state.orch ceph.stage.2root@master #
salt-run state.orch ceph.stage.3
È possibile controllare l'avanzamento con ceph -s
o ceph osd tree
. È fondamentale lasciare ribilanciare il cluster prima di ripetere il processo sul successivo nodo OSD.
Prima di iniziare la procedura di upgrade, è necessario che il software seguente sia installato e aggiornato alle versioni del package più recenti su tutti i nodi Ceph per cui si desidera eseguire l'upgrade:
SUSE Linux Enterprise Server 12 SP2
SUSE Enterprise Storage 4
Inoltre, prima di avviare l'upgrade, occorre eseguire l'upgrade del nodo Salt master a SUSE Linux Enterprise Server 12 SP3 e SUSE Enterprise Storage 5 eseguendo zypper migration
(o il modo di upgrade preferito).
Verificare che il servizio AppArmor sia in esecuzione e disattivarlo su ciascun nodo cluster. Avviare il modulo YaST AppArmor, selezionare
(Impostazioni), quindi deselezionare la casella di controllo (Abilita Apparmor). Confermare con (Fine).Tenere presente che SUSE Enterprise Storage non funziona con AppArmor attivato.
Sebbene il cluster sia completamente funzionale durante l'upgrade, DeepSea imposta il flag "noout" che impedisce a Ceph di ribilanciare i dati durante il tempo di indisponibilità, quindi evita i trasferimenti di dati non necessari.
Per ottimizzare il processo di upgrade, DeepSea esegue l'upgrade dei nodi nell'ordine, in base al ruolo assegnato come consigliato da Ceph a monte: MON, MGR, OSD, MDS, RGW, IGW e NFS Ganesha.
Tenere presente che DeepSea non è in grado di impedire la violazione dell'ordine prescritto se un nodo esegue più servizi.
Sebbene il cluster Ceph sia operativo durante l'upgrade, i nodi potrebbero venire riavviati per applicare, ad esempio, le nuove versioni del kernel. Per ridurre le operazioni di I/O in attesa, si consiglia di rifiutare le richieste in entrata durante il processo di upgrade.
L'upgrade del cluster può richiedere molto tempo, circa lo stesso richiesto per eseguire l'upgrade su un computer moltiplicato per il numero di nodi del cluster.
A partire da Ceph Luminous, l'opzione di configurazione osd crush location
non è più supportata. Aggiornare i file di configurazione DeepSea per utilizzare crush location
prima dell'upgrade.
Per eseguire l'upgrade del cluster SUSE Enterprise Storage 4 alla versione 5, attenersi a questa procedura:
Impostare il nuovo ordinamento degli oggetti interni, eseguire:
root #
ceph osd set sortbitwise
Per verificare che il comando sia stato eseguito, si consiglia di eseguire
root #
ceph osd dump --format json-pretty | grep sortbitwise
"flags": "sortbitwise,recovery_deletes,purged_snapdirs",
Con rpm -q deepsea
, verificare che la versione del pacchetto DeepSea sul nodo Salt master inizi almeno con 0.7
. Ad esempio:
root #
rpm -q deepsea
deepsea-0.7.27+git.0.274c55d-5.1
Se il numero di versione del pacchetto DeepSea inizia con 0.6, verificare di aver eseguito correttamente la migrazione del nodo Salt master a SUSE Linux Enterprise Server 12 SP3 e SUSE Enterprise Storage 5 (consultare Importante: requisiti del software all'inizio di questa sezione). Si tratta di un prerequisito da completare prima di avviare la procedura di upgrade.
Se i sistemi sono stati registrati con SUSEConnect e si utilizza SCC/SMT, non sono richieste ulteriori azioni. Continuare con Passo 4.
Se non si utilizza SCC/SMT ma un Media-ISO o altra sorgente del pacchetto, aggiungere i seguenti repository manualmente: SLE12-SP3 Base, SLE12-SP3 Update, SES5 Base e SES5 Update. Per questo scopo, è possibile utilizzare il comando zypper
. Rimuovere prima tutti i repository software esistenti, quindi aggiungere quelli nuovi richiesti e infine aggiornare le sorgenti dei repository:
root #
zypper sd {0..99}root #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOLroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATESroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOLroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATESroot #
zypper ref
Cambiare quindi i dati di Pillar per utilizzare una diversa strategia. Modificare
/srv/pillar/ceph/stack/name_of_cluster/cluster.yml
e aggiungere la riga seguente:
upgrade_init: zypper-dup
La strategia zypper-dup
richiede di aggiungere manualmente i repository software più recenti, mentre zypper-migration
di default si basa sui repository forniti da SCC/SMT.
Aggiornare il Pillar:
root@master #
salt target saltutil.sync_all
Per informazioni sull'indirizzamento dei Salt minion, vedere Sezione 4.2.2, «Indirizzamento dei minion».
Verificare che la scrittura su Pillar sia riuscita:
root@master #
salt target pillar.get upgrade_init
Il risultato del comando dovrebbe rispecchiare la voce aggiunta.
Eseguire l'upgrade dei Salt minion:
root@master #
salt target state.apply ceph.updates.salt
Verificare che sia stato eseguito l'upgrade di tutti i Salt minion:
root@master #
salt target test.version
Includere i Salt minion del cluster. Per ulteriori dettagli, fare riferimento a Sezione 4.2.2, «Indirizzamento dei minion» di Procedura 4.1, «Esecuzione delle fasi di distribuzione».
Avviare l'upgrade di SUSE Linux Enterprise Server e Ceph:
root@master #
salt-run state.orch ceph.maintenance.upgrade
Se il processo determina il riavvio del Salt master, rieseguire il comando per avviare il processo di upgrade per i Salt minion.
Verificare che dopo l'upgrade, AppArmor sia disattivato e arrestato su tutti i nodi:
root #
systemctl disable apparmor.service
systemctl stop apparmor.service
Dopo l'upgrade, i Ceph Manager non sono ancora installati. Per ottenere uno stato migliore del cluster, attenersi a questa procedura:
Eseguire la Fase 0 per attivare l'API REST Salt:
root@master #
salt-run state.orch ceph.stage.0
Eseguire la Fase 1 per creare la sottodirectory role-mgr/
:
root@master #
salt-run state.orch ceph.stage.1
Modificare Sezione 4.5.1, «Il file policy.cfg
» e aggiungere un ruolo Ceph Manager dove sono distribuiti i Ceph Monitor. Inoltre, aggiungere il ruolo openATTIC a uno dei nodi cluster. Per ulteriori dettagli, fare riferimento a Capitolo 15, openATTIC.
Eseguire la Fase 2 per aggiornare il Pillar:
root@master #
salt-run state.orch ceph.stage.2
DeepSea utilizza un diverso approccio per generare ora il file di configurazione ceph.conf
, per ulteriori informazioni, consultare Sezione 1.11, «File ceph.conf
personalizzato».
Per distribuire i Ceph Manager, eseguire la Fase 3:
root@master #
salt-run state.orch ceph.stage.3
Per configurare correttamente openATTIC, eseguire la Fase 4:
root@master #
salt-run state.orch ceph.stage.4
Se si verifica un errore di ceph.stage.3
con "Error EINVAL: entity client.bootstrap-osd exists but caps do not match", le capacità (cap) chiave per la chiave esistente client.bootstrap.osd
del cluster non corrispondono alle cap che DeepSea sta cercando di impostare. Sopra il messaggio di errore, in testo rosso, è possibile vedere un dump del comando ceph auth
non riuscito. Osservare il comando per verificare il file e ID chiave in uso. In caso di client.bootstrap-osd
, il comando sarà
root #
ceph auth add client.bootstrap-osd \
-i /srv/salt/ceph/osd/cache/bootstrap.keyring
Per risolvere le cap chiave non corrispondenti, controllare il contenuto del file portachiavi che DeepSea cerca di distribuire, ad esempio:
cephadm >
cat /srv/salt/ceph/osd/cache/bootstrap.keyring
[client.bootstrap-osd]
key = AQD6BpVZgqVwHBAAQerW3atANeQhia8m5xaigw==
caps mgr = "allow r"
caps mon = "allow profile bootstrap-osd"
Confrontarlo con il risultato di ceph auth get client.bootstrap-osd
:
root #
ceph auth get client.bootstrap-osd
exported keyring for client.bootstrap-osd
[client.bootstrap-osd]
key = AQD6BpVZgqVwHBAAQerW3atANeQhia8m5xaigw==
caps mon = "allow profile bootstrap-osd"
Notare nell'ultima chiave la mancanza di caps mgr = "allow r"
. Per risolvere, eseguire:
root #
ceph auth caps client.bootstrap-osd mgr \
"allow r" mon "allow profile bootstrap-osd"
L'esecuzione di ceph.stage.3
dovrebbe ora riuscire.
Lo stesso problema può verificarsi con i portachiavi di Metadata Server e Object Gateway quando si esegue ceph.stage.4
. Applicare la stessa procedura precedente: verificare il comando non riuscito, il file portachiavi distribuito e le cap della chiave esistente. Eseguire quindi ceph auth caps
per aggiornare le cap della chiave esistenti in modo che corrispondano a quanto viene distribuito da DeepSea.
Se il cluster resta nello stato "HEALTH_ERR" per oltre 300 secondi, oppure uno dei servizi per ciascun ruolo assegnato non è attivo per oltre 900 secondi, l'upgrade non è riuscito. In tale caso, cercare di individuare il problema, risolverlo e rieseguire la procedura di upgrade. Tenere presente che negli ambienti virtualizzati, i timeout sono più brevi.
Dopo aver eseguito l'upgrade a SUSE Enterprise Storage 5, gli OSD FileStore richiedono circa cinque minuti di più per l'avvio, in quanto l'OSD esegue una conversione one-off dei propri file su disco.
Se occorre individuare le versioni dei singoli componenti e nodi del cluster, ad esempio per vedere se tutti i nodi hanno effettivamente lo stesso livello di patch dopo l'upgrade, è possibile eseguire
root@master #
salt-run status.report
Il comando passa attraverso i Salt minion connessi e analizza i numeri di versione di Ceph, Salt e SUSE Linux Enterprise Server, fornendo un report che visualizza la versione della maggioranza dei nodi e mostrando i nodi la cui versione è diversa da quella della maggioranza.
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 più veloci/diversi.
In SES5, 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
Migrare i profili hardware:
root@master #
salt-run state.orch ceph.migrate.policy
Questo runner si occupa della migrazione dei profili hardware utilizzati dal file policy.cfg
. Elabora policy.cfg
, individua eventuali profili hardware che utilizzano la struttura dati originale e li converte alla nuova struttura dei dati. Il risultato è un nuovo profilo hardware denominato "migrated-original_name". Viene anche aggiornato policy.cfg
.
Se la configurazione originale presenta giornali di registrazione separati, la configurazione di BlueStore utilizzerà lo stesso dispositivo per "wal" e "db" per tale OSD.
DeepSea migra gli OSD impostandone i pesi a 0 "svuotando" i dati finché l'OSD non è vuoto. È possibile migrare gli OSD uno alla volta o tutti gli OSD insieme. In un caso o nell'altro, quando l'OSD è vuoto, l'orchestrazione lo rimuove e lo ricrea con la nuova configurazione.
Se è presente un grande numero di nodi di storage fisici o quasi assenza di dati, utilizzare ceph.migrate.nodes
. Se un nodo rappresenta meno del 10% della capacità, ceph.migrate.nodes
può essere marginalmente può veloce a spostare tutti i dati dagli OSD in parallelo.
Se non si è certi del metodo da utilizzare, oppure se il sito contiene pochi nodi di storage (ad esempio ogni nodo ha più del 10% dei dati del cluster), selezionare ceph.migrate.osds
.
Per migrare gli OSD uno alla volta, eseguire:
root@master #
salt-run state.orch ceph.migrate.osds
Per migrare tutti gli OSD nello stesso nodo in parallelo, eseguire:
root@master #
salt-run state.orch ceph.migrate.nodes
Poiché l'orchestrazione non fornisce alcun feedback sull'avanzamento della migrazione, utilizzare
root #
ceph osd tree
per vedere quali OSD hanno un peso pari a zero periodicamente.
Dopo la migrazione a BlueStore, il numero di oggetti rimane lo stesso e l'utilizzo del disco quasi uguale.
ceph-deploy
Deployment) a 5 #Prima di iniziare la procedura di upgrade, è necessario che il software seguente sia installato e aggiornato alle versioni del package più recenti su tutti i nodi Ceph per cui si desidera eseguire l'upgrade:
SUSE Linux Enterprise Server 12 SP2
SUSE Enterprise Storage 4
Scegliere il Salt master per il cluster. Se nel cluster è distribuito Calamari, il nodo Calamari è già il Salt master. In alternativa, il nodo admin da cui è stato eseguito il comando ceph-deploy
diventa il Salt master.
Prima di avviare la procedura seguente, occorre eseguire l'upgrade del nodo Salt master a SUSE Linux Enterprise Server 12 SP3 e SUSE Enterprise Storage 5 eseguendo zypper migration
(o il modo di upgrade preferito).
Per eseguire l'upgrade al cluster SUSE Enterprise Storage 4 distribuito con ceph-deploy
alla versione 5, attenersi a questa procedura:
Installare il pacchetto salt
da SLE-12-SP2/SES4:
root #
zypper install salt
Installare il pacchetto salt-minion
da SLE-12-SP2/SES4, quindi attivare e avviare il servizio correlato:
root #
zypper install salt-minionroot #
systemctl enable salt-minionroot #
systemctl start salt-minion
Accertare che il nome host "salt" si risolva nell'indirizzo IP del nodo Salt master. Se il Salt master non è raggiungibile dal nome host salt
, modificare il file /etc/salt/minion
oppure creare un nuovo file /etc/salt/minion.d/master.conf
con il seguente contenuto:
master: host_name_of_salt_master
Nei Salt minion esistenti l'opzione master:
è già impostata in /etc/salt/minion.d/calamari.conf
. Il nome del file di configurazione è ininfluente, la directory /etc/salt/minion.d/
è importante.
Se sono state apportate modifiche ai file di configurazione menzionati sopra, riavviare il servizio Salt su tutti i Salt minion:
root@minion >
systemctl restart salt-minion.service
Se i sistemi sono stati registrati con SUSEConnect e si utilizza SCC/SMT, non sono richieste ulteriori azioni.
Se non si utilizza SCC/SMT ma un Media-ISO o altra sorgente del pacchetto, aggiungere i seguenti repository manualmente: SLE12-SP3 Base, SLE12-SP3 Update, SES5 Base e SES5 Update. Per questo scopo, è possibile utilizzare il comando zypper
. Rimuovere prima tutti i repository software esistenti, quindi aggiungere quelli nuovi richiesti e infine aggiornare le sorgenti dei repository:
root #
zypper sd {0..99}root #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOLroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATESroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOLroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATESroot #
zypper ref
Impostare il nuovo ordinamento degli oggetti interni, eseguire:
root@master #
ceph osd set sortbitwise
Per verificare che il comando sia stato eseguito, si consiglia di eseguire
root@master #
ceph osd dump --format json-pretty | grep sortbitwise
"flags": "sortbitwise,recovery_deletes,purged_snapdirs",
Eseguire l'upgrade del nodo Salt master a SUSE Linux Enterprise Server 12 SP3 e SUSE Enterprise Storage 5. Per i sistemi con registrazione SCC, utilizzare zypper migration
. Se i repository software richiesti sono forniti manualmente, utilizzare zypper dup
. Dopo l'upgrade, verificare che solo i repository per SUSE Linux Enterprise Server 12 SP3 e SUSE Enterprise Storage 5 siano attivi (e aggiornati) sul nodo Salt master prima di continuare.
Se non è già presente, installare il pacchetto salt-package
, quindi attivare e avviare il servizio correlato:
root@master #
zypper install salt-masterroot@master #
systemctl enable salt-masterroot@master #
systemctl start salt-master
Verificare la presenza di tutti i Salt minion elencandone le chiavi:
root@master #
salt-key -L
Aggiungere tutte le chiavi dei Salt minion al Salt master compreso il minion master:
root@master #
salt-key -A -y
Verificare che tutte le chiavi dei Salt minion siano state accettate:
root@master #
salt-key -L
Verificare che il software sul nodo Salt master sia aggiornato:
root@master #
zypper migration
Installare il pacchetto deepsea
:
root@master #
zypper install deepsea
Includere i Salt minion del cluster. Per ulteriori dettagli, fare riferimento a Sezione 4.2.2, «Indirizzamento dei minion» di Procedura 4.1, «Esecuzione delle fasi di distribuzione».
Importare il cluster installato ceph-deploy
esistente:
root@master #
salt-run populate.engulf_existing_cluster
Il comando esegue quanto indicato di seguito:
Distribuzione di tutti i moduli Salt e DeepSea richiesti a tutti i Salt minion.
Esaminare il cluster Ceph in esecuzione e inserire /srv/pillar/ceph/proposals
in un layout del cluster.
Viene creato /srv/pillar/ceph/proposals/policy.cfg
con ruoli corrispondenti a tutti i servizi Ceph in esecuzione rilevati. Visualizzare questo file per verificare che ogni nodo MON, OSD, RGW e MDS esistente abbia i ruoli appropriati. I nodi OSD verranno importati nella sottodirectory profile-import/
, quindi è possibile esaminare i file in /srv/pillar/ceph/proposals/profile-import/cluster/
e /srv/pillar/ceph/proposals/profile-import/stack/default/ceph/minions/
per confermare che gli OSD siano stati prelevati correttamente.
Il file policy.cfg
generato applica solo i ruoli per i servizi Ceph rilevati "role-mon", "role-mgr", "role-mds", "role-rgw", "role-admin" e "role-master" per il nodo Salt master. Altri eventuali ruoli desiderati devono essere aggiunti al file manualmente (vedere Sezione 4.5.1.2, «Assegnazione ruolo»).
ceph.conf
del cluster esistente viene salvato in /srv/salt/ceph/configuration/files/ceph.conf.import
.
/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml
comprende il fsid del cluster, reti pubbliche e cluster e inoltre specifica l'opzione configuration_init: default-import
che consente a DeepSea di utilizzare il file di configurazione ceph.conf.import
citato in precedenza, invece di utilizzare il modello predefinito di DeepSea /srv/salt/ceph/configuration/files/ceph.conf.j2
.
ceph.conf
personalizzato
Se occorre integrare il file ceph.conf
con modifiche personalizzate, attendere il corretto completamento del processo di importazione/upgrade. Modificare quindi il file /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml
e commentare la riga seguente:
configuration_init: default-import
Salvare il file e seguire le informazioni in Sezione 1.11, «File ceph.conf
personalizzato».
I diversi portachiavi del cluster vengono salvati nelle seguenti directory:
/srv/salt/ceph/admin/cache/ /srv/salt/ceph/mon/cache/ /srv/salt/ceph/osd/cache/ /srv/salt/ceph/mds/cache/ /srv/salt/ceph/rgw/cache/
Verificare che siano presenti i file portachiavi e che non via sia alcun file portachiavi nella seguente directory (il Ceph Manager non esisteva prima di SUSE Enterprise Storage 5):
/srv/salt/ceph/mgr/cache/
Il comando salt-run populate.engulf_existing_cluster
non gestisce l'importazione della configurazione openATTIC. È necessario modificare manualmente il file policy.cfg
e aggiungere una riga role-openattic
. Per ulteriori dettagli, fare riferimento a Sezione 4.5.1, «Il file policy.cfg
».
Il comando salt-run populate.engulf_existing_cluster
non gestisce l'importazione delle configurazioni dei Gateway iSCSI. Se il cluster comprende iSCSI Gateway, importarne manualmente le configurazioni:
Su uno dei nodi iSCSI Gateway, esportare il lrbd.conf
corrente e copiarlo nel nodo Salt master:
root@minion >
lrbd -o >/tmp/lrbd.confroot@minion >
scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf
Sul nodo Salt master, aggiungere la configurazione iSCSI Gateway predefinita alla configurazione di DeepSea:
root@master #
mkdir -p /srv/pillar/ceph/stack/ceph/root@master #
echo 'igw_config: default-ui' >> /srv/pillar/ceph/stack/ceph/cluster.ymlroot@master #
chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml
Aggiungere i ruoli iSCSI Gateway a policy.cfg
e salvare il file:
role-igw/stack/default/ceph/minions/ses-1.ses.suse.yml role-igw/cluster/ses-1.ses.suse.sls [...]
Eseguire la Fase 1 per creare tutti i ruoli possibili:
root@master #
salt-run state.orch ceph.stage.1
Generare le sottodirectory richieste in /srv/pillar/ceph/stack
:
root@master #
salt-run push.proposal
Verificare che sia presente un cluster operativo gestito da DeepSea con i ruoli assegnati correttamente:
root@master #
salt target pillar.get roles
Confrontare il risultato con il layout effettivo del cluster.
Calamari lascia un lavoro Salt pianificato in esecuzione per controllare lo stato del cluster. Rimuovere il lavoro:
root@minion >
salt target schedule.delete ceph.heartbeat
Da questo punto in avanti, seguire la procedura descritta in Sezione 5.4, «Eseguire l'upgrade da SUSE Enterprise Storage 4 (distribuzione DeepSea) a 5».
Prima di iniziare la procedura di upgrade, è necessario che il software seguente sia installato e aggiornato alle versioni del package più recenti su tutti i nodi Ceph per cui si desidera eseguire l'upgrade:
SUSE Linux Enterprise Server 12 SP2
SUSE Enterprise Storage 4
Per eseguire l'upgrade di SUSE Enterprise Storage 4 distribuito mediante Crowbar alla versione 5, attenersi a questa procedura:
Per ciascun nodo Ceph (compreso il nodo Calamari), arrestare e disabilitare tutti i servizi relativi a Crowbar:
root@minion >
sudo systemctl stop chef-clientroot@minion >
sudo systemctl disable chef-clientroot@minion >
sudo systemctl disable crowbar_joinroot@minion >
sudo systemctl disable crowbar_notify_shutdown
Per ciascun nodo Ceph (compreso il nodo Calamari), verificare che i repository software puntino ai prodotti SUSE Enterprise Storage 5 e SUSE Linux Enterprise Server 12 SP3. Se sono ancora presenti repository che puntano a versioni dei prodotti precedenti, disabilitarli.
Per ciascun nodo Ceph (compreso il nodo Calamari), verificare che salt-minion sia installato. In caso contrario, installarlo:
root@minion >
sudo zypper in salt salt-minion
Per i nodi Ceph che non hanno il pacchetto salt-minion
installato, creare il file /etc/salt/minion.d/master.conf
con l'opzione master
che punta al nome host del nodo Calamari completo:
master: full_calamari_hostname
Nei Salt minion esistenti l'opzione master:
è già impostata in /etc/salt/minion.d/calamari.conf
. Il nome del file di configurazione è ininfluente, è importante la directory /etc/salt/minion.d/
.
Abilitare e avviare il servizio salt-minion
:
root@minion >
sudo systemctl enable salt-minionroot@minion >
sudo systemctl start salt-minion
Nel nodo Calamari, accettare eventuali chiavi salt minion rimanenti:
root@master #
salt-key -L [...] Unaccepted Keys: d52-54-00-16-45-0a.example.com d52-54-00-70-ac-30.example.com [...]root@master #
salt-key -A The following keys are going to be accepted: Unaccepted Keys: d52-54-00-16-45-0a.example.com d52-54-00-70-ac-30.example.com Proceed? [n/Y] y Key for minion d52-54-00-16-45-0a.example.com accepted. Key for minion d52-54-00-70-ac-30.example.com accepted.
Se Ceph è stato installato sulla rete pubblica ma non è presente alcuna interfaccia VLAN, aggiungere al nodo Calamari un'interfaccia (VLAN) sulla rete pubblica di Crowbar.
Eseguire l'upgrade del nodo Calamari a SUSE Linux Enterprise Server 12 SP3 e SUSE Enterprise Storage 5, utilizzando zypper migration
o il metodo prescelto. Da questo punto in avanti, il nodo Calamari diventa il Salt master. Dopo l'upgrade, riavviare il Salt master.
Installare DeepSea sul Salt master:
root@master #
zypper in deepsea
Specificare l'opzione deepsea_minions
per includere il gruppo corretto di Salt minion nelle fasi di distribuzione. Per ulteriori dettagli, fare riferimento a Sezione 4.2.2.3, «Impostare l'opzione deepsea_minions
».
DeepSea si aspetta che tutti i nodi Ceph abbiano un identico /etc/ceph/ceph.conf
. Crowbar distribuisce un ceph.conf
leggermente diverso su ciascun nodo, quindi occorre consolidarli:
Rimuovere l'opzione osd crush location hook
inclusa da Calamari.
Rimuovere l'opzione public addr
dalla sezione [mon]
.
Rimuovere i numeri di porta dall'opzione mon host
.
Se si stava eseguendo l'Object Gateway, Crowbar ha distribuito un file /etc/ceph/ceph.conf.radosgw
separato per mantenere i segreti keystone separati dal file ceph.conf
standard. Crowbar aggiunge anche un file /etc/systemd/system/ceph-radosgw@.service
personalizzato. Poiché DeepSea non lo supporta, occorre rimuoverlo:
Aggiungere tutte le sezioni [client.rgw....]
dal file ceph.conf.radosgw
a /etc/ceph/ceph.conf
su tutti i nodi.
Sul nodo Object Gateway, eseguire:
root@minion >
rm /etc/systemd/system/ceph-radosgw@.service
systemctl reenable ceph-radosgw@rgw.public.$hostname
Verificare che ceph status
funzioni quando eseguito dal Salt master:
root@master #
ceph status
cluster a705580c-a7ae-4fae-815c-5cb9c1ded6c2
health HEALTH_OK
[...]
Importare il cluster esistente:
root@master #
salt-run populate.engulf_existing_clusterroot@master #
salt-run state.orch ceph.stage.1root@master #
salt-run push.proposal
Il comando salt-run populate.engulf_existing_cluster
non gestisce l'importazione delle configurazioni dei Gateway iSCSI. Se il cluster comprende iSCSI Gateway, importarne manualmente le configurazioni:
Su uno dei nodi iSCSI Gateway, esportare il lrbd.conf
corrente e copiarlo nel nodo Salt master:
root@minion >
lrbd -o > /tmp/lrbd.confroot@minion >
scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf
Sul nodo Salt master, aggiungere la configurazione iSCSI Gateway predefinita alla configurazione di DeepSea:
root@master #
mkdir -p /srv/pillar/ceph/stack/ceph/root@master #
echo 'igw_config: default-ui' >> /srv/pillar/ceph/stack/ceph/cluster.ymlroot@master #
chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml
Aggiungere i ruoli iSCSI Gateway a policy.cfg
e salvare il file:
role-igw/stack/default/ceph/minions/ses-1.ses.suse.yml role-igw/cluster/ses-1.ses.suse.sls [...]
Se i sistemi sono stati registrati con SUSEConnect e si utilizza SCC/SMT, non sono richieste ulteriori azioni.
Se non si utilizza SCC/SMT ma un Media-ISO o altra sorgente del pacchetto, aggiungere i seguenti repository manualmente: SLE12-SP3 Base, SLE12-SP3 Update, SES5 Base e SES5 Update. Per questo scopo, è possibile utilizzare il comando zypper
. Rimuovere prima tutti i repository software esistenti, quindi aggiungere quelli nuovi richiesti e infine aggiornare le sorgenti dei repository:
root #
zypper sd {0..99}root #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/Storage/5/x86_64/product/ SES5-POOLroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATESroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOLroot #
zypper ar \ http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATESroot #
zypper ref
Cambiare quindi i dati di Pillar per utilizzare una diversa strategia. Modificare
/srv/pillar/ceph/stack/name_of_cluster/cluster.yml
e aggiungere la riga seguente:
upgrade_init: zypper-dup
La strategia zypper-dup
richiede di aggiungere manualmente i repository software più recenti, mentre zypper-migration
di default si basa sui repository forniti da SCC/SMT.
Modificare i "grain" (piccoli elementi di dati) host affinché DeepSea utilizzi nomi host brevi sulla rete pubblica per gli ID istanza del daemon Ceph. Per ciascun nodo, occorre eseguire grains.set
con il nuovo nome (breve) host. Prima di eseguire grains.set
, verificare le istanze del monitor corrente eseguendo ceph status
. Viene fornito un esempio per "prima" e "dopo":
root@master #
salt target grains.get host
d52-54-00-16-45-0a.example.com:
d52-54-00-16-45-0a
d52-54-00-49-17-2a.example.com:
d52-54-00-49-17-2a
d52-54-00-76-21-bc.example.com:
d52-54-00-76-21-bc
d52-54-00-70-ac-30.example.com:
d52-54-00-70-ac-30
root@master #
salt d52-54-00-16-45-0a.example.com grains.set \ host public.d52-54-00-16-45-0aroot@master #
salt d52-54-00-49-17-2a.example.com grains.set \ host public.d52-54-00-49-17-2aroot@master #
salt d52-54-00-76-21-bc.example.com grains.set \ host public.d52-54-00-76-21-bcroot@master #
salt d52-54-00-70-ac-30.example.com grains.set \ host public.d52-54-00-70-ac-30
root@master #
salt target grains.get host
d52-54-00-76-21-bc.example.com:
public.d52-54-00-76-21-bc
d52-54-00-16-45-0a.example.com:
public.d52-54-00-16-45-0a
d52-54-00-49-17-2a.example.com:
public.d52-54-00-49-17-2a
d52-54-00-70-ac-30.example.com:
public.d52-54-00-70-ac-30
Eseguire l'upgrade:
root@master #
salt target state.apply ceph.updatesroot@master #
salt target test.versionroot@master #
salt-run state.orch ceph.maintenance.upgrade
Ogni nodo si riavvia. Il cluster si riattiva rilevando l'assenza dell'istanza attiva di Ceph Manager. Questa situazione è normale. A questo punto, Calamari non deve essere più installato/in esecuzione.
Eseguire tutte le fasi di distribuzione richieste per portare il cluster a uno stato funzionale:
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.3
Per distribuire openATTIC (vedere Capitolo 15, openATTIC), aggiungere una riga role-openattic
(vedere Sezione 4.5.1.2, «Assegnazione ruolo») appropriata a /srv/pillar/ceph/proposals/policy.cfg
, quindi eseguire:
root@master #
salt-run state.orch ceph.stage.2root@master #
salt-run state.orch ceph.stage.4
Durante l'upgrade, è possibile ricevere errori come/del tipo "Error EINVAL: entity [...] exists but caps do not match". Per risolverli, consultare Sezione 5.4, «Eseguire l'upgrade da SUSE Enterprise Storage 4 (distribuzione DeepSea) a 5».
Eseguire la pulizia rimanente:
Crowbar crea voci in /etc/fstab
per ogni OSD. Poiché non sono necessarie, cancellarle.
Calamari lascia un lavoro Salt pianificato in esecuzione per controllare lo stato del cluster. Rimuovere il lavoro:
root@master #
salt target schedule.delete ceph.heartbeat
Sono ancora presenti alcuni pacchetti installati non necessari, soprattutto correlati a ruby gems e chef. La loro rimozione non è richiesta, ma è possibile eliminarli eseguendo zypper rm pkg_name
.
Prima di iniziare la procedura di upgrade, è necessario che il software seguente sia installato e aggiornato alle versioni del package più recenti su tutti i nodi Ceph per cui si desidera eseguire l'upgrade:
SUSE Linux Enterprise Server 12 SP1
SUSE Enterprise Storage 3
Per eseguire l'upgrade del cluster SUSE Enterprise Storage 3 alla versione 5, seguire la procedura descritta in Procedura 5.1, «Procedura da applicare a tutti i noi del cluster (compreso il nodo Calamari)» quindi Procedura 5.2, «Procedura da applicare al nodo Salt master».