Building the Standby CommServe Host Using Basic Configuration

In a basic configuration, you can use the Microsoft SQL Server Agent to stage the production CommServe databases on the standby CommServe host by scheduling frequent backups and restores of production databases and logs .

The production CommServe host is the active node, where regular backups and restore operations are scheduled to run from the CommServe client. You can create a new CommServe host or use an existing CommServe host for the configuration.

To build a standby CommServe host by using the basic configuration, complete the following steps:

Note: You can also use the following predefined workflows to build the standby CommServe host using basic configuration.

Step1: Review the Requirements

Review the hardware and software requirements for failover configuration as discussed in System Requirements.

Step 2: Install the CommServe Software

Production CommServe Host

Review the CommServe Installation: Considerations for Disaster Recovery Failover, and then install the CommServe software on the production host.

You can also use an existing production CommServe host for the configuration.

Standby CommServe Host

Review the CommServe Installation: Considerations for Disaster Recovery Failover, and then install the CommServe software on the standby host.

Note: Make sure to use the same CommServe client name on both production and standby hosts.

After install, stop services on the standby CommServe host.

Note: All the latest software updates installed on the production CommServe host must be installed on the standby CommServe host. The standby CommServe database may not perform the CommCell operations unless you install all the updates on the standby CommServe host. For more information, see, Installing Updates on the Standby CommServe Host.

Step 3: Optional: Configuring a Floating CommServe Host Name

In large CommCell environment with several clients, you can minimize the down time for failover by configuring a floating CommServe host name on your DNS server.

Using this setup, you can fail over all clients that point to the floating CommServe host name to the standby CommServe host simultaneously with minimum down time.

A floating CommServe host name is a virtual host name that is used by all clients and MediaAgents to communicate to the active CommServe host. If you have a DNS setup, you can add an entry in the DNS Server for the floating CommServe host name that points to the active CommServe host.

Note: For basic configurations, the CommServe host name on the production and standby hosts must be different from the floating CommServe host name.

For example, the production CommServe host name is maincs.company.com and the standby CommServe host name is standbycs.company.com. The floating CommServe host name to be used can be prodcs.company.com.

Expand All

New Production CommServe Host:

If you installed a new production CommServe host, complete the following steps:

  1. Create a DNS A record with a virtual host name that points to the IP address of the production CommServe host. See Creating a DNS A Record.

    The virtual host name is used as the floating CommServe host name.

    Note: Record the floating CommServe host name. This information is required during the installation of the MediaAgent and clients.

  2. Install the MediaAgent on a separate computer at the standby CommServe location.
  3. Install new clients.

    Note: Provide the floating CommServe host name when installing the MediaAgent and clients.

Existing Production CommServe Host:

If you have an existing production CommServe computer, complete the following steps to configure the floating CommServe host name by using the existing CommServe host name:

  1. Perform a disaster recovery backup of the production CommServe host.
  2. Verify that all clients and MediaAgents are pointing to the production (existing) CommServe host name.

    For more information, see Updating the CommServe Name for Clients and MediaAgents.

  3. Disable all CommCell operations on the production CommServe host.

    For information on how to disable the operations, see Activity Control - Getting Started.

  4. If the CommServe client name and host name are same as the computer host name, then rename the existing CommServe computer host name. For information on how to change the computer host name of a Windows Server, see Microsoft documentation.

    If the client name and host name are different from the computer host name then skip this step.

    Note: After a reboot, the computer host name will be renamed to the new name. But, the CommServe still uses the old host name. The old name is used as a floating CommServe host name during this set up.

  5. Use the SetPreImagedNames tool to change the CommServe host name.

    At the command line on the production CommServe host, run the following command:

    Installation_Directory/Base>SetPreImagedNames.exe CSNAME -instance instance001 -hostname new_host_name old_host_name -passiveCS

    where,

    new_host_name and old_host_name are the new and old host names of the CommServe computer, entered in the computer.domain.company.com format.

  6. Create a DNS A Record with the old CommServe host name and IP address of the production CommServe host. See Creating a DNS A Record.
  7. Enable all CommCell operations on the production CommServe host. See Activity Control - Getting Started.
  8. Perform a disaster recovery backup of the production CommServe host.

Step 4: Install and Configure the SQL Server Agent

Complete the following steps to install and configure the SQL Server Agent on the production and standby hosts.

  1. Install the SQL Server Agent on a new instance on the CommServe hosts.

    For information about installing the agent, see SQL Server Agent Installation: Considerations for Disaster Recovery Failover.

  2. Create a SQL Server agent subclient for the second instance of both the production and standby CommServe clients.

    For instructions, see Configure a SQL Server Agent Subclient to Backup the CommServe Databases.

Step 5: Create Client Computer Groups

Create separate client computer groups for test failover and actual failover.

Note: If you are using a floating CommServe host name, make sure the clients added to these groups point to the physical host name of the active CommServe host and not the floating CommServe host name.

For Failover Testing

Create a new client computer group on the production CommServe host and add clients to be used for failover testing. When adding test clients, also make sure to add the MediaAgent that is used by the test clients to the client computer group.

Best Practice: Install a new test client and MediaAgent and add them to the client computer group. Run backups on the new test client by using the test MediaAgent.

For Actual Failover

Create another client computer group for actual failover and include the second instance of CommServe clients and the MediaAgent that are used for SQL backup and restore operations.

You can also add other clients and MediaAgents that are not part of any DNS and require continued access to the CommServe software. During an actual failover, the CommServe name on the clients and MediaAgents is updated to the standby CommServe host.

Remember: If you have several clients in the client computer group, it will be a time consuming task to update the CommServe host name on all the clients.

Step 6: Install and Configure the CommServe Failover Component

Complete the following steps to install and configure the CommServe Failover component on both the production and the standby hosts.

  1. Install the CommServe Failover Component on the second instance (where SQL Agent is installed) on the CommServe hosts.
  2. Configure the CommServe Failover Component with basic configuration type.

Step 7: Synchronize the CommServe Databases

Back up and restore the production CommServe databases to the standby CommServe host.

For instructions, see Synchronize the CommServe Databases.

Step 8: Create Backup and Restore Schedules

  1. Create separate backup schedules for the production CommServe databases and transaction logs. For instructions, see Scheduling a Backup.

    When scheduling log backups, select the Transaction Log option as the backup type.

    Best Practices:

    • Schedule full database backups once a week and transaction log backups every 30 minutes.

      Important: Perform frequent transaction log backups on the production CommServe host; otherwise, you may lose some metadata when you shift CommCell operations to the standby CommServe host. You may also experience transaction log growth on the production CommServe host.

    • Depending on the backup schedule frequency, set the aging rules for the storage policy. For example, if you are scheduling full database backups once every week, set the backup retention to 7 days and 1 cycle.

      Ensure that the storage policy uses a MediaAgent located at the standby CommServe location.

  2. Create restore schedules to restore the transaction logs after each backup.

    For instructions, see Scheduling Restores for SQL Transaction Logs.

Additional Configurations

Using Customized Scripts

If you do not want to change the CommServe name on the clients, or change the DNS manually, you can configure the failover component to use customized scripts for updating DNS records. For more information on configuring failover parameters, see Failover Configuration Parameters.

Note: If the DNS server name changes, run the cvfailover_config.cmd to update the host name or modify the domainServerName parameter in the cvfailover.cfg file with the new host name or IP address.

Configuring a Proxy

If you have a firewall configured between existing clients and the CommServe host, you can use a proxy exclusively for disaster recovery purpose and route requests and responses between the CommServe and the proxy-enabled clients. Since the clients and CommServe communicate through the proxy, during a fail over, you will not require to update the DNS with the IP address of the current active CommServe host. For instructions on configuring a proxy for disaster recovery, see Using SnapProtect Proxy for Disaster Recovery.

Related Topics

Moving CommCell Operations to Standby CommServe Host: Basic Failover