General guidelines and recommendations for AFM-DR

AFM-DR is a disaster recovery solution, which is by nature a business-critical solution. Its success depends on administration discipline, including careful design, configuration, and testing. Considering this, IBM® requires that the AFM Async DR (AFM-ADR) deployment must follow certain guidelines and recommendations for the deployment. The AFM-ADR feature is disabled by default and it can be enabled by following the recommendations and guidelines.

However, the general recommendations and prerequisites for the AFM-DR setup for general usage might differ for use-case specific configurations. The general recommendations help to understand the requirement better for the AFM-DR deployment.

Guidelines or recommendations for the deployment of IBM Storage Scale AFM-DR are as follows:

AFM-DR filesets and files recommendation

  • The number of AFM DR filesets that can be configured in an IBM Storage Scale cluster is up to 100.
  • The number of files in an IBM Storage Scale AFM-ADR environment is approximately 100 million files in every fileset.

Gateway nodes recommendation

  • The number of gateway nodes that can be configured in an IBM Storage Scale cluster depends upon the number of AFM filesets.
  • Keep AFM gateway nodes equal to 1/10th of the number of filesets. That is, for 20 ADR filesets in a primary cluster, the recommended number of gateway nodes is ‘2’. So that, every gateway can be assigned up to 10 filesets.
  • The gateway node must have a dedicated role and no other role must be assigned to the gateway node.
  • Gateway node(s) are needed at primary Site only. AFM or AFM-DR do not need any Gateway node at the secondary site.

Memory and storage recommendation for a gateway node

  • Random access memory (RAM) on the gateway node should be 128 G.
  • The /var partition space storage needs to be provisioned for bigger storage (based on the number of filesets handled by gateway node * files in fileset * 255 bytes) space for internal usage during the recovery or resynchronization.

Configuration parameters recommendation for AFM-ADR

Tunable Recommended value
Pagepool 8G
afmHardMemThreshold 40G
afmNumFlushThreads 8
afmDIO 2
maxFilesToCache 10000
afmMaxParallelRecoveries 3
To set these parameters, use the mmchconfig command. For example,
# mmchconfig pagepool=4G

For more information about configuration parameters, see Parameters for performance tuning and optimization.

Network and computing requirement

  • Plan necessary network bandwidth between primary and secondary clusters to replicate incoming changes based on a workload.
  • This requirement varies based on the workload. The application is slower on AFM DR filesets because of the message queuing on the gateway node for the replication. This performance hit varies from 1.2x to 4x based on network and gateway node resources. If the gateway node handles many filesets, more computational power is required for filtering and dependency checking logic.

Data synchronization for the AFM fileset conversion

  • You can convert an existing GPFS-independent fileset to an AFM-ADR fileset by using the --inband trucking method. You must not use the --outband (deprecated) option even though data was copied by using the external tool.
  • If the secondary site has already data, AFM does not copy data during the initial resynchronization. You can still truck (out of band) data by using any other tool such as rsync and convert the fileset by using the --inband option. AFM expects that files are in sync with nanoseconds time difference. Use rsync version >= 3.10 on both source and destination to copy the data and later use the inband conversion. The inband conversion skips the data, if data exists (and matches) on the secondary site.

Limitations

For more information about the limitations of AFM-DR, see AFM and AFM DR limitations.