Microsoft Azure Infrastructure-as-a-Service offering allows organizations to essentially have a virtual infrastructure environment in the cloud.
As opposed to an on-premises environment, the Infrastructure-as-a-Service offering from Microsoft allows businesses to have access to an environment to run virtual machine without the capital expenditure required to provision and configure a virtual infrastructure on-premise.
In addition, the IaaS solution offered by Microsoft Azure allows organizations to bypass the hardware and environmental management that is required by an on-premises environment. This allows IT staff to focus in on the development and operational management of the virtual environment rather than the lower-level management that comes with maintaining the environment on-premises. Microsoft manages the underlying physical infrastructure and simply hands over the ability to create and management of the virtual machines via the Azure interface.
In this post, we will take a look at Azure IaaS Virtual Machine Infrastructure, sizing, and pricing calculator.
Microsoft Azure IaaS Server and Virtual Machine Infrastructure
Microsoft uses an interesting approach to deploying groups of Azure physical servers that back the Infrastructure-as-a-Service offerings.
Servers are deployed in groups of servers called stamps. A stamp is also referred to as a scale unit or cluster. The advantage of deploying and identifying the servers in the stamp groups is to ensure consistency across virtual machines deployed. Within a stamp, the hardware including processor type, speed, etc., is the same. This translates into the designations on the various virtual machines that are available to choose from when provisioning a new virtual machine in the Azure environment.
Microsoft optimizes various stamps of servers for various workloads and this translates into the VM types and processor configurations as detailed in the following chart found in the Sizes for Windows virtual machines in Azure post:
| Type | Sizes | Description |
|---|---|---|
| General purpose | B, Dsv3, Dv3, DSv2, Dv2, Av2 | Balanced CPU-to-memory ratio. Ideal for testing and development, small to medium databases, and low to medium traffic web servers. |
| Compute optimized | Fsv2, Fs, F | High CPU-to-memory ratio. Good for medium traffic web servers, network appliances, batch processes, and application servers. |
| Memory optimized | Esv3, Ev3, M, GS, G, DSv2, Dv2 | High memory-to-CPU ratio. Great for relational database servers, medium to large caches, and in-memory analytics. |
| Storage optimized | Ls | High disk throughput and IO. Ideal for Big Data, SQL, and NoSQL databases. |
| GPU | NV, NC, NCv2, NCv3, ND | Specialized 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 | H | Our fastest and most powerful CPU virtual machines with optional high-throughput network interfaces (RDMA). |
A general breakdown of the various common virtual machine types includes the following:
- A Series – This is the Azure virtual machines originally provisioned having a wide range of CPU and memory configurations. Storage is HDD based
- D Series – This is similar to the A series type virtual machine with the exception of storage. Storage is SSD based as opposed to HDD
- F Series – The F Series VMs have high memory sizes. The CPU cores are assigned 2 GB of memory each and it is generally configured with 16 GB of SSD-based temporary storage
- G series – These are very “wide” VMs that contain a high core and memory footprint along with large SSD storage
- N series – These VMs provide Nvidia CUDA cards that allow using Discrete Device Assignment
When using a virtual machine that has temporary storage assigned, this is temporary or like a scratch partition of sorts. The data is not persistent and does not last. The temporary storage is present on the physical machine that is hosting your VM. If your VM is migrated to a different host, the data stored in the temporary storage on the previous host is no longer available such as in the case of a host failure. Any data saved on the previous temporary drive is not migrated.
Why is temporary storage allocated to virtual machines in Azure?
It is for saving the system paging file. The side benefit is that you have a freely available “space” of sorts to stick data with the understanding that the data storage location is volatile and will not persist. If customers need a place to store data permanently so that it is persistent, data disks can be attached to the virtual machine instances.
Understanding Azure Credits
One of the most difficult things to understand about the public cloud is how you are billed. However, an easy concept to wrap your head around is the fact that Azure Credits apply across the board. This means that your credits can be used for anything from virtual machines, SQL databases, services, and any other offering found in Azure. Pricing of the various offerings is generally based on the sizing of the resources that are available with that service such as the various sizes of virtual machines.
A great resource to make use of with understanding Azure costs is the Azure Pricing Calculator found here. With the pricing calculator, you select the number of services and the type of services you need and the monthly price is displayed for you.
Below, is an example of selecting a resource and having the calculator display the estimated monthly price. Here we have a virtual machine running Windows OS only (you have the option to select SQL or BizTalk) and the instance size. You can change the quantity of the resources to be calculated as well.
You may also notice that Linux virtual machines are less in price vs Windows Server. This is due to the fact that the Windows Server license is included in the cost of the Windows virtual machine.
An important note to make concerning the billing of a virtual machine, many customers may assume if they simply power off a virtual machine, they are no longer billed for this resource. However, a virtual machine must be deallocated as opposed to stopped before billing actually stops on a virtual machine resource.
There are subtle differences in how virtual machines can be stopped in the Azure environment and they include the following:
- Shutting down the virtual machine within the guest OS – the Azure resources are still provisioned and you will be billed
- Using the Stop-AzureRmVM cmdlet with the StayProvisioned parameter will keep the Azure resources provisioned and so billing will continue. If the StayProvisioned parameter is not used, billing will be stopped also
- Virtual machines stopped in the Azure portal using the Shut Down button actually deallocates the Azure resources. Since there are no longer resources provisioned and so billing also stops
Understanding the billing behavior with the various states of Azure virtual machines is important and requires a shift in how organizations use and manage server resources. On-premises servers generally run 24 hours a day, 7 days a week, 365 days a year. So, they are continually powered on and available. In the cloud, this approach is simply not a recommended approach to efficiently utilizing resources. This is especially true given the way billing happens with Azure infrastructure resources. You only get billed for what you use.
For instance, if a web company utilizing Azure virtual machines sees high traffic during normal business hours but very little traffic in the overnight hours, it would not make sense to keep the same amount of resources provisioned overnight as are available during the day.
Utilizing public cloud infrastructure requires that organizations make use of automation and a more DevOps approach to managing systems. Microsoft Azure also includes native Start/Stop virtual machine functionality that allows controlling the start/stop state of virtual machines during off-hours. Users can define schedules and configure notifications of these types of actions.
The solution provides a decentralized low-cost automation option that allows organizations to make the most efficient use of virtual machine provisioning and billing. With the solution, organizations can:
- Schedule virtual machines to start and stop
- Schedule virtual machines to start/stop based on Azure Tags
- Schedule virtual machine stops based on low-CPU usage
To use this functionality, you need to spin up an Azure Automation account. To manage virtual machines with Azure Automation, the virtual machines need to be in the same subscription.
Concluding Thoughts
Microsoft Azure IaaS virtual machines provide a great solution for organizations to run virtual machines in the public cloud. Microsoft provides varying sizes of virtual machine infrastructure that allows businesses to choose the best fit for their production workload use case.
One of the challenges that come into play with running resources in the public cloud is understanding billing. Similar to other public cloud vendors, Microsoft Azure billing is based on usage. With this in mind, it is important to understand the relationship between stopping virtual machines and deallocating the resources and which actions equate to which state as billing is either stopped or continues accordingly. Using Azure Automation to start/stop virtual machines in off-peak hours is a great way to be fiscally efficiently when using Azure IaaS virtual machines.
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
