How to route floating IP addresses across multiple AWS AZs for NetApp Services?
A subnet cannot span more than one availability zone (AZ) in AWS. Because of this, the IP address assigned to an instance in one AZ cannot be reassigned to another instance in a different AZ.
Applications that require users to have a single IP address for connectivity, such as cloud-based NFS and CIFS services, need a way to failover to a different instance in another AZ when a node fails. This fault tolerance is key to services like NetApp’s ONTAP Cloud. A single AZ solution does not satisfy users’ demands for a guarantee of an always-on solution.
In order to overcome the AWS limitation, NetApp relies on “floating” IPs addresses for failover between nodes in different AZs. Floating IP addresses are outside the range of the VPC CIDR. The subnet(s) routing table is updated to direct traffic destined for the floating IP addresses to the ONTAP device.
Clients connect to the floating IP address rather than the IP address of the node itself. When a node failure (or even an entire AZ failure) is detected, the floating IP address is “moved” to an instance in another AZ via a change to the route table(s).
The floating IP solution works well if the client is in the same VPC as the server. However, if the client is not in the same VPC (as in the diagram below), AWS will not be able to route traffic to it using the floating IP address. Since the floating IP address is outside of the CIDR range of the VPC (and outside of any peered VPC), those packets will never exit the VPC.
Aviatrix solves this problem by handling routing of the floating IP addresses in the client VPC. All packets destined for the floating IP address(es) will be delivered to the Aviatrix Gateway. The gateway maintains an internal route table that points those packets to an Aviatrix gateway in the server VPC. Once in the server’s VPC, AWS can route to these IP addresses without issue.
Detailed step-by-step deployment instructions can be found on docs.aviatrix.com.