VAST Cluster listens for requests on IP endpoints that are virtual, and therefore called Virtual IPs (VIPs). These endpoints are for all data traffic for all protocols (NFSv3, NFSv4.1, SMB and S3).
To configure the VIPs, you need to create VIP pools. VIP pools are ranges of IP addresses that VAST Cluster can use to listen for data traffic. All VIPs in a configured VIP pool are distributed evenly among all active CNodes or a group of CNodes. If a CNode fails, the VIPs assigned to it are automatically moved to other active CNodes, ensuring that clients can continue to connect to stable IP addresses.
This model provides for load balancing and transparent failover among the CNodes.
A VIP pool can include both IPv4 and IPv6 addresses at the same time. Load balancing in this case is done separately: all IPv4 addresses are balanced across all the CNodes, and all IPv6 addresses are balanced across all the CNodes.
IPv6 is supported for VIP pools on new installations only. If the cluster has been upgraded to version 4.5, IPv6 is not supported.
*You can choose to limit a VIP pool to a specific group of CNodes. See Dedicating CNode Groups to Specific VIP Pools.
Clients can mount VAST Cluster views using DNS names. Every client is allocated a single VIP per mount. The distribution can be handled most easily using the VAST Cluster DNS server. Configuring the VAST Cluster DNS Server simplifies the configurations you need to do on your external DNS server. You can alternatively configure an external DNS server to handle all DNS forwarding to VIPs. With either alternative, VIPs are allocated in a round robin scheme. It's possible to configure multiple VIP pools and to set different domain names per VIP pool. For further information, see DNS-Based VIP Distribution.
VAST Data recommends a minimum of two VIPs per CNode. For optimal load balancing, we encourage four VIPs per CNode for clusters with one Cbox (four CNodes); and four or more VIPs per CNode for larger clusters.
When determining how many VIPs to configure, the following considerations apply:
Since each CNode has two ports listening for data traffic, there should be at least two VIPs available to each CNode.
It is desirable for the number of VIPs to be evenly divisible by the number of CNodes. That way when all CNodes are running, VIPs will be spread evenly.
More VIPs improve balancing on failure. In case a CNode with only one VIP were to fail, the one VIP for that node would be moved to one active CNode, doubling the work of that CNode. If the failed CNode had more than one VIP, each VIP could be moved to a different active CNode. Therefore, the more VIPs there are per CNode, the better the system is able to balance load on failure. With one VIP per CNode, 100% of that load is moved to one other CNode. With two VIPs, 50% is moved to one and 50% to another. With three VIPs, the ratio is 33%/33%/33%, and so on.
If the cluster has four or more CBoxes, the management CNode (the CNode that runs VMS) is not assigned VIPs.
You can limit a VIP pool to a specific group of CNodes, in order to dedicate those CNodes to a specific set of hosts or applications.
CNode Port Affinity adds the ability for CNodes to be connected to multiple networks simultaneously. For example, one port can be connected to an InfiniBand network and the other to an Ethernet network, or the two ports can be connected to two different InfiniBand networks.
By default, a VIP pool runs on all ports on the CNodes added to the pool. If necessary, you can configure the VIP pool to run only on left ports or only on right ports of the CNodes.
Port membership is specified when you create or modify a VIP pool. See Managing Virtual IP Pools.
You can limit the set of VIP pools that can access a given view. This is configured in the view policy.
Yes, you can use VLAN tagging if you wish to control which VIP pools are accessible on specific VLANs on your data network.
VMS runs on one of the CNodes in the cluster. In the event that the CNode hosting VMS fails, VMS is moved to another CNode. VIP pools have an optional setting, VMS preferred, which you can use to configure a preferred domain for VMS election. Enabling VMS preferred on a given VIP pool specifies that the CNodes participating in the VIP pool belong to a VMS-preferred domain.
If a VMS-preferred domain is configured, then, in the event that the VMS CNode becoming unavailable, VMS moves to one of the CNodes in the VMS-preferred domain unless all CNodes in the VMS-preferred domain are offline. If all CNodes in the VMS-preferred domain are offline, VMS is started on a non VMS-preferred CNode and then moved to a VMS-preferred CNode when one is active and stable.
In clusters that have fewer than 16 CNodes, the CNode that hosts VMS can concurrently host one or more VIPs from VIP pools. In clusters with 16 or more CNodes, one CNode is dedicated to VMS. In this larger cluster case, when VMS moves to a CNode, the VIPs on the CNode are redistributed to other CNodes.
Therefore, with larger clusters, if a VIP pool is configured with a CNode group, then having VMS move to one of the CNodes in the CNode group means that the VIP pool loses that CNode for the time being.
VMS preferred is not supported for VIP pools that have a CNode group with fewer than three CNodes.
Article is closed for comments.