on 13-Feb-2020 16:04
In this edition of Lightboard Lessons, I cover the deployment of a BIG-IP in Azure cloud. There are a few videos associated with this topic, and each video will address a specific use case.
Topics will include the following:
Glossary:
This overview covers the on-prem BIG-IP with a 3-nic example setup. I then discuss the Azure cloud network and cloud components and how that relates to making a BIG-IP work in the Azure cloud. Things discussed include NICs, routes, network security groups, and IP configurations. The important thing to remember is that the cloud is not like on-prem regarding things like L2 and L3 networking components. This makes a difference as you assign NICs and IPs to each virtual machine in the cloud.
Read more here on F5 CloudDocs for Azure BIG-IP Deployments.
The high availability section will review three different videos. These videos will discuss the failover methods for a BIG-IP cluster and how traffic can failover to the second device upon a failover event. I also discuss IP addressing options for the BIG-IP VIP/listeners and "why".
Question: “Which F5 solution is right for me? Autoscaling or HA solutions?”
Use these bullet points as guidance:
How do IP addresses and routes failover to the other BIG-IP unit and still process traffic with no layer 2 (L2) networking? Easy, API calls to the cloud. When you deploy an HA pair of BIG-IP instances in the Azure cloud, the BIG-IP instances are onboarded with various cloud scripts. These scripts help facilitate the moving of cloud objects by detecting failover events, triggering API calls to Azure cloud, and thus moving cloud objects (ex. Azure IPs, Azure route next-hops). Traffic now processes successfully on the newly active BIG-IP instance.
Benefits of Failover via API:
Requirements for Failover via API:
Other things to know:
Read about the F5 GitHub Azure Failover via API templates.
This type of BIG-IP deployment in Azure requires the use of an Azure load balancer. This ALB sits in a Tier 1 position and acts as an Layer 4 (L4) load balancer to the BIG-IP instances. The ALB performs health checks against the BIG-IP instances with configurable timers. This can result in a much faster failover time than the "HA via API" method in which the latter is dependent on the Azure API queue. In default mode, the ALB has Direct Server Return (DSR) disabled. This means the ALB will DNAT the destination IP requested by the client. This results in the BIG-IP VIP/listener IP listening on a wildcard 0.0.0.0/0 or the NIC subnet range like 10.1.1.0/24. Why? Because ALB will send traffic to the BIG-IP instance on a private IP. This IP will be unique per BIG-IP instance and cannot "float" over without an API call. Remember, no L2...no ARP in the cloud. Rather than create two different listener IP objects for each app, you can simply use a network range listener or a wildcard. The video has a quick example of this using various ports like 0.0.0.0/0:443, 0.0.0.0/0:9443.
Benefits of Failover via LB:
Requirements for Failover via LB:
Other things to know:
Read about the F5 GitHub Azure Failover via ALB templates.
This is a quick follow up video to the previous "HA via ALB". In this fourth video, I discuss the "HA via ALB" method again but this time the ALB has DSR enabled. Whew! Lots of acronyms! When DSR is enabled, the ALB will send the traffic to the backend pool (aka BIG-IP instances) private IP without performing destination NAT (DNAT). This means...if client requested 2.2.2.2, then the ALB will send a request to the backend pool (BIG-IP) on same destination 2.2.2.2. As a result, the BIG-IP VIP/listener will match the public IP on the ALB. This makes use of a floating IP.
Benefits of Failover via LB with ALB DSR Enabled:
Requirements for Failover via LB:
Example iRule...
when HTTP_REQUEST { HTTP::respond 200 content "OK" }
Other things to know:
Read about the F5 GitHub Azure Failover via ALB templates. Also read about Azure LB and DSR.
This type of BIG-IP deployment takes advantage of the native cloud features by creating an auto scaling group of BIG-IP instances. Similar to the "HA via LB" mentioned earlier, this deployment makes use of an ALB that sits in a Tier 1 position and acts as a Layer 4 (L4) load balancer to the BIG-IP instances. Azure auto scaling is accomplished by using Azure Virtual Machine Scale Sets that automatically increase or decrease BIG-IP instance count.
Benefits of Auto Scale with LB:
Requirements for Auto Scale with LB:
Other things to know:
Sorry, no video yet...a picture will have to do! Here's an example diagram of auto scale with ALB.
Read about the F5 GitHub Azure Auto Scale via ALB templates.
This type of BIG-IP deployment takes advantage of the native cloud features by creating an auto scaling group of BIG-IP instances. Unlike "HA via LB" mentioned earlier or "Auto Scale with ALB", this deployment makes use of DNS that acts as a method to distribute traffic to the auto scaling BIG-IP instances. This solution integrates with F5 BIG-IP DNS (formerly named GTM). And...since there is no ALB in front of the BIG-IP instances, this means you do not need SNAT automap on the BIG-IP listeners. In other words, if you have apps that need to see the real client IP and they are non-HTTP apps (can't pass XFF header) then this is one method to consider.
Benefits of Auto Scale with DNS:
Requirements for Auto Scale with DNS:
Other things to know:
Sorry, no video yet...a picture will have to do! Here's an example diagram of auto scale with DNS.
Read about the F5 GitHub Azure Auto Scale via DNS templates.
That's it for now! I hope you enjoyed the video series (here in full on YouTube) and quick explanation. Please leave a comment if this helped or if you have additional questions.
F5 High Availability - Public Cloud Guidance
The Hitchhiker’s Guide to BIG-IP in Azure
The Hitchhiker’s Guide to BIG-IP in Azure – “Deployment Scenarios”
The Hitchhiker’s Guide to BIG-IP in Azure – “High Availability”
The Hitchhiker’s Guide to BIG-IP in Azure – “Life Cycle Management”
I plan to cover auto scale deployments and a few others in future articles.
Thank you for the easy to understand explanation of how this all works. Great job!
Thanks for this documentation.
For HA Using ALB for Failover with DSR Enabled (Floating IP)
I created the "Dummy VIP" on each device and assigned the Irule.
The problem is that on each device, the self ip answers.
Therefore, the ALB sends on both members of the cluster and not only on the active member.
Thank you for the easy to understand explanation.
Please tell me about "HA Using ALB for Failover with DSR Enabled (Floating IP)".
I also read your article below.
"F5 High Availability - Public Cloud Guidance"
https://community.f5.com/t5/technical-articles/f5-high-availability-public-cloud-guidance/ta-p/28438...
Please tell me about "HA Using ALB for Failover with DSR Enabled (Floating IP)".
For ALB for Failover with DSR Enabled (Floating IP) configuration,
When BIG-IP is in Active-Active configuration, can traffic from ALB be session-maintained?
Will ALB be round-robined to Active-BIG-IP#1 and Active-BIGIP#2?
I want to session persitence.(From ALB to Bigip)
You will need to choose the correct affinity at the Azure LB side to maintain persistence when BIG-IP is active-active. Affinity is a separate LB setting from DSR floating IP. As for round-robin, Azure LB by default uses hash which sends to any healthy node. There is no typical round-robin. To stick to a certain BIG-IP, the source affinity will be required.
"The hash is used to route traffic to healthy backend instances within the backend pool. The algorithm provides stickiness only within a transport session. When the client starts a new session from the same source IP, the source port changes and causes the traffic to go to a different backend instance."
https://learn.microsoft.com/en-us/azure/load-balancer/distribution-mode-concepts
By default, Azure Load Balancer uses a five-tuple hash.
The five tuple includes: