Cisco Unified MeetingPlace, Release 7.0 -- About Failover Options for the Application Server
Main page: Cisco Unified MeetingPlace, Release 7.0
Up one level: Planning Your Deployment
Use the information in this section to determine which type of Application Server failover you want for your Cisco Unified MeetingPlace system.
How Application Server Redundancy Works
For Application Server redundancy, you deploy two Application Servers-an active and a standby-as part of one logical site. Only one Application Server is active at any time. The active Application Server runs all processes and subsystems, while the standby Application Server only runs the database and Apache Tomcat processes and subsystems.
Each Application Server has an Informix database that contains information about users, groups, and meetings. The system uses the Informix Enterprise Replication (ER) feature to allow changes in the database of one Application Server to be automatically carried over to the database of the other Application Server.
If the active Application Server fails, then you can activate the standby Application Server and place the previously active Application Server in standby mode. Each Application Server in a site is called a node.
If your deployment includes a one-to-one redundancy of Media Servers, associate one Media Server with the active Application Server and the redundant Media Server with the standby Application Server. If the primary and standby Application Servers share a common Media Server, add the Media Server to both Applications Servers.
You can configure your system for Application Server redundancy in one of two ways:
- Using intra-site failover, which does not allow changes to be made to both databases at the same time. See About Configuring Your Application Server for Intra-Site Failover.
- Using inter-site failover, which does allow you to make changes to both databases at the same time. See About Configuring Your Application Server for Inter-Site Failover with Directory Service.
Note: Cisco Unified MeetingPlace does not support combined intra-site and inter-site failover.
Requirements for Application Server Redundancy
- The standby Application Server must have its own set of licenses. The licenses used for the active Application Server do not work on the standby Application Server.
- The time must be synchronized between both sets of Application Servers and between the Application Server and the Web Server.
- The active and the standby Application Servers can reside in different physical locations if the following two conditions are met:
- They must both be configured on the same VLAN. This requires data center VLAN to span between both sites. Please consult your Cisco technical representative for various options for this requirement.
- There is a dedicated failover Media Server.
- Failover requires a minimum bandwidth of 4 mpbs.
- There is no minimum requirement for latency, which affects the delay in getting the data replicated to the other server.
- The network sends a heartbeat between the two replicating databases every 60 seconds. If there is no response, the network pings the database from which there was no response. If the database still does not respond, the system buffers all data until the heartbeat detects that the database is back. The network then sends the updated information to the database that was not previously responding.
- Do not leave a standby server out of production for a period of time, as this can cause the primary server to fail. If the standby server must be brought down for days or weeks at a time, disable replication during this time.
About Configuring Your Application Server for Intra-Site Failover
In this deployment, there is one site with two Application Servers, or nodes, that share data related to users, groups, and meetings, but only one Application Server can be active at any time. There is a maximum of two Application Servers allowed per site.
The system replicates the data between the two databases. The system does not allow simultaneous changes to database tables that contain users, groups, and meeting information.
If there is a network disconnection between the two Application Servers and certain records are modified in the databases for both Application Servers, the system uses the update timestamp to resolve the conflict. When the connection is restored, the latest update is propagated to both the servers.
Figure: Intra-Site Failover
Restrictions and Requirements for Intra-Site Failover
- The time must be synchronized between the two Application Servers. This is required to resolve conflicts when the same piece of data is modified simultaneously in both Application Servers.
- For failover deployments, the primary and standby Application Servers communicate using TCP port 2008 for database replication purposes. The system must allow communication on TCP port 2008 between the servers.
- Allocate the following hostnames and IP addresses:
- Node 1 eth0 and Node 2 eth0-Use the same hostname and IP address for the eth0 network interface on both Node 1 and Node 2. Example: meetings.example.com, 10.0.0.1
- Node 1 eth0:1-Use a unique hostname and IP address for this virtual network interface. Example: meetings1.example.com, 10.0.0.2
- Node 2 eth0:1-Use a unique hostname and IP address for this virtual network interface. Example: meetings2.example.com, 10.0.0.3
- Make sure that the Domain Name System (DNS) server is configured for all three hostname-IP address pairs. That is, at the DNS server, create forward lookup Host (A) records, and reverse lookup Pointer (PTR) records for all three hostname-IP address pairs.
About Configuring Your Application Server for Inter-Site Failover with Directory Service
This deployment allows two simultaneously active and inter-connected Application Servers, or nodes, at two different sites. This configuration is useful when the Application Servers need to have the same set of user profiles (from an LDAP server) and user groups.
This mechanism does not provide an automated failover mechanism. However, since both systems share a common user database, reservationless meetings can be held equally on either. If one is set up as an active standby, and the primary is down, then if calls (and web addresses) are rerouted from the primary to the standby, the standby system can hold the reservationless meetings.
One of the Application Servers gets the user data from the LDAP server through Cisco Unified Communications Manager and then the Application Servers are synchronized through database replication.
Other than the user profile and user group synchronization, the Application Servers are independent and are associated with different Web Servers. A user connecting to an Application Server will see different configuration data (for example, meetings) except for the user profiles and user groups.
The replication setup replicates profile users who are type "End Users". Any other types (including System Administrators and Attendants) will be local. So if an End User is replicated and the type of user is changed to System Administrator or Attendant on one, the other copy will be removed by the database.