Enhanced Distance Cluster Recommendations

Although Enhanced Distance Cluster configurations provide access from both sites to all shared data storage in the system, the volume of traffic to off-site storage, either through the storage or cluster inter-site connections, should be minimized to maintain performance levels. Therefore, you should be aware of the following recommendations are applicable. Not following these recommendations can have detrimental effect on system performance and availability.

The main purpose of most of these recommendations is to design a configuration that minimizes I/O latency and contention issues within both the cluster and the SAN storage inter-site connections:

The configuration of an application and its data storage should be located within the same site. Doing otherwise can cause significant performance degradation to the application’s runtime performance.
Each application should have its associated data in separate file systems, or AdvFS domains, in order to locate the CFS server for these file systems with the application.
Applications should not use any storage/directory within the system tree (for example, root, /usr, /tmp, /var, /var/tmp, and so on). Instead they should use dedicated file systems that can be co-located with the application. If the application requires a directory in the system tree, a symbolic link should be used to redirect these directories to a separate storage/file system.
The use of remote I/O via DRD to serve devices is strongly discouraged due to the increased traffic on the cluster interconnect possibly resulting in unacceptable latencies.
Although the use of LSM for striping is supported, it is not recommended for use.
Although data replication is supported between HSG80 arrays, their use as shared storage within an Enhanced Distance Cluster it is not recommended. This is due to the inter-site distance limitations of the HSG80's remote data replication, which would significantly impact the Enhanced Distance Cluster configuration.
The use of a cluster alias for network-client access is discouraged due to the potential for additional traffic on the cluster interconnect if the alias router is not located with the application.
If a cluster alias is used, each application must have its own cluster alias. Each application should have its cluster alias router located on the node where the application is executing. This can be achieved by using the cluamgr command and adjusting the values of selection weight and routing priority. During a failover of the application, the cluster alias also should be relocated to the same node.