Storage
Microsoft Azure Storage Types Explained
Microsoft Azure Cloud offers several types of scalable and with high-availability storage. And in many cases, it is not that easy to determine the best solution for your or your client’s company requirements since there are two types of storage accounts, five types of storage, four levels of redundancy, and three tiers for storing your data in Microsoft Azure.
In this article, we outline all Microsoft Azure storage types and use-cases, and also give examples.
Before You Start
To start working with Microsoft Azure Storage, you need to:
- Define the need in the storage
- Get an account in Azure
- Choose your storage account type
- Choose your storage type, depending on the storage account type
- Choose your redundancy level, depending on the storage type
Microsoft Azure Storage Types
One of the most important steps in choosing Microsoft Azure storage type is defining what you want to store, how and which options and features you need to achieve that.
There are five storage types available in Microsoft Azure divided into two groups.
The first group, which includes Queue Storage, Table Storage, and Blob Storage is designed with file storage, scalability, and communication in mind and is accessible via REST API. The other, which includes File Storage and Disk Storage, is for extending the capabilities of the Microsoft Azure Virtual Machine environment and for access exclusively from VMs. (Don’t get distracted by the naming of the File Storage. It does not represent the unstructured storage for files.)
Let’s take a closer look at all five storage types.
Blob Storage
Blob is a file
It all has begun with Blob Storage in Microsoft Azure. BLOB is an acronym and means Binary Large OBject. Or, in plain English, the unstructured files, such as images, video, music files, backup files, etc.
There are three different ways to store Blobs in Microsoft Azure:
Block Blob
Good for file storage, capable of 4.77 TB per file
When you store a file as a block blob, it arrives to the storage in small parts (or, you guessed it, blocks), and only after you complete the upload - the file/blob is merged in one piece. With this architecture, the file cannot be modified without a complete reload. This is the easiest and the cheapest way to store files in Azure.
You can access the files, but you cannot modify them inside the repository without completely rewriting the files. Previously, the size of a single blob (one file) could not exceed 200GB. If in the year 2007, 200 GB per file was acceptable, nowadays it is a way too small of a limitation. Thus, Microsoft has upgraded the technology and now the limit is 4.77 TB per blob.
Append Blobs
Good for storing logs or meta-data, can be updated constantly
As we’ve already stated, you cannot modify a Block Blob without re-uploading it. However, there are times when you need to perform many input/output operations, like in the databases. Append Blobs were created for this very purpose - they are structured in such a way that the user can upload parts of the files from the end.
Page Blobs
Designed for storing disks
Page Blobs are the basis for the Microsoft Azure virtual machine environment. They have been specifically designed with disk limitations in mind - each Page Blob should be multiple of 512 bytes. The architecture of Page Blobs allows data to be written to each part of a blob.
The purpose of Page Blobs is simple - when a VM or your on-prem machine is operating with local storage (HDD or SSD with your disk partitions inside) - it operates various parts of the device - without a linear structure.
In fact, if you are running any sort of disk on a VM in Microsoft Azure - it uses Page Blobs. However, that is not the end with the blobs. They also have the so-called access tiers.
Blobs Access Tiers
Besides three Blob types, there are also Blob access tiers in Microsoft Azure. You may have already heard about hot, cool, and cold storage tiers:
- The hot tier is for the frequently needed data. It’s expensive to store but cheap to access.
- The cool tier is for the less frequently needed data. It’s less expensive to store files than in hot tier, but more expensive to access,
- The cold tier is for your archives. It’s dirt cheap to store files there but highly expensive to access files.
Microsoft has all three access tiers for the Blob Storage named respectively - Hot Tier, Cool Tier and Archive for the cold tier.
For details on the different storage tiers and when to use them, see our guide:
Further reading Azure Blob Storage Tiers Explained
Remember that you cannot change the access tier for Page Blobs. The access tier applies only to Append Blobs and Block Blobs. This limitation is related to the purpose and architecture of these storage types. You can change the access tiers for files, but not for disks.
Table Storage
Cheaper, more scalable storage for your structured data and big data analysis
In Table storage you can store, what a surprise, tables. But not all tables. Microsoft Azure Table Storage was designed to store structured NoSQL data. The storage is hugely scalable and, at the same time, cheap to store data. However, it becomes more expensive if you access files frequently.
This storage is useful if you find Microsoft Azure SQL too expensive and can go without SQL structure and architecture.
Queue Storage
When your services need to communicate with each other
Queue Storage is designed to connect the components of your application. It allows you to build flexible applications with independent components that rely on asynchronous message queuing.
Let’s say you have an on-premises application interacting with a server somewhere in the cloud. Sometimes the server is down, which means that you can no longer send messages to it. If you try, that would normally result in an error. Here are some other issues concerning asynchronous communication that you have to deal with in such case:
- The necessity to have both the receiver and the sender available simultaneously. Needless to say, if one of them goes down, the communication terminates.
- Mandatory implementation of try/retry logic to provide for a possible outage.
- Lack of proper scalability.
However, all of that can be avoided simply by using a mediator that will collect the messages while one of the communication partners is down. With Azure Queues, you have a third player that connects the two components and acts as both a buffer and a mediator.
Azure Queue storage is essentially a service for storing large numbers of messages that can be accessed from anywhere via authenticated HTTP or HTTPS requests. A single queue sizes up to 64 kb.
Azure supports two types of queue mechanisms:
- Storage queues. Being part of the Azure storage infrastructure, they feature a simple REST-based GET/PUT/PEEK interface with reliable and persistent messaging within and between services.
- Service Bus queues are part of a broader Azure messaging infrastructure that supports queuing as well as more advanced integration patterns.
Azure Queue storage is unquestionably a service for advanced users that requires certain know-how. We, therefore, suggest you to read Microsoft documentation to get a clearer picture of how it works in real life.
Disk Storage
Microsoft Azure Disk Storage is based on Page Blobs. It is a service that allows you to create disks for your virtual machines. A disk created in Disk Storage can be accessed from only one virtual machine. In other words - it is your local drive. Yes, it’s that simple.
Here you can have two options for the speed of your disks:
- HDDs that are cheap but slow and called standard storage.
- SSDs that are fast but expensive and called premium storage.
And two options for disk management:
- Unmanaged disk - you should manage the disk storage and corresponding account yourself
- Managed disk - Azure does everything for you. You need to select only the size of the disk and the desired type - standard or premium
File Storage
Microsoft Azure File storage is the second storage type that was designed to support the needs of the Azure VM environment. That storage is, in essence, a network share. You can store files there that can be accessed from different Virtual Machines. It is similar to Amazon EFS its direct competitor.
Again, quite simple. (Though the naming could be a bit clearer.)
Redundancy
Okay, now you are done with choosing the type of storage for your needs. However, in the IT world, the safety of your data is amongst the most essential and basic things. When you store data in Microsoft Azure, regardless of the type of storage, it is stored somewhere in the datacenters of Microsoft.
However, what if one day you wake up and read the news about the devastating accident that has completely destroyed the data center in question? Kind of a nightmare really.
To prevent that from happening, Microsoft has four options for data replication amongst their data-centers.
Disk Storage redundancy will be described separately, as it cannot be simply added to the following structure
Locally-Redundant Storage
3 copies of each file in one building but 3 different places
That is the most basic and the cheapest way to replicate your data. When you choose Locally-Redundant Storage (LRS), your data is copied within one data-center in 3 different nodes (basically, on different hard drives).
LRS is available for all 5 types of Microsoft Azure Storage.
Geo-Redundant Storage
3 copies in one building, 3 copies in the other
However, if a meteorite strikes the data center, it won’t matter how many different nodes your data is in, it will be still lost!
For this reason, Microsoft created a GRS - Geo-Redundancy Storage. With it, You have 6 copies of your data in 2 different regions, hundreds of miles apart.
Basically, this is LRS times 2.
Further reading Geo-Redundancy Clash: Amazon S3, Microsoft Azure Blob and Google Cloud Storage
Read-Access Geo-Redundant Storage
Read-Access Geo-Redundant storage gives you read-only access to your data at the secondary location, in addition to the dual region replication provided by GRS. The secondary endpoint is similar to the primary endpoint but adds a suffix to the account name. For example, myaccount.blob.core.windows.net turns into myaccount-secondary.blob.core.windows.net.
Zone Redundant Storage
Zone-redundant storage (ZRS) asynchronously replicates your data across data centers in one or two regions in addition to storing three replicas similarly to LRS. The data stored in ZRS is durable even if the primary data center is unavailable thus. ZRS is only available for block blobs and cannot be converted to LRS or GRS or vice versa.
Disk Storage Redundancy
Disk storage serves as storage for Azure VMs and hence requires replication to ensure data integrity. The first thing you need to do is to enable Azure VM replication in the Microsoft Azure portal.
The next step is to configure continuous replication for your VMs. Thus data written on the VM disks is continuously transferred to the cache storage account at the target location. Site Recovery processes the data and sends it to the target storage account.
After the data is processed, recovery points are generated in the target storage account every few minutes. If your main setup fails somehow, new virtual machines will be initiated in the target region and the cache storage account will ensure that your data is intact.
Microsoft Azure Storage Accounts
Now that you are aware of storage types, access tiers, and redundancy, it will be quite easy to understand how to enable all of that in your Microsoft Azure account. In Microsoft Azure, you can choose two Storage Account types. They are General-Purpose Account and Blob Storage account. You may think that the Blob Storage account works only with blobs and General-Purpose works with the rest.
And you would be completely wrong.
General-Purpose Storage Account
General-Purpose Account is designed to operate with all types of Microsoft Azure Storage, except Disk Storage. To create disks inside your Azure Storage, you should first create the Microsoft Azure Virtual Machine.
Blob Storage Account
Blob Storage account is designed to work with Block Blobs and Append Blobs. Page Blobs, however, can only be created when you are using a General-Purpose account.
Why?
One of the distinctive features of Block and Append Blobs is their ability to be in Hot, Cool, or Archive tiers as they are files. As Page Blobs were designed to be disks, they cannot be put into Cool or Archive tiers.
Microsoft Azure Storage and MSP360 Products
We in MSP360 are working to bring support for each and every cloud storage on the market, bringing you more versatile for backup and storage of your files.
Backup to Microsoft Azure Blob
When you create a backup plan in MSP360 Backup, the first thing you have to do is to indicate the cloud storage of your choice. Microsoft Azure Blob is fully supported and ready for action.
Restore from Block Blob to Azure VM
Aside from backups, MSP360 Backup enables you to restore your image-based backups to Azure VM. The data can be fetched from any cloud storage service, including Azure Block Blob.
Support for Access Tiers
MSP360 Backups also supports different Azure Block Blob storage tiers, enabling you to upload either to Azure Cool Blob Storage or Azure Archive Storage.
Microsoft Azure and Explorer PRO Capabilities
We also have MSP360 Explorer for Azure — the cloud explorer that lets you list, download, upload, and change the access tier of files in Azure. It is available free of charge for the standard version, so be sure to check it out.
Conclusion
Microsoft Azure Storage is not the easiest to understand choice on the market but is definitely one of the most flexible. In fact, it offers more options than Amazon AWS, while substantially outperforming it in the pricing department. If you’re thinking of moving your IT infrastructure to the cloud, definitely take a look at Microsoft Azure.
Simple. Reliable.
