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
8 Aggiunta di un OSD a un nodo SES 5
do echo $i
salt-run disengage.safety salt-run remove.osd $i done
1.6.1 Rimozione forzata degli OSD interrotti
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:
1. Selezionare il dispositivo che potrebbe contenere partizioni orfane e salvare l'elenco delle partizioni in un file:
root@minion > ls /dev/sdd?* > /tmp/partitions
2. 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.
3. Rimuovere le partizioni orfane che non appartengono a Ceph con il comando (ad esempio fdisk, parted o sgdisk).
9 Rimozione forzata degli OSD interrotti SES 5
1.7 Recupero di un nodo OSD reinstallato
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:
1. Reinstallare il sistema operativo sul nodo.
2. 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 Libro «Guida alla di-stribuzione», Capitolo 4 «Installazione con DeepSea/Salt», Sezione 4.3 «Distribuzione del cluster». 3. Eseguire le seguenti parti invece dell'intera fase 0:
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
4. 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
5. Eseguire la fase 0 di DeepSea:
root@master # salt-run state.orch ceph.stage.0
6. Riavviare il nodo OSD pertinente. Tutti i dischi OSD verranno rilevati e riutilizzati.
1.8 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 com-portamento specificato.
10 Recupero di un nodo OSD reinstallato SES 5
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/pil-lar/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/ma-ster.d/reactor.conf:
- /srv/salt/ceph/reactor/discovery.sls
come segue
- /srv/salt/ceph/reactor/all_stages.sls
1.9 Aggiornamento dei nodi cluster
È una buona idea applicare regolarmente aggiornamenti in sequenza ai nodi cluster. Per appli-care gli aggiornamenti, eseguire la fase 0:
root@master # salt-run state.orch ceph.stage.0
11 Aggiornamento dei nodi cluster SES 5
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 cor-rotti 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.