Save to My DOJO
In this article, I will focus on Azure File Sync, explaining the service and the use cases. I will not be able to touch everything about Azure File Sync, but I will try to include the most important things and guide you to the rest so that you can find them in the documentation or additional resources.
What is Azure File Sync Service?
When I try to explain Azure File Sync, I normally start with: “Think of Windows Server Distributed File System Replication on Drugs, or Office 365 One Drive for Servers.”
So, to understand file sync we need to understand its on-premises equivalent and its client equivalent first.
Microsoft Office 365 OneDrive
With OneDrive, users can access and store files from various devices like Windows Clients, Mobile Phones and Web Browsers. The access is built to be easy and secure. Users can cooperate with others on files within an organization or outside of it. Users can share those files using the Microsoft Content Delivery Network. To access OneDrive you need either a web browser or the OneDrive Client which integrates into the Operating System of your Client or Mobile Device.
OneDrive is primarily built for User files like those you would classically put into a user fileserver home directory. It’s not meant to be used as a classic file share.
Distributed File System Replication
Distributed File System Replication or DFS Replication is a role service within a Windows Fileserver that was introduced in Windows Server 2008. Since then it is part of all Windows Servers. DFS R is the successor of File Replication Service or FRS. It was built to replace FRS as the replication engine for DFS Namespaces as well as Windows Server Active Directory Domain Services (Windows ADDS) SYSVOL folder. This folder contains the Active Directory Domain Information for a domain and forest. You can enable DFS R to replace NFS starting with Windows Server 2008 or later domain function level.
DFS-R is a pretty good Windows Service, sometimes a bit hard and clunky to set up and stabilize, but it does its job.
In comparison to Azure File Sync, you can consider File Sync as a cloud-managed DFS-R Service which uses Azure Storage Backend in addition to local File Servers.
How it works
In the difference to Distributed File System Replication, Azure Files works with a sync client like OneDrive.
The client syncs all data to an Azure Storage Fileshare. Azure Storage acts as a central repository for all attached File Servers.
You can use Azure File Sync to sync Fileshares and Servers from 2012 R2 and newer. You can sync fileserver clusters and stand-alone servers.
This gives you a great option to set up global Fileshares using DFS Namespaces and also set up redundancy without the hustle of cluster hardware.
With the Fileshares and Files, the Access Control Lists (ACLs) are also migrated between servers. If you want to use a local fileserver only, you do not need to do anything in addition but there is also the option to use Azure Fileshare target directly without a fileserver. That would be a great scenario if you are already in Azure and want to save some money or have a branch or datacenter very near to an Azure Region. The latency should be below 12 milliseconds.
There is only one small issue, Azure Files is based on Azure AD Users, Groups and Permissions. So, every user or computer who wants to use the Fileshare must be hybrid joined/cloud synced. To achieve that, your Windows Active Directory must be synced with Azure Active Directory. A guide to configuring the hybrid connectivity can be found below.
Here you can find more information about the File Sync and Identity integration.
Another feature worth mentioning is the cloud tearing and cloud site backups possible with Azure Files and Azure File Sync.
With cloud tiering, you enable a feature that only caches the most frequently accessed files on-prem on the local storage. Other files are transferred to Azure and only kept as a local link. Those files can be downloaded on demand. You can control how many files are uploaded by limiting the storage and local disk space used on-prem on the fileserver.
For more information about cloud tiering, please visit the Cloud tiering overview.
You can also set up different peering policies. You will find a detailed guide about these policies as well as the requirements here: Choose Azure File Sync cloud tiering policies | Microsoft Docs
Cloud Site Backup
We all know the struggles of backing up a fileserver, especially when you don’t want to impact the user while reducing fileserver performance during backup.
Normally you only have a small timeframe to backup your file server. That timeframe is mostly out of business hours during the night. With that there are two issues coming up:
- If the backup fails, you will see it the next morning and you probably won’t have a backup from the past day.
- If the fileserver becomes larger you could run out of time when backing up many changes or new files.
With Azure Backup combined with Azure Files and File Sync, you avoid those issues. Azure Backup can run any time without any performance impact on the Storage.
It also enables a quicker restore. If you need to restore files, you can restore them on Azure and the files will be replicated to all connected fileservers automatically.
I don’t want to go too deep into the implementation because there is a very granular tutorial on the Microsoft Azure Docs, but let me explain what you basically need:
- Create an Azure Storage for Files and download the sync client
- Install the client on your fileserver and connect it to the fileshare
- If you want to implement a hybrid identity, you need to implement and configure Azure AD Connect
As said, you will find all guidance needed following the link below.
I don’t want to go through all the possible use cases but will concentrate on the most common ones.
As already discussed above, the most common case to use Azure File Sync is to replace file replication between servers and branches regionally or globally. Customers use Azure to cache and replicate their file storage or discover fileservers from Azure Storage.
Azure File Sync replicates the files to an Azure Storage Vault and pulls down changes from Azure Storage Vault if files changed. The intelligence to manage duplicates or access is done by Azure File Sync Service Azure component.
So, nothing really fancy and uncommon in that use case.
Reduction of Storage Cost for Branches and Datacenters
Another pretty common use case is to reduce storage costs in a datacenter or branch. Reasons to reduce the storage costs are obvious, normally for on-prem you pay around 23 cents per Gigabyte in storage costs, while in the cloud it’s around 2 cents plus maybe another 5 cents on bandwidth to access the files.
So it is a no-brainer that you want to replicate rarely accessed data to the cloud instead of keeping it on disks in your server.
To be honest, that scenario only makes sense when you can fulfil the following requirements:
- You have cold data which can be uploaded to Azure
- You have enough bandwidth to download cold files if they need to b accessed for some reason
If you want to use access Files on Azure live without any download, you should also fulfil the following requirement:
- Low latency access to Azure Region storing the data. I normally prefer a latency lower than 12 milliseconds. Above that, you could run into issues.
That scenario has some great benefits:
- Reducing storage, electricity, and operational costs
- Optimizing your economic and ecological footprint
- Reducing space needed in datacenter and branch for the equipment.
- Free up resources for other operations or projects
You can also use Azure Backup or Altaro Backup to back up your files directly in the cloud.
That optimizes resource usage of the hardware still on-prem and you can maybe move the Fileservers on Hyperconverged Systems like with Azure Stack HCI or others.
The next scenario would be File Migration and Hardware replacement.
In the past, I had customers who used Azure File Sync to migrate their Fileservers to other Hardware, Virtual Machines or Locations. They just set up Azure Filesync to Sync all data over to Azure and then down to the new Fileserver.
After the Migration, they just remove the old fileserver and the Azure Filesync Migration and Agent.
So, they spare license costs and development time for Migration Tools and Scripts and they only spend Azure Costs during the migration.
For Fileserver cleanup, there are two options. The first one is to reduce the amount of storage used and the other is removing a Fileserver completely from a site.
When using the scenario for reduction of storage used on your fileserver, you use basically the tiering feature we discussed before. You would use the cloud tiering feature. There are two options to reduce the amount of storage.
- Silent removal: You use the cloud tiering feature, keeping your data on-prem and waiting for the tiering feature to kick in. This means the data is silently moved to Azure and removed from the storage depending on usage
- Big Bang: You replicate all data to Azure, connect Azure to a new Server or Folder on the server, and keep all data in Azure if it is not needed. If needed, the data is downloaded on demand.
As previously said, another common scenario is to remove the Fileserver completely from a branch or datacenter. Here you replicate the data to Azure and then disconnect the Fileserver as an endpoint. Afterward, you mount the fileshare directly from Azure to your clients using DFS-N or direct link and shut down the original Fileserver.
So Azure File Sync is a nice tool for shutting down traditional Fileservers.
Is it REALLY the Future then?
As we already learned with the previous blog about Azure Files, it might not be the right tool or service for everyone. If you fit into the limitations and scenarios, it’s an awesome service to work with. Azure File Sync removes the issues we all faced for example with DFS-Replication timeouts or SMB Transfer over wide area networks.
It also brings more value to an enterprise, as we are considering for example OneDrive, dropbox, etc. a replacement for Fileservers. These tools are great for personal data but if you have classic applications that need SMB or NFS, I would still stick with my Fileservers.
It also adds additional security, as it encapsulates traffic into SSL encryption.
I would highly recommend going through the Microsoft documentation and building yourself a lab to test it.
The lab guide can be found here:
Overall, it’s a great addition to every infrastructure engineer or administrator toolbox.
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!