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 both the primary and HA systems are at the
The HA system
size must be the same as the primary system size.
The HA system
must be at the same release version as the primary system.
If you update
the primary system, the HA system must be updated.
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.
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.
Your HA system must be
configured with the same OVA and patch as your primary system. If the versions
of your primary and high-availability systems do not match, you are instructed
to upgrade to the higher version of the two.
Use the same
base version OVA as was used to deploy the current system. For example, assume
that originally you deployed internal virtual machines by using 220.127.116.11 OVA
and over time updated your system to 18.104.22.168 version. If you use 22.214.171.124 OVA
file to deploy an IRP virtual machine and add Public Access, the process will
fail with the message, "The primary system is a different version than the
Internet Reverse Proxy virtual machines. Redeploy the Internet Reverse Proxy
virtual machines by using the same OVA file used to deploy the primary system."
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.
Most of the features on your
HA system are prohibited. For example you do not have access to the HA system
to upgrade, configure SNMP, access storage or configure email servers. You can
view system properties, but modification to the HA system is prohibited.
is not configurable; it is automatic and built into the system. Any Load
Balancer configured as separate machine is not supported.
conditions must be met before adding HA to a primary system:
primary system is deployed and not part of an
There is a
redundant network between virtual machines.
network is a 10–gbps high-bandwidth network.
Time Protocol (NTP) configured on the primary and HA system, and that the
clocks are synchronized.
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)
(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.
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.
Verify the HA
and primary system versions match:
In a separate browser window, sign in to the primary system WebEx Administration site.
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.
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.
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
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.)
Notify users and
administrators that the system is being put into Maintenance Mode.
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.
Sign into the
primary system administration site.
In the System section, select
instructions on the
Properties page to add the HA system.
fully-qualified domain name (FQDN) of the Administration site virtual machine
of the high-availability system and select
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.
If "Error code: Database-64" displays, repeat this procedure by using a snapshot of the high-availability virtual machines.
high-availability system is added and automatically configured to serve as a
backup in the event of a primary system failure.
Sign back into the
Administration site after the restart is complete.
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).
(HA) systems Cisco WebEx Meetings Server will recover for these components when
there is a single component failure:
service on one virtual machine.
physical server or blade, which hosts up to two virtual machines (as long as
the virtual machine layout conforms to the specifications listed in
Meetings Server Planning Guide).
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
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.
might cause teleconferencing audio connections to disconnect. If that happens,
users will need to reconnect manually. Reconnection should succeed within two
failures not all clients and meetings are affected. Meeting connections are
normally redistributed across multiple virtual machines and hosts.
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:
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.
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.
Availability from a System
Sign in to the
More in the System section.
High Availability System.
High Availability System page appears displaying the fully qualified
domain name (FQDN) of your high-availability system.
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.
high-availability system is removed.
vCenter and remove the high-availability system by using the
from Disk command.
Maintenance Mode and
Continue to confirm.