Forum Discussion
vytbr2
Altostratus
AltostratusAutomating 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 A...
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
MVP
MVPvytbr2 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.
vytbr2Hi 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
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.