Integration with Solution Control Server and Warm Standby

Starting in release 8.5.1, Performance Management Advisors support warm standby – a form of high availability (HA) in which a backup server application remains initialized and ready to take over the operations of the primary server. Warm standby mode does not ensure the continuation of interactions in progress when a failure occurs.

In a Genesys environment, an application that supports HA is typically integrated with the Genesys Management Layer, specifically the Local Control Agent (LCA), the Solution Control Server (SCS), and the Genesys Administrator or Configuration Manager. LCA, SCS, and the management interface manage the primary/backup pair of applications.

In release 8.5.1, the Advisors modules that support warm standby must be integrated with and installed with the LCA and SCS, even if you do not have a licence for an HA deployment.

Additional Information

For information about Genesys Management Layer, see Management Framework Deployment Guide and Management Layer User's Guide.

Integration with Solution Control Server

Starting in release 8.5.1 some Advisors modules must integrate with the Solution Control Server, while others do not need to. For those that do, you must create Application and Host objects for those modules whether you are installing a basic deployment or a warm standby deployment. See the following sections for the list of modules that require integration with the management layer and the list of modules that do not.

[+] Advisors Modules Controlled by SCS

In release 8.5.1, the following Advisors modules are integrated with the LCA, SCS, and the Genesys Management Layer user interface (Genesys Administrator or Configuration Manager) to support warm standby.

• Advisors Genesys Adapter
• Advisors CISCO Adapter
• Contact Center Advisor XML Generator
• Workforce Advisor WA Server
• Frontline Advisor FA Server (that is, FA with the rollup engine)

Because the preceding modules are integrated with the Management Layer, proceed as follows. For exact instructions on carrying out the following tasks, see Deploying Components Controlled by Solution Control Server.

• install and run the LCA on a system that runs any of the preceding modules
• configure a Host for the system in Configuration Manager or Genesys Administrator
• configure an Application in Configuration Manager or Genesys Administrator for each Advisors server that runs one or more of the preceding modules
• if you have a licence for an HA deployment, configure a second Application in Configuration Manager or Genesys Administrator for the secondary server, and associate the two Applications as a primary and backup pair for failover
• specify the properties, during installation, that permit the Advisors server to integrate with the LCA, SCS, the Application, and the Host
• do not create a Windows or Linux service to control this module, because SCS will control it.

[+] Advisors Modules Not Controlled by SCS

The following Advisors modules are not controlled by SCS. They have been automatically highly-available since release 8.1.5, because you can install each of these modules on more than one system – you do not configure them as primary-backup pairs:

• Contact Center Advisor Web Services
• Workforce Advisor Web Services
• Frontline Advisor FA Web Services (that is, FA without the rollup engine and installed as a cluster member)
• Contact Center Advisor–Mobile Edition Server

Because the preceding modules are independent of LCA, SCS, or other parts of the Management Layer:

• it is unnecessary to install the LCA on a system that runs any of the preceding modules
• it is unnecessary to configure a Host or Application for the system or module in Configuration Manager or Genesys Administrator.
• you must create a Windows or Linux service to control this module, because SCS will not control it.

[+] Advisors Modules that do not Support HA

The following Advisors modules are not automatically highly-available in release 8.5.1:

• Advisors Administration module
• Resource Management Console

Tip

You can use different operating systems on primary and backup servers. For example, the host for your primary instance of the WA server can be a Windows-based system, while the host running the backup instance of the WA server uses a Linux platform.

Limitations and Special Configuration

Does Not Support Stop Gracefully

Advisors do not support the Stop Gracefully functionality available in the Solution Control Server UI. If you choose Stop Gracefully, it is the same as choosing Stop.

Multiple Advisors Servers on One System

You can install more than one Advisors server, all part of the same cluster, on one system.

For example, you can install both CCAdv XML Generator and WA Server on one system. XML Generator does not require Advisors Platform to run, but the WA Server does.

For this deployment, you must create two Application objects in Configuration Server. One Application object is for CCAdv XML Generator, and the other is for the Geronimo instance that runs WA Server.

For a diagram illustrating such a deployment, see Applications, Advisors Servers, and Cluster Nodes.

Separating Advisors Servers that SCS Controls from Those That It Does Not

Genesys recommends that you install the Advisors modules that SCS controls, and the modules that it does not, on different systems. For example, Genesys recommends that you not install Workforce Advisor WA Server and Workforce Advisor Web Services on the same system. This is because it is easier to think about the deployment of Advisors if you keep them separate.

For example, imagine the following: you install WA Server and WA Web services on the same system, in one Advisors server. Because that server runs WA Server, it must be controlled by SCS via an application in the CME. WA Server communicates with SCS and indicates its status in the SCI, but WA web services does not communicate with SCS.

Here are some consequences of that:

• If WA web services fails and stops sending data to WA dashboards, the SCS UI will not indicate this. The application's status in the SCS UI will be Running.
• In the SCS UI, the execution mode of the application will not always reflect the state of WA Web Services. For example, if the application's execution mode is Backup, WA Web Services will still actually be running and will respond to requests from dashboards. This is because the module does not know about execution modes, and is not controlled by SCS.

If you think you can keep such things in mind and deal with the consequences, feel free to combine the installation of Advisors modules in servers however you please.

Advisors Genesys Adapter

When configuring AGA instances on primary and backup systems, use the following rules:

• Configure the same number of adapter instances on both the systems. For example, if the primary system has two CCAdv/WA adapters, then the backup system should also have two adapters for CCAdv/WA.
• Configure the same Stat Servers exactly on the adapters of the two systems.

Frontline Advisor

Frontline Advisor requires integration with SCS and supports HA only when installed with the FA rollup engine. The following two configurations do this.

• FA installed as a cluster member with the rollup engine.
• FA installed standalone, which automatically includes the rollup engine.

Administration Module

The Advisors Administration module does not have separate warm standby configuration. The following sections describe the two HA solutions for the Administration module.

Fellow-Traveller Warm Standby

You could install the Administration module on the same system with either WA Server or FA with the rollup engine. Because the resulting Advisors server communicates with LCA and SCS, it does support warm standby. If that server fails, SCS will fail over to its backup, on which you have installed the same Advisors modules, including the Administration module.

The Administration module can sync Person objects from Configuration Server and users in the Platform database. Only one Advisors server should be configured to perform this task. In this scenario, configure only one of the servers to do this. The reason is that the Administration module does not know about execution modes. If both primary and backup servers are configured to synch users, and both servers are started at the same time, both will synch users at the same time, and both will fail.

Cold Standby

Deploy a second installation of the module, with the platform to support it. If the primary installation fails, manually switch to the second installation, as described in Cold Standby Configuration and Switchover.

Warm Standby and the FA Admin

When a deployment of Advisors includes Frontline Advisor, then in the Administration module, there is an FA Admin command in the navigation menu.

That command takes you to the FA Administration pages.

The functionality for the FA Admin pages is not in the Administration module. Instead, it is included in the same server as the FA Server. This is a requirement for the FA Administration to operate. This means that if primary and backup FA Server installations exist, then primary and backup FA Admin modules also exist.

Failover Scenarios

In an HA deployment of Advisors, failover from the primary system to the backup system might occur for the following reasons.

Problem	Solution
Machine or Virtual machine (VM) is not available.	Processing fails over to the waiting backup VM or machine running the same modules.
An Advisors server is not available, although the VM is still running.	Processing fails over to a similarly-configured backup server on another VM or machine.
An important process in the Advisors server does not complete before a timeout period. The process, and the timeout period, are different for the various Advisors modules.	Processing fails over to a similarly-configured backup server on another VM or machine.

An Advisors server does not fail over from primary to backup if the reason for the failure is something that would also cause the backup to fail. In this case, there is no point failing over.

Contact Center Advisor XML Generator does not fail over from primary to backup if its connections to a database fail. Functionality in XML Generator from before 8.5.1 re-tries the connections to the database for a configured interval, until the connection is restored.

Managing Failover with the Solution Control Server

As with other Genesys products, the SCS manages failovers for primary-backup pairs. You can use Genesys Administrator or the Solution Control Interface (SCI) to manually switch processing from the primary Application to the backup, or to stop or start a primary or backup Application. See also Deploying Components Controlled by Solution Control Server, particularly Step 6 of the procedure.

The SCS controls the request to fail over, however the primary and backup server in a pair also communicate with each other, as a backup mechanism for failover. This is important because the SCS or LCA can sometimes fail, or a network communication path between the server and the SCS can fail.

Advisors Warm Standby and Databases

All Advisors components are designed to restore the loss of database connectivity automatically. Ensure a backup Advisors application instance uses the same database as the primary application instance.

The solution for High availability of the Advisors databases relies on the respective database vendor's solutions. Advisors support the following HA solutions for databases:

• Oracle Database with Oracle Real Application Clusters (Oracle RAC) and combinations with RAC for scalability and disaster recovery offered by Oracle.
• Microsoft SQL Server Failover Cluster. Advisors databases can be installed on a Failover Cluster Instance (FCI) where FCI is a single instance installed across Windows Server Failover Clustering (WSFC) nodes. MSSQL 2012 FCI with multiple subnets is also supported.
  Important

  Database mirroring, log shipping, and MSSQL 2012 AlwaysOn Availability Groups feature are not supported because of the Simple recovery model requirement for all Advisors MSSQL databases.