AWS FSx for NetApp ONTAP Adds Flexibility and Resiliency to VMware Cloud on AWS
In this blog
The exciting news around AWS FSx for NetApp ONTAP (FSxN) with VMware Cloud on AWS (VMC on AWS) has been a long time coming. The marriage of VMware and AWS's premier hybrid cloud platform to NetApp and AWS's leading cloud data platform unlocks additional features and flexibility for existing and potential customers.
Additionally, WWT's close partnerships with all three companies allowed us to get a sneak peek at the solution and integrate it within our own Advanced Technology Center (ATC) ahead of the announcement.
Before we explain FSxN with VMC on AWS and its benefits, let's take a look at each solution individually to better understand why this development is so interesting.
VMware Cloud on AWS
VMware and AWS jointly released VMC on AWS as a hybrid cloud service offering in 2017. The pioneering partnership was originally intended to speed up cloud migrations by making it easier for customers of both companies to move their VMware-based workloads from on-premises and collocated private clouds to the AWS cloud. This was accomplished by layering VMware's class-leading software defined infrastructure — already adopted in many customers' private clouds — across AWS public cloud infrastructure, creating the ability to move VMware-based workloads and associated data seamlessly between the two environments without the need for costly and time-consuming rehosting and replatforming.
FSx for NetApp ONTAP
FSxN is an enterprise storage platform running NetApp's ONTAP storage operating system natively within AWS public cloud. If you are familiar with the feature sets that NetApp offers on-premises, like deduplication, cloning, snapshots and more, then you will be happy to know that all these features are also supported in FSxN. Many of NetApp's customer-favorite features will come in handy with this VMC on AWS primary datastore integration, notably SnapMirror replication between on-premises and collocated NetApp storage infrastructure and FSxN within AWS public cloud. This will allow customers to migrate VMware virtual machine data, or establish disaster recovery policies targeting VMC on AWS, faster and with less operational overhead and cost.
What is FSxN with VMC on AWS and how does it work?
VMware ESXi has long-supported NFS mounts for hosting virtual machine data and images, so there was no additional work to be done on that front. What AWS, NetApp and VMware have done is figure out how best to integrate these services over AWS cloud infrastructure. Since VMC on AWS is a fully managed offering from VMware and AWS, a customer's software-defined data center (SDDC) actually exists in AWS cloud and not within their own organization. To get the two AWS tenants (VMC on AWS and customer) connected with one another, networking tools such as Elastic Network Interface (ENI), IPSEC tunnel (VPN) and AWS Transit Gateway (TGW) have traditionally been employed. To connect FSxN, a service typically deployed in one of the customer's own AWS Virtual Private Clouds (VPC) and not necessarily the one that is directly connected to VMC on AWS via ENI, VMware and AWS chose to employ VMware's Transit Connect (vTGW), which is a VMware-managed TGW originally intended to connect multiple VMC on AWS SDDCs to one another as well as to the customer's on-premises gateway for cloud interlink. vTGW can also be used to connect to more customer VPCs than just the one VMC on AWS connected to via ENI. This is advantageous as it allows the storage team to manage FSxN out of their own AWS footprint within the organization while extending data services to the customer's VMC on AWS SDDCs.
The one thing customers should keep in mind with this approach is that while there are no egress charges, there is a small fee per vTGW attachment and GB of data transferred just as with AWS TGW. This means variable charges for the integration will depend on application workload characteristics relating to I/O. Furthermore, for existing VMC on AWS customers, the SDDC consuming FSxN must be created within an SDDC group in order to use vTGW. Some environments may need to be reconstructed in order to accomplish this if they were not originally architected that way.
Additional benefits to using FSxN with VMC on AWS
With FSxN, VMC on AWS customers will finally be able to scale storage independently from compute resources and migrate even more of their VMware-based workloads to AWS public cloud, but these are not the only benefits of integrating FSxN with VMC on AWS.
Many of VMware's customers for on-premises and collocated private cloud also use NetApp data storage and management solutions within those same environments. With the feature sets of ONTAP, FSxN allows these customers to extend the same features they already enjoy into AWS public cloud. Features like SnapMirror, Snapshots and Flexclones can now be used to protect and test production data sets for VMC on AWS without having to make full copies. This allows for accelerated migrations and setting up disaster recovery plans with tools that are already well understood by administrators and operators, tools such as VMware SRM. Being NFS, customers will also be able to expand and shrink the datastore on demand. This allows customers to fine-tune the additional storage capability based on inbound workload migrations or potentially retiring workloads once they are replatformed or refactored to take advantage of cloud-native solutions. Additionally, cloud tiering may be employed to incorporate longer term data retention using highly cost-effective and immutable cloud-native storage services like AWS S3.
Why is this solution important?
VMC on AWS is built on VMware vSAN, a hyper-converged infrastructure (HCI) technology that uses software intelligence to create reliable and performant shared storage services across a cluster of compute nodes, with each one contributing their own directly attached storage devices to that end. HCI solutions like vSAN have enjoyed widespread adoption as a way of making shared storage services easier to deploy, manage, scale and operate.
That said, many organizations have found that HCI does not work for every workload. This could be due to one or more concerns with the application to be hosted. One very common issue we see at WWT is vendor support requirements for mission-critical commercial off-the-shelf applications that were written with certain parameters and integrations in mind or have acceptance testing limited to a smaller subset of potential underlying infrastructure. Another common issue is simply how some applications are architected versus how HCI typically operates under the hood. Imagine an application like Hadoop, which is using its own software intelligence to ensure data integrity and availability, riding atop an HCI solution doing exactly the same thing. Though you could obviously tweak vSAN storage policies specific to that end, the result without such additional complexity will be a very inefficient usage of underlying infrastructure.
Furthermore, HCI ties compute scalability (processing and memory) to storage scalability (capacity and performance) by its very nature. While this allows for more granular scaling of HCI environments versus a more traditional three-tier environment, sometimes referred to as converged infrastructure, what happens when storage needs to scale out of step with compute? As an example, a customer might be storage capacity constrained on their VMware virtual machines due to large, attached data volumes associated with the application workload. This means the vSAN cluster will need to grow to accommodate the sizes of these larger virtual machines. However, by adding more VMware ESXi nodes, additional processing cores, memory, software licensing and networking requirements will also be added to the cluster. These expensive commodities may not be necessary if the cluster was already meeting or exceeding those requirements.
For these reasons and more, many customers have continued to use class-leading storage solutions from partners like NetApp for targeted workloads even as they expand their adoption of HCI solutions like vSAN. Up until now, this has not been possible with VMC on AWS without going through third-party managed service providers at significant additional cost. In other words, organizations could not accomplish this on their own and use data platforms of their own choosing. The only other options were to either keep expanding the VMC on AWS host count, usually at higher on-demand pricing if a commitment had already been purchased, or simply not migrate certain application workloads.
Explore FSxN with VMC on AWS in the ATC
As stated earlier, FSxN with VMC on AWS is already featured in our ATC hybrid cloud environment and ready to be showcased for and tested by our customers.
Having achieved top-level partnership status with many of the leading OEMs in IT and cloud service providers, including being named an AWS Advanced Consulting Partner, a VMware Principal Partner and NetApp Star Partner, and holding multiple VMware Master Specialist certifications, including VMC on AWS, we are well-positioned to answer any questions you may have and guide you through next steps.