This chapter contains
the following sections:
ESC supports High
Availability (HA) in the form of a Primary and Standby model. Two ESC instances
are deployed in the network to prevent ESC failure and provide ESC service with
minimum service interruption. If the primary ESC instance fails, the standby
instance automatically takes over the ESC services. ESC HA resolves the
following single point failures:
A High Availability
deployment consists of two ESC instances: a primary and a standby. Under normal
circumstances, the primary ESC instance provides the services. The
corresponding standby instance is passive. The standby instance is in constant
communication with the primary instance and monitors the primary instances'
status. If the primary ESC instance fails, the standby instance automatically
takes over the ESC services to provide ESC service with minimum interruption.
The standby also has
a complete copy of the database on the primary, but it does not actively manage
the network until the primary instance fails. When the primary instance fails,
the standby takes over automatically. Standby instance takes over primary
instance to manage the services while primary instance restoration taken place.
When the failed
instance is restored, failback operations can be initiated to resume network
management via the original primary instance.
ESC instances are
managed by using KeepAliveD. The VM handshake between ESC instances occurs
through the KeepAliveD over the IPv4 network.
Deploying ESC High
To deploy ESC HA on
VMware vCenter or vSphere, two separate standalone nodes need to be installed
first. After the standalone ESC instances are installed, reconfigure these
nodes to turn them into Primary and Standby using the following:
Before You Begin
ESC VM, we need to run
escadm tool to configure ESC HA parameters and then reboot
are deploying ESC HA, the kad_vip argument allows end users to access the
Primary ESC instance.
- Cisco Elastic Services
Controller (ESC) High Availability (HA) requires a network to keep alive and
replicate database between primary and standby nodes. Both ESC VMs must have at
least one network interface connecting to the same network and must be able to
communicate to each other through the network.
- Ensure the two ESC VMs are
located in different hosts and datastores so that single point failures can be
||Log in to the
ESC Standalone instances.
||As an admin
user, run the
tool on both the Primary and Standby instances and provide the
kad_vip— Specifies the IP address for Keepalived VIP
(virtual IP) plus the interface of Keepalived VIP [ESC-HA]
kad_vif— Specifies the interface for Keepalived virtual IP
and keepalived VRRP [ESC-HA]. You can also use this argument to only specify
the interface for keepalived VRRP, if the VIP interface is already specified
ha_node_list— Specifies list of IP addresses for HA nodes in
the Primary/Standby cluster for DRDB synchronization. This argument is utilized
for replication-based HA solution only. For ESC instances with multiple network
interfaces, the IP addresses should be within the network that
--kad_vif argument specifies .
$ escadm ha set --kad_vip= <ESC_HA_VIP> --kad_vif= <ESC_KEEPALIVE_IF> --ha_node_list= <ESC_NODE_1_IP> <ESC_NODE_2_IP>
$ escadm restart
restart, one ESC VM should be in Primary state and the other one should be in
|| Add the VIP
to the allowed address pairs for both VMs so that the VIP is reachable from
status of each ESC instance.
# escadm status
table lists few other command to check the status:
you want to see more details (such as status of the VIM manager, SNMP, portal,
ESC manager, keepalived status and so on), add '–v':
escadm status --v
To check the detailed status, check the /var/log/esc/escadm.log
Important Notes for
The HA failover
takes about 2 to 5 minutes based on the number of managed VNFs to be
operational. ESC service will not be available during the switchover time.
switchover is triggered during transactions, all incomplete transactions will
be dropped. The requests should be re-sent by Northbound interface if it does
not receive any response from ESC.
Check for network
failures. If a network problem occurs, you must check the following details:
The IP address
assigned is correct, and is based on the OpenStack configuration.
for each network interface must be pinged.
configuration between the installation arguments and ASR configuration must
Check the logs for
manager log at
The ESC HA log
The exabgp log
by grep keepalived
The ESC service status log at