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;
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.
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.
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.
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.
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.
It can be connected to each other, enabling resources in any virtual network to communicate with resources in any other virtual network.
A virtual network can be connected to an on-premises network, enabling resources to communicate with each other
Network traffic can be filtered from resources in a virtual network by source IP address and port
Azure’s routing can be optionally overridden by default through configuration with your own routes or by propagating BGP routes through network gateway.
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.
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.
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.
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.
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.
When your are deciding to move to Azure there are two ways in which you can carry out.
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:
It can also be utilized by organization who simply want to offload their infrastructure to the cloud.
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.
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.
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.
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 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:
Basic A and standard A uses HDD temp drive. All other VMs uses SSD temp-drive.
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.
Each series is further broken into sizes.
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.
How to remember it?
Very low specs
A is the starting point
D is for disk
D is for disk
Limited Azure features
Low spec machines
*ACU Azure Compute Unit allows us to measure the efficacy of each VM depending on its computing power.
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.
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!
In Azure you select from a range of predefined configuration options that correspond to different VM sizes.
The VM size determines characteristic such as;
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 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 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 VM sizes offer high disk throughput and IO, and are ideal for Big Data, SQL, and NoSQL databases.
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.
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.