Home > Storage > PowerScale (Isilon) > Product Documentation > Networking > Dell PowerScale: Network Design Considerations > Protocols and SmartConnect allocation methods
A common concern during a PowerScale configuration is choosing 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 reconnection experience. Certain workflows require only downtime, or the overarching IT requirements dictate IP address persistence. This section provides guidance on the reconnection behavior based on the protocol. The reconnection sequence takes place during a hardware fault, network fault, OneFS Non-Disruptive upgrade, or other scenarios with downtime.
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. Session state information for each file is not shared among PowerScale nodes.
Note: For static zones, ensure SmartConnect is configured with a time-to-live of zero. For dynamic zones, a time-to-live of zero is less critical since the IP address will always be available. However, a larger the time-to-live value creates a greater impact on load balancing, resulting in a more unbalanced load across nodes. For more information, see DNS and time-to-live.
The IP allocation method for Server Message Block (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. It is also essential to note that SMB3 Continuously Available (CA) only functions with static IPs.
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. Depending on the client’s current I/O status, the SMB connection for the client is reset momentarily to update the new node with the correct state information.
In this event, consider how a brief 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 described above will not be noticed because the client can quickly re-open the file and seamlessly continue reading. For write-intensive applications, the interrupt must be handled within the application time-out setting. A SMB protocol reset to a new connection may be several seconds, but if the application time-out tolerance is set to one second, an event will occur. Even if a time-out event does occur for an application, it may redrive the write operation, and the SMB reset will still appear seamless to the application.
The OneFS SMB drain support further improves its non-disruptive upgrade capabilities by allowing the safe disconnection of SMB clients during the upgrade process. Microsoft Windows Continuous Availability (CA) offers this feature natively. However, it may not always be a viable option because of the requirements for client SMB3 support. The OneFS SMB drain feature ensures that, in non-CA scenarios, an SMB client can flush its cache before being disconnected and with SmartConnect enables the safe migration of SMB clients to non-rebooting cluster nodes. Once the drain service is enabled, OneFS drains SMB connections through the following sequence:
Note: Clients running Microsoft Windows 10 or later complete the sequence in less than two seconds. Clients with DNS caches, such as macOS clients, may attempt to reconnect to the draining node.
Before a major implementation, test the workflow in a lab environment to understand the limitations, the best practices for a specific workflow, and the application timeout setting.
OneFS 9.7.0.0 introduces SMB3 multi-channel Flexnet Awareness with a new SmartConnect IP address library, lwsmartconnect. The new library is now Network Pool aware with an affinity to the clients associated with the current Network Pool, in other words, it maps the current IP address to available IPs on the node. It also removes back-end IPs and down interfaces from the library.
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 introduces stateful client connections. OneFS retains open and lock session-state information in a cluster-coherent way for NFSv4. For dynamic connections, the client reconnects upon failing over to a node, but the client state is recreated. The client reclaims all opens and locks it had prior to failing over.
For static connections, no open or lock session-state information is stored in OneFS for failover. The client will use pure local advisory locking, which can be beneficial for unusual workflows, or management connections.
As a best practice, test the workflow in a lab environment to understand limitations and the best practices for a specific workflow.
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:
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.
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.
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.
Protocol | Protocol category | Suggested zone type |
NFSv2 (not supported in OneFS 7.2 and higher) | Stateless | Dynamic |
NFSv3 | Stateless | Dynamic |
NFSv4 | Stateful | NFS. |
SMBv1 | Stateful | Dynamic or Static. See Server Message Block. |
SMBv2 / SMBv2.1 | Stateful | |
SMBv3 Multi-Channel | Stateful | |
FTP | Stateful | Static |
SFTP / SSH | Stateful | Static |
HDFS | Stateful – Protocol is tolerant of failures | See Dell EMC Isilon Best Practices Guide for Hadoop Data Storage Hadoop Data Storage. |
S3 | Stateless | Dynamic |
HTTP / HTTPS | Stateless | Static |
SyncIQ | Stateful | Static required |