When looking to use AWS’s new managed file service, FSx for Windows, its important to understand that AWS make sure that this is highly available within a single AZ. This is done by replicating your data across this AZ (which includes one or more discrete datacenters) seamlessly in the background. This availability will generally be enough for mainstream use and the majority of your data, however what about business critical data? What happens in the highly unlikely event of large service disruption (or full outage) within a AZ? What would the cost of not having access to these files be to your business or users? This is where the benefits of running services in a Multi AZ (that is regionally distributed) configuration becomes clear.
In order to achieve this, we need to ensure our data is both up-to-date and available. We need to not only replicate the data from one FSx file system into another located in another availability zone (Multi AZ), but provide access to either the primary or secondary (replicated) copy seamlessly without intervention.
To be able to meet both requirements of replication and access, we need to configure the replication between file systems and implement infrastructure that will provide a single point of access to files stored within multiple AZ’s. This implementation utilises Microsoft DFS (distributed file system) in both variants; DFS-R for replication and DFS-N for namespaces (to allow your users to access either the primary or secondary data copies through the use of a single HA path). The below diagram shows the logical file access path following our DFS deployment:
In the tutorial, we will look to implement a HA solution of AWS FSx for Windows into your existing windows domain. If you are following the guide in your own environment, we will presume:
- Your VPC is setup and at least one subnet is configured for each AZ you want to deploy into
- Your Active Directory is setup and accessible by your AWS environment and you have admin access
AWS FSx for Windows previously only supported using your on-premise domain where a trust to their managed AD service was in place as FSx for windows only supported AWS Managed AD. However, it now supports your own in-house active directory domain. This can be either though an on-premise domain controller or a domain controller running on a EC2 instance.
The below diagram shows the VPC infrastructure we will be implementing to provide our Highly Available Multi AZ FSx for Windows.
In this implementation, we will have 2 DFS namespace servers (one in each AZ). These servers will publish the namespace (single UNC path for users to access files through). We will also configure replication between each managed FSx filesystem. Our domain and test client will be located in AZ A. DFS and FSx file systems will be placed in AZ B and C.
- Domain: testdomain.thecloudwolf.com
- Domain Controller: TE-DC01 (172.16.0.10)
- Client PC: TE-CLIENT (172.16.1.15)
- DFS Namespace Server in AZ B: TE-FSazB (172.16.5.20)
- DFS Namespace Server in AZ C: TE-FSazC (172.16.10.30)
All instance sizes and FSx implementation sizes would need to be adapted and adjusted to your own environment to meet your throughput and data needs. I will look to publish another article, which focuses more on sizing of this infrastructure, but for this article, we will focus on the implementation.
Continue to Part 2 where we begin the configuration by launching our DFS servers.