Hello again to all my loyal readers!

Communication Square is back again with a comprehensive understanding of Azure Virtual Machines.

I promise you all that when you leave this page today, you’ll be an Azure VM expert!

So before we start, I want to know how many of you are acquainted with the idea of Azure?

For my beginner fellows, Azure is basically a cloud computing platform using which you launch services and servers on Azure. It’s the freedom to build, manage, and deploy applications on a massive, global network using your favorite tools and frameworks.

So let's go ahead and see what are we going to learn in today’s blog.

First I will start off with;

What is a Virtual Machine?

In computing, a virtual machine is an emulation of a computer system. Virtual machines are based on computer architectures and provide the functionality of a physical computer. Their implementations may involve specialized hardware, software or both.

VM is basically a raw server that you get from your cloud provider. It's like your own personal computer, rather than purchasing it, you are renting it out on the cloud. Right? When you are renting it out on the cloud, it is the same as if you are on your own computer. It's just a fresh piece of operating system, you can install as many software as you want, you can make it be a web server, you can configure it to be anything.

If you compare it with AWS, which is also a popular cloud computing service; with AWS, this same service is called EC2, in Azure its called VM.

What is an Azure Virtual Network?

An Azure virtual network (VNet) is the representation of your own network in the cloud. It's a logical isolation of the Azure cloud dedicated to your subscription.

A virtual network is just like a representation of your network but on the cloud. For example, we launch the server on the cloud and we connect to our virtual network. When we connect to our virtual network that is on Azure, our network will include that server as if it's on our own network. Your server will be on the cloud but your company or your company’s network will feel as if the server is on your own network. And like I said it's a logical isolation of the Azure cloud dedicated to your subscription, i/e. Whatever resources you have launched on the cloud, it logically isolates it from the rest of the resources that are there on the Azure, it could be your own resources or someone’s else's resources as well. It logically isolates them and insulates it from other resources.

Virtual Cloud Network Features

1. Isolation

Each of these networks work independently
when creating a virtual network you can divide them into segments.
You can configure the virtual network to use your own DNA servers.

2. Internet Communication

By default When you are launching any instances in the VM it can access the Internet
As and when you need you can enable inbound access to specific resources.

3. Azure Resource Communication

Resources which fall under Azure virtual network can communicate with each other using private IP addresses, irrespective of the resources are from different subnets.
They provide default routing between subnets, on-premise networks so you don't have to configure and manage routes.

4. Virtual Network Connectivity

It can be connected to each other, enabling resources in any virtual network to communicate with resources in any other virtual network.

5. On - Premise Connectivity

A virtual network can be connected to an on-premises network, enabling resources to communicate with each other

6. Traffic Filtering

Network traffic can be filtered from resources in a virtual network by source IP address and port

7. Routing

Azure’s routing can be optionally overridden by default through configuration with your own routes or by propagating BGP routes through network gateway.

Azure Virtual Network: DHCP (Dynamic Host Configuration)

Azure uses Dynamic Host Configuration Protocol services to allocate Ip addresses from the ranges you assign to virtual network. Each IP address lease has an infinite duration.

Components

Subnet

Each visual network can be divided into subparts, called subnets. Subnets are further configured using Network security groups.

When you divide a virtual network into subparts, it is called an Azure subnet.

These subnets can be given unique properties.

For example, in this same virtual network (shown in the figure) you have three virtual machines; one VM is in one subnet and the other VM is in another subnet.

You can configure each of this subnet to be unique. For example, we want to create a public subnet. A public subnet is a subnet which has internet access.

We can configure the properties in a way that the VM in one particular subnet has the internet access while the VM in another subnet does not have the internet access. A subnet with no internet access is called a private subnet. But when you see it from a broader prospect, all of these subnets are on the same network. But because of the different configuration of subnets, they reflect different properties. So being on the same network, different virtual machines can have different properties using subnets.

Network Security Groups

NSGs are just like firewalls, which filter the traffic coming in and going out of your VMs. These settings can be done easily using Azure.

Say I want to connect to a web server, I need to go through an HTTP protocol. All of this is configured in a firewall, that firewall is called Network Security Groups.

Network Security Groups are just firewalls in which you put in the properties that you want the subnet to reflect. For example, I want to connect to my web server so I have to allow all HTTP traffic on that subnet and for that I'll have to attach that particular network security group to that subnet.

Let's Suppose, we have this virtual network; In the virtual network we have subnets and a subnet is attached to a NSG. This NSG is where you'll be configuring all the protocols, all the properties you want your particular machine to reflect. This firewall will be attached to the subnet, in which you'll be deploying your VM. and this subnet is actually included in your virtual network. One virtual network can have as many subnets as you want and each subnet will have different properties because of its NSG.

Why do We Need a Virtual Network?

Virtual networks act as a communication channel between resources launched in the cloud. Why virtual? Because there are no physical wires involved in connecting these resources.

If you want to launch two virtual machines and you want both of them to communicate with each other; for example, you want to deploy a web server and a database server and you want the web server to talk to the database server.. For this communication we need a channel and hence we need a network. But why virtual networks? If you guys have noticed that in cloud there are no wires there are no switches there are no routers, so your VM is connected using a logical connection. The two servers are logically isolated and that is why we call it virtual.

Difference between a Classic and Latest Virtual Machine on Azure

There are two kinds of virtual machines available; latest and classic.

The major difference between the classic VM and latest VM is in the way these VMs are deployed. Classic VMs are available only at the older version of Azure but are still supported in the latest azure portal.

When Azure started, service management API or SM API was being used, but with time Microsoft came up with a new API called Azure resource manager API or ARM. So all the latest virtual machines that you deploy, use the ARM API, whereas the classic VMs use SM API. The difference between these APIs are more about access control and permission. I’ll recommend you to create the latest version as it has more access control than the classic ones.

Azure Virtual Machine: Workloads

When your are deciding to move to Azure there are two ways in which you can carry out.

• Suitable workloads
• Unsuitable workloads

Suitable Workloads

It is nothing but which is highly available service workloads, it could be commercial online stores. It can also be for periodic workloads such as:

• Marketing campaigns which are seasonal on a website of an organization.
• Annual Sales during festive holidays.
• For unpredicted workloads like startups where they are unaware of their growth.

It can also be utilized by organization who simply want to offload their infrastructure to the cloud.

Unsuitable Workloads​​​​

If you want to move your applications to the cloud in which you are not seeing the cost difference it is not suitable
There are some regulations from the authorities or the local government who decides that you cannot move to the cloud based on their regulations.

How to Virtual Machine Configuration

There are a couple of ways to get a VM up and running on the cloud.

First we are going to look at cloud - first provisioning of VMs.

Cloud - First Provisioning of VMs

What this means is that we build and configure a machine in the cloud. It does not exist as a separate physical machine anywhere beforehand.

There are three ways to do this.

• You can build it through clicking at the Azure management portal.
• You can write a script to do it either on windows or other operating systems.
• You can write a program called an Azure REST API.

Once you have made your choice, you will need to select an image and VM size to start from.

This newly created disk will be stored in Azure storage service and your machine will boot.

Azure Virtual Machines gives you the flexibility of virtualization for a wide range of computing solutions with support for Linux, Windows Server, SQL Server, Oracle, IBM, SAP, and more.

Temp Drive

Temp-drive is a non persistent place to store data on disk and it is actually stored on the host-local disk.

Do not store any data on the temp-drive. This is a free disk. A lot of people will be tempted to put data on here but if your VM is rebooted or it’s moved to a different host, the temp drive will be gone.

It is used for:

• Guest OS swap/paging file
• SQL Server TempDB (optional configuration)

Basic A and standard A uses HDD temp drive. All other VMs uses SSD temp-drive.

VM Series

People often get lost in the Azure world while looking at the virtual machines. There are so many variations, people just get blinded with all the options. But don’t you worry. I have got it all simplified for you.

There are different VM series in Azure. Each series is based on the set of traits.

Each series is named after a letter. These letters actually mean something. Within a series there can be generations. e.g.

• D series
• D v2 series

Each series is further broken into sizes.

Azure VM Specialization

There are also some special letters that tell about a particular VM and its capabilities.

S= supports SSD/premium storage

M= higher than normal memory

R= additional RDMA NIC

If I see a VM with letter S it means that it supports SSD. Here is the cool thing, if I deploy a DS2 VM instead of a D2 VM, it's the same cost. What changes is the cost of the disk which is not included in the cost of the VM.

Similarly A2m_v2 has four times more memory than A2_v2.

H16r has an extra RDMA(remote direct memory access) NIC.

The most common Vm series are the A series, the D series and the F series.

*ACU Azure Compute Unit allows us to measure the efficacy of each VM depending on its computing power.

The A Family (100 ACU/Core)

A0-A4 (Low Memory)

Workloads

• Economical option for development workloads, test servers and other basic applications.

Standard

• Most flexible.
• Supports load balancing and auto scaling

Basic

• Entry level
• No load balancing
• No auto scaling
• $0.06 per 1000 ACU
• A5-A7(high memory)
• $1.10 per 1000 ACU

B-Series

Premium Storage:

Supported

Premium Storage Caching:

Not Supported

• The B-series burstable VMs are ideal for workloads that do not need the full performance of the CPU continuously, like web servers, small databases and development and test environments. These workloads typically have burstable performance requirements.
• The B-Series provides these customers the ability to purchase a VM size with a price conscious baseline performance that allows the VM instance to build up credits when the VM is utilizing less than its base performance.

When the VM has accumulated credit, the VM can burst above the VM’s baseline using up to 100% of the CPU when your application requires the higher CPU performance.

D Series Family: (160 ACU/Core)

• 60% faster CPU
• Upto 112 GB memory
• Local SSD storage
• D14 isolated

Dv2 Series: (210 ACU/Core)

• 35% faster CPU than D series
• Upto 140 GB memory and 20 cores
• Local SSD storage is 1TB

Dsv3-Series: (ACU: 160-190)

Premium Storage

Supported

Premium Storage Caching:

Supported

• Dsv3-series sizes are based on the 2.4 GHz Intel Xeon® E5-2673 v3 (Haswell) processor or the latest 2.3 GHz Intel XEON ® E5-2673 v4 (Broadwell) processor that can achieve 3.5GHz with Intel Turbo Boost Technology 2.0 and use premium storage.
• The Dsv3-series sizes offer a combination of vCPU, memory, and temporary storage for most production workloads.

Ev3-Series: (ACU: 160-190)

Premium Storage:

Not Supported

Premium Storage Caching:

Not Supported

• Ev3-series instances are based on the 2.3 GHz Intel XEON ® E5-2673 v4 (Broadwell) processor and can achieve 3.5GHz with Intel Turbo Boost Technology 2.0. Ev3-series instances are ideal for memory-intensive enterprise applications.
• Ev3-series VM’s feature Intel® Hyper-Threading Technology.
• Constrained core sizes available.
• Instance is isolated to hardware dedicated to a single customer.

The F Family

• F-series is based on the 2.4 GHz Intel Xeon® E5-2673 v3 (Haswell) processor, which can achieve clock speeds as high as 3.1 GHz with the Intel Turbo Boost Technology 2.0. This is the same CPU performance as the Dv2-series of VMs.
• 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.
• The Fs-series provides all the advantages of the F-series, in addition to Premium storage.

The G Family: (180 ACU/Core)

• Unparalleled computational performance
• More memory
• More local SSD storage than any other VM size in the public cloud
• Optimized for data work loads
• G5 instance is isolated to hardware dedicated to a single customer

Ls-Series: (ACU:180-240)

Premium Storage:

Supported

Premium Storage Caching:

Not Supported

• The maximum disk throughput possible with Ls-series VMs may be limited by the number, size, and striping of any attached disks.

The M Family: (ACU: 160-180)

• The highest vCPU count (up to 128 vCPUs)
• Largest memory (up to 3.8 TiB) of any VM in the cloud.
• It’s ideal for extremely large databases or other applications that benefit from high vCPU counts and large amounts of memory.

Premium Storage

Supported

Premium Storage Caching

Supported

Write Accelerator: 

Supported

• M-series VM’s feature Intel® Hyper-Threading Technology
• More than 64 vCPUs require one of these supported guest OSes: Windows Server 2016, Ubuntu 16.04 LTS, SLES 12 SP2, and Red Hat Enterprise Linux, CentOS 7.3 or Oracle Linux 7.3 with LIS 4.2.1.
• Constrained core sizes available.
• Instance is isolated to hardware dedicated to a single customer.

N Series Family

• Solves both compute and visualization scenarios.
• Supports Open CL and CUDA
• Supports Open GL and DirectX
• NC, NCv2, NCv3, and ND sizes are optimized for compute-intensive and network-intensive applications and algorithms. Some examples are CUDA- and OpenCL-based applications and simulations, AI, and Deep Learning.
• NV sizes are optimized and designed for remote visualization, streaming, gaming, encoding, and VDI scenarios using frameworks such as OpenGL and DirectX.

Things to know

• Standard A series was replaced by A_v2 which is cheaper.
• Similarly D_v2 is cheaper and faster than D series.
• Microsoft later replaced D_v2 by D_v3
• D_v3 is cheaper than D_v2.
• The D series is typically aimed at the database workloads and the database workloads are not all about GHz, they are also about the thread count. Database needs more threads to be faster not GHz.
• D_v3:
• Hosts use Intel hyperthreading
• 28% less GHz, but 28% cheaper than D_v2

But it's okay because we have more threads at a cheaper rate so it works better even if its power is 28% lower. So it is a win win!

• FS_v2 replaced the F series, which is faster and cheaper. It is available with an S variant which means you can work both with SSD or HS

Azure: VM Sizing

In Azure you select from a range of predefined configuration options that correspond to different VM sizes.

The VM size determines characteristic such as;

• The Number And Speed Of The Processors,
• Amount Of Memory,
• Maximum Number Of Network Adapters Or
• Data Disks You Can Attach To It, And
• Maximum Size Of A Temporary Disk.

General Purpose Virtual Machine Sizes

General purpose VM sizes provide balanced CPU-to-memory ratio. Ideal for testing and development, small to medium databases, and low to medium traffic web servers.

Compute Optimized Virtual Machine Sizes

Compute optimized VM sizes have a high CPU-to-memory ratio and are good for medium traffic web servers, network appliances, batch processes, and application servers.

Memory Optimized Virtual Machine Sizes 

Memory optimized 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 Optimized Virtual Machine Sizes

Storage optimized VM sizes offer high disk throughput and IO, and are ideal for Big Data, SQL, and NoSQL databases.

GPU Optimized Virtual Machine Sizes

GPU optimized VM sizes are specialized virtual machines available with single or multiple NVIDIA GPUs. These sizes are designed for compute-intensive, graphics-intensive, and visualization workloads.

High Performance Compute VM Sizes

Azure H-series virtual machines are the latest in high performance computing VMs aimed at high end computational needs, like molecular modeling, and computational fluid dynamics.

I hope you are not lost anymore in the world of Azure virtual machines.

This is all about Azure VM series for now. If you still have any queries or you want any help in deciding which VM series to select, feel free to contact us, we would be pleased to offer any help.

References:

^[1] https://intellipaat.com/tutorial/microsoft-azure-tutorial/constructing-azure-virtual-machine/

^[2]  https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes-general

^[3] https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes-memory

^[4]https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes-compute

^[5] https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes-storage

^[6] https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes-gpu

^[7] https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes-hpc