File servers are a key foundational workload in most organizations.  In addition to providing shared folders for document collaboration, storage and archiving, they can also serve as a data repository for other key business applications.  As such, file servers are a kind of “network utility” for data storage, without which most organizations would find it hard to continue operations.

Disaster Recovery challenges …

When planning a disaster recovery strategy, shared file services are often one of the first workloads for which organizations find themselves needing an effective recovery approach.  Of course, you may already have a traditional backup plan for recovering file servers, but have you tested it recently? Many organizations find that traditional restore processes for recovering large file servers take too long and do not meet Recovery Time Objective (RTO) expectations.  In addition, some data may be very volatile, and performing only traditional daily backups may not be meeting your Recovery Point Objectives (RPO) either.

  • Learn more about DR: Check out the entire series HERE.

Don’t get me wrong … Backups are good!

Traditional backups are still needed and are a good first step in preparing yourself with basic recovery options.  But, to reduce recovery time and data loss to tolerable limits that meet your RTO and RPO, you’ll want to consider augmenting a backup strategy with more agile recovery options.  In this article, I’ll discuss one such recovery scenario for key file server workloads: implementing a file server replication strategy to a disaster recovery site leveraging Windows Azure and Windows Server 2012 R2.  And, the good news is … we’ll be using capabilities that are native to these products, so you won’t need to purchase expensive storage solutions or third-party software.

Wait! What if I don’t have a Disaster Recovery site?

Lots of organizations have “single-site” networks or may lack a dedicated disaster recovery site.  If your organization falls into this category, you should take a look at Windows Azure!  As an on-demand cloud platform, Windows Azure can provide a really cost-effective alternative to a traditional DR site, and one that can be “brought online” much more quickly. 

In fact, for many of the IT Pros I speak with, Disaster Recovery in the Cloud is a key area of interest even if they already have a dedicated DR site – to help reduce their costs associated with disaster recovery.

Distributed File System Replication (DFS-R) to the Rescue!

To build an effective file server replication solution for disaster recovery purposes, we’ll be leveraging the built-in Distributed File System Replication (DFS-R) engine in Windows Server 2012 R2.  Actually, DFS-R has been available as a core technology of Windows Server since the days of Windows Server 2003, but nearly every major release of Windows Server since then has brought significant new enhancements to DFS-R for improved scalability, performance and management.  In Windows Server 2012 R2, we’ve tested DFS-R for asynchronously replicating up to 70 million files per volume with a combined size of up to 100TB of data!

In fact, we’ll be leveraging a new feature of DFS-R in Windows Server 2012 R2 to speed up the initial replication of a large set of files: DFS-R database cloning.

  • Get the FAQ’s on DFS-R! See this DFS Replication FAQ which has been updated for Windows Server 2012 and Windows Server 2012 R2.

DFS-R Dependencies

To leverage DFS Replication, there are a couple dependencies that we’ll need to keep in mind prior to configuring DFS-R:

  • Site-to-Site connectivity: there needs to be a direct connection between sites for DFS-R to communicate between servers.  Typically this is accomplished via either a WAN connection or a Site-to-Site VPN connection.  In this article, we’ll be walking through the process of establishing a secure Site-to-Site VPN connection to a Windows Azure Virtual Network that will be used as our “on-demand DR site”.
     
    BONUS: Secure Site-to-Site connectivity to a private virtual network in the cloud is also a key infrastructure enabler for many other on-demand cloud scenarios, such as disaster recovery, on-demand dev/test environments, and line-of-business application hosting.
     
  • Active Directory: Like many applications, DFS-R also depends on Active Directory.  To support DFS, we will want to extend our Active Directory forest with local domain controllers at the DR site, in much the same way that we’d extend Active Directory to a branch office location.
     
    BONUS: By extending Active Directory to our DR site, you’ll also be improving your Active Directory disaster recovery posture.  Since many applications depend on Active Directory, this provides much more value to your DR plan than just supporting File Server recovery.

By implementing these dependencies first, you’ll not only be supporting the needs of DFS-R for disaster recovery.  Rather, you’ll be paving the way for your organization to leverage the cloud for lots of key scenarios that can improve agility and reduce costs.

File Server Disaster Recovery Scenario

In our file server disaster recovery scenario, we’ll be stepping through the following tasks:

  • Build a Windows Azure Virtual Network with cross-premises connectivity
  • Extend on-premises Active Directory to Windows Azure Virtual Network
  • Provision a file server on the Windows Azure Virtual Network
  • Install and configure DFS Replication on Windows Server 2012 R2
  • Implement a DFS Namespace

By the time we’re done, our scenario will resemble the diagram below.

image
File Server Disaster Recovery Scenario with Windows Azure and DFS-R

Let’s get started …

To proceed through the tasks in this article, you’ll need an active Windows Azure subscription.  If you don’t yet have a Windows Azure subscription, you can activate a free subscription via our Windows Azure trial program.

To begin these tasks, sign-in to the Windows Azure Management Portal with the user credentials that you used when activating your Windows Azure subscription.

  1. Build a Windows Azure Virtual Network with cross-premises connectivity.
     
    Windows Azure Virtual Networks currently support secure cross-premises connectivity via a Site-to-Site IPSec VPN tunnel to an on-premises VPN gateway or firewall.  In addition, forth-coming joint support has been announced for direct connectivity to Windows Azure via Equinix, AT&T and Level 3 Communications.
     
    DO IT: Step-By-Step – Extend Your Network to Windows Azure Virtual Networks
     
  2. Extend on-premises Active Directory to the Windows Azure Virtual Network.
     
    Provision a new Active Directory domain controller for your existing Active Directory forest in your Windows Azure Virtual Network to provide Active Directory availability in your on-demand cloud-based DR site.
     
    DO IT: Step-by-Step – Extend Active Directory to the Cloud using Windows Azure Virtual Networks
     
  3. Provision a file server on the Windows Azure Virtual Network.
     
    This virtualized file server will be the target for DFS Replication.   In the event of a disaster, you’ll be able to leverage DFS Namespaces to failover from the primary on-premises file server to this cloud-based file server. 
     
    DO IT: Step-by-Step –  Create a Virtual Machine running Windows Server on Windows Azure
     
    When provisioning your file server VM, be sure to …
    - Add to the same Windows Azure Virtual Network provisioned above.
    - Via a remote desktop connection to the VM, add to your Active Directory domain.
     
  4. Install and Configure DFS Replication on Windows Server 2012 R2
     
    The DFS Replication role service will be installed on both your on-premises file server as well as your cloud-based file server provisioned in the task above.  As part of the initial configuration of DFS-R, we’ll be using the new DFS-R database cloning feature to speed up the initial synchronization process.
     
    DO IT: Step-by-Step - DFS Replication Initial Sync on Windows Server 2012 R2 by Ned Pyle
     
  5. Implement a DFS Namespace 
     
    Domain-based DFS Namespaces provide a a consistent shared folder path for accessing replicated shared folders on the primary file server, or in the event of a disaster, the replica of those shared folders at the DR site.  As such, it provides an easy method to manually failover shared folders to the DR site by re-targeting the DFS Namespace folders with the locations of the replica folders at the DR site.  Since the shared folder path that applications are accessing is a consistent DFS Namespace path, applications do not need to be updated or repointed to new data locations.
     
    DO IT: Step-by-Step Guide to Deploying a DFS Namespace 
     
    With the DFS Namespace implemented, failover of shared folders from production to DR sites is as easy as updating the DFS Namespace folder targets.  Once these DFS Namespace changes replicate via Active Directory, users will be connected to the appropriate folder targets transparently when connecting via the DFS Namespace path.

Completed! Want more?

In addition to this scenario, you may also be interested in the following additional step-by-step cloud scenarios:

See you in the Clouds!

- Keith