8 Distribuzione dei rimanenti servizi di base mediante cephadm #

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

cephuser@adm > ceph orch status

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

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

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

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

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 8.3, «Distribuzione dei servizi Ceph».

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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:

Nota

I comandi della procedura utilizzano i valori di default per dominio e zona.

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

2. Se 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.pem
   cephuser@adm > ceph config-key set rgw/cert/default/default.key -i key.pem

3. Modificare 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"

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

   Ad esempio, la destinazione è client.rgw.default.default.node4.yiewdu. Rimuovere lo specifico valore rgw_frontends corrente:

   cephuser@adm > ceph config rm client.rgw.default.default.node4.yiewdu rgw_frontends

   

   Suggerimento

   Anziché 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"

5. Riavviare gli Object Gateway:

   cephuser@adm > ceph orch restart rgw.default.default

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

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

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

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

spec:
  api_secure: true

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

Importante

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:

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

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

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

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:

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.