Restore Master VCS

[CGL]

Hi All,

We have recently had our master VCS C go down and are currently running off the slave system. 

These are both Gen 1 Appliances and as a temporary fix until they are migrated to VM in the near future we are replacing the Master VCS with another Gen1 appliance that we have. 

I have had the licensing migrated to the new serial but would like to confirm that all I will need to do now is restore the previous back up to the new VCS and power it on and it will re cluster with the slave and take over again as the master? 

Is the process this simple or is there additional configuration that needs to be done ?

Any advice on restoring a cluster from first hand experience would be great. 

Thanks so much. 

[Anurag Srivastava1]

Hello 

I will need to do now is restore the previous back up to the new VCS and power it on and it will re cluster with the slave and take over again as the master? ---> That will work also make sure the software version is same on new server else the restore will not work.

Also you can follow the procedure in the below link to be safe side-(Replace a Peer And Keep Its Configuration)

https://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/vcs/config_guide/X8-9/Cisco-VCS-Cluster-Creation-and-Maintenance-Deployment-Guide-X8-9-2.pdf

Thanks

Please rate if it is helpful and mark as accepted solution if applicable...

[JJ77]

100% agree with Anurag's response.However i would like to bring up the following pre-requisite and this needs to be checked even before you start clustering it 

Clustering Prerequisites
Before setting up a cluster of X8.9.2 VCS peers or adding an X8.9.2 VCS to a cluster, ensure that:
Platform and Software Versions Match
■ All clusters peers are running the same version of code. The only occasion where different peers are allowed
to run different versions of code is for the short period of time while a cluster is being upgraded from one
version of code to another, during which time the cluster will operate in a partitioned fashion.
■ Each peer is using a hardware platform (appliance or virtual machine) with equivalent capabilities; for
example, you can cluster peers that are running on standard appliances with peers running on 2 core Medium
VMs, but you cannot cluster a peer running on a standard appliance with peers running on 8 core Large VMs.
Network Conditions Are Met
■ Each peer has a different LAN configuration (a different IPv4 address and a different IPv6 address, where
enabled).
■ Each peer in a cluster is within a 15ms hop (30ms round trip delay) of each and every other VCS in or to be
added to the cluster.
■ Each peer in a cluster is directly routable to each and every other VCS in or to be added to the cluster. (There
must be no NAT between cluster peers – if there is a firewall ensure that the required ports are opened.)
Basic Configuration Is Done
■ Each peer has a different system name to all other peers.
■ Each peer has a certificate that identifies it to other peers, creating unauthenticated TLS connections
between peers (default of TLS verification mode set to Permissive).
If you wish to have authenticated TLS connections, the certificate must also be valid and be issued by an
authority that is trusted by all peers (TLS Verification mode set to Enforce).
We recommend populating the CN of all peer certificates with the same cluster FQDN, and populating each
peer certificate's SAN with that peer's FQDN.
■ All peers have the same set of option keys installed, with the following exceptions:
— Traversal and non-traversal call licenses
— TURN relay licenses
All other license keys must be identical on each peer.
Note: Installing some types of option keys requires you to restart the VCS.
■ H.323 mode is enabled on each peer (Configuration > Protocols > H.323, and for H.323 mode select On).
The cluster uses H.323 signaling between peers to determine the best route for calls, even if all endpoints are
SIP endpoints.
DNS Configuration is Done
DNS server configuration does not replicate so you must enter the DNS server address(es) on each peer.
■ The DNS servers used by the VCS peers must support both forward and reverse DNS lookups of Cisco TMS
and all VCS peer addresses; the DNS servers must also provide address lookup for any other DNS functionality
required, such as:
— NTP servers or the external manager if they configured using DNS names
— Microsoft FE Server FQDN lookup
— LDAP server forward and reverse lookup (reverse lookups are frequently provided through PTR records)