Skip to main content

Azure File (Day 21 or 31)

List of all posts from this series: http://vunvulearadu.blogspot.ro/2014/11/azure-blog-post-marathon-is-ready-to.html

Short Description 
Azure File Storage is a shared storage for any kind of applications and systems. Is constructed over Azure Storage and is used to share data and files across applications components. Content from this repository can be accessed not only by applications using mounted shares but also via File Storage API.


Main Features 
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.
Simultaneously Shares
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.
Virtual Machine 
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.
PowerShell
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.
Azure Applications
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.
Share
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.
REST API
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.
Redundant
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
Pay only what you use 
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.

Limitations 

  • 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.

Code Sample 
// 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 
Pros

  • Maxim size of a file is 1TB.
  • SMB 2.1 support

Cons

  • Azure Emulator doesn’t support Azure Files in this moment.
  • No support for AD based authentication.   


Pricing 
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)

Conclusion
Azure Files can be used with success when you need to share content over multiple Virtual Machines. With support of SMB 2.1 it is a good option when you need to share a file on machines that are hosted on Azure.

Comments

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP