87
D14049.05
February 2009
Grey Headline
(continued)
TANDBERG
VIDEO COMMUNICATIONS SERVER
ADMINISTRATOR GUIDE
Introduction
Getting started
Overview and
status
System
configuration
VCS
configuration
Zones and
neighbors
Call
processing
Bandwidth
control
Firewall
traversal
Appendices
Applications
Maintenance
Clustering and peers
When one VCS in a cluster receives a search request (such as an LRQ, an ARQ or an INVITE), it
checks its own registration database along with that of each of its peers 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 that they are still functioning. In order to prevent
delays during call setup, any non-functioning peers will 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 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. This
may result in your H.323 endpoint community’s registrations being spread over all the peers in 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 changing this to just a few
minutes will ensure that if one VCS becomes unavailable, the endpoint will quickly failover to one of
its peers. To change this setting, navigate 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 clients also 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.
What configuration is and isn’t replicated?
Most items of configuration are replicated from
the master to all peers, with the exceptions
listed below.
System name
The
system name
is not replicated. It must be
different for each peer in the cluster.
Administrator accounts
The password for the default
admin
administrator account is not replicated. Each
peer can have a different password.
Any other administrator accounts and
passwords will be replicated from the master
peer to all other peers.
See the
Administrator accounts
section for
further information.
Option keys
Option keys
are not replicated. Each peer must
have an identical set of option keys installed,
but you must purchase these separately for
each peer in the cluster.
Ethernet speed
The
ethernet speed
is not replicated. Each
peer may have slightly different requirements
for the connection to their ethernet switch.
Conference Factory template
The
Template
used by the
Conference Factory
application to route calls to the MCU is not
replicated, as it must be unique for each peer in
the cluster.
IP configuration
LAN
configuration is not replicated across
peers. Each peer must have a different
IPv4 address and a different IPv6 address.
The
IP protocol
is replicated, because each
peer must support the same protocol(s).
IP gateway
configuration is not replicated. Each
peer can use a different gateway.
IP routes
(also known as static routes) are
not replicated. If these are used, they can be
different for each peer.
DNS configuration
DNS servers
are not replicated across peers
- each peer can use a different set of DNS
servers. However, the
DNS domain name
is
replicated across peers.
Logging
The Event Log and Configuration Log on each
peer will only report activity for that particular
VCS. We recommend that you set up a remote
syslog server to which the logs of all peers can
be sent. This will allow you to have a global
view of activity across all peers in the cluster.
See the
About remote logging
section for
further details.
FindMe database
FindMe account information is copied across
all peers in the cluster. However, this is
not achieved by replicating the master's
configuration - instead, it is done using a
separate process whereby each peer shares its
FindMe information directly with all other peers.
See the section
Clustering and FindMe
for more
information.
