È possibile modificare la configurazione di default del cluster generata nella Fase 2 (consultare Descrizione delle fasi di DeepSea). Ad esempio, può essere necessario modificare le impostazioni di rete o il software installato sul nodo admin di default. È possibile eseguire la prima operazione modificando il Pillar aggiornato dopo la Fase 2, mentre la seconda viene ottenuta creando un file sls
personalizzato e aggiungendolo al Pillar. I dettagli sono descritti nelle sezioni seguenti.
In questa sezione vengono elencati diversi task che richiedono aggiunta/modifica dei propri file sls
. Tale procedura viene utilizzata in genere quando occorre modificare il processo di distribuzione di default.
I file .sls personalizzati appartengono alla stessa sottodirectory dei file .sls di DeepSea. Per evitare di sovrascrivere i file .sls con quelli nuovi aggiunti dal pacchetto DeepSea, apporre un prefisso al nome con la stringa custom-
.
Se si indirizza un task specifico esterno al processo di installazione di DeepSea ed è quindi necessario ignorarlo, creare un file "no-operation" seguendo questo esempio:
Creare /srv/salt/ceph/time/disabled.sls
con il seguente contenuto e salvarlo:
disable time setting: test.nop
Modificare /srv/pillar/ceph/stack/global.yml
, aggiungere la riga seguente e salvarlo:
time_init: disabled
Verificare aggiornando il Pillar ed eseguendo la fase:
root@master #
salt target saltutil.pillar_refreshroot@master #
salt 'admin.ceph' state.apply ceph.time admin.ceph: Name: disable time setting - Function: test.nop - Result: Clean Summary for admin.ceph ------------ Succeeded: 1 Failed: 0 ------------ Total states run: 1
L'ID del task "disable time setting" può essere qualsiasi messaggio univoco in un file sls
. Impedire le collisioni ID specificando descrizioni univoche.
Se occorre sostituire il comportamento di default di una fase specifica con uno personalizzato, creare un file sls
personalizzato con contenuto sostitutivo.
Per default, /srv/salt/ceph/pool/default.sls
crea un'immagine rbd denominata "demo". Nel nostro esempio, non si desidera creare tale immagine, ma sono richieste due immagini: "archive1" e "archive2".
Creare /srv/salt/ceph/pool/custom.sls
con il seguente contenuto e salvarlo:
wait: module.run: - name: wait.out - kwargs: 'status': "HEALTH_ERR"1 - fire_event: True archive1: cmd.run: - name: "rbd -p rbd create archive1 --size=1024"2 - unless: "rbd -p rbd ls | grep -q archive1$" - fire_event: True archive2: cmd.run: - name: "rbd -p rbd create archive2 --size=768" - unless: "rbd -p rbd ls | grep -q archive2$" - fire_event: True
Il modulo wait va in pausa finché il cluster Ceph non ha lo stato | |
Il comando |
Per richiamare il nuovo file personalizzato creato invece di quello di default, occorre modificare /srv/pillar/ceph/stack/ceph/cluster.yml
, aggiungere la riga seguente e salvarlo:
pool_init: custom
Verificare aggiornando il Pillar ed eseguendo la fase:
root@master #
salt target saltutil.pillar_refreshroot@master #
salt 'admin.ceph' state.apply ceph.pool
La creazione di pool o immagini richiede autorizzazioni sufficienti. Il minion admin.ceph
ha un portachiavi admin.
Un'altra opzione è invece modificare la variabile in /srv/pillar/ceph/stack/ceph/roles/master.yml
. Con questo file si riduce l'ingombro dei dati del Pillar per altri minion.
A volte può essere necessaria una fase specifica per eseguire task aggiuntivi. Si sconsiglia di modificare il file di stato correlato, in quanto potrebbe complicare un futuro upgrade. Creare invece un file separato per eseguire i task aggiuntivi identico a quello descritto in Sezione 7.1.2, «Sostituzione di una fase di installazione».
Assegnare al nuovo file sls
un nome descrittivo. Ad esempio, se occorre creare due immagini rbd oltre all'immagine demo, assegnare al file il nome archive.sls
.
Creare /srv/salt/ceph/pool/custom.sls
con il seguente contenuto e salvarlo:
include: - .archive - .default
In questo esempio, Salt crea le immagini archive quindi l'immagine demo. In questo esempio, l'ordine è ininfluente. Per cambiare l'ordine, invertire le righe dopo la direttiva include:
.
È possibile aggiungere la riga include direttamente ad archive.sls
e verranno così create anche tutte le immagini. Tuttavia, a prescindere dalla posizione della riga include, Salt elabora prima le fasi nel file incluso. Sebbene sia possibile ignorare questo comportamento con dichiarazioni requires e order, un file separato comprendente le altre garantisce l'ordine e riduce le possibilità di confusione.
Modificare /srv/pillar/ceph/stack/ceph/cluster.yml
, aggiungere la riga seguente e salvarlo:
pool_init: custom
Verificare aggiornando il Pillar ed eseguendo la fase:
root@master #
salt target saltutil.pillar_refreshroot@master #
salt 'admin.ceph' state.apply ceph.pool
Se occorre aggiungere una fase di installazione completamente separata, creare tre nuovi file, un file sls
che esegue il comando, un file di orchestrazione e un file personalizzato che allinea la nuova fase alle fasi di distribuzione originali.
Ad esempio, se occorre eseguire logrotate
su tutti i minion nell'ambito della fase di preparazione:
Creare prima un file sls
e includere il comando logrotate
.
logrotate
su tutti i Salt minion #
Creare una directory come /srv/salt/ceph/logrotate
.
Creare /srv/salt/ceph/logrotate/init.sls
con il seguente contenuto e salvarlo:
rotate logs: cmd.run: - name: "/usr/sbin/logrotate /etc/logrotate.conf"
Verificare che il comando funzioni su un minion:
root@master #
salt 'admin.ceph' state.apply ceph.logrotate
Poiché il file di orchestrazione deve essere eseguito prima di tutte le fasi di preparazione, aggiungerlo alla fase 0 Prep:
Creare /srv/salt/ceph/stage/prep/logrotate.sls
con il seguente contenuto e salvarlo:
logrotate: salt.state: - tgt: '*' - sls: ceph.logrotate
Verificare che il file di orchestrazione funzioni:
root@master #
salt-run state.orch ceph.stage.prep.logrotate
L'ultimo file è quello personalizzato che comprende la fase aggiuntiva con le fasi originali:
Creare /srv/salt/ceph/stage/prep/custom.sls
con il seguente contenuto e salvarlo:
include: - .logrotate - .master - .minion
Ignorare il comportamento di default. Modificare /srv/pillar/ceph/stack/global.yml
, aggiungere la riga seguente e salvare il file:
stage_prep: custom
Verificare che la Fase 0 sia funzionale:
root@master #
salt-run state.orch ceph.stage.0
global.yml
?
Il file global.yml
viene scelto rispetto a cluster.yml
perché durante la fase prep, nessun minion appartiene al cluster Ceph e non ha accesso ad alcuna impostazione in cluster.yml
.
Durante la fase 0 (fare riferimento al Descrizione delle fasi di DeepSea per ulteriori informazioni sulle fasi di DeepSea) il Salt master e i Salt minion potrebbero riavviarsi perché i pacchetti appena aggiornati, ad esempio kernel, richiedono il riavvio del sistema.
Il comportamento di default consiste nell'installare i nuovi aggiornamenti disponibili senza riavviare i nodi, anche in caso di aggiornamenti del kernel.
È possibile modificare il comportamento di default di aggiornamento/riavvio della fase 0 di DeepSea·aggiungendo/modificando le opzioni stage_prep_master
e stage_prep_minion
nel file·/srv/pillar/ceph/stack/global.yml
. Con _prep_master
si imposta il comportamento della fase del Salt master e con stage_prep_minion
quello di tutti i minion. Tutti i parametri disponibili sono:
Installa gli aggiornamenti senza il riavvio.
Installa gli aggiornamenti e successivamente esegue il riavvio.
Riavvia senza installare gli aggiornamenti.
Non installa gli aggiornamenti né il riavvio.
Ad esempio, per impedire ai nodi del cluster di installare gli aggiornamenti e di effettuare il riavvio, modificare /srv/pillar/ceph/stack/global.yml
e aggiungere le righe seguenti:
stage_prep_master: default-no-update-no-reboot stage_prep_minion: default-no-update-no-reboot
I valori di stage_prep_master
corrispondono ai nomi di file ubicati in /srv/salt/ceph/stage/0/master
, mentre i valori di stage_prep_minion
corrispondono ai file in /srv/salt/ceph/stage/0/minio
:
root@master #
ls -l /srv/salt/ceph/stage/0/master default-no-update-no-reboot.sls default-no-update-reboot.sls default-update-reboot.sls [...]root@master #
ls -l /srv/salt/ceph/stage/0/minion default-no-update-no-reboot.sls default-no-update-reboot.sls default-update-reboot.sls [...]
Dopo aver completato la Fase 2, è possibile modificare la configurazione rilevata. Per visualizzare le impostazioni correnti, eseguire:
root@master #
salt target pillar.items
Il risultato della configurazione di default per un singolo minion è di solito simile a:
---------- available_roles: - admin - mon - storage - mds - igw - rgw - client-cephfs - client-radosgw - client-iscsi - mds-nfs - rgw-nfs - master cluster: ceph cluster_network: 172.16.22.0/24 fsid: e08ec63c-8268-3f04-bcdb-614921e94342 master_minion: admin.ceph mon_host: - 172.16.21.13 - 172.16.21.11 - 172.16.21.12 mon_initial_members: - mon3 - mon1 - mon2 public_address: 172.16.21.11 public_network: 172.16.21.0/24 roles: - admin - mon - mds time_server: admin.ceph time_service: ntp
Le impostazioni menzionate sopra sono distribuite tra più file di configurazione. La struttura di directory con questi file è definita nella directory /srv/pillar/ceph/stack/stack.cfg
. I file seguenti di solito descrivono il cluster:
/srv/pillar/ceph/stack/global.yml
- il file influisce su tutti i minion nel cluster Salt.
/srv/pillar/ceph/stack/ceph/cluster.yml
- il file influisce su tutti i minion nel cluster Ceph denominato ceph
.
/srv/pillar/ceph/stack/ceph/roles/role.yml
- influisce su tutti i minion assegnati al ruolo specifico nel cluster ceph
.
/srv/pillar/ceph/stack/ceph/minions/MINION_ID/yml
- interessa il singolo minion.
Esiste una struttura di directory parallela che memorizza l'impostazione della configurazione di default in /srv/pillar/ceph/stack/default
. Non modificare qui questi valori, in quanto vengono sovrascritti.
La procedura tipica per modificare la configurazione raccolta è la seguente:
Individuare l'ubicazione della voce di configurazione che occorre modificare. Ad esempio, se occorre modificare un'impostazione relativa al cluster come la rete cluster, modificare il file /srv/pillar/ceph/stack/ceph/cluster.yml
.
Salvare il file.
Verificare le modifiche eseguendo:
root@master #
salt target saltutil.pillar_refresh
quindi
root@master #
salt target pillar.items
Poiché l'indirizzamento di rete IPv4 è il modello più diffuso, è necessario abilitare l'indirizzamento IPv6 come impostazione personalizzata. In DeepSea non sono presenti funzionalità di rilevazione automatica dell'indirizzamento IPv6.
Per configurare IPv6, impostare le variabili public_network
e cluster_network
nel file /srv/pillar/ceph/stack/global.yml
su sottoreti IPv6 valide. Ad esempio:
public_network: fd00:10::/64 cluster_network: fd00:11::/64
Quindi, eseguire la fase 2 di DeepSea e verificare che le informazioni di rete corrispondano all'impostazione. La fase 3 genererà il file ceph.conf
con i flag richiesti.
Ceph non supporta il protocollo dual stack e quindi non è possibile eseguirlo in contemporanea su IPv4 e IPv6. Il processo di convalida di DeepSea rifiuterà la discordanza tra public_network
e cluster_network
o all'interno di una di queste variabili. Nell'esempio seguente è riportato un errore di convalida.
public_network: "192.168.10.0/24 fd00:10::/64"
fe80::/10 link-local
Evitare di utilizzare gli indirizzi fe80::/10 link-local
. Tutte le interfacce di rete dispongono di un indirizzo fe80
e richiedono un qualificatore di interfaccia per effettuare l'instradamento corretto. Assegnare gli indirizzi IPv6 allocati al proprio sito o prendere in considerazione di utilizzare fd00::/8
. Questi elementi sono parte di ULA e non sono instradabili a livello globale.