Vai al contenutoNaviga tra le pagine: pagina precedente [tasto di scelta p]/pagina successiva [tasto di scelta n]
documentation.suse.com / Documentazione di SUSE Enterprise Storage 7 / Guida alla distribuzione / Distribuzione del cluster Ceph / Distribuzione con cephadm
Si applica a SUSE Enterprise Storage 7

5 Distribuzione con cephadm

 

SUSE Enterprise Storage 7 utilizza lo strumento basato su Salt ceph-salt per preparare per la distribuzione tramite cephadm il sistema operativo su ogni nodo del cluster partecipante. cephadm distribuisce e gestisce i cluster Ceph connettendosi agli host dal daemon Ceph Manager tramite SSH. cephadm gestisce l'intero ciclo di vita dei cluster Ceph. Come prima cosa, esegue il bootstrap di un cluster di piccole dimensioni su un nodo singolo (un servizio MON e MGR) e usa quindi l'interfaccia di coordinamento per espandere il cluster in modo che includa tutti gli host ed esegua il provisioning di tutti i servizi Ceph. È possibile eseguire questa operazione tramite l'interfaccia riga di comando (CLI) di Ceph o parzialmente tramite il Ceph Dashboard (GUI).

Importante
Importante

Tenere presente che nella documentazione della community Ceph viene utilizzato il comando cephadm bootstrap durante la distribuzione iniziale. Il ceph-salt richiama il comando cephadm bootstrap e non deve essere eseguito direttamente. Le distribuzioni dei cluster Ceph in cui è utilizzato in modo manuale il comando cephadm bootstrap non saranno supportate.

Per distribuire un cluster Ceph tramite cephadm, è necessario completare i task seguenti:

  1. Installare ed eseguire le attività di configurazione di base del sistema operativo sottostante (SUSE Linux Enterprise Server 15 SP2) su tutti i nodi del cluster.

  2. Distribuire l'infrastruttura Salt su tutti i nodi del cluster per eseguire le preparazioni di distribuzione iniziali tramite ceph-salt.

  3. Configurare le proprietà di base del cluster tramite ceph-salt e distribuirlo.

  4. Aggiungere nuovi nodi e ruoli al cluster e distribuire i servizi su questi ultimi tramite cephadm.

5.1 Installazione e configurazione di SUSE Linux Enterprise Server

 

  1. Installare e registrare SUSE Linux Enterprise Server 15 SP2 su ciascun nodo del cluster. Durante l'installazione di SUSE Enterprise Storage, è necessario eseguire la registrazione poiché l'accesso agli archivi di aggiornamento è obbligatorio. Includere almeno i moduli seguenti:

    • Basesystem Module

    • Server Applications Module

    All'indirizzo https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-install.html è possibile trovare ulteriori dettagli su come installare SUSE Linux Enterprise Server.

  2. Installare l'estensione SUSE Enterprise Storage 7 su ogni nodo del cluster.

    Suggerimento
    Suggerimento: installazione di SUSE Enterprise Storage insieme a SUSE Linux Enterprise Server

    È possibile installare l'estensione SUSE Enterprise Storage 7 separatamente dopo aver installato SUSE Linux Enterprise Server 15 SP2 oppure è possibile aggiungerla durante la procedura di installazione di SUSE Linux Enterprise Server 15 SP2.

    All'indirizzo https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-register-sle.html è possibile trovare ulteriori dettagli su come installare le estensioni.

  3. Configurare le impostazioni di rete compresa la risoluzione del nome DNS corretto su ogni nodo. Per ulteriori informazioni sulla configurazione di una rete, vedere https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-network.html#sec-network-yast. Per ulteriori informazioni sulla configurazione di un server DNS, vedere https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-dns.html.

5.2 Distribuzione Salt

 

SUSE Enterprise Storage utilizza Salt e ceph-salt per la preparazione iniziale del cluster. Salt consente di configurare ed eseguire contemporaneamente i comandi su più nodi del cluster da un host dedicato denominato Salt Master. Prima della distribuzione Salt, esaminare quanto segue:

  • I Salt Minion sono i nodi controllati da un nodo dedicato denominato Salt Master.

  • Se l'host Salt Master deve fare parte del cluster Ceph, deve eseguire il proprio Salt Minion, anche se non si tratta di un requisito obbligatorio.

    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 con la procedura di upgrade, non distribuire il ruolo Ceph OSD, del server di metadati o Ceph Monitor sul nodo admin.

  • I Salt Minion devono risolvere correttamente il nome host del Salt Master in rete. Per default, cercano il nome host salt, ma è possibile specificare altri nomi host individuabili in rete nel file /etc/salt/minion.

  1. Installare il salt-master sul nodo Salt Master: 

    root@master # zypper in salt-master

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

  3. Se si intende utilizzare il firewall, verificare che il nodo Salt 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 salt-master per la zona appropriata. Ad esempio, public.

  4. Installare il pacchetto salt-minion su tutti i nodi minion. 

    root@minion > zypper in salt-minion

  5. Modificare /etc/salt/minion e rimuovere i commenti dalla riga seguente: 

    #log_level_logfile: warning

    Modificare il livello di log da warning a info.

    Nota
    Nota: log_level_logfile e log_level

    Mentre log_level controlla i messaggi di log che verranno visualizzati sulla schermata, log_level_logfile controlla i messaggi di log che verranno scritti su /var/log/salt/minion.

    Nota
    Nota

    Assicurarsi di impostare il livello di log su tutti i nodi del cluster (minion).

  6. Assicurarsi che il nome di dominio completo di ogni nodo possa essere risolto in un indirizzo IP sulla rete di cluster pubblica da tutti gli altri nodi.

  7. Configurare tutti i minion sulla connessione 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 contenuto seguente: 

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

    root@minion > systemctl restart salt-minion.service

  8. Verificare che il servizio salt-minion sia abilitato e avviato su tutti i nodi. Abilitarlo e avviarlo se necessario: 

    root # systemctl enable salt-minion.service
root # systemctl start salt-minion.service

  9. Verificare ogni impronta digitale del Salt Minion e accettare tutte le chiavi salt sul Salt Master se le impronte digitali corrispondono.

    Nota
    Nota

    Se l'impronta digitale del Salt Minion viene restituita vuota, assicurarsi che il Salt Minion disponga di una configurazione Salt Master e che sia in grado di comunicare con quest'ultimo.

    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 digitali 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 digitali dei minion corrispondono, accettarle: 

    root@master # salt-key --accept-all

  10. Verificare che le chiavi siano state accettate: 

    root@master # salt-key --list-all

  11. Verificare se tutti i Salt Minion rispondono: 

    root@master # salt-run manage.status

5.3 Distribuzione del cluster Ceph

 

Questa sezione illustra il processo di distribuzione di un cluster Ceph di base. Leggere con attenzione le sottosezioni seguenti ed eseguire i comandi inclusi nell'ordine dato.

5.3.1 Installazione di ceph-salt

 

ceph-salt fornisce strumenti per la distribuzione dei cluster Ceph gestiti da cephadm. ceph-salt utilizza l'infrastruttura Salt per la gestione del sistema operativo, ad esempio gli aggiornamenti del software o la sincronizzazione dell'orario, e per la definizione dei ruoli dei Salt Minion.

Sul Salt master, installare il pacchetto ceph-salt : 

root@master # zypper install ceph-salt

Il comando riportato sopra ha installato ceph-salt-formula come una dipendenza che ha modificato la configurazione del Salt Master tramite l'inserimento di file aggiuntivi nella directory /etc/salt/master.d. Per applicare le modifiche, riavviare salt-master.service e sincronizzare i moduli Salt: 

root@master # systemctl restart salt-master.service
root@master # salt \* saltutil.sync_all

5.3.2 Configurazione delle proprietà del cluster

 

Utilizzare il comando ceph-salt config per configurare le proprietà di base del cluster.

Importante
Importante

Il file /etc/ceph/ceph.conf è gestito da cephadm e gli utenti non devono modificarlo. Impostare i parametri di configurazione Ceph con il nuovo comando ceph config. Consultare Sezione 28.2, «Database di configurazione» per maggiori informazioni.

5.3.2.1 Utilizzo della shell ceph-salt

 

Se si esegue ceph-salt config senza alcun percorso o sottocomando, viene creata una shell ceph-salt interattiva. La shell è utile se è necessario configurare contemporaneamente più proprietà o se non si desidera digitare l'intera sintassi del comando. 

root@master # ceph-salt config
/> ls
o- / ............................................................... [...]
  o- ceph_cluster .................................................. [...]
  | o- minions .............................................. [no minions]
  | o- roles ....................................................... [...]
  |   o- admin .............................................. [no minions]
  |   o- bootstrap ........................................... [no minion]
  |   o- cephadm ............................................ [no minions]
  |   o- tuned ..................................................... [...]
  |     o- latency .......................................... [no minions]
  |     o- throughput ....................................... [no minions]
  o- cephadm_bootstrap ............................................. [...]
  | o- advanced .................................................... [...]
  | o- ceph_conf ................................................... [...]
  | o- ceph_image_path .................................. [ no image path]
  | o- dashboard ................................................... [...]
  | | o- force_password_update ................................. [enabled]
  | | o- password ................................................ [admin]
  | | o- ssl_certificate ....................................... [not set]
  | | o- ssl_certificate_key ................................... [not set]
  | | o- username ................................................ [admin]
  | o- mon_ip .................................................. [not set]
  o- containers .................................................... [...]
  | o- registries_conf ......................................... [enabled]
  | | o- registries .............................................. [empty]
  | o- registry_auth ............................................... [...]
  |   o- password .............................................. [not set]
  |   o- registry .............................................. [not set]
  |   o- username .............................................. [not set]
  o- ssh ............................................... [no key pair set]
  | o- private_key .................................. [no private key set]
  | o- public_key .................................... [no public key set]
  o- time_server ........................... [enabled, no server host set]
    o- external_servers .......................................... [empty]
    o- servers ................................................... [empty]
    o- subnet .................................................. [not set]

Come è possibile vedere dall'output del comando ls di ceph-salt, la configurazione del cluster presenta una struttura ad albero. Sono disponibili due opzioni per configurare una proprietà specifica del cluster nella shell ceph-salt:

  • Eseguire il comando dalla posizione corrente e immettere il percorso assoluto alla proprietà come primo argomento: 

    /> /cephadm_bootstrap/dashboard ls
o- dashboard ....................................................... [...]
  o- force_password_update ..................................... [enabled]
  o- password .................................................... [admin]
  o- ssl_certificate ........................................... [not set]
  o- ssl_certificate_key ....................................... [not set]
  o- username .................................................... [admin]
/> /cephadm_bootstrap/dashboard/username set ceph-admin
Value set.

  • Modificare inserendo il percorso di cui occorre configurare la proprietà ed eseguire il comando: 

    /> cd /cephadm_bootstrap/dashboard/
/ceph_cluster/minions> ls
o- dashboard ....................................................... [...]
  o- force_password_update ..................................... [enabled]
  o- password .................................................... [admin]
  o- ssl_certificate ........................................... [not set]
  o- ssl_certificate_key ....................................... [not set]
  o- username ................................................[ceph-admin]
Suggerimento
Suggerimento: completamento automatico degli snippet di configurazione

Dalla shell ceph-salt, è possibile utilizzare la funzione di completamento automatico in modo simile a come la si utilizza in una normale shell Linux (Bash). Tale funzione consente di completare i percorsi di configurazione, i sottocomandi o i nomi dei Salt Minion. Durante il completamento automatico di un percorso di configurazione, sono disponibili due opzioni:

  • Per fare in modo che la shell termini un percorso relativo sulla posizione corrente, premere due volte il tasto TAB →|.

  • Per fare in modo che la shell termini un percorso assoluto, immettere / e premere due volte il tasto TAB →|.

Suggerimento
Suggerimento: navigazione con i tasti del cursore

Se si immette cd dalla shell ceph-salt senza specificare alcun percorso, il comando stamperà una struttura ad albero della configurazione del cluster con la riga dell'attuale percorso attivo. È possibile utilizzare i tasti su è giù del cursore per spostarsi tra le singole righe. Dopo aver confermato con Enter, il percorso di configurazione verrà modificato sull'ultimo percorso attivo.

Importante
Importante: convenzione

Per assicurare la coerenza della documentazione, viene utilizzata la sintassi di un singolo comando senza immettere la shell ceph-salt. Ad esempio, è possibile elencare l'albero di configurazione del cluster con il comando seguente: 

root@master # ceph-salt config ls

5.3.2.2 Aggiunta di Salt Minion

 

Includere nella configurazione del cluster Ceph tutti o un sottoinsieme di Salt Minion distribuiti e accettati nella Sezione 5.2, «Distribuzione Salt». È possibile specificare i Salt Minion utilizzando il loro nome intero oppure le espressioni glob "*" e "?" per includere contemporaneamente più Salt Minion. Utilizzare il sottocomando add nel percorso /ceph_cluster/minions. Il comando seguente include tutti i Salt Minion accettati: 

root@master # ceph-salt config /ceph_cluster/minions add '*'

Verificare che i Salt Minion specificati siano stati aggiunti: 

root@master # ceph-salt config /ceph_cluster/minions ls
o- minions ................................................. [Minions: 5]
  o- ses-master.example.com .................................. [no roles]
  o- ses-min1.example.com .................................... [no roles]
  o- ses-min2.example.com .................................... [no roles]
  o- ses-min3.example.com .................................... [no roles]
  o- ses-min4.example.com .................................... [no roles]

5.3.2.3 Specifica dei Salt Minion gestiti da cephadm

 

Specificare i nodi che apparterranno al cluster Ceph e che saranno gestiti da cephadm. Includere tutti i nodi che eseguiranno i servizi Ceph, oltre al nodo admin: 

root@master # ceph-salt config /ceph_cluster/roles/cephadm add '*'

5.3.2.4 Specifica del nodo admin

 

Il nodo admin è il nodo in cui sono installati il file di configurazione ceph.conf e il portachiavi di amministrazione Ceph. In genere, i comandi correlati a Ceph vengono eseguiti sul nodo admin.

Suggerimento
Suggerimento: Salt Master e nodo admin sullo stesso nodo

Negli ambienti eterogenei, dove tutti o quasi tutti gli host appartengono a SUSE Enterprise Storage, si consiglia di posizionare il nodo admin sullo stesso host del Salt Master.

Negli ambienti eterogenei dove un'infrastruttura Salt ospita più di un cluster, ad esempio SUSE Enterprise Storage insieme a SUSE Manager, non posizionare il nodo admin sullo stesso host del Salt Master.

Per specificare il nodo admin, eseguire il comando seguente: 

root@master # ceph-salt config /ceph_cluster/roles/admin add ses-master.example.com
1 minion added.
root@master # ceph-salt config /ceph_cluster/roles/admin ls
o- admin ................................................... [Minions: 1]
  o- ses-master.example.com ...................... [Other roles: cephadm]
Suggerimento
Suggerimento: installazione di ceph.conf e del portachiavi di amministrazione su più nodi

È possibile installare il file di configurazione e il portachiavi di amministrazione Ceph su più nodi, se richiesto dalla distribuzione. Per motivi di sicurezza, evitare di installarli su tutti i nodi del cluster.

5.3.2.5 Specifica del primo nodo MON/MGR

 

È necessario specificare quale Salt Minion del cluster eseguirà il bootstrap del cluster. Questo minion diventerà il primo a eseguire i servizi Ceph Monitor e Ceph Manager. 

root@master # ceph-salt config /ceph_cluster/roles/bootstrap set ses-min1.example.com
Value set.
root@master # ceph-salt config /ceph_cluster/roles/bootstrap ls
o- bootstrap ..................................... [ses-min1.example.com]

Inoltre, è necessario specificare l'indirizzo IP del MON di bootstrap sulla rete pubblica per assicurarsi che il parametro public_network sia impostato correttamente, ad esempio: 

root@master # ceph-salt config /cephadm_bootstrap/mon_ip set 192.168.10.20

5.3.2.6 Specifica dei profili ottimizzati

 

È necessario specificare quali minion del cluster dispongono di profili ottimizzati attivamente. A questo scopo, aggiungere questi ruoli esplicitamente con i comandi seguenti:

Nota
Nota

Un minion non può ricoprire sia il ruolo latency che il ruolo throughput. 

root@master # ceph-salt config /ceph_cluster/roles/tuned/latency add ses-min1.example.com
Adding ses-min1.example.com...
1 minion added.
root@master # ceph-salt config /ceph_cluster/roles/tuned/throughput add ses-min2.example.com
Adding ses-min2.example.com...
1 minion added.

5.3.2.7 Generazione di una coppia di chiavi SSH

 

cephadm utilizza il protocollo SSH per comunicare con i nodi del cluster. L'account utente denominato cephadm viene creato automaticamente e utilizzato per la comunicazione SSH.

È necessario generare la parte privata e pubblica della coppia di chiavi SSH: 

root@master # ceph-salt config /ssh generate
Key pair generated.
root@master # ceph-salt config /ssh ls
o- ssh .................................................. [Key Pair set]
  o- private_key ..... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
  o- public_key ...... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]

5.3.2.8 Configurazione del server dell'orario

 

L'orario di tutti i nodi del cluster deve essere sincronizzato con un'origine dell'orario affidabile. Sono previsti diversi scenari di approccio alla sincronizzazione dell'orario:

  • Se tutti i nodi del cluster sono già configurati sulla sincronizzazione dell'orario tramite un servizio NTP preferito, disabilitare del tutto la gestione del server dell'orario: 

    root@master # ceph-salt config /time_server disable

  • Se il sito dispone già di un'origine dell'orario singola, specificare il nome host di tale origine: 

     root@master # ceph-salt config /time_server/servers add time-server.example.com

  • In alternativa, ceph-salt è in grado di configurare uno dei Salt Minion nel ruolo di server dell'orario per il resto del cluster. In questi casi, si parla di "server dell'orario interno". In questo scenario, ceph-salt configurerà il server dell'orario interno (che deve essere uno dei Salt Minion) sulla sincronizzazione del suo orario con un server dell'orario esterno, come pool.ntp.org, e configurerà tutti gli altri minion per fare in modo che ricavino il proprio orario dal server dell'orario interno. È possibile eseguire questa operazione come segue: 

    root@master # ceph-salt config /time_server/servers add ses-master.example.com
root@master # ceph-salt config /time_server/external_servers add pool.ntp.org

    L'opzione /time_server/subnet specifica la sottorete da cui i client NTP possono accedere al server NTP. Questa opzione è impostata automaticamente se si specifica /time_server/servers. Se è necessario modificarla o specificarla manualmente, eseguire: 

    root@master # ceph-salt config /time_server/subnet set 10.20.6.0/24

Verificare le impostazioni del server dell'orario: 

root@master # ceph-salt config /time_server ls
o- time_server ................................................ [enabled]
  o- external_servers ............................................... [1]
  | o- pool.ntp.org ............................................... [...]
  o- servers ........................................................ [1]
  | o- ses-master.example.com ..................................... [...]
  o- subnet .............................................. [10.20.6.0/24]

All'indirizzo https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-ntp.html#sec-ntp-yast sono disponibili ulteriori informazioni sulla configurazione della sincronizzazione dell'orario.

5.3.2.9 Configurazione delle credenziali di login del Ceph Dashboard

 

Il Ceph Dashboard sarà disponibile in seguito alla distribuzione del cluster di base. Per accedervi, è necessario impostare un nome utente e una password validi, ad esempio: 

root@master # ceph-salt config /cephadm_bootstrap/dashboard/username set admin
root@master # ceph-salt config /cephadm_bootstrap/dashboard/password set PWD
Suggerimento
Suggerimento: forzatura dell'aggiornamento della password

Per default, il primo utente del dashboard sarà forzato a modificare la password al primo login al dashboard. Per disabilitare questa funzione, eseguire il comando seguente: 

root@master # ceph-salt config /cephadm_bootstrap/dashboard/force_password_update disable

5.3.2.10 Configurazione del percorso alle immagini del container

 

cephadm deve conoscere un percorso URI valido alle immagini del container, che verrà utilizzato durante il passaggio di distribuzione. Verificare se il percorso di default è impostato: 

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path ls

Se il percorso di default non è impostato o se la distribuzione richiede un percorso specifico, aggiungerlo come indicato di seguito: 

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path set registry.suse.com/ses/7/ceph/ceph
Nota
Nota

Per lo stack di monitoraggio, sono necessarie ulteriori immagini del container. Per le distribuzioni Air-gap o per quelle eseguite da un registro locale, è consigliabile recuperare queste immagini già durante questa fase per preparare il registro locale di conseguenza.

Tenere presente che queste immagini del container non saranno utilizzate da ceph-salt per la distribuzione. Si tratta di una preparazione a un passaggio successivo in cui cephadm verrà utilizzato per la distribuzione o la migrazione dei componenti di monitoraggio.

Per ulteriori informazioni sulle immagini utilizzate dallo stack di monitoraggio e sulla loro personalizzazione, visitare la pagina Sezione 16.1, «Configurazione di immagini personalizzate o locali».

5.3.2.11 Configurazione del registro del container

 

Facoltativamente, è possibile impostare un registro del container locale che fungerà da copia speculare del registro registry.suse.com. Ricordare che sarà necessario ripetere la sincronizzazione del registro locale ogni volta che saranno disponibili nuovi container aggiornati in registry.suse.com.

La creazione di un registro locale è utile negli scenari seguenti:

  • Sono presenti molti nodi del cluster e si desidera risparmiare tempo di download e larghezza di banda tramite la creazione di una copia speculare locale delle immagini del container.

  • Il cluster non dispone dell'accesso al registro online (distribuzione Air-gap) e si necessita di una copia speculare locale da cui eseguire il pull delle immagini del container.

  • Se il cluster non riesce ad accedere ai registri remoti tramite un collegamento sicuro a causa di problemi di configurazione o di rete, è necessario disporre di un registro locale non cifrato.

Importante
Importante

Per distribuire le PTF (Program Temporary Fixes) su un sistema supportato, è necessario distribuire un registro del container locale.

Per configurare un URL del registro locale insieme alle credenziali di accesso, procedere come segue:

  1. Configurare l'URL del registro locale: 

    cephuser@adm > ceph-salt config /containers/registry_auth/registry set REGISTRY_URL

  2. Configurare il nome utente e la password per accedere al registro locale: 

    cephuser@adm > ceph-salt config /containers/registry_auth/username set REGISTRY_USERNAME
    cephuser@adm > ceph-salt config /containers/registry_auth/password set REGISTRY_PASSWORD

  3. Eseguire ceph-salt apply per aggiornare il Salt Pillar su tutti i minion.

Suggerimento
Suggerimento: cache del registro

Per evitare di ripetere la sincronizzazione del registro locale quando sono presenti nuovi container aggiornati, è possibile configurare una cache del registro.

I metodi di sviluppo e rilascio delle applicazioni cloud-native richiedono un registro e un'istanza CI/CD (Continuous Integration/Delivery) per lo sviluppo e la produzione delle immagini del container. In questo caso, è possibile utilizzare un registro privato.

5.3.2.12 Abilitazione della cifratura in esecuzione dei dati (msgr2)

 

Il protocollo Messenger v2 (MSGR2) è il protocollo cablato di Ceph. Fornisce una modalità di sicurezza che cifra tutti i dati in transito sulla rete, l'incapsulamento dei payload di autenticazione e l'abilitazione dell'integrazione futura delle nuove modalità di autenticazione (come Kerberos).

Importante
Importante

msgr2 non è attualmente supportato dai client Ceph del kernel Linux, come CephFS e il dispositivo di blocco RADOS (RADOS Block Device, RBD).

I daemon Ceph possono eseguire l'associazione a più porte, consentendo ai client Ceph esistenti e ai nuovi client abilitati per v2 di connettersi allo stesso cluster. Per default, i MON eseguono adesso l'associazione alla nuova porta 3300 con assegnazione IANA (CE4h o 0xCE4) per il nuovo protocollo v2, oltre all'associazione alla precedente porta 6789 di default per il protocollo v1 legacy.

Il protocollo v2 (MSGR2) supporta due modalità di connessione:

crc mode

Un'autenticazione iniziale sicura quando viene stabilita la connessione e un controllo dell'integrità CRC32.

secure mode

Un'autenticazione iniziale sicura quando viene stabilita la connessione e una cifratura completa di tutto il traffico post-autenticazione, incluso un controllo dell'integrità crittografico.

Per la maggior parte delle connessioni, sono disponibili opzioni per controllare le modalità da utilizzare:

ms_cluster_mode

La modalità di connessione (o le modalità consentite) utilizzata per la comunicazione interna al cluster tra i daemon Ceph. Se sono elencate più modalità, sono preferite quelle nelle prime posizioni dell'elenco.

ms_service_mode

Un elenco delle modalità consentite che i client possono utilizzare durante la connessione al cluster.

ms_client_mode

Un elenco di modalità di connessione, in ordine di preferenza, che i client possono utilizzare (o consentire) durante la comunicazione con un cluster Ceph.

È presente un insieme di opzioni parallele che si applica specificamente ai monitor e che consente agli amministratori di impostare requisiti diversi (in genere più sicuri) per la comunicazione con i monitor.

ms_mon_cluster_mode

La modalità di connessione (o le modalità consentite) da utilizzare tra i monitor.

ms_mon_service_mode

Un elenco delle modalità consentite che i client o altri daemon Ceph possono utilizzare durante la connessione ai monitor.

ms_mon_client_mode

Un elenco delle modalità di connessione, in ordine di preferenza, che i client o i daemon diversi dai monitor possono utilizzare durante la connessione ai monitor.

Per abilitare la modalità di cifratura MSGR2 durante la distribuzione, è necessario aggiungere delle opzioni di configurazione alla configurazione ceph-salt prima di eseguire ceph-salt apply.

Per utilizzare la modalità secure, eseguire i comandi seguenti.

Aggiungere la sezione globale a ceph_conf nello strumento di configurazione ceph-salt: 

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf add global

Impostare le opzioni seguenti: 

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_cluster_mode "secure crc"
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_service_mode "secure crc"
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_client_mode "secure crc"
Nota
Nota

Assicurarsi che secure preceda crc.

Per forzare la modalità secure, eseguire i comandi seguenti: 

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_cluster_mode secure
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_service_mode secure
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_client_mode secure
Suggerimento
Suggerimento: aggiornamento delle impostazioni

Se si desidera modificare le impostazioni riportate sopra, impostare le modifiche alla configurazione nell'archivio di configurazione del monitor. A questo scopo, utilizzare il comando ceph config set. 

root@master # ceph config set global CONNECTION_OPTION CONNECTION_MODE [--force]

Esempio: 

root@master # ceph config set global ms_cluster_mode "secure crc"

Se si desidera selezionare il valore attuale, incluso quello di default, eseguire il comando seguente: 

root@master # ceph config get CEPH_COMPONENT CONNECTION_OPTION

Ad esempio, per attivare la ms_cluster_mode per gli OSD, eseguire: 

root@master # ceph config get osd ms_cluster_mode

5.3.2.13 Configurazione della rete di cluster

 

Se si esegue una rete di cluster separata, potrebbe essere necessario impostare l'indirizzo IP della rete di cluster seguito dalla porzione della maschera di sottorete dopo il simbolo della barra, ad esempio 192.168.10.22/24.

Eseguire i comandi seguenti per abilitare cluster_network: 

root@master # ceph-salt config /cephadm_bootstrap/ceph_conf add global
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf/global set cluster_network NETWORK_ADDR

5.3.2.14 Verifica della configurazione del cluster

 

La configurazione minima del cluster è stata completata. Analizzarla per individuare errori evidenti: 

root@master # ceph-salt config ls
o- / ............................................................... [...]
  o- ceph_cluster .................................................. [...]
  | o- minions .............................................. [Minions: 5]
  | | o- ses-master.example.com .................................. [admin]
  | | o- ses-min1.example.com ......................... [bootstrap, admin]
  | | o- ses-min2.example.com ................................. [no roles]
  | | o- ses-min3.example.com ................................. [no roles]
  | | o- ses-min4.example.com ................................. [no roles]
  | o- roles ....................................................... [...]
  |   o- admin .............................................. [Minions: 2]
  |   | o- ses-master.example.com ....................... [no other roles]
  |   | o- ses-min1.example.com ................. [other roles: bootstrap]
  |   o- bootstrap ................................ [ses-min1.example.com]
  |   o- cephadm ............................................ [Minions: 5]
  |   o- tuned ..................................................... [...]
  |     o- latency .......................................... [no minions]
  |     o- throughput ....................................... [no minions]
  o- cephadm_bootstrap ............................................. [...]
  | o- advanced .................................................... [...]
  | o- ceph_conf ................................................... [...]
  | o- ceph_image_path ............... [registry.suse.com/ses/7/ceph/ceph]
  | o- dashboard ................................................... [...]
  |   o- force_password_update ................................. [enabled]
  |   o- password ................................... [randomly generated]
  |   o- username ................................................ [admin]
  | o- mon_ip ............................................ [192.168.10.20]
  o- containers .................................................... [...]
  | o- registries_conf ......................................... [enabled]
  | | o- registries .............................................. [empty]
  | o- registry_auth ............................................... [...]
  |   o- password .............................................. [not set]
  |   o- registry .............................................. [not set]
  |   o- username .............................................. [not set]
  o- ssh .................................................. [Key Pair set]
  | o- private_key ..... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
  | o- public_key ...... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
  o- time_server ............................................... [enabled]
    o- external_servers .............................................. [1]
    | o- 0.pt.pool.ntp.org ......................................... [...]
    o- servers ....................................................... [1]
    | o- ses-master.example.com .................................... [...]
    o- subnet ............................................. [10.20.6.0/24]
Suggerimento
Suggerimento: stato della configurazione del cluster

È possibile verificare la validità della configurazione del cluster eseguendo il comando seguente: 

root@master # ceph-salt status
cluster: 5 minions, 0 hosts managed by cephadm
config: OK

5.3.2.15 Esportazione delle configurazioni del cluster

 

Dopo aver configurato il cluster di base e averne verificato la validità della configurazione, è consigliabile esportare tale configurazione in un file: 

root@master # ceph-salt export > cluster.json
Avvertimento
Avvertimento

L'output dell'esportazione ceph-salt export include la chiave privata SSH. In caso di dubbi sulle implicazioni di sicurezza, non eseguire questo comando senza le appropriate precauzioni.

Se si dovesse interrompere la configurazione del cluster e fosse necessario ripristinarla a uno stato di backup precedente, eseguire: 

root@master # ceph-salt import cluster.json

5.3.3 Aggiornamento dei nodi e bootstrap del cluster minimo

 

Prima di distribuire il cluster, aggiornare tutti i pacchetti software su tutti i nodi: 

root@master # ceph-salt update

Se durante l'aggiornamento un nodo restituisce il messaggio che informa che è necessario eseguire il riavvio, vuol dire che i pacchetti importanti del sistema operativo (come il kernel) sono stati aggiornati a una versione più recente ed è necessario riavviare il nodo per applicare le modifiche.

Per riavviare tutti i nodi pertinenti, aggiungere l'opzione --reboot 

root@master # ceph-salt update --reboot

Oppure, riavviarli in un passaggio separato: 

root@master # ceph-salt reboot
Importante
Importante

Il Salt Master non viene mai riavviato dai comandi ceph-salt update --reboot o ceph-salt reboot. Se è necessario riavviare il Salt Master, occorre procedere manualmente.

In seguito all'aggiornamento dei nodi, eseguire il bootstrap del cluster minimo: 

root@master # ceph-salt apply
Nota
Nota

Al termine del bootstrap, sul cluster saranno presenti un Ceph Monitor e un Ceph Manager.

Il comando riportato sopra consentirà di aprire un'interfaccia utente interattiva in cui è mostrato l'avanzamento di ogni minion.

Distribuzione di un cluster minimo
Figura 5.1: Distribuzione di un cluster minimo
 
Suggerimento
Suggerimento: modalità non interattiva

Se è necessario applicare la configurazione da uno script, è disponibile anche una modalità di distribuzione non interattiva, utile anche quando il cluster viene distribuito da un computer remoto, per evitare le distrazioni causate dall'aggiornamento continuo delle informazioni di avanzamento sulla schermata online: 

root@master # ceph-salt apply --non-interactive

5.3.4 Revisione dei passaggi finali

 

Al termine dell'esecuzione del comando ceph-salt apply, dovrebbe essere presente un Ceph Monitor e un Ceph Manager. Dovrebbe essere possibile eseguire correttamente il comando ceph status su uno dei minion a cui è stato assegnato il ruolo admin come root o utente cephadm tramite sudo.

I passaggi successivi riguardano l'uso di cephadm per la distribuzione di Ceph Monitor, Ceph Manager, OSD, stack di monitoraggio e gateway aggiuntivi.

Prima di continuare, rivedere le nuove impostazioni di rete del cluster. A questo punto, l'impostazione public_network è stata popolata in base ai valori immessi per /cephadm_bootstrap/mon_ip nella configurazione ceph-salt. Tuttavia, questa impostazione è stata applicata soltanto a Ceph Monitor. È possibile rivederla con il comando seguente: 

root@master # ceph config get mon public_network

Si tratta della configurazione minima richiesta per il funzionamento di Ceph, ma si consiglia di configurare l'impostazione public_network come global, ovvero di applicarla a tutti i tipi di daemon Ceph e non soltanto ai MON: 

root@master # ceph config set global public_network "$(ceph config get mon public_network)"
Nota
Nota

Questo passaggio non è obbligatorio. Tuttavia, se si sceglie di non utilizzare questa impostazione, i Ceph OSD e altri daemon (ad eccezione di Ceph Monitor) resteranno in ascolto su tutti gli indirizzi.

Se si desidera che gli OSD comunichino tra di loro su una rete completamente separata, eseguire il comando seguente: 

root@master # ceph config set global cluster_network "cluster_network_in_cidr_notation"

Eseguendo questo comando, gli OSD creati nella distribuzione utilizzeranno fin dall'inizio la rete di cluster designata.

Se sono stati impostati nodi dense per il cluster (più di 62 OSD per host), assicurarsi di assegnare un numero sufficiente di porte ai Ceph OSD. L'intervallo di default (6800-7300) attualmente non consente più di 62 OSD per host. Per un cluster con nodi dense, regolare l'impostazione ms_bind_port_max su un valore adeguato. Ogni OSD consumerà otto porte aggiuntive. Ad esempio, per un host impostato sull'esecuzione di 96 OSD, saranno necessarie 768 porte. L'impostazione ms_bind_port_max deve essere configurata su almeno 7568 tramite l'esecuzione del comando seguente: 

root@master # ceph config set osd.* ms_bind_port_max 7568

A questo scopo, è necessario regolare le impostazioni del firewall di conseguenza. Consultare Sezione 13.7, «Firewall settings for Ceph» per maggiori informazioni.

5.4 Distribuzione di servizi e gateway

 

In seguito alla distribuzione del cluster Ceph di base, distribuire i servizi di base su altri nodi del cluster. Per rendere i dati del cluster accessibili ai client, distribuire anche dei servizi aggiuntivi.

Attualmente, la distribuzione dei servizi Ceph sulla riga di comando è supportata tramite l'utilità di coordinamento Ceph (sottocomandi ceph orch).

5.4.1 Il comando ceph orch

 

Il comando ceph orch dell'utilità di coordinamento Ceph, un'interfaccia del modulo cephadm, elenca i componenti del cluster e distribuisce i servizi Ceph sui nuovi nodi del cluster.

5.4.1.1 Visualizzazione dello stato dell'utilità di coordinamento

 

Il comando seguente mostra lo stato e la modalità correnti dell'utilità di coordinamento Ceph. 

cephuser@adm > ceph orch status

5.4.1.2 Elenco di dispositivi, servizi e daemon

 

Per elencare tutti i dispositivi disco, eseguire quanto riportato di seguito: 

cephuser@adm > ceph orch device ls
Hostname   Path      Type  Serial  Size   Health   Ident  Fault  Available
ses-master /dev/vdb  hdd   0d8a... 10.7G  Unknown  N/A    N/A    No
ses-min1   /dev/vdc  hdd   8304... 10.7G  Unknown  N/A    N/A    No
ses-min1   /dev/vdd  hdd   7b81... 10.7G  Unknown  N/A    N/A    No
[...]
Suggerimento
Suggerimento: servizi e daemon

Con il termine generale servizio si indica un servizio Ceph di un tipo specifico, ad esempio Ceph Manager.

Daemon è un'istanza specifica di un servizio, ad esempio un processo mgr.ses-min1.gdlcik in esecuzione su un nodo denominato ses-min1.

Per elencare tutti i servizi noti a cephadm, eseguire: 

cephuser@adm > ceph orch ls
NAME  RUNNING  REFRESHED  AGE  PLACEMENT  IMAGE NAME                  IMAGE ID
mgr       1/0  5m ago     -    <no spec>  registry.example.com/[...]  5bf12403d0bd
mon       1/0  5m ago     -    <no spec>  registry.example.com/[...]  5bf12403d0bd
Suggerimento
Suggerimento

Con il parametro facoltativo -–host, è possibile limitare l'elenco ai servizi che si trovano su un determinato nodo, mentre con il parametro facoltativo --service-type, è possibile limitarlo ai servizi di un determinato tipo (i tipi accettabili sono mon, osd, mgr, mds e rgw).

Per elencare tutti i daemon in esecuzione distribuiti da cephadm, eseguire: 

cephuser@adm > ceph orch ps
NAME            HOST     STATUS   REFRESHED AGE VERSION    IMAGE ID     CONTAINER ID
mgr.ses-min1.gd ses-min1 running) 8m ago    12d 15.2.0.108 5bf12403d0bd b8104e09814c
mon.ses-min1    ses-min1 running) 8m ago    12d 15.2.0.108 5bf12403d0bd a719e0087369
Suggerimento
Suggerimento

Per interrogare lo stato di un daemon specifico, utilizzare --daemon_type e --daemon_id. Per gli OSD, l'ID corrisponde all'ID numerico dell'OSD: Per MDS, l'ID corrisponde al nome del file system: 

cephuser@adm > ceph orch ps --daemon_type osd --daemon_id 0
cephuser@adm > ceph orch ps --daemon_type mds --daemon_id my_cephfs

5.4.2 Specifica del servizio e del posizionamento

 

Per specificare la distribuzione dei servizi Ceph, si consiglia di creare un file con formattazione YAML contenente la specifica dei servizi da distribuire.

5.4.2.1 Creazione di specifiche del servizio

 

È possibile creare un file della specifica separato per ogni tipo di servizio, ad esempio: 

root@master # cat nfs.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE

In alternativa, è possibile specificare più tipi di servizi (o tutti) in un file, ad esempio cluster.yml, in cui sono indicati i nodi che eseguiranno i servizi specifici. È necessario separare i singoli tipi di servizi con tre trattini (---): 

cephuser@adm > cat cluster.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE
---
service_type: rgw
service_id: REALM_NAME.ZONE_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
---
[...]

Le proprietà descritte in precedenza hanno il significato seguente:

service_type

Il tipo di servizio. Può trattarsi di un servizio Ceph (mon, mgr, mds, crash, osd o rbd-mirror), di un gateway (nfs o rgw) o di parte dello stack di monitoraggio (alertmanager, grafana, node-exporter o prometheus).

service_id

Il nome del servizio. Per le specifiche del tipo mon, mgr, alertmanager, grafana, node-exporter e prometheus non è necessaria la proprietà service_id.

placement

Specifica quali nodi eseguiranno il servizio. Per ulteriori dettagli, fare riferimento alla Sezione 5.4.2.2, «Creazione della specifica di posizionamento».

spec

Ulteriore specifica pertinente al tipo di servizio.

Suggerimento
Suggerimento: applicazione di servizi specifici

In genere, i servizi del cluster Ceph dispongono di diverse proprietà specifiche. Per esempi e dettagli delle specifiche dei singoli servizi, fare riferimento alla Sezione 5.4.3, «Distribuzione dei servizi Ceph».

5.4.2.2 Creazione della specifica di posizionamento

 

Per distribuire i servizi Ceph, cephadm deve sapere su quali nodi agire. Utilizzare la proprietà placement ed elencare i nomi host abbreviati dei nodi a cui si applica il servizio: 

cephuser@adm > cat cluster.yml
[...]
placement:
  hosts:
  - host1
  - host2
  - host3
[...]

5.4.2.3 Applicazione della specifica del cluster

 

Dopo aver creato un file cluster.yml completo con le specifiche di tutti i servizi e il relativo posizionamento, è possibile applicare il cluster eseguendo il comando seguente: 

cephuser@adm > ceph orch apply -i cluster.yml

Per visualizzare lo stato del cluster, eseguire il comando ceph orch status. Per ulteriori informazioni, vedere Sezione 5.4.1.1, «Visualizzazione dello stato dell'utilità di coordinamento».

5.4.2.4 Esportazione della specifica di un cluster in esecuzione

 

Durante il funzionamento, la configurazione del cluster potrebbe differire dalla specifica originale, anche se i servizi sono stati distribuiti sul cluster Ceph utilizzando i file della specifica descritti nella Sezione 5.4.2, «Specifica del servizio e del posizionamento». Inoltre, i file della specifica potrebbero essere stati eliminati per errore.

Per recuperare la specifica completa di un cluster in esecuzione, eseguire: 

cephuser@adm > ceph orch ls --export
placement:
  hosts:
  - hostname: ses-min1
    name: ''
    network: ''
service_id: my_cephfs
service_name: mds.my_cephfs
service_type: mds
---
placement:
  count: 2
service_name: mgr
service_type: mgr
---
[...]
Suggerimento
Suggerimento

È possibile aggiungere l'opzione --format per modificare il formato di output yaml di default. È possibile scegliere tra json, json-pretty o yaml. Esempio: 

ceph orch ls --export --format json

5.4.3 Distribuzione dei servizi Ceph

 

Una volta che il cluster di base è in esecuzione, è possibile distribuire i servizi Ceph su nodi aggiuntivi.

5.4.3.1 Distribuzione di Ceph Monitor e Ceph Manager

 

Il cluster Ceph dispone di tre o cinque MON distribuiti su nodi diversi. Se nel cluster sono presenti cinque o più nodi, si consiglia di distribuire cinque MON. Come buona prassi, distribuire gli MGR sugli stessi nodi dei MON.

Importante
Importante: inclusione del MON di bootstrap

Durante la distribuzione dei MON e degli MGR, ricordarsi di includere il primo MON aggiunto durante la configurazione del cluster di base nella Sezione 5.3.2.5, «Specifica del primo nodo MON/MGR».

Per distribuire i MON, applicare la specifica seguente: 

service_type: mon
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
Nota
Nota

Se è necessario aggiungere un altro nodo, aggiungere il nome host allo stesso elenco YAML. Esempio: 

service_type: mon
placement:
 hosts:
 - ses-min1
 - ses-min2
 - ses-min3
 - ses-min4

Analogamente, per distribuire gli MGR, applicare la specifica seguente:

Importante
Importante

Assicurarsi che per ogni distribuzione siano presenti almeno tre Ceph Manager. 

service_type: mgr
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
Suggerimento
Suggerimento

Se i MON o gli MGR non si trovano sulla stessa sottorete, è necessario aggiungere gli indirizzi delle sottoreti. Esempio: 

service_type: mon
placement:
  hosts:
  - ses-min1:10.1.2.0/24
  - ses-min2:10.1.5.0/24
  - ses-min3:10.1.10.0/24

5.4.3.2 Distribuzione dei Ceph OSD

 
Importante
Importante: se è disponibile un dispositivo di memorizzazione

Un dispositivo di memorizzazione è considerato disponibile se sono rispettate tutte le condizioni seguenti:

  • Il dispositivo non dispone di partizioni.

  • Il dispositivo non dispone di alcuno stato LVM.

  • Il dispositivo non è montato.

  • Il dispositivo non contiene un file system.

  • Il dispositivo non contiene un OSD BlueStore.

  • Il dispositivo ha una capacità maggiore di 5 GB.

Se le condizioni elencate sopra non sono rispettate, Ceph rifiuterà di eseguire il provisioning di questi OSD.

È possibile distribuire gli OSD in due modi:

  • Inviare a Ceph l'istruzione di utilizzare tutti i dispositivi di memorizzazione disponibili e non in uso: 

    cephuser@adm > ceph orch apply osd --all-available-devices

  • Utilizzare i DriveGroups (vedere Sezione 13.4.3, «Aggiunta di OSD tramite la specifica dei DriveGroups») per creare una specifica OSD in cui sono descritti i dispositivi che verranno distribuiti in base alle relative proprietà, come il tipo di dispositivo (SSD o HDD), i nomi di modello, le dimensioni o i nodi su cui si trovano tali dispositivi. Quindi, applicare la specifica eseguendo il comando seguente: 

    cephuser@adm > ceph orch apply osd -i drive_groups.yml

5.4.3.3 Distribuzione dei Metadata Server

 

Per CephFS sono necessari uno o più servizi Metadata Server (MDS). Per creare un CephFS, creare innanzitutto dei server MDS applicando la specifica seguente:

Nota
Nota

Assicurarsi di disporre di almeno due pool, uno per i dati e uno per i metadati di CephFS, creati prima dell'applicazione della seguente specifica. 

service_type: mds
service_id: CEPHFS_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3

Una volta che gli MDS saranno in funzione, creare il CephFS: 

ceph fs new CEPHFS_NAME metadata_pool data_pool

5.4.3.4 Distribuzione degli Object Gateway

 

cephadm distribuisce gli Object Gateway sotto forma di raccolta di daemon che gestiscono un dominio e una zona specifici.

È possibile correlare un servizio Object Gateway a un dominio e a una zona già esistenti (fare riferimento a Sezione 21.13, «Object Gateway multisito» per ulteriori dettagli) oppure specificare un nome per un dominio e una zona non esistenti (REALM_NAME e ZONE_NAME), che verranno creati automaticamente in seguito all'applicazione della configurazione seguente: 

service_type: rgw
service_id: REALM_NAME.ZONE_NAME
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  rgw_realm: RGW_REALM
  rgw_zone: RGW_ZONE
5.4.3.4.1 Uso dell'accesso SSL sicuro
 

Per utilizzare una connessione SSL sicura a Object Gateway, è necessaria una coppia di file di chiave e certificato SSL validi (vedere Sezione 21.7, «Abilitazione di HTTPS/SSL per gli Object Gateway» per ulteriori dettagli). È necessario abilitare SSL, specificare un numero di porta per le connessioni SSL e i file di chiave e certificato SSL.

Per abilitare SSL e specificare il numero di porta, includere quanto segue nella specifica: 

spec:
  ssl: true
  rgw_frontend_port: 443

Per specificare la chiave e il certificato SSL, è possibile incollarne i contenuti direttamente nel file della specifica YAML. Il simbolo della barra verticale (|) alla fine della riga indica al parser che il valore sarà una stringa con più righe. Esempio: 

spec:
  ssl: true
  rgw_frontend_port: 443
  rgw_frontend_ssl_certificate: |
   -----BEGIN CERTIFICATE-----
   MIIFmjCCA4KgAwIBAgIJAIZ2n35bmwXTMA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNV
   BAYTAkFVMQwwCgYDVQQIDANOU1cxHTAbBgNVBAoMFEV4YW1wbGUgUkdXIFNTTCBp
   [...]
   -----END CERTIFICATE-----
   rgw_frontend_ssl_key: |
   -----BEGIN PRIVATE KEY-----
   MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQDLtFwg6LLl2j4Z
   BDV+iL4AO7VZ9KbmWIt37Ml2W6y2YeKX3Qwf+3eBz7TVHR1dm6iPpCpqpQjXUsT9
   [...]
   -----END PRIVATE KEY-----
Suggerimento
Suggerimento

Invece di incollare il contenuto dei file di chiave e certificato SSL, è possibile omettere le parole chiave rgw_frontend_ssl_certificate: e rgw_frontend_ssl_key: ed effettuarne l'upload nel database di configurazione: 

cephuser@adm > ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.crt \
 -i SSL_CERT_FILE
cephuser@adm > ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.key \
 -i SSL_KEY_FILE
5.4.3.4.2 Distribuzione con un sottocluster
 

I sottocluster aiutano a organizzare i nodi nei cluster per isolare i workload e semplificare il ridimensionamento elastico. Per le distribuzioni con un sottocluster, applicare la configurazione seguente: 

service_type: rgw
service_id: REALM_NAME.ZONE_NAME.SUBCLUSTER
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  rgw_realm: RGW_REALM
  rgw_zone: RGW_ZONE
  subcluster: SUBCLUSTER

5.4.3.5 Distribuzione di iSCSI Gateway

 

cephadm esegue la distribuzione di iSCSI Gateway, ovvero un protocollo di rete dell'area di memorizzazione (SAN) che consente ai client (denominati iniziatori) di inviare comandi SCSI ai dispositivi di memorizzazione SCSI (destinazioni) su server remoti.

Applicare la configurazione seguente per eseguire la distribuzione. Assicurarsi che trusted_ip_list contenga gli indirizzi IP di tutti i nodi iSCSI Gateway e Ceph Manager (vedere l'output di esempio di seguito).

Nota
Nota

Assicurarsi che il pool sia stato creato prima di applicare la specifica seguente. 

service_type: iscsi
service_id: EXAMPLE_ISCSI
placement:
  hosts:
  - ses-min1
  - ses-min2
  - ses-min3
spec:
  pool: EXAMPLE_POOL
  api_user: EXAMPLE_USER
  api_password: EXAMPLE_PASSWORD
  trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2"
Nota
Nota

Assicurarsi che negli IP elencati per trusted_ip_list non sia presente uno spazio dopo la virgola di separazione.

5.4.3.5.1 Configurazione SSL sicura
 

Per utilizzare una connessione SSL sicura tra il Ceph Dashboard e l'API della destinazione iSCSI, è necessaria una coppia di file di chiave e certificato SSL validi, emessi da un'autorità di certificazione o autofirmati (vedere Sezione 10.1.1, «Creazione di certificati autofirmati»). Per abilitare SSL, includere l'impostazione api_secure: true nel file della specifica: 

spec:
  api_secure: true

Per specificare la chiave e il certificato SSL, è possibile incollarne i contenuti direttamente nel file della specifica YAML. Il simbolo della barra verticale (|) alla fine della riga indica al parser che il valore sarà una stringa con più righe. Esempio: 

spec:
  pool: EXAMPLE_POOL
  api_user: EXAMPLE_USER
  api_password: EXAMPLE_PASSWORD
  trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2"
  api_secure: true
  ssl_cert: |
    -----BEGIN CERTIFICATE-----
    MIIDtTCCAp2gAwIBAgIYMC4xNzc1NDQxNjEzMzc2MjMyXzxvQ7EcMA0GCSqGSIb3
    DQEBCwUAMG0xCzAJBgNVBAYTAlVTMQ0wCwYDVQQIDARVdGFoMRcwFQYDVQQHDA5T
    [...]
    -----END CERTIFICATE-----
  ssl_key: |
    -----BEGIN PRIVATE KEY-----
    MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5jdYbjtNTAKW4
    /CwQr/7wOiLGzVxChn3mmCIF3DwbL/qvTFTX2d8bDf6LjGwLYloXHscRfxszX/4h
    [...]
    -----END PRIVATE KEY-----

5.4.3.6 Distribuzione di NFS Ganesha

 

cephadm esegue la distribuzione di NFS Ganesha tramite un pool RADOS predefinito e uno spazio dei nomi facoltativo. Per distribuire NFS Ganesha, applicare la specifica seguente:

Nota
Nota

Se non è presente un pool RADOS predefinito, l'operazione ceph orch apply non andrà a buon fine. Per ulteriori informazioni sulla creazione di un pool, vedere Sezione 18.1, «Creazione di un pool». 

service_type: nfs
service_id: EXAMPLE_NFS
placement:
  hosts:
  - ses-min1
  - ses-min2
spec:
  pool: EXAMPLE_POOL
  namespace: EXAMPLE_NAMESPACE

  • EXAMPLE_NFS con una stringa arbitraria che identifica l'esportazione NFS.

  • EXAMPLE_POOL con il nome del pool in cui verrà archiviato l'oggetto di configurazione RADOS di NFS Ganesha.

  • EXAMPLE_NAMESPACE (facoltativo) con lo spazio dei nomi NFS di Object Gateway desiderato (ad esempio, ganesha).

5.4.3.7 Distribuzione di rbd-mirror

 

Il servizio rbd-mirror sincronizza le immagini del dispositivo di blocco RADOS (RADOS Block Device, RBD) tra due cluster Ceph (per ulteriori dettagli, vedere Sezione 20.4, «Copie speculari delle immagini RBD»). Per distribuire rbd-mirror, utilizzare la specifica seguente: 

service_type: rbd-mirror
service_id: EXAMPLE_RBD_MIRROR
placement:
  hosts:
  - ses-min3

5.4.3.8 Distribuzione dello stack di monitoraggio

 

Lo stack di monitoraggio è composto da Prometheus e dalle relative utilità di esportazione, da Prometheus Alertmanager e da Grafana. Il Ceph Dashboard utilizza questi componenti per archiviare e visualizzare metriche dettagliate sull'utilizzo e le prestazioni del cluster.

Suggerimento
Suggerimento

Se per la distribuzione sono necessarie immagini del container personalizzate o fornite in locale dei servizi dello stack di monitoraggio, fare riferimento a Sezione 16.1, «Configurazione di immagini personalizzate o locali».

Per distribuire lo stack di monitoraggio, seguire la procedura indicata di seguito:

  1. Abilitare il modulo prometheus nel daemon Ceph Manager. Questa operazione espone le metriche Ceph interne per consentirne la lettura da parte di Prometheus. 

    cephuser@adm > ceph mgr module enable prometheus
    Nota
    Nota

    Assicurarsi di eseguire questo comando prima di procedere con la distribuzione di Prometheus. Altrimenti, occorrerà ripetere la distribuzione di Prometheus per aggiornarne la configurazione: 

    cephuser@adm > ceph orch redeploy prometheus

  2. Creare un file della specifica (ad esempio monitoring.yaml) con un contenuto simile al seguente: 

    service_type: prometheus
placement:
  hosts:
  - ses-min2
---
service_type: node-exporter
---
service_type: alertmanager
placement:
  hosts:
  - ses-min4
---
service_type: grafana
placement:
  hosts:
  - ses-min3

  3. Applicare i servizi di monitoraggio eseguendo: 

    cephuser@adm > ceph orch apply -i monitoring.yaml

    Per il completamento della distribuzione dei servizi di monitoraggio potrebbero essere necessari alcuni istanti.

Importante
Importante

Se la distribuzione viene eseguita come descritto sopra, la comunicazione reciproca tra Prometheus, Grafana e il Ceph Dashboard è configurata automaticamente, per un'integrazione Grafana completamente funzionante nel Ceph Dashboard.

L'unica eccezione a questa regola è costituita dal monitoraggio con le immagini RBD. Consultare Sezione 16.5.4, «Abilitazione del monitoraggio dell'immagine RBD» per maggiori informazioni.