89
D14049.05
February 2009
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 and peers
Configuration
To neighbor your local VCS (or VCS cluster) to a remote VCS
cluster, you create a single zone to represent the cluster and
configure it with the details of all the peers in that cluster:
On your local VCS (or, if the local VCS is a cluster, on the
1.
master peer),
create a zone
of the appropriate type. This
zone will represent the connection to the cluster.
On the
2.
Edit zone
page for the zone, in the
Location
section,
enter the IP address or FQDN of each peer in the remote
cluster in the
Peer 1
to
Peer 6 address
fields.
To do this using the CLI:
Zones Zone [1..200] Neighbor Peer [1..6]
•
Addres
s
Zones Zone [1..200] TraversalClient Peer [1..6]
•
Addres
s
Ideally you should use IP addresses in these fields. If
you use FQDNs instead, each FQDN must be different
and must resolve to a single IP address for each peer.
The order in which the peers in the remote VCS cluster
are listed here does not matter.
Whenever you add an extra VCS to a cluster (to increase
capacity or improve redundancy, for example) you will
need to modify any VCSs which neighbor to that cluster
to let them know about the new cluster member.
Neighboring the local VCS to another VCS cluster
Overview
You can neighbor your local VCS (or VCS cluster) to a remote
VCS cluster; this remote cluster could be a neighbor, traversal
client, or traversal server to your local VCS. In this case, when a
call is received on your local VCS and is passed via the relevant
zone to the remote cluster, it will be routed to whichever peer in
that neighboring cluster has the lowest resource usage. That
peer will then forward the call as appropriate:
to one of its locally registered endpoints (if the endpoint is
•
registered to that peer)
to one of its peers (if the endpoint is registered to another
•
peer in that cluster)
one of its external zones (if the endpoint has been located
•
elsewhere).
When configuring a connection to a remote cluster, you create
a single zone and configure it with details of all the peers in the
cluster. Adding this information to the zone will ensure that the
call is passed to that cluster regardless of the status of the
individual peers.
Note that when you are configuring a connection to a remote
cluster, you need to enter the IP address of all peers in the
remote cluster when the connection is via a
neighbor
or
traversal client
zone. You do not do this for
traversal server
zones, as these connections are not configured by specifying the
remote system's IP address.
!
Systems that are configured as peers must
not
also be
configured as neighbors to each other, and vice versa.
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 (shown in the diagram at the start of the
Clustering
and Peers
section). Any calls between two peers in the cluster
will briefly 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 cannot 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 -> Cluster Subzone
, and
on Peer 2 as
Cluster Subzone -> 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 -> Default Subzone
-> Cluster Subzone
, and on Peer 1 as
Cluster Subzone ->
Default Subzone
.
If
Call routed mode
is set to
Optimal
and the call is
H.323, the call will not appear on Peer 2, and on
Peer 1 the route will be
Branch Office >
DefaultSubzone
.
