Moving to the cloud should be easy, right? I mean, how hard can it be to deploy or migrate your server workloads to virtual machines running in Microsoft Azure? Well, it’s not always as simple as it seems. There are things you need to watch out for and keep in mind as you build out your cloud infrastructure using Azure virtual machines. There are things that may be counterintuitive, things you can easily get wrong if you’re not careful. In other words, there are some “gotchas” you need to know about before you get started so you can save yourself some pain down the road.
To help us understand some of the gotchas you might run into when you use Azure virtual machines, I’ve asked Sharon Bennett to share some thoughts with us on this matter. Sharon is an IT staff instructor at LinkedIn Learning where she creates instructional content focusing on Microsoft Office 365 and Microsoft Azure (you can check out her LinkedIn courses. Previously, Sharon worked with Microsoft Partners, providing technical and business development advice to help them build their cloud offerings. Sharon is a certified Microsoft Cloud Solutions Architect, a Microsoft Certified Trainer, and holds several other Microsoft certifications. Additionally, Sharon also taught Azure and other Microsoft technologies to Microsoft Partners. Sharon brings 20-plus years of technical experience and her own entrepreneurial lessons to her position. You can contact Sharon via LinkedIn or follower her on Twitter at @bennettbusiness. Let’s turn the floor over to Sharon.
What could be simpler?
Over the years, I have come across the same hiccups that new Azure administrators have when it comes to Azure virtual machines. As IT pros, we all adore Azure virtual machines! We can spin up a virtual machine in seven minutes (and just a little longer for SQL); we can delete them when we are done with them, and the licensing is included when using one of the Azure templates. What could be simpler? And maybe that is the root of the problem: It is simple. We get ourselves into trouble because we just spin the virtual machine up and start running with it, without consideration of best practices and what I like to call “gotchas.” Below are some of the most common ones I have come across.
1. Not securing Azure virtual machines
Unfortunately, I see this one much too often, especially considering that this requires so little time and energy. Just because the virtual machine is in the cloud does not mean we can forget about hardening it.
- Network Security Groups — NSGs contain lists of security rules that will allow or deny traffic to your subnet or NICs assign to the virtual machine.
- Strong usernames and passwords — We are all guilty of forgoing strong usernames and passwords, even though this is your first line of defense.
- Patching the Azure virtual machines — Microsoft will not patch your virtual machines, this is your responsibility.
2. Assuming your virtual machine will always be available.
One of the biggest advantages of virtual machines is that you do not have to worry about the underlying infrastructure, Microsoft does. But the host machines must still be maintained and outages will occur. Hard drives die, network cards fail, hypervisors need to be patched … everything that we have to deal with on-premises occurs in the Microsoft datacenter. You do not have to deal with it yourself, but while the Microsoft team does, you may experience an unplanned outage. To keep your virtual machine up and running and meet the SLA, you must have two virtual machines in an availability set. Microsoft has additional details and instructions on how to set up high availability in Azure. The exception to this rule is if you use premium storage for your virtual machine’s operating and data disks, then the 99.99 percent SLA applies.
3. Incorrectly deploying virtual machines to an availability set
As I mentioned in the previous point, Microsoft always recommends deploying Azure virtual machines in an availability set to avoid downtime, but this is only in the case of multiple virtual machines. Virtual machines owners/administrators will be notified when a scheduled outage is planned if the virtual machine is not in an availability set. If your virtual machines are in an availability set, then the outage occurs without notification. If you put your single virtual machine in an availability set you will NOT be notified of any planned outages and you will be unaware when your system is down. The general rule of thumb: Do NOT include single virtual machines in an availability set.
4. Putting data where it shouldn’t be
Due to the recent Microsoft warning, I have seen this gotcha much less, but it still happens. After creating your virtual machine, you will see a 70GB-plus D: drive. In an on-premises environment we use this space to store data, however, when doing so in Azure, your system reboots due to maintenance (see point 2) and all your data is gone. Unfortunately, this was not widely known as a problem until recently. Microsoft has since put a text file on D: drive warning that data stored on its space could result in data loss:
Your new procedure is to attach a data disk to every virtual machine for all data. This protects you if your virtual machine fails or if you need to move your virtual machine to another network. For more information, see this Azure article.
5. Lack of planning
Moving your infrastructure into Azure is a familiar task, but all too often we get ahead of ourselves and forget about the bigger picture. When implementing a solution in Azure, we have to plan the design just as we do on-premises. In some cases, we need to pay a little more attention to the planning.
- Virtual machine placement — Moving virtual machines between virtual networks is not an easy task. Take the time to plan which virtual machines will be in which virtual networks before deploying. You could use Azure Virtual Machine Backup to redeploy your Azure virtual machine if you did need to move the virtual machine.
- Adding hosts — If you do not plan for virtual machine growth, you may find that your subnets will not accommodate the increased number of hosts, and you will need to delete your subnets, modify the subnet that is not large enough, and then re-create the subsequent subnets. Refer to the Azure VNet FAQ for specific limitations.
- Virtual machines: size matters — Here is one gotcha that will come back to haunt you. Cloud is scalable, right? That’s why we put our virtual machines there; we can scale them as needed. For the most part, that’s true, unless you created your initial virtual machine in a different family. For example, a Basic_A0 machine cannot scale to a Standard_D1v2. Always ensure the virtual machine you select can be scaled to the maximum size you will need and the virtual machine is available in the desired region. Keep in mind not all virtual machines are available in all regions.
6. Setting a static IP
In the on-premises world, once a server is up and running, we assign a static IP to it. If you do this with an Azure virtual machine, you will lose connectivity to it. Assign Static IPs via the Azure Portal or PowerShell.
7. Not backing up data and virtual machines
This is another one of those items that we just assume is taken care of for us. When you create your storage account to associate with your virtual machine, you can choose local or geo-redundant storage. Local means that three copies of your data are housed in the same datacenter, and geo maintains six copies in two datacenters in a secondary region. The data is replicated and does not protect you from deleted or corrupted data. The best practice is to back up your data, just as we do on-premises. Azure Backup can back up your files and folders, Azure virtual machines, and SMB file shares. Please refer to the Azure Backup documentation for detailed instructions on how to implement the Azure Backup scenario that best meets your needs.
Watch out for the ‘gotchas’
As we continue the transition to cloud options, there will always be things to watch out for, but as cloud computing matures, watching out for these common gotchas will save you hours of time, and more importantly, frustration. As I have only mentioned a few of the more common gotchas here I would highly recommend you refer to the Azure Reference Architectures for more details as well as the specific resource documentation.
Photo credit: Pixabay
