If you are an Azure Veteran … what was the first thing you have created in Azure? If you are new to Azure, what are you looking for to create? In many cases the answer is: Virtual Machines
An even if you are one of the fancy-new-world-everything-paas-and-serverless gurus … we must be honest and say: most things in the cloud run on VMs. Even if the Virtual Machine layer is no longer visible to us, as the PaaS idea is abstracting this.
So let’s have a look into some base topics you should know about running Azure Virtual Machines … if I missed something important, feel free to add in comments.
I remember back to the early days of Azure … when there were rumors about the Hypervisor that is running Azure. Is it Hyper-V? Is it VMware? Is it a Linux distro?
In the end it is very easy: Windows Azure Hypervisor
It is a customized Windows Server operating system which is hardened, minimized to the required components and adjusted for the standardized hardware and environment of Microsoft Azure. It can be compared to the Hyper-V core from a concept perspective.
The virtualization hosts run as single hosts and are not grouped together in Clusters. On the one hand for scalability reason, on the other hand it is due to the design of Azure Hardware and Operations.
This optimized Hypervisor and other components are running the “Fabric”. On top of this we have the Azure Resource Manager as the management layer for customers to create, control and operate their workloads.
Another important topic is the placement of Virtual Machine storage. If you boot up your first Azure VM with a Windows Operating System you will recognize that there are two disks attached:
To understand this is very important. The C-drive is where your operating system is on. This disk is stored in an Azure Page BLOB Stroage account remote from the Hypervisor Host. This allows us to reboot the machine on any other host even as we have no clusters in Azure.
The D-drive is a local drive out of the Hypervisor. This is done to optimize the performance of the VM. As you can imagine a remote storage has some latency and to shift things like the Cache to this is not very useful. So the temp drive covers temporary data. Please do not store any valuable data there.
As soon as the VM gets booted on another host, the D-drive will be empty again 🙂
Many people still think, if a VM is running in Azure, Microsoft will take care of it. So I never have to care about backup, patching, security, etc.
But this is a big misconception!
As we can see in the shared responsibility model, the customer still has to take action on his VMs. The cloud provider only serves the underlying infrastructure.
So that means if you are running a VM with a public IP, without firewall, unpatched and without backup … you can do this. I would not recommend …. but nobody is blocking you.
That’s the benefit of IaaS, as you can decide how fast you want to change. In PaaS, Microsoft is taking over the VM layer … but that also means they are deciding on updates, etc.
On very common issue is the misunderstanding of VM states. This is that much important that it is (was) even a question in some Azure certifications. We know the following main states:
Additionally there are states in between like Starting, Stopping and Deallocating.
Azure VMs are brought to you in fixed sizes. To learn more about this have a look into the official documentation.
Azure Virtual Machines are charged on full minutes. So you have to pay the instance size for the time you are running your VM. Also with this, normally, you pay for the licensing cost.
What you always have to keep in mind that a VM has related resources like, Network, Storage, Backup, … all those resources incur additional cost. Especially things like network egress can make a VM much more expensive than initially expected.
To safe some money on VMs you could use Azure Reservations for the VM size and for some licenses. And you can also have a look into Hybrid Use Benefit of Microsoft.
Dieser Post ist auch verfügbar auf:
German
Leave a comment