Nimbostratus
NimbostratusDon't upgrade for the sake of upgrading. Unless you really enjoy lots of free time right now. Normally, to upgrade, you must have a reason. Do you have a stability or security problem with your current version? Fancy try out a new feature you saw in release notes? If not, there's nothing wrong with sticking to 11.5.4 for another year.
If you insist on upgrading, current conservative LTS pick is v12.1.3. If you prefer not upgrade BigIP to a new major release more than once per 2 years, going with the latest 13.1.0.1 LTS release could be the better option. It's cutting edge with a slightly higher risk on stability. I'd still wait until it's at least a month old before putting it on a production system.
NimbostratusDear Hannes Rapp, Thank you very much for Answer.
What is the best practice to upgrade the IOS in HA mode?
what will be the effect on running production in case of the upgrade?
NimbostratusYou set one appliance in your cluster to "ForcedOffline" status while it's being upgraded. When done, you perform a network failover and repeat the upgrade on other unit.
Before you upgrade the second unit, you ask application specialists and other stakeholders to verify if services work as intended with new BigIP version active. You also do your own due diligence, i.e. monitoring /var/log/ltm to swiftly spot any errors and address them on the go. In ideal conditions, the impact of a major upgrade is a session disruption during cluster failover (SSL/TLS sessions may break). Depending on applications, this may mean clients have to re-login and that's about it (impact of a few seconds). In a more stressful scenario, some applications may require cold server reboots to restore services. If all is well coordinated, first server should be available within 10-20 minutes.
With that said, major upgrades are major projects. The more modules you have, the more problems you will face. Most problems are configuration load errors that do not cause an impact on production. Worst-case impact includes subtle problems that are not obvious. I.e. silently changed values in vendor default profiles may show first signs of negative impact hours or even days after the upgrade itself is already completed. It takes a seasoned BigIP upgrade expert to pull off a major software upgrade with less than 10 minutes of downtime or notable service degradation.
If it's your first time, and you have at least 2 active BigIP modules or 50 Virtual Servers in LTM-only setup, assume the following. 30 mins full downtime for at least 1 service, 1 hour service degradation for at least 1 service, and 2 days of your own time to troubleshoot configuration load errors.
It would help if you have a place to emulate your upgrade, a BigIP lab