Cloud applications and On-premises
The content from Azure File Storage can be accessed not only by virtual machines that are running on Azure, but also from On-premises system using sharing capabilities (over File Storage API).
SMB 2.1 Protocol
Azure File Storage support Service Message Protocol version 2.1 that can be used to access shared file from different networks nodes and system. This protocol was introduced with Windows 7 and Windows Server 2008 R2 and is used worldwide for file sharing.
Multiple applications can connect to (mount) the same share in the same time. We are not limited to only one applications. SMB protocol handle a part of the locking headaches that appear with simultaneously read and write access.
If you are using Azure File Storage, it is very simple to integrate this file sharing and mount it as a normal drive/directory. From the OS you will be able to access the files from it like normal files/folders. In this way you can share content to multiple virtual machines.
Because of SMB 2.1 protocol, it has full support from PowerShell. System administrators can manage and mount this storage directly from command line or PowerShell.
All application hosted on Microsoft Azure can access the file storage like using simple I/O operations. Migrating application from normal storage to Azure Files is very simple and natural, with minimal integration costs.
A Share is like a container for files and directory. As base concept is the same share concept from SMB protocol. A Storage Account can have unlimited number of shares. Usually I compare a Share with the partition concept. It is not the same thing but is very similar in the way how files and director are grouped under the same root.
All shares can be accessed not only using SMB 2.1 protocol but also via REST API. This can be used with success by on-premises system that need to access this content.
Shares for Linux
Yes, there are some versions of Linux that support Azure File Storage. For example Ubuntu allow us to mount the shares.
Queue Storage give us multiple options when we talk about redundancy. By default we have redundancy at data center level – this mean that all the time there are 3 copies of the same content (and you pay only one). On top of this there are other 3 options of redundancy that I will describe below (plus the one that we already talk about):
- LRS (Local Redundant Storage) – Content is replicate 3 times in the same data center (facility unit from region)
- GRS (Geo Redundant Storage) – Content is replicated 6 times across 2 regions (3 times in the same region and 3 times across different regions
At the end of the month you will pay only the space that you used. Because of this, clients don’t pay in advance the space that will be used or to pay for the space that is not used anymore.
- In this moment there is a capacity limit per share of 5TB (even if Azure Blobs can go to 500TB).
- Maximum size of a file is 1TB.
- Current IOPS speed limitation per share is 1K.
- Maximum data transfer bandwidth per share is 60MB.
- SMB 2.1 protocol can be used to access content only from applications a system from the same region. For external application we need to use the REST API protocol.
Applicable Use Cases
Below you can find some use cases when I would use Azure Files.
Audit and Diagnostics information
We can use Shares to write crash dump, logs and system metrics. In this way we can have a real time sharing mechanism between systems that create the audit and diagnostic content and the systems that analyze them.
Kits and Tools distribution
Azure File can be used as a place where we can share content to different machines and users. In this way we can have our tools shared cross machines without having copy/paste them or downloading them from a central repository.
Extend storage capabilities
On a normal VM or on-premises machine the storage capabilities are limited. On top of this there are times when you want to share the same content on multiple machines. For example a picture directory that you want to share with all the machines. Azure Files allow to do this, having content shared across the globe with multiple systems.
// Get a reference to storage content $ctx=New-AzureStorageContext fooAccount fooAccountKey // Create a new share $s = New-AzureStorageShare fooshare -Context $ctx // Create a directory called car New-AzureStorageDirectory -Share $s -Path car // Upload a picture with a BMW Set-AzureStorageFileContent -Share $s -Source C:\cars\bmw.jpg -Path car // List all files and directories under car folder Get-AzureStorageFile -Share $s -Path car // Download bmw.jpg picture on the local storage Get-AzureStorageFileContent -Share $s -Path car/bmw.jpg -Destination C:\myCar // Remove bmw.jpg pictures from our share Remove-AzureStorageFile -Share $s -Path car/bmw.jpg
Pros and Cons
- Maxim size of a file is 1TB.
- SMB 2.1 support
- Azure Emulator doesn’t support Azure Files in this moment.
- No support for AD based authentication.
When you start to calculate the cost of Azure Blob Storage you should take into account the following things:
- Capacity (size)
- Number of Transactions
- Outbound traffic
- Traffic between facilities (data centers)