IBM®
Skip to main content
    Country/region [select]      Terms of use
 
 
    
     Home      Products      Services & industry solutions      Support & downloads      My IBM     
developerworks > My developerWorks >  Dashboard > WebSphere Virtual Enterprise > Home > Customer focused testing for WebSphere Virtual Enterprise and WebSphere Compute Grid for zOS
developerWorks
Log In   View a printable version of the current page.
Customer focused testing for WebSphere Virtual Enterprise and WebSphere Compute Grid for zOS
Browse space Browse Space    
Added by finn, last edited by finn on Nov 10, 2009  (view change)
Labels: 
(None)

Overview

This document provides a general overview of the testing scenario and environment details.

Audience

The document is intended for technical sales, marketing, or the interested customer who wants to learn more about some of the common features found in WebSphere Virtual Enterprise and WebSphere Extended Deployment Compute Grid.

The objective of this testing was to focus on areas that customers had identified as areas for improvement on the z/OS platform. There were three main areas of focus during this cycle:

  1. How to migrate from WebSphere Virtual Enterprise Version 6.1.0.5 and WebSphere Application Server Network Deployment Version 6.1.0.21 to the latest version of WebSphere Virtual Enterprise/WebSphere Compute Grid and WebSphere Application Server Network Deployment Version Version 6 or Version 7. This included enabling 64 bit support.
  2. Focus on Compute Grid specific testing.
  3. Increased effort in termination testing to avoid abends.

Environmental details

The configuration tested was on z/OS system hardware.

  1. WebSphere® Application Server Network Deployment Server Version 6.1.0.25
  2. WebSphere Virtual Enterprise 6.1.1.1 (Formerly Extended Deployment Operations Optimization)
  3. Compute Grid Version 6.1.1.1

The environment was configured having multiple applications, multiple dynamic clusters, two on demand routers (ODRs) with Global Security enabled for selected tests. WebSphere Compute Grid was configured also in the environment including schedulers and endpoints.

Configuration Components:

  1. Global Security
  2. Ports
    • Default ports used for WebSphere Application Server and federation.
    • Standard ports for WebSphere Virtual Enterprise, ODRs and WebSphere Compute Grid.

Verification of the Environment

A. Installation and migration of WebSphere Virtual Enterprise and WebSphere Compute Grid

The purpose of these tests were to move systems from older levels of WebSphere® Application Server Network Deployment and WebSphere Extended Deployment to the latest levels of WebSphere Application Server Network Deployment, WebSphere Virtual Enterprise and WebSphere Compute Grid. This includes rolling migration where each server, Dmgr is migrated one at a time. Also to make sure that all servers, Dmgrs, and node agents could be run in 64 bit mode.

Validation criteria

  • All servers, dmgrs and node agents are on the correct level.
  • All can run in 64-bit mode.
  • Basic functionality works throughout the process and at the end.

Operational profile

  • Deployment Manger
  • Dynamic cluster
  • ODR
  • Validation

Tests run to validate

  • XD611_Z_MIGRATION011 - z/OS: WAS 6.1/XD 6.10 (PTF) => WAS6.1/XD 6.11 (GA) 31 bit and 64 bit testing
  • XD611_Z_MIGRATION012 - z/OS: WAS 7.0/XD 6.10 (PTF) => WAS7.0/XD 6.11 (GA) 31 bit and 64 bit testing
  • XD611_Z_MIGRATION013 - z/OS: WAS 6.1.0/XD 6.10 (PTF) => WAS7.0/XD 6.11 (GA) 31 bit and 64 bit testing

Test description

Levels will vary depending on what is the desired level at the end of migration.

This test is designed to determine whether a current WebSphere Extended Deployment Verion 6.1.0 and WebSphere Application Server Verion 6.1.0 customer can move to a new cell with WebSphere Extended Deployment Version 6.1.1.0 and WebSphere Application Server Verion 6.1.0. The key to this scenario is that you are staying on the same release of WebSphere Application Server, and in this case it is WebSphere Application Server Version 6.1.0.

Even though you may or not may go to a higher WebSphere Application Server PTF, the key is that you stay on the same release of WebSphere Application Server. As long as you are on the same release, then you can use the following steps.

  1. Start with WebSphere Extended Deployment Version 6.1.0.5 driver with WebSphere Application Server Version 6.1.0, which is P008201 CF5090339775 AK78240.
  2. Add in all the dynamic cluster servers and ODRs, then start them to make sure all are running. Serve application A, and if successful, shut down the cell.
  3. Upgrade WebSphere Application Server Version 6.1.0 to the latest PTF in the field (since WebSphere Virtual Enterprise will prerequisite that PTF.).
  4. Start all the servers again so that the WebSphere Application Server postinstaller updates WebSphere Application Server Version 6.1.0.
  5. Perform the WebSphere Virtual Enterprise work in the next step. Shut down the cell.
  6. Mount the WebSphere Extended Deployment Version 6.1.1 SMPE hfs at /usr/lpp/zWebSphereXD/V6R1M1.
  7. Unaugment DG from the current cell
  8. From the dmgr node:
    • cd /WebSphere/ND/DeploymentManager/bin 
      ./manageprofiles.sh -unaugment -profileName default -templatePath /WebSphere/ND/DeploymentManager/profileTemplates/wxddg_augment -ignoreStack
  9. Start the dmgr
  10. From all the application server nodes, run the syncNode.sh command to synchronize the nodes.
    • cd /WebSphere/ND/AppServer/bin 
      ./syncNode.sh   dmgrSystem dmgrPport -conntype soap -username userid -password userpw
  11. Stop the dmgr
  12. Remove the DG links and directories
  13. From the dmgr node:
    • cd /WebSphere/ND/DeploymentManager/bin 
      ./removeOG610.sh /usr/lpp/zWebSphereXD/V6R1M1 /WebSphere/ND/DeploymentManager userid userpw
  14. Start the dmgr
  15. From all the application server nodes, run the removeOG610.sh
  16. cd /WebSphere/ND/AppServer/bin 
    ./removeOG610.sh /usr/lpp/zWebSphereXD/V6R1M1 /WebSphere/ND/AppServer userid userpw
  17. Stop the dmgr
  • Link WebSphere Virtual Enterprise and WebSphere Compute Grid, and perform upgrades
  1. From the dmgr node:
    • cd /WebSphere/ND/DeploymentManager/bin 
      ./upgradeVECG611.sh /usr/lpp/zWebSphereXD/V6R1M1 /WebSphere/ND/DeploymentManager userid userpw
  2. Start the dmgr
  3. From all the application server nodes, run the upgradeVECG611.sh. This example shows just one application server running.
    • cd /WebSphere/ND/AppServer/bin 
      ./upgradeVECG611.sh /usr/lpp/zWebSphereXD/V6R1M1 /WebSphere/ND/AppServer userid userpw
  4. Stop the dmgr
  • Allow JAVA2 security access to the new 611 filesystem

Edit the server.policy file

  1. Edit binary file /WebSphere/ND/DeploymentManager/profiles/default/properties/server.policy and add in these two lines: 
    grant codeBase "file:/usr/lpp/zWebSphereXD/V6R1M1/lib/-" { permission java.security.AllPermission; };
grant codeBase "file:/usr/lpp/zWebSphereXD/V6R1M1/-" { permission java.security.AllPermission; };

This example shows just one of the application server nodes, but you must edit all of them.

  1. Edit the following two lines: 
    grant codeBase "file:/usr/lpp/zWebSphereXD/V6R1M1/lib/-" { permission java.security.AllPermission; };
grant codeBase "file:/usr/lpp/zWebSphereXD/V6R1M1/-" { permission java.security.AllPermission; };
  2. Start the cell.
  3. Start all the tasks. Note: The postinstaller will not run for WebSphere Extended Deployment, because by performing the link step, the service-level.properties files were set to be the same.
  4. Serve application A.
    • Everything is in 31 bit mode. Ensure all servers can now be modified and created as 64 bit mode.
  5. Stop everything but the dmgr. With just the dmgr running, from the administrative console, click the 64 bit box for the dmgr and save the change.
  6. Stop the cell, and start the dmgr.
  7. After the dmgr is running, start the nodeagents. Change the ODR and dynamic cluster servers to 64 bit mode, and save and synchronize the changes.
  8. Start the ODR and dynamic cluster servers. They should now be in 64 bit mode. Serve application A again thru the ODR and dynamic cluster servers.
  9. Through the administrative console, create a new ODR and a new dynamic cluster server. Ensure thatyou click the 64 bit box.
  10. Save and synchronize the changes. Display these servers again
    to ensure the 64 bit box is still checked, and that when started they are in 64 bit mode.

B. Compute Grid testing

The purpose of this testing was to focus on different features that WebSphere Compute Grid provides and make sure it
functions in the way it is designed.

Validation criteria

  • WebSphere Compute Grid installs and jobs can run successfully.
  • Job management console works where appropriate.
  • Jobs run without causing memory leaks.

Operational profile

  • Deployment manager
  • Scheduler cluster
  • EndPoint cluster

Validation

Tests run to validate:

  • BUSGRID100 - Native WSGRID - setup and job submission
  • BUSGRID101 - Native WSGRID - simple scenarios
  • Prereq set up is minimum 1 JobScheduler and 1 Endpoint. Medium job
  • Straight submission: submit 1 job, wait for XD job to finish. XD job state = "Ended". Proxy job RC = 0
  • Submission/Restart: submit 1 job (with forced_cancel property in xjcl), XD job state = "Restartable". Proxy job RC = 4084. Restart proxy. Proxy = 0, XD = Ended.
  • Submission/Restart: submit 1 job, cancel XD job while it is executing. XD job state = "Restartable". Proxy job RC = 4088 (-8). Restart proxy. XD job ="Ended", Proxy job RC = 0
  • Submission/Cancel proxy: submit 1 job. Wait for XD job in "executing", cancel Proxy job. Proxy = abend. XD job = "Restartable"
  • Submission/ExecutionFailed: submit 1 job, trigger execution failed (how ??). XD job state = "ExecutionFailed". Proxy job RC = 4080
  • Straight submission scenario but with 30 jobs
  • BUSGRID103 - Native WSGRID - stress
  • Straight Submission with 30 short jobs
  • Straight Submission with 100 short jobs
  • Straight Submission with 300 short jobs
  • Straight Submission with 100 medium jobs
  • Straight Submission with 100 long jobs
  • Straight Submission with 999 medium jobs
  • BUSGRID002 - M0: Simple grid sample application
  • BUSGRID067 - WSGrid failover
    1. Job cancel
    2. Scheduler failover
    3. Job restart
  • BUSGRID070 - Parallel Job Manager - Advanced failover
  • Endpoint failover
  • Scheduler failover
  • Node failover
  • Database failover
  • SVT_Z_CSI - 3 day stress run with CG and HTTP traffic.
  • Verify no memory leaks while running jobs and HTTP traffic.

Basic setup

Instructions for running on WebSphere Extended Deployment Version 6.1.0:

  1. Install WebSphere Extended Deployment
  2. Setup Business Grid
  3. Install simpleci.ear
  4. Run simplecixjcl.xml from cli
    • Jobs are completed. They will either go into a cancel/submitted/or complete state.

Setup Instructions for SimpleCI Business Grid on z/OS

1. Configure servers for Business Grid

A. Create scheduler and endpoint node groups

Follow the steps in NODEGROUPCONFIG002 to create two nodegroups:

  • nodegroup 1: endpoint_ng
    • member: ndnode2
  • nodegroup 2: scheduler_ng
    • member: ndnode1

B. Set the GenerateUniquePorts custom properties if running on same system

From the administrative console:

  1. CExpand System administration > Node groups > [node group name] > Custom Properties
  2. Click New, and type the following:
  • Name: GenerateUniquePorts
  • Value: true
  1. Click OK and Save.

C. Create scheduler and endpoint dynamic clusters

Follow the steps in DYNAMICCLUSTER001 to create two dynamic clusters:

  1. dynamic cluster 1: dc_endpoint
    • node group: endpoint_ng
  2. dynamic cluster: dc_scheduler
    • node group: scheduler_ng

In WebSphere Extended Deployment Version 6.0.2 testing, the environment is run without security on. Currently, there is not a setup.

2. Set dc_scheduler as the job scheduler host

  • System administration > Job scheduler
  • From the Scheduler hosted by drop-down menu, select dc_scheduler
  • Click Apply, then save your changes.

3. Verify Derby LRS database automatically created

In OMVS, verify that the following directory exists:

/WebSphere/ND/AppServer/profiles/default/gridDatabase/LRSCHED
non-Z/OS: ssh into dc_scheduler /opt/WAS61/profiles/node/gridDatabase/LRSCHED

4. Set security roles

  • System administration > Job scheduler > Security role to user/group mapping
  • In the Select column, check both boxes for lrsubmitter and lradmin.
  • Click Look up users.
  • In the Search String box, enter your user ID and click Search.
  • Under Available, select your userID, press [>>] to add it to the selected list, and click OK.
  • Verify that your user ID appears under the Mapped Users column for each, and click OK.
  • Click Save.

5. Install shipped SimpleCI application

  • Expand Applications > Install New Application
  • Select Remote file system, and enter the following path: 
    /WebSphere/ND/DeploymentManager/installableApps/SimpleCI.ear
  • Click Show me all installation options and parameters, and click Next.
  • Click the Generate Default Bindings checkbox, and click Next.
  • Click Continue.
  • Step 1: uncheck Deploy enterprise beans and click Next.
  • Step 2: Check the box for SimpleCIEJB, select dc_endpoint as the cluster to host the application, and click Apply.
  • Verify that the module is set to be hosted on dc_endpoint, and click Next.
  • Click on the last step for the Application (accepting the defaults for all remaining settings).
  • Click Finish and wait for the application to install.
  • Click Save.

6. Verify Derby LREE database created

In OMVS, verify that the following directory exists:
/WebSphere/ND/AppServer2/profiles/default/gridDatabase/LREE
non-Z/OS: ssh into dc_endpoint /opt/WAS61/profiles/node/gridDatabase/LRSCHED

7. Determine the port for the scheduler's Job Management Console

  • Expand Servers > All servers > dc_scheduler_ndnode1 > Ports
  • Note the port listed for WC_defaulthost_secure (e.g. 9445)
    non-Z/OS: 9443

8. Restart the cell

  • Stop all servers
  • Start the Deployment Manager, the two nodeagents, the scheduler server, and the endpoint server.

9. Open the Job Management Console

  • In a browser window, open the following URL: 
    https://<hostname>:<port from step 8>/jmc/login.jsp
  • Enter your user ID and password to log in.

10. View jobs

  • Expand Job Management > View Jobs
  • Verify that you receive this message:
    There is no job in the job scheduler.

11. Submit the SimpleCI job

  • Expand Job Management > Submit a job.
  • Save this xJCL file to the system with the browser:
  • Under Local file system > Specify path to xJCL, enter the fully-qualified path to SimpleCIxJCL.xml (Browse if necessary) and press Submit. (Wait for the job to submit successfully.)
  • Job Management > View Jobs
  • Refresh the view by pressing the circle beside the State column label.
  • Verify that the job changes from the Submitted state to the Executing (3 seconds) and Ended states successfully.

Native WSGRID setup after basic setup (example only)

  • The native WSGrid set up requires DB2.
  • Start DB2 ( on sdsf panel: /-DSN8 START DB2)
  • Add MQ STEPLIB to app server JCL proc

Note: These instructions are defined for our setup, and shown here as example.

A. edit USER.PROCLIB

  • create member MQSTEP that contains the following lines: 
    //         DD DSN=MQSERIES.V6R0M0.SCSQLOAD,DISP=SHR 
//         DD DSN=MQSERIES.V6R0M0.SCSQAUTH,DISP=SHR
  • create member MQASRZ that contains the following lines: 
    //* Output DDs                                   
//*                                              
//CEEDUMP   DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE  
//SYSOUT    DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE  
//SYSPRINT  DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE  
//*                                              
//*Steplib Setup                                 
//*                                              
//         INCLUDE MEMBER=WASSTEP                
//         INCLUDE MEMBER=DB2STEP                
//         INCLUDE MEMBER=MQSTEP
  • update WAS configuration to use new STEPLIB includes
  • Define MQ queues

From SDSF

  1. Start MQ. Wait for the queue manager to complete its start up.
    -M600 START QMGR PARM(M600ZPRM)
    Note: You will not be able to define local queue if the queue manager is not started.
  2. Define input queue. WASIQ is the queue name. Make note of this name because we you will use it later.
    -M600 DEFINE QLOCAL(WASIQ) SHARE
  3. Define output queue. WASOQ is the queue name. Make note of this name because you will use it later.
    -M600 DEFINE QLOCAL(WASOQ) SHARE
  • Run installWSGrid.py script with the following input parameters: 
    wsadmin.sh -f installWSGridMQ.py    -install {-cluster <cluster name> | -node <node name> -server <server>}
               -mqroot <dir of mq root>
               -qmgr <queue manager name>
               -inqueue <input queue as defined above>
               -outqueue <output queue as defined above>

For example:

./wsadmin.sh -f installWSGridMQ.py -install -cluster scheduler -mqroot /usr/lpp/mqm/V6R0M0 -qmgr M600 -inqueue WASIQ -outqueue WASOQ
./wsadmin.sh -f installWSGridMQ.py -install -cluster scheduler -mqroot  /mqSeries/mqs600/mqm/V6R0M0 -qmgr M4P0 -inqueue WASIQ -outqueue WASOQ
  1. Create the WSGRID load module:
  2. FTP the "unpackWSGRID" script to system in ascii mode. This is a REXX script, so it must be in EBCDIC on USS. If you are using the Version 6.1.1 build, the unpackWSGRID script is in the /longRunning directory.
  • unpackWSGRID: unpackWSGRID
  1. Set permission:
    chmod 777 unpackWSGRID
  2. Perform unpack
    unpackWSGRID /WebSphere/ND/AppServer (where /WebSphere/ND/AppServer is the server that started with MQ )

This step should be performed for each unique user who will submit a native WSGrid job.

The following is an example output: 

/u/USER26> unpackWSGRID /WebSphere/ND/AppServer
Unpack WSGRID with values:

   WAS_HOME=/WebSphere/ND/AppServer
   HLQ     =USER26
   WORK_DIR=/tmp
   BATCH   =INTERACTIVE
   DEBUG   =NODEBUG

Continue? (Y|N)
Y
User response: Y
Unzip /WebSphere/ND/AppServer/bin/cg.load.xmi.zip
extracted: cg.load.xmi
Move cg.load.xmi to /tmp
Delete old dataset 'USER26.CG.LOAD.XMI'
Allocate new dataset 'USER26.CG.LOAD.XMI'
Copy USS file /tmp/cg.load.xmi to dataset 'USER26.CG.LOAD.XMI'
Delete USS file /tmp/cg.load.xmi
Delete old dataset 'USER26.CG.LOAD'
Go to TSO and issue RECEIVE INDSN('USER26.CG.LOAD.XMI') to create CG.LOAD
  1. Go to TSO, ISPF, option 6, and type in the line in bold in the previous step:

The following output will display:

Press enter to end. You will see output similar to:

Submit native WSGrid job

  • Modify the example JCL for the appropriate load data set name, and path to the XD job xJCL.
  • native.jcl: native.jcl
  • Submit the modified native.jcl the same way that is used to submit Java WSGrid. I use the submit script (submit native.jcl)
    submit: submit script for z/OS.

Termination testing

The purpose of this testing was focus on different types of server termination. The purpose was to make sure
servers came down clean with no abends.

Validation criteria

  • Servers can be stopped and no abends occur.
  • Operational profile
  • Deployment Manger
  • ODR
  • Dynamic cluster with at least 2 servers started
  • 2 node agents at least started.

Validation

Tests run to validate

  • CUSTOMER_1000 - Test shutdown of servers
    1. This test included P bbodmnc to make sure all started servers, dmgr and node agents ran without errors.
  • CUSTOMER_1001 - Test shutdown of DMGR
    1. This test included P bbodmgr to make sure dmgr ran without errors even with other servers up.

Reference

The following Information is available for reference in addition to the steps outlined previously:

WebSphere Virtual Enterprise Version 6.1.1 Program Directory

Customization Guide and Migration Guide for WebSphere Extended Deployment V6.1.1 for z/OS

    About IBM      Privacy      Contact