SoftNAS SNAP HA™ easily fits within a modern, virtualized data center. Today's data center is often running VMware, with a network architecture comprised of several VLANs used to segregate various classes of network traffic. The diagram to the right shows one such network topology, which implements best practices for SoftNAS SNAP HA™ in the data center.

User subnets are allocated outside the data center network, and traverse one or more routers to reach the data center.

The data center network exists on its own /16 (or similar) layer 2 network, which we term the "Datacenter Primary Subnet". This subnet is used for administrative and other default traffic.

A separate "Replication VLAN" and corresponding subnet is allocated for SoftNAS® block replication traffic; i.e., SnapReplicate™ is configured to flow across this dedicated VLAN, which prevents data replication traffic between controllers from impacting storage or other data center services. During high periods of I/O, data replication on a 1 GbE network can reach sustained levels of 120 MB/sec as multiple streams of block replication take place across controllers, so the replication VLAN is an important consideration.

A separate "Storage VLAN" and corresponding subnet is allocated for SoftNAS® primary virtualization storage traffic; i.e., NFS and iSCSI traffic between VMware vmKernels on each VM host responsible for storage access. Assigning a separate vSwitch and physical NICs to storage is essential for achieving maximum throughput and IOPS, and for keeping storage access isolated from other network segments. If storage is not isolated on its own VLAN, vSwitch and physical NICs, performance will be impacted, and high storage I/O loads will impact other services.

StorageCenter and routine, lower-priority storage traffic (e.g., from the User Subnets) can be routed across the default data center network, if simplicity of network topology is desired. Alternatively, certain protocols (e.g., CIFS for Windows shares) could be routed to the Storage VLAN and HTTP/HTTPS/SSH routed to the default data center network for SoftNAS StorageCenter™ access and administration.

In the example shown to the right, VLAN 30 is assigned to SNAP HA™ replication. VLAN 20 is assigned to as the Storage VLAN. A special "Elastic HA™" IP address is configured within the Storage VLAN subnet to act as a virtual IP address. SoftNAS SNAP HA™ uses ARP IP aliasing to route the Elastic HA IP address to the proper SoftNAS® Controller.

Elastic HA IP

The Elastic HA IP in VMware is implemented as a virtual IP termed a "VIP"; that is, an IP address that can be quickly reassigned using a combination of ARP and local interface commands. Choose a VIP address that is within the Storage VLAN subnet.

In the example shown to the right, a VIP of 10.0.20.100 would work fine. The VIP must not be manually assigned to any interface. During installation and set up of SNAP HA™, the VIP will be automatically configured and assigned to the primary controller and then managed by SNAP HA™.

HA Controller VM

In the VMware virtualization environments, a 3rd SoftNAS® VM is installed to act as the "HA Controller", shown below.

The HA Controller acts as an independent, 3rd party witness and controller to all SNAP HA™ failover and takeover operations. The HA Controller keeps track of which SoftNAS® storage controller is, in fact, operating as the Primary controller. This prevents the possibility of "split-brain" or other potential cluster management maladies that could otherwise occur when only two cluster nodes are present by fencing off failed controllers and ensuring they are not allowed to come back online and pose as a primary storage controller.

In VMware HA environments, an HA Controller deployed as a "FT" (fault tolerant) VM is required. HA Controllers are relatively lightweight versions of SoftNAS®, only requiring 512 MB of RAM and 1 vCPU, and have relatively little network traffic or data change, so they pose relatively little resource overhead vs. the added peace of mind of always knowing that storage HA operations will remain consistent, no matter what takes place across the virtualization environment.

The HA Controller is required for both production and test environments to ensure proper HA operation always takes place. If no HA Controller is deployed, IT administrators would instead have to assume all responsibility for keeping track of failovers and ensuring controllers with old data are not brought online before the most recent primary controller. As this would defeat the purpose of automated failovers, and the premise behind high availability, SoftNAS requires HA controllers for all VMware HA configurations.

VMware SNAP HA™ Setup

Set up SNAP HA™ in any VMWare virtualized environment. In order to set up SNAP HA™ the following is required:

Two SoftNAS® controller nodes for replication and their corresponding IP addresses (DNS names) and networking credentials.
a virtual IP within the storage VLAN subnet (see HA Design Principles for more information).
An additional SoftNAS SNAP HA™ Controller node is required. This node is necessary, as it acts as a 3rd party witness and controller to all SNAP HA™ failover and takeover operations.
Replication must be set up between the two SoftNAS® controller nodes.

For more information about SNAP HA™ networking best practices, see section HA Design Principles.

For more information about common SoftNAS® installation procedures, see the document SoftNAS Installation Guide.

Setting Up SNAP HA™ for VMWare

After the above networking requirements have been fulfilled, SNAP HA™ may be set up.

Navigate to the SoftNAS StorageCenter™ interface of the primary node.
From the SoftNAS SnapReplicate™ panel click on Add Snap HA.

The Instructions page will appear. Click Next.

Enter the Virtual IP of an unassigned VIP address in the storage VLAN subnet (In this example we use 25.25.25.25). Click on Next.

Enter the static IP of a third SoftNAS® virtual machine that will act as the HA Controller in the HA Controller IP field (In this example, the IP address is 172.16.0.40). It is recommended that this machine be deployed in fault tolerant mode. Click on Next.