Environment
Our environment can be found below.
- Two virtual networks.
- Two virtual machines – one in UK South, one in East US with IIS running and exposing port 80.
- Two external public-facing load balancers
- One cross-region load balancer deployed in UK South
- Two Network Security Groups.
Let’s make this a little easier to understand by showing a single region without the cross-region load balancer. It isn’t easy to scale this architecture to other regions. However, this would be suitable for an application that is single region.
High availability would come through placing the virtual machines in separate availability zones. However, this design isn’t great when trying to provide regional redundancy.
In our single region architecture – we can confirm its working by going to the external front-end IP of the load balancer. The load balancer has a rule for listening to traffic on port 80. I’ve added some text to the default image, showing that the VM is in UK South.
An identical setup has been provisioned in East US. However, it has a different public IP address for the external load balancer. Again, you can see a diagram below.
If we try to access that IP address from my client machine, I can see that I can access the VM in East US through the load balancer.
Now that we have the same workload running in both UK South and East US, it’s time to use the Cross-Region Azure Load Balancer, which will provide us with regional redundancy and scale for our application.
Deploying the Cross-Region Azure Load Balancer is simple and can be done through the portal. Once it is up and running, we can start to configure it. You’ll notice that the tier for the load balancer is now set up to global.
The first setting is to create a frontend IP configuration, this needs to be done on the initial deployment, and you can view the public IP below.
Now it’s time to add backend pools – adding a backend pool is easy; however, it’s important to note that external-facing load balancers are currently only supported. I believe there are plans to allow you to use internal load balancers. You can see the screenshot below, which shows me adding both our external facing load balancers as backend targets.
Clicking save will start to deploy the backend pool configuration.
The final part is to add load balancing rules; again, this is simple if you have done previous deployments of Azure Load Balancers, the backend pool we are selecting has our external load balancers, and we have configured the cross-region load balancer to listen on port 80.
Once the following steps have been done, our cross-region load balancer has been configured. We don’t have to worry about health probes currently, as Azure sends health probes to external regional load balancers every 20 seconds by default.
If I now go to the public IP address of the cross-region load balancer, we can access our application. In this example, I am based in the UK, so I would go to the UK South load external load balancer.
I will turn off the VM running in UK South and confirm if I can still access our application, but now from East US. This took probably 10 seconds, and I switched to East US.
We can see that the health probe status has dropped on the cross-region load balancer after I turned off the VM in UK South.
After turning back on the VM, I can access the application in UK South, and the health probe status continues to increase in Azure Metrics.
