Tag Archives: Azure Virtual Machines

#Azure : Step-by-step Availability Sets

1 Reply

In my previous post, I had explained about the high availability configuration for Azure virtual machines, Availability Sets, Fault domains and Update domains. In this blogpost, I’ll cover step-by-step configuration using Azure Portal. Availability Set configuration can be done in two ways, either by creating and configuring it in early stage based on your application architecture or set it up while creating a first VM for each tier and add rest of the same tier VMs to the respective availability set.

I am going to explain, how to create and configure availability set in advance.

Login to the Azure Portal and select “+ Create a resource”.

In the Azure Market Place, search for Availability Set.

From the search results, select “Availability Set”.

In the Availability Set panel, select create.

In the create availability set panel, define the parameters.

Name: Enter the name of the availability set.

Subscription: Select the subscription.

Resource group: Either create a new one or select an existing one based on your requirement.

Location: Select the location.

Fault domains: Select the number of fault domains, by default it is two but for specific Azure regions you can select up to three fault domains.

Update domains: Select the number of update domains, by default it is five but you go up to 20 update domains in each availability sets.

Use managed disks: Select Yes (by default) if you would like to use managed disk for all the VMs that will be create in this availability set otherwise “No”.

Once, you have filled all the details based on your requirement then select “create” to start the deployment of availability sets.

Wait for few seconds, your availability set will be created. Now, you can go head and create your VMs using this availability set.

While creating a virtual machine you get both the options, either select the existing availability set or create a new one.

If you select the “+ Create new” then again you have to fill the same details as filled earlier then select “OK”.

Once you created an availability set, you will not able to modify it and the same concept applies to VM as well. If you have created a VM as part of the availability set then you can’t come out or change the availability set until you delete and recreate it.

Advertisement

#Azure : Virtual Machines High Availability

Leave a reply

High availability is crucial for any production environment either it is in on-premises datacenter or in cloud. If you will go in detail of high availability, you will observer that HA can be achieved in the following levels from compute perspective:

Hardware level

Hypervisor/VM level

Operating System level

 

In this blogpost, I’ll cover high availability options available in MS Azure. First, make it clear that OS level HA has no difference between on-premises or in cloud. Now, let me provide the overview of H/W, and Hypervisor/VM level HA in on-premises datacenter or private cloud.

Hardware level HA: Dual or Quad processor, dual power supply, multi memory channel, multiple network slots, and multiple PCI card slots etc.

Hypervisor/VM level: All type 1 hypervisors provide high-availability configuration options like operating systems. Once, you configure HA for the hypervisor the VM can be created on top of that and hypervisor HA configuration maintains the availability for guest VMs if any host goes down.

Apart from the H/W and hypervisor level, all the datacenter components can be configured in high available mode such as multiple racks and power supply units etc. but when it comes to public cloud you can’t define the above configurations by your-self. However, cloud service provider does all these configurations for you in advance and to simply the things for you it just provides an availability feature.

Microsoft Azure provides “Availability Set” to provide high-availability at the VM level. This availability set feature takes care of both planned and unplanned failures. To define these planned and unplanned failures, availability set allows you to configure update domain and fault domains.

In simple words, availability set is a logical grouping of two or more virtual machines. When you setup the availability set keep the following principles in your mind:

Setup an availability set for one type of VMs. For example, in 3 tier application architecture create different availability sets for each tier.

For high availability of VMS, create multiple VMs in an availability set.

Attach load balancer with availability sets. It helps you to divide the load among the VMs.

Now, let me explain you update domain and fault domain.

Update domain: An update domain allows VMs to maintain availability during planned maintenance. Each update domain contains set of virtual machines and associated physical hardware that can be updated and rebooted at the same time. It allows Azure to perform incremental or rolling upgrades across a deployment. Once, you create an availability set then you can observe that there are five update domains by default set but you can configure up to twenty update domains.

Fault domain: A fault domain allows VMs to maintain availability during unplanned hardware failures, network outages, power failures and software updates. Fault domain describes the datacenter level components such as network switches and power supply serving a single rack can become a single point of failure for one rack or multiple racks. To avoid these circumstance, VMs in an availability set can have at least two fault domains. Many Azure region only supports two fault domains while other Azure regions can have maximum three fault domains.

If you would like to setup an availability set, follow the step by step availability sets blogpost.

#Azure : Virtual Machine Configuration

Leave a reply

When you have decided to use Azure IaaS virtual machines based on your requirements, you need to look at the configuration. Resource group is required to create any resource in Microsoft Azure. Let see the configuration of virtual machine.

Login to the Microsoft Azure Portal and select “+ create a resource”. Select compute and then select OS that needs to be deployed as part of the VM. In my case, I am deploying “Windows Server 2016 Datacenter”.

In the first step, define settings as required.

Name = Name of the virtual machine, same name will be applied as a host name.

VM disk type = Either HDD or SSD

User name = Default administrator name

Password = Password for the administrative user name

Confirm password = Confirm password for the administrative user name

Subscription = Select subscription from where the VM cost will be deducted

Resource group = Either “Create new” or “Use existing”

Location = Select the location of your Azure Region

Windows license = Select “Yes” if you have windows license otherwise “No”

Finally select “OK”

In the second step, select the VM size based on your requirement. You can short the VM size by selecting disk type, vCPUs and Memory.

In the third step, configure optional features.

High Availability = If you are deploying multiple VMs in the HA mode, create an “Availability set” and define fault & update domain as needed.

Storage = If you would like to use disk managed by Microsoft, select “Yes” in “Use managed disks” option. Otherwise select “No”, if you select “No” then you need to define a storage account.

Network = Select virtual network for the VM. If you don’t have any then a new will be created for you by default but still you can define your virtual network and use the same.

Subnet = select subnet, an ip to the VM will be assigned from this subnet

Public IP address = Use public ip address, if you want to access this VM directly through the internet. Otherwise you can select “None” here.

Network security group = Use network security group, if you would like to access or deny network traffic on the VM level.

Extensions = If you need to use any extensions as part of the VM deployment then add extensions such as PowerShell DSC, Custom Script Extension etc.

Auto-shutdown = Either “On” or “Off” and define the time and time zone based on your needs.

Notification before shutdown = Either “On” or “Off”

Monitoring = Either “Enabled” or “Disabled” for boot and guest OS diagnostics. If you enable the diagnostics then you need to use a storage account. This diagnostics user account either you can create or use the existing one.

Backup = Either “Enabled” or “Disabled”. If you enable backup option then you need to define “Recovery Services vault”, Resource group (for recovery service vault) and backup policy.

Once done select OK.

In the fourth step, review all the configuration and select “Create” to start the deployment process.

Wait for couple of minutes, your VM will be available for use. If you would like to reuse the VM configuration as-is or would like to reuse the VM configuration with customization then “Download template and parameters” for future deployments.

#Azure : Virtual Machines

Leave a reply

Virtual machines look simple in the public cloud space but when do you look at it from the datacenter perspective, you feel the heat. VM is not only a set of resources or a platform with operating system to run your application, runtime or database. It is a baseline that defines the purpose of its existence itself based on the resources used in it. VM configuration is vendor agnostic and totally depends on how do you design it with certain set of components such as processor, memory, storage and networking. Apart from these basic components, there are some specific set of design considerations such as high availability that needs to be taken into the account while planning for any infrastructure based solution. In public cloud, the VM configuration can be determined by VMs size and VMs family type.

Let me take you through the VM design considerations applicable to public cloud. However, these best practices can also be leveraged in private cloud or virtualization stack in the on-premises datacenter.

Storage: How much, where, and in what configuration.

Disk: Sizing, persistence and caching.

Compute: Capacity required.

Availability: Uptime requirements, geo-distribution, service level agreements, and accessibility.

Cost: Azure services, such as storage and compute.

Here is the list of VM sizes and respective description:

Type Sizes Description
General purpose B, Dsv3, Dv3, DSv2, Dv2, DS, D, Av2, A0-7 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, DS, Dv2, D 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, A8-11 Our fastest and most powerful CPU virtual machines with optional high-throughput network interfaces (RDMA).

Courtesy: Microsoft

While best practices and VMs size should be considered effectively, at the same time you need to find suitable and not suitable workloads for Microsoft Azure VMs.

Suitable workloads:

There are certain types of workloads that are a better fit for hosting in an Azure IaaS environment than others. Here are some examples:

  • Highly available service workloads such as commercial online stores.
  • Unpredictable growth workloads like those experienced by small, but rapidly expanding organizations, or short-term increased sales of fad items.
  • Spiking workloads, such as those experienced by sites providing news services.
  • Steady workload scenarios where organizations simply want to offload their infrastructure to the cloud.
  • Periodic workloads such as retail sales spurts during holidays.

Not Suitable workloads

When planning virtual machine workloads for Azure IaaS, it is also important to remember that not every application or service is a suitable fit for the cloud. Here are some examples.

  • Low volume or limited growth workloads where the organization might be able to run the service or application on commodity hardware on-premise less expensively than in the cloud.
  • Regulated environment workloads where an organization, or even the local government, may regulate the type of data that can be hosted in the cloud. However, these cases might be suitable candidates for a hybrid solution where only some highly available data is hosted in Azure and the more sensitive, regulated data is kept on-premises.

Notice that although Azure virtual machines are based on Windows Server Hyper-V not all Hyper-V features are supported. For example, Multipath I/O and Network Load Balancing are not currently supported. Also, certain Azure virtual machine offerings may include additional Microsoft software on a per-hour or evaluation basis. Licenses for other software must be obtained separately.