Saltar al contenutoSaltar alla navigazione delle pagine: pagina precedente [chiave d’accesso p]/pagina successiva [chiave d’accesso n]
Si applica a SUSE Enterprise Storage 5

1 Amministrazione di Salt Cluster

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

1.1 Aggiunta di nuovi nodi cluster

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

  1. 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
  2. Accettare tutte le chiavi salt sul Salt master:

    root@master # salt-key --accept-all
  3. 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».

  4. 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
  5. 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
  6. 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».

  7. 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
  8. Le fasi di configurazione e distribuzione includono i nodi aggiunti di recente:

    root@master # salt-run state.orch ceph.stage.3
    root@master # salt-run state.orch ceph.stage.4

1.2 Aggiunta di nuovi ruoli ai nodi

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

  1. 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
  2. Eseguire la fase 2 per aggiornare Pillar:

    root@master # salt-run state.orch ceph.stage.2
  3. Eseguire la fase 3 per distribuire i servizi di base o la fase 4 per eseguire quelli opzionali. È anche possibile eseguire entrambe le fasi.

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

1.3 Rimozione e reinstallazione dei nodi del cluster

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

Esempio 1.1: Rimozione di un Salt minion dal cluster

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.2
root@master # salt-run state.orch ceph.stage.5
Esempio 1.2: Migrazione dei nodi

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.

1.4 Ridistribuzione dei nodi di monitoraggio

Quando uno o più nodi di monitoraggio vengono meno e non rispondono, è necessario rimuoverli dal cluster e possibilmente aggiungerli nuovamente.

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

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

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

  2. Eseguire le fasi da 2 a 5 di DeepSea per applicare le modifiche:

    root@master # deepsea stage run ceph.stage.2
    root@master # deepsea stage run ceph.stage.3
    root@master # deepsea stage run ceph.stage.4
    root@master # deepsea stage run ceph.stage.5

1.5 Aggiunta di un OSD a un nodo

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

1.6 Rimozione di un OSD

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

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

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 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 comportamento specificato.

Avviso
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/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

1.9 Aggiornamento dei nodi cluster

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

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

default

Installa gli aggiornamenti e successivamente esegue il riavvio.

default-update-no-reboot

Installa gli aggiornamenti senza il riavvio.

default-no-update-reboot

Riavvia senza installare gli aggiornamenti.

default-no-update-no-reboot

Non installa gli aggiornamenti né il riavvio.

1.10 Interruzione o riavvio del cluster

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:

  1. Indicare al cluster Ceph di impostare il flag noout:

    root # ceph osd set noout
  2. Interrompere daemon e nodi nel seguente ordine:

    1. Client di memorizzazione

    2. Gateway, ad esempio NFS Ganesha o Object Gateway

    3. Metadata Server

    4. Ceph OSD

    5. Ceph Manager

    6. Ceph Monitor

  3. Se necessario, eseguire task di manutenzione.

  4. Avviare nodi e server in ordine inverso rispetto al processo di spegnimento:

    1. Ceph Monitor

    2. Ceph Manager

    3. Ceph OSD

    4. Metadata Server

    5. Gateway, ad esempio NFS Ganesha o Object Gateway

    6. Client di memorizzazione

  5. Rimuovere il flag noout:

    root # ceph osd unset noout

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

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

1.11.1 Sostituzione delle impostazioni di default

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

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

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

Stampa pagina