SmartConnect zones map to access zones, which map to a root-based path. When an access zone is defined, a root-based path must be defined. Best practice is to use the cluster name, a numerical access zone number, and a directory. For example, Access Zone 1 maps to /ifs/clustername/az1/<data directories>, Access Zone 2 maps to /ifs/clustername/az2/<data directories>. A root-based path with this delineation provides data separation and multitenancy, maintains the Unified Permission model, and makes SyncIQ failover and failbacks easier.

Generally, the best practice is to remove all data access from the default System zone. Otherwise, this leads to complications in the future as the cluster grows and additional teams or workflows are added. Further, as previously mentioned, create a subdirectory under the access zone, rather than using the root of the zone, to make migration and disaster recovery simpler. It is preferred not to have an overlap of root-based paths unless it is required for a specific workflow. Overlap is supported in 8.0 and newer releases through the CLI.

In the following figure, as Cluster 1 fails over to Cluster 2, the directory structure remains consistent, easily identifying where the files originated from. This delineation also ensures clients have the same directory structure after a failover. Once the IP address is updated in DNS, the failover is transparent to clients. As more clusters are brought together with SyncIQ, this makes it easier to manage data, understanding where it originated from and provides seamless disaster recovery.

Figure 24.    Importance of root-based path best practices

Root-based paths may also be based on protocol. As an example, protocols are matched with a root-based path in the following table:

Table 11.  Protocol-specific access zones