Background
I set up a VCS lab a while back and I captured information that I thought would be good blog material. I just recently dusted that material off and figured it was a good time to share. The example is based on VCS X5.2. VCS X6 is out now and it is a recommended version. The configuration steps are basically the same. VCS X6 did improve upon the secure channel communications between VCS peers.
The VCS Cluster
At a very high-level, a VCS cluster is a logical grouping of up to 6 identical peers. These peers work together as one large Local Zone. A VCS Local Zone is a collection of endpoints, gateways, MCUs, and Content Servers registered with the VCS or VCS cluster.
Clustering provides an increase of resource capacities as well as redundancy if a VCS peer becomes unavailable. A cluster can contain 6 peers but only 4 of these peers can host registrations. The other 2 peers can be used as dedicated redundant peers.
A customer can achieve spatial redundancy by distributing VCS peers across the network. However, it is required that the round trip time between any two peers is less than 30ms. The peers also need adequate bandwidth to communicate with each other. Each VCS peer must be directly routable to each other peer in the cluster and NAT between cluster peers is not supported.
All VCS cluster peers must be running the same VCS version and have the same option keys installed. The VCS clustering mechanism is used to replicate information from one VCS peer (the master peer) to all other peers. However, not all information is replicated. The following list identifies what is not replicated between VCS peers (these settings must be configured locally on each peer):
- System name: must be unique on each peer
- Default administration account: the password for the default admin account is not replicated. User added admin accounts are replicated.
- Option keys
- Ethernet speed
- LAN configuration
- IP Gateway
- IP routes
- DNS configuration
- Logging configuration: recommend having peers log to the same destination
As noted, there is one master peer in the VCS cluster. This happens to be configurable by the system administrator. The master peer is responsible for pushing out all configuration information to other peers. In the event the master peer goes off line, the VCS peer with the next highest priority takes over the master role (as designated master). When the master peer comes back online, the designated master synchronizes data with the master peer and then hands back control.
Configuring a VCS Cluster
In the example provided, assume the following:
- VCS Cluster name: vcsc.netcraftsmen.net
- VCS Master peer: vcsc1.netcraftsmen.net (192.168.36.40)
- VCS peer: vcsc2.netcraftsmen.net (192.168.36.45)
- There is no other VCS cluster
Preparing to Build the Cluster
Determine which VCS peer will be the master peer. In our case that is vcsc1.netcraftsmen.net. Each VCS peer must be on line and reachable (via IP) to perform the following preparation steps:
- Backup all VCS hosts.
- Go to the Zones configuration and ensure that the VCS cluster peers are not listed in any neighbor or traversal zone.
- Go to the Overview configuration and ensure that all VCS peers are running the same software version.
- Enable root access via SSH.
- Turn off FindMe on all VCS peers.
- Check IP configuration, DNS, and NTP settings to ensure configurations are present and accurate.
- Ensure no cluster peers are configured under the Cluster configuration page.
- Ensure all cluster peers have unique local host names.
If you are using TMS then additional preparation steps are needed. These additional steps are not covered here.
Adding Cluster Peer Configurations
We need to tell the cluster peers about each other and their role in the cluster. This is done under the VCS Configuration > Clustering page on each VCS. First, configure the VCS which will be the master peer. In our example, this is vcsc1.netcraftsmen.net (192.168.36.40). Set the following values:
- Cluster name (FQDN for Provisioning)
- Configuration master (defaults to 1)
- Peer 1 IP address
- Peer 2 IP address
We set the configuration master to use peer 1. After we save and refresh the screen, the second peer is listed as “Failed”. This is expected behavior because we have not initialized the cluster yet.
Next, SSH to the console of the second VCS peer and login as admin. Enter the command:
xcommand defaultvaluesset level: 2
NOTE: This command will wipe any LDAP configuration that exists. Make sure you know the web admin password before entering the command.
Next, go to the clustering configuration page on the second VCS peer. Set the same values configured on the VCS master.
Initializing the Cluster
We are almost there…
SSH as root to the console of the VCS master peer and run the cluster wizard:
silversurfer:ssh root@192.168.36.40
Logged in (keyboard-interactive)
Last login: Tue Jan 25 21:35:47 GMT 2011 from 192.168.1.19 on ssh
WARNING: Security alert: the TMS Agent database has the default password set.
WARNING: Security alert: The admin user has the default password set
WARNING: Security alert: The root user has the default password set
WARNING: Telnet service has been changed, however a restart is required for this to take effect
WARNING: Security alert: the TMS Agent database has the default replication password set.
WARNING: Security alert: the SSH service is using the default key
~ # cluster
.----------------------------------------------------------------------------.
| Tandberg VCS Clustering Main Menu |
'----------------------------------------------------------------------------'
Hostname : vcsc1
IP Address : 192.168.36.40
Use this menu to configure replication of data for peers in a cluster.
(1) Set this VCS to be the Configuration Master peer of a new cluster
(2) Enable this VCS to replicate with an existing peer
(3) Disable replication on this VCS
(4) Disable replication on another peer
(5) Check the replication status of this VCS
(6) Check the TMS Agent status of this VCS
(7) Rebuild TMS Agent database indexes
(q) Quit
Choose an option : 1
.------------------------------------------------------------------------.
| Preparing this VCS as the first replicating peer |
'------------------------------------------------------------------------'
The following cluster peers are configured on this VCS:
* 192.168.36.40 (me)
* 192.168.36.45
The replicable data on this VCS will be preserved so that
it can be replicated across the peers in the cluster.
Is the list of peers above correct? (Y/N) Y
Creating local key
Restarting replication services.
Replication has been enabled on this peer.
Press Enter to continue
Next, SSH as root to the second VCS peer:
silversurfer:ssh root@192.168.36.45
Logged in (keyboard-interactive)
Last login: Tue Jan 25 22:31:49 GMT 2011 from 192.168.1.19 on pts/0
WARNING: Security alert: the TMS Agent database has the default password set.
WARNING: Security alert: The admin user has the default password set
WARNING: Configuration warning: expected default link between the Default Subzone and the Default Zone is missing
WARNING: Security alert: The root user has the default password set
WARNING: Security alert: the TMS Agent database has the default replication password set.
WARNING: Security alert: the SSH service is using the default key
NOTE: This VCS is part of a cluster but is not the configuration master.
Any configuration changes made on this VCS may be lost.
See the VCS Administrator Guide for more information on clustering.
~ # cluster
.----------------------------------------------------------------------------.
| Tandberg VCS Clustering Main Menu |
'----------------------------------------------------------------------------'
Hostname : vcsc2
IP Address : 192.168.36.45
Use this menu to configure replication of data for peers in a cluster.
(1) Set this VCS to be the Configuration Master peer of a new cluster
(2) Enable this VCS to replicate with an existing peer
(3) Disable replication on this VCS
(4) Disable replication on another peer
(5) Check the replication status of this VCS
(6) Check the TMS Agent status of this VCS
(7) Rebuild TMS Agent database indexes
(q) Quit
Choose an option : 2
.------------------------------------------------------------------------.
| Preparing this VCS to replicate with an existing cluster peer. |
'------------------------------------------------------------------------'
WARNING: Replicable data on this VCS will be destroyed.
Are you sure you wish to proceed? (Y/N) y
Replicable data destroyed on 192.168.36.45.
The following cluster peers are configured on this VCS:
* 192.168.36.40 * 192.168.36.45 (me)
Is the list of peers above correct? (Y/N) y
Finding a peer to download replicable data from ... Shall I use 192.168.36.40 (Y/N) y
Creating local key
Initial Key negotiation
Copying my public key to 192.168.36.40 (password required)
Enter 192.168.36.40's Password:
Download replicable data from 192.168.36.40 (password not needed)
Deploying all public keys to all peers
Logging into 192.168.36.40
Copying public key to 192.168.36.40
Testing connection to 192.168.36.40 ...ok (config required)
Obtain everyone else's public keys (from 192.168.36.40)
Restarting replication services.
Replication has been enabled on this peer.
Press Enter to continue
After initializing the cluster, you can validate replication by using running the cluster wizard and choosing Option 5 “Check the replication status of this VCS.”. It may take up to an hour for replication to be reported successful.
You can also view cluster status from the cluster configuration page on either VCS. For example:
After configuring and initializing the cluster most admin configurations should occur on the master peer. If you connect to a non-master peer, you should see a message clearly letting you know that you should add configurations on another peer.
Wrap Up
In this example we reviewed what a VCS cluster is, how to configure a two-node cluster, and how to initialize a cluster. I plan on covering how to configure DNS and clients to take advantage of the VCS cluster redundancy in a later blog. Until then, thanks for reading.
William Bell is the Collaboration Practice Lead for Chesapeake NetCraftsmen. Bill has over 10 years of experience in the IT industry with a focus on communication and collaboration technologies. In addition to blogging on the NetCraftsmen site, Bill also maintains the UC Guerrilla blog: http://ucguerrilla.com. You can follow Bill on Twitter: @ucguerrilla