Choosing Microsoft Azure Storage for IaaS

Storage is the foundation of many Microsoft Azure services; you can use it to store performance information, gather website logs, store virtual machines and much more. Storage has never been simple and that’s how an Azure novice might feel when you check out their deployment options. I will explain those options in this article so you will know what you need to price when deploying storage in Azure for infrastructure-as-a-service (IaaS).

Microsoft Azure Storage Accounts

Azure storage is actually much simpler than on-premises storage, and that simplicity is what causes a lot of the confusion for IT pros. When you deploy storage on-premises you:

1. Choose a storage system
2. Provision a LUN of a specific size with required fault tolerance
3. Create and format a volume, usually filling the LUN
4. Mount that volume, either as a mount point or as a driver letter

You’ll use that mount point or driver letter to store shared folders, place website files, or locate virtual machine files.
We worth with something called a storage account in Azure. This is a much simpler device that is stored in Azure’s cloud-scale software-defined storage. The process is:

1. Decide on a unique name, that is used to create a unique URL for the storage account
2. Create the storage account in a region of choice, with fault tolerance of choice

You then use the storage account based on the name or URL for the other Azure services that you deploy. Note that I didn’t mention drive letters or sizes. A storage account is elastic; it can grow up to 500 TB and you are billed based on your storage use (capacity and transactions).

Standard versus Premium Storage

Most of the time people will deploy standard storage. This is shared HDD based storage in the Azure fabric. Another form of shared storage is Premium Storage. This is shared SSD capacity that offers greater IOPS and throughput with lower latency, but at a higher cost. Premium Storage has a different design and deployment system that is intended for Azure virtual machines with very high performance requirements. I will focus the rest of this article on Standard Storage.

Storage Services

There are four Azure storage services; these are ways that you can use a storage account and each one has a different billing rate:

• Block Blobs: This is unstructured data that can be any type of text or binary data. Examples might be images, documents, video files, and so on. You might use this in IaaS for storing vast quantities of media files.
• Tables & Queues: Tables are a structured store based on NoSQL key-attribute data stores, designed for rapid access to huge amounts of data. Queues provide reliable messaging between different components of cloud services. It’s unlikely that you’ll use either of these in IaaS outside the context of a very specific application usage.
• Files: This service is in preview at the time of writing. You can use Azure Files as an SMB 2.1 folder that is accessed by some application component(s) to share file data. You might find yourself using Azure Files in some IaaS deployments.
• Page Blobs and Disks: This is the service that you will use to store Azure virtual machine files and disks, because it is optimized for random read and write operations.

When you create a storage account, you provide it with a unique name. This name is appended with a URL for each of the above possible services. You then use that URL to access the associate service. The below image shows the Microsoft-generated URLs for a storage account called demopetri.

Azure Storage Services and their URLs [Source: Aidan Finn]

Location & Fault Tolerance

You should always locate your Azure storage in the same region as the service(s) that you want to deploy. For example, it makes no sense to create storage in South Central US and then try to deploy virtual machines in North Europe; the latency would be too high!
Note that the desired location and fault tolerance of your Azure storage does have an effect on peak storage performance.
Azure always stores multiple a minimum of three copies of your storage account. You can choose how and where the copies are stored by selecting a redundancy option.

• Locally redundant storage (LRS): Azure will use synchronous replication to keep 3 copies of your data within a single data center. There is storage fault tolerance but there is no facility fault tolerance.
• Read access geo-redundant storage (RA-GRS): 3 copies of your storage account are replicated synchronously in the region of your choice. Another 3 copies of your storage account are asynchronously replicated to another region. Note that the second region provides read-only access to the data.
• Geo-redundant storage (GRS): This is similar to RA-GRS except the storage account is read-write in both regions.
• Zone redundant storage (ZRS): This block blobs only storage (not virtual machines) keeps three copies of the storage account, in two to three facilities; these may be in a single region or two regions.

You can convert storage accounts between different redundancy levels. However, you cannot convert to/from ZRS to any other redundancy level.

I Just Want To Store Virtual Machines!

Say you want to deploy virtual machines with data storage disks. You’re going to be using Page Blobs and Disks. You cannot use ZRS and RA-GRS makes no sense. So you’ll either use LRS (maybe providing DR by deploying duplicate VMs in another region) or use ZRS to asynchronously replicate the VM files to another region.