Hands-On: FSx Storage Gateway with DNS Query Policies

In this blog post, I take the new AWS FSx Storage Gateway for a test spin together with a set of Active Directory DNS Geo-Location policies for a seamless namespace for clients that attach to the gateway. Meaning I only want to tell my clients to attach to a single name (i.e. fsx1.spikebiz.com) no matter if they are using the FSx file system directly or through the gateway.

For this scenario, I am using a FSx deployment in us-west-2 and a FSx Gateway deployment in us-east-1. Clients in us-west-2 attach directly to the FSx server shares while the clients in us-east-1 attach to the running gateway.

FSx Architecture

I followed this excellent blog post by Steve Roberts to create the FSx Storage Gateway setup. The general architecture is depicted below. While I’m using another AWS region, you could just as easily deploy the FSx Gateway in your on-premises environment.

DNS Policy Record Setup

What we want to happen is that our clients in us-west-2 just attach directly to the FSx file system at \\fsx1.spikebiz.com\ and our clients in us-east-1 to attach to the FSx Storage Gateway also as \\fsx1.spikebiz.com Once you get the FSx Storage Gateway created it will show you the IP address that your clients will need to connect to (192.168.6.81) in this case

Here is the DNS resolution for fsx1.spikebiz.com before DNS policy records are added:

Adding DNS policy records we can control the IP address that are retured for clients in us-east-1. After the DNS policy records are created, here is the DNS resolution for fsx1.spikebiz.com from a client in us-east-1.

So how do this work? There are basically 4 steps.

1. Create the Client Subnet (192.168.4.0/22 – us-east-1)
2. Create a new server zone scope (spikebiz.com)
3. Create the new resource record (fsx1.spikebiz.com)
4. Create a new query server resolution policy

We create the following DNS entries from PowerShell.

Add-DnsServerClientSubnet -name "us-east-1" -IPv4Subnet "192.168.4.0/22"
Add-DnsServerZoneScope -ZoneName "spikebiz.com" -Name "us-east-1"
Add-DnsServerResourceRecord -ZoneName "spikebiz.com" -A -Name "fsx1" -IPv4Address "192.168.6.81" -ZoneScope "us-east-1"
Add-DnsServerQueryResolutionPolicy -Name "us-east-1" -Action ALLOW -ClientSubnet "eq,us-east-1" -ZoneScope "us-east-1,1" -ZoneName "spikebiz.com"

When this is completed we can see running the performance tests, that we are in fact using the IP address of the Fsx Storage Gateway

Performance Testing of FSx Gateway

I used the Dskspd utility to gather some performance metrics directly from us-west-2, then from us-east-1 with and without the FSx gateway.

I used the Dskspd parameters from this blog post to calculate the Max IOPS and the Max MB/s.

If I had chosen a different region with greater latency, I would suspect to see a greater difference, but since the traffic was us-west-2 <-> us-east-1 over a VPC peer using a private endpoint the only significant difference is in the Max IOPs which was definitely higher with the gateway than the local FSx system.

The cloud is an architect’s dream. Prior to the cloud if I screwed something up there was tanigle evidence that had to be destroyed. Now it’s just a small blip in the bill. — Mike Spence