Microsoft Azure gives us to ability to deploy virtual machines of different types and specifications, depending on your services’ needs. Some of these virtual machines are configured in a way to provide scalability and performance. As Microsoft has publicly stated, Azure is based on the core of Hyper-V. That means that you can deploy virtual machines with similar configurations as on Azure. In this article, I will show you how you can emulate some of the virtual machine designs from Azure in your private or hosted Hyper-V environments.
Azure Virtual Machines
There are several different choices to make when you are deploying a virtual machine configuration in Azure. You can choose between:
- Standard and Basic: Basic virtual machines are, well, basic. I think of them as classic standalone virtual machines that won’t support features such as load balancing and scale-out. This decision point is irrelevant to the rest of this article.
- Series: This is where the fun begins. There are A-, D-, and G- series virtual machines in Azure. We’ll talk more about this in a moment.
- Specification: You can choose low spec virtual machines 1 core with 0.75 GB RAM, or you can deploy something with much more capacity.
Typically with cloud computing, we scale-out smaller workloads. This approach allows us to run smaller systems during quiet periods. It also allows us to efficiently grow capacity and costs to match demand and profits. But there are times when you need to deploy more specialized workloads that scale-up instead of, or as well as, scaling out.
At this time you can deploy A- and D- series virtual machines. In the near future you can deploy G- series virtual machines. Here’s what this means:
- A-Series A0 to A7: The A0 to A7 specifications of this series are referred to as general purpose virtual machines. This makes up the majority of deployments.
- A-Series A8 & A9: These virtual machines offer RDMA networking on Infiniband networking. This is low processor impact, low latency, 40Gbps networking, making these virtual machines ideal for high performance clusters (HPC), intense collaborative computational workloads, message handling, and other network intensive services.
- D-Series: These virtual machines are running on hosts with faster processors and SSDs for temporary data. Using high IOPS storage greatly improves the speed of temporary database files and paging files.
- G-Series: A friend of mine nicknamed this series as the Godzilla-series of virtual machines. If you need virtual machines with massive amounts of RAM, then this is where you shop. You can get up to 448 GB RAM per VM with the same style of SSD storage as included on the D-Series. This is super for OLTP and similar workloads, especially if you want to leverage the RAM caching features of databases, such as SQL Server 2014.
Remember, Azure is running Hyper-V, so this means you can deploy something similar to these types of virtual machines in your own virtualization deployments. We’ll look at how you can do this now.
Virtual Machine Storage
The storage in Azure is very affordable, especially when you look at the cost of owning, supporting, and powering the cost of SAN storage on-premises. Microsoft is doing two things that enables their costs to be lower:
- Cloud-Scale: Microsoft operates 1 million hosts in Azure. Most virtualization customers have less than 10 hosts so there’s no way you can match Microsoft’s ability to bulk purchase and get components at crazy-low prices.
- Software-Defined Computing: Azure is not using the traditional SAN of the past. Block storage is about the most expensive way to do computing. Microsoft is using JBODs (just a bunch of disks) and from this, we can assume that they are deploying Storage Spaces and Scale-Out File Servers (SOFS) with SMB 3.0 connectivity to the hosts. This is something that we can do and you can find plenty of information on these technologies here on Petri.com.
The implementations that we can deploy of these technologies are very specific file-based solutions. Azure is blob-based. This is not a significant difference for the purposes of this discussion. However, the main points are:
- SMB 3.0 offers great storage connectivity performance and easy deployment and maintenance.
- Software-defined storage is scalable, costs less, and offers the same levels of resilience that you get with a SAN.
- Virtual machine files are typically, but not always, stored on shared storage and accessed by a compute Hyper-V cluster via SMB 3.0.