This year at Ignite, Microsoft announced the Public Preview of Azure File Sync.
I am very excited about this technology, as it gives us another option for file storage and backups in the cloud.
If you’ve worked with File Servers in relation to Azure in the past, you know there are a few other alternative methods and technologies that you can use to get your files into Azure, which we will briefly cover here as well.
The first option that comes to my mind is StorSimple. After all, it was originally designed mostly around File Servers.
In a simplified explanation, StorSimple is a SAN device, which contains a “hot” tier (running on SSDs), a “cold” tier (running on regular HDDs), and an “archive” tier (offloaded to Azure). It looks something like this:
But if you are familiar with StorSimple, you’re probably wondering how it compares to Azure Files/File Sync.
In the following Ignite session recording (Microsoft Azure File Sync), Klaas Langhout explains it well (starting at 26m 25s). He states that:
“the StorSimple team is a part of Azure Storage. We are working together. StorSimple is really a tiering solution with primary storage. You buy an appliance, you put it on-premises, it has a linkage to BLOB to sync. Your native support isn’t quite as good because it is to BLOBs, and it’s converting that file store into BLOBs, and you don’t really have concurrent access, it’s not bi-direction sync.
StorSimple is more around providing that primary storage extension on-premises, with a cloud tier to provide more elasticity. Whereas Azure File Sync is a sync engine. StorSimple has a tiering functionality, Azure File Sync is a sync engine. Azure File Sync can sync content multi-master, across different sites. And it’s using that sync engine to also provide tiering.”
Azure IaaS VM
Alternatively, if you wanted to get files into Azure, you could create an IaaS Virtual Machine, install the File Server role, and add it to your DFS configuration. However, you then have to include multiple Data Disks, possibly including Storage Spaces for expansion, etc.
Now with the availability of larger disks in Azure (up to 4 TB per disk), storage space should not be an issue.
It’s definitely possible, but not as simplified of a solution as Azure File Sync is.
Now, Azure Backup is not a solution for file storage per say. But File Servers are a very common scenario for backups. With Azure Backup, you can directly backup Files and Folders via the Azure Backup Agent.
But then you have to account for data volumes, network bandwidth/throughput, data churn/changes, etc. Case in point, for one customer I setup the Microsoft Azure Backup Server (MABS aka DPM-lite), and configured it to backup a local File Server containing approximately 700 GB of content. The local backups completed without issue, but the online recovery point initially took 75 hours to complete!
Azure File Sync
Now let’s explore Azure File Sync.
Before initiating a deployment, you’re going to want to read some documentation to better understand when/why you would use Azure Files, and when you might not.
You can start with an Introduction to Azure Files. You’re also going to want to understand the differences between the various Azure Storage elements. Here’s some good reference material that helps explain when to use Azure Blobs, Azure Files, or Azure Disks.
It’s also important to note that Azure Files support SMB 2.1 and 3.0, not SMB 1.0 (which by now, we’ve learned that we should stop using SMB1). So keep this in mind if you’re planning on using Azure Files for any legacy applications, to ensure they can operate using a newer protocol.
It’s also important to know that Azure Files only support NTFS volumes today. Hopefully, this will be expanded to include ReFS in the future, but Microsoft has not stated such yet. It’s also important to be aware that Access Control Lists (ACLs) and NTFS Compression are supported.
One of the nice features in Azure File Sync is the Cloud Tier ability, which moves seldom accessed files into Azure Storage, but leaves a pointer reference link to the file on your File Server. This reduces the storage load on your local File Server, but when those files are needed again, Azure File Sync brings it back locally.
Per the referenced Ignite session recording, Azure File Sync is not a DFS-R engine. Rather, it uses the Microsoft Sync Framework, which is also the technology that is used in SQL Server replication and other types of replication (i.e. Work Folders).
Install and Config
When you go through the process of installing the Azure File Sync component, you may encounter the following message. Note that the AzureRM PowerShell module is required on the server. You need to keep this in mind because this also requires PowerShell version 5. So if your server does not have PowerShell v5, you’ll need to install that as well. Also, Azure File Sync is currently only supported on Windows Server 2012 R2 and newer Operating Systems.
Here’s another important piece of information. It may be confusing to figure out how to deploy the Storage Sync Service. For me, I instinctively navigate to More Services > Storage Sync Services.
But, as you can see, there is no “+ Add” or “Create” button, which confused me.
But, if you navigate to + New > Storage, Azure File Sync is listed. I personally feel this is an oversite, and chalk it up to being in Preview. Like all other Azure services, I expect there to be a “+ New” button available when I navigate to the service itself.
After the service is created, it does appear in the list as expected.
Only after you have this Storage Sync Service created will you be able to successfully register your File Server through Azure File Sync.
Now that the server is registered, we need to create a Sync Group.
Now we need to add our File Server to our Sync Group (aka Server Endpoint). You’ll notice that the Registered Server field is only a dropdown list, so you need to complete the installation and registration of Azure File Sync on your target servers first, for them to show up in the list.
Also note that the Path has specific requirements, that of being local.
When I attempted this the first time, I encountered the following error:
Server endpoint creation failed
Server endpoint ‘FileServer.MI.LAB’
Details: Server job with command name NewServerEndpoint and id 8b01e663-6b28-4c5a-b0be-81dc7d09f270 failed with -2134375898.
Correlation ID: 6d38116f-4560-4bc4-9bdd-010275c39e6f
Request ID: d9bf2ecd-c439-4c9b-8bb6-12f88c230018
Digging a little deeper, we see an error in the Event Viewer (under Applications and Services Logs > Microsoft > FileSync > Management > Operational).
Error Details: Server Endpoint creation failed.
Job ID: 8b01e663-6b28-4c5a-b0be-81dc7d09f270
Server Endpoint name: f25e6769-7666-43a2-8e3a-18acc868ebda
ErrorCode: 0x0x80c80226 – Bottomless configuration / ghosting is not supported for given path
After following up with the Product Group, I was informed that “If you enable cloud tiering and, you are setting a path that points to a system/boot volume then it is disallowed.”
So I added another drive to my VM, set up another Share, and re-added the Server Endpoint; this time it worked as expected.
Testing File Sync
And when I copied files into my File Share, within a very short period of time, they appeared in my Azure Files share.
Just one other quick note. If you’re like me and think that the visual experience could be improved by including document-type specific icons versus the generic Azure Files icons, then vote up my suggestion on UserVoice here: https://feedback.azure.com/forums/217298-storage/suggestions/31787329-enhance-azure-files-azure-file-sync-to-include-d