A basic Advisors setup is one in which there are no backup servers configured to support failover.
Integration with Solution Control Server and Warm Standby
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 a Genesys configuration interface, such as Genesys Administrator. LCA, SCS, and the management interface manage the primary/backup pair of applications.
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.
Integration with Solution Control Server
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.
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 Advisors 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 Advisors 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 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 Advisors 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 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.
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.
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.
In an HA deployment of Advisors, failover from the primary system to the backup system might occur for the following reasons.
|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.
ImportantDatabase 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.