In this article we configure Azure NetApp Files and Windows Server DFS Namespaces to have resilient Enterprise File Shares. The file shares and the corresponding data will be replicated, so in case of a regional disruption, access to the shares can be transparently redirected to a secondary region.
This article was created in collaboration with Arnt de Gier (NetApp) and Max Melcher (Microsoft).
The replicated file shares can be used in either applications, or home- or team-drives, and virtual desktop environments that must be resilient to regional disruption or service maintenance events.
With Azure NetApp Files and Cross-Region Replication combined with Windows Server Distributed File System Namespaces (DFS Namespaces), businesses can prepare for disasters and recover in a second region.
Cross-Region replication is, at the time of writing this post, in Preview. You need to request access to use this feature.
For this post, we assume you have one subscription. All the needed components will be created step-by-step. You can use your existing on-premises Active Directory infrastructure or build one in the cloud.
We start by creating a Virtual Network (VNET) in the primary region, we choose Germany West Central:
As Address Space we create two subnets, one for VMs and one for Azure NetApp Files (ANF) with a CIDR size of /28.
Then we create a second VNET in the secondary region. We choose France Central for our example:
Then we create the Active Directory Servers in the primary region:
We add the VM to the primary VNET:
Next we create a secondary Active Directory Domain Controller in the secondary region:
And place it in the secondary VNET:
To build a Domain Forest, replicating a domain across regions, we peer the VNETs to enable direct communication of the two Active Directory Domain Controllers:
This is the list of the resources we deployed so far:
Domain Forest & DFS Namespace
DFS Namespaces is a role service in Windows Server that enables you to group shared folders located on different servers into one or more logically structured namespaces. This makes it possible to give users a virtual view of shared folders, where a single path leads to files located on multiple servers
Next, we promote the servers to Active Directory Domain Controllers by installing the Active Directory Domain Services feature. Additionally, we install the DFS Namespace feature to allow grouping shares on different servers behind a single path.
Next, we promote the server to a Domain Controller and create a new domain contoso.com:
We also promote the secondary VM to a domain controller and join this the existing domain contoso.com:
Next, we create an Azure NetApp account in the primary region:
We add a capacity pool of 4 TB Premium storage:
Then we configure the Active Directory Domain Settings with the private IP of the primary Domain Server that we created earlier:
Before we can create the first share, we need to delegate the ANF subnet to Azure NetApp/volumes:
And repeat this for the secondary VNET:
Afterwards, we create a first volume in the primary region:
We use SMB and select the Active Directory configuration:
And repeat this for the Azure NetApp account in the secondary region:
Joining the Azure NetApp Files account to the secondary Domain Controller in the secondary region:
And create a new capacity pool in the secondary ANF.
Please note: the performance tier must not be equal to the source volume. In this example the primary has Premium performance, the secondary has standard performance:
Then we create a protection volume in the secondary region:
Select SMB as protocol and the secondary VNET:
Next, we need to authorize the replication from the source to the destination. For this we need the Resource ID of the source volume. You can get this from the Properties blade of the source volume:
And added to the protection volume settings. We chose 10 minutes as replication schedule:
Next, we need to copy the Resource ID of the destination volume to authorize the replication:
And authorize the replication in the source volume by providing the Resource ID of the destination volume:
The replication will then start and replicate the volume from the primary to the secondary region:
Configuration of DFS Namespace:
Next, we create a DFS Namespace to point to the share in the primary region:
And host the Namespace on the primary Domain Controller:
And then add the namespace on the secondary Domain Controller as well:
Lastly, we add a new folder to the namespace. We name it Vol1 and point it to the primary ANF volume by using the mount path that we can see in the Azure Portal:
Adding the new folder with the source mount path:
The file share is now available through the path \\contoso.com\share1\vol1:
Every change of a file or folder will then be replicated based on the replication schedule.
We can confirm this by mounting the replicated volume in the secondary region. The data is available in read-only mode there:
For failing-over to the secondary region, we need to do two steps:
- Break the replication on the ANF volume
- Change the target in the DFS namespace to point to the volume in the secondary region
We break the peering on the primary volume:
The secondary volume now becomes writable.
In the DFS namespace we change the target of the share to the secondary volume:
The DFS Namespace now points to the secondary volume.
The great benefit of this is that the fail-over is transparent to the user, the access path does not change. Because the data is replicated continuously, we can also test the disaster recovery at any given time and ensure the process and availability of the files.
In this blog post we showed, end to end, how to configure a resilient File Share environment with Azure NetApp Files Cross-Region replication. Additionally, we did a fail-over to the secondary region by leveraging the DFS Namespace feature available in Windows Server.
In case you have questions or feedback, please post a comment.