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.1 / Guida alla distribuzione / Distribuzione del cluster Ceph / Distribuzione dei rimanenti servizi di base mediante cephadm
Si applica a SUSE Enterprise Storage 7.1

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

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 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 a Sezione 8.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 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
---
[...]
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

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.

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

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

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:

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

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

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

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.

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

Importante
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
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).

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.

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.