8 Distribuzione dei rimanenti servizi di base mediante cephadm #
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
).
8.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.
8.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
8.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
[...]
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
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
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 0cephuser@adm >
ceph orch ps --daemon_type mds --daemon_id my_cephfs
8.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.
8.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
orbd-mirror
), di un gateway (nfs
orgw
) o di parte dello stack di monitoraggio (alertmanager
,grafana
,node-exporter
oprometheus
).service_id
Il nome del servizio. Per le specifiche del tipo
mon
,mgr
,alertmanager
,grafana
,node-exporter
eprometheus
non è necessaria la proprietàservice_id
.placement
Specifica quali nodi eseguiranno il servizio. Per ulteriori dettagli, fare riferimento a Sezione 8.2.2, «Creazione della specifica di posizionamento».
spec
Ulteriore specifica pertinente al tipo di servizio.
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 8.3, «Distribuzione dei servizi Ceph».
8.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
[...]
8.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 8.1.1, «Visualizzazione dello stato dell'utilità di coordinamento».
8.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 8.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
---
[...]
È 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
8.3 Distribuzione dei servizi Ceph #
Una volta che il cluster di base è in esecuzione, è possibile distribuire i servizi Ceph su nodi aggiuntivi.
8.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.
Durante la distribuzione dei MON e degli MGR, ricordarsi di includere il primo MON aggiunto durante la configurazione del cluster di base nella Sezione 7.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
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:
Assicurarsi che per ogni distribuzione siano presenti almeno tre Ceph Manager.
service_type: mgr placement: hosts: - ses-min1 - ses-min2 - ses-min3
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
8.3.2 Distribuzione dei Ceph OSD #
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-devicesUtilizzare 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
8.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:
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
8.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
8.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-----
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_FILEcephuser@adm >
ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.key \ -i SSL_KEY_FILE
8.3.4.1.1 Configurazione dell'Object Gateway per l'ascolto su entrambe le porte 443 e 80 #
Per configurare l'Object Gateway per l'ascolto su entrambe le porte 443 (HTTPS) e 80 (HTTP), seguire la procedura indicata di seguito:
I comandi della procedura utilizzano i valori di default
per dominio e zona.
Distribuire l'Object Gateway fornendo un file della specifica. Per ulteriori dettagli sulla specifica dell'Object Gateway, fare riferimento alla Sezione 8.3.4, «Distribuzione degli Object Gateway». Utilizzare il seguente comando:
cephuser@adm >
ceph orch apply -i SPEC_FILESe nel file della specifica non sono forniti i certificati SSL, aggiungerli utilizzando il seguente comando:
cephuser@adm >
ceph config-key set rgw/cert/default/default.crt -i certificate.pemcephuser@adm >
ceph config-key set rgw/cert/default/default.key -i key.pemModificare il valore di default dell'opzione
rgw_frontends
:cephuser@adm >
ceph config set client.rgw.default.default rgw_frontends \ "beast port=80 ssl_port=443"Rimuovere la configurazione specifica creata da cephadm. Identificare per quale destinazione è stata configurata l'opzione
rgw_frontends
eseguendo il comando:cephuser@adm >
ceph config dump | grep rgwAd esempio, la destinazione è
client.rgw.default.default.node4.yiewdu
. Rimuovere lo specifico valorergw_frontends
corrente:cephuser@adm >
ceph config rm client.rgw.default.default.node4.yiewdu rgw_frontendsSuggerimentoAnziché rimuovere un valore per
rgw_frontends
, è possibile specificarlo. Ad esempio:cephuser@adm >
ceph config set client.rgw.default.default.node4.yiewdu \ rgw_frontends "beast port=80 ssl_port=443"Riavviare gli Object Gateway:
cephuser@adm >
ceph orch restart rgw.default.default
8.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
8.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).
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"
Assicurarsi che negli IP elencati per trusted_ip_list
non sia presente uno spazio dopo la virgola di separazione.
8.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-----
8.3.6 Distribuzione di NFS Ganesha #
NFS Ganesha supporta NFS versione 4.1 e versioni successive. Non supporta NFS versione 3.
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:
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
).
8.3.7 Distribuzione 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
8.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.
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:
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 prometheusNotaAssicurarsi 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 prometheusCreare 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
Applicare i servizi di monitoraggio eseguendo:
cephuser@adm >
ceph orch apply -i monitoring.yamlPer il completamento della distribuzione dei servizi di monitoraggio potrebbero essere necessari alcuni istanti.
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.