Forum Discussion

vytbr2's avatar
vytbr2
Icon for Altostratus rankAltostratus
Feb 01, 2023

Automating via BIG-IQ vs. BIG-IP direct configuration

Hello, 

I'm a bit puzzled with the architectural intention of central management through BIG-IQ platform from the perspective of automating the multi-Load-balancer configuration (system parameters AND services).

1. Some properties of BIG-IQ (such as it synchronizing with the BIG-IP nodes and being able to populate their settings centrally) seem to indicate, that it is the central point of policy definition and application, which in turn would suggest that any config to BIG-IP systems should be defined and applied via the BIG-IQ CM node.

2. On the other hand, when looking at the config backup content, I can't find any service objects in the CM itself, but rather all the configuration policy is distributed and is present directly in corresponding managed BIG-IP devices. This leads me into looking at BIG-IQ as more of an orchestrator - easing the pushing of config policy to multiple nodes and providing the overall visibility on the service state instead of being a true aggregator of all intended configuration policy. This Orchestrator-like "vibe" is further strenghened when I check out the f5networks.f5_modules collection in ansible, which seemingly is mostly adapted to pushing config directly to BIG-IP (avoiding BIG-IQ alltogether).

I'm currently building the ansible code, which has to build and configure a group of BIG-IP node clusters together with a BIG-IQ CM cluster. My question then is: should I strive for configuring as much as possible through the BIG-IQ (as would be true in scenario 1, despite it means NOT using ansible f5networks collection) or I should just configure my BIG-IPs and then resync their config with BIG-IQ afterwards (as would make much more sense in scenario 2 given the existing ansible code is targeting BIG-IPs directly)?

thanks,

Vytautas

application delivery
  • Paulius's avatar
    Paulius
    Feb 01, 2023

    vytbr2 From what I have seen and experienced you are correct in your conclusions. As far as backups are concerned the only piece that will suffice as a backup is running a backup on the BIG-IQ which is usually a scheduled task and in that task you can also copy the backup to another device such as backup server for long term storage and even configure a setting to delete over a certain amount of backups off of the BIG-IQ. Now you to retain a certain amount of configuration on the BIG-IQ for the BIG-IPs that it manages but nothing that can be used to restore a deleted or failed device. If you had a replacement device and you configured everything on it so it would be accessible the remainder of the configuration such as virtual servers, pools, monitors, and other LTM functions those would sync back to the BIG-IP provide the device is named the same.

  • Paulius's avatar
    Paulius
    Icon for MVP rankMVP
    Feb 01, 2023

    vytbr2 Based on all the documentation that I have found and my experience with the BIG-IQ I would say for initial configuration and massive amounts of changes should be done on the BIG-IP and then synced to the BIG-IQ because certain sub-configuration settings are not visible on the BIG-IQ. An example of one setting that I know off the top of my head is when enabling LACP on an F5 trunk you can only see and configure this setting on the BIG-IP even though the BIG-IQ has to be aware of this because when I sync to the BIG-IQ from the BIG-IP the setting doesn't become disable even though I cannot see the setting as being configured in the GUI of the BIG-IQ. In addition to this the CLI of the BIG-IQ does not allow you to manipulate about 99% of BIG-IQ configuration and is only done through the GUI. On top of this some configuraiton is shared between all devices such as health monitors so if you have profiles named the same but they have slightly different settings you will want to differentiate those names in some way, an example might be MON_example.com_http_QA and MON_example.com_http_PROD otherwise if the name is MON_example.com_http they will appear as just that in the BIG-IQ. I have found that the BIG-IQ is great for the following.

    1. Changing Users if they are the same on all devices, such as root and admin users.
    2. Updating shared configuration on all devices, such as monitors, SSL certificates, and more. These must be identical or this one isn't valid.
    3. Mass code upgrades. This allows you to compare configuration before and after the upgrade.
    4. Mass backups and export of those backups to a backup server for long term storage. This allows you to compare configuration changes across multiple backups as long as the backup is on the BIG-IQ.
    5. Looking at device status for standalone and HA devices.
    6. Consolidated area for logs and statistics, assuming you have DCD as well.
    7. Licensing of devices, provided you received the licenses and they weren't installed directly on the BIG-IPs.

    I might have missed something in this list because I haven't had a large amount of experience with the BIG-IQ but from the experience that I do have this is my stance. To be honest just having the passwords, code upgrades, and backups seems worth it to me unless you have some home grown software that will do this for you without issues.

    • vytbr2's avatar
      vytbr2
      Icon for Altostratus rankAltostratus
      Feb 01, 2023

      Hi Paulius,

        thanks for your comprehensive answer. Please correct me if I missunderstood something, but by reading your response I'm leaning towards the following conclusions:

      1. BIG-IQ is best when you need to work with multiple devices manually (meaning by using GUI or CLI as opposed to automated scripts)

      2. BIG-IQ is not supporting ALL config optoins available at BIG-IPs (in addition to your example with with LACP I believe I saw a KB article, which mentions creating new partitions is only possible from within BIG-IP)

      3. As per the above and given I'm not looking to reduce manual efforts (because I'm automating and  a "computer" would do all the work for me) - I'm better off dealing with pre-configuring BIG-IPs directly and then syncing their settings to BIG-IQ.

      Let me know if you agree with my reasoning or have any additional thoughts.

      Also, based on your experience - is the configuration of the BIG-IP saved in BIG-IQ anywhere after I have synced the config? I guess the config would be saved if I initiate a backup of BIG-IP devices from within BIG-IQ, but that's a different story. In other words - if I were to pre-configure a virtual BIG-IP, sync it to BIG-IQ and then remove the BIG-IP VM, would BIG-IQ retain all the config objects it synced from that BIG-IP even if it no longer exists?

      thanks,

      Vytautas

      • Paulius's avatar
        Paulius
        Icon for MVP rankMVP
        Feb 01, 2023

        vytbr2 From what I have seen and experienced you are correct in your conclusions. As far as backups are concerned the only piece that will suffice as a backup is running a backup on the BIG-IQ which is usually a scheduled task and in that task you can also copy the backup to another device such as backup server for long term storage and even configure a setting to delete over a certain amount of backups off of the BIG-IQ. Now you to retain a certain amount of configuration on the BIG-IQ for the BIG-IPs that it manages but nothing that can be used to restore a deleted or failed device. If you had a replacement device and you configured everything on it so it would be accessible the remainder of the configuration such as virtual servers, pools, monitors, and other LTM functions those would sync back to the BIG-IP provide the device is named the same.