Forum Discussion
4 Replies
- F5_JeffCirrus
yes. you may reboot the standby BIGIP first. and when the reboot is successful, you may failover the active one and repeat rebooting.
- Vijay_ECirrus
I am assuming you want to reboot in order to upgrade code - is this right ?
Normally, this sequence would be of help:
- Reboot secondary
- Failover from active to secondary.
- Reboot current secondary.
- If need be, you can fail back to the original active device (current standby).
It is important to know that the sequence of reboot/failover events will minimise the downtime but not completely remove it. You should perform the steps under a maintenance window and prepare for downtime of about 1 minute when failing between the devices. The actual duration could be higher depending on features like persistence, mirroring and the robustness of your application to recover from packet loss that will occur during failover.
- IainThomson85_1Cumulonimbus
It's also worth noting above - To give your business full confidence of the procedure. You may wish to conduct a "Failover" without the reboots prior to the main event. I.e.
Failover from Active to Standby Test applications (Buisness Critical) for a good period. Failover from Active to Standby again.
I've known scenarios in the past where the standby box self IP's for health monitoring haven't been added to internal firewalls etc, which may only manifest when in a failover scenario.
It's also an opportunity to test how the applications behave, as a fallback is a lot faster to resolve than waiting for a box to fully come back up.
Hi
Try to keep parallel root CLI sessions open for both F5 boxes. Do a "tail -f /var/log/ltm" to see the sequence of events.