Il servizio permette di esportare un filesystem CephFS o un bucket RadosGW attraverso protocollo NFS 4.
L'erogazione vera e propria avviene attraverso un cluster Ganesha NFS che media l'accesso ai dati sugli OSD e ai metadati del MDS.
Assumendo di disporre di un cluster CEPH operativo, per il deploy dei relativi daemon è possibile seguire i seguenti passi:
1. Applicare una label (di seguito verrà utilizzata una label nfsgw) a tutti gli host che dovranno ospitare i relativi daemon:
ceph orch host label add <host1> nfs ... ceph orch host label add <hostn> nfs
2. Verificare la corretta associaziome deelle label con:
ceph orch host ls
3. Scatenare il deploy dei servizi utilizzando come regola di placement l'assegnazione della label corrispondente:
ceph nfs cluster create <nfsgw_service_name> "label:nfs" --ingress --virtual_ip=<VIP_CIDR> --ingress-mode haproxy-protocol
ATTENZIONE!!!: il comando sopra comporta la creazione del cluster Ganesha e di un ingress per l'esposizione in HA dei molteplici server che verrebbero installati (uno per ogni host avente la label nsf associata) attraverso delle istanze keepalived. Se sugli stessi host sono presenti altri ingress (ad esempio per il servizio RadosGW), è necessario che i 2 gruppi di servizi keepalived abbiano un identificativo (virtual_router_id) differente.
Questo perchè di default gli ingress implementano istanze di keepalived aventi come virtual_router_id 50, senza un intervento ulteriore si verificherebbero malfunzionamenti e messaggi di errore. Perciò è consigliabile definire i due servizi (cluster NFS e ingress NFS) con un manifest file come quello d'esempio indicato sotto:
service_type: nfs service_id: nfsgw service_name: nfs.nfsgw placement: label: nfs spec: port: 12049 enable_haproxy_protocol: true --- service_type: ingress service_id: nfs.nfsgw service_name: ingress.nfs.nfsgw placement: label: nfs spec: backend_service: nfs.nfsgw frontend_port: 2049 monitor_port: 9049 virtual_ip: <VIP_CIDR> first_virtual_router_id: 60 # != 50 enable_haproxy_protocol: true
ATTENZIONE: per un presunto bug, nell'ultima versione di cephadm (20.2.0 - Tentacle) i servizi `nfsgw` vanno in errore perchè ammettono il protocollo NFS v3 che invece non è supportato. Per ovviare al problema, una volta creato il cluster NFS, va apportata una modifica al file di configurazione relativo. Su ogni nodo, nel file `/var/lib/ceph/<FSID>/<NFS_cluster_ID>.<container_ID>/etc/ganesha/ganesha.conf` sostituire:
Protocols = 3, 4;
con
Protocols = 4;
e riavviare i servizi con:
ceph orch restart <NFS_cluster_ID>
4. Verificare i servizi effettivamente avviati con:
ceph orch ls
La creazione di un export può avvenire con il seguente comando:
ceph nfs export create cephfs --cluster-id <NFS_CLUSTER_ID> --pseudo-path <ABS_PATH> --fsname <CEPHFS_VOLUME> --client_addr <IP_CIDR> --squash <SQUASH_OPTIONS>
ATTENZIONE: il comando non contempla tutte le funzionalità per la configurazione di un export. La modalità di creazione raccomandata è quella attraverso l'interfaccia web nella relativa sezione NFS, è intuitiva e completa. Se si necessita di utilizzare la CLI, è possibile ottenere la configurazione in formato JSON dell'export appena creato e modificarla, ad esempio:
# ceph nfs export info nfsgw /dir1 > nfsgw_dir1_export.json
# cat nfsgw_dir1_export.json
{
"access_type": "RW",
"clients": [
{
"access_type": "RW",
"addresses": [
"192.168.1.1/32"
],
"squash": "no_root_squash"
}
],
"cluster_id": "nfsgw",
"export_id": 1,
"fsal": {
"fs_name": "nfstest",
"name": "CEPH",
"user_id": "nfs.nfsgw.1"
},
"path": "/",
"protocols": [
4
],
"pseudo": "/dir1",
"security_label": false,
"squash": "no_root_squash",
"transports": [
"TCP"
]
}
# vi nfsgw_dir1_export.json # make changes...
# ceph nfs export apply nfsgw -i nfsgw_dir1_export.json