Using WebLogic Server Clusters

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Understanding Cluster Configuration

This following sections explain how the information that defines the configuration of a cluster is stored and maintained, and the methods you can use to accomplish configuration tasks:

Note: Much of the information in this section also pertains to the process of configuring a WebLogic domain in which the server instances are not clustered.

 


Cluster Configuration and config.xml

The config.xml file is an XML document that describes the configuration of a WebLogic Server domain. config.xml consists of a series of XML elements. The Domain element is the top-level element, and all elements in the Domain descend from the Domain element. The Domain element includes child elements, such as the Server, Cluster, and Application elements. These child elements may have children of their own. For example, the Server element includes the child elements WebServer, SSL and Log. The Application element includes the child elements EJBComponent and WebAppComponent.

Each element has one or more configurable attributes. An attribute defined in config.dtd has a corresponding attribute in the configuration API. For example, the Server element has a ListenPort attribute, and likewise, the weblogic.management.configuration.ServerMBean has a ListenPort attribute. Configurable attributes are readable and writable, that is, ServerMBean has a getListenPort and a setListenPort method.

To learn more about config.xml, see Domain Configuration Files in Understanding Domain Configuration.

 


Role of the Administration Server

The Administration Server is the WebLogic Server instance that configures and manages the WebLogic Server instances in its domain.

A domain can include multiple WebLogic Server clusters and non-clustered WebLogic Server instances. Strictly speaking, a domain could consist of only one WebLogic Server instance—however, in that case that sole server instance would be an Administration Server, because each domain must have exactly one Administration Server.

There are a variety of ways to invoke the services of the Administration Server to accomplish configuration tasks, as described in Methods of Configuring Clusters. Whichever method is used, the Administration Server for a cluster must be running when you modify the configuration.

When the Administration Server starts, it loads the config.xml for the domain. It looks for config.xml in the directory:

BEA_HOME/user_projects/domains/<domain_name>/config

where domain_name is a domain-specific directory, with the same name as the domain.

Each time the Administration Server starts successfully, a backup configuration file named config.xml.booted is created in the domain directory. In the unlikely event that the config.xml file should be corrupted during the lifetime of the server instance, it is possible to revert to this previous configuration.

The following figure shows a typical production environment that contains an Administration Server and multiple WebLogic Servers instances. When you start the server instances in such a domain, the Administration Server is started first. As each additional server instance is started, it contacts 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.

Figure 4-1 WebLogic Server Configuration

WebLogic Server Configuration

What Happens if the Administration Server Fails?

The failure of an Administration Server for a domain does not affect the operation of Managed Servers in the domain. If an Administration Server for a domain becomes unavailable while the server instances it manages—clustered or otherwise—are up and running, those Managed Servers continue to run. If the domain contains clustered server instances, the load balancing and failover capabilities supported by the domain configuration remain available, even if the Administration Server fails.

Note: If an Administration Server fails because of a hardware or software failure on its host machine, other server instances on the same machine may be similarly affected. However, the failure of an Administration Server itself does not interrupt the operation of Managed Servers in the domain.

For instructions on re-starting an Administration Server, see Avoiding and Recovering From Server Failure in Managing Server Startup and Shutdown.

 


How Dynamic Configuration Works

WebLogic Server allows you to change the configuration attributes of domain resources dynamically—while server instances are running. In most cases you do not need to restart the server instance 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 config.xml.

Not all configuration changes are applied dynamically. For example, if you change a Managed Server's ListenPort value, the new port will not be used until the next time you start the Managed Server. The updated value is stored in config.xml, but the runtime value is not affected.

The Administration Console validates attribute changes, checking for out-of-range errors and data type mismatch errors, and displays an error message for erroneous entries.

Once the Administration Console has been started, if another process captures the listen port assigned to the Administration Server, you should stop the process that captured the port. If you are not able to remove the process that captured the listen port, edit the config.xml file to change the ListenPort value.

 


Methods of Configuring Clusters

There are several methods for configuring a clusters:


  Back to Top       Previous  Next