Migration of CNFS clusters to CES clusters

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

Points to consider before you migrate

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 the failover not only within a group but also within ranges, CES does not. Make sure that your failover concepts are handled correctly by CES.
  • CES nodes use SMB, NFS, and OpenStack SWIFT Object services.
  • File system ACL permissions need to be in NFSv4 format.
  • File system ACL semantics need to be set to NFSv4 format: nfs4 ACL semantics in effect.
  • CES SMB (Samba) services expect 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.
  • A CES cluster has maximum 16 protocol nodes if the SMB protocol is also enabled.
  • A CES cluster has maximum 32 protocol nodes if only NFS is enabled.

Because of 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 could not 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, 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

  1. If you are planning to convert your existing CNFS nodes to CES nodes, see the support matrix first to know the supported configuration of a CES node. It is best to upgrade the nodes first while they are running CNFS. Because of these nodes upgrade, you can ensure that functions are the same as before you start to change over to CES nodes.
  2. Ensure that you stop application and user access to the CNFS exports.
  3. 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,…
  4. 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 ~]#
  5. Consider de-refencing the GPFS variable cnfsSharedRoot, although this step is not a requirement.
  6. 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.
  7. Run the systemctl disable nfs command to ensure kNFS does not start automatically.

Steps to Configure CES NFS

  1. If you did not yet configure the CES nodes for authentication, complete this step before you create the exports. See CES NFS support for details on configuring authentication for your environment.
  2. 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 works as expected.
  3. 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
  4. 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.
  5. Alternately, you can manually re-create each export on the CES cluster by using the mmnfs command.
    # mmnfs export add Path --client ClientOptions
  6. Before you proceed to configure CES nodes, remove the NFS exports from the /etc/exports file from each of the old CNFS nodes.
  7. Add the IPs that were previously assigned to CNFS to the address pool to be managed by CES 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.

  8. Ensure that the IP addresses are unique and valid for your subnet.

For more information about 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. This access test is needed to ensure that your applications and NFS clients can continue without further changes.