Migration of CNFS clusters to CES clusters

If your system has established clustered Network File System (CNFS) clusters, you might consider migrating these clusters to Cluster Export Services (CES) clusters.

Points to consider before you migrate

Cluster Export Services (CES) protocol nodes have the following dependencies and restrictions:

CES nodes cannot coexist with CNFS clusters.
The concepts of failover in CES node groups and CNFS failover groups are slightly different. While CNFS allows to failover not just within a group but also within ranges, CES does not. Make sure that your failover concepts are handled correctly by CES.
The installation toolkit confirms that your cluster does not have an existing CNFS cluster.
CES nodes use SMB, NFS, and Openstack SWIFT Object services.
File system ACL permissions need to be in NFSv4 format.
CES NFS services expects NFSv4 ACL formats.
CES SMB (Samba) services expects NFSv4 ACL formats.
Existing CNFS exports definitions are not compatible with CES NFS. It is best to script and automate the creation of the equivalent exports by using the mmnfs export add command to reduce the amount you need to change in the future.
CES nodes need authentication that is configured.
There is a maximum of 16 protocol nodes in a CES cluster if the SMB protocol is also enabled.
There is a maximum of 32 protocol nodes in a CES cluster if only NFS is enabled.

Because there is a mutual exclusivity between CNFS and CES nodes, you need to accommodate user and application access outage while CES clusters nodes are installed, configured, set up for authentication, and the NFS exports are re-created. The duration of this process depends on the complexity of the customer environment.

You might want to procure new CES nodes or reuse the existing CNFS nodes. Either way, you cannot use the installation toolkit until the CNFS nodes are unconfigured.

If you do not have an opportunity to test or plan the implementation of a CES cluster elsewhere, you might have to deal with the design and implementation considerations and issues during the planned outage period. Usually this process is straightforward and quick. If you have a more complex environment, however, it might take longer than the allotted upgrade window to complete the migration. In this case, it is possible to set up one or two non-CNFS, NFS servers to serve NFS for a short time. During this time, you would move all your CNFS IPs to these nodes as you decommission the CNFS cluster. Then, after you successfully set up your CES nodes, authentication, and corresponding exports, you can move the IPs from the temporary NFS servers over to the CES nodes.

Saving CNFS export configuration

You need to make a copy of the exports configuration file /etc/exports so that you can use this file as the basis for creating the new exports in CES NFS. CES NFS exports configuration needs to be created by using the mmnfs export add command or created in bulk by using the mmnfs export load command. When you unconfigure CNFS, you also need to delete the /etc/exports file from each of the CNFS nodes.

Steps to unconfigure CNFS

CES nodes can be configured only on Red Hat Enterprise Linux 7.x and SLES 12 nodes. If you are planning to convert your existing CNFS nodes to CES nodes, ensure that they are upgraded to Red Hat Enterprise Linux 7.x or SLES 12 first. It is best to upgrade the nodes first while they are running CNFS so that you can ensure that functions are the same as before you start to change over to CES nodes.
Ensure that you stop application and user access to the CNFS exports.
Run the mmchnode command to dereference or evict a CNFS node from the cluster. This command removes both the node and its associated IP):
```
mmchnode –cnfs-interface=default –N node1Name,node2Name,…
```

When you remove the last node, CNFS is unconfigured and you see an output similar to this result:

[root@esnode3 ~]# mmlscluster --cnfs

GPFS cluster information
========================
  GPFS cluster name:         esvcluster1.esnode1
  GPFS cluster id:           15635445795275488305

mmlscluster:  CNFS is not defined in this cluster.

[root@esnode3 ~]#

Consider de-refencing the GPFS™ variable cnfsSharedRoot, although this step is not a requirement.
You can now delete the /etc/exports file on each of the CNFS nodes. Ensure that you have a backup copy of this file to use as a reference when you create the exports under CES NFS.

Steps to Configure CES NFS

If you have not yet configured the CES nodes for authentication, complete this step before you create the exports. Refer to CES NFS support for details on configuring authentication for your environment.
Ensure that the file systems you want to export access to are configured for the NFSv4 security model. If you are converting an existing file system from another security model to NFSv4 you might need to review the ACL structures of the files and verify that your access will work as expected.
If you have special configurations or options set in CNFS server, you might also want to reflect these settings in CES NFS. You need to review the appropriateness of these settings for the new environment. To change the settings, use the following command:
```
mmnfs config change
```
If you have many exports to be converted to CES NFS, use the following command:
```
mmnfs export load ExportCfgFile
```
ExportCfgFile contains a listing of all your exports as defined in the format that is used for /etc/ganesha/gpfs.ganesha.exports.conf.
Alternately, you can manually re-create each export on the CES cluster by using the mmnfs command.
```
mmnfs export add Path --client ClientOptions
```
Before you proceed to configure CES nodes, remove the NFS exports from /etc/exports from each of the old CNFS nodes
Add the IPs that were previously assigned to CNFS to the address pool to be managed by CNFS by using the following command:
```
mmces address add –-node node1Name –-ces-ip ipAddress
```
See CES network configuration for details about how to use this command.
Take care to ensure that the IP addresses are unique and valid for your subnet.

For more information on creating protocol data exports, see Fileset considerations for creating protocol data exports.

Test access to new exports on CES NFS

Test and verify that you have the same level of access to the NFS exports as you did on CNFS to ensure that your applications and NFS clients can continue without further changes.