Grey Headline (continued)
Clustering, Peers and Alternates
TANDBERG VIDEO COMMUNICATIONS SERVER ADMINISTRATOR GUIDE
About Clustering
A VCS can be part of a Cluster of up to six VCSs. Each VCS in the Cluster is a Peer of every other VCS in the Cluster.
The purpose of a Cluster is twofold:
•to increase the capacity of your VCS deployment compared with a single VCS
•to provide redundancy in the rare case that a VCS becomes unavailable (for example, due to a network or power outage).
All Peers in a Cluster must use TMS to ensure they are configured identically for subzones, zones, links, pipes, authentication, bandwidth control and call policy. They must also have identical sets of options keys installed. Peers share information with each other about their use of bandwidth, registrations, and FindMe users. This allows the Cluster to act, as one large VCS Local Zone.
The diagram opposite shows four Peers clustered together to form one large Local Zone. 
”Alternate” is an H.323 term for a system used to provide redundancy to a Primary
gatekeeper, and prior to version X3.0 the VCS supported Alternates. From X3.0 onwards, redundancy (along with other features) is provided by clusters of Peers, which support both
H.323 and SIP and work as equals. However, Peers may sometimes be referred to as Alternates.
Cluster Subzone
When two or more VCSs are clustered together, a new subzone is created within the cluster’s Local Zone. This is the Cluster Subzone, and any calls between two Peers in the Cluster will pass via this Subzone during call setup. The Cluster Subzone is (like the Traversal Subzone) a virtual Subzone used for call routing only, and endpoints can not register to this subzone. Once a call has been established between two Peers, the Cluster Subzone will no longer appear in the call route and the call will appear as having come from (or being routed to) the Default Subzone.
The two situations in which a call will pass via the Cluster Subzone are:
•Calls between two endpoints registered to different peers in the Cluster.
For example, Endpoint A is registered in the Default Subzone to Peer 1. Endpoint B is also registered in the Default Subzone, but to Peer 2. When A calls B, the call route is shown on Peer
1 as Default Subzone
•Calls received from outside the Cluster by one Peer, for an endpoint registered to another Peer. For example, we have a single VCS for the Branch Office, which is neighbored to a Cluster of 4 VCSs at the Head Office. A user in the Branch Office calls Endpoint A in the Head Office. Endpoint A is registered in the Default Subzone to Peer 1. The call is received by Peer 2, as
it has the lowest resource usage at that moment. Peer 2 then searches for Endpoint A within the Cluster’s Local Zone, and finds that it is registered to Peer 1. Peer 2 then forwards the call to Peer 1, which forwards it to Endpoint A. In this case, on Peer 2 the call route will be shown as Branch Office
Introduction | Getting Started | Overview and | System | VCS | Zones and | |
Status | Configuration | Configuration | Neighbors | |||
|
|
VCS CLUSTER
PEER 1 PEER 2 PEER 3 PEER 4
LOCAL |
|
|
|
| ||
ZONE |
| Cluster |
|
| ||
|
|
| Subzone |
|
| |
| Subzone |
| Traversal | |||
| Traversal | Client Zone | ||||
|
|
| ||||
|
|
| Subzone |
|
| |
|
| Default |
| Neighbor | ||
|
|
| Zone |
| ||
|
| Subzone |
|
|
| |
|
| Default | DNS | ENUM |
| |
|
| Zone | Zone | Zone |
| |
Call | Bandwidth | Firewall | Applications | Maintenance | Appendices | |
Processing | Control | Traversal | ||||
|
|
| ||||
D14049.04 | 96 |
JULY 2008 |
