Business Edition Premise High Availability Blueprint. White Paper. Version 1.0

Transcription

1 Business Edition Premise High Availability Blueprint White Paper Version 1.0

2 The information contained herein is proprietary and confidential and cannot be disclosed or duplicated without the prior written consent of Genesys Telecommunications Laboratories, Inc. Copyright 2017 Genesys Telecommunications Laboratories, Inc. All rights reserved. About Genesys Genesys is the world's leading provider of customer service and contact center software - with more than 4,000 customers in 80 countries. Drawing on its more than 20 years of customer service innovation and experience, Genesys is uniquely positioned to help companies bring their people, insights and customer channels together to effectively drive today's customer conversation. Genesys software directs more than 100 million interactions every day, maximizing the value of customer engagement and differentiating the experience by driving personalization and multichannel customer service - and extending customer service across the enterprise to optimize processes and the performance of customer-facing employees. Go to for more information. Each product has its own documentation for online viewing at the Genesys Documentation website or on the Documentation Library DVD, which is available from Genesys upon request. For more information, contact your sales representative. Notice Although reasonable effort is made to ensure that the information in this document is complete and accurate at the time of release, Genesys Telecommunications Laboratories, Inc. cannot assume responsibility for any existing errors. Changes and/or corrections to the information contained in this document may be incorporated in future versions. Your Responsibility for Your System s Security You are responsible for the security of your system. Product administration to prevent unauthorized use is your responsibility. Your system administrator should read all documents provided with this product to fully understand the features available that reduce your risk of incurring charges for unlicensed use of Genesys products. Trademarks Genesys and the Genesys logo are registered trademarks of Genesys Telecommunications Laboratories, Inc. All other company names and logos may be trademarks or registered trademarks of their respective holders. Genesys Business Edition Premise High Availability Blueprint Page 2 of 32

3 Table of Contents Table of Contents Introduction Solution Architecture HA Deployment View... 6 Application Layer HA... 9 Data Layer HA Voice Layer HA SIP Server HA Digital Layer HA Server Chat Server Workspace Implementation Details Database Steps Migration POSTGRESQL DB to MSSQL DB. (BEP configuration DB) Create Mirroring Certificates and Endpoints Create Accounts for Mirroring Backup Databases and Logs Restore Backups to the Mirrored Instance Activate Mirroring Monitoring SQL Servers & Force Role Switch SQL Connections for Mirroring Voice Configuration Details Digital Channels Configuration Appendix A: Alternative HA Architectures vsphere Fault Tolerant for BEP Rationale References Genesys HA for BEP Rationale Appendix B: References Genesys Business Edition Premise High Availability Blueprint Page 3 of 32

4 1 Introduction This document describes a standard approach to deploying Genesys Business Edition Premise (BEP) in High Availability (HA) mode. The goal of this solution is to reduce downtime, maintain voice traffic and protect data in case of various failure scenarios. High Availability can have multiple meanings. In this case, HA refers to the availability of a service within a single data center. Dual or multiple data center redundancy is typically referred to as either Disaster Recovery or Business Continuity within Genesys and is beyond the scope of this document. The solution assumes two BEP instances are deployed on separate hardware machines within a single data center. As BEP is designed to minimize costs to the customer, this solution will focus on cost-efficient methods of achieving HA, noting that there are many expensive methods that can ensure a higher level of availability. The Business Edition Premise High Availability Blueprint is intended to provide guidance to Solution Consultants, Professional Services, and partners when designing and deploying BEP. 2 Solution Architecture The BEP HA solution is based on traditional Genesys HA concepts and components along with database replication technology. There are other alternative solutions available (please see Appendix A), but they rely on VMware and other tools that raise the overall total costs (TCO). The overall solution should consist of two BEP (ESX) machines - each containing the BEP Virtual Machines (VMs). One machine contains BEP/Genesys components that are setup as primary instances while the second machine contains backup instances. Note that the Solution Control Server (SCS) application is the exception the primary instance needs to be deployed on the secondary machine and the backup instance should be deployed on the primary machine. Also note that there are some components that should operate in an active/active mode across the two machines. Genesys Business Edition Premise High Availability Blueprint Page 4 of 32

5 The following diagram depicts the overall solution architecture: BEP comes with an instance of Microsoft SQL Server to support the BEP data requirements. There are many customers that already have licenses for SQL Server and would prefer to use their existing SQL Server infrastructure for storing the Genesys BEP data. For those customers, moving BEP data into those database systems and configuring the appropriate database connections within the Genesys environment is fully supported. Note that the customer is then responsible for protecting that data and making it highly available using either database mirroring or Always On clustering. Genesys Business Edition Premise High Availability Blueprint Page 5 of 32

6 The HA solution with a customer provided MS SQL Server is depicted in the following diagram: In both cases, voice and digital ( , chat, etc) traffic are sent to the appropriate BEP components within the Primary BEP during normal operations. If a failure happens, the backup components in the Secondary BEP take over and traffic is diverted to those components. Details will be provided in the next section. BEP data will be mirrored between the Primary and Secondary BEP machines. During a failure, the mirrored database becomes the principal database and handles subsequent queries and updates. If the customer uses their own SQL Server infrastructure, they can use mirroring or clustering to provide similar functionality. 3 HA Deployment View The BEP/Genesys architecture consists of various layers. To make BEP highly available, we need to setup and configure HA for each of these layers. Genesys Business Edition Premise High Availability Blueprint Page 6 of 32

7 The following diagram shows the layers of Genesys BEP at a high level. There is the Application Layer that provides the key business functionality for the overall system. There is a Media Layer that handles the various voice and digital traffic between the customers, agents, and BEP. And finally, there is the Data Layer that stores all BEP related information. BEP also consists of various VM images that contain the various Genesys products contained within the overall solution. These are shown in the diagram on the next page. Genesys Business Edition Premise High Availability Blueprint Page 7 of 32

8 Genesys Business Edition Premise High Availability Blueprint Page 8 of 32

9 Application Layer HA The first step in deploying the BEP HA solution is to set up the Secondary BEP machine (assuming the Primary BEP machine is already configured). As of this writing, the BEP setup does not account for HA configurations. Therefore, the second BEP needs to be set up using the standard BEP installation and tuneup (as documented in Business Edition Premise Provider's Guide) and then modified. The following changes need to be made at the application layer of BEP: The Config Server on the Secondary BEP needs to be set to Backup mode for the primary Config Server on the Primary BEP All applications on the Secondary BEP need to be configured using the Primary BEP's Config Server. In general, most applications that support hot standby mode will have their instance on the Secondary BEP set to backup mode. The primary Solution Control Server (SCS) must be configured on the Secondary BEP (ESXi 2) and its backup SCS setup on ESXi1. This is to ensure that network isolation does not prevent the appropriate switchover to happen. Genesys InfoMart (GIM) should be disabled on ESXi-2 as it operates in a cold standby mode. The following applications support Active-Active mode and need to be configured as such: Orchestration Server (ORS), Resource Manager, Genesys Voice Media Control Platform (MCP), Genesys Mobile Services (GMS), Chat Server, ICON for SIP, ICON for Digital. Genesys Business Edition Premise High Availability Blueprint Page 9 of 32

10 Once completed, the two BEP ESXi machines should resemble the following diagram: Note: Primary and Backup instances are denoted with -P and -B suffix respectively. Where a process can be deployed in active/active mode, the instances are denoted with a numeric suffix. Windows Registry & Services In addition to the Genesys configuration, modifications to the Windows Registry are required. If the Genesys applications have been setup as Windows Services, the Services command for those applications may also need to be modified to ensure the proper startup parameters/options. Genesys Business Edition Premise High Availability Blueprint Page 10 of 32

11 Data Layer HA As of this writing, Genesys BEP stores data in both Postgres and MS SQL Server databases. To facilitate replication and data availability, all data needs to move from Postgres into the MS SQL Server database. The Postgres can be shutdown and/or removed. Note that the BEP tuneup procedure should be executed first before moving the data out of Postgres. After the data has been moved into SQL Server, database mirroring needs to be configured between the two SQL Server instances on ESXi-1 and ESXi-2. See Implementation Details for more information on setting up mirroring. Genesys Business Edition Premise High Availability Blueprint Page 11 of 32

12 As mentioned earlier, BEP comes with an instance of Microsoft SQL Server, and there are many customers that would prefer to use their existing SQL Server infrastructure. In this case, the Postgres data and BEP SQL Server data should be moved into the customers' SQL Server databases. All database connections within the Genesys environment need to be configured to retrieve data from the appropriate SQL Server instances. Data layer HA is then the customer's responsibility. They can use the database mirroring described here or use alternative methods (such as Always-On database clustering) as supported by their Microsoft licenses. Note: As mentioned above, the BEP tuneup procedure must be executed first before moving the data. Genesys Business Edition Premise High Availability Blueprint Page 12 of 32

13 Cassandra Data Many Genesys applications can also use Cassandra for data storage. As of this writing, the base components of BEP do not require Cassandra. If a Genesys BEP deployment is enhanced with an application that does require a Cassandra data store, a Cassandra ring needs to be installed in the customers' environment, following best practices. Genesys Business Edition Premise High Availability Blueprint Page 13 of 32

14 Voice Layer HA A typical network for VoIP will have a Media Gateway (MGW) connecting the PSTN to the internal IP network or a Session Border Controller (SBC) to a SIP Trunk provided by the customer's carrier. The SBC/MGW must be configured to forward the VoIP traffic (SIP and RTP) into Genesys BEP, keeping in mind that the SBC/MGW may also be deployed in a highly available topology SIP Server HA Within Genesys, the SIP Server provides control of the VoIP traffic. There are multiple ways to make SIP Server highly available which are documented here. There are two approaches: SIP Proxy and Virtual IP Takeover SIP Proxy SIP Proxy is the preferred approach to VoIP HA as it avoids the reliance on scripts and configuring Virtual IP Addresses on NIC cards. A cluster of SIP Proxies is created that monitors the primary and backup SIP Servers and performs switchover when the primary becomes inactive. For BEP, this requires the installation of SIP Proxy into the Core VM on both BEP machines. A fully qualified domain name (FQDN) needs to be assigned to the SIP Proxies and configured within the SIP Servers Outbound Proxy DN. More information: Description of SIP Proxy Configuring SIP Proxy Virtual IP Takeover Virtual IP Takeover is provided as an alternative approach to SIP Proxy. It requires less resources than SIP Proxy but also requires scripting and configuration of Virtual IP addresses which can be error prone (although it has been successfully deployed in many environments). A Virtual IP address (VIP) is created as the SIP address to be used by all SIP endpoints and gateways. This will be the address to configure within the SBC/MGW and SIP phones. The Virtual IP address is added to the NIC of the primary BEP/SIP server. A script is required to handle failover - the script needs to delete the VIP from the primary SIP server and add it to the backup server. Genesys Business Edition Premise High Availability Blueprint Page 14 of 32

15 More information: Configuring Virtual IP Takeover Media Servers While SIP Server provides the control layer, the actual media (RTP) is handled by Genesys Media Servers. There are two main component of the Media Servers - the Resource Manager and the Media Control Platform (MCP). BEP comes with an instance of each. When configuring two BEPs for HA, both the Resource Manager and MCPs should be set up in active-active mode. There are multiple ways to configure Resource Manager HA, but the preferred method for BEP is to use Active-Active load balancing with SIP Server. For instructions, see Resource Manager High Availability. In addition, a Resource Group should be created that points to the two MCPs. This will allow the Resource Manager to load balance requests between the two MCPs on the two BEP instances. Digital Layer HA The Digital Layer within Genesys BEP includes and chat channels. Both channels rely on the Interaction Server (IXN) and Universal Contact Server (UCS). The Interaction Server and UCS both rely on the data layer to save all interaction data and states. As such, both UCS and IXN should be setup with a warm standby on the secondary BEP Server The BEP Server supports a standby configuration. strategies do not typically require real-time operations, therefore the time to switchover to a warm standby should be acceptable. Note that in the case of a failure to BEP, the itself is still within the corporate server and assuming the data layer has been properly configured, all interaction data should be safe as well. For more details, see the eservices User's Guide Chat Server The Chat Server supports an active/active configuration. As such, both Genesys Mobile Services (GMS) and Chat Server should be set to N+1 load balanced modes. For more details, see the eservices User's Guide. Genesys Business Edition Premise High Availability Blueprint Page 15 of 32

16 Workspace Workspace Desktop Edition is the agent desktop application provided with BEP. It enables the agent to answer phones calls, chats and s routed to them by the routing strategies. It includes many other features to support contact center operations. For more information, see the Workspace Desktop Edition section of the Genesys documentation site. Workspace Desktop Edition supports HA deployments. This is configured within the Workspace Desktop Edition Application object using the Genesys administration tools. Essentially, a Read right needs to be assigned to the backup application objects for various services (e.g. SIP Server, UCS, Interaction Server, etc.). For more information on configuring these objects, see Preparing the Configuration Layer. Once configured, the Desktop application should be able to communicate with the backup server should a failover occur. 4 Implementation Details Database Steps Microsoft SQL Server has multiple options to support database high availability. Many of these are based on the Microsoft SQL Server Enterprise license. To minimize costs, BEP recommends using Database Mirroring supported by the Microsoft SQL Server Standard Edition license. Please refer to this Microsoft Tech Note on mirroring. A key concept in mirroring are principal and mirror database partners. The Principal database will be the main connection for all database operations. For normal operations this should be the Primary BEP (ESXi-1), the Mirrored instance will be on the Secondary BEP (ESXi-2). The following steps are required and detailed below: Complete initial setup of the BEP machines. Migrate Postgres database to MS SQL Server. Configure Mirroring: Create certificates for Principal and Mirrored database instances. Create mirroring endpoints on principal & mirrored database instances. Create accounts in SQL for mirroring using certificates. Backup databases and logs for each Genesys database on the principal instance. Restore those backups to the mirrored instance. Genesys Business Edition Premise High Availability Blueprint Page 16 of 32

17 Activate mirroring after backups have successfully imported. Alter each database on the mirror instance to set partner to the principal instance: ALTER DATABASE xxx SET PARTNER = 'TCP://gen-db-1:5022'; Alter each database on the principal instance to set partner to the mirror instance: ALTER DATABASE xxx SET PARTNER = 'TCP://gen-db-2:5022'; Setup scripts to monitor availability of SQL Server instances and force role switching in case of failure or resumption of service. To simplify DBServer/client reconnection after switchover, the recommendation is to use either a host file or a DNS entry (see SQL Connections for Mirroring). There are multiple databases within the Genesys BEP solution. The following databases should be mirrored as part of this procedure: ConfigDB IxN UCS GI2 GAX Pulse GIM The ICON database should not be mirrored, as it normally operates in an active-active HA mode. SQL Server Management Studio Note that the Microsoft SQL Server Management Studio tool may facilitate setting up the mirroring of the databases and subsequent monitoring and failover Migration POSTGRESQL DB to MSSQL DB. (BEP configuration DB) 1. Create an identical (same version) MSSQL DB by Executing only 'Init_multi_mssql.sql scripts'. DO NOT run the 'CfgLocale_mssql.sql' against this DB. 2. Use Configuration Conversation Wizard, Export/Import functionality to migrate the source PostgreSQL Db to Target MSSQL DB Genesys Business Edition Premise High Availability Blueprint Page 17 of 32

18 3. Export of the POSTGESQL DB will create a.sql file, that you will need to import into the new MSSQL DB. Importing the sql file may result in some errors, that will need to be manually corrected. The Insert statement for 'cfg_time_zone' was corrected to make the import work. Genesys Business Edition Premise High Availability Blueprint Page 18 of 32

19 The following example shows the correction for one of the time zone fields (highlighted). Please repeat for any other time zones in the script. ORIGINAL: insert into cfg_time_zone (dbid, tenant_dbid, name, description, offset_, is_dst_observed, dst_start_date, dst_stop_date, name_netscape, name_msexplorer, state, csid, tenant_csid, dst_offset) values(101,1,'gmt','greenwich Mean Time',0,2, , ,'GMT','GMT',1,0,0,60) FIXED: insert into cfg_time_zone (dbid, tenant_dbid, name, description, offset, is_dst_observed, dst_start_date, dst_stop_date, name_netscape, name_msexplorer, state, csid, tenant_csid, dst_offset) values(101,1,'gmt','greenwich Mean Time',0,2, , ,'GMT','GMT',1,0,0,60) Note: The identical change should be done for all existing Time Zones Create Mirroring Certificates and Endpoints Create the following directories on Mirror and Principal by running the following scripts: REM Run on Mirror mkdir d:\cert mkdir d:\bak REM Run on Principal mkdir d:\cert mkdir d:\bak Run the following scripts against the Principal Instance (please replace 'StrongPassword!' with an appropriate password that meets customers' security requirements): USE MASTER CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'StrongPassword!' CREATE CERTIFICATE HOST_PRIN_cert WITH SUBJECT = 'HOST_PRIN certificate', START_DATE = '08/08/2016' Genesys Business Edition Premise High Availability Blueprint Page 19 of 32

20 CREATE ENDPOINT End_Mirroring STATE = STARTED AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL) FOR DATABASE_MIRRORING ( AUTHENTICATION = CERTIFICATE HOST_PRIN_cert, ENCRYPTION = REQUIRED ALRITHM RC4, ROLE = ALL ) BACKUP CERTIFICATE HOST_PRIN_cert TO FILE = 'D:\cert\HOST_PRIN_cert.cer' Run the following script against the Mirrored Instance (please replace 'StrongPassword!' with an appropriate password that meets customers' security requirements): USE master CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'StrongPassword!' CREATE CERTIFICATE HOST_MIRR_cert WITH SUBJECT = 'HOST_MIRR certificate', START_DATE = '08/08/2016' CREATE ENDPOINT End_Mirroring STATE = STARTED AS TCP (LISTENER_PORT = 5023, LISTENER_IP = ALL) FOR DATABASE_MIRRORING ( AUTHENTICATION = CERTIFICATE HOST_MIRR_cert, ENCRYPTION = REQUIRED ALRITHM RC4, ROLE = ALL ) BACKUP CERTIFICATE HOST_MIRR_cert TO FILE = 'D:\cert\HOST_MIRR_cert.cer' Create Accounts for Mirroring Run the following script on the Principal Instance, replacing 'Password!' with an appropriate password: /* *Execute this against the Principal Instance. The HOST_MIRR_cert.cer * needs to be copied on the Principal Server. */ USE MASTER /* * We are creating a SQL Login here. For Windows logins, Genesys Business Edition Premise High Availability Blueprint Page 20 of 32

21 * use the Grant Login instead of Create Login */ CREATE LOGIN HOST_MIRR_login WITH PASSWORD = 'Password!' CREATE USER HOST_MIRR_user FOR LOGIN HOST_MIRR_login CREATE CERTIFICATE HOST_MIRR_cert AUTHORIZATION HOST_MIRR_user FROM FILE = 'D:\cert\HOST_MIRR_cert.cer' GRANT CONNECT ON ENDPOINT::Mirroring TO [HOST_MIRR_login] Run the following script on the Mirrored Instance, replacing 'Password!' with an appropriate password: /* * Execute this against the Mirror Instance. The HOST_PRIN_cert.cer * needs to be copied on the Mirror Server. */ USE MASTER /* * We are creating a SQL Login here. For Windows logins, * use the Grant Login instead of Create Login */ CREATE LOGIN HOST_PRIN_login WITH PASSWORD = 'Password!' CREATE USER HOST_PRIN_user FOR LOGIN HOST_PRIN_login CREATE CERTIFICATE HOST_PRIN_cert AUTHORIZATION HOST_PRIN_user FROM FILE = 'D:\cert\HOST_PRIN_cert.cer' GRANT CONNECT ON ENDPOINT::Mirroring TO [HOST_PRIN_login] Backup Databases and Logs Run the following script against the Principal Instance for each database to be mirrored: USE MASTER BACKUP DATABASE cfg85 TO DISK = 'D:\Bak\cfg85_FullBackup.bak' BACKUP LOG cfg85 TO DISK = 'D:\Bak\cfg85_LogBackup.trn' Restore Backups to the Mirrored Instance Run the following against the Mirrored Instance for each database to be mirrored: Genesys Business Edition Premise High Availability Blueprint Page 21 of 32

22 USE MASTER RESTORE DATABASE cfg85 FROM DISK = 'D:\Bak\cfg85_FullBackup.bak' WITH NORECOVERY RESTORE LOG cfg85 FROM DISK = 'D:\Bak\cfg85_LogBackup.trn' WITH NORECOVERY Activate Mirroring To activate mirroring, run the following script on the Mirrored Instance for each database to be mirrored. Ensure that the appropriate network address is used when referencing the PARTNER database instance: /* * Execute this against the Mirror Instance. */ ALTER DATABASE cfg85 SET PARTNER = 'TCP://g1-db-bep2.some.company.com:5022' Next, run the following script on the Principal Instance for each database to be mirrored. Ensure that the appropriate network address is used when referencing the PARTNER database instance: /* * Execute this against the Principal Instance. */ ALTER DATABASE cfg85 SET PARTNER = 'TCP://g1-db-bep1.some.company.com:5022' Monitoring SQL Servers & Force Role Switch Monitoring of SQL Server database mirroring can be accomplished either using the SQL Server Management Studio or using the following Microsoft stored procedures: dbmmonitor sp_dbmmonitorresults This will provide statistics on how well the data is being mirrored from the principal server. SQL Server also sends WMI events of type DATABASE_MIRRORING_STATE_CHANGE when there is a change in the mirroring state. Of particular interest are the following state changes: Genesys Business Edition Premise High Availability Blueprint Page 22 of 32

23 Mirror changes to 5 (Connection with Principal is Lost), Principal changes to 6 (Connection with Mirror List) Either changes to 9 (Mirroring suspended). Note that this will happen when the mirror takes over from the principal. SQL Server Management Studio can setup Alerts for these conditions. It can also setup actions on those alerts such as ing an administrator or executing a script. Once a failure has been detected, the Mirror instance needs to take over as the Principal instance until the original Principal has been restored to normal operations. Since this solution does not use the SQL Server Enterprise Edition license or a 3rd server to act as a witness, manual failover and/or forced service is required. Scripting can be used to automate this. For each database, the following SQL needs to be executed: /* * Execute this against the Mirror Instance */ ALTER DATABASE cfg85 SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS This is the Force Service mechanism which may result in some data loss. This will typically be required if one of the BEP machines fails. The alternative is a Manual Failover which can be used if the principal is still communicating to the mirror (useful for database upgrades). Change the SET line in the above script to the following: SET PARTNER FAILOVER Care needs to be taken to ensure the switchover is required and if Force Service is required, to check or any data loss References (SQL) Genesys Business Edition Premise High Availability Blueprint Page 23 of 32

24 (Studio) Forced (SQL) SQL Connections for Mirroring Set up a virtual name for the MSSQL Server host (e.g. gen_db) in the hosts file. Set up Data Access Points for the JDBC Connection to each Genesys database using the appropriate credentials and other information. Specify the virtual MSSQL Server host name in the Server Info tab. During failover the host file can be manipulated via a script to point from the primary to the mirrored SQL Server machine. Alternatively, DNS can also be used for the SQL Server host. Voice Configuration Details The recommended approach for setting up VoIP HA is to use SIP Proxy. Please consult the SIP Server HA Deployment Guide for details and especially the section, Using SIP Proxy. Genesys Business Edition Premise High Availability Blueprint Page 24 of 32

25 Digital Channels Configuration For details, see the eservices User's Guide. 5 Appendix A: Alternative HA Architectures This section discusses some of the alternative architectures explored to support a highly available deployment of BEP. These alternative architectures were not selected as part of the solution for various reasons additional cost and complexity being the main factors. This section is provided as background to why the solution architecture was chosen over these other options. There are two main options to deploying BEP in an HA configuration. The first is to deploy standard Genesys HA across 2 sets of BEP VM images. The second is to rely on the underlying virtualization software to provide HA (in this case VMWare vsphere Fault Tolerant software). Note that there are other considerations that impact both solutions database availability, VM image creation, etc. vsphere Fault Tolerant for BEP VMWare's vsphere has several availability models. vsphere HA and vsphere Fault Tolerant (FT) provide differing degrees of availability. FT creates a shadow mirrored image of the VMs on the primary image. This needs to be prototyped to see if the shadowed VM image can take over processing if the primary ESXi fails. Note that FT and HA together can also provide application level failover. More investigation is required to see how to configure that. Genesys Business Edition Premise High Availability Blueprint Page 25 of 32

26 The following diagrams depicts using vsphere FT to provide HA. Note that vcenter and other potential components are not depicted. Using shared disk storage will enhance the overall reliability of the system and the durability of Genesys BEP data. A SAN is typically used with a Fibre Channel between the ESX host and the network storage. Care needs to be taken to ensure SANs and DBs are properly configured to work together but there are a lot of references on both. VMWare also supports a Virtual SAN (still investigating..) Genesys Business Edition Premise High Availability Blueprint Page 26 of 32

27 The following diagram depicts the architectural approach using vsphere FT for BEP with SAN for data durability. A vsphere HA cluster needs to be setup using the availability guide listed in the reference. VSphere HA can provide application monitoring and restarting, but it does require using the SDK to send appropriate heartbeat messages for monitoring. vsphere FT requires a 10 GBit login network with low latency a dedicated FT network is recommended. Another related technology to consider is the VMWare Virtual SAN. Genesys Business Edition Premise High Availability Blueprint Page 27 of 32

28 5.1.1 Rationale Note that this solution requires that the customer is proficient with VMWare technology and operations. There are additional costs associated with licensing vsphere that are not included in the BEP package. Therefore, this solution is not recommended References VMware-vCenter-Server-6-0-Availability-Guide.pdf vsphere-esxi-vcenter-server-601-setup-mscs.pdf vsphere-esxi-vcenter-server-601-availability-guide.pdf Genesys HA for BEP Genesys HA models should be well-understood. Primary instances of Genesys applications need to be configured on ESXi1 and backup instances on ESXi2. The main exception is SCS where the primary should be setup on ESXi2. This is done to ensure that proper switchover happens if a system experiences network isolation. There are two approaches to setting up the VMs. The first approach is to do two BEP setup/tuneups and then reconfigure all the applications and their connections. The second approach is to setup one BEP and then clone that image and reconfigure it via database scripts, changing application names, etc. There are several approaches to database replication to consider. Database mirroring is tried and true although Microsoft has proposed deprecating support for this in a future release. Postgres also supports mirroring. Cassandra, on the other hand, should be configured with a minimum of 3 nodes; a 2-node cluster can be configured, but data inconsistencies may occur. Genesys Business Edition Premise High Availability Blueprint Page 28 of 32

29 The following diagram depicts Genesys HA using mirroring: Microsoft also supports a 2-node failover cluster in SQL Server standard edition. Note that Enterprise Edition supports Always On clustering but that is cost-prohibitive for BEP target customers. Note that a Watcher process can also be used to enhance database replication and automated failover for SQL Server. A 3rd ESXi instance can hold a VM with the Watcher and a 3rd Cassandra node to provide true clustering. Additional work is required to set up this additional "Watcher VM" image. Genesys Business Edition Premise High Availability Blueprint Page 29 of 32

30 The following diagram depicts Genesys HA using failover cluster: A SAN can also be used with Genesys HA to provide resilient data storage without worrying about mirroring and clustering. Genesys Business Edition Premise High Availability Blueprint Page 30 of 32

31 The following diagram depicts the architectural approach using standard Genesys HA and a SAN: Lastly, there will be deployments of BEP where the customer insists on using their own Microsoft SQL Server infrastructure. In these cases, data resiliency and HA is under customer control. If they have an Enterprise license they can even configured SQL Server Alway On availability groups for Genesys data. Genesys Business Edition Premise High Availability Blueprint Page 31 of 32

32 The following diagram depicts Genesys HA with a customer supplied MS SQL Server RDBMS: Rationale Note that the initial core of this approach is part of the solution. However, the use of a SAN and the 3-node cluster were not considered as they added additional costs to the BEP package. 6 Appendix B: References Microsoft SQL Server 2012 Licensing Guide SQL Server DB-mirroring [kb/ ] Microsoft Tech Note on mirroring. Genesys Business Edition Premise High Availability Blueprint Page 32 of 32