5.3 Parallel sysplex scenarios and tests
|
| < Day Day Up > |
|
5.3 Parallel sysplex scenarios and tests
We ran some tests using our sysplex setup. We show the configuration we used and then we define scenarios for testing.
5.3.1 Sysplex configuration used for the tests
When you have completed the sysplex configuration as described in 5.2, "Setting up the infrastructure" on page 148, the system is similar to that illustrated below, which is a high level view of this configuration.
Figure 5-8: Sample sysplex WPSPLEX
Two z/OS systems (WPS3 and WPS4) are configured in a sysplex (WPSPLEX). Three sysplex distributors (WPSPLEX1, WPSPLEX2, and WPSPLEX3) are configured in the sysplex. The DB2 tables and file systems are shared with read/write access in the sysplex.
Figure 5-9 on page 170 shows details of WebSphere Application Server, particularly the servers that are started in WebSphere Application Server on each system. It also shows details of the shared database and file systems.
Figure 5-9: WebSphere Application Server in a sysplex configuration
The behavior of WebSphere Portal in a sysplex is primarily defined by the support that WebSphere Application Server provides for its applications. These supporting functions can be combined in a few ways within the sysplex to enable parallel processing on a single system.
5.3.2 Review of the system components in the sysplex
The following terms are used when explaining various types of parallel processing. This is similar to their usage in the documentation of WebSphere Application Server.
-
z/OS system: A computer and its associated devices where z/OS or OS/390 and WebSphere Application Server for z/OS are running.
-
Sysplex: A set of z/OS or OS/390 systems communicating and cooperating with each other through certain multisystem hardware components and software services to process customer workloads. A sysplex is a single-image system complex. It is one or more z/OS or OS/390 systems that, together, provide a single system complex (for example, it may be two LPARs on the same hardware). This means that while a sysplex might be composed of multiple systems, it acts and reacts like a single instance.
-
Server: A logical grouping of server instances. All server instances within a server are identical in structure and run the same set of applications.
Administration is usually done at the server level. In addition, a server, from a management perspective, is a single entity in the sysplex. The server presents a single interface to the network and operator for control.
-
Server instance: A functional component on which WebSphere Application Server for z/OS applications runs. It is an instance of a replicated server that can provide all the functions that the server makes available. All server instances within a server are identical in structure.
A server instance has two kinds of address spaces: a Control Region (CR) and one or more Server Regions (SR). Application server code runs in a server region. A server region can be replicated based on the workload demands of the system. The control regions queue messages to the server regions.
5.3.3 Parallel processing scenarios
WebSphere Application Server offers settings to enable parallel processing both on a single system and in a sysplex. The most important settings that were used to define parallel scenarios are explained here.
-
(Server) Isolation policy: One transaction or multiple transactions per server region?
You have a choice of running server regions with an isolation policy of one transaction per server region or multiple transactions per server region. From a performance perspective, running more threads in a server region will consume less memory but at the cost of thread contention. This contention is application dependent. It is generally recommended that you use multiple transactions unless you have contention problems.
-
(Server) Replication policy: One or multiple server regions per server?
The replication policy specifies how many server regions should be started. This is used when the server regions are replicated inside the server. The default value is to replicate as needed.
One server region per server is recommended for transient objects. If you select multiple server regions per server, you can define a minimum and maximum boundary for the number of server regions to be started. Specify this using the variables MAX_SRS=<#> and MIN_SRS=<#> in the SMEUI of WebSphere Application Server at server level.
-
Multiple server instances on distinct systems in a sysplex
To create this setup, perform the configuration as described in 5.2, "Setting up the infrastructure" on page 148.
Figure 5-10 shows the resulting configuration in the SMEUI.
Figure 5-10: Sysplex in SMEUI
For more information, refer to WebSphere Application Server V4.0.1 for z/OS and OS/390: Operations and Administration, SA22-7835.
As a combination of the isolation policy, replication policy, and multiple server instances, the following scenarios were created. The summary of the scenarios can be seen in Table 5-1 on page 173.
| Scenario Description | Scenario | ||||
|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | |
| Single transaction per server region | X | ||||
| Multiple transactions per server region (recommended by WebSphere Application Server) | X | X | X | X | |
| 1 server region per server (recommended by WebSphere Application Server for transient objects) | X | X | X | X | |
| Multiple server regions per server (like horizontal scaling in WebSphere Portal for Multiplatforms) | X |
| |||
| 1 server instance | X | X | X | ||
| 2 server instances 1 system (not tested because reasonable usage was not determined) | X | ||||
| Multiple server instances in multiple systems (sysplex) (like vertical scaling in WebSphere Portal for Multiplatforms) | X | ||||
| All scenarios were executed using session affinity and no session persistence. | |||||
Scenario 1: Reference scenario with no parallel processing of incoming requests
One WebSphere Portal instance only was started (one control region in one system, and one server region defined per control region). A single transaction per server region was defined.
Scenario 2: Parallel processing of incoming requests within one server region
One WebSphere Portal instance only was started (one control region in one system, and one server region defined per control region). Multiple transactions per server region were defined.
Scenario 3: Horizontal scaling
This is similar to the scenario referred to as horizontal scaling in the documentation of WebSphere Portal for Multiplatforms. One WebSphere Portal instance only was started (one control region in one system, and two server regions defined per control region). Multiple transactions per server region were defined.
Scenario 4: Two server instances on one system
This scenario is untested, because there was no additional benefit when compared to scenario 3, assuming that an exact clone is required.
Scenario 5: Vertical scaling
This scenario is for parallel processing in a sysplex. It is similar to the scenario referred to as vertical scaling in the documentation of WebSphere Portal for Multiplatforms. Two WebSphere Portal instances were started (one control region in each system, and one server region defined per control region). Multiple transactions per server region were defined.
5.3.4 The test cases
The main intention for the test is to verify that WebSphere Portal on z/OS in a sysplex behaves like WebSphere Portal for Multiplatforms when the latter uses horizontal or vertical scaling. The intent was not to exploit all possible scenarios within the sysplex on z/OS, for example, session persistence and failover scenarios were not tested.
One problem during these tests was to show in which server instance of the portal a special scenario was executed. Two tools were used to solve this problem: the Vertical Cloning Test Portlet and a modified Login class that writes trace messages.
The Vertical Cloning Test Portlet that is used in the class IBM WebSphere Portal Version 4 Administration (WebSphere Portal for Multiplatforms) was installed. This portlet was deployed without change on the z/OS portal and displayed the Clone identification, as shown in Figure 5-11 on page 175.
Figure 5-11: Vertical Cloning Test Portlet
The Vertical Cloning Test Portlet was helpful during browser tests. It was not used during the automated test scenarios or during parallel scenarios 1 to 3, because the Host Name, Host IP Address, and Application Server Name are identical for all clones in these scenarios. To cover these cases, the Login class was modified to print a trace statement (--->SYSPLEX_TEST:Login <userid>) in the standard output each time a login was made. This modification produced similar traces to those shown in Figure 5-12 on page 176.
Figure 5-12: Standard output showing the login trace
Manual test with a browser
Log in manually via a browser to each of the portal instances. In all cases, the login can be done using the same or different user IDs. The user IDs must have the necessary access rights to access the security portlet. The access rights of some user IDs are changed on one system. The users logged in to the other portal instances verified that the modified rights are visible in all other portal instances.
Automated scenarios
An automated scenario is created with AK/Stress to log in, view some portlets, and log out again.
One user ID only used by all clients
Logging in from four clients with one user ID resulted in a successful scenario, but produced this exception in all scenarios (except scenario 1), as expected:
com.ibm.wps.util.ConcurrentModificationException
The exception is produced because if you use only one user ID with four automated clients, the probability arises that two or more clients try to access the same database fields at about the same time.
Distinct user IDs used by each client
Logging in from four clients parallel with different user IDs resulted in successful scenarios, without the exception:
com.ibm.wps.util.ConcurrentModificationException.
Portlet deployment test
WebSphere Portal on z/OS and OS/390 uses a modified procedure for portlet deployment that is in part different to that of WebSphere Portal for Multiplatforms (for details, refer to "Portlet deployment" on page 178). During the portlet deployment test, two portlets were deployed. The first part of the deployment of each portlet was done in one of the portal instances. The second part of the deployment was done on one system in the sysplex. The result was that after the second part was completed, both portlets were available in each portal instance.
5.3.5 Considerations for parallel processing of multiple portal instances
When you run multiple Portal instances you should be aware of some shared resources and their uses. Here we give some advice on shared resources.
Shared resources
For all the parallel scenarios, all resources (file systems, property files, logs, and DB2, and so on) are shared between the portal server instances that run in parallel, regardless of whether the instances run on one or multiple systems.
Portal database access
If you log in to the portal two times with the same user ID or when different users concurrently use portlets that access the same backend data, the same database records are used and modified. The portal database is set up to allow maximum concurrency with data integrity (isolation level Cursor Stability). Database rows are locked for access during a very short period only. This means that one process may read database fields and another process is able to modify the fields immediately after the read is complete.
For example, if you use the same user ID during multiple logins (regardless of whether you use multiple instances of the portal) you might see error messages like the one shown below. This message might also appear if you have only one instance of the portal and you log in more than once.
2003.07.30 10:54:41.441 com.ibm.wps.datastore.UserDescriptorPersister handleException Error during database access! Last SQL statement: {UPDATE USER_DESC SET MODIFIED = ?, LAST_LOGIN = ? WHERE ((OID = ?) AND (MODIFIED = ?))} 2003.07.30 10:54:41.441 com.ibm.wps.datastore.core.DataStoreContext handleException com.ibm.wps.util.ConcurrentModificationException: Database has been changed since creation of data object! ObjectID = 10 at com.ibm.wps.datastore.core.BasePersister.storeUpdate(BasePersister.java:208)
Log files and standard output files
For the tests above:
-
All property files are shared.
-
The standard output file is written to the job log of each server region (each instance of the portal).
-
The portal log file (wps<timestamp>.log in directory WPS_PATH/log) is written separately for each server region (each instance of the portal).
-
The logs of WebSphere Transcoding Publisher (TranscoderMessagesx.log and TranscoderTracex.log) are written once only. All entries from all portal instances are accumulated into these files.
Portlet deployment
Portlet deployment is performed in two parts, as described in the topic "Deploying portlets on z/OS and OS/390" in the InfoCenter of WebSphere Portal for z/OS and OS/390.
Administrative tasks on WebSphere Portal using the administration portlet for installing portlets. This step generates job files with descriptions of further administration steps to be done in WebSphere Application Server. Changes to the portal configuration are effective immediately but the portlets are operational only after the next step. These tasks can be executed by any instance of the portal. The generated job files are all written into the same directory in shared HSF.
Administrative tasks are performed on WebSphere Application Server. Here, you install new portlets or update or delete existing ones by deploying them using the WPAConfig script and the jobs created by the administration portlet. The WPAConfig script can be executed on any z/OS system of the sysplex. It searches for jobs created by the administration portlet and executes them one by one in the sequence of their generation. During this step, any job files from all portal instances will be processed. After the successful execution of the tasks above, the portlets are available on each instance of the portal.
| Important | During the second phase of the deployment, WebSphere Application Server stops and restarts each WebSphere Portal instance (stops each control region and the associated server regions). During the tests above, the stop and restart cycle frequently failed. To avoid this situation, stop all WebSphere Portal instances before you start the WPAConfig script (or the corresponding JCL procedure). |
Summary
The three tests above were successfully executed for the parallel processing scenarios 1, 2, 3, and 5. The outcome was as expected, that is, the same as for WebSphere Portal for Multiplatforms, including the production of this exception in test case 2:
com.ibm.wps.util.ConcurrentModificationException
In addition, we have seen that if WebSphere Application Server is configured in the sysplex, it is very easy to install WebSphere Portal. There are no differences between portlet deployment in a single system and portlet deployment in a sysplex.
All migration steps from PTF2 to PTF3 that were executed were done on one system in the sysplex. All WebSphere Portal instances were successfully migrated, without any change in the migration procedure compared to migration in a single system installation.
|
| < Day Day Up > |
|
