Azure Storage services - File storage
The Azure Files service enables you to set up highly available network file shares that can be accessed by using the standard Server Message Block (SMB) protocol. This means that multiple VMs can share the same files with both read and write access. The files can also be accessed using the REST interface or the storage client libraries. The Files service removes the need for you to host your own file shares in an Azure VM and go through the tricky configuration required to make it highly available.
One thing that’s really special about Azure file shares versus file shares on-premises is that you can access the file from anywhere by using a URL that points to the file (similar to the blob storage URL displayed above). To do this, you have to append a shared access signature (SAS). We’ll talk more about shared access signatures in the section on Security.
File shares can be used for many common scenarios:
Many on-premises applications use file shares; this makes it easier to migrate those applications that share data to Azure. If you mount the file share to the same drive letter that the on-premises application uses, the part of your application that accesses the file share should work without any changes.
Configuration files can be stored on a file share and accessed by multiple VMs.
Diagnostic logs, metrics, crash dumps, etc. can be saved to a file share to be processed and analyzed later.
Tools and utilities used by multiple developers in a group can be stored on a file share to ensure that everyone uses the same version and that they are available to everyone in the group.
To make the share visible to a VM, you just mount it as you would any other file share, and then you can access it through the network URL or the drive letter to which it was assigned. The network URL has the format \\[storage account name].file.core.windows.net\[share name]. After the share is mounted, you can access it using the standard file system APIs to add, change, delete, and read the directories and files.
To create or view a file share or upload or download files to it from outside Azure, you can use the Azure portal, PowerShell, the Azure Command-Line Interface (CLI), the REST APIs, one of the storage client libraries, or AzCopy, a command-line tool provided by Microsoft. (For more information on AzCopy, check out this link: http://azure.microsoft.com/documentation/articles/storage-use-azcopy/.) There are also several storage explorers you can use, as noted at the beginning of this article.
Here are some of the points about Azure Files that you need to know:
When using SMB 2.1, the share is available only to VMs within the same region as the storage account. This is because SMB 2.1 does not support encryption.
When using SMB 3.0, the share can be mounted on VMs in different regions, or even the desktop. Note that to mount an Azure file share on the desktop, port 445 (SMB) must be open, so you may need to negotiate that with your company. Many ISPs and corporate IT departments block this port. This TechNet wiki shows a list of ISPs reported by Microsoft customers as allowing or disallowing port 445 traffic: http://social.technet.microsoft.com/wiki/contents/articles/32346.azure-summary-of-isps-that-allow-disallow-access-from-port-445.aspx
If using a Linux VM, you can only mount shares available within the same region as the storage account. This is because while the Linux SMB client supports SMB 3.0, it does not currently support encryption. The Linux developers responsible for SMB functionality have agreed to implement this, but there is no known time frame.
If using a Mac, you can’t mount Azure File shares because Apple’s Mac OS doesn’t support encryption on SMB 3.0. Apple has agreed to implement this, but there is no known time frame.
You can access the data from anywhere by using the REST APIs (rather than SMB).
The storage emulator does not support Azure Files.
The file shares can be up to 5 TB.
Throughput is up to 60 MB/s per share.
The size limit of the files placed on the share is 1 TB.
There are up to 1,000 IOPS (of size 8 KB) per share.
Active Directory–based authentication and access control lists (ACLs) are not currently supported, but it is expected that they will be supported at some time in the future. For now, the Azure Storage account credentials are used to provide authentication for access to the file share. This means anybody with the share mounted will have full read/write access to the share.
For files that are accessed repeatedly, you can maximize performance by splitting a set of files among multiple shares.
Source of Information : Microsoft Azure Essentials Fundamentals of Azure Second Edition