BEA Logo BEA WebLogic Server Release 6.1

  BEA Home  |  Events  |  Solutions  |  Partners  |  Products  |  Services  |  Download  |  Developer Center  |  WebSUPPORT



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

Configuring WebLogic Servers and Clusters


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:


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:

  1. Enter the following URL:

    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).

  2. 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.

  1. 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.

  2. All WebLogic Servers in a cluster must be located on the same local area network (LAN) and must be reachable via IP multicast.

  3. 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.


Server Configuration Tasks

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


Cluster Configuration Tasks

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


back to top previous page next page