BEA Logo BEA WebLogic Enterprise Release 5.1

  Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy

   http://www.oracle.com/technology/documentation/index.html   |   Site Map   |   Search   |   PDF Files   |   Contact   |   Glossary

 

   WebLogic Enterprise Doc Home   |   WebLogic Enterprise Installation Guide   |   Previous Topic   |   Next Topic   |   Contents   |   Index

Preparing to Install the WebLogic Enterprise Software

 

BEA WebLogic Enterprise is a sophisticated software product. It should not be installed without proper planning.

This topic includes the following sections:

 

Checking the WebLogic Enterprise Product Boxes

The WebLogic Enterprise software comes in two boxes:

Refer to the BEA WebLogic Enterprise Release Notes for information about the distribution mechanism for the T-Engine, J-Engine, and Jolt licenses.

If you ordered the WebLogic Enterprise 5.1 56-bit or 128-bit Encryption Package software product, an additional, separate package contains the CD for this software. Installation of the optional Encryption Package software on Windows systems is explained in WebLogic Enterprise Encryption Package Installation on Windows Systems. Installation of the optional Encryption Package software on UNIX systems is explained in WebLogic Enterprise Encryption Package Installation on UNIX Systems.

Figure 1-1 shows the contents of the four CDs that come in the WebLogic Enterprise product box, plus the optional Encryption Package CDs that are separately orderable.

Figure 1-1 Distribution CDs for WebLogic Enterprise 5.1

Note: Using CD #1, you can also install WebLogic Enterprise T-Engine client components on Windows 98 or Windows 95 systems.

 

WebLogic Enterprise CDs #1 and #2 Software Components

The WebLogic Enterprise CDs #1 and #2 contain the following software components.

For a list of the platforms supported for this release of the WebLogic Enterprise software, see WebLogic Enterprise T-Engine Platform Data Sheets.

Notes: The installation procedure for the J-Engine software components on CD #3 is described in Part III, J-Engine Installation. The installation procedure for the BEA Jolt software components on CD #3 is described in Part V, BEA Jolt Installation. The optional BEA WebLogic Enterprise 56-bit or 128-bit Encryption Package software, which provides Secure Sockets Layer (SSL) and Link-Level Encryption (LLE) for WebLogic Enterprise applications, is shipped to you only if you purchased this software. It is packaged and distributed on a separate CD. The installation procedure for this optional software is described in Part IV, Encryption Package Installation.

The WebLogic Enterprise 5.1 T-Engine installation procedure lets you select or deselect the T-Engine components that you want to install. You can also select or deselect specific subcomponents within the servers or clients categories.

At least one component or subcomponent must be selected for installation. Selecting a main component category causes all of its subcomponents to be selected. Deselecting a component causes all of its subcomponents to be deselected. Deselecting all subcomponents causes their parent component to be deselected.

The main component categories are:

Within the Servers category, the options are:

This feature allows you to install one or more server components on the target system.

Please note:

If you select the Clients component, you can indicate which types of clients you want to install. The Client options are:

The Administration category consists of the Administration Console and does not have any subcomponents. For information about how to start this console after it is installed, refer to BEA Administration Console Startup. For information about how to use this console, refer to the online help that is accessible through the Console's Help button.

 

Hardware and Software Prerequisites for the WebLogic Enterprise Software

The WebLogic Enterprise software must be installed on each machine that will run a WebLogic Enterprise client or server application.

Note: Do not share the WebLogic Enterprise executables across remote file systems.

The BEA Administration Console must be installed in a file system that supports long filenames (that is, those containing more than 14 characters).

Before you can install the optional WebLogic Enterprise Encryption Package 5.1 software, you must first install at least one WebLogic Enterprise 5.1 server component, or at least one of the following WebLogic Enterprise 5.1 client component options:

If you are installing the WebLogic Enterprise 5.1 Encryption Package software on a Microsoft Windows 98 or Windows 95 client system, you must first install at least one of the WebLogic Enterprise 5.1 client components shown in the previous list. Installation of the optional Encryption Package software on Windows systems is explained in WebLogic Enterprise Encryption Package Installation on Windows Systems. Installation of the optional Encryption Package software on UNIX systems is explained in WebLogic Enterprise Encryption Package Installation on UNIX Systems.

For details about the hardware and software prerequisites for all platforms on which the WebLogic Enterprise software is supported, see WebLogic Enterprise T-Engine Platform Data Sheets. Check the data sheet for each platform on which you plan to install the WebLogic Enterprise software.

For UNIX Systems

You need the following information and resources before installing the WebLogic Enterprise software on a UNIX system:

For Windows Systems

You need the following resources before installing the WebLogic Enterprise software on a Microsoft Windows system:

 

Overview of Upgrade Considerations

If you are installing the WebLogic Enterprise 5.1 software on a Microsoft Windows 2000, NT, 98, or 95 system that contains a previous version of WebLogic Enterprise, M3, or BEA Tuxedo software, there are important upgrade considerations. In general, BEA recommends that you use the Windows Add/Remove (uninstall) program to remove the previous WebLogic Enterprise, M3, or BEA Tuxedo software on the target system, before you install WebLogic Enterprise 5.1. These considerations are discussed in WebLogic Enterprise T-Engine Installation on Windows Systems.

 

Managing Files and Databases

This section explains how to assign ownership of the WebLogic Enterprise system files to the system administrator, and how to set up your disk to accommodate those files.

Assigning File Ownership on UNIX Systems

If you are installing the WebLogic Enterprise software on a UNIX system, BEA recommends that you create a separate user account for the WebLogic Enterprise system administrator and give ownership of the WebLogic Enterprise system files to that account.

Allocating Disk Space

A running WebLogic Enterprise client or server application needs disk space for system files and for the application's database(s). You do not use this space until you begin to develop or run your WebLogic Enterprise client or server application, but it is important to plan for this space before installing the software. To help explain what is involved, the following sections describe how the WebLogic Enterprise system handles files.

For more information about the commands discussed in this section, see the following documents:

The WebLogic Enterprise System Disk Management Interface

The WebLogic Enterprise system has a facility, the Disk Management Interface (DMI), that manages logical files within a single disk device or set of devices. Among other things, the DMI stores binary configuration tables and the transaction log.

The WebLogic Enterprise disk management software supports the notion of a WebLogic Enterprise file system that is distinct from any operating system file system. (For the remainder of this discussion, the term OS file system is used to refer to any operating system file system.)

Administrative access to the DMI to create, initialize, or destroy entries in the WebLogic Enterprise file system is through tmadmin administrative commands.

There are two ways to physically store the logical files managed by the DMI:

Files reside on special device files in that disk space, and the DMI manages the files directly. Space outside the OS file system is usually referred to as raw disk space. Not only is I/O faster when done by system calls reading directly from and writing directly to device special files on raw disks, raw disk space is preferred when it is important to know for certain that a physical write() has been done.

With the OS file system, the precise moment at which a write() is done cannot be relied upon. In the WebLogic Enterprise system, accurate control of the write operation is particularly important for entries in the transaction log. With multiple users, control of the write operation is also an important element in assuring database consistency.

Arranging for Raw Disk Space

If you decide to use raw disk space for your WebLogic Enterprise client or server application, you may find that the hard disk devices on your machine are fully allocated to file systems such as /(root), /usr, and other UNIX file systems. If that is the case, it is necessary to repartition your hard disk device to set aside some partitions that are not to be used for an OS file system. Information about how to do this can be found in the system administration documentation for your particular platform.

Notes: Repartitioning disks can render the machine unusable and should be attempted only by experienced UNIX system administrators.

On Microsoft Windows NT platforms, the default behavior is unbuffered I/O; no special arrangements are needed.

How the WebLogic Enterprise File System Is Organized

A WebLogic Enterprise file system has a Volume Table of Contents (VTOC) that lists files on a set of devices named in the Universal Device List (UDL). The UDL contains information about the location of the physical storage space for the WebLogic Enterprise tables.

In a WebLogic Enterprise system, all the system files might be stored together on the same raw disk slice or OS file system file. While it is possible to use regular OS file system files for the configuration tables, it is strongly recommended that the transaction log (TLOG) be stored on a raw disk device.

Because the TLOG seldom needs to be larger than 100 blocks and because disk partitions are always substantially larger than 100 blocks, it may make sense to use the same device for everything. The pathname of the device needs to be contained in both the TUXCONFIG and the FSCONFIG environment variables.

Listing 1-1 shows approximately how the content might appear.

Listing 1-1 VTOC and UDL Output

 

Output based on setting FSCONFIG=$TUXCONFIG, and invoking tmadmin:

No bulletin board exists. Entering boot mode.

> livtoc
Volume Table of Contents on /usr2/bank/tuxconfig:
0: VTOC: Device 0 Offset 0 Pages 7
1: UDL: Device 0 Offset 7 Pages 28
2: _RESOURCE_SECT: Device 0 Offset 35 Pages 3
3: _MACHINES_SECT: Device 0 Offset 38 Pages 40
4: _GROUPS_SECT: Device 0 Offset 78 Pages 40
5: _SERVERS_SECT: Device 0 Offset 118 Pages 40
6: _SERVICES_SECT: Device 0 Offset 158 Pages 20
7: _ROUTING_SECT: Device 0 Offset 178 Pages 100
8: _NETWORK_SECT: Device 0 Offset 278 Pages 20
9: _MIBPERMS_SECT: Device 0 Offset 298 Pages 2

# If the TLOG is stored on the same device, there will be an
# entry something like:

9: TLOG1: Device 0 Offset 236 Pages 100
> q

The WebLogic Enterprise system administrator must ensure that raw disk slices are available, as needed, on each machine participating in a WebLogic Enterprise domain. The size of entities in the WebLogic Enterprise file system are shown in Table 1-1.

Table 1-1 Size of System Tables

Entity

512-byte Pages

VTOC

1

TUXCONFIG

270

TLOG

100 (default)

UDL

28

TOTAL

399

The size of the TUXCONFIG file is larger if there are more entries in the configuration file (UBBCONFIG). The administrator is encouraged to allocate additional space for dynamic reconfiguration and for growth of the application. The default size assumed by the crdl subcommand of tmadmin is 1000 blocks, which should be adequate for the initial installation.

Space for Queue Spaces (If You Are Using /Q)

If your WebLogic Enterprise application is using the BEA Tuxedo system/Q for store-and-forward queue management, your queue space can be listed in the same UDL and can be managed by the WebLogic Enterprise VTOC.

Space for Application Servers

As you are calculating the space requirements for the WebLogic Enterprise system, also consider the requirements of the server machines that perform the work of the server application. These requirements are specified by the application, and they are in addition to the requirements for the WebLogic Enterprise system itself (unless otherwise specified).

Space for Stateful Session Bean Storage

When you calculate the space requirements for the WebLogic Enterprise system, also consider the requirements for saving the state of EJB Stateful Session Beans. These requirements are specified by the application, and they are in addition to the requirements for the WebLogic Enterprise system itself.

 

Selecting Directories for the WebLogic Enterprise Files

During the installation process, you are prompted to make decisions about where, in your file system, a number of your WebLogic Enterprise directories and files are installed. To help you plan for this part of the process, this section describes the directories and files about which you are prompted to make a decision, as follows:

For All Platforms

You are prompted for a pathname for the base directory of your WebLogic Enterprise software. This directory must meet the following requirements:

In the WebLogic Enterprise documentation, this directory is referred to as $TUXDIR (UNIX systems) or %TUXDIR% (Windows NT systems), except in cases where a sample path is shown, such as c:\wledir.

For All Server Platforms Supporting the BEA Administration Console

If you are installing the WebLogic Enterprise Administration software, you are prompted to accept or replace the default pathnames and filenames used for the BEA Administration Console components. These default pathnames and filenames are based on the value of %TUXDIR% (Windows NT systems) or $TUXDIR (UNIX systems) that you specify.

If you are running a commercial Web server, you may find the default settings inappropriate, especially if your server is handling requests from both the BEA Administration Console and other Web programs on the same port. To accommodate this situation, the WebLogic Enterprise software enables you to choose between accepting the defaults and assigning your own pathnames and filenames. The remainder of this section describes the choices you are given, as follows:

  1. A pathname for the HTML files-by default, the following HTML files are installed in the directory %TUXDIR%\udataobj\webgui (Windows NT systems), and $TUXDIR/udataobj/webgui (UNIX systems). You are prompted to supply your own paths for these files if you prefer to have them installed elsewhere.

  2. A pathname for the Java and image files-by default, the class files for the Java applet are installed in one of the following directories. You are prompted to supply your own paths for these files if you prefer to have them installed elsewhere.

  3. A directory pathname for the CGI program (tuxadm)-specify one of the following (unless the following exception applies):

  4. An alias for the directory pathname for tuxadm. This is the path for the directory in which Web clients expect to find tuxadm. The default is either /cgi-bin or /scripts (for UNIX systems) or \cgi-bin or \scripts (for Windows 2000 or NT systems).

 

Selecting an Administrative Password

The WebLogic Enterprise system uses an administrative password to protect the machine on which it is installed from unauthorized administrative requests and operations (such as tmboot). Whenever administrative communications arrive on this machine through the tlisten and wlisten processes, the WebLogic Enterprise system authenticates the communications by means of the password.

You assign an administrative password during the installation process (to the machine on which the WebLogic Enterprise software is being installed) by entering the password of your choice after the appropriate prompt. The password must be a string of alphanumeric characters in clear-text format. It may contain no more than 80 characters.

A common password is required for two machines in a WebLogic Enterprise domain to communicate successfully. For this reason, you must use the same password whenever you install the WebLogic Enterprise software on multiple machines for a single domain. As described previously, you are prompted to provide the password during the WebLogic Enterprise installation process. If, however, you use a different password for one machine, you must add that password to the tlisten.pw file on each existing machine with which you want that machine to communicate.

For these reasons, you may have more than one administrative password in your tlisten.pw file. A single password file may contain no more than 20 passwords, with one password per line.

The administrative password that you enter during installation is collected by the installation script and is stored in:

$TUXDIR/udataobj/tlisten.pw (UNIX systems)
%TUXDIR%\udataobj\tlisten.pw (Windows 2000 or NT systems)

Make sure the permissions on your tlisten.pw file are set such that only the WebLogic Enterprise system administrator can read the file.

 

Configuring the WebLogic Enterprise System for Windows 2000 or NT

You cannot configure your WebLogic Enterprise system for Microsoft Windows 2000 or NT until after you install the WebLogic Enterprise software and license. After you complete the installation as described in WebLogic Enterprise T-Engine Installation on Windows Systems, refer to the section "Configuring the WebLogic Enterprise System for Microsoft Windows 2000 and NT 4.0" on page 4-2 for instructions on configuring the WebLogic Enterprise system for Windows 2000 or NT.

 

Configuring the UNIX Operating System for the WebLogic Enterprise Software

The WebLogic Enterprise software uses the UNIX operating system Interprocess Communications (IPC) resources.

IPC resources are configured by three sets of tuning parameters that control the amount of shared memory (prefix SHM), number of semaphores (prefix SEM), and size of message queues and messages (prefix MSG).

The settings for these parameters are WebLogic Enterprise system dependent. Most UNIX systems, however, are shipped with default values that are too low for WebLogic Enterprise systems.

The following sections describe the IPC parameters and provide guidelines for configuring them. Because these parameters vary across different versions of UNIX, the following descriptions are generic. For the exact parameter names, default settings, settings used for the University Sample applications for each platform, and information about how to change the parameters, see WebLogic Enterprise T-Engine Platform Data Sheets.

If you change a parameter, you need to rebuild the kernel and reboot the operating system using the standard administrative tools. Consult your operating system administrator or the system administrator's guide for your platform for details.

If your WebLogic Enterprise client or server application is distributed, the minimum IPC resources must be available on every UNIX platform participating in the application.

Semaphores

Every process that participates in a WebLogic Enterprise system requires a semaphore. When the system boots, the number of semaphores configured in the operating system is checked, and the boot fails if the configured number is not high enough.

Semaphores on UNIX systems are grouped in semaphore sets. Each semaphore in a set can be accessed separately. Although WebLogic Enterprise does not perform operations on semaphore sets, it attempts to allocate as many semaphores per semaphore set as possible. WebLogic Enterprise also needs undo structures to function properly. The operating system uses undo structures to unlock semaphores held by a process that dies unexpectedly.

The following semaphore parameters may need to be adjusted:

Maximum number of semaphores in the system. The minimum requirement for SEMMNS is:

MAXACCESSERS - MAXWSCLIENTS + 13

where MAXACCESSERS is the maximum number of WebLogic Enterprise processes on a particular machine (including servers and native clients), and MAXWSCLIENTS is the maximum number of WebLogic Enterprise remote clients. Both of these parameters are specified in the application's UBBCONFIG file.

For more information about UBBCONFIG, see Creating a Configuration File in the WebLogic Enterprise online documentation, or the ubbconfig(5) reference page in the BEA Tuxedo Reference Manual.

Maximum number of active semaphore sets. See SEMMSL.

Maximum number of semaphores per semaphore set. SEMMNI and SEMMSL are commonly chosen so that their product equals SEMMNS. The WebLogic Enterprise system does not perform semaphore operations on semaphore sets; however, it attempts to allocate as many semaphores per semaphore set as possible.

Size of the control map used to manage semaphore sets. SEMMAP should be equal to SEMMNI.

Number of undo structures in the system. Because an undo structure is needed for each process that can access the Bulletin Board, SEMMNU must be at least as large as SEMMNS.

Maximum number of undo entries per undo structure. The value 1 suffices.

Message Queues and Messages

WebLogic Enterprise client and server applications use UNIX messages and message queues for client/server communication. Examples of such messages are service requests, service replies, conversational messages, unsolicited notification messages, administrative messages, and transaction control messages.

Every Multiple Servers, Single Queue (MSSQ) set of servers, and every individual server has a message queue for receiving requests. Every client has its own queue for receiving replies. Servers that specify the REPLYQ parameter also get individual reply queues.

The adjustment of kernel message parameters is important to the proper tuning of the WebLogic Enterprise system. Inappropriate values can lead to an inability to boot, or to severe performance degradation.

There are various message queue parameters. They limit various characteristics of the queue space, including the total number of outstanding messages (MSGTQL), the total number of bytes that can be on one queue (MSGMNB), the size limit of an individual message (MSGMAX), the total number of message segments that can be outstanding at one time (MSGSEG), and the size of each segment (MSGSSZ).

Exceeding any of the parameter limits described previously results in what is known as a blocking condition. There is a special case for MSGMAX. Messages that exceed 75 percent of MSGMNB, or that are larger than MSGMAX, are placed in a UNIX file. A very small message with the filename in it is then sent to the recipient. Avoid this mode of operation, because it results in a severe reduction in performance.

An application deadlock can result if every process is blocked when it tries to send a message. For example, when client applications fill the message space with requests, and server applications are all blocked when they try to send replies, because no server application can read a message, there is a deadlock. Timeouts can sometimes break the deadlock, but no useful work will have been done.

Especially troublesome is a client application that sends its requests with the TPNOREPLY flag. This practice can fill either individual queues or the system message space, depending on the size of the messages. Such applications may have to implement their own flow control to limit the number of outstanding messages.

To summarize, if client applications or server applications are blocking on their send operations (that is, requesting services or sending replies), there is potential for trouble. It is usually no problem, though, for a single server request queue to always be full, as long as there is space in the system for more messages on other queues.

There are performance implications to queue blocking conditions, both on the sending side and the receiving side. The UNIX operating system, when waking up blocked processes, wakes up all the processes blocked on a particular event, even if only one can proceed. The other processes go back to sleep. This process scheduling overhead can be expensive.

For example, on an empty server request queue where there is more than one server application (that is, MSSQ), an arriving message wakes up all the idle, or blocked, server applications on that queue. In the case of a full server request queue, as each request is read by a server application, the system wakes up all the blocked clients. Depending on the size of the messages, zero or more clients are allowed to place their messages on the queue. The remainder of the clients have to go back to sleep. Because there may be hundreds of clients in the system, the mass wakeup of all of these clients every time a service request is processed can severely degrade performance.

A properly tuned system rarely fills its queues. Enough slack should be left in the queues to handle the natural variability of the message flow. No exact settings can be recommended. Tuning is very system dependent. The UNIX ipcs(1) command provides a snapshot of the queues so you can tell whether they are full. You can try the TPNOBLOCK flag when sending requests. That way, clients can tell when queues are full, and they can slow down a bit. It might help to increase the scheduling priority of the servers whose request queues are full.

The following message parameters may need to be adjusted:

Number of unique message queue identifiers. Each process participating in a WebLogic Enterprise client or server application on a particular machine typically needs at least one message queue. This number is reduced if MSSQ sets are used, where multiple server processes share a single queue. For transaction processing, count an additional queue per server group for TMS processes. Thus, the minimum requirement for MSGMNI can be determined by this formula:

MSGMNI = MAXACCESSERS + 7
+ (number of servers with REPLYQ)
+ (number of MSSQ sets)
- (number of servers in MSSQ sets)

Maximum message size in bytes. MSGMAX must be large enough to handle any WebLogic Enterprise client or server application running on this machine.

Maximum message queue length in bytes. This number must accommodate the total size of all messages that are on a queue and that have not been taken off by the associated process(es). The minimum value for MSGMNB is MSGMAX. Messages longer than 75 percent of MSGMNB are sent to a file instead of to a message queue. Avoid this situation because it severely degrades performance.

Number of entries in the control map used to manage message segments. MSGMAP should be the same as the number of message segments (MSGSEG), which should be twice the size of MSGMNI.

Size of a message segment in bytes. A message can consist of several such segments. The value of MSGSSZ should be such that a multiple of MSGSSZ is equal to the size (including the WebLogic Enterprise system header) of the most commonly sent message. This practice avoids wasting space.

Number of message segments in the system.

Total number of outstanding messages that can be stored by the kernel. This is the maximum number of unread messages at any given time.

Shared Memory

In the WebLogic Enterprise environment, shared memory is used for the Bulletin Board and for the control table of the IIOP Listener. An application also may choose to use shared memory for its own purposes.

The following shared memory parameters may need to be adjusted:

Maximum shared memory segment size in bytes. This number represents the largest shared memory segment that can be allocated. A process can, however, attach to more than one segment of size SHMMAX.

Maximum number of shared memory segments per process. For a given configuration, the maximum amount of shared memory in bytes to which a process can attach is SHMMAX * SHMSEG. A value between 6 and 15 should be adequate.

Maximum number of shared memory identifiers in the system. The WebLogic Enterprise system requires one identifier per Bulletin Board and an additional identifier if the IIOP Listener is running.

Minimum shared memory segment size in bytes. This should always be
set to 1.

Other Kernel Tuning Parameters

Experience with WebLogic Enterprise systems has shown that some other UNIX tuning parameters may need to be set to higher values. The settings are dependent on the application and do not apply to all applications.

ULIMIT

Maximum file size. ULIMIT needs to be large enough so that you can install the WebLogic Enterprise software and build servers. We recommend 4 MB.

NOFILES

Maximum number of open files per process. A WebLogic Enterprise server application requires a minimum of four file descriptors.

MAXUP

Maximum number of processes per non-super user. The WebLogic Enterprise system processes (servers and administrative processes) run with the UID specified in the application's UBBCONFIG file. MAXUP needs to be large enough to allow all these processes to run.

NPROC

Maximum number of processes (system wide).

NREGION

Number of region table entries to allocate. Most processes have three regions: text, data, and stack. Additional regions are needed for each shared memory segment and shared library (text and data) attached. However, the region table entry for the text of a shared text program is shared by all processes executing that program. Each shared memory segment attached to one or more processes uses another region table entry.

NUMTIM

Maximum number of STREAMS modules that can be pushed by the Transport Layer Interface (TLI). A typical default value is 16. Set NUMTIM to at least 256.

NUMTRW

The number of TLI read/write structures to allocate in kernel data space. A typical default value is 16. Set NUMTRW to at least 256.

Calculating IPC Requirements

When the WebLogic Enterprise software has been installed and an application configuration file (UBBCONFIG file) is available, the tmloadcf command can be used to calculate the IPC resources needed to support the application. For more information, see the tmloadcf(1) reference page in the BEA Tuxedo Reference Manual. Also see "Verifying IPC Requirements" on page 4-17.

 

 

 

Copyright © 2000 BEA Systems, Inc. All rights reserved.
Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.