When one VCS in a cluster receives a search
request (such as an LRQ, ARQ or an INVITE),
it checks its own and its peers' registration
databases before responding. This allows all
endpoints in the cluster to be treated as if they
were registered with a single VCS.

Peers are periodically queried to ensure
they are still functioning. To prevent
delays during call setup, any non-
functioning peers do not receive LRQs.

H.323 registrations

All the peers in a cluster share responsibility
for their H.323 endpoint community. When
an H.323 endpoint registers with one peer, it
receives a registration response which contains
a list of Alternate gatekeepers, populated with a
randomly ordered list of the IP addresses of all
the other peers in that cluster.
If the endpoint loses contact with the initial
peer, it will seek to register with one of the
other peers. The random ordering of the list of
alternate peers ensures that endpoints that can
only store a single alternate peer will failover
evenly across the cluster.

When using a cluster, you should
change the registration Time to live on
all peers in the cluster from the default

30 minutes to just a few minutes. This setting
determines how often endpoints are required to
re-register with their VCS, and reducing this to
just a few minutes ensures that if one VCS
becomes unavailable, the endpoint will quickly
failover to one of its peers. To change this
setting, go to VCS configuration > Protocols >
H.323 > Gatekeeper > Time to live.

SIP registrations

Failover re-registration to a peer applies to
H.323 re-registrations only.
The SIP standard currently has no direct
equivalent, but some SIP UAs including
Movi™ v2.0 (or later) clients support similar
functionality. If you configure such endpoints
with a SIP server address that is an FQDN, and
configure this FQDN to resolve to a round-robin
DNS record populated with the IP addresses of
all the peers in the cluster, then this could allow
the endpoint to re-register with another peer if
its connection to the original peer was lost.

Sharing registrations across peers

Sharing bandwidth across peers

When clustering has been configured, all peers
share the bandwidth available to the cluster.
Peers must be configured identically for
all aspects of bandwidth control including
subzones, links and pipes.
Peers share their bandwidth usage information
with all other peers in the cluster, so when one
peer is consuming part or all of the bandwidth
available within or from a particular subzone, or
on a particular pipe, this bandwidth will not be
available for other peers.
For general information on how the VCS
manages bandwidth, see the

Bandwidth

control

section.

Upgrades and downgrades

The clustering feature was introduced to the
VCS in software release X3.0.

Upgrading from versions prior to X3.0

If you are upgrading from VCS software
versions prior to X3.0 and want to implement
clustering, you must:
1. Remove any existing Alternate configuration.
2. Upgrade all VCSs to be added to the cluster

to the latest VCS software version.

3. Follow the steps outlined in the

Configuring

clusters

section.

Downgrading

See the

Downgrade procedure

section for

details on restoring system configuration
details.

Backup and restore

The

Backup and restore

process saves all

configuration information for a particular VCS.
You are recommended to regularly backup
not just the master peer but all peers in
the cluster. This ensures that peer-specific
configuration information (see the

Which

configuration is not replicated?

section) is

saved and can be restored individually for each
peer.

Do not restore a backup made on one
peer to another peer.