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.
È 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».
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/.
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:
Fase 0, la preparazione, durante questa fase, vengono applicati tutti gli aggiornamenti richiesti e il sistema potrebbe riavviarsi.
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.
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
.
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.
È 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
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
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
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
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:*'
È 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
).
Il processo di distribuzione del cluster comprende fasi diverse. Primo, occorre preparare tutti i nodi del cluster configurando Salt, quindi distribuire e configurare Ceph.
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.
Installare e registrare SUSE Linux Enterprise Server 12 SP3 insieme con SUSE Enterprise Storage extension su ciascun nodo del cluster.
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
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.
Configurare, attivare e avviare il server di sincronizzazione dell'ora NTP:
root@master #
systemctl enable ntpd.serviceroot@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.
Verificare che il servizio AppArmor sia in esecuzione e disattivarlo su ciascun nodo cluster. Avviare il modulo YaST AppArmor e selezionare
(Impostazioni) quindi deselezionare la casella di controllo (Abilita Apparmor). Confermare con (Fine).Tenere presente che SUSE Enterprise Storage non funziona con AppArmor attivato.
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.serviceroot@master #
systemctl start salt-master.service
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 .
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
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.
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
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.serviceroot@minion >
systemctl start salt-minion.service
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
Verificare che le chiavi siano state accettate:
root@master #
salt-key --list-all
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:
Interrompere tutti i processi che utilizzano il disco specifico.
Verificare se eventuali partizioni sul disco sono montate e smontare se necessario.
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.
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.
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
Cancellare la tabella di partizione:
sgdisk -Z --clear -g /dev/sdX
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
Installare DeepSea sul nodo Salt master:
root@master #
zypper in deepsea
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.
È 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.
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».
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
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».
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
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
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
».
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:
.
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
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.
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
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.
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à 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.
I comandi DeepSea CLI possono essere eseguiti solo nel nodo Salt master, con privilegi di root
.
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
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:
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
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.
policy.cfg
È possibile trovare diversi esempi dei file di policy completi nella directory /usr/share/doc/packages/deepsea/examples/
.
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
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».
È 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
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
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
.
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
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:
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.
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]
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$
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
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. | |
Il minion denominato "examplesesadmin" ha il ruolo "master", quindi ottiene le chiavi admin per il cluster. | |
Anche tutti i minion che corrispondono a "sesclient*" ottengono le chiavi admin. | |
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. | |
Tutti i minion che corrispondono a "ses-example-[123]" (tutti i nodi MON nell'esempio) vengono impostati come nodi MGR. | |
Il minion "ses-example-4" avrà il ruolo MDS. | |
Accerta che DeepSea conosca l'indirizzo IP del nodo IGW. | |
Il minion "ses-example-4" avrà il ruolo IGW. | |
Il minion "ses-example-4" avrà il ruolo RGW. | |
Specifica di installare l'interfaccia utente openATTIC per amministrare il cluster Ceph. Per ulteriori informazioni, vedere Capitolo 15, openATTIC. | |
Significa che si accettano i valori di default per i parametri di configurazione comuni come | |
Significa che si accettano i valori di default per i parametri di configurazione comuni come | |
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. | |
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. |
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».