·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
LOAD MORE