Cisco Cisco TelePresence Video Communication Server Expressway 관리 매뉴얼

다운로드
페이지 295
80
D14049.08 
November 2010
Grey Headline (continued)
CISCO TELEPRESENCE
 VIDEO COMMUNICATION SERVER
ADMINISTRATOR GUIDE
Cluster configuration
Which configuration is not replicated?
Most items of configuration are replicated from 
the master to all peers, with the exceptions 
listed below.
System name
The 
 is not replicated. It must be 
different for each peer in the cluster.
Administrator accounts
The password for the default admin 
administrator account is not replicated. Each 
peer can have a different password.
Any other local administrator accounts and 
passwords are replicated from the master peer 
to all other peers.
Option keys
 are not replicated. Each peer must 
have an identical set of option keys installed, 
but you must purchase these separately for 
each peer in the cluster.
Ethernet speed
The 
 is not replicated. Each peer 
may have slightly different requirements for the 
connection to their ethernet switch.
Conference Factory template
The Template used by th
application to route calls to the MCU is not 
replicated, as it must be unique for each peer.
DNS configuration
 are not replicated across peers 
- each peer can use a different set of DNS 
servers. However, th
 is 
replicated across peers.
IP configuration 
 configuration is not replicated across 
peers. Each peer must have a different 
IPv4 address and a different IPv6 address.
 configuration is not replicated. Each 
peer can use a different gateway.
 (also known as static routes) are 
not replicated. If these are used, they can be 
different for each peer.
Note that the 
 is replicated, because 
each peer must support the same protocol(s). 
Logging
The Event Log and Configuration Log on each 
peer will only report activity for that particular 
VCS. We recommend that you set up a remote 
syslog server to which the logs of all peers can 
be sent. This will allow you to have a global view 
of activity across all peers in the cluster. See 
the 
 section for further 
details.
Certificates
The security certificates and certificate 
revocation lists (CRLs) used by the VCS must be 
uploaded individually per peer.
!
Configuration data that is replicated 
across peers should not be modified on 
non-master peers. At best it will result 
in the changes being overwritten from the 
master; at worst it will cause cluster replication 
to fail.
Troubleshooting cluster replication problems
Cluster replication can fail for a variety of 
reasons. The most common problems are listed 
below, followed by instructions for resolving the 
problem:
NTP servers not configured and active on each 
cluster peer
1. For each peer in the cluster, go to the 
System configuration > Time page.
2. Ensure the peer has a correctly configured 
and active NTP server.
Some peers have a different master peer 
defined
1. For each peer in the cluster, go to the VCS 
configuration > Clustering page.
2. Ensure each peer identifies the same 
Configuration master.
Cluster configuration script has not been run 
against each peer
1. For each peer in the cluster, go to the VCS 
configuration > Clustering page.
2. Enter the address of each of peer into the 
Peer IP address fields and configure the 
Configuration master. Ensure each peer 
identifies the same Configuration master 
peer.
3. Log in to each peer as root (by default you 
can only do this using a serial connection 
or SSH) and run the cluster configuration 
script (full details on running this script 
and configuring clusters is available in the 
).
Cluster replication warnings can appear 
briefly while the cluster is initially being 
set up. These warnings are removed 
after the data has completed synchronizing and 
the cluster has stabilized. This takes 
approximately 3 minutes.
Unable to reach the cluster configuration master 
peer
The VCS operating as the master peer could be 
unreachable for many reasons, including:
• 
network access problems
• 
VCS unit is powered down
• 
incorrectly configured IP addresses
"Manual synchronization of configuration is 
required" warnings are raised on peer VCSs
1. Log in to the peer as admin through the CLI 
(available by default over SSH and through 
the serial port).
2. Type 
xCommand ForceConfigUpdate.
This will delete the non-master VCS 
configuration and force it to update its 
configuration from the master VCS.
!
Never issue this command on the 
master VCS, otherwise all VCS 
configuration for the cluster will be lost.