5 Things You Didn’t Know About Azure VMs

By | 2015-05-05T15:35:34+00:00 May 5th, 2015|Application Lifecycle Management (ALM)|0 Comments


You’re likely already familiar with Azure’s Infrastructure-as-a-Service. As one of the key offerings, you can spin up Windows and Linux virtual machines in Azure in minutes. There are over a hundred pre-built templates ranging from Windows Server running SQL Server, to Linux running MySQL, as well as a host of other flavors.   Check out the Azure marketplace to get a feel for what’s available.

Of course, if you’ve spent any time in Azure you are likely well acquainted with the various VM templates that are available. But even if you are familiar with the various configuration options and marketplace offerings, there are likely details you may not be aware of. Let’s take a look at 5 things you didn’t know about Azure VMs.

1) VMs running Windows Domain Controllers require special attention.

Creating a VM in Azure – easy. Building a DC in Azure – also easy. But there are a few idiosyncrasies around cloud-based DC VMs you should be aware of. First of all, Azure VMs remain available even when there are system issues. Azure will move VMs in order to self heal, but that can cause issues with domain controllers. OS disks use caching while data disks do not. When a system disk hosts the AD DS database, logs, and SYSVOL and does not cleanly shut down, you could lose data. If it’s on a data disk, the data is written immediately so you won’t lose it. In other words, when configuring a DC in the cloud, you need to make sure you place the AD DS database, logs, and SYSVOL onto an Azure data disk and not on the system disk. If you don’t, you can run into problems.

You should also consider using PowerShell to assign the Windows Server DC VM with a static IP address. Check out this article for more information.

2) When there is an outage, Azure service healing will restore your VM to a running state.

Azure is constantly monitoring itself. If the node where your VM is running has issues, Azure will automatically spin down the VM and spin it up on another node. You don’t need to do a thing. Though this is a great feature for ensuring that you always have access to your VMs, you should be mindful of the impact of this ‘feature’. Just like with DCs, you should consider the impact of shutting down and spinning up a VM. For one, the IP address can be re-allocated. This may not be an issue since DNS is used for address resolution, but machines that are turned off may not be cleanly shut down, so make sure you set up your machine so that sensitive data is being written to a data disk and not a system disk.

3) You can connect an Azure Virtual Network to your on-premises network, creating a hybrid network.

If you’ve created a VM then you’ve already created a virtual network. It is possible you’ve spun up several VMs in your virtual network and have configured them to talk with each other. But did you know that you can easily set up a site-to-site VPN between Azure and your on-premises network? Just create an IP-Sec VPN between your on-premises network to the Azure Virtual Network using the wizard.

4) You can ‘easily’ setup redundancy with your VMs.

Setting up redundancy is relatively straight forward. You will need to create an availability set and multiple instances of your VM. From there you can add them to your availability set. You should also consider configuring Azure load balancing. Before setting up redundancy you should take the time to architect your requirements. For example, for a website you may want to design a multi-tiered model, with IIS running on two or more machines on one availability set, and the data tier on a separate availability set. Azure makes it pretty straightforward to create high-availability infrastructure and there is quite a bit of documentation.

To learn more, check out “manage the availability of virtual machines”.

5) For disaster recovery, you can replicate your VMs to Azure, whether it’s Hyper-V or VMWare.

It’s called Azure Site Recovery and it could save you from disaster. Whether you use on-premises Hyper-V or VMWare for your virtual machine infrastructure, you will likely need to have backups of your data. Azure Site Recovery replicates your VM environments to the cloud for backup, failover, and recovery of virtual machines! In other words, with Azure Site Recovery, if your on-premises environment goes down, you can failover to the instance in Azure.  If you are looking for a disaster recovery or fail-over option, you should take the time to investigate Azure Site Recovery.

Azure Infrastructure-as-a-Service provides more than just virtual machine infrastructure. Migration tools, disaster recovery, fail-over, hybrid connections, SLA, pre-built images, and cross-platform support are just a few of the many features. But Azure isn’t just a cornucopia of features, it’s a platform of services that can keep your organization focused on the development of your products instead of the potential resource-drain of infrastructure management.

About the Author:

Leave A Comment