Il componente base di Ceph è denominato RADOS (Reliable Autonomic Distributed Object Store), responsabile per la gestione dei dati memorizzati nel cluster. I dati in Ceph vengono in genere memorizzati come oggetti. Ciascun oggetto consiste di un identificativo e dai dati.

RADOS fornisce i seguenti metodi di accesso agli oggetti memorizzati che riguardano molti casi d'uso:

librados è utilizzata da Object Gateway e RBD mentre CephFS si interfaccia direttamente con RADOS Figura 1.1, «Interfacce con l'archivio dati Ceph».

Figura 1.1: Interfacce con l'archivio dati Ceph #

 

Il core del cluster Ceph è l'algoritmo CRUSH. CRUSH è l'acronimo di Controlled Replication Under Scalable Hashing. CRUSH è una funzione che gestisce l'allocazione dello storage e richiede comparabilmente pochi parametri. Ciò significa che è necessaria solo una piccola quantità di dati per calcolare la posizione di storage di un oggetto. I parametri sono una mappa corrente del cluster comprendente lo stato, alcune regole di posizionamento definite dall'amministratore e il nome dell'oggetto che deve essere memorizzato o recuperato. Con questi dati, tutti i nodi nel cluster Ceph sono in grado di calcolare dove si trova un oggetto e le sue repliche. Ciò rende la scrittura o la lettura dei dati molto efficace. CRUSH tenta di distribuire in modo uniforme i dati tra tutti i nodi nel cluster.

La mappa CRUSH contiene tutti i nodi di storage e le regole di posizionamento definite dall'amministratore per la memorizzazione degli oggetti nel cluster e definisce una struttura gerarchica che di solito corrisponde alla struttura fisica del cluster. Ad esempio, i dischi contenenti i dati sono negli host, gli host sono nei rack, i rack in righe e le righe nei data center. È possibile utilizzare questa struttura per definire i domini di guasto. Ceph quindi garantisce che le repliche vengano memorizzate su diverse diramazioni di uno specifico dominio di guasto.

Se il dominio di guasto è configurato su un rack, le repliche degli oggetti sono distribuite su diversi rack. Ciò può ridurre le perdite provocate da un errore di commutazione in un rack. Se un'unità di distribuzione alimentazione alimenta una riga di rack, il dominio di guasto può essere configurato su una riga. In caso di errore dell'unità di distribuzione di alimentazione, i dati replicati sono sempre disponibili su altre righe.

In Ceph, i nodi sono server che lavorano per il cluster e possono eseguire diversi tipi di daemon. Si consiglia di eseguire solo un tipo di daemon in ogni nodo, tranne per i daemon Ceph Manager che possono essere co-ubicati con i Ceph Monitor. Per ogni cluster sono necessari almeno i daemon Ceph Monitor, Ceph Manager e Ceph OSD:

Per utilizzare CephFS, Object Gateway, NFS Ganesha o iSCSI Gateway, sono richiesti nodi aggiuntivi:

Gli oggetti memorizzati in un cluster Ceph vengono posti nei pool. I pool rappresentano le partizioni logiche del cluster per l'esterno. Per ogni pool è possibile definire un set di regole, ad esempio quante repliche di ogni oggetto devono esistere. La configurazione standard dei pool è denominata pool replicato.

I pool in genere contengono oggetti, ma è possibile configurarli anche per funzionare come RAID 5. In questa configurazione, gli oggetti vengono memorizzati in chunk insieme con i chunk di codifica aggiuntivi. I chunk di codifica contengono i dati ridondanti. Il numero di dati e chunk di codifica può essere definito dall'amministratore. In questa configurazione, i pool sono denominati pool con codice di cancellazione o pool EC.

I gruppi di posizionamento (PG) sono utilizzati per la distribuzione dei dati in un pool. Quando si crea un pool, viene impostato un determinato numero di gruppi di posizionamento. I gruppi di posizionamento sono utilizzati internamente per raggruppare gli oggetti e sono un fattore importante per le prestazioni di un cluster Ceph. Il PG di un oggetto è determinato dal nome dell'oggetto.

Questa sezione fornisce un esempio semplificato della gestione dati di Ceph (vedere Figura 1.2, «Esempio di Ceph su piccola scala»). Questo esempio non rappresenta una configurazione consigliata per un cluster Ceph. La configurazione hardware consiste di tre nodi di storage Ceph OSD (Host 1, Host 2, Host 3). Ogni nodo ha tre dischi rigidi utilizzati come OSD (da osd.1 a osd.9). In questo esempio, vengono tralasciati i nodi Ceph Monitor.

Nota: differenza tra Ceph OSD e OSD

Mentre Ceph OSD o daemon Ceph OSD si riferisce a un daemon eseguito su un nodo, il termine OSD si riferisce al disco logico con cui interagisce il daemon.

Il cluster ha due pool, Pool A e Pool B. Mentre il Pool A replica gli oggetti solo due volte, la resilienza per Pool B è più importante e ha tre repliche per ogni oggetto.

Quando un'applicazione mette un oggetto in un pool, ad esempio tramite la API REST, un Gruppo di posizionamento (da PG1 a PG4) viene selezionato in base a pool e nome oggetto. L'algoritmo CRUSH calcola quindi su quali OSD viene memorizzato l'oggetto, in base al Gruppo di posizionamento contenente l'oggetto.

In questo esempio, il dominio di guasto è impostato sull'host. Ciò garantisce che le repliche degli oggetti siano memorizzate su diversi host. In base al livello di replica impostato per un pool, l'oggetto viene memorizzato su due o tre OSD utilizzati dal Gruppo di posizionamento.

Un'applicazione che scrive un oggetto interagisce solo con un Ceph OSD, il Ceph OSD primario. Il Ceph OSD primario si occupa della replica e conferma il completamento del processo di scrittura dopo che tutti gli altri OSD hanno memorizzato l'oggetto.

In caso di errore di osd.5, tutti gli oggetti in PG1 sono ancora disponibili su osd.1. Non appena il cluster riconosce l'errore di un OSD, un altro OSD lo sostituisce. In questo esempio osd.4 viene utilizzato come sostituzione per osd.5. Gli oggetti memorizzati su osd.1 vengono quindi replicati su osd.4 per ripristinare il livello di replica.

Figura 1.2: Esempio di Ceph su piccola scala #

 

Se si aggiunge al cluster un nuovo nodo con nuovi OSD, la mappa del cluster cambia. La funzione CRUSH restituisce quindi diverse ubicazioni per gli oggetti. Gli oggetti che ricevono nuove ubicazioni vengono riposizionati. Questo processo determina un uso bilanciato di tutti gli OSD.

Si consiglia di utilizzare una singola rete a tolleranza di errore con larghezza di banda sufficiente per soddisfare i propri requisiti. Per l'ambiente di rete pubblica Ceph, si consigliano due interfacce di rete associate da 25 GbE (o più veloci) associate tramite 802.3ad (LACP). Questa è considerata come la configurazione di base di Ceph. Se si utilizza anche una rete di cluster, si consigliano quattro interfacce di rete associate da 25 GbE. L'associazione di due o più interfacce di rete offre migliore velocità effettiva tramite l'aggregazione dei collegamenti e, in caso di collegamenti e switch ridondanti, maggiore tolleranza agli errori e gestibilità.

È possibile inoltre creare VLAN per isolare diversi tipi di traffico su un'associazione. Ad esempio, è possibile creare un'associazione per fornire due interfacce VLAN, una per la rete pubblica e una per la rete di cluster. Tuttavia, ciò non è necessario durante la configurazione delle reti Ceph. All'indirizzo https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-network.html#sec-network-iface-bonding sono disponibili ulteriori dettagli sull'associazione delle interfacce.

Isolando i componenti nei domini di errore, si aumenta la tolleranza agli errori. Per ottenere una maggiore tolleranza agli errori della rete, è possibile associare un'interfaccia a due NIC (Network Interface Card) separate, qualora si verificasse un errore su una. Analogamente, associare due switch diversi fornisce maggiore protezione, nel caso si verificasse un errore su uno. Rivolgersi al fornitore delle apparecchiature di rete per impostare il livello adeguato di tolleranza agli errori.

Importante: rete di amministrazione non supportata

La configurazione della rete di amministrazione aggiuntiva, che consente ad esempio la separazione delle reti SSH, Salt o DNS, non è né testata né supportata.

Suggerimento: nodi configurati tramite DHCP

Se i nodi di storage sono configurati tramite DHCP, i timeout default possono non essere sufficienti per configurare correttamente la rete prima dell'avvio dei vari daemon Ceph. Se ciò avviene, i Ceph MON e OSD non si avvieranno in modo corretto (l'esecuzione di systemctl status ceph\* genererà errori di associazione). Per evitare questo problema, si consiglia di aumentare il timeout del client DHCP ad almeno 30 secondi su ciascun nodo nel cluster di memorizzazione. È possibile fare questo modificando le impostazioni seguenti su ogni nodo:

In /etc/sysconfig/network/dhcp, impostare

DHCLIENT_WAIT_AT_BOOT="30"

In /etc/sysconfig/network/config, impostare

WAIT_FOR_INTERFACES="60"

2.1.1.2 Nodi di monitoraggio su sottoreti diverse #

 

Se i nodi monitor sono su sottoreti diverse, ad esempio si trovano in stanze diverse e sono serviti da switch differenti, occorre specificare l'indirizzo di rete pubblica nella notazione CIDR:

cephuser@adm > ceph config set mon public_network "MON_NETWORK_1, MON_NETWORK_2, MON_NETWORK_N

Esempio:

cephuser@adm > ceph config set mon public_network "192.168.1.0/24, 10.10.0.0/16"

Avvertimento

Se si specifica più di un segmento di rete per la rete pubblica (o di cluster) come descritto in questa sezione, ciascuna di queste sottoreti deve essere in grado di eseguire l'instradamento a tutte le altre, altrimenti i MON e gli altri daemon Ceph su segmenti di rete diversi non potranno comunicare e verrà generato un cluster suddiviso. Inoltre, se si utilizza un firewall, assicurarsi di includere ogni indirizzo IP o sottorete nelle iptables e aprire le porte per questi ultimi su tutti i nodi in base alle esigenze.

La configurazione minima del cluster è costituita da:

La configurazione dettagliata prevede:

Figura 2.2: Configurazione minima del cluster #

 

Con la crescita del cluster, si consiglia di ricollocare i Ceph Monitor, i Metadata Server e i gateway per separare i nodi e ottenere una maggiore tolleranza agli errori.

Se si desidera utilizzare l'hardware multipath, assicurarsi che LVM visualizzi multipath_component_detection = 1 nella sezione devices del file di configurazione. È possibile verificare questa istruzione tramite il comando lvm config.

In alternativa, assicurarsi che LVM filtri i componenti mpath di un dispositivo tramite la configurazione di filtro LVM. Si tratta di un'impostazione specifica per l'host.

Nota

Questa procedura non è consigliata e deve essere presa in considerazione soltanto se non è possibile impostare multipath_component_detection = 1.

Per ulteriori informazioni sulla configurazione multipath, vedere https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-multipath.html#sec-multipath-lvm.

Vi sono due tipi di spazi su disco necessari per l'esecuzione su OSD: lo spazio per il dispositivo WAL/DB e lo spazio primario per i dati memorizzati. Il valore minimo (e di default) per il dispositivo WAL/DB è 6 GB. Lo spazio minimo per i dati è pari a 5 GB, in quanto a partizioni più piccole di 5 GB viene assegnato automaticamente il peso di 0.

Perciò, sebbene lo spazio minimo su disco per un OSD sia 11 GB, si sconsigliano dischi inferiori a 20 GB, anche per scopi di test.

Le unità a stato solido (SSD) non hanno parti in movimento. Ciò riduce il tempo di accesso casuale e la latenza di lettura accelerando il throughput dei dati. Poiché il loro prezzo per 1MB è sensibilmente maggiore rispetto al prezzo dei dischi rigidi classici, le SSD sono adatte solo per storage di piccole dimensioni.

Gli OSD possono avere un significativo miglioramento delle prestazioni grazie alla memorizzazione delle relative partizioni WAL/DB su un disco SSD e dei dati oggetto su un disco rigido separato.

Suggerimento: condivisione di un disco SSD con più partizioni WAL/DB

Dal momento che le partizioni WAL/DB occupano relativamente poco spazio, è possibile condividere un disco SSD con più partizioni WAL/DB. Tenere presente che con ogni partizione WAL/DB, le prestazioni del disco SSD diminuiscono. Si consiglia di non condividere più di sei partizioni WAL/DB sullo stesso disco SSD e 12 sui dischi NVMe.

Il server può contenere tutti i dischi consentiti. Quando si pianifica il numero di dischi per server, vi sono alcuni elementi da tenere presente:

SUSE Manager e SUSE Enterprise Storage non sono integrati, perciò SUSE Manager non è in grado attualmente di gestire un cluster SES.

Se si esegue config senza alcun percorso o sottocomando, viene creata una shell ceph-saltceph-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 ceph-saltls di , la configurazione del cluster presenta una struttura ad albero. Sono disponibili due opzioni per configurare una proprietà specifica del cluster nella shell ceph-salt:

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

Includere nella configurazione del cluster Ceph tutti o un sottoinsieme di Salt Minion distribuiti e accettati nella Capitolo 6, 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]

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

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

È 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

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

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.

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]

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:

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-SP3/html/SLES-all/cha-ntp.html#sec-ntp-yast sono disponibili ulteriori informazioni sulla configurazione della sincronizzazione dell'orario.

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

Il cluster Ceph deve avere accesso a un registro del container per poter effettuare il download e la distribuzione dei servizi Ceph in container. Sono previsti due modi per accedere al registro:

7.2.10.1 Creazione e configurazione del registro locale (facoltativo) #

 

Importante

Esistono diversi metodi per creare un registro locale. Le istruzioni fornite in questa sezione sono esempi di creazione di registri sicuri e non sicuri. Per informazioni generali sull'esecuzione di un registro delle immagini del container, fare riferimento a https://documentation.suse.com/sles/15-SP3/single-html/SLES-container/#sec-docker-registry-installation.

Suggerimento: posizionamento e utilizzo della porta

Distribuire il registro su un computer accessibile da tutti i nodi del cluster. Si consiglia di utilizzare il nodo admin. Per default, il registro resta in ascolto sulla porta 5000.

Sul nodo del registro, utilizzare il seguente comando per assicurarsi che la porta sia libera:

ss -tulpn | grep :5000

Se altri processi (come iscsi-tcmu) sono già in ascolto sulla porta 5000, individuare un'altra porta libera utilizzabile per mappare la porta 5000 nel container del registro.

Procedura 7.1: creazione del registro locale #

 

1. Verificare che l'estensione Containers Module sia abilitata:

   > SUSEConnect --list-extensions | grep -A2 "Containers Module"
   Containers Module 15 SP3 x86_64 (Activated)

2. Verificare che i seguenti pacchetti siano installati: apache2-utils (se si abilita un registro sicuro), cni, cni-plugins, podman, podman-cni-config e skopeo.

3. Recuperare le seguenti informazioni:

   • Il nome di dominio completo dell'host del registro (REG_HOST_FQDN).

   • Un numero di porta disponibile utilizzabile per mappare la porta 5000 del container del registro (REG_HOST_PORT).

   • Se il registro sarà sicuro o non sicuro (insecure=[true|false]).

4. Per avviare un registro non sicuro (senza cifratura SSL), seguire la procedura indicata di seguito:

   1. Configurare ceph-salt per il registro non sicuro:

      cephuser@adm > ceph-salt config containers/registries_conf enable
      cephuser@adm > ceph-salt config containers/registries_conf/registries \
       add prefix=REG_HOST_FQDN insecure=true \
       location=REG_HOST_PORT:5000

   2. Avviare il registro non sicuro creando la directory necessaria (ad esempio, /var/lib/registry) e avviando il registro con il comando podman:

      # mkdir -p /var/lib/registry
      # podman run --privileged -d --name registry \
       -p REG_HOST_PORT:5000 -v /var/lib/registry:/var/lib/registry \
       --restart=always registry:2

   3. Per avviare il registro dopo un riavvio, creare un file di unità systemd per il registro e abilitarlo:

      > sudo podman generate systemd --files --name registry
      > sudo mv container-registry.service /etc/systemd/system/
      > sudo systemctl enable container-registry.service

5. Per avviare un registro sicuro, seguire la procedura indicata di seguito:

   1. Creare le directory necessarie:

      # mkdir -p /var/lib/registry/{auth,certs}

   2. Generare un certificato SSL:

      # openssl req -newkey rsa:4096 -nodes -sha256 \
       -keyout /var/lib/registry/certs/domain.key -x509 -days 365 \
       -out /var/lib/registry/certs/domain.crt

      

      Nota

      Impostare il valore di CN=[value] sul nome di dominio completo dell'host ([REG_HOST_FQDN]).

   3. Copiare il certificato su tutti i nodi del cluster e aggiornare la cache del certificato:

      # salt-cp '*' /var/lib/registry/certs/domain.crt \
       /etc/pki/trust/anchors/
      # salt '*' cmd.shell "update-ca-certificates"

   4. Generare una combinazione di nome utente e password per l'autenticazione al registro:

      # htpasswd2 -bBc /var/lib/registry/auth/htpasswd \
       REG_USERNAME REG_PASSWORD

   5. Avviare il registro sicuro. Utilizzare il flag REGISTRY_STORAGE_DELETE_ENABLED=true per poter eliminare in seguito le immagini con il comando skopeo delete.

      podman run --name myregistry -p REG_HOST_PORT:5000 \
       -v /var/lib/registry:/var/lib/registry \
       -v /var/lib/registry/auth:/auth:z \
       -e "REGISTRY_AUTH=htpasswd" \
       -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
       -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
       -v /var/lib/registry/certs:/certs:z \
       -e "REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt" \
       -e "REGISTRY_HTTP_TLS_KEY=/certs/domain.key" \
       -e REGISTRY_STORAGE_DELETE_ENABLED=true \
       -e REGISTRY_COMPATIBILITY_SCHEMA1_ENABLED=true -d registry:2

   6. Effettuare un test dell'accesso sicuro al registro:

      > curl https://REG_HOST_FQDN:REG_HOST_PORT/v2/_catalog \
       -u REG_USERNAME:REG_PASSWORD

6. Dopo aver creato il registro locale, è necessario sincronizzare le immagini del container dal registro ufficiale SUSE, disponibile all'indirizzo registry.suse.com con quello locale. A tale scopo, è possibile utilizzare il comando skopeo sync disponibile nel pacchetto skopeo. Per ulteriori dettagli, fare riferimento alla documentazione (man 1 skopeo-sync). Si considerino i seguenti esempi:

   Esempio 7.1: visualizzazione dei file manifest #

    

   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/ceph | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/grafana | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/prometheus-server:2.32.1 | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/prometheus-node-exporter:1.1.2 | jq .RepoTags
   skopeo inspect docker://registry.suse.com/ses/7.1/ceph/prometheus-alertmanager:0.21.0 | jq .RepoTags

   Esempio 7.2: sincronizzazione con una directory #

    

   Sincronizzare tutte le immagini Ceph:

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/ceph /root/images/

   Sincronizzare solo le immagini più recenti:

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/ceph:latest /root/images/

   Esempio 7.3: sincronizzazione delle immagini Grafana: #

    

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/grafana /root/images/

   Sincronizzare solo le immagini Grafana più recenti:

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/grafana:latest /root/images/

   Esempio 7.4: sincronizzazione delle immagini Prometheus più recenti #

    

   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/prometheus-server:2.32.1 /root/images/
   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/prometheus-node-exporter:1.1.2 /root/images/
   skopeo sync --src docker --dest dir registry.suse.com/ses/7.1/ceph/prometheus-alertmanager:0.21.0 /root/images/

Procedura 7.2: configurazione del registro locale e delle credenziali di accesso #

 

1. Configurare l'URL del registro locale:

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

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

   cephuser@adm > ceph-salt config /containers/registry_auth/username set REG_USERNAME

   cephuser@adm > ceph-salt config /containers/registry_auth/password set REG_PASSWORD

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.

7.2.10.2 Configurazione del percorso alle immagini del container #

 

Importante

Questa sezione consente di configurare il percorso delle immagini del container del cluster di bootstrap (distribuzione della prima coppia Ceph Monitor e Ceph Manager). Il percorso non si applica alle immagini del container di servizi aggiuntivi, ad esempio dello stack di monitoraggio.

Suggerimento: configurazione del proxy HTTPS

Se è necessario utilizzare un proxy per comunicare con il server del registro del container, eseguire la seguente procedura di configurazione su tutti i nodi del cluster:

1. Copiare il file di configurazione per i container:

   > sudo cp /usr/share/containers/containers.conf /etc/containers/containers.conf

2. Modificare il file appena copiato e aggiungere l'impostazione http_proxy alla rispettiva sezione [engine]; ad esempio:

   > cat /etc/containers/containers.conf
    [engine]
    http_proxy=proxy.example.com
    [...]

È necessario che cephadm conosca un percorso URI valido per le immagini del container. Verificare l'impostazione di default eseguendo il comando:

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

Se non è necessario un registro locale o alternativo, specificare il registro del container SUSE di default:

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

Se la distribuzione richiede un percorso specifico, ad esempio un percorso a un registro locale, configurarlo nel modo seguente:

root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path set LOCAL_REGISTRY_PATH

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

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:

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

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

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

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

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

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.1/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: 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

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

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

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 Book “Guida all'amministrazione e alle operazioni”, Chapter 21 “Ceph Object Gateway”, Section 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 Book “Guida all'amministrazione e alle operazioni”, Chapter 21 “Ceph Object Gateway”, Section 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 Book “Guida all'amministrazione e alle operazioni”, Chapter 18 “Gestione dei pool di memorizzazione”, Section 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 Book “Guida all'amministrazione e alle operazioni”, Chapter 20 “Dispositivo di blocco RADOS (RADOS Block Device, RBD)”, Section 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 Book “Guida all'amministrazione e alle operazioni”, Chapter 16 “Monitoraggio e creazione di avvisi”, Section 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 Book “Guida all'amministrazione e alle operazioni”, Chapter 16 “Monitoraggio e creazione di avvisi”, Section 16.5.4 “Abilitazione del monitoraggio dell'immagine RBD” per maggiori informazioni.

iSCSI è un'implementazione del set di comandi Small Computer System Interface (SCSI) mediante il Protocollo Internet (IP), specificato in RFC 3720. iSCSI è implementato come servizio dove un client (l'iniziatore) parla a un server (la destinazione) tramite una sessione sulla porta TCP 3260. Una porta e un indirizzo IP della destinazione iSCSI sono denominati portale iSCSI, dove una destinazione può essere esposta attraverso uno o più portali. La combinazione di una destinazione e uno o più portali è detta gruppo portale di destinazione (target portal group, TPG).

Il protocollo dello strato collegamento dati sottostante per iSCSI è di solito Ethernet. Più specificamente, le moderne infrastrutture iSCSI utilizzano reti Ethernet 10 GigE o più veloci per una velocità effettiva ottimale. Si consiglia la connettività Ethernet 10 Gigabit tra iSCSI Gateway e il cluster Ceph back-end.

ceph-iscsi combina i vantaggi dei dispositivi di blocco RADOS con la versatilità diffusa di iSCSI. Impiegando ceph-iscsi su un host di destinazione iSCSI (noto come iSCSI Gateway), qualsiasi applicazione che deve utilizzare uno storage di blocco può trarre vantaggio da Ceph, anche se non utilizza alcun protocollo del client Ceph. Al contrario, gli utenti possono utilizzare iSCSI o un altro protocollo front-end di destinazione per collegarsi a una destinazione LIO che traduce tutti gli I/O di destinazione in operazioni di storage RBD.

Figura 9.1: Cluster Ceph con un singolo iSCSI Gateway #

 

ceph-iscsi è intrinsecamente a elevata disponibilità e supporta operazioni multipath. Perciò, gli host iniziatori a valle possono utilizzare più iSCSI Gateway per alta disponibilità e scalabilità. Quando si comunica con una configurazione iSCSI con più gateway, gli iniziatori possono bilanciare il carico delle richieste iSCSI tra più gateway. Nel caso in cui un gateway sia in errore, temporaneamente irraggiungibile o disattivato per manutenzione, gli I/O continueranno in modo trasparente attraverso un altro gateway.

Figura 9.2: Cluster Ceph con più iSCSI Gateway #

 

Una configurazione minima di SUSE Enterprise Storage 7.1 con ceph-iscsi contiene i componenti seguenti:

Una configurazione di produzione raccomandata di SUSE Enterprise Storage 7.1 con ceph-iscsi consiste di:

Questa sezione descrive i passaggi per installare e configurare un iSCSI Gateway su SUSE Enterprise Storage.

cephuser@adm > rbd --pool iscsi-images create --size=102400 testvol

9.1.4.3 Esportazione di immagini RBD tramite iSCSI #

 

Per esportare le immagini RBD tramite iSCSI, è possibile utilizzare l'interfaccia Web del Ceph Dashboard o l'utility gwcli ceph-iscsi. Questa sezione è incentrata esclusivamente su gwcli e illustra come creare una destinazione iSCSI in grado di esportare un'immagine RBD tramite la riga di comando.

Nota

Non è possibile esportare tramite iSCSI le immagini RBD con le proprietà seguenti:

• immagini con la funzione di journaling abilitata

• immagini con un'unità di striping inferiore a 4096 byte

Come root, immettere il container di iSCSI Gateway:

# cephadm enter --name CONTAINER_NAME

Da root, avviare l'interfaccia riga di comando di iSCSI Gateway:

# gwcli

Andare a iscsi-targets e creare una destinazione con il nome iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol:

gwcli >  /> cd /iscsi-targets
gwcli >  /iscsi-targets> create iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol

Creare gli iSCSI Gateway specificando il nome (name) e l'indirizzo ip del gateway:

gwcli >  /iscsi-targets> cd iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/gateways
gwcli >  /iscsi-target...tvol/gateways> create iscsi1 192.168.124.104
gwcli >  /iscsi-target...tvol/gateways> create iscsi2 192.168.124.105

Suggerimento

Utilizzare il comando help per visualizzare l'elenco dei comandi disponibili nel nodo di configurazione corrente.

Aggiungere l'immagine RBD denominata testvol nel pool iscsi-images:

gwcli >  /iscsi-target...tvol/gateways> cd /disks
gwcli >  /disks> attach iscsi-images/testvol

Mappare l'immagine RBD alla destinazione:

gwcli >  /disks> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/disks
gwcli >  /iscsi-target...testvol/disks> add iscsi-images/testvol

Nota

È possibile utilizzare strumenti di livello inferiore, come targetcli, per interrogare la configurazione locale, ma non per modificarla.

Suggerimento

È possibile utilizzare il comando ls per rivedere la configurazione. Alcuni nodi di configurazione supportano inoltre il comando info, che può essere utilizzato per visualizzare altri dettagli.

Tenere presente che, l'autenticazione ACL è abilitata per default, pertanto questa destinazione non è ancora accessibile. Consultare la Sezione 9.1.4.4, «Autenticazione e controllo dell'accesso» per ulteriori informazioni sull'autenticazione e il controllo dell'accesso.

9.1.4.4 Autenticazione e controllo dell'accesso #

 

L'autenticazione iSCSI è flessibile e include diverse possibilità di autenticazione.

9.1.4.4.1 Disabilitazione dell'autenticazione ACL #

 

No Authentication indica che qualsiasi iniziatore potrà accedere ai LUN sulla destinazione corrispondente. È possibile abilitare l'impostazione No Authentication disabilitando l'autenticazione ACL:

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts
gwcli >  /iscsi-target...testvol/hosts> auth disable_acl

9.1.4.4.2 Uso dell'autenticazione ACL #

 

Se si utilizza l'autenticazione ACL basata sul nome di iniziatore, la connessione è consentita soltanto agli iniziatori definiti. È possibile definire un iniziatore come indicato di seguito:

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts
gwcli >  /iscsi-target...testvol/hosts> create iqn.1996-04.de.suse:01:e6ca28cc9f20

Gli iniziatori definiti potranno eseguire la connessione, ma disporranno dell'accesso soltanto alle immagini RBD aggiunte esplicitamente all'iniziatore:

gwcli >  /iscsi-target...:e6ca28cc9f20> disk add rbd/testvol

9.1.4.4.3 Abilitazione dell'autenticazione CHAP #

 

Oltre all'autenticazione ACL, è possibile abilitare l'autenticazione CHAP specificando un nome utente e una password per ciascun iniziatore:

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts/iqn.1996-04.de.suse:01:e6ca28cc9f20
gwcli >  /iscsi-target...:e6ca28cc9f20> auth username=common12 password=pass12345678

Nota

I nomi utente devono avere una lunghezza compresa tra 8 e 64 caratteri e possono contenere caratteri alfanumerici, ., @, -, _ oppure :.

Le password devono avere una lunghezza compresa tra 12 e 16 caratteri e possono contenere caratteri alfanumerici, @, -, _ o /..

Facoltativamente, è possibile abilitare anche l'autenticazione CHAP reciproca specificando i parametri mutual_username e mutual_password nel comando auth.

9.1.4.4.4 Configurazione dell'autenticazione rilevazione e dell'autenticazione reciproca #

 

L'autenticazione rilevazione è indipendente dai metodi di autenticazione descritti in precedenza. Richiede le credenziali per la navigazione, è facoltativa e può essere configurata tramite:

gwcli >  /> cd /iscsi-targets
gwcli >  /iscsi-targets> discovery_auth username=du123456 password=dp1234567890

Nota

I nomi utente devono avere una lunghezza compresa tra 8 e 64 caratteri e possono contenere solo lettere, ., @, -, _ oppure :.

Le password devono avere una lunghezza compresa tra 12 e 16 caratteri e possono contenere solo lettere, @, -, _ oppure /.

Facoltativamente, è possibile specificare anche i parametri mutual_username e mutual_password nel comando discovery_auth.

È possibile disabilitare l'autenticazione rilevazione tramite il comando seguente:

gwcli >  /iscsi-targets> discovery_auth nochap

9.1.4.5 Configurazione delle impostazioni avanzate #

 

È possibile configurare ceph-iscsi con parametri avanzati che vengono quindi trasmessi alla destinazione di I/O di LIO. Tali parametri sono suddivisi nei parametri target e disk.

Avvertimento

Se non diversamente specificato, si consiglia di non modificare l'impostazione di default di questi parametri.

9.1.4.5.1 Visualizzazione delle impostazioni target #

 

È possibile visualizzare il valore di tali impostazioni tramite il comando info:

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol
gwcli >  /iscsi-target...i.SYSTEM-ARCH:testvol> info

E modificare un'impostazione con il comando reconfigure:

gwcli >  /iscsi-target...i.SYSTEM-ARCH:testvol> reconfigure login_timeout 20

Le impostazioni target disponibili sono:

default_cmdsn_depth

Profondità di default CmdSN (Command Sequence Number). Limita la quantità di richieste che l'iniziatore iSCSI può avere in sospeso in qualsiasi momento.

default_erl

Livello di ripristino errore di default.

login_timeout

Valore timeout di login in secondi.

netif_timeout

Timeout errore NIC in secondi.

prod_mode_write_protect

Se impostata a 1, impedisce le operazioni di scrittura sui LUN.

9.1.4.5.2 Visualizzazione delle impostazioni disk #

 

È possibile visualizzare il valore di tali impostazioni tramite il comando info:

gwcli >  /> cd /disks/rbd/testvol
gwcli >  /disks/rbd/testvol> info

E modificare un'impostazione con il comando reconfigure:

gwcli >  /disks/rbd/testvol> reconfigure rbd/testvol emulate_pr 0

Le impostazioni disk disponibili sono:

block_size

Dimensione di blocco del dispositivo sottostante.

emulate_3pc

Se impostata a 1, abilita Third Party Copy.

emulate_caw

Se impostata a 1, abilita Compare e Write.

emulate_dpo

Se impostato a 1, attiva Disable Page Out.

emulate_fua_read

Se impostata a 1, attiva la lettura Force Unit Access.

emulate_fua_write

Se impostata a 1, abilita la scrittura Force Unit Access.

emulate_model_alias

Se impostata a 1, utilizza il nome del dispositivo back-end per l'alias modello.

emulate_pr

Se impostata a 0, il supporto delle prenotazioni SCSI, incluse le Persistent Group Reservation, è disabilitato. Se è disabilitata, l'iSCSI Gateway SES può ignorare lo stato di prenotazione per generare una migliore latenza della richiesta.

Suggerimento

Si consiglia di impostare backstore_emulate_pr a 0 se gli iniziatori iSCSI non richiedono il supporto della prenotazione SCSI.

emulate_rest_reord

Se impostata a 0, il modificatore algoritmo di coda ha riordinamento limitato.

emulate_tas

Se impostata a 1, abilita Task Aborted Status.

emulate_tpu

Se impostata a 1, abilita Thin Provisioning Unmap.

emulate_tpws

Se impostata a 1, abilita Thin Provisioning Write Same.

emulate_ua_intlck_ctrl

Se impostata a 1, abilita Unit Attention Interlock.

emulate_write_cache

Se impostata a 1, attiva Write Cache Enable.

enforce_pr_isids

Se impostata a 1, applica gli ISID di prenotazione persistenti.

is_nonrot

Se impostata a 1, il backstore è un dispositivo non rotativo.

max_unmap_block_desc_count

Numero massimo di descrittori di blocco per UNMAP.

max_unmap_lba_count:

Numero massimo di LBA per UNMAP.

max_write_same_len

Lunghezza massima per WRITE_SAME.

optimal_sectors

Dimensione richiesta ottimale in settori.

pi_prot_type

Tipo di protezione DIF.

queue_depth

Profondità coda.

unmap_granularity

Granularità UNMAP.

unmap_granularity_alignment

Allineamento granularità UNMAP.

force_pr_aptpl

Se abilitata, LIO scriverà sempre lo stato di prenotazione permanente nello spazio di memorizzazione permanente, a prescindere dal fatto che il client lo abbia richiesto o meno tramite aptpl=1. Ciò non ha effetto sul back-end RBD del kernel per LIO, che manterrà sempre lo stato di prenotazione permanente. Idealmente, l'opzione target_core_rbd dovrebbe forzarla su "1" e generare un errore se qualcuno tenta di disabilitarla tramite la configurazione.

unmap_zeroes_data

Determina se LIO invierà un bit LBPRZ agli iniziatori SCSI, per indicare che gli zero di una determinata area verranno riletti dopo l'esecuzione di un comando UNMAP o WRITE SAME con un bit di annullamento della mappatura.

ceph-iscsi supporta i backstore rbd (basati su kernel) e user:rbd (tcmu-runner), rendendo la gestione invisibile all'utente e indipendente dal backstore.

Avvertimento: tecnologia in anteprima

Le distribuzioni di iSCSI Gateway basate su tcmu-runner sono attualmente un'anteprima.

A differenza delle distribuzioni iSCSI Gateway basate su kernel, gli iSCSI Gateway basati su tcmu-runner non offrono supporto per Multipath I/O o per le prenotazioni permanenti SCSI.

Per esportare un'immagine del dispositivo di blocco RADOS con tcmu-runner, occorre semplicemente specificare il backstore user:rbd durante il collegamento del disco:

gwcli >  /disks> attach rbd/testvol backstore=user:rbd

Nota

Durante l'uso di tcmu-runner, sull'immagine RBD esportata deve essere abilitata la funzione exclusive-lock.

Prima di eseguire l'upgrade, leggere per intero le sezioni seguenti per comprendere tutti i task che devono essere completati.

Si consiglia vivamente di eseguire il backup completo della configurazione e dei dati del cluster prima di avviare l'upgrade a SUSE Enterprise Storage 7.1. Per istruzioni su come eseguire il backup di tutti i dati, vedere https://documentation.suse.com/ses/6/single-html/ses-admin/#cha-deployment-backup.

Se in precedenza è stato eseguito l'upgrade dalla versione 5, verificare che l'upgrade alla versione 6 sia stato completato correttamente:

Controllare se il file /srv/salt/ceph/configuration/files/ceph.conf.import è presente.

Questo file è creato dal processo engulf durante l'upgrade da SUSE Enterprise Storage 5 a 6. L'opzione configuration_init: default-import è impostata in /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml.

Se l'opzione configuration_init è ancora impostata su default-import, come file di configurazione il cluster utilizza ceph.conf.import e non la configurazione ceph.conf di default di DeepSea, compilata dai file in /srv/salt/ceph/configuration/files/ceph.conf.d/.

Pertanto, è necessario analizzare ceph.conf.import per rilevare eventuali configurazioni personalizzate e possibilmente spostare la configurazione in uno dei file in /srv/salt/ceph/configuration/files/ceph.conf.d/.

Quindi, rimuovere la riga configuration_init: default-import da /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml.

Verificare che tutti gli ultimi aggiornamenti di SUSE Linux Enterprise Server 15 SP1 e SUSE Enterprise Storage 6 siano stati applicati a tutti i nodi del cluster:

# zypper refresh && zypper patch

Suggerimento

Per informazioni dettagliate sull'aggiornamento dei nodi del cluster, fare riferimento a https://documentation.suse.com/ses/6/html/ses-all/storage-salt-cluster.html#deepsea-rolling-updates.

Dopo aver applicato gli aggiornamenti, riavviare il Salt Master, sincronizzare i nuovi moduli Salt e controllare l'integrità del cluster:

root@master # systemctl restart salt-master.service
root@master # salt '*' saltutil.sync_all
cephuser@adm > ceph -s

 cephuser@adm > ceph status
 cluster:
   id:     3fe8b35a-689f-4970-819d-0e6b11f6707c
   health: HEALTH_WARN
   mons are allowing insecure global_id reclaim
 [...]

cephuser@adm > ceph config set mon auth_allow_insecure_global_id_reclaim false

Verificare che ogni nodo del cluster disponga dell'accesso agli archivi software di SUSE Linux Enterprise Server 15 SP3 e SUSE Enterprise Storage 7.1, oltre che al registro delle immagini del container.

In SUSE Enterprise Storage 7.1, gli Object Gateway sono sempre configurati con un dominio per consentire l'uso della funzionalità multisito (vedere Book “Guida all'amministrazione e alle operazioni”, Chapter 21 “Ceph Object Gateway”, Section 21.13 “Object Gateway multisito” per ulteriori dettagli) in un secondo momento. Se Object Gateway è stato configurato in modalità sito singolo in SUSE Enterprise Storage 6, seguire la procedura indicata di seguito per aggiungere un dominio. Se non si prevede di utilizzare la funzionalità multisito, è possibile utilizzare il valore default per il nome del dominio, del gruppo di zone e della zona.

Per inserire il servizio Object Gateway in container, creare il file della specifica corrispondente come descritto nella Sezione 8.3.4, «Distribuzione degli Object Gateway» e applicarlo.

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

Importante

NFS Ganesha supporta NFS versione 4.1 e versioni successive. Non supporta NFS versione 3.

Di seguito viene mostrato come eseguire la migrazione di un servizio NFS Ganesha esistente su cui è in esecuzione Ceph Nautilus a un container NFS Ganesha su cui è in esecuzione Ceph Octopus.

Avvertimento

Nella documentazione seguente si presuppone che l'utente abbia già eseguito correttamente l'upgrade dei servizi Ceph di base.

NFS Ganesha memorizza la configurazione aggiuntiva di ogni daemon e la esporta in un pool RADOS. È possibile individuare il pool RADOS configurato nella riga watch_url del blocco RADOS_URLS nel file ganesha.conf. Per default, questo pool sarà denominato ganesha_config.

Prima di tentare qualsiasi migrazione, si consiglia vivamente di eseguire una copia degli oggetti di configurazione del daemon e dell'esportazione ubicati nel pool RADOS. Per individuare il pool RADOS configurato, eseguire il seguente comando:

cephuser@adm > grep -A5 RADOS_URLS /etc/ganesha/ganesha.conf

Per elencare i contenuti del pool RADOS:

cephuser@adm > rados --pool ganesha_config --namespace ganesha ls | sort
  conf-node3
  export-1
  export-2
  export-3
  export-4

Per copiare gli oggetti RADOS:

cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
cephuser@adm > OBJS=$(rados $RADOS_ARGS ls)
cephuser@adm > for obj in $OBJS; do rados $RADOS_ARGS get $obj $obj; done
cephuser@adm > ls -lah
total 40K
drwxr-xr-x 2 root root 4.0K Sep 8 03:30 .
drwx------ 9 root root 4.0K Sep 8 03:23 ..
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node2
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node3
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-1
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-2
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-3
-rw-r--r-- 1 root root 358 Sep 8 03:30 export-4

Su ogni singolo nodo, occorre interrompere eventuali servizi NFS Ganesha esistenti e sostituirli con un container gestito da cephadm.

È possibile eseguire la migrazione delle esportazioni esistenti in due modi diversi:

Al termine della migrazione, è possibile rimuovere il servizio NFS Ganesha basato su Nautilus.

Diversamente dai servizi MON, MGR e OSD, il Metadata Server non può essere adottato sul posto. Al contrario, è necessario ridistribuirlo in container tramite l'utilità di coordinamento Ceph.

Per eseguire l'upgrade di iSCSI Gateway, è necessario ridistribuire tale servizio nei container tramite l'utilità di coordinamento Ceph. Se sono presenti più iSCSI Gateway, occorre ridistribuirli uno per uno per ridurre il tempo di fermo del servizio.

Prima di eseguire l'upgrade, leggere per intero le sezioni seguenti per comprendere tutti i task che devono essere completati.

Si consiglia vivamente di eseguire il backup completo della configurazione e dei dati del cluster prima di avviare l'upgrade. Per istruzioni su come eseguire il backup di tutti i dati, vedere Book “Guida all'amministrazione e alle operazioni”, Chapter 15 “Backup e ripristino”.

Verificare che ogni nodo del cluster disponga dell'accesso agli archivi software di SUSE Linux Enterprise Server 15 SP3 e SUSE Enterprise Storage 7.1, oltre che al registro delle immagini del container.