Does Zadara have the ability to connect to multiple VPCs at AWS?
Within a private data centre, the flexibility of owning and managing the local network means that the way in which storage is assigned to servers can be tightly configured. Fibre channel provides all the capabilities for multi-tenancy, using features like zoning and masking. In the IP world, traffic can be isolated through the use of VLANs and separate subnet ranges.
In Amazon Web Services (AWS), Virtual Private Clouds or VPCs can be used to create whole isolated networks that can be further subdivided into separate subnets. A VPC might be used to manage an entire department or in many cases there may only be a single VPC defined. Zadara’s VPSA provides the capability to connect to multiple VPCs and deliver multi-tenanted storage either to one or more VPCs in a single AWS account or connect multiple VPCs from separate AWS accounts. Multi-VPC support provides a high degree of flexibility in defining storage networks with VPSA, as well as making sure resources are used as efficiently as possible.
Let’s dig a little deeper and see how the configuration from a VPSA to multiple VPCs is achieved. The following diagram shows at a high level the relationships between the networking components with AWS. Within a VPC, multiple subnets can be defined to subdivide the network. Each subnet can be associated with an Internet Gateway (IGW) to provide external connectivity and/or a Virtual Private Gateway (VGW) that can be used with Amazon Direct Connect to provide a route through to a Zadara VPSA. 
Direct Connect uses Virtual Interfaces (VIFs) and the BGP (Border Gateway Protocol) to establish a peering connection from a previously defined VPSA in Zadara’s infrastructure to the virtual gateway in AWS, specifically for the customer’s AWS account(s). VIFs are account specific and so can be used to connect multiple accounts to a single VPSA.
In my example I have created two VPCs under the same AWS account, as IP networks 172.18.0.0/16 and 172.19.0.0/16. These have two associated subnets, 172.18.0.0/24 and 172.19.0.0/24 respectively. The route table for each subnet points to the VGW assigned to that subnet for each VIF pair through Direct Connect. Here’s the VIF pair for one of the two connections.
I added an explicit route to the VPSA network, in this instance 172.29.224.0/22 (EU-West), but is dependent on AWS region. You can see there is an Internet Gateway and VPG defined in this routing table, providing both internet connectivity and a connection to the VPSA.
Note that the VPCs and subnets originally chosen above must be separate from the ones already in use for VPSAs in the region being used. Once the networking is in place, I can test access to my VPSA:
After that it’s then a simple case of logging into the VPSA GUI and configuring up either LUN or NFS access and assigning to hosts within the appropriate subnets. Here are my two servers, mapped to the same VPSA across different subnets from the two VPCs.
The flexibility of being able to associate multiple VPCs with a single VPSA allows for many configuration options. These could include:
- Production/Dev Testing – A single VPSA could provide production access from one VPC and development from another, with VPSA snapshots used to generate data copies between the two platforms.
- Segment Block and File Traffic – A single VPSA could provide NFS/SMB access through one VPC and subnet, while delivering block data for servers through another VPC.
- Run a single VPSA for multiple accounts – there may be reasons to segment AWS accounts (for billing or other purposes). VPSA VPC support enables a single VPSA to support multiple accounts, providing a single billing and management point for shared storage.
Most importantly, I can map the VPSA into my AWS network in multiple places, without having to redesign the network around VPSA. This is a powerful feature that provides the same level of flexibility that could be achieved with traditional on-premises storage.
To learn more about the VPSA functionality, download the data sheet.
