Azure File Sync (AFS) is a solution developed by Microsoft to allow organisations to use Microsoft Azure as a centralised platform for files and company data, whilst also maintaining the performance and compatibility of the existing on-premises file server solutions which have been used for many years. Files that are stored within the Azure File Share can be cached and tiered to on-premises servers removing the requirement of large physical disks.
In the last week, Microsoft have announced Azure File Sync to become generally available, resulting in a lot more organisations now more inclined to use the solution within their production environments. risual has been using this solution for the last 6 months as part of a global transformation project. AFS has become a very useful tool to provide a cloud alternative solution as opposed to using the traditional on-premises file servers. The following resources are the main concepts for Azure File Sync
- Resource group – A resource group will need to be created first. This will store all the resources required for File Sync to be set up.
- Storage Account – To set up AFS, you will need to create a storage account to hold the data. It is not a requirement to choose a certain type of replication for the storage account, this can be locally redundant storage (LRS), zone redundant storage (ZRS), geo-redundant storage (GRS) or read-access geo-redundant storage (RS-GRS). This is based upon cost and how your organisation would like the data stored.
- Azure File Share – An Azure file share is required to store all the data of which is uploaded to Azure. The file share holds all the data and replicates, if chosen, to other servers in the same sync group. An Azure file share has a maximum size limit of 5tb. If you have more than 5tb worth of data, you will need to think about creating additional storage accounts and file shares.
- Storage Sync Service – A Storage Sync Service is deployed into the resource group that is created at the very beginning before any resources are deployed. This allows servers to be registered to Azure into the sync service, to later be added to the sync group. Without a Storage Sync Service, you will not have anywhere to register the servers to upon registration.
- Storage Sync Group – A Storage Sync Group is deployed into the Storage Sync Service. This holds the servers and Azure file shares that you would like to be in sync. Cloud and server endpoints are added to the sync group to allow a simultaneous sync between all the endpoints. A cloud endpoint is the Azure file share that has been created within the storage account. All files that are synced to Azure, will be held within the cloud endpoint. Server endpoints are servers that have been registered with AFS that also require a copy of the data set.
How to register a server?
You can register a server to an Azure File Sync Group by installing the storage sync agent on to your required server. The latest agent can be downloaded from the following Microsoft site – https://go.microsoft.com/fwlink/?linkid=858257. Before registering the server with the agent, you will need to complete the following pre-requisites;
• Disable Internet Explorer Enhanced Security Configuration. This is only required whilst you install and register the server. As soon as this has complete, you can proceed to re-enable this for security purposes.
• Install Azure RM module via PowerShell. You can do this by running the following command in PowerShell as an administrator – ‘Install-Module AzureRM -AllowClobber’
If the Azure RM module does not install correctly, please ensure the server has access to download the required files via the firewall over ports 443 and 9443.
Once the above pre-requisites have been completed, you can proceed to install the agent downloaded from the above Microsoft link. You will need to choose which resource group the File Sync Service has been deployed to, the storage account that holds the Azure file share, and the Azure file share itself. Once this has completed, it will appear in the Storage Sync Service in Azure as a ‘Registered Server’.
Cloud Tiering is a very useful feature of AFS that can offer some great benefits to organisations. Cloud Tiering, when enabled on the server will store a percentage of files in Azure and then releases disk space on the server that has Cloud Tiering enabled. This feature means that you can store for example, 80% of your files in Azure and 20% of the files on the server, meaning only 20% disk space will be used on the server. The full data set of files will show as normal to users on the file server, although if a file is opened which is stored within Azure, it will be pulled down and can be accessed as normal.
Cloud Tiering can be enabled on the server endpoint within a file sync group. You will be required to set a percentage of disk space to be retained on the server. If you choose 50%, AFS and Cloud Tiering will always ensure 50% of the data is stored within Azure. Once enabled, Azure will frequently check for files that are ‘hot or cold’. ‘Hot files’ will be stored on the server as physical files to ensure they can be accessed fast when required. Files that haven’t been used in a while will be classed as ‘cold files’ and stored in Azure. When ‘cold’ files are required to be accessed, they will be pulled down from Azure and opened.
Azure File Sync Scenario
risual have been involved in a global transformation project for a global customer, migrating on-premises file server solutions to Azure. Below you will see a high-level diagram of the solution deployed to achieve a successful migration.
The customer has an existing file server on-premises which contains the full user data set, along with all the shares. A Robocopy takes place to copy the dataset over the LAN to a new on-premises caching server. The on-premises caching server will then have File Sync installed and configured to the Azure File Sync Service. All shares are re-created on the on-premises caching server and users will be mapped via Group Policy to point at the required shares.
Once File Sync has been installed on the caching server, the server endpoint is then added to the File Sync group in Azure. This means that the server will then copy the data to the Azure file share via the internet using ports 443 and 9443. Cloud Tiering is also configured at 60%, ensuring that 40% of the files are always hosted on the caching server and preserves 60% disk space due to other files kept in the Azure file share.
In the solution, we also deploy an Azure file server to hold the full dataset too. The reason for this is due to backup purposes, by backing up the file server, it provides a longer retention policy in the event of a restore. Therefore, File Sync is also installed onto the Azure file server, cloud tiering is not enabled for this server.
My thoughts on Azure File Sync
Overall, I think Azure File Sync is a great service provided by Microsoft and as of yet, I have not experienced any major issues which would stop me using this in the future for customer engagements. For more information on Azure File Sync and how you can begin to use this service, please see the following Microsoft article – https://docs.microsoft.com/en-us/azure/storage/files/storage-sync-files-deployment-guide?tabs=portal