Manage VM sizes
There are many situations where the amount of compute processing your workload needs varies dramatically from day to day or even hour to hour. For example, in many organizations, line of business (LOB) applications are used heavily during the workweek, but on the week- ends, they see little actual usage. Other examples are workloads that require more processing time due to scheduled events such as backups or maintenance windows where having more compute time may make it faster to complete these tasks. Azure provides purpose-built virtual machine sizes. This means that each family is designed for specific purposes to make it easier for you to choose the right VM size for the right workload.
The different types are
- General Purpose This size type is most suitable for small- to medium-scale develop- ment environments. It has a balanced CPU-to-memory ratio. As the name suggests, it is recommended for general use.
- Compute Optimized This size type has a higher CPU compared to memory and can be used for CPU-intensive workloads in medium-scale environments. This is ideal for network appliances or batch processes in small environments.
- Memory Optimized This size type provides higher memory compared to CPU and is ideal for medium-scale database servers. With high memory, these sizes can be used for caches, or used with memory analytics.
- Storage Optimized This size type offers high disk throughput and IO, which makes it a good fit for large transactional databases, such as Cassandra, MongoDB, and so on. Also, it can be used for Big Data and data warehousing.
- GPU Optimized This size type provides VMs with one or many NVIDIA GPUs.
It provides high compute and graphics, which are ideal for visualization workloads.
- High Performance Compute This size type is capable of handling batch processing, molecular modeling, and fluid dynamics. This size type offers substantial CPU power and diverse options for low-latency RDMA networking using FDR InfiniBand and several memory configurations to support memory-intensive computational requirements.
Azure Virtual Machines make it relatively easy to change the size of a virtual machine, even after it has been deployed. There are a few things to consider with this approach.
First, ensure that the region your VM is deployed to supports the instance size that you want to change the VM to. In most cases, this is not an issue, but if you have a use case where the desired size isn’t in the region to which the existing VM is deployed, your only options are to either wait for the size to be supported in the region or to move the existing VM to a region that already supports it. This can become complicated because then the new region must also have the networking and other resources required by the VM.
Second, ensure that the new size is supported in the current hardware cluster in which your VM is deployed. This can be determined by viewing the Size blade in the virtual machine con- figuration blade in the Azure portal of a running virtual machine, as shown in Figure 3-25. If the size is available, you can select it. Changing the size reboots the virtual machine.
FIGURE 3-25 Changing the size of an Azure virtual machine using the Azure portal
If a desired size is not available, it means either the size is not available in the region or on the current hardware cluster. You can view the available sizes by region at https://azure. microsoft.com/regions/services/. If you need to change to a different hardware cluster, you must first deallocate the virtual machine, and if it is part of an availability set, you must stop all instances of the availability set at the same time. After all the VMs are deallocated, you can then change the size, which moves all the VMs to the new hardware cluster as they are resized and started. All VMs in the availability set must be stopped before performing the resize operation to a size that requires different hardware because all running VMs in the availability set must use the same physical hardware cluster. Therefore, if you are required to change a physical hardware cluster in order to change the VM size, all VMs must be stopped and then restarted one by one to a different physical hardware cluster.