How to set up Azure internal load balancer?

person using laptop computer during daytime
Reading Time: 4 minutes

Introduction

The Internal load balancer manages load for a private network with any inbound access from the public platform. As in the diagram below, the primary load balancer managing load from the internet is a public-type load balancer. But, the VMs communication to storage or database is managed through a type-internal load balancer.

internal load balancer use

Internal Load Balancer Setup

Let us see our setup which we will explain here. We have 3 virtual machines, 1 virtual network, and 1 Load Balancer of type-internal. We will use the vmtest to test if we can balance the load for traffic from the same network. The load will be on web servers deployed on two VMs: vm1 and vm2.

internal load balancer setup

Create a common resource group in the Azure cloud for this demonstration. We are taking the name “rg-lb” and the rest of the default configuration.

Step 1: Creating the Virtual Network

We used the following configurations:

  • Name: myVnet
  • region: East US
  • Address: 10.0.0.0/16
  • subscription: Azure subscription 1
  • resource group: rg-lb
  • subnet name: mySubnet
  • Subnet Address range: 10.0.0.0/24

Step 2: Creating the virtual machines

Create 3 VMs with similar configurations only name changes

  • Name: vm1 / vm2 / vmtest
  • subscription: Azure subscription 1
  • resource group: rg-lb
  • region: East US
  • Availability options: Availability set (because distribute VMs across multiple fault domains but zone remains same)
  • Availability set: (create a new set and leave the fault domains:2 and update domains:5 as they are): myavailabilityset
  • Image: Windows Server 2016 Datacenter ( windows servers are good for practice)
  • size: Standard_B2s
  • Username: azureuser
  • Password: yourown
  • Confirm Password: yourown
  • inbound ports: HTTP,HTTPS,RDP
  • OS disk type: Standard SSD
  • Boot diagnostics: Off ( to stop from creating a storage account)
  • Virtual network: myVnet
  • subnet: mySubnet
availibility set
vm created

Step 3: Creating a Load Balancer

We will be creating a load balancer with the following configurations:

  • name: webserverlb
  • type: Internal
  • SKU: Standard
  • virtual network: myVnet
  • subnet: mysubnet
  • resource group: rg-lb
  • location: East US
  • tier: Regional
  • frontend IP
    • Name: mylbIP
    • Virtual Network: myNet
    • Subnet: mySubnet(10.0.0.0/24)
    • Assignment: Dynamic
  • Backend pool
    • Name: mylbPool
    • Backend Pool Configuration: IP address
    • IP addresses: select private IPs of vm1 and vm2
  • load balancing group:
    • Name: lb-rule
    • IP Version: IPv4
    • Backend pool: mylbPool
    • Protocol: TCP
    • Port: 80
    • Backend Port: 80
    • health probe (create new)
      • Name: mylbProbe
      • protocol: HTTP
      • Interval: 5 seconds
      • Path: /
      • Port: 80
    • ideal time out 4 minute
    • TCP reset: disabled
    • Floating IP: disabled
inbound rule NAT
inbound rule
loadbalancing rule
load balancing rule
Webserlb

Step 4: Webserver installation on VMs

Download the RDP file of vm1 and vm2. We are using Remina Connect to run the virtual machines locally with an RDP connection. You can use Remote Desktop Connection in Windows. Install the IIS web server on vm1 and vm2 using server manager. And set up the default pages in a way that distinguishes both pages like we have done.

vm1 setup
vm2 setup

Step 5: Testing the connection

Download the RDP file of vmtest and open using the RDP connecter. Copy the Private IP of the load balancer from the frontend IP configuration. Open the private IP on the browser, and you would get the default page of one of the VMs. As the idle time to wait is 4 minutes, then refresh you would get the other VM’s default page as shown here.

load balancer ip
vm1 page
vm2 page

Conclusion

This was to practice the use internal load balancer. We can create a complete network infrastructure as stated in starting diagram. You can refer to azure docs for understanding.

Note: Do not forget to delete the resource group to delete all resources created.

knoldus footer

Also published on Medium.

Written by 

Vaibhav Kumar is a DevOps Engineer at Knoldus | Part of Nashtech with experience in architecting and automating integral deployments over infrastructure. Proficient in Jenkins, Git, AWS and in developing CI pipelines. Able to perform configuration management using ansible and infrastructure management using terraform. Like to script and do developing in Python. Other than AWS, have an experience in Google Cloud, Azure cloud services. Other than Jenkins, CI/CD in Azure Pipelines, GitHub Actions, Teamcity. Loves to explore new technologies and ways to improve work with automation.