beautypg.com

Sharing registrations across peers, H.323 registrations, Sip registrations – TANDBERG D14049.04 User Manual

Page 98: Sharing bandwidth across peers, Backup and restore, Upgrades and downgrades, Upgrading to x3.0, Downgrading from x3.0, H.323 registrations sip registrations, Upgrading to x3.0 downgrading from x3.0

background image

98

D14049.04
JULY 2008

Grey Headline (continued)

TANDBERG

VIDEO COMMUNICATIONS SERVER

ADMINISTRATOR GUIDE

Introduction

Getting Started

Overview and

Status

System

Configuration

VCS

Configuration

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

Sharing Registrations Across Peers

Sharing Bandwidth Across Peers

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.

Upgrades and Downgrades

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:

Remove any existing Alternate configuration.

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 configure it

2.

accordingly.
Create and configure the cluster via TMS.

3.

Add the remaining Peers to the cluster via TMS.

4.

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