NFS Ganesha fornisce accesso NFS a Object Gateway o a CephFS. In SUSE Enterprise Storage 5, sono supportate le versioni NFS 3 e 4. NFS Ganesha viene eseguito nello spazio utente invece che nello spazio kernel e interagisce direttamente con l'Object Gateway o CephFS.
Per installare correttamente NFS Ganesha, occorre aggiungere un role-ganesha
a /srv/pillar/ceph/proposals/policy.cfg
. Per informazioni, vedere Sezione 4.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 4.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 14.2, «Configurazione».
Prima di poter eseguire le fasi 2 e 4 di DeepSea per installare NFS Ganesha, occorre soddisfare i seguenti requisiti:
Almeno un nodo deve essere assegnato a role-ganesha
.
È possibile definire solo un role-ganesha
per minion.
Per il funzionamento, NFS Ganesha richiede un Object Gateway o CephFS.
Se NFS Ganesha deve utilizzare l'Object Gateway per interfacciarsi con il cluster, specificare /srv/pillar/ceph/rgw.sls
sul Salt master.
Questa procedura fornisce un'installazione di esempio che utilizza l'Object Gateway e CephFS File System Abstraction Layers (FSAL) di NFS Ganesha.
Se non è già stato fatto, eseguire le fasi 0 e 1 di DeepSea prima di continuare con questa procedura.
root #
salt-run
state.orch ceph.stage.0root #
salt-run
state.orch ceph.stage.1
Dopo aver eseguito la fase 1 di DeepSea, modificare /srv/pillar/ceph/proposals/policy.cfg
e aggiungere la riga
role-ganesha/cluster/NODENAME
Sostituire NODENAME con il nome di un nodo nel cluster.
Accertare inoltre che siano assegnati un role-mds
e un role-rgw
.
Creare il file /srv/pillar/ceph/rgw.sls
e inserire il contenuto seguente:
rgw_configurations: rgw: users: - { uid: "demo", name: "Demo", email: "demo@demo.nil" } - { uid: "demo1", name: "Demo1", email: "demo1@demo.nil" }
Questi utenti vengono creati in seguito come utenti di Object Gateway e vengono generate le chiavi API. Sul nodo Object Gateway, è possibile eseguire in seguito radosgw-admin user list
per elencare tutti gli utenti creati e radosgw-admin user info --uid=demo
per ottenere dettagli sui singoli utenti.
DeepSea accerta che l'Object Gateway e NFS Ganesha ricevano entrambi le credenziali di tutti gli utenti elencati nella sezione rgw
di rgw.sls
.
Il NFS esportato utilizza tali nomi utente sul primo livello del file system, in questo esempio vengono esportati i percorsi /demo
e /demo1
.
Eseguire almeno le fasi 2 e 4 di DeepSea. Si consiglia l'esecuzione della fase 3 tra le altre due fasi.
root #
salt-run
state.orch ceph.stage.2root #
salt-run
state.orch ceph.stage.3 # optional but recommendedroot #
salt-run
state.orch ceph.stage.4
Verificare che NFS Ganesha funzioni montando la condivisione NFS da un nodo client:
root #
mount
-o sync -t nfs GANESHA_NODE:/ /mntroot #
ls
/mnt cephfs demo demo1
/mnt
deve contenere tutti i percorsi esportati. Le directory degli utenti di CephFS e Object Gateway devono essere esistenti. Per ogni bucket posseduto da un utente, viene esportato un percorso /mnt/USERNAME/BUCKETNAME
.
Questa sezione fornisce un esempio di come impostare una configurazione attiva-passiva a due nodi dei server NFS Ganesha. La configurazione richiede SUSE Linux Enterprise High Availability Extension. I due nodi sono denominati earth
e mars
.
Per informazioni su SUSE Linux Enterprise High Availability Extension, vedere https://www.suse.com/documentation/sle-ha-12/.
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-12/install-quick/data/install-quick.html.
Preparare i nodi NFS Ganesha sul Salt master:
Eseguire le fasi 0 e 1 di DeepSea sul Salt master.
root@master #
salt-run
state.orch ceph.stage.0root@master #
salt-run
state.orch ceph.stage.1
Assegnare ai nodi earth
e mars
il role-ganesha
in /srv/pillar/ceph/proposals/policy.cfg
:
role-ganesha/cluster/earth*.sls role-ganesha/cluster/mars*.sls
Eseguire le fasi 3 e 4 di DeepSea sul Salt master.
root@master #
salt-run
state.orch ceph.stage.3root@master #
salt-run
state.orch ceph.stage.4
Registrare SUSE Linux Enterprise High Availability Extension su earth
e mars
.
root #
SUSEConnect
-r ACTIVATION_CODE -e E_MAIL
Installare ha-cluster-bootstrap su entrambi i nodi:
root #
zypper
in ha-cluster-bootstrap
Inizializzare il cluster su earth
:
root@earth #
ha-cluster-init
Lasciare che mars
si unisca al cluster:
root@mars #
ha-cluster-join
-c earth
Verificare lo stato del cluster. Si dovrebbero vedere due nodi aggiunti al cluster:
root@earth #
crm
status
Su entrambi i nodi, disabilitare l'avvio automatico del servizio NFS Ganesha durante il boot:
root #
systemctl
disable nfs-ganesha
Avviare la shell crm
su earth
:
root@earth #
crm
configure
I comandi successivi vengono eseguiti nella shell crm.
Su earth
, avviare la shell crm per eseguire i comandi indicati per configurare la risorsa per i daemon NFS Ganesha come cloni del tipo di risorsa systemd:
crm(live)configure#
primitive nfs-ganesha-server systemd:nfs-ganesha \ op monitor interval=30scrm(live)configure#
clone nfs-ganesha-clone nfs-ganesha-server meta interleave=truecrm(live)configure#
commitcrm(live)configure#
status 2 nodes configured 2 resources configured Online: [ earth mars ] Full list of resources: Clone Set: nfs-ganesha-clone [nfs-ganesha-server] Started: [ earth mars ]
Creare un IPAddr2 primitivo con la shell crm:
crm(live)configure#
primitive ganesha-ip IPaddr2 \ params ip=192.168.2.1 cidr_netmask=24 nic=eth0 \ op monitor interval=10 timeout=20crm(live)#
status Online: [ earth mars ] Full list of resources: Clone Set: nfs-ganesha-clone [nfs-ganesha-server] Started: [ earth mars ] ganesha-ip (ocf::heartbeat:IPaddr2): Started earth
Per configurare una relazione tra il server NFS Ganesha e l'IP virtuale mobile, si utilizza collocazione e ordinamento.
crm(live)configure#
colocation ganesha-ip-with-nfs-ganesha-server inf: ganesha-ip nfs-ganesha-clonecrm(live)configure#
order ganesha-ip-after-nfs-ganesha-server Mandatory: nfs-ganesha-clone ganesha-ip
Utilizzare il comando mount
dal client per assicurare che la configurazione del cluster sia completa:
root #
mount
-t nfs -v -o sync,nfsvers=4 192.168.2.1:/ /mnt
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 earthroot@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.
Definire la risorsa di ping:
crm(live)configure#
primitive ganesha-ping ocf:pacemaker:ping \
params name=ping dampen=3s multiplier=100 host_list="CLIENT1 CLIENT2" \
op monitor interval=60 timeout=60 \
op start interval=0 timeout=60 \
op stop interval=0 timeout=60
host_list
è un elenco di indirizzi IP separati da spazi. Viene eseguito regolarmente il ping sugli indirizzi IP per controllare eventuali indisponibilità di rete. Se un client deve sempre avere accesso al server NFS, aggiungerlo a host_list
.
Creare un clone:
crm(live)configure#
clone ganesha-ping-clone ganesha-ping \
meta interleave=true
Il comando seguente consente di creare un vincolo per il servizio NFS Ganesha. Forza il servizio a spostarsi su un altro nodo quando host_list
non è raggiungibile.
crm(live)configure#
location nfs-ganesha-server-with-ganesha-ping
nfs-ganesha-clone \
rule -inf: not_defined ping or ping lte 0
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 avvio e arresto del servizio NFS Ganesha dalla Fase 4 di DeepSea:
Copiare /srv/salt/ceph/ganesha/default.sls
in /srv/salt/ceph/ganesha/ha.sls
.
Rimuovere la voce .service
da /srv/salt/ceph/ganesha/ha.sls
in modo che abbia l'aspetto seguente:
include: - .keyring - .install - .configure
Aggiungere la riga seguente a /srv/pillar/ceph/stack/global.yml
:
ganesha_init: ha
Ulteriori informazioni sono disponibili all'indirizzo Capitolo 14, NFS Ganesha: esportazione dei dati Ceph tramite NFS.