Overview of the course
What is a Virtual Machine?
Creating and Connecting to Azure VMs
Scaling Azure Virtual Machines
Design and Implement VM Storage
Configure Monitoring & Alerts for Azure VMs
Azure Resource Manager Virtual Machines
Virtual Machines are a very foundational and fundamental resource in Cloud Computing. Deploying virtual machines gives you more flexibility and control over your cloud infrastructure and services, however, it also means you have more responsibility to maintain and configure these resources. This course gives you an overview of why use virtual machines as well as how to create, configure, and monitor VMs in Azure Resource Manager.
Azure Resource Manager Virtual Machines: What You'll Learn
|Lesson||What you'll learn|
|Overview||Overview of the course and the Learning Objectives|
|What is a Virtual Machine?||Understand what are Azure Virtual Machines and what workloads are ideal for VMs|
|Creating and Connecting to Azure VMs||Learn to deploy Windows and Linux VMs as well as how to connect to these VMs|
|Scaling Azure Virtual Machines||Understand VM scaling, load-balancing, and Availability Sets in Azure Resource Manager|
|Configuration Management||Understand the basic concepts of Desired State Configuration and the options available to Azure VMs|
|Design and Implement VM Storage||Gain an understanding of the underlying Storage options available to VMs as well as Encryption|
|Configure Monitoring & Alerts for Azure VMs||Learn to monitor VMs in Azure Resource Manager as well as configure alerts.|
|Summary||Course summary and conclusion|
GitHub Code Repository
Understanding Azure VM Storage capacities is very important as it makes a big difference in not only cost of storage, but also how readily available and redundant your data will be. Storage is a big topic. Azure has five types of Storage options including: Blobs, Files, Disks, Tables and Queues. This lesson is focused on Azure virtual machine storage options which are mainly Disk and File storage options. But note that within Disk options, we have options for both Managed and Unmanaged disks as well as Standard and Premium disk options. All these factors have different limitations and affect pricing.
Azure publishes documentation called “Azure subscription and service limits, quotas, and constraints.”
I cannot begin to tell you how super important this document is. And like any Azure professional, you’ll find yourself coming back to this document frequently as a reference for most all Azure service limits. At the moment, our main concern is with Storage limits. These numbers change all the time, and rather than stick a few numbers on a slide that will be outdated over time, it’s better to learn how to find these numbers at any point in time. So let’s go directly to the source and have a look.
The column on the left shows the actual Azure resource or feature, and the column on the right shows the default limit. It’s important to know that many of these Default limits can easily be increased by contacting Microsoft Support to get the default limits raised. Just like in our first example, the number of storage accounts per subscription is 200. But if you see there’s a note that says this limit applies to both Standard and Premium storage accounts, but that the Azure Storage Team may approve up to 250 storage accounts after reviewing your business case. Keep in mind that all these limits are per subscription only and not say the total number across several subscriptions.
Let’s have a look at a few more limits. Each storage account can have up to 500 TB. The max size of a fileshare is 5 TB. The max size of a file in a fileshare is 1 TB. We have a maximum of 1000 Input/Output operations 8KB in size per file share. And finally we have the maximum Gbps of ingress (or data requests) and egress (or data responses) per storage account based on the underlying Storage Replication option.
<insert slide on storage replication options>
This is a nice segway to talk about different Storage Replication options. When creating a storage account you have different options available based on how much replication you’d like and of course how much you’re willing to pay. Let’s do a quick rundown of the terms. LRS, or Locally redundant storage means that your storage account is replicated within the same Azure Datacenter. ZRS, or Zone-redundant storage replicates asynchronously across datacenters within one or two close regions. GRS, or Geo-redundant storage replicates your data across regions that are very far away and has keeps additional replicas of the data. Finally RA-GRS, or Read-access geo-redundant is just like Geo-redundant storage but also adds an extra level of high-availability by giving you read-only access directly from the replicas in the secondary region. It’s important to note that Premium storage supports only Locally redundant storage (LRS) at the moment. Standard storage supports all these options.
This is a table that summarizes the different storage replication options. In the previous lesson on Scaling Azure Virtual Machines we talked about Fault domains and Update domains. When Storage is replicated it’s by default replicated across 3 Fault and Update domains. So if a rack of servers goes down or server nodes get upgraded your data would still be available and accessible without any data loss. This is baseline across all storage options in Azure which is how Microsoft guarantees 99.9% SLA availability.
In the table you can see that LRS storage is replicated 3 times, but within the same datacenter, and there is no secondary location of replication. Also, LRS storage can be upgraded to GRS or RA-GRS storage for Standard Storage only. LRS is a common storage option because it’s the entry-level cheapest option which provides the highest maximum bandwidth of other storage replication options. But just remember, that if a natural disaster, for example, were to take down the whole datacenter then you’d be in trouble if you’re worried about that sorta thing.
ZRS storage also replicates three copies of the data, however it does replicate asynchronously across datacenters that are relatively close within the same region or two regions. Just know that in a failover scenario the replica storage account may not be available until some time after Azure fails over to the secondary. You cannot convert a ZRS storage account to LRS or GRS nor vice-versa.
Geo-redundant storage replicates 6 times, three times in a primary region followed by three additional times in a secondary region. This secondary region differs from ZRS in that the secondary region is determined based on the primary region. If the primary is East US, the secondary region would be West US, Germany Central pairs with Germany Northeast, UK West pairs with UK South, etc. These distances are far enough apart to avoid major disasters. However like ZRS you may not access data from the secondary region until Azure performs a failover from the primary region.
In the final column we have Read-access geo-redundant storage. This option replicates exactly the same as Geo-redundant storage with one advantage, you have read-only access to your secondary region replicas at all times. This option is purely used for high-availability purposes but may be exactly what your business needs in a disaster-recovery scenario.
About the Author
Chris has over 15 years of experience working with top IT Enterprise businesses. Having worked at Google helping to launch Gmail, YouTube, Maps and more and most recently at Microsoft working directly with Microsoft Azure for both Commercial and Public Sectors, Chris brings a wealth of knowledge and experience to the team in architecting complex solutions and advanced troubleshooting techniques. He holds several Microsoft Certifications including Azure Certifications.
In his spare time, Chris enjoys movies, gaming, outdoor activities, and Brazilian Jiu-Jitsu.