Configuring Siebel Server Load Balancing

Load balancing distributes the workload across multiple Siebel Servers. For background information and initial configuration information about load balancing, see Siebel Deployment Planning Guide and the Siebel Installation Guide for the operating system you are using.

This topic includes the following information:

"Enabling Siebel Native Load Balancing"
"Changing the Enterprise Configuration Under Siebel Native Load Balancing"
"Optimizing Performance for Siebel Native Load Balancing"
"Rebalancing Siebel Server Loads"
"Revising the Third-Party HTTP Load Balancer Configuration"
"Troubleshooting Siebel Native Load Balancing"
"Verifying IP Access to Load-Balanced Siebel Servers"
"Verifying Load Balancing Port Access on Siebel Servers"

Enabling Siebel Native Load Balancing

After you install and configure the Siebel Servers and install the Siebel Web Server Extension (SWSE), you start the SWSE Configuration Wizard to enable Siebel native load balancing. You generate the load balancing configuration file (lbconfig.txt) and place it in the directory where you store the SWSE logical profile, and then you configure the SWSE (apply the logical profile). For information about generating the lbconfig.txt file and applying an SWSE logical profile, see the Siebel Installation Guide for the operating system you are using. For more information about the lbconfig.txt file, see Appendix D, "Structure of the lbconfig.txt File."

When you select Siebel native load balancing in the SWSE Configuration Wizard, the wizard then adds the Siebel native load balancing information specified in the lbconfig.txt file by modifying parameters in the SWSE configuration file (eapps.cfg) of the installed SWSE. The SWSE Configuration Wizard also copies the lbconfig.txt file from the directory that stores the SWSE logical profile to the SWSE_ROOT\admin directory, where SWSE_ROOT is the installation directory for the Siebel Web Server Extension.

Note:

You must apply the SWSE logical profile to all of the Web servers where the SWSE is installed for Siebel native load balancing to function correctly.

Table 3-2 describes the load-balancing parameters in the eapps.cfg file.

Table 3-2 Siebel Native Load Balancing Parameters in the ConnMgmt Section of eapps.cfg

Variable Name Acceptable Values Description

Variable Name	Acceptable Values	Description
EnableVirtualHosts	True or False	Settings include: Set to True to enable Siebel native load balancing. Set to False to disable Siebel native load balancing. If you are configuring a third-party HTTP load balancer, then this variable must be set to False.
VirtualHostsFile	`pathname`	Represents the full path to the lbconfig.txt file. The lbconfig.txt file is copied to the following default location when you apply an SWSE logical profile: `SWSE_ROOT\admin\lbconfig.txt` where SWSE_ROOT is the installation directory for the Siebel Web Server Extension.

EnableVirtualHosts

True or False

Settings include:

Set to True to enable Siebel native load balancing.
Set to False to disable Siebel native load balancing.

If you are configuring a third-party HTTP load balancer, then this variable must be set to False.

VirtualHostsFile

pathname

Represents the full path to the lbconfig.txt file. The lbconfig.txt file is copied to the following default location when you apply an SWSE logical profile:

SWSE_ROOT\admin\lbconfig.txt

where SWSE_ROOT is the installation directory for the Siebel Web Server Extension.

Changing the Enterprise Configuration Under Siebel Native Load Balancing

The most common configuration changes that affect load balancing performance are as follows:

Adding or removing Siebel Servers
Enabling or disabling Application Object Manager components

Update your lbconfig.txt file to reflect post-configuration changes in your Siebel environment. The recommended method of updating the lbconfig.txt file is to regenerate it and reapply the SWSE logical profile, as described in "Enabling Siebel Native Load Balancing". This topic describes how to manually edit the lbconfig.txt file to reflect post-configuration changes.

Adding or Removing Siebel Servers

If you add or remove Siebel Servers that are being load-balanced, then you must revise the lbconfig.txt file to add or remove the servers from the VirtualServer definition. You can revise the lbconfig.txt file, as described in "Enabling Siebel Native Load Balancing". Alternatively, if you have optimized the lbconfig.txt file, as described in "Optimizing Performance for Siebel Native Load Balancing", then you might consider editing the file instead. Editing the file preserves your existing settings. After you edit the lbconfig.txt file, restart the Web server. Repeat these steps for all of the Web servers on which the SWSE is installed. You do not have to revise the SWSE configuration file (eapps.cfg).

Enabling or Disabling Application Object Managers

If you enable or disable a load-balanced Application Object Manager, then you must edit the lbconfig.txt file if either of the following is true:

You are enabling an Application Object Manager on a Siebel Server that is not included in the VirtualServer definition in lbconfig.txt. Edit the definition to add the server.
You are disabling an Application Object Manager on a server, and the Application Object Manager is the only one being load-balanced on the server. To prevent failed connection attempts, remove the Siebel Server from the VirtualServer definition in lbconfig.txt.

After you save the file, restart the Web server. Repeat these steps for all of the Web servers on which the SWSE is installed. You do not have to edit the SWSE configuration file (eapps.cfg).

Optimizing Performance for Siebel Native Load Balancing

By default, Siebel native load balancing maps all of the Siebel Servers to a single virtual server after generating the lbconfig.txt file. All of the Application Object Manager connection strings receive the virtual server name in the SWSE configuration file (eapps.cfg). This configuration allows the SWSE to distribute requests for all of the Application Object Managers to all of the participating Siebel Servers.

When the SWSE sends a request for an Application Object Manager to a Siebel Server on which the Application Object Manager is not running, these requests fail. When this situation occurs, the SWSE automatically sends the failed request to another Siebel Server. Typically, users do not notice these retries unless the allowed maximum number of retries is exceeded.

The allowed maximum number of retries is five. Therefore, if there are more than five load-balanced Siebel Servers on which an Application Object Manager is not running, then you might consider optimizing the load balancing configuration file. This configuration prevents users from experiencing failed attempts to start applications.

You optimize lbconfig.txt by adding additional virtual server definitions that define the groups of Siebel Servers on which particular Application Object Managers run. You then edit the Application Object Manager connection strings in the SWSE configuration file (eapps.cfg) to include the virtual server specific to each Application Object Manager. You edit the connection strings in the eapps.cfg file after you apply an SWSE logical profile. Reapplying an SWSE logical profile updates the eapps.cfg file, and you lose the changes that you made to the connection strings.

For example, you have two Siebel Servers, Sieb1 and Sieb2, which run the Application Object Managers for Japanese that are shown in Table 3-3.

Table 3-3 Application Object Managers Running on the Siebel Servers

Sieb1	Sieb2
Call Center Object Manager (JPN)	Call Center Object Manager (JPN)
Sales Object Manager (JPN)	Sales Object Manager (JPN)
eChannel Object Manager (JPN)	Marketing Object Manager (JPN)

To minimize retries, delete the existing VirtualServer definition in lbconfig.txt and define four virtual servers as shown in the following examples:

#Section one -- Session Manager Rules:
CallCenterVirtualServer=1:sieb1:2321;2:sieb2:2321;
SalesVirtualServer=1:sieb1:2321;2:sieb2:2321;
eChannelVirtualServer=1:sieb1:2321;
MarketingVirtualServer=2:sieb2:2321;

Then edit the connection strings in the SWSE configuration file (eapps.cfg) as in the following examples for Japanese:

Call Center Object Manager (JPN). ConnectString = siebel.TCPIP.none.none://CallCenterVirtualServer/SBA81/SCCObjMgr_jpn
Sales Object Manager (JPN). ConnectString = siebel.TCPIP.none.none://SalesVirtualServer/SBA81/SSEObjMgr_jpn
eChannel Object Manager (JPN). ConnectString = siebel.TCPIP.none.none://eChannelVirtualServer/SBA81/eChannelObjMgr_jpn

Marketing Object Manager (JPN). ConnectString = siebel.TCPIP.none.none://MarketingVirtualServer/SBA81/SMObjMgr_jpn

Note:

If you optimize lbconfig.txt by creating multiple virtual server definitions, then you lose these changes if you generate the file again. To prevent this situation, save the file under another name before generating it. Then copy your additional virtual server definitions to the new file.

To optimize the load balancing configuration file

Start Siebel Server Manager and enter the following command to obtain Siebel Server IDs.
```
list server show SBL_SRVR_NAME, SV_SRVRID
```
Write down the Siebel Server IDs of the servers that you want to add to virtual server definitions.
Navigate to the directory where you store the SWSE logical profile and open the lbconfig.txt file with a text editor.
In Section One, add additional virtual server definitions. Save the file.
Apply the SWSE logical profile to the Web server that hosts the SWSE.
Open the SWSE configuration file, eapps.cfg, with a text editor.

Its default location is in SWSE_ROOT\bin, where SWSE_ROOT is the installation directory for the SWSE.
Change the virtual server name in the Application Object Manager connection strings, then save the file.
Restart the Web server.

Rebalancing Siebel Server Loads

Server loads can become unevenly distributed for several reasons:

You have just added a new Siebel Server to the network. It will have a low workload compared to other Siebel Servers.
You have just enabled an Application Object Manager on a Siebel Server. It will have a lower workload than other Application Object Managers on different Siebel Servers.
There was a server configuration or request routing problem that prevented even distribution of workloads. When this problem is corrected, one or more Siebel Servers will have low workloads.

Siebel native load balancing distributes workloads based on logins. Users must terminate existing sessions and log in to the new sessions to cause workloads to be redistributed. For example, you have 1000 concurrent user sessions running on three Siebel Servers. You then add a fourth Siebel Server. Until all of the users end their sessions and log in again, the load is not evenly distributed between all four servers.

Whenever possible, let normal user login behavior rebalance Siebel Server workloads. Intervene only when absolutely necessary. Use one of the following methods to rebalance server workloads:

Stop SCBroker on a Siebel Server. Doing so directs workload away from that server, but does not affect existing user sessions. However, SISNAPI session reconnect does not work for this server. If the SISNAPI connection times out, and user requests come through a Web server other than the one used for login, then the session is lost.
Revise the lbconfig.txt file to remove a Siebel Server, as described in "Changing the Enterprise Configuration Under Siebel Native Load Balancing". Removing a Siebel Server from load balancing directs its workload to other servers. If you have only one Web server, then removing a Siebel Server from the file terminates all of the user sessions. If you have multiple Web servers, then users making a session request might experience session termination. Use this method only as a last resort.

Revising the Third-Party HTTP Load Balancer Configuration

You must revise the third-party HTTP load balancer configuration or edit the SWSE configuration file (eapps.cfg) if you do either of the following:

Add or remove a Siebel Server that is load-balanced.
Enable or disable an Application Object Manager that is load-balanced.

Requirements for Configuring Third-Party Load Balancing

Observe the following requirements for configuring third-party load balancing:

Verify that all of the Siebel Servers that you want to load-balance are running.
Verify that the Application Object Managers that you want to load-balance are running. Disable any Application Object Managers that you do not want to load-balance.
Obtain the virtual IP (VIP) address and port number for the load balancer.
Review the layout of the load-balancing configuration file.

Several of the steps in the following procedures are about manually modifying the configuration of the load balancer. If a script is available that automatically imports server configurations, then run this script instead.

Revising the Load Balancer Configuration After Adding or Removing a Load-Balanced Siebel Server

Use the following procedure to revise the load balancer configuration after adding or removing a load-balanced Siebel Server.

To revise the load balancer configuration after adding or removing a load-balanced Siebel Server

Add or remove the Siebel Server.

See the Siebel Installation Guide for the operating system you are using.
Generate a new lbconfig.txt file.

Doing so updates the URL mappings in the file to reflect the new or removed server. See the Siebel Installation Guide for the operating system you are using.
Place the new lbconfig.txt file in the directory where you store the SWSE logical profile.
Use a text editor to view the lbconfig.txt file.

Use the file to obtain URLs for editing rules in the following steps.
Start the load balancer configuration software.
Update the resource group definitions to reflect the added or removed server.
Revise the component and round-robin rules to reflect the added or removed Application Object Manager running on the server.
If you are adding a server, then create a server rule. If you are deleting a server, then delete the server rule.
Save the configuration.
Apply the SWSE logical profile to Web servers where the SWSE is installed.

See the Siebel Installation Guide for the operating system you are using.

Revising the Load Balancer Configuration After Enabling or Disabling an Application Object Manager on a Load-Balanced Siebel Server

Use the following procedure to revise the load balancer configuration after enabling or disabling an Application Object Manager on a load-balanced Siebel Server.

To revise the load balancer configuration after enabling or disabling an Application Object Manager on a load-balanced Siebel Server

Enable or disable the Application Object Manager.

For more information, see "Configuring the Siebel Server".
Generate a new lbconfig.txt file.

See the Siebel Installation Guide for the operating system you are using.
Place the new lbconfig.txt file in the directory where you store the SWSE logical profile.
Use a text editor to view the lbconfig.txt file.

Use the file to obtain URLs for editing rules in the following steps.
Start the configuration software for the third-party load balancer.
Revise the component and round-robin rules to reflect the added or removed Application Object Manager.
Save the configuration.
Apply the SWSE logical profile to Web servers where the SWSE is installed.

See the Siebel Installation Guide for the operating system you are using.

No changes are required to the server rules that manage reconnection requests in the load balancer.

Troubleshooting Siebel Native Load Balancing

This topic provides guidelines for resolving problems with Siebel native load balancing. To resolve a problem, look for it in the list of symptoms or error messages in Table 3-4. Some problem solutions in the table require changing the function of server components.

Table 3-4 Resolving Siebel Native Load Balancing Problems

Problem	Cause	Solution
Users do not get a login page. The browser might display `Server Busy Error`.	Verify IP access to Siebel Servers.	See "Verifying IP Access to Load-Balanced Siebel Servers".
	Verify TCP port access on Siebel Servers.	See "Verifying Load Balancing Port Access on Siebel Servers".
	Verify that the SWSE is configured correctly.	The SWSE configuration file (eapps.cfg) is located in `SWSE_ROOT`\`bin`, where SWSE_ROOT is the installation directory for the SWSE. Open the file and check the following: EnableVirtualHosts is True. VirtualHostFile is set to the full path to the lbconfig.txt file. The default location for this file is `SWSE_ROOT`\`admin`, where SWSE_ROOT is the installation directory for the SWSE. For each load-balanced Application Object Manager, verify that the virtual server specified in the connection string matches the one in lbconfig.txt.
	Verify that Siebel native load balancing is configured correctly.	The default location for the load balancing configuration file (lbconfig.txt) is `SWSE_ROOT`\`admin`, where SWSE_ROOT is the installation directory for the SWSE. Typically, this file is generated automatically. If you have edited the virtual server definition, then do the following: Verify that the syntax of the virtual server definition is correct. For each Siebel Server in a virtual server definition, verify that the server ID (sid) is correct.
	Check whether a Siebel Server has been reinstalled or reconfigured.	If so, then the load balancing configuration file (lbconfig.txt) must be edited or regenerated.
	Increase the SWSE logging level.	To turn on detailed SWSE logging, set the following environment variables: SIEBEL_SESSMGR_TRACE=1 SIEBEL_LOG_EVENTS=ALL Then restart the Web server. If this logging level does not reveal the problem, then set the following: SIEBEL_SISNAPI_TRACE=1 This setting greatly increases the logging level for SISNAPI message handling.
	Configure a Web server to connect directly to a Siebel Server.	Open the SWSE configuration file (eapps.cfg) and edit the connection string for an Application Object Manager to specify a known good Siebel Server. Restart the Web server and try to log in. If the login succeeds, then the problem is with the Siebel native load balancing configuration. If the login fails, then the problem is related to network connectivity.
Users can connect but loads are not balanced evenly between Siebel Servers	Unequal loads might be caused by characteristics of users and jobs.	Because jobs are distributed in a round-robin fashion, it is normal for a snapshot of the servers to show somewhat unequal loads. Unequal loads can be caused by several things, including the nature of the jobs and the rate at which users log in and log out on different servers. Over a longer period, the number of sessions handled by each server evens out.
	Siebel Servers do not have equal access to computing resources.	Verify that all of the Siebel Servers have equal access to computing resources such as CPU and memory.
	A Siebel Server has recently added or has been restarted.	Load balancing is based on user logins. During the process in which current sessions are terminated and new sessions are started, the new Siebel Server is included in the load sharing.
	A Web server cannot route requests to one or more Siebel Servers.	Check for connectivity problems between the Web servers and the Siebel Server with the low workload, as described earlier in this table.
	A Siebel Server is rejecting an unusual number of user requests.	Check the SWSE log files for `SISNAPI Connection Refused` messages. Possible causes are: The SCBroker component either is not running or is listening on a different port. The requested Application Object Manager is not running or cannot run any more tasks. The requested Application Object Manager has a task or thread that is not responding. The Application Object Manager cannot communicate with the database server.
	A Siebel Server has functional or configuration problems.	Enable server diagnostics. Look for problems with components. Verify that the basic configuration is correct. For more information about monitoring and diagnosing server problems, see Siebel System Monitoring and Diagnostics Guide.

Verifying IP Access to Load-Balanced Siebel Servers

This topic describes how to verify IP access to the load-balanced Siebel Servers.

To verify IP access to the load-balanced Siebel Servers

Open the lbconfig.txt file.

Its default location is SWSE_ROOT\admin, where SWSE_ROOT is the installation directory for the SWSE.
Write down the exact string used to identify the Siebel Servers in the Virtual Server definitions.

This string is either a host name or an IP address.
On the Web servers where SWSE is running, ping each Siebel Server. Use the string from the lbconfig.txt file.

If the ping succeeds, then there is IP access. If the ping does not succeed, then complete the remaining steps that follow.
Verify that the Siebel Servers are on the network and running.
Check for basic networking problems such as cabling, routers, and so on. Verify there is a physical path between the Web servers and Siebel Servers.
If the Siebel Servers are part of multiple networks, then verify that the Web servers and Siebel Servers have a network in common.
If you used the host name to do the ping, then verify that the Siebel Servers are registered correctly in the DNS and that the names resolve to the correct IP address.
Check that no other networking device, such as a router or firewall, is blocking access to the Siebel Servers.

Verifying Load Balancing Port Access on Siebel Servers

This topic describes how to verify access to the load balancing port (that is, the port on which the SCBroker component listens) on your Siebel Servers.

To verify load balancing port access on your Siebel Servers

On the Web servers where SWSE is running, telnet to the SCBroker port (such as 2321) on each Siebel Server.

For example, if a Siebel Server has the host name SiebSrvr1, then use the following command:
```
telnet SiebSrvr1 2321
```
If the connection succeeds, then there is load balancing port access. The connection times out after 500 ms.

If the connection fails, with the message Could not open connection to server, then complete the remaining steps that follow.
Verify that the Siebel Business Applications that you want are running on each Siebel Server.
On each Siebel Server, verify that SCBroker is running and is configured to listen on port 2321.
Verify that the operating system is not blocking access to the SCBroker port.
Check that no other networking device, such as a firewall, is blocking access to the SCBroker port.