Amministrazione di Salt Cluster | Guida all'amministrazione

documentation.suse.com › Documentazione di SUSE Enterprise Storage 6 › Guida all'amministrazione › Gestione del cluster › Amministrazione di Salt Cluster

ContenutoContenuto

Guida all'amministrazione

Navigazione←→

Si applica a SUSE Enterprise Storage 6

2 Amministrazione di Salt Cluster #

2.1 Aggiunta di nuovi nodi cluster
2.2 Aggiunta di nuovi ruoli ai nodi
2.3 Rimozione e reinstallazione dei nodi del cluster
2.4 Ridistribuzione dei nodi di monitoraggio
2.5 Aggiunta di un disco OSD a un nodo
2.6 Rimozione di un OSD
2.7 Sostituzione di un disco OSD
2.8 Recupero di un nodo OSD reinstallato
2.9 Spostamento del nodo admin su un nuovo server
2.10 Installazione automatizzata tramite Salt
2.11 Aggiornamento dei nodi del cluster
2.12 Interruzione o riavvio del cluster
2.13 Regolazione di ceph.conf tramite le impostazioni personalizzate
2.14 Abilitazione dei profili AppArmor
2.15 Disattivazione dei profili ottimizzati
2.16 Rimozione dell'intero cluster Ceph

Dopo aver distribuito un cluster Ceph, potrà essere necessario apportare occasionalmente alcune modifiche. Tra queste sono incluse l'aggiunta o la rimozione di nuovi nodi, dischi o servizi. In questo capitolo è descritto come compiere tali task amministrativi.

2.1 Aggiunta di nuovi nodi cluster #

La procedura per aggiungere nuovi nodi al cluster è pressoché identica alla distribuzione dei nodi cluster iniziale descritta in Capitolo 5, Installazione con DeepSea/Salt:

Suggerimento: impedire il ribilanciamento

Tenere presente che quando si aggiunge un OSD al cluster esistente, successivamente questo ne eseguirà il ribilanciamento per un periodo di tempo. Per ridurre al minimo i periodi di ribilanciamento, aggiungere contemporaneamente tutti gli OSD previsti.

In alternativa, impostare l'opzione osd crush initial weight = 0 nel file ceph.conf prima di aggiungere gli OSD:

Aggiungere osd crush initial weight = 0 a /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf.

Creare la nuova configurazione sul nodo Salt master:

root@master # salt 'SALT_MASTER_NODE' state.apply ceph.configuration.create

Applicare la nuova configurazione ai minion OSD di destinazione:

root@master # salt 'OSD_MINIONS' state.apply ceph.configuration

Dopo aver aggiunto i nuovi OSD, modificarne il peso in base alle esigenze utilizzando il comando ceph osd crush reweight.

Installare SUSE Linux Enterprise Server 15 SP1 sul nuovo nodo e configurarne le impostazioni di rete in modo che il nome host del Salt master venga risolto correttamente. Verificare che la connessione alla rete pubblica e a quella del cluster sia corretta e che la sincronizzazione dell'orario sia configurata correttamente. Quindi, installare il pacchetto salt-minion:
```
root@minion > zypper in salt-minion
```
Se il nome host del Salt master è diverso da salt, modificare /etc/salt/minion e aggiungere quanto segue:
```
master: DNS_name_of_your_salt_master
```
Se sono state apportate modifiche ai file di configurazione di cui sopra, riavviare il servizio salt.minion:
```
root@minion > systemctl restart salt-minion.service
```
Sul Salt master, accettare la chiave salt sul nuovo nodo:
```
root@master # salt-key --accept NEW_NODE_KEY
```
Verificare che /srv/pillar/ceph/deepsea_minions.sls utilizzi come destinazione il nuovo Salt minion e/o impostare il grain DeepSea corretto. Per ulteriori dettagli, consultare questo riferimento: Sezione 5.2.2.1, «Corrispondenza del nome del minion» o:Procedura 5.1, «Esecuzione delle fasi di distribuzione».
Eseguire la fase di preparazione. Moduli e grain (piccoli elementi di dati) vengono sincronizzati in modo che il nuovo minion possa fornire tutte le informazioni che DeepSea si aspetta.
```
root@master # salt-run state.orch ceph.stage.0
```
Importante: possibile riavvio della fase 0 di DeepSea
Se il Salt master si è riavviato dopo l'aggiornamento del kernel, è necessario riavviare la fase 0 di DeepSea.
Eseguire la fase di rilevazione. Verranno scritte nuove voci di file nella directory /srv/pillar/ceph/proposals in cui è possibile modificare i file .yml pertinenti:
```
root@master # salt-run state.orch ceph.stage.1
```
Se lo si desidera, modificare /srv/pillar/ceph/proposals/policy.cfg se l'host appena aggiunto non corrisponde allo schema di denominazione esistente. Per ulteriori informazioni, fare riferimento a Sezione 5.5.1, «Il file policy.cfg».
Eseguire la fase di configurazione. Viene letto tutto ciò che risiede in /srv/pillar/ceph e Pillar viene aggiornato di conseguenza:
```
root@master # salt-run state.orch ceph.stage.2
```
Pillar memorizza i dati cui è possibile accedere con il seguente comando:
```
root@master # salt target pillar.items
```
Suggerimento: modifica del layout dell'OSD
Se si desidera modificare il layout di default dell'OSD e la configurazione dei gruppi di unità, seguire la procedura descritta nel riferimento Sezione 5.5.2, «DriveGroups».

Le fasi di configurazione e distribuzione includono i nodi aggiunti di recente:

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

2.2 Aggiunta di nuovi ruoli ai nodi #

È possibile distribuire tutti i tipi di ruoli supportati con DeepSea. Vedere Sezione 5.5.1.2, «Assegnazione ruolo» per ulteriori informazioni sui tipi di ruoli supportati ed esempi della rispettiva corrispondenza.

Per aggiungere un nuovo servizio a un nodo esistente, seguire la procedura indicata di seguito:

Adattare /srv/pillar/ceph/proposals/policy.cfg in modo che corrisponda all'host esistente con il nuovo ruolo. Per ulteriori informazioni, fare riferimento a Sezione 5.5.1, «Il file policy.cfg». Ad esempio, se è necessario eseguire un Object Gateway su un nodo MON, la riga è simile a:
```
role-rgw/xx/x/example.mon-1.sls
```

Eseguire la fase 2 per aggiornare il Pillar:

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

Eseguire la fase 3 per distribuire i servizi di base o la fase 4 per distribuire quelli opzionali. È anche possibile eseguire entrambe le fasi.

2.3 Rimozione e reinstallazione dei nodi del cluster #

Suggerimento: rimozione temporanea di un nodo del cluster

Il Salt master si aspetta che tutti i minion siano reattivi e all'interno del cluster. Se un minion si interrompe e non è più reattivo, causerà problemi all'infrastruttura Salt, soprattutto ai dashboard DeepSea e Ceph.

Prima di riparare il minion, eliminarne temporaneamente la chiave dal Salt master:

root@master # salt-key -d MINION_HOST_NAME

Dopo la riparazione del minion, aggiungere nuovamente la relativa chiave al Salt master:

root@master # salt-key -a MINION_HOST_NAME

Per rimuovere un ruolo da un cluster, modificare /srv/pillar/ceph/proposals/policy.cfg e rimuovere le righe di corrispondenti. Eseguire quindi le fasi 2 e 5 come descritto nel riferimento Sezione 5.3, «Distribuzione del cluster».

Nota: rimozione degli OSD dal cluster

Qualora fosse necessario rimuovere un determinato nodo OSD dal cluster, assicurarsi che questo disponga di uno spazio libero su disco maggiore rispetto al disco che si intende rimuovere. Tenere presente che la rimozione di un OSD comporta il ribilanciamento dell'intero cluster.

Prima di eseguire la rimozione effettiva tramite la fase 5, verificare sempre quali OSD verranno rimossi da DeepSea:

root@master # salt-run rescinded.ids

Quando si rimuove un ruolo da un minion, l'obiettivo è annullare tutte le modifiche correlate a tale ruolo. Per la maggior parte dei ruoli, il task è semplice, ma potrebbero verificarsi problemi con le dipendenze del pacchetto. Se un pacchetto è disinstallato, le dipendenze non lo sono.

Gli OSD rimossi figurano come unità vuote. I task correlati sovrascrivono la parte iniziale dei file system e rimuovono le partizioni di backup oltre a cancellare le tabelle delle partizioni.

Nota: conservazione delle partizioni create mediante altri metodi

È possibile che le unità disco configurate precedentemente mediante altri metodi, come ceph-deploy, contengano comunque partizioni che non verranno distrutte automaticamente da DeepSea. L'amministratore deve recuperare tali unità manualmente.

Esempio 2.1: Rimozione di un Salt minion dal cluster #

Se si assegna un nome ai minion di memorizzazione, ad esempio, "data1.ceph", "data2.ceph" ... "data6.ceph" e le righe correlate nel file policy.cfg sono simili a quanto segue:

[...]
# Hardware Profile
role-storage/cluster/data*.sls
[...]

Per rimuovere il Salt minion "data2.ceph", modificare le righe come indicato di seguito:

[...]
# Hardware Profile
role-storage/cluster/data[1,3-6]*.sls
[...]

Inoltre, ricordarsi di adattare il file drive_groups.yml in base alle nuove destinazioni.

    [...]
    drive_group_name:
      target: 'data[1,3-6]*'
    [...]

Eseguire quindi la fase 2, verificare quali OSD verranno rimossi e terminare l'operazione eseguendo la fase 5:

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

Esempio 2.2: Migrazione dei nodi #

Presupporre la seguente situazione: durante la nuova installazione del cluster, l'amministratore ha allocato uno dei nodi di memorizzazione come Object Gateway autonomo durante l'attesa dell'arrivo dell'hardware del gateway. Adesso l'hardware permanente è disponibile per il gateway e finalmente è possibile assegnare il ruolo desiderato al nodo di memorizzazione di backup e rimuovere il ruolo gateway.

Dopo aver eseguito le fasi 0 e 1 (consultare questo riferimento: Procedura 5.1, «Esecuzione delle fasi di distribuzione») per il nuovo hardware, il nuovo gateway viene denominato rgw1. Se per il nodo data8 è necessario che venga rimosso il ruolo Object Gateway, che venga aggiunto il ruolo di memorizzazione e policy.cfg presenta il seguente aspetto:

# Hardware Profile
role-storage/cluster/data[1-7]*.sls

# Roles
role-rgw/cluster/data8*.sls

Modificarlo in:

# Hardware Profile
role-storage/cluster/data[1-8]*.sls

# Roles
role-rgw/cluster/rgw1*.sls

Eseguire le fasi da 2 a 4, verificare quali OSD verranno probabilmente rimossi e terminare l'operazione eseguendo la fase 5. Nella fase 3 verrà aggiunto data8 come nodo di memorizzazione. Per un breve periodo, data8 avrà entrambi i ruoli. Il ruolo Object Gateway verrà aggiunto a rgw1 durante la fase 4 e verrà rimosso da data8 durante la fase 5:

root@master # salt-run state.orch ceph.stage.2
root@master # salt-run state.orch ceph.stage.3
root@master # salt-run state.orch ceph.stage.4
root@master # salt-run rescinded.ids
root@master # salt-run state.orch ceph.stage.5

2.4 Ridistribuzione dei nodi di monitoraggio #

Quando uno o più nodi di monitoraggio vengono meno e non rispondono, è necessario rimuoverli dal cluster e possibilmente aggiungerli nuovamente.

Importante: il numero minimo di nodi di monitoraggio è tre

Il numero di nodi di monitoraggio non deve essere inferiore a tre. Se un nodo di monitoraggio viene meno e di conseguenza nel cluster ne rimangono solo due, è necessario assegnare temporaneamente il ruolo di monitoraggio agli altri nodi del cluster prima di ridistribuire i nodi di monitoraggio con errore. Dopo la distribuzione dei nodi di monitoraggio con errore, è possibile disinstallare temporaneamente ruoli di monitoraggio.

Per ulteriori informazioni sull'aggiunta di nuovi nodi/ruoli al cluster Ceph, vedere Sezione 2.1, «Aggiunta di nuovi nodi cluster» e Sezione 2.2, «Aggiunta di nuovi ruoli ai nodi».

Per ulteriori informazioni sulla rimozione dei nodi cluster, fare riferimento a Sezione 2.3, «Rimozione e reinstallazione dei nodi del cluster».

Un nodo Ceph ha due gradi di errore di base:

L'host Salt minion è interrotto fisicamente o a livello di sistema operativo e non risponde alla chiamata salt 'minion_name' test.ping. In tal caso è necessario ridistribuire completamente il server seguendo le istruzioni pertinenti incluse in Sezione 5.3, «Distribuzione del cluster».
I servizi correlati al monitoraggio vengono meno e il recupero è impossibile, ma l'host risponde alla chiamata salt 'minion_name' test.ping. In tal caso, seguire la procedura indicata di seguito:

Modificare /srv/pillar/ceph/proposals/policy.cfg sul Salt master e rimuovere o aggiornare le righe che corrispondono ai nodi di monitoraggio con errore in modo che questi puntino ai nodi di monitoraggio in funzione. Ad esempio:
```
[...]
# MON
#role-mon/cluster/ses-example-failed1.sls
#role-mon/cluster/ses-example-failed2.sls
role-mon/cluster/ses-example-new1.sls
role-mon/cluster/ses-example-new2.sls
[...]
```

Eseguire le fasi da 2 a 5 di DeepSea per applicare le modifiche:

root@master # deepsea stage run ceph.stage.2
root@master # deepsea stage run ceph.stage.3
root@master # deepsea stage run ceph.stage.4
root@master # deepsea stage run ceph.stage.5

2.5 Aggiunta di un disco OSD a un nodo #

Per aggiungere un disco a un nodo OSD esistente, verificare che sul disco siano state rimosse e cancellate tutte le partizioni. Per ulteriori dettagli, fare riferimento a Passo 12 in Sezione 5.3, «Distribuzione del cluster». Adattare /srv/salt/ceph/configuration/files/drive_groups.yml di conseguenza (per i dettagli, consultare questo riferimento: Sezione 5.5.2, «DriveGroups»). Dopo aver salvato il file, eseguire la fase 3 di DeepSea:

root@master # deepsea stage run ceph.stage.3

2.6 Rimozione di un OSD #

È possibile rimuovere un Ceph OSD dal cluster eseguendo il seguente comando:

root@master # salt-run osd.remove OSD_ID

OSD_ID deve essere un numero dell'OSD senza il termine osd. prefisso. Ad esempio, da osd.3 utilizzare solo la cifra 3.

2.6.1 Rimozione di più OSD #

Seguire la stessa procedura descritta nella Sezione 2.6, «Rimozione di un OSD», ma specificando semplicemente più ID OSD:

root@master # salt-run osd.remove 2 6 11 15
Removing osd 2 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.2 is safe to destroy
Purging from the crushmap
Zapping the device


Removing osd 6 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.6 is safe to destroy
Purging from the crushmap
Zapping the device


Removing osd 11 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.11 is safe to destroy
Purging from the crushmap
Zapping the device


Removing osd 15 on host data1
Draining the OSD
Waiting for ceph to catch up.
osd.15 is safe to destroy
Purging from the crushmap
Zapping the device


2:
True
6:
True
11:
True
15:
True

2.6.2 Rimozione di tutti gli OSD in un host #

Per rimuovere tutti gli OSD in un host specifico, eseguire il comando seguente:

root@master # salt-run osd.remove OSD_HOST_NAME

2.6.3 Rimozione forzata degli OSD interrotti #

In alcuni casi la rimozione di un OSD si conclude con un errore non grave (vedere Sezione 2.6, «Rimozione di un OSD»). Ciò può verificarsi, ad esempio, se l'OSD o il rispettivo dispositivo journal, WAL o DB vengono interrotti, a causa di operazioni I/O in sospeso o quando è impossibile smontare il disco OSD.

root@master # salt-run osd.remove OSD_ID force=True

Suggerimento: montaggi in sospeso

Se una partizione è ancora montata sul disco in fase di rimozione, il comando restituirà il messaggio "Unmount failed - check for processes on DEVICE". È quindi possibile visualizzare un elenco di tutti i processi che accedono al file system con fuser -m DEVICE. Se fuser non restituisce nessun risultato, provare con il comando manuale unmount DEVICE e osservare l'output dei comandi dmesg o journalctl.

2.6.4 Convalida dei metadati LVM dell'OSD #

In seguito alla rimozione di un OSD tramite salt-run osd.remove ID o altri comandi di Ceph, i metadati LVM potrebbero non essere rimossi completamente. Di conseguenza, se si desidera ridistribuire un nuovo OSD, verranno utilizzati i metadati LVM precedenti.

Innanzitutto, verificare che l'OSD sia stato rimosso:

cephadm@osd > ceph-volume lvm list

L'OSD può essere presente nell'elenco anche se è stato rimosso correttamente. Ad esempio, se è stato rimosso osd.2, l'output sarà il seguente:

  ====== osd.2 =======

  [block] /dev/ceph-a2189611-4380-46f7-b9a2-8b0080a1f9fd/osd-data-ddc508bc-6cee-4890-9a42-250e30a72380

  block device /dev/ceph-a2189611-4380-46f7-b9a2-8b0080a1f9fd/osd-data-ddc508bc-6cee-4890-9a42-250e30a72380
  block uuid kH9aNy-vnCT-ExmQ-cAsI-H7Gw-LupE-cvSJO9
  cephx lockbox secret
  cluster fsid 6b6bbac4-eb11-45cc-b325-637e3ff9fa0c
  cluster name ceph
  crush device class None
  encrypted 0
  osd fsid aac51485-131c-442b-a243-47c9186067db
  osd id 2
  type block
  vdo 0
  devices /dev/sda

In questo esempio, è possibile osservare che osd.2 è ancora ubicato in /dev/sda.

Convalidare i metadati LVM sul nodo OSD:

cephadm@osd > ceph-volume inventory

L'output derivante dall'esecuzione di ceph-volume inventory contrassegna la disponibilità /dev/sda come False. Ad esempio:

  Device Path Size rotates available Model name
  /dev/sda 40.00 GB True False QEMU HARDDISK
  /dev/sdb 40.00 GB True False QEMU HARDDISK
  /dev/sdc 40.00 GB True False QEMU HARDDISK
  /dev/sdd 40.00 GB True False QEMU HARDDISK
  /dev/sde 40.00 GB True False QEMU HARDDISK
  /dev/sdf 40.00 GB True False QEMU HARDDISK
  /dev/vda 25.00 GB True False

Eseguire il comando seguente sul nodo OSD per rimuovere completamente i metadati LVM:
```
cephadm@osd > ceph-volume lvm zap --osd-id ID --destroy
```

Eseguire nuovamente il comando inventory per verificare che la disponibilità /dev/sda restituisca il valore True. Ad esempio:

cephadm@osd > ceph-volume inventory
Device Path Size rotates available Model name
/dev/sda 40.00 GB True True QEMU HARDDISK
/dev/sdb 40.00 GB True False QEMU HARDDISK
/dev/sdc 40.00 GB True False QEMU HARDDISK
/dev/sdd 40.00 GB True False QEMU HARDDISK
/dev/sde 40.00 GB True False QEMU HARDDISK
/dev/sdf 40.00 GB True False QEMU HARDDISK
/dev/vda 25.00 GB True False

I metadati LVM sono stati rimossi e adesso è possibile eseguire il comando dd sul dispositivo.

A questo punto, è possibile ridistribuire l'OSD senza dover riavviare il nodo OSD:

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

2.7 Sostituzione di un disco OSD #

Potrebbe essere necessario sostituire un disco OSD per diverse ragioni, ad esempio:

Si sono verificati o si verificheranno a breve errori sul disco OSD in base alle informazioni SMART e il disco non può più essere utilizzato per memorizzare i dati in modo sicuro.
È necessario eseguire l'upgrade del disco OSD, ad esempio per aumentarne le dimensioni.

La procedura di sostituzione è la stessa per entrambi i casi. È inoltre valida per le mappe CRUSH di default e personalizzate.

Presupporre ad esempio che "5" sia l'ID dell'OSD di cui è necessario sostituire il disco. Il comando seguente lo contrassegna come eliminato definitivamente nella mappa CRUSH, ma conserva il suo ID originale:
```
root@master # salt-run osd.replace 5
```
Suggerimento: osd.replace e osd.remove
I comandi osd.replace e osd.remove di Salt (vedere la Sezione 2.6, «Rimozione di un OSD») sono identici tranne per il fatto che osd.replace lascia l'OSD nello stato "destroyed" (eliminato definitivamente) nella mappa CRUSH, mentre osd.remove ne rimuove tutte le tracce dalla mappa CRUSH.
Sostituire manualmente l'unità OSD con errori/sottoposta a upgrade.
Se si desidera modificare il layout di default dell'OSD e la configurazione dei DriveGroups, seguire la procedura descritta nel riferimento Sezione 5.5.2, «DriveGroups».
Eseguire la fase 3 di distribuzione per distribuire il disco OSD sostituito:
```
root@master # salt-run state.orch ceph.stage.3
```

2.8 Recupero di un nodo OSD reinstallato #

Se il sistema operativo si interrompe ed è impossibile recuperarlo su uno dei nodi OSD, seguire la procedura indicata di seguito per recuperarlo e ridistribuirne il ruolo OSD con dati del cluster invariati:

Reinstallare il sistema operativo SUSE Linux Enterprise di base sul nodo contenente il sistema operativo interrotto. Installare i pacchetti salt-minion sul nodo OSD, eliminare la chiave precedente del Salt minion sul Salt master e registrare la nuova chiave del Salt minion sul Salt master. Per ulteriori informazioni sulla distribuzione iniziale, consultare questo riferimento: Sezione 5.3, «Distribuzione del cluster».

Invece di eseguire l'intera fase 0, concentrarsi sulle parti seguenti:

root@master # salt 'osd_node' state.apply ceph.sync
root@master # salt 'osd_node' state.apply ceph.packages.common
root@master # salt 'osd_node' state.apply ceph.mines
root@master # salt 'osd_node' state.apply ceph.updates

Eseguire le fasi da 1 a 5 di DeepSea:

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

Eseguire la fase 0 di DeepSea:

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

Riavviare il nodo OSD pertinente. Tutti i dischi OSD verranno rilevati e riutilizzati.

Installare/eseguire l'utilità di esportazione del nodo di Prometheus:

root@master # salt 'RECOVERED_MINION' \
 state.apply ceph.monitoring.prometheus.exporters.node_exporter

Aggiornare i grain Salt:

root@master # salt 'RECOVERED_MINION' osd.retain

2.9 Spostamento del nodo admin su un nuovo server #

Se è necessario sostituire l'host del nodo admin con uno nuovo, spostare i file del Salt master e di DeepSea utilizzando uno strumento di sincronizzazione di propria scelta. In questa procedura, viene utilizzato rsync poiché si tratta di uno strumento standard disponibile negli archivi software di SUSE Linux Enterprise Server 15 SP1.

Interrompere i servizi salt-master e salt-minion sul nodo admin precedente:

root@master # systemctl stop salt-master.service
root@master # systemctl stop salt-minion.service

Configurare Salt sul nuovo nodo admin per consentire la comunicazione tra il Salt master e i Salt minion. Ulteriori dettagli sono disponibili in Sezione 5.3, «Distribuzione del cluster».
Suggerimento: transizione dei Salt minion
Per semplificare la transizione dei Salt minion sul nuovo nodo admin, rimuovere la chiave pubblica originale del Salt master da ciascuno di questi:
```
root@minion > rm /etc/salt/pki/minion/minion_master.pub
root@minion > systemctl restart salt-minion.service
```
Verificare che il pacchetto deepsea sia installato e installarlo se necessario.
```
root@master # zypper install deepsea
```
Personalizzare il file policy.cfg modificando la riga role-master. Ulteriori dettagli sono disponibili in Sezione 5.5.1, «Il file policy.cfg».
Sincronizzare le directory /srv/pillar e /srv/salt del nodo admin precedente con quello nuovo.
Suggerimento: esecuzione di prova di rsync e collegamenti simbolici
Se possibile, provare la sincronizzazione dei file in modalità di esecuzione di prova per verificare quali verranno traferiti (opzione di rsync -n). Inoltre, includere i collegamenti simbolici (opzione di rsync -a). Per rsync, il comando di sincronizzazione avrà l'aspetto seguente:
```
root@master # rsync -avn /srv/pillar/ NEW-ADMIN-HOSTNAME:/srv/pillar
```
Se sono state apportate modifiche personalizzate ai file al di fuori di /srv/pillar e /srv/salt, ad esempio in /etc/salt/master o /etc/salt/master.d, sincronizzare anche questi ultimi.
Adesso è possibile eseguire le fasi di DeepSea dal nuovo nodo admin. Per la descrizione dettagliata, consultare questo riferimento: Sezione 5.2, «Introduzione a DeepSea».

2.10 Installazione automatizzata tramite Salt #

È possibile automatizzare l'installazione mediante l'uso di Salt Reactor. Per gli ambienti virtuali o di hardware coerenti, questa configurazione consentirà di creare un cluster Ceph con il comportamento specificato.

Avviso

Salt non è in grado di effettuare verifiche della dipendenza in base agli eventi del reattore. Vi è il rischio effettivo di sovraccarico del Salt master o che questo non risponda più.

Per l'installazione automatizzata è richiesto quanto segue:

Un file /srv/pillar/ceph/proposals/policy.cfg creato in modo appropriato.
La preparazione di configurazione personalizzata posizionata nella directory /srv/pillar/ceph/stack.

Nella configurazione del reattore di default verranno eseguite solo le fasi 0 e 1. In tal modo è possibile testare il reattore senza dover attendere il completamento delle fasi successive.

All'avvio del primo salt-minion avrà inizio la fase 0. Un blocco impedisce più istanze. Quando tutti i minion completano la fase 0, avrà inizio la fase 1.

Se l'operazione viene eseguita correttamente, modificare il file

/etc/salt/master.d/reactor.conf

e sostituire la riga seguente

- /srv/salt/ceph/reactor/discovery.sls

con

- /srv/salt/ceph/reactor/all_stages.sls

Verificare che la riga non sia impostata come commento.

2.11 Aggiornamento dei nodi del cluster #

Mantenere i nodi del cluster Ceph aggiornati applicando regolarmente gli aggiornamenti in sequenza.

2.11.1 Archivi software #

Prima di applicare le patch al cluster con i pacchetti software più recenti, verificare che tutti i nodi del cluster dispongano dell'accesso agli archivi pertinenti. Per un elenco completo degli archivi obbligatori, consultare questo riferimento: Sezione 6.8.1, «Esecuzione dell'upgrade manuale dei nodi tramite il DVD del programma di installazione».

2.11.2 Gestione provvisoria dell'archivio #

Se si utilizza uno strumento di gestione provvisoria, ad esempio SUSE Manager, Subscription Management Tool (SMT) o Repository Mirroring Tool, tramite cui implementare gli archivi software sui nodi del cluster, verificare che le fasi degli archivi "Updates" di SUSE Linux Enterprise Server e SUSE Enterprise Storage vengano create nello stesso momento.

Si consiglia di utilizzare uno strumento di gestione provvisoria per applicare patch con livelli di patch bloccati/con gestione provvisoria. In questo modo, sarà possibile assicurarsi che i nuovi nodi uniti al cluster dispongano dello stesso livello di patch dei nodi già in esecuzione al suo interno. Questo evita di dover applicare le patch più recenti a tutti i nodi del cluster prima che i nuovi nodi possano unirsi a quest'ultimo.

2.11.3 `zypper patch` o `zypper dup` #

Per default, l'upgrade dei nodi del cluster viene eseguito con il comando zypper dup. Se si preferisce aggiornare il sistema utilizzando invece zypper patch, modificare /srv/pillar/ceph/stack/global.yml e aggiungere la riga seguente:

update_method_init: zypper-patch

2.11.4 Riavvi del nodo del cluster #

Durante l'aggiornamento, è possibile scegliere di riavviare i nodi del cluster se è stato eseguito l'upgrade anche del relativo kernel. Se si desidera eliminare la possibilità di un riavvio forzato potenzialmente di tutti i nodi, verificare che la versione più recente del kernel sia installata e in esecuzione sui nodi Ceph o disabilitare i riavvi automatici del nodo come descritto nel riferimento Sezione 7.1.5, «Aggiornamenti e riavvii durante la fase 0».

2.11.5 Tempo di fermo dei servizi Ceph #

A seconda della configurazione, i nodi del cluster potrebbero essere riavviati durante l'aggiornamento come descritto nella Sezione 2.11.4, «Riavvi del nodo del cluster». Se è presente un single point of failure per servizi come Object Gateway, gateway Samba, NFS Ganesha o iSCSI, i computer del client potrebbero essere temporaneamente disconnessi dai servizi i cui nodi sono in corso di riavvio.

2.11.6 Esecuzione dell'aggiornamento #

Per aggiornare i pacchetti software su tutti i nodi del cluster alla versione più recente, seguire la procedura indicata di seguito:

Aggiornare i pacchetti deepsea, salt-mastere salt-minion e riavviare i servizi pertinenti sul Salt master:
```
root@master # salt -I 'roles:master' state.apply ceph.updates.master
```
Aggiornare e riavviare il pacchetto salt-minion in tutti i nodi del cluster:
```
root@master # salt -I 'cluster:ceph' state.apply ceph.updates.salt
```

Aggiornare tutti gli altri pacchetti software nel cluster:

root@master # salt-run state.orch ceph.maintenance.upgrade

2.12 Interruzione o riavvio del cluster #

In alcuni casi può essere necessario interrompere o riavviare l'intero cluster. Si consiglia di verificare attentamente le dipendenze dei servizi in esecuzione. Nei passaggi successivi è descritto come interrompere e avviare il cluster:

Indicare al cluster Ceph di impostare il flag noout:
```
cephadm@adm > ceph osd set noout
```
Interrompere daemon e nodi nel seguente ordine:
1. Client di memorizzazione
2. Gateway, ad esempio NFS Ganesha o Object Gateway
3. Metadata Server
4. Ceph OSD
5. Ceph Manager
6. Ceph Monitor
Se necessario, eseguire task di manutenzione.
Avviare nodi e server in ordine inverso rispetto al processo di spegnimento:
1. Ceph Monitor
2. Ceph Manager
3. Ceph OSD
4. Metadata Server
5. Gateway, ad esempio NFS Ganesha o Object Gateway
6. Client di memorizzazione
Rimuovere il flag noout:
```
cephadm@adm > ceph osd unset noout
```

2.13 Regolazione di `ceph.conf` tramite le impostazioni personalizzate #

Se è necessario inserire impostazioni personalizzate nel file ceph.conf, è possibile farlo modificando i file di configurazione nella directory /srv/salt/ceph/configuration/files/ceph.conf.d:

global.conf
mon.conf
mgr.conf
mds.conf
osd.conf
client.conf
rgw.conf

Nota: `rgw.conf` univoco

Object Gateway offre elevata flessibilità ed è univoco rispetto alle altre sezioni di ceph.conf. Tutti gli altri componenti Ceph presentano intestazioni statiche, come [mon] o [osd]. Object Gateway ha intestazioni univoche, come [client.rgw.rgw1]. Vale a dire che per il file rgw.conf è necessaria una voce intestazione. Per gli esempi, vedere

/srv/salt/ceph/configuration/files/rgw.conf

oppure

/srv/salt/ceph/configuration/files/rgw-ssl.conf

Importante: esecuzione della fase 3

Dopo aver apportato modifiche personalizzate ai file di configurazione di cui sopra, eseguire le fasi 3 e 4 per applicarle ai nodi del cluster:

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

Questi file vengono inclusi dal file modello /srv/salt/ceph/configuration/files/ceph.conf.j2 e corrispondono alle diverse sezioni accettate dal file di configurazione Ceph. L'inserimento di un frammento di configurazione nel file corretto consente a DeepSea di posizionarlo nella sezione esatta. Non è necessario aggiungere alcuna intestazione di sezione.

Suggerimento

Per applicare un'opzione di configurazione a istanze specifiche di un daemon, aggiungere un'intestazione come [osd.1]. Le opzioni di configurazione seguenti verranno applicate solo al daemon OSD con ID 1.

2.13.1 Sostituzione delle impostazioni di default #

Le istruzioni più recenti in una sezione sostituiscono quelle precedenti. Pertanto, è possibile sostituire la configurazione di default come specificato nel modello /srv/salt/ceph/configuration/files/ceph.conf.j2. Ad esempio, per disattivare l'autenticazione cephx, aggiungere le tre righe seguenti al file /srv/salt/ceph/configuration/files/ceph.conf.d/global.conf:

auth cluster required = none
auth service required = none
auth client required = none

Durante la ridefinizione dei valori di default, gli strumenti correlati a Ceph, come rados, potrebbero generare avvisi per informare che valori specifici di ceph.conf.j2 sono stati ridefiniti in global.conf. Questi avvisi vengono generati poiché è presente un parametro assegnato due volte nel file ceph.conf risultante.

Come soluzione di questo caso specifico, seguire la procedura indicata di seguito:

Modificare la directory attuale in /srv/salt/ceph/configuration/create:
```
root@master # cd /srv/salt/ceph/configuration/create
```
Copiare default.sls in custom.sls:
```
root@master # cp default.sls custom.sls
```
Modificare custom.sls e cambiare ceph.conf.j2 in custom-ceph.conf.j2.
Modificare la directory attuale in /srv/salt/ceph/configuration/files:
```
root@master # cd /srv/salt/ceph/configuration/files
```

Copiare ceph.conf.j2 in custom-ceph.conf.j2:

root@master # cp ceph.conf.j2 custom-ceph.conf.j2

Modificare custom-ceph.conf.j2 ed eliminare la riga seguente:
```
{% include "ceph/configuration/files/rbd.conf" %}
```
Modificare global.yml e aggiungere la riga seguente:
```
configuration_create: custom
```

Aggiornare il Pillar:

root@master # salt target saltutil.pillar_refresh

Eseguire la fase 3:

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

Adesso, dovrebbe essere presente una sola voce per ciascuna definizione di valore. Per creare nuovamente la configurazione, eseguire:

root@master # salt-run state.orch ceph.configuration.create

e verificare i contenuti di /srv/salt/ceph/configuration/cache/ceph.conf.

2.13.2 Inclusione di file di configurazione #

Se è necessario applicare numerose configurazioni personalizzate, utilizzare le istruzioni di inclusione seguenti nei file di configurazione per rendere più semplice la gestione dei file. Di seguito è riportato un esempio di file osd.conf:

[osd.1]
{% include "ceph/configuration/files/ceph.conf.d/osd1.conf" ignore missing %}
[osd.2]
{% include "ceph/configuration/files/ceph.conf.d/osd2.conf" ignore missing %}
[osd.3]
{% include "ceph/configuration/files/ceph.conf.d/osd3.conf" ignore missing %}
[osd.4]
{% include "ceph/configuration/files/ceph.conf.d/osd4.conf" ignore missing %}

Nell'esempio precedente, i file osd1.conf, osd2.conf, osd3.conf e osd4.conf contengono le opzioni di configurazione specifiche per l'OSD correlato.

Suggerimento: configurazione di runtime

Le modifiche apportate ai file di configurazione Ceph vengono applicate dopo il riavvio dei daemon Ceph correlati. Per ulteriori informazioni sulla modifica della configurazione di runtime Ceph, vedere Sezione 16.1, «configurazione di runtime».

2.14 Abilitazione dei profili AppArmor #

AppArmor è una soluzione di sicurezza che associa i programmi a un profilo specifico per limitarne le capacità. Per ulteriori informazioni, fare riferimento alla https://www.suse.com/documentation/sles-15/book_security/data/part_apparmor.html.

In DeepSea sono disponibili tre stati per i profili AppArmor: "enforce", "complain" e "disable". Per attivare uno stato AppArmor specifico, eseguire:

salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-STATE

Per attivare lo stato "enforce" sui profili AppArmor:

root@master # salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-enforce

Per attivare lo stato "complain" sui profili AppArmor:

root@master # salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-complain

Per disabilitare i profili AppArmor:

root@master # salt -I "deepsea_minions:*" state.apply ceph.apparmor.default-disable

Suggerimento: abilitazione del servizio AppArmor

Ognuna di queste tre chiamate consente di verificare se AppArmor è installato, installandolo se necessario, e di avviare e abilitare il servizio systemd correlato. DeepSea avviserà l'utente se AppArmor è stato installato e avviato/abilitato secondo una procedura diversa e se è quindi in esecuzione senza profili DeepSea.

2.15 Disattivazione dei profili ottimizzati #

Per default, DeepSea distribuisce i cluster Ceph con profili ottimizzati attivi sui nodi Ceph Monitor, Ceph Manager e Ceph OSD. In alcuni casi può essere necessario disattivare definitivamente i profili ottimizzati. Per farlo, inserire le righe seguenti in /srv/pillar/ceph/stack/global.yml ed eseguire nuovamente la fase 3:

alternative_defaults:
 tuned_mgr_init: default-off
 tuned_mon_init: default-off
 tuned_osd_init: default-off

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

2.16 Rimozione dell'intero cluster Ceph #

Lo strumento di esecuzione ceph.purge consente di rimuovere l'intero cluster Ceph. In questo modo è possibile pulire l'ambiente del cluster durante il test di diverse configurazioni. Al completamento di ceph.purge, il cluster Salt viene ripristinato nello stato in cui si trovava al termine della fase 1 di DeepSea. È possibile quindi modificare policy.cfg (consultare questo riferimento: Sezione 5.5.1, «Il file policy.cfg») oppure passare alla fase 2 di DeepSea con la stessa configurazione.

Per evitare eliminazioni involontarie, lo strumento di coordinamento controlla se le misure di sicurezza sono disattivate. È possibile disattivare le misure di sicurezza e rimuovere il cluster Ceph eseguendo:

root@master # salt-run disengage.safety
root@master # salt-run state.orch ceph.purge

Suggerimento: disabilitazione della rimozione del cluster Ceph

Se si desidera impedire l'esecuzione dello strumento ceph.purge, creare un file denominato disabled.sls nella directory /srv/salt/ceph/purge e inserire la riga seguente nel file /srv/pillar/ceph/stack/global.yml:

purge_init: disabled

Importante: revoca dei ruoli personalizzati

Se in precedenza sono stati creati ruoli personalizzati per il Ceph Dashboard (per le informazioni dettagliate fare riferimento alla Sezione 22.2.6, «Aggiunta di ruoli personalizzati» e alla Sezione 22.10.2, «Ruoli e autorizzazioni dell'utente»), eliminarli definitivamente seguendo dei passaggi manuali prima di eseguire lo strumento di esecuzione ceph.purge. Ad esempio, se il ruolo personalizzato di Object Gateway è denominato "us-east-1", seguire la procedura indicata di seguito:

root@master # cd /srv/salt/ceph/rescind
root@master # rsync -a rgw/ us-east-1
root@master # sed -i 's!rgw!us-east-1!' us-east-1/*.sls

Stampa pagina

Guida all'amministrazione

2 Amministrazione di Salt Cluster #

2.1 Aggiunta di nuovi nodi cluster #

Suggerimento: impedire il ribilanciamento

Importante: possibile riavvio della fase 0 di DeepSea

Suggerimento: modifica del layout dell'OSD

2.2 Aggiunta di nuovi ruoli ai nodi #

2.3 Rimozione e reinstallazione dei nodi del cluster #

Suggerimento: rimozione temporanea di un nodo del cluster

Nota: rimozione degli OSD dal cluster

Nota: conservazione delle partizioni create mediante altri metodi

Esempio 2.1: Rimozione di un Salt minion dal cluster #

Esempio 2.2: Migrazione dei nodi #

2.4 Ridistribuzione dei nodi di monitoraggio #

Importante: il numero minimo di nodi di monitoraggio è tre

2.5 Aggiunta di un disco OSD a un nodo #

2.6 Rimozione di un OSD #

2.6.1 Rimozione di più OSD #

2.6.2 Rimozione di tutti gli OSD in un host #

2.6.3 Rimozione forzata degli OSD interrotti #

Suggerimento: montaggi in sospeso

2.6.4 Convalida dei metadati LVM dell'OSD #

2.7 Sostituzione di un disco OSD #

Suggerimento: osd.replace e osd.remove

2.8 Recupero di un nodo OSD reinstallato #

2.9 Spostamento del nodo admin su un nuovo server #

Suggerimento: transizione dei Salt minion

Suggerimento: esecuzione di prova di rsync e collegamenti simbolici

2.10 Installazione automatizzata tramite Salt #

Avviso

2.11 Aggiornamento dei nodi del cluster #

2.11.1 Archivi software #

2.11.2 Gestione provvisoria dell'archivio #

2.11.3 zypper patch o zypper dup #

2.11.4 Riavvi del nodo del cluster #

2.11.5 Tempo di fermo dei servizi Ceph #

2.11.6 Esecuzione dell'aggiornamento #

2.12 Interruzione o riavvio del cluster #

2.13 Regolazione di ceph.conf tramite le impostazioni personalizzate #

Nota: rgw.conf univoco

Importante: esecuzione della fase 3

Suggerimento

2.13.1 Sostituzione delle impostazioni di default #

2.13.2 Inclusione di file di configurazione #

Suggerimento: configurazione di runtime

2.14 Abilitazione dei profili AppArmor #

Suggerimento: abilitazione del servizio AppArmor

2.15 Disattivazione dei profili ottimizzati #

2.16 Rimozione dell'intero cluster Ceph #

Suggerimento: disabilitazione della rimozione del cluster Ceph

Importante: revoca dei ruoli personalizzati

Suggerimento: `osd.replace` e `osd.remove`

Suggerimento: esecuzione di prova di `rsync` e collegamenti simbolici

2.11.3 `zypper patch` o `zypper dup` #

2.13 Regolazione di `ceph.conf` tramite le impostazioni personalizzate #

Nota: `rgw.conf` univoco