Just DFS it!


I see a lot of questions from customers and others around how to handle user data and replication – in this post I’ll go over some considerations around user and data management and why DFS can be an ideal choice.

First off, what are my options?

Most of the time, customers have the following considerations:

  • Local File Server
  • Array Based (CIFS/SMB)
  • Embedded VDI (View Persona, Personal vDisk)
  • DFS

Each of the above has it’s own applicable scenarios, but each comes with caveats.  Local file servers are site specific and have limited HA capabilities in the case of a site outage.  Array based solutions are high performing (…initially) however are inflexible and expensive, and embedded VDI can be a configuration nightmare and forces vendor lock-in.  So what to do?

Follow the KISS principle!

I’ve gone through a ton of complex datacenter and system designs and one very fundamental principle to a successful deployment and operation is not making things more complex than they need to.

When it comes down to it there are very simple things needed by any file/user data storage platform:

  • Manageability – I have to be able to build AND manage it
  • Availability – Data needs to be available
  • Performance – I don’t want to spend a lot of time waiting
  • Scalability – I need to be able to increase storage capacities

Guess what, we can have all of these with DFS …and Nutanix :)

Windows DFS – A Primer

We’re all aware of Windows file servers and have likely been using them for ages.  DFS advances these capabilities and provides IT something that can be deployed and managed for the enterprise.  Deployment of DFS is done by installing the File Services role with the DFS features.  You can also learn more from Microsoft here: http://technet.microsoft.com/en-us/library/cc732006.aspx

DFS can be broken down into two main components (we’ll go into each further below):

  • DFSN – The DFS Namespace Component
  • DFSR – The DFS Replication Component


DFSN creates a domain based namespace (\\mydomain.com\DATA) which clients can access shares.  Each namespace is composed of one or many DFS file servers each hosting storage and data.  A key piece to DFSN is that the namespace might consist of multiple file servers which are dispersed in multiple geographical locations, however when accessed by clients it appears like a single share.

When accessing a namespace share the client’s DFS file server is chosen based upon targets which can be based upon cost, local site or randomly.  If a client were to move from one site to another and the referral cache duration (time to cache referrals for namespace) has expired the client’s DFS target would then be a different (preferably local) DFS file server.

Below we show an example of how DFSN looks to a client:




DFSR is the replication capability of DFS and allows admins to create replication typologies and schedules.  This allows for both high-availability in the case of a DFS file server, or site, failure as well as for the ability to perform I/Os on a local DFS file server as compared to going over the WAN.  This can be used to replicate user data from the branch to a failover site or datacenter as well as for bits/software distribution between sites.

DFSR has a few main typologies:

  • Hub and Spoke
  • Full Mesh
  • Custom

The hub and spoke topology is similar to your normal branch office (spoke) and datacenter (hub) replication topology.  This topology is great for branch office user data failover where the user data and virtual desktop might be hosted at a branch office, and in the case of a site outage be failed over to a datacenter.  This topology is also normally used for data collection for central backups of multiple sites.  With this model remote spoke sites would replicate data to the hub site where the data would then be centrally backed up.

Below we show an example of what this looks like:



The full mesh model replicates between all participating peers and is best suited for smaller replication groups.  This can also be used for peer replication between a few sites where they will protect each other or to replicate data between a few sites.

Below we show an example of what this looks like:



Custom replication topologies can be configured for cases where full mesh or hub and spoke models don’t fit.

In conclusion…

Is DFS the answer for every user data issue or data replication decision?  No.  However, it can be a good starting point and solution to be considered for multiple scenarios.  I’ve used this and deployed in instances ranging from DFS for VDI user home folder redirection to ISO and software replication between sites and vDisk replication for Citrix PVS.

Remember, follow the KISS principle

Comments are closed.

Legal Mumbo Jumbo

Copyright © Steven Poitras, The Nutanix Bible and StevenPoitras.com, 2014. Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Steven Poitras and StevenPoitras.com with appropriate and specific direction to the original content.