
Grey Headline (continued)
Clustering, Peers and Alternates
TANDBERG VIDEO COMMUNICATIONS SERVER ADMINISTRATOR GUIDE
Sharing Registrations Across Peers |
| Sharing Bandwidth Across Peers |
| Upgrades and Downgrades |
|
|
|
|
|
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
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
SIP Registrations
Failover
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.
Backup and Restore
The Backup and Restore process saves all configuration 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
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:
1.Remove any existing Alternate configuration.
1.Upgrade all VCSs to be added to the cluster to VCS software version X3.0.
2.Determine which VCS will be the master VCS and configure it accordingly.
3.Create and configure the cluster via TMS.
4.Add the remaining Peers to the cluster via TMS.
Downgrading from X3.0
If you have clustering configured and subsequently downgrade to a version of VCS software prior to X3.0, the VCS will retain all its existing configuration but will no longer act as a Peer in a cluster
-it will essentially become a
•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.)
Introduction | Getting Started |
| Overview and |
| System |
| VCS | Zones and | Call |
| Bandwidth |
| Firewall |
| Applications |
| Maintenance |
| Appendices |
| Status |
| Configuration |
| Configuration | Neighbors | Processing |
| Control |
| Traversal |
|
|
| |||||
|
|
|
|
|
|
|
|
|
|
|
|
| |||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
D14049.04 |
|
|
|
|
|
|
| 98 |
|
|
|
|
|
|
|
|
|
| |
JULY 2008 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|