Clusters
Clustering provides the following functionality:
- Hosting of multiple EVSs on each node in a cluster. Cluster nodes can simultaneously host multiple EVSs, allowing all servers to be active at the same time, each providing file services to clients.
- Redundant monitoring and transparent failover of EVS hosts. The cluster monitors the health of each server through redundant channels. Should one server fail, the EVSs hosted by that node are migrated to another cluster node, which takes over the failed node's functions transparently to network clients, so no loss of service results from a single node failure. After the failed node is restored and is ready for normal operation, previously hosted EVSs can be migrated back.
NoteDuring the time a node is off line, and during the restoration of the failed node, the cluster may operate with reduced performance.
- Redundant availability of configuration settings for all nodes. The cluster provides a cluster-wide replicated registry, containing configuration information for all nodes in the cluster.
The following sections discuss options for configuring server nodes as clusters to expand their functionality.
N-way clusters
The simplest cluster configuration is a two-node cluster. Configurations of more than two nodes are called N-way clusters. The maximum number of cluster nodes is dependent on three factors:
- The model of HNAS server being used as cluster nodes
- The server firmware version in use
- The maximum number of cluster nodes allowed by the cluster's licenses
The following diagram shows the logical view of an HNAS server N-way cluster configuration of 4 nodes. For more information on setting up N-way clusters, refer to the Hitachi NAS Platform and Hitachi Unified Storage System Installation Guide.
Maximum number of nodes supported
The maximum number of nodes in a cluster is controlled by several factors, including hardware model of the server nodes, HNAS server firmware version, and maximum number of cluster nodes allowed by the cluster licenses.
The maximum licensed number of nodes in a cluster will never exceed the maximum number of nodes supported by the hardware and software of the nodes making up the cluster.
For each HNAS server model, the maximum supported number of nodes allowed in a single cluster is:
| HNAS server model being used as nodes | Maximum number of nodes supported |
| 3080 | 2 |
| 3090 | 4 |
| 4040 | 2 |
| 4060 | 2 |
| 4080 | 4 |
| 4100 | 8 |
| 5200 | 4 |
| 5300 | 4 |
All nodes in a cluster must be of the same model of server.
Quorum device in a cluster configuration
The quorum device (QD) enables a cluster to maintain operations following a communications failure between nodes and also to restore the cluster registry (containing the cluster configuration), as follows:
- Surviving a communication failure between nodes. Clustering preserves data integrity through a quorum voting algorithm that ensures only one node can access a given file system at any time. Under this algorithm, each of the cluster nodes may “vote” regarding file access. When a cluster contains an even number of nodes, the QD also votes. When a cluster node has obtained a quorum (a simple majority of the votes available in the entire cluster) it receives exclusive access to the file system. Under certain failure scenarios, cluster nodes can lose communication with each other and may attempt to access the same file system; in this situation, the QD alone “votes” for one of the nodes, establishing the quorum and granting one node exclusive access to the file system.
- Preserving a copy of the cluster registry. Although the registry is replicated across cluster nodes, some failure scenarios could result in the loss of recent configuration changes, a condition called amnesia. Anticipating the possibility of such a condition, the QD preserves a copy of the registry, ensuring that configuration changes can always be replicated.
An external quorum device runs on the same system as the NAS Manager and can provide QD services for up to eight clusters (or up to eight servers in a server farm).
The number of entities (devices) required to form an acceptable quorum depends on the number of nodes in the cluster. The formula for establishing the acceptable number of entities is simple: (the number of nodes in the cluster / 2) + 1. For example:
| Number of nodes in the cluster | Number of entities (devices) required for a functioning quorum | Entities (devices) that may be in the quorum |
| 2 | 2 | 1 node + 1 NAS Manager |
| 3 | 2 | 2 nodes (the NAS Manager is not used as a quorum device in a cluster with an odd number of nodes) |
| 4 | 3 | 2 nodes + 1 NAS Manager, or 3 nodes and no NAS Manager |
| 5 | 3 | 3 nodes (the NAS Manager is not used as a quorum device in a cluster with an odd number of nodes) |
| 6 | 4 | 3 nodes + 1 NAS Manager, or 4 nodes and no NAS Manager |
| 7 | 4 | 4 nodes (the NAS Manager is not used as a quorum device in a cluster with an odd number of nodes) |
| 8 | 5 | 4 nodes + 1 NAS Manager, or 5 nodes and no NAS Manager. |
If enough of the entities (nodes and the NAS Manager) in the cluster are not functioning, and an acceptable quorum cannot be formed, and the cluster will fail, and stop providing file serving functions. Cluster nodes may go into a boot loop cycle, trying to establish a quorum, and cluster nodes may even go off line in certain circumstances.
Enhanced cluster quorum device
Beginning with release 10.1, an Enhanced Cluster Quorum Device, Quorum Services v2 was introduced. QD v2, hosted on the same system as the NAS Manager, operates in a passive rather than active fashion. It is used only when communication fails between cluster nodes, whereas the previous QD continually polled cluster nodes to detect a node failure. Rather than actively polling the cluster heartbeat, the QD v2 quorum daemon is only called when the server cluster requires an additional quorum vote, in the event of the loss of a cluster node. QD v2 stores node information to elect one node as the master when the cluster experiences a change in the membership. After one node is elected as master, all the remaining nodes will join the master to reconfigure the cluster.
Current NAS Manager versions continue to support servers running 8.x firmware, and the NAS Manager runs instances of both the previous and the new Quorum Device daemons. The firmware version determines the user choice of either the legacy QD, or QD v2. Both are managed from the NAS Manager. Servers running firmware 8.x or earlier can only use the legacy quorum services. Servers running firmware 10.x or later, requiring quorum services, can only use Quorum Services v2. The two Quorum Device daemons communicate with each other for cluster configuration, so that a single cluster cannot be served by both the old and the new QD daemons simultaneously.
Cluster topology
Typically, the private management network connects cluster nodes and the QD, keeping cluster traffic off of the public data network, and isolating them from potential congestion due to heavy data access loads.
The high-speed cluster interconnect provides an additional, direct connection among the cluster nodes. This dedicated connection consists of dual redundant gigabit Ethernet links, and is reserved for clustering traffic and NVRAM mirroring.
VSP N series and VSP Gx00 and Fx00 storage systems with NAS modules
VSP N series models and Virtual Storage Platform G400, G600, G800 (VSP Gx00 models) and Virtual Storage Platform F400, F600, F800 (VSP Fx00 models) storage systems with NAS modules deliver native NAS functionality in a unified storage platform. VSP N series models and Unified VSP Gx00 and Fx00 models automatically form a two-node cluster in a single chassis upon installation. The two nodes are connected to each other via the internal Ethernet network link and intra-cluster connect, so no external cabling is required.
The unified configuration is limited to two nodes, but two VSP N series or Gx00 model storage systems with NAS modules can be clustered together in a GAD Enhanced for NAS configuration.
GAD Enhanced for NAS
VSP N Series and VSP Gx00 storage systems provide a global-active device (GAD) feature that maintains identical read/write copies of data in two locations at the same time. GAD Enhanced for NAS takes advantage of this feature to cluster two VSP N Series or VSP Gx00 systems with NAS modules across two sites. This synchronous disaster recovery configuration, also referred to as a stretched cluster, creates a four-node cluster stretched across two sites within 100 km of each other. Contact your Hitachi Vantara representative for more information about this special configuration.
With GAD Enhanced for NAS, the cluster of two VSP N Series or VSP Gx00 systems operates similar to a 4-node HNAS cluster. There is one cluster name and UUID, and cluster-wide locks, management requests, and broadcast requests continue to work as they do in a 4-node HNAS cluster. However, the internal quorum used by each 2-node VSP N Series or VSP Gx00 cluster cannot work across the two VSP N Series or VSP Gx00 systems, so the stretched cluster configuration uses an external SMU to host the external quorum device. Also, the cluster uses the maintenance network as the redundant communication link to connect the nodes.
Although it works like a 4-node HNAS cluster, from the block perspective it is two separate VSP N Series or VSP Gx00 clusters, with GAD mirroring the data between the clusters. The cluster uses the GAD volume, which is available as read/write on both sites. From the NAS perspective, it looks like shared storage because GAD hides the storage mirroring between VSP N Series or VSP Gx00 systems and presents the virtual volumes that are accessible to all four nodes.
Example:
In the case of disaster at location A, EVSs from NAS node 1 fail over to NAS node 3. NAS node 2 EVSs fail over to NAS node 4. When the VSP N Series or VSP Gx00 system at site A recovers, EVSs are manually migrated according to the EVS preferred mapping.