Back in 2017, I wrote an article discussing how you can host an SMB file share in Azure. Here’s the problem statement from that article:
In an ideal world, all our cloud applications would be designed from the ground up to work with the cloud, they would be designed to work with cloud principals, make use of PaaS services and provide high availability. Unfortunately, this is often not the case. We are regularly tasked with moving existing on-premises applications into the cloud as a “lift and shift” type operation until they can be redesigned to be cloud-native. In these sort of applications, it is not uncommon for there to be a need for a shared file store.
At the time I wrote that article, several options could be used to create a File Share in Azure, such as Azure Files, Storage Spaces Direct, Storage Replica, and so on. These solutions all allowed you to present an SMB share, but each one had fairly significant downsides.
The solutions presented in the 2017 article are all still valid, but there have also been some significant new advances in this area over the last year or so. I thought it was time we took another look at this topic and see if there are any better ways to present SMB shares in Azure.
The solutions mentioned in the previous article include:
- Azure Files
- Single File Server
- Storage Spaces Direct
- Storage Replica
- Third-Party Solutions
These solutions are all still valid; if they work for you, then these are perfectly acceptable ways to deliver an SMB share, just be aware of the downsides mentioned.
Azure Shared Disks (Preview)
One of the issues with hosting file servers in Azure that drove a lot of the previous choices was the fact that a single disk in Azure could not be shared between multiple machines. This meant that traditional failover file servers were not feasible. This is no longer the case.
Azure Shared Disks is a new feature, that is still in preview currently, that allows you to attach an Azure Managed disk to multiple Virtual Machines at the same time. This means that you can now use a Windows Server Failover Cluster to create a highly available file server, just like you would do on-premises.
This service is currently in preview, so it cannot be used for production work. There are are some significant limitations in place currently:
- Only supports premium disk
- Only supported in West Central US
- VMs must be in the same proximity placement group
- Data Disks only
- Azure Backup and Site Recovery support is not available
Most of these restrictions will go away once it is out preview. Once that is the case, this will be an excellent solution for those who want to host failover clusters in Azure.
More details can be found here - https://docs.microsoft.com/en-us/azure/virtual-machines/windows/disks-shared
Azure Files AAD/AD Support
Azure Files is one of the simplest methods to create file share in Azure, requiring no infrastructure and able to expand dynamically as required. The issue with Azure Files is that it required the use of the storage account key to access the share. The lack of ACL support meant that there was no way to grant per user permissions and no way to limit users access to the resource; it was all or nothing.
This problem is now being solved. Azure Files has introduced support for Access Control Lists (ACL’s) which means you can grant access to specific users and lock down files. The implementation of this is done in two ways.
Azure AD Domain Services
The first method for integrating Azure Files with AD is through the use of Azure AD Domain Services (AAD DS). AAD DS provides a Domain Control as a Service running in Azure and tied to your Azure Active Directory Tenant. This means that to use this solution, you need to be using Azure Active Directory and able to turn on AAD DS. AAD DS does have some fairly significant limitations, so make sure you are aware of these. For some, it may not be possible to deploy AAD DS to support this requirement.
Once you have AAD DS enabled, you can configure your Azure Files share to utilise this and then set ACL’s on files with a users Azure AD account. Users can connect to the file share from their machines using their Azure AD Accounts.
Azure AD DS authentication for Azure Files is now GA, and you can find the documentation here - https://docs.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-active-directory-domain-service-enable
The second option for Azure Files Authentication is direct with Active Directory, no requirement for AAD DS. This option is new and is currently in preview. This option does require that you use Azure AD and that you sync users who require access into your Azure AD tenant.
Once you enable AD integration for your storage account, it performs an offline domain join on behalf of your storage account to create an account in your directory. Once that is done, you can grant access to AD users as you would with an on-premises share. Users can then connect to it using their AD accounts.
As this service is in preview, there are some regions where this is not available. You can find the documentation on this here - https://docs.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-active-directory-enable
Azure NetApp Files
Azure NetApp Files (ANF) is a brand new offering that provides NetApp based file shares as a PaaS service in Azure. This is real NetApp hardware running in Azure data centres and presented as a first-class Azure Service.
ANF supports Active Directory ACL’s directly, so permissions can be granted to AD users and access restricted as required. ANF instances are joined directly to an Azure Virtual Network, and so the usual vNet functionality can be used to grant and restrict access. ANF is a PaaS service and so does not require you to manage the underlying infrastructure, patch resources etc.
ANF offers 3 tiers of storage - standard, premium and ultra. Each tier has corresponding throughput and pricing levels.
There are some downsides to ANF that you should be aware of. Firstly, it is a relatively new service, it is GA, but it does have some limitations:
- Not in all regions
- Replication to another ANF device or another region is not supported currently
- ANF does not integrate with Azure Backup; backups require taking snapshots either through the portal or the API
The other downside to ANF is that it can be quite expensive, especially if you are looking at the premium or ultra tier. There is a minimum requirement for 4TB, and then increases of 1TB, so if you only need a small amount of storage, this could be an issue.
I mentioned third party solutions in the previous article, but I wanted to bring it up again as there is another third party solution worth being aware of.
NetApp Cloud Volumes ONTAP (CVO) is NetApp’s enterprise-level solution for storage available in the Azure Marketplace. CVO does support features like replication and snap vault that are not available in ANF. CVO makes use of Azure Storage (both disk and Blob) under the hood to offer shares that can be expanded, tiered and replicated as required.
This solution does have a reasonable price tag both in terms of the NetApp licences and the underlying hardware you need to provide. CVO is an IaaS service, so you are responsible for managing the virtual machines this is built on. That said, if you need all of the features of a NetApp solution, then this can provide these, running in Azure.
Three years on it looks like we are finally getting to a place where we can provide SMB shares in Azure without a lot of the issues mentioned in the previous article. Some of these solutions are in preview so we will need to wait just a little bit longer for GA support, but we are getting there. Once all of these solutions are ready, we will have:
- The ability to run Windows Failover Clusters just like we would on-premises for a true lift and shift
- Azure Files with support for ACL’s to provide cheap, scalable file shares as a PaaS service
- NetApp Files to provide support for demanding workloads and NetApp’s feature set, at a price for those who want it