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

4 Installazione con DeepSea/Salt

Nota
Nota: ceph-deploy rimosso in SUSE Enterprise Storage 5

Lo strumento di installazione cluster ceph-deploy è obsoleto in SUSE Enterprise Storage 4 ed è stato completamente rimosso a favore di DeepSea da SUSE Enterprise Storage 5.

Salt insieme con DeepSea è uno stack di componenti che consentono di installare e gestire l'infrastruttura del server, risultando scalabile, veloce e relativamente semplice da eseguire. Prima di avviare l'installazione del cluster con Salt, leggere le seguenti considerazioni:

  • I Salt minion sono i nodi controllati da un nodo dedicato denominato Salt master. I Salt minion hanno ruoli, ad esempio Ceph OSD, Ceph Monitor, Ceph Manager, Object Gateway, iSCSI Gateway o NFS Ganesha.

  • Un Salt master esegue il proprio Salt minion, richiesto per eseguire task privilegiati, ad esempio creazione, autorizzazione e copia di chiavi sui minion, in modo che i minion remoti non debbano mai eseguire task privilegiati.

    Suggerimento
    Suggerimento: condivisione di più ruoli per server

    È possibile ottenere le prestazioni migliori dal cluster Ceph quando ogni ruolo viene distribuito su un nodo separato. Le installazioni reali, tuttavia, a volte richiedono la condivisione di un nodo per più ruoli. Per evitare problemi di prestazioni e della procedura di upgrade, non distribuire il ruolo Ceph OSD, Metadata Server o Ceph Monitor sul Salt master.

  • I Salt minion devono risolvere correttamente il nome host del Salt master in rete. Per impostazione predefinita, viene cercato il nome host salt, ma è possibile specificare altri nomi host individuabili in rete nel file /etc/salt/minion, vedere Sezione 4.3, «Distribuzione del cluster».

4.1 Lettura delle note di rilascio

Nelle note di rilascio è possibile trovare informazioni aggiuntive sulle modifiche apportate rispetto alla release precedente di SUSE Enterprise Storage. Controllare le note di rilascio per vedere se:

  • l'hardware necessita di considerazioni speciali;

  • i pacchetti software utilizzati hanno subito modifiche significative;

  • è necessario adottare precauzioni speciali per l'installazione.

Le note di rilascio forniscono inoltre informazioni che non si è fatto in tempo a riportare nel manuale. Contengono anche alcune note su problemi noti.

Dopo aver installato il pacchetto release-notes-ses, individuare localmente le note di rilascio nella directory /usr/share/doc/release-notes o online all'indirizzo https://www.suse.com/releasenotes/.

4.2 Introduzione a DeepSea

DeepSea consente di far risparmiare tempo all'amministratore ed eseguire in sicurezza operazioni complesse su un cluster Ceph.

Ceph è una soluzione software altamente configurabile che aumenta la libertà e la responsabilità degli amministratori di sistema.

La configurazione minima di Ceph è ottima per scopi dimostrativi, ma non mostra le funzionalità interessanti di Ceph visibili con un alto numero di nodi.

DeepSea raccoglie e memorizza i dati sui singoli server, ad esempio indirizzi e nomi dei dispositivi. Per un sistema di storage distribuito come Ceph, possono esistere centinaia di tali voci da raccogliere e memorizzare. La raccolta delle informazioni e l'immissione manuale dei dati in uno strumento di gestione della configurazione è un'operazione complessa in cui è facile fare degli errori.

I passaggi necessari per preparare i server, raccogliere la configurazione, configurare e distribuire Ceph sono quasi uguali. Tuttavia, ciò non riguarda la gestione di funzioni separate. Per le operazioni giornaliere, è richiesta la capacità di aggiungere hardware a una data funzione e rimuoverlo senza problemi.

DeepSea gestisce queste osservazioni con la seguente strategia: DeepSea consolida le decisioni dell'amministratore in un singolo file. Le decisioni comprendono assegnazione del cluster, assegnazione del ruolo e assegnazione del profilo, mentre DeepSea raccoglie ciascun insieme di task in un semplice obiettivo. Ogni obiettivo è una fase:

Descrizione delle fasi di DeepSea
  • Fase 0, la preparazione, durante questa fase, vengono applicati tutti gli aggiornamenti richiesti e il sistema potrebbe riavviarsi.

    Importante
    Importante: ripetere la Fase 0 dopo il riavvio del Salt master

    Se, durante la Fase 0, il Salt master si riavvia per caricare la nuova versione del kernel, occorre eseguire di nuovo la Fase 0, in caso contrario i minion non vengono indirizzati.

  • Fase 1, il rilevamento, qui viene rilevato tutto l'hardware nel cluster e vengono raccolte le informazioni necessarie per la configurazione di Ceph. Per informazioni sulla configurazione, consultare Sezione 4.5, «Configurazione e personalizzazione».

  • Fase 2, la configurazione, è necessario preparare i dati di configurazione in un formato particolare.

  • Fase 3, l'installazione, crea un cluster Ceph di base con i servizi Ceph obbligatori. Per l'elenco, vedere Sezione 1.2.3, «Daemon e nodi Ceph».

  • Fase 4, i servizi, in questa fase è possibile installare funzionalità aggiuntive di Ceph come iSCSI, Object Gateway e CephFS. Sono tutte opzionali.

  • Fase 5, la fase di rimozione. Questa fase non è obbligatoria e durante la configurazione iniziale non è in genere necessaria. In questa fase vengono rimossi i ruoli dei minion e anche la configurazione del cluster. È necessario eseguire questa fase quando occorre rimuovere un nodo di storage dal cluster. Per ulteriori informazioni, vedere la Sezione 1.3, «Rimozione e reinstallazione dei nodi del cluster».

Un'introduzione più dettagliata a DeepSea è disponibile all'indirizzo https://github.com/suse/deepsea/wiki.

4.2.1 Organizzazione e ubicazioni importanti

Salt dispone di diverse ubicazioni standard e diverse convenzioni di assegnazione del nome utilizzate sul nodo master:

/srv/pillar

La directory memorizza i dati di configurazione per i minion del cluster. Pillar è un'interfaccia che fornisce valori di configurazione globali a tutti i minion del cluster.

/srv/salt/

La directory memorizza i file di stato di Salt (denominati anche file sls). I file di stato sono descrizioni formattate di stati in cui deve trovarsi il cluster. Per ulteriori informazioni, consultare la documentazione Salt.

/srv/module/runners

La directory memorizza script Python noti come runner. I runner vengono eseguiti sul nodo master.

/srv/salt/_modules

La directory memorizza gli script Python denominati moduli. I moduli vengono applicati a tutti i minion nel cluster.

/srv/pillar/ceph

La directory è utilizzata da DeepSea. I dati della configurazione raccolti vengono memorizzati qui.

/srv/salt/ceph

Una directory utilizzata da DeepSea. Memorizza i file sls che possono essere in formati diversi, ma ogni sottodirectory contiene file sls. Ciascuna sottodirectory contiene solo un tipo di file sls. Ad esempio, /srv/salt/ceph/stage contiene i file di orchestrazione eseguiti da salt-run state.orchestrate.

4.2.2 Indirizzamento dei minion

I comandi DeepSea vengono eseguiti tramite l'infrastruttura Salt. Quando si utilizza il comando salt, occorre specificare un insieme di Salt minion interessati dal comando. L'insieme dei minion viene descritto come destinazione per il comando salt. Le sezioni seguenti descrivono i possibili metodi di individuare i minion.

4.2.2.1 Corrispondenza del nome del minion

È possibile individuare un minion o un gruppo di minion tramite corrispondenza dei nomi. Il nome di un minion è in genere il nome host breve del nodo in cui viene eseguito il minion. Questo è in genere un metodo di indirizzamento Salt, non correlato a DeepSea. Per limitare il campo dei nomi di minion, è possibile utilizzare caratteri jolly, espressioni regolari o elenchi. Segue la sintassi generica:

root@master # salt target example.module
Suggerimento
Suggerimento: cluster solo Ceph

Se tutti i Salt minion nell'ambiente appartengono al cluster Ceph, è possibile sostituire in sicurezza target con "*" per includere tutti i minion registrati.

Far corrispondere tutti i minion nel dominio example.net (supponendo che i nomi dei minion siano identici ai loro nomi host "completi"):

root@master # salt '*.example.net' test.ping

Far corrispondere i minion da "web1" a "web5":

root@master # salt 'web[1-5]' test.ping

Far corrispondere i minion "web1-prod" e "web1-devel" utilizzando un'espressione regolare:

root@master # salt -E 'web1-(prod|devel)' test.ping

Far corrispondere un semplice elenco di minion:

root@master # salt -L 'web1,web2,web3' test.ping

Far corrispondere tutti i minion nel cluster:

root@master # salt '*' test.ping

4.2.2.2 Indirizzamento con un Grain "deepsea"

In un ambiente eterogeneo gestito da Salt dove SUSE Enterprise Storage è distribuito su un sotto insieme di nodi con altre soluzioni cluster, è opportuno "contrassegnare" i minion pertinenti applicandovi un grain "deepsea". In questo modo è possibile indirizzare con facilità i minion DeepSea negli ambienti dove è problematica la corrispondenza del nome.

Per applicare il grain "deepsea" a un gruppo di minion, eseguire:

root@master # salt target grains.append deepsea default

Per rimuovere il grain "deepsea" da un gruppo di minion, eseguire:

root@master # salt target grains.delval deepsea destructive=True

Dopo aver applicato il grain "deepsea" ai minion pertinenti, è possibile individuarli come segue:

root@master # salt -G 'deepsea:*' test.ping

Il comando seguente è un equivalente:

root@master # salt -C 'G@deepsea:*' test.ping

4.2.2.3 Impostare l'opzione deepsea_minions

L'impostazione della destinazione dell'opzione deepsea_minions è un requisito per le distribuzioni di DeepSea. DeepSea la utilizza per istruire i minion durante l'esecuzione delle fasi (per informazioni, consultare Descrizione delle fasi di DeepSea.

Per impostare o modificare l'opzione deepsea_minions, modificare il file /srv/pillar/ceph/deepsea_minions.sls sul Salt master e aggiungere o sostituire la riga seguente:

deepsea_minions: target
Suggerimento
Suggerimento: destinazione deepsea_minions

Come target per l'opzione deepsea_minions, è possibile utilizzare uno dei metodi di indirizzamento: Corrispondenza del nome del minion e Indirizzamento con un Grain "deepsea".

Far corrispondere tutti i minion Salt nel cluster:

deepsea_minions: '*'

Far corrispondere tutti i minion con il grain "deepsea":

deepsea_minions: 'G@deepsea:*'

4.2.2.4 Ulteriori informazioni

È possibile utilizzare metodi più avanzati per l'indirizzamento dei minion mediante l'infrastruttura Salt. Per una descrizione di tutte le tecniche di indirizzamento, consultare https://docs.saltstack.com/en/latest/topics/targeting/.

Inoltre, la pagina del manuale "deepsea-minions" fornisce ulteriori dettagli sull'indirizzamento di DeepSea (man 7 deepsea_minions).

4.3 Distribuzione del cluster

Il processo di distribuzione del cluster comprende fasi diverse. Primo, occorre preparare tutti i nodi del cluster configurando Salt, quindi distribuire e configurare Ceph.

Suggerimento
Suggerimento: distribuzione dei nodi monitor senza definire profili OSD

Se occorre ignorare la definizione dei profili OSD e distribuire prima i nodi monitor, è possibile farlo impostando la variabile DEV_ENV, che consente di distribuire i monitor senza la presenza della directory profile/, oltre a distribuire un cluster con almeno un nodo storage, monitor e manager.

Per impostare la variabile ambientale, abilitarla globalmente nel file /srv/pillar/ceph/stack/global.yml, oppure impostarla solo per la sessione di shell corrente:

root@master # export DEV_ENV=true

La procedura seguente descrive la preparazione del cluster in modo dettagliato.

  1. Installare e registrare SUSE Linux Enterprise Server 12 SP3 insieme con SUSE Enterprise Storage extension su ciascun nodo del cluster.

  2. Verificare che i prodotti corretti siano installati e registrati elencando i repository software esistenti. L'elenco sarà simile a questo:

     root@minion > zypper lr -E
    #  | Alias   | Name                              | Enabled | GPG Check | Refresh
    ---+---------+-----------------------------------+---------+-----------+--------
     4 | [...]   | SUSE-Enterprise-Storage-5-Pool    | Yes     | (r ) Yes  | No
     6 | [...]   | SUSE-Enterprise-Storage-5-Updates | Yes     | (r ) Yes  | Yes
     9 | [...]   | SLES12-SP3-Pool                   | Yes     | (r ) Yes  | No
    11 | [...]   | SLES12-SP3-Updates                | Yes     | (r ) Yes  | Yes
  3. Configurare le impostazioni di rete compresa la risoluzione del nome DNS corretto su ogni nodo. Il Salt master e tutti i Salt minion devono risolvere ciascuno mediante i loro nomi host. Per ulteriori informazioni sulla configurazione di una rete, vedere https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_basicnet_yast.html. Per ulteriori informazioni sulla configurazione di un server DNS, vedere https://www.suse.com/documentation/sles-12/book_sle_admin/data/cha_dns.html.

  4. Configurare, attivare e avviare il server di sincronizzazione dell'ora NTP:

    root@master # systemctl enable ntpd.service
    root@master # systemctl start ntpd.service

    Ulteriori informazioni sulla configurazione di NTP sono disponibili in https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_netz_xntp_yast.html.

  5. Verificare che il servizio AppArmor sia in esecuzione e disattivarlo su ciascun nodo cluster. Avviare il modulo YaST AppArmor e selezionare Settings (Impostazioni) quindi deselezionare la casella di controllo Enable Apparmor (Abilita Apparmor). Confermare con Done (Fine).

    Tenere presente che SUSE Enterprise Storage non funziona con AppArmor attivato.

  6. Installare i pacchetti salt-master e salt-minion sul nodo Salt master:

    root@master # zypper in salt-master salt-minion

    Verificare che il servizio salt-master sia abilitato e avviato, se necessario abilitarlo e avviarlo:

    root@master # systemctl enable salt-master.service
    root@master # systemctl start salt-master.service
  7. Se si intende utilizzare il firewall, verificare che il nodo master abbia le porte 4505 e 4506 aperte per tutti i nodi Salt minion. Se le porte sono chiuse, è possibile aprirle con il comando yast2 firewall consentendo il servizio SaltStack.

    Avviso
    Avviso: le fasi di DeepSea non riescono con il firewall

    Le fasi di installazione di DeepSea non riescono se il firewall è attivo (e anche configurato). Per eseguire le fasi correttamente, occorre disattivare il firewall eseguendo

    root@master # systemctl stop SuSEfirewall2.service

    oppure impostare l'opzione FAIL_ON_WARNING su "False" in /srv/pillar/ceph/stack/global.yml:

    FAIL_ON_WARNING: False
  8. Installare il pacchetto salt-minion su tutti i nodi minion.

    root@minion > zypper in salt-minion

    Accertare che il nome di dominio qualificato completo di ciascun nodo possa essere risolto sull'indirizzo IP della rete pubblica da tutti gli altri nodi.

  9. Configurare tutti i minion (compreso il minion master) per il collegamento al master. Se il Salt master non è raggiungibile dal nome host salt, modificare il file /etc/salt/minion oppure creare un nuovo file /etc/salt/minion.d/master.conf con il seguente contenuto:

    master: host_name_of_salt_master

    Se sono state apportate modifiche ai file di configurazione menzionati sopra, riavviare il servizio Salt su tutti i Salt minion:

    root@minion > systemctl restart salt-minion.service
  10. Verificare che il servizio salt-minion sia abilitato e avviato su tutti i nodi. Abilitarlo e avviarlo se necessario:

    root@minion > systemctl enable salt-minion.service
    root@minion > systemctl start salt-minion.service
  11. Verificare ogni impronta del Salt minion e accettare tutte le chiavi salt sul Salt master se le impronte corrispondono.

    Visualizzare l'impronta di ogni minion:

    root@minion > salt-call --local key.finger
    local:
    3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

    Dopo aver raccolto le impronte di tutti i Salt minion, elencare le impronte di tutte le chiavi minion non accettate sul Salt master:

    root@master # salt-key -F
    [...]
    Unaccepted Keys:
    minion1:
    3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

    Se le impronte dei minion corrispondono, accettarle:

    root@master # salt-key --accept-all
  12. Verificare che le chiavi siano state accettate:

    root@master # salt-key --list-all
  13. Prima di distribuire SUSE Enterprise Storage, accertare che tutti i dischi utilizzati come OSD dai cluster precedenti siano vuoti senza partizioni. Per accertarlo, occorre cancellare manualmente tutti i dischi. Ricordare di sostituire "X" con la lettera corretta del disco:

    1. Interrompere tutti i processi che utilizzano il disco specifico.

    2. Verificare se eventuali partizioni sul disco sono montate e smontare se necessario.

    3. Se il disco è gestito da LVM, disattivare ed eliminare l'intera infrastruttura LVM. Per ulteriori dettagli, fare riferimento a https://www.suse.com/documentation/sles-12/stor_admin/data/cha_lvm.html.

    4. Se il disco fa parte di MD RAID, disattivare RAID. Per ulteriori dettagli, fare riferimento a https://www.suse.com/documentation/sles-12/stor_admin/data/part_software_raid.html.

    5. Suggerimento
      Suggerimento: riavvio del server

      Se si ricevono messaggi di errore come "partition in use" o "kernel can not be updated with the new partition table" nelle fasi seguenti, riavviare il server.

      Cancellare l'inizio di ogni partizione:

      for partition in /dev/sdX[0-9]*
      do
        dd if=/dev/zero of=$partition bs=4096 count=1 oflag=direct
      done
    6. Cancellare la tabella di partizione:

      sgdisk -Z --clear -g /dev/sdX
    7. Cancellare le tabelle di partizione di backup:

      size=`blockdev --getsz /dev/sdX`
      position=$((size/4096 - 33))
      dd if=/dev/zero of=/dev/sdX bs=4M count=33 seek=$position oflag=direct
  14. Installare DeepSea sul nodo Salt master:

    root@master # zypper in deepsea
  15. Verificare che il file /srv/pillar/ceph/master_minion.sls sul Salt master punti al Salt master. Se il Salt master è raggiungibile tramite più nomi host, utilizzare quello idoneo per il cluster di storage. Se è stato utilizzato il nome host predefinito per il Salt master, salt, nel dominio ses, l'aspetto del file è:

    master_minion: salt.ses

Ora è possibile distribuire e configurare Ceph. Se non specificato diversamente, tutti i passaggi sono obbligatori.

Nota
Nota: convenzioni del comando Salt

È possibile eseguire salt-run state.orch in due modi, uno è con stage.<numero fase>, l'altro con il nome della fase. Entrambe le annotazioni hanno lo stesso impatto e la scelta del comando da utilizzare dipende dall'utente.

Procedura 4.1: Esecuzione delle fasi di distribuzione
  1. Includere i Salt minion appartenenti al cluster Ceph in corso di installazione. Per ulteriori informazioni sull'indirizzamento dei minion, consultare Sezione 4.2.2.1, «Corrispondenza del nome del minion».

  2. Preparare il cluster. Per ulteriori dettagli, fare riferimento a Descrizione delle fasi di DeepSea.

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

    oppure

    root@master # salt-run state.orch ceph.stage.prep
    Nota
    Nota: eseguire o monitorare le fasi con DeepSea CLI

    Con DeepSea CLI, è possibile seguire l'avanzamento dell'esecuzione delle fasi in tempo reale, eseguendo DeepSea CLI nella modalità di monitoraggio o eseguendo la fase direttamente tramite DeepSea CLI. Per ulteriori informazioni, vedere la Sezione 4.4, «DeepSea CLI».

  3. Facoltativo: creare sotto volumi Btrfs per /var/lib/ceph/. Questa fase deve essere eseguita solo prima di eseguire le fasi successive di DeepSea. Per la migrazione delle directory esistenti o per ulteriori informazioni, vedere Sezione 18.5, «Sottovolume Btrfs per /var/lib/ceph».

    root@master # salt-run state.orch ceph.migrate.subvolume
  4. La fase di rilevamento raccoglie i dati da tutti i minion e crea frammenti di configurazione memorizzati nella directory /srv/pillar/ceph/proposals. I dati sono memorizzati nel formato YAML nei file *.sls o *.yml.

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

    oppure

    root@master # salt-run state.orch ceph.stage.discovery
  5. Dopo il corretto completamento di un comando, creare un file policy.cfg in /srv/pillar/ceph/proposals. Per ulteriori informazioni, vedere la Sezione 4.5.1, «Il file policy.cfg».

    Suggerimento
    Suggerimento

    Se occorre modificare l'impostazione di rete del cluster, modificare /srv/pillar/ceph/stack/ceph/cluster.yml e modificare le righe che iniziano con cluster_network: e public_network:.

  6. La fase di configurazione analizza il file policy.cfg e unisce i file inclusi nella forma finale. Il contenuto relativo a cluster e ruolo viene posto in /srv/pillar/ceph/cluster, mentre il contenuto specifico di Ceph in /srv/pillar/ceph/stack/default.

    Per attivare la fase di configurazione, eseguire il comando seguente:

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

    oppure

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

    La fase di configurazione può richiedere diversi secondi. Al completamento del comando, è possibile visualizzare i dati di Pillar per i minion specificati (ad esempio, denominati ceph_minion1, ceph_minion2, ecc.) eseguendo:

    root@master # salt 'ceph_minion*' pillar.items
    Nota
    Nota: sovrascrittura dei default

    Non appena il comando viene completato, è possibile visualizzare la configurazione di default e modificarla in base alle esigenze. Per ulteriori informazioni, vedere la Capitolo 7, Personalizzazione della configurazione di default.

  7. Ora è possibile eseguire la fase di installazione. In questa fase, il Pillar viene convalidato e i monitor e daemon ODS vengono avviati sui nodi di storage. Per avviare la fase, eseguire il comando di seguito:

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

    oppure

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

    Il comando può richiedere alcuni minuti. In caso di errore, risolvere il problema ed eseguire di nuovo le fasi precedenti. Al corretto completamento del comando, eseguire questo comando per verificare lo stato:

    root@master # ceph -s
  8. L'ultima fase dell'installazione del cluster Ceph è quella dei servizi. Qui è possibile istanziare uno dei servizi correntemente supportati: iSCSI Gateway, CephFS, Object Gateway, openATTIC e NFS Ganesha. In questa fase, vengono creati i pool necessari, i portachiavi di autorizzazione e i servizi di avvio. Per avviare la fase, eseguire il comando:

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

    oppure

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

    In base alla configurazione, l'esecuzione del comando può richiedere vari minuti.

4.4 DeepSea CLI

DeepSea fornisce inoltre uno strumento CLI che consente all'utente di monitorare o eseguire le fasi mentre visualizza l'avanzamento dell'esecuzione in tempo reale.

Per visualizzare l'avanzamento dell'esecuzione di una fase sono supportate due modalità:

Modalità DeepSea CLI
  • Modalità di monitoraggio: visualizza l'avanzamento dell'esecuzione di una fase di DeepSea attivata dal comando salt-run emesso in un'altra sessione del terminale.

  • Modalità stand-alone: esegue una fase di DeepSea fornendo la visualizzazione in tempo reale delle relative fasi componenti durante l'esecuzione.

Importante
Importante: comandi DeepSea CLI

I comandi DeepSea CLI possono essere eseguiti solo nel nodo Salt master, con privilegi di root.

4.4.1 DeepSea CLI: nodo monitor

Il monitor di avanzamento fornisce una visualizzazione dettagliata in tempo reale di quanto si verifica durante l'esecuzione delle fasi mediante i comandi salt-run state.orch in altre sessioni del terminale.

Prima di eseguire i comandi salt-run state.orch occorre avviare il monitor, in modo che quest'ultimo possa rilevare l'avvio dell'esecuzione della fase.

Se si avvia il monitor dopo aver eseguito il comando salt-run state.orch, non viene mostrato alcun avanzamento dell'esecuzione.

È possibile avviare la modalità monitor utilizzando il comando che segue:

root@master # deepsea monitor

Per ulteriori informazioni sulle opzioni della riga di comando disponibili del comando deepsea monitor consultare la pagina del manuale relativa:

root@master # man deepsea-monitor

4.4.2 DeepSea CLI: modalità stand-alone

Nella modalità stand-alone, è possibile utilizzare DeepSea CLI per eseguire una fase DeepSea, mostrandone l'esecuzione in tempo reale.

Il comando per eseguire una fase DeepSea da DeepSea CLI ha la forma seguente:

root@master # deepsea stage run stage-name

dove stage-name corrisponde al modo in cui viene fatto riferimento ai file di stato di orchestrazione Salt. Ad esempio, alla fase distribuzione, che corrisponde alla directory ubicata in /srv/salt/ceph/stage/deploy, si fa riferimento come ceph.stage.deploy.

Questo comando è un'alternativa ai comandi basati su Salt per eseguire le fasi DeepSea (o qualunque file di stato di orchestrazione DeepSea).

Il comando deepsea stage run ceph.stage.0 è equivalente a salt-run state.orch ceph.stage.0.

Per ulteriori informazioni sulle opzioni della riga di comando disponibili del comando deepsea stage run consultare la pagina del manuale relativa:

root@master # man deepsea-stage run

La figura seguente mostra un esempio del risultato di DeepSea CLI quando si esegue la Fase 2:

Risultato avanzamento esecuzione fase DeepSea CLI
Figura 4.1: Risultato avanzamento esecuzione fase DeepSea CLI

4.4.2.1 Alias stage run DeepSea CLI

Per gli utenti avanzati di Salt, è inoltre supportato un alias per eseguire una fase di DeepSea che utilizza il comando Salt per eseguire una fase, ad esempio, salt-run state.orch stage-name, come comando di DeepSea CLI.

Esempio:

root@master # deepsea salt-run state.orch stage-name

4.5 Configurazione e personalizzazione

4.5.1 Il file policy.cfg

Il file di configurazione /srv/pillar/ceph/proposals/policy.cfg consente di determinare i ruoli dei singoli nodi del cluster. Ad esempio, quale nodo funge da OSD o quale ha un nodo monitor. Modificare policy.cfg per riflettere la configurazione del cluster desiderata. L'ordine delle sezioni è arbitrario, ma il contenuto delle righe incluse sovrascrive le chiavi corrispondenti dal contenuto delle righe precedenti.

Suggerimento
Suggerimento: esempi di policy.cfg

È possibile trovare diversi esempi dei file di policy completi nella directory /usr/share/doc/packages/deepsea/examples/.

4.5.1.1 Assegnazione cluster

Nella sezione cluster è possibile selezionare i minion per il cluster. È possibile selezionare tutti i minion, oppure inserire i minion in blacklist o whitelist. Di seguito vengono forniti esempi per un cluster denominato ceph.

Per includere tutti i minion, aggiungere le righe seguenti:

cluster-ceph/cluster/*.sls

Per inserire nella whitelist un minion particolare:

cluster-ceph/cluster/abc.domain.sls

oppure un gruppo di minion, è possibile utilizzare la corrispondenza con caratteri jolly della shell:

cluster-ceph/cluster/mon*.sls

Per inserire nella blacklist i minion, impostarli su unassigned:

cluster-unassigned/cluster/client*.sls

4.5.1.2 Assegnazione ruolo

Questa sezione fornisce i dettagli per l'assegnazione dei "ruoli" ai nodi cluster. Un "ruolo" in questo contesto significa il servizio che occorre eseguire sul nodo, come Ceph Monitor, Object Gateway, iSCSI Gateway o openATTIC. Nessun ruolo viene assegnato automaticamente, vengono distribuiti solo i ruoli aggiunti a policy.cfg.

L'assegnazione segue questo schema:

role-ROLE_NAME/PATH/FILES_TO_INCLUDE

Dove le voci hanno i seguenti significati e valori:

  • ROLE_NAME è uno dei seguenti: "master", "admin", "mon", "mgr", "mds", "igw", "rgw", "ganesha" o "openattic".

  • PATH è un percorso di directory relativo ai file .sls o .yml. Nel caso dei file .sls, in genere è cluster, mentre i file .yml si trovano in stack/default/ceph/minions.

  • FILES_TO_INCLUDE sono i file di stato Salt o i file di configurazione YAML che consistono normalmente di nomi host dei Salt minion, ad esempio ses5min2.yml. Per una corrispondenza più specifica è possibile utilizzare la corrispondenza con caratteri jolly della shell.

Segue un esempio per ogni ruolo:

  • master - il nodo ha portachiavi admin su tutti i cluster Ceph. Attualmente, è supportato solo un singolo cluster Ceph. Poiché il ruolo master è obbligatorio, aggiungere sempre una riga simile a:

    role-master/cluster/master*.sls
  • admin - il minion ha un portachiavi admin. Definire il ruolo nel modo seguente:

    role-admin/cluster/abc*.sls
  • mon - il minion fornisce il servizio di monitoraggio al cluster Ceph. Questo ruolo richiede gli indirizzi dei minion assegnati. Fino a SUSE Enterprise Storage 5, gli indirizzi pubblici vengono calcolati dinamicamente e non sono più necessari nel Pillar Salt.

    role-mon/cluster/mon*.sls

    L'esempio assegna il ruolo di monitoraggio a un gruppo di minion.

  • mgr - il daemon manager Ceph che raccoglie tutte le informazioni sullo stato dall'intero cluster. Distribuirlo su tutti i minion dove si pianifica di distribuire il ruolo monitor Ceph.

    role-mgr/cluster/mgr*.sls
  • mds - il minion fornisce il servizio metadati per supportare CephFS.

    role-mds/cluster/mds*.sls
  • igw - il minion funge da iSCSI Gateway. Questo ruolo richiede gli indirizzi dei minion assegnati, perciò occorre anche includere i file della directory stack:

    role-igw/stack/default/ceph/minions/xyz.domain.yml
    role-igw/cluster/*.sls
  • rgw - il minion funge da Object Gateway:

    role-rgw/cluster/rgw*.sls
  • openattic - il minion funge da server openATTIC:

    role-openattic/cluster/openattic*.sls

    Per ulteriori informazioni, consultare Capitolo 15, openATTIC.

  • ganesha - il minion funge da server NFS Ganesha. Il ruolo "ganesha" richiede un ruolo "rgw" o "mds" nel cluster, in caso contrario la convalida non riesce nella Fase 3.

    Per installare correttamente NFS Ganesha, è richiesta una configurazione aggiuntiva. Se si desidera utilizzare NFS Ganesha, leggere Capitolo 12, Installazione di NFS Ganesha prima di eseguire le fasi 2 e 4. Tuttavia, è possibile installare NFS Ganesha in seguito.

    In alcuni casi può essere utile definire ruoli personalizzati per i nodi NFS Ganesha. Per informazioni, vedere Sezione 14.3, «Ruoli NFS Ganesha personalizzati».

Nota
Nota: ruoli multipli dei nodi del cluster

È possibile assegnare più ruoli a un singolo nodo. Ad esempio, è possibile assegnare i ruoli mds ai nodi monitor:

role-mds/cluster/mon[1,2]*.sls

4.5.1.3 Configurazione comune

La sezione di configurazione comune comprende i file di configurazione generati durante il rilevamento (fase 1). Questi file di configurazione memorizzano parametri come fsid o public_network. Per includere la configurazione comune Ceph richiesta, aggiungere le righe seguenti:

config/stack/default/global.yml
config/stack/default/ceph/cluster.yml

4.5.1.4 Assegnazione profilo

In Ceph, un singolo ruolo di storage è insufficiente per descrivere le svariate configurazioni dei dischi disponibili con lo stesso hardware. La fase 1 di DeepSea genera una proposta del profilo di storage di default. Per default, questa proposta sarà un profilo bluestore che cercherà di proporre la configurazione con le migliori prestazioni per la configurazione hardware data. Ad esempio, i giornali di registrazione esterni vengono preferiti rispetto a un singolo disco contenente oggetti e metadati. Lo storage a stato solido viene preferito ai normali dischi rigidi. I profili vengono assegnati nel file policy.cfg come per i ruoli.

La proposta di default presente nella struttura di directory predefinita del profilo. Per includerla, aggiungere le due righe seguenti a policy.cfg.

profile-default/cluster/*.sls
profile-default/stack/default/ceph/minions/*.yml

È inoltre possibile creare un profilo di storage personalizzato a piacimento mediante il runner della proposta. Tale runner offre tre metodi: help, peek e populate.

salt-run proposal.help stampa il testo della guida del runner sui vari argomenti accettati.

salt-run proposal.peek mostra la proposta generata in base agli argomenti forniti.

salt-run proposal.populate scrive la proposta nella sottodirectory /srv/pillar/ceph/proposals. Utilizzare name=myprofile per assegnare il nome al profilo di storage. Si ottiene una sottodirectory profile-myprofile.

Per tutti gli altri argomenti, consultare il risultato di salt-run proposal.help.

4.5.1.5 Distribuzione degli OSD cifrati

A partire da SUSE Enterprise Storage 5, gli OSD sono distribuiti di default tramite BlueStore invece di FileStore. Sebbene BlueStore supporti la cifratura, i Ceph OSD sono distribuiti non cifrati di default. Supponiamo che entrambi i dischi WAL/DB e dati da utilizzare per la distribuzione OSD siano vuoti e senza partizioni. Se il disco è già stato utilizzato, cancellarlo mediante la procedura seguente descritta in Passo 13.

Per utilizzare gli OSD cifrati per la nuova distribuzione, utilizzare il runner proposal.populate con l'argomento encryption=dmcrypt:

root@master # salt-run proposal.populate encryption=dmcrypt

4.5.1.6 Filtraggio voci

A volte non è pratico includere tutti i file di una data directory con il carattere jolly *.sls. L'analizzatore di file policy.cfg comprende i seguenti filtri:

Avviso
Avviso: tecniche avanzate

Questa sezione descrive le tecniche di filtraggio per utenti avanzati. Se non utilizzati correttamente, i filtri possono provocare problemi, ad esempio se cambia la numerazione del nodo.

slice=[start:end]

Utilizzare il filtro slice per includere solo le voci da start a end-1. Tenere presente che le voci nella directory data sono in ordine alfabetico. La riga seguente comprende i file dal terzo al quinto della sottodirectory role-mon/cluster/:

role-mon/cluster/*.sls slice[3:6]
re=regexp

Utilizzare il filtro dell'espressione regolare per includere solo le voci che corrispondono alle espressioni date. Ad esempio:

role-mon/cluster/mon*.sls re=.*1[135]\.subdomainX\.sls$

4.5.1.7 File policy.cfg di esempio

Di seguito viene fornito un esempio di un file policy.cfg di base:

## Cluster Assignment
cluster-ceph/cluster/*.sls 1

## Roles
# ADMIN
role-master/cluster/examplesesadmin.sls 2
role-admin/cluster/sesclient*.sls 3

# MON
role-mon/cluster/ses-example-[123].sls 4

# MGR
role-mgr/cluster/ses-example-[123].sls 5

# MDS
role-mds/cluster/ses-example-4.sls 6

# IGW
role-igw/stack/default/ceph/minions/ses-example-4.yml 7
role-igw/cluster/ses-example-4.sls 8

# RGW
role-rgw/cluster/ses-example-4.sls 9

# openATTIC
role-openattic/cluster/openattic*.sls 10

# COMMON
config/stack/default/global.yml 11
config/stack/default/ceph/cluster.yml 12

## Profiles
profile-default/cluster/*.sls 13
profile-default/stack/default/ceph/minions/*.yml 14

1

Indica che tutti i minion sono inclusi nel cluster Ceph. Se sono presenti minion che non si desidera includere nel cluster Ceph, utilizzare:

cluster-unassigned/cluster/*.sls
cluster-ceph/cluster/ses-example-*.sls

La prima riga indica tutti i minion come non assegnati. La seconda riga sovrascrive i minion che corrispondono a "ses-example-*.sls" e li assegna al cluster Ceph.

2

Il minion denominato "examplesesadmin" ha il ruolo "master", quindi ottiene le chiavi admin per il cluster.

3

Anche tutti i minion che corrispondono a "sesclient*" ottengono le chiavi admin.

4

Tutti i minion che corrispondono a "ses-example-[123]" (presumibilmente tre minion: ses-example-1, ses-example-2 e ses-example-3) vengono impostati come nodi MON.

5

Tutti i minion che corrispondono a "ses-example-[123]" (tutti i nodi MON nell'esempio) vengono impostati come nodi MGR.

6

Il minion "ses-example-4" avrà il ruolo MDS.

7

Accerta che DeepSea conosca l'indirizzo IP del nodo IGW.

8

Il minion "ses-example-4" avrà il ruolo IGW.

9

Il minion "ses-example-4" avrà il ruolo RGW.

10

Specifica di installare l'interfaccia utente openATTIC per amministrare il cluster Ceph. Per ulteriori informazioni, vedere Capitolo 15, openATTIC.

11

Significa che si accettano i valori di default per i parametri di configurazione comuni come fsid e public_network.

12

Significa che si accettano i valori di default per i parametri di configurazione comuni come fsid e public_network.

13

Si indica a DeepSea di utilizzare il profilo hardware di default per ogni minion. La scelta del profilo hardware di default significa che si desiderano tutti i dischi aggiuntivi (diversi dal disco di root) come OSD.

14

Si indica a DeepSea di utilizzare il profilo hardware di default per ogni minion. La scelta del profilo hardware di default significa che si desiderano tutti i dischi aggiuntivi (diversi dal disco di root) come OSD.

4.5.2 File ceph.conf personalizzato

Se occorre inserire impostazioni personalizzate nel file di configurazione ceph.conf, per ulteriori informazioni, vedere Sezione 1.11, «File ceph.conf personalizzato».

Stampa pagina