Last week I spoke at the Virtualization Group - Boston event held at Microsoft's Waltham offices. I enjoyed meeting the group very much and let me thank Tim Mangan for letting us participate in that event.

Tim has continued that conversation about AutoVirt file virtualization and Microsoft DFS online at his blog, and it has been interesting to follow along. Now seems like a good time to chime in. There are a couple of items in the comment thread worth addressing – so hopefully I can explain some of the reasons our customers need the capabilities that AutoVirt supplies.

1) What’s the big differentiator to DFS? 

Let me tell you the story of one of our customers.  He had five Windows file servers with 6,000 shares that were used by 2,000 people in his company.  He needed to move it all to a new NetApp without impacting his users.  After installing AutoVirt he created the namespaces in 20 minutes, converted the 2,000 users from direct access to access via the AutoVirt namespaces in 5 minutes, and kicked off migration in one minute.  The next six weeks, AutoVirt on his behalf, migrated all the shares and users on nights and weekends. After watching the rate of progress, he decided to speed it up.  He added 10 servers from a blade farm to the AutoVirt configuration and it automatically redistributed the workload.

His users never discovered what was going on and he took the time originally allocated to work other things.

Now, let’s examine the differences between DFS and AutoVirt and imagine the same story played out with DFS.  

1. DFS namespaces are created manually with a GUI or a script.  Creating a namespace with 2,000+ folders, 2,000+ sets of ACLs, and 2,000 targets that way would take a prohibitively long time.  Testing and debugging the result afterwards would be similarly demanding.  AutoVirt does all that in 20 minutes using its automated file server inventory function.
   
   
2. Changing all the shortcuts and embedded links used by the 2,000 users and get that right would be equally monstrous. Some of our customers have million of embedded links in databases and files making it impossible rather than hard. AutoVirt makes it entirely unnecessary to change any of these by transferring the file server names to its namespaces in the domain controller and renaming the physical filers.
   
   
3. DFS has no data management capabilities.  The DFS manual makes the following suggestion for data migration:
   1. Install the new filer
   2. Create all the 2,000 shares with ACLs on the target
   3. Take the old file servers offline
   4. Copy files and ACLs to the new server with RoboCopy
   5. Edit the 2,000 namespace targets manually in the DFS namespace
   6. Bring the clients back online (and keep your fingers crossed)

The AutoVirt migration policy does all that, no manual labor required, no downtime required.  In AutoVirt, policy and namespaces are automatically kept synchronized.

In DFS, the namespace is the purpose.  In AutoVirt, the namespace enables data management independently from data use.

In fact, there are many differences between AutoVirt and DFS and if you are interested in learning more then you should check out the DFS Tech Brief on AutoVirt's resources page.

2) What about reparse points and MKLINK? Why do you need a broker like AutoVirt instead of just using the built-in reparse points?

Agreed, if a namespace was my only purpose then I would use re-parse points instead of DFS or AutoVirt.  Re-parse points are fine for file system extension or for adding capacity as long as all the users come in the same way and are willing to traverse through them.  File systems that are built this way makes data management harder since re-parse points contain additional physical references.

A global namespace that is delivered separately from the participating file system creates an abstraction that provides stable views for the users while allowing the IT staff full freedom to relocate, replicate, and provision. Let me give a few examples:

1. Data migration. With a namespace, the content of any target can be relocated independently and at any time.  This enables server replacements, consolidation, splits and merges, and tiering.
2. Copy Replication. With a namespace, the “same” data can exist in multiple places.  Clients will use a single URL to get the full list of referral targets and will select the closest copy regardless of where they are at any time.
3. HA Replication. Two copies of the data are maintained, one as primary, the other as a standby.  The namespace is used to switch the clients.  Policies are used to synchronize.

These examples only work as long as the namespace is independent from the file systems.

In summary, AutoVirt automates the management of data and file system resources, the namespace is a feature, not the goal.

Check out what we are doing at http://autovirt.com.