In our previous series, we started to lay the groundwork for building a virtual network in the cloud. Azure storage is the final topic to understand before we can build a VM.
This blog entry is the fifth in a series regarding virtual machines within Microsoft’s Azure Infrastructure-as-a-Service (IaaS) platform. After our coverage of the Laying the Groundwork for Azure Infrastructure, this post focuses on the required storage.
The last item that is absolutely required for a virtual machine is storage. While you do not have to create the storage before building the virtual machine (you can do it as part of the process in the wizard), it is important to understand the many different types of storage that are available in Azure, as well as the appropriate scenarios in which to use each.
Storage Redundancy
Before we dive into the types of storage, it is important to become familiar with commonly used storage redundancy terminology. You will routinely come across terms like “LRS” or “GRS” in Azure storage conversations. These have very specific and important meanings.
Locally Redundant Storage (LRS) – Any data classified as LRS is replicated locally such that there are always 3 synchronous copies within a single Azure datacenter. Those copies are resilient against any single point of failure below a total datacenter failure. So, if any single switch, server, disk or even an entire rack fails, your data will still be protected.
Zone Redundant Storage (ZRS) – If you remember back to when I wrote about Azure Datacenters and regions, you may recall that any specific region is made up of multiple physical datacenters. These datacenters are classified as “zones”. So, ZRS means that the data is synchronously copied 3 times, but across multiple datacenters within a region. This gives you increased availability as you are protected against the failure of an entire datacenter.
Geo-redundant Storage (GRS) – GRS take storage that is locally redundant and then asynchronously copies that data from the region that you specify to its regional pair for a total of 6 total copies of your data.
Geo-zone-redundant Storage (GZRS) – You probably thing that GZRS combines ZRS and GRS, and you would be mostly correct, however there is one important thing to specify. The data in the second region is contained in a single datacenter. So, the result is that you have 6 total copies of your data – one in each of 3 zones in one region, replicated asynchronously to a single datacenter in the paired region, where it is synchronously replicated 3 times locally.
There is one additional acronym that you may see and that is RA which means “Read Access”. This is a feature that allows read-only access to storage in a scenario where the data is still active in another region. This feature can be added to either GRS or GZRS.
Blobs and tables and queues, oh my!
The first types of storage we are going to look at are the ones that you aren’t going to use, at least not for a virtual machine. Azure Blob (Binary Large Object) storage is a service for storing large amounts of unstructured data, such as text or binary data. This storage can be used to serve files to browsers or applications, to stream audio or video files, it can even be assigned to virtual machines for storage of VHD’s. However, this is not the recommended way to build VM’s. Azure Table Storage stores non-relational structured data (NoSQL data) providing a key/attribute store with a schema-less design. Finally, Azure Queue Storage is for message storage. Not email type of messages, but application or task messaging akin to a service bus. Again, queues and tables will not be used for anything related to virtual machines.
Azure Managed Disks
Now that we have covered the storage that you won’t use, here is the storage that you will use to create virtual machines.
Think of managed disks like physical disks that you put in server. While this is all virtualized, it is managed pretty much the same way that you would manage disks in a physical server.
Disks are available in discreet sizes anywhere from 4 GB to 32 TB and in a number of performance tiers from standard HDD’s to premium SSD’s and for specialized cases even higher. It should be obvious, but the cost of storage will depend largely on the size, speed and redundancy of the disks. For example, a 64 GB Standard HDD will cost you only $3.01 per month while a zone redundant 32 TB Premium SSD will cost $5,406.23 per month.
Some storage technologies in Azure are more expensive for another reason. Some are billed based on consumption and some are billed based on quota. Managed disks are all quota based – so whatever size disk you deploy, you will pay for that size disk. For this reason, when you are creating virtual machines, you should be very careful about what you deploy – you don’t want to be paying for large amounts of free space. You can increase the size of a disk if you need to, so try to be conservative when estimating your storage needs.
While managed disks are the preferred method for most storage on virtual machines, there are some scenarios where a more flexible and more economical approach can be found. Azure Files provides the ability to host server-less SMB file shares in the cloud. Originally this was of limited value because there was no support for NTFS permissions. However, In January of 2020, Microsoft introduced the ability to associate a storage account with Active Directory, making this possible.
There is much more to Azure Files that we will cover in a subsequent post, but for now, we can safely say that we have all of the prerequisites covered and are ready to get into creating VMs in Azure! The next post will cover building a virtual machine and all of the other factors that need to be on your radar.
To continue to the conversation with our team, please get in touch.
