Revision as of 15:21, May 23, 2018 by Pmcknigh (talk | contribs) (→‎Components)
Jump to: navigation, search

Disaster Recovery / Business Continuity

This section describes a recommended architecture to ensure successful disaster recovery, or business continuity, following a scenario in which the main site was rendered inoperable because of some natural or other disaster.

Overview

The Genesys system configuration is stored in a single database, and can be accessed by only one primary master Configuration Server connection at a time. The Configuration Database is constantly modified by Configuration Server clients, and is archived periodically to prevent the loss of data. However, database maintenance and periodic backup can cause significant downtime. It cannot prevent partial or whole loss of configuration data if a major disaster occurs, such as one in which the Configuration Database and all updates and modifications made since the last backup is completely lost. To improve the robustness of the Management Framework solution and to reduce downtime for system maintenance, this architecture replicates a secondary standby database.

Architecture

The following diagram illustrates the disaster recovery architecture for a multi-site configuration operating under normal conditions.

MF851 Dep DR-BC-arch.png

Components

Framework components for all VMs should be set up identically in this architecture.

Region 1

  • A primary DBMS, containing the Configuration Database and the Log Database (optional).
  • An active redundant master Configuration Server primary/backup (HA) pair in the Framework Virtual Machine (VM).
  • An active DB Server HA pair in the Framework VM, which is required for Configuration Server (8.1 only) to connect to Configuration Database.
  • An active Solution Control Server (SCS) in distributed mode; as the main SCS, it is required to control the main master Configuration Server pair in the Framework VM.
  • An active Message Server HA pair configured in distributed mode in the Framework VM to support communication between the Solution Control Servers that are controlling components such as Configuration Server Proxy pairs, and Log Message Servers.
  • A Local Control Agent in each VM.
  • A Configuration Server Proxy HA pair in the Voice VM and connected to the currently active primary Configuration Server.
  • A Solution Control Server HA pair in distributed mode as default in Voice VM, to control other components.
  • (Optional) A Log Message Server HA pair in both the Framework and Voice VMs for network logging, and connected to the Log Database.

Region 2

  • A secondary DBMS, containing the replicated Configuration Database and the replicated Log Database (optional), which gets updated by the primary instance in case of any changes.
  • A dormant (non-active) redundant master Configuration Server primary/backup (HA) pair in the Framework VM.
  • A dormant DB Server HA pair in the Framework VM, which is required for Configuration server (8.1 only) to connect to the Configuration Database.
  • A dormant Solution Control Server (SCS) in distributed mode; as the main SCS, it is required to control the main master Configuration Server pair in Framework VM.
  • A dormant Message Server HA pair configured in distributed mode in the Framework VM to support communication between Solution Control Servers controlling components, such as Configuration Server Proxy pairs and Log Message Servers.
  • A Local Control Agent in each VM.
  • Configuration Server Proxy HA pair in the Voice VM and connected to the currently active primary Configuration Server.
  • A Solution Control Server HA pair in distributed mode as default in the Voice VM, to control other components.
  • (Optional) A Log Message Server HA Pair in both the Framework and Voice VMs for network logging, and connected to the Log Database.
Comments or questions about this documentation? Contact us for support!