Saltar al contenutoSaltar alla navigazione delle pagine: pagina precedente [chiave d’accesso p]/pagina successiva [chiave d’accesso n]
Si applica a SUSE Enterprise Storage 5

5 Upgrade dalle release precedenti

Questo capitolo presenta la procedura per l'upgrade di SUSE Enterprise Storage dalle release precedenti a quella attuale.

5.1 Lettura delle note di rilascio

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

5.2 Procedura di upgrade generica

Prima di avviare la procedura di upgrade, considerare quanto segue:

Ordine di upgrade

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:

  1. Ceph Monitor

  2. Ceph Manager

  3. Ceph OSD

  4. Metadata Server

  5. Object Gateway

  6. iSCSI Gateway

  7. NFS Ganesha

Eliminare le snapshot non necessarie del sistema operativo

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.

Verificare lo stato del cluster

Si consiglia di verificare lo stato del cluster prima di avviare la procedura di upgrade.

Eseguire l'upgrade di uno alla volta

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
Impostare il flag 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.

5.3 Cifratura degli OSD durante l'upgrade

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.

Importante
Importante: un OSD alla volta

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

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

  2. Eseguire DeepSea Stage 3 per distribuire le modifiche:

    root@master # salt-run state.orch ceph.stage.3
  3. Verificare che il file ceph.conf sia aggiornato sui relativi nodi OSD:

    root@minion > cat /etc/ceph/ceph.conf
  4. 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.

    Importante
    Importante: identificativi di disco lunghi

    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
  5. 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.2
    root@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.

5.4 Eseguire l'upgrade da SUSE Enterprise Storage 4 (distribuzione DeepSea) a 5

Importante
Importante: requisiti del software

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

Avviso
Avviso: punti da tenere presente prima dell'upgrade
  • Verificare che il servizio AppArmor sia in esecuzione e disattivarlo su ciascun nodo cluster. Avviare il modulo YaST AppArmor, selezionare Settings (Impostazioni), quindi deselezionare la casella di controllo Enable Apparmor (Abilita Apparmor). Confermare con Done (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:

  1. Impostare il nuovo ordinamento degli oggetti interni, eseguire:

    root # ceph osd set sortbitwise
    Suggerimento
    Suggerimento

    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",
  2. 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.

    1. Se i sistemi sono stati registrati con SUSEConnect e si utilizza SCC/SMT, non sono richieste ulteriori azioni. Continuare con Passo 4.

    2. 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-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATES
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATES
      root # 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
      Suggerimento
      Suggerimento

      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.

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

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

  5. Eseguire l'upgrade dei Salt minion:

    root@master # salt target state.apply ceph.updates.salt
  6. Verificare che sia stato eseguito l'upgrade di tutti i Salt minion:

    root@master # salt target test.version
  7. 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».

  8. Avviare l'upgrade di SUSE Linux Enterprise Server e Ceph:

    root@master # salt-run state.orch ceph.maintenance.upgrade
    Suggerimento
    Suggerimento: rieseguire all'avvio

    Se il processo determina il riavvio del Salt master, rieseguire il comando per avviare il processo di upgrade per i Salt minion.

  9. Verificare che dopo l'upgrade, AppArmor sia disattivato e arrestato su tutti i nodi:

    root # systemctl disable apparmor.service
    systemctl stop apparmor.service
  10. Dopo l'upgrade, i Ceph Manager non sono ancora installati. Per ottenere uno stato migliore del cluster, attenersi a questa procedura:

    1. Eseguire la Fase 0 per attivare l'API REST Salt:

      root@master # salt-run state.orch ceph.stage.0
    2. Eseguire la Fase 1 per creare la sottodirectory role-mgr/:

      root@master # salt-run state.orch ceph.stage.1
    3. Modificare policy.cfg come descritto in 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.

    4. Eseguire la Fase 2 per aggiornare il Pillar:

      root@master # salt-run state.orch ceph.stage.2
    5. 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».

    6. Per distribuire i Ceph Manager, eseguire la Fase 3:

      root@master # salt-run state.orch ceph.stage.3
    7. Per configurare correttamente openATTIC, eseguire la Fase 4:

      root@master # salt-run state.orch ceph.stage.4
    Nota
    Nota: errata corrispondenza capacità chiave Ceph

    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.

Importante
Importante: upgrade non riuscito

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.

Importante
Importante: riavvio degli OSD

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.

Suggerimento
Suggerimento: verificare la versione dei nodi/componenti del cluster

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.

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

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

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

    Suggerimento
    Suggerimento: metodo consigliato

    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.

    1. Per migrare gli OSD uno alla volta, eseguire:

      root@master # salt-run state.orch ceph.migrate.osds
    2. Per migrare tutti gli OSD nello stesso nodo in parallelo, eseguire:

      root@master # salt-run state.orch ceph.migrate.nodes
    Suggerimento
    Suggerimento

    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.

5.5 Eseguire l'upgrade da SUSE Enterprise Storage 4 (ceph-deploy Deployment) a 5

Importante
Importante: requisiti del software

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:

Procedura 5.1: Procedura da applicare a tutti i noi del cluster (compreso il nodo Calamari)
  1. Installare il pacchetto salt da SLE-12-SP2/SES4:

    root # zypper install salt
  2. Installare il pacchetto salt-minion da SLE-12-SP2/SES4, quindi attivare e avviare il servizio correlato:

    root # zypper install salt-minion
    root # systemctl enable salt-minion
    root # systemctl start salt-minion
  3. 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
    Suggerimento
    Suggerimento

    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
    1. Se i sistemi sono stati registrati con SUSEConnect e si utilizza SCC/SMT, non sono richieste ulteriori azioni.

    2. 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-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATES
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATES
      root # zypper ref
Procedura 5.2: Procedura da applicare al nodo Salt master
  1. Impostare il nuovo ordinamento degli oggetti interni, eseguire:

    root@master # ceph osd set sortbitwise
    Suggerimento
    Suggerimento

    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",
  2. 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.

  3. Se non è già presente, installare il pacchetto salt-package, quindi attivare e avviare il servizio correlato:

    root@master # zypper install salt-master
    root@master # systemctl enable salt-master
    root@master # systemctl start salt-master
  4. Verificare la presenza di tutti i Salt minion elencandone le chiavi:

    root@master # salt-key -L
  5. Aggiungere tutte le chiavi dei Salt minion al Salt master compreso il minion master:

    root@master # salt-key -A -y
  6. Verificare che tutte le chiavi dei Salt minion siano state accettate:

    root@master # salt-key -L
  7. Verificare che il software sul nodo Salt master sia aggiornato:

    root@master # zypper migration
  8. Installare il pacchetto deepsea:

    root@master # zypper install deepsea
  9. 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».

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

      Nota
      Nota

      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.

      Nota
      Nota: 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/
  11. 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».

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

    1. Su uno dei nodi iSCSI Gateway, esportare il lrbd.conf corrente e copiarlo nel nodo Salt master:

      root@minion > lrbd -o >/tmp/lrbd.conf
      root@minion > scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf
    2. 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.yml
      root@master # chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml
    3. 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
      [...]
  13. Eseguire la Fase 1 per creare tutti i ruoli possibili:

    root@master # salt-run state.orch ceph.stage.1
  14. Generare le sottodirectory richieste in /srv/pillar/ceph/stack:

    root@master # salt-run push.proposal
  15. 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.

  16. 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
  17. 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».

5.6 Eseguire l'upgrade da SUSE Enterprise Storage 4 (Crowbar Deployment) a 5

Importante
Importante: requisiti del software

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:

  1. Per ciascun nodo Ceph (compreso il nodo Calamari), arrestare e disabilitare tutti i servizi relativi a Crowbar:

    root@minion > sudo systemctl stop chef-client
    root@minion > sudo systemctl disable chef-client
    root@minion > sudo systemctl disable crowbar_join
    root@minion > sudo systemctl disable crowbar_notify_shutdown
  2. 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.

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

    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-minion
    root@minion > sudo systemctl start salt-minion
  5. 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.
  6. 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.

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

  8. Installare DeepSea sul Salt master:

    root@master # zypper in deepsea
  9. 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».

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

  11. 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
  12. Verificare che ceph status funzioni quando eseguito dal Salt master:

    root@master # ceph status
    cluster a705580c-a7ae-4fae-815c-5cb9c1ded6c2
    health HEALTH_OK
    [...]
  13. Importare il cluster esistente:

    root@master # salt-run populate.engulf_existing_cluster
    root@master # salt-run state.orch ceph.stage.1
    root@master # salt-run push.proposal
  14. 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:

    1. Su uno dei nodi iSCSI Gateway, esportare il lrbd.conf corrente e copiarlo nel nodo Salt master:

      root@minion > lrbd -o > /tmp/lrbd.conf
      root@minion > scp /tmp/lrbd.conf admin:/srv/salt/ceph/igw/cache/lrbd.conf
    2. 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.yml
      root@master # chown salt:salt /srv/pillar/ceph/stack/ceph/cluster.yml
    3. 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
      [...]
    1. Se i sistemi sono stati registrati con SUSEConnect e si utilizza SCC/SMT, non sono richieste ulteriori azioni.

    2. 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-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/Storage/5/x86_64/update/ SES5-UPDATES
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Products/SLE-SERVER/12-SP3/x86_64/product/ SLES12-SP3-POOL
      root # zypper ar \
       http://172.17.2.210:82/repo/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/ SLES12-SP3-UPDATES
      root # 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
      Suggerimento
      Suggerimento

      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.

  15. 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-0a
    root@master # salt d52-54-00-49-17-2a.example.com grains.set \
     host public.d52-54-00-49-17-2a
    root@master # salt d52-54-00-76-21-bc.example.com grains.set \
     host public.d52-54-00-76-21-bc
    root@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
  16. Eseguire l'upgrade:

    root@master # salt target state.apply ceph.updates
    root@master # salt target test.version
    root@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.

  17. Eseguire tutte le fasi di distribuzione richieste per portare il cluster a uno stato funzionale:

    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
  18. 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.2
    root@master # salt-run state.orch ceph.stage.4
  19. 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».

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

5.7 Eseguire l'upgrade da SUSE Enterprise Storage 3 a 5

Importante
Importante: requisiti del software

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

Stampa pagina