Per installare correttamente NFS Ganesha, occorre aggiungere un role-ganesha a /srv/pillar/ceph/proposals/policy.cfg. Per informazioni, vedere Sezione 5.5.1, «Il file policy.cfg». NFS Ganesha richiede inoltre un role-rgw o un role-mds presente in policy.cfg.

Sebbene sia possibile installare ed eseguire il server NFS Ganesha su un nodo Ceph già esistente, si consiglia di eseguirlo su un host dedicato con accesso al cluster Ceph. Gli host client non fanno in genere parte del cluster, ma devono avere accesso di rete al server NFS Ganesha.

Per abilitare il server NFS Ganesha in qualsiasi punto dopo l'installazione iniziale, aggiungere role-ganesha a policy.cfg e ripetere almeno le fasi 2 e 4 di DeepSea. Per informazioni, vedere Sezione 5.3, «Distribuzione del cluster».

NFS Ganesha è configurato tramite il file /etc/ganesha/ganesha.conf esistente sul nodo NFS Ganesha. Tuttavia, tale file viene sovrascritto ogni volta che si esegue la fase 4 di DeepSea. Perciò si consiglia di modificare il modello utilizzato da Salt, ossia il file /srv/salt/ceph/ganesha/files/ganesha.conf.j2 sul Salt master. Per informazioni sul file di configurazione, vedere Sezione 21.2, «Configurazione».

Prima di poter eseguire le fasi 2 e 4 di DeepSea per installare NFS Ganesha, occorre soddisfare i seguenti requisiti:

In questa configurazione earth ha l'indirizzo IP 192.168.1.1 e mars l'indirizzo 192.168.1.2.

Inoltre, vengono utilizzati due indirizzi IP virtuali mobili che consentono ai client di connettersi al servizio indipendentemente dal nodo fisico sul quale è in esecuzione. 192.168.1.10 è utilizzato per amministrazione del cluster con Hawk2 e 192.168.2.1 esclusivamente per esportazioni NFS. Ciò semplifica la successiva applicazione delle limitazioni di sicurezza.

La procedura seguente descrive l'installazione di esempio. Ulteriori informazioni sono disponibili all'indirizzo https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/art_sleha_install_quick.html.

Nel caso di errore di NFS Ganesha in uno dei nodi, ad esempio earth, risolvere il problema ed effettuare la pulizia della risorsa. Solo dopo aver effettuato la pulizia, la risorsa può riposizionarsi in sicurezza su earth in caso di errore di NFS Ganesha su mars.

Per effettuare la pulizia della risorsa:

root@earth # crm resource cleanup nfs-ganesha-clone earth
root@earth # crm resource cleanup ganesha-ip earth

In alcune situazioni, il server potrebbe non essere in grado di raggiungere il client a causa di un problema di rete. Una risorsa di ping può rilevare e mitigare questo problema. La configurazione della risorsa è facoltativa.

DeepSea non supporta la configurazione HA (alta disponibilità) di NFS Ganesha. Per impedire a DeepSea di andare in errore dopo aver configurato HA di NFS Ganesha, escludere l'avvio e l'interruzione del servizio NFS Ganesha dalla fase 4 di DeepSea:

Per questa configurazione di esempio, è necessario quanto segue:

Dopo aver distribuito i nodi NFS Ganesha, verificare che il cluster sia operativo e che i pool CephFS di default siano presenti:

cephadm@adm > rados lspools
cephfs_data
cephfs_metadata

Controllare che su entrambi i nodi NFS Ganesha si installato il file/etc/ganesha/ganesha.conf. Aggiungere i blocchi seguenti, se non ancora esistenti, al file di configurazione per abilitare RADOS come back-end di recupero di NFS Ganesha.

NFS_CORE_PARAM
{
    Enable_NLM = false;
    Enable_RQUOTA = false;
    Protocols = 4;
}
NFSv4
{
    RecoveryBackend = rados_cluster;
    Minor_Versions = 1,2;
}
CACHEINODE {
    Dir_Chunk = 0;
    NParts = 1;
    Cache_Size = 1;
}
RADOS_KV
{
    pool = "rados_pool";
    namespace = "pool_namespace";
    nodeid = "fqdn"
    UserId = "cephx_user_id";
    Ceph_Conf = "path_to_ceph.conf"
}

È possibile individuare i valori di rados_pool e pool_namespace controllando la riga già esistente nella configurazione del modulo:

%url rados://rados_pool/pool_namespace/...

Il valore dell'opzione nodeid corrisponde all'FQDN del computer e il valore delle opzioni UserId e Ceph_Conf può essere individuato nel blocco RADOS_URLS già esistente.

Le opzioni di NFS precedenti alla versione 4.2 sono disabilitate poiché tali versioni legacy di NFS impediscono la revoca della moratoria in una fase precedente, prolungando di conseguenza un riavvio del server. Inoltre, è disabilitata anche la maggior parte delle funzioni di memorizzazione nella cache di NFS Ganesha poiché le librerie Ceph eseguono già una memorizzazione aggressiva nella cache.

Il back-end di recupero "rados_cluster" memorizza le relative informazioni negli oggetti RADOS. Sebbene non si tratti di un'elevata quantità di dati, è preferibile impostarlo come altamente disponibile. A tal fine, viene utilizzato il pool di metadati CephFS all'interno del quale viene dichiarato un nuovo spazio dei nomi "ganesha" per distinguerlo dagli oggetti CephFS.

Nota: ID del nodo del cluster

La maggior parte delle impostazioni di configurazione è identica per i due host, tuttavia l'opzione nodeid nel blocco "RADOS_KV" deve essere una stringa univoca per ciascun nodo. Per default, NFS Ganesha imposta nodeid sul nome host del nodo.

Se è necessario utilizzare valori fissi diversi dai nomi host, è possibile ad esempio impostare nodeid = 'a' su un nodo e nodeid = 'b' sull'altro.

È necessario verificare che tutti i nodi nel cluster siano consapevoli della reciproca esistenza. Per farlo, ci si serve di un oggetto RADOS condiviso tra gli host. NFS Ganesha utilizza tale oggetto per comunicare lo stato corrente relativamente a una moratoria.

Il pacchetto nfs-ganesha-rados-grace contiene uno strumento a riga di comando per l'interrogazione e la gestione di questo database. Se il pacchetto non è installato su almeno uno dei nodi, installarlo con

root # zypper install nfs-ganesha-rados-grace

Verrà utilizzato il comando per creare il DB e aggiungere entrambi i nodeid. Nell'esempio, i due nodi NFS Ganesha sono denominati ses6min1.example.com e ses6min2.example.com. Su uno degli host NFS Ganesha, eseguire

cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min1.example.com
cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min2.example.com
cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha
cur=1 rec=0
======================================================
ses6min1.example.com     E
ses6min2.example.com     E

Questa procedura consente di creare il database extra e di aggiungervi "ses6min1.example.com" e "ses6min2.example.com". L'ultimo comando consente di eseguire il dump dello stato corrente. Si presuppone sempre che gli host appena aggiunti applichino la moratoria e di conseguenza viene impostato per entrambi il flag "E". I valori "cur" e "rec" indicano rispettivamente le epoche attuale e di recupero, tramite cui è possibile tenere traccia degli host a cui è consentito eseguire il recupero e quando.

Su entrambi i nodi NFS Ganesha, riavviare i servizi correlati:

root # systemctl restart nfs-ganesha.service

In seguito al riavvio dei servizi, controllare il database extra:

cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha
cur=3 rec=0
======================================================
ses6min1.example.com
ses6min2.example.com

Nota: flag "E" cancellato

Notare che il flag "E" è stato cancellato da entrambi i nodi per indicare che questi non applicano più la moratoria e che si trovano adesso in modalità di funzionamento normale.

Dopo aver completato tutti i passaggi precedenti, è possibile montare l'NFS esportato da uno dei due server NFS Ganesha ed eseguirvi le normali operazioni NFS.

Nella configurazione di esempio si presuppone che se uno dei due server NFS diventa inattivo, verrà riavviato manualmente dall'utente entro 5 minuti. Dopo questo intervallo di tempo, il server di metadati potrebbe annullare la sessione messa in attesa dal client NFS Ganesha e tutto lo stato a questa associato. Se le capacità della sessione vengono annullate prima che il resto del cluster entri nella moratoria, i client del server potrebbero non essere in grado di recuperare tutto il relativo stato.