Load Balancer - Internal

🎯 Lab Objective

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

• Create and configure an Azure Internal Load Balancer for private network traffic distribution
• Set up backend pools with virtual machines for internal load distribution
• Configure health probes for automatic backend health monitoring
• Create load balancing rules for internal traffic routing
• Test load distribution and validate high availability scenarios
• Understand the differences between internal and external load balancers

Goal: Configure an Internal Load Balancer to distribute traffic between web servers within your private network.

---

🏗️ 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-internal-lb-lab	Contains all lab resources	Logical container
Virtual Network	lab-vnet	Private network space	Network foundation
Subnet	web-subnet	Web server subnet	Backend server network
Web Server 1	web-server-1	NGINX with “Server 1” content	Backend target
Web Server 2	web-server-2	NGINX with “Server 2” content	Backend target
Test VM	test-vm	Ubuntu with testing tools	Load balancer client

Network Architecture

lab-vnet (Private Network)
└── web-subnet
    ├── web-server-1 (NGINX - "Web Server 1")
    ├── web-server-2 (NGINX - "Web Server 2")
    ├── test-vm (Testing client)
    └── Internal Load Balancer (to be created)

Default Credentials

Resource	Username	Password
All VMs	azureuser	LabPassword123!

---

🚀 Lab Exercises

Part 1: Verify Pre-Provisioned Environment

Step 1: Navigate to Resource Group

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

Step 2: Verify Resources

Confirm the following resources are present:

Resource	Type	Expected Status
web-server-1	Virtual Machine	✅ Running
web-server-2	Virtual Machine	✅ Running
test-vm	Virtual Machine	✅ Running
lab-vnet	Virtual Network	✅ Available
web-subnet	Subnet	✅ Configured

Step 3: Note Private IP Addresses

1. Click on each VM to view its Overview page
2. Record the Private IP addresses:

VM	Private IP	Notes
web-server-1	.._.	Backend server
web-server-2	.._.	Backend server
test-vm	.._.	Test client

---

Part 2: Test Individual Web Servers

Before creating the load balancer, verify each web server works independently.

Step 1: Connect to Test VM

1. In the Azure Portal, click on test-vm
2. Click Connect → SSH
3. Use one of these methods:
   • Azure Cloud Shell: Click Go to Azure Cloud Shell
   • Native SSH: Use the provided command
   • Azure Bastion: If available in your lab

Step 2: Test Web Server Connectivity

Once connected to the test VM, run these commands:

# Test web-server-1 (replace with actual IP)
curl http://[web-server-1-private-ip]

# Test web-server-2 (replace with actual IP)
curl http://[web-server-2-private-ip]

# Alternative: Use nslookup to resolve hostnames
nslookup web-server-1
nslookup web-server-2

Expected Results:

• web-server-1 should return: “Welcome from Web Server 1”
• web-server-2 should return: “Welcome from Web Server 2”

💡 Troubleshooting: If connections fail, verify the VMs are running and NSG rules allow port 80 traffic.

---

Part 3: Create the Internal Load Balancer

Step 1: Start Load Balancer Creation

1. In your resource group, click + Create
2. Search for “Load balancer”
3. Select Load balancer by Microsoft
4. Click Create

Step 2: Configure Basic Settings

Setting	Value	Notes
Subscription	Your subscription	Pre-selected
Resource group	Your lab resource group	Pre-selected
Name	web-app-lb	Descriptive name
Region	Same as resource group	Must match VMs
SKU	Standard	Required for advanced features
Type	Internal	Private network only
Tier	Regional	Single region deployment

Step 3: Configure Frontend IP

1. Click Next: Frontend IP configuration
2. Click + Add a frontend IP configuration

Setting	Value	Notes
Name	WebAppFrontend	Frontend identifier
IP version	IPv4	Standard protocol
Virtual network	lab-vnet	Target network
Subnet	web-subnet	Backend subnet
IP assignment	Dynamic	Let Azure assign IP
Availability zone	No Zone	Single zone for lab

3. Click Add

Step 4: Skip Backend Pools (For Now)

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

Step 5: Complete Creation

1. Click Next: Outbound rules
2. Click Next: Tags (optional)
3. Click Review + create
4. Review the configuration
5. Click Create

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

---

Part 4: Configure Backend Pool

Step 1: Navigate to Load Balancer

1. Go to your resource group
2. Click on web-app-lb
3. Wait for deployment to complete if still in progress

Step 2: Create Backend Pool

1. In the left menu, select Backend pools
2. Click + Add

Step 3: Configure Backend Pool Settings

Setting	Value	Notes
Name	WebServersPool	Pool identifier
Virtual network	lab-vnet	Target network
Backend Pool Configuration	IP address	Use VM IP addresses
IP version	IPv4	Match frontend

Step 4: Add Web Servers

1. Under IP addresses, click + Add
2. Add both web servers:

Web Server 1:

• Virtual machine → Select web-server-1
• Network IP configuration → Select the IP configuration
• Click Add

Web Server 2:

• Virtual machine → Select web-server-2
• Network IP configuration → Select the IP configuration
• Click Add

3. Click Save

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

---

Part 5: Create Health Probe

Step 1: Navigate to Health Probes

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

Step 2: Configure Health Probe

Setting	Value	Purpose
Name	WebHealthProbe	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

1. Click OK
2. Wait for the probe to be created

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

---

Part 6: Create Load Balancing Rule

Step 1: Navigate to Load Balancing Rules

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

Step 2: Configure Load Balancing Rule

Setting	Value	Notes
Name	WebAppRule	Rule identifier
IP Version	IPv4	Match frontend
Frontend IP address	WebAppFrontend	Previously created
Protocol	TCP	Transport protocol
Port	80	HTTP port
Backend port	80	Same as frontend
Backend pool	WebServersPool	Target pool
Health probe	WebHealthProbe	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

1. Click OK
2. Wait for the rule to be created

---

Part 7: Test Load Balancer Functionality

Step 1: Get Load Balancer Private IP

1. In your load balancer, click Overview
2. Note the Private IP address under Frontend IP configuration
3. Record this IP: [load-balancer-private-ip]

Step 2: Connect to Test VM

1. Return to your SSH session on test-vm
2. If disconnected, reconnect using the same method as before

Step 3: Test Load Distribution

# Single test request
curl http://[load-balancer-private-ip]

# Multiple requests to see distribution
echo "Testing load distribution..."
for i in {1..10}; do
    echo "Request $i:"
    curl http://[load-balancer-private-ip]
    echo ""
done

Expected Results:

• Responses should alternate between “Web Server 1” and “Web Server 2”
• Traffic is distributed across both backend servers

Step 4: Continuous Testing

# Watch load balancing in real-time
while true; do
    echo "$(date): $(curl -s http://[load-balancer-private-ip])"
    sleep 2
done

Press Ctrl+C to stop the continuous test.

🎯 Success Criteria: You should see roughly equal distribution of requests between the two web servers.

---

Part 8: Test High Availability & Failover

Step 1: Monitor Current Health Status

1. In Azure Portal, navigate to your load balancer
2. Click Backend pools → WebServersPool
3. Observe: Both servers should show as Healthy

Step 2: Simulate Server Failure

1. Go to your resource group
2. Click on web-server-1
3. Click Stop in the toolbar
4. Confirm the stop action

Step 3: Monitor Health Changes

1. Return to the backend pool view
2. Wait 30-60 seconds for health probe to detect the failure
3. Observe: web-server-1 should show as Unhealthy

Step 4: Test Failover Behavior

From your test VM SSH session:

# Test during failover
echo "Testing failover behavior..."
for i in {1..10}; do
    echo "Request $i:"
    curl http://[load-balancer-private-ip]
    echo ""
done

Expected Results:

• All requests should go to web-server-2 only
• No requests should fail (high availability maintained)

Step 5: Restore Service

1. Go back to web-server-1 in the Azure Portal
2. Click Start in the toolbar
3. Wait for the VM to fully start
4. Monitor: Server should return to Healthy status
5. Test: Traffic should resume to both servers

---

Part 9: Advanced Testing & Configuration

Step 1: Configure Session Persistence

1. Navigate to Load balancing rules → WebAppRule
2. Click Edit
3. Change Session persistence to Client IP
4. Click Save

Step 2: Test Session Persistence

# Test sticky sessions
echo "Testing session persistence..."
for i in {1..10}; do
    echo "Request $i:"
    curl http://[load-balancer-private-ip]
    echo ""
done

Expected Result: All requests should consistently go to the same server.

Step 3: Reset to Round Robin

1. Change Session persistence back to None
2. Test again to confirm round-robin behavior returns

Step 4: Monitor Performance Metrics

1. In your load balancer, click Metrics
2. Explore key metrics:

Metric	Purpose
Data path availability	Overall health percentage
Health probe status	Backend server health
Packet count	Internal traffic volume
Byte count	Data transferred

---

🔧 Troubleshooting Guide

Common Issues and Solutions

Issue	Possible Cause	Solution
Load balancer doesn’t respond	Incorrect private IP	Verify frontend IP configuration
Can’t connect to test VM	NSG blocking SSH	Check NSG rules allow port 22
Health probe fails	Web service not running	Verify NGINX is running on web servers
All traffic to one server	Session persistence enabled	Check load balancing rule settings
Slow failover detection	Health probe interval too long	Reduce probe interval

Health Status Meanings

Status	Description	Action
Healthy	Server responding to probes	No action needed
Unhealthy	Server failing health checks	Check server status
Unknown	Initial state or transitioning	Wait for probe results

---

🔍 Internal vs External Load Balancer Comparison

Internal Load Balancer

• ✅ Private IP address within VNet
• ✅ Internal traffic only (VNet-to-VNet, on-premises)
• ✅ No internet exposure (enhanced security)
• ✅ Lower cost (no public IP required)
• ❌ Not accessible from internet

External Load Balancer

• ✅ Public IP address for internet access
• ✅ Internet-facing applications
• ✅ Global accessibility
• ❌ Higher cost (public IP required)
• ❌ Increased attack surface

---

🧪 Additional Experiments

Try these optional exercises to deepen your understanding:

1. Multiple Subnets: Deploy load balancer across different subnets
2. Custom Health Checks: Create specific health check endpoints
3. Port-based Rules: Configure different ports for different services
4. Network Security: Test with restrictive NSG rules
5. Cross-VNet: Test load balancer with peered virtual networks

---

🎓 Key Takeaways

After completing this lab, you should understand:

• Internal Load Balancers distribute traffic within private networks
• Backend pools group internal resources for load distribution
• Health probes ensure high availability through automatic failover
• Session persistence affects client routing behavior
• Private IP addressing keeps traffic within Azure networks
• High availability is maintained even during server failures

---

📈 Load Balancer Configuration Summary

Key Components

• Frontend IP: Private IP within your VNet
• Backend Pool: Collection of internal servers
• Health Probe: Monitors server availability
• Load Balancing Rule: Defines traffic distribution

Distribution Methods

• None (Round Robin): Requests distributed evenly
• Client IP: Same client always goes to same server
• Client IP and Protocol: Based on IP and protocol combination

---

📚 Additional Resources

• Internal Load Balancer Overview
• Load Balancer Health Probes
• Internal vs External Comparison
• Load Balancer Best Practices