Updated – 16/12/2021 – NFS v4.1 Higher performance and reserved instance pricing, please check the following section for more details.
Azure Files is a distributed cloud file system serving Server Messaging Block (SMB) and REST protocols. Azure Files helps to easily lift and shift legacy workloads to the cloud without any technology or code changes. SMB works great on both Windows and UNIX operating systems for most use cases. However, because some applications are written for POSIX-compliant file systems, many developers wanted to have the same great experience on a fully POSIX-compatible NFS file system.
This article will share with you how to get started with NFS v4.1 for Azure Files so you can extend the use of your applications written for Linux file systems.
Table of Contents
NFS is a 36-years old filesystem but still an extremely popular file system, even in this time and age of Cloud-Native-Everything. NFS is simple, reliable, and extremely useful when you need an RWX (ReadWriteExecute) filesystem for your applications.
In September 2020, Microsoft announced Azure Files support for the NFS v4.1 protocol in public preview.
In November 2021, Microsoft announced Azure Files support for the NFS v4.1 protocol in general availability (GA). NFS share can be seamlessly mounted on virtual machines, virtual machine scale sets, or containers, including container orchestration engines such as Kubernetes (K8S). NFS can also be used in PaaS services like the HPC cycle cloud.
There are a lot of advantages of using the NFS file system such as:
- Simple and scalable. You can set up a file system in a matter of a couple of minutes. You don’t have to maintain any servers or any NAS devices or take any downtime for patching and upgrading. You pay for whatever you use, you can pay for less than 100 GB and scale the share as your demands increase.
- True Native File System. It’s a true POSIX-compliant file system, which means that you will be able to migrate to the cloud without changing your application. It is NFS v4.1 which is a major revision over the previous NFS protocol versions. It has features like inbuilt locking support which is extremely desirable by a lot of applications. Additionally, hard links and symbolic links are fully supported.
- Durable and Highly Available. Azure Storage provides seamless locally redundant storage (LRS) and Zone-redundant storage (ZRS) options, which means if you choose LRS, you’re getting 3 copies of your data in the same Azure region, and if you choose ZRS, you’re replicating your data across the three zones synchronously. It is also backed by solid Azure storage SLAs.
- Secure by design. You can secure your NFS file system at various levels. For the control plane, you can provide role-based access control (RBAC) permissions, for the mounting and data plane access, you lock it down using the network security access by setting up virtual networks (VNets) either public or private endpoints, in terms of data at rest, it is automatically encrypted by either the Microsoft managed keys or customer-managed keys. For setting file and folder level permissions, you have the POSIX mode bits, and for managing root access there is an option for setting the root squash. At the time of this writing, Azure Defender for storage does NOT support NFS yet. Stay Tuned!
- Globally accessible. The NFS file system is the most widely available in the cloud. At the time of this writing, there are more than 36 regions, and Microsoft is continuously adding more regions. In terms of mounting the NFS file shares, even if you are on-premises or your VM is in another region, you can still mount the file share from cross-region or on-premises.
- Performance. NFS is built on Azure storage and backed by solid-state drive (SSD) hardware, which means that it is highly parallel due to its distributed nature and can drive a high amount of throughput and IOPS. You can easily go up to 10 GBPS, or 100,000 IOPS. And since Azure Files is optimized for random access, so you can expect to have highly performant in-place edits as well.
In this article, I will walk you through how to create and mount an NFS v4.1 file share in Azure Storage, and finally, I’ll show you how to use NFS as you would normally do with NFS on-premises today.
To follow this article, you need to have the following:
1) Azure subscription – If you don’t have an Azure subscription, you can create a free one here.
2) Azure Resource Group (RG) obviously.
3) At least one Azure virtual machine is deployed in the desired RG. Please check the following quickstart guide to create a Linux virtual machine. You can also have a Linux machine running on-premises, check the networking prerequisites point 5 below.
4) Create an Azure Storage with File Storage account kind in one of the supported regions (more on this in the next section).
- HTTPS (secure transfer) should be disabled.
5) Please note that NFS file shares can only be accessed from trusted networks. Connections to your NFS share must originate from one of the following sources:
- Create a private endpoint (recommended) or restrict access to your public endpoint with firewalls and virtual networks (more on this in the next section).
- Configure a Point-to-Site (P2S) VPN on Linux for use with Azure Files.
- Or, configure a Site-to-Site (S2S) VPN for use with Azure Files.
- Or, configure Azure Express Route.
Create a file storage account for NFS v4.1
In this section, we will create a storage account. But before doing so, make sure to check that the NFS file share is registered in your Azure subscription.
Jump to the Cloud Shell and run the following PowerShell command:
# Check NFS 4.1 file share registration Get-AzProviderFeature ` -ProviderNamespace Microsoft.Storage ` -FeatureName AllowNfsFileShares
If the NFS file share is not registered in your subscription, then you can run the following PowerShell commands to register it.
# Set the actively selected subscription, if you have not already done so. $subscriptionId = "<yourSubscriptionIDHere>" $context = Get-AzSubscription -SubscriptionId $subscriptionId Set-AzContext $context # Register the NFS 4.1 feature with Azure Files to enable the preview. Register-AzProviderFeature ` -ProviderNamespace Microsoft.Storage ` -FeatureName AllowNfsFileShares Register-AzResourceProvider -ProviderNamespace Microsoft.Storage
Once the registration state is completed which might take up to 30 minutes, you can proceed with the creation of the storage account.
Currently, NFS 4.1 shares are only supported in the following 36 Azure regions and are available as premium file shares. To deploy a premium file share with NFS 4.1 protocol support, you must first create a FileStorage storage account. A storage account is a top-level object in Azure that represents a shared pool of storage that can be used to deploy multiple Azure file shares.
- East US
- East US 2
- West US
- West Europe
- East Asia
- Southeast Asia
- Japan East
- Japan West
- North Central US
- South Central US
- Central US
- North Europe
- Brazil South
- Australia East
- Australia Southeast
- South India
- Central India
- West India
- Canada East
- Canada Central
- West US 2
- West Central US
- UK South
- UK West
- Korea Central
- Korea South
- France Central
- Australia Central
- South Africa North
- UAE North
- Switzerland North
- Germany West Central
- Norway East
- West US 3
- East US 2 EUAP
- Central US EUAP
For the remainder of this article, I’ll be using Azure PowerShell to create and manage NFS v4.1, however, you can also use the Azure Portal and Azure CLI.
To create a FileStorage storage account, open up a PowerShell prompt and execute the following commands. Remember to replace <resource-group-name> and <storage-account-name> with the appropriate values for your environment.
$resourceGroupName = "<resource-group-name>" $storageAccountName = "<storage-account-name>" $location = "northeurope" $storageAccount = New-AzStorageAccount ` -ResourceGroupName $resourceGroupName ` -Name $storageAccountName ` -SkuName Premium_LRS ` -Location $location ` -Kind FileStorage
NFS Network security options
As noted in the prerequisites section, NFS file shares can only be accessed from trusted networks.
To use the NFS protocol for an Azure file share requires network-level security configurations, you can choose one from the options below:
- Create a private endpoint for this storage account. This is the recommended approach to ensure network-level security for your NFS traffic. A private endpoint gives your storage account a private IP address from within the address space of your virtual network. Traffic to your storage account stays within peered virtual networks. This includes peered networks in other regions or on-premises networks. Please check the following article on how to set up a private endpoint.
- Securely access the public endpoint. This is a fast but less flexible way to ensure network-level security for your NFS traffic. If you already have a VNet for an Azure VM and want to access this NFS share, you can simply select that VNet for the storage account (more on this below). This will restrict access to your storage account’s public endpoint to traffic coming from clients in designated virtual networks within the same region as your storage account.
- Connect from on-premises. You may want virtual machines from outside of Azure to use the NFS protocol with this share as well. You could configure Azure Express Route, Site-to-Site (S2S) VPN, or Point-to-Site (P2S) VPN. Please note that a private endpoint is also required when connecting from on-premises, so options 1 and 3 go hand in hand.
In this example, I will use option 2 (Securely access the public endpoint) by allowing access for my existing virtual network and subnet. This is done at the storage account level under the networking section by configuring Azure Storage firewalls and virtual networks.
Open up a PowerShell prompt and execute the following commands, remember to replace <resource-group-name>, <storage-account-name>, <virtual-network-name>, <virtual-subnet-name>, and <address-prefix> with the appropriate values for your environment.
$resourceGroupName = "<resource-group-name>" $storageAccountName = "<storage-account-name>" $virtualnetwork = "<virtual-network-name>" $virtualsubnet = "<virtual-subnet-name>" $addressprefix = "<address-prefix>" # Enable service endpoint for Azure Storage on an existing virtual network and subnet Get-AzVirtualNetwork -ResourceGroupName $resourceGroupName -Name $virtualnetwork | ` Set-AzVirtualNetworkSubnetConfig -Name $virtualsubnet -AddressPrefix $addressprefix ` -ServiceEndpoint "Microsoft.Storage" | Set-AzVirtualNetwork # Add a network rule for a virtual network and subnet $subnet = Get-AzVirtualNetwork -ResourceGroupName $resourceGroupName ` -Name $virtualnetwork | Get-AzVirtualNetworkSubnetConfig -Name $virtualsubnet Add-AzStorageAccountNetworkRule -ResourceGroupName $resourceGroupName ` -Name $storageAccountName -VirtualNetworkResourceId $subnet.Id # List existing virtual network rules (Get-AzStorageAccountNetworkRuleSet -ResourceGroupName $resourceGroupName ` -AccountName $storageAccountName).VirtualNetworkRules
To use the NFS protocol for an Azure file share requires also disabling (HTTPS) the “secure transfer required” storage account configuration.
Open up a PowerShell prompt and execute the following commands, remember to replace <resource-group-name> and <storage-account-name> with the appropriate values for your environment.
$resourceGroupName = "<resource-group-name>" $storageAccountName = "<storage-account-name>" # Disable HTTPS traffic for the storage account Set-AzStorageAccount -ResourceGroupName $resourceGroupName ` -AccountName $storageAccountName -EnableHttpsTrafficOnly $false
The NFS file shares live inside the storage account, so once the storage account is created and configured properly, we will create file shares.
Create an NFS file share
In this section, we will create an NFS file share(s) which is a very simple task.
Please note that premium file shares are billed using a provisioned model. The provisioned size of the file share is specified by -QuotaGiB parameter below. For more information, please refer to the Azure Files pricing page.
Open up a PowerShell prompt and execute the following commands, remember to replace <resource-group-name>, <storage-account-name>, and <file-share-name> with the appropriate values for your environment.
$resourceGroupName = "<resource-group-name>" $storageAccountName = "<storage-account-name>" $fileShareName = "<file-share-name>" $storageaccount = Get-AzStorageAccount $storageAccountName ` -ResourceGroupName $resourceGroupName # Create NFS file share with 100GiB provisioned capacity # Minimum 100 GiB and maximum 102400 GiB # The provisioned capacity of the premium file share can be decreased only once every 24 hours New-AzRmStorageShare ` -StorageAccount $storageaccount ` -Name $fileShareName ` -EnabledProtocol NFS ` -RootSquash RootSquash ` -QuotaGiB 100
And now we have an NFS file share created.
Mount an NFS file share
In this section, we will mount the NFS file share inside a Linux machine.
Assuming you have a Linux virtual machine deployed, take now the following steps.
Open the Azure Portal and navigate to your storage account, select File shares under Data storage and then click on the newly created file share name.
The ‘connect from Linux‘ page will open as shown in the figure below where you can see the mount sample command available ready to use.
If you don’t have the NFS client installed on your machine, you can select your Linux distribution and then run the update command. In this example, I am running Ubuntu 20.04 LTS.
SSH to your Linux machine and paste the mount command. Assuming your network is set up correctly, the mount command should be completed successfully.
Let’s see the content of the file share by going into the mount point. As shown in the figure below, we have an empty file share.
NFS file share permissions
In this section, we will restrict access to a file on the NFS file share.
First, we will create a file with some content in it using the vi text editor and then read its content using the cat command.
vi mynfsfile.txt cat mynfsfile.txt
Next, we will see what’s the current UID of the user by typing: id. As shown in the figure below, the user UID on this VM is 1000.
Let’s restrict the permission to the UID 1000 (owner) on this file. I will set the permission to 700 using the chmod command.
chmod 700 mysfsfile.txt
The permission has been given 700. And I am the owner, so I can still read the file as shown in the figure below.
I will switch to another account and see the UID of this particular user by using the ‘su‘ command.
As you can see in the figure below, this user has UID 1001 different from 1000. Next, let’s see if we can read the content of the same file. Permission is denied!
Please note that the NFS file shares will follow the UNIX style permission model. If the file is owned by the root, and the permission is restricted to the root user, then you will need to use ‘sudo‘ at every command.
That’s there you have it!
Higher performance and Reserved Instance pricing
The baseline IOPS for all sizes shares have now been increased to 3,000 from the previous 400. Microsoft also increased the baseline burst IOPS to 10,000 from the previous 4,000. That is up to 7X improvement in some cases. Workloads like SAP and some container-based workloads generating smaller capacities but needing high IOPS will benefit significantly from this increase.
Also, they enhanced the premium share provisioned throughput such that 100% of the throughput can be used either towards reading or writing or a combination in any ratio. They did this by removing the ingress: egress 40:60 ratio. This change will significantly help scenarios that are either read-heavy or write-heavy. For example, the migration of data is typically write-heavy.
The IOPS and throughput improvements come at no extra cost to the customers. Both new and existing shares can leverage these benefits alike.
For further cost optimization, customers now can use RI (Reserved Instance) pricing to save up to 36% cost on their premium shares.
With NFS v4.1, you can now deploy fully POSIX compliant, distributed, file shares in production environments and leverage the elasticity, scale, and cost savings of the cloud. NFS can be used for a wide variety of use cases like an SAP application layer, enterprise messaging, user home directories, backups, database replication, AI and machine learning user directories, DevOps pipelines, and many more industry-specific workloads.
With all these additional announcements, premium shares have expanded to run a much wider range of workloads more economically from the OS of one’s choice!
In this article, I showed you how to create an NFS v4.1 file share in Azure Storage, and how simple it’s to mount the file share, and finally, I showed you how to use NFS and assign permissions as you would normally do today. As described in this article, we have a fully POSIX-compliant file system in a matter of a few minutes.
Are you planning to use NFS v4.1 for your workloads? let me know in the comment section below.
Until NFS v4.1 becomes generally available on Microsoft Azure, stay tuned!
Do you want to learn more about Azure Storage including Azure Blobs and Azure File Shares? Make sure to check my recently published online course here: Azure Storage Essential Training.
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.