ceph.conf
personalizzatoDopo aver distribuito il cluster Ceph, occasionalmente potrà essere necessario apportare 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 4, Installazione con DeepSea/Salt:
Installare SUSE Linux Enterprise Server 12 SP3 sul nuovo nodo, configurarne le impostazioni di rete in modo che il nome host del Salt master venga risolto correttamente e 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
Accettare tutte le chiavi salt sul Salt master:
root@master #
salt-key --accept-all
Verificare che anche la destinazione di /srv/pillar/ceph/deepsea_minions.sls
sia il nuovo Salt minion. Per ulteriori dettagli, fare riferimento a Sezione 4.2.2.1, «Corrispondenza del nome del minion» di Procedura 4.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
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 4.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
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 4.5.1.2, «Assegnazione ruolo» per ulteriori informazioni sui tipi di ruoli supportati ed esempi della rispettiva corrispondenza.
In genere si consiglia di eseguire tutte le fasi di distribuzione comprese tra 0 e 5 quando si aggiunte aggiunge un nuovo ruolo a un nodo cluster. Per risparmiare tempo, è possibile ignorare le fasi 3 o 4, a seconda del tipo di ruolo che si intende distribuire. Mentre i ruoli OSD e MON includono servizi di base e sono richiesti da Ceph, altri ruoli, come Object Gateway, sono opzionali. Le fasi di distribuzione DeepSea sono gerarchiche: mentre nella fase 3 vengono distribuiti servizi di base, nella fase 4 vengono distribuiti quelli opzionali.
Pertanto, è necessario eseguire la fase 3 quando si distribuiscono ruoli di base, come MON su un nodo OSD esistente, ed è possibile ignorare la fase 4.
In modo analogo, è possibile ignorare la fase 3 quando si distribuiscono servizi opzionali come Object Gateway, ma in tal caso è necessario eseguire la fase 4.
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 4.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 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 eseguire quelli opzionali. È anche possibile eseguire entrambe le fasi.
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, si consiglia di aggiungere contemporaneamente tutti gli OSD previsti.
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 in Sezione 4.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.
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à.
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 profile-default/cluster/data*.sls profile-default/stack/default/ceph/minions/data*.yml [...]
Per rimuovere il Salt minion "data2.ceph", modificare le righe come indicato di seguito:
[...] # Hardware Profile profile-default/cluster/data[1,3-6]*.sls profile-default/stack/default/ceph/minions/data[1,3-6]*.yml [...]
Quindi, eseguire le fasi 2 e 5:
root@master #
salt-run state.orch ceph.stage.2root@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 (vedere Procedura 4.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 profile-default/cluster/data[1-7]*.sls profile-default/stack/default/ceph/minions/data[1-7]*.sls # Roles role-rgw/cluster/data8*.sls
Modificarlo in:
# Hardware Profile profile-default/cluster/data[1-8]*.sls profile-default/stack/default/ceph/minions/data[1-8]*.sls # Roles role-rgw/cluster/rgw1*.sls
Eseguire le fasi da 2 a 5. Nella fase 3 verrà aggiunto data8
come nodo di memorizzazione. Per un breve periodo, data8
avrà entrambi i ruoli. Nella fase 4 verrà aggiunto il ruolo Object Gateway a rgw1
e nella fase 5 verrà rimosso il ruolo Object Gateway da data8
.
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 uno o due, è necessario assegnare temporaneamente il ruolo di monitoraggio agli altri nodi 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 1.1, «Aggiunta di nuovi nodi cluster» e Sezione 1.2, «Aggiunta di nuovi ruoli ai nodi».
Per ulteriori informazioni sulla rimozione dei nodi cluster, fare riferimento a Sezione 1.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 4.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.
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 13 in Sezione 4.3, «Distribuzione del cluster». Una volta che il disco è vuoto, aggiungerlo al file YAML del nodo. Il percorso del file è /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions/node_name.yml
. Dopo aver salvato il file, eseguire le fasi 2 e 3 di DeepSea:
root@master #
deepsea
stage run ceph.stage.2root@master #
deepsea
stage run ceph.stage.3
Invece di modificare manualmente il file YAML, DeepSea può creare nuovi profili. Per consentire a DeepSea di creare nuovi profili, è necessario spostare quelli esistenti:
root@master #
old
/srv/pillar/ceph/proposals/profile-default/root@master #
deepsea
stage run ceph.stage.1root@master #
deepsea
stage run ceph.stage.2root@master #
deepsea
stage run ceph.stage.3
È possibile rimuovere un Ceph OSD dal cluster eseguendo il seguente comando:
root@master #
salt-run
disengage.safetyroot@master #
salt-run
remove.osd OSD_ID
OSD_ID deve essere un numero dell'OSD senza il termine osd
. Ad esempio, da osd.3
utilizzare solo la cifra 3
.
Non è possibile in alcun modo rimuovere più OSD contemporaneamente con il comando salt-run remove.osd
. Per automatizzare la rimozione di più OSD, è possibile utilizzare il ciclo seguente (5, 21, 33, 19 sono numeri ID degli OSD da rimuovere):
for i in 5 21 33 19 do echo $i salt-run disengage.safety salt-run remove.osd $i done
In alcuni casi la rimozione di un OSD si conclude con un errore non grave (vedere Sezione 1.6, «Rimozione di un OSD»). Ciò può verificarsi se, ad esempio, l'OSD o la rispettiva cache vengono interrotti, a causa di operazioni I/O in sospeso, o quando è impossibile smontare il disco OSD. In tal caso, è necessario forzare la rimozione dell'OSD:
root@master #
target osd.remove OSD_ID force=True
Con questo comando si rimuovono le partizioni dei dati e le partizioni del journal o WAL/DB.
Per identificare possibili dispositivi journal/WAL/DB orfani, seguire la procedura indicata di seguito:
Selezionare il dispositivo che potrebbe contenere partizioni orfane e salvare l'elenco delle partizioni in un file:
root@minion >
ls /dev/sdd?* > /tmp/partitions
Eseguire readlink
a fronte di tutti i dispositivi block.wal, block.db e journal, quindi confrontare l'output con l'elenco delle partizioni salvato precedentemente:
root@minion >
readlink -f /var/lib/ceph/osd/ceph-*/{block.wal,block.db,journal} \
| sort | comm -23 /tmp/partitions -
L'output è l'elenco delle partizioni che non vengono utilizzate da Ceph.
Rimuovere le partizioni orfane che non appartengono a Ceph con il comando (ad esempio fdisk
, parted
o sgdisk
).
Se il sistema operativo si interrompe ed è impossibile recuperarlo su uno dei nodi OSD nodes, seguire la procedura indicata di seguito per recuperarlo e ridistribuirne il ruolo OSD con dati del cluster invariati:
Reinstallare il sistema operativo sul nodo.
Installare i pacchetti salt-minion sul nodo OSD, eliminare la chiave del Salt minion precedente sul Salt master e registrare la nuova chiave del Salt minion con il Salt master. Per ulteriori informazioni sulla distribuzione del Salt minion, vedere Sezione 4.3, «Distribuzione del cluster».
Eseguire le seguenti parti invece dell'intera fase 0:
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.
È 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 l'ultima riga nel file /etc/salt/master.d/reactor.conf
:
- /srv/salt/ceph/reactor/discovery.sls
come segue
- /srv/salt/ceph/reactor/all_stages.sls
È una buona idea applicare regolarmente aggiornamenti in sequenza ai nodi cluster. Per applicare gli aggiornamenti, eseguire la fase 0:
root@master #
salt-run state.orch ceph.stage.0
Se DeepSea rileva un cluster Ceph in esecuzione, vengono applicati gli aggiornamenti e i nodi vengono avviati in sequenza. DeepSea segue il consiglio ufficiale di Ceph secondo il quale è opportuno aggiornare prima i monitoraggi, successivamente gli OSD e infine i servizi aggiuntivi, come MDS, Object Gateway, iSCSI Gateway o NFS Ganesha. DeepSea interrompe il processo di aggiornamento se rileva un problema nel cluster. Un trigger può essere:
Ceph segnala "HEALTH_ERR" per più di 300 secondi.
Dopo un aggiornamento i Salt minion vengono interrogati per verificare se i servizi loro assegnati sono ancora attivi e in esecuzione. L'aggiornamento ha esito negativo se i servizi sono inattivi per più di 900 secondi.
Queste disposizioni assicurano il funzionamento del cluster Ceph nonostante aggiornamenti corrotti o con errore.
La fase 0 di DeepSea aggiorna il sistema tramite zypper update
e lo riavvia se il kernel viene aggiornato. Se si desidera eliminare l'eventualità di un riavvio forzato di tutti i potenziali nodi, assicurarsi che sia installato e in esecuzione l'ultimo kernel, prima di iniziare la fase 0 di DeepSea.
zypper patch
Se si preferisce aggiornare il sistema utilizzando il comando zypper patch
, modificare /srv/pillar/ceph/stack/global.yml
e aggiungere la riga seguente:
update_method_init: zypper-patch
È possibile modificare il comportamento di avvio di default della fase 0 di DeepSea aggiungendo le righe seguenti a /srv/pillar/ceph/stack/global.yml
:
stage_prep_master: default-update-no-reboot stage_prep_minion: default-update-no-reboot
Con stage_prep_master
si imposta il comportamento della fase 0 del Salt master e con stage_prep_minion
quello di tutti i minion. Tutti i parametri disponibili sono:
Installa gli aggiornamenti e successivamente esegue il riavvio.
Installa gli aggiornamenti senza il riavvio.
Riavvia senza installare gli aggiornamenti.
Non installa gli aggiornamenti né il riavvio.
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:
root #
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:
root #
ceph
osd unset noout
ceph.conf
personalizzato #
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 molta 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 un esempio, vedere /srv/salt/ceph/configuration/files/rgw.conf
.
Dopo aver apportato modifiche personalizzate ai file di configurazione di cui sopra, eseguire la fase 3 per applicarle ai nodi cluster:
root@master #
salt-run state.orch ceph.stage.3
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
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 1.12, «Configurazione Ceph di runtime».
Nella Sezione 1.11, «File ceph.conf
personalizzato» è illustrato come modificare il file di configurazione Ceph ceph.conf
. Il comportamento effettivo del cluster non è tuttavia determinato dallo stato attuale del file ceph.conf
, bensì dalla configurazione dei daemon Ceph in esecuzione, che è memorizzata.
È possibile interrogare un daemon Ceph daemon individuale per una determinata impostazione di configurazione utilizzando il socket amministrativo sul nodo in cui è in esecuzione il daemon. Ad esempio, con il seguente comando si ottiene il valore del parametro di configurazione osd_max_write_size
dal daemon denominato osd.0
:
root #
ceph --admin-daemon /var/run/ceph/ceph-osd.0.asok \
config get osd_max_write_size
{
"osd_max_write_size": "90"
}
È inoltre possibile modificare le impostazioni dei daemon in fase di runtime. Tenere presente che questa modifica è temporanea e al riavvio successivo del daemon andrà persa. Ad esempio, con il seguente comando si modifica il parametro osd_max_write_size
a "50" per tutti gli OSD nel cluster:
root #
ceph tell osd.* injectargs --osd_max_write_size 50
injectargs
non è affidabile
Sfortunatamente, se si modificano le impostazioni del cluster con il comando injectargs
, l'operazione non è affidabile al 100%. Se è necessario avere la certezza che il parametro modificato sia attivo, modificarlo nel file di configurazione e riavviare tutti i daemon nel cluster.