If you’re used to high-control virtualization environments, the fixed nature of the options for sizing virtual machines in Azure can be a bit confusing. One of the benefits of cloud environments like Azure is that it’s possible to find the right size for your loads and thereby save money. In today’s post, I’m going to show a practical example to help you better understand how to size an Azure VM.
As an example, let’s take a legacy database server with 16 cores, 64 GiB of RAM, and a need for moderate-to-high disk throughput.
Location is everything … even in Azure. Each location has different machines available and different pricing for the machines. As a result, the location you pick could limit your options. If you have a workload that is not sensitive to the location or has limited egress/ingress, you can take a moment to shop around and find the best price for your virtual machines. The pricing can be substantially different. At the time I’m writing this articleI’m looking at the prices in West US. An A2M_v2 in that region costs 34% more than one in West US 2, and getting a D12_v2 in East US 2 will save you nearly 20%!
It’s important to understand what you need from the disk. Generally speaking, you will want to always choose managed disks. There’s a few reasons for this, but one of the most important is that they have very guaranteed performance characteristics, high availability, and high durability (approaching a 0% failure rate). This really leaves us with one choice: Premium (SDD) or Standard (HDD) Managed Disks. Understanding how to select the right performance characteristics is a subject for a future article. For now, there are a few important things to know:
For most databases, you will typically want to choose a Premium disk in order to have provisioned and guaranteed performance characteristics. This limits you to only the series of VMs which have an “S” … DS, DSv2, GS, Ls, Fs, and ESv3. Let’s narrow that down a bit further.
So we’ve narrowed our search to machines that accept premium disks. What next? We need to look at each series and select the right one. There’s several things to consider. First, you may need to examine the maximum number of disks if you need storage over 4 TiB or if you need high IOPS (via RAID). Second, examine the network performance associated with the machine. Different sizes and series of machines will support varying amounts of network performance. Let’s examine each series in our list of candidates.
Series | ACU per vCPU | vCPU : Core | Purpose |
---|---|---|---|
D | 160 | 1:1 | General compute, legacy tier. Supports up to 16 cores and 112 GiB RAM. |
DSv2 | 210 to 250 | 1:1 | General compute. Ideal for most OLAP database workloads. Supports up to 20 cores and 140 Gib RAM. |
DSv3 | 160 to 190 | 2:1 | General purpose workloads. Reduced cost using hyper-threaded vCPUs instead of cores running on customized Xeon. Supports up to 64 vCPUs (32 cores with hyper-threading) and 256 GiB RAM. |
Es | 160 to 190 | 2:1 | Extended memory. Ev3 was the D11-D14 tiers. Higher available memory than the D-series, supporting up to 64 cores and 432 GiB RAM. |
GS | 180 to 240 | 1:1 | Goliath. More RAM per core and faster disk speeds than D-series. G5 is dedicated hardware, supporting 32 cores and 448 GiB RAM. |
Ls | 180 to 240 | 1:1 | Low latency storage (uses local SSD drives, which can out-perform Premium SSD storage). Supports up to 32 cores, 256 GiB RAM, and 5,630 GiB temporary drives (SSD). Max temp drive throughput is 160K IOPS/ 1.6 GBps. |
For a basic database workload, the D-series is usually a good starting point. For a long time, this has been the main workhorse for general purpose computing loads. Starting with the DSv3 series, the virtual CPU (vPU) is actually separated from the underlying physical cores. In this case, 1 vCPU in a DSv2 represents a 1/2 core (hyper-threaded) and has a correspondingly lower price point. The V3 series has the ability to incrementally increase the computing power, reaching higher performance levels than the previous V2 machines.
The Gs-series (“Goliath”) are specifically optimized for large database workloads. Consequently, they have significantly larger RAM quantities and temporary disk sizes. Strictly on ACUs, the CPU is not as powerful as the DSv2 series and the prices are significantly higher.The tradeoff is consistency in performance. Additionally, a G5 (32 cores) is dedicated and isolated to a single customer. Consequently, these are more expensive units, and they do not get a discount for Reserved Instances. If you need more RAM (or higher MBps) than the D-series, then you should also consider these machines.
The Ls-series (“low latency”) are optimized for high disk throughput and I/O for processing large amounts of data. They are ideal for large databases and Big Data solutions. This series utilizes local SSD drives for temporary storage, increasing the maximum throughput significantly compared to the normal Premium SSD solutions. It is optimized for loads requiring low-latency disk access.
Since we don’t have a need for low-latency or semi-dedicated hardware, we’ll look at the D-series.
Finally, it’s time to review the Azure Compute Unit (ACU) rating for any series we are considering. The ACU metric provides a quick way of gauging the relative performance of different virtual machine sizes without knowing the underlying hardware details. For example, a rating of 200 is twice as fast on a typical load as a rating of 100. You can see from the ACU ratings above that each vCPU of a DSv2 is around 35% faster than the original D series.at the options we selected above in a bit more detail:
The maximum ACU performance is determined by multiplying the number of cores against the ACU rating for the series. Consequently, we can easily see how a few of these systems will compare if we place these values into a chart:
Instance | vCPU | ACU | Total ACU | RAM (GiB) | Temp Storage (GiB) | Max Data Disks | Max cached and temp | Max uncached disk | |||
---|---|---|---|---|---|---|---|---|---|---|---|
IOPS | MBps | Cache | IOPS | MBps | |||||||
DS13_V2 | 8 | 210 to 250 | 1,680 to 2,000 | 56 | 112 | 32 | 32k | 256 | 288 | 25.6K | 284 |
D16S_V3 | 16 | 160 to 190 | 2,560 to 3,040 | 64 | 128 | 32 | 32K | 256 | 400 | 25.6K | 384 |
DS14_V2 | 16 | 210 to 250 | 3,360 to 4,000 | 112 | 224 | 64 | 64K | 512 | 576 | 51.2K | 768 |
DS15_V2 | 20 | 210 to 250 | 4,200 to 5,000 | 140 | 280 | 64 | 80K | 640 | 720 | 64K | 960 |
GS4 | 16 | 180 to 240 | 2,880 to 3,840 | 224 | 448 | 64 | 40K | 800 | 2112 | 32K (64×500) | 1000 |
Placed into a chart like this, it becomes easier to see our options — and how we can scale the machine up or down to get the right level of CPU utilization. Notice that although the DS16_V3 has 8 physical cores (and 16 VCPUs), it has noticeably higher ACUs than the 8-core DS13_V2. By reviewing the ACU range, we can determine a good starting point and how to scale up or down as needed.
As a starting point for our legacy database, a D16S_V3 is a good starting point with 16 VCUs and just the right amount of memory. If we need the parallel processing power of 16 physical cores, then we would need to step up to the DS14_V2.
Each VM size in Azure supports a specific amount of RAM. This means that as we choose a specific VM size, we’re also choosing the associated memory. If you’re coming from a VMWare world, this is quite a change. Since we only need 64 GiB, the D16S_V3 remains a good starting point.
To save some time, let’s use PowerShell to help us in our search. Assume we’ve picked Central US for our region. We can use a simple script to find machines that match specific sizing needs:
Login-AzureRMAccount
$region = 'CentralUS'
Get-AzureRMVMSize -Location $region `
| Where { $_.NumberOfCores -ge 16 `
-and $_.MemoryInMB -ge 65536 `
-and $_.Name -match '_[DEGFL][^_]*s' } `
| Format-Table
This will provide you a formatted table of virtual machines that meet your requirements. Notice that unfortunately you cannot query for machine sizes that support premium disks except by name. As a result, this search uses a very simple regular expression to match the naming conventions for the sizes that support premium storage.
Finding the right VM size on Azure can be challenging, but with a little bit of research it’s easy to identify the series and size that will be right for your specific load. The great thing about Azure is that if you find you’ve created a machine that is too large or too small for you needs, you can simply change the VM size. This is part of the power of elastic compute resources — they can quickly be scaled up or down to meet your needs. This makes it incredibly easy to right-size your virtual machine to match its load.
Until next time, Happy DevOp’ing!
Microsoft Azure and Amazon Web Services (AWS) are two of the most popular cloud platforms.…
Cloud management is difficult to do manually, especially if you work with multiple cloud…
Azure’s scalable infrastructure is often cited as one of the primary reasons why it's the…
https://www.youtube.com/watch?v=wDzCN0d8SeA Watch our "Unlocking the Power of AI in your Software Development Life Cycle (SDLC)"…
FinOps is a strategic approach to managing cloud costs. It combines financial management best practices…
Using Kubernetes with Azure combines the power of Kubernetes container orchestration and the cloud capabilities…