The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter contains the following sections:
Information About System-Level High Availability
The Cisco Nexus 1000V can be configured with a single Virtual Supervisor Module (VSM) or dual VSMs. The following table describes the HA supervisor roles for single and dual VSM operation.
The redundancy role indicates not only whether the VSM interacts with other VSMs, but also the module number it occupies. The following table shows the available HA roles for VSMs.
Independent of its role, the redundancy state of a VSM can be one of the following described in this table.
Redundancy State |
Description |
---|---|
Active |
Controls the system and is visible to the outside world. |
Standby |
Synchronizes its configuration with that of the active VSM so that it is continuously ready to take over in case of a failure or manual switchover. You cannot use Telnet or Secure Shell (SSH) protocols to communicate with the standby VSM. Instead, you can use the attach module command from the active VSM to access the standby VSM console. Only a subset of the CLI commands are available from the standby VSM console. |
The active and standby VSMs are in the operationally HA state and can automatically synchronize when the internal state of one supervisor module is Active with HA Standby and the internal state of the other supervisor module is HA Standby.
If the output of the show system redundancy command indicates that the operational redundancy mode of the active VSM is None, the active and standby VSMs are not yet synchronized. This example shows the VSM internal state of dual supervisors as observed in the output of the show system redundancy status command:
switch# show system redundancy status Redundancy role --------------- administrative: standalone operational: standalone Redundancy mode --------------- administrative: HA operational: None This supervisor (sup-1) ----------------------- Redundancy state: Active Supervisor state: Active Internal state: Active with no standby Other supervisor (sup-2) ------------------------ Redundancy state: Not present switch#
Information About VSM Restarts and Switchovers
In a system with only one supervisor, when all HA policies have been unsuccessful in restarting a service, the supervisor restarts. The supervisor and all services restart with no prior state information.
When a VSM fails in a system with dual supervisors, the system performs a switchover rather than a system restart in order to maintain a stateful operation. In some cases, a switchover might not be possible at the time of the failure. For example, if the standby VSM is not in a stable standby state, a restart rather than a switchover is performed.
A dual VSM configuration allows uninterrupted traffic forwarding with a stateful switchover (SSO) when a failure occurs in the VSM. The two VSMs operate in an active/standby capacity in which only one is active at any given time, while the other acts as a standby backup. The two VSMs constantly synchronize the state and configuration to provide a seamless and stateful switchover of most services if the active VSM fails.
A switchover occurs when the active supervisor fails (for example, if repeated failures occur in an essential service or if the system that is hosting the VSM fails).
A user-triggered switchover could occur (for example, if you need to perform maintenance tasks on the system hosting the active VSM).
An HA switchover has the following characteristics:
When a stable standby VSM detects that the active VSM has failed, it initiates a switchover and transitions to active. When a switchover begins, another switchover cannot be started until a stable standby VSM is available.
If a standby VSM that is not stable detects that the active VSM has failed, then, instead of initiating a switchover, it tries to restart the system.
Before you can initiate a manual switchover from the active to the standby VSM, the standby VSM must be stable.
Once you have verified that the standby VSM is stable, you can manually initiate a switchover.
Once a switchover process begins, another switchover process cannot be started until a stable standby VSM is available.
Although primary and secondary VSMs can reside in the same host, to improve redundancy, install them in separate hosts and, if possible, connect the VSMs to different upstream switches.
The console for the standby VSM is available by entering the module attach x command, but configuration is not allowed and many commands are restricted. Enter this command at the console of the active VSM.
You cannot use Telnet or Secure Shell (SSH) protocols to communicate with the standby VSM because the management interface IP is unconfigured until the VSM becomes active.
Instead, you can use the following methods:
Virtual Network Computing (VNC) . Use the port 5901 and the host node's management IP to connect to the VSM VM.
The virsh console VSM_VM_domain_name command from the server console that is hosting the VSM VM.
A tool similar to virt-manager on the server that is hosting the VSM virtual machines. With this tool, you can use a GUI interface to login to the VSM virtual machines and then execute the commands for setting the redundancy role.
The active and standby VSMs must be on the same management subnet.
This procedure powers on the Virtual Supervisor Module (VSM) virtual machine (VM).
Before beginning this procedure, you must be logged in to the CLI in EXEC mode.
Command or Action | Purpose |
---|
This example shows how to power on the VSM VM:
# ssh 192.0.2.0 switch# virsh list --all switch# virsh start vm1 Domain vm1 started switch#
This procedure powers off the Virtual Supervisor Module (VSM) virtual machine (VM).
Before beginning this procedure, you must be logged in to the CLI in EXEC mode.
Command or Action | Purpose |
---|
This example shows how to power off the VSM VM:
# ssh 192.0.2.0 switch# virsh list switch# virsh destroy vm1 Domain vm1 destroyed switch#
Configuring System-Level High Availability
The Cisco Nexus 1000V VSM software installation provides an opportunity for you to designate the role for each VSM. You can use this procedure to change that initial configuration.
Caution | Changing the role of a VSM can result in a conflict between the VSM pair. If a primary and secondary VSM see each other as active at the same time, the system resolves this problem as described in Split-Brain Resolution. |
Use this procedure to change the role of a VSM to one of the following after it is already in service:
Before beginning this procedure, you must be logged in to the CLI in EXEC mode.
If you are changing a standalone VSM to a secondary VSM, be sure to first isolate it from the other VSM in the pair to prevent any interaction with the primary VSM during the change. Power the VM off before reconnecting it as standby. See Powering Off the VSM VM for more information.
You must understand the following information:
The possible HA roles are standalone, primary, and secondary.
The possible HA redundancy states are active and standby.
To activate a change from primary to secondary VSM, you must reload the VSM by doing one of the following:
Enter the reload command.
Power the VM off and then on. See Powering Off the VSM VM and Powering On the VSM VM for more information.
A change from a standalone to a primary VSM takes effect immediately.
This example shows how to change the VSM role:
switch# system redundancy role standalone switch# show system redundancy status Redundancy role --------------- administrative: standalone operational: standalone Redundancy mode --------------- administrative: HA operational: None This supervisor (sup-1) ----------------------- Redundancy state: Active Supervisor state: Active Internal state:Active with no standby Other supervisor (sup-2) ------------------------ Redundancy state: Not present switch#
Configuring a Switchover
Use one of the following commands to verify the configuration:
Command |
Purpose |
---|---|
show system redundancy status |
Displays the current redundancy status for the VSM(s). If the output indicates the following, you can proceed with a system switchover: |
show module |
Displays information about all available VEMs and VSMs in the system. If the output indicates the following, you can proceed with a system switchover: |
Be sure you know the following about manually switching the active VSM to a standby VSM:
A switchover can be performed only when two VSMs are functioning in the switch.
If the standby VSM is not in a stable state (ha-standby), you cannot initiate a manual switchover and will see the following error message:
Failed to switchover (standby not ready to takeover in vdc 1)
If a switchover does not complete successfully within 28 seconds, the supervisors reset.
Log in to the active VSM CLI in EXEC mode.
Complete the steps in "Verifying that a System is Ready for a Switchover" and verify that the system is ready for a switchover.
This example shows how to switch an active VSM to the standby VSM and displays the output that appears on the standby VSM as it becomes the active VSM:
switch# system switchover ---------------------------- 2009 Mar 31 04:21:56 n1000v %$ VDC-1 %$ %SYSMGR-2-HASWITCHOVER_PRE_START: This supervisor is becoming active (pre-start phase). 2009 Mar 31 04:21:56 n1000v %$ VDC-1 %$ %SYSMGR-2-HASWITCHOVER_START: This supervisor is becoming active. 2009 Mar 31 04:21:57 n1000v %$ VDC-1 %$ %SYSMGR-2-SWITCHOVER_OVER: Switchover completed. 2009 Mar 31 04:22:03 n1000v %$ VDC-1 %$ %PLATFORM-2-MOD_REMOVE: Module 1 removed (Serial number )
This example shows how to display the difference between the running and startup configurations:
switch# show running-config diff *** Startup-config --- Running-config *************** *** 180,189 **** --- 179,190 ---- inherit port-profile bundle-uplink no shutdown interface Ethernet3/2 inherit port-profile bundle-uplink + + interface control0 clock summer-time EDT 2 Sun Mar 02:00 1 Sun Nov 02:00 60 line console line vty boot kickstart bootflash:/nexus-1000v-sk-upgrade-kickstart.5.2.1.SK1.2.0.437.gbin.upg sup-1 boot system bootflash:/nexus-1000v-sk-upgrade.5.2.1.SK1.2.0.437.gbin.upg sup-1 switch#
If the communication network between two VSMs in an HA pair experiences interruptions longer than the 15-second default, you can change the VSM-to-VSM heartbeat interval so that it is less sensitive to falsely detecting active VSM failures.
switch# configure terminal switch(config)# system inter-sup-heartbeat time 10 switch(config)# show running-config | grep heartbeat system inter-sup-heartbeat time 10 switch(config)# copy running-config startup-config
Adding a Second VSM to a Standalone System
Although primary and secondary VSMs can reside in the same host, to improve redundancy, install them in separate hosts and, if possible, connect them to different upstream switches.
When you install the second VSM, assign the secondary role to it.
The secondary VSM needs to have its control, management, and packet network interfaces in the same VLANs as the primary VSM.
To add a secondary VSM to the standalone VSM, convert the standalone VSM to a primary VSM.
After the secondary VSM is installed, the following occurs automatically:
You can change the role of a VSM from standalone in a single VSM system to primary in a dual VSM system.
A change from a standalone to a primary VSM takes effect immediately.
Log in to the CLI in EXEC mode.
This example shows how to display the current system redundancy status for the VSM:
switch# system redundancy role primary switch# show system redundancy status Redundancy role --------------- administrative: primary operational: primary Redundancy mode --------------- administrative: HA operational: None This supervisor (sup-1) ----------------------- Redundancy state: Active Supervisor state: Active Internal state: Active with no standby Other supervisor (sup-2) ------------------------ Redundancy state: Not present switch# copy running-config startup-config
Use one of the following commands to verify the configuration:
Command |
Purpose |
---|---|
show system redundancy status |
Displays the current redundancy status for VSMs in the system. |
show module |
Displays information about all available VSMs and VEMs in the system. |
Note | Equipment Outage—This procedure requires that you power down and reinstall a VSM. During this time, your system will operate with a single VSM. |
You can replace a primary VSM in a dual VSM system.
Note | Equipment Outage—This procedure requires that you power down and reinstall a VSM. During this time, your system will operate with a single VSM. You can alternately replace a primary VSM in a dual VSM system by using the Cisco OpenStack Installer (COI). See Replacing the Primary VSM in a Dual VSM System Using the Cisco OpenStack Installer. |
Log in to the CLI in EXEC mode.
Configure the port groups so that the new primary VSM cannot communicate with the secondary VSM or any of the VEMs during the setup. VSMs with a primary or secondary redundancy role have built-in mechanisms for detecting and resolving the conflict between two VSMs in the active state. To avoid these mechanisms during the configuration of the new primary VSM, you must isolate the new primary VSM from the secondary VSM.
If you no longer need the original primary VSM VM, you can remove it.
Have access to the console of both the active and standby VSM.
Isolate the standby VSM from the active VSM to avoid the built-in mechanisms that detect and resolve conflict between two VSMs with a primary or secondary redundancy role. This procedure has a step for isolating the VSMs.
Note | Equipment Outage—This procedure requires that you power down a VSM. During this time, your system will operate with a single VSM. |
Use one of the following commands to verify the configuration:
Command |
Purpose |
---|---|
show system redundancy status |
Displays the HA status of the system. |
show module |
Displays information about all available VSMs and VEMs in the system. |
show processes |
Displays the state of all processes and the start count of the process. The states and types are described as follows: |
Related Topic |
Document Title |
---|---|
Software upgrades |
Cisco Nexus 1000V for KVM Software Installation Guide |
Cisco Nexus 1000V commands |
Cisco Nexus 1000V for KVM Command Reference |
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
MIBs |
MIBs Link |
---|---|
CISCO-PROCESS-MIB |
To locate and download MIBs, go to the following URL: http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml |
No RFCs are supported by this feature.
Technical Assistance Center (TAC) home page, containing 30,000 pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.
Go to the following URL: http://www.cisco.com/cisco/web/support/index.html
This table includes only the updates for those releases that have resulted in additions or changes to the feature.
Feature Name |
Releases |
Feature Information |
---|---|---|
System -Level High Availability |
Release 5.2(1)SK1(2.1) |
This feature was introduced. |