Use an Azure ARM template to create a high availability (active-standby) pair of BIG-IP Virtual Edition instances in Microsoft Azure. When one BIG-IP VE goes standby, the other becomes active, the virtual server address is reassigned from one external NIC to another.
Today, let’s walk through how to create a high availability pair of BIG-IP VE instances in Microsoft Azure. When we’re done, we’ll have an active-standby pair of BIG-IP VEs.
To start, go to the F5 Networks Github repository.
Click F5-azure-arm-templates. Then go to Supported>ha-avset and there are two options. You can deploy into an existing stack when you already have your subnets and existing IP addresses defined but to see how it works, let’s deploy a new stack.
Click new stack and scroll down to the Deploy button. If you have a trial or production license from F5, you can use the BYOL option but in this case, we’re going to choose the PAYG option.
When you get to the questions:
The DNS label is used as part of the URL.
Instance Name is just the name of the VM in Azure.
Instance Type determines how much memory and CPU you’ll have.
Image Name determines how many BIG-IP modules you can run (and you can choose the latest BIG-IP version).
Licensed Bandwidth determines the maximum throughput of the traffic going through BIG-IP.
Select the Number of External IP addresses (we’ll start with one but can add more later). For instance, if you plan on running more than one application behind the BIG-IP, then you’ll need the appropriate external IP addresses.
Vnet Address Prefix is for the address ranges of you subnets (we’ll leave at default).
The next 3 fields (Tenant ID, Client ID, Service Principal Secret) have to do with security. Rather than using your own credentials to modify resources in Azure, you can create an Active Directory application and assign permissions to it.
The last two fields also go together. Managed Routes let you route traffic from other external networks through the BIG-IPs. The Route Table Tag means that anytime this tag is found in the route table, routes that have this destination are updated so that the next hop is the IP address of the active BIG-IP VE. This is useful if you want all outbound traffic to go through the BIG-IP or if you want to send traffic from a bunch of different Vnets through the BIG-IP.
We’ll leave the rest as default but the Restricted Src Address is good way to put IP addresses on my network – the ones that are allowed to connect to the BIG-IP.
We’ll agree to the terms and click Purchase.
We’re redirected to the Dashboard with the Deployment in Progress indicator. This takes about 15 minutes.
Once finished we’ll go check all the resources in the Resource Group.
Let’s find out where the virtual server address is located since this is associated with one of the external NICs, which have ‘ext’ in the name. Click the one you want.
Then click IP Configuration under Settings.
When you look at the IP Configuration for these NICs, whenever the NIC has two IP addresses that’s the NIC for the active BIG-IP. The Primary IP address is the BIG-IP Self IP and the Secondary IP is the virtual server address.
If we look at the other external NIC we’ll see that it only has one Self IP and that’s the Primary and it doesn’t have the Secondary virtual server address. The virtual server address is assigned to the active BIG-IP.
When we force the active BIG-IP to standby, the virtual server address is reassigned from one NIC to the other.
To see this, we’ll log into the BIG-IPs and on the active BIG-IP, we’ll click Force to Standby and the other BIG-IP becomes Active.
When we go back to Azure, we can see that the virtual server IP is no longer associated with the external NIC.
And if we wait a few minutes, we’ll see that the address is now associated with the other NIC.