11/8/11

Clustering for your portal: WebSphere Portal Server

Clustering for your portal

This section provides information about setting up your portal in a WebSphere domain, or cluster. Also, information about workload management is provided. Read all information and follow the instructions to ensure that successfully configure your portal within a clustered environment. Overview Modeling and cloning: main example Modeling and cloning: additional examples Adding a reverse proxy server

Overview
Cluster refers to a WebSphere domain in which the components of WebSphere Application Server run. This section provides information to help you manage the workload associated with WebSphere Portal Server as it runs in a cluster. Some knowledge of WebSphere distribution and load balancing is required to perform the steps in this section. Before performing the steps in this section, it is recommended that you consult the following documentation for details about workload management concepts associated with WebSphere Application Server: IBM Redbook WebSphere Scalability: WLM and Clustering Using WebSphere Application Server Advanced Edition SG24-6153-00 WebSphere Application Server InfoCenter, specifically sections about distribution, load balancing, and workload management

Modeling and cloning: main example

A model is a template for creating copies of a server or process instance, such as an application server like WebSphere Portal Server. The copies are called clones, and the act of creating the clones is called cloning. In horizontal scaling, clones are defined on multiple machines in a system. This allows WebSphere Portal Server to run on several machines while presenting a single system image. Client requests that overwhelm a single machine can be distributed over several machines in the system. If a machine becomes unavailable, its work can be routed to other machines that contain clones. The following steps provide detailed information about how to set up your WebSphere Portal Server by modeling and cloning. Step 1: Set up machine A as a database server Step 2: Install WebSphere Portal Server and create a model on machine B Step 3: Configure and create clones on machine C Step 4: Configure HTTP server and plug-ins Step 5: Configure Network Dispatcher on machine D Use the following figure as a guide for the main example of modeling and cloning that is presented in this section.

www-01.ibm.com/software/genservers/portal/library/v12/InfoCenter/wps/inst_clo.html

1/7

11/8/11

Clustering for your portal: WebSphere Portal Server

Note: The following instructions are for a standard installation of WebSphere Portal Server. Step 1: Set up machine A as a database server Do the following: 1. Note the LDAP root and suffix. The default settings for WebSphere Portal Server are cn=root and dc=yourco,dc=com. 2. Create the WebSphere Application Server database (for example: WAS) as the shared administrative repository. 3. Create a back-end database for the storage of HTTP-session information that WebSphere Portal can access. This database is often referred to as a persistent session store. 4. Create the WebSphere Portal Server database (for example: WPS) for portal data. Step 2: Install WebSphere Portal Server and create a model on machine B Do the following: 1. Install the required prerequisites for WebSphere Portal Server, this includes IBM HTTP Server, WebSphere Application Server, and the required e-fixes and .jar files. During the WebSphere Application Server installation, point to the WebSphere Application Server database on machine A. Start the Admin Server. 2. Install WebSphere Portal Server. During the installation, make sure you do the following: Select a standard installation. Use the LDAP directory on machine A. Use the WebSphere Portal Server database on machine A. 3. Use the WebSphere Administrative Console to configure the WebSphere Portal Server servlet engine to INET sockets. Do the following: a. Start the Administrative Console. b. In the left panel, click node name - WebSphere Portal Server - WPS Servlet Engine.

www-01.ibm.com/software/genservers/portal/library/v12/InfoCenter/wps/inst_clo.html

2/7

11/8/11

Clustering for your portal: WebSphere Portal Server

c. In the right panel, click the Advanced tab and then click the Settings button. The Edit Servlet Engine Transport window displays. d. Click the arrow for the drop-down menu beside Transport type, and select INET Sockets. e. Click OK and then Apply to apply the changes. Note: Changes will not take effect until the WebSphere Portal Server and HTTP Server are restarted. 4. Create Datasource for session persistence and point to the session database on machine A. For instructions on creating Datasources, see the WebSphere Application Server documentation. 5. Set the WLM policy. For more information, see the WebSphere Application Server documentation. 6. Share the WebSphere Portal Server directory structure for machine C to acquire and share the /DeployedPortlets directory. 7. Create model of WebSphere Portal Server application server. At this point, multiple clones can be installed on machine B (vertical scaling). Follow the security steps in WebSphere Application Server for each clone on machine B. Step 3: Configure and create clones on machine C Do the following: 1. Install the required prerequisites for WebSphere Portal Server, this includes IBM HTTP Server, WebSphere Application Server, and the required e-fixes and .jar files. During the WebSphere Application Server installation point to the WebSphere Application Server database on machine A. Start the Admin Server. 2. Acquire the WebSphere Portal Server directory from machine B. Mimic the directory structure on machine B (machine B portal root=machine C portal root=c:\websphere\portalserver) 3. Modify <wps_root>/app/web/WEB_INF-conf/WPSResources.properties. Change URILookup.webappbasedir.uri=<machineB_host_name> to URILookup.webappbasedir.uri=<cluster_name> Change application.repository.dir=c:/WebSphere/PortalServer/app/DeployedPortlets to application.repository.dir=x:/WebSphere/PortalServer/app/DeployedPortlets, where x: is a mapped network drive to the machine B portal root. 4. Clone the WebSphere Portal Server application server onto machine C. 5. In the WebSphere Administrative Console, edit the WPS Enterprise Application to include the newly-cloned Enterprise JavaBeans: User, PageInstance, Component Instance, PortletInstance, ComponentDescriptor, and PortletDescriptor. (If you installed WebSphere Personalization, other enterprise beans might be required.) Do the following: a. b. c. d. e. f. g. Click Console - Tasks - Edit Application Enterprise. Click to expand the Enterprise Applications folder. Click WPS Enterprise Application and then click Next to continue. Click to expand Enterprise Beans. Select an enterprise bean and click Add. Click Next. Click Finish.

6. In the WebSphere Administrative Console, configure the security for the cloned enterprise beans. Do the following: a. Click Console - Tasks - Configure Resource Security. b. Click to expand Enterprise Beans and select a cloned enterprise bean. c. Click Next to continue. Note: If a window displays that asks you to use default method groups, click

www-01.ibm.com/software/genservers/portal/library/v12/InfoCenter/wps/inst_clo.html

3/7

11/8/11

Clustering for your portal: WebSphere Portal Server

d. e. f. g. h. i.

Yes and continue. In the Methods groups window, select all folders and click Add. A smaller Methods groups window displays. Expand the Method Groups folder and click EJB_OpenForEveryoneMethod and click OK. Click Next in the Resources window and the Delegation window displays. Click to the drop-down arrow under the Run-As Mode field to select SYSTEM. Click Finish. Repeat the preceding steps (a through h) for each cloned enterprise bean. Important: In the Delegation window, you must click Finish for each bean for which you configure security.

7. Install the wpsJDBC driver and any other dependent JDBC drivers on the new node. Other JDBC drivers might include the one for the persistent session database. In the WebSphere Administrative Console, rightclick wpsJDBC, and click Install. Follow the instructions on screen to install the driver. 8. Repeat steps 4-7 for other cloned machines. Step 4: Configure HTTP server and plug-ins After all models have been added and the model has been started, do the following on all nodes: 1. Run OSERemoteConfig to allow the HTTP server to run on a separate machine and send requests to application servers running on remote machines. OSE supports clustering and workload management of application servers. Run <was_root>\bin\OSERemoteConfig -serverRoot <was_root> adminNodeName <current_node>. Running OSERemoteConfig writes <was_root>temp\queues.properties to allow every HTTP server to WLM between all models and all clones. 2. If your HTTP server runs on the WebSphere Application Server machine, you can configure the bootstrap.properties so that you do not have to run OSERemoteConfig again if a model restarts or if the administrative server restarts. Do the following: a. Create a new directory such as <was_root>\tmp4was. b. Copy the properties files (queue.properties, rules.properties, and vhost.properties) to the <was_root>\tmp4was directory. c. Make a copy of the <was_root>\properties\bootstrap.properties file (for example, bootstrap1.properties). d. Modify the ose.tmp.dir entry in the original bootstrap.properties file to point to the new directory. For example: /usr/WebSphere/AppServer/tmp4was. e. Stop and start the WebSphere Administrative Servers. Now you have to run the OSERemoteConfig script only if you modify some configuration data. You have to copy the files after you create them with OSERemoteConfig. Note: If you do not configure bootstrap.properties as described in the preceding steps, you must run OSERemoteConfig again if a model restarts, or if the administrative server restarts. 3. Restart the HTTP Server. Step 5: Configure Network Dispatcher on machine D Network Dispatcher is a standard component of WebSphere Edge Server. By default, Network Dispatcher distributes the client requests among all available servers in a round-robin fashion as each server in the cluster gets the next request in turn. For the following example, the round-robin concept is used. To configure Network Dispatcher, do the following: 1. Modify <wps_root>/app/web/WEB_INF-conf/WPSResources.properties on machines B and C. Change URILookup.webappbasedir.uri=<host_name> to URILookup.webappbasedir.uri= <cluster_name> 2. Configure Network Dispatcher to include the host names of all WebSphere Portal Server machines. 3. Modify the default host alias list to include the IP and host name for the cluster.

www-01.ibm.com/software/genservers/portal/library/v12/InfoCenter/wps/inst_clo.html

4/7

11/8/11

Clustering for your portal: WebSphere Portal Server

4. Restart all application servers (model-clones). 5. Run OSERemoteConfig against all WebSphere Portal Server machines. See the description in the preceding section. 6. Restart each Web server. 7. Access the WebSphere Portal Server using the cluster host name. At this point, all WebSphere Portal Server requests directed to the cluster host name (the machine on which Network Dispatcher is running) are redirected to all the Web servers in turn. Note: In this type of configuration, the Web server receiving your request might not be the machine that services the request. The WebSphere Application Server plug-in determines which WebSphere Portal Server clone will do that.

Modeling and cloning: additional examples

The steps in the main example show one possible solution for setting up WebSphere Portal Server in a clustered environment. By modifying some steps in the main example, you can also cluster WebSphere Portal Server. Alternate example 1 1. Install WebSphere Portal Server on machine B and copy the portal directory and all resources to machine C. 2. Copy the following files from machine B to machine C: <was_root>/lib/personalization.jar <was_root>/jdk/jre/lib/ext/jaas.jar <was_root>/jdk/jre/lib/security/java.security <was_root>/deployedEJBs/Deployedum.jar <was_root>/deployedEJBs/Deployedcm.jar <was_root>/deployedEJBs/Deployedpm.jar 3. Continue with the steps from the main example for machine C. Alternate example 2 The following steps explain how to set up WebSphere Portal Server machines in a clustered environment with requests being sent to the cluster by Network Dispatcher. In this example, clustering is implemented without modeling and cloning across nodes, and each node requires its own separate administration. Steps from the main example are referenced. 1. Configure machine A as a database server and LDAP machine, (described above) with one exception: create separate WebSphere Application Server databases for machine B and machine C. Both machine B and machine C will share the same WebSphere Portal Server and persistent session databases. 2. Model the WebSphere Portal Server and clone it onto itself (also known as vertical cloning). Note: In this setup, the model and clones on one node do not know that models and clones exist on other nodes. 3. Install WebSphere Portal Server and its prerequisites on all machines in the cluster. 4. Update the virtual host (default_host) alias list for machine B and machine C to include their own host name as well as the cluster host name (the dispatcher). 5. Modify <wps_root>/app/web/WEB_INF-conf/WPSResources.properties on machine B and machine C. Replace URILookup.webappbasedir.uri=<host_name> with: URILookup.webappbasedir.uri= <cluster_name> 6. Configure Network Dispatcher to include the host names of all the WebSphere Portal Server machines in the cluster: in this example, that would be machine B and machine C. 7. Make WebSphere Portal Server requests using the cluster host name. At this point, all Websphere Portal requests directed to the cluster host name (the dispatcher) are redirected to all the Web servers in turn (determined by the manner in which you have configured your dispatcher). Unlike the scenario above which employs horizontal cloning, the Web server that receives the request from the dispatcher

www-01.ibm.com/software/genservers/portal/library/v12/InfoCenter/wps/inst_clo.html

5/7

11/8/11

Clustering for your portal: WebSphere Portal Server

will always be the machine that services it. Consult your WebSphere Application Server guides for instructions on letting your dispatcher know if a WebSphere Application Server appserver is unavailable to service a request.

Adding a reverse proxy server

Use the following figure as a guide for the information about adding a reverse proxy server to a cluster.

For the configuration in the preceding figure, note the following: All client requests go through machine D, and it sends the requests through to the cluster. However, you can have only one proxy rule to match the /* requested URI. After the proxy requests a WebSphere Portal Server resource to machine B, the plug-in for machine B will round robin the request between the application servers on machine B and machine C. Additional Workload Management (WLM) could be accomplished by pointing the reverse proxy to a dispatcher machine. You only have to run OSERemoteConfig on machine B because the Web server on machine C will never receive a request. Modify <wps_root>\app\web\WEB_INF\conf\WPSResources.properties: change URILookup.webappbasedir.uri=<current_host_name> to URILookup.webappbasedir.uri=<machineD_host_name> on every WebSphere Application Server machine, in this case, machine B and machine C.

Related information Planning Installing

www-01.ibm.com/software/genservers/portal/library/v12/InfoCenter/wps/inst_clo.html

6/7

11/8/11

Clustering for your portal: WebSphere Portal Server

www-01.ibm.com/software/genservers/portal/library/v12/InfoCenter/wps/inst_clo.html

7/7