Table of Contents
Advertisement
Grey Headline (continued)
Managing clusters and peers
Sharing registrations across 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.
Overview and
System
Introduction
status
configuration
D14049.07
March 2010
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.
VCS
Zones and
Clustering and
configuration
neighbors
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.
Call
Bandwidth
processing
control
81
TANDBERG
VIDEO COMMUNICATION SERVER
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
clusters
section.
Downgrading
See the
Downgrade procedure
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
configuration is not replicated?
saved and can be restored individually for each
peer.
Do not restore a backup made on one
!
peer to another peer.
Firewall
Applications
Maintenance
traversal
ADMINISTRATOR GUIDE
Configuring
section for
Which
section) is
Appendices
Advertisement
Table of Contents
