Have an account?

  •   Personalized content
  •   Your products and support

Need an account?

Create an account

Administration Guide for Cisco Webex Meetings Server Release 3.0

Book Contents
Find Matches in This Book
Available Languages
Download Options

Book Title

Administration Guide for Cisco Webex Meetings Server Release 3.0

Chapter Title

Adding a High Availability System

Results

Updated:
November 12, 2019

Chapter: Adding a High Availability System

Adding a High Availability System

Preparing to Add High Availability (HA) to a System

A High Availability (HA) system is a local, redundant system that is created, then added to a primary system. In the event of a virtual machine failure, the system falls back to the HA system.

If you are planning to add HA and update the system, we recommend that you add HA before updating the system, then update the combined (primary and HA) system; the HA system is updated automatically when the primary system is updated. If you update the primary system first, then to add HA, you must independently deploy and then update the HA system so that both the primary and HA systems are the same version.

The HA system has the following constraints:

  • A system running HA cannot join a Multi-data Center (MDC). (To remove HA, see Removing High Availability from a System.)

  • The HA system size must be the same as the primary system size.

  • The HA system must be the same release version as the primary system.

    You must configure the HA system with the same OVA and patch as your primary system. If the versions of your primary and high-availability systems do not match, the following links appear:

    • Update—Appears on the last page of HA configuration.

    • High Availability Upgrade—Appears after starting the process to add HA, but only if the versions don't match.

  • If the primary system currently has HA and you are deploying a new HA system, you cannot reuse the virtual machines in the original HA system. Remove the old HA virtual machines before deploying the new HA system with new virtual machines.

  • Because this process adds new virtual machines to your system, your current security certificate becomes invalid and requires an updated certificate unless you are using a self-signed certificate.

  • The HA system internal virtual machines must be on the same subnet as the primary system internal virtual machines.

  • If you have added public access on the primary system, add it to the HA system. Also, the HA system Internet Reverse Proxy virtual machine must be on the same subnet as the primary system Internet Reverse Proxy virtual machine.

  • You can view the system properties, but you cannot modify the HA system. For example, you cannot upgrade, configure SNMP, access storage, or configure email servers.

  • Load Balancing is not configurable; it is automatic and built into the system. Any Load Balancer configured as separate machine is not supported.

Before You Begin

  • Verify:

    • The target primary system is deployed and not part of an MDC.

    • There is a redundant network between virtual machines.

    • The network is a 10–gbps high-bandwidth network.

    • Network Time Protocol (NTP) configured on the primary and HA system, and that the clocks are synchronized.

  • Create a backup of the primary system. See Creating a Backup by Using VMware vCenter.

  • Verify that all virtual machines are functioning normally. Determine virtual machine status by viewing the System Monitor on the Dashboard.

  • We recommend that you take a snapshot on the high-availability virtual machines before you perform this procedure. Redo the procedure from the snapshot in the event of an error.

  • Record the fully qualified domain name (FQDN) of the high-availability virtual machine; you must know the FQDN to add high-availability to the primary system.

Deploying a System for High Availability (HA)

High Availability (HA) is deployed like a primary system, except that during the deployment the system identifies it as a HA system. The HA system is then linked to the primary system that uses the HA system as a fallback in the event of a primary system failure. A primary system failure is transparent to users.

To add HA to a system:

Procedure

Step 1

Deploy a parallel system by using Deploying a System Automatically: Workflowor Deploying a System Manually: Workflow. When the process asks if you are deploying a primary system or HA, choose HA.

We recommend that you use the same process to deploy the HA system that you used to deploy the primary system. If you do not know which process was used to deploy the primary system, use the procedures to deploy the system automatically, unless you are deploying a large (2000 concurrent users) system. All large systems require that you deploy the system manually.

Step 2

Verify the HA and primary system versions match:

  1. In a separate browser window, sign in to the primary system Webex Administration site.

  2. On the Dashboard tab, verify that the primary system version number in the System pane matches the version of the HA.

    If the versions match, continue.

  3. If the primary system is at a later version than the HA system, redeploy the HA system by using an OVA file with a matching version of the software or update the HA system.

What to do next

Link the HA system to the primary system by using Linking a High Availability System to a Primary System.

When you update a high-availability system, after you reboot the system and the reboot process is complete, we recommend that you wait an extra 15 minutes before starting the procedure to add high-availability to the system.

Linking a High Availability System to a Primary System

To link the primary system to a deployed HA system completing the integration of HA into the primary system:

Before you begin

Verify that this system is not part of a Multi-data Center (MDC) system. (HA is not supported in a MDC environment.)

Create a High Availability (HA) system by using the same process that you used to create the primary system described in Deploying a System for High Availability (HA).

Procedure

Step 1

Notify users and administrators that the system is being put into Maintenance Mode.

When you schedule a maintenance window to perform this task, the system performs a system reboot when you turn off maintenance mode. A system reboot takes approximately 30 minutes depending on the size of your system.

Step 2

Sign in to Webex Site Administration for the primary system.

Step 3

In the System section, select the Manage link.

Step 4

Click Add High Availability System.

Step 5

Follow the instructions on the System Properties page to add the HA system.

Step 6

Enter the fully-qualified domain name (FQDN) of the Administration site virtual machine of the high-availability system and select Continue.

The readiness of both the primary system and the HA system is validated. If both systems are ready, then you see a green Add button. (Do not select it if your system is not in Maintenance Mode.) If either system is not ready, an error message is displayed. Fix the error and attempt the procedure again.

Step 7

Select Add.

Note 

If "Error code: Database-64" displays, repeat this procedure by using a snapshot of the high-availability virtual machines.

Your high-availability system is added and automatically configured to serve as a backup in the event of a primary system failure.

Step 8

Sign back into Webex Site Administration after the restart is complete.

To remove HA, see Removing High Availability from a System.

High Availability System Behavior After Component Failure

When specific media and platform components running on a virtual machine go down, these components are automatically restarted by the system. Affected meetings fail over to other available resources in the same or another virtual machine in the system (for other than a standalone 50-user system).

High-Availability Systems

On high-availability (HA) systems Cisco Webex Meetings Server will recover for these components when there is a single component failure:

  • A single service on one virtual machine.

  • A virtual machine.

  • A single physical server or blade, which hosts up to two virtual machines (as long as the virtual machine layout conforms to the specifications listed in the Cisco Webex Meetings Server Planning Guide).

  • A single network link, assuming the network is provisioned in a fully redundant manner.

  • A single Cisco Unified Communications Manager (CUCM) node, assuming CUCM is provisioned in a redundant manner.

Following the single component failure, the Cisco Webex Meetings Server system behaves as follows:

  • For a period of up to three minutes, application sharing, audio voice connection using computer and video might be interrupted. Cisco Webex Meetings Server allows three minutes for the failure to be detected and to reconnect all the affected meeting clients automatically. Users should not need to close their meeting clients and rejoin their meeting.

  • Some failures might cause teleconferencing audio connections to disconnect. If that happens, users will need to reconnect manually. Reconnection should succeed within two minutes.

  • For some failures not all clients and meetings are affected. Meeting connections are normally redistributed across multiple virtual machines and hosts.

Additional Information For a 2000 User System

A 2000 user system provides some high-availability functionality without the addition of a HA system. For a 2000 user system without high availability:

  • Your system still functions after the loss of any one of the web or media virtual machines but system capacity will be impaired.

  • Loss of the Administration virtual machine renders the system unusable.

For a 2000 user system with high availability:

  • Loss of any one virtual machine (administration, media, or web) does not affect your system. Your system will still run at full capacity even with the loss of any one physical server that is hosting the primary virtual machines (administration and media or web and media) or the HA virtual machines (administration and media or web).

  • When a failed virtual machine is restarted, it rejoins the system and the system returns to its normal working state.

  • When a media virtual machine fails, meetings hosted on that server are briefly interrupted, but the meeting fails over to an alternate media virtual machine. Users must manually rejoin the desktop audio and video sessions.

  • When a web virtual machine fails, existing web sessions hosted on that virtual machine also fail. Users must sign in to the Cisco Webex site again and establish a new browser session that will be hosted on an alternate web virtual machine.

  • When an administration virtual machine fails, any existing administrator sessions also fail. Administrators must sign in again to the Administration site and establish a new browser session that will be hosted on the alternate administration virtual machine. Also, there might be a brief interruption to any existing administrator or end-user meeting sessions.

Removing High Availability from a System

Procedure

Step 1

Sign in to the Administration site.

Step 2

Select Turn On Maintenance Mode.

Step 3

Select View More in the System section.

Step 4

Select Remove High Availability System.

The Remove High Availability System page appears displaying the fully qualified domain name (FQDN) of your high-availability system.

Step 5

Select Continue.

After you have removed a high-availability system, you cannot add the same high-availability system back into the system. To restore high availability, you must deploy a high-availability system by using the OVA file. See Adding a High Availability System for more information.

Your high-availability system is removed.

Step 6

Open VMware vCenter and remove the high-availability system by using the Delete from Disk command.

Step 7

Select Turn Off Maintenance Mode and Continue to confirm.

The system reboots.

Was this Document Helpful?

FeedbackFeedback

Contact Cisco

Related Cisco Community Discussions

About Us
Contact Us
Work with Us