Disaster Recovery for Enterprise File Shares

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

CRR.png

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.

 

Infrastructure Overview

 

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:

MaxMelcher_0-1633349153322.png

 

As Address Space we create two subnets, one for VMs and one for Azure NetApp Files (ANF) with a CIDR size of /28.

MaxMelcher_1-1633349153334.png

 

Then we create a second VNET in the secondary region. We choose France Central for our example:

MaxMelcher_2-1633349153343.png

 

 

Then we create the Active Directory Servers in the primary region:

MaxMelcher_3-1633349153352.png

 

We add the VM to the primary VNET:

MaxMelcher_4-1633349153362.png

 

 

Next we create a secondary Active Directory Domain Controller in the secondary region:

MaxMelcher_5-1633349153371.png

 

And place it in the secondary VNET:

 

MaxMelcher_6-1633349153380.png

 

 

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:

MaxMelcher_7-1633349153391.png

 

 

This is the list of the resources we deployed so far:

MaxMelcher_8-1633349153402.png

 

 

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.

 

MaxMelcher_9-1633349153421.png

 

MaxMelcher_10-1633349153434.png

 

 

Next, we promote the server to a Domain Controller and create a new domain contoso.com:

MaxMelcher_11-1633349153440.png

 

 

We also promote the secondary VM to a domain controller and join this the existing domain contoso.com:

MaxMelcher_12-1633349153445.png

 

MaxMelcher_13-1633349153451.png

 

 

Next, we create an Azure NetApp account in the primary region:

MaxMelcher_14-1633349153453.png

 

We add a capacity pool of 4 TB Premium storage:

MaxMelcher_15-1633349153455.png

 

Then we configure the Active Directory Domain Settings with the private IP of the primary Domain Server that we created earlier:

MaxMelcher_16-1633349153458.png

 

Before we can create the first share, we need to delegate the ANF subnet to Azure NetApp/volumes:

MaxMelcher_17-1633349153463.png

 

And repeat this for the secondary VNET:

MaxMelcher_18-1633349153466.png

 

Afterwards, we create a first volume in the primary region:

MaxMelcher_19-1633349153471.png

 

We use SMB and select the Active Directory configuration:

MaxMelcher_20-1633349153474.png

 

 

And repeat this for the Azure NetApp account in the secondary region:

MaxMelcher_21-1633349153477.png

 

 

Joining the Azure NetApp Files account to the secondary Domain Controller in the secondary region:

MaxMelcher_22-1633349153479.png

 

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:

 

MaxMelcher_23-1633349153481.png

 

 

Then we create a protection volume in the secondary region:

MaxMelcher_24-1633349153487.png

 

Select SMB as protocol and the secondary VNET:

MaxMelcher_25-1633349153490.png

 

 

 

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:

MaxMelcher_27-1633349153499.png

 

And added to the protection volume settings. We chose 10 minutes as replication schedule:

MaxMelcher_28-1633349153502.png

 

 

 

Next, we need to copy the Resource ID of the destination volume to authorize the replication:

MaxMelcher_30-1633349153510.png

 

 

And authorize the replication in the source volume by providing the Resource ID of the destination volume:

MaxMelcher_31-1633349153512.png

 

 

 

 

The replication will then start and replicate the volume from the primary to the secondary region:

MaxMelcher_33-1633349153521.png

 

Configuration of DFS Namespace:

Next, we create a DFS Namespace to point to the share in the primary region:

MaxMelcher_34-1633349153528.png

 

And host the Namespace on the primary Domain Controller:

MaxMelcher_35-1633349153534.png

 

And then add the namespace on the secondary Domain Controller as well:

MaxMelcher_36-1633349153544.png

 

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:

MaxMelcher_37-1633349153550.png

 

Adding the new folder with the source mount path:

MaxMelcher_38-1633349153557.png

 

Replication Test

 

The file share is now available through the path \\contoso.com\share1\vol1:

MaxMelcher_39-1633349153562.png

 

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:

MaxMelcher_40-1633349153566.png

 

Fail-Over Test

 

For failing-over to the secondary region, we need to do two steps:

  1. Break the replication on the ANF volume
  2. Change the target in the DFS namespace to point to the volume in the secondary region

 

We break the peering on the primary volume:

MaxMelcher_41-1633349153569.png

 

The secondary volume now becomes writable.

In the DFS namespace we change the target of the share to the secondary volume:

MaxMelcher_42-1633349153576.png

 

MaxMelcher_43-1633349153581.png

 

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.

MaxMelcher_44-1633349153585.png

 

Summary

 

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.

REMEMBER: these articles are REPUBLISHED. Your best bet to get a reply is to follow the link at the top of the post to the ORIGINAL post! BUT you're more than welcome to start discussions here:

This site uses Akismet to reduce spam. Learn how your comment data is processed.