·A step-by-step guide to configuring a WebSphere Portal V5 cluster Belinda Yu Software Engineer, WebSphere Portal Marshall Lamb Chief Programmer for WebSphere Portal V5 January, 2004 © Copyright International Business Machines Corporation 2004. All rights reserved.
Table of contents Introduction ................................................................................................................................................. 3 About the example environment ................................................................................................................. 3 Before you begin ......................................................................................................................................... 4
Allocating hard disk for WebSphere Portal nodes .................................................................................. 4 Installing the environment components ...................................................................................................... 5
Preparing the DB2 server and clients...................................................................................................... 5 Installing WebSphere Portal.................................................................................................................... 7 Configuring the first WebSphere Portal node for DB2........................................................................... 8 Configuring WebSphere Portal security ................................................................................................. 9 Configuring WebSphere Portal with an external Web server ............................................................... 11 Network Deployment ............................................................................................................................ 12
Building a cell ........................................................................................................................................... 12 Building a cluster ...................................................................................................................................... 14
Install WebSphere Portal on WP02....................................................................................................... 15 Add WP02 into the cell ......................................................................................................................... 16 Add WP02 into the cluster .................................................................................................................... 16 Update Web Server plugin .................................................................................................................... 17 Update DeploymentServices.properties............................................................................. 17 Start the cluster...................................................................................................................................... 18
Session persistence.................................................................................................................................... 18 Create a database to store session data.................................................................................................. 18 Create JDBC provider for session database .......................................................................................... 18 Enable session on WebSphere Portal application server ...................................................................... 20
Hints and tips............................................................................................................................................. 21 Portlet deployment .................................................................................................................................... 22 Manually synchronizing nodes with Deployment Manager ..................................................................... 23 Conclusion................................................................................................................................................. 23 About the authors ...................................................................................................................................... 23
IBM, the 8-bar IBM logo, WebSphere and DB2 are trademarks or registered trademarks of International Business Machines Corporation in the United States and/or other countries.
UNIX is a trademark or registered trademark of Open Group Ltd. in the United States and/or other countries.
Java is a trademark or registered trademark of Sun Microsystems Corporation in the United States and/or other countries.
Introduction This document is for portal administrators and others who want to create an IBM® WebSphere® Portal cluster for failover and scalability support, especially for a production environment. The reader should be familiar with the standalone installation and configuration of IBM WebSphere Portal Version 5.0 (hereafter called WebSphere Portal). IBM WebSphere Application Server Version 5 (hereafter called Application Server) introduced the concept of a managed cell. The configuration and application binaries of all nodes in the cell are centralized into a cell master configuration repository managed by a central server called Deployment Manager, new to Application ServerV5. If you are familiar with Application Server V4, you know that in order to run the application, you need to copy and expand the application binaries on all the nodes on which the application was installed . When you deploy or update portlets in aWebSphere Portal V4 cluster, you need to copy portlet directories from the main node to all other clone nodes. In Application Server V5, the application binaries of all components in the cell are synchronized with each node in a distributed topology. Also, Application Server V5 no longer has server group and clone functionality, which was available in version 4. A WebSphere V5 cluster is a grouping of separately configured nodes all of which host the same application server. Nodes that belong to a cluster are called cluster members. About the example environment This guide shows you how to configure a cluster consisting of: • Two WebSphere Portal V5 nodes, called WP01 and WP02 • A database server, in this case, DB2®, which contains the WebSphere Portal, WebSphere Member
Manager, and WebSphere Portal content publishing databases • A single Web server, IBM HTTP Server V1.3 • The LDAP server, in this case IBM Directory Server V5.1 • The Deployment Manager, which is installed from the Application Server V5 Network Deployment
package In this example scenario, WP01 and WP02 are UNIX® systems, and the backend data storage is DB2. The Data item represents various databases, which are set up by WebSphere Portal: • WPS50 - portal configuration database • WMM50 - user profile repository • WPCP50 - content publisher repository • FDBK50 - page visitation and personalization analysis feedback database • Session - session persistance database, for failover purposes
Figure 1. Example cluster environment
The request flows like this: 1. Browser request goes to the HTTP Web Server. 2. The Application Server plugin within the HTTP Web Server dispatches the request to an available
WebSphere Portal application server (WP01 or WP02). If this is a subsequent request to portal, the same WebSphere Portal application server is used for this request as was used for the prior request.
3. WebSphere Portal looks up the user context information from IBM Directory Server. 4. WebSphere Portal looks up the page layout, portlet configuration, and user access permissions from
the portal databases. 5. WebSphere Portal constructs the page, invokes the appropriate portlets, and the output is returned
through the HTTP Web Server back to the client. 6. In parallel to this request processing, Deployment Manager is used to maintain the WebSphere
Portal application servers themselves (start, stop, application deployment, and so on). Before you begin Before you install and configure the environment, you need to do a little planning. Allocating hard disk for WebSphere Portal nodes You need to have enough disk space to support two portal configurations. The reason is that you can remove a WebSphere Portal node from the cell using the removeNode command, and the WebSphere Portal server will be restored to its fully functional standalone state on the node. In order for this action to execute successfully, enough free hard drive space is required to support the active and backed-up configuration. The easiest way to determine what space you need is, after installing WebSphere Portal
V5 and Application Server V5 on a system, determine how much space the <was_root>/config directory requires and double it, allowing for a complete backup of that directory to exist.
Installing the environment components This section covers setting up the environment for WebSphere Portal, in prepartions for building a cluster from WebSphere Portal nodes. It covers setting up a shared database, installing WebSphere Portal, setting up security, setting up an external Web server used by each of the portal nodes, and finally installing Deployment Manager if it has not already been done. Preparing the DB2 server and clients First, you create the databases required by WebSphere Portal on the DB2 server. 1. On the DB2 server machine, enter the following commands to create the WebSphere Portal
database: $ db2 create database wps50 using codeset UTF-8 territory us $ db2 update database configuration for wps50 using applheapsz 16384 app_ctl_heap_sz 8192 $ db2 update database configuration for wps50 using stmtheap 60000 $ db2 update database configuration for wps50 using locklist 400 $ db2 update database configuration for wps50 using indexrec RESTART $ db2 update database configuration for wps50 using logfilsiz 1000 $ db2 update database configuration for wps50 using logprimary 12 $ db2 update database configuration for wps50 using logsecond 10 $ db2set DB2_RR_TO_RS=yes
2. If you are not planning to share the WebSphere Member Manager database with the WebSphere
Portal Server database, then enter the following commands to create the WebSphere Member Manager database: $ db2 create database wmm50 using codeset UTF-8 territory us $ db2 update database configuration for wmm50 using applheapsz 16384 app_ctl_heap_sz 8192 $ db2 update database configuration for wmm50 using stmtheap 60000 $ db2 update database configuration for wmm50 using locklist 400 $ db2 update database configuration for wmm50 using indexrec RESTART $ db2 update database configuration for wmm50 using logfilsiz 1000 $ db2 update database configuration for wmm50 using logprimary 12 $ db2 update database configuration for wmm50 using logsecond 10 $ db2set DB2_RR_TO_RS=yes
3. Enter the following commands to create the WebSphere Portal content publishing databases:
$ db2 create database wpcp50 using codeset UTF-8 territory us collate using identity $ db2 create database fdbk50 using codeset UTF-8 territory us collate using identity $ db2 update database configuration for wpcp50 using applheapsz 4096 $ db2 update database configuration for fdbk50 using applheapsz 4096 $ db2 update database configuration for wpcp50 using logfilsiz 4096 $ db2 update database configuration for fdbk50 using logfilsiz 4096 $ db2 update database configuration for wpcp50 using logprimary 4 $ db2 update database configuration for fdbk50 using logprimary 4 $ db2 update database configuration for wpcp50 using logsecond 25 $ db2 update database configuration for fdbk50 using logsecond 25
You must ensure that the DB2 client is installed and operational on both WebSphere Portal systems, WP01 and WP02. Furthermore, the DB2 client instance must match the instance name of the DB2 server. For example, if the server instance that you connect to is db2inst1, then the DB2 client instance that you create on both WP01 and WP02 must also be db2inst1.
On the DB2 server machine: 1. Open the /etc/services file in a text editor. If it does not specify DB2 connection and interrupt
service ports, add the following to specify the ports: db2cdb2inst1 50000/tcp # DB2 connection service port db2icdb2inst1 50001/tcp # DB2 interrupt service port
where db2inst1 is the name of the DB2 server instance
2. Set DB2COMM to TCP/IP using the db2set command:
$db2set DB2COMM=TCPIP
3. Set up the correct service name by entering the following command:
$ db2 UPDATE DBM CFG USING svcename svce_name
where svce_name is db2cdb2inst1, in this example On the DB2 client machine: 1. To export the DB2 instance environment in your profile:
a. In your .bashrc, .dshrc, or .profile file, add if [ -f /home/db2inst1/sqllib/db2profile ]; then /home/db2inst1/sqllib/db2profile; fi
where db2inst1 represents your database instance.
b. Reopen all the shells.
c. Validate that your environment has set the DB2 profile environment variables, by running this command in the shell: env
If you see DB2INSTANCE=db2inst1 where db2inst1 represents your database instance, that means DB2 environment has been set up in your system.
2. Open the /etc/services file in a text editor. If it does not specify the DB2 connection service
port, add the following text to specify the port for the DB2 server instance:
db2cdb2inst1 50000/tcp # DB2 connection service port
where db2cdb2inst1 is the name of the DB2 server instance. The connection service port on the DB2 client must match the connection service port on the DB2 server.
3. Set DB2COMM to TCP/IP by using the db2set command, as follows:
$ db2set DB2COMM=tcpip
4. Catalog the TCP/IP node with the IP address of the remote database server, as follows: $ db2 catalog tcpip node was_node remote database_server_node server connection_service_port
where, in this example: was_node is the DB2 server host name database_server_node is the fully qualified host name of your database server machine connection_service_port is db2cdb2inst1
5. To catalog the WebSphere Portal, WebSphere Member Manager and content publishing
databases, enter: $ db2 catalog db wps50 as wps at node was_node $ db2 catalog db wmm50 as wmm at node was_node $ db2 catalog db wpcp50 as wpcp at node was_node $ db2 catalog db fdbk50 as fdbk at node was_node
where: wps50, wmm50, wpcp50, and fdbk50 are the names of the WebSphere Portal, WebSphere Member Manager, and WebSphere Portal content publishing databases on the server machine wps, wmm, wpcp and fdbk are the database alias names that you are defining on the DB2 client machine was_node is the node name used previously
Installing WebSphere Portal Before installing WebSphere Portal on the first node, see the WebSphere Portal InfoCenter to make sure your systems meet the minimum hardware and software requirements, and to get additional information or procedures that you may need. You need to install a set of fixes to WebSphere Portal. If you install WebSphere Application Server with the WebSphere Portal installation program, a subset of the fixes are installed for you; you must install the others manually. See the Planning -> Supported hardware and software section of the WebSphere Portal InfoCenter for details. Now, on WP01, launch the WebSphere Portal installer to install WebSphere Portal. After the installation is finished, WebSphere Portal is up and running with the Cloudscape database. It uses the
internal HTTP transport within WebSphere Application Server to handle requests, and it runs without security enabled.
Configuring the first WebSphere Portal node for DB2 The next step is to transfer the backend storage to a database with greater capability. In this example scenario, you use DB2. First, export data from the Cloudscape database: 1. In the command prompt, change to the <wp_root>/config directory . 2. Enter this command:
./WPSconfig.sh database-transfer-export
Next, import the data into the DB2 database: 1. In the command prompt, change to the <wp_root>/config directory . 2. Make a backup copy of the wpconfig.properties file. 3. Modify the wpconfig.properties file by entering the values appropriate for your environment, as
illustrated in the example in Listing 1.
Listing 1. Example wpconfig.properties file - database section # Database Properties – BEGIN
DbSafeMode=false DbType=db2 WpsDbName=wps cswps.jdbc.schema.names=db2admin,FEEDBACK,PZNADMIN,EJB,wcmdbadm DbDriver=COM.ibm.db2.jdbc.app.DB2Driver DbDriverDs=COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource JdbcProvider=wps50JDBC DbUrl=jdbc:db2:WPS # DbUser: The database administrator user ID DbUser=db2inst1 # DbPassword: The database administrator password DbPassword=ibmdb2 DbLibrary=/home/db2inst1/sqllib/java12/db2java.zip WpsDsName=wps50DS WpsDbNode=srvname # PORTAL INFO SEQUENCE # WPCP Database Properties – BEGIN
WpcpDbNode=srvname WpcpDbName=wpcp # WpcpDbUser: The database user for WPCP WpcpDbUser=db2inst1 # WpcpDbPassword: The database password for WPCP WpcpDbPassword=ibmdb2 WpcpDbUrl=jdbc:db2:wpcp # FeedbackDbName: The name of the feedback database. FeedbackDbName=fdbk
# FeedbackDbUser: The database user for feedback database. FeedbackDbUser=db2inst1 # FeedbackDbPassword: The database password for feedback database. FeedbackDbPassword=ibmdb2 FeedbackDbUrl=jdbc:db2:fdbk # WPCP Database Properties – END # WPCP Additional Properties – BEGIN
WpcpWorkflow=liteWF # WPCP Additional Properties – END # WMM Properties – BEGIN
WmmDsName=wmmDS WmmAppName=wmmApp WmmDbName=wmm # WmmDbUser: The database administrator user ID WmmDbUser=db2inst1 # WmmDbPassword: The database administrator password WmmDbPassword=ibmdb2 WmmDbUrl=jdbc:db2:wmm WmmEjbName=ejb/MemberServiceHome # WMM Properties – END
4. Enter the following commands to validate your DB2 properties and values in the
wpconfig.properties file :
validate existence of and access right to WPS database ./WPSconfig.sh validate-database-connection-wps
validate existence of and access right to WMM database ./WPSconfig.sh validate-database-connection-wmm
validate existence of and access right to WPCP database ./WPSconfig.sh validate-database-connection-wpcp
validate the database driver ./WPSconfig.sh validate-database-driver
5. Enter the following commands to import the data into DB2 databases
./WPSconfig.sh database-transfer-import
Configuring WebSphere Portal security This document will use IBM Directory Server as the LDAP server managing user and group definitions. First, ensure that the LDAP software is installed and any LDAP setup required by WebSphere Portal has been performed. Refer to the WebSphere Portal InfoCenter for detailed requirements and setup instructions. Then, to configure WebSphere Portal for IBM Directory Server:
1. Change to the <wp_root>/config directory .
2. Make a backup copy of the wpconfig.properties file. 3. Modify the wpconfig.properties file by entering the values appropriate for your environment, as
illustrated in Listing 2. Listing 2. Example wpconfig.properties file – LDAP configuration section # LDAP Properties Configuration – BEGIN
LookAside=false LDAPHostName=ldapserver..raleigh.ibm.com LDAPPort=389 LDAPAdminUId=cn=root LDAPAdminPwd=ldappwd LDAPServerType=IBM_DIRECTORY_SERVER LDAPBindID=uid=wpsbind,cn=users,o=wps LDAPBindPassword=wpsbind # LDAP Properties Configuration – END
# Advanced LDAP Configuration – BEGIN
LDAPSuffix=o=wps LdapUserPrefix=uid LDAPUserSuffix=cn=users LdapGroupPrefix=cn LDAPGroupSuffix=cn=groups LDAPUserObjectClass=inetOrgPerson LDAPGroupObjectClass=groupOfUniqueNames LDAPGroupMember=uniqueMember LDAPGroupMinimumAttributes= LDAPUserBaseAttributes=givenName,sn,preferredLanguage LDAPUserMinimumAttributes= LDAPsearchTimeout=120 LDAPreuseConnection=true LDAPIgnoreCase=true LDAPsslEnabled=false # Advanced LDAP Configuration – END
4. To validate your LDAP properties and values in the wpconfig.properties file, enter:
./WPSconfig.sh validate-ldap
./WPSconfig.sh stop-portal-server
6. To configure security with WebSphere Application Server, WebSphere Portal, and WebSphere
Member Manager, enter: ./WPSconfig.sh enable-security-ldap
7. To cause after the security changes to take effect:
a) Stop WebSphere Application Server ./WPSconfig.sh stop-admin-server
b) Start WebSphere Application Server ./WPSconfig.sh start-admin-server
c) Start WebSphere Portal ./WPSconfig.sh start-portal-server
Tip: These tasks script the WebSphere Application Server stopServer and startServer commands for manipulating the Application Server state. They are used instead of stopServer and startServer so you do not have to change directories between steps.
8. To verify security:
a) WebSphere Application Server
Using a browser, open the following URL. You are prompted with a login form asking for a user ID and password. This means that application server authorization is enabled appropriately. http://<your_web_server>:9090/admin
Depending on the configuration of your Application Servers, the port used to access the Administration Console may be different than the default of 9090.
b) WebSphere Portal and WebSphere Member Manager
Using a browser, access WebSphere Portal and login as an admin user. Select Administration - > Access -> Users and Groups, and then All Authenticated Portal Users. You see the users that have been defined for WebSphere Portal access in your LDAP server.
Configuring WebSphere Portal with an external Web server First, ensure that the Web server software is installed and functional. Second, install the WebSphere Application Server Web server plug-in. Refer to WebSphere Portal InfoCenter for detailed instructions. Ensure you can access WebSphere Application Server through the Web server before you continue. Then, to configure WebSphere Portal for a remote Web server: 1. In a console window, change to the <wp_root>/config directory . 2. Make a backup copy of the wpconfig.properties file. 3. Modify the wpconfig.properties file by entering values appropriate for your environment, as
illustrated in this example:
# WpsHostName: The name of the WebSphere Portal host WpsHostName=<web_server_fully_qualified_hostname>
# WpsHostPort: The port used by WebSphere Portal WpsHostPort=80
4. Enter the following command to configure WebSphere Portal with the external Web server:
./WPSconfig.sh httpserver-config
5. Copy the <was_root>/config/cells/plugin-cfg.xml file from the WebSphere Portal machine to the remote Web server machine. Make sure you copy the file to the same directory on the remote machine.
6. Stop and start the Web server. 7. To make the configuration changes take effect, change to the <wp_root>/config directory, then do
the following: A. Stop WebSphere Application Server
./WPSconfig.sh stop-admin-server B. Start WebSphere Application Server
./WPSconfig.sh start-admin-server C. Stop WebSphere Portal
./WPSconfig.sh stop-portal-server
D. Start WebSphere Portal ./WPSconfig.sh start-portal-server
To verify you can access WebSphere Portal from the remote Web server, open this URL in a Web browser: http://< your_web_server_fully_qualified_hostname >:80/wps/portal
Network Deployment So far, you have: • Configured WebSphere Portal using DB2 as the backend data store • Enabled security for WebSphere Application Server, WebSphere Member Manager and WebSphere
Portal using LDAP • Enabled access to WebSphere Portal through a remote Web server The next step, if you have not done so already, is to install WebSphere Application Server Deployment Manager (hereafter called Deployment Manager) on a dedicated system. See the WebSphere Portal InfoCenter for setup instructions. After Deployment Manager is running and functional, you must configure it with the same security settings as WebSphere Portal. See the WebSphere Application Server V5.0 InfoCenter for details on configuring security for Deployment Manager. While configuring security for Deployment Manager, make sure you enable Global Security, but do not enable Java2 security. Java2 security is automatically set when you check the Enabled box. Make sure you un-check the Java2 security checkbox before saving your work. You must add those Portal users and groups, which you wish to authorize for portlet deployment, as console users and groups in Deployment Manager. In Deployment Manager’s Administration Console, expand System Administration -> Console Users to add a console user. Use a similar procedure to add groups. Building a cell
Before you add the first node WP01 into a cell that is managed by Deployment Manager, you need to update the following script files to increase the maximum heap size for the Java™ commands used in processing these commands. 1. In a console window, change to the <was_root>/bin directory . 2. Make a backup copy of addNode.sh and removeNode.sh. 3. Add the -Xmx512m option to the Java command used in each script. Make sure you update both
addNode.sh and removeNode.sh scripts. A sample is provided below.
"$JAVA_H”ME"/bin/java \ -Xmx512–m -Xbootclasspath”p:"$WAS_BOOTCLASSP”TH" \
4. Add WP01 to Deployment Manager by entering the following command in one line:
./addNode.sh <deployment_manager_host> <deployment_manager_port> -username <admin_user_id> -password <admin_password> -includeapps where:
o <deployment_manager_host> is the Deployment Manager host name. o <deployment_manager_port> is the Deployment Manager SOAP connector-address. The
default value is 8879. o <admin_user_id> is the WebSphere Application Server administrative user name. o <admin_password> is the administrative user password. o Parameters: -includeapps transfers the complete set of applications installed on a node
into the Deployment Manager's master configuration. You must use the -includeapps parameter on the first node, and only the first node.
5. To uninstall the WpsAdminconsole application:
a. In the Deployment Manager’s Administration Console, expand Applications, and select
Enterprise Applications b. Find the WpsAdminconsole application. c. Select to uninstall that application. d. Make sure the Synchronize changes with nodes checkbox is checked when saving your
changes.
6. Define the HTTP port.
Make sure the Web server hostname and port value are defined in the Virtual Host definitions for WebSphere Portal access. a. In Deployment Manager’s Administration Console, expand Environment, and select Virtual
Hosts. b. Select default_host, and then select Host Aliases. c. If your Web server port is not defined in the list, you need to add it. Click on New, and define
your Web server name as the host name (or use the wildcard * to represent any host name), and give your Web server port value.
d. Make sure the Synchronize changes with nodes checkbox is checked when saving your changes.
7. Update Web Server plugin.
a. If you have added entries to Virtual Hosts using the Deployment Manager’s Administration Console, you need to update the Web server plugin. Expand Environment, then select Update Web Server Plugin.
b. You can find the generated plugin-cfg.xml file in the <Deployment_Manager>/config/cells directory. If the Deployment Manager and the Web server are running in different operating systems, you must change the paths in plugin-cfg.xml to match the Web server’s target platform.
c. Then, copy the plugin-cfg.xml file from the Deployment Manager machine to the remote Web server machine. The default directory is <was_root>/config/cells on the remote machine.
d. Finally, restart the Web server for the changes to take effect.
At this point, you have federated a node with WebSphere Portal applications installed into a cell that is managed by Deployment Manager. In Deployment Manager’s Administration Console, you can view WebSphere Portal by expanding Servers, and then select Application Servers. Building a cluster Now you are ready to create the cluster. 1. In the Deployment Manager’s Administration Console, expand Servers, Cluster, and then select
New to create a cluster.
2. Enter the basic cluster information: a. Define the cluster name. b. Check the box Prefer local enabled. c. Check the box Create Replication Domain for this cluster. d. Select the option Select an existing server to add to this cluster and then choose server
WebSphere_Portal on node WP01 from the list. e. Check the box Create Replication Entry in this Server. f. Click Next, then Click Next, then Finish.
3. Save the changes.
Figure 2: Defining the cluster
4. After you complete the steps above, you can view the cluster topology by expanding Servers, and
then selecting the Cluster Topology view.
Install WebSphere Portal on WP02 Each additional WebSphere Portal node to be added to the cluster should have the same directory tree structures as WP01. a. In the WP02 system, launch the WebSphere Portal installer to install WebSphere Portal. After the
installation is finished: • WebSphere Portal is up and running with Cloudscape database • It uses the internal HTTP transport within WebSphere Application Server to handle requests • It runs without security enabled.
b. Modify the wpconfig.properties file by entering the values appropriate for your environment.
Use database validation tasks to validate database properties and values, and LDAP validation tasks
to validate LDAP properties and values. Refer to the Installing WebSphere Portal section above for samples and procedures.
c. Unlike WP01, the steps for configuring WebSphere Portal with an external Web server are not
needed here. However, you need to modify the WpsHostName property in wpconfig.properties file. Replace the default value localhost with WP02’s fully qualified host name.
d. Next, connect the WebSphere Portal installed on WP02 to the databases that are used by WebSphere
Portal installed on WP01. Unlike WP01, you do not execute export and import tasks; you run the connect-database task instead. Be sure you have passed database and LDAP validation tasks before you continue. a. Change to the <wp_root>/config directory . b. Stop WebSphere Portal by entering the following command:
./WPSconfig.sh stop-portal-server
c. Enter the following command: ./WPSconfig.sh connect-database
d. Do not start WebSphere Portal on WP02 and do not access WebSphere Portal as any user at this time because you are sharing a database outside a cluster environment. Database configuration may not match your local application server configuration. Wait until this node becomes a WebSphere Portal cluster member before validating it.
e. Modify wpconfig.properties, set the following: DbSafeMode=true
f. To configure security with WebSphere Application Server, WebSphere Portal, and WebSphere Member Manager, enter: ./WPSconfig.sh enable-security-ldap
Add WP02 into the cell
Add WP02 to Deployment Manager by entering the following command in one line. Do not use includeapps parameter in this case, because applications were added when WP01 was federated to the cell.
./addNode.sh <deployment_manager_host> <deployment_manager_port> -username <admin_user_id> -password <admin_password>
o <deployment_manager_host> is the Deployment Manager host name. o <deployment_manager_port> is the Deployment Manager SOAP connector-address. The
default value is 8879. o <admin_user_id> is the WebSphere Application Server administrative user name. o <admin_password> is the administrative user password.
Add WP02 into the cluster 1. In the Deployment Manager Administration Console, expand Servers -> Clusters. Click on the
cluster name that you created, click the cluster members link, and then click New.
2. Enter this cluster member information:
• Define the member name. Give this cluster member (and consecutive members) a different name to distinguish it from the first cluster member WP01; for example, WebSphere_Portal-WP02.
• Select WP02 as the node. • Uncheck Generate Unique Http Ports check box. • Finish creating the cluster member. Make sure you check the Synchronize changes with Nodes
check box before saving changes. 3. After the save completes, expand System Administration, click on Nodes and make sure all cluster
member nodes are fully synchronized. See Hints and tips for manual synchronization instructions, if necessary.
4. Expand Environment -> Internal Replication Domains. Click on the cluster name that you
created, click Replicator Entries link, then click New.
5. Enter the Replicator information: • Define the Replicator name. You can use machine’s host name. • Select the cluster member for WP02. • Define WP02’s host name as the Replicator host name. • Define Replicator port, for example: 7978 • Define client port, for example: 7977 • Make sure you check the Synchronize changes with Nodes check box, and then save your
changes. Update Web Server plugin See Update Web Server plugin section in Building a cell above for detailed instructions. Update DeploymentServices.properties Each cluster member node needs to know the WebSphere Portal cluster name created for portlet deployment. On each cluster member node: 1. Change to <portal_root>/shared/app/config/services directory 2. In the DeploymentServices.properties file, change the following property
wps.appserver.name=<your_cluster_name>
where: your_cluster_name is the WebSphere Portal cluster name you created.
Start the cluster Now, you can start the WebSphere Portal cluster. In Deployment Manager’s Administration Console, expand Servers, and select Clusters. Select the WebSphere Portal cluster you created, and click Start. After the cluster starts successfully, both WP01 and WP02 are able to handle your requests. Session persistence By now, you should have a functional WebSphere Portal cluster. An important aspect of a cluster is the ability of each node in the cluster to assume ownership of requests if another node goes down; this can be accomplished by enabling session persistence. There are two ways to implement session persistence: database session persistence and memory-to-memory replication. This document shows how to enable database session persistence. Create a database to store session data In a multi-server environment, session information can be stored in a central session database for session persistence. Below is an example for creating a DB2 session database. create database session using codeset UTF-8 territory us; connect to session; create bufferpool sessionBP size 1000 pagesize 8k; connect reset; connect to session; create tablespace sessionTS pagesize 8k managed by system using ('/home/db2inst1/db2inst1/NODE0000/SQL00005/sessionTS.0') bufferpool sessionBP; connect reset;
where db2inst1 is the DB2 instance
Create JDBC provider for session database Next, create a JDBC provider to access the session database. It is better to create the provider on the cell level. Later, if there is a need to add another node into the cluster, you do not have to create another JDBC provider for it, because all nodes in the cell can share the same JDBC provider at the cell level.
Figure 3. Creating a JDBC provider
1. In Deployment Manager’s Administration Console, expand Resources, then JDBC Providers.
Make sure the scope is set to the cell level. Click New, then select DB2 Legacy CLI-based Type 2 JDBC Driver.
2. Click on the driver link for configuration. Before you modify Classpath, you might notice that the
class path contains a WebSphere variable. You will set its value later. Click on Apply. 3. Click on Data Sources link under Additional Properties. 4. Click New to create a new data source. Specify a unique data source name and unique JNDI name,
then click Apply. 5. Click J2C Authentication Data Entries link. 6. Click New to create a new J2C authentication data entry. Define a unique name for Alias. The User
ID and Password fields should be your DB2 instance name and administrator password. Click Ok to continue.
7. Navigate back to Data Sources panel, for both Component-managed Authentication Alias and Container-managed Authentication Alias; select the J2C authentication data entry you created.
8. Now, you move on to set the WebSphere variable defined in JDBC driver classpath. You need to set
WebSphere Variables on the node level. Select Environment Manage WebSphere Variables; Browse Nodes, select a cluster member, and click Apply. Select the WebSphere variable, in this example, DB2_JDBC_DRIVER_PATH. Click on the link, set the value to: /home/db2inst1/sqllib/java12/
9. Make sure you check the Synchronize changes with Nodes check box, and then Save changes.
Enable session on WebSphere Portal application server 1. In Deployment Manager’s Administration Console, expand Servers, Application Servers, click on
the link of a WebSphere Portal cluster member, click on Web Container, then click on Session Management, then click on Distributed Environment Settings under the Additional Properties panel.
2. Select Database as the distributed session type. Then click on the Database link. Enter the JNDI name you defined when you created the data source. The user ID and password values should be the same as when you created the J2C authentication data entry.
3. Based on the sample session database created above, the DB2 row size here is ROW_SIZE_8KB, and the Table space name is sessionTS. Check the Use Multi row schema check box, then click OK.
4. Make sure you check the Synchronize changes with Nodes check box, then save your changes.
If the WebSphere Portal cluster is running, you need to restart the cluster for session changes to take effect.
Figure 4. Enabling the sesssion
Hints and tips When you run any configuration task, it is a good idea to write the output to a file. When the task is done, check the output file for any error messages before proceeding with any additional tasks. If the configuration task fails, verify the property values in the wpconfig.properties file. When you need to apply interim fixes, make sure you apply to all cluster member nodes. All cluster member nodes must be at the same corrective service levels. If your Web server and WebSphere Portal are installed on the same machine, after you build the WebSphere Portal cluster, you may want to change the Web server plug-in path on the node, especially if the Deployment Manager and the Web server are running in different operating systems. If you have changed paths in plugin-cfg.xml and you keep automatic synchronization settings on in Deployment Manager, you must change the path for the plugin-cfg.xml file. Otherwise, the synchronization between Deployment Manager and nodes will override the plugin-cfg.xml file located on the node.
Each node in the cluster should have the same synchronization settings to ensure consistency between WebSphere Portal node configurations. By default, automatic synchronization flag is on and the synchronization interval is 60 seconds. It is recommended that you increase the synchronization interval in a production environment to reduce the overhead, or turn it off and require synchronization to be a manual step. Portlet deployment When using XMLAccess to deploy portlets, you will need to use the WebSphere Portal HTTP port explicitly from the node that you run the command. Otherwise, you may receive a FileNotFoundException if other cluster members handle the request and the portlet’s WAR file does not exist on that node. The default port for WebSphere Portal is 9081. You can add that port into Host Aliases for portlet deployment. Refer to the Define HTTP port and Update Web Server Plugin section in Building a cell above for detailed instructions. After you have added the port, you can deploy portlets using port 9081 on the node. An example is provided below: 1. Change to <portal_root>/bin directory. 2. Deploy the portlet using installPortlet.xml that you define. You can use the
DeployPortlet.xml as a template, found under <portal_root>/doc/xml-samples. Enter following command on a single line:
./xmlaccess.sh -in <source_dir>/installPortlet.xml -user <admin_user_id> -pwd <admin_password> -url http://<your_portal_server>:9081/wps/config
where: • <source_dir> is the directory where the installPortlet.xml file is located • <admin_user_id> is the WebSphere Application Server administrative user name. • <admin_password> is the administrative user password. • <your_portal_server> is the name of the WebSphere Portal node’s host name that will be used
for deploying the portlet You must add those Portal users and groups, which you wish to authorize for portlet deployment, as console users and groups in Deployment Manager. In Deployment Manager’s Administration Console, expand System Administration -> Console Users to add a console user. Use a similar procedure to add groups.
Manually synchronizing nodes with Deployment Manager You can use the following commands to manually synchronize nodes with Deployment Manager. Optionally, you can use the Deployment Manager Aministration Console to synchronize the nodes as well.
1. In the WebSphere Portal node, change to the <was_root>/bin directory. 2. Stop the node agent before running synNode. To stop the node agent, enter:
./stopNode.sh –user <admin_user_id> -password <admin_password>
where: <admin_user_id> is the WebSphere Application Server administrative user name <admin_password> is the administrative user password
3. Synchronize node with Deployment Manager by entering command in a single line:
./syncNode.sh <deployment_manager_host> <deployment_manager_port> -user <admin_user_id> -password <admin_password>
4. Finally, restart the node agent:
./startNode.sh –username <admin_user_id> -password <admin_password>
Conclusion This article showed you how to set up WebSphere Portal and the most common features, such as session persistence and security, used with it in a cluster environment. After you have set up the WebSphere Portal cluster, using portal is much like using WebSphere Portal outside a cluster. You no longer have to choose which portal through which to install portlets and which clones to start and stop. Keeping nodes synchronized is much easier because you no longer have to worry about keeping file system directories in common between nodes in the cluster. Obviously, though, cluster setup can be complex. As both WebSphere Application Server V5 and WebSphere Portal V5 evolve, the process will get easier, allowing you to focus more on portal application development and deployment than on cluster operations. About the authors Belinda Yu is a software engineer in WebSphere Portal system
verification team at the IBM Software Group in Research Triangle Park, NC. Belinda started with the Visual Age product, and has been worked with WebSphere Portal for the past three years.
Marshall Lamb is a Senior Software Engineer and Chief Programmer for WebSphere Portal V5. Before that, he lead the Business Portlet development team for WebSphere Portal as well as the WebSphere Transcoding Publisher product for several years. Marshall started in networking software development, working through the Host Integration product line before moving into the Pervasive Software Division (WTP) and finally Lotus Software, with WebSphere Portal.
The authors would like to thank the following people for their contribution to this article: Gangadhar Poondota Rajesh Lalgowdar Venu Rao Shekar Maramraju
References For more information on the IBM products referenced in this article, see: • WebSphere Portal for Multiplatforms version 5.0
http://publib.boulder.ibm.com/pvc/wp/500/index.html
Installing the environment components
Installing WebSphere Portal
Configuring WebSphere Portal security
Network Deployment
Update Web Server plugin
Create JDBC provider for session database
Enable session on WebSphere Portal application server
Hints and tips
Conclusion