Installing Portal Server in a cluster environment

Transcription

1 IBM WebSphere Portal for Multiplatforms Version June, 2002 Second Edition Abstract Because Portal Server runs as an application server within WebSphere Application Server, you can take advantage of workload-management features that are provided with Application Server. This paper provides step-by-step instructions for creating server groups and clones that Portal Server can use to help balance workloads and to achieve higher performance. Introduction...2 About this paper...2 Planning - Configure the...4 Steps for vertical scaling...5 Steps for horizontal scaling...10 Deploying portlets into an existing horizontal cluster...17 Troubleshooting and tips...19 Additional information...20 Copyright International Business Machines Corporation All rights reserved.

2 Introduction Configuring server groups and clones, commonly referred to as clustering, is a feature of Application Server that can improve workload management. A server group is a template that represents a collection of identical application servers, and the template is used to create additional copies of the Portal Server content and administrative resources. As requests to the original Portal Server come in, the copies, called clones, handle the requests to help balance the workload for the portal. The clustering architecture enables the distribution of portal processes beyond the original Portal Server to multiple copies on a single machine or across copies on multiple machines. Clustering is most effective in environments that distribute portal processes across multiple machines (nodes), called horizontal scaling. Also, you can use workload management in systems that contain multiple servers on a single, high-capacity machine, called vertical scaling. This paper provides steps for implementing vertical and horizontal topologies. About this paper This section explains the conventions and assumptions that are used in this paper. Because numerous configurations are achievable with the products provided with WebSphere Portal, this paper focuses on cluster configurations that are presented in this section which have been tested by IBM. This paper will be updated periodically. Refer to the WebSphere Portal Web site for the latest information. Note The steps in this paper for using the interfaces might change if changes to the user interfaces are implemented after this paper is released. Updates The following updates have been included in this version: 6/28/02 Emphasized that Setup Manager must be used to install Portal Server. Revised Assumptions. Added Planning - Configure the. Added Deploying portlets into an existing horizontal cluster. Added additional file copies between the and the Clone for third-party authentication support. Added Troubleshooting and tips. Conventions The following conventions are used in this paper: Setup Manager: the installation program provided with WebSphere Portal. You can use Setup Manager to install most software components referenced in this paper. In all instances that Portal Server is installed, you must use Setup Manager. DB2 Server: the remote machine where DB2 server is installed. Also, for the purposes of this paper, it is assumed that IBM SecureWay Directory (LDAP server) is installed on the same machine with DB2 Server. 2

3 : the main node for the cluster. Clone node: represents clones of the in the horizontal scaling example. was41 database: the Application Server example database. wps41 database: a database created to store Portal Server user information. wms database: the database used to store the Member Services information. Portal Server uses the Member Services database to manage data for users and groups of users. Member Services in Portal Server keeps track of the overall attribute set of the users and groups within the system and the values of those attributes for individual users and groups. db2_root: root directory where DB2 software is installed. was_root: root directory where Application Server is installed. wps_root: root directory where Portal Server is installed. Where variables are used, users should edit the directory paths according to their machine configuration. Assumptions Read this section to learn about the assumptions that are used in the examples in this paper. General assumptions Setup Manager is used to install Portal Server. Read the WebSphere Portal Release Notes and InfoCenter for details on installing software. The Web server is running on a separate machine from the. Throughout this paper, IBM HTTP Server is referenced as the Web server that is used. If you use a third-party authentication server for security, you must configure it prior to setting up the server group and clones. See the WebSphere Portal InfoCenter for more information on using a third-party authentication server. Machine descriptions The following table provides descriptions of the servers that are referenced in this paper. Table 1 - Machine descriptions and requirements Machine name Machine description Software requirements DB2 Server A remote machine where DB2 server is installed. Also, for the purposes of this paper, it is assumed that IBM SecureWay Directory (LDAP server) is installed on the DB2 Server. Clone node The for each clustered environment. The uses DB2 client software to connect to the DB2 Server. A clone of the in the horizontal topology. The Clone node use DB2 client software to connect to the DB2 Server. DB2 server is installed and TCP/IP is functional. The required databases must be created and configured at the DB2 Server. Also, JDBC Version 2.0 is required. Note for Unix systems During the DB2 installation, make sure that you specify the JDBC 2 driver directory: db2_root/java12/db2java.zip The requires DB2 Administration Client, WebSphere Application Server, the Application Server fixpack, the Application Server e-fixes, and Portal Server to be installed. Setup Manager must be used to install Portal Server. The Clone node requires DB2 Administration Client, WebSphere Application Server, the Application Server fixpack, and the Application Server e-fixes to be installed. 3

4 Software descriptions The following table provides descriptions of the software that is referenced in this paper. Table 2 - Software referenced in this paper Software name Description Where installed DB2 Universal Database V7.2 + Fixpack 5 IBM SecureWay Directory V e-fix 2 IBM WebSphere Application Server, Advanced Edition V4.0 + Fixpack 2 plus e-fixes Database software. Where applicable, the terms DB2 server and DB2 client are used. LDAP server software. Application server software. At the time of this publication, the following e-fixes were required: DB2 server is installed on the DB2 Server. DB2 client is installed on the and the Clone node. Runs on the DB2 Server. WebSphere Application Server is installed on the and the Clone node. Portal Server PQ55941, PQ56615, PQ57814, PQ58289, PQ58678, PQ58795, PQ59932, PQ60461, PQ60787 Portal server software. You must use Setup Manager to install Portal Server. Portal Server is installed on the Main node. Planning - Configure the This section provides important planning information that will help you successfully set up server groups and clones for your portal environment. Read this section carefully and follow all instructions before proceeding to the steps for vertical or horizontal scaling. It is important to successfully install, configure, and test software on the before moving to a cluster environment. The following list provides actions that you should complete before setting up server groups and clones: Install and configure the required software on the. The steps for vertical and horizontal scaling in this paper guide you through the installation and configuration of the required software for the. Read this note about portlet deployment in a horizontal cluster. Portlets are the reusable components that provide access to Web-based content, applications, and other resources. All portlets are servlets (J2EE applications), and WebSphere Application Server provides the capability to deploy new portlets in your portal environment. Historically, businesses have used WebSphere Application Server to roll out new applications on a schedule that requires planned updates and server downtime. In comparison, the concept behind deploying portlets is different, in that portlets are perceived as applications that you can deploy quickly without planned interruptions. Currently, with WebSphere Application Server Version 4.02, it is recommended that you deploy portlets after you install Portal Server and prior to creating the cluster environment. If you decide to deploy portlets after you have set up the cluster, you should follow the steps in one of the options provided in this paper: Option 1: Share the installedapps directory on 4

5 page 17 or Option 2: Manually copy portlets on page 17. Note that if you follow the instructions in option 2 to deploy portlets after you set up the cluster, each clone must be recycled. This clone recycling is only required if you are deploying new portlets after you have set up the cluster. Clone recycling is not required if you add portlets to pages, configure existing portlets, or deploy new portlets as described in option 1. Configure and test a third-party authentication server for security (optional). If you plan to use a third-party authentication server, you should configure and test it prior to setting up the server group and clones. Also, if you employ horizontal clustering, you must copy related files from the to the Clone nodes. The file copying procedure is part of Step 7 - Copy files and directories between the and the Clone node on page 14. For details about using a third-party authentication server with your portal, see the WebSphere Portal InfoCenter. Steps for vertical scaling Vertical scaling enables portal processes to be created on a single, physical machine by using server groups and clones. Use the following steps to install and configure vertical clones of Portal Server. Important Make sure that you read Planning - Configure the on page 4 before performing the steps in this section. Table 3 - Steps for vertical scaling Steps Step 1 - Create and configure the Application Server and Portal Server databases Step 2 - Enable JDBC Version 2.0 Step 3 - Establish connections to the remote databases Step 4 - Install and configure Application Server Step 5 - Use Setup Manager to install Portal Server Step 6 - Create server groups and clones Step 7 - Regenerate the Web server plug-in Step 8 - Start the server group Step 9 - Configure session management properties for the server group Step 10 - Rename log files for each clone Where DB2 server DB2 server, DB2 server Step 1 - Create and configure the Application Server and Portal Server databases This section provides steps for creating and tuning the Application Server and Portal Server databases, enabling TCP/IP remote connections, and cataloging the databases as remote databases. Note about using a local database: The examples in this paper use a remote DB2 server. You can install DB2 server on the same machine as Application Server and Portal Server when setting up a cluster environment. For Unix system, if DB2 server is installed on the same Unix machine with Application Server and Portal Server, you must manually create and configure the Portal Server databases. For more information, see the Requirements section of the InfoCenter provided with WebSphere Portal. 5

6 Do the following: 1. Go to the DB2 Server and log on to DB2 server with superuser (root) privileges. 2. Create and update the Application Server database (example: was40). create database was40 update database configuration for was40 using applheapsz 256 The was40 database is the administrative repository for Application Server. 3. Create and update the Portal Server database (example: wps41). create database wps41 using codeset UTF-8 territory us update database configuration for wps41 using applheapsz 1024 app_ctl_heap_sz Create and update the WebSphere Member Services database (example: wms). create database wms using codeset UTF-8 territory US; update database configuration for wms using applheapsz 16384; update database configuration for wms using stmtheap 60000; update database configuration for wms using app_ctl_heap_sz 8192; update database configuration for wms using locklist 400; update database configuration for wms using indexrec RESTART; update database configuration for wms using logfilsiz 1000; update database configuration for wms using logprimary 12; update database configuration for wms using logsecond 10; Note The database tables are created during the Application Server and Portal Server installations. Step 2 - Enable JDBC Version 2.0 The following instructions are for Windows systems only. See the note below for information related to Unix systems. To enable the JDBC Version 2.0 for Application Server and Portal Server, execute the usejdbc2 batch file on the DB2 Server. This file is in the db2_root\java12 directory. The following is an example. C:\SQLLIB\java12>usejdbc2 The JDBC driver is usually located in db2_root\java\db2java.zip, where db2_root is usually SQLLIB. If you execute the usejdbc2 batch file, the db2java.zip file is overwritten with the zip file of JDBC Version 2.0. Note for Unix systems JDBC Version 2.0 is required for the instructions in this paper. During the DB2 installation, make sure that you specify the JDBC 2 driver directory: db2_root/java12/db2java.zip. 6

7 Step 3 - Establish connections to the remote databases The following instructions assume that DB2 Administration Client is installed on the and that TCP/IP is configured correctly and will be used as the transport protocol. 1. Log on to the system with a valid DB2 user ID. 2. At the, update the services file, if necessary. Use a text editor to open the services file located in the winnt\system32\drivers\etc directory for Windows and /etc for Unix. If entries do not specify DB2 connection and interrupt service ports, specify the ports. For example: server1 server1i 50000/tcp # DB2 connection service port 50001/tcp # DB2 interrupt connection service port 3. Go to the DB2 Server, and issue the following commands to establish a remote connection. For example: db2set db2comm=tcpip db2 update dbm cfg using svcename service_port The first line sets the DB2 environment variable db2comm to indicate that TCP/IP will be used as the protocol for remote communication. The second line updates the service port to the variable that was given in step Go to the and catalog the node and databases. The following example uses the database names that were provided when the databases were created in Step 1 - Create and configure the Application Server and Portal Server databases on page 5. db2 catalog tcpip node db2node remote serverhost service_port db2 catalog database was40 as alias_name at node db2node db2 catalog database wps41 as alias_name at node db2node db2 catalog database wms as alias_name at node db2node 5. Stop and start DB2 for your changes to take effect by using the db2stop and db2start commands, as follows: db2stop db2start 6. To log out as the DB2 instance owner, enter the following command: exit The DB2 server remains active unless you stop it by using the db2stop command. Step 4 - Install and configure Application Server Install WebSphere Application Server, fixpack 2 and the required e-fixes on the. This section contains important information about installing and configuring Application Server. Install the required level of Application Server At the time of publication, the level of Application Server required was IBM WebSphere Application Server, Advanced Edition V4.0 + Fixpack 2 with the following e-fixes: 7

8 PQ55941 PQ56615 PQ57814 PQ58289 PQ58678 PQ58795 PQ59932 PQ60461 PQ60787 If you use Setup Manager to install WebSphere Application Server, the preceding e-fixes and fixpack are installed automatically except for e-fix PQ60461, which must be installed manually. You can download e-fix PQ60461 from the following Web site: See the README file that is included with the e-fix for more information. Select Remote Database during the installation During the WebSphere Application Server installation, make sure that you select the Remote Database checkbox, and type the database User ID and password of the remote database server. Step 5 - Use Setup Manager to install Portal Server Use the instructions provided with WebSphere Portal to install Portal Server on the. For the latest information on installing WebSphere Portal components, see the WebSphere Portal Library Web site: Because you created and configured the Portal Server (example: wps41) and the WebSphere Member Services (example: wms) databases in Step 1 - Create and configure the Application Server and Portal Server databases, select Initialize an existing database during the Portal Server installation. The Portal Server installation automatically creates the tables for the databases. Step 6 - Create server groups and clones After you install Portal Server, use the WebSphere Administrative Console to create server groups and clones. 1. Start the WebSphere Administrative Server and then the Administrative Console. 2. Verify that the WebSphere Portal application server is not running. In the tree view, click WebSphere Administrative Domain > Nodes > node_name > Application Servers > WebSphere Portal, and then right-click on WebSphere Portal and select Stop. 3. Click Console > Wizards > Create Server Group. 4. If the Create server group based on an existing application server checkbox is not selected, select it. 5. Select WebSphere Portal from the top drop-down menu. 6. Type a name in the Server group name box. 7. Select the desired setting for the Workload Management selection property box. 8

9 8. Click Next. 9. Select the desired services and edit appropriately, and then click Next to continue. 10. Type a name in the Create Application Server cloned named box. Make sure that the value in the Node to install server on box is the node that you are currently on. 11. Click Add. 12. Click Next to review the updates, and then click Finish. Step 7 - Regenerate the Web server plug-in Manually trigger the WebSphere plug-in to regenerate its configuration. Failure to regenerate the plug-in might produce a 404 File Not Found error if a user tries to access the portal. Important: Regenerating the Web server plug-in overwrites any manual configuration changes that you might want to preserve. Before regenerating the Web server plug-in, understand its implications as described in the article about administering Web server plug-ins at: To regenerate the Web server plug-in: 1. Locate the node which runs the IBM HTTP Server in the tree view of the Administrative Console. 2. Right-click it, then select Regen Webserver Plugin. 3. Stop and restart IBM HTTP Server. Step 8 - Start the server group To start the server group you created, do the following: 1. Locate the server group in the tree view of the Administrative Console. 2. Right-click it, then select Start. All clones start when the server group starts, and workload management automatically begins. Step 9 - Configure session management properties for the server group After you have the clones up and running, enable session management to ensure that the subsequent requests from the client will continue to be served by the same server. Session management properties are typically administered at the server group level and not on individual clones. To access session management settings for a server group: 1. Select the server group that you created in the tree view of the Administrative Console. 2. Click the Services tab. 3. Select the Session Manager Service from the Services list. 4. Click the Edit Properties button. You can control all session management properties on the screen that displays. 9

10 Step 10 - Rename log files for each clone For each clone on the system, change the location or name of the Application Server Standard output and Standard error files so that all clones do not write to the same file. 1. Verify that the WebSphere Portal application server is not running. 2. In the tree view, click WebSphere Administrative Domain > Nodes > node_name > Application Servers > clone_name, and then right-click on name and select Properties. 3. Click File. 4. Change the value of the Standard output and Standard error files. For example change appserver-out.log to clone_name-appserver-out.log. 5. Click OK. Steps for horizontal scaling Horizontal scaling enables portal processes to be created on multiple physical machines by using server groups and clones. Use the following steps to install and configure horizontal clones of Portal Server. Important Make sure that you read Planning - Configure the on page 4 before performing the steps in this section. Table 4 - Steps for horizontal scaling Steps Step 1 - Create and configure the Application Server and Portal Server databases Step 2 - Enable JDBC Version 2.0 Step 3 - Establish connections to the remote databases Step 4 - Install and configure Application Server Step 5 - Use Setup Manager to install Portal Server Step 6 - Configure JDBC providers for the Clone node Step 7 - Copy files and directories between the and the Clone node Step 8 - Create server groups and clones Step 9 - Regenerate the Web server plug-in Step 10 - Start the server group Step 11 - Configure session management properties for the server group Where DB2 server DB2 server, Clone node, DB2 server, Clone node, Clone node Step 1 - Create and configure the Application Server and Portal Server databases This section provides steps for creating and tuning the Application Server and Portal Server databases, enabling TCP/IP remote connections, and cataloging the databases as remote databases. Note about using a local database: The examples in this paper use a remote DB2 server. You can install DB2 server on the same machine as Application Server and Portal server when setting up a cluster environment. For Unix systems, if DB2 server is installed on the same Unix machine with Application Server and Portal Server, you must manually create and configure the Portal Server databases. For more information, see the Requirements section of the InfoCenter provided with WebSphere Portal. 10

11 Do the following: 1. Go to the DB2 Server and log on to DB2 server with superuser (root) privileges. 2. Create and update the Application Server database (example: was40). create database was40 update database configuration for was40 using applheapsz 256 The was40 database is the administrative repository for Application Server. 3. Create and update the Portal Server database (example: wps41). create database wps41 using codeset UTF-8 territory us update database configuration for wps41 using applheapsz 1024 app_ctl_heap_sz Create and update the WebSphere Member Services database (example: wms). create database wms using codeset UTF-8 territory US; update database configuration for wms using applheapsz 16384; update database configuration for wms using stmtheap 60000; update database configuration for wms using app_ctl_heap_sz 8192; update database configuration for wms using locklist 400; update database configuration for wms using indexrec RESTART; update database configuration for wms using logfilsiz 1000; update database configuration for wms using logprimary 12; update database configuration for wms using logsecond 10; Note The database tables are created during the Application Server and Portal Server installations. Step 2 - Enable JDBC Version 2.0 The following instructions are for Windows systems only. See the note below for information related to Unix systems. To enable the JDBC Version 2.0 for Application Server and Portal Server, execute the usejdbc2 batch file on the DB2 Server. This file is in the db2_root\java12 directory. The following is an example. C:\SQLLIB\java12>usejdbc2 The JDBC driver is usually located in db2_root\java\db2java.zip, where db2_root is usually SQLLIB. If you execute the usejdbc2 batch file, the db2java.zip file is overwritten with the zip file of JDBC Version 2.0. Note for Unix systems: JDBC Version 2.0 is required for the instructions in this paper. During the DB2 installation, make sure that you specify the JDBC 2 driver directory db2_root/java12/db2java.zip. 11

12 Step 3 - Establish connections to the remote databases The following instructions assume that DB2 Administration Client is installed on the and the Clone node, and that TCP/IP is configured correctly and will be used as the transport protocol with the DB2 server. 1. Log on to the system with a valid DB2 user ID. 2. At the, update the services file, if necessary. Use a text editor to open the services file located in the winnt\system32\drivers\etc directory for Windows and /etc for Unix. If entries do not specify DB2 connection and interrupt service ports, specify the ports. For example: server1 server1i 50000/tcp # DB2 connection service port 50001/tcp # DB2 interrupt connection service port 3. Go to the DB2 Server, and issue the following commands to establish a remote connection. For example: db2set db2comm=tcpip db2 update dbm cfg using svcename service_port The first line sets the DB2 environment variable db2comm to indicate that TCP/IP will be used as the protocol for remote communication. The second line updates the service port to the variable that was given in step Go to the and catalog the node and databases. The following example uses the database names that were provided when the databases were created in Step 1 - Create and configure the Application Server and Portal Server databases on page 10. db2 catalog tcpip node db2node remote serverhost service_port db2 catalog database was40 as alias_name at node db2node db2 catalog database wps41 as alias_name at node db2node db2 catalog database wms as alias_name at node db2node 5. Stop and start DB2 for your changes to take effect by using the db2stop and db2start commands, as follows: db2stop db2start 6. Repeat steps 2 through 5 for the Clone node. 7. To log out as the DB2 instance owner, enter the following command: exit The DB2 server remains active unless you stop it by using the db2stop command. Step 4 - Install and configure Application Server Install WebSphere Application Server, fixpack 2 and the required e-fixes on the and Clone node. This section contains important information about installing and configuring Application Server. 12

13 Install the required level of Application Server At the time of publication, the level of Application Server required was IBM WebSphere Application Server, Advanced Edition V4.0 + Fixpack 2 with the following e-fixes: PQ55941 PQ56615 PQ57814 PQ58289 PQ58678 PQ58795 PQ59932 PQ60461 PQ60787 If you use Setup Manager to install WebSphere Application Server, the preceding e-fixes and fixpack are installed automatically except for e-fix PQ60461, which must be installed manually. You can download e-fix PQ60461 from the following Web site: See the README file that is included with the e-fix for more information. Create the same directory structure for the and Clone node The same Application Server and Portal Server directory structure must exist on both the Main node and the Clone node. For example, if you install Application Server in c:\websphere\appserver on the, and then install Application Server in d:\websphere\appserver on the Clone node, the clustering will fail. Select Remote Database during the installation During the WebSphere Application Server installation, make sure that you select the Remote Database checkbox, and type the database User ID and password of the remote database server. Update admin.conf on the Clone node before you start Application Server At the Clone node, before you start Application Server, update the was_root/bin/admin.conf file to change the following parameter to false. install.initial.config=false : # Create AdminServer database tables com.ibm.ejs.sm.adminserver.createtables=true After you set this parameter to false and start Application Server for the first time, Application Server will not install the Default Server on the Clone node. Step 5 - Use Setup Manager to install Portal Server Use the instructions provided with WebSphere Portal to install Portal Server on the. For the latest information on installing WebSphere Portal components, see the WebSphere Portal Library Web site: 13

14 Because you created and configured the Portal Server (example: wps41) and the WebSphere Member Services (example: wms) databases in Step 1 - Create and configure the Application Server and Portal Server databases, select Initialize an existing database during the Portal Server installation. The Portal Server installation automatically creates the tables for the databases. Note about portlet deployment It is recommended that you install all portlets prior to creating the cluster environment. If you want to install portlets after you have created the server group and clones, see "Deploying portlets into an existing horizontal cluster on page 17 for important information. Step 6 - Configure JDBC providers for the Clone node Use the Administrative Console to install the wps40jdbc driver and Pers DB Driver for the Clone node. 1. Select Resources > JDBC Providers >wps40jdbc in the tree view of the Administrative Console. 2. Select the Nodes tab, and then click Install New. 3. Select the name of the Clone node, and then specify the driver file db2_root\java12\db2java.zip. You can either type the path and file name, or you can click Specify driver to launch windows that enable you to search for the file. 4. Click Install after you specify the driver file. 5. Follow steps 1 through 4 to install Pers DB Driver. 6. Select Nodes > Application Server > WebSphere Portal in tree view. 7. Right-click on WebSphere Portal and select Stop to stop the portal. Step 7 - Copy files and directories between the and the Clone node 1. On the Clone node, create the following directories: WebSphere/PortalServer (wps_root) was_root/lib/app was_root/installedapps/wps_enterprise_application.ear was_root/installedapps/websphere_member_subsystem.ear was_root/installedapps/wcm_publish_webapp.ear was_root/installedapps/ws_proxy.ear was_root/personalization (AIX) /usr/ibmtrans (Linux or Solaris) /opt/ibmtrans 2. Copy the following directories and files from the to the Clone node: Copy the WebSphere/PortalServer/ directory. Copy the was_root/lib/app/ directory Copy the was_root/personalization/ directory Copy was_root/java/jre/lib/ext/jaas.jar Copy the was_root/java/jre/lib/security/ directory Copy the was_root/installedapps/ directory Copy was_root/lib/brbclient.jar 14

15 Copy was_root/lib/brbserver.jar Copy the IBMTrans/ directory. 3. Optional Copy files related to third-party authentication servers: JAR files Copy was_root/classes/wpstai.jar Copy was_root/classes/rsatai.jar (WebSphere Portal Version only) (SiteMinder and RSA ClearTrust only) Copy the supporting tai jar files from the was_root/classes directory. For example, for the SiteMinder TAI, copy the file smjavaagentapi.jar. Properties files Copy was_root/properties/trustedservers.properties Copy was_root/properties/webseal.properties (Access Manager TAI only) Copy was_root/properties/cleartrust.properties (RSA ClearTrust TAI only) Copy was_root/properties/siteminder.properties (SiteMinder TAI only) 4. Do the following at the Clone node: Copy wps_root/app/wps.ear/* to: was_root/installedapps/wps_enterprise_application.ear Copy wps_root/app/wms.ear/* to: WebSphere_Member_Subsystem.ear Copy wps_root/app/wcmpznpublish.ear/* to: WCM_Publish_WebApp.ear Copy wps_root/app/wsproxy.ear/* to: was_root/installedapps/ws_proxy.ear Step 8 - Create server groups and clones Use the WebSphere Administrative Console to create server groups and clones. 1. Start the WebSphere Administrative Server and then the Administrative Console. 2. Verify that the WebSphere Portal application server is not running. In the tree view, click WebSphere Administrative Domain > Nodes > node_name > Application Servers > WebSphere Portal, and then right-click on WebSphere Portal and select Stop. 3. Click Console > Wizards > Create Server Group. 15

16 4. If the Create server group based on an existing application server checkbox is not selected, select it. 5. Select WebSphere Portal from the top drop-down menu. 6. Type a name in the Server group name box. 7. Select the desired setting for the Workload Management selection property box. 8. Click Next. 9. Select the desired services and edit appropriately, and then click Next to continue. 10. Type a name in the Create Application Server cloned named box. Make sure that the value in the Node to install server on box is the node that you are currently on. 11. Click Add. 12. Click Next to review the updates, and then click Finish. Step 9 - Regenerate the Web server plug-in Manually trigger the WebSphere plug-in to regenerate its configuration. Failure to regenerate the plug-in might produce a 404 File Not Found error if a user tries to access the portal. Important Regenerating the Web server plug-in overwrites any manual configuration changes that you might want to preserve. Before regenerating the Web server plug-in, understand its implications as described in the article about administering Web server plug-ins at: To regenerate the Web server plug-in: 1. Locate the node where IBM HTTP Server is running in the tree view of the Administrative Console. 2. Right-click it, then select Regen Webserver Plugin. 3. Stop and restart IBM HTTP Server. Step 10 - Start the server group To start the server group you created, do the following: 1. Locate the server group in the tree view of the Administrative Console. 2. Right-click it, then select Start. All clones start when the server group starts, and workload management automatically begins. Step 11 - Configure session management properties for the server group After you have the Clone node up and running, enable session management to ensure that the subsequent requests from the client will continue to be served by the same server. Session management properties are typically administered at the server group level and not on individual clones. To access session management settings for a server group: 1. Select the server group that you created in the tree view of the Administrative Console. 2. Click the Services tab. 3. Select the Session Manager Service from the Services list. 16

17 4. Click the Edit Properties button. You can control all session management properties on the screen that displays. Deploying portlets into an existing horizontal cluster It is recommended that you deploy portlets after you install Portal Server and prior to creating the cluster environment. If you decide to deploy portlets after you have set up the cluster, you can use one of the options in this section to deploy portlets across clones. Read this section carefully to determine the best method for deploying portlets in your environment. Option 1: Share the installedapps directory Advantage: A manual copy of portlets between the and the Clone nodes is not required. Limitations: A single point of failure exists, and performance is affected. A basic approach to deploying portlets is to share the was_root/installedapps directory across all nodes in the cluster. The was_root/installedapps directory contains all the portlet directories for the portal. Note the following: Ensure that the login session is associated with the. See the related tip in Troubleshooting and tips on page 19. For all nodes in the cluster, share the was_root/installedapps directory. Option 2: Manually copy portlets Advantages: Performance improvement over option 1. Also, a single point of failure does not exist. Limitations: Not convenient for quick deployment of portlets after a horizontal cluster is setup. Portlets are installed one at a time on the. The following steps use Portal Administration, an interface provided with Portal Server, to install new portlets. An administrator must have the correct permissions on the portal to install portlets. Before you can copy portlets from the to the Clone node, a Web ARchive (WAR) file for the portlet must exist in a local directory of the. When you use Portal Administration, the portlet installation process uploads the WAR file to the server, installs the portlet, and then adds it to the portlet catalogue and activates the portlet. After the portlet is installed successfully on the, you can copy the related files to the Clone node. If you require more information about installing portlets, see the InfoCenter provided with WebSphere Portal. Do the following: 1. Ensure that the login session is associated with the and that the login has adequate permissions for installing portlets. See the related tip in Troubleshooting and tips on page In the Portal Server interface, go to Portal Administration to install the new portlet. For additional information on installing a portlet, click the help button in the Portal Administration interface. 3. After you install the portlet, the following error message displays. This error message is expected at this point of portlet deployment. This portlet is unavailable. If the problem persists, please contact the portal administrator. 17

18 Note All clone nodes will receive this error. To view the log file for this error, open the wps_root/log/appserver-out.log file on each Clone node. The following is an example of contents in the appserver-out.log file: [6/27/02 9:51:34:150 EDT] ActiveModule W ADSM0105W: Failed to load application docviewer_wps_pa_155com.ibm.etools.archive.exception.openfailureexception: Could not open /usr/websphere/appserver/installedapps/docviewer_wps_pa_155.earstack trace of nested exception:java.io.filenotfoundexception: URI Name: /usr/websphere/appserver/installedapps/docviewer_wps_pa_155.ear File name: /usr/websphere/appserver/installedapps/docviewer_wps_pa_155.ear 4. Go to the was_root/installedapps directory on the to verify that the newly installed portlet directories are listed. The directory names for the newly installed portlets use the following convention: filename_wps_pa_xxx.ear where filename is the WAR file name, and WPS_PA_xxx are automatically generated. 5. Select Manage Portlet Applications from Portal Administration, and select the newly installed web modules from the Web Modules list. If portlets that belong to the selected web module are inactive, select Activate to make the portlets active. 6. Do one of the following: If you want to install additional portlets, log off the portal, and repeat steps 1 through 5. After you install all portlets, log off the portal and go to step 7. If you do not want to install any more portlets, log off the portal and go to step Copy all the newly-installed portlet directories from the was_root/installedapps directory of the to the was_root/installedapps directory on all horizontal Clone nodes. 8. In the Administrative Console, select the server group that you created, and then right-click. 9. Select Ripple to make the portlets available for use. 18

19 Troubleshooting and tips This section provides troubleshooting information and tips. Troubleshooting: Server group was not created successfully Solution: Uninstall Portal Server, and then install Portal Server again Details: Before you uninstall Portal Server, do the following to verify that the server group was not created successfully. 1. In the Administrative Console, select the server group that you created. 2. Select the JVM Settings tab. If the Classpaths, System Properties, and Generated Command Line Arguments areas do not contain data, the server group was not created successfully. 3. Uninstall Portal Server using the procedures in the InfoCenter, and install Portal Server again. Verify that Portal Server is stopped before you create the server group for it. Troubleshooting: A clone was not created successfully Solution: Stop the clone and remove it, then create the clone again. Details: Before you remove the clone, do the following to verify that the clone was not created successfully: 1. In the Administrative Console, select the clone that you created. 2. Select the JVM Settings tab. If the Classpaths, System Properties, and Generated Command Line Arguments areas do not contain data, the clone was not created successfully. 3. Stop the clone, remove the clone, and then create the clone again. Troubleshooting: 404 or 500 error message when trying to access the portal. Solution: Regenerate the plugin configuration Details: Check the JVM Settings tab to verify that content exists. Next, do the following: 1. Select the main node from the Administrative Console. 2. Right-click, and then select the Regen Webserver Plugin. 3. Stop and then restart the Web server. Tip: Ensure that you are logged on to the. Before you can deploy portlets in an existing horizontal cluster, ensure that you are logged on to the. To ensure this, you can stop all horizontal clones, or you can update the hosts file on client machine. If you want to update the hosts file, do the following: 1. Use a text editor to open the hosts file located at winnt\system32\drivers\etc\hosts for Windows or /etc/hosts for Unix. 2. Map the external name to the node address. For example: if the public portal url is and the host name is wpsmain.yourco.com, type the hosts entry wpsmain.yourco.com Note that this entry is only necessary if you are installing portlets. 19

20 Additional information WebSphere Application Server InfoCenter topics: Read about administering server groups at: Read about using server groups and clones: Advice for cloning: WebSphere Portal Library Web site: Produced in the United States of America International Business Machines Corporation June 2002 All Rights Reserved IBM, WebSphere, and DB2 are trademarks of International Business Machines Corporation in the United States, other countries or both. Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries or both. Other company, product and service names may be trademarks or service marks of others. INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PAPER AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions; therefore, this statement may not apply to you. Information in this paper as to the availability of products (including portlets) was believed accurate as of the time of publication. IBM cannot guarantee that identified products (including portlets) will continue to be made available by their suppliers. This information could include technical inaccuracies or typographical errors. Changes may be made periodically to the information herein; these changes may be incorporated in subsequent versions of the paper. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this paper at any time without notice. 20