Revision as of 01:20, July 1, 2016 by Dkozlova (talk | contribs) (→‎Deploying High-Availability Chat Server)
Jump to: navigation, search

Deploying High-Availability Chat Server

Chat Server can run in high availability (HA) mode where in the case of any Chat Server failure, chat sessions can be continued on other running Chat Server instances. Run Chat Server in load-balancing mode (also known as N+1) to enable HA mode. In load-balancing mode, configure Chat Server to run all instances in primary, or active, mode with no backup applications configured.
Note: Primary and backup mode are still supported, but not recommended.

When running Chat Server in HA mode:

  • The web chat application (for instance, GMS) selects an active Chat Server instance to begin a new chat session. If the instance is interrupted during the course of the chat session, the web chat application selects another active Chat Server instance where the session will be restored and continued. At session restoration, Chat Server updates the interaction properties in Interaction Server with connection parameters that reflect the new location of the chat session.
  • Agent Desktop watches for interaction property updates. After receiving the appropriate notification, Agent Desktop reconnects to a chat session at the specified Chat Server instance.


In HA mode, after each submitted message in a chat session, Chat Server stores the intermediate chat session transcript in persistent storage.This You can configure either of the following options to store the session transcripts:

  • UCS – UCS configuration is simpler but creates an additional load on UCS and its database.
  • Cassandra – Cassandra requires special configuration but removes the load from UCS which is beneficial to deployments with high loads.

Configure Chat Server for HA

Configure as follows:

  1. Configure Primary and Backup Chat Server instances. Specify Warm Standby mode for the backup instance.
  2. Connect Web API Server to the Primary Chat Server only. Web API Server reads the information about the backup Chat Server automatically.
  3. Connect Interaction Server to the Primary Chat Server only.
  4. Set the following values for options in the settings section for both Chat Server applications:
    • session-restoration-mode = simple

      This enables Chat Server's session restoration functionality.

    • transcript-auto-save = 1

      This makes Chat Server update the transcript in UCS after each submitted message. You may also set this option to 2 (notify clients when the transcript is updated), however that would be effective only if the agent desktop can process special notifications from Chat Server (in particular, the notice ucs-save-fail/save). From the standpoint of resources, using the value 2 will slightly increase CPU usage; also Genesys Interaction Workspace does not currently support this functionality.

    • transcript-save-on-error = close

      This makes Chat Server close the chat session (without a final update in UCS) if, during the session, UCS sends a non-recoverable error message in response to one of Chat Server's periodic transcript updates.

  5. Review the values for the following options (see eServices 8.1 Reference Manual for full descriptions):
    • transcript-resend-attempts
    • transcript-resend-delay
    • transcript-save-on-error
    • transcript-save-notices

    The default values are acceptable for HA functionality; however you may wish to evaluate whether those values produce the behavior that you expect.

Deploying Chat Server with Cassandra

For high availability mode, Chat Server uses UCS to save intermediate transcripts so that chat sessions can be restored in cases of server failure or unavailability. This produces an additional load on the UCS database, especially for deployments with a high volume of customer chat interactions. To improve the performance of UCS and its database, Chat Server (starting with release 8.5.104) can use Cassandra for this functionality. With Cassandra, Chat Server requires UCS only to store the final chat transcript upon chat session completion.

Following must be done:

  • Deploy Cassandra.
  • Initialize Cassandra for Chat Server.
  • Connect Chat Server with Cassandra.

Optional: Configure secure connections to Cassandra.

Deploy Cassandra

Chat Server supports Apache Cassandra 2.2. Download the latest stable release of Cassandra 2.2.x here.

Important
For multi-node (cluster) Cassandra installation, use NTP (Network Time Protocol) to synchronize the clocks on all nodes.


Cassandra installation
For simple one-node Cassandra deployment:

  1. Modify the cassandra.yaml configuration file:
    1. Change the options seeds, listen_address, and rpc_address to the host IPv4 address.
    2. Make sure the Cassandra ports specified in cassandra.yaml do not overlap with ports used by existing applications.
  2. For load testing purposes, modify the cassandra.yaml configuration file:
    1. Change the option auto_snapshot to false.
    2. Change the option compaction_throughput_mb_per_sec to 0.
    3. Change the option write_request_timeout_in_ms to 10000.
  3. Start Cassandra node.

Initialize Cassandra for Chat Server

Initialization scripts are located in "cassandra" sub-folder of Chat Server installation folder. Run these scripts using Cassandra CQL Shell. It will create a new keyspace and the required tables. Before running scripts you need to make a decision on following:

  • Replication factor: in production, we recommend a replication_factor of at least 3. The replication strategy should be set according to the cluster and datacenter configuration.
  • Time-to-live: it is possible that in case of failures some records in Cassandra will not be deleted by Chat Server. To setup self-cleanup procedure when Cassandra will be deleting records after certain time - select appropriate script from "cassandra" sub-folder and specify desired "default_time_to_live" and "gc_grace_seconds".

Note: For version 8.5.104 of Chat Server, initialization scripts are not included with installation package. Scripts could be found here.

Connect Chat Server to Cassandra

To Connect Chat Server to Cassandra:

  1. Create and configure a Chat Server Cassandra RAP application object based on the ChatServerCassandraRAP template provided in the installation package.
    1. Configure Host in the Server Info tab to point to one of the Cassandra cluster nodes. Configure the default port to the Cassandra cluster connection port and set the Reconnect Timeout.
      Note:
      • If the contact-points option is not set, the Cassandra Cluster uses the Host defined in the Server Info tab as a contact point. If set, this option's value is used instead of the Host defined in the Server Info tab.
      • The Reconnect Attempts parameter in the Server Info tab is not used.
    2. Refer to the Options Reference Guide or the contents of ChatServerCassandraRAP.xml.
      Note:
      • In production, the recommended read and write consistency level is quorum.
  2. See Configure a secure connection to Cassandra for more information.
  3. Add a connection from each Chat Server application to the newly created Chat Server Cassandra RAP.
  4. Restart Chat Server.


Run a Test

A properly configured solution with HA mode must work without any additional configuration for other components. This section describes a simple test.

Requirements:

  • The Chat HA sample included in Web API Server
  • Interaction Workspace (agent desktop)
  • A primary/backup pair of Chat Servers

Conduct the test as follows:

  1. Start a chat session using the Chat HA web sample.
  2. Send a message to verify that the chat session is active.
  3. Then do either of the following:
    • Kill the primary Chat Server process, using Task Manager on Windows or kill -9 on UNIX (if you then restart Chat Server it should start in backup mode).
    • Switch the primary Chat Server over from primary to backup using SCI.
  4. Send a message to verify that the web sample is continuing the chat session. You will see messages showing that a user was disconnected and connected again. It is up to chat web application and/or agent desktop to decide if to show these messages.
  5. Optionally, examine the Chat Server logs to see what actions were performed by the server to restore the chat session.
Comments or questions about this documentation? Contact us for support!