AWS – Making AWS FSx for Windows Highly Available through Multi AZ Resilience – Part 6: Testing Multi AZ FSx for Windows High Availability

To check our namespace will still be available if we were to lose one of our namespace servers, we are going to simulate a failure of the one of the namespace servers and then also remove connectivity to our primary subnet containing a FSx filesystem and a namespace server (this is the subnet in AZ B). This loss of connectivity should have no impact on accessing our files, and also, once restored, should replicate any changes while it was offline.

Checking namespace availability for FSx Filesystems

For this, I am going to log into the AWS console, and shutdown the EC2 instance for the first namespace server added (TE-FSazB). Shutting down this instance, we are still able to browse to the UNC path of our namespace and also directly to both of our FSx fileserver’s.

Next, in order to check that we will still have access to our files in the unlikely event of a AZ failure. We need to simulate a total loss of connectivity to our namespace server and FSX filesystem in availability zone B. In order to check total loss of connectivity, I have created a new ACL that we will apply only to the subnet in availability zone B where our FSx filesystem and namespace server sits. This will BLOCK all traffic inbound and outbound of the subnet, cutting it off from the rest of the network/VPC.

After applying the network ACL, we are no longer able to access the UNC of the FSx fileserver in availability zone B directly, or remote desktop onto TE-FSazB. But we are still able to access the UNC of our FSx filesystem and the namespace server in AZ C.

Testing that we can still access our namespace while not able to access resources in AZ B is successful. This shows that the namespace is accessible and has also updated to point to use the FSx filesystem in AZ C.

To check that our data will remain consistent when out AZ comes back online, I have placed a new file called “NewFileWhileAZBDown” into the namespace UNC path. This shows up properly on the FSx filesystem in AZ C.

After resetting the NALC back to its original access and giving it a moment to catch up, we can see that once the FSx filesystem is available, the file we created when it was disconnected has replicated back across successfully.

This testing shows and confirms that we have successfully created a Highly Available Multi AZ FSx for Windows deployment.

Continue to Part 7, to review some information on costs and also review some considerations that should be taken into consideration when looking to deploy FSx in general and also in a multi AZ solution.