Configuring WebLogic Servers and Clusters


	BEA Home \| Events \| Solutions \| Partners \| Products \| Services \| Download \| Developer Center \| WebSUPPORT
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| Download Documentation \| Contact \| Glossary

\| WebLogic Server Doc Home \| Administration Guide \| Previous Topic \| Next Topic \| Contents \| Index \| View as PDF

The following sections discuss how to set up WebLogic Servers and WebLogic Server clusters:

Overview of Server and Cluster Configuration

The persistent configuration for a domain of WebLogic Servers and clusters is stored in an XML configuration file. You can modify this file in three ways:

Through the Administration Console, BEA's graphical user interface (GUI) for managing and monitoring a domain configuration. This is intended as the main way to modify or monitor the domain configuration.
By writing a program to modify the configuration attributes, based on the configuration application programmatic interface (API) provided with WebLogic Server.
By running the WebLogic Server command-line utility for accessing configuration attributes of domain resources. This is provided for those who want to create scripts to automate domain management.

Role of the Administration Server

Whichever method you choose, the Administration Server must be running when you modify your domain configuration.

The Administration Server is the WebLogic Server on which the Administration Service runs. The Administration Service provides the functionality for WebLogic Server, and manages the configuration for an entire domain.

By default; an instance of WebLogic Server is treated as an Administration Server. When the Administration Server starts, it loads the configuration files, which are stored, by default, in a directory called config under the WEBLOGIC_HOME directory. The config directory has a subdirectory for each domain that is available to the Administration Server. The actual configuration file resides inside the domain-specific directory and is called config.xml. By default, when an Administration Server starts, it looks for the configuration file (config.xml) under the default domain directory (which is specified during installation of WebLogic Server software).

Each time the Administration Server is successfully started, a backup configuration file named config.xml.booted is created in the domain specific directory.In the unlikely event that the config.xml file should become corrupted during the lifetime of the server, it is possible to revert to this previously known, good configuration.

A domain could consist of only one WebLogic Server. But in that case, that WebLogic Server would be an Administration Server because each domain must have at least (and at most) one Administration Server.

Figure 4-1 shows a typical production environment that contains an Administration Server and multiple WebLogic Servers. When you start the servers in such a domain, the Administration Server is started first. As each additional server is started, it is instructed to contact the Administration Server for its configuration information. In this way, the Administration Server operates as the central control entity for the configuration of the entire domain. No more than one Administration Server can be active in a domain. Only the Administration Server can modify the configuration files when it is running.

Note: Do not use a shared filesystem and a single installation to run multiple WebLogic Server instances on separate machines. Using a shared filesystem introduces a single point of contention. All servers must compete to access the filesystem (and possibly to write individual log files). Moreover, should the shared filesystem fail, you may be unable to start managed or clustered servers.

Figure 4-1 WebLogic Server Configuration

Starting the Administration Console

The main point of access to the Administration Server is through the Administration Console. To open the Administration Console:

Enter the following URL:
http://host:port/console
where host is the host name or IP address of the machine on which the Administration Server is running and port is the address of the port at which the Administration Server is listening for requests (by default, 7001).
The system prompts you to enter a user ID and password. Enter your UserID and password. The system performs an authentication and authorization check: it verifies the user ID and password against the user database.
If you are authorized to work with the console, then the console is displayed in the access mode that the system administrator originally assigned to you: either ReadOnly or Read/Write

How Dynamic Configuration Works

WebLogic Server allows you to change the configuration attributes of domain resources dynamically, that is, while servers are running. In most cases you do not need to restart WebLogic Server for your changes to take effect. When an attribute is reconfigured, the new value is immediately reflected in both the current run-time value of the attribute and the persistent value stored in the XML configuration file.

There are exceptions, however. If, for example, you change a WebLogic Server's listen port, the new address will not be used until the next time you start the affected server. In that case, if you modify the value, you are changing the persistent value stored in the XML file and the current run-time configuration value for the attribute may differ from that persistently stored value. The Administration Console indicates if the persistent and runtime values for a configuration attribute are not the same using an icon which changes to an alert
when the server needs to be restarted for changes to take effect.

The console does a validation check on each attribute that users change. The errors that are supported are out-of-range errors and datatype mismatch errors. In both cases, an error dialog box displays telling the user that an error has occurred.

Once the Administration Console has been started, if another process captures the Listen Port assigned to the Administration Server, you should remove the process that has captured the server. If you are not able to remove the process that has captured the Listen Port assigned to the Administration Server, you must edit the Config.XML file to change the assigned Listen Port. For information about editing the Config.XML file, please see the Configuration Reference.

Planning a Cluster Configuration

When planning a cluster configuration, keep in mind the following constraints on the networking environment and the cluster configuration.

The machine(s) you will be using as WebLogic hosts for the cluster must have permanently assigned, static IP addresses. You cannot use dynamically-assigned IP addresses in a clustering environment. If the servers are behind a firewall and the clients are in front of the firewall, each server must have a public static IP address that can be reached by the clients.
All WebLogic Servers in a cluster must be located on the same local area network (LAN) and must be reachable via IP multicast.
All servers in a cluster must be running the same version of WebLogic Server.

Configure the servers in your cluster to support the particular mix of services that you are offering.

For EJBs that are using JDBC connections, all the servers that deploy a particular EJB must have the same deployment and persistence configuration. This means configuring the same JDBC connection pool on each server.
Every machine that hosts servlets must maintain the same list of servlets with identical ACLs (access control lists).
If your client application uses JDBC connection pools directly, you must create identical connection pools (with identical ACLs) on each WebLogic Server. This means that it must be possible to create any connection pool in use on all machines in the cluster. If, for example, you configure a pool of connections to a Microsoft SQL Server database on a Windows NT server running WebLogic, you cannot use this connection pool in a cluster that contains any non-Windows machines (that is, any machines that cannot support a Microsoft SQL Server connection).
Other configuration details may differ for various members in the cluster. You might, for example, configure a Solaris server to process more login requests than a small Windows NT workstation. Such differences are acceptable. Thus, in the example given here, the performance-specific attributes of individual cluster members may be configured with different values, so long as the service configuration for all members is identical. In practice, this often results in WebLogic Servers in the cluster being identically configured in all areas to do with WebLogic services, class files, and external resources (such as databases).

Server Configuration Tasks

Server configuration tasks that can be accomplished from the Administration Console include:

Configuring an individual server using the Server node of the Administration Console. The attributes that can be changed using this node include the Server Name, the ListenPort, and the IP Address.
Cloning an individual server using the Server node of the Administration Console. The individual server is cloned, maintaining the attribute values in the original server and the name of the new server is set on the Configuration portion of the Server node.
Deleting a server using the Server node of the Administration Console. Click the delete icon for the server you want to delete. A dialog box will appear asking you to confirm the deletion of the server. Click Yes to confirm your decision to delete the server.
Viewing a server log using the Server node of the Administration Console. Click the server you want to monitor. Select the Monitoring tab. Click the View Server Log link and monitor the server log in the right pane of the Administration Console.
Viewing a server JNDI tree using the Server node of the Administration Console. Click the server you want to monitor. Select the Monitoring tab. Click the View JNDI Tree link and view the tree in the right pane of the Administration Console.
Viewing server execute queues using the Server node of the Administration Console. Click the server you want to monitor. Click the Execute Queues link and view the table in the right pane of the Administration Console.
Viewing server execute threads using the Server node of the Administration Console. Click the server you want to monitor. Click the Execute Queues link and view the table in the right pane of the Administration Console.
Viewing server sockets using the Server node of the Administration Console. Click the server you want to monitor. Click the View Sockets link and view the table in the right pane of the Administration Console.
Viewing server connections using the Server node of the Administration Console. Click the server you want to monitor. Click the View Connections link and view the table in the right pane of the Administration Console.
Forcing garbage collection on a server using the Server node of the Administration Console. Click the server you want to monitor. Select the JVM tab. Click the Force Garbage Collection link. A dialog box will appear to confirm that garbage collection has taken place.
Monitoring server security using the Server node of the Administration Console. Click the server you want to monitor. Select the Monitoring tab. Select the Security tab. The security information will be displayed.
Viewing the server version using the Server node of the Administration Console. Click the server you want to monitor. Select the Version tab. The version data for this server will be displayed.
Monitoring server clusters using the Server node of the Administration Console. Click the server you want to monitor. Select the Cluster tab. The cluster data for this server will be displayed.
Deploying EJBs on a server using the Server node of the Administration Console. Click the server on which you want to deploy EJBs. Click the EJB you want to deploy and use the move control to move it to the Chosen column. Click Apply to save your selections.
Monitoring all EJB deployments on a server using the Server node of the Administration Console. Click the server on which you want to monitor EJBs. Click the Monitor All EJB Deployments link to display the EJB Deployments table.
Deploying Web Application components on a server using the Server node of the Administration Console. Click the server on which you want to deploy Web Applications. Click the Web Application you want to deploy and use the move control to move it to the Chosen column. Click Apply to save your selections.
Monitoring all Web Application components on a server using the Server node of the Administration Console. Click the server on which you want to monitor Web Applications. Click the Monitor All Web Applications link to display the Web Application Deployments table.
Deploy startup and shutdown classes on a server using the Server node of the Administration Console. Click the server on which you want to deploy startup classes. Click the startup class you want to deploy and use the move control to move it to the Chosen column. Click Apply to save your selections. Use the same process to deploy shutdown classes using the Shutdown Class control.
Assigning JDBC connection pools to a server using the Server node of the Administration Console. Click a server for Web-server assignment. Click one or more JDBC connection pools in the Available column that you want to assign to the server and use the mover control to move the JDBC connection pools you selected to the Chosen column. Click Apply to save your assignments.
Assigning WLEC connection pools to a server using the Server node of the Administration Console. Click a server for WLEC connection-pool assignment. Click one or more WLEC connection pools in the Available column that you want to assign to the server and use the mover control to move the WLEC connection pools you selected to the Chosen column.
Monitoring all WLEC connection pools on a server using the Server node of the Administration Console. Click a server for WLEC connection-pool monitoring. Click the Monitor All WLEC Connection Pools on This Server text link on the WLEC tab. The WLEC Connection Pools table displays in the right pane showing all the connection pools assigned to this server.
Assigning XML registries to a server using the Server node of the Administration Console. Click a sever for XML registry assignment. Click a registry from the XML Registry drop-down list box. Click Apply to save your selection.
Assigning mail sessions to a server using the Server node of the Administration Console. Click a server for mail-session assignment. Click one or more mail sessions in the Available column that you want to assign to the server. Use the mover control to move the mail sessions you selected to the Chosen column. Click Apply to save your selections.
Assigning File T3s to a server using the Server node of the Administration Console. Click a server for file T3 assignment. Click one or more file T3s in the Available column that you want to assign to the server. Use the mover control to move the file T3s you selected to the Chosen column. Click Apply to save your selections.

Cluster Configuration Tasks

Cluster configuration tasks that can be accomplished from the Administration Console include:

Configuring a cluster of servers using the Cluster node of the Administration Console. The attributes that can be changed using this node include the Cluster Name, the Cluster ListenPort, and the names of the servers in the cluster.
Cloning a cluster of servers using the Cluster node of the Administration Console. The cluster is cloned, maintaining the attribute values and individual servers in the original cluster and the name of the new cluster is set on the Configuration portion of the Server node.
Monitoring servers in a cluster using the Cluster node of the Administration Console. Click a cluster for server monitoring. Click the Monitor Server Participation in This Cluster text link. The server table displays in the right pane showing all the servers assigned to this cluster.
Assigning servers to a cluster using the Cluster node of the Administration Console. Click a cluster for server assignment. Click one or more servers in the Available column that you want to assign to the cluster. Use the mover control to move the servers you selected to the Chosen column. Click Apply to save your selections.
Deleting a cluster using the Cluster node of the Administration Console. Click the Delete icon in the row of the cluster you want to delete. A dialog box displays in the right pane asking you to confirm your deletion request. Click Yes to confirm your decision to delete the cluster.