Skip to content

Commit 4203cc4

Browse files
committed
Add additional CephFS-NFS adoption limitations
- Add warning about simultaneous access to old and new NFS services - Document limited management capabilities after control plane adoption - Add requirement for short switchover window for end user workloads
1 parent 6cdf63f commit 4203cc4

File tree

1 file changed

+6
-0
lines changed

1 file changed

+6
-0
lines changed

docs_user/modules/con_changes-to-cephFS-via-NFS.adoc

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -14,4 +14,10 @@ Before you begin the adoption, review the following information to understand th
1414

1515
* To ensure that NFS users are not required to make any networking changes to their existing workloads, assign an IP address from the same isolated `StorageNFS` network to the clustered Ceph NFS service. NFS users only need to discover and re-mount their shares by using new export paths. When the adoption is complete, {rhos_acro} users can query the {rhos_component_storage_file} API to list the export locations on existing shares to identify the preferred paths to mount these shares. These preferred paths correspond to the new clustered Ceph NFS service in contrast to other non-preferred export paths that continue to be displayed until the old isolated, standalone NFS service is decommissioned.
1616

17+
* When migrating, users must ensure that exports are not consumed from both the old NFS service as well as the new clustered Ceph NFS service at the same time. This simultaneous access is considered dangerous and bypasses the protections for concurrent access ensured by the NFS protocol. When migrating the workloads to use exports from the new NFS service, care must be taken to migrate the use of each export entirely so that no part of the workload stays connected to the old NFS service.
18+
19+
* The old Pacemaker-controlled `ceph-nfs` service can no longer be controlled through the {rhos_prev_long} Director after the control plane adoption is complete. This means that there is no support for updating the NFS Ganesha software, or changing any configuration. While data is protected in case of server crashes or restarts, high availability and data recovery is still very limited, and these maintenance issues are no longer visible to {rhos_component_storage_file}.
20+
21+
* Cloud administrators must ensure a reasonably short window to switch over all end user workloads to the new NFS service.
22+
1723
For more information on setting up a clustered NFS service, see xref:creating-a-ceph-nfs-cluster_ceph-prerequisites[Creating an NFS Ganesha cluster].

0 commit comments

Comments
 (0)