Installation Guide for Cisco Evolved Programmable Network Manager 2.1 and Maintenance Packs (2.1.x)

High Availability Deployment Models

Cisco EPN Manager supports the following High Availability (HA) deployment models.

Consider the following factors when deciding whether to use the Local, Campus, or Remote HA deployment model:

• Exposure to disaster—Remote HA deployments are least likely to be affected by natural disaster, resulting in a less complex and costly business continuity model. While the same is true for Campus HA deployments, this can complicate business continuity planning and increase disaster recovery. Local HA deployments are most vulnerable to disaster because of server co-location, which can result in increased insurance costs.
• Whether you can use a virtual IP address—Only Local HA deployments can use virtual IP addresses. A virtual IP address is a single IP address that will always point to the active server, even after a failover and fallback. It also allows both the primary and secondary servers to share a common management IP address.
• Bandwidth/latency—Bandwidth/latency is best for Local HA deployments because the primary and secondary servers are connected by short network links that have high bandwidth and latency. Campus HA deployments may have lower bandwidth/latency than Local HA deployments. Remote HA deployments have the least bandwidth.
• Administration—HA administration is simplest for Local HA deployments, with increasing complexity for Campus and Remote HA deployments. Remote HA deployments will require administrative remedying.
• Configuration of device event forwarding—Configuring event forwarding can be simplest with Local HA deployments because you can use a virtual IP address, and then configure your devices to forward events to that single virtual IP address. Without a virtual IP address, you must configure your devices to forward events to both the primary and secondary servers.

For more details about HA, see the Cisco Evolved Programmable Network Manager User and Administrator Guide .

Understand High Availability Limitations

The Cisco EPN Manager HA system is subject to the following limiting factors (this applies to all HA deployment models):

• The HA system requires at least 255 Mbps of network bandwidth to handle HA operations (the ideal is 977 Mbps). These operations include (but are not restricted to) HA registration, database and file synchronization, and triggering failback. Because Cisco EPN Manager uses a single physical port for all its networking needs, there can be occurrences of insufficient bandwidth which in turn will affect HA performance.
• The HA system requires low latency (less than 100 msecs) across network links between the primary and secondary servers. Irrespective of the physical proximity of these two servers, high latency on these links can affect how Cisco EPN Manager maintains sessions between the primary and secondary servers. This is because larger databases require more synchronization transactions which require lower latency and higher bandwidth. If you are managing a relatively small network using Cisco EPN Manager, your database would be smaller and therefore, HA might work with a higher network latency and less bandwidth.
• HA performance is always sensitive to the network throughput delivered by the network that connects the primary and secondary servers. This restriction applies (to some degree) to all of the deployment models. For example, in a geographically dispersed deployment, a remote HA deployment is more likely to have problems due to low bandwidth and high latency. However, if Local and Campus HA deployments are not properly configured, they are highly susceptible to problems with latency that result from bandwidth limitations on high-usage networks.

For assistance in determining whether your network is suitable for any of the HA variations, please contact your Cisco representative.

Consider Whether You Can Use Virtual IP Addresses

Using virtual IP addresses in a Local HA deployment setup gives your users the ability to connect to the active server using a single IP address or web URL without having to know which server is actually active. Virtual IP addresses also allow both servers to share a common management IP address. During normal operation, the virtual IP address points to the primary server. If a failover occurs, the virtual IP address automatically points to the secondary server. When failback occurs, the virtual IP address automatically switches back to the primary server.

To use virtual IP addresses, the following IP addresses must be on the same subnet:

• The virtual IP address
• The IP addresses of the primary and secondary servers
• The IP address of the gateway configured on both primary and secondary servers.

The following example illustrates how virtual, primary, and secondary IP addresses should be assigned with respect to each other. If the primary and secondary servers have the following IP address assignments within the given subnet, the virtual IP address for both servers can be assigned as follows:

• Subnet mask: 255.255.255.224 (/32)
• Primary server IP address: 10.10.101.1
• Secondary server IP address: 10.10.101.2
• Virtual IP address: 10.10.101.[3-30] e.g., 10.10.101.3. Note that the virtual IP address can be any of a range of addresses that are valid for the given subnet mask.

If you do not use a virtual IP address, you must configure your devices to forward events to both the primary and secondary servers (for example, by forwarding them to a given subnet or range of IP addresses that includes both the primary and secondary server). To reduce (or eliminate) the chance of losing data, you must configure device event forwarding before a failover occurs. You do not need to make any changes to the secondary server during installation; simply provision the primary and secondary servers with their individual IP addresses.

Whether your HA deployment uses a single IP address or not, users should always connect to the Cisco EPN Manager web GUI using the active server IP address/URL.

Best Practices if Firewall is Used Between Primary and Secondary Servers

Firewalls between the primary and secondary servers should be configured to avoid short timeouts for TCP packets to allow enough time for HA registration and other processes.

Following is the procedure for changing the Oracle and OS timeouts, if necessary. Use this procedure if the failback operation fails repeatedly.

Before you Begin

Back up the files specified in the procedure below.

Procedure

Note This procedure must be performed on both primary and secondary servers.

Step 1 Open the following file:
/opt/oracle/base/product/12.1.0/dbhome_1/network/admin/sqlnet.ora

Step 2 Add the following parameters:
SQLNET.EXPIRE_TIME=2
DISABLE_OOB=on
SQLNET.INBOUND_CONNECT_TIMEOUT=600

Step 3 Open the following file:
/opt/CSCOlumos/bin/ha_dgmgrl.sh

Step 4 Add the following line under the register() function:
edit database $1 set property NetTimeout=1000

Following is an example excerpt of the file with the relevant line in bold:

Step 5 Open the following file:
/etc/sysctl.conf

Add the following commands to the end of the file:

Step 6 Run the following command from the root shell:
sysctl -system