A common concern during a PowerScale configuration is selecting between static and dynamic allocation methods. The requirement for dynamic failover depends heavily on the protocol in use, workflow, and overall high-availability design requirements. Stateful versus stateless protocols, combined with the allocation method, affect the failover experience. Certain workflows require minimal downtime, or the overarching IT requirements dictate IP address persistence. This section provides guidance on failover behavior based on the protocol.

Client access protocols are either stateful or stateless. Stateful protocols are defined by the client/server relationship having a session state for each open file. Failing over IP addresses to other nodes for these types of workflows means that the client assumes that the session state information was carried over. Session state information for each file is not shared among PowerScale nodes. On the contrary, stateless protocols are generally accepting of failover without session state information being maintained, except for locks.

Note: For static zones, ensure SmartConnect is configured with a time-to-live of zero. For more information, see DNS and time-to-live.

SMB

The IP allocation method for SMB is based on the workflow requirements. In certain workflows, SMB is preferred with dynamic allocation of IP addresses, because IP address consistency is required. Aside from a workflow requirement, it could also be an IT administrative dependence.

SMB works well with dynamic allocation of IP addresses, but it is essential to understand the protocol limitations. SMB preserves complex state information per session on the server side. During a dynamic failover to a new node, the existing SMB connection ends with the existing node, and a new SMB connection is established to the new node. The SMB connection for the client is reset because the new node does not have the correct state information. In this event, consider how a state reset impacts the workflow. For example, if the SMB workflow is primarily reads or is heavier on the read side, the impact of a dynamic failover will not be as noticeable because the client can re-open the file and continue reading. During OneFS upgrades, administrators may set the option to wait for connections to drain, minimizing impacts during an upgrade. It is also essential to note that SMB3 Continuously Available (CA) only functions with static IPs.

Before a major implementation, test the workflow in a lab environment to understand the limitations and the best option for a specific workflow.

NFS

The NFSv2 and NFSv3 protocols are stateless, and in almost all cases, perform best with dynamic allocation of IP addresses. The client does not rely on writes unless commits have been acknowledged by the server, enabling NFS to failover dynamically from one node to another.

The NFSv4 protocol introduced state, making it a better fit for static zones in most cases because it expects the server to maintain session state information. However, OneFS 8.0 introduced session-state information across multiple nodes for NFSv4, making dynamic pools the better option. Also, most mountd daemons still behave in a v3 manner—if the IP address it is connected to becomes unavailable, a stale mount results. In this case, the client does not attempt a new nslookup and connects to a different node.

Another factor to consider for NFSv4 is if Kerberos authentication is configured. For Kerberos environments with NFSv4, static allocation is recommended. For non-Kerberos environments, dynamic allocation is recommended.

Again, as mentioned, test the workflow in a lab environment to understand limitations and the best option for a specific workflow.

HDFS

The requirements for HDFS pools have been updated with the introduction of new OneFS features and as HDFS environments have evolved. During the design phases of HDFS pools, several factors must be considered. The use of static versus dynamic pools are affected by:

• Use of OneFS racks if needed
• Node Pools: Is the cluster a single heterogeneous node type or do different node pools exist
• Availability of IP addresses

These factors, coupled with the workflow requirements, determine the pool implementation. See the HDFS Pool Usage and Assignments section in the Dell Isilon Best Practices Guide for Hadoop Data Storage for additional details and considerations with HDFS pool implementations.

S3

OneFS 9.0 introduces support for Amazon’s Simple Storage Service (S3) protocol. The S3 protocol is stateless. For most workflows, S3 performs optimally with dynamic allocation of IP addresses, ensuring seamless client failover to an available node in an event where the associated node becomes unavailable.

Suggested zones by protocol

The following table lists the suggested IP allocation strategies for SmartConnect Advanced by the protocol. As noted, these are suggested, and the actual zone type depends on the workflow requirements, as previously discussed.

Table 3.      Suggested protocols and zone types