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

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

Suggerimento: ruoli e fasi obbligatori e opzionali

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:

Suggerimento

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

Nota: rimozione degli ODS 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.

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

[...]
# Hardware Profile
profile-default/cluster/data*.sls
profile-default/stack/default/ceph/minions/data*.yml
[...]

[...]
# Hardware Profile
profile-default/cluster/data[1,3-6]*.sls
profile-default/stack/default/ceph/minions/data[1,3-6]*.yml
[...]

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

# 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

# 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

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

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.2
root@master # deepsea stage run ceph.stage.3

Suggerimento: profili aggiornati automaticamente

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.1
root@master # deepsea stage run ceph.stage.2
root@master # deepsea stage run ceph.stage.3

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

root@master # salt-run disengage.safety
root@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.

Suggerimento: rimozione di più ODS

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

root@master # target osd.remove OSD_ID force=True

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:

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

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:

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.

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

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:

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:

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

Importante: esecuzione della fase 3

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.

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.

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

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

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