technote540 http loadbalancing

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


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:

HTTP Load Balancer Web

Listening Ports

SRB

OMOMOM

Siebel Server

Siebel Server

Resonate Central Dispatch

SWSE

Web ServerWeb Server

SWSE

Web Server WebServer

Browser HTTP HTTPS

VIP/VPort

HTTP HTTPS

SISNAPI/SSL

SISNAPI/SSL

Listening Ports

OM OM OM

ServerComp.

SISNAPI SRB

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:


SCBroker

Listening Port

SRB

OMOMOM

Siebel Server

Listening Port

SRB

OMOM OM

SiebelServer

SWSE


SWSE


Browser HTTP HTTP

HTTPS HTTPS

SISNAPI/SSL

SISNAPI/SSL

SCBroker

ServerComp.SISNAPI

page 4 of 56


• Using a third party HTTP Load Balancer. The architecture diagram then becomes:

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


SCBroker

Listening Port

SRB

OMOMOM

Siebel Server

Listening Port

SRB

OMOM OM

Siebel Server

HTT

SWSE


SWSE


Browser HTTP HTTPS

VIP/VPort

HTTP HTTPS

SISNAPI/SSL

SISNAPI/SSL

SCBroker

ServerComp.SISNAPI

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:

Hub/Switch (10.1.0.x)

Siebel Server 1IP:(10.1.0.11)

SIebel Server 2IP:(10.1.0.12)

Load BalancerVLAN1 IP:(192.168.0.50)

VLAN2 IP:(10.1.0.50)VLAN2 VIP:(10.1.0.100)

Web Server 1IP:(192.168.0.11)

Web Server 1IP:(192.168.0.11)

Hub/Switch (192.168.0.x)

DMZ

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:

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.

HTTP Load BalancerWeb

SCBroker

Listening Port=2321

eChannelOM

SalesOM

CallCenter OM

SiebSrvr1 ServerID=1

Listening Port=2322

SiebSrvr2ServerID = 2

SWSE


SWSE

Web Server WebServer

Browser HTTP HTTP

HTTPS HTTPS

Enterprise Name = Siebel

SISNAPI/SSL VIP:VPort=10.1.0.100:2321

HTTP Load Balancer

SISNAPI/SSL

SCBroker

CallCenter Sales Marketing OM OM OM

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 Balancing Scheme

Load Distribution Description

Advantages Limitations

Round Robin

Distributes connection requests in a round-robin fashion.

Distribution pattern is easily understood. Evenly distributes new session requests across Siebel Servers. This is a good scheme to start out with when server resources and configuration are identical.

May not work well with un-equal configuration or resources, as servers with less resources may reach capacity before the larger servers.

Weighted Round Robin

Distributes connections in a round-robin fashion, but with a user-specified ratio across servers.

Distribution pattern is easily understood. Resolves the issue where load balanced servers have unequal resources. This is a good scheme to start out with when server resources and configuration are not identical.

Does not react dynamically to changing server load or user login and logouts. A re-started server may not pick up load quickly, as it must wait for its turn to pick up new users.

Open Connections

Distributes connection requests to the server with the least number of open TCP connections

Allows servers with fewer connections to pick up new user sessions faster, and reacts to user login and logout dynamics better.

The number of TCP connections does not accurately reflect Siebel Server load or user session distribution as by default these connections are never closed once opened by the Web Server.

Weighted Open Connections

Similar to the above, except you can specify weight so connections are distributed according to this ratio

Better support for unequal load balanced servers.

Same issue as above.

Fastest Response

Directs connection requests to the server that has the shortest latency when responding to a connection request.

May shorten average response time by directing user to the server with best performance.

Connection response time does not always correspond to Siebel Server load as connection creation can be fast even when Siebel Server processes are very busy.

Server Load or Resource Availability

Directs connection requests to the server with the least load or most available resources.

Better overall distribution of load, and accounts for different user patterns, loads, and other dynamic factors.

May be difficult to diagnose load balancing issues as any number of factors may affect load balancing. Most Load Balancers 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

http://www.f5.com/support/


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

Manager Alias Enabled Application Servers

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

http://supportweb.siebel.com/support/private/content/images/technote540-1_siebbigip.zip

http://www.activestate.com/Products/ActivePerl/


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:2321; /siebel/eMarketObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/SMObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eTrainingObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/ERMEmbObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/ERMAdminObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/ERMObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/SalesCEObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/ServiceCEObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eCustomerObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eSalesObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eProdCfgObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/WirelesseServiceObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/WirelesseChannelObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/WirelessServiceObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/WirelessSalesObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eChannelObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;

page 36 of 56


/siebel/PManagerObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/EAIObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eServiceObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /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:2321; /siebel/eMarketObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/SMObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eTrainingObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/ERMEmbObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/ERMAdminObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/ERMObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/SalesCEObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/ServiceCEObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eCustomerObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eSalesObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eProdCfgObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/WirelesseServiceObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/WirelesseChannelObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/WirelessServiceObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/WirelessSalesObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1: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:

#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:2321; /siebel/eMarketObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/SMObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eTrainingObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/ERMEmbObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/ERMAdminObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/ERMObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/SalesCEObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/ServiceCEObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eCustomerObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eSalesObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eProdCfgObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/WirelesseServiceObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/WirelesseChannelObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/WirelessServiceObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/WirelessSalesObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eChannelObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/PManagerObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;

page 38 of 56


/siebel/EAIObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eServiceObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /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:2321; /siebel/eMarketObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/SMObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eTrainingObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/ERMEmbObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/ERMAdminObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/ERMObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/SalesCEObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/ServiceCEObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eCustomerObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eSalesObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/eProdCfgObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/WirelesseServiceObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/WirelesseChannelObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/WirelessServiceObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/WirelessSalesObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1: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 39 of 56


The following is the result:

#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/SMEObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/SSEObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; #Server Rules: */!2.*=SiebSrvr300pl1:2321; */!1.*=SiebSrvr300pl2:2321; #Round Robin Rules: /siebel/SMEObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/SSEObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321;

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

Application Object

Manager

Alias Enabled Application Servers

Sales (English) SSEObjMgr_enu SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; Marketing (English)

SMEObjMgr_enu SiebSrvr300pl2:2321

Then modify the lbconfig file to be:

#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 pa rty 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

page 40 of 56


#Component Rules: /siebel/SMEObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/SSEObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; #Server Rules: */!2.*=SiebSrvr300pl1:2321; */!1.*=SiebSrvr300pl2:2321; #Round Robin Rules: /siebel/SMEObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; /siebel/SSEObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; Or, #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/SMEObjMgr_enu/=SiebSrvr300pl2:2321; /siebel/SSEObjMgr_enu/=SiebSrvr300pl2:2321;SiebSrvr300pl1:2321; #Server Rules: */!2.*=SiebSrvr300pl1:2321; */!1.*=SiebSrvr300pl2:2321; #Round Robin Rules: /siebel/SMEObjMgr_enu/RR=SiebSrvr300pl2:2321; /siebel/SSEObjMgr_enu/RR=SiebSrvr300pl2:2321;SiebSrvr300pl1: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,

else if (http_uri contains "/!2.") { 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:

else if (http_uri contains "/!2.") { 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 http loadbalancing

Documents

resonate central dispatch

setup failover boxes

windows clip board

deployment planning guide

sample ibconfig file

load balancers support

web administration interface

http load balancers