TANDBERG D14049.04 Network Card User Manual


  Open as PDF
of 276
 
97
D14049.04
JULY 2008
Grey Headline (continued)
TANDBERG VIDEO COMMUNICATIONS SERVER
ADMINISTRATOR GUIDE
Introduction Getting Started
Overview and
Status
System
Conguration
VCS
Conguration
Zones and
Neighbors
Call
Processing
Bandwidth
Control
Firewall
Traversal
Appendices
Applications Maintenance
Clustering, Peers and Alternates
Conguring Clusters
Prerequisites
Before creating your cluster, ensure that:
Each VCS to be added to the cluster is congured with a different
•
system name.
All VCSs to be added to the cluster have different
•
LAN conguration (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 congure 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 Conguration >
Protocols > H.323 and ensure that H.323 mode is set to On.
TMS
Clusters are created, congured and managed via TANDBERG Management Suite (TMS)
version 12.0 and above. To create a cluster using TMS:
From1. Systems > Navigator, select the VCS that will be the Master. This will be the VCS on which
all conguration changes are made, and whose conguration 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 conguration of the Master to all other Members (Peers) in
the cluster. This ensures that conguration across the cluster is kept identical; if it is not, you may
experience problems. You must only make conguration changes on the Master. Any changes
made on other Peers will not be reected across the cluster, and will be overwritten the next time
the Master’s conguration 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 congured 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 sufcient connectivity between the networks to ensure a low degree of latency between
the Peers.
What Conguration is and isn’t Replicated?
Most items of conguration 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 conguration
LAN conguration 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 conguration 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 Conguration
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 Conguration 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.
 previous next