97
D14049.04
JULY 2008
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, Peers and Alternates
Configuring Clusters
Prerequisites
Before creating your cluster, ensure that:
Each VCS to be added to the cluster is configured with a different
•
system name
.
All VCSs to be added to the cluster have different
•
LAN
configuration (i.e. a different IPv4 Address
and subnet mask, and different IPv6 Address, where enabled).
All VCSs to be added to the cluster have identical sets of
•
option keys
installed.
Determine which VCS is to be the master and configure it with the settings you wish to apply to
•
the entire cluster.
Enabling H.323
H.323 signaling is used for both endpoint location searching and sharing bandwidth usage
information with other Peers in the cluster. This means that H.323 must be enabled on all Peers,
even if all endpoints in the cluster are SIP only. To enable H.323, navigate to
VCS Configuration >
Protocols > H.323
and ensure that
H.323 mode
is set to
On
.
TMS
Clusters are created, configured and managed via TANDBERG Management Suite (TMS)
version 12.0 and above. To create a cluster using TMS:
From
1.
Systems > Navigator
, select the VCS that will be the Master. This will be the VCS on which
all configuration changes are made, and whose configuration is replicated to the other Peers.
From the
2.
Clustering
tab, select
Create New Cluster
.
Enter a
3.
Cluster Name
and select
Create Cluster
.
You will then have the option to
4.
Add Members
to the cluster. Select the VCS(s) that are to be
Peers in the cluster and click
Add
.
(For full information, refer to the TMS Administrator Guide.)
TMS will automatically propagate the configuration of the Master to all other Members (Peers) in
the cluster. This ensures that configuration across the cluster is kept identical; if it is not, you may
experience problems. You must only make configuration changes on the Master. Any changes
made on other Peers will not be reflected across the cluster, and will be overwritten the next time
the Master’s configuration is replicated across the Peers.
!
We recommend that Peers in a Cluster are deployed on the same LAN as each other so
that they can be configured with the same routing information such as local domain
names and local domain subnet masks. If Peers are deployed on different LANs, there
must be sufficient connectivity between the networks to ensure a low degree of latency between
the Peers.
What Configuration is and isn’t Replicated?
Most items of configuration are replicated
across Peers, with the exceptions listed below.
System Name
The
system name
is not replicated. It must be
different for each Peer in the cluster.
Administration Accounts
The password for the default
admin
administrator account is not replicated. Each
Peer can have a different password.
Any other administration accounts and
passwords will be replicated from the Master
Peer to all other Peers.
See the
Administration 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.
IP configuration
LAN
configuration is not replicated across
Peers. Each Peer must have a different
IPv4 Address and 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
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.
