Downloads |
 Feedback
|
Table Of Contents
Understanding Virtual Security Gateway High Availability
Information About NX-OS High Availability
Information About VSG High Availability
Message and Transaction Service
Understanding Virtual Security Gateway High Availability
This chapter describes High Availability (HA) concepts and features for the Cisco Virtual Security Gateway (VSG).
This chapter includes the following sections:
•
Information About NX-OS High Availability
•
Information About NX-OS High Availability
The following NX-OS High Availability features minimize or prevent traffic disruption in the event of a failure:
•
•
•
•
Information About VSG High Availability
VSG HA is a subset of NX-OS HA. The following HA features minimize or prevent traffic disruption in the event of a failure:
•
•
•
Figure 1-1 shows the VSG high availability model.
Figure 1-1 VSG High Availability
This section describes VSG High Availability features and includes the following topics:
Redundancy
VSG redundancy is equivalent to HA pairing. The possible redundancy states are active and standby. An active VSG is paired with a standby VSG. HA pairing is based on VSG ID. Two VSGs that are assigned the identical ID are automatically paired. All processes running in the VSG are data path critical. If one process fails in an active VSG, failover to the standby VSG occurs instantly and automatically.
Isolation of Processes
The VSG software contains independent processes, known as services, that perform a function or set of functions for a subsystem or feature set. Each service and service instance runs as an independent, protected process. This way of operating provides a highly fault-tolerant software infrastructure and fault isolation between services. A failure in a service instance will not affect any other services running at that time. Additionally, each instance of a service can run as an independent process, which means that two instances of a routing protocol can run as separate processes.
VSG Failover
The VSG HA pair configuration allows uninterrupted traffic forwarding using stateful failover when a failure occurs. For information about VSG failover, see the "VSG HA Pair Failover" section.
System-Control Services
The VSG allows stateful restarts of most processes and services. Back-end management of processes, services, and applications is handled by a set of high-level system-control services:
•
•
•
•
Figure 1-2 shows the system-control services.
Figure 1-2 System-control Services
This section describes the services and includes the following topics:
•
System Manager
The System Manager (SM) directs overall system function, service management, and system health monitoring, and enforces high-availability policies. It is responsible for launching, stopping, monitoring, and restarting services. The SM is also responsible for initiating and managing the synchronization of service states and supervisor states.
Persistent Storage Service
The Persistent Storage Service (PSS) stores and manages the operational run-time information and configuration of platform services. The PSS component works with system services to recover states in the event of a service restart. It functions as a database of state and run-time information, which allows services to make a checkpoint of their state information whenever needed. A restarting service can recover the last known operating state that preceded a failure, which allows for a stateful restart.
Each service that uses PSS can define its stored information as private (it can be read only by that service) or shared (the information can be read by other services). If the information is shared, the service can specify that it is local (the information can be read only by services on the same supervisor) or global (it can be read by services on either supervisor or on modules).
Message and Transaction Service
The message and transaction service (MTS) is a high-performance interprocess communications (IPC) message broker that specializes in high-availability semantics. The MTS handles message routing and queuing between services on and across modules and between supervisors. The MTS facilitates the exchange of messages such as event notification, synchronization, and message persistency between system services and system components. The MTS can maintain persistent messages and logged messages in queues for access even after a service restart.
HA Policies
Nexus software usually allows each service to have an associated set of internal HA policies that define how a failed service will be restarted. When a process fails on a device, System Manager either performs a stateful resart, a stateless restart, or a failover. For a VSG, only processes borrowed by a VSG from a VSM will restart. Processes native to a VSG, like policy engine or inspect, will not restart. A failed native VSG process causes an automatic failover.
VSG HA Pairs
For VSG HA pairs:
•
•
•
•
•
This section includes the following topics:
VSG Roles
•
•
•
HA Pair States
•
•
VSG HA Pair Synchronization
The active and standby VSGs automatically synchronize when the internal state of one is active and the internal state of the other is standby.
If the output of the show system redundancy status command indicates that the operational redundancy mode of the active VSG is none, then the active and standby VSGs are not yet synchronized. The following example shows the internal state of VSG HA pair when they are synchronized.
vsg# show system redundancy status
Redundancy role
---------------
administrative: primary
operational: primary
Redundancy mode
---------------
administrative: HA
operational: HA
This supervisor (sup-1)
-----------------------
Redundancy state: Active
Supervisor state: Active
Internal state: Active with HA standby
Other supervisor (sup-2)
------------------------
Redundancy state: Standby
Supervisor state: HA standby
Internal state: HA standby
vsg#
VSG HA Pair Failover
The VSG HA pair configuration allows uninterrupted traffic forwarding using stateful failover when a failure occurs. The pair operates 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 VSGs constantly synchronize the state and configuration in order to provide a stateful failover of most services.
This section includes the following topics:
Failover Characteristics
A failover occurs when the active VSG fails and it has the following characteristics:
•
•
Automatic Failover
When a stable standby VSG detects that the active VSG has failed, it initiates a failover and transitions to active. When a failover begins, another failover cannot be started until a stable standby VSG is available. If a standby VSG that is not stable detects that an active VSG has failed, then instead of initiating a failover, it tries to restart the pair.
Manual Failover
Before you can initiate a manual failover from the active to the standby VSG, the standby VSG must be stable. To find out if it is, see the "Verifying that a VSG Pair is Ready for a Failover" section on page 2-4. Once you have verified that the standby VSG is stable, you can manually initiate a failover. To find out if it is, see the "Manually Switching the Active VSG to Standby" section on page 2-5. Once a failover process begins, another failover process cannot be started until a stable standby VSG is available.
