cephx
ceph.conf
tramite le impostazioni personalizzateDopo 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.
La procedura per aggiungere nuovi nodi al cluster è pressoché identica alla distribuzione dei nodi cluster iniziale descritta in Capitolo 5, Installazione con DeepSea/Salt:
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
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
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.3root@master #
salt-run state.orch ceph.stage.4
È 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.
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».
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.
È 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.
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.2root@master #
salt-run rescinded.idsroot@master #
salt-run state.orch ceph.stage.5
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.2root@master #
salt-run state.orch ceph.stage.3root@master #
salt-run state.orch ceph.stage.4root@master #
salt-run rescinded.idsroot@master #
salt-run state.orch ceph.stage.5
Quando uno o più nodi di monitoraggio vengono meno e non rispondono, è necessario rimuoverli dal cluster e possibilmente aggiungerli nuovamente.
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.2root@master #
deepsea
stage run ceph.stage.3root@master #
deepsea
stage run ceph.stage.4root@master #
deepsea
stage run ceph.stage.5
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
È 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
.
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
Per rimuovere tutti gli OSD in un host specifico, eseguire il comando seguente:
root@master #
salt-run osd.remove OSD_HOST_NAME
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
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
.
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.2root@master #
salt-run state.orch ceph.stage.3
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
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
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.syncroot@master #
salt 'osd_node' state.apply ceph.packages.commonroot@master #
salt 'osd_node' state.apply ceph.minesroot@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.1root@master #
salt-run state.orch ceph.stage.2root@master #
salt-run state.orch ceph.stage.3root@master #
salt-run state.orch ceph.stage.4root@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
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.serviceroot@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».
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.pubroot@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.
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».
È 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.
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.
Mantenere i nodi del cluster Ceph aggiornati applicando regolarmente gli aggiornamenti in sequenza.
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».
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.
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
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».
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.
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
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:
Client di memorizzazione
Gateway, ad esempio NFS Ganesha o Object Gateway
Metadata Server
Ceph OSD
Ceph Manager
Ceph Monitor
Se necessario, eseguire task di manutenzione.
Avviare nodi e server in ordine inverso rispetto al processo di spegnimento:
Ceph Monitor
Ceph Manager
Ceph OSD
Metadata Server
Gateway, ad esempio NFS Ganesha o Object Gateway
Client di memorizzazione
Rimuovere il flag noout:
cephadm@adm >
ceph
osd unset noout
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
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
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.3root@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.
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.
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
.
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.
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».
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
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.
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
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.safetyroot@master #
salt-run state.orch ceph.purge
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
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/rescindroot@master #
rsync -a rgw/ us-east-1root@master #
sed -i 's!rgw!us-east-1!' us-east-1/*.sls