83
D14049.07
March 2010
Grey Headline
(continued)
TANDBERG
VIDEO COMMUNICATION SERVER
ADMINISTRATOR GUIDE
Introduction
Overview and
status
System
configuration
VCS
configuration
Zones and
neighbors
Clustering and
peers
Call
processing
Bandwidth
control
Firewall
traversal
Appendices
Applications
Maintenance
Managing clusters 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:
1. On your local VCS (or, if the local VCS is a cluster, on the
master peer),
create a zone
of the appropriate type. This zone
will represent the connection to the cluster.
2. 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..1000] Neighbor Peer [1..6]
Address
•
Zones Zone [1..1000] TraversalClient Peer [1..6]
Address
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 peer.
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 in the
Clustering overview
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. After
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
.
