Modernizing F5 BIG-IP Synchronized HA Pairs with Ansible Validated Content

I wanted to provide an update to a previous article I released a few months ago where we developed Ansible Automation Platform code to help with migrating Standalone Legacy platforms (non-iSeries, iSeries and Viprion Instances) to our Modern Architectures (rSeries and Velos) using F5OS Tenant instances.

I am happy to announce that the code for Synchronized HA pairs has been completed, and we have uploaded it to Ansible Automation Hub as Validated Content. 

 

What is Ansible Automation Hub Validated Content?

Ansible validated content collections contain pre-built YAML content (such as playbooks or roles) to address the most common automation use cases. You can use Ansible validated content out-of-the-box or as a learning opportunity to develop your skills. It's a trusted starting point to bootstrap your automation: use it, customize it, and learn from it.

Due to the focus on customization and the intent for this content to be modified, it is not subject to the same support requirements as our certified collections. To this end, any issues with this content should be filed directly at the source repository for that collection.

Why Synchronized HA Pairs?

This is a very common use case for a lot of our customers who want resiliency and redundancy, especially for their applications and services.  The biggest issue with migrating an HA Pair is that because of the way they are set up, things like Management IP Addresses and Master Keys are essential to the transition process.

Even mismatched versions during upgrades cannot synchronize during the process of upgrading to major/minor releases.

 

What does the updated Validated Code do?

• Standalone Migrations – Where you can change the Management IP, due to the nature of being a standalone device, an outage will occur during the transition period.
  • o   There are 2 options for Playbooks
    • Single Playbook for the full migration
    • 2 Parts where
      • Part 1 – Does backups and does a big start stop of the unit
      • Part 2 – Migrates the standalone device

• HA Pairs – Combined – This code is designed for a customer who just needs to transition both HA Units but isn’t concerned about an outage window. It will migrate both units at the same time to F5OS Tenants.
  • The Playbooks for this Code are broken apart in specific areas
    • Part 1 – Backup the Information
    • Part 2 – Ensure Both Units are offline and Migrate both units at the same time.

• HA Pairs – Sequential – This code is designed for customers who need to migrate one unit at a time and maintain availability of their applications.
  • It will migrate the Standby Unit first as part of the code
  • When ready to transition the active unit, it will place it in Standby and make the Transitioned Standby unit the Active Node transferring services to it
  • Then the previously Active Unit (now standby) will be migrated
  • There are playbooks to the Code to break apart specific areas of the transition
    • Part 1 – Backup the Information
    • Part 2 – Ensure the Standby Devices are offline (via Management IP) and Migrate the Standby Unit
    • Part 3 – Transition the Standby to become the Active Unit and Begin Transitioning the New Standby Unit (Previously Active Unit) similarly to Part 2

This code has been tested and validated against many different platforms, and there are plans to continue testing for other use cases.  The Transition can be Like-for-Like versioning (i.e. 16.1.x to 16.1.x) within the same family tree or can be an upgrade at the same time (i.e. 15.1.10 à 17.5.1.3 or even 21.0.0) 

These are Ansible Playbooks with supporting roles tailored for Red Hat Ansible Automation Platform. It’s built to perform a lift-and-shift migration of a F5 BIG-IP configuration from one device to another—with optional OS upgrades included.

 

What is the future of the code?

I plan on adding some Validation code to separate roles/playbooks so customers could have points of references for testing, i.e. (ping tests and pool tests) before and after the transition, QKView Backups, and other information provided on the state of the unit prior to transition to ensure when migrated it can be validated that everything is the way it was.

 

Notes about the Code

• The code is not designed to handle Non-VLANed infrastructure (F5OS is designed to be multi-tenant and setup with VLANs to deal with Multi-Tenancy) If your BIG-IPs use Untagged networks, they will need to be migrated to VLANed prior to using this code.
• Has not been validated/tested with FIPS-based environments
• Has not been validated/tested F5 DNS environments – Coming Soon
• HA Pairs must retain the Management IP address from source to destination; the code will ensure that the source device is powered off prior to transitioning it.

 

Cool Additions

• Override variables are allowed as extra_vars to create flexibility in your deployment
  • override_cpu - This allows you to set the CPUs of the Tenant OS. If the memory override isn’t set, it will be set to the same formula that the F5OS Gui would calculate.
    DEFAULT is set to 4 CPU
    
    
  • override_disk_size - This allows you to set the Disk Space of the Tenant OS.
    DEFAULT is set to 120GB
    
    
  • override_memory - This allows you to set the Memory of the Tenant OS. Be warned if over-provisioned, the Tenant may not start. 
    DEFAULT is calculated by the CPU counts formula used in the GUI.
    
    
  • tenant_nodes - This allows you to set the slot for the Tenant OS if there are multiple slots associated with your F5OS Partition. 
    DEFAULT is an array object and it is set to [1]
    
    
  • cryptos - This allows you to set the Crypto on the Tenant OS to either enabled or disabled. 
    DEFAULT is set to enabled
• 

   

• Variables for deployments – the code is designed to utilize specific hostnames and group names to execute the code. These variables allow connectivity to BIGIP and F5OS Tenants. When creating these hosts, you will need to provide
  • When creating hosts in AAP, you will need to provide the following information
    • ansible_host: - This is the IP Address of the device of the host
    • ansible_user: - This is the username to login to the device
    • ansible_password: - this is the password to login to the device; if using a credential in AAP, you would associate that variables information here as a reference. i.e.
      
      
  • Standalone deployments
    • host_vars
      • f5_destination_partition – This is the F5OS Partition information
      • f5_destination_tenant – This is the F5OS Tenant information
      • f5_source – This is the source device
  • HA Pair Deployments
    • group_vars
      • ha_pair_destination_chassis – contains a group of 2 hosts for the destination tenants to be deployed to (can be 2 hosts with the same information or different)
      • ha_pair_source – contains a group of 2 hosts for the source BIG-IP Devices in a synchronized HA Pair.
      • ha_pair_source_dynamic - this group is created automatically throughout the code to program the new Tenant OSes after deployment 
        (DOES NOT NEED TO BE CREATED)
• 

   

Demos/Information

We have uploaded a new demo video below, you’ll see an migration of a synchronized HA Pair of BIG-IPs running as Viprion Tenants on F5 B2250 Blades running 15.1.10 transitioning to a pair of rSeries R5800s Tenant OSs running 17.5.1.x — demonstrating a smooth modernization process.

Watch the synchronized HA migration Demo Video

 

 

If you want to check out the information and demo video on the Standalone migrations, check out my other article at – 
Modernizing F5 Platforms with Ansible | DevCentral

 

You can access the validated content via Ansible Automation Hub (Need Red Hat Account with AAP)

https://console.redhat.com/ansible/automation-hub/repo/validated/f5networks/f5_platform_modernization/ 

Or you can access the direct code from our GitHub Repository
https://github.com/f5devcentral/f5-bd-ansible-platform-modernization

This project is built for the community/partners/system integrators — so as I always say, feel free to take it, fork it, and expand it. Let’s make F5 platform modernization as seamless and automated as possible!