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.  Figure 4 below shows one such network topology, which implements best practices for SoftNAS SNAP HA in the data center.

 

Figure 4 - Private Data Center with SoftNAS SNAP HA

 

 

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 StorageCenter access and administration.

 

In the example shown above, VLAN 30 is assigned to SNAP HA repliication.  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 and Hyper-V 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 show in Figure 4, a VIP of 10.0.20.100 would work fine.  The VIP must not be manually assigned to any interface. During installation and setup 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 and Hyper-V virtualization environments, a 3rd SoftNAS VM is installed to act as the "HA Controller", shown below in Figure 5.

 

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 environment, it is optional, but recommended, to deploy the HA Controller as an "FT" (fault tolerant) VM, so there is always an HA Controller available.  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 your storage HA operations will remain consistent, no matter what takes place across the virtualization environment.

 

Figure 5 - HA Controller VM

 

 

The HA Controller is optional - for demo and evaluation systems only. The HA Controlelr is required for production environments to ensure proper HA operation always takes place.  If no HA Controller is deployed, IT administrators must instead assume all responsibility for keeping track of failovers and ensuring controllers with old data are not brought online before the most recent primary controller.  For production systems, always deploy an HA Controller.