Now that we have our VM’s up and running in ARM, there are still some things to configure.

Some main items still need our direct attention and that’s what will be covered in this blog:

Public IP, Load Balancers and Availability Sets

Availability Sets

Besides the Load Balancers, we also need to put the Web VMs in an availability set if we want to make use of Azure fault tolerance.

It would be a great addition if you could specify this in the ASR replication policy, as you will see that we will need to delete and recreate the VMs to make this happen.

Thanks to the community and in this case especially SAMIR FARHAT for his script that does this for us:

This script will guide you through the whole process, the only thing you might want to do is to create the Availability Set that you want to use:

Starting the script:

Checking if the WebVMs show that they are member of the Availability Set that we specified:

and they are, moving on to the next step:

Load Balancers

When it comes down to load balancers, VMs deployed within a cloud service boundary can be grouped to use a load balancer.

In the ASM model a public IP address and a FQDN are assigned to the cloud service itself.

The load balancer does port translation and load balances the network traffic by using the public IP address for the cloud service.

In the Resource Manager deployment model there is no such thing as a Cloud service, the load balancer is created to route traffic among multiple virtual machines.

A public IP address is an individual resource that has a domain label (DNS name) and the public IP address is associated with the load balancer resource.

Load balancer rules and inbound NAT rules use the public IP address as the Internet endpoint for the resources that are receiving load-balanced network traffic.

Public IP

create public ip

I prefer to create the Public IP first (you are able to do this while creating the Load Balancer but then you lack the options to specify FQDN)

create public ip

Give your resource a name, select ‘Static’ mode for your IP and assign a  DNS name.

Create the Load Balancer

create loadbalancer

create loadbalancer

give the resource a name, make sure the type is set to Public and select the Public IP you previously created

create backend pool

click add

create backend pool

assign a name to the pool

create backend pool

select the Availability Set and Web VM’s and click OK on all the steps

Health Probes

Before we can add the load balancing rule for HTTP, we first need to configure a health probe.

For this I select the HTTP probe as this one also checks if the website is healthy (TCP probe just checks if ping requests get answered)

create health probe

create HTTP rule

Now we can move over to adding the HTTP rule to the Load Balancer

create load balancer rule

click add

create load balancer rule

create the rule to balance incoming HTTP traffic on port 80


Now lets take the DNS name of the public IP assigned to the load balancer and paste it in a browser

verify web connectivity

WebVM2 is responding

verify web connectivity

and so is WebVM1

Hope you have enjoyed the walk through!


Some items that were encountered during this POC but did not get published:

  • There was a difference in the naming of the destination VM’s so we also had to change the SQL connection string in the ‘web.config’ file
  • The SQL VM had a virtual disk (Storage Spaces) that we needed to recreate on the destination VM

In a production environment it will make more sense to make use of the SQL application replication mechanism, if that’s not possible then make sure you have a working SQL backup that you can restore on the target VM.

You should also add Networks Security Groups to the subnets and install Web Application Firewall to protect your resources!



This article is part of a series, check for the overview here:  Azure: Moving form ASM to ARM with ASR (TOC)