doc/cephadm: document keepalive only nfs

Signed-off-by: Adam King <adking@redhat.com>
(cherry picked from commit 5de3312dece60027070bf940e3746dc0769548ea)

diff --git a/doc/cephadm/services/nfs.rst b/doc/cephadm/services/nfs.rst
index c48d0f7658f71e4ab8ba2e6d7efd34b35da40ae2..0e263275d13bc2dddca26ad59392b251e8a007b7 100644 (file)
--- 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 a79d994ddb3818cfdd9da628607e23b9c5179262..6c199d9945b1149de6d1681c642ad716e91ae8da 100644 (file)
--- 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 <cluster_id> [<placement>] [--port <port>] [--ingress --virtual-ip <ip>]
+    $ nfs cluster create <cluster_id> [<placement>] [--ingress] [--virtual_ip <value>] [--ingress-mode {default|keepalive-only}] [--port <int>]
 
 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.,