By David Piet, Partner Solutions Architect at AWS
One of the advantages of using VMware Cloud on AWS is being able to leverage native AWS services, such as shared file systems with Amazon FSx, and seamlessly integrate them back into your VMware Cloud on AWS software defined data center (SDDC).
When you provision an SDDC from VMware, the ESXi hypervisors are automatically deployed onto bare metal Amazon Elastic Compute Cloud (Amazon EC2) instances with elastic network interfaces that connect to your own Amazon Web Services (AWS) account.
This post describes how you can take advantage of Amazon FSx in your SDDC. We’ll deploy a fully managed, shared Windows file system with Amazon FSx for Windows File Server and mount it to virtual machines (VMs) running in your SDDC. With this fully managed solution, you and your company can focus on your business—and not your business infrastructure.
Amazon FSx provides you with the native compatibility of third-party file systems. You no longer have to worry about managing file servers and storage, because Amazon FSx automates administration tasks such as hardware provisioning, software configuration, patching, and backups.
The diagram in Figure 1 shows VMware Cloud on AWS linking into a customer-owned AWS account.
Figure 1 – VMware Cloud on AWS linking into a customer-owned AWS account.
Amazon FSx for Windows File Server is built on Microsoft Windows Server and includes full support for the Server Message Block (SMB) protocol, Windows New Technology File System (NTFS), Active Directory integration, and Distributed File System (DFS). It’s backed by solid state drive (SSD) storage, is fully managed, and comes complete with automated backups.
To see how you can use FSx for Windows File Server with your SDDC, consider the following example. Your company is consolidating data centers and wants to migrate a large VMware-based environment to the cloud. Your team is building a set of tools and applications using the Microsoft .NET framework, and you decide to use VMware Cloud on AWS to migrate quickly, without the need for re-tooling or re-platforming.
To keep the storage footprint small while maintaining ease of use, you decide to store the code base and repository in a shared file system. That allows the development team to continuously push, pull, and access code in a fast and easy manner. You also must have a backup component to meet your disaster recovery (DR) needs.
One way to accomplish this would be to deploy the .NET code base and repository into FSx for Windows File Server and mount this file system to the VMware Cloud on AWS virtual machines for in-guest file access.
Before digging into the Amazon FSx setup, here’s some information about the VMware migration. How do you get your on-premises VMs into your SDDC? There are a couple of ways to do this; the easiest is a simple vMotion migration from your on-premises environment into your SDDC.
VMware vSphere allows cold vMotion migrations of your virtual machines from your on-premises data center to your SDDC. However, if you have both AWS Direct Connect and an NSX Layer 2 virtual private network (VPN) setup, VMware vSphere allows you to do a live vMotion migration. Alternatively, VMware HCX is a software-as-a-service (SaaS) offering that provides bi-directional application mobility and is great for bulk migration.
Configuring AWS Managed Microsoft AD
You first need to configure AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD). Why must you use Active Directory with Amazon FSx? Because this is a shared file system with multiple users, and it’s likely they each have different levels of access to the files within Amazon FSx. Use Active Directory to manage access control and grant those respective permissions.
This can be a new instance of Microsoft Active Directory, or, if you already have Active Directory running on-premises, it can be linked to that as well. There’s no need to configure multiple Active Directory instances. The VMs that are deployed in the SDDC can also be joined to this domain, a trusted domain, or no domain at all. That’s a factor to consider when setting this up.
From the AWS Directory Service landing page in the AWS Management Console, choose Set up a directory. This kicks off the configuration process, and the only requirement is that you must select AWS Managed Microsoft AD as the directory type.
Figure 2 – Select AWS Managed Microsoft AD as the directory type.
Provisioning Amazon FSx for Windows File Server
Now that you have Active Directory set up, you can provision Amazon FSx. As noted earlier, Amazon FSx supports two varieties: FSx for Windows File Server and Amazon FSx for Lustre. Because you’re looking for a file system to mount to your Windows VMs running in VMware Cloud on AWS, select Amazon FSx for Windows File Server.
Next, name your file system and select both the storage and throughput capacities. For this example use case, provision 16,384 GiB for storage capacity and the default 256 MB/s for throughput capacity. Some use cases, such as hosting home directories, typically don’t have high throughput demands, so you can use a lower value. Alternatively, if you’re doing something like media processing and transcoding, you will probably want to dial up the throughput capacity.
Figure 3 – Name your file system and select both the storage and throughput capacities.
Now, select the virtual private cloud (VPC) and subnets in which the file system should reside. One important consideration when configuring the networking aspect is that standard AWS data transfer rates apply.
If your Amazon FSx instance resides in the same Availability Zone (AZ) as the subnet associated to your SDDC, there is zero cost associated with data transfer between your VMs and the Amazon FSx instance. However, if your SDDC and Amazon FSx instance are not in the same AZ, you are then charged for the cross-AZ transfer.
Select the Active Directory instance to manage your Amazon FSx instance. In this case, specify the Active Directory instance that you configured earlier.
Next, select the encryption key. You can either use the default key for the account or provide an Amazon Resource Name (ARN) for a different key.
Figure 4 – Use the default key for the account or provide an ARN for a different key.
One of the many advantages of using Amazon FSx is that taking and managing backups are built in and easy to set up. Because it’s a fully managed service, schedule a weekly 30-minute window for patching and maintenance. Set the backups to run at 07:00 UTC and the weekly maintenance for Sunday at 08:00 UTC. You can also opt for no preference when the backups or maintenance window occur.
Figure 5 – Schedule a weekly 30-minute window for patching and maintenance.
Configuring Firewall Rules for the SDDC
Next, ensure that your SDDC can communicate properly with your AWS account. When an SDDC is deployed, by default, there is no communication between it and the connected AWS account. Now, you must open up that access.
To do so, add two firewall rules to your compute gateway in the VMware Cloud console. One rule allows inbound traffic to the compute networks from your VPC, and the other rule allows outbound traffic from the compute networks to your VPC. The two rules are shown in the red box in Figure 6.
Figure 6 – Firewall rules for access between customer-owned VPC and the SDDC.
Performing the Final Touches
Finally, register the VMware Cloud on AWS virtual machines with AWS Directory Service in the same way you would register a Windows instance to any other Active Directory service.
Now, go to a Windows Server 2019 VM running in VMware Cloud on AWS and mount the Amazon FSx file system:
- Open File Explorer and choose This PC, Map Network Drive.
- In the dialog box, select the drive letter of your choice. The folder is \\<File System ID>.<AD Domain>.local\share, where the File System ID is provided by Amazon FSx.
Figure 7 – In the dialog box, select the drive letter of your choice.
Now, you can let the development team resume work on its .NET tools and applications. Because it’s a shared file system, they can see all the changes being made in real-time. The best part is that, because it’s a fully managed service, you no longer have to worry about provisioning capacity, patching, upgrading, maintaining, or handling backup safeguards.
Figure 8 – Complete architecture of the solution.
Pricing for Amazon FSx
There are two major components in the pricing of Amazon FSx in this solution.
The first is the cost of the Amazon FSx instance itself. You pay for the storage and throughput capacity of the file system, as well as the backups. Storage is charged based on the average amount of storage capacity provisioned for your file system per month, measured in GB-months. The throughput capacity is charged based on the average provisioned throughput capacity per month in MBps-months. Backups are charged for the average backup storage per month, also in GB-months.
The second is the standard AWS data transfer charges previously mentioned. If the Amazon FSx instance and the SDDC subnet, which is the same as the VMware Cloud network interface subnet, reside in the same Availability Zone, there are no associated charges for data transfer. If the Amazon FSx instance and the SDDC subnet are in different AZs, you are charged for the data transferred in either direction.
Amazon FSx for Windows File Server is an easy way to provide a fully managed, native AWS shared file system for in-guest file storage to your Windows virtual machines that reside in your VMware Cloud on an AWS SDDC.
You can create file systems ranging from 300 GiB to 65,536 GiB in storage capacity, and with throughput capacity ranging from 8 MB/s to 2048 MB/s. There’s no need to worry about capturing and storing backups, or how to restore from a backup in a disaster recovery event.
In this post, we deployed a fully managed, shared Windows file system with Amazon FSx for Windows File Server and mounted it to VMs running in your SDDC. With this fully managed solution, you and your company can focus on your business—and not your business infrastructure.
To learn more, see Manually Joining a Windows Instance to AWS Directory Service.
from AWS Partner Network (APN) Blog