AVAYA AIC DEPLOYMENT PLAN – PART 4

DatabaseGuidelines-Avaya IC Databases

Avaya IC servers and client applications depend upon the databases to access, store, and retrieve vital data, including information about customers, contacts, employees, and configuration. Avaya OA uses data stored in the IC Repository database.
This module describes the databases that the components of Avaya IC use and provides some basic guidelines for their implementation and configuration.

IC Databases
The table shows the databases that Avaya IC uses. An Avaya IC system might not include all of these databases, as some databases are only used by specific components of Avaya IC.
Your Avaya IC databases interact with:
Avaya IC software
Avaya IC data store units
Avaya OA software

At a minimum, your Avaya IC system must include the IC Repository database and the CCQ database. Some Avaya IC applications, such as Business Advocate, also require dedicated databases. Depending on the components in your implementation, your Avaya IC system may also require one or more of these optional Avaya IC databases. The Avaya Customer Interaction Repository includes the Avaya IC and Avaya OA database and storage components used by an Avaya IC system.

Database Guidelines -Avaya IC Databases (Continued)

Avaya IC 7.2 Server Guidelines –Introduction 

General server guidelines that you need to consider while planning your Avaya IC system:
?Server Partitioning Guidelines
?Server Location Guidelines
?Server Failure Guidelines
?Server Interaction guidelines
?Virtualization

Avaya IC is made up of servers that interact with each other to provide its functionality. You can host Avaya IC servers on the same machine, across multiple machines, and across multiple sites. The correct deployment of your Avaya IC environment is vital to achieve an optimal level of performance and security.
Consider these guidelines when you decide how many of each type of server the system requires, which computers will host the servers, where to locate those computers on the network. The guidelines are:
Server Partitioning Guidelines
Server Location Guidelines
Server Failure Guidelines
Server Interaction Guidelines
Virtualization

Server Partitioning Guidelines –Physical PartitioningServer

The correct partitioning of an Avaya IC system is vital to achieve an optimal level of performance and security. Avaya IC servers use two types of partitioning—physical and logical.
How you deploy the Avaya IC servers on physical servers in your system defines the physical partitioning of your Avaya IC system. The physical partitioning performs the following functions for Avaya IC:
Determines the connectivity between servers
Defines how hardware and network failures will impact the servers
You can deploy computers that host Avaya IC servers in a single site on one LAN, or across multiple sites on multiple LANs that are interconnected by WANs.

Server Partitioning Guidelines –Logical Partitioning

How you group the Avaya IC servers in Avaya IC domains defines the logical partitioning of an Avaya IC system. The Avaya IC domains determine preferred communication paths and how failover functions.
When you set up the domains for an Avaya IC system, you define the following communication paths:
Between the Avaya IC servers
Between the Avaya IC servers and the Avaya IC client applications

Important: Each Avaya IC domain should only contain one server of that type although there are certain exceptions to this rule. For example, the Default domain can include more than one ORB server.
Use a common naming convention for your domains to ensure that you can easily identify where a component is deployed. In a multi-site deployment, you should use the following naming convention: <site>_<service>, where service represents the media channel or function of the servers in the domain. For example, in an Avaya IC system with a site in Boston, you could name a domain for the voice channel: Boston_VoiceA.
Information: For more information about logical partitioning and how to use Avaya IC domains, you can refer to IC Administration Volume 1: Servers & Domains. For more information about recommended logical partitioning of servers, you can refer to IC Installation Planning and Prerequisites

Server Failure Considerations
Whenever possible, design an Avaya IC system to ensure that failure of a single server does not impact all agents.
Also consider the Process redundancy limitations when you designan Avaya IC system.

Note:Don’t configure redundant IC services on the same machine.
Process redundancy limitations:
Web Management (WebACD) and Email Management support process redundancy. If the Functional WebACDserver fails, Avaya IC will be able to route contacts for e-mail and chat media channels with another WebACDserver. However, WebACDserver does not support multiple redundancy. There can be only two WebACDservers in the entire Avaya IC system. But you can have multiple e-mail servers in the Avaya IC system

Server Location Guidelines

 

Attribute server: 
Install an Attribute server in the DMZ on the computer that hosts your Avaya IC Web site if your Avaya IC system records DataWake information. An Attribute server inside the firewall can record DataWake information. However, if you install an Attribute server on the Web site computer, you will reduce network traffic across the firewall

Guidelines for the Data server:
Data server location: 
Do not install the Data server on the computer that hosts your Database server.

Network location for Data server: Locate computers that host a Data server topologically close to the computer that hosts the Avaya IC databases on a high-speed backbone. Avaya IC generates the bulk of database access traffic between the Data servers and the Database server. This configuration minimizes network bandwidth.

LAN location for Data server machine: Locate the Data server on the same LAN as the Avaya IC databases. This configuration minimizes network bandwidth

Data server and DUStore server location: When on the same LAN as the database, install a Data server on every computer that hosts a DUStore server. Configure the DUStore server to use this Data server. Also host a backup Data server on another computer. This configuration minimizes network traffic and minimizes failure modes.

Data server and Report server location: When on the same LAN as the database, install a Data server on every computer that hosts a Report server. Configure the Report Server to use this Data server. Also host a backup Data server on another computer. This configuration minimizes network traffic and minimizes failure modes

Reference: For more information about databases and the Data servers, refer to Database guidelines in IC Installation Planning and Prerequisites.

Server Location Guidelines (Continued)

 

Server Location Guidelines (Continued)

Report server: Install a Report server on every computer that hosts an EDU server. This configuration minimizes failure modes and network traffic. The Report server is a heavy user of the Data server. Ensure that the Report servers in the Avaya IC system do not share a Data server with a Workflow server that performs routing.

Telephony server: Locate your Telephony server in the same LAN as the associated telephony switch and software. This location provides Avaya IC telephony services with high-speed access to telephony devices, such as telephony switches or IVRs.

Web License Manager: Install at least one Web License Manager at each site. If you install a WebLM at each site, WAN segmentation should not prevent an Avaya IC server or client from getting the appropriate licenses. In the deployment scenarios with redundancy, the Core servers at each site host a WebLM. This configuration has no significance except to reduce the total number of computers. Note: IC 7.2 does not support segmented licensing.

Web Management server: Provide Web Management servers with high-speed access to Web and e-mail servers.

Server Interaction Guidelines

Avaya IC servers interact with other Avaya IC servers and with Avaya OA servers. You need to consider the interaction guidelines when you decide which Avaya IC servers you need in an IC system, and how you deploy those servers

Time synchronization: All servers require time synchronization. This requirement ensures that Avaya IC and Avaya OA maintain consistent time. If
time is not synchronized, your reports may not be consistent. The clocks on all the servers must also be synchronized to track issues in log files.

To achieve time synchronization if you do not have an existing infrastructure, install Network Time Protocol, NTP software on all computers that host Avaya IC servers and Avaya OA servers. You can use a commercial time synchronization application that includes the ability to provide gradual clock corrections over time such as Windows Time Service. Avaya IC may fail with time-out errors if you change the system clock in large increments. For example, more than two to three seconds per minute.
ADU servers support Avaya IC accounts for agents and administrators. Consider the guidelines for ADU servers when you plan the deployment of ADU servers:

ADU server limitations: An ADU server can handle events from approximately 500 agents. Avaya recommends that you include a minimum of two ADU servers at each site.
ADU server failover: Do not configure agent domains to failover to an ADU server that:
Is not monitored by an Event Collector server at the same site
Is monitored by an Event Collector server at a different site

ADU persistence: If the Avaya IC system requires ADU persistence, follow the guidelines for EDU persistence.

The interaction guidelines for Data server are:
Data server location: Do not install the Data server on the computer that hosts your database server.

Network location: Locate the Data server on the same LAN as the database. The protocol between agent applications and the Data server is much more efficient than the SQL protocol between the Data server and the database. This configuration provides for better throughput of data in your Avaya IC 6.1 system.

Data server and DUStore server location: When on the same LAN as the database, install a Data server on every computer that hosts a DUStore server. Configure the DUStore server to use this Data server. Also host a backup Data server on another computer. This configuration minimizes network traffic and minimizes failure modes.

Server Interaction Guidelines (Continued)

DUStore server: While deploying any Avaya IC system that includes the e-mail channel to minimize network traffic and provide load balancing, it is essential to:
Configure a secondary DUStore server for the e-mail EDU server only,
Locate the secondary DUStore server on the same computer as the e-mail EDU server,
Configure the e-mail EDU server to use this DUStore server, and
Install and Configure a backup DUStore server in case of a failure of the DUStore server.

EDU server: Install a separate EDU server for every media channel domain. Different media channels have different requirements for configuring the EDU server to ensure optimal processing.

E-mail EDU server: Verify that the persistence parameter is set to “on” for the e-mail EDU server.

EDU limitations: The EDU has a limitation if the contact center includes some Avaya IC agents and some agents who do not work in Avaya IC. Avaya IC cannot track an EDU outside the Avaya IC system. For example, if an Avaya IC agent transfers a contact out of Avaya IC to a non-Avaya IC agent, then Avaya IC terminates the EDU for that contact. Avaya IC considers the contact to be retired. If an agent transfers the contact back to an Avaya IC agent, Avaya IC assigns a second EDU to the contact. As a result, the same contact has two EDUs. This limitation can create problems with tracking and reporting for that contact.

Server Interaction Guidelines (Continued)

ICM server and CIRS server: If you expect a high volume of customer interaction and chat contacts on the Web Management Web site, you can add more than one ICM server to increase the number of supported chat contacts and permit greater scalability

If the Avaya IC system includes more than one ICM server:
Configure a CIRS server to provide load balancing for the ICM servers
Host each ICM server on a separate computer.
Consider the guidelines for planning the deployment of Telephony Queue Statistics (TSQS) servers:

Potential queue limitations: If there are more than 500 queues defined on the system, the TSQS server may timeout in a failover situation.

Configuration requirements for multiple TSQS servers: Do not configure more than one TSQS server with the same Site and ACD Name. If you configure redundant TSQS servers with the same Site and ACD name, both servers will attempt to create and update the ADU for the queue. This simultaneous update can cause the problems as:
Incorrect and duplicate data in Avaya OA reports
Problems with creation of multiple ADUs
Failure of both TSQS servers

Backup TSQS servers: If the Avaya IC system requires a backup TSQS server, configure:
The backup TSQS server NOT to autostart
The backup Telephony server for the queue as the first server in the TS Set list for the Voice Device in IC Manager

Server Interaction Guidelines (Continued)

Location of Workflow servers: To mitigate the impact of a failure due to customized workflows, keep Workflow servers logically separate. For example, create a Workflow server for each media and host those servers with other servers that are specific to the same media

Customization of workflows: Workflow servers typically have many external interfaces, such as interfaces to the database and Prompter. Because the Workflow server is scriptable and extensible, Avaya cannot test all possible customizations and usages as part of the out-of-the-box product. Customized workflows can be less reliable than the sample workflows and can impact the performance of other servers. Avaya recommends that you thoroughly test all customized workflows, including possible failure scenarios

Load partitioning: Deploy several Workflow servers to provide general load partitioning for contacts, and to limit the types of workflows run by each Workflow server. If you limit the types of workflows, you minimize the possibility that a workflow will impact the performance of other Avaya IC system functions

Your Avaya IC system should include separate Workflow servers for the following:
Each Blender server in your Avaya IC system
Each media channel in your Avaya IC system
Each agent workgroup that uses Prompter
Other utility functions run by the Workflow server, such as periodic tasks You can configure a Workflow server for each computer that hosts media-specific servers.
For example, create a Workflow server for each computer that hosts a Telephony server.

Coupling between Blender server, Workflow server, and ADU server: A tight coupling between the Blender server, Workflow server, and ADU server is critical for agent login and for agent channel assignment.
If you install redundant servers, or the contact center requires higher available of agents, include the following in your deployment:
Install at least two sets of Blender server, Workflow server, and ADU server on every LAN in the Avaya IC system that includes agent desktop applications.
Configure each set of servers to fail over to the other set of servers.
Split the agent population on the LAN between the two sets of servers. Each agent group should use one set of servers and use the second set as a backup. This set of servers is critical for agent login and agent channel assignment. If you split your agents across two sets of servers, a single server (or computer) failure cannot disable your contact center. One group of agents can continue uninterrupted operation while the other group restores connections through failover.
Note: Some deployments do not include an ADU server in a user domain. Those deployments include the Blender server and Workflow server in the user domain, and the ADU server in a media domain. Those deployments also ensure that the failover is configured correctly for the user domains and the failover domains. For more information about how to configure the failover, see Avaya IC single site deployment scenarios and Avaya IC multi-site deployment scenarios in IC Installation Planning and Prerequisites

Workflow server and Business Advocate: Configure at least one Workflow server on the same computer as every Telephony Services Adaptor server and Web Advocate Adaptor server. This Workflow server handles the qualification and exceptions of all the contacts for that server. If the Telephony Services Adaptor server or Web Advocate Adaptor server handles a high volume of contacts, assign multiple Workflow servers to that server. The Telephony Services Adaptor server or Web Advocate Adaptor server can distribute contacts evenly between the assigned Workflow servers.

Workflow server and email qualification: To improve email processing throughput, run email qualification workflows on a different Workflow server than the email analysis workflows. Email analysis should always occur on a dedicated computer in the Email domain.

Depending upon the volume of incoming email contacts, email qualification can occur on:
The same Workflow server as chat qualification for a contact center with a low to medium volume of email and chat contacts.
A dedicated Workflow server for a contact center with a medium to high volume of email and chat contacts.
 
Reference
The Avaya IC deployment scenarios have been discussed from slide 6 in this chapter.