Home > Storage > PowerScale (Isilon) > Product Documentation > Networking > Dell PowerScale: Network Design Considerations > SmartConnect DNS, subnet, and pool design
This section provides a starting point for planning SmartConnect DNS, subnet, and SmartConnect pool layouts that meet the needs of most new cluster implementations with a SmartConnect Advanced License.
Note: SmartConnect Service IP Addresses (SSIPs) are only supported for use by a DNS server. Although SSIPs may be used in other configurations, the design intent was for a DNS server. Thus, other implementations with SSIPs are not supported.
For clarity and simple recognition, name SmartConnect zones according to relevant details. For example, use some or all of the following variables when composing names:
These variables together form a SmartConnect zone name. For example: isi01-s0.domain.com
The name includes the cluster name (isi01), the allocation strategy of the zone (s for static), and the number of the pool (pool0).
For example, a cluster with three pools:
Based on the SmartConnect zone, pool, and the cluster information, here is a sample DNS layout for the cluster named isi01:
From a client or application perspective, the goals for all scale-out NAS deployments are consistency and availability. Consistency, in this context, implies that every time a client connects, whether that client is an application server or a user opening their home directory, the same level of performance is provided. Dell Technologies offers several different PowerScale node types with varied performance profiles.
Many factors determine performance in network-attached storage. In a PowerScale cluster, key components are the front-end performance, which consists of the network card, CPU, and memory in the node that is serving the relevant data protocol, and the back-end performance, which, in this case, is the disk tier or pool where the data resides. In the context of SmartConnect configuration, creating a connection pool that spans different node performance levels is not recommended. For example, a pool with Isilon F800 nodes and A200 nodes would provide significantly varying protocol performance. It is imperative to understand how the nodes within a connection pool affect client experience.