81
D14049.07
March 2010
Grey Headline
(continued)
TANDBERG
VIDEO COMMUNICATION SERVER
ADMINISTRATOR GUIDE
Introduction
Overview and
status
System
configuration
VCS
configuration
Zones and
neighbors
Clustering and
peers
Call
processing
Bandwidth
control
Firewall
traversal
Appendices
Applications
Maintenance
Managing clusters and peers
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
TANDBERG 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.
