Implementing Master-Slave Dispatchers
This section provides an overview of master-slave dispatching and describes how to:
Configure dynamic slave dispatchers.
Configure static slave dispatchers.
Create template slave domains.
Implement master-slave load balancing.
Implement deferred master domain processing.
Master-slave dispatching is where a master domain allocates messages to one or more slave dispatchers for processing. This section provides an overview of master-slave dispatcher processing.
Master-Slave Dispatcher Processing
A slave dispatcher processes service operations assigned to it by a master dispatcher.
A master domain allocates service operations to a slave for processing when:
The master detects that a slave dispatcher is active and not busy processing service operations.
The slave has an active queue on which the master is currently processing service operations.
The dispatcher(s) processing in slave mode then process the allocated service operations.
Master and slave dispatchers can reside on the same or on different machines.
Note: When master-slave processing is implemented, there can be only one master domain at a given time.
You can create a domain consisting of only dedicated slave pub/sub servers. These servers register themselves as slaves, along with additional configurable information, such as the number of process handlers booted, so that the appropriate master server can use that information to allocate work (service operations to process) to the slave server(s).
The master domain can allocate work to one or more slave domains.
Slave Types
There are two types of dispatcher slaves:
|
Field or Control |
Definition |
|---|---|
| Dynamic slaves |
A dynamic slave can change from a master to a slave. Dynamic slaves are configured in conjunction with domain failover. If a slave domain has the highest priority within a failover group, it can dynamically change to a master during failover. You configure dynamic slaves in the Failover Configuration page in the Service Operations Monitor. |
| Static slaves |
Static slaves are those that cannot become masters without manual configuration. You configure static slave domains in PSADMIN. |
| Template slaves |
A template slave is an already-configured master domain that you import into PSADMIN an save as a slave domain. Template slaves enable you to dynamically add slave domains without performing any configuration changes in PSADMIN. You use the Import Domain Configuration command in PSADMIN to import a master domain configuration and then save it as a static slave domain. The slave domain created uses all the Pub/Sub processes and queue lists configured for the master domain on which the slave template is based. If dedicated servers are configured for the master domain, they are also imported an available on the slave domain. |
Failover and Master-Slave Dispatchers
You can create a slave domain for use in domain failover.
The domain with the highest priority dynamically becomes the active domain (master domain) in each group during failover. The next domain in priority will be programmatically configured as an active slave domain.
When a failover occurs the domain that failed becomes inactive. The failover domain specified goes from an active slave to an active master. The next domain in priority then becomes an active slave.
You can set failover for slave dispatchers. However, slave dispatchers cannot be part of any group and you cannot prioritize them.
Use the Failover Configuration page in the Service Operations Monitor to configure dynamic slave dispatchers.
You use PSADMIN to specify a pub/sub dispatcher as master or slave by setting the following property:
|
Property |
Description |
|---|---|
|
DispatcherSlaveMode |
Options are:
|
This section discusses how to:
Import domain configurations from application domains.
Import domain configurations from files.
View template slave domains.
Add and delete dispatcher queues from template slave domains.
Restore dispatcher queue lists.
Understanding Template Slave Domains
Template slaves enable you to dynamically add slave domains without performing any configuration changes in PSADMIN.
When you create a template slave domain you import a domain configuration and save it as a template for the slave domain. This process creates a static slave domain that uses all of the pub/sub processes and queue lists configured for the domain that you import. If dedicated servers are configured for the domain that you import, they are imported and available on the slave domain. After you import a domain configuration and save it as a slave domain, you can add or remove dispatcher queues from the slave domain as needed.
All template slave domains must be based on the same master domain configuration.
Template Slave Domain Types
There are two options for importing a domain as a template:
|
Field or Control |
Definition |
|---|---|
| IB Slave Basic |
When the configuration is imported, all the Pub/Sub processes are configured identically to the domain on which the slave template is based, including the PSWATCHSRV and PSMONITOR server processes. Other process, such as PSAPPSRV, PSSAMSRV, and so on, are not included in the template slave domain. However, you can modify the template slave domain configuration file to include these processes if needed |
| IB Sync Slave |
As in the IB Slave Basic template, when the configuration is imported, all the Pub/Sub processes are configured identically to the domain on which the slave template is based, including the PSWATCHSRV and PSMONITOR server processes. However, unlike the IB Slave Basic template, this option imports the PSAPPSRV, JSL, and JREPSVR processes from the domain on which the template is based. In addition you have the option to change the default Jolt port (Jolt port taken from the master configuration file). |
Understanding Importing Domain Configurations
To import the domain configuration on which the template slave domain is based, you use the Import Domain Configuration command in PSADMIN. You can import a domain that is already configured in PSADMIN or you can import a domain configuration from a file.
To import a domain configuration from an application domain you specify the location of <PS_CFG_HOME> for the domain that you want to import. For example, the location might be c:\documents and settings\admin\psft\ps\<PS_CFG_HOME>.
To import a PeopleTools 8.49 or earlier application domain you must specify the <PS_HOME> location for <PS_CFG_HOME>. For example, the location might be c:\documents and settings\<PS_HOME>\<PS_CFG_HOME>.
Prerequisites for Importing Domain Configurations
If you are importing a domain that is already configured in PSADMIN, you must first set the PS_FILEDIR environment variable equal to the PS_HOME location of the domain you importing.
If importing a domain configuration from a file, you must first set the PS_FILEDIR environment variable to the location where you are importing the file.
See Understanding Setting PS_FILEDIR and PS_SERVDIR Environment Variables.
Importing Domain Configurations from Files
To import a domain configuration from a file:
Open PSADMIN.
The PeopleSoft Server Administration menu appears.
Enter 1 for Application Server and press the ENTER key.
The PeopleSoft Application Server Administration menu appears.
Enter 4 for Import Domain Configuration and press the ENTER key.
The PeopleSoft Import Application Server Configuration menu appears.
Enter 2 for Import IB Master Configuration and press the ENTER key.
A Configuration Templates prompt appears.
Select one of the following options:
Enter 1 to import the domain as an IB Slave Basic template and press the ENTER key.
Enter 2 to import the domain as an IB Sync Slave template and press the ENTER key.
The PeopleSoft Import Application Server Configuration menu appears.
Enter 1 for Import from file and press theENTER key.
A prompt displays to enter the full path to the domain configuration file to import.
Enter the full path to the domain configuration file to import and press the ENTER key.
A prompt displays to enter a name for the new domain.
Enter a name for the new domain and press the ENTER key.
The system merges the domain configuration with the new template slave domain and creates the new configuration and loads it on the application server. Upon completion, the PeopleSoft Domain Administration menu appears, where you may boot the template slave domain, configure the template slave domain or perform other administrative tasks.
Importing Domain Configurations from Application Domains
To import a domain configuration from an application domain:
Open PSADMIN.
The PeopleSoft Server Administration menu appears.
Enter 1 for Application Server and press the ENTER key.
The PeopleSoft Application Server Administration menu appears.
Enter 4 for Import Domain Configuration and press the ENTER key.
The PeopleSoft Import Application Server Configuration menu appears.
Enter 2 for Import IB Master Configuration and press the ENTER key.
A Configuration Templates prompt appears.
Select one of the following options:
Enter 1 to import the domain as an IB Slave Basic template and press the ENTER key.
Enter 2 to import the domain as an IB Sync Slave template and press the ENTER key.
The PeopleSoft Import Application Server Configuration menu appears.
Enter 2 to for Import from application domain and press theENTER key.
A prompt displays to enter the location of <PS_CFG_HOME>.
Enter the location of <PS_CFG_HOME> and press theENTER key.
The Tuxedo Domain List appears that lists the application domains that you can import.
Enter the number that corresponds to the application domain to import.
A prompt displays to enter a name for the new domain.
Enter a name for the new domain and press the ENTER key.
The system merges the domain configuration with the new template slave domain and creates the new configuration and loads it on the application server. Upon completion, the PeopleSoft Domain Administration menu appears, where you may boot the template slave domain, configure the template slave domain or perform other administrative tasks.
Adding and Removing Dispatcher Queues from Template Slave Domains
This section applies only to asynchronous slave templates.
Template slave domains contain all of the dispatcher queues that exist on the domain on which it is based. However, you can add and remove queues to configure the template slave domain to suit your requirements.
Note: Before you can add or remove queues from a template slave, you must inactivate all domains.
The Slave Templates page (IB_DOMAIN2_SEC) lists the dispatcher queues assigned to each dispatcher process of the template slave.
Image: Slave Templates page
This example illustrates the Slave Templates page. Use this page to view the queues assigned to each dispatcher process of a template slave.
From the Slave Templates page, you can use the Add/Remove Queues link located under each dispatcher process name to access the Add/Remove Queues page to add or remove queues assigned to the dispatcher.
Image: Add/Remove Queues page
This example illustrates the Add/Remove Queues page. Use this page to add or remove queues for a dispatcher process of a template slave.
Note that this example shows a partial queue list for the domain.
On the Add/Remove Queues page you can use the plus (+) button to add a queue to the queue list. Use the minus (-) button to remove a queue from the list.
To add or remove dispatcher queues for template slaves:
Access the Domain Status page ().
Check the All Domains Inactive box and click the Update button.
The Force Reset button appears.
Click the Force Reset button to reset any contacts that are in a Started or Working state.
Click the Slave Templates link.
The Slave Templates page appears.
Click the Add/Remove Queues link for a queue dispatcher.
The Add/Remove Queues page appears and displays the queue list for the dispatcher.
To add a queue:
Click the plus (+) button to insert a new row into the list.
Click the Lookup button to search for a queue to add.
Click the OK button at the bottom of the Add/Remove Queues page.
The Slave Templates page appears.
Click the Update button.
The Domain Status page appears.
To delete a queue:
Click the minus (-) button next to the queue to delete.
Click the OK button in the dialog box to confirm the delete action.
Click the OK button at the bottom of the Add/Remove Queues page.
The Slave Templates page appears.
Click the Update button.
The Domain Status page appears.
Activate the domains in the messaging system.
Check the All Domains Active box and click the Update button to activate the domains.
Restoring Template Slave Dispatcher Queue Lists
Restoring a queue list deletes any changes you have made to a template slave dispatcher queue list, and restores it to the queue list that you originally imported from the master domain.
To restore a template slave queue list, use the Slave Template Cleanup page (IB_DOMAIN3_SEC).
Image: Slave Template Cleanup page
This example illustrates the Slave Template Cleanup page. Use this page to restore dispatcher queue lists to the default settings from the master domain.
In the previous example, PSBRKDSP_dflt appears in the Dispatcher Name field, meaning that additions or deletions have been made to the queue. In this example, you could use the page to restore the default template slave dispatcher list for PSBRKDSP_dflt.
To restore a template slave dispatcher queue list, you must first inactivate all domains on the system.
To restore a template slave dispatcher queue list:
Inactivate the domains on the messaging system:
Access the Domain Status page ().
Check the All Domains Inactive box and click the Update button.
The Force Reset button appears.
Click the Force Reset button to reset any contacts that are in a Started or Working state.
Access the Slave Template Cleanup page:
From the Domain Status page, click the Slave Templates link.
The Slave Templates page appears.
On the Slave Templates page, click the Slave Template Cleanup link.
The Slave Template Cleanup page appears.
Check the box next to each dispatcher process name for which you want to restore the default queue list.
Click the Restore Default(s) button.
The Domain Status page appears.
Activate the domains in the messaging system.
Check the All Domains Active box and click the Update button to activate the domains.
This section provides and overview of master-slave load balancing and discusses how to set up master-slave load balancing on the PeopleSoft system.
Understanding Master-Slave Load Balancing
You can implement master-slave load balancing on the integration system to compensate for processing capabilities of various machines on which master domains and slave domains run.
As an example, you might have a domain on machine that is also running the PeopleSoft Pure Internet Architecture. In this case, you could configure master-slave load balancing such that the machine that is running the PeopleSoft Pure Internet Architecture processes fewer requests than other machines on which domains reside.
Another example is a situation where the machines on which you are running domains have different processing capabilities due to the hardware installed in them. In this situation you can configure the machines with the most process power to process the greater number of requests.
To configure master-slave load balancing, you assign a weight between1 and 10 to each domain to distribute request processing. A domain assigned a weighted value of 1 processes the fewest requests; a domain assigned a weighted value of 10 processes the greatest number of requests.
Setting Up Master-Slave Load Balancing
You set up master-slave load balancing using the Master/Slave Load Balancing page (IB_DOMAIN_SEC).
To set up master/slave load balancing, you assign a processing weight value to each domain. The domain with the lowest number processes the fewest number of requests and is the master domain. The domains with the higher numbers are the slave domains and process the greatest number of requests.
Image: Master/Slave Load Balance page
This example illustrates the Master/Slave Load Balance page. The example shows master/slave load balancing set up for the system.
The Domain section on the page lists information for the master domain, while the Static/Template Slave Domains section lists information about static slave domains.
The example shows two domains configured on one machine. The domain listed in the Domains section, QEDMO, is the master domain and has a load balance weight of 1 assigned to it. Given the load balance weight assigned to the domain, it processes the fewest number of requests.
The domain listed in the Static/Template Slave Domains section, DOMAIN002, has a load balance weight of 5 assigned to it. It processes a greater number of requests than the master domain.
To set up master-slave load balancing:
Access the Master/Slave Load Balance page ( and click the Master/Slave Load Balance link.).
For each domain select a value from the Weighted drop-down list box to assign a load balancing weight for the domain.
Click the OK button.
Setting Up Master-Slave Load Balancing for Long-Running Events
Typical master-slave load balancing usually focuses on normal events running at a high throughput. However, there are some instances where there are low volume service operation that contain long-running events. For better performance, you can assign these types of service operation to long-running event queues, where the processing is spread across all potential master and slave handlers.
You use the IB Long Running Event Queues page (IB_DOMAIN4_SEC) to assign service operations to long-running event queues.
Image: IB Long Running Event Queues page
This example illustrates the IB Long Running Event Queues page.
To assign a service operation to a long-running event queue, you add the service operation queue that is currently defined on the service operation definition to one of the dispatcher queues on the page. When you click the Add/Remove Queues link for one of the dispatchers, the Add/Remove Queues page (PSIBQUEUE_SEC) appears.
Image: Add/Remove Queues page
This example illustrates the Add/Remove Queue page.
You use the Lookup button on the page to search for the service operation queue to which the service operation is assigned. When you click the OK button, the IB Long Running Event Queues page appears and the queue you specified appears in the dispatcher Queue field.
Image: IB Long Running Event Queues page
This example illustrates the IB Long Running Event Queues page. The example shows the service operation queue FLIGHTQUEUE added to the Broker Dispatcher queue.
The following table describes the proper dispatchers to which to assign service operation queues based on the type of processing required:
|
Dispatcher |
Processing |
|---|---|
|
Broker Dispatcher |
|
|
Publication Dispatcher |
|
|
Subscription Dispatcher |
|
Important! Do not assign service operations that contain long-running events to the same queues as those that do not contain long-running events. Processing performance for the normal high-volume service operations can be impacted.
To assign a service operation to a long-running event queue:
Access the Domain Status page ().
The Domain Status page appears.
Inactivate the domain.
In the Domains grid, locate the Domain Status drop-down list box and select Inactive.
Click the Force Reset button.
Click the Master/Slave Load Balance link.
The Master/Slave Load Balance page appears.
Click the Add Long Running Event Queues link.
The IB Long Running Event Queues page appears.
Click the Add/Delete Queue link for the dispatcher to which to add the service operation queue.
The Add/Remove Queues page appears.
Enter a name or use the Lookup button to search for the name of the queue to which the service operation is assigned.
Click the Update button.
The Master/Slave Load Balance page appears.
Click the OK button.
The Domain Status page appears.
Activate the domain by selecting Active from the Domain Status drop-down list in the Domains grid.
Click the Update button.
This section provides an overview of deferred master domain processing and discusses how to set up deferred master domain processing.
Understanding Deferred Master Processing
PeopleSoft Integration Broker enables you to defer request processing on master domain to slave domains that are available for processing. Configuring deferred master processing enables you to free processing resources on the master domain machine due to hardware or processing power limitations, or so it can run other processes.
The Master/Slave Load Balance page features a Master Processing Status drop-down list box where you set the processing status for the master domain. The following table lists the master processing statuses and their descriptions.
|
Master Domain Processing Status |
Description |
|---|---|
|
Enabled |
The master domain processes its appropriate share of requests. (Default.) |
|
Deferred – All Queues |
The master domain does not send any requests to its respective process handler(s) as long as there is at least one active slave domain that can be used for the dispatch cycle. |
|
Deferred – Unordered Queues |
The master domain does not send any requests in an unordered queue to its respective process handler(s) as long as there is at least one active slave domain that can be used for the dispatch cycle. When you select this option the master domain dispatchers only send requests to a slave domain for processing if the queue being processed is defined as unordered queue. If the queue is not unordered, the master domain sends the request to its own process handler for processing not to the slave domain. |
If the system is set to any of the deferred modes the master will process requests if no slave dispatchers are available. In each of the deferred modes, the master assigns processing to slave dispatchers based on the load balancing weight value assigned to the slave dispatcher.
Setting Up Deferred Master Domain Processing
To set up deferred master domain processing:
Select .
The Domain Status page appears.
Click the Master/Slave Load Balance link.
The Master/Slave Load Balance page appears.
From the Master Processing Status drop-down list box, select a master domain processing status.
The valid values are:
Enabled
Deferred — All Queues
Deferred — Unordered Queues
Click the OK button.