FSx for Windows is an AWS service that offers a fully-managed Windows File Server in the AWS Cloud. Recently, I’ve been working on a project in which we are setting up FSx for Windows to act as a centralised file server in a Microsoft Distributed Filesystem (DFS). The DFS replicates (DFS-R), allowing data written locally at remote sites to replicate to the cloud. If a local file server goes down, the local site can access these files the same way, connecting to FSx instead of locally.

Architecture Diagram

This article is born out of frustration, as I didn’t find much information on configuring FSx with an existing DFS-R filesystem. So hopefully, this resolves any headaches for someone who wants a bit of confirmation that what they’re doing is right or perhaps wrong (in which case, they’ll learn how to do it correctly).

But before you dive too far, there are some things to ponder.

Thoughts on DFS vs DFS-R for FSx

This is a great question, as even though there is a use-case for DFS-R, is it warranted? (i.e. is it the best use-case for DFS-R here?).

DFS-R is old technology; many businesses use it because it’s reliable for what it does - file replication. Of course, this was required in the days of slow internet, but it’s a good argument that in the modern-day, with high-speed fibre being pretty standard, is there a need for replicating files to local sites for lower latency?

DFSR’s viability for your business is a question your team will need to investigate and answer, and is dependent on how you have configured your network and your connectivity to AWS. If you are currently utilising DFSR, it will also depend on how it’s presently configured.

It’s essential to factor in AWS Services like FSx File Gateway and AWS Direct Connect if on-premises connectivity and latency are concerns preventing you from abandoning DFSR.

Filesystem Versions

AWS FSx has a few versions of their filesystem available for deployment:

  1. FSx Version 2 Multi-AZ (SSD/HDD)
  2. FSx Version 2 Single-AZ (SSD/HDD)
  3. FSx Version 1 Single-AZ (SSD Only)

The importance of going over this is only one of these filesystems supports DFS-R: the version 1 filesystem. By choosing a version 1 filesystem to use FSx with DFS-R, you are limited to an older FSx version, and in addition, you only have a single-AZ option that only supports SSD.

Architecture Diagram

In most cases where you’re using DFS-R, this isn’t a problem as you need the high-performance SSD (you can offset the cost somewhat with deduplication), but it’s still important to note. Why? Think of the following situations:

  • You are migrating from an on-premises file system to a cloud one.
  • You’re using DFS-R for replicating data to a location that won’t be read/written from/to

Although the version 1 filesystem would work in both situations, it wouldn’t be ideal. For example, in the 1st scenario, you’d need to deploy another expensive version 1 filesystem and use DFS-R between them to get the extra availability; this introduces the need for a management instance to manage DFS and additional technical debt (and cost).

In the 2nd scenario, you’re paying more for an SSD instance when you could change your approach entirely and utilise a tool to sync data to an HDD FSx or use a service like S3, which works excellent for cold data and would save costs.

In my opinion, the only situation where you should deploy a version 1 filesystem is if you are currently using DFS-R, heavily depend on it, and plan to continue using it for the foreseeable future. It is possible to migrate from one FSx filesystem to another type using DataSync. For example, suppose you plan to relocate SMB workloads to the cloud but know it will take years. In that case, decommissioning some on-premises servers and replacing them with an FSx version 1 filesystem will give you time to migrate. It will still be significantly better than using your on-premises file server.

Reasons for DFS-R in the First Instance

Before considering setting up a version 1 FSx filesystem, I think considering whether DFS-R even suits your use-case any longer is worthwhile. DFS-R, as mentioned above, is quite old and does have its flaws. It requires additional technical debt via monitoring (presumably with SCOM or a third-party tool) and further management. Sometimes you’ll run into issues with DFS-R. If your monitoring isn’t solid, you may not even notice! If your monitoring is good, and you do notice - it might require a long troubleshooting session depending on the issue.

While I won’t get into them here, some alternatives to DFS-R are worth exploring. At least investigating other options will expand your horizons and allow you to plan the best cloud migration for your organisation.

AWS FSx is Still the Best Solution

Despite all these thoughts about whether DFS-R is the best solution, DFS is still a superb solution for SMB filesystems. Without the additional technical overhead and potential issues of adding replication to the mix and beyond that, FSx is a highly robust and performant SMB solution for your infrastructure.

If you think DFS-R may not be the best option for you any longer, moving to a version 2 FSx filesystem will give you better performance and multi-AZ choice, providing that fully-managed availability. Combined with all the additional benefits FSx offers a fully-managed service on top, making this an excellent choice. DFS is still compatible with version-2 systems, and I imagine it always will be - if your infrastructure needs a refresh, consider migrating to a more modern solution.

Setting Up FSx with DFS-R

Ok, the part you have probably been waiting for - where we set up DFS-R with FSx.

To relieve some potential technical headaches, here are a few points to note about how FSx for Windows behaves with DFS-R:

  • There is nothing you need to enable on FSx to enable DFS-R explicitly. The service is running by default.
  • You must allow the standard DFS-R ports (445, 135, 5722).
  • If possible, allow all outbound traffic to specific servers in the DFS. If you need to restrict ports, even to particular servers - ensure all ports are allowed as described here.
  • Ensure you can access the FSx SMB Server from each file server in the DFS to ensure communication is working.

Steps to enable DFS-R

Configure SMB Share

Firstly, ensure you configured your SMB shares correctly. If you use DataSync to migrate data to your FSx filesystem, ensure you look at the owner of the SMB shares and make sure you’ve set it to a user that’s part of a group you’re actually in (i.e. not the local FSx user, as this won’t work).

Configure DFSR

Configure DFS-R as described here. You don’t need to do it from Powershell explicitly, but if you find copying and pasting commands easier, then do it that way.

In general, the process will look like this:

  1. Add the FSx filesystem into the replication group
  2. If copying from another file server to FSx, ensure you set the FSx filesystem as secondary and the local file server as the primary.
  3. Set a file target for the FSx filesystem inside the replication group for a specific replicated share (you’ll need to repeat this for each replicated share in the group).
  4. Configure replication direction, schedules and bandwidth.
  5. If you configured this correctly, wait for 30-minutes (to be sure), and then test replication.

Due to the lack of logging on FSx (since it’s fully managed and you can’t see Operating System logs) and the complexity of setting up DFS-R in some environments, this might take a couple of rounds of troubleshooting.

Good References

Closing Notes

I hope, at the very least; this article might have given you some things to think about and ponder; at the most, it might give you that little link or hint of information that relieves a massive headache.

Keep learning, folks.