Azure Virtual Machines

    Size matters...

    The process of migrating services from on-premises locations to any public cloud platform can be very daunting, the unknowns boundless and a simple thing like deciding the correct size of a Virtual Machine (VM) can drive a person to distraction. There are many considerations when deciding which VM size is best for the workload it is required to run, such as how much CPU, RAM, the disk size and speed all need to be considered. When deploying to a virtual estate on-premises this is a relatively easy task as customers have control over the infrastructure, its configuration and setup. In a public cloud environment, this is not the case as the underlying layer that hosts the platform is supported by the vendor and VM sizes are dictated by templates which are sized by the vendor, in this case Microsoft. Understanding how VM types and sizes are structured, the best use cases for each and their capabilities/limitations is crucial. This article will hopefully aid in the decision making around virtual machine sizing and give its readers a better understanding of the options on offer and which one might be the best suited to their requirements.

    Considerations when creating an Azure Virtual Machine

    The Infrastructure as a Service (IaaS) offering available in Azure gives customers the flexibility of virtualisation without having to purchase and maintain the physical hardware required to support the deployment. However, there still remains the requirement for the customer to maintain the VM by performing tasks, such as configuration, patching, monitoring and installation of the software. There are several ways in which Azure VMs can be used, here are some examples:

    • Dev/Test – Azure VMs offer a quick and easy way to create a computer with specific configurations required to code and test an application. Customers can leverage the power and functionality of DevTest Labs to give developers access to VMs without the need for administration staff to create them. Using Role Based Access Controls (RBAC), DevTest Labs allows for the creation of templates and policies that can be used to grant developers the permissions they require to build environments but maintain control over access rights and most important of all cost.
    • Cloud Apps – Because demand for access to applications and services can fluctuate, it might make economic sense to run it on a VM in Azure. Customers can pay for extra VMs when they need them and shut them down when they don’t, thus saving money. Those that experience spikes in resource utilisation, for example retailers, can take advantage of the scalability of public cloud. During busy periods such as Christmas time, demand on retailers’ websites could be double that of a normal day. In an on-premises environment it may prove difficult to respond to that demand without an investment in hardware to support it. With Azure public cloud, retailers can utilise the scalability to respond to that demand by up-scaling the platform when required. Once the demand has subsided the platform can be scaled back to its normal operating level, which in turn lowers the cost of the resource being consumed. This means that the retailer has been able to meet its customer requests, by scaling up, but then scaling down to keep costs as lower as possible.
    • Hybrid data centre – Virtual machines in an Azure virtual network can easily be connected to your organisations on-premises network. This can be easily accomplished with a site-to-site Virtual Private Network (VPN). Those customers with a Multiprotocol Label Switching (MPLS) Wide Area Network (WAN) can take advantage of Azure ExpressRoute. The main difference between an ExpressRoute circuit and a traditional VPN is that ExpressRoute delivers consistency, low latency, which can be very important when hosting solutions in Azure and extending the data centre into the cloud. But is does come at a price for both Azure consumption and from the circuit vendor to deliver the connection.

    As with any infrastructure design there are a huge amount of considerations that need to be thought about and decided upon before deployment of the solution. When it comes to Azure VMs here are a few of those considerations to take into account prior to deployment:

    • Naming conventions - The naming of VMs and services, such as Resource Groups, VNets etc.
    • Network design - Network access, VPN, ExpressRoute or public Internet
    • Security – How systems are secure and who has access to what
    • Region – Which region resources are to be deployed into, try to deploy services as close to end users as possible
    • Scale – The maximum number of VMs that can be created, current limit is 50
    • Operating systems – Which operating system is required, Windows, Linux?
    • Additional resource – Any other resources required by VMs, Disks, NICs etc.
    • Machine size – Type and Size of VM required to host applications and workloads

    Types of Virtual Machine in Azure

    The first step when selecting the correct VM is to understand the different types that are available to use. It is also important to note that there are different types depending on whether customers need to run Windows or Linux Apps and workloads. More information about virtual machine types and sizing  for Windows can found here and for Linux can be found here. As of writing there are six different types of Azure VM, each designed to run different workloads. The following sections discuss the different VM types in more depth and the workloads that are most suited to be run on each machine type. The table below shows a brief overview of the available VM types:

    Type

    Description

    General Purpose

    Balanced CPU-to-memory ratio. Ideal for testing and development, small to medium databases, and low to medium traffic web servers.

    Compute optimised

    High CPU-to-memory ratio. Good for medium traffic web servers, network appliances, batch processes, and application servers.

    Memory optimised

    High memory-to-CPU ratio. Great for relational database servers, medium to large caches, and in-memory analytics.

    Storage optimised

    High disk throughput and IO. Ideal for Big Data, SQL, and NoSQL databases.

    Graphics (GPU)

    Specialised virtual machines targeted for heavy graphic rendering and video editing, as well as model training and inferencing (ND) with deep learning. Available with single or multiple GPUs.

    High performance compute (HPC)

    The fastest and most powerful CPU virtual machines with optional high-throughput network interfaces (RDMA).

    General-Purpose

    General purpose VM sizes provide balanced CPU-to-memory ratio. The different options available in the general-purpose type are A and Av2 series, D series, Dv2 and Dv3 series and the B series, basic tier. Ideal for Test/Dev, small to medium databases, and low to medium traffic web servers. These servers are probably the most commonly used and provide great value and reliability.

    Compute optimised

    Compute optimised VM sizes have a high CPU-to-memory ratio and are good for medium traffic web servers, network appliances, batch processes, and application servers. The different series are F-series and Fsv2-series. F-series VMs are an excellent choice for workloads that demand faster CPUs but do not need as much memory or temporary storage per vCPU. Workloads such as analytics, gaming servers, web servers, and batch processing will benefit from the value of the F-series.

    Memory optimised

    There are several VMs that are focused on memory optimisation, these are D, Dv2, Ev3, G and M series. Memory optimised VM sizes offer a high memory-to-CPU ratio that are great for relational database servers, medium to large caches, and in-memory analytics.

    Storage optimised

    Storage optimised VM sizes, the LS series, offer high disk throughput and IO, and are ideal for Big Data, SQL, and NoSQL databases.

    GPU optimised

    GPU optimised VM sizes are specialised virtual machines available with single or multiple NVIDIA GPUs. The different options available are NC, NCv2, ND and NV series. These sizes are designed for compute-intensive, graphics-intensive, and visualisation workloads. This article provides information about the number and type of GPUs, vCPUs, data disks, and NICs as well as storage throughput and network bandwidth for each size in this grouping.

    High Performance Compute (HPC)

    High Performance Compute (HPC) machines are also known as compute-intensive instances. The different series available in the HPC type are HPC sizes are A8 – A11 and H series. The hardware that runs these sizes is designed and optimised for compute-intensive and network-intensive applications, including high-performance computing (HPC) cluster applications, modeling, and simulations. In addition to the substantial CPU power, the H-series offers diverse options for low latency RDMA networking using FDR InfiniBand and several memory configurations to support memory intensive computational requirements.

    Cloud Governance… who is in control?

    The types and sizes of machines mentioned above naturally have a cost associated with them. If left ungoverned with no controls placed around who has access and rights to create services within an Azure subscription then these costs can spiral out of control. Here is one example of how those costs can escalate into a very expensive bill at the end of the month.

    Those who have worked in an IT department and administered systems know, when a request is submitted for the creation of a virtual machine with 4 CPUs 64GB RAM and 1TB of SSD high IOPs storage, that is probably not actually what they require. What that person actually needs is most likely a VM with 1 x CPU, 2GB RAM and 50GB of HDD low IOPs storage, but we all push the boundaries sometime and I am sure you will agree, you can never have enough CPU or RAM! Now this is fine if its hosted on-premises in your virtual estate because it is consuming resource that has most likely been bought and paid for, but when it’s in a public cloud, this significantly changes the game and how you should play it. When customers use public cloud services, they consume resources that are billable on a per minute basis. This means that as soon as a VM has been started the cash registers start ringing and money is being spent. Users who have administrative access to an Azure subscription can build services on-demand, complete a few configuration steps and that’s it, they are up and running, consuming resources and spending money. One example of this is shown in the image of a GS5 virtual machine instance. This type of server delivers huge power and capacity, but this comes at a price, after approximately eight clicks in the Azure portal you could be well on the way to spending the best part of £6000 in your first month with just one virtual machine.

    For more information about the array of governance controls implemented within Microsoft Azure from both the customer's and Microsoft operations' perspectives, this article, Governance in Azure provides an in depth look at the options available within with Microsoft Azure platform.

    Summary

    When designing solutions to be hosted in Microsoft Azure, making the right choice of virtual machine is very important. Selecting the correct type and size means that applications will function reliably and most important of all keep costs under control. Implementing performance optimisation by right-sizing your Azure VMs has a natural by-product of cost optimisation. Businesses need to respect cloud computing from three main perspectives: technical, security and commercial. In order to maintain control and protect against technical failings, breaches of security and out of control spending, the adoption and implementation of cloud governance is paramount to any successful cloud deployment.

    Contact a specialist