UCS manager runs on UCS 6100 series fabric interconnects and is used to manage and configure the entire UCS system. The UCS manager High Availability (HA) architecture works when two UCS 6100 series fabric interconnects are connected as cluster peers. In such a case two instances of UCS manager are running on two fabric interconnects. The UCS manager instances communicate over the dual cluster links between the two fabric interconnects.
The UCS manager uses active/standby architecture, in which the active instance is called primary and the standby instance is called subordinate. All communication with the external world is handled by the primary instance which maintains the main configuration database. The main configuration database is stored on the primary and replicated on the subordinate. The primary sends updates to the subordinate when configuration changes occur.
High Availability architecture details
Both of the fabric interconnects have private static IP address configured. However they share a virtual IP address and this IP address is always associated with the fabric interconnect running the primary instance of UCS manager. The two UCS manager instances keep themselves aware of each other by heart-beat message exchanges. When both of the fabric interconnects in cluster are running, the copies of configuration database on them are kept in sync.
How It Works
The two instances of Cisco UCS Manager communicate across a private network between the L1 and L2 Ethernet ports on the fabric interconnects. Configuration and status information is communicated across this private network to ensure that all management information is replicated. This ongoing communication ensures that the management information for Cisco UCS persists even if the primary fabric interconnect fails. In addition, the "floating" management IP address that runs on the primary Cisco UCS Manager ensures a smooth transition in the event of a failover to the subordinate fabric interconnect.
In the situation when the fabric interconnect running primary instance fails, the subordinate fabric interconnect takes the role of primary. If some configuration changes are made on this fabric interconnect they will not get updated on the failed fabric interconnect. If for some reason this fabric interconnect also fails and the first failed fabric interconnect comes up, it will have the old copy of the configuration database. In such cases the active fabric interconnect will first check the configuration database version number of the other fabric interconnect stored in the blade chassis in a shared area. If the other fabric interconnect’s configuration database version number is higher it means that the other fabric interconnect has a more recent configuration. The active fabric interconnect stops loading and waits for administrator’s input.
Similarly in the case when the communication links between two fabric interconnects fail, the fabric interconnects use the blade chassis for communicating the heart-beat. If the fabric interconnects receive proper heart-beat then the primary stays as primary and the subordinate stays as subordinate and the system enters Link-Failed state. However in this scenario only heart-beats can be exchanged and any update to the configuration database will not get reflected on the subordinate.
I found two different theory to handle l3 traffic for unknown IP in ACI one is stated below which is from White Paper 739989 and in other cisco live document I have seen that this will be treated via spine proxy method. "For (L3) routed traffic to an...
I found below note in cisco white paper i.e 739989 - end point learning but unable to understand it. "An exception exists for remote MAC address learning when a packet is incoming from L3Out to Cisco ACI. If ARP traffic is coming from an L3Out SVI ra...
Dears ,Please check as the ACI sandbox does not accept any simple action on it from yesterday ? even creation of a tenant returns "Error: 400 - the messaging layer was unable to deliver the stimulus (connection error, Connection refused)"
Our DX80 is connected to the corp network, we use for video conf and also to display screen contents via HDMI connection to a laptop. When both are in progress, the call controls constantly flash as if the screen was being constantly touched, so oft...
Hello:i have this problem: i connected a dell tape library tl2000 to my switch cisco nexus 5548 via fiber channel, i need the tape library to be recognized by a server who has Veeam software running, this server is also connected to the cisco nexus the se...