Installazione con DeepSea/Salt | Guida alla distribuzione

documentation.suse.com › Documentazione di SUSE Enterprise Storage 6 › Guida alla distribuzione › Distribuzione e upgrade del cluster › Installazione con DeepSea/Salt

ContenutoContenuto

Guida alla distribuzione

Navigazione←→

Si applica a SUSE Enterprise Storage 6

5 Installazione con DeepSea/Salt #

5.1 Lettura delle note di rilascio
5.2 Introduzione a DeepSea
5.3 Distribuzione del cluster
5.4 DeepSea CLI
5.5 Configurazione e personalizzazione

Salt insieme con DeepSea è uno stack di componenti che consentono di installare e gestire l'infrastruttura del server, risultando scalabile, veloce e relativamente semplice da eseguire. Prima di avviare l'installazione del cluster con Salt, leggere le seguenti considerazioni:

I Salt minion sono i nodi controllati da un nodo dedicato denominato Salt master. I Salt minion hanno ruoli, ad esempio Ceph OSD, Ceph Monitor, Ceph Manager, Object Gateway, iSCSI Gateway o NFS Ganesha.
Un Salt master esegue il proprio Salt minion, richiesto per eseguire task privilegiati, ad esempio creazione, autorizzazione e copia di chiavi sui minion, in modo che i minion remoti non debbano mai eseguire task privilegiati.
Suggerimento: condivisione di più ruoli per server
È possibile ottenere le prestazioni migliori dal cluster Ceph quando ogni ruolo viene distribuito su un nodo separato. Le installazioni reali, tuttavia, a volte richiedono la condivisione di un nodo per più ruoli. Per evitare problemi di prestazioni e con la procedura di upgrade, non distribuire il ruolo Ceph OSD, del server di metadati o Ceph Monitor sul nodo admin.
I Salt minion devono risolvere correttamente il nome host del Salt master in rete. Per impostazione predefinita, viene cercato il nome host salt, ma è possibile specificare altri nomi host individuabili in rete nel file /etc/salt/minion, vedere Sezione 5.3, «Distribuzione del cluster».

5.1 Lettura delle note di rilascio #

Nelle note di rilascio è possibile trovare informazioni aggiuntive sulle modifiche apportate rispetto alla release precedente di SUSE Enterprise Storage. Controllare le note di rilascio per vedere se:

l'hardware necessita di considerazioni speciali;
i pacchetti software utilizzati hanno subito modifiche significative;
è necessario adottare precauzioni speciali per l'installazione.

Le note di rilascio forniscono inoltre informazioni che non si è fatto in tempo a riportare nel manuale. Contengono anche alcune note su problemi noti.

Dopo aver installato il pacchetto release-notes-ses, individuare localmente le note di rilascio nella directory /usr/share/doc/release-notes o online all'indirizzo https://www.suse.com/releasenotes/.

5.2 Introduzione a DeepSea #

DeepSea consente di far risparmiare tempo all'amministratore ed eseguire in sicurezza operazioni complesse su un cluster Ceph.

Ceph è una soluzione software altamente configurabile che aumenta la libertà e la responsabilità degli amministratori di sistema.

La configurazione minima di Ceph è ottima per scopi dimostrativi, ma non mostra le funzionalità interessanti di Ceph visibili con un alto numero di nodi.

DeepSea raccoglie e memorizza i dati sui singoli server, ad esempio indirizzi e nomi dei dispositivi. Per un sistema di storage distribuito come Ceph, possono esistere centinaia di tali voci da raccogliere e memorizzare. La raccolta delle informazioni e l'immissione manuale dei dati in uno strumento di gestione della configurazione è un'operazione complessa in cui è facile fare degli errori.

I passaggi necessari per preparare i server, raccogliere la configurazione, configurare e distribuire Ceph sono quasi uguali. Tuttavia, ciò non riguarda la gestione di funzioni separate. Per le operazioni giornaliere, è richiesta la capacità di aggiungere hardware a una data funzione e rimuoverlo senza problemi.

DeepSea gestisce queste osservazioni con la seguente strategia: DeepSea consolida le decisioni dell'amministratore in un singolo file. Le decisioni comprendono assegnazione del cluster, assegnazione del ruolo e assegnazione del profilo, mentre DeepSea raccoglie ciascun insieme di task in un semplice obiettivo. Ogni obiettivo è una fase:

Descrizione delle fasi di DeepSea #

Fase 0, la preparazione, durante questa fase, vengono applicati tutti gli aggiornamenti richiesti e il sistema potrebbe riavviarsi.
Importante: nuova esecuzione della fase 0 dopo il riavvio del nodo admin
Se, durante la fase 0, il nodo admin si riavvia per caricare la nuova versione del kernel, occorre eseguire di nuovo la fase 0, in caso contrario i minion non vengono indirizzati.
Fase 1, la rilevazione, viene rilevato tutto l'hardware nel cluster e vengono raccolte le informazioni necessarie per la configurazione Ceph. Per informazioni sulla configurazione, consultare Sezione 5.5, «Configurazione e personalizzazione».
Fase 2, la configurazione, è necessario preparare i dati di configurazione in un formato particolare.
Fase 3, l'installazione, crea un cluster Ceph di base con i servizi Ceph obbligatori. Per l'elenco, vedere Sezione 1.2.3, «Daemon e nodi Ceph».
Fase 4, i servizi, in questa fase è possibile installare funzionalità aggiuntive di Ceph come iSCSI, Object Gateway e CephFS. Sono tutte opzionali.
Fase 5, la fase di rimozione. Questa fase non è obbligatoria e durante la configurazione iniziale non è in genere necessaria. In questa fase vengono rimossi i ruoli dei minion e anche la configurazione del cluster. È necessario eseguire questa fase quando occorre rimuovere un nodo di storage dal cluster. Per ulteriori informazioni, vedere la Sezione 2.3, «Rimozione e reinstallazione dei nodi del cluster».

5.2.1 Organizzazione e ubicazioni importanti #

Salt dispone di diverse ubicazioni standard e diverse convenzioni di assegnazione del nome utilizzate sul nodo master:

/srv/pillar: La directory memorizza i dati di configurazione per i minion del cluster. Pillar è un'interfaccia che fornisce valori di configurazione globali a tutti i minion del cluster.
/srv/salt/: La directory memorizza i file di stato di Salt (denominati anche file sls). I file di stato sono descrizioni formattate di stati in cui deve trovarsi il cluster.
/srv/module/runners: La directory memorizza script Python noti come runner. I runner vengono eseguiti sul nodo master.
/srv/salt/_modules: La directory memorizza gli script Python denominati moduli. I moduli vengono applicati a tutti i minion nel cluster.
/srv/pillar/ceph: La directory è utilizzata da DeepSea. I dati della configurazione raccolti vengono memorizzati qui.
/srv/salt/ceph: Una directory utilizzata da DeepSea. Memorizza i file sls che possono essere in formati diversi, ma ogni sottodirectory contiene file sls. Ciascuna sottodirectory contiene solo un tipo di file sls. Ad esempio, /srv/salt/ceph/stage contiene i file di orchestrazione eseguiti da salt-run state.orchestrate.

5.2.2 Indirizzamento dei minion #

I comandi DeepSea vengono eseguiti tramite l'infrastruttura Salt. Quando si utilizza il comando salt, occorre specificare un insieme di Salt minion interessati dal comando. L'insieme dei minion viene descritto come destinazione per il comando salt. Le sezioni seguenti descrivono i possibili metodi di individuare i minion.

5.2.2.1 Corrispondenza del nome del minion #

È possibile individuare un minion o un gruppo di minion tramite corrispondenza dei nomi. Il nome di un minion è in genere il nome host breve del nodo in cui viene eseguito il minion. Questo è in genere un metodo di indirizzamento Salt, non correlato a DeepSea. Per limitare il campo dei nomi di minion, è possibile utilizzare caratteri jolly, espressioni regolari o elenchi. Segue la sintassi generica:

root@master # salt target example.module

Suggerimento: cluster solo Ceph

Se tutti i Salt minion nell'ambiente appartengono al cluster Ceph, è possibile sostituire in sicurezza target con "*" per includere tutti i minion registrati.

Far corrispondere tutti i minion nel dominio example.net (supponendo che i nomi dei minion siano identici ai loro nomi host "completi"):

root@master # salt '*.example.net' test.ping

Far corrispondere i minion da "web1" a "web5":

root@master # salt 'web[1-5]' test.ping

Far corrispondere i minion "web1-prod" e "web1-devel" utilizzando un'espressione regolare:

root@master # salt -E 'web1-(prod|devel)' test.ping

Far corrispondere un semplice elenco di minion:

root@master # salt -L 'web1,web2,web3' test.ping

Far corrispondere tutti i minion nel cluster:

root@master # salt '*' test.ping

5.2.2.2 Indirizzamento con un grain DeepSea #

In un ambiente eterogeneo gestito da Salt in cui SUSE Enterprise Storage 6 è distribuito su un sottoinsieme di nodi insieme ad altre soluzioni cluster, è necessario contrassegnare i minion pertinenti applicandovi un grain "deepsea" prima di eseguire la fase 0 di DeepSea. In questo modo è possibile indirizzare con facilità i minion DeepSea negli ambienti dove è problematica la corrispondenza del nome.

Per applicare il grain "deepsea" a un gruppo di minion, eseguire:

root@master # salt target grains.append deepsea default

Per rimuovere il grain "deepsea" da un gruppo di minion, eseguire:

root@master # salt target grains.delval deepsea destructive=True

Dopo aver applicato il grain "deepsea" ai minion pertinenti, è possibile individuarli come segue:

root@master # salt -G 'deepsea:*' test.ping

Il comando seguente è un equivalente:

root@master # salt -C 'G@deepsea:*' test.ping

5.2.2.3 Impostare l'opzione `deepsea_minions` #

L'impostazione della destinazione dell'opzione deepsea_minions è un requisito per le distribuzioni di DeepSea. DeepSea la utilizza per istruire i minion durante l'esecuzione delle fasi (per i dettagli, fare riferimento a Descrizione delle fasi di DeepSea).

Per impostare o modificare l'opzione deepsea_minions, modificare il file /srv/pillar/ceph/deepsea_minions.sls sul Salt master e aggiungere o sostituire la riga seguente:

deepsea_minions: target

Suggerimento: destinazione `deepsea_minions`

Come target per l'opzione deepsea_minions, è possibile utilizzare uno dei metodi di indirizzamento: Corrispondenza del nome del minion e Indirizzamento con un grain DeepSea.

Far corrispondere tutti i minion Salt nel cluster:

deepsea_minions: '*'

Far corrispondere tutti i minion con il grain "deepsea":

deepsea_minions: 'G@deepsea:*'

5.2.2.4 Ulteriori informazioni #

È possibile utilizzare metodi più avanzati per l'indirizzamento dei minion mediante l'infrastruttura Salt. La pagina della documentazione "deepsea-minions" fornisce ulteriori dettagli sull'indirizzamento di DeepSea (man 7 deepsea_minions).

5.3 Distribuzione del cluster #

Il processo di distribuzione del cluster comprende fasi diverse. Primo, occorre preparare tutti i nodi del cluster configurando Salt, quindi distribuire e configurare Ceph.

Suggerimento: distribuzione dei nodi monitor senza definire profili OSD

Se occorre ignorare la definizione dei ruoli di storage per OSD come descritto nella Sezione 5.5.1.2, «Assegnazione ruolo» e distribuire prima i nodi Ceph Monitor, è possibile farlo impostando la variabile DEV_ENV

che consente di distribuire i monitor senza la presenza della directory role-storage/, oltre a distribuire un cluster Ceph con almeno un ruolo storage, monitor e manager.

Per impostare la variabile ambientale, abilitarla globalmente nel file /srv/pillar/ceph/stack/global.yml, oppure impostarla solo per la sessione di shell corrente:

root@master # export DEV_ENV=true

Ad esempio, è possibile creare /srv/pillar/ceph/stack/global.yml con i contenuti seguenti:

DEV_ENV: True

La procedura seguente descrive la preparazione del cluster in modo dettagliato.

Installare e registrare SUSE Linux Enterprise Server 15 SP1 insieme con l'estensione SUSE Enterprise Storage 6 in ciascun nodo del cluster.

Verificare che i prodotti corretti siano installati e registrati elencando i repository software esistenti. Eseguire zypper lr -E e confrontare l'output con l'elenco seguente:

 SLE-Product-SLES15-SP1-Pool
 SLE-Product-SLES15-SP1-Updates
 SLE-Module-Server-Applications15-SP1-Pool
 SLE-Module-Server-Applications15-SP1-Updates
 SLE-Module-Basesystem15-SP1-Pool
 SLE-Module-Basesystem15-SP1-Updates
 SUSE-Enterprise-Storage-6-Pool
 SUSE-Enterprise-Storage-6-Updates

Configurare le impostazioni di rete compresa la risoluzione del nome DNS corretto su ogni nodo. Il Salt master e tutti i Salt minion devono risolvere ciascuno mediante i loro nomi host. Per ulteriori informazioni sulla configurazione di una rete, vedere https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_network_yast.html. Per ulteriori informazioni sulla configurazione di un server DNS, vedere https://www.suse.com/documentation/sles-15/book_sle_admin/data/cha_dns.html.
Selezionare uno o più server dell'orario/pool e sincronizzare l'orario locale rispetto a questi ultimi. Verificare che il servizio di sincronizzazione dell'orario sia abilitato per ogni avvio di sistema. È possibile utilizzare il comando yast ntp-client trovato nel pacchetto yast2-ntp-client per configurare la sincronizzazione dell'orario.
Suggerimento
Le macchine virtuali non sono origini NTP attendibili.
Ulteriori informazioni sulla configurazione di NTP sono disponibili in https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_ntp_yast.html.
Installare i pacchetti salt-master e salt-minion sul nodo Salt master:
```
root@master # zypper in salt-master salt-minion
```
Verificare che il servizio salt-master sia abilitato e avviato, se necessario abilitarlo e avviarlo:
```
root@master # systemctl enable salt-master.service
root@master # systemctl start salt-master.service
```
Se si intende utilizzare il firewall, verificare che il nodo master abbia le porte 4505 e 4506 aperte per tutti i nodi Salt minion. Se le porte sono chiuse, è possibile aprirle con il comando yast2 firewall consentendo il servizio SaltStack.
Avviso: le fasi di DeepSea non riescono con il firewall
Le fasi di installazione di DeepSea non riescono se il firewall è attivo (e anche configurato). Per eseguire le fasi correttamente, occorre disattivare il firewall eseguendo
```
    root # systemctl stop firewalld.service
```
oppure impostare l'opzione FAIL_ON_WARNING su "False" in /srv/pillar/ceph/stack/global.yml:
```
FAIL_ON_WARNING: False
```
Installare il pacchetto salt-minion su tutti i nodi minion.
```
root@minion > zypper in salt-minion
```
Accertare che il nome di dominio qualificato completo di ciascun nodo possa essere risolto sull'indirizzo IP della rete pubblica da tutti gli altri nodi.
Configurare tutti i minion (compreso il minion master) per il collegamento al master. Se il Salt master non è raggiungibile dal nome host salt, modificare il file /etc/salt/minion oppure creare un nuovo file /etc/salt/minion.d/master.conf con il seguente contenuto:
```
master: host_name_of_salt_master
```
Se sono state apportate modifiche ai file di configurazione menzionati sopra, riavviare il servizio Salt su tutti i Salt minion:
```
root@minion > systemctl restart salt-minion.service
```
Verificare che il servizio salt-minion sia abilitato e avviato su tutti i nodi. Abilitarlo e avviarlo se necessario:
```
root # systemctl enable salt-minion.service
root # systemctl start salt-minion.service
```
Verificare ogni impronta del Salt minion e accettare tutte le chiavi salt sul Salt master se le impronte corrispondono.
Nota
Se l'impronta digitale del Salt minion viene restituita vuota, assicurarsi che il Salt minion disponga di una configurazione Salt master e che sia in grado di comunicare con quest'ultimo.
Visualizzare l'impronta di ogni minion:
```
root@master # salt-call --local key.finger
local:
3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...
```
Dopo aver raccolto le impronte di tutti i Salt minion, elencare le impronte di tutte le chiavi minion non accettate sul Salt master:
```
root@master # salt-key -F
[...]
Unaccepted Keys:
minion1:
3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...
```
Se le impronte digitali dei minion corrispondono, accettarle:
```
root@master # salt-key --accept-all
```
Verificare che le chiavi siano state accettate:
```
root@master # salt-key --list-all
```
Prima di distribuire SUSE Enterprise Storage 6, cancellare manualmente tutti i dischi. Ricordare di sostituire "X" con la lettera corretta del disco:
1. Interrompere tutti i processi che utilizzano il disco specifico.
2. Verificare se eventuali partizioni sul disco sono montate e smontare se necessario.
3. Se il disco è gestito da LVM, disattivare ed eliminare l'intera infrastruttura LVM. Per ulteriori dettagli, fare riferimento a https://www.suse.com/documentation/sles-15/book_storage/data/cha_lvm.html.
4. Se il disco fa parte di MD RAID, disattivare RAID. Per ulteriori dettagli, fare riferimento a https://www.suse.com/documentation/sles-15/book_storage/data/part_software_raid.html.
5. Suggerimento: riavvio del server
  Se si ricevono messaggi di errore come "partition in use" o "kernel can not be updated with the new partition table" durante le fasi seguenti, riavviare il server.
  Cancellare la parte iniziale di ogni partizione (come root):
```
for partition in /dev/sdX[0-9]*
do
  dd if=/dev/zero of=$partition bs=4096 count=1 oflag=direct
done
```
6. Cancellare la parte iniziale dell'unità:
```
root # dd if=/dev/zero of=/dev/sdX bs=512 count=34 oflag=direct
```
7. Cancellare la parte finale dell'unità:
```
root # dd if=/dev/zero of=/dev/sdX bs=512 count=33 \
  seek=$((`blockdev --getsz /dev/sdX` - 33)) oflag=direct
```
8. Verificare che l'unità sia vuota (senza strutture GPT) utilizzando:
```
root # parted -s /dev/sdX print free
```
  oppure
```
root # dd if=/dev/sdX bs=512 count=34 | hexdump -C
root # dd if=/dev/sdX bs=512 count=33 \
  skip=$((`blockdev --getsz /dev/sdX` - 33)) | hexdump -C
```
Facoltativamente, se è necessario preconfigurare le impostazioni di rete del cluster prima dell'installazione del pacchetto deepsea creare manualmente /srv/pillar/ceph/stack/ceph/cluster.yml e impostare le opzioni cluster_network: e public_network:. Tenere presente che il file non verrà sovrascritto dopo l'installazione di deepsea.
Suggerimento: abilitazione di IPv6
Se è necessario abilitare l'indirizzamento della rete IPv6, fare riferimento alla Sezione 7.2.1, «Abilitazione di IPv6 per la distribuzione del cluster Ceph»
Installare DeepSea sul nodo Salt master:
```
root@master # zypper in deepsea
```
Il valore del parametro master_minion viene derivato dinamicamente dal file /etc/salt/minion_id sul Salt master. Se è necessario sostituire il valore rilevato, modificare il file /srv/pillar/ceph/stack/global.yml e impostare un valore pertinente:
```
master_minion: MASTER_MINION_NAME
```
Se il Salt master è raggiungibile tramite altri nomi host, utilizzare il nome del Salt minion per il cluster di memorizzazione restituito dal comando salt-key -L. Se è stato utilizzato il nome host predefinito per il Salt master, salt, nel dominio ses, l'aspetto del file è:
```
master_minion: salt.ses
```

Ora è possibile distribuire e configurare Ceph. Se non specificato diversamente, tutti i passaggi sono obbligatori.

Nota: convenzioni del comando Salt

È possibile eseguire salt-run state.orch in due modi: uno è con "stage.STAGE_NUMBER", l'altro è con il nome della fase. Entrambe le annotazioni hanno lo stesso impatto e la scelta del comando da utilizzare dipende dall'utente.

Procedura 5.1: Esecuzione delle fasi di distribuzione #

Assicurarsi che i Salt minion appartenenti al cluster Ceph siano indirizzati correttamente tramite l'opzione deepsea_minions in /srv/pillar/ceph/deepsea_minions.sls. Per ulteriori informazioni consultare Sezione 5.2.2.3, «Impostare l'opzione deepsea_minions».
Per default, DeepSea distribuisce i cluster Ceph con profili ottimizzati attivi sui nodi Ceph Monitor, Ceph Manager e Ceph OSD. In alcuni casi potrebbe essere necessario effettuare la distribuzione senza profili ottimizzati. A questo scopo, inserire le righe seguenti in /srv/pillar/ceph/stack/global.yml prima di eseguire le fasi di DeepSea:
```
alternative_defaults:
 tuned_mgr_init: default-off
 tuned_mon_init: default-off
 tuned_osd_init: default-off
```
Facoltativo: creare sotto volumi Btrfs per /var/lib/ceph/. Questa fase deve essere eseguita prima della fase 0 di DeepSea. Per eseguire la migrazione delle directory esistenti o per ulteriori dettagli, consultare questo riferimento: Sezione 25.6, «Sottovolume Btrfs per /var/lib/ceph sui nodi Ceph Monitor».
Applicare i comandi seguenti a ciascuno dei Salt minion:
```
root@master # salt 'MONITOR_NODES' saltutil.sync_all
root@master # salt 'MONITOR_NODES' state.apply ceph.subvolume
```
Nota
Il comando Ceph.subvolume consente di creare /var/lib/ceph come sottovolume Btrfs @/var/lib/ceph.
Il nuovo sottovolume viene a questo punto montato e /etc/fstab viene aggiornato.
Preparare il cluster. Per ulteriori dettagli, fare riferimento a Descrizione delle fasi di DeepSea.
```
root@master # salt-run state.orch ceph.stage.0
```
oppure
```
root@master # salt-run state.orch ceph.stage.prep
```
Nota: eseguire o monitorare le fasi con DeepSea CLI
Con DeepSea CLI, è possibile seguire l'avanzamento dell'esecuzione delle fasi in tempo reale, eseguendo DeepSea CLI nella modalità di monitoraggio o eseguendo la fase direttamente tramite DeepSea CLI. Per ulteriori informazioni, vedere la Sezione 5.4, «DeepSea CLI».
La fase di rilevamento raccoglie i dati da tutti i minion e crea frammenti di configurazione memorizzati nella directory /srv/pillar/ceph/proposals. I dati sono memorizzati nel formato YAML nei file *.sls o *.yml.
Per attivare la fase di rilevazione, eseguire il comando seguente:
```
root@master # salt-run state.orch ceph.stage.1
```
oppure
```
root@master # salt-run state.orch ceph.stage.discovery
```
Dopo il corretto completamento di un comando, creare un file policy.cfg in /srv/pillar/ceph/proposals. Per ulteriori informazioni, vedere la Sezione 5.5.1, «Il file policy.cfg».
Suggerimento
Se occorre modificare l'impostazione di rete del cluster, modificare /srv/pillar/ceph/stack/ceph/cluster.yml e modificare le righe che iniziano con cluster_network: e public_network:.
La fase di configurazione analizza il file policy.cfg e unisce i file inclusi nella forma finale. Il contenuto relativo a cluster e ruolo viene posto in /srv/pillar/ceph/cluster, mentre il contenuto specifico di Ceph in /srv/pillar/ceph/stack/default.
Per attivare la fase di configurazione, eseguire il comando seguente:
```
root@master # salt-run state.orch ceph.stage.2
```
oppure
```
root@master # salt-run state.orch ceph.stage.configure
```
La fase di configurazione può richiedere diversi secondi. Al completamento del comando, è possibile visualizzare i dati di Pillar per i minion specificati (ad esempio, denominati ceph_minion1, ceph_minion2, ecc.) eseguendo:
```
root@master # salt 'ceph_minion*' pillar.items
```
Suggerimento: modifica del layout dell'OSD
Se si desidera modificare il layout di default dell'OSD e la configurazione dei gruppi di unità, seguire la procedura descritta nel riferimento Sezione 5.5.2, «DriveGroups».
Nota: sovrascrittura dei default
Non appena il comando viene completato, è possibile visualizzare la configurazione di default e modificarla in base alle esigenze. Per ulteriori informazioni, vedere la Capitolo 7, Personalizzazione della configurazione di default.
Ora è possibile eseguire la fase di installazione. In questa fase viene convalidato il Pillar e vengono avviati i daemon Ceph Monitor e Ceph OSD:
```
root@master # salt-run state.orch ceph.stage.3
```
oppure
```
root@master # salt-run state.orch ceph.stage.deploy
```
Il comando può richiedere alcuni minuti. In caso di errore, risolvere il problema ed eseguire di nuovo le fasi precedenti. Al corretto completamento del comando, eseguire questo comando per verificare lo stato:
```
cephadm@adm > ceph -s
```
L'ultima fase dell'installazione del cluster Ceph è quella dei servizi. Qui è possibile creare un'istanza di uno dei servizi correntemente supportati: iSCSI Gateway, CephFS, Object Gateway e NFS Ganesha. In questa fase, vengono creati i pool necessari, i portachiavi di autorizzazione e i servizi di avvio. Per avviare la fase, eseguire il comando:
```
root@master # salt-run state.orch ceph.stage.4
```
oppure
```
root@master # salt-run state.orch ceph.stage.services
```
In base alla configurazione, l'esecuzione del comando può richiedere vari minuti.
Prima di continuare, si consiglia di abilitare il modulo di telemetria Ceph. Per ulteriori informazioni e istruzioni, consultare questo riferimento: Sezione 10.2, «Modulo di telemetria».

5.4 DeepSea CLI #

DeepSea fornisce inoltre uno strumento di interfaccia riga di comando (CLI) che consente all'utente di monitorare o eseguire le fasi mentre visualizza l'avanzamento dell'esecuzione in tempo reale. Verificare che la versione del pacchetto deepsea-cli sia installato prima di aprire l'eseguibile deepsea.

Per visualizzare l'avanzamento dell'esecuzione di una fase sono supportate due modalità:

Modalità DeepSea CLI #

Modalità di monitoraggio: visualizza l'avanzamento dell'esecuzione di una fase di DeepSea attivata dal comando salt-run emesso in un'altra sessione del terminale.
Modalità stand-alone: esegue una fase di DeepSea fornendo la visualizzazione in tempo reale delle relative fasi componenti durante l'esecuzione.

Importante: comandi DeepSea CLI

I comandi dell'interfaccia riga di comando DeepSea possono essere eseguiti solo nel nodo Salt master, con privilegi di root.

5.4.1 DeepSea CLI: nodo monitor #

Il monitor di avanzamento fornisce una visualizzazione dettagliata in tempo reale di quanto si verifica durante l'esecuzione delle fasi mediante i comandi salt-run state.orch in altre sessioni del terminale.

Suggerimento: avvio del monitor in una nuova sessione del terminale

Per fare in modo che il monitor rilevi l'avvio dell'esecuzione della fase, è necessario avviarlo in una nuova finestra terminale prima di eseguire salt-run state.orch.

Se si avvia il monitor dopo aver eseguito il comando salt-run state.orch, non viene mostrato alcun avanzamento dell'esecuzione.

È possibile avviare la modalità monitor utilizzando il comando che segue:

root@master # deepsea monitor

Per ulteriori informazioni sulle opzioni della riga di comando disponibili del comando deepsea monitor, consultare la relativa documentazione:

root@master # man deepsea-monitor

5.4.2 DeepSea CLI: modalità stand-alone #

Nella modalità stand-alone, è possibile utilizzare DeepSea CLI per eseguire una fase DeepSea, mostrandone l'esecuzione in tempo reale.

Il comando per eseguire una fase DeepSea da DeepSea CLI ha la forma seguente:

root@master # deepsea stage run stage-name

dove stage-name corrisponde al modo in cui viene fatto riferimento ai file di stato di orchestrazione Salt. Ad esempio, alla fase distribuzione, che corrisponde alla directory ubicata in /srv/salt/ceph/stage/deploy, si fa riferimento come ceph.stage.deploy.

Questo comando è un'alternativa ai comandi basati su Salt per eseguire le fasi DeepSea (o qualunque file di stato di orchestrazione DeepSea).

Il comando deepsea stage run ceph.stage.0 è equivalente a salt-run state.orch ceph.stage.0.

Per ulteriori informazioni sulle opzioni della riga di comando accettate dal comando deepsea stage run disponibili, consultare la relativa documentazione:

root@master # man deepsea-stage run

La figura seguente mostra un esempio del risultato di DeepSea CLI quando si esegue la Fase 2:

Figura 5.1: Risultato avanzamento esecuzione fase DeepSea CLI #

5.4.2.1 Alias `stage run` DeepSea CLI #

Per gli utenti avanzati di Salt, è inoltre supportato un alias per eseguire una fase di DeepSea che utilizza il comando Salt per eseguire una fase, ad esempio, salt-run state.orch stage-name, come comando di DeepSea CLI.

Esempio:

root@master # deepsea salt-run state.orch stage-name

5.5 Configurazione e personalizzazione #

5.5.1 Il file `policy.cfg` #

Il file di configurazione /srv/pillar/ceph/proposals/policy.cfg consente di determinare i ruoli dei singoli nodi del cluster. Ad esempio, quali nodi fungono da Ceph OSD o da Ceph Monitor. Modificare policy.cfg per riflettere la configurazione del cluster desiderata. L'ordine delle sezioni è arbitrario, ma il contenuto delle righe incluse sovrascrive le chiavi corrispondenti dal contenuto delle righe precedenti.

Suggerimento: esempi di `policy.cfg`

È possibile trovare diversi esempi dei file di policy completi nella directory /usr/share/doc/packages/deepsea/examples/.

5.5.1.1 Assegnazione cluster #

Nella sezione cluster è possibile selezionare i minion per il cluster. È possibile selezionare tutti i minion, oppure inserire i minion in blacklist o whitelist. Di seguito vengono forniti esempi per un cluster denominato ceph.

Per includere tutti i minion, aggiungere le righe seguenti:

cluster-ceph/cluster/*.sls

Per inserire nella whitelist un minion particolare:

cluster-ceph/cluster/abc.domain.sls

oppure un gruppo di minion, è possibile utilizzare la corrispondenza con caratteri jolly della shell:

cluster-ceph/cluster/mon*.sls

Per inserire nella blacklist i minion, impostarli su unassigned:

cluster-unassigned/cluster/client*.sls

5.5.1.2 Assegnazione ruolo #

Questa sezione fornisce i dettagli per l'assegnazione dei "ruoli" ai nodi cluster. Un "ruolo" in questo contesto indica il servizio che occorre eseguire sul nodo, come Ceph Monitor, Object Gateway o iSCSI Gateway. Nessun ruolo viene assegnato automaticamente, vengono distribuiti solo i ruoli aggiunti a policy.cfg.

L'assegnazione segue questo schema:

role-ROLE_NAME/PATH/FILES_TO_INCLUDE

Dove le voci hanno i seguenti significati e valori:

ROLE_NAME è uno dei seguenti: "master", "admin", "mon", "mgr", "storage", "mds", "igw", "rgw", "ganesha", "grafana" o "prometheus".
PATH è un percorso di directory relativo ai file .sls o .yml. Nel caso dei file .sls, in genere è cluster, mentre i file .yml si trovano in stack/default/ceph/minions.
FILES_TO_INCLUDE sono i file di stato Salt o i file di configurazione YAML che consistono normalmente di nomi host dei Salt minion, ad esempio ses5min2.yml. Per una corrispondenza più specifica è possibile utilizzare la corrispondenza con caratteri jolly della shell.

Segue un esempio per ogni ruolo:

master - il nodo ha portachiavi admin su tutti i cluster Ceph. Attualmente, è supportato solo un singolo cluster Ceph. Poiché il ruolo master è obbligatorio, aggiungere sempre una riga simile a:
```
role-master/cluster/master*.sls
```
admin - il minion ha un portachiavi admin. Definire il ruolo nel modo seguente:
```
role-admin/cluster/abc*.sls
```
mon - il minion fornisce il servizio di monitoraggio al cluster Ceph. Questo ruolo richiede gli indirizzi dei minion assegnati. A partire da SUSE Enterprise Storage 5, gli indirizzi pubblici vengono calcolati dinamicamente e non sono più necessari in salt pillar.
```
role-mon/cluster/mon*.sls
```
Nell'esempio, il ruolo di monitoraggio viene assegnato a un gruppo di minion.
mgr - il daemon manager Ceph che raccoglie tutte le informazioni sullo stato dall'intero cluster. Distribuirlo su tutti i minion dove si pianifica di distribuire il ruolo monitor Ceph.
```
role-mgr/cluster/mgr*.sls
```
storage - utilizzare questo ruolo per specificare i nodi di storage.
```
role-storage/cluster/data*.sls
```
mds - il minion fornisce il servizio metadati per supportare CephFS.
```
role-mds/cluster/mds*.sls
```
igw - il minion funge da iSCSI Gateway. Questo ruolo richiede gli indirizzi dei minion assegnati, perciò occorre anche includere i file della directory stack:
```
role-igw/cluster/*.sls
```
rgw - il minion funge da Object Gateway:
```
role-rgw/cluster/rgw*.sls
```
ganesha - il minion funge da server NFS Ganesha. Il ruolo "ganesha" richiede un ruolo "rgw" o "mds" nel cluster, in caso contrario la convalida non riesce nella Fase 3.
```
role-ganesha/cluster/ganesha*.sls
```
Per installare correttamente NFS Ganesha, è richiesta una configurazione aggiuntiva. Se si desidera utilizzare NFS Ganesha, leggere Capitolo 12, Installazione di NFS Ganesha prima di eseguire le fasi 2 e 4. Tuttavia, è possibile installare NFS Ganesha in seguito.
In alcuni casi può essere utile definire ruoli personalizzati per i nodi NFS Ganesha. Per informazioni, vedere Sezione 21.3, «Ruoli NFS Ganesha personalizzati».
grafana, prometheus - questo nodo aggiunge i grafici Grafana basati sugli avvisi Prometheus sul Ceph Dashboard. Per la descrizione dettagliata, consultare questo riferimento: Capitolo 22, Ceph Dashboard.
```
role-grafana/cluster/grafana*.sls
```
```
role-prometheus/cluster/prometheus*.sls
```

Nota: ruoli multipli dei nodi del cluster

È possibile assegnare più ruoli a un singolo nodo. Ad esempio, è possibile assegnare i ruoli "mds" ai nodi monitor:

role-mds/cluster/mon[1,2]*.sls

5.5.1.3 Configurazione comune #

La sezione di configurazione comune comprende i file di configurazione generati durante la rilevazione (fase 1). Questi file di configurazione memorizzano parametri come fsid o public_network. Per includere la configurazione comune Ceph richiesta, aggiungere le righe seguenti:

config/stack/default/global.yml
config/stack/default/ceph/cluster.yml

5.5.1.4 Filtraggio voci #

A volte non è pratico includere tutti i file di una data directory con il carattere jolly *.sls. L'analizzatore di file policy.cfg comprende i seguenti filtri:

Avviso: tecniche avanzate

Questa sezione descrive le tecniche di filtraggio per utenti avanzati. Se non utilizzati correttamente, i filtri possono provocare problemi, ad esempio se cambia la numerazione del nodo.

slice=[start:end]

Utilizzare il filtro slice per includere solo le voci da start a end-1. Tenere presente che le voci nella directory data sono in ordine alfabetico. La riga seguente comprende i file dal terzo al quinto della sottodirectory role-mon/cluster/:

role-mon/cluster/*.sls slice[3:6]

re=regexp

Utilizzare il filtro dell'espressione regolare per includere solo le voci che corrispondono alle espressioni date. Ad esempio:

role-mon/cluster/mon*.sls re=.*1[135]\.subdomainX\.sls$

5.5.1.5 File `policy.cfg` di esempio #

Di seguito viene fornito un esempio di un file policy.cfg di base:

## Cluster Assignment
cluster-ceph/cluster/*.sls 1

## Roles
# ADMIN
role-master/cluster/examplesesadmin.sls 2
role-admin/cluster/sesclient*.sls 3

# MON
role-mon/cluster/ses-example-[123].sls 4

# MGR
role-mgr/cluster/ses-example-[123].sls 5

# STORAGE
role-storage/cluster/ses-example-[5,6,7,8].sls 6

# MDS
role-mds/cluster/ses-example-4.sls 7

# IGW
role-igw/cluster/ses-example-4.sls 8

# RGW
role-rgw/cluster/ses-example-4.sls 9

# COMMON
config/stack/default/global.yml 10
config/stack/default/ceph/cluster.yml 11

1	Indica che tutti i minion sono inclusi nel cluster Ceph. Se sono presenti minion che non si desidera includere nel cluster Ceph, utilizzare: cluster-unassigned/cluster/.sls cluster-ceph/cluster/ses-example-.sls La prima riga indica tutti i minion come non assegnati. La seconda riga sovrascrive i minion che corrispondono a "ses-example-*.sls" e li assegna al cluster Ceph.
2	Il minion denominato "examplesesadmin" ha il ruolo "master", quindi ottiene le chiavi admin per il cluster.
3	Anche tutti i minion che corrispondono a "sesclient*" ottengono le chiavi admin.
4	Tutti i minion che corrispondono a "ses-example-[123]" (presumibilmente tre minion: ses-example-1, ses-example-2 e ses-example-3) vengono impostati come nodi MON.
5	Tutti i minion che corrispondono a "ses-example-[123]" (tutti i nodi MON nell'esempio) vengono impostati come nodi MGR.
6	Tutti i minion corrispondenti a "ses-example-[5,6,7,8]" verranno configurati come nodi di storage.
7	Il minion "ses-example-4" avrà il ruolo MDS.
8	Il minion "ses-example-4" avrà il ruolo IGW.
9	Il minion "ses-example-4" avrà il ruolo RGW.
10	Significa che si accettano i valori di default per i parametri di configurazione comuni come `fsid` e `public_network`.
11	Significa che si accettano i valori di default per i parametri di configurazione comuni come `fsid` e `public_network`.

5.5.2 DriveGroups #

I DriveGroups specificano i layout degli OSD nel cluster Ceph. Questi sono definiti in un singolo file /srv/salt/ceph/configuration/files/drive_groups.yml.

L'amministratore deve specificare manualmente un gruppo di OSD correlati tra di loro (OSD ibridi distribuiti su unità a stato solido e a rotazione) o condividere le stesse opzioni di distribuzione (ad esempio lo stesso archivio dati, la stessa opzione di cifratura, gli stessi OSD stand-alone). Per evitare di elencare esplicitamente i dispositivi, i DriveGroups utilizzano un elenco di elementi di filtro che corrispondono ad alcuni campi selezionati dei rapporti di archivio di ceph-volume. Nel caso più semplice, può ad esempio trattarsi del flag "rotational" (tutte le unità a stato solido devono essere dispositivi di database e quelle a rotazione dispositivi di dati) o un elemento più specifico, come le dimensioni o le stringhe "model". In DeepSea è fornito un codice che traduce tali DriveGroups in elenchi di dispositivi effettivi che l'utente potrà esaminare.

Di seguito è riportata una procedura di base in cui è illustrato il workflow di base durante la configurazione dei DriveGroups:

Esaminare le proprietà del disco in uso tramite il comando ceph-volume. Soltanto le proprietà seguenti sono accettate dai DriveGroups:
```
root@master # salt-run disks.details
```
Aprire il file YAML/srv/salt/ceph/configuration/files/drive_groups.yml e modificarlo in base alle esigenze. Vedere la Sezione 5.5.2.1, «Specifica». Ricordare di utilizzare gli spazi al posto dei caratteri di tabulazione. Nella Sezione 5.5.2.4, «Esempi» sono riportati esempi più avanzati. L'esempio seguente include tutte le unità disponibili per Ceph come OSD:
```
default_drive_group_name:
  target: '*'
  data_devices:
    all: true
```
Verificare i nuovi layout:
```
root@master # salt-run disks.list
```
Questo strumento di esecuzione restituisce una struttura di dischi corrispondenti basata sui DriveGroups. Se il risultato non è soddisfacente, ripetere il passaggio precedente.
Suggerimento: rapporto dettagliato
Oltre allo strumento di esecuzione disks.list, è disponibile uno strumento di esecuzione disks.report che stampa un rapporto dettagliato di ciò che si verifica quando viene richiamata la successiva fase 3 di DeepSea.
```
root@master # salt-run disks.report
```
Distribuire gli OSD. Quando viene richiamata la successiva fase 3 di DeepSea, i dischi OSD verranno distribuiti in base alla specifica del gruppo di unità.

5.5.2.1 Specifica #

/srv/salt/ceph/configuration/files/drive_groups.yml accetta le opzioni seguenti:

drive_group_default_name:
  target: *
  data_devices:
    drive_spec: DEVICE_SPECIFICATION
  db_devices:
    drive_spec: DEVICE_SPECIFICATION
  wal_devices:
    drive_spec: DEVICE_SPECIFICATION
  block_wal_size: '5G'  # (optional, unit suffixes permitted)
  block_db_size: '5G'   # (optional, unit suffixes permitted)
  osds_per_device: 1   # number of osd daemons per device
  format:              # 'bluestore' or 'filestore' (defaults to 'bluestore')
  encryption:           # 'True' or 'False' (defaults to 'False')

Nelle configurazioni FileStore, drive_groups.yml può avere l'aspetto seguente:

drive_group_default_name:
  target: *
  data_devices:
    drive_spec: DEVICE_SPECIFICATION
  journal_devices:
    drive_spec: DEVICE_SPECIFICATION
  format: filestore
  encryption: True

5.5.2.2 Creazione di corrispondenze dei dispositivi disco #

È possibile descrivere la specifica tramite i filtri seguenti:

In base al modello di disco:
```
model: DISK_MODEL_STRING
```
In base al produttore del disco:
```
vendor: DISK_VENDOR_STRING
```
Suggerimento: stringa del produttore in lettere minuscole
Scrivere sempre DISK_VENDOR_STRING in lettere minuscole.
Per indicare se si tratta di un disco rotativo o meno. Le unità SSD e NVME non sono rotative.
```
rotational: 0
```
Per distribuire un nodo utilizzando tutte le unità disponibili per gli OSD:
```
data_devices:
  all: true
```
Inoltre, tramite la limitazione del numero di dischi corrispondenti:
```
limit: 10
```

5.5.2.3 Aggiunta di filtri ai dispositivi in base alle dimensioni #

È possibile filtrare i dispositivi disco in base alle dimensioni (valore esatto o intervallo di dimensioni). Il parametro size: accetta gli argomenti nel formato seguente:

"10G" - include i dischi di dimensioni esatte.
"10G:40G" - include i dischi di dimensioni comprese nell'intervallo.
":10G" - include i dischi di dimensioni inferiori o uguali a 10 GB.
"40G" - include i dischi di dimensioni uguali o superiori a 40 GB.

Esempio 5.1: Corrispondenza in base alle dimensioni del disco #

drive_group_default:
  target: '*'
  data_devices:
    size: '40TB:'
  db_devices:
    size: ':2TB'

Nota: virgolette obbligatorie

Quando si utilizza il delimitatore ":", occorre racchiudere le dimensioni tra virgolette altrimenti il simbolo ":" verrà interpretato come un nuovo hash di configurazione.

Suggerimento: scorciatoie di unità

Invece di (G)igabyte, è possibile specificare le dimensioni anche in (M)egabyte o (T)erabyte.

5.5.2.4 Esempi #

Questa sezione include esempi di diverse configurazioni OSD.

Esempio 5.2: Configurazione semplice #

Questo esempio descrive due nodi con la stessa configurazione:

20 HDD
- Produttore: Intel
- Modello: SSD-123-foo
- Dimensioni: 4 TB
2 SSD
- Produttore: Micron
- Modello: MC-55-44-ZX
- Dimensioni: 512 GB

Il file drive_groups.yml corrispondente avrà l'aspetto seguente:

drive_group_default:
  target: '*'
  data_devices:
    model: SSD-123-foo
  db_devices:
    model: MC-55-44-XZ

Tale configurazione è semplice e valida. Tuttavia, in futuro un amministratore può aggiungere dischi di altri produttori che non verranno inclusi. È possibile ovviare a questo problema riducendo i filtri sulle proprietà di base delle unità:

drive_group_default:
  target: '*'
  data_devices:
    rotational: 1
  db_devices:
    rotational: 0

Nell'esempio precedente, viene forzata la dichiarazione di tutti i dispositivi a rotazione come "dispositivi di dati" e tutti i dispositivi non a rotazione verranno utilizzati come "dispositivi condivisi" (wal, db).

Presupponendo che le unità di più di 2 TB saranno sempre i dispositivi di dati più lenti, è possibile applicare dei filtri in base alle dimensioni:

drive_group_default:
  target: '*'
  data_devices:
    size: '2TB:'
  db_devices:
    size: ':2TB'

Esempio 5.3: Configurazione avanzata #

Questo esempio descrive due configurazioni diverse: 20 HDD devono condividere 2 SSD, mentre 10 SSD devono condividere 2 NVMe.

20 HDD
- Produttore: Intel
- Modello: SSD-123-foo
- Dimensioni: 4 TB
12 SSD
- Produttore: Micron
- Modello: MC-55-44-ZX
- Dimensioni: 512 GB
2 NVMe
- Produttore: Samsung
- Modello: NVME-QQQQ-987
- Dimensioni: 256 GB

È possibile definire tale configurazione con due layout come segue:

drive_group:
  target: '*'
  data_devices:
    rotational: 0
  db_devices:
    model: MC-55-44-XZ

drive_group_default:
  target: '*'
  data_devices:
    model: MC-55-44-XZ
  db_devices:
    vendor: samsung
    size: 256GB

Esempio 5.4: Configurazione avanzata con nodi non uniformi #

Gli esempi precedenti sono basati sul presupposto che tutti i nodi dispongano delle stesse unità. Tuttavia, non è sempre questo il caso:

Nodi da 1 a 5:

20 HDD
- Produttore: Intel
- Modello: SSD-123-foo
- Dimensioni: 4 TB
2 SSD
- Produttore: Micron
- Modello: MC-55-44-ZX
- Dimensioni: 512 GB

Nodi da 6 a 10:

5 NVMe
- Produttore: Intel
- Modello: SSD-123-foo
- Dimensioni: 4 TB
20 SSD
- Produttore: Micron
- Modello: MC-55-44-ZX
- Dimensioni: 512 GB

È possibile utilizzare la chiave "target" nel layout per indirizzare nodi specifici. La notazione della destinazione Salt consente di non complicare la configurazione:

drive_group_node_one_to_five:
  target: 'node[1-5]'
  data_devices:
    rotational: 1
  db_devices:
    rotational: 0

seguito da

drive_group_the_rest:
  target: 'node[6-10]'
  data_devices:
    model: MC-55-44-XZ
  db_devices:
    model: SSD-123-foo

Esempio 5.5: Configurazione esperta #

In tutti i casi descritti in precedenza si presupponeva che i WAL e i DB utilizzassero lo stesso dispositivo. È tuttavia possibile anche distribuire i WAL su un dispositivo dedicato:

20 HDD
- Produttore: Intel
- Modello: SSD-123-foo
- Dimensioni: 4 TB
2 SSD
- Produttore: Micron
- Modello: MC-55-44-ZX
- Dimensioni: 512 GB
2 NVMe
- Produttore: Samsung
- Modello: NVME-QQQQ-987
- Dimensioni: 256 GB

drive_group_default:
  target: '*'
  data_devices:
    model: MC-55-44-XZ
  db_devices:
    model: SSD-123-foo
  wal_devices:
    model: NVME-QQQQ-987

Esempio 5.6: Configurazione complessa (e improbabile) #

Nella configurazione seguente, si tenterà di definire:

20 HDD supportati da 1 NVMe
2 HDD supportati da 1 SSD (db) e 1 NVMe (wal)
8 SSD supportati da 1 NVMe
2 SSD stand-alone (cifrati)
1 HDD è di riserva e non deve essere distribuito.

Di seguito è riportato il riepilogo delle unità utilizzate:

23 HDD
- Produttore: Intel
- Modello: SSD-123-foo
- Dimensioni: 4 TB
10 SSD
- Produttore: Micron
- Modello: MC-55-44-ZX
- Dimensioni: 512 GB
1 NVMe
- Produttore: Samsung
- Modello: NVME-QQQQ-987
- Dimensioni: 256 GB

La definizione dei DriveGroups sarà la seguente:

drive_group_hdd_nvme:
  target: '*'
  data_devices:
    rotational: 0
  db_devices:
    model: NVME-QQQQ-987

drive_group_hdd_ssd_nvme:
  target: '*'
  data_devices:
    rotational: 0
  db_devices:
    model: MC-55-44-XZ
  wal_devices:
    model: NVME-QQQQ-987

drive_group_ssd_nvme:
  target: '*'
  data_devices:
    model: SSD-123-foo
  db_devices:
    model: NVME-QQQQ-987

drive_group_ssd_standalone_encrypted:
  target: '*'
  data_devices:
    model: SSD-123-foo
  encryption: True

Rimarrà un'unità HDD, poiché il file viene analizzato dall'alto verso il basso.

5.5.3 Regolazione di `ceph.conf` tramite le impostazioni personalizzate #

Se occorre inserire impostazioni personalizzate nel file di configurazione ceph.conf, per ulteriori informazioni, vedere Sezione 2.13, «Regolazione di ceph.conf tramite le impostazioni personalizzate».

Stampa pagina