Filter
Top Products
98
D14049.04
JULY 2008
Grey Headline (continued)
TANDBERG VIDEO COMMUNICATIONS SERVER
ADMINISTRATOR GUIDE
Introduction Getting Started
Overview and
Status
System
Conguration
VCS
Conguration
Zones and
Neighbors
Call
Processing
Bandwidth
Control
Firewall
Traversal
Appendices
Applications Maintenance
Clustering, Peers and Alternates
When one VCS in a cluster receives a Location Request, 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 Location
Requests.
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
Alternates. This may result in your H.323 endpoint community’s
registrations being spread over all the Peers in the 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 Conguration
> Protocols > H.323 > Gatekeeper > Time to live.
SIP Registrations
Failover re-registration to an Alternate applies to H.323 re-
registrations only. The SIP standard currently has no equivalent.
However, if you congure your endpoints with a SIP server
address that is an FQDN, and congure 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 congured, all Peers share the
bandwidth available to the cluster.
Peers must be congured 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.
Upgrades and Downgrades
Backup and Restore
The Backup and Restore process saves all conguration
information for a particular VCS. We recommend that you
backup not just the master Peer but all Peers in the cluster. This
will ensure that Peer-specic conguration information (see the
section What conguration is and isn’t replicated?) is saved and
can be restored individually for each Peer.
Do not restore a backup made on one Peer to another Peer.
The Clustering feature was introduced to the VCS in software
release X3.0.
Upgrading to X3.0
If you are upgrading to VCS software version X3.0 from a
previous version and wish to implement clustering, you must:
Remove any existing Alternate conguration.1.
Upgrade all VCSs to be added to the cluster to VCS software 1.
version X3.0.
Determine which VCS will be the master VCS and congure it 2.
accordingly.
Create and congure the cluster via TMS.3.
Add the remaining Peers to the cluster via TMS.4.
Downgrading from X3.0
If you have clustering congured and subsequently downgrade to
a version of VCS software prior to X3.0, the VCS will retain all its
existing conguration but will no longer act as a Peer in a cluster
- it will essentially become a stand-alone system. This will have
the following impact:
Changes to the master Peer will not be replicated to the
•
VCS, or if the VCS is the master Peer, its changes will not be
replicated to any other VCS.
The VCS’s FindMe database will be a copy of that shared
•
across all Peers in the cluster at the point when the VCS was
downgraded. The FindMe database will then be accessible to
the local VCS only.
Other VCSs that were Peers to this VCS will now be treated
•
as Alternates. (See the X2.n Administrator Guide for full
information on Alternates.)