Saltar al contenutoSaltar alla navigazione delle pagine: pagina precedente [chiave d’accesso p]/pagina successiva [chiave d’accesso n]
Si applica a SUSE Enterprise Storage 5

13 File system in cluster

In questo capitolo sono descritti i task amministrativi che di norma vengono eseguiti dopo la configurazione del cluster e l'esportazione di CephFS. Per ulteriori informazioni sulla configurazione di CephFS, fare riferimento a Capitolo 11, Installazione di CephFS.

13.1 Montaggio di CephFS

Una volta creato il file system ed MDS è attivo, si è pronti per montare il file da un host client.

13.1.1 Preparazione del client

Se sull'host client è in esecuzione SUSE Linux Enterprise 12 SP2 o SP3, è possibile ignorare questa sezione in quanto il sistema è pronto per il montaggio di CephFS senza alcuna configurazione aggiuntiva.

Se sull'host client è in esecuzione SUSE Linux Enterprise 12 SP1, è necessario applicare le patch più recenti prima di montare CephFS.

In ogni caso, tutto il necessario per montare CephFS è incluso in SUSE Linux Enterprise. Non è necessario il prodotto SUSE Enterprise Storage.

Per supportare la sintassi mount completa, è necessario installare il pacchetto ceph-common (fornito in dotazione con SUSE Linux Enterprise) prima di tentare di montare CephFS.

13.1.2 Creazione di un file segreto

Per default, quando il cluster Ceph è in esecuzione l'autenticazione è attivata. È necessario creare un file in cui archiviare la chiave segreta (non il portachiavi stesso). Per ottenere la chiave segreta per un determinato utente e creare il file, procedere come indicato di seguito:

Procedura 13.1: Creazione di una chiave segreta
  1. Visualizzare la chiave per l'utente specificato in un file portachiavi:

    cat /etc/ceph/ceph.client.admin.keyring
  2. Copiare la chiave dell'utente che utilizzerà il file system Ceph FS montato. Di norma, la chiave è simile a quanto riportato di seguito:

    AQCj2YpRiAe6CxAA7/ETt7Hcl9IyxyYciVs47w==
  3. Creare un file in cui il nome utente costituisce parte del nome file, ad esempio /etc/ceph/admin.secret per l'utente admin.

  4. Incollare il valore della chiave nel file creato al passaggio precedente.

  5. Impostare i diritti di accesso al file appropriati. L'utente deve essere il solo in grado di leggere il file, gli altri non possono avere alcun diritto di accesso.

13.1.3 Montaggio di CephFS

È possibile montare CephFS utilizzando il comando mount. È necessario specificare il nome host di monitoraggio o l'indirizzo IP. Poiché in SUSE Enterprise Storage l'autenticazione cephx è abilitata per default, è necessario specificare un nome utente e il rispettivo segreto:

sudo mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \
 -o name=admin,secret=AQATSKdNGBnwLhAAnNDKnH65FmVKpXZJVasUeQ==

Dato che il comando precedente rimane nella cronologia shell, la lettura del segreto da un file rappresenta un approccio più sicuro:

sudo mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \
 -o name=admin,secretfile=/etc/ceph/admin.secret

Il file segreto deve contenere solo il segreto del portachiavi effettivo. Nell'esempio, il file conterrà quindi solo la riga seguente:

AQATSKdNGBnwLhAAnNDKnH65FmVKpXZJVasUeQ==
Suggerimento
Suggerimento: specificare più monitoraggi

Qualora uno dei monitoraggi dovesse essere inattivo al momento del montaggio, è buona prassi specificare più monitoraggi separati da virgole nella riga di comando mount. Ciascun indirizzo di monitoraggio si presenta nella forma host[:port]. Se non si specifica la porta, per default viene utilizzata la 6789.

Creare il punto di montaggio nell'host locale:

sudo mkdir /mnt/cephfs

Montaggio di CephFS:

sudo mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \
 -o name=admin,secretfile=/etc/ceph/admin.secret

Se è necessario montare un sottoinsieme del file system, è possibile specificare una sottodirectory subdir:

sudo mount -t ceph ceph_mon1:6789:/subdir /mnt/cephfs \
 -o name=admin,secretfile=/etc/ceph/admin.secret

È possibile specificare più host di monitoraggio nel comando mount:

sudo mount -t ceph ceph_mon1,ceph_mon2,ceph_mon3:6789:/ /mnt/cephfs \
 -o name=admin,secretfile=/etc/ceph/admin.secret
Importante
Importante: accesso in lettura alla directory radice

Se si utilizzano client con restrizioni di percorso, tra le funzionalità MDS deve essere incluso l'accesso in lettura alla directory radice. Ad esempio, un portachiavi potrebbe presentare l'aspetto seguente:

client.bar
 key: supersecretkey
 caps: [mds] allow rw path=/barjail, allow r path=/
 caps: [mon] allow r
 caps: [osd] allow rwx

la parte allow r path=/ significa che i client con restrizioni di percorso sono in grado di leggere il volume radice, ma non di scriverlo. Nei casi di utilizzo in cui l'isolamento completo è un requisito, ciò può rappresentare un problema.

13.2 Smontaggio di CephFS

Per smontare CephFS, utilizzare il comando umount:

sudo umount /mnt/cephfs

13.3 CephFS in /etc/fstab

Per montare CephFS automaticamente all'avvio del client, inserire la riga corrispondente nella rispettiva tabella dei file system /etc/fstab:

mon1:6790,mon2:/subdir /mnt/cephfs ceph name=admin,secretfile=/etc/ceph/secret.key,noatime,_netdev 0 2

13.4 Più daemon MDS attivi (MDS attivo-attivo)

Per default CephFS è configurato per un unico daemon MDS attivo. Per adattare le prestazioni dei metadati a sistemi su larga scala, è possibile abilitare più daemon MDS attivi in modo che il workload dei metadati venga condiviso con un altro.

13.4.1 Quando utilizzare MDS attivo-attivo

Quando le prestazioni dei metadati sull'MDS singolo di default si bloccano, prendere in considerazione l'eventualità di utilizzare più daemon MDS attivi.

L'aggiunta di ulteriori daemon non migliora le prestazioni su tutti i tipi di workload. Ad esempio, una singola applicazione in esecuzione su un unico client non sarà avvantaggiata da un maggior numero di daemon MDS, a meno che l'applicazione non esegua parallelamente molte operazioni di metadati.

I workload che di norma traggono vantaggi da un maggior numero di daemon MDS attivi sono quelli provvisti di numerosi client, che magari funzionano su molte directory separate.

13.4.2 Aumento delle dimensioni del cluster attivo MDS

Ciascun file system CephFS presenta un'impostazione max_mds che controlla il numero di livelli che saranno creati. Il numero di livelli effettivo nel file system aumenterà solo se è disponibile un daemon di riserva da inserire nel nuovo livello. Se ad esempio è in esecuzione un solo daemon MDS e max_mds è impostato su due, non verrà creato un secondo livello.

Nell'esempio seguente, l'opzione max_mds viene impostata a 2 per creare un nuovo livello oltre a quello di default. Per visualizzare le modifiche, eseguire ceph status prima di impostare max_mds, quindi osservare la riga contenente fsmap:

root@master # ceph status
  [...]
  services:
    [...]
    mds: cephfs-1/1/1 up  {0=node2=up:active}, 1 up:standby
    [...]
root@master # ceph mds set max_mds 2
root@master # ceph status
  [...]
  services:
    [...]
    mds: cephfs-2/2/2 up  {0=node2=up:active,1=node1=up:active}
    [...]

Il livello appena creato (1) passa dallo stato "creating" al rispettivo stato "active".

Importante
Importante: daemon in standby

Anche con più daemon MDS attivi, in un sistema altamente disponibile è comunque richiesto che vengano impiegati daemon in standby se i server in esecuzione su un daemon attivo vengono meno.

Di conseguenza, il numero massimo effettivo di max_mds per i sistemi altamente disponibili è uno in meno rispetto al numero totale di server MDS presenti nel sistema. Per garantire la disponibilità qualora si verificassero più errori di server, aumentare il numero di daemon in standby nel sistema in modo che corrisponda al numero di errori di server necessario per poter rimanere attivi.

13.4.3 Riduzione del numero di livelli

Tutti i livelli, inclusi quelli da rimuovere, devono prima essere attivi. Vale a dire che è necessario disporre di almeno max_mds daemon MDS disponibili.

In primo luogo, impostare max_mds a un numero inferiore. Ad esempio, tornare a un singolo MDS attivo:

root@master # ceph status
  [...]
  services:
    [...]
    mds: cephfs-2/2/2 up  {0=node2=up:active,1=node1=up:active}
    [...]
root@master # ceph mds set max_mds 1
root@master # ceph status
  [...]
  services:
    [...]
    mds: cephfs-1/1/1 up  {0=node2=up:active}, 1 up:standby
    [...]

Si noti che sono ancora presenti due MDS attivi. I livelli continuano a esistere nonostante la riduzione di max_mds, perché max_mds limita solo la creazione di nuovi livelli.

Successivamente, utilizzare il comando ceph mds deactivate rank per rimuovere il livello non necessario:

root@master # ceph status
  [...]
  services:
    [...]
    mds: cephfs-2/2/1 up  {0=node2=up:active,1=node1=up:active}
root@master # ceph mds deactivate 1
telling mds.1:1 192.168.58.101:6805/2799214375 to deactivate

root@master # ceph status
  [...]
  services:
    [...]
    mds: cephfs-2/2/1 up  {0=node2=up:active,1=node1=up:stopping}

root@master # ceph status
  [...]
  services:
    [...]
    mds: cephfs-1/1/1 up  {0=node2=up:active}, 1 up:standby

Il livello disattivato passerà allo stato interrotto per un periodo di tempo, mentre distribuisce la rispettiva parte di metadati ai rimanenti daemon attivi. Questa fase può durare da pochi secondi fino ad alcuni minuti. Se sembra che MDS sia bloccato allo stato di interruzione, potrebbe trattarsi di un possibile bug ed è opportuno indagare in merito.

Se un daemon MDS si blocca o viene terminato mentre si trova in stato "stopping", un daemon in standby verrà impiegato al suo posto e lo stato tornerà ad essere "active". Una volta tornato attivo, sarà possibile tentare nuovamente di disattivarlo.

Quando un daemon non è più in stato di interruzione, viene riavviato e torna in standby.

13.4.4 Aggiunta manuale di un albero della Directory a un livello

Per distribuire uniformemente il carico dei metadati nel cluster in configurazioni con vari server di metadati attivi, viene eseguito un bilanciamento. Di norma, questo metodo risulta sufficientemente efficace per la maggior parte degli utenti, ma talvolta è auspicabile sostituire il bilanciamento dinamico con mappature esplicite dei metadati in determinati livelli. In tal modo l'amministratore o gli utenti possono distribuire uniformemente il carico di applicazioni o limitare l'impatto delle richieste di metadati degli utenti sull'intero cluster.

Il meccanismo fornito a tale scopo è denominato "pin di esportazione". Si tratta di un attributo esteso delle directory il cui nome è ceph.dir.pin. Gli utenti possono impostare questo attributo mediante l'uso di comandi standard:

setfattr -n ceph.dir.pin -v 2 /path/to/dir

Il valore (-v) dell'attributo esteso corrisponde al livello cui assegnare il sottoalbero della directory. Un valore di default pari a -1 indica che la directory non è stata aggiunta.

La directory superiore più vicina con pin di esportazione impostato, eredita il pin. Pertanto, l'impostazione del pin di esportazione in una directory influisce su tutte le rispettive directory secondarie. Il pin della directory superiore può essere sostituito impostando il pin di esportazione della directory secondaria. Ad esempio:

mkdir -p a/b                      # "a" and "a/b" start with no export pin set.
setfattr -n ceph.dir.pin -v 1 a/  # "a" and "b" are now pinned to rank 1.
setfattr -n ceph.dir.pin -v 0 a/b # "a/b" is now pinned to rank 0
                                  # and "a/" and the rest of its children
                                  # are still pinned to rank 1.

13.5 Gestione del failover

Se un daemon MDS smette di comunicare con il monitoraggio, questo attenderà mds_beacon_grace secondi (valore di default 15 secondi) prima di contrassegnare il daemon come lento. È possibile configurare uno o più daemon "in standby" che verranno impiegati durante il failover del daemon MDS.

13.5.1 Configurazione dei daemon in standby

Esistono diverse impostazioni di configurazione che consentono di controllare il comportamento di un daemon in standby. È possibile specificarle in ceph.conf nell'host in cui viene eseguito il daemon MDS. Tali impostazioni vengono caricate dal daemon al suo avvio e vengono inviate al monitoraggio.

Per default, se non si utilizza alcuna di queste impostazioni, tutti i daemon MDS privi di livelli verranno utilizzati come "standby" per qualsiasi livello.

Le impostazioni che associano un daemon in standby a un determinato nome o livello non garantiscono che il daemon verrà utilizzato solo per il livello specificato. Vale a dire che quando sono disponibili più daemon in standby, viene utilizzato quello associato. Se un livello risulta impossibile ed è disponibile uno standby, verrà utilizzato quest'ultimo anche se è associato a un livello a un daemon con nome diverso.

mds_standby_replay

Se impostata su true, il daemon in standby leggerà continuamente il journal dei metadati di un livello attivo. In tal modo si otterrà una cache dei metadati approntata e si velocizzerà il processo di failover se il daemon che serve il livello viene meno.

A un livello attivo è possibile assegnare un solo daemon di riproduzione in standby. Se due daemon sono entrambi impostati per la riproduzione in standby, uno di essi sarà arbitrariamente prioritario e l'altro diventerà un normale daemon in standby non di riproduzione.

Un daemon che entra in stato di riproduzione in standby, verrà utilizzato come standby per il livello successivo. Se un altro livello risulta impossibile, il daemon di riproduzione in standby non verrà utilizzato come sostituto, anche se non ve ne sono altri in standby disponibili.

mds_standby_for_name

Configurare questa impostazione per fare in modo che il daemon in standby venga impiegato al posto di un livello non riuscito se l'ultimo daemon che lo contiene corrisponde a tale nome.

mds_standby_for_rank

Configurare questa impostazione per fare in modo che il daemon in standby venga impiegato al posto del livello specificato. Se un altro livello risulta impossibile, non verrà utilizzato il daemon per sostituirlo.

Utilizzare insieme a mds_standby_for_fscid per specificare il livello del file system desiderato nel caso di più file system.

mds_standby_for_fscid

Se mds_standby_for_rank è impostata, questa impostazione è un semplice qualificatore che indica a quale livello del file system si fa riferimento.

Se mds_standby_for_rank non è impostata, l'impostazione di FSCID farà in modo che il daemon consideri come destinazione qualsiasi livello nell'FSCID specificato. Utilizzare questa impostazione se si desidera utilizzare un daemon per qualsiasi livello, ma solo in un determinato file system.

mon_force_standby_active

Questa impostazione viene utilizzata sugli host di monitoraggio. Per default è su true.

Se viene impostata su false, i daemon configurati con standby_replay=true diventeranno attivi solo se il livello/nome per il quale sono stati configurati risulta impossibile. D'altro canto, se questa impostazione è su true, è possibile che un daemon configurato con standby_replay=true venga assegnato a un altro livello.

13.5.2 Esempi

Di seguito sono riportati diversi esempi di configurazioni ceph.conf. Sarà quindi possibile applicare a tutti i server la configurazione ceph.conf e quella dei daemon oppure disporre di un file diverso su ciascun server contenente la configurazione di deamon di un server specifico.

13.5.2.1 Coppia semplice

Due daemon MDS "a" e "b" agiscono in coppia. Quello cui attualmente non è assegnato un livello diventerà il daemon di riproduzione in standby successivo.

[mds.a]
mds standby replay = true
mds standby for rank = 0

[mds.b]
mds standby replay = true
mds standby for rank = 0
Stampa pagina