Configuring MCF Clusters

This chapter provides an overview of PeopleSoft MultiChannel Framework scalability and failover and discusses how to:

• Configure MCF servers.

• Configure MCF clusters.

Understanding PeopleSoft MultiChannel Framework Scalability and Failover

This section discusses:

• PeopleSoft MultiChannel Framework cluster architecture.

• MCF clusters.

• Logical queues and physical queues.

• Queue server failover.

• MCF log server failover.

• MCF cluster configuration.

• Queue server scalability.

• Recommended configurations.

PeopleSoft MultiChannel Framework Cluster Architecture

In a PeopleSoft system, all application server processes—including MCF servers and real-time event notification (REN) servers—belong to an application server domain. Each domain can have only one REN server process (PSRENSRV), one queue server process (PSUQSRV), and one MCF log server process (PSMCFLOG). Domains can be redundantly clustered to provide failover. Logical queues can be serviced by multiple clusters for scalability. Support for scalability and failover is integrated into the configuration process.

This diagram illustrates MCF cluster architecture:

PeopleSoft MultiChannel Framework cluster architecture

MCF Clusters

An MCF cluster is a group of multiple MCF-enabled application server domains in which all queue servers and log servers communicate with the same REN server cluster. Only one queue server and one log server in an MCF cluster are active at any one time. These are called the masters. The rest are dormant and redundant, and are called the slaves. If a master drops out of the cluster for any reason, the slaves elect a new master to take its place.

Logical Queues and Physical Queues

PeopleSoft MultiChannel Framework enables the configuration of both logical and physical queues.

A logical queue is an application-level queue that receives work requests (tasks) relating to an application area, such as chat requests regarding sales information, and routes them to agents capable of handling the work. For example, you might configure a logical queue called SALES for sales inquiries and another called SUPPORT for support issues.

Logical queues can be partitioned into physical queues for scalability. A physical queue is managed by a single MCF cluster. For scalability, the tasks enqueued on a logical queue are distributed by the framework among all available physical queues. For example, the SALES queue could be serviced by four MCF clusters across four physical queues: SALES1, SALES2, SALES3, and SALES4.

Each agent can be assigned to only one physical queue within each logical queue. Each agent can be assigned to multiple logical queues.

Queue Server Failover

The queue server process (PSUQSRV) is a BEA Tuxedo–managed server with a standard PeopleSoft database connection. Each queue server process is the central routing point for one or more physical queues. The queue server maintains state information for work requests, work in progress, agent availability, and agent workload. Queue server state is written to database records, except for the assignment of chat to agents.

The queue server can recover from a crash because most of its state is written to the database. When a queue server reboots, it checks the database and loads state information for open work tasks. The queue server connects to its REN server and issues restart queries to each console so it can rebuild agent assignment information, which may have changed while the queue server was down.

Although a single queue server can recover state after recovering from software failure, this does not guard against hardware failure. Multiple queue server processes running on multiple host machines and configured in a cluster provide failover for hardware failure. Unlike the REN server cluster, the clustered queue servers operate as one master and many slaves. The master handles all routing decisions, while slave processes monitor the master and step in only if it fails. Any rebooted queue server rejoins the cluster in a slave role. Any slave promoted to master loads state from the database and issues queries to consoles as if it were the only process in the cluster.

Each queue server process follows a fixed procedure to ensure that the cluster has at most one functioning master. Database locks eliminate possible race conditions, and the master periodically writes a timestamp to indicate its health. The masterinterval parameter controls the frequency at which the master process must update the timestamp in the cluster table. The masterinterval parameter corresponds to the maximum time after a master queue server fails before another queue server process takes over. Minimizing this value provides rapid failover response time but also requires frequent database updates.

See Tuning Cluster Parameters.

Each queue server must be part of an MCF cluster, and each MCF cluster must include at least one queue server. An MCF cluster of only one queue server provides no redundancy against hardware failure.

In summary, configure queue servers to provide hardware failover as follows:

1. Each queue server is part of an MCF cluster.

   To support hardware failover, distribute master and slave queue servers over multiple hosts.

2. Every queue server in an MCF cluster communicates with the same REN server ID.

   Therefore, REN server failover is also crucial.

   See Configuring REN Servers.

3. The first queue server that places a valid master entry for itself in the cluster table becomes the master queue server.

   In most cases the master queue server is the first queue server started. There is no configuration parameter to designate master or slave queue server within a cluster.

4. After an MCF cluster's master queue server is established, all other cluster members become slave queue servers.

5. If the slave queue servers within a cluster detect a failure of the master queue server, the remaining slave servers compete to become the master queue server.

   If the master queue server reboots before a slave takes over, the master queue server also competes.

   There is no configuration parameter to designate priority among slave servers.

MCF Log Server Failover

The MCF log server (PSMCFLOG) is a BEA Tuxedo–managed server similar to the queue server. Each MCF log server receives events sent by a REN server and is responsible for writing MCF events to the database.

The MCF log server logs events to PS_MCFUQEVENTLOG. By default, the log server does not log periodic state information broadcasts from the queue server to the MultiChannel Console. If you need to log these events, configure logging on the Cluster Tuning page. You can also configure the log server to log the contents of chat sessions. Chat session logging is turned off by default. Logged chats are stored in PS_MCFCHATLOG.

If the MCF log server crashes, it resumes functioning immediately after restarting. When the first slave log server detects a failed master, it takes over as the master log server for the cluster. The new master log server again receives all base topics, but it does not log chat sessions that started or continued during the time the original master log server failed. The new master log server does not log per-agent events for agents that were signed in at, or during, the time of the failure.

An MCF log server is created along with a queue server when you enable MCF servers during application server domain configuration. There is no specific log server configuration during domain configuration.

MCF Cluster Configuration

Each MCF cluster includes a minimum of one queue server and one log server communicating with one REN server. An MCF cluster is typically identified by the ID of the REN server cluster serving it. There is no configuration limit to the maximum number of queue servers in an MCF cluster.

In MCF architecture, a chat client initiates contact with an agent through the designated external (browser) URL for a REN server. This URL can point to a load balancer, switch, reverse proxy server, or other hardware or software directing requests through a firewall. The external URL is also known as the browser URL, because it supports the MCF browser windows (agent chat, customer chat, and MultiChannel Console).

For communication of queue servers, log servers, and application servers with REN servers—for example, handling email requests—behind a firewall, you can use an internal URL. Specify both internal (cluster) and external (browser) REN server URLs during MCF cluster configuration.

Note. If no security is implemented, the browser and cluster URLs may be the same.

Queue Server Scalability

PeopleSoft MultiChannel Framework is scalable to support large capacity call centers or other large organizations. The basic strategy is to divide the workload by spreading it over several MCF clusters. This is accomplished by creating multiple physical queues for each logical queue and spreading the management responsibility for each physical queue to separate queue server processes, preferably on multiple host machines. This technique should not be confused with failover protection, which also adds processes and machines. In failover, the added processes are clustered together and do not provide performance improvement.

Organize applications using PeopleSoft MultiChannel Framework around logical queues (for example, Sales queue and Support queue). Incoming work tasks are sent to a logical queue. PeopleSoft MultiChannel Framework then assigns the task to one of the corresponding physical queues. This assignment is random across the queues. Since only one physical queue per logical queue can be serviced by a single MCF cluster, this balances load across the servers.

For example, a logical Support queue might be split into physical Support-1 and Support-2 queues such that work requests are randomly distributed between the two physical queues. Half the agents receive from one queue and half from the other. This splits the workload evenly between the two queue server processes, while still presenting one logical Support queue to the application.

Recommended Configurations

Consider the following configuration options to ensure maximum reliability and scalability of your PeopleSoft MultiChannel Framework installation:

• Configure multiple MCF servers in a cluster across multiple host machines.

  This provides protection against single-point failures.

  Each MCF cluster requires a REN server cluster. Configuring multiple REN server clusters is functionally the same as configuring multiple MCF clusters for scalability. Inside a REN server cluster, configuring multiple REN servers is functionally the same as multiple queue servers for failover.

• Use REN server clusters only for failover.

  REN server clusters do not enhance performance.

• Split logical queues into more than one physical queue if there is more work on that queue than a single process or machine can handle.

• If an application server domain is likely to be restarted regularly for reasons not related to PeopleSoft MultiChannel Framework, configure PeopleSoft MultiChannel Framework in a separate domain.

  Regular restarting of MCF servers affects performance because the MCF servers must recover state when they are recycled or when a slave takes over from a master server.

Configuring MCF Servers

This section provides an overview of MCF server configuration and discusses how to configure MCF servers.

Understanding MCF Server Configuration

PeopleSoft MultiChannel Framework depends on processes configured and booted as part of an application server domain. Configure MCF processes (servers) through PSADMIN, along with other processes in each application server domain.

Note. The REN server process can be utilized by applications separate from the queue server and MCF log processes. In this case you can configure the application server domain for event notification without creating the MCF servers.

After considering performance and failover issues, the MCF system administrator provides configuration information that describes the arrangement of queues, domains, queue server processes, REN server processes, MCF processes, and URL addresses.

REN server processes are configured on PeopleSoft Pure Internet Architecture pages before or after being initiated in an application server domain. Each queue server process is uniquely identified in the system by combining the machine name, domain subdirectory name, and process identifier. MCF log processes use the same queue server identification scheme.

See Also

Configuring REN Servers

Creating Queue Servers

Create a queue server and log server that start when an application domain is started by selecting MCF Servers from the quick-configure menu during application domain configuration.

Configuring MCF Clusters

To configure MCF clusters, use the MCF Cluster (MCF_UQCLUSTER) component.

This section discusses how to configure MCF clusters.

Page Used to Configure MCF Clusters

Defining MCF Clusters

Access the MCF Cluster page.

MCF Cluster URL	Displays the URL for the REN server that serves this cluster. This is the URL used by internal processes. If the MCF cluster is served by a REN server cluster, the cluster URL is that of the switch or load balancer in front of the clustered REN servers.
Buffer Test	Click to initiate a test of the REN server's ability to break up and send a large file using multiple internal buffers. The buffer test is not dependent on specified domain names, so you can use it to verify that RENSRV is running on the network.
MCF Browser URL	Displays the URL for the REN server cluster that serves this MCF cluster for external clients and for agent chat. The browser URL may be different from the cluster URL, which should not have to go through any firewall, reverse proxy server, or other outward-facing security barrier.
Ping Test	Click to initiate a test of the REN server specified in the URL fields. Failure may indicate that a URL is incorrectly specified.
Delete	Click to delete the entire MCF cluster. There must not be any active agents or tasks on the cluster.

Note. If the cluster's queue server configuration is changed, changes to the actual application server domains must be made manually using PSADMIN. For example, if a cluster member (queue server) is removed, the affected application server domain must be shut down and reconfigured (set the MCF Servers field to No) using PSADMIN. If the cluster URL is changed, all associated queue server domains must be shut down and rebooted.

Queue Server

An MCF cluster can consist of a primary queue server and any number of backup servers.

Each cluster requires a minimum of one queue server. The primary queue server is the first queue server started, and the remaining queue servers are backups. If the primary queue server fails, the system determines the subsequent primary queue server among the backups.

You can add a queue server to a cluster by adding a new row. Before removing a queue server, ensure that it is not the master, then shut down its domain. Then click Delete (the minus sign).

If a domain is started with a queue server that does not belong to a cluster, the universal queue server and MCF log server poll the MCF configuration tables indefinitely until the queue server is assigned to a cluster.