This blog post is focused on setting up Amazon FSx for Windows File Server step by step that I recently tested in my POC lab.
Introduction to Amazon FSx:
AWS launched this service last year during their yearly product launch event re:Invent 2018. If you are still thinking what is Amazon FSx so basically it’s a managed file system service provided in AWS cloud. Amazon FSx service is available in two different file system types below based on the platform.
- Amazon FSx for Windows File Server
- Amazon FSx for Lustre – This is for the Linux based platforms.
In this blog I will talk about Amazon FSx for Windows File Server, this service is fully built on the native Microsoft Windows based file system and has rich integration and support with Active Directory, DFS, SMB and Windows NTFS. Since it fully supports SMB protocol, we will be able to use this file service with many different variety of Windows workloads and services that can use this as SMB share.
Data Backup and Maintenance:
As this is a fully managed cloud service we don’t have to worry about the data backup or maintenance of FSx file systems like we do in On-prem for traditional Windows file servers or any other workload running in on-prem datacenter. FSx file system automatically takes backup every day once however we have the ability to modify the schedule or initiate on-demand backup manually. We will see those option later in this blog.
When you deploy single Amazon FSx file system in Availability Zone (AZ), it is going to reside in the same AZ that we specify during creation wizard and will be replicated with same AZ. This will be highly available within the AZ only, which means if there is any fault occurs at AZ level the FSx file system will not be available. If you would like to have AZ level redundancy then we need to deploy FSx file system across at least 2 or more Availability Zones so it will be able to tolerate AZ level failures and our FSx file system service will always be replicating across AZs and will be online even in the event of single complete AZ failure. My lab implementation is Multi-AZ so I will be deploying two FSx for Windows File Server file systems across two different AZ.
People who are not familiar with concepts like AWS Regions and Availability Zones, Please have a look at the below documentations.
Connectivity from On-premises:
Amazon FSx service supports both AWS VPN and AWS Direct Connect so whatever connectivity you have between your On-premises and AWS you will be able to access FSx file systems from your On-premises network.
Prerequisites for FSx for Windows File Server:
1. “AWS Managed Microsoft AD” – We need to have AWS Managed Microsoft AD domain which requires to deploy FSx for Windows File server file system.
2. In case if you have your ADDS environment running on EC2 instance in the VPC, In this scenario also you need to have “AWS Managed Microsoft AD”. You need to create trust relationship between your corporate ADDS running on EC2 and “AWS Managed Microsoft AD”. Same will be applicable if you have On-premises ADDS.
3. AWS AD Connector is not supported as of today with FSx.
4. AWS VPN or AWS Direct Connect between On-premises and AWS if you would like to access FSx file systems from On-premises network.
Lab Deployment and Configuration:
Now let’s login to AWS Console and deploy two Amazon FSx for Windows File Server file systems across two AZs so this lab is going to be FSx Multi-AZ scenario based with replication across both AZ.
- I already have AWS Managed Microsoft AD in my lab so I will be using this for my FSx lab.
2. Now I will go to FSx service in AWS Console and this is how it looks like. Now click “Create file system” to deploy FSx file system.
3. Now will get option to choose which type of FSx file system you would like to deploy. As I mentioned above, we have two type of FSx file systems based on Windows and Linux platform workloads. I selected Amazon FSx for Windows File Server because I’m implementing this in my lab considering Windows-based workloads.
4. Now you need to provide storage capacity that you need for your FSx file system, we can’t create FSx file system below 300 GB so I’m specifying the minimum. Further you need select VPC where you would like to deploy this FSx file system, then you can choose directory service that will be used by FSx. Here you also have ability to specify maintenance window and backup schedules for your FSx file systems.
5. Review the details and click “Create file system”.
6. My FSx file system is being created now.
7. I’m creating two FSx file systems in two different AZs as I explained above for Multi-AZ scenario. I will repeat same steps for creating FSx in second AZ so I will not detail about that.
Ok, so now if you see now we have two FSx file systems ready across two different AZs in same VPC in North Virginia region.
8. If you verify from Active Directory console for your directory used by FSx, you will find computer objects created and joined to the domain. In DNS Management console you will see CNAME records created for each FSx file system against these computer object’s host (A) records.
At this moment we have Multi-AZ FSx for Windows File Server ready but now we need to configure replication between these two FSx file systems across different AZs so that our data stored on FSx file systems are highly available and replicated for redundancy. FSx for Windows File Server replication across two AZs will use native DFS feature to replicate data across both FSx file systems.
The default file share that you get with FSx file system is \\FSx-FileSystem-ID.domainname\share, as per my knowledge and experience in the lab this “share” folder is available on D: volume on FSx file system in the backend but you will not able to create your own folder and share under D: volume on FSx file system. So you will always to have use this default provided share but you can use DFS Namespace feature to have your custom UNC that will be mounted to end users.
I will discuss two different scenario for “FSx for Windows File Server” in this lab implementation.
Scenario 1: Multi-AZ FSx File Systems with DFS Replication:
To access FSx file systems and configure replication we need to have one EC2 instance where we need to install Windows RSAT tools and then we need to configure DFS replication between FSx file systems using DFS PowerShell cmdlets.Launch an EC2 – Windows instances in two different AZ in same region as FSx file system, For now I need only one EC2 Windows instance to configure DFS replication for FSx file systems but later I will be using these two EC2 instances as DFS Namespace servers for scenario 2 for FSx with DFS Namespace Failover). So please don’t be confused why I’m launching two EC2 instances.
- Launch an EC2 – Windows instances in two different AZ in same region as FSx file system, For now I need only one EC2 Windows instance to configure DFS replication for FSx file systems but later I will be using these two EC2 instances as DFS Namespace servers for scenario 2 for FSx with DFS Namespace Failover). So please don’t be confused why I’m launching two EC2 instances.
2. Both of the above instances are joined to same domain (lab.local) as the FSx file systems.
3. Install RSAT Tools on both of the EC2 instances. Though we don’t need all the RSAT tools but this is just lab environment and I might need different RSAT tools later for different purpose.
4. Reboot the both servers to take effect of changes.
5. Now we have all the core requirements met and we will follow below steps to configure DFS Replication between FSx file systems across two AZs.
6. Now login to one of the EC2 instance and run below PowerShell cmdlets to create DFS Replication Group and Replicated Folder.
$ReplicationGroup = “LabDFSReplication
$RepFolder = “LabDFSRep”
New-DfsReplicationGroup –GroupName $ReplicationGroup
Grant-DfsrDelegation –GroupName $ReplicationGroup –AccountName “FSxAdmins” –Force
New-DfsReplicatedFolder –GroupName $ReplicationGroup –FolderName $RepFolder
7. Collect FSx file system’s hostname from AD by running below cmdlets, we will use FSx instance hostname in the next step to add them to DFS Replication Group that we created above.
$FSxFSID1 = “fs-048xxx”
$FSxFSID2 = “fs-0e75xxx”
$FSXComputer1 = (Resolve-DnsName $FSxFSID1 –Type CNAME).NameHost
$FSXComputer2 = (Resolve-DnsName $FSxFSID2 –Type CNAME).NameHost
8. Add FSx File Systems to DFS Replication Group.
Add-DfsrMember –GroupName $ReplicationGroup –ComputerName $FSXComputer
Add-DfsrMember –GroupName $ReplicationGroup –ComputerName $FSXComputer2
9. Configure DFS Membership and Replication:
$ContentPath1 = “D:\share”
$ContentPath2 = “D:\share”
Set-DfsrMembership –GroupName $ReplicationGroup –FolderName $RepFolder –ContentPath $ContentPath1 –ComputerName $FSXComputer1 –PrimaryMember $True
Set-DfsrMembership –GroupName $ReplicationGroup –FolderName $RepFolder –ContentPath $ContentPath2 –ComputerName $FSXComputer2 –PrimaryMember $False
10. Create DFS Connection between both FSx file systems:
Add-DfsrConnection –GroupName $ReplicationGroup –SourceComputerName $FSXComputer1 –DestinationComputerName $FSXComputer2
11. Now verify by creating some folders under “\\FSxFileSystemID\Share” on one of the FSx file system and it should be replicated to another one in less than a minute. See the below screenshot.
Note: Now we have Multi-AZ FSx for Windows File Server ready to be used by end users and services. This is highly available and redundant file server configured. Now you can map this file system to end user as network drive to use it.
Scenario 2: Multi-AZ FSx File Systems with DFS Replication and DFS Namespace Failover:
In this scenario I will use DFS Namespace feature to configure failover between FSx file systems. As we already deployed two FSx file systems in previous scenario and configured DFS replication, now using DFS Namespace we will configure first FSx File System to act as Primary and second FSx file system as Secondary.
We will configure a custom namespace (domain based DFS Namespace) which will be hosted by DFS Namespace servers and target for this namespace will our both FSx File Systems. So the folder mapping at the end users/services will be a common user friendly namespace (like lab.local\corpshare) but actually it will be targeted to FSx File Systems behind the scene (like \\FSxFileSystemID.lab.local\share). People who have experience managing DFS environment in the enterprise will understand this. People who are new to Windows DFS can go through below Microsoft document to understand Distributed File System (DFS).
DFS Namespaces overview:
Note: We need two EC2 Windows instance acting as DFS Namespace server in the same AZ as FSx File Systems for this lab. As you know I had already built two EC2 instances in previous scenario (though they were not used in that scenario – I used only one for management purpose) I will be using those two EC2 instances as DFS Namespace server for this scenario.
My two DFS Namespace servers are DFS03.lab.local and DFS04.lab.local running in same AZ as FSx file systems. If you are wondering why the name is DFS03/04, I used DFS01/02 for my other lab in same domain.
- Install DFS Features on both EC2 instances.
2. So I have DFS Management Console available now.
3. Right click on “Namespaces” in DFS Management Console and Click on “New Namespace”.
4. Enter the name of the first DFS Namespace server, In my case it is “DFS03”.
5.Specify namespace name, whatever name you specify will appear as “YOURDOMAIN\NAMESPACENAME”. So in my case it will be “lab.local\CorpShare”.
6. If you would like to change some settings like this shared folder’s ACL you can click on “Edit Settings”. You can do this later as well after successful creation.
7. Select “Domain-based namespace” and leave all other option as is and proceed further.
8. Now click on “Create” to create this DFS namespace.
9. Now we have DFS Namespace created successfully.
10. Now go back to the DFS Management console, you will see namespace created with DFS03.lab.local server.
11. Add the second DFS Namespace server “DFS04.lab.local” to the same DFS namespace. Please follow the below screenshot.
12. Ok, finally I have both DFS Namespace servers (DFS03/04) added to my DFS Namespace \\lab.local\CorpShare.
13. Till this step I have created a DFS Namespace “\\lab.local\CorpShare” with two DFS Namespace servers running on EC2 instance, So how is it related to FSx file systems ??
To answer above, now we need to create a folder hosting on this namespace and “Target” for that will be FSx file systems. You can have multiple such folder hosting on the namespaces. Keep following the steps further:
A folder target is the Universal Naming Convention (UNC) path of a shared folder or another namespace that is associated with a folder in a namespace. Adding multiple folder targets increases the availability of the folder in the namespace.
14. Click on “New Folder” in DFS Management Console, provide any desired name and specify UNC path for first FSx File System (in my lab it was \\fs-048xx.lab.local\sahre).
15. Add second FSx File System as “Folder Target” to the same folder. This FSx file system will be secondary.
Now I have both FSx File Systems added as primary and secondary to the DFS Namespace.
16. Now if you access “lab.local\corpshare” namespace from client or any server you will see both FSx instance mapped as DFS location as Primary and Secondary.
17.Now if I create couple of folders under this location, it will be actually creating on FSx file systems and replicating across both AZs.
18. I created above folders under DFS namespace, let’s confirm if it’s actually creating on FSx and replicating, And Yes it is.
19. Now you can map the DFS share to end users either via logon scripts or GPO.
Multi-AZ File System Deployments:
This was all based on personal lab implementation experience. Please share your feedback if there is anything incorrect or something missing here. Your feedback is highly appreciated.