Deployment Scenario: WebSphere Portal Mashup integration and page builder

Deployment Scenario: WebSphere Portal 6.1.5 Mashup integration and page builder Deployment Scenario: WebSphere Portal 6.1.5 Mashup integration and page builder...1 Abstract...2 Portal Mashup integration and the page builder features introduction...2 Test Environment AIX Cluster...2 Portal Mashup integration and page builder cluster on AIX specifications...3 Test Environment Linux Standalone...4 Portal Mashup integration and page builder cluster on Linux specifications..5 Test Environment Solaris Cluster...7 Test Environment Windows Standalone...8 Portal Mashup integration client-side testing on Windows specifications...9 Test Environment z/os Cluster...10 Portal Mashup integration and page builder cluster on z/os specifications 11 Configuration steps for a Portal cluster with mashup integration and page builder on multi-platform (non-z/os)...12 Configuration steps for a Portal cluster with mashup integration and page builder on z/os...16 Test Methodology...19 Page builder Test Methodology...19 Portal Mashup integration Test Methodology...21 Portlets and pages Test Methodology...21 Portal mashup integration client-side Test Methodology...22 Client-side Test Flow...22 Description of Test 1...22 Description of Test 2...23 Reliability Test Configurations...23 1

Abstract The goal of this document is to outline the steps by which the WebSphere Portal System Verification Test (SVT) team installed, configured, and tested the Portal Mashup integration feature (including business spaces) and the page builder feature as part of the WebSphere Portal V6.1.5 on multi-platform and z/os environments. Portal Mashup integration and the page builder features introduction The Portal Mashup integration (including business spaces) and page builder are new features in WebSphere, and a description of the features can be found at http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp?topic=/com.ibm.wp.ent.doc_v615/welcome_main.html. The features were tested on new installs of both individually and in a combination of workloads, which included a traditional portal workload : Portal Mashup integration (with business spaces) only Page builder only Portal Mashup integration (with business spaces) and page builder Portal Mashup integration (with business spaces), page builder, and the traditional portlets and pages (all three workloads together denoted as the Combo All workload). The Portal configurations were tested on the following supported platforms: AIX Linux Solaris Windows z/os The stand-alone environments and cluster environments are defined in more details below. Test Environment AIX Cluster WebSphere Content was installed in a cluster environment and included the following components: IBM WebSphere v6.1.0.27 Deployment Manager 2

IBM WebSphere primary node on IBM WebSphere Application Server v6.1.0.27 IBM WebSphere Portal v.6.1.5 secondary node on IBM WebSphere Application Server v6.1.0.27 IBM DB2 v9.7 (for the WebSphere Portal database) IBM HTTP Server v6.1 (web server) IBM Tivoli Directory Server v6.2 -- contains 100000 portal users IBM Mashup Center v2.0 The following specifications detail the machines used to test Portal Mashup integration and the page builder feature: Portal Mashup integration and page builder cluster on AIX specifications Machine OS # of CPUs CPU Speed (GHz) CPU Type WebSphere v6.1.0.27 Deployment Manager IBM AIX v6.1 SP3 4 1.64 p Series 16 with WAS v6.1.0.27 IBM AIX v6.1 SP3 4 1.64 p Series 16 with WAS v6.1.0.27 IBM AIX v6.1 SP3 4 1.64 p Series 16 IBM Tivoli Directory Server v6.2 IBM AIX v6.1. SP3 4 1.64 p Series 16 RAM (GB) Function Deployment Manager Primary Portal node Secondary Portal node 100K users LDAP Database for Portal IBM DB2 v9.7 IBM AIX v6.1 SP3 4 1.64 p Series 16 IBM HTTP Webserver v6.1 IBM AIX v6.1 SP3 4 1.64 p Series 16 Web server IBM Mashup Center v2 Windows 2003 2 2.4 x Series 3 Mashup Hub HatJ Linux SuSE SLES 11 2 2.66 x Series 64-bit 10 Automation 3

WAS v6.1.0.27 Network Deployment (AIX v6.1 SP3) Portal Cell on AIX Cluster Configuration node 1 (WAS v6.1.0.27) (AIX v6.1 SP3) node 2 (WAS v6.1.0.27) (AIX v6.1 SP3) Database IBM DB2 v9.7 for (AIX v6.1 SP3) Rational Performance Tester / HatJ (client load) Directory Server IBM Tivoli DS v6.2 100K Users (AIX v6.1 SP3) Mashup V2 (Windows 2003 SP2) Web server IBM HTTP v6.1 (AIX v6.1 SP3) Portal mashup integration + page builder on AIX long run configuration Test Environment Linux Standalone WebSphere Content was installed in a stand-alone environment and included the following components: IBM WebSphere Portal v.6.1.5 on IBM WebSphere Application Server v7.0.0.5 Oracle 11g (11.1.0.6) for the IBM WebSphere Portal database IBM HTTP Server v7.0 web server IBM Tivoli Directory Server v6.2 -- contains 100000 portal users IBM Mashup Center v2.0 The following specifications detail the machines used to test Portal Mashup integration and page builder feature: 4

Portal Mashup integration and page builder cluster on Linux specifications Machine OS # of CPUs CPU Type CPU Speed (GHz) with WAS v7.0.0.5 Linux SUSE SLES 11 2 3.0 IBM Tivoli Directory Server v6.2 Linux SUSE SLES 10 4 1.6 Oracle 11g (11.1.0.6) Linux SUSE SLES 10 2 3.0 IBM HTTP Webserver v7 Linux SUSE SLES 10 2 3.0 IBM Mashup Center v2 Windows 2008 2 3.4 HatJ Linux SuSE SLES 11 2 2.66 RAM (GB) x Series Intel Xeon x64 32 Function Standalone Portal p Series Power PC 4 16 100K users LDAP x Series Intel Database for Xeon x64 32 Portal x Series Intel Xeon x64 32 Web server x Series Intel Xeon 7 Mashup Hub x Series Intel Xeon x64 10 Automation 5

Stand-alone Portal Configuration Portal v 6.1.5 + WAS v7.0.0.5 (Linux SUSE 11) Database Oracle 11g (11.1.0.6) for (Linux SUSE 10) Rational Performance Tester / HatJ (client load) Directory Server IBM Tivoli DS v6.2 100K Users (Linux SUSE 10) Web server IBM HTTP v7 (Linux SUSE 10) Mashup V2 (Windows 2008) Portal mashup integration + page builder on Linux long run configuration 6

Test Environment Solaris Cluster WebSphere Content was installed in a clustered environment and included the following components: IBM WebSphere v7.0.0.5 Deployment Manager IBM WebSphere Portal v.6.1.5 primary node on IBM WebSphere Application Server v7.0.0.5 IBM WebSphere Portal v.6.1.5 secondary node on IBM WebSphere Application Server v7.0.0.5 Oracle 10gR2 Patch 3 (10.2.0.3) for the IBM WebSphere Portal database Sun One Web Server v6.1 Fixpack 10 (web server) Sun One Directory Server v6.1 -- contains 100000 portal users IBM Mashup Center v2.0 The following specifications detail the machines used to test Portal Mashup integration and page builder feature: Portal mashup integration and page builder cluster on Solaris specifications Machine OS # of CPUs CPU Speed (GHz) WebSphere v7.0.0.5 Deployment Manager Solaris 10 2 1.6 CPU Type RAM (GB) Sun Blade 2500 2 with WAS v7.0.0.5 Solaris 10 2 1.6 Sun Fire v440 4 with WAS v7.0.0.5 Solaris 10 2 1.28 Sun Fire v240 4 Sun One Directory Server Sun Blade 2500 2 Function Deployment Manager Primary Portal node Secondary Portal node 100K users LDAP Database for Portal v6.1 Solaris 9 2 1.28 Oracle 10gR2 Patch 3 Solaris 10 2 1.28 Sun Fire v240 Sun One web 0.75 Sun Blade server v6.1 Solaris 9 2 1000 1 Web server IBM Mashup Center v2 Windows 2008 EE SP2 4 3.19 x Series 2 Mashup Hub HatJ Windows 2003 EE 1 2.4 x Series 2 Automation 7

WAS v7.0.0.5 Network Deployment (Solaris 10) Portal Cell on Solaris Configuration node 1 (WAS v7.0.0.5) (Solaris 10) node 2 (WAS v7.0.0.5) (Solaris 10) Database Oracle 10gR2 Patch 3 for (Solaris 10) Directory Server Sun One DS v6.1 100K Users (Solaris 9) Mashup V2 (Windows 2003 SP2) Rational Performance Tester / HatJ (client load) Web server Sun One WS v6.1 FP 10 (Solaris 9) Portal mashup integration + page builder on Solaris long run configuration Test Environment Windows Standalone WebSphere Content was installed in a stand-alone environment and included the following components: IBM WebSphere Portal v.6.1.5 on IBM WebSphere Application Server v7.0.0.5 Microsoft SQL Server 2005 (for the IBM WebSphere Portal database) IBM HTTP Server v7.0 (web server) IBM Tivoli Directory Server v6.1 -- contains 100000 portal users IBM Mashup Center v2.0 The following specifications detail the machines used to test the Portal Mashup integration client-side workload: 8

Portal Mashup integration client-side testing on Windows specifications Machine OS # of CPUs with WAS v7.0.0.5 IBM Tivoli Directory Server v6.1 Microsoft SQL CPU Speed (GHz) Windows 2008 Enterprise SP2 16 2.4 Windows 2003 EE SP2 Windows 2008 Enterprise SP2 4 3.0 CPU Type RAM (GB) x Series x64 Intel Xeon 16 2 2.4 x Series 2 x Series x64 Intel Xeon 4 Function Standalone Portal 100K users LDAP Database for Portal Server 2005 IBM HTTP Webserver v7 Windows 2003 EE SP2 4 3.2 x Series 2 Web server IBM Mashup Center v2 Windows 2003 EE 4 3.2 x Series 2 Mashup Hub Rational Function Tester VMware Windows XP 1 x Series 4 Automation 9

Stand-alone Portal configuration Portal v 6.1.5 + WAS v7.0.0.5 (Windows 2008) Database Microsoft SQL Server 2005 for (Windows 2008 SP2) Rational Functional Tester (client load) Directory Server IBM Tivoli DS v6.2 100K Users (Windows 2003 EE SP2) Mashup V2 (Windows 2003 EE SP2) Web server IBM HTTP v7 (Windows 2003 EE SP2) Portal mashup integration on Windows client-side configuration Test Environment z/os Cluster WebSphere Content was installed in a clustered environment and included the following components: IBM WebSphere v7.0.0.6 Deployment Manager on z/os + IBM WebSphere Portal v.6.1.5 primary node IBM WebSphere Portal v.6.1.5 secondary node on IBM WebSphere Application Server on z/os v7.0.0.6 IBM DB2 9.1 PUT0905 DS2 (for WebSphere Portal database) IBM HTTP v7 Web Server (web server) IBM Tivoli Directory Server v6.1 -- contains 100000 portal users IBM Mashup Center v2.0 The following specifications detail the machines used to test Portal Mashup integration and page builder feature: 10

Portal Mashup integration and page builder cluster on z/os specifications Machine OS # of CPUs WebSphere v7.0.0.6 Deployment Manager + + DB2 9.1 PUT0905 DS2 with WAS v7.0.0.6 + DB2 9.1 PUT0905 DS2 IBM Tivoli Directory Server v6.2 IBM HTTP Webserver v7 IBM Mashup Center v2 HatJ IBM z/os V1 R10 IBM z/os V1 R10 CPU Speed (GHz) CPU Type RAM (GB) 4 (shared) LPAR zseries (z-10) 8 4 (shared) LPAR zseries (z-10) 8 Function Deployment Manager + primary portal node + DB2- sharing Secondary Portal node + DB2-sharing Microsoft Windows 2003 EE 2 2 x Series 4 100K users LDAP Microsoft Windows 2008 Enterprise SP2 2 2 x Series 3 Web server Microsoft Windows 2008 EE SP2 4 3.19 x Series 2 Mashup Hub Microsoft Windows 2003 EE 1 2.4 x Series 2 Automation 11

WAS v7.0.0.6 DM + node 1 Portal Cluster Portal Cell on z/os Configuration Database DB2 on z/os for node 2 (WAS v7.0.0.6) Directory Server ITDS v6.1 (Windows 2003 SP2) (100K Users) Performance Tester (client load) Mashup V2 (Windows 2003 SP2) Web server ITDS v6.1 (Windows 2008) Portal mashup integration + page builder on z/os long run configuration Configuration steps for a Portal cluster with mashup integration and page builder on multi-platform (non-z/os) The section describes a summary of the steps for setting up the Portal mashup integration and page builder environments. Before configuring Portal in a stand alone or cluster configuration, you should review the information in the Planning for WebSphere Portal followed by the Mashup integration section and the Working with page builder section in the WebSphere Portal InfoCenter. The WebSphere Portal 6.1.5 InfoCenter main URL (for all platforms) can be found at: http://www.ibm.com/developerworks/websphere/zones/portal/proddoc.html For multi-platform configurations, the steps to configure the Portal mashup integration and page builder in a stand-alone and a cluster test environment: 1. These steps assume the database for WebSphere Portal, the LDAP, and the web server are already installed and configured. The individual tables above contain the specific components used for each platform. For example, DB2 v9.7 database was installed in the AIX test environment. Also note that the Portal offering CDs contain some products that were used. For 12

example, the IBM Tivoli Directory Server v6.1 for Windows 32-bit can be found on CD W-9, W-9A, and W-9B. Any required patches for the installed components were applied. 2. The Mashup Center was installed and configured (more information can be found at http://publib.boulder.ibm.com/infocenter/mashhelp/v2/index.jsp ). The Mashup Center WebSphere admin ID and password were set to be the same as the WebSphere admin ID and password used with the Portal (required for Single Sign On). The user registry configured with the Mashup Center was also the same as used for the portal configurations. 3. For cluster configurations only, install WebSphere Deployment Manager (DM) on a single machine. For the WebSphere Application Server Network Deployment v6.1.0.27 configurations, we used the CD A-2 on AIX for the 64- bit version. For the WebSphere Application Server Network Deployment v7.0.0.5 configurations, you will have to order this version from IBM. You will have to install the base WebSphere Application Server first. We enabled WebSphere Administrative security and entered a userid that will be the same on the Portal machines. Once the DM is up and running we verified we could log in to the WebSphere Administrative console before continuing. Record the port values you are using for the DM along with other values. As described in the Portal InfoCenter, change the HTTP transport timeout and the JMX Connector timeout values. Next, we added the required fix packs using the WebSphere Update Installer utility. Apply any additional fixes required for the environment. 4. For WebSphere v6.1.0.27 configurations, install the WebSphere Portal primary node (cluster) or stand-alone Portal on another machine. For configurations using the WebSphere Application Server v6.1.0.27 as its base, this will automatically be installed via the Portal Setup CD for your platform. For cluster configurations, we used the same WebSphere admin ID as used in step 2 and step 3. We verified logging on the Portal and the WebSphere Administrator console. We increased the JVM for the Portal(for example, on the primary Solaris the JVM size was set to 2 GB). 5. For WebSphere v7.0.0.5 configurations, install the WebSphere Portal primary node (cluster) or stand-alone Portal on another machine. For configurations using WebSphere Application Server v7.0.0.5 as its base, we had to acquire this separately and install the base v7.0.0.0 before adding required fixpack and fixes. For cluster configurations, we used the same WebSphere admin ID as used in step 2 and step 3.. Verify you can log in to the WebSphere Administrator console. Using the Portal Setup CD, we next installed Full Portal to an existing instance of WebSphere. We verified logging on the Portal and the WebSphere Administrator console. We 13

increased the JVM for the Portal (for example, on the primary Solaris the JVM size was set to 2 GB). 6. Transfer WebSphere Portal from Derby to remote database. Depending on our platform configuration, we followed the Portal InfoCenter to create databases, modify properties, and configure the databases for WebSphere Portal. Pre-requisite preparation for each database (such as DB2, Oracle or Microsoft SQL Server) prior to database transfer was required. We made sure any thin clients (JDBC Type 4) were installed on the primary portal machine. The tasks to setup, verify, and transfer the database on the primary (cluster) or stand-alone portal were run. The database transfer was verified. We also ran update statistics on the database. 7. For clusters only, configure the primary node to communicate with the deployment manager. Using the task to collect-files-for-dmgr, the DM was prepared for cluster configuration. We verified the DM had been re-started. The Portal search collections were deleted. 8. For clusters only, create the static cluster for the primary node. The Portal server was stopped and the wkplc.properties file was updated. The cluster-node-config-pre-federation task was run (accept the SSL certificate). After this completed, the cluster-node-config-post-federation task was run. Note that since the WAS admin user and password on the DM and the primary node were the same, we did not have to run the wp-change-portaladmin-user task. The final task to run for cluster set up is the cluster-nodeconfig-cluster-setup. Next, restart the DM and the primary node, and verify the cluster and the portal node in the cluster. 9. Configure the Portal (stand-alone or cluster) to use a remote external web server. At this point the web server was already installed on another machine. We followed the InfoCenter for the web server configuration steps. Depending on the web server, we installed the appropriate WebSphere plugin. Specify a unique web server web definition name, and copy this file to the DM machine in the cluster (or to the stand-alone portal machine) and run the script as documented in WebSphere Application Server InfoCenter. Through the WebSphere Admin console, the WCM_Host and WCM_Port variables were modified to reflect the web server machine and port. Once the DM (cluster), primary node and web server were restarted, we verified accessing the Portal through the web server. 10. Prepare and configure the default federated user registry (stand-alone and cluster). For all environments in this document, we added a directory server to the default federated user registry. Modify the wkplc.properties file for the environment, and run the tasks to validate and add the federated user 14

registry. Restart the cluster (or the stand-alone server) and verify logging in to the portal with users defined in the LDAP. 11. For WebSphere v6.1.0.27 configurations (cluster only), install the WebSphere Portal secondary node on another machine. For configurations using the WebSphere Application Server v6.1.0.27 as its base, this will automatically be installed via the Portal Setup CD for your platform. For cluster configurations, we used the same WebSphere admin ID as used in step 2 and step 3.. Verify logging on the Portal and the WebSphere Administrator console. We increased the Portal JVM size (for example, on the 4 GB Solaris secondary portal the JVM size was set to 2 GB). 12. For WebSphere v7.0.0.5 configurations (cluster only), install the WebSphere Portal secondary node on another machine. For configurations using WebSphere Application Server v7.0.0.5 as its base, we had to acquire this separately and install the base v7.0.0.0 before adding required fixpack and fixes. For cluster configurations, we used the same WebSphere admin ID as used in step 2 and step 3.. Verify you can log in to the WebSphere Administrator console. Using the Portal Setup CD, we next installed Full Portal to an existing instance of WebSphere. Verify logging on the Portal and the WebSphere Administrator console. We increased the Portal JVM size (for example, on the 4 GB Solaris secondary portal the JVM size was set to 2 GB). 13. For clusters only, add the secondary node to the static cluster. For database access (such as DB2, Oracle or Microsoft SQL Server), we made sure the required JDBC Type 4 files were copied to the secondary portal machine. Follow the steps to configure the second node in the cluster. Note that since the WebSphere admin user and password on the DM and the primary node were the same. Wait at least 30 minutes before restarting the DM and the two nodes. After restart, verify the cluster contains two portal nodes. Through the DM Administration console, update the WCM_Host and WCM_Port variables for the secondary node to reflect the web server machine and port. Re-gen the web server plugin and copy to the web server machine (and restart). Verify you can log in to the Portal through the web server. 14. Tune the Portal configurations by following the platform and component specific guidelines found in the WebSphere Portal and Lotus Web Content Management 6.1.x Performance Tuning Guide https://idoc2.swg.usma.ibm.com/portal/topic/com.ibm.wp.ent.doc_v615/tune/p erformance.html Options that were tuned included JVM heap size, session timeout, servlet engine thread pool size, data sources connection pools, statement cache, web server tuning, VMM connection pooling, database reorganization, and various portal properties files. Once the tuning was complete, we restarted all components. 15

15. Configure portal with page builder by using the Tab Menu Page Builder theme (see the Page builder Test Methodology section for details). The Portal mashup integration was configured with the Mashup Center V2 as documented in the Portal InfoCenter (see the Portal mashup integration Test Methodology section at the end of this document for details). Configuration steps for a Portal cluster with mashup integration and page builder on z/os The steps for setting up the Portal mashup integration and page builder on the z/os platform environment are documented below. Before configuring Portal in a stand alone or cluster configuration, you should review the information in the Planning for WebSphere Portal followed by the Mashup integration section and the Working with page builder section in the WebSphere Portal InfoCenter. WebSphere Portal 6.1.5 InfoCenter main URL (including z/os) can be found at: http://www.ibm.com/developerworks/websphere/zones/portal/proddoc.html The steps to install and configure the Portal mashup integration and page builder in a z/os cluster test environment are as follows: 1. These steps assume the database for WebSphere Portal, the LDAP, and the web server are already installed and configured. The configuration table above contains the specific components used for the z/os platform. For example, for the z/os configuration the DB2 on z/os Data Sharing Coupling Facility has been installed and configured. Also note that the Portal offering CDs contain some products that were used. For example, the IBM Tivoli Directory Server v6.1 for Windows 32-bit can be found on CDs W-9, W-9A, and W-9B. Any required patches for the installed components were applied. 2. The Mashup Center was installed and configured (more information can be found at http://publib.boulder.ibm.com/infocenter/mashhelp/v2/index.jsp ). The Mashup Center WebSphere admin ID and password were set to be the same as the WebSphere admin ID and password used with the Portal (required for Single Sign On). The user registry configured with the Mashup Center was also the same as used for the portal configurations. 3. Install WebSphere Deployment Manager and node agent for z/os on a single machine. The z/os WebSphere Application Server Customization Tool (zwct) was downloaded to a Windows machine. The zwct created the customization definitions, which were used to create the WebSphere 16

Application Server runtime environment on a remote system. Using the WAS 7.0 Customization Tool, the environment selected was Cell (deployment manager and an application server). The jobs for the customization definition were uploaded to the target z/os system. We recorded the port values assigned for the Deployment Manager (DM) and the node agent along with other values in the customization tool. For security customization, we used WebSphere to manage users, groups and the authorization policy. Generate the jobs after you have saved the customization variables. Follow the instructions in BBODMINS and run the jobs defined. Next, verify RRS is active before starting the DM. At this point DM was up and running. Verify you can log in to the WebSphere Administrative console before continuing. Start the node agent and verify. 4. Install second LDAP with node agent for z/os. The same z/os WebSphere Application Server Customization Tool (zwct) used in step 3 was used. Using the WAS 7.0 Customization Tool, the environment selected was Managed (custom) node. The jobs for the customization definition created were uploaded to the target z/os system. We recorded the port values assigned for the secondary node agent along with other values in the customization tool. For security customization, we used WebSphere to manage users, groups and the authorization policy. Generate the jobs after you have saved the customization variables. Make sure the DM and the primary node agent are started. Follow the instructions in BBODMINS and run the jobs defined. At this point DM is up and running make sure you can log in to the WebSphere Administrative console before continuing. Start the secondary node agent and verify. 5. Tune the WebSphere configuration before installing Portal by following the WebSphere Portal InfoCenter steps http://publib.boulder.ibm.com/infocenter/wpzosdoc/v6r1/topic/com.ibm.wp.zos.doc_v615/install/clsa_prep_nd_zos.html. Note that tuning WebSphere prior to the Portal install will circumvent a number of problems (for example, timeouts and out of memory). 6. Generate jobs to install WebSphere Portal for z/os v6.1.0.3 on the first LPAR by following the WebSphere Portal InfoCenter to configure the base portal into the primary node. We used the customization dialogs and generated the jobs. 7. Generate jobs to install the v6.1.5 feature pack on z/os on the first LPAR by following the WebSphere Portal InfoCenter. Under basic configuration tasks, we used option 5 in the customization dialogs to configure the v6.1.5 feature pack on the primary node and generated the jobs. 8. Generate jobs on the primary machine with customization dialogs for advanced configuration tasks following the WebSphere Portal InfoCenter. 17

Under advanced configuration tasks, we created the database transfer jobs, the advanced cluster scenario, and the security configuration tasks to enable security for a federated LDAP repository. 9. Run the jobs to install base Portal on the primary machine by following the instructions in EJPIND1. 10. Run the jobs to enable the v6.1.5 feature pack on the first LPAR by following the instructions in EJPIFP. 11. Run the jobs to perform database transfer on the first LPAR by following the instructions in EJPIDBT. 12. Run the jobs to create the cluster configuration for the primary node by following the instructions in EJPINDS. 13. Run the job to federate the LDAP by following the instructions in EJPISER. 14. Verify the primary node in portal server cluster has started and you can log in as the Portal admin. 15. Generate install WebSphere Portal for z/os v6.1.0.3 jobs on the second LPAR for the secondary node by following the WebSphere Portal InfoCenter. We used the customization dialogs and generated the jobs 16. Generate jobs for the advanced cluster tasks on the second LPAR for the secondary node by following the WebSphere Portal InfoCenter. Under advanced configuration tasks, we used option 5 in the customization dialogs for advanced cluster scenarios on the secondary node and generated the jobs. 17. Generate jobs to install the v6.1.5 feature pack on z/os on the second LPAR for the secondary node by following the WebSphere Portal InfoCenter. Under basic configuration tasks, we used option 5 in the customization dialogs to configure the v6.1.5 feature pack on the secondary node and generated the jobs. 18. Run the jobs to install base Portal on the second machine by following the instructions in EJPIND2. 19. Run the jobs to add the second portal to the cluster configuration by following the instructions in EJPINDS. 20. Run the jobs to enable the v6.1.5 feature pack on the second node by following the instructions in EJPIFP. 18

21. Configure the Portal cluster to use a remote external web server. Depending on the web server, we installed the appropriate WebSphere plugin. Specify a unique web server web definition name, and copy this file to the DM machine in the cluster and run the script as documented in WebSphere Application Server InfoCenter. Verify you can access the Portal and update the WCM properties. 22. Run the jobs to enable mashup integration on z/os by following the instructions in EJPIFP. On the primary node, the job to enable the mashup integration is EJPSFPUI. Follow the Portal InfoCenter on additional configuration steps for mashups. 23. Enable database session persistence in the cluster by following the instructions in http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.webs phere.zseries.doc/info/zseries/ae/tprs_cnfp.html. 24. The WebSphere Portal cluster environment was tuned using the WebSphere Portal and Lotus Web Content Management 6.1.x Performance Tuning Guide https://idoc2.swg.usma.ibm.com/portal/topic/com.ibm.wp.ent.doc_v615/tune/p erformance.html Options that were tuned included JVM heap size, session timeout, servlet engine thread pool size, data sources connection pools, statement cache, web server tuning, VMM connection pooling, database reorganization, and various portal properties files. Once the tuning was complete, we restarted all components. Test Methodology Using an automation tool, up to three workloads were selected in a combination of tests in order to verify many users running concurrently over a three to five day period. The three workloads were as follows: Page builder workload Portal Mashup integration workload Portlets and pages workload Authenticated portal users (that is, non-portal administrators) would log in and execute the steps for one of these three workloads. The specifics of each workload are defined below. Page builder Test Methodology The scenario for page builder required pre-populating 13 pages on the portal, each defined to use the Tab Menu Page Builder theme. These pages were 19

imported under the Home page, with three top level pages. Two of the new pages contained four child pages, and the third page contained two child pages. All of the pages contained up to three out of the box portlets, and each page was defined to use a different style and layout setting available. Here is an example of one of the child pages (PB_SVT_T1P1) containing out of the box portlets: The page builder workload consisted of the following steps: 1. A non-administrative user logs in to the portal. 2. The user selects the first page, and then the traverses each of the four child pages. The user waits 8 seconds between each page traversal. 3. The user selects the second page, and then the traverses each of the four child pages. The user waits 8 seconds between each page traversal. 4. The user selects the third page, and then the traverses each of the two child pages. The user waits 8 seconds between each page traversal. 5. The user clicks on the Edit mode icon, which will enable the user to add a new page at the primary level. The user adds a new page. The user will traverse to the new page; decide not to keep the page by selecting More Actions button and clicks on the Delete Page function. 6. The user traverses back to the first page. 7. The user logs out. Depending on the configuration, many users executed the page builder workload concurrently for up to 5 days. 20

Portal Mashup integration Test Methodology The scenario for Portal mashup integration consisted of two key areas: executing portal mashup tasks and executing Business Spaces tasks. A user executing the portal mashup integration function did the following: Login to Portal Create clean Workspace Delete widget from Toolbox Delete all pages Create pages Rename pages Call Portal Home Navigate to MashupContentNode Call Portal Page Navigate to MashupPage under PortalContentNode Push widgets from Hub to Portal into Toolbox Push page from Hub Deploy widgets on serveral pages Change theme of widgets Hide widgets Share page with widgets on it in edit mode to one user Delete widget from page The portal user would then perform the following business spaces steps: Login Cleanup Delete all existing business spaces visible for this user to make sure test starts empty. Create Space (loop 2 times) Create Pages in Space (Create 2 pages per space) Navigate to new Space (loop 2 times over each newly created Space) Navigate to each page within new Space Delete Spaces Logout Depending on the configuration, many users executed the portal mashup integration and business space workloads concurrently for up to 5 days. Portlets and pages Test Methodology The scenario for portlets and pages consisted of tasks to validate different types of portlets and WSRP on different pages with personalization (PZN). The types of portlets used are JSR 168 portlets, JSR 286 portlets, and WCM site areas with PZN components, composite applications, and custom themes and skins. 21

Portal Mashup integration client-side Test Methodology The client-side test was performed on the Windows configuration only. The goal of this test was to simulate (using Rational Function Tester) browser-side actions only for a long period of time -- 24 hours. The following describes the actions performed: Client-side Test Flow 1. Open Browser (Full screen) 2. Navigate to Portal Server 3. Login to Portal 4. Display Portal Version (only when logged in as admin) 5. Select Mashup-Root Page (My Mashups) Start Test Loop: Start Test 1 (description below) Start Test 2 (description below)... Loop until Test time finished (the tests are always completely executed) 6. Close Browser Note: each test can be run by its own - all created resources within the test are always cleared within the test - except on errors - this will stop the test execution. Description of Test 1 1. Create page under Mashup-Root (My Mashups) + verify page 2. Rename Page + verify changes 3. Change Page Theme (to Default Theme Columned) + verify changes 4. Install widget (Event Explorer) on page + verify 5. Rename widget + verify 6. Install widget (Event Explorer) on page + verify 7. Install widget (Web Site Display) on page + verify 8. Delete page 22

Description of Test 2 1. Create page1 under Mashup-root (My Mashups) + verify page (edit mode, check page name) 2. Create page2 under page 1 + verify page 3. Install widget (Event Explorer) on page2 + verify that widget is available 4. Rename widget + verify 5. Move widget 6. Resize widget 7. Set widget skin (to Thin Skin) + verify 8. Save page2, go to home, edit page2 + verify widget 9. Delete widget + verify deletion + save page2 10. Delete page2 + delete page1 Reliability Test Configurations The following reliability long run tests were run: Scenario AIX cluster (DB2) 24 hr Linux Stand-alone (Oracle) Solaris cluster (Oracle) Windows stand-alone (MS SQL) z/os cluster (DB2) PnP only PB only 48 hr 24 hr PMUI only 48 hr 48 hr 48 hr 48 hr PnP + PB 72 hr PnP + PMUI 72 hr Combo run All 120 hr Client-side only 24 hr Legend: 1. PB = page builder scenario 2. PMUI = portal mashup integration scenario (including business spaces) 3. PnP = portlets and pages scenario 4. Combo run All = PB + PMUI + PnP 5. Client-side = PMUI client-side scenario 6. hr = hours For the reliability tests, virtual users with an 8 12 second think time over defined number of hours were run. The total number of users was gradually ramped up until the total number of users ran on average 50% CPU. The number of users ranged from 20 to 100 users, depending on the configuration and workload scenario. For combination runs, the user would log in, run the first workload completely and continue (that is, not log out) running the second workload. 23