Forum Discussion

brad_11480's avatar
Icon for Nimbostratus rankNimbostratus
Feb 07, 2011

Standalone to HA active/passive pair - best practices?

I currently have a standalone LTM/ASM and want to make it high available so will be adding a second box.



Wondering if there is an established procedure to accomplish this. Would like to add it without interruption to the existing traffic, if possible. Otherwise with minimal disruption.



If so, I'd appreciate any references/information that are known. Hoping to make this as transparent and painless as possible.



I'm not sure the signficance of the VIP and IP's of each member box. From the perspective of the applications, they will see a slight change where the health polls will come from the member IP and the traffic from the VIP.



A question in this regard is what IP should become the VIP. Use the current IP of the standalone box, or leave the standalone box IP as is and make the VIP another IP on the subnet?



I know that I have to activiate the HA before I can make any of this work.



Right now the second box is basically configured and loaded with the same configuration as the existing standalone box (it could be swapped in as a replacement if that box failed). I can bring this up off-net and setup the HA information in it so that it can join up as a standby, if that is a good approach.



Thanks for any information.

2 Replies

  • Hi Brad,



    You can steal some steps from SOL8086:



    SOL8086: Replacing a BIG-IP system in a redundant pair without interrupting service







    The virtual server addresses on the existing active unit should not need to be changed. You can set the unit to a member of an active/standby pair under System | Platform. You can then add floating self IP addresses on any VLAN that will be used to accept routed traffic on.



    Then for the new unit:



    Connect the hardwire failover cable to the new unit.


    Connect the mgmt cable to the new unit.


    Power it up.


    Run the config script from the CLI to set the hostname and management IP.


    Once you can connect via the GUI, you can configure the base config (VLANs, static self IPs, etc).



    You can then copy a UCS from the existing unit to the new one via the management port and load it (b config save my.ucs / b config install my.ucs). Only the shared config should load. Once that completes successfully, you can plug in the network cables. Make sure the new unit can successfully monitor the pool members (ie, there aren't any firewall rules which need to be changed) before making it active. During a maintenance window, you can fail over to the new unit and test major functionality through the unit.



    F5 Support should be able to confirm these steps.



  • Thank you for this great information. My SE also provided another reference in solution 8581, so mashing them together I end up with a couple of questions.





    1. is a reboot required when changing the existing standalone unit to "Redundant Pair" in the High Availlability setting in the System>Platform, probably after the floating IP is added?


    2. the solution indicated that the existing interface IP should be moved to be the floating IP address shared between the units. The reason provided in the solution is that "this eliminates the need to modify the upstream router or downstream nodes". Unless it is for ARP or something similar, I don't think that the router nor other systems really look at the IP of the F5. I guess if a reboot is necessary in step 1 it doesn't make much difference.



    My goal is to change from standalone to high available with this node as the primary/active node without interruption to services. Then to add the new secondary pair member. Note that this system is a '1-arm' and all services use SNAT (it is not a default gateway).



    The procedure you provided seems to indicate that may very well be possible but there is a difference in the approach taken with the solution 8581 in regard to the floating address and need to reboot and failover a couple of times. I do agree that once this is in place that I will want to test the configuration synchronization and failover between the units.



    Thanks again for your insight and advice.