80
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
Cluster configuration
Which configuration is not 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 local administrator accounts and
passwords are replicated from the master peer
to all other peers.
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.
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.
IP configuration
LAN
configuration is not replicated across
peers. Each peer must have a different
IPv4 address and a different IPv6 address.
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.
Note that the
IP protocol
is replicated, because
each peer must support the same protocol(s).
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.
Certificates
The security certificates and certificate
revocation lists (CRLs) used by the VCS must be
uploaded individually per peer.
!
Configuration data that is replicated
across peers should not be modified on
non-master peers. At best it will result
in the changes being overwritten from the
master; at worst it will cause cluster replication
to fail.
Troubleshooting cluster replication problems
Cluster replication can fail for a variety of
reasons. The most common problems are listed
below, followed by instructions for resolving the
problem:
NTP servers not configured and active on each
cluster peer
1. For each peer in the cluster, go to the
System configuration > Time
page.
2. Ensure the peer has a correctly configured
and active
NTP server
.
Some peers have a different master peer
defined
1. For each peer in the cluster, go to the
VCS
configuration > Clustering
page.
2. Ensure each peer identifies the same
Configuration master
.
Cluster configuration script has not been run
against each peer
1. For each peer in the cluster, go to the
VCS
configuration > Clustering
page.
2. Enter the address of each of peer into the
Peer IP address
fields and configure the
Configuration master
. Ensure each peer
identifies the same
Configuration master
peer.
3. Log in to each peer as
root
(by default you
can only do this using a serial connection
or SSH) and run the cluster configuration
script (full details on running this script
and configuring clusters is available in the
Clustering deployment guide [27]
).
Cluster replication warnings can appear
briefly while the cluster is initially being
set up. These warnings are removed
after the data has completed synchronizing and
the cluster has stabilized. This takes
approximately 3 minutes.
Unable to reach the cluster configuration master
peer
The VCS operating as the master peer could be
unreachable for many reasons, including:
•
network access problems
•
VCS unit is powered down
•
incorrectly configured IP addresses
"Manual synchronization of configuration is
required" warnings are raised on peer VCSs
1. Log in to the peer as
admin
through the CLI
(available by default over SSH and through
the serial port).
2. Type
xCommand ForceConfigUpdate
.
This will delete the non-master VCS
configuration and force it to update its
configuration from the master VCS.
!
Never issue this command on the
master VCS, otherwise all VCS
configuration for the cluster will be lost.
