BEA Logo BEA WebLogic Portal Release 4.0

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

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

 

   WebLogic Portal Documentation   |   Deployment Guide   |   Previous Topic   |   Next Topic   |   Contents   |   Index

Deploying Clusters

 

Clustering provides several advantages that are optimal for Production-type designs including, but not limited to, load-balancing, failover, performance, administration and security. A cluster comprises one Administration Server and one or more Managed Servers. The Administration Server provides most of the configuration for application deployment and network communication, while the Managed Servers handle most of the business logic and client requests.

This topic contains the following sections:

 

How Clusters Are Organized and Maintained

In any WebLogic Server cluster, the host for the Administration Server is the only computer that contains the physical files that describe the cluster, enterprise application, and other supporting services. If you want to modify the cluster or application's configuration, you do so from the Administration Server host. WebLogic Server distributes any configuration changes from the Administration Server to the logical processes and data structures on the Managed Servers.

While WebLogic Server supports a variety of cluster configurations, this topic guides you through deploying a cluster that is in the following recommended configuration (See Figure 6-1):

Consider creating at least one mirror site for your cluster. When you need to perform maintenance or deploy additional application data onto a cluster, you can route all customers to a mirror site. Then, when you finish your updates, you can route customers to the original site while you update the mirror.

 

Before You Start

Before you start to set up a cluster, do the following:

 

Setting Up a Cluster

To set up a cluster, complete the following tasks on the computer that you want to host the Administration Server:

Activate the Domain and Start the WebLogic Server Administration Console

Logically, a cluster resides in a single WebLogic Server administrative domain: one domain defines and administers the cluster.

You can create a domain specifically for your cluster or copy an existing domain onto the computer that you want to host the Administration Server. To activate the domain, start an instance of WebLogic Portal on the computer that you want to be the cluster's Administration Server.

Note: Later in the process of setting up a cluster, you will install your enterprise application onto this server. Then WebLogic Server deploys this enterprise application onto the Managed Servers; it will also deploy any subsequent modifications that you make to the enterprise application on the Administration Server.

Then access the WebLogic Server Administration Console for the domain by entering the following URL in a Web browser:

http://admin-host-name:port-number/console

For example, http://localhost:7501/console

Create Machines

A machine is intended to be the logical representation of a single, physical, piece of hardware. WebLogic Server uses machines to establish a preferred order for replicating objects. (Its first preference is to replicate objects on separate machines for failover purposes.)

Create machines for each node by doing the following:

  1. In the WebLogic Server Administration Console, in the left pane, right click the Machines folder. Then click Configure a New Machine. (See Figure 6-2.)

  2. In the Name box, enter a name for the machine. Use a name that correlates to the name of the server that you intend to deploy onto this piece of hardware. For example, for Server A, enter the name Machine A.

  3. Click Create.

  4. Repeat until you have created machines for the Administration Server and all Managed Servers in the cluster.

    Figure 6-2 Creating a Machine


     

Create Server Configurations

A cluster contains configurations for one Administration Server and multiple Managed Servers. This section contains the following subsections:

Creating an Administration Server

By default, when you start a server instance, it is an Administration Server. You can use the currently active server as the Administration Server for your cluster, or, if you want to create a server configuration specifically for administering your domain, do the following:

  1. In the left pane of the WebLogic Server Administration Console, right click Servers.

  2. Click Configure a new Server.

  3. On the Create a New Server page, in the Name box, enter a name for the server. Use a name that indicates the purpose of the server. For example, AdminServer.

  4. From the Machine list, select a machine for the server.

  5. In the Listen Port box, enter a port number that you will use to connect to the Administration Server. For example, in Figure 6-1 the Administration Server listens on port 35111.

  6. In the Listen Address box, enter either the server host's name or IP address. You can use the host name only if you have configured a host file. Entering a host name gives the flexibility of using the hosts file to maintain mappings of host names to IP addresses.

  7. Click Create.

Creating a Synchronization Server

To create a server for synchronizing application data across the cluster, do the following:

  1. In the left pane of the WebLogic Server Administration Console, right click Servers.

  2. Click Configure a new Server.

  3. On the Create a New Server page, in the Name box, enter a name for the server. For example, SynchServer.

  4. From the Machine list, select a machine for the server.

  5. In the Listen Port box, enter a port number that the E-Business Control Center will use to connect to the Synchronization Server.

  6. In the Listen Address box, enter either the server host's name or IP address. You can use the host name only if you have configured a host file. Entering a host name gives the flexibility of using the hosts file to maintain mappings of host names to IP addresses.

  7. Click Create.

Creating Managed Servers

To create Managed Servers, do the following:

  1. In the left pane of the WebLogic Server Administration Console, right click Servers.

  2. Click Configure a new Server.

  3. On the Create a New Server page, in the Name box, enter a name for the server. Use a name that correlates to the function of the server. For example, for a Managed Server, create a server named Server A.

  4. From the Machine list, select a machine for the server.

  5. In the Listen Port box, enter a port number on which the server listens for requests from the proxy server. Each server in the cluster should use the same listen address port. For example, in Figure 6-1 the Managed Servers listen on port 35121.

  6. In the Listen Address box, enter either the server host's name or IP address. You can use the host name only if you have configured a host file. Entering a host name gives the flexibility of using the hosts file to maintain mappings of host names to IP addresses.

  7. Click Create.

  8. Click the Logging tab. From the Stdout severity threshold list, select Info. Then click Apply. Informational messages display information about the server joining the cluster, which is useful for diagnosing any problems with the cluster.

  9. Repeat these steps for each Managed Server.

Set Up SSL

To set up SSL, do the following for each Managed Server:

  1. In the left pane, open the Servers folder.

  2. Click a Managed Server.

  3. On the Server page, click the SSL tab.

  4. On the SSL tab, check the Enabled box. Then provide values for the following fields:

  5. Click Apply.

  6. Repeat for the remaining Managed Server configurations.

Configure a Cluster

Configure a cluster by doing the following:

  1. In the left pane, right click the Cluster folder.

  2. Click Configure a new Cluster.

  3. On the Create a New Cluster page, in the Name box, enter a name for the cluster.

  4. In the Cluster Address box, enter the IP addresses (or host names) of all the Managed Servers in the cluster. Separate addresses by commas. Do not add the IP address for the Administration Server.

  5. Click Create. (See Figure 6-3.)

    Figure 6-3 Configure a Cluster


     

  6. Set up the Multicast address by doing the following:

    1. On the Cluster page, click the Multicast tab.

    2. In the Multicast Address box, enter an IP address that the nodes in the cluster use to communicate with each other. Multicast addresses must range between 224.0.0.1 and 239.255.255.255. If you set up multiple clusters on your network, make sure that each cluster uses a unique multicast address.

      We recommend that you conduct a multicast test. For information on using the WebLogic Server MulticastTest utility, refer to "Using the WebLogic Java Utilities" in the WebLogic Server Administration Guide.

    3. Click Apply.

  7. On the Cluster page, click the Servers tab.

  8. Move the Managed Servers from the Available list to the Chosen list. Do not place the Administration Server or the Synchronization Server in the Chosen list.

  9. Click Apply.
     

 

Configure Your Web Application to Support Clusters

Before you deploy your application, configure your Web applications to support clusters by completing the following steps:

  1. From the computer that hosts the Administration Server, start a text editor and open your Web application's web.xml file. In the wlcsApp reference application, the file is in the following location: PORTAL_HOME/applications/wlcsApp/wlcs/WEB-INF/web.xml.

  2. The following elements determine which port numbers the createWebflowURL() method encodes in the URLs that it generates. Change the value of the <param-value> subelements to match the HTTP and HTTPS listen ports of the proxy server:

    <context-param>
    <param-name>HTTP_PORT</param-name>
    <param-value>35101</param-value>
    </context-param>

    <context-param>
    <param-name>HTTPS_PORT</param-name>
    <param-value>35102</param-value>
    </context-param>

    This excerpt uses the port numbers from Figure 6-1.

  3. Open your Web application's weblogic.xml file. In the wlcsApp reference application, the file is in the following location: PORTAL_HOME/applications/wlcsApp/wlcs/WEB-INF/weblogic.xml.

  4. Add the following elements to enable replication of HTTP Sessions across the cluster nodes:

    <session-param>
    <param-name>PersistentStoreType</param-name>
    <param-value>replicated</param-value>
    </session-param>

    Note: The name of the cookie on a proxy server must match the cookie name specified in the weblogic.xml of the deployed Web application. For Netscape Enterprise Server, no change is needed. For Apache, you declare the cookie name in the httpd.conf file. If WebLogic Server is being used as a Web proxy server, you make the change in the WebLogic Server proxy server's weblogic.xml file. For example, the unedited weblogic.xml might contain:

    <session-param>
    <param-name>CookieName</param-name>
    <param-value>
    JSESSIONID
    </param-value>
    </session-param>

    The wlcsApp, for example, uses JSESSIONID_WLCS_COMMERCE in its weblogic.xml. On the proxy server's weblogic.xml, change the CookieName parameter's value to JSESSIONID_WLCS_COMMERCE.

For more information on modifying deployment descriptors, refer to the following sections:

 

Deploying Applications to a Cluster

To deploy applications and supporting services to a cluster, complete the following tasks:

Configure a New Application

  1. Copy your application onto the computer that hosts the Administration Server.

  2. Launch the WebLogic Server Administration Console for the server.

  3. In the left pane, open the Deployments folder.

  4. Right click the Applications folder and click Configure a New Application. (See Figure 6-4.)

    Figure 6-4 Configure a New Application


     
     

  5. On the Configure a New Application page, do the following:

    1. In the Name box, enter the name of the application. WebLogic Server uses this name only within the WebLogic Server Administration Console. The name does not affect the URIs of resources within the enterprise application.

    2. In the Path box, enter the pathname of the application's root directory.

    3. Clear the Deploy check box.

    4. Click Create.

Deploy and Configure DataSync Web Applications for the Cluster

The DataSync Web application receives synchronization requests from the E-Business Control Center and channels them to Data Repositories, which are runtime representations of application data.

Clusters with Shared Access to Disk Containing DataSync Database Pool

If your cluster environment provides shared access to the disk containing the DataSync Database Pool, do the following to deploy the DataSync Web application that the cluster uses for configuration purposes:

  1. In the left pane, click Deployments -> Web Applications and then click the DataSync Web application that the cluster uses for configuration purposes. For example, if you named this Web application BankAppDataConfig, click BankAppDataConfig in the left pane.

  2. On the Web application page, click the Targets tab. Then click the Servers sub tab.

  3. Move the Synchronization Server from the Available column to the Chosen column. Then click Apply.

  4. Click the Clusters sub tab.

  5. Move your cluster from the Available column to the Chosen column. Then click Apply.

  6. Deploy the DataSync Connection Pool to these servers (the synchronization server and the managed servers).

  7. Sync to the URL of the Synchronization Server.

  8. Refresh the data for each of the Managed Servers:

    1. From a Web browser, enter the following URL: 
      http://hostname:port-number/datasync/index.html

      Where datasync is the name of your DataSync Web application. For more information, refer to Adding DataSync in a Cluster.

    2. On the index page, click the Data Repository Browser link.

    3. In the Master Data Repository table, click the Refresh and Notify icon.

Clusters without Shared Access to Disk Containing DataSync Database Pool

If your cluster environment does not provide shared access to the disk containing the DataSync Database Pool, we require that you configure two DataSync Web applications for each cluster. You will need:

This section contains the following subsections:

For more information about Data Repositories, refer to Synchronized Data.

Deploying the Configuration DataSync Web Application

Do the following to deploy the DataSync Web application that the cluster uses for configuration purposes:

  1. In the left pane, click Deployments -> Web Applications and then click the DataSync Web application that the cluster uses for configuration purposes. For example, if you named this Web application BankAppDataConfig, click BankAppDataConfig in the left pane.

  2. On the Web application page, click the Targets tab. Then click the Clusters sub tab.

  3. Move your cluster from the Available column to the Chosen column. Then click Apply.

Deploying the Synchronization DataSync Web Application

Do the following to deploy the DataSync Web application that you use to synchronize data:

  1. In the left pane, click Deployments -> Web Applications and then click the DataSync Web application that you use to synchronize data across the cluster. For example, if you named this Web application BankAppDataSync, click BankAppDataSync in the left pane.

  2. On the Web application page, click the Targets tab. Then click the Servers sub tab.

  3. Move the Synchronization Server from the Available column to the Chosen column. Make sure that the Synchronization Server is the only server in the Chosen column. Then click Apply.

  4. Configure Proxy Data Repositories for this Web application. For more information, refer to Configuring a Proxy Data Repository.

    When you want to synchronize data for the cluster, you specify the URL of this DataSync Web application. It sends the synchronization information to its proxies, which, in turn, notify the repositories on each Managed Server.

Preventing Synchronization by Undeploying DataSync Web Applications

If changes in your production environment are infrequent and highly controlled, we recommend that after you start a Managed Server (which causes the server to synchronize its Data Repositories with the Master on the Synchronization Server or Administration Server) after you force a refresh-and-notify operation for your Managed Servers, do the following:

  1. Shut down the Managed Servers and the Administration Server.

  2. On the Administration Server, if the application is archived, expand the archive.

    In a text editor, open the application.xml file for your application and remove the declaration for the DataSync Web application. For example, in the sample wlcsApp, open PORTAL_HOME/applications/wlcsApp/META-INF/application.xml and remove the following element:
    <module>
    <web>
    <web-uri>datasync</web-uri>
    <context-root>wlcsAppDataSync</context-root>
    </web>
    </module>

  3. Re-archive the enterprise application and restart the cluster's Administration Server. Then restart the Managed Servers.

For information on forcing a refresh-and-notify operation, refer to Refreshing the Contents of Data Repositories.

Configuring Read-Write Persistence

When the DataSync Web application is deployed on the WebLogic Server Synchronization Server for a cluster (or on a single WebLogic Server instance in a single-server environment), the Master Data Repository uses a read-write JDBC Persistence Manager to read and write application data via the dataSync Data Source. The DataSync Web application that you deploy to a Managed Server reads data from the database when the server starts (or when you use the Data Repository Browser to explicitly refresh the contents). Then it stores the data in memory for use by the Managed Server. It assumes that the DataSync Web application on the Synchronization Server has already written to the database. You can modify this behavior by using the following java.lang.System properties:

Deploy Your Web Application and Other Modules to the Cluster

To deploy the remaining modules of your enterprise application, do the following:

  1. In the WebLogic Server Administration Console, in the left pane, open the Applications folder.

  2. Open the folder for the application that you configured in Configure a New Application.

  3. With the exception of the two DataSync Web applications that you deployed in the previous section, do the following for each remaining module in the enterprise application:

    1. In the left pane, select a module.

    2. In the right pane, click the Targets tab.

    3. Click the Clusters subtab.

    4. Move your cluster from the Available to the Chosen list and click Apply. (See Figure 6-5.)

      Figure 6-5 Deploy Application Modules to the Cluster


       

  4. In the left pane, under the Deployments folder, open the Startup & Shutdown folder. Do the following for each module in the Startup & Shutdown folder:

    1. In the left pane, select a module.

    2. In the right pane, click the Targets tab.

    3. Click the Clusters subtab.

    4. Move your cluster from the Available to the Chosen list and click Apply.

  5. In the left pane, click Services -> JDBC. For each data pool, data source, and transactional (Tx) data source, do the following:

    1. From the left pane, select a data pool, data source or Tx data source.

    2. In the right pane, click the Targets tab. Then click the Clusters subtab.

    3. Move your cluster from the Available list to the Chosen list and click Apply. (See Figure 6-6.)

      Figure 6-6 Deploy Connection Pools to the Cluster


       

 

Starting a Cluster

To start a cluster, complete the following tasks:

In addition, you must start the proxy server. For information on starting the proxy server, refer to the documentation for the server type that hosts the WebLogic Server plug-in.

Start the WebLogic Server Administration Console

Because the commands for setting environment variables and starting a server are long and prone to typographical errors, we recommend that you use scripts to start servers.

To create a startup script for an Administration Server, copy PORTAL_HOME/config/portalDomain/startPortal.bat (startPortal.sh on UNIX) onto the computer that hosts the Administration Server. On the target machine you can rename the file, if desired, to a more appropriate name like AdminSyncServer.bat (or .sh). You should shut down the server before creating a copy of StartPortal.bat and running the new script.

Make the following modifications:

Then run the startup script. You must start the Administration Server before the Managed Servers.

Start the Synchronization Server

Because the commands for setting environment variables and starting a server are long and prone to typographical errors, we recommend that you use scripts to start servers.

To create a startup script for a Synchronization Server, copy PORTAL_HOME/config/portalDomain/startPortal.bat (startPortal.sh on UNIX) onto the computer that hosts the Synchronization Server. On the target machine you can rename the file, if desired, to a more appropriate name like StartSyncServer.bat (or .sh). Then make the following modifications:

Then run the startup script. You must start the Synchronization Server before the Managed Servers.

Start the Managed Servers

To create a startup script for a Managed Server, copy PORTAL_HOME/config/portalDomain/startPortal.bat (startPortal.sh on UNIX) onto the computer that hosts the Managed Server. On the target machine you can rename the file, if desired, to a more appropriate name like StartManagedServer.bat (or .sh). Then make the following modifications on each computer:

For example, add the following variables to the startup script for each Managed Server:

 
SET DOMAIN_NAME=portalDomain
SET SERVER_NAME=ClusterNode1
SET ADMIN_SERVER=192.168.33.137:7501
SET ADMIN_SERVER_USERNAME=system
SET ADMIN_SERVER_PASSWORD=weblogic

And then use these variables in the startup command:

 
%JDK_HOME%/bin/java %JAVA_VM% -Xms128m -Xmx128m -classpath %CLASSPATH% -Dcloudscape.system.home=%WL_PORTAL_HOME%/db/data -Dweblogic.Domain=%DOMAIN_NAME% -Dweblogic.Name=%SERVER_NAME% -Dbea.home=%BEA_HOME% -Dweblogic.management.server=%ADMIN_SERVER% -Dweblogic.management.username=%ADMIN_SERVER_USERNAME% -Dweblogic.management.password=%ADMIN_SERVER_PASSWORD% -Djava.security.policy==%WEBLOGIC_HOME%/lib/weblogic.policy -Dcommerce.properties=%PORTAL_HOME%/weblogiccommerce.properties -Dpipeline.properties=%PORTAL_HOME%/pipeline.properties -Dwebflow.properties=%PORTAL_HOME%/webflow.properties weblogic.Server

Then run the startup script.

For more information about starting Managed Servers, refer to "Starting a WebLogic Managed Server" under "Starting and Stopping WebLogic Servers" in the WebLogic Server Administration Guide.

Refresh Data Repositories on Managed Servers

If you want to refresh the contents of the Data Repositories on the Managed Servers and cause subordinate repositories to refresh their contents, do the following on the Synchronization Server:

  1. From a Web browser, enter the following URL:

    http://hostname:port-number/datasync/index.html

    Where datasync is the name of your DataSync Web application. For more information, refer to Adding DataSync in a Cluster.

  2. On the index page, click the Data Repository Browser link.

  3. In the Master Data Repository table, click the Refresh and Notify icon.

    Figure 6-7 Refresh and Notify


     

 

Test Cluster and Application for Failover

To verify that the cluster supports the replication of session data, deploy one of the reference applications onto your cluster. Then access the reference application using the listen port of your proxy server and log in as a sample user. Kill the Managed Server that contains your current session and verify that the session data is available from another Managed Server.

To verify that your application's data is safe in a failover situation, we recommend the following testing methods as a supplement to testing with a multi-node cluster:

 

back to top previous page next page

 

Copyright © 2001 BEA Systems, Inc. All rights reserved.
Required browser: Netscape 4.77 or higher, or Microsoft Internet Explorer 5.0 or higher.
Contact us (documentation feedback only)