Planning for Azure files

Azure files can be a great idea but can also cause a lot of problems if you implement them before you are ready. As with any project you want to make sure you do the right planning before you start doing anything. Let’s take a look at the various things we need to be aware of when we want to deploy Azure files.

There are 2 options for setting up Azure files. We must know if we want to have a direct mount file share or if we will be using a file server to cache the files stored in Azure. If you want users to access the file share directly from Azure, then you will want to use the Direct mount method. You will use a PowerShell script to mount the file share as a drive or network location. This will make it appear just like any other file share.

SMB VS NFS

There are 2 protocols that Azure files can be set up. NFS or SMB. NFS is still in preview and does not support all the features that SMB does.

Here is a breakdown of the differences between the two.

SMB shares are generally available, so we have all the features. This is the protocol I recommend using.

Our next thing to look at is what kind of storage account we want to use. Azure file shares are deployed into storage accounts. Storage accounts can be used for all kinds of storage but for our purpose we will need to decide on the type of storage account we want to use. We have general purpose version 2 or FileStorage accounts available. The general purpose V2 storage accounts can be used for other things such as containers, tables, or queues. I would not recommend mixing the storage account uses. It is a better practice to set up separate storage accounts for different things. From a performance view, the general purpose V2 storage accounts use standard HDD based hardware. If we look FileStorage accounts then we can only use the account for file shares, but we do get SSD based hardware.

Once we have decided on the storage account we will need to think about the security. We have a few different ways we can control access.

• On-premises Active Directory: Azure storage accounts can be domain joined to Active Directory, just like a Windows Server file server. Once a storage account is domain-joined, the end-user can mount a file share with the user account they signed into their PC with. AD-based authentication uses the Kerberos authentication protocol.
• Azure Active Directory Domain Services: Domain joining your storage account to Azure AD DS provides similar benefits to domain joining it to an on-premises Active Directory. This deployment option is most useful for application lift-and-shift scenarios that require AD-based permissions. Since Azure AD DS provides AD-based authentication, this option also uses the Kerberos authentication protocol.
• Azure storage account key: Azure file shares may also be mounted with an Azure storage account key. Using the storage account key to mount the Azure file share is effectively an administrator operation since the mounted file share will have full permissions to all of the files and folders on the share, even if they have ACLs. When using the storage account key to mount over SMB, the NTLMv2 authentication protocol is used.

Using Azure AD DS allows us to set permissions on the share or the folders within the share. This is the method I recommend using. It allows for more control over security. This does mean an additional cost for setting up Azure AD DS.

Once we have the storage account setup, we will want to access it to be able to migrate data and to use the file share. To make sure you can mount the file share, which will require port 445.

NOTE: Many organizations and internet service providers (ISPs) block the port that SMB uses to communicate, port 445.

You can check if your ISP is one of the ones that block access by checking TechNet.

If your ISP is blocking access, there is still a way around this. You could use a VPN to change what port you send traffic through.

Once we start putting data into our file share, we want that to be secure. We are in luck since Azure has the data encrypted at rest and in transit. By default, all Azure storage accounts have encryption in transit enabled. Azure Files will only allow the connection if it is made with SMB 3.0+ with encryption or HTTPS. If you do not have SMB 3.0 and encryption enabled, you will not be able to mount the file share. You could disable the encrypt in transit, but it is NOT recommended. All data stored in Azure Files is encrypted at rest using Azure storage service encryption (SSE). This allows for encryption to happen beneath the file system. By default, data stored in Azure Files is encrypted with Microsoft-managed keys. With Microsoft-managed keys, Microsoft holds the keys to encrypt/decrypt the data, and is responsible for rotating them on a regular basis. You could of course change this to manage your own keys, but that would beg the question of why. It is far easier to let Microsoft handle that part of things.

After we make sure we have our data encrypted the next step is to make sure we have some kind of backup or redundancy in place. On a traditional file server, this would be done with a combination of shadow copies, and backups. That is the same approach we want to look at here. Soft delete for file shares is a storage-account level setting that allows you to recover your file share when it is accidentally deleted. This is similar to shadow copies on a traditional file server. You can set how long you want the data retained. This is still in preview for file shares. I expect this to become a feature in general availability soon.

No matter where your data is stored, ALWAYS have a backup. Using Azure backup to do this seems to be the easiest. If you use Azure backup, then snapshots will be made and stored in the file share. So, if you delete the file share you will also delete your snapshots. With Azure Backup you can manage the retention of the snapshots and keep them for up to 10 years. You can also alert on the backups, and provide reporting. This is one of the key features that I often get asked about.

Backups and redundancy get confused a lot. Especially when we talk about Azure. You will want to make sure you have a backup. The backup is to allow you to restore files if someone deletes something. But what if we have a hurricane what happens to our data? What if a tornado takes out the data center? What if there is a fire in the rack and the server where my data is stored gets destroyed? This is where redundancy comes in. Redundancy protects you from hardware or environmental failures. With Azure files, it gets built-in. At the lowest level, you will still have 3 copies of your files written, and it goes up from there.

Azure Files currently supports the following data redundancy options:

• Locally redundant: Locally redundant storage, often referred to as LRS, means that every file is stored three times within an Azure storage cluster.
• Zone redundant: Zone redundant storage, (ZRS), means that every file is stored three times across three distinct Azure storage clusters. These copies are physically isolated in three distinct storage clusters in different Azure availability zones. Like with locally redundant storage, zone redundancy gives you three copies of each file.
• Geo-redundant: (GRS) stores data three times within an Azure storage cluster in the primary region. All writes are then asynchronously replicated to a Microsoft-defined secondary region. Geo-redundant storage provides 6 copies of your data spread between two Azure regions.
• Geo-zone redundant: (GZRS) is like zone redundant storage, in that a file is stored three times across three distinct storage clusters in the primary region. All writes are then asynchronously replicated to a Microsoft-defined secondary region.

We also have to take into account how often we will need to access the data, and how quickly we will need to access the data. This is where the storage tiers come in. Azure Files offers four different tiers of storage, premium, transaction optimized, hot, and cool. For setting up file shares that will be used on a regular basis we will want a Hot tier.

• Premium: Premium file shares provide consistent high performance and low latency, for IO-intensive workloads. This would normally be used for things like databases, web site hosting, and development environments.
• Transaction optimized: Transaction optimized file shares enable transaction heavy workloads that don’t need the latency offered by premium file shares.
• Hot: Hot file shares offer storage optimized for general purpose file sharing scenarios.
• Cool: Cool file shares offer cost-efficient storage optimized for online archive storage scenarios.

Drive size is always an issue when you look at file servers/ with Azure files we have a near limitless supply of storage space. We can even set quotas on the file shares. There are a few things we need to consider when we set up the file shares though.

By default, standard file shares can span only up to 5 TiB, although the share limit can be increased to 100 TiB. There are some limitations if you take a standard file share to the 100 TiB size.

• Currently, only locally redundant storage (LRS) and zone redundant storage (ZRS) accounts are supported.
• Once you enable large file shares, you cannot convert storage accounts to geo-redundant storage (GRS) or geo-zone-redundant storage (GZRS) accounts.
•  Once you enable large file shares, you can’t disable it.

Now that we have checked on a few things and come up with answers to those critical questions we can decide if Azure files is the solution we want. If it is we can proceed to setting it up and migrating our data.