From 736275a47f244c2e935c1169b97736683af06330 Mon Sep 17 00:00:00 2001 From: Adam King Date: Thu, 9 Feb 2023 21:31:34 -0500 Subject: [PATCH] doc/cephadm: document keepalive only nfs Signed-off-by: Adam King (cherry picked from commit 5de3312dece60027070bf940e3746dc0769548ea) --- doc/cephadm/services/nfs.rst | 48 ++++++++++++++++++++++++++++++++++++ doc/mgr/nfs.rst | 16 +++++++++++- 2 files changed, 63 insertions(+), 1 deletion(-) diff --git a/doc/cephadm/services/nfs.rst b/doc/cephadm/services/nfs.rst index c48d0f7658f71..0e263275d13bc 100644 --- a/doc/cephadm/services/nfs.rst +++ b/doc/cephadm/services/nfs.rst @@ -113,6 +113,54 @@ A few notes: a *port* property that is not 2049 to avoid conflicting with the ingress service, which could be placed on the same host(s). +NFS with virtual IP but no haproxy +---------------------------------- + +Cephadm also supports deploying nfs with keepalived but not haproxy. This +offers a virtual ip supported by keepalived that the nfs daemon can directly bind +to instead of having traffic go through haproxy. + +In this setup, you'll either want to set up the service using the nfs module +(see :ref:`nfs-module-cluster-create`) or place the ingress service first, so +the virtual IP is present for the nfs daemon to bind to. The ingress service +should include the attribute ``keepalive_only`` set to true. For example + +.. code-block:: yaml + + service_type: ingress + service_id: nfs.foo + placement: + count: 1 + hosts: + - host1 + - host2 + - host3 + spec: + backend_service: nfs.foo + monitor_port: 9049 + virtual_ip: 192.168.122.100/24 + keepalive_only: true + +Then, an nfs service could be created that specifies a ``virtual_ip`` attribute +that will tell it to bind to that specific IP. + +.. code-block:: yaml + + service_type: nfs + service_id: foo + placement: + count: 1 + hosts: + - host1 + - host2 + - host3 + spec: + port: 2049 + virtual_ip: 192.168.122.100 + +Note that in these setups, one should make sure to include ``count: 1`` in the +nfs placement, as it's only possible for one nfs daemon to bind to the virtual IP. + Further Reading =============== diff --git a/doc/mgr/nfs.rst b/doc/mgr/nfs.rst index a79d994ddb381..6c199d9945b11 100644 --- a/doc/mgr/nfs.rst +++ b/doc/mgr/nfs.rst @@ -24,12 +24,14 @@ see :ref:`nfs-ganesha-config`. NFS Cluster management ====================== +.. _nfs-module-cluster-create: + Create NFS Ganesha Cluster -------------------------- .. code:: bash - $ ceph nfs cluster create [] [--port ] [--ingress --virtual-ip ] + $ nfs cluster create [] [--ingress] [--virtual_ip ] [--ingress-mode {default|keepalive-only}] [--port ] This creates a common recovery pool for all NFS Ganesha daemons, new user based on ``cluster_id``, and a common NFS Ganesha config RADOS object. @@ -94,6 +96,18 @@ of the details of NFS redirecting traffic on the virtual IP to the appropriate backend NFS servers, and redeploying NFS servers when they fail. +If a user additionally supplies ``--ingress-mode keepalive-only`` a +partial *ingress* service will be deployed that still provides a virtual +IP, but has nfs directly binding to that virtual IP and leaves out any +sort of load balancing or traffic redirection. This setup will restrict +users to deploying only 1 nfs daemon as multiple cannot bind to the same +port on the virtual IP. + +Instead providing ``--ingress-mode default`` will result in the same setup +as not providing the ``--ingress-mode`` flag. In this setup keepalived will be +deployed to handle forming the virtual IP and haproxy will be deployed +to handle load balancing and traffic redirection. + Enabling ingress via the ``ceph nfs cluster create`` command deploys a simple ingress configuration with the most common configuration options. Ingress can also be added to an existing NFS service (e.g., -- 2.39.5