Standby APIC - Replacement

[udo.konstantin]

Hello,

we have the following scenario in our Multi-Pod Testlab.

Pod 1: APIC1 IP 10.1.1.1/24 active

Pod 1: APIC2 IP 10.1.1.2/24 active 

Pod 1: APIC3 IP 10.1.1.3/24 active

Pod 2: APIC4 IP 10.1.1.4/24 standby

For testpurpose I replace APIC 2 with the standby. So APIC 4 takes over the role of APIC 2. 

"Cluster as seen by node" shows the new one with the name of the Standby. 

How can we restore the old situation? Should we decommission the APIC 2 (was standby APIC), reset it and configure it again as standby?

Thanks 

Udo 

Ud 

[RedNectar · Accepted solution]

Hi @udo.konstantin ,

I've let this one sit for a while thinking someone more knowledgeable than me might answer it - and to be honest I've never actually done this, but I believe that once you have have promoted the standby APIC to APIC2, then the old APIC2 becomes the standby.

At this point you are exactly where you started - with 3 active APICs and one Standby.

The process for bringing the Standby to Active is EXACTLY the same as the first time.

 If it works, let me know, because I'm not 100% sure having never actually done it. (I'm not a big fan of the Standby APIC idea.)

[Robert Burns · Accepted solution]

When you promote a Standby to Active it completely replaces the instance of the original APIC in all ways.  After decommissioning the original APIC, you can promote a standby to replace it.   At this point if you wanted to re-use the decommissioned APIC as your new standby, you'd need to first wipe the config on that APIC (acidiag touch clean && acidiag touch setup), and reconfigure it with standby role.  To reverse your testing scenario you'd have to repeat the scenario.  Decommission (new) APIC2, promote standby to Active and replace it, then re-wipe the decommissioned APIC, and bring it back up again as standby role. 

I would question why you'd want a standby APIC in your second POD when all other APICs reside in Pod1.  The goal of having a standby APIC is to be able to quickly restore the cluster redundancy to a fully fit state in the event of a device failure.  For this I'd want the cluster APICs to be as reachable as possible at all time.  There's no value I can see having the standby APIC (alone) in Pod2.  Should you lose the IPN for any reason you'd have no way to even sync it up with the other APICs in Pod1, so the end result is you'd never be able to promote it (even if only to come up alone as R/O).  You should also host the standby APIC in the Pod where the majority of your controllers reside.

Robert