Technote540-Configuring A Third Party HTTP Load Balancer For Siebel Server Load Balancing

Technical Note 540: Configuring a Third Party HTTP Load Balancer for
Siebel Server Load Balancing
Last Modified: 30 June 2004

Area(s): Installation, System Administration, Upgrade
Release(s): V7 (Enterprise)
Database(s): All Supported Databases
App Server OS(s): All Supported Platforms
Latest release tested against: V7 (Enterprise)
Keywords: F5, BigIP, Big IP, Load Balancing
Notice
This technical note applies to Siebel version 7.7 and higher only. It does not apply to previous
Siebel versions 7.5.x, 7.0.x, 6.x, etc. as Resonate Central Dispatch is used for load balancing in
these versions.
Before deploying a third party Load Balancer with the Siebel Applications, Siebel Systems
recommends that you review this technical note in detail. Siebel Systems also strongly
recommends that customers are proficient with F5 BIG-IP technology or have an F5 BIG-IP
consultant on-site for assistance.
Use the information in this technical note with the Deployment Planning Guide in the Siebel
Bookshelf, as there are extensive cross references between this technical note and the
Deployment Planning Guide. This document does not cover the installation and the initial set up
of the Load Balancer hardware or software. It assumes that the Load Balancer solution has been
installed and set up correctly. This document also does not cover the configuration of load
balancing for Web servers. This document focuses on Siebel Server (Object Manager) load
balancing only.
Third party Load Balancer configuration information is subject to change by third party vendors.
Review the third party vendor’s documentation carefully whenever there appears to be a
discrepancy. Please report any necessary updates to Siebel Technical Support and this
document will be updated appropriately as needed.
Background
The focus of this technical note centers on using a third party HTTP Load Balancer with Siebel
Servers. For details on Siebel Load Balancing configuration and deployment, please consult the
Deployment Planning Guide in Siebel 7.7 Bookshelf.
The following topics are discussed in this technical note:
Notice
Background
Summary
Technology Background
HTTP Load Balancer Technology
Siebel Load Balancing
General Steps to Configure Third Party HTTP Load Balancing
Load Balancing Options and Comparison
page 1 of 56
Technical Note 540: Configuring a Third Party HTTP Load Balancer for Siebel Server Load Balancing
General Installation and Configuration Steps

Step 1. Determining Third Party HTTP Load Balancer Compatibility
Step 2. Pre-Configuration Checks
Step 3. Setup Servers, Routing Rules, and VIPs
Step 4. Verify Load Balancer Configuration
Advanced Deployment Options
Adding or Removing Server Components or Servers
HTTP Load Balancer Implementation Limitation
Configuring the F5 BIG-IP System
Complete Configuration Steps for the F5 BIG-IP System
Step 1. Preparing the F5 BIG-IP System for a Siebel Installation
Step 2. Install Siebel Application on Siebel Servers
Step 3. Verify Siebel Servers are Installed and Configured Properly
Step 4. Generate and Modify Load Balancing Configuration File
Step 5. Generate the F5 Configuration File
Step 6. Setup Server Pools, Rules, and VIPs
Step 7. Choose a Load Balancing Scheme
Step 8. Set up a Health Monitor
Step 9. Post Configuration Verification
Step 10. Install SWSE and Get a Login Page
Add or Remove a Siebel Server or Application for the F5 BIG-IP System
Adding a Siebel Server
Removing a Siebel Server
Adding an Application Object Manager
Removing an Application Object Manager
Appendix A: Sample lbconfig file and the Cleanup Process
Appendix B: Perl Script for F5 BIG-IP System Configuration
Appendix C: Trouble-Shooting Perl Script Compilation
Bad File Name
Perl Script Compiler is not installed
Invalid host name in the lbconfig.txt
Other errors not captured by the Perl script
Appendix D: Troubleshooting F5 BIG-IP System Configuration Issues
Node is marked as down
Node is marked up, but continuous attempts to login gets “Server Busy” error in the browser
Login is possible, but only after many refreshes
Login is possible, but it takes a long time to get the login screen
Login is posible, but many unexpected “Server Busy” errors appear, which ends the
sessions
User session distribution across servers is uneven
Appendix E: Manual Configuration of F5 BIG-IP System
Summary
Technology Background
Application Server load balancing is the primary mechanism to achieve horizontal scalability for a
Siebel application deployment. It allows Siebel application load to be distributed across multiple
servers, as the number of concurrent user increases. Furthermore, load balancing provides
reliability and redundancy to Siebel Servers, offering resiliency to general failures in one or more
Siebel Servers. Lastly, it offers flexibility in operation and maintenance, as servers can be
removed and put back into operation to handle tasks such as operating system (OS) upgrades,
hardware (HW) upgrades, etc.
In Siebel 7.5 and prior, Resonate Central Dispatch software is integrated with Siebel Applications
to provide the load balancing functionality for the Siebel Servers. It was the only supported
page 2 of 56
solution for Siebel 7.5 and prior versions. The following diagram depicts a Siebel 7.0 or Siebel 7.5
logical architecture:
Web HTTP HTTP Load Balancer HTTP

Browser HTTPS HTTPS
Web Web Server Web Web Server

Server Server
SWSE SWSE
SISNAPI/SSL
VIP/VPort
Resonate Central Dispatch
SISNAPI/SSL
Listening Ports Listening Ports
OM OM OM OM OM OM
Server
SRB SRB Comp.
Siebel Siebel
SISNAPI
Server Server
page 3 of 56
Starting in Siebel 7.7, Resonate Central Dispatch is no longer supported, and the following
choices to load balance the Siebel Servers are available:
• Using Siebel-Provided Load Balancing, or Siebel Load Balancing. A logical architecture

diagram with Siebel Load Balancing is:

Browser HTTPS HTTPS

Server Server
SWSE SWSE
SISNAPI/SSL
SISNAPI/SSL
Listening Port Listening Port
Siebel SCBroker Siebel SCBroker

Server Server
OM OM OM OM OM OM
SRB SRB Server

SISNAPI Comp.
page 4 of 56
• Using a third party HTTP Load Balancer. The architecture diagram then becomes:

Browser HTTPS HTTPS

Server Server
SWSE SWSE
SISNAPI/SSL
VIP/VPort
HTT
SISNAPI/SSL
Listening Port Listening Port
Siebel SCBroker Siebel SCBroker

Server Server
OM OM OM OM OM OM
SRB SRB Server

SISNAPI Comp.
The focus of this technical note centers on using a third party HTTP Load Balancer with Siebel
Servers. For details on Siebel Load Balancing configuration and deployment, please consult the
Deployment Planning Guide in the Siebel 7.7 Bookshelf.
HTTP Load Balancer Technology
As internet sites and traffic boomed in the late 1990’s, it became critical for a Web site to scale
across many Web servers as Web traffic increased. Therefore, the networking technology that
load-balances multiple servers quickly grew. One of the early pioneers in this area is Resonate.
When the Siebel Applications first integrated with the Resonate Central Dispatch product, it was
one of the most flexible load balancing products in the market. However, as the technology
progresses, hardware quickly gained the dominant portion of the market for a variety of reasons.
Today, a hardware-based Load Balancer is considered an integral part of the networking
infrastructure, and is quickly becoming a commodity type of product.
HTTP Load Balancers are also called Content Switches.
The cores of the HTTP Load Balancer technology are:
• Packet Inspection and Routing
This refers to the ability to parse information embedded in the network packets and
routes based on this embedded information. HTTP Load Balancers can parse and load
balance based on two types of information: HTTP header or TCP/IP information. Siebel
Server Load Balancing relies on HTTP level information.
• Connection Distribution
page 5 of 56
This refers to the ability to distribute TCP connection requests across multiple servers
based on heuristics, the load, latency, and response time information, or both.
• TCP Connection Management and Mapping
Track and manage the mapping of TCP connections between the client and Load
Balancer and between the Load Balancer and server.
• Network Switch
Higher-end HTTP Load Balancers also have an internal network switch, allowing servers
to directly connect to the Load Balancer.
In addition to HTTP traffic, Load Balancers can also be used to load balance network devices
such as the Domain Name Server, Firewalls, and Web Caches.
Not all Load Balancers are HTTP Load Balancers. There are IP-based Load Balancers (MS
Network Load Balancing, for example) that cannot route based on HTTP header information.
Network Load Balancers can be used to load balance IP-based traffic or devices, but not HTTP or
Siebel Application Server traffic.
Hardware Load Balancers are itself a network entity with its own IP addresses. They are
considered a part of the networking infrastructure, and typically are managed as such. There are
two major types of Hardware-based HTTP Load Balancers:
• Appliances: These Load Balancers have a PC and OS running inside, and in many cases
run Linux operating systems. These are typically lower-end Load Balancers that have
almost all of the features but have performance and scalability limitations due to the
architecture.
• Level 7 Switches: These Load Balancers are built from the ground up to handle level 7
(for example, HTTP) traffic. Internally it still runs an operating system, but also contains
chips specifically designed to handle certain intensive tasks.
page 6 of 56
Siebel Applications are indifferent to these two types of Load Balancers and both Appliances and
Level 7 switches interact with Siebel Applications in the same way. An example of how the Load
Balancer fits into the networking infrastructure is depicted in the figure below:
DMZ
Web Server 1 Web Server 1

IP:(192.168.0.11) IP:(192.168.0.11)
Hub/Switch (192.168.0.x)
Load Balancer
VLAN1 IP:(192.168.0.50)
VLAN2 IP:(10.1.0.50) Hub/Switch (10.1.0.x)
VLAN2 VIP:(10.1.0.100)
Siebel Server 1 SIebel Server 2

IP:(10.1.0.11) IP:(10.1.0.12)
Application Zone
In the example above, Siebel Servers and Web Servers exist in different Virtual LANs (VLANs).
Siebel Applications itself do not have any specific requirement around the implementation
topology of the Load Balancers, except for a few restrictions list below, in the General Installation
and Configuration Steps section detailed later in the document.
Overall network topology and layout, on the other hand, dictates where and how Load Balancers
can be deployed. Siebel Systems recommends that you work with your third party load balancing
vendors to ensure their network topology can work with the load balancing technology.
Siebel Load Balancing
Siebel Load Balancing resides in the Siebel Web Server Extension (SWSE) on the Web Servers.
It allows each instance of SWSE to distribute connection requests to multiple application servers
in a round-robin fashion. Application server information is stored in a Load Balancer configuration
file generated by a Server Manager command. For details on generating this file, as well as other
configuration steps for Siebel Load Balancing, please consult the Siebel 7.7 Deployment Planning
Guide for details.
General Steps to Configure Third Party HTTP Load Balancing
If you are setting up the F5 Networks® BIG-IP® product for load balancing, please review the
following section to gain a general understanding of the configuration process. However, when
page 7 of 56
you are ready to configure your F5 BIG-IP device, please jump to the next section, Configuring
the F5 BIG-IP System, for step-by-step instructions.
Load Balancing Options and Comparison
In Siebel 7.7, you can choose between three deployment options around load balancing:
1. No Application Server Load Balancing
In this case, each Web server is directly tied to an application server. Load balancing can
still be done in front of the Web servers, but the following restriction applies for such a
configuration:
• Web server failure prevents users from accessing the application server tied to that
Web server.
• Web server load balancing must be implemented with persistent sessions (sticky
sessions).
2. Siebel Load Balancing
Each Web server load balances between multiple application servers in a round-robin
fashion.
3. Third Party HTTP Load Balancing
The HTTP Load Balancer receives requests from all Web servers and distributes
connection requests to multiple Siebel Servers.
For a detailed comparison of these load balancing options, please refer to the “Load Balancing
and Resilient Processing Planning” chapter in the Deployment Planning Guide. In general, this
decision should be made based on your requirements and preferences. Siebel Systems only
recommends that you select a certified solution which provides you with the assurance that the
solution has been thoroughly tested against Siebel Application Servers.
General Installation and Configuration Steps
There are some general steps in installing and configuring for third party HTTP Load Balancers.
These steps are not specific to a particular HTTP Load Balancer, but rather apply to all HTTP
Load Balancers. Please read this section first before reading the vendor-specific sections.
page 8 of 56
Step 1. Determining Third Party HTTP Load Balancer Compatibility
First, check the Systems Requirements and Support Platforms (SRSP) document on SupportWeb
to see which HTTP Load Balancers have been certified. A certified HTTP Load Balancer has
gone through extensive testing to ensure compatibility, performance, scalability, and reliability
with Siebel Servers. Siebel Systems strongly recommends that you select a certified solution.
While only a limited number of HTTP Load Balancers have been certified, Siebel Servers are
designed to work with most industry-standard HTTP Load Balancers on the market today.
Without Siebel certification, however, it is not possible to determine whether non-certified HTTP
Load Balancers work with Siebel Servers. However, if the following known requirements are met,
then a HTTP Load Balancer is likely to be compatible with Siebel Servers:
• Level 7 (HTTP) Routing Capable: The HTTP Load Balancer must be able to route
requests based on HTTP header (URL) information.
• HTTP Load Balancer allows end points (Web Server and Siebel Server) to manage TCP
Connections: In other words, there is a one-to-one mapping between the client (Web
Server) and server (Siebel Server) TCP Sessions. If the Web Server makes one
connection request to the Load Balancer, the Load Balancer creates a corresponding
connection to the Siebel Server. If one end closes the TCP connection, then the Load
Balancer cleans up connections at the other end.
Most of the standard HTTP Load Balancers fit these requirements. Siebel Systems recommends
that you work with the third party vendor and verify compatibility before making any purchasing
decisions.
Step 2. Pre-Configuration Checks
Before configuring the HTTP Load Balancer to load balance Siebel Servers, check to ensure the
HTTP Load Balancer is set up properly to route TCP/IP and HTTP traffic. Setting up an HTTP
Load Balancer generally has the following steps (for hardware Load Balancers):
1. Plan out the network topology with the HTTP Load Balancer. The Load Balancer itself is
a network entity, and may require load balanced servers to reside in the same subnet.
Therefore, the Load Balancer affects how the network is laid out. You also need to plan
out what Virtual IP address to use, which Port to configure, etc.
2. Install the Load Balancer box in the Data Center and hook up the network cables to the
switches and hubs.
3. Initialize the Load Balancer with vendor-provided license keys, and assign static IP
addresses for the Load Balancer.
4. Setup failover boxes to ensure Load Balancer high availability
5. Configure the Network Gateway, Subnet, and all other networking parameters for the
Virtual LANs (VLANs) supported by this Load Balancer. This is typically a critical step, as
it determines what IP addresses Siebel Servers can use while being load balanced.
6. Set up machines that will host the Siebel application, and configure the TCP/IP properties
for these machines. Test out basic TCP/IP connectivity between the Load Balancer and
servers based on vendor instructions.
page 9 of 56
In general, setting up the networking infrastructure with the Load Balancer is not a trivial task. To
avoid last minute surprises, Siebel Systems strongly recommends that you complete network
configurations and the Load Balancer installation before installing Siebel Application Servers.
There are several Siebel-specific restrictions when planning out the networking topology:
• Each URL on each instance of the SWSE can only point to one Object Manager (OM)
connect string. This means one virtual IP (VIP) and virtual port combination per URL for a
particular SWSE.
• Each URL and OM connect string typically corresponds to one Siebel Application.
• Typically, one application has one VIP, although a VIP can be shared across multiple
applications. This allows all servers hosting an application to be load balanced together.
For example, for a customer running Call Center, Sales, and the eChannel applications,
the following partitioning schemes follows the above rule:
• VIP1: Call Center, Sales, and eChannel

• VIP1: Call Center and Sales. VIP2: eChannel
• VIP1: Call Center. VIP2: Sales. VIP3: eChannel
The following partitioning scheme does not:
• VIP1: Call Center, Sales. VIP2: Sales, eChannel

• Sales OM connect string can only point to one VIP
• It is possible to configure multiple VIPs for one Siebel Application, but the Web servers
must be partitioned accordingly. Typically, multiple Virtual IP addresses are unnecessary
unless the number of load balanced Siebel Servers exceeds the Load Balancer’s
limitation. For example, a particular Load Balancer can only support up to 64 nodes per
scheduling rule. Therefore, if you need to load balance more than 64 servers, then the
entire site must be partitioned into 2 Virtual IP Addresses. This means that both Web
Servers and Siebel Servers are also partitioned into 2 corresponding groups.
Step 3. Setup Servers, Routing Rules, and VIPs
The next step is to install Siebel Applications software. For details, please review the Deployment
Planning Guide and Server Installation Guide in the Siebel Bookshelf. Siebel Server Load
Balancer configuration is typically done after the Siebel Servers and Database Server have been
installed, but can be done before the Web servers are installed. To configure:
1. First, check the Deployment Planning Guide in the Siebel Bookshelf on configuration
recommendations. Pay special attention to SCBroker configuration. Set Default Task and
Maximum Task parameters to 2 for the SCBroker. This is the recommended value when
third party Load Balancers are deployed.
2. Generate the load balancing configuration file by logging into the Server Manager and
type “generate lbconfig”. This generates a load balancing configuration file in the
SIEBEL_INSTALLATION_ROOT/Admin directory.
3. Review the load balancing configuration file, and remove unnecessary entries for
applications not used. By default, the configuration file contains both enabled and
disabled applications.
page 10 of 56
Clean up the file so it does not contain excessive number of rules. For example, if you
only use the Sales Object Manager and EAI Object Manager, then remove all other
entries in the lbconfig file. Therefore, locate the entries in the lbconfig file containing the
names of the Object Manager used, and remove the other entries. There should be at
least one entry in each of the sections when this is completed. If too many rules are
removed accidently, you can easily re-generate the file by issuing the Server Manager
command.
For a detailed explanation of the various types of rules, please review the Deployment
Planning Guide.
4. At this point, the lbconfig file should contain only a handful of rules for each of the
sections. Ensure that component, server, and round-robin rules are still present.
5. For non-certified Load Balancers, there are two methods to enter these rules into the
Load Balancer:
• Manual – manually enter these rules into the Load Balancer using the Load
Balancer’s utilities
• Script – set up scripts to automatically load the content of the lbconfig.txt file into the
Load Balancer. This is very helpful for re-configuration, and you should check the
documentation from third party vendors to create such a script. Most typical third
party HTTP Load Balancers support automated configuration scripts.
6. At a high level, configuring these rules into the Load Balancer typically follows the steps
below:
a. Add load balanced Siebel Servers as resources.

b. Create groups of resources as a logical unit, such as a Pool or Cluster.
c. Open the lbconfig.txt file.
d. Create routing rules that map URLs with groups of resources (URL=Server1…)
based on information in the lbconfig.txt file.
For example, for the entry:
*/siebel/SCCObjMgr_enu/*=siebsrvr1:2321;siebsrvr2:2322
Configure the URL “/siebel/SCCObjMgr_enu” to route to servers with host names

siebsrvr1 on port 2321, and siebserver2 on port 2322.
e. Configure the load balancing scheme for the different types of rules.
• For component rules, use one of the recommended load balancing schemes
detailed in the next section.
• For server rules, use the default load balancing scheme. Since there is only one
server per rule, the load balancing scheme here does not matter.
• For round-robin rules, as the name implies, these rules must be set up to use a
round-robin load balancing scheme.
• For details, please review the Deployment Planning Guide.
f. Create VIP and Virtual Ports, which are also referred to as services.
g. Map VIP and Virtual Ports to the rules. This step allows the Web Server to route
requests to the VIP and Virtual Port, and the Load Balancer can then route requests
based on the specified rules.
page 11 of 56
Using an example to explain this, consider the following deployment:

Browser HTTPS HTTPS

Server Server
SWSE SWSE
Enterprise
Name = Siebel
VIP:VPort=10.1.0.100:2321 SISNAPI/SSL
HTTP Load Balancer

SISNAPI/SSL
Listening Port=2321 Listening Port=2322

SiebSrvr1 SiebSrvr2
ServerID=1 SCBroker SCBroker ServerID = 2
CallCenter Sales eChannel CallCenter Sales Marketing

OM OM OM OM OM OM
Ignoring section one, which is used only for Siebel Load Balancing, the lbconfig.txt file has the
following entries:
# Section two -- 3rd Party Load Balancer Rules
#Component Rules:
/siebel/SCCObjMgr_enu/=siebsrvr1:2321;siebsrvr2:2322
/siebel/SSEObjMgr_enu/=siebsrvr1:2321;siebsrvr2:2322
/siebel/eChannel_enu/=siebsrvr1:2321
/siebel/SMEObjMgr_enu/=siebsrvr2:2322
#Server Rules:
/siebel/*/!1.*=siebsrvr1:2321
/siebel/*/!2.*=siebsrvr2:2322
#Round Robin Rules:

/siebel/SCCObjMgr_enu/RR=siebsrvr1:2321;siebsrvr2:2322
/siebel/SSEObjMgr_enu/RR=siebsrvr1:2321;siebsrvr2:2322
/siebel/eChannel_enu/RR=siebsrvr1:2321
/siebel/SMEObjMgr_enu/RR=siebsrvr2:2322
The configuration steps are:
1. Set up three server pools, one containing siebsrvr1:2321;siebsrvr2:2322, one containing

siebsrvr1:2321, and one containing siebsrvr2:2322.
2. If the load balancing scheme is tied to a particular server pool, then create two pools
containing siebsrvr1:2321;siebsrvr2:2322. Configure one of the pools to use the round-
robin load balancing scheme. If the load balancing scheme is tied to a URL rule, then
skip this step.
page 12 of 56
3. Set up routing rules for each URL in the lbconfig.txt file, and map the URL to a server
pool. For example, create a rule to parse for “/siebel/SSEObjMgr_enu/”, and route
requests to siebsrvr1:2321 or siebsrvr2:2322.
NOTE: Not all Load Balancers support a wild card character in the middle of the URL. If
your Load Balancer does not, configure the server rules to parse for “*/!1.*” and “*/!2.*”
only. Under this URL configuration, however, a single Virtual IP Address and Port
combination cannot be shared across multiple Siebel Enterprises. Each enterprise
should have a unique Virtual IP address and Port combination.
4. Set up server health checks. If the Load Balancer supports HTTP-based health checks,
then Siebel Server health can be checked with HTTP messages. Set up instructions are
available in the Deployment Planning Guide, under the topic “Monitoring Servers with
Third-Party HTTP Load Balancers”. In general, Load Balancers support the following
types of health checks:
• ICMP Ping – Under this type of health check, the Load Balancer sends periodic pings
to the server. This is the most basic form of a health check.
• Capability: Determines if the target host is on the network or not. Verifies that
there is a network interface card or device listening on this IP address.
• Limitations: It cannot reliably verify whether the operating system or the Siebel
software is running on the target server or not. It cannot verify whether a TCP
open is open or not.
• TCP/IP Health Check – Under this type of health check, the Load Balancer opens a
temporary TCP/IP connection to the server.
• Capability: Determines if the target IP address and TCP port is open or not.
Verifies that there are some processes or programs that have opened the TCP
port.
• Limitations: Not recommended for checking Siebel Server health, as sometimes
it does not clean up TCP connections properly, which may potentially block
connection request into that Siebel Server. This check also cannot guarantee
whether the Siebel Application or another application is listening on the specified
TCP port.
• HTTP Health Check – Under this type of health check, the Load Balancer sends a
HTTP request to the server, and checks for return messages.
• Capability – Determines if the target IP address and TCP port is listening for
application-specific traffic. This is typically the most common form of health
check for HTTP Load Balancers.
• Limitations – Target application must support HTTP messages.
5. Next, select a load balancing scheme most appropriate for your deployment. Load
balancing schemes supported by most HTTP Load Balancers are compared and
described below. In general, schemes based on heuristics generally do a reasonable job
in balancing the load, although they do not react dynamically to changing user patterns.
For example, if more users logout in one server versus another, this server with less
users may be running at lower load for a little while. On the other hand, schemes that
react to user load or response time may do a better job to ensure the load is even. The
load balancing decisions, however, would be much harder to predict and troubleshooting
may become more difficult.
page 13 of 56
Load Load Distribution Advantages Limitations

Balancing Description
Scheme
Round Distributes Distribution pattern is May not work well with un-
Robin connection requests easily understood. equal configuration or
in a round-robin Evenly distributes new resources, as servers with
fashion. session requests less resources may reach
across Siebel Servers. capacity before the larger
This is a good servers.
scheme to start out
with when server
resources and
configuration are
identical.
Weighted Distributes Distribution pattern is Does not react dynamically
Round connections in a easily understood. to changing server load or
Robin round-robin fashion, Resolves the issue user login and logouts.
but with a user- where load balanced A re-started server may not
specified ratio servers have unequal pick up load quickly, as it
across servers. resources. must wait for its turn to pick
This is a good up new users.
scheme to start out
with when server
resources and
configuration are not
identical.
Open Distributes Allows servers with The number of TCP
Connections connection requests fewer connections to connections does not
to the server with pick up new user accurately reflect Siebel
the least number of sessions faster, and Server load or user session
open TCP reacts to user login distribution as by default
connections and logout dynamics these connections are
better. never closed once opened
by the Web Server.
Weighted Similar to the above, Better support for Same issue as above.
Open except you can unequal load
Connections specify weight so balanced servers.
connections are
distributed
according to this
ratio
Fastest Directs connection May shorten average Connection response time
Response requests to the response time by does not always
server that has the directing user to the correspond to Siebel
shortest latency server with best Server load as connection
when responding to performance. creation can be fast even
a connection when Siebel Server
request. processes are very busy.
Server Load Directs connection Better overall May be difficult to diagnose
or Resource requests to the distribution of load, load balancing issues as
Availability server with the least and accounts for any number of factors may
load or most different user affect load balancing.
available resources. patterns, loads, and Most Load Balancers
other dynamic factors. support this scheme
page 14 of 56
through custom scripts or

agents, but only a small
number of Load Balancers
natively support this
scheme.
Step 4. Verify Load Balancer Configuration
After completing the configuration, verify that the Load Balancer is set up for Siebel Server load
balancing. The steps are:
1. Ensure all Siebel Servers are up and running.
2. Check that the Load Balancer can reach all Siebel Servers by enabling ICMP health
check, which allows the Load Balancer to ping each Siebel Server. Or, if the Load
Balancer supports a telnet session, ping the Siebel Servers directly from the Load
Balancer. This verifies that IP address related information is set up correctly and the
Load Balancer IP is able to reach the Siebel Server IP addresses.
3. Ensure the Load Balancer can reach the SCBroker port on each Siebel Server by
enabling TCP health checks to the SCBroker ports in each Siebel Server. This check
may not be reliable, since SCBroker forces any such connection attempt to close after
500 ms. Also, any such health check should be disabled right away, before any user login
attempts are made.
Another option is to start a telnet session on the Load Balancer, and then try to telnet into
the Siebel Server with the following command:
telnet <host name or IP>:<SCBroker Port>
For example:
telnet SiebSrvr:2321
If the SCBroker (or any application) is listening on the port, then the telnet session is
opened briefly.
4. If Siebel Servers are pre-configured with the Web server (such as IIS on a Microsoft
Windows Server), set up a test page on each server. If possible, set up unique test pages
on each server, so that each server returns different content. This helps to determine if
the Load Balancer is able to hit all Siebel Servers.
Then set up a test HTTP rule and a test VIP. From one Web server, start a Web browser
and request the test page against the VIP. Use a round-robin scheduling rule as this test
allows the Load Balancer to hit all Siebel Servers. Repeat this test on all Web servers.
This test ensures that all Web servers can communicate with the Load Balancer, and the
Load Balancer can balance requests to all Siebel Servers.
5. If the Siebel Servers do not have any Web servers installed, then set up TCP routing
rules instead of HTTP rules. That is, forward a TCP/IP request to another TCP/IP
address:port. You can then use any TCP application running on the Siebel Servers to
verify communication.
page 15 of 56
Advanced Deployment Options
The Deployment Planning Guide in the Siebel Bookshelf discusses a number of potential
deployment options around co-locating Siebel Enterprises and Siebel Servers on a single
machine or UNIX partition. In general, load balancing can be set up with any recommended
deployment options referenced in the Deployment Planning Guide, but the following factors
should be considered:
• Define each Siebel Server as a unique combination of IP address and TCP (SCBroker)
port. Multiple Siebel Servers can share the same IP address, but each Siebel Server
instance must have its own TCP Port.
• By default, all Siebel Servers listen on the same (2321) port number. Therefore, it is
recommended to plan out port usage before installing Siebel Servers. It is possible to fix
port conflict after installation by using Server Manager, but may be time consuming to
diagnose such issues.
• Certain Load Balancers require the Virtual Port number to be the same as physical port
number on the servers. Cisco CSS is one such Load Balancer. Check with the third party
vendor for such restrictions and plan port number usage accordingly.
• It is technically possible to use multiple VIPs for one application in a single Siebel
Enterprise. This may be necessary if the Load Balancer imposes a limit on the number of
servers a single VIP may have. For example, for the Cisco CSS Load Balancer, a routing
rule may be configured with at most 64 nodes. However, it requires Web servers to be
partitioned into groups, with each group pointing to a different VIP. If this is required due
to the size of deployment, please contact Siebel Expert Services to assist in planning out
such deployments.
Adding or Removing Server Components or Servers
Configuration in the third party Load Balancer is static. Therefore, when a load balanced Siebel
OM component is added or removed from a server, third party configuration needs to be updated.
The same rule applies when a Siebel Server is added or removed from the load balancing pool.
There are essentially two ways to accomplish this:
• Completely re-generate the Load Balancer configuration by following the same steps as
initial configuration. This may incur a small downtime when the rules are being deleted
and re-created.
• Manually update the Load Balancer configuration using a Load Balancer specific
management tool. This should not incur any downtime.
In general, follow the recommended approach as documented in the “Managing Third Party Load
Balancer” chapter of the Deployment Planning Guide. In most cases, manual update requires a
relatively small effort and is not difficult to do. However, it should be done only with a good
understanding of what various scheduling rules are used for. This is documented in the “Load
Balancing and Resilient Processing Planning” chapter of the Deployment Planning Guide.
HTTP Load Balancer Implementation Limitation
A common feature or option for high-end HTTP Load Balancers is SSL Accelerator Module. It
offloads SSL overhead from the Web server into a dedicated device. Currently, it is not possible
to use the SSL Accelerator for Web Server to Siebel Server communications. It is true that
SISNAPI can be encrypted as an SSL connection, but currently the Web Server plug-in
negotiates the SSL handshake directly with the Siebel Server. Therefore, it cannot be used.
page 16 of 56
On the other hand, it may be possible to use the SSL accelerator for Web Browser to Web Server
communications.
Configuring the F5 BIG-IP System
The following are a set of specific steps to set up the F5 BIG-IP System for Siebel Server load
balancing.
Complete Configuration Steps for the F5 BIG-IP System
Step 1. Preparing the F5 BIG-IP System for a Siebel Installation
Before installing Siebel Applications, first setup the F5 BIG-IP device on the network and assign
IP addresses with license keys activated. Follow F5 documentation on how to initially set up the
F5 BIG-IP device. Several key points to keep in mind, however, include:
• In order to configure the F5 BIG-IP System for Siebel Application Servers, requires
administration access into the F5 BIG-IP device.
• Plan what network topology and IP addresses should be used for Siebel Servers. This
affects the network settings of F5 BIG-IP device.
• Plan access control and security aspects of the network. For example, determine if a
firewall will be deployed in front of the Siebel Servers.
• It is recommended to setup failover boxes to ensure Load Balancer high availability, and
remove a critical single point of failure in the deployment.
• Set up machines that host Siebel applications and configure the TCP/IP properties for
these machines. .Ensure there is TCP/IP connectivity between the Load Balancer and
servers.
• Lastly, if you have a support agreement with F5 Networks, check the F5 support site
(http://www.f5.com/support/) for any new documents on this topic.
These preparation steps are exactly the same as preparing Web servers to be load balanced by
F5 BIG-IP System. Consult F5 documentation and F5 Technical Support for any questions on
preparing the F5 BIG-IP System for installation.
Step 2. Install Siebel Application on Siebel Servers
The next step in the process is installing the Siebel application on designated servers. For each
server, it is critical to record IP addresses, host name, and the SCBroker port number specified
for the Siebel Servers. The default SCBroker port is 2321. This port is used for the Load Balancer
configuration.
After installation, enable the Siebel Server services and processes so it is up and running. It is
not required to start all Siebel Servers before setting up the load balancing; however, it allows you
to verify correct configuration during the setup process, as the Load Balancer can send health
checks to running Siebel Servers.
For details of installing Siebel application components, please consult the System Installation
Guide in the Siebel Bookshelf.
page 17 of 56
Step 3. Verify Siebel Servers are Installed and Configured Properly
After Siebel Servers have been installed, install the Siebel Web Server Extension on one of the
Web servers. During installation, you are prompted for your load balancing choice. For now, pick
the option where there is only one Siebel Server in the enterprise. Next, attempt to log in to the
Siebel Application through this Web Server. This verifies that the basic configurations have been
properly specified.
Step 4. Generate and Modify Load Balancing Configuration File
After Siebel Servers have been installed, generate the Load Balancing configuration file. Steps
are detailed in the Deployment Planning Guide. Basically, this is accomplished by first logging
into the Server Manager and typing the following command at the prompt:
generate lbconfig
A file named lbconfig.txt is generated in the SIEBEL_INSTALLATION_ROOT/admin directory.

Please see Appendix A: Sample Ibconfig File and the Cleanup Process for an example of the
lbconfig.txt file.
Before using this file to configure the F5 BIG-IP device, clean it up and remove un-used rules. To
do this, you should first determine which Application Object Managers are used or enabled and
where they are installed. Then remove unnecessary rules following the two step process below:
1. First, remove any Application Object Managers that are not available or enabled in the
deployment. For example, if only the Call Center and Sales applications are used in your
deployment, remove all entries not used for the Call Center and Sales applications. The
steps are:
a. Determine the Alias or Short Names for enabled Object Managers. A complete list of
OM names and their alias is listed in Appendix A of the Siebel System Administration
Guide in the Siebel Bookshelf. For example, the Call Center Object Manager alias is
sccobjmgr.
b. Identify and verify the URL entries in the lbconfig.txt file containing the alias of the
enabled Object Managers.
c. Remove all other URL entries that do not contain the alias for enabled Object
Managers. Since these URLs are intended for disabled or non-licensed components
they can therefore be safely removed.
2. Next, determine if all enabled Application Object Managers are running on all Siebel
Servers. If yes, then skip this step. The lbconfig.txt file is ready to use. If not, then create
a table mapping Siebel Servers against enabled Application Object Managers, such as
the table below. Using this table, identify the corresponding component and round-robin
scheduling rules based on the alias, and remove server entries from these rules.
Application Object Alias Enabled Application Servers

Manager
Please refer to Appendix A: Sample Ibconfig File and the Clieanup Process for a
complete step-by-step example of this process.
page 18 of 56
Step 5. Generate the F5 Configuration File
After a clean lbconfig.txt file has been generated, the next step is to convert the lbconfig.txt file
into F5 specific configuration commands. To assist in this process, a Perl script has been
provided to convert the lbconfig.txt contents into F5 BIG-IP System commands. To run the Perl
script and create the BIG-IP System commands, please follow the steps below:
1. Ensure you have all files and configuration information ready. You need the lbconfig.txt
file, the Virtual IP address that is used for load balanced Siebel Servers, and the Virtual
Port number.
2. Create a directory on your local PC to store working files for this configuration. For
example, D:\f5config.
3. Move the lbconfig.txt file into the directory created above.
4. Click on the link below to download the file, and click Yes when prompted.
technote540-1_siebbigip.zip
The WinZip is launched. Within the WinZip file is a file called siebbigip.pl. Extract the
content into the directory created in the last step, for example, D:\f5config. If you cannot
open this file, please refer to Appendix B: Perl Script for F5 BIG-IP System
Configuration.
5. Modify siebbigip.pl with the appropriate Virtual IP address, Host Name, and Virtual Port
Number (VPort). This is an optional step, as you can also specify them when compiling
the Perl Script. Search for the following string in the file
$VSERVER="127.0.0.1:2321";
Modify the IP address and Port number to the ones designated for your deployment. For
example, if the VIP and VPort for your deployment are 192.10.10.100 and port 2400, then
modify the line above to:
$VSERVER="192.10.10.100:2400";
Then update rule name with a meaningful name. Search for the string:
$RULE_NAME="NewRule";
Update “NewRule” to a meaningful name. A good naming convention is using the Siebel
Enterprise name in the rule name. For example, if the Siebel Enterprise name for this VIP
is CRMEnt1, then change the rule name to:
$RULE_NAME="CRMEnt1Rule";
Save the modified file.
6. Next, download a Perl script compiler. If you already have a Perl script compiler installed
on your workstation, please ignore this step. A free distribution of a Perl compiler is
available at http://www.activestate.com/Products/ActivePerl/.
7. Now, execute the Perl script in a command line interface. This is recommended because
compilation errors are displayed in the screen. On Windows, open a command prompt by
selecting Start > Run, then typing cmd, and clicking OK. On UNIX, open a command line
page 19 of 56
interface, change directory (cd) to the directory created above, for example, D:\f5config,
and type the file name of the Perl script on the command line. This executes the Perl
script and generates a file called bigip.cfg in the same directory. Compilation status and
error messages are returned to the screen.
The options available with the Perl script are listed below. They can also be listed by
running the command:
perl sieblbcfg.pl -?
Option Description Default value if not specified on

command line
-b output file for bigip config .\bigip.cfg
-c complete path to lbconfig.txt .\lbconfig.txt
-r BIG-IP System rule name NewRule
-v vserver:vport 127.0.0.1:2321
For example, a successful compilation looks like:
This means the compilation is successful and you are ready to move to the next step. If not,
please refer to Appendix C: Trouble-Shooting Perl Script Compilation for information on
troubleshooting the Perl script compilation.
Step 6. Setup Server Pools, Rules, and VIPs
The next step is to run the F5 configuration command. You need to be familiar with two
interfaces: Big-Pipe command line interface and Web Administration interface. For information on
the Web Administration interface, please consult F5 documentation.
Big-Pipe is a command line interface into the F5 switch. It is accessible through an SSH client.
The recommended SSH clients reside in the following location:
https://<F5BIG-IP System Host Name or IP>/doc/download_ssh.html
Where <F5BIG-IP System Host Name or IP> is the administration IP address or the host name of
the F5 BIG-IP device.
page 20 of 56
The steps below applies to the Windows (puTTY) SSH client.
1. Start the PuTTY client by double clicking on the executable and select SSH.
page 21 of 56
2. Enter the administration IP address or host name of the F5 BIG-IP device in the Host
Name box, and click Open. You are prompted for a user ID and password. Enter the F5
admin user ID and password which opens an SSH session into the F5 BIG-IP device.
3. Open the bigip.cfg file in Notepad, select the entire contents, and click Copy. This copies
the content of the file onto the Windows clip board.
4. Return to the puTTY window, and right click on the window. This copies the content of
the Windows clip board to be entered into the command line and executes each line as
commands. These commands create the appropriate pools and rules.
The following is an example of the bigip.cfg file:
bigpipe pool SMEObjMgr_enuConnPool { lb_method rr \

member 172.20.83.160:2321 \
member 172.20.83.159:2321 \
}
bigpipe pool SSEObjMgr_enuConnPool { lb_method rr \
member 172.20.83.160:2321 \
member 172.20.83.159:2321 \
}
bigpipe pool SMEObjMgr_enuRRPool { lb_method rr \
member 172.20.83.160:2321 \
member 172.20.83.159:2321 \
}
bigpipe pool SSEObjMgr_enuRRPool { lb_method rr \
member 172.20.83.160:2321 \
member 172.20.83.159:2321 \
}
bigpipe pool SiebSrvr300pl1ServerPool { lb_method rr \
member 172.20.83.159:2321 \
}
bigpipe pool SiebSrvr300pl2ServerPool { lb_method rr \
page 22 of 56
member 172.20.83.160:2321 \
}
b rule CRMEnt1Rule { \
if '(http_uri ends_with "/siebel/smeobjmgr_enu/") {use pool
SMEObjMgr_enuConnPool ' }\
else if '(http_uri ends_with "/siebel/sseobjmgr_enu/") {use
pool SSEObjMgr_enuConnPool ' }\
else if '(http_uri ends_with "/siebel/smeobjmgr_enu/rr") {use
pool SMEObjMgr_enuRRPool ' }\
else if '(http_uri ends_with "/siebel/sseobjmgr_enu/rr") {use
pool SSEObjMgr_enuRRPool ' }\
else if '(http_uri contains "/!2.") {use pool
SiebSrvr300pl1ServerPool ' }\
else if '(http_uri contains "/!1.") {use pool
SiebSrvr300pl2ServerPool ' }\
else { discard }\
}
b virtual 192.10.10.100:2400 use rule CRMEnt1Rule
page 23 of 56
When executed in the puTTY client, it displays:
page 24 of 56
In the F5 administration page, you then see the following pools and rules created:
5. Next, navigate to the Virtual Servers > Virtual Services Properties tab, and ensure TCP is
enabled for the specified port. Also set the Idle Connection Timeout based on your IT
policy. This specifies the amount of idle time a SISNAPI connection waits before getting
terminated by the F5 BIG-IP System.
page 25 of 56
If there is no IT policy around this, then set the timeout value to one year, or 31536000.
For example, if the Idle Connection Timeout is 31536000 seconds, then set the following:
6. Next, if the TCP connection timeout is set to a value less than the recommended value,
then adjust the SISNAPI Connection Maximum Idle Time parameter for all Application
Object Manager(s) load balanced by this Virtual IP and Port. The Connection Idle Time
value should be set to a value slightly less than the TCP connection timeout value in the
F5 BIG-IP System. For example, if the TCP Connection Timeout is set to 3600, then the
Connection Idle Time should be set to 3500.
NOTE: This is a key step. If this is not done, users may experience occasional Server Busy
errors after long periods of idle time.
Please refer to the Siebel System Administration Guide in the Siebel Bookshelf for details.
The F5 BIG-IP System configuration is now complete.
Step 7. Choose a Load Balancing Scheme
The load balancing scheme for the F5 BIG-IP System is defined at the Pool level. You should not
modify the load balancing scheme for the Round Robin rules and Server rules; that is, the Pools
with the name <component alias>RRPool and <server name>ServerRule. These should be
round-robin.
You can modify the load balancing scheme for the <component alias>ConnPool. This pool is
used for initial load balancing of user sessions. Please refer to Step 3. Setup Servers, Routing
Rules, and VIPs in the General Installation and Configuration Steps section of this technical note
where a comparison between various load balancing schemes is provided.
page 26 of 56
Step 8. Set up a Health Monitor
The next step is to set up a health monitor for the Siebel Servers. Setting up a health monitor
minimizes unnecessary re-tries when servers are taken out of rotation for maintenance purposes.
It also allows you to monitor Siebel Server availability from the F5 BIG-IP Configuration Utility
Management interface. To set up:
1. First, open the F5 BIG-IP Configuration Utility Management Web interface, and click on
the Monitors icon on the left side of the page.
2. Click Add, and enter a name for the monitor. In the Inherits From box, select http.
page 27 of 56
3. After clicking NEXT, the next screen allows you to specify the monitor interval. Simply
use the default values or increase the value to reduce traffic to the Siebel Servers. It is
critical, that, you set the Timeout value to be several times larger than the Interval value.
If the Timeout value is less than the Interval value, then the Siebel Server may be taken
offline by the F5 BIG-IP device.
4. Click the NEXT button, and enter the HTTP string for the health check. In the Send String
box, enter the following text where Siebel_Enterprise_Name is the name of your
enterprise:
GET /<Siebel_Enterprise_Name>/scbroker HTTP/1.0
page 28 of 56
For example, if the Siebel Enterprise name is “siebel”, specify the send string as below.
Then, click DONE.
5. Lastly, associate the monitor with the nodes (IP:port), node addresses (IP), or Service
(port). Choose the method most appropriate for your site. In general,
• If all Siebel Servers have the same SCBroker port number (default 2321) and there is
only one enterprise, then the simplest configuration is to associate this monitor with
port 2321.
• If the F5 BIG-IP device is used for multiple enterprises, or multiple TCP port numbers
are used for Siebel Servers, then you must associate monitors with each node.
page 29 of 56
To associate monitors, select Monitors > Basic Associations in the F5 BIG-IP System Web
Administration screen. Under the Node column, first select the monitor created above then
click the Add check boxes next to the Siebel Server nodes. If there are multiple Siebel
Servers running on one physical box, then ensure the right IP:Port number combination is
picked. An example of this association is:
Lastly, click the Apply button at the bottom of the screen, and the monitor is set up.
Step 9. Post Configuration Verification
If all Siebel Servers are running and all configurations are created correctly, then there should be
a green icon next to the node in the F5 BIG-IP System Administration screen. For example:
page 30 of 56
If the Siebel Servers are not running, or monitors are not set up correctly, then you may see the
following:
If all nodes are green, then proceed to install SWSE on all Web Servers. If all nodes are not all
green, please refer to Appendix D: Troubleshooting F5 BIG-IP System Configuration Issues.
Step 10. Install SWSE and Get a Login Page
Next, install SWSE on all Web servers. During the SWSE installation, enter the appropriate
values when prompted for the Virtual IP address and Port number. After installation, from each
Web Server, ping the Virtual IP address to ensure it can be reached. If the Virtual IP cannot be
pinged, check with your network administrator to ensure network addresses are properly
configured.
If ping is successful, then start a browser on your PC, and attempt to log in to the Siebel
Application. The initial login may take some time, and you may have to hit refresh a few times. If
you get a Server Busy error on the screen right away, then proceed to Appendix D:
Troubleshooting F5 BIG-IP System Configuration Issues. If you can get a login screen, then the
configuration is successful.
Add or Remove a Siebel Server or Application for the F5 BIG-IP System
The safest approach is to repeat the steps specified in the previous section above whenever a
Siebel Server or application is added or removed from the enterprise. Before running Step 6.
Setup Server Pools, Rules, and VIPs delete the current Virtual Server definition in the F5 BIG-IP
System. This may introduce a brief interruption of service, and some user sessions may be lost.
Therefore, this activity is recommended during maintenance downtime.
It is also possible to manually modify the configuration and avoid a brief downtime. To do this,
you should be familiar with the F5 BIG-IP System administration interface. This is not
recommended for the first time user.
Adding a Siebel Server
To add a Siebel Server, first install the Siebel applications software to the server, specify the
SCBroker port, and start the server processes. Check the application log files to ensure it is
running properly.
Next, start the F5 BIG-IP Configuration Utility Web Administration interface, and find the Virtual
Server used for this Siebel Enterprise. To add a server, you need to:
1. Identify the server Pools associated with the Application Object Managers running on the
new Siebel Server. Each Application Manager has two server pools. You need to add the
new Siebel Server to the appropriate Pools. For example, if the new server is running the
page 31 of 56
Sales Object Manager (alias SSEObgmgr_enu), then modify the following Pools:
SSEObjMgr_enuConnPool and SSEObjMgr_enuRRPool.
2. Modify the Pool by clicking on the link in the F5 BIG-IP System interface, enter the server
IP address into the Member Address field and the SCBroker port into the Service field,
and click the right arrow.
3. Click Apply to activate the new server. As soon as you click Apply, the new server is now
available to accept new requests.
In the example below, a new server with IP Address 172.20.192.73 and SCBroker port
2321 is added to the Sales Object Manager (SSEObjMgr_enuConnPool) connection
pool. Note that you also need to add the same server to (SSEObjMgr_enuRRPool) pool.
page 32 of 56
page 33 of 56
4. Add a server pool for the new server by selecting Pool > Add, and specify the Pool Name
using the convention <ServerName>ServerPool. For example:
After the new server Pool is added, modify the rule for this enterprise. First identify the
Server ID for the new server. To do this, log into Server Manager, and type the following
command where ServerName is the name of the newly installed server, and Server ID for
this server is 3:
srvrmgr> list server show SBLSRVR_NAME, SV_SRVRID
SBLSRVR_NAME SV_SRVRID
------------ ---------
SiebSrvr300pl2 1
SiebSrvr300pl1 2
ServerName 3
Then add the following to the rule:
page 34 of 56
else if (http_uri contains "/!3.") {

use pool ServerNameServerPool
}
After modifying the rule, the new server is fully set up.
Removing a Siebel Server
The steps to remove a Siebel Server are identical to adding a Siebel Server. Remove the server
entry from the Connection Pool and Round Robin Pool. You need to remove the Server Pool and
modify the Rule to remove the reference to the Server Pool.
Adding an Application Object Manager
To add a new Application Object Manager, add the corresponding Connection Pool and Round
Robin Pool to F5 BIG-IP System. You also need to add multiple entries in the rule. Therefore, it is
recommended to repeat the steps provided for initial configuration of the F5 BIG-IP System to
add the new Application Object. See the Configuring for F5 BIG-IP System section in this
document for a listing of these steps. If you must eliminate any downtime, and are comfortable
with F5 BIG-IP System configuration in general, please refer to Appendix E: Manual
Configuration of the F5 BIG-IP System for instruction to manually set up all rules and pools.
Removing an Application Object Manager
Similar to adding an OM, it is recommended to complete the steps provided for the initial
configuration of the F5 BIG-IP System to add the new Application Object. See the Configuring for
page 35 of 56
F5 BIG-IP System section in this document for a listing of these steps. If you must manually
remove an OM, please follow instructions in Appendix E: Manual Configuration of the F5 BIG-IP
System.
Appendix A: Sample lbconfig file and the Cleanup Process
The following is a sample lbconfig file generated from the Server Manager.
#This is the load balance configuration file generated by the

Siebel srvrmgr "generate lbconfig" command.
#It contains two sections. Section one contains load balancing
rules to be used by Siebel session manager.
#Section two is intended for 3rd party load balancers. Before
modifying the content of this file please
#read the chapter on SWSE configuration in the Siebel Bookshelf.
#Section one -- Session Manager Rules:

VirtualServer=2:SiebSrvr300pl1:2321;1:SiebSrvr300pl2:2321;
******************************
#Section two -- 3rd Party Load Balancer Rules
#Component Rules:
/siebel/CRAObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/eEventsObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:232
1;
/siebel/eMarketObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:232
1;
/siebel/SMObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/eTrainingObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2
321;
/siebel/ERMEmbObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321
;
/siebel/ERMAdminObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:23
21;
/siebel/ERMObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/SalesCEObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:232
1;
/siebel/ServiceCEObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2
321;
/siebel/eCustomerObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2
321;
/siebel/eSalesObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321
;
/siebel/eProdCfgObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:23
21;
/siebel/WirelesseServiceObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr3
00pl1:2321;
/siebel/WirelesseChannelObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr3
00pl1:2321;
/siebel/WirelessServiceObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr30
0pl1:2321;
/siebel/WirelessSalesObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300p
l1:2321;
/siebel/eChannelObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:23
21;
page 36 of 56
/siebel/PManagerObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:23
21;
/siebel/EAIObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/eServiceObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:23
21;
/siebel/SCCObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/SMEObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/SSEObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/SFSObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
#Server Rules:
*/!2.*=SiebSrvr300pl1:2321;
*/!1.*=SiebSrvr300pl2:2321;
#Round Robin Rules:

/siebel/CRAObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/eEventsObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2
321;
/siebel/eMarketObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2
321;
/siebel/SMObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/eTrainingObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1
:2321;
/siebel/ERMEmbObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:23
21;
/siebel/ERMAdminObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:
2321;
/siebel/ERMObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/SalesCEObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2
321;
/siebel/ServiceCEObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1
:2321;
/siebel/eCustomerObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1
:2321;
/siebel/eSalesObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:23
21;
/siebel/eProdCfgObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:
2321;
/siebel/WirelesseServiceObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrv
r300pl1:2321;
/siebel/WirelesseChannelObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrv
r300pl1:2321;
/siebel/WirelessServiceObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr
300pl1:2321;
/siebel/WirelessSalesObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr30
0pl1:2321;
/siebel/eChannelObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:
2321;
/siebel/PManagerObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:
2321;
/siebel/EAIObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/eServiceObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:
2321;
/siebel/SCCObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/SMEObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/SSEObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/SFSObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
page 37 of 56
NOTE: This file contains references to both enabled and disabled object managers. If only Sales
and Marketing Object Managers are used in the enterprise, then first identify the alias for these
two Object Managers (SSEObjMgr_enu and SMCObgMgr_enu). Then remove the unnecessary
entries as below:


******************************
#Component Rules:
/siebel/CRAObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/eEventsObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:232
1;
/siebel/eMarketObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:232
1;
/siebel/SMObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/eTrainingObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2
321;
/siebel/ERMEmbObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321
;
/siebel/ERMAdminObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:23
21;
/siebel/ERMObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/SalesCEObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:232
1;
/siebel/ServiceCEObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2
321;
/siebel/eCustomerObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2
321;
/siebel/eSalesObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321
;
/siebel/eProdCfgObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:23
21;
/siebel/WirelesseServiceObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr3
00pl1:2321;
/siebel/WirelesseChannelObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr3
00pl1:2321;
/siebel/WirelessServiceObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr30
0pl1:2321;
/siebel/WirelessSalesObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300p
l1:2321;
/siebel/eChannelObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:23
21;
/siebel/PManagerObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:23
21;
page 38 of 56
/siebel/EAIObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/eServiceObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:23
21;
/siebel/SCCObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/SFSObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
#Server Rules:
*/!2.*=SiebSrvr300pl1:2321;
*/!1.*=SiebSrvr300pl2:2321;
#Round Robin Rules:

/siebel/CRAObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/eEventsObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2
321;
/siebel/eMarketObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2
321;
/siebel/SMObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/eTrainingObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1
:2321;
/siebel/ERMEmbObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:23
21;
/siebel/ERMAdminObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:
2321;
/siebel/ERMObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/SalesCEObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2
321;
/siebel/ServiceCEObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1
:2321;
/siebel/eCustomerObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1
:2321;
/siebel/eSalesObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:23
21;
/siebel/eProdCfgObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:
2321;
/siebel/WirelesseServiceObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrv
r300pl1:2321;
/siebel/WirelesseChannelObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrv
r300pl1:2321;
/siebel/WirelessServiceObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr
300pl1:2321;
/siebel/WirelessSalesObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr30
0pl1:2321;
/siebel/eChannelObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:
2321;
/siebel/PManagerObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:
2321;
/siebel/EAIObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/eServiceObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:
2321;
/siebel/SCCObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
/siebel/SFSObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
page 39 of 56
The following is the result:


******************************
#Component Rules:
#Server Rules:
*/!2.*=SiebSrvr300pl1:2321;
*/!1.*=SiebSrvr300pl2:2321;
#Round Robin Rules:

Next, create the following table. Suppose that the Marketing OM is running only on one of the
servers:
Application Alias Enabled Application Servers

Object
Manager
Sales (English) SSEObjMgr_enu SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;
Marketing SMEObjMgr_enu SiebSrvr300pl2:2321
(English)
Then modify the lbconfig file to be:

#Section two is intended for 3rd pa
rty load balancers. Before modifying the content of this file
please

******************************
page 40 of 56
#Component Rules:
#Server Rules:
*/!2.*=SiebSrvr300pl1:2321;
*/!1.*=SiebSrvr300pl2:2321;
#Round Robin Rules:

Or,


******************************
#Component Rules:
/siebel/SMEObjMgr_enu/=SiebSrvr300pl2:2321;
#Server Rules:
*/!2.*=SiebSrvr300pl1:2321;
*/!1.*=SiebSrvr300pl2:2321;
#Round Robin Rules:

/siebel/SMEObjMgr_enu/RR=SiebSrvr300pl2:2321;
Appendix B: Perl Script for F5 BIG-IP System Configuration
#/usr/bin/perl
#
# Generates a configuration file for BigIP based on
# lbconfig.txt. lbconfig.txt must first be generated by running
# the srvrmgr command "generate lbconfig".
#
# Run the program with the ? option to get the options
#
# For every <CompName> create pools: <CompName>ConnPool,
<CompName>RRPool
$BIGIP_CFG_FILE_NAME=".\\bigip.cfg";
$INPUT_FILE_NAME=".\\lbconfig.txt";
page 41 of 56
$RULE_NAME="NewRule";
$VSERVER="120.0.0.1:2321";
if ($ARGV[0] =~ /\?/) {
&printOptions();
}
use Getopt::Long;
GetOptions("b=s"=>\$BIGIP_CFG_FILE_NAME,
"c=s"=>\$INPUT_FILE_NAME,
"r=s"=>\$RULE_NAME,
"v=s"=>\$VSERVER,
"h"=>\$HELP_FLAG);
&printOptions() if $HELP_FLAG;
sub printOptions()
{
print "\nOptions:\n";
print "\t-b [output file for BigIP config]\n";
print "\t-c [complete path to lbconfig.txt]\n";
print "\t-r [BigIP rule name]\n";
print "\t-v [vserver:vport]\n";
exit();
}
print "\nInput parameters:\n";

print "--------------------------------------------------------
\n";
print "Full path to lbconfig.txt........... $INPUT_FILE_NAME\n";
print "BigIP rule name..................... $RULE_NAME\n";
print "vserver:vport....................... $VSERVER\n\n";
print "Output parameters:\n";
print "--------------------------------------------------------
\n";
print "BigIP configuration file............
$BIGIP_CFG_FILE_NAME\n";
print "\nGenerating configuration for BigIP\n";

print "--------------------------------------------------------
\n";
open(BIGIP_CFG_FILE,">$BIGIP_CFG_FILE_NAME") || die "Couldn't

open $BIGIP_CFG_FILE_NAME";
open(INPUT_FILE,"$INPUT_FILE_NAME") || die "Couldn't open
$INPUT_FILE_NAME";
$rule_token_comp="#Component Rules:"; # rule type 1

$rule_token_srvr="#Server Rules:"; # rule type 2
$rule_token_rr="#Round Robin Rules:"; # rule type 3
$cRuleArrInd=0;
$sRuleArrInd=0;
$rrRuleArr=0;
$rule_type=-1;
while(chop($line = readline(*INPUT_FILE))) {
page 42 of 56
# based on the type of rule we are now on, process the data
if ($rule_type >= 0) {
# the line is a rule of type rule_type, add it to the correct

array
if ((index($line, "/") ==0 || index($line, "*") == 0 )
&& length($line) > 0) {
if ($rule_type == 1) {
$cRuleArr[$cRuleArrInd++]=$line;
}
elsif ($rule_type == 2) {
$sRuleArr[$sRuleArrInd++]=$line;
}
elsif ($rule_type == 3) {
$rrRuleArr[$rrRuleArrInd++]=$line;
}
}
else {
# the line is not a rule, determine if we need to switch
rule_type
if (rindex($line, $rule_token_comp) > -1) {
$rule_type=1;
}
if (rindex($line, $rule_token_srvr) > -1) {
$rule_type=2;
}
if (rindex($line, $rule_token_rr) > -1) {
$rule_type=3;
}
}
}
# process until we find a line that starts with *****

if (rindex($line, "*****") > -1) {
$rule_type=0;
}
}
# uriPoolArr: data structure mapping URIs to pools

# [URI][pool][0:connect or RR rule, 1:server rule]
$uriPoolArrInd=0;
for ($i=0; $i < $cRuleArrInd; $i++) {

&processRule($cRuleArr[$i], "ConnPool", "rr");
}
for ($i=0; $i < $rrRuleArrInd; $i++) {

&processRule($rrRuleArr[$i], "RRPool", "rr");
}
for ($i=0; $i < $sRuleArrInd; $i++) {

&processRule($sRuleArr[$i], "ServerPool", "rr");
}
# create the rule

print BIGIP_CFG_FILE "\nb rule $RULE_NAME { \\\n";
page 43 of 56
for ($i=0; $i < $uriPoolArrInd; $i++) {
if ($i > 0) {
print BIGIP_CFG_FILE "else ";
}
if ($i < $uriPoolArrInd) {

print BIGIP_CFG_FILE "if '(http_uri ";
if ($uriPoolArr[$i][2] != 0) {
print BIGIP_CFG_FILE "ends_with";
}
else {
print BIGIP_CFG_FILE "contains";
}
print BIGIP_CFG_FILE " \"$uriPoolArr[$i][0]\") {";
print BIGIP_CFG_FILE "use pool $uriPoolArr[$i][1] ' }\\\n";
}
}
print BIGIP_CFG_FILE "else { discard }\\\n";

print BIGIP_CFG_FILE "}\n";
# create virtual server

print BIGIP_CFG_FILE "\nb virtual $VSERVER use rule
$RULE_NAME\n";
print "\nConfiguration instructions\n";

print "--------------------------------------------------------
\n";
print "\nTo configure BigIP, telnet to the BigIP machine, and
paste\n";
print "the contents of the file $BIGIP_CFG_FILE_NAME\n\n";
exit();
# create the pool declaration, add the URI and pool to the list
#
# arguments
# 0: input line <URI>=<server list>
# 1: pool name suffix, (ConnPool or RRPool)
# 2: LB method
#
sub processRule
{
local($line, $poolSuffix, $lbMethod) = ($_[0], $_[1], $_[2]);
# ruleType values
# 0: server
# 1: connect
# 2: round robin
# determine the type of rule

if (index($line, "*") == 0) {
$ruleType=0;
}
elsif ($line =~ /\/RR/i) {
page 44 of 56
$ruleType=2;
}
else {
$ruleType=1;
}
# Get the component name. The pool will be named

<CompName>ConnPool
$uriStr = substr($line, 0,
index($line, "="));
$serverStr = substr($line,
index($line, "=") + 1);
@serverArr=split(/;/,$serverStr);
if ($ruleType != 0) {
@uriArr=split(/\//, $uriStr);
$compName=$uriArr[2];
}
else {
@serverDataArr=split(/:/,$serverArr[0]);
$compName=$serverDataArr[0];
}
# Add BigIP config

$poolName="$compName";
substr($poolName, length($poolName))="$poolSuffix";
print BIGIP_CFG_FILE "bigpipe pool $poolName";

print BIGIP_CFG_FILE " { lb_method $lbMethod \\\n";
for ($j=0; $j < @serverArr; $j++) {

#print BIGIP_CFG_FILE "member $serverArr[$j] \\\n";
@serverPortArr=split(/:/,$serverArr[$j]);
$ipAddr=getIPForHost($serverPortArr[0]);
print BIGIP_CFG_FILE "member $ipAddr:$serverPortArr[1]
\\\n";
}
print BIGIP_CFG_FILE "}\n";
$origUriStr=$uriStr;
# remove starting and trailing * if it is a server rule

$uriStr =~ tr /*/ /;
for ($uriStr) {
s/^\s+//;
s/\s+$//;
}
# add the URI to pool mapping to the array to create the

# BigIP rule later.
# change the URI to lower case (BigIP requirement)
$uriPoolArr[$uriPoolArrInd][0]=lc($uriStr);
$uriPoolArr[$uriPoolArrInd][1]=$poolName;
$uriPoolArr[$uriPoolArrInd][2]=$ruleType;
$uriPoolArrInd++;
page 45 of 56
# input: text hostname

# output: dotted decimal IP of the host
sub getIPForHost
{
local($host) = ($_[0]);
# redirect stderr to stdout so that we can parse for errors

$test=`nslookup $host 2>&1`;
if ($test =~ /find/) {
$ipAddress = $host;
print "Warning: Couldn't resolve hostname $host to IP
address.\n";
}
else {
@nsLookupArr = split(/:/, $test);
$ipAddress=$nsLookupArr[4];
for ($ipAddress) {
s/^\s+//;
s/\s+$//;
}
}
$ipAddress;
}
Appendix C: Trouble-Shooting Perl Script Compilation
The following are a few potential errors you may see during the Perl script compilation.
Bad File Name
page 46 of 56
This means either the Perl script does not exist or the file name is misspelled. Double check the
file names and location.
Perl Script Compiler is not installed
First make sure the Perl script file has the correct extension (pl). If it does not, modify the file
extension and try again. If it already has the correct extension, then the Perl Script compiler may
not be installed properly. Check that Perl Script compiler is installed correctly.
Invalid host name in the lbconfig.txt
The above error message appears if the lbconfig.txt file contains invalid host names, either
because of a typo in the specified host name, the server does not exist, or simply because it is
page 47 of 56
not running or registered with the DNS. Double check and ensure the specified host name is
correctly spelled. In the example above, this error message is repeated thee times because the
host name is referenced three times in the lbconfig.txt file. If an invalid IP address (bad format) is
entered in the lbconfig.txt file, you also see the same error message.
This is a non-fatal error. The bigip.cfg file is still generated with the host name or IP address in
question. The assumption is that you may be setting up the F5 BIG-IP System while the target
server is unavailable, or cannot be reached from your PC.
Other errors not captured by the Perl script
There are certain entries that cannot be validated at the time of compilation, and therefore they
are not captured. It is recommended to double check these entries before implementing them.
They are:
• Invalid Virtual IP or Virtual Port: since these are not yet set up, there is no way to verify
these.
• URL, Object Manager, and Siebel Server mismatch. As long as the lbconfig.txt file is
generated and modified as specified above, this should not happen. If there is a
mismatch, it may result in a number of communication failures. Please check the Web
Server log file for any error messages.
Appendix D: Troubleshooting F5 BIG-IP System Configuration Issues
This section is continuously enhanced to reflect accumulated experiences from different sources.
Please check Siebel SupportWeb for any updates to this document.
Node is marked as down
If you see the following in the F5 BIG-IP System Web Administration interface, the F5 BIG-IP
System is unable to verify that the Siebel Server is up and running.
This means that the target server and port combination is unable to reply to the HTTP Health
Checks. The target server and port can only reply to this health check if the Siebel Server or
SCBroker is running and is listening on the specified TCP port. Therefore, verify the following:
1. First, check for the Interval and Timeout setting of the monitor. NOTE: Keep in mind that
the Timeout value must be set to three times greater than the Interval value.
2. Next, check if the Load balancer can ping the target server. To do this, open a MindTerm
SSH terminal session from the F5 BIG-IP System Web Administration screen or use
puTTY to establish a telnet session on the F5 BIG-IP device. Then ping the target server.
If this does not work, check to see if target server is actually on the network or if the
page 48 of 56
network topology allows the F5 BIG-IP device to reach Siebel Servers. For network
topology and basic network setup issues, please check F5 documentation for details.
3. If this works, then the F5 BIG-IP device can physically reach the target server. Next,
check to see if the target port is open. To do this, remove the HTTP Health Check to the
server and set up a TCP Health Check on the F5 BIG-IP System to check for the target
server and port.
a. If it works, it means that the port is open, but the SCBroker is not up and running. If
so, check in the Siebel Application Administration screens to ensure the SCBroker is
running on that server. This may also indicate that the Siebel Server processes
ended abnormally and the TCP may be left open. Therefore, you should restart the
server machine to clean up the TCP port usage.
b. If this does not work, then there is no program listening on the specified port. First,
check to ensure the correct port number is specified. If it is, then check to see the
Siebel Server and SCBroker are actually running on that server.
Please remember to remove the TCP Health Check and restore the HTTP Health Check
after this step. The TCP Health Check is not a recommended health monitor for on-going
operations.
4. Next, check to ensure the HTTP check string is configured correctly. The string must
have the format:
Get /<Siebel Enterprise Name>/scbroker HTTP 1.0
Where Siebel Enterprise Name is the name of the Siebel Enterprise in which the target
Siebel Server belongs to. If this appears to be correct, then bounce the Siebel Server to
ensure that SCBroker is running properly.
5. If this does not resolve the issue, remove the HTTP Health Check, and then proceed with
configuration. At the end of configuration, check to see if you are able to get a login page.
If not, go to the next troubleshooting step. If yes, then the health check string most likely
contains an error. Running without a health check is not recommended, although it is
unlikely to cause production downtime. You should try to resolve the issue with Siebel
Technical Support. Please log a service request on SupportWeb if assistance is required.
Node is marked up, but continuous attempts to login gets “Server Busy” error in the
browser
First, verify that Web Server and Application Servers are set up correctly. To do this, first update
the eapps.cfg file on one of the Web servers so it directly connects to the Application Server, and
check to see if a user session can be started. For detail instructions on setting up Siebel Servers
and Web Servers, please reference the Siebel System Installation Guide in the Siebel Bookshelf.
Next, if you can get a login screen with one Web server and Siebel Server, set up Siebel Load
Balancing temporarily to see if all server configurations are correct. You need to copy the
lbconfig.txt file generated above into the SWSE_INSTALL_ROOT/Admin directory, and update
the following eapps.cfg entry to true:
EnableVirtualHosts = True
Next, start a number of sessions to ensure that there is at least one session on each Siebel
Server. If this does not work, reference the troubleshooting section of the Siebel Load Balancing
chapter in the Deployment Planning Guide for details.
page 49 of 56
If both direct connection and Siebel Load Balancing work correctly, then focus troubleshooting on
the F5 BIG-IP System configuration.
1. First, update the eapps.cfg file to disable Siebel Load Balancing by changing the setting
below as follows:
EnableVirtualHosts = False
2. Next, modify the Object Manager connect string so it points to the Virtual IP and Port. For
the load balanced Object Manager, the connect string must have the format:
ConnectString =
siebel.TCPIP.None.None://<VirtualIP>:<VirtualPort>/<Siebel
Enterprise Name>/<Alias of the Object Manager>
Where:
<VirtualIP> is the IP address of the Virtual Server specified in F5. The Virtual Server
should be linked to the scheduling Rule.
<VirtualPort> is the Port Number, or Service defined in the Virtual Server definition.
<Siebel Enterprise Name> is the name of the Siebel Enterprise in which the load
balanced Siebel Servers reside
<Alias of the Object Manager> is the alias of the Load Balanced Object Manager
3. If the connect string is configured correctly, then next check that the network connection
request actually reached the F5 BIG-IP device.
a. From each Web Server, attempt to ping the Virtual IP address hosted by the F5 BIG-
IP device. You should be able to ping it. If not, then there are issues with networking
configuration. Check the network topology to ensure the Web Server can indeed
reach the F5 BIG-IP device.
b. Open the F5 BIG-IP Configuration Utility Web Administration interface. Select the
Statistics > Virtual Servers page and a screen that shows network traffic statistics
displays.
c. Click the Reset all Stats button on the bottom of the page, and ensure that all stats
are reset to 0.
d. Next, find the entry for the Virtual IP and Virtual port defined for this enterprise, and
verify all stats are still 0.
e. Start a Web browser session and attempt to log into the Siebel Server.
f. At this time, continue to hit the Refresh button as many times as needed to see if
there is any connection created against the Virtual IP and port.
g. If the connection count goes up, it means the Web Server is able to reach the Virtual
IP address, but the SISNAPI traffic is not getting routed correctly. If this is the case,
move to the step that performs rule tracing (below).
h. If the connection count does not go up, it means the Web Server is not able to reach
the F5 BIG-IP device. If the Web Server can still ping the VIP, then it’s possible that
port number specified in the connect strings do not match the virtual port number.
i. If the connection count does go up, but there is still no login page, then it’s possible
that networking topology (subnets, for example) is not set up correctly, so SISNAPI
traffic is unable to complete its round trip. Please consult the F5 support
documentation to ensure the networking topology is set up correctly. Before doing so,
page 50 of 56
however, please ensure you have tested against direct connection and Siebel Load
Balancing to rule out any Siebel-specific configuration issues.
j. However, if the network topology has been checked out, then you need to check and
see if the rules are created correctly.
4. Next, open up the F5 BIG-IP Configuration Utility Web Administration interface, find the
Rule defined above, and insert a line into each of the if clauses so that something is
written to the log file when a URL match is hit. Insert the line:
Log “Use <Pool Name> Rule”
Below is an example:
On the last else clause, insert the line:
log “discard”
This helps to debug whether URLs are being parsed correctly or no URL is found.
Next, start a Web browser and attempt to log in. At this time, open the Log Files > BIG-IP
System Log screen. It should display the log content specified in the rule above. Check to
see if “discard” is logged when a connection attempt is made. If so, it means that the
request did reach the correct Virtual IP and Port number, but none of the rule conditions
matched. In this case, double check the HTTP rule conditions to ensure they are correct.
page 51 of 56
NOTE: The URLs specified in the Rule is case sensitive. All characters in the URL are
lower case. If there is any upper case character, then covert it into lower case and try
again.
Also, ensure the If condition in the rule is specified exactly as created by the siebbigip.pl
script. In other words:
• For all component and round-robin rules, that is, URLs containing the alias of the
object manager component, the If clause should use the “http_uri ends_with”
condition. If not, URL matching does not work correctly. For example:
if (http_uri ends_with "/siebel/smeobjmgr_enu/") {

log "Use SMEObjMgr_enuConnPool Rule"
use pool SMEObjMgr_enuConnPool
}
else if (http_uri ends_with "/siebel/smeobjmgr_enu/rr") {
use pool SMEObjMgr_enuRRPool
}
• For all server rules, that is, URL containing server ID, the If clause should use the
“http_uri contains” condition. For example,

use pool SiebSrvr300pl1ServerPool
Make any necessary changes, and try again. It may take a few attempts to uncover
the problem clause.
5. If the correct rule is being invoked, but there is still no login screen, check the Pool
definitions to ensure Server IP addresses and ports are defined correctly.
6. If all of the above is set up correctly, the F5 documentation and troubleshooting steps
have been exhausted, and both direct connection and native load balancing work
correctly, then log a service request to Siebel Technical Support or F5 Technical Support
for assistance. Whichever support organization is contacted first, it is likely that both
Siebel and F5 will work together to resolve this issue.
Login is possible, but only after many refreshes
By default, the Siebel Web Server Extension attempts five times or up to one minute to reach one
Siebel Server. If several refreshes are necessary, it’s possible that either health checks are not
set up correctly, or at least five servers have reached max task.
1. Check the SWSE and OM log files to see if any maxtask reached error messages exist. If
yes, then either increase the number of servers, the server capacity, or the maxtask
setting.
2. Next, if there are no maxtask reached errors, check to see if the health check is set up
correctly. All servers should have the green arrow next to their icons in the F5 BIG-IP
Configuration Utility Web Administration screen. If there is no arrow or icon, then it means
the health check is not set up correctly. If there are more than five servers down in the
enterprise, then you may see the Server Busy error when attempting to log in.
3. Lastly, ensure that the Round Robin rules (URL with RR at the end) are also created
correctly. If the Round Robin rules are not created, then all retries fail. This means the
page 52 of 56
user only gets one attempt in connecting, which may require many refreshes to overcome
this.
Login is possible, but it takes a long time to get the login screen
Ensure the HTTP health monitor is used, rather than the TCP/IP monitor. Furthermore, check that
the TCP connection timeout is set correctly. Review Step 8: Set up a Health Monitor of the F5
BIG-IP System configuration procedures above for details. If the TCP timeout is not set correctly,
it can result in SWSE attempting to use stale or timed out connections. This may cause some
delays when SWSE tries to clean up these connections.
Login is posible, but many unexpected “Server Busy” errors appear, which ends the
sessions
Ensure the server rules are created correctly. Also, verify that the correct server ID is specified in
the rule. For example, check the following where 2 is the Siebel Server ID for SiebSrvr300pl1:

use pool SiebSrvr300pl1ServerPool
This Siebel Server ID is unique to each Siebel Server within one enterprise, and is assigned
during initial installation. Please do not assume that it is a sequential number. Always use the
following Server Manager command to obtain the server ID for a specific Siebel Server:
list server show SBLSRVR_NAME, SV_SRVRID
User session distribution across servers is uneven
In most cases, this may be due to the natural dynamics of user sessions. Users on one server
may log out at a faster rate than another server, which means that server has less user sessions.
In general, keep in mind that each user login triggers the F5 BIG-IP device to distribute the
connection request. Once logged in, however, a user session is tied to a particular server, and
the F5 BIG-IP System does not perform load balancing for individual operations.
If the round-robin or weighted round-robin scheme is used, then each new session request is
distributed evenly (or based on weights) to all active Siebel Servers. If another load balancing
scheme is used, then results may be different. In general, Siebel Systems recommends that you
start with a simple round-robin or weighted round-robin scheme initially, and observe the load
dynamics. If necessary, adjust and use more advanced load balancing schemes.
Lastly, a server taking on less load can simply mean that it has just been restarted or is having
problems taking on user load. Check the server with unexpectedly low load for any errors or
crashes.
Appendix E: Manual Configuration of F5 BIG-IP System
The steps described below are required in the absence of the output provided by the automated
configuration script. It is useful to be familiar with these manual steps as well so that tuning the F5
BIG-IP System and debugging configuration problems is easier.
1. Log in to the F5 BIG-IP Configuration Utility Administration interface using a Web

browser.
a. Open the appropriate address to administer the F5 BIG-IP System.

b. Log in with the correct username and password.
page 53 of 56
2. Select the link “Configure your BIG-IP SYSTEM (R) using the Configuration Utility”.
3. Create pools containing the machines that will be running the Siebel servers.
There should be one pool for component connect rules, one pool for component round-
robin rules, and one pool for each physical machine running a Siebel server. For an
enterprise with n number of servers, the total number of pools is 2 + n.
a. Create the component connect pool. This is the pool used for the initial connect from
SWSE to the Siebel server.
i. From the menu bar on the left side, Select System > Pools
ii. Select “+” (Add).
iii. Name the pool something meaningful, such as “Sales server pool”.
iv. Choose the desired load balancing.
v. In the Resources section for each physical machine the Siebel Server (siebsrvr)
runs:
• Set Member Address to the physical IP of the machine where siebsrvr runs
• Set Service to 2321 or the appropriate SCBroker port on that machine.
• Ignore the other fields.
• Select >> to add the machine to the pool.
vi. Leave the other options as the default

vii. Select “X” (Done)
b. Create the component round-robin pool.
i. Follow the same steps for the component connect pool.

ii. Choose Round Robin for the load balancing type.
iii. Name the pools something meaningful, for example, SalesReconnectPool.
c. Create one pool for each server, with only one server in each pool. This is used for
the reconnect rules so that the SWSE can reconnect to the component in the session
ID.
i. Follow the steps for creating the component rule, but name the pool something
like “<server>SalesPool” where <server> is the Siebel server name.
ii. Only add the IP address of the one <server> in the Resources section.
4. Determine the server IDs to be used in the reconnect rules. Use srvrmgr to determine
the server IDs of the servers for which scheduling rules will be registered.
srvrmgr> list server show SBLSRVR_NAME, SV_SRVRID
SBLSRVR_NAME SV_SRVRID
------------ ---------
srvr1 3
srvr2 5
5. Create a rule that maps Siebel URLs to the appropriate pools.
Make sure that <enterprise> and <component> are specified in lower case and you
specify rr in lowercase instead of RR in uppercase. The F5 BIG-IP System does not
match the URI if the rule is in mixed case.
page 54 of 56
The rule allows the SWSE to connect to the appropriate component on the Siebel server.
It contains component rules, round-robin rules, and component reconnect rules.
The rules only need to be created to map URIs to object managers (such as
SSEObjMgr_enu) and to SCBroker. Round-robin rules (those ending with rr) only need
to be created for object managers, and can be omitted for SCBroker.
The rule should contain the following, but with the names modified as appropriate for your
implementation:
if (http_uri ends_with "/<enterprise>/<component>") {

use pool <connect pool>
}
else if (http_uri ends_with "/<enterprise>/<component>/rr") {
use pool <round robin pool>
}
else if (http_uri contains "/!<server one ID>.") {
use pool <server one pool>
}
…
else if (http_uri contains "/!<server N ID>.") {
use pool <server N pool>
}
else {
discard
}
The format of the reconnect rules is important. These are used when the SWSE
reconnects to an existing session on a component. Each URI containing the following
must be mapped to the appropriate server pool:
/<enterprise>/<component>/!<server ID>.
For example, if there are two servers named ServerOne and ServerTwo and the server
IDs are 1 and 2, respectively, there should be two pools created. The ServerOnePool
contains only the physical server that ServerOne is on, and likewise the ServerTwoPool
contains that of ServerTwo.
Assume each server runs the component ExampleComp, and the enterprise is
ExampleEnt.
The process rule for ServerOne would map URIs starting with the following to pool
ServerOnePool:
/ExampleEnt/ExampleComp/!1.
The process rule for ServerTwo would map URIs starting with the following ot pool
ServerTwoPool:
/ExampleEnt/ExampleComp/!2.
6. Add a virtual server that maps to the rule that was created.
a. From the menu bar on the left side, Select System > Virtual Servers.
b. Select “+” (Add)
c. Set Address to the virtual IP that maps to the pool.
page 55 of 56
d. Set Service to the virtual port to be used. You can choose any value not in use on
the F5 Big-IP machine, such as 2320.
e. Ignore the Netmask field.
f. In the Basic Properties screen, use the defaults and choose > (Next).
g. In the Select Physical Resources screen:
i. Choose Rule.
ii. Select the rule created previously.
iii. Select X (Done).
7. Map the IP of the Web server machine to the virtual server IP.
a. From the menu bar on the left side, Select System > BIGpipe.
b. In the text box, enter the following command and press <Enter>:
snat map <client IP> to <virtual host IP>
Make sure the <client IP> is the IP of the machine running the Web server, and
<virtual host IP> is the same as the one previously chosen.
8. Modify the connect strings in eapps.cfg to use the virtual server. For example:
ConnectString = siebel://<virtual server>:<virtual

Port>/<enterprise>/<component>
9. Restart the Web server and verify that the system can be connected to.
page 56 of 56

Technote540-Configuring A Third Party HTTP Load Balancer For Siebel Server Load Balancing

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Technote540-Configuring A Third Party HTTP Load Balancer For Siebel Server Load Balancing

Uploaded by

Copyright:

Available Formats

Technical Note 540: Configuring a Third Party HTTP Load Balancer for

Siebel Server Load Balancing

Last Modified: 30 June 2004

The following topics are discussed in this technical note:

General Installation and Configuration Steps

Web HTTP HTTP Load Balancer HTTP

Web Web Server Web Web Server

Listening Ports Listening Ports

• Using Siebel-Provided Load Balancing, or Siebel Load Balancing. A logical architecture

Web HTTP HTTP Load Balancer HTTP

Web Web Server Web Web Server

Listening Port Listening Port

Siebel SCBroker Siebel SCBroker

SRB SRB Server

Web HTTP HTTP Load Balancer HTTP

Web Web Server Web Web Server

Listening Port Listening Port

Siebel SCBroker Siebel SCBroker

SRB SRB Server

HTTP Load Balancer Technology

HTTP Load Balancers are also called Content Switches.

The cores of the HTTP Load Balancer technology are:

• Packet Inspection and Routing

• TCP Connection Management and Mapping

Web Server 1 Web Server 1

Siebel Server 1 SIebel Server 2

Siebel Load Balancing

General Steps to Configure Third Party HTTP Load Balancing

Load Balancing Options and Comparison

1. No Application Server Load Balancing

2. Siebel Load Balancing

3. Third Party HTTP Load Balancing

General Installation and Configuration Steps

Step 1. Determining Third Party HTTP Load Balancer Compatibility

Step 2. Pre-Configuration Checks

4. Setup failover boxes to ensure Load Balancer high availability

• VIP1: Call Center, Sales, and eChannel

The following partitioning scheme does not:

• VIP1: Call Center, Sales. VIP2: Sales, eChannel

Step 3. Setup Servers, Routing Rules, and VIPs

a. Add load balanced Siebel Servers as resources.

For example, for the entry:

Configure the URL “/siebel/SCCObjMgr_enu” to route to servers with host names

Using an example to explain this, consider the following deployment:

Web HTTP HTTP Load Balancer HTTP

Web Web Server Web Web Server

HTTP Load Balancer

Listening Port=2321 Listening Port=2322

CallCenter Sales eChannel CallCenter Sales Marketing

# Section two -- 3rd Party Load Balancer Rules

#Round Robin Rules:

The configuration steps are:

1. Set up three server pools, one containing siebsrvr1:2321;siebsrvr2:2322, one containing

Load Load Distribution Advantages Limitations

through custom scripts or

Step 4. Verify Load Balancer Configuration

1. Ensure all Siebel Servers are up and running.

telnet <host name or IP>:<SCBroker Port>

Advanced Deployment Options

Adding or Removing Server Components or Servers

HTTP Load Balancer Implementation Limitation

Configuring the F5 BIG-IP System

Complete Configuration Steps for the F5 BIG-IP System