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 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 Configuration > 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 configure your endpoints with a SIP server address that is an FQDN, and configure 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.

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 Peer-specific configuration information (see the section What configuration 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:

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 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.)

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Page 98
Image 98
TANDBERG D14049.04 manual SIP Registrations, Backup and Restore, Upgrading to, Downgrading from