Common Misconceptions About Load-Balanced Azure VMs

Overview

In my work as a Udacity reviewer for the "Deploying a Web Server in Azure" project, I've noticed a common misunderstanding. Many students add an Availability Set to its Terraform configuration and omit connecting the VMs to the Load Balancer. While an Availability Set offers redundancy within a data center, it does not handle traffic distribution, a task performed by a Load Balancer.

Students may attempt to achieve auto-scaling by adding the Availability Set, but this project needs to cover it. I understand the importance of autoscaling; however, it's achieved through resources like Azure Scale Sets, not Availability Sets.

This article aims to clarify these critical distinctions to understand Azure infrastructure better.

Detailed Steps for VM and Load Balancer Integration in Azure

In the "Deploying a Web Server in Azure" project by Udacity, correctly configuring multiple VMs and connecting them to a Load Balancer is crucial.

1. Configuring multiple VMs, the VMs should depend on network interfaces, which must be created beforehand:

resource "azurerm_virtual_machine" "vm" {
  count                = var.vm_count
  name                 = "example-vm-${count.index}"
  network_interface_ids = [azurerm_network_interface.example[count.index].id]
  // ...other configurations...
  depends_on = [azurerm_network_interface.example]
}
        

This Azure NIC documentation is an excellent resource for a comprehensive understanding of Azure Network Interfaces (NICs).

2. Next, we define the Load Balancer:

resource "azurerm_lb" "example_lb" {
  name                = "example-lb"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name

  frontend_ip_configuration {
    name                 = "publicIPAddress"
    public_ip_address_id = azurerm_public_ip.example.id
  }

  // Additional configurations may include specific rules, probes, etc.
}
        

In this declaration:

• name: Specifies the name of the Load Balancer.
• location and resource_group_name: Define where the Load Balancer is located and the resource group it belongs to.
• frontend_ip_configuration: This block configures the front-end IP settings, associating the Load Balancer with a public IP address.

This configuration sets the foundation for the Load Balancer, which will distribute traffic across the VMs defined earlier. Please remember to tailor additional settings like load balancing rules and health probes to your needs.

3. In the association of VMs with the Load Balancer, we use the count attribute to iterate over the number of VMs and associate each with the Load Balancer. Here's how it works:

resource "azurerm_lb_backend_address_pool_association" "vm_lb_association" {
  count                    = var.vm_count
  network_interface_id     = azurerm_network_interface.example[count.index].id
  lb_backend_address_pool_id = azurerm_lb_backend_address_pool.example.id
}
        

• count = var.vm_count: This iterates over the VMs based on the number defined in var.vm_count.
• count.index: This is used to reference each specific VM’s network interface. For instance, on the first iteration (count.index = 0), the first VM’s network interface is associated with the Load Balancer, and so on for each subsequent VM.

In the azurerm_lb_backend_address_pool_association resource, the count attribute creates multiple instances of the association, each corresponding to a VM. The count.index serves as the current iteration index, linking each association instance to the respective VM and network interface.

For example, when count.index is 0, the first VM's network interface is associated with the Load Balancer. As count.index increments, the following VM's network interface is picked up for association, ensuring that each VM is correctly linked to the Load Balancer sequentially and orderly. This methodical linkage is crucial for efficient load balancing across all VMs.

Enhancing VM Availability with Availability Sets

Availability Sets in Azure are designed to maximize the uptime of VMs by distributing them across isolated hardware nodes.

Azure automatically distributes VMs across fault and update domains within an Availability Set. We can only specify the number of these domains when declaring the availability set.

An essential detail to remember is that VMs can be assigned to an Availability Set only during creation. We must use the availability_set_id attribute to connect the VM to the availability set. We used the corresponding attributes when declaring the availability set resource to set up the number of faults and update domains:

resource "azurerm_availability_set" "example_avset" {
  name                        = "example-avset"
  location                    = azurerm_resource_group.example.location
  resource_group_name         = azurerm_resource_group.example.name
  platform_fault_domain_count = 2 // Number of fault domains
  platform_update_domain_count = 2 // Number of update domains
}

resource "azurerm_virtual_machine" "example_vm" {
  name                  = "example-vm"
  availability_set_id   = azurerm_availability_set.example_avset.id
  // Other configurations...
}
        

This setup ensures high availability by leveraging Azure's distribution across different hardware nodes, enhancing the resilience of your deployment. But it won't start more VMs if we see a sudden user surge for our application.

Implementing Autoscaling with VM Scale Sets and Load Balancer Integration

Autoscaling in Azure using Virtual Machine Scale Sets (VMSS) allows for dynamic adjustment of resources. Here's how to set it up with a custom image and integrate it with a Load Balancer:

First, we define the VM template in the VMSS resource, specifying the custom image and other VM settings:

resource "azurerm_virtual_machine_scale_set" "example" {
  name                = "example-vmss"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name

  sku {
    name     = "Standard_DS1_v2" // Example VM size
    capacity = 2
  }

  storage_profile_image_reference {
    id = "" // Your custom image ID
  }

  // Other VM configurations...
}
        

In the sku section, we control the size of the VMs that are running at all times will be created and the minimum number of VMs r with the capacity attribute.

To integrate the Load Balancer, we'll do the VMSS configuration and define the network profile to include the Load Balancer’s backend address pool:

network_profile {
  name    = "exampleNetworkProfile"
  primary = true

  ip_configuration {
    name                                   = "IPConfiguration"
    subnet_id                              = azurerm_subnet.example.id
    load_balancer_backend_address_pool_ids = [azurerm_lb_backend_address_pool.example.id]
  }
}
        

In VMSS, availability sets are implicitly created and managed by Azure. We don't need to manually create or assign VMs to availability sets as VMSS automatically distributes VM instances across fault and updates domains for high availability.

This setup ensures that your VMs, based on the specified custom image, will automatically scale and are balanced across the Load Balancer, optimizing performance and reliability.

This example provides a minimal configuration for autoscaling using Azure VM Scale Sets in Terraform. You must refer to detailed resources to understand all autoscaling capabilities and comprehensive, advanced configurations. A complete overview, including more complex scenarios and in-depth guidelines, can be found in Azure's documentation on autoscaling. You can explore Azure's Autoscale documentation to learn more details.

Conclusion

In conclusion, deploying a highly available and scalable web server in Azure requires understanding several Azure components. By correctly configuring VMs within Availability Sets, implementing Load Balancers, and utilizing Azure VM Scale Sets with autoscaling, you can ensure that your application is resilient and efficiently handles varying loads.

Remember, while this article covers the essentials, Azure's capabilities are extensive, and continuous learning is critical to leveraging its full potential in infrastructure management and optimization.

Addendum: A Special Note for Our Readers

I decided to delay the introduction of subscriptions, you can read the full story here.

In the meantime, I decided to accept donations.

If you can afford it, please consider donating:

Every donation helps me offset the running costs of the site and an unexpected tax bill. Any amount is greatly appreciated.

Also, if you are looking to buy some Swag, please visit I invite you to visit the TuringTacoTales Store on Redbubble.

Take a look, maybe you can find something you like: