Differences

This shows you the differences between two versions of the page.

--- strutture:lnf:dr:calcolo:sistemi:ceph:nfsgw [2024/03/07 11:50] – rorru@infn.it
+++ strutture:lnf:dr:calcolo:sistemi:ceph:nfsgw [2024/06/21 14:37] (current) – rorru@infn.it
@@ Line 1: / Line 1: @@
+====== NFS Gateway ======
+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.
+===== Deploy =====
+Assumendo di disporre di un cluster CEPH operativo, per il deploy dei relativi daemon è possibile seguire i seguenti passi:
+. 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
+. Verificare la corretta associaziome deelle label con:
+  ceph orch host ls
+. 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>
+**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 aventa 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 simile al seguente:**
+  service_type: nfs
+  service_id: nfsgw
+  service_name: nfs.nfsgw
+  placement:
+    label: nfs
+  spec:
+    port: 12049
+  ---
+  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
+. Verificare i servizi effettivamente avviati con:
+  ceph orch ls
+===== Creazione export CephFS =====
+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:**
+<code>
+# 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": [
+  ],
+  "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
+</code>