Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

...

...

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 below 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 above, 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.

Image Added

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 below, 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 environment an HA Controller deployed as an "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.

 

Image Added