Jump to: navigation, search

Cold Standby Configuration and Switchover

Performance Management Advisors support cold standby High Availability starting in release 8.5.0. Cold standby means you have redundant servers available for each of the nodes in the Platform database's Cluster_Member table for which you require backup, and also for any data adapters (Advisors Genesys Adapter or Advisors Cisco Adapter) configured in the system. When an Advisors component or its host server fails, you switch over to the backup system.

You can install the backup system before the primary goes down, or after the primary fails. In either case, after the backup system is installed, you need only make small manual adjustments in the Platform database to replace the primary server with the backup server, and back again.

Note that starting in release 8.5.1, Advisors support warm standby HA for certain modules, integrating with Solution Control Server. See Integration with Solution Control Server and Warm Standby.

<tabber>

Install Redundant Servers=

1. Review the list of nodes in the Advisors Platform database Cluster_Member table, and then identify a backup server machine for each node for which you require a backup.
2. On each backup machine, install the same Advisors components that are installed on the primary machine. Use the installer properties files (ant.install.properties) from the original system.

3. For pre-installing the backups, ensure that the Cluster_Node page attributes are exactly the same on the backup as they were for the primary; that is, do not change the node name or host values. Using the identical configuration ensures the backup system installation does not overwrite the primary. You can change the following, if necessary, on the backup machine, but it is very important that you do not change any other installer options:

  • the installation path
  • the Java path
  • the folder from which the Oracle JDBC driver is provided to the installer
  • the log folder, depending on your file folder structure
4. Follow Step 3 for data adapters (Advisors Genesys Adapter or Advisors Cisco Adapter). Again, do not change the host values or names of the adapters on their registration pages.
5. Run the primary system.
6. If a primary system fails and you must switch over to the backup, follow the relevant procedure on the other tabs of this page.

|-| Switchover on a Cluster Node Server=

If the primary server, or the platform service on a primary server goes down, use the following procedure to switch over to the redundant system. This procedure assumes the redundant server is installed. See the procedure on the Install Redundant Servers tab if you have not already installed the backup system.

1. Stop the system service on all other Advisors nodes in the deployment. The data adapters can continue to run, but you will have to restart them later.
2. Update the row in the Platform database Cluster_Member table that identifies the failed node; set the IP_Address column to the IP or hostname of the backup server for that node. If you use an Oracle database, commit the changes.
3. Update any affected addresses for ProxyPass entries in the Apache configuration file (httpd.conf) so that they point to the backup server. See information on the HA and Apache Server tab.
4. Restart the system service on all data adapters.
5. Start the main Advisors Platform node first (the node on which you installed the administration workbench), regardless of whether it is a primary or a backup node.
6. Follow the Advisors startup sequence to bring the full deployment back up, starting the other nodes on their respective servers in the correct order, and depending on which components you have installed:
  1. Main (administration) Platform
  2. Apache service
  3. AGA for FA, if present
  4. AGA for CCAdv, if present
  5. CCAdv Web services, if not on the administration node
  6. FA Platform
  7. WA server, if present
  8. XML Generator Platform, if it is different from the administration Platform
  9. WA Web service, if not on the WA Platform
  10. SDS, if present
  11. XML Generator service
7. Users that were logged into the Advisors interface must log out, or close their browsers, and then log in again.

|-| Switchover on an Adapter=

If a data adapter (Advisors Genesys Adapter or Advisors Cisco Adapter) or its host server fails, use the following procedure to switch over to the redundant adapter/server.

To switch over from a backup adapter to the primary adapter again, you use the same procedure, but there is no need to update the inf_genesys_adapter.properties file on the primary server. That server's properties file was not changed during the switch over to the backup adapter; it therefore contains the correct information.

1. Stop the system service for all other adapters and all Advisors nodes in the deployment (you must restart nodes that depend on the adapters, and therefore all other nodes, as well).

2. In the Platform database Adapter_Instances table, identify the record that corresponds to the adapter that needs to be switched over. Update the Host property of this record to that of the redundant system's host name or IP address. Commit the change, if necessary.

3. On the redundant adapter server, open the inf_genesys_adapter.properties file (in the Advisors installation /conf folder). Update the following line to point to the redundant server's host name or IP address; if you used an IP address in Step 2, you must use the IP address here (the same is true of the host name – you must use the same type of entry in both locations):
informiam.genesys_connector.host.name =

4. Repeat the preceding Steps (2 and 3) for each adapter instance that you want to switch over to its backup system.
5. Start the redundant adapters, and then restart all other adapters.
6. Restart the system service for each node in the correct Advisors startup sequence:
  1. Main (administration) Platform
  2. Apache service
  3. AGA for FA, if present
  4. AGA for CCAdv, if present
  5. CCAdv Web services, if not on the administration node
  6. FA Platform
  7. WA server, if present
  8. XML Generator Platform, if it is different from the administration Platform
  9. WA Web service, if not on the WA Platform
  10. SDS, if present
  11. XML Generator service
6. Users that were logged into the Advisors interface must log out, or close their browsers, and then log in again.

|-| HA and Apache Server=

If you move any Advisors node to a backup server, you must update the ProxyPass section of the Apache server configuration file (httpd.conf). It is important that you find every instance of the IP address or host name of the system that is being replaced, and change those instances to the IP address or host name of the system that you have configured as the backup.

After you complete and save updates to the Apache Server configuration file, stop and then restart the Apache service.

|-| HA and RMC=

The Supervisor Desktop Service (SDS) server that supports the Resource Management Console (RMC) has no inherent High Availability (HA) capability. Loss of the SDS server requires recovery of the service or machine, or a redundant SDS installation with the same configuration as the existing SDS installation (that is, it must point to the same Configuration Server, Stat Server(s), and TServer(s)), and with the same permission structure.

If you transfer from one SDS server to another, you must update the RMCInfo.xml file in the RMC installation to point to the new SDS instance. Instructions are available in the Deploying SDS and RMC section of the Performance Management Advisors Deployment Guide.

If your Advisors deployment uses RMC, Genesys strongly advises you to install the CCAdv Web services component into the Advisors Platform instance where the administration workbench is installed because RMC uses objects in both the workbench and in the Web services. RMC cannot connect to both sets of objects if the workbench and Web services are on different servers.

If you install RMC with both the administration workbench and CCAdv Web Services, RMC is supported for HA along with the entire node.

This page was last edited on March 27, 2015, at 20:17.
Comments or questions about this documentation? Contact us for support!