12
Load Balancing Considerations

12.1 Introduction

This chapter discusses load balancing considerations for the Forms Server. Load balancing allows you to maintain a pool of middle tier machines (a "server farm") and balance the load of server traffic among these machines. Load balancing is implemented using a CGI executable that can run on any Web server with CGI support.

This chapter contains information about the following topics:

• Load Balancing Terminology

• Load Balancing in Action

• Configuring for Forms Server Load Balancing

• Setting Up the Load Balancer Server Trace Log

12.2 Load Balancing Terminology

Here are some terms you will want to understand before you set up load balancing:

• Forms CGI: CGI stands for Common Gateway Interface. Forms CGI is a program that is used for load balancing. It can be used with any generic listener that supports CGI.

• Load Balancer Server: This is the component that keeps track of all Forms Servers in the various load balancing pools. It tracks the status of the servers in a given pool and keeps statistics indicating their loads. It is responsible for directing each Form execution request to the least loaded server that is able to service requests in the given pool.

• Load Balancer Client: This is the component that sends load information to the Load Balancer Server, such as the number of Forms processes that are currently running on that machine. The Load Balancer Client runs on each machine with a Forms Server.

• Primary Node: This is the Forms Listener (plus any related software) where all URL requests to execute Forms are addressed. If load balancing is in use, each Form execution request is routed to the least loaded machine where a Forms Server is running. It gets the least loaded machine name from the Load Balancer Server.

• Secondary Node: These are machines on which the Forms Server, runtime client, and load balancer client are running. Forms execution requests are directed to them from the Primary Node when load balancing is being used.

  In many cases, the Primary Node will also act as a Secondary Node (for example, if it has Forms Server installed and running on it).

12.3 Load Balancing in Action

Figure 12-1 illustrates the events that occur when you use load balancing:

Figure 12-1 Forms Server load balancing

The following events occur when you use Forms Server load balancing:

1. Load Balancer Clients periodically send load information to the Load Balancer Server. This load information includes the total number of processes running on each Load Balancer Client.

2. A user accesses a URL pointing to the Forms CGI-bin executable.

3. The Forms CGI-bin executable asks the Load Balancer Server for the name of the least-loaded system that is available.

4. The Forms CGI-bin executable dynamically creates an HTML page with the name of the least-loaded system specified as the system on which to run the Forms Server, and returns that HTML page to the user's Web browser.

5. The user's Web browser then requests the Java applet to be downloaded from the host specified in the HTML page.

6. The Java applet sends a request to the Forms Server asking for a particular Form Builder application (that is, an .FMX).

7. The server contacts a Forms Server Runtime Engine. (The server maintains a pool of available Runtime Engines to minimize application startup delays.) Each active user receives a dedicated Runtime Engine.

8. The server establishes a direct socket, HTTP, or HTTPS connection with the Runtime Engine, and sends the socket, HTTP, or HTTPS information to the Java applet. The Java applet then establishes a direct socket, HTTP, or HTTPS connection with the Runtime Engine. The Java applet and the Runtime Engine now communicate directly, freeing the server to accept startup requests from other users. (At this point, neither the application server nor the Forms Server is involved in the communication between the applet and the Runtime Engine.) The Java applet displays the application's user interface in the main window of the user's Web browser.

9. The Runtime Engine communicates directly with the database through Net8 or ODBC (Open Database Connectivity), depending on the data source.

10. Load Balancer Clients continue to send load information to the Load Balancer Server. All new service requests are routed based on that information.

Note:

If the Load Balancer Server is unavailable, at Step 3 the Forms CGI-bin executable will not get any information back about which is the least-loaded system. Instead, the Forms CGI-bin will redirect the user's browser to the URL specified by the MetricsServerErrorURL parameter. The user does not necessarily know this is happening because the redirect is behind the scenes from the user's viewpoint.

12.4 Configuring for Forms Server Load Balancing

You can implement load balancing using the following CGI-bin executables provided with Forms Server:

• Forms Server Listener (f60ctl)

• Load Balancing Server (d2ls60)

• Load Balancing Client (d2lc60)

You will need to install and configure the load balancing components on each machine that will be load balanced. This includes the machine with the primary node and any other machines containing secondary nodes.

You will also need to edit the forms60_server shell script on each machine that is using load balancing. The forms60_server shell script is found in the $ORACLE_HOME/6iserver directory.

Be sure that:

• The Data Port value for the Load Balancer Server matches the Data Port values for ALL Load Balancer Clients.

• All Forms Servers that are to be load balanced have the same Forms Server Port value.

You will need administrator privileges to make the changes, and will need to stop and restart the process in order for the configuration changes to take effect.

To configure for load balaning, you must set the following paramaters on each machine within the forms60_server shell script:

• Forms Server Listener Parameters

• Load Balancer Server Parameters

• Load Balancer Client Parameters

12.4.1 Forms Server Listener Parameters

Set the port number and protocol to be used by the Forms Server Listener by editing the forms60_server shell script found in the $ORACLE_HOME/6iserver directory. The following syntax is used to start the Forms Server Listener:

f60ctl start port=<Forms Server Port> mode=<Protocol>

For example:

f60ctl start port=9001 mode=socket

Forms Server Port: The default is 9001. Enter the TCP/IP port number to which the Forms Server will listen for form execution requests.

Note:

All Forms Servers that are to be load balanced must have the same Forms Server Port value.

Protocol: The default is socket. This is the protocol that will be used for communication between the Forms Runtime Engine and the Forms Java applet. The value should only be changed to HTTP or HTTPS if communications must pass through a firewall. (For example, select HTTP if this machine is inside a firewall and the Forms applications must be available to users outside the firewall. Select HTTPS to use HTTP with SSL, secure sockets layer.)

You can accept the default parameters values, or modify the startup parameter values for the Forms Server. Change the port number only if it is already being used by another program.

12.4.2 Load Balancer Server Parameters

Set the port numbers to be used by the Forms Load Balancer Server by editing the forms60_server shell script found in the $ORACLE_HOME/6iserver directory. The following syntax is used to start the Load Balancer Server:

d2ls60 <Data Port> <Request Port> <Maximum Clients> <Trace Level>

For example:

d2ls60 9011 9021 1000 0

Data Port: The default is 9011. Enter the TCP/IP port number on which to listen for load data from Load Balancer Clients (which will run on Secondary Nodes).

The Data Port value for the Load Balancer Server must match the Data Port values for ALL Load Balancer Clients.

Request Port: The default is 9021. Enter the TCP/IP port number on which to listen for requests for the "least loaded host" made by the Forms Web CGI. This value is written to the formsweb.cfg file as the MetricServerPort parameter.

The serverHost parameter is set to the value %LeastLoadedHost% (i.e. serverHost=%LeastLoadedHost%). You should append your domain name to the serverHost parameter if a domain name is required in your network for name resolution. For example, serverHost=%LeastLoadedHost%.us.oracle.com.

Maximum Clients. The default is 1000. Specifies the maximum number of Load Balancer Clients that will be running and sending load information to the Load Balancer Server.

Trace Level: The default is 0 for no tracing. Specifying 10 allows you to create output for the Load Balancer Server.

Note::

For all machines that are being used and configured as secondary nodes only, you will have to edit the forms60_server shell script and remove the section related to the Load Balancer Server.

This section includes the lines from

# Stop load lalancing server
 

until the line

# Stop load balancing client.

12.4.3 Load Balancer Client Parameters

Set the Load Balancer host name and data port number to be used by the Forms Load Balancer Client by editing the forms60_server shell script found in the $ORACLE_HOME/6iserver directory. The following syntax is used to start the Load Balancer Client:

d2lc60 <Load Balancer Host> <Data Port> 0 [<Scale Factor> <Process Name>]

For example:

d2lc60 neko 9011 0 1 f60webm

Load Balancer Host: The default value is originally set to the name of the local machine you installed the software on. This name needs to be changed to the name of the host containing the Load Balancer Server. Enter the full host name of the Primary Node (the machine on which the Load Balancer Server is running). The value can contain up to 256 characters.

Data Port: The default is 9011. Enter the TCP/IP port number to which the load balancer server is listening for load data. The Data Port value for each Load Balancer Client must match the Data Port value for the Load Balancer Server.

Scale Factor: The default is 4 for Windows NT and 1 for UNIX. The scale factor allows you to reduce the imbalances resulting from varying capacities of Load Balancer processes running on each Load Balancer Client. A system that appears to be the least-loaded system may not necessarily be the best place to run a new process. You should assign a higher value for the scale factor for your lower-capacity systems.

Process Name: The default is f60webm. Setting the value tells the Load Balancer Client to count processes (for load balancing pruposes_ whose executable name matches the name specified. If a value is not specified, all proceses on the machine are counted.

12.5 Setting Up the Load Balancer Server Trace Log

This section describes the format of Load Balancer Server trace messages.

To start a trace, you must restart the Load Balancer Server and specify the <traceLevel> parameter in the forms60_server shell script. The <traceLevel> defaults to 0 for no tracing. Specifying 10 allows you to create trace output for the Laod Balance Server.

12.5.1 Trace level 1

Trace level 1 contains a header as follows:

HOSTNAME:          neko.us.oracle.com    IP ADDRESS: 144.25.83.146
Data port number:  1234  Request port number:  1235
Maximum number of clients: 10    Trace level: 2

• Hostname and IP Address: Indicate the D2LS server host name and address.

• Data port number: Indicates the port number where the D2LS server listens for D2LC client messages. This port should be used to configure the D2LC client processes.

• Request port number: Indicates the port number where the server listens for requests for least loaded host information.

• Maximum number of clients: Indicates the number of slots allocated for D2LC clients. One slot is required for each client.

• Trace level: Indicates the amount of Trace information printed to the server log file.

12.5.2 Trace level 2

At Trace level 2, messages are given in the following format from a D2LC client. A description of each field follows.

 D:000    144.25.83.92:1236  922541864 1     2  45 3 [cogito]
 |  |          |        |        |     |     |  |  | | 
 ^  |          |        |        |     |     |  |  | |  Packet type recv'd
   ^^^         |        |        |     |     |  |  | |  Client index
          ^^^^^^^^^^^^  |        |     |     |  |  | |  D2LC IP Address
                       ^^^^      |     |     |  |  | |  D2LC Port number
                             ^^^^^^^^^ |     |  |  | |  Time msg recv'd
                                       ^     |  |  | |  Scale factor
                                             ^  |  | |  Sequence number
                                                ^^ | |  Number of processes
                                                   ^ |  Last selected
                                                     ^  D2LC Hostname

The description of each field of the trace log is as follows:

• Packet Type Received: Indicates what type of packet was received. The following types are possible:
  • D: Data Received from D2LC Client. For packets with type "D", the remaining data on the trace line corresponds to information communicated from the client.

  • S: Selected client for Least Loaded Host. For packets with type "S", the remaining data on the trace line corresponds to the client selected and returned as the least loaded host.

• Client index: The client index is the internal index for the D2LC client. This index is assigned when a request is first received from the client, starting at 0.

• D2LC IP Address: The IP Address for the client sending the message.

• D2LC Port number: The IP Port number used by the client to send the message.

• Time message received: This is the time that the message was received from the client, in seconds since 00:00:00 UTC, January 1, 1970.

• Scale factor: The scale factor assigned for the client. The scale factor is used as a multiplier against the number of processes in choosing the least loaded host.

• Sequence number: The sequence number is the number of times the client has attempted to send messages to the D2LS server.

• Number of processes: The number of processes reported by the client.

• Last selected: This number indicates the last time a client was selected as a least loaded host. An internal counter in the server is incremented over time. When a client is selected as least loaded host, this counter is stored in the Last Selected field. The D2LC client with the lowest Last Selected field is known to be least recently used. When a request for a least loaded host results in a tie for least number of processes, then the least recently used client is selected to break the tie.

• D2LC Hostname: Shows the hostname of the D2LC client.

12.5.3 Sample Trace File

The following is a sample trace file for a two server configuration. Formsvr1 runs a D2L client and D2L server. Formsvr2 runs a D2L client.

HOSTNAME:          formsvr1.us.oracle.com       IP ADDRESS:   144.25.87.101
Data port number:  1234 Request port number:  1235
Maximum number of clients: 10   Trace level: 2

D:000   144.25.87.101:1000  925260387 1     2    0 0 [formsvr1]
D:000   144.25.87.101:1000  925260387 1     3   43 0 [formsvr1]
D:001   144.25.87.102:1001  925260388 1     2    0 0 [formsvr2]
D:001   144.25.87.102:1001  925260388 1     3   43 0 [formsvr2]
S:000   144.25.87.101:1000  925260387 1     3   44 1 [formsvr1]
D:000   144.25.87.101:1000  925260387 1     4   45 1 [formsvr1]
D:001   144.25.87.102:1001  925260388 1     4   45 0 [formsvr2]
S:001   144.25.87.102:1001  925260388 1     4   46 2 [formsvr2]
D:000   144.25.87.101:1000  925260387 1     5   45 1 [formsvr1]
D:001   144.25.87.102:1001  925260388 1     5   45 2 [formsvr2]
S:000   144.25.87.101:1000  925260387 1     5   46 3 [formsvr1]
D:000   144.25.87.101:1000  925260387 1     6   47 3 [formsvr1]
D:001   144.25.87.102:1001  925260388 1     6   47 2 [formsvr2]
S:001   144.25.87.102:1001  925260388 1     6   48 4 [formsvr2]
D:000   144.25.87.101:1000  925260387 1     7   47 3 [formsvr1]
D:001   144.25.87.102:1001  925260388 1     7   47 4 [formsvr2]