You have the ability to (manually or programmatically) tier blobs (files) in a storage account. This post will explain how.
The Theory
There are three tiers of blob storage in Azure:
- Hot: The cheapest to access, but the most expensive to store.
- Cool: Medium price storage, but expensive to access.
- Archive: Extremely cheap per GB storage (~$2.05 per TB per month)
Archive storage is unique because it does not offer read performance – you cannot download or directly access blobs (files) from archive storage. You can only send items from hot/cool storage to archive storage, and then “rehydrate” the blobs again by restoring them to hot/cool storage – then you can download or read the blobs. Hot and cool storage have a read latency of milliseconds, but rehydrating a blob from archive storage can take up to 15 hours. 15 hours is alright because these are files that aren’t even cool any more – they’re files that you’re keeping for legal reasons. In a legal scenario, a retrieval isn’t a rush operation because you’ll have days/weeks to comply with requests/orders.
Cool and archive storage both have minimum storage durations. For example, if you place a file into cool storage, Azure expects you to keep that file there for a minimum of 30 days. If you retrieve it after 5 days, then there’s a pro-rated minimum storage charge of 25 days (30-5). Archive storage expects you to keep files in that tier for at least 180 days. If I retrieve a file after 5 days, then there is a pro-rated charge of 175 days (180-5). In other words, only put things into cool or archive storage if they are either being used infrequently (cool) or not at all (archive).
At the moment, tiering is a manual or scripted/programmed action. There is no auto-tiering of blobs but, at Build (earlier in 2017), Microsoft did say this was something they wanted to try to do after general availability (yesterday).
Storage Accounts
There are 3 kinds of storage account today. You can deploy cool and hot blob storage accounts. Creating new blob storage account that is cool sets the default storage tier to the cool, and creating a hot blob storage account sets the default tier to be hot. You can switch the tiering of individual blobs from hot-cool-archive as you wish. Blob storage accounts were a stepping stone to tiering, as you’ll see in a moment.
General Purpose storage accounts (what used to be just “storage accounts”) are now called General Purpose v1 (GPv1) storage accounts. GPv1 storage accounts support blob storage, but also page blob (un-managed disks or VHD), Azure Files (Azure File Sync and file storage for legacy apps), queues (PaaS messages), and tables (NoSQL, where performance metrics are kept). GPv1 storage accounts do not offer tiering for blobs.
Now we have General Purpose v2 storage accounts which do offer blob tiering, at the same prices as hot/cool blob storage accounts. The per GB price of blob storage is slightly less than that of GPv1, however the blob storage transaction costs are quite a bit higher than GPv1.
Note, those of you doing Azure virtual machines should now be using managed disks which are not kept in storage accounts. Your use of storage accounts should be reduced quite a bit now.
GPv2 storage accounts have higher transaction costs than GPv1 storage accounts, x125 in some cases. This could have a big bad impact on your bill. You will be better off sticking with GPv1 storage accounts with some Azure services, such as Azure Site Recovery (ASR).
The Practice
The process of creating a new storage account is changed slightly. Microsoft is recommending, and have set it to default, that we only ever create GPv2 storage accounts. You’ll note that GPv2 storage accounts are the default, and you have the option to set the default blob tier to be hot or cool. Choose hot if you’re accessing the blobs frequently, and cool if you’ll access the majority of blobs infrequently.
Existing GPv1 (not blob) storage accounts can be easily upgraded to GPv2. Open the GPv1 storage account, browse to Configuration, and hit Upgrade.
I have uploaded a blob to a container in a GPv2 storage account. As you can see below, the default tier was hot, because the blob (file) is in the hot tier.
If I click the blob, the properties of the blob appear. Note the ability to change the tier of the blob at the bottom of the blade.
I can switch the blob to cool by selecting Cool and clicking Save (at the top). Now if I refresh the view of the container, the blob is in the cool tier.
To move the blob to the archive tier, I’ll open the properties again, select the Archive tier, and click Save. I am warned that the blob will be inaccessible while it resides in the archive tier. If I want to use the blob again, I will have to rehydrate it back to the Cool or Hot tiers. I’m doing moving the blob from the cool tier on day 0 of it being in the cool tier so there will be a 30 day minimum duration charge.
Now if I hit Refresh, the tier of the blob has changed to Archive.
Note that if I open the blob properties, the option to download this archived blob is greyed out/disabled. I cannot directly access archived blobs, so to download the file, I must rehydrate the blob back to either the cool tier or the hot tier. That’s easily done by selecting a tier (hot in my example) and clicking Save. I’m doing this on day 0 on this blob’s presence in the archive tier, so there will be a 180 day minimum duration charge.
This rehydration may take up to 15 hours. A notification in the properties of the blob informs you that rehydration is taking place.
Summary
And that’s it! The process is pretty easy. I don’t envision anyone changing the tiers of lots of individual blobs up and down on a manual basis, but I can imagine software taking advantage of this tiering process and doing it on your behalf. Maybe Azure Backup or other 3rd party tiering systems (or StorSimple) might take advantage of this over time.
Was This Post Useful?
If you found this information useful, then imagine what 2 days of training might mean to you. I’m delivering a 2-day course in Amsterdam on April 19-20, teaching newbies and experienced Azure admins about Azure Infrastructure. There’ll be lots of in-depth information, covering the foundations, best practices, troubleshooting, and advanced configurations. You can learn more here.
We have tons of old vhd’s that we need to keep and I assume that archival of page blobs is still not supported ?
Page blobs no … but store them as blobs.
Is storing VHDs as block blobs a viable option if one wanted to mount them to an Azure VM in the future?
For example, I store a VHD as a block blob in Archive tier for 2 years. Then I get a request to spin up a VM from that VHD – one cannot convert a block blob to a page blob to attach to the VM, so how would you envision that request being met?
No idea. Haven’t looked into it.