We are used to the notion of virtualization in our modern computing infrastructure. Virtual memory has been a fundamental concept in many operating systems for years; virtual disks, virtual machines, and virtual networks are all commonplace in today’s IT environments.
Virtualized access to networked file systems has been available for many years via Microsoft’s Distributed File System (DFS), although few IT shops take advantage of this powerful technology.
The advantages of using a virtualization layer between clients and file servers are numerous, including better organization of a company’s file shares, increased flexibility for storage administrators, and efficient solutions to several business-critical problems, such as load-balancing access to file shares and providing disaster recovery methods for file shares.
Microsoft introduced DFS as an add-on to Windows NT 4.0, and DFS has been included as a free subsystem in all versions of Windows since Windows 2000. DFS consists of a server component, included in all versions of Windows Server, and a client component, included in all versions of Windows.
DFS works with the Server Message Block (SMB) protocol, sometimes referred to as Windows networking. The SMB protocol is also commonly referred to as the Common Internet File System (CIFS). Microsoft’s DFS does not work with non-SMB file networking protocols such as NFS or HDFS.
With DFS, the storage administrator creates a hierarchical namespace of links that point to his company’s file shares. These shares can be hosted by any SMB-compatible device, including Windows Servers, network-attached storage devices from numerous vendors, and even Samba shares. The organization of the DFS namespace can be whatever makes sense for the company. For example, shares can be grouped by business unit, by geographic location, or both. A well-designed DFS namespace makes it much easier for users to find shares in the company’s networked infrastructure.
DFS Namespaces works with SMB file shares regardless of where they’re housed: on-premises Windows File Servers with or without Azure File Sync, Azure file shares directly, SMB file shares located in Azure NetApp Files or other third-party offerings, and even file shares hosted in other clouds. Azure’s data management is essential to customers’ digital transformation journeys due to its power, versatility, and expandability. Here’s an example of how to use DFS Namespaces with Azure Files.
Migrating data from on-premises into Azure is the first and most challenging step. As part of the Azure File Migration Program, Microsoft supports the use of Data Dynamics StorageX for migration into Microsoft Azure at an enterprise scale without requiring customers to purchase separate migration licenses. Click here to know more.
Once a company’s users have switched from using hard-coded share paths to locating those shares via the DFS namespace, the storage administrator has considerable flexibility in managing the physical storage in his infrastructure. For example, if he needs to migrate a group of home folders to a new device with more capacity, he can copy the files as a background task; when the files are synchronized, and he is ready to cut over to the new device, the storage administrator simply re-targets the appropriate DFS link(s) to point to the new share(s), and the users are automatically redirected to the new device the next time they access the DFS namespace.
In my next blog post, I will discuss another very useful feature of DFS, multi-targeted links, which provide solutions to several business-critical problems, such as share load-balancing and disaster recovery.