Azure Storage Sync Services is a relatively new offering within an Azure tenant that lets Azure customers place data in the cloud and synchronize it to other servers within an organization or make it available to Azure VMs directly within Azure.
Note: this article assumes familiarity with the terms used in the Azure Portal.
It’s not always desirable for branch office users to use potentially limited bandwidth to gain access to files at the corporate office. Rather, these users need a method for gaining access to a synchronized local copy. The situation is similar to the functionality provided by the old BranchCache functionality of earlier, non-cloud-oriented versions of Windows (If you’ll pardon the oversimplification). In addition, the backup requirements of local file shares—and shares spread around the organization—may be more expensive than those offered by an Azure backup solution. In this case it makes perfect sense to keep a master copy of the file data store in Azure where a backup can be taken, and a subset—even a complete set in some situations—can be kept on-premises. All of the backup infrastructure devoted to files can then be decommissioned, or otherwise diverted to applications that remain on-premises. The local branch office servers now no longer need to keep an entire copy of a file share–just a percentage of available space, based on recent access.
To create the Azure File Sync resources in the right order, these key elements are required:
1. Resource Groups
Create a new Resource Group in Azure. A separate RG is useful because it allows you to easily track such things as costs and assign management and access control roles to the new service.
2. Storage Account
Create a new Storage Account in Azure, configured to the optimum disk type. You’ll probably just want the cheapest storage available, for two reasons. Firstly, users won’t be writing directly to this location. Secondly, you pay for every Megabyte of storage, so you won’t want to pay SSD prices for a service for which you don’t need the IOPS.
3. Create a file share on Azure
That’s it. Don’t do any more there for now.
4. Create a Storage Sync Service
You can have several, but the initial deployment only requires one. This ties-in with the RG, so if you plan to deploy multiple RG’s—say, in a complex management environment—you can now achieve that level of management.
Now let’s turn our attention from the Azure portal and look at the servers that will act as the server endpoints. See this article: https://docs.microsoft.com/en-us/azure/storage/files/storage-sync-files-deployment-guide?tabs=portal for how to configure the on-premises servers. This connects your Azure subscription, Resource Group, and Storage Sync Service to the local server. At this point, you’re not configuring file shares that may already be on the server. Once you’ve successfully registered the servers you need to synchronize, go back to the Azure Portal.
5. From the Storage Sync Service, create new synchronization groups
This maps the share you created to the servers that will synchronize with it. It also connects the storage account to the share, so if you do find a requirement for more IOPS in the file shares, here is where you’ll select a different storage account (remember: the storage account is where the disk category is selected).
You now have a Resource Group for management, a Storage Account for the right storage category, and a Storage Sync Service that maps to the Resource Group. Finally, you have a Storage Sync Group that connects the cloud endpoint you created (the file share on Azure) to the server endpoints. But you still don’t have any server endpoints.
In the Storage Sync Group, select Add Server Endpoint. Since you’ve already used the link above to register the endpoints, you’ll be able to use the drop-down list to add the registered server. Next, manually enter the file path at the endpoint. To start with new shares, create and share them on the endpoint. Otherwise, if you want to synchronize data from an existing share—and copy the data into the cloud—enter an existing path to a shared folder.
If your goal is to synchronize the whole directory, you don’t need to do anything with Cloud Tiering, since that’s designed to place only a subset of data onto other servers. You might see that one on-premises share is wholly sent up to Azure, while other endpoints only have a certain number of days (since last modification) of data, or data up to a space-guarantee on that remote endpoint.
The file share names at the various endpoints don’t need to have the same file path or share name, which allows flexibility when synchronizing data to locations of different server configurations, or even server languages. If you think back to a semi-similar analogy in the Exchange DAG—where every copy of the Exchange database and logs had to be in an identical drive and folder structure—the benefits of this flexibility are plain to see.
In summary, multiple file servers from around the world are now able to synchronize data up to Azure File Services, where a centralized backup can take place, and from where other users in the organization may view and (when permissions allow) edit the documents. Saved documents are efficiently returned to Azure and synchronized down to those file shares whose users summon the documents once more.
I hope you found this post helpful. Microsoft Azure is a diverse and wide-ranging technology and our blog has covered many related topics. Please check out our additional Azure posts and podcasts from Anexinet here. Anexinet also offers a Cloud Strategy Kickstart, which is the perfect way to begin your Azure journey. Lastly, please don’t hesitate to contact us for a personal answer to any burning Azure questions. We’d love to help you out.