One of the recent announcements from the Azure Storage team was about a new feature called Azure Files. This basically allows you to set up an equivalent to network shares in your Azure environment, to make files available to multiple VM’s simultaneously.
Some use cases
If you have a web application that outputs data that you need to input into a different web application, you could set up a file share and give access to both applications; one could write the data, the other could read it.
If you have a set of tools that you frequently use, you might put them on a shared drive. Then you can attach the drive and use the tools from multiple VM’s. As a developer, I would put the installation packages for tools that I use every day – Beyond Compare, FileZilla, etc – and when I spin up a VM with Visual Studio in it, I could then attach the share and install the tools in my VM.
If you have a team of developers using Visual Studio in VM’s, this makes it easy for them to share tools, and to enable all of the team members to use the same version. You could even put a OneNote notebook on the share and have the developers share notes about the project in that notebook.
Wasn’t there already a way to do this?
There was a convoluted way to do this with the current IAAS offering – hosting a file share backed by an IAAS data disk, and writing code to find the IAAS File Share from the rest of the VMs in your service, trying to handle high availability, etc. With the new feature, you just set up the shared drive, then attach it in your VMs. It’s that simple.
Since the Azure Files is built on the same underlying layers as Azure Storage, it provides the same availability, durability, and scalability that Azure Storage already provides for blobs, queues, and tables. The Azure Files can be locally redundant (3 replicas of the data within a single region) or globally redundant (3 replicas of the data in the same data center, and 3 replicas in another region).
How do I access the files on the share?
Azure Files provides two interfaces: SMB 2.1 and REST. The SMB protocol allows you to access the file share from VM’s. The interface for REST provides something you don’t have in on-premise file shares – the ability to access the files in the share with REST interface. For example, you might store files on the share that are used in multiple web applications, then use the network path to the share in your web applications to access those files. Those files can then be updated externally using REST.
The SMB 2.1 protocol is natively supported by OS APIs, libraries, and tools. This includes Windows (CreateFile, ReadFile, WriteFile…), .NET (FileStream.Read, FileStream.Write, etc.), and many others. It also supports standard file system commands for moving and renaming files and directories, as well as change notifications.
There is an SMB 3.0 protocol available, and I suspect that eventually Microsoft will support it. I think they choose 2.1 to start with because it is supported by the most tools and OSes. It is definitely supported by Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. While not being completely supported on every version of Linux, it does work on some distributions, such as Ubuntu 13.10 and Ubuntu 14.04 LTS.
Note that the file and directory objects on the share are true file and directory objects. This is different from Blob storage, which has a flat structure. In Blob storage, you only have containers (the equivalent of a top-level directory). Anything that looks like it is in a folder within a container is actually part of the Blob file name, which is frequently parsed and visualized like a directory structure.
What are the specs?
These are the preview scalability targets for Azure Files:
- Up to 5TB per share
- A file can be up to 1 TB
- Up to 1000 IOPS (of size 8KB) per share
- Up to 60 MBps per share of data transfer for large IOs
Using the SMB protocol, Azure Files are only accessible to VMs in the same region as the file share. However, you can access the files from anywhere in the world using REST. (This may be because SMB 2.1 doesn’t have built-in encryption, so there’s no way to protect the files going out of the data center.)
One question I’ve seen asked a lot so far is “Can I attach the share to my desktop?” The answer is no, because the SMB protocol is not designed for the latency involved. This is going to be a huge feature request, so I’d be surprised if Microsoft didn’t come up with a solution at some point in the future.
How can I get access to this preview feature?
Go to the Azure Preview Portal and sign up for the Azure Files service using one (or more) of your existing Azure subscriptions. As subscriptions are approved, you will get an e-mail notification.
After being approved, log into your account and create a new storage account. It will not work with storage accounts created prior to signing up for the preview. When you create the new account, you will see the new endpoint displayed in the portal (http://storageaccountname.files.core.windows.net).
From there, you can create the share, put files into it, and connect to it from a VM.
Check out this blog article by the storage team for more details. It also has a link to the video from the Tech Ed session.
The new Azure Files preview is something people have been asking for for a long time. To be able to set up a file share and access it from multiple VMs simultaneously brings a lot of new possibilities to Microsoft Azure, and should help people migrating from on-premise to the cloud, as well as those running hybrid implementations. In my next post, I’ll show you how to use PowerShell to maintain a file share and upload/download files.