Guidelines and Limitations for Warm Standby Cisco APICs

Follow these requirements when configuring and managing Warm Standby Cisco APICs:

• In Cisco APIC 6.1(2), a warm standby APIC supported APIC clusters only on physical APIC nodes. Beginning with Cisco APIC 6.1(3), standby APICs for APIC clusters with virtual nodes are also supported. Standby APICs must be of the same form factor (physical or virtual) as the active APICs in the cluster.

  A Warm Standby APIC is supported for both types of APIC connectivity – directly attached and remotely attached via a L3 network.

• Before Cisco APIC release 6.2(1), you could configure only one type of standby APIC—either cold or warm—per cluster. Cold and warm standby APICs could not coexist in the same cluster, and you had to set or modify the standby type before or after adding standby nodes.

  Starting with Cisco APIC release 6.2(1), only the warm standby controller type is supported. Cold standby controllers are deprecated and are not available in this or later releases.

• Limit the number of Warm Standby APIC nodes to a maximum of three per cluster.

  Do not change the standby APIC type to Warm if four or more Cold Standby APIC nodes exist in the cluster.

  In Cisco ACI 6.2(1) and later, upgrading fails if more than three cold standby nodes are present. Reduce the number of standby nodes to three before upgrading; these nodes are converted to warm standby by default during the upgrade.

• Disaster recovery with Warm Standby APIC to rebuild the entire cluster is allowed only when there is data loss in the cluster, in other words only when three or more active APIC nodes are lost and as a result all three replicas of some shard are lost forever.

• When three or more active APICs are lost temporarily because of a network issue in the Inter-Pod Network (IPN), you should not promote the Warm Standby APIC node to APIC 1 as you must initialize all other APICs and rebuild the cluster even when the APIC nodes are healthy in each pod.

• You must change the Standby APIC Type of the cluster to Cold before you downgrade to a version older than 6.1(2) that does not support the Warm Standby APIC.

  Prior to Cisco APIC 6.1(2) which only had the Cold Standby APIC, the upgrade (or downgrade) of standby APIC nodes was not visible. You did not have to wait before you proceeded with a switch upgrade. The standby APIC nodes were initialized and booted up with a new version after the APIC upgrade for the active nodes were completed.

  Starting from Cisco APIC 6.1(2), the APIC upgrade process may take a little longer than before when there are standby APIC nodes. The upgrade process explicitly includes standby APIC nodes for both Warm and Cold Standby APICs. This is to ensure that the database is backed up in the Warm Standby APIC and is updated to match the new version models. Although, the Cold Standby APIC does not contain any data to be updated, the same process is applied to the Cold Standby APIC, but this process completes much faster than the Warm Standby APIC.

• You can delete a Standby node from the cluster. Refer to Delete a standby from the cluster for more information.

• If any switch is unavailable during disaster recovery due to reboot, interface down, process crash, power failure etc., then Cisco recommends you do a clean reboot and rediscover the switch back into fabric.

• If a Cisco APIC cluster is running in Strict mode on Cisco APIC 6.1(2) or later and the switches are running versions earlier than Cisco APIC 6.1(1), disaster recovery operations fail. The cluster must be switched to Permissive mode before performing disaster recovery.