Azure Storage Options Explained

Azure has a number of services that require data storage in one form or another, whether it be a virtual hard disk, message queues, table records. Microsoft provides Azure Storage as it’s cloud storage service. Although there are some other forms of data storage, Azure Storage is the primary service supplying scalable and redundant data storage.

Azure Storage allows the creation of Storage Accounts which provide various data services for different types of data.  A single account can have multiple containers which combined can store up to 2PB of data depending on the Azure region (some regions have a lower cap of 500TB).

Once a storage account has been created, the account has containers where the specific data is stored. Each data service is designed for a particular type of data which is stored in specialised data containers.

Data Services

These data services are Blob, Files, Queues and Table which have Containers, File Shares, Queues and Tables respectively for storing information.  

blob.png

Blob

Azure Blob storage is designed to store Blobs (or Binary Large OBjects) in containers. Blobs are unstructured data such as image, text or binary data files. This is the standard type of storage most Azure components and systems will use to store various binary objects required for your infrastructure.

A blob storage container can be optimised for Block, Page or Append blobs.

Block Blob
Block Blobs are the default blob type used for file storage, great for static content, for example, image or text files. That are not likely to be updated frequently.

Page Blob
Page Blobs are used for unmanaged VM disks. Page blobs were designed for storing disks images either as a template or active disk.

Append Blob
Optimised for logging, this type of blob storage allows for additional information to be added to the blobs when additional information is appended to the files.

files.png

Files

Azure Files storage allows you to setup SMB (Server Message Block) shares within your Azure subscription, allowing multiple VMs to access the same files. This is similar to your on-premises SMB file shares, but with the correct configuration, these files can be accessed from anywhere with working internet.

queues.png

Queues

The Azure Queue service is optimised for storing queue messages. These are small messages up to 64KB, stored in queues to be processed asynchronously. This is used more with PaaS components that need a message queue for data processing.

tables.png

Tables

Azure Table storage is for storing structured NoSQL data within the cloud. There is also a premium option for storing NoSQL data, should you need it, this is Azure’s NoSQL database CosmosDB which is used for also storing NoSQL data and offers various APIs.

Storage Account Endpoints

Each storage account that you create is given a unique namespace within Azure. This means that each storage account has a URI and distinct service endpoints that can be used to access the data within the storage account.

For example, if your general-purpose storage account is named mystorageaccount, then the default endpoints for that account are:

·        Blob storage: http://mystorageaccount.blob.core.windows.net
·        Azure Files: http://mystorageaccount.file.core.windows.net
·        Queue storage: http://mystorageaccount.queue.core.windows.net
·        Table storage: http://mystorageaccount.table.core.windows.net

Storage Account Types

Within Azure there are five different types of storage accounts, some are older options that have been replaced with more versatile options, and as of writing, one option is currently in preview.

General Purpose v2

Starting with General Purpose v2, this is the generally available default option used for any new storage accounts. There other options available but for most situations, General Purpose v2 is the account type you will want to use. It offers all data services with all options for replication and access tiers where available.

General Purpose v1

General Purpose v1 is still available for creation but now offers a subset of the options available from General Purpose v2. It provides all the data services like General Purpose v2 but does not have all the replication options or access tiers. If you don’t need these options, or you are using Classic resources created before the introduction of the Azure Resource Manager (ARM) Portal, then you can continue to use General Purpose v1 accounts. The pricing for storage and data access varies, so there may be cases where using General Purpose v1 instead of General Purpose v2 is also cost-effective.

Blob Storage (Standard)

Like General Purpose v1, Blob storage is a pre-ARM portal service; it was introduced with additional services over and above the base General Purpose v1 account. These extra features are now all available in the General Purpose v2 account which is now the default account type.

Azure Storage access tiers

Blob Storage is specialised into storing blob data but gives additional options of access tiers. Depending on the access frequency of the data you are using, there are cheaper options that have increased access times and costs. You can still use the same APIs for accessing your data at any of the tiers, the metadata of the container or blob dictates the optimisation for the allocated tier.

Hot

The Hot access tier is the default tier due to the optimisation for frequent access. Due to the optimisation, this means access costs are lower while storage costs are higher than other potential options. If the data is in use continually or accessed frequently it is the correct tier for your data.

Cool

Cool tiers are designed for data less frequently accessed, stored for the short to medium term. This could be recent backups, DR information, or files read on a reduced frequency. Due to the nature of access, this tier was designed for (when compared to the hot tier) lower storage costs, but data access costs are increased.

Archive

The archive tier is designed for the archival of individual block blobs and can be used as an ideal replacement for tape backup. The blob data is taken offline and so incurs high retrieval latency. This tier is perfect for long-term backups and archived datasets that need to be kept but do not require immediate access. To access these blobs, they need to be converted back to hot or cold storage through the rehydration process. This can take up to 15 hours.

Summary

To summarise the permutation of options available to you when creating new storage accounts are as follows

StorageTable.PNG

Matt Boyd