Skip to end of metadata
Go to start of metadata

On AWS, SoftNAS SNAP HA™ is designed to operate within the Virtual Private Cloud (VPC). VPCs can be as simple as a single subnet, with or without a VPN security gateway, or as complex as public/private compartmentalized subnets, as depicted in the figures herein. In the first image below, we see a VPC configured to operate across two availability zones (AZ), with separate subnets for public and private use.

SoftNAS® controllers are placed into the public subnet for elastic IP address routing purposes. 

About Elastic HA™ IP Addresses

SoftNAS® storage is normally not accessible from the public Internet. A special "Elastic HA™" IP address is configured with a security group setting that restricts its access to only the internally-routable, private IPs assigned to the VPC; e.g., in this example, only EC2 instances within the VPCs internal 10.0.0./16 private network are routable to the Elastic HA IP.

Why use an Elastic IP? Elastic IPs (EIP) were previously the only supported cross-zone routable IP addresses available in the AWS VPC environment. In practice, EIPs add very little latency or other overhead to storage traffic and provide routing redundancy across the zones.

SoftNAS SNAP HA™ takes a basic EC2 elastic IP and layers on additional patent-pending functionality that turns it into an Elastic HA IP - a cross-zone IP suitable for highly-available network-attached storage.

AWS Cross-Availability Zone Architecture Overview

Please refer to the image shown below for the remaining discussion. This drawing depicts a typical HA deployment, but is not the only possible design. In fact, SoftNAS SNAP HA™ can be deployed with dual controllers located within a single AZ on a VPC (there is no requirement to split controllers across AZs, but it is a recommended best practice for maximum availability). 

We see a VPC created in a /16 network in AWS US East (Virginia) data center, with subnets allocated in US East 1-a and 1-b. This topology provides the best overall redundancy and availability within the AWS AZ architecture.

Two SoftNAS® controller EC2 instances are deployed - one per AZ. If optional private subnets are configured in one or more AZs, they will also have access to the Elastic HA IP for NFS client storage access via NFS, CIFS and iSCSI protocols.

The drawing shows SNAP HA™ replication traffic flowing from Controller A to Controller B. This traffic is allocated to interface 0. Interface 0 is also used for administration using the SoftNAS StorageCenter™ GUI. Block replication keeps a warm copy of the data from node A on node B, in case a failover is necessary.

The drawing shows two orange arrows emanating from an orange and white circle, which represents the Elastic HA IP. The black lock symbol represents the EC2 Security Group associated with the Elastic HA IP. The shadowed orange arrow represents re-routed storage requests flowing to Controller B after an automatic failover or manual takeover.

When an automatic failover or manual takeover occurs, NAS traffic is re-routed via the Elastic HA IP from Controller A to Controller B, as indicated by in the diagram above. When an Elastic HA switches over from one controller to another, NAS client traffic is rapidly re-routed to the new controller, typically in just a few seconds. NAS clients typically experience a brief switchover delay of up to 20 seconds or so, and automatically reconnect after the switch-over event takes place.

AWS Cross-Availability Zone Network Design

Each SoftNAS® controller has two NICs assigned - interface 0 (default) and one additional interface 1 (added during EC2 instance configuration).

  1. Admin and Replication, Interface 0 - the first (default) NIC is used for SoftNAS StorageCenter™ access and SnapReplicate™ data replication across controllers.

  2. SoftNAS® Storage, Interface 1 - the second NIC is dedicated to NAS storage traffic and is used for Elastic HA IP routing of storage-related traffic (NFS, CIFS, iSCSI).

    Note in the following diagrams the IP addresses shown are for illustration purposes only, and actual IP addresses will be assigned by AWS. 

The remaining EC2 instances constitute NAS clients; that is, EC2 instances that connect using NFS, CIFS or iSCSI protocols to access NAS services across the private network. Although only two AZs are shown in these diagrams, NAS clients can access HA NAS services from any zone within the region allowed access to the Elastic HA IP.

Secure Administrative Access in VPC

There are multiple ways to configure secure administrative access to the SoftNAS SNAP HA™ storage controllers:

  1. VPN - this is the most secure and recommended best practice for limiting access to the private IPs of each SoftNAS® controller. In this case, use DNS to assign a common name to each controller (e.g., "", ""), making routing to each SoftNAS® controller convenient for administrators

  2. Admin Desktop - an even more secure approach is to combine VPN access with an Administrator's desktop, typically running Windows and accessed via RDP. This secure admin desktop adds another layer of authentication, namely Active Directory (or local account) authentication. Once an administrator has gained secure, encrypted access to the Admin Desktop, she opens up a web browser to connect to the SoftNAS StorageCenter™ controller. 

  3. Direct Internet Access - the least secure, yet simplest form of providing administrators with access to SoftNAS StorageCenter™ is to assign two additional Elastic IP addresses, one per SoftNAS® controller (see image below). Of course, a corresponding security group, locked down to restrict the IP addresses allowed access to the controllers is necessary to properly secure this configuration. While not recommended for production systems, this configuration is most commonly seen during evaluation and for development systems, where full VPC deployment has not yet taken place. 

HA Controller in AWS

On AWS, shared data stored in highly-redundant S3 storage is used as an HA Controller. A single S3 bucket is created in the same region as the VPC.

HA controller bucket names in S3 are of the form "hacontroller-<haUUID>", where haUUID is a unique ID created by SNAP HA™ and assigned to represent a customer's HA cluster; e.g., "hacontroller-02c8a87d-8af7-4295-962e-8313e1ff6c7d" is an HA controller bucket stored on S3. The HA controller bucket occupies very little space.