Understand Microsoft Azure Storage for Virtual Machines

Microsoft Azure provides a storage solution that can be used for files, backups, virtual machines and so on. In this topic I’ll talk about Blob Storage that enables to store virtual disks for Virtual Machines.

Storage account

To use the Microsoft Azure storage solution, it’s necessary to create a Storage Account. This storage account gives you a single namespace where only you (by default) can have access. Each Storage Account handles up to 20.000 IOPS, and 500TB of data. If you use this storage account for Standard Virtual Machines, you can store until 40 virtual disks (a disk from a standard virtual machine provides 500 IOPS).

To authenticate on the Microsoft Azure Storage, the Storage Account comes with two keys, called the primary key and the secondary key. Each key can be regenerated when you want. Two key are provided to ease the key regeneration process. For example, if an application uses the primary key to access to the storage, you can:

1. Regenerate the secondary key ;
2. Modify the application to use the secondary key;
3. Regenerate the primary key.

Moreover, if you want to give temporary administrator right to someone, you can give him the secondary key and regenerate it 24h after if you want.

When you create a storage account, several REST endpoints are created to manage the contents of your storage:

• Blob endpoint: https://<Storage Account Name>.blob.core.windows.net
• Queue endpoint: https://<Storage Account Name>.queue.core.windows.net
• Table endpoint: https://<Storage Account Name>.table.core.windows.net
• File endpoint (preview): https://<Storage Account Name>.file.core.windows.net

The Azure Blob (Binary Large OBject) storage enables to store files as docx, pdf, vhd and so on. There are two blob types called page blobs and block blobs. I’ll talk longer about the differences of these two kind of types after. The Queue storage is useful for messaging and communication between Cloud Services Components. The Table storage is used for NoSQL structured datasets. To finish, the File storage provides SMB 2.1 shares that can be managed from Windows Explorer for example. SMB 2.1 has been chosen for compatibility reason with Linux. This feature is still in Preview.

In the next section, I’ll talk only about blob storage because Virtual Disks are stored in the blob storageJ.

BLOB Storage

Entities and Hierarchy

First it’s important to understand the entities which play a role in blob storage:

• Storage Account: this is the root of the hierarchy,
• Container: you can compare container to a folder. You can manage access right from this entity,
• Blob: this is the binary you want to store (docx, pdf, vhd and so on),
• Metadata: you can associate your own metadata to a blob.

Block and Page blobs

Before I have told there are two kinds of blobs: the Block blob and the Page blob. So it’s time to explain that :):

• The page blob is designed for IaaS usage as Virtual Machine disks. The maximum size for a page blob is exactly 1023GB;
• The block blob is mostly used to store data as documents, photos, videos, backups and so on. The maximum size for a block blob is 200GB.

Access right management

By default, blobs in a container are not accessible anonymously. However you can change this behavior by changing the access type. There is three access types:

• Private (Off): No Anonymous Access;
• Blob: Access blobs via anonymous requests;
• Container: List and access blobs via anonymous requests.

When you want to give access to a container or a blob to someone for a specific period of time and with specific permissions you can use Shared Access Signatures.

Replication

Your data are replicated to avoid to lose them. Currently there are four replication options:

• Locally redundant storage (Standard_LRS): the data is replicated synchronously three times in a single datacenter;
• Zone redundant storage (Standard ZRS): this replication option is only available for block blobs. Three copies of data are made on multiple datacenter;
• Geographically redundant storage (Standard_GRS): the data is replicated synchronously three times in a single datacenter and three others asynchronously copy in a second datacenter;
• Read-Access geographically redundant storage (Standard_RAGRS): same things as Standard_GRS and you can have a read access to the data in the second datacenter.

Manage Blob Storage

Create a Storage Account

To create an Azure Storage Account, you can use the PowerShell cmdlet New-AzureStorageAccount:

New-AzureStorageAccount -StorageAccountName "techcoffee01" `
                        -label "techcoffee01" `
                        -description "Storage Account to store Virtual Machines" `
                        -Location "West Europe" `
                        -Type "Standard_LRS"

The StorageAccountName parameter enables you to give a name to your Storage Account. Next provides the datacenter where you want to create this storage account by using location parameter. To finish choose a replication option with Type argument. Below this is a screenshot of a successfully Azure Account Storage creation.

Next if I open the Azure Portal, I can retrieve my new Azure Storage Account information as endpoints, location or replication option.

You can also retrieve these information by using Get-AzureStorageAccount cmdlet PowerShell.

Create Azure Storage Context

Before being able to manage containers and blobs, you have to create an Azure Storage Context. First you have to get the primary or the secondary key of your Storage Account by using the command Get-AzureStorageKey.

You can see in the above screenshot the primary and the secondary key. Now we can use the cmdlet New-AzureStorageContext to create the context as below:

New-AzureStorageContext -StorageAccountName techcoffee01 `
                        -StorageAccountKey $Key.Primary

In the next part I’ll use the $ctx variable when the context is required.

Manage containers

To create a container, you can use the New-AzureStorageContainer as below:

Be careful because the container name must be a valid DNS name as MSDN says:

• Container names must start with a letter or number, and can contain only letters, numbers, and the dash (-) character.
• Every dash (-) character must be immediately preceded and followed by a letter or number; consecutive dashes are not permitted in container names.
• All letters in a container name must be lowercase.
• Container names must be from 3 through 63 characters long.

You can list the container from PowerShell by using the cmdlet Get-AzureStorageContainer:

Moreover you can manage your containers from the Azure Portal:

To finish, you can modify the permissions associated to the container by using Set-AzureStorageContainerACL. Bellow I modify the permission of the oldvhds container to blob:

To finish you can delete easily the container by using the cmdlet Remove-AzureStorageContainer:

Upload a VHD

If you want to upload a VHD to create your own image to deploy Virtual Machines, you can use the cmdlet Add-AzureVHD cmdlet:

Delete Storage Account

To delete the storage account you can use the cmdlet Remove-AzureStorageAccount as below:

The result is the same from the Azure Portal:

Conclusion

The Microsoft Azure Storage is a feature that enables you to store binaries, backups, shares and so on. To have your own storage namespace, you have to create a storage account. Each storage account  handles up to 20.000 IOPS and 500TB of data. When Virtual Machines are created in Azure, the VHD files are stored in a page blob storage. You can manage your blob storage easily by using PowerShell cmdlets. You can have the list of PowerShell cmdlet related to Azure Storage with this cmdlet: get-command *AzureStorage*.