Load Balancer - External

🎯 Lab Objective

In this hands-on lab, you will learn how to:

Create and configure an Azure Public Load Balancer to distribute internet traffic
Set up backend pools and add virtual machines for load distribution
Configure health probes for automatic backend health monitoring
Create load balancing rules to control traffic flow
Test failover scenarios and validate high availability
Monitor load balancer performance using Azure Portal metrics

🏗️ Pre-Provisioned Environment

The following Azure resources have been pre-deployed in your environment:

Resource Overview

Resource Type	Resource Name	Configuration	Purpose
Resource Group	`rg-loadbalancer-lab`	Contains all lab resources	Logical container
Virtual Network	`vnet-webtier`	Subnet for web servers	Network foundation
Network Security Group	`nsg-webservers`	HTTP/HTTPS traffic rules	Security layer
Web Server VMs	`vm-webserver-1/2/3`	IIS with unique content	Backend targets
Public IP	`pip-loadbalancer`	Reserved for load balancer	Frontend endpoint
Temp Public IPs	`pip-webserver-*`	Individual VM access	Testing purposes

Network Architecture

Internet Traffic
       ↓
Azure Load Balancer (pip-loadbalancer)
       ↓
Backend Pool (vnet-webtier)
├── vm-webserver-1 (IIS - Server 1)
├── vm-webserver-2 (IIS - Server 2)
└── vm-webserver-3 (IIS - Server 3)

🚀 Lab Exercises

Part 1: Verify Pre-Provisioned Environment

Step 1: Navigate to Resource Group

Open the Azure Portal
Search for and select Resource groups
Click on your lab resource group

Step 2: Verify Resources

Confirm the following resources are present:

Resource	Type	Status
`vm-webserver-1`	Virtual Machine	✅ Running
`vm-webserver-2`	Virtual Machine	✅ Running
`vm-webserver-3`	Virtual Machine	✅ Running
`vnet-webtier`	Virtual Network	✅ Available
`nsg-webservers`	Network Security Group	✅ Configured
`pip-loadbalancer`	Public IP Address	✅ Reserved

Step 3: Test Individual Web Servers

In your resource group, click on each pip-webserver-* public IP
Copy the IP address from the overview page
Open a new browser tab and navigate to each server:
- http://[webserver-1-ip] → Should show “Welcome from Server 1”
- http://[webserver-2-ip] → Should show “Welcome from Server 2”
- http://[webserver-3-ip] → Should show “Welcome from Server 3”

💡 Note: Each server displays unique content to help you identify which server is responding during load balancing tests.

Part 2: Create the Public Load Balancer

Step 1: Start Load Balancer Creation

In your resource group, click + Create
Search for “Load balancer”
Select Load balancer by Microsoft
Click Create

Step 2: Configure Basics

Setting	Value	Notes
Subscription	Your subscription	Pre-selected
Resource group	Your lab resource group	Pre-selected
Name	`lb-webservers`	Descriptive name
Region	Same as resource group	Must match VMs
SKU	Standard	Required for advanced features
Type	Public	Internet-facing
Tier	Regional	Single region deployment

Step 3: Configure Frontend IP

Click Next: Frontend IP configuration
Click + Add a frontend IP configuration

Setting	Value	Notes
Name	`frontend-web`	Frontend identifier
IP version	IPv4	Standard internet protocol
IP type	IP address	Use existing public IP
Public IP address	`pip-loadbalancer`	Pre-created IP
Availability zone	Zone-redundant	High availability

Click Add

Step 4: Skip Backend Pools (For Now)

Click Next: Backend pools
Click Next: Inbound rules (we’ll configure pools later)

Step 5: Deploy Load Balancer

Click Next: Outbound rules
Click Next: Tags (optional)
Click Review + create
Review the configuration
Click Create

⏱️ Deployment Time: Typically takes 2-3 minutes to complete.

Part 3: Configure Backend Pool

Step 1: Navigate to Load Balancer

Go to your resource group
Click on lb-webservers
Wait for deployment to complete if still in progress

Step 2: Create Backend Pool

In the left menu, select Backend pools
Click + Add

Step 3: Configure Backend Pool Settings

Setting	Value	Notes
Name	`backend-webservers`	Pool identifier
Virtual network	`vnet-webtier`	Target network
Backend Pool Configuration	IP address	Use VM IP addresses
IP version	IPv4	Match frontend

Step 4: Add Virtual Machines

Under IP address and Virtual machine, click + Add
For each web server VM:

VM 1:

Virtual machine → Select vm-webserver-1
Network IP configuration → Select the IP configuration
Click Add

VM 2:

Virtual machine → Select vm-webserver-2
Network IP configuration → Select the IP configuration
Click Add

VM 3:

Virtual machine → Select vm-webserver-3
Network IP configuration → Select the IP configuration
Click Add

Click Save

🔍 Verification: You should see all 3 VMs listed in the backend pool with their private IP addresses.

Part 4: Create Health Probe

Step 1: Navigate to Health Probes

In your load balancer, click Health probes in the left menu
Click + Add

Step 2: Configure Health Probe

Setting	Value	Purpose
Name	`health-probe-http`	Probe identifier
Protocol	HTTP	Web service protocol
Port	80	Standard HTTP port
Path	`/`	Root page check
Interval	15 seconds	Check frequency
Unhealthy threshold	2 failures	Failover trigger

Step 3: Save Health Probe

Click OK
Wait for the probe to be created

💡 How it Works: The health probe sends HTTP GET requests to each backend server every 15 seconds. If 2 consecutive requests fail, the server is marked unhealthy and removed from rotation.

Part 5: Create Load Balancing Rule

Step 1: Navigate to Load Balancing Rules

In your load balancer, click Load balancing rules
Click + Add

Step 2: Configure Load Balancing Rule

Setting	Value	Notes
Name	`rule-http-traffic`	Rule identifier
IP Version	IPv4	Match frontend
Frontend IP address	`frontend-web`	Previously created
Protocol	TCP	Transport protocol
Port	80	HTTP port
Backend port	80	Same as frontend
Backend pool	`backend-webservers`	Target pool
Health probe	`health-probe-http`	Health monitoring

Step 3: Advanced Settings

Setting	Value	Purpose
Session persistence	None	Round-robin distribution
Idle timeout	4 minutes	Connection timeout
TCP reset	Disabled	Default setting
Floating IP	Disabled	Standard configuration

Step 4: Save Rule

Click OK
Wait for the rule to be created

Part 6: Test Load Balancer Functionality

Step 1: Get Load Balancer Public IP

In your load balancer, click Overview
Note the Public IP address under Frontend IP configuration
Copy this IP address

Step 2: Basic Connectivity Test

Open a new browser tab
Navigate to http://[load-balancer-public-ip]
Expected Result: You should see content from one of your web servers

Step 3: Load Distribution Test

Refresh the page multiple times (F5 or Ctrl+R)
Observe the responses: You should see different servers responding:
- “Welcome from Server 1”
- “Welcome from Server 2”
- “Welcome from Server 3”
Pattern: Requests are distributed across all healthy servers

Step 4: Command Line Testing (Optional)

If you have access to a command line with curl:

# Run this command multiple times to see load distribution
curl http://[load-balancer-public-ip]

🎯 Success Criteria: Traffic should be distributed across all 3 servers in a round-robin fashion.

Part 7: Test High Availability & Failover

Step 1: Simulate Server Failure

Go to your resource group
Click on vm-webserver-1
Click Connect → RDP (or use Bastion)
Connect to the VM using provided credentials

Step 2: Stop IIS Service

Once connected to vm-webserver-1:
Open Server Manager
Click Tools → Internet Information Services (IIS) Manager
In IIS Manager:
- Expand the server name
- Expand Sites
- Right-click Default Web Site
- Select Stop

Step 3: Monitor Health Status

Return to Azure Portal
Navigate to your load balancer
Click Backend pools → backend-webservers
Observe: vm-webserver-1 should show as Unhealthy (may take 30-60 seconds)

Step 4: Test Failover

Go back to your browser with the load balancer URL
Refresh multiple times
Expected Result: You should only see responses from Server 2 and Server 3
Confirm: No traffic goes to the failed server

Step 5: Restore Service

Return to the RDP session on vm-webserver-1
In IIS Manager:
- Right-click Default Web Site
- Select Start
Monitor: Server should return to Healthy status
Test: Traffic should resume to all 3 servers

🔧 Troubleshooting: If the server doesn’t show as unhealthy, verify the health probe settings and ensure the Default Web Site is actually stopped.

Part 8: Advanced Configuration & Monitoring

Step 1: Configure Session Persistence

Navigate to Load balancing rules → rule-http-traffic
Click Edit
Change Session persistence to Client IP
Click Save
Test: Now your browser should consistently hit the same server

Step 2: Adjust Health Probe Sensitivity

Navigate to Health probes → health-probe-http
Click Edit
Modify settings:
- Interval: Change to 5 seconds
- Unhealthy threshold: Change to 3 failures
Click Save
Observe: Faster detection of server issues

Step 3: View Performance Metrics

In your load balancer, click Metrics
Explore key metrics:

Metric	Purpose
Data path availability	Overall health percentage
Health probe status	Backend server health
Packet count	Traffic volume
Byte count	Data transferred
VIP availability	Frontend availability

Create charts for different time ranges
Set up alerts for critical metrics (optional)

🔧 Troubleshooting Guide

Common Issues and Solutions

Issue	Possible Cause	Solution
Load balancer doesn’t respond	Incorrect frontend IP configuration	Verify public IP assignment
All traffic goes to one server	Session persistence enabled	Check load balancing rule settings
Health probe fails	Web service not running	Verify IIS is running on all VMs
Slow failover	Health probe interval too long	Reduce probe interval and threshold
Backend pool empty	VMs not added correctly	Re-add VMs to backend pool

Health Probe Status Guide

Status	Meaning	Action
Healthy	Server responding correctly	No action needed
Unhealthy	Server failing health checks	Check web service status
Unknown	Initial state or transitioning	Wait for probe results

🧪 Additional Experiments

Try these optional exercises to deepen your understanding:

Multiple Ports: Configure rules for HTTPS (port 443)
Custom Health Checks: Create specific health check pages
Load Testing: Use tools like Apache Bench to stress test
Monitoring Alerts: Set up email alerts for health issues
Network Security: Modify NSG rules and observe impact

🎓 Key Takeaways

After completing this lab, you should understand:

Azure Load Balancer distributes traffic across multiple backend servers
Health probes automatically detect and handle server failures
Backend pools group servers for load distribution
Session persistence affects how clients are routed to servers
Standard SKU provides advanced features and availability zones
High availability is achieved through automatic failover