This section describes DNS delegation best practices for PowerScale clusters.

Delegate to address (A) records, not to IP addresses

The SmartConnect service IP address on a PowerScale cluster, in most cases, should be registered in DNS as an address (A) record, also referred to as a host entry. For example, the following SSIP (A) record would designate the SSIP record with a corresponding IP address:

cls01-ssip.foobar.com. IN A 192.168.255.10

In this case, the (A) record maps the URL, cls01-ssip.foobar.com, to a corresponding IP address of 192.168.255.10. Delegating a SmartConnect zone to an (A) record simplifies failover and failback in business continuity, maintenance, and disaster recovery scenarios. In such cases, the change requirement remains minimal because only a single DNS record, the (A) record, would require an update.

All other SmartConnect zone delegations that are configured against the SSIP can be left alone as per the example:

cls01-smb.foobar.com. IN NS cls01-ssip.foobar.com

cls01-nfs.foobar.com. IN NS cls01-ssip.foobar.com

cls01-hdfs.foobar.com. IN NS cls01-ssip.foobar.com

SmartConnect zone aliases as opposed to CNAMEs

A Canonical Name (CNAME) record is a DNS resource mapping one domain to another domain. CNAMEs are not recommended with OneFS because it is not possible to discover which CNAME points to a given SmartConnect zone name.

During a disaster recovery scenario, CNAMEs complicate and extend the failover process because many CNAMEs must be updated. Further, Active Directory Kerberos does not function with CNAMEs. Zone aliases are the recommended alternative.

OneFS provides an option for creating SmartConnect zone aliases. As a best practice, a SmartConnect zone alias should be created in place of CNAMEs. To create a SmartConnect zone alias, use the following command:

isi networks modify pool <subnet:pool> --add-zone-aliases=<zone alias name>

Once the SmartConnect zone alias is provisioned, a matching delegation record must be created in the site DNS, pointing to a SmartConnect Service IP (SSIP).

One name server record for each SmartConnect zone name or alias

One delegation for each SmartConnect zone name or each SmartConnect zone alias on a cluster is recommended. This method permits the failover of only a portion of the cluster's workflow—one SmartConnect zone—without affecting any other zones.

For example, an administrator might have the following delegations in place:

cls01-smb.foobar.com. IN NS cls01-ssip.foobar.com

cls01-nfs.foobar.com. IN NS cls01-ssip.foobar.com

cls01-hdfs.foobar.com. IN NS cls01-ssip.foobar.com

With this approach, the administrator has the flexibility of failing over or moving one or multiple delegations. Consider the following example:

cls01-smb.foobar.com. IN NS cls01-ssip.foobar.com

cls01-nfs.foobar.com. IN NS cls01-ssip.foobar.com

cls01-hdfs.foobar.com. IN NS cls99-ssip.foobar.com

We recommend that you do not create a single delegation for each cluster and then create the SmartConnect zones as sub-records of that delegation. Consider the following example:

smb.cls01.foobar.com

nfs.cls01.foobar.com

hdfs.cls01.foobar.com

This approach enables PowerScale administrators to change, create, or modify their SmartConnect zones and zone names as needed without involving a DNS team.

However, the disadvantage of this approach is that it causes failover operations to involve the entire cluster and affects the entire workflow, not just the affected SmartConnect zone, *.cls01.foobar.com.

Multiple DNS resolvers in a groupnet

Complex data center integrations and authentication realms might require multiple DNS resolvers within a logical group. If possible, separate these into multiple groupnets to create a hierarchy aligning with the site environment.

Depending on the existing hierarchy, separating DNS instances in multiple groupnets might not be an option, requiring multiple resolvers and name servers to reside in a single groupnet. For these implementations, using DNS hosts that are capable of DNS forwarding to forward to the corresponding DNS resolvers is recommended.

OneFS allows up to three DNS instances in a single groupnet. Proceed with caution when adding more than a single DNS instance to a groupnet. Determining how clients are routed to a specific DNS instance affects the client's performance and overall session latency.

The multiple DNSs in a single groupnet are managed in OneFS through the isi network groupnets [create or modify] command and the following options:

• --dns-options: The dns-options configuration specifies how OneFS selects between the multiple DNS instances. In the current release, the only option is to rotate between the instances, providing a DNS selection process of round robin.
• --dns-search: The dns-search configuration specifies up to three DNS suffixes in a single groupnet. OneFS searches these DNS suffixes to resolve queries.
• --dns-servers: The dns-servers configuration specifies up to three IP addresses for multiple DNS instances in a single groupnet.

For round robin options of the DNS instances or searching through more than a single DNS suffix, it is crucial to consider the varying impacts on client experience. If the DNS for a specific session is not consistent, the overall session latency might increase, depending on the assigned DNS. If the latency is inconsistent, workflow success is difficult to predict, resulting in users reporting random experiences. If a groupnet contains two DNS instances, this results in a low chance of having the appropriate DNS assigned to a session. If three DNS instances are specified for a groupnet, the resolution success rate drops further.