Websphere Portal on Z/OS

5.2 Setting up the infrastructure

In the configuration sample here, the following infrastructure is assumed: an existing parallel sysplex with coupling facility, shared HFS, WLM running in goal mode, and DB2 Version 7 running in datasharing mode.

5.2.1 Sysplex distributor

To set up a sysplex distributor, you need to enable an XCF network, define one or more virtual IP addresses, and a routing protocol, such as Routing Information Protocol (RIP) or Open Shortest Path First (OSPF). The routing protocol is an essential element of this setup, because availability and routes of the IP address can change dynamically. Therefore, it is necessary to propagate routes dynamically using a routing protocol. In the sample configuration, OSPF is chosen to manage routing within the sysplex.

A sysplex distributor defines a virtual IP address (VIPA) that represents a sysplex-wide IP address known to all systems in a sysplex. Therefore, such an address is also called a cluster address. The VIPA distributes IP requests from the distributing IP stack to other IP stacks (including its own) through the internal XCF network of the sysplex. Distribution is done depending on workload within the sysplex.

In the sample configuration, the systems WPS3 and WPS4 are from an existing sysplex. System WPS3 owns the distributing IP stack and WPS4 is defined as the VIPA backup.

Three VIPAs are defined to allow for more than four ports to be distributed within the sysplex. This is necessary because the TCP/IP APAR (PQ65205), which allows the distribution of more than four ports per VIPA, is not applied.

5.2.2 Cluster addresses

The following IP address is associated with the DNS name:

9.152.88.233 = wpsplex1.boeblingen.de.ibm.com

This address distributes incoming requests to the WebSphere Application Server LDAP (port: 1389), the WebSphere Application Server daemon (port: 5555 and 5556), and the System Management of WebSphere Application Server (port: 9000).

9.152.88.234 = wpsplex2.boeblingen.de.ibm.com

This second address distributes requests to WebSphere Portal (port: 8082), the HTTP server (port: 80), the sample application of WebSphere Application Server (port: 8081), and the WebSphere Portal LDAP (port: 2389).

9.152.88.235 = wpsplex3.boeblingen.de.ibm.com

This third address distributes requests for TELNET (port: 23), OTELNET (port: 623), and FTP (port: 21).

5.2.3 XCF addresses

XCF addresses are the IP addresses of the single systems in the internal XCF network of the sysplex. XCF for TCP/IP is implemented through VTAM-to-VTAM connections. It is enabled in z/OS and VTAM® either by specifying startup parameters XCFINIT=YES or HPR=RTP, or by activating the VTAM major node ISTLSXCF. For configuration details, refer to z/OS Communications Server: SNA Network Implementation, SC31-8777.

The XCF devices for TCP/IP (EZAXCFS4, and so on) are dynamically generated by specifying IPCONFIG DYNAMICXCF in the profile TCP.PROFILE. The sysplex distributor then distributes incoming client requests to the XCF addresses depending on availability and workload, or by complying with policies specified for the policy agent of the requested services.

The XCF addresses are:

• 9.152.88.35 for system WPS3

• 9.152.88.36 for system WPS4

5.2.4 Static IP addresses

Static IP addresses are the IP addresses of devices that are physically connected to the intranet or Internet.

The static IP addresses for WPS3 are:

The static IP addresses for WPS4 are:

LINKETH is the device that was previously defined for the system WPS3 and WPS4, respectively.

LINKVIA is the device that was added per stack, because device LINKETH is not connected to a subnet that provides OSPF as the routing protocol.

In a real, high availability solution including sysplex distributor and WebSphere Application Server, the IP name of the static IP address should be defined on the OSPF-managed device, or should be a static VIPA. This is not the case in the test environment.

If, for example, device LINKETH is not accessible in the test environment, then IP names boewps3 and boewps4 are not available. This is because in the test environment, LINKETH and LINVIA are fast Ethernet devices defined through QDIO physically sharing the same device. Therefore, the test environment demonstrates the principles and is not an actual high availability solution.

Figure 5-1 on page 151 shows the principles of a sysplex distributor.

Figure 5-1: Principles of a sysplex distributor

That is, for the client, the System Management of WebSphere Application Server is accessible as if it was a single server, under a single cluster address (wpsplex1.boeblingen.de.ibm.com). In this figure, a client, for example, the System Management End User Interface (SMEUI) of WebSphere Application Server, connects through the sysplex distributor to the System Management of WebSphere Application Server. The client request is distributed to WPS4, depending on the workload and availability. For the client, this processing is transparent.

Implementation of the sysplex environment

As a first step, the IP configuration profiles for the systems are updated. Example 5-1 and Example 5-2 are sample profiles for the test environment.

Example 5-1: TCP.PROFILE of system WPS3

IPCONFIG SYSPLEXROUTING DATAGRAMFWD DYNAMICXCF 9.152.88.35 255.255.255.240 1 VIPADYNAMIC VIPADEFINE MOVE IMMEDIATE 255.255.255.248 9.152.88.233 9.152.88.234 VIPADEFINE MOVE IMMEDIATE 255.255.255.248 9.152.88.235 VIPADISTRIBUTE DEFINE 9.152.88.233 PORT 1389 5555 5556 9000 DESTIP 9.152.88.35 9.152.88.36 VIPADISTRIBUTE DEFINE 9.152.88.234 PORT 80 2389 8081 8082 DESTIP 9.152.88.35 9.152.88.36 VIPADISTRIBUTE DEFINE 9.152.88.235 PORT 21 23 623 DESTIP 9.152.88.35 9.152.88.36 ENDVIPADYNAMIC . . HOME 9.152.87.143 LINKETH 9.152.64.117 LINKVIA

Example 5-2: TCP.PROFILE of system WPS4

IPCONFIG SYSPLEXROUTING DATAGRAMFWD DYNAMICXCF 9.152.88.36 255.255.255.240 1 ; VIPADYNAMIC VIPAbackup 100 9.152.88.233 VIPAbackup 100 9.152.88.234 VIPAbackup 100 9.152.88.235 ENDVIPADYNAMIC . . HOME 9.152.87.144 LINKETH 9.152.64.118 LINKVIA

Next, OSPF routing for the sysplex IP addresses is set up. This configuration depends on your network topology, and is required for the sysplex distributor to manage dynamic IP addresses.

Example 5-3 shows the OSPF configuration for the system that owns the sysplex distributor, WPS3.

Example 5-3: OSPF definition of system WPS3

RouterID=9.152.64.117; Area Area_Number=0.0.0.3 stub_Area=YES Authentication_Type=Password; OSPF_Interface IP_Address=9.152.64.117 Name=LINKVIA Subnet_mask=255.255.255.240 MTU=1492 Attaches_To_Area=0.0.0.3 Hello_Interval=1 Dead_Router_Interval=4 Authentication_Key="xx"; OSPF_Interface IP_Address=9.152.88.* Name=XCFs Subnet_mask=255.255.255.240 MTU=1492 Attaches_To_Area=0.0.0.3 Hello_Interval=1 Dead_Router_Interval=4 Authentication_Key="xx"; OSPF_INTERFACE IP_Address=9.152.88.232 Name=VIPAs Subnet_mask=255.255.255.248 MTU=1492 Attaches_To_Area=0.0.0.3 Hello_Interval=1 Dead_Router_Interval=4 Authentication_Key="xx"; INTERFACE IP_Address=9.152.87.143 Name=LINKETH Subnet_mask=255.255.248.0; AS_Boundary_routing Import_Direct_Routes=YES Import_Static_Routes=YES;

Example 5-4 shows the result of a D TCPIP command.

Example 5-4: OSPF interfaces and neighbours of WPS3, that own the VIPAs

D TCPIP,,OMPR,OSPF,INTERFACE EZZ7849I INTERFACES 591 IFC ADDRESS PHYS ASSOC. AREA TYPE STATE #NBRS #ADJS 9.152.88.35 EZASAMEMVS 0.0.0.3 P-2-MP 1 0 0 9.152.88.35 EZAXCFS8 0.0.0.3 P-2-MP 1 0 0 9.152.88.35 EZAXCFS6 0.0.0.3 P-2-MP 1 0 0 9.152.88.35 EZAXCFS2 0.0.0.3 P-2-MP 1 0 0 9.152.88.233 VIPL099858E9 0.0.0.3 VIPA N/A N/A N/A 9.152.88.234 VIPL099858EA 0.0.0.3 VIPA N/A N/A N/A 9.152.88.235 VIPL099858EB 0.0.0.3 VIPA N/A N/A N/A 9.152.64.117 LINKVIA 0.0.0.3 BRDCST 32 3 2 9.152.88.35 EZAXCFS4 0.0.0.3 P-2-MP 16 1 1 D TCPIP,,OMPR,OSPF,NEIGHBOR EZZ7851I NEIGHBOR SUMMARY 593 NEIGHBOR ADDR NEIGHBOR ID STATE LSRXL DBSUM LSREQ HSUP IFC 9.152.64.116 9.152.94.197 128 0 0 0 OFF LINKVIA 9.152.64.118 9.152.64.118 8 0 0 0 OFF LINKVIA 9.152.64.115 9.152.94.193 128 0 0 0 OFF LINKVIA 9.152.88.36 9.152.64.118 128 0 0 0 OFF EZAXCFS4

Example 5-5 shows the OSPF configuration for the other system in the sysplex, in the test environment, WPS4.

Example 5-5: OSPF definition of system WPS4

RouterID=9.152.64.118; Area Area_Number=0.0.0.3 stub_Area=YES Authentication_Type=Password; OSPF_Interface IP_Address=9.152.64.118 Name=LINKVIA Subnet_mask=255.255.255.240 MTU=1492 Attaches_To_Area=0.0.0.3 Hello_Interval=1 Dead_Router_Interval=4 Authentication_Key="xx"; OSPF_Interface IP_Address=9.152.88.* Name=XCFs Subnet_mask=255.255.255.240 MTU=1492 Attaches_To_Area=0.0.0.3 Hello_Interval=1 Dead_Router_Interval=4 Authentication_Key="xx"; OSPF_INTERFACE IP_Address=9.152.88.232 Name=VIPAs Subnet_mask=255.255.255.248 MTU=1492 Attaches_To_Area=0.0.0.3 Hello_Interval=1 Dead_Router_Interval=4 Authentication_Key="xx"; INTERFACE IP_Address=9.152.87.144 Name=LINKETH Subnet_mask=255.255.248.0; AS_Boundary_routing Import_Direct_Routes=YES

Example 5-6 shows the result of a D TCPIP command.

Example 5-6: OSPF interfaces and neighbours of WPS4

D TCPIP,,OMPR,OSPF,INTERFACE EZZ7849I INTERFACES 969 IFC ADDRESS PHYS ASSOC. AREA TYPE STATE #NBRS #ADJS 9.152.88.36 EZASAMEMVS 0.0.0.3 P-2-MP 1 0 0 9.152.88.36 EZAXCFS8 0.0.0.3 P-2-MP 1 0 0 9.152.88.36 EZAXCFS6 0.0.0.3 P-2-MP 1 0 0 9.152.88.36 EZAXCFS3 0.0.0.3 P-2-MP 16 1 1 9.152.88.36 EZAXCFS2 0.0.0.3 P-2-MP 1 0 0 9.152.64.118 LINKVIA 0.0.0.3 BRDCST 32 3 2 D TCPIP,,OMPR,OSPF,NEIGHBOR EZZ7851I NEIGHBOR SUMMARY 971 NEIGHBOR ADDR NEIGHBOR ID STATE LSRXL DBSUM LSREQ HSUP IFC 9.152.88.35 9.152.64.117 128 0 0 0 OFF EZAXCFS3 9.152.64.117 9.152.64.117 8 0 0 0 OFF LINKVIA 9.152.64.116 9.152.94.197 128 0 0 0 OFF LINKVIA 9.152.64.115 9.152.94.193 128 0 0 0 OFF LINKVIA

5.2.5 DB2 consideration

DB2 Version 7 is configured in datasharing mode. On WPS3, the DB2 subsystem is started with the subsystem name SG91, and on WPS4, it is started with the subsystem name SG92. The database group name is DSN9 and the DB2 Location Name is WPSDSN9. For details on enabling datasharing mode, see DB2 Data Sharing: Planning and Administration, SC26-9935.

5.2.6 Shared HFS

The installation directory of WebSphere Portal (WPS_PATH) is made accessible by using the same directory name (/usr/lpp/PortalServer) on all systems in the sysplex.

You can see the shared HFS setup in Figure 5-2.

Figure 5-2: Overview of the shared HFS of WebSphere Portal

5.2.7 Configuring WebSphere Application Server in a sysplex

WebSphere Application Server is bootstrapped to the first system (WPS3) in the sysplex and is extended to the other systems in the sysplex (WPS4). Use the SMEUI (Figure 5-4 on page 157) of WebSphere Application Server to configure it for each system in the sysplex. For more information, refer to WebSphere Application Server Version 4.0.1 for z/OS and OS/390: Installation and Customization, GA22-7834-06.

Figure 5-4: SMEUI for enabling WebSphere Application Server in the sysplex

5.2.8 Enable LDAP in the sysplex

Configure the LDAP settings in WebSphere Application Server for the sysplex. The customization of the LDAP settings of WebSphere Portal is the same as customizing the LDAP of WebSphere Application Server. For details, refer to WebSphere Application Server Version 4.0.1 for z/OS and OS/390: Installation and Customization, GA22-7834-06.

Figure 5-5 shows the LDAP configuration files that were copied from system WPS3 to WPS4 to enable the WebSphere Application Server LDAP and the Portal Server LDAP in a Sysplex.

Figure 5-5: Configuration files for enabling LDAP in the sysplex

Configure WebSphere Portal in a Sysplex

Here we discuss Configuring WebSphere Portal in a Sysplex in WebSphere Application Server. Installing WebSphere Portal in a sysplex environment is basically the same as installing it in a monoplex (refer to the PTF 3 Readme in Section "Installing WebSphere Portal for z/OS and OS/390 Version 4.1 PTF 3"), plus some additional setup. We recommend that you use setup values similar to the following sample configuration. WebSphere Portal is configured in a shared HFS that must be available for all systems.

1. Ensure that you have set up the configuration file of WebSphere Portal for a sysplex:

   WPS_PATH/zoinst/scripts/wps.setup.in

   This should be done during an installation step of WebSphere Portal.

   WPS_PORT is the HTTP Port of the webcontainer.

   WPS_RESOURCE_LOCATION is the common location name of the DB2 subsystems.

   WPS_HOST is the VIPA IP name that distributes requests for WPS_ PORT.

   WPS_SHORT_HOST is the VIPA short name.

   WPS_LDAP_SERVER is the URL of the LDAP server of WebSphere Portal. The LDAP of WebSphere Portal is also accessible through the sysplex distributor.

   WPS_LDAP_PORT is the port of the LDAP of WebSphere Portal.

   Example 5-7 shows the wps.setup.in file for the test environment.

   Example 5-7: The wps.setup.in file for the test environment

   # HTTP port of the Portal Server. Required. export WPS_PORT=8082 # Location name of the data base that should be used when establishing # connections with the DB2 Datasource used by the Portal Server code. # In a sysplex environment, MUST be identical on all systems. For # details, refer to the "Installation Instructions" document # Optional export WPS_RESOURCE_LOCATION=WPSDSN9 # Name of the Portal Server host. Required for # $WPS_PATH/libapp/config/services/ConfigService.properties # and # $WS_CONFIG_PATH/controlinfo/envfile/$SYSPLEX/$WPS_SERVERNAME/webcontainer.conf export WPS_HOST=wpsplex2.boeblingen.de.ibm.com # Short Name of the Portal Server host. Required for # $WS_CONFIG_PATH/controlinfo/envfile/$SYSPLEX/$WPS_SERVERNAME/webcontainer.conf export WPS_SHORT_HOST=wpsplex2 . . # Name of the LDAP server used by WebSphere Portal Server. Required for # $WPS_PATH/libapp/config/um.properties export WPS_LDAP_SERVER=wpsplex2.boeblingen.de.ibm.com # Port of the LDAP server used by WebSphere Portal Server. Optional, if set, # added to $WPS_PATH/libapp/config/um.properties export WPS_LDAP_PORT=2389

   Note

   The variable WPS_PORT must be set to the HTTP port of the webcontainer during the WebSphere Portal installation. This is because the installation scripts set this as the BBOC_HTTP_PORT variable at server level during the configuration of WebSphere Application Server. Other network components, which can be used with WebSphere Application Server V4.0.1, such as Network Dispatcher, WebSphere Edge Server, and the WebSphere Advanced Edition HTTP plugin (introduced with WebSphere Application Server V4.0.1 PTFs UQ90051, UQ90052, and UQ70037) should be enabled subsequently.

2. Run the installation jobs delivered with WebSphere Portal. Refer to the PTF3 Readme (Section "Installing WebSphere Portal for z/OS and OS/390 Version 4.1 PTF3"), and Chapter 2, "Portal installation" on page 19. Make sure that WebSphere Portal is accessible with the URL you have specified in the file wps.setup.in during installation.

3. From the z/OS or OS/390 console, stop WebSphere Portal via the command: stop WSPORT.WSPORTA

4. After WebSphere Portal has been successfully installed, use the SMEUI of WebSphere Application Server to change the portal server instances for each additional system in the sysplex (WSPORTB, WSPORTC, and so on). You need to map the correct daemon and system management instances, and add environment variables at server instance level. For details, refer to WebSphere Application Server Version 4.0.1 for z/OS and OS/390: Installation and Customization, GA22-7834-06. Add two environment variables at server level (WSPORT):

   BBOC_HTTP_MODE=INTERNAL SESSION_COOKIE_NAME=sesessionid (This is case sensitive.)

   Use the SMEUI to add the variables as seen on Figure 5-6 on page 161.

   Figure 5-6: Defining environment variables using SMEUI

   Note

   Per WebSphere Application Server default, the session cookie name is JSESSIONID, in which case no environment variable SESSION_COOKIE_NAME needs to be specified. However, WebSphere Portal uses sesessionid as cookie name. Therefore, environment variable SESSION_COOKIE_NAME needs to be specified. The value matches the value session.cookie.name in file webcontainer.conf that is shipped and installed with WebSphere Portal.

5. Edit the configuration file to enable the HTTP plugin for WebSphere Portal:

   /WPS_PATH/libapp/config/services/ConfigService.properties

   The test environment specifies the URL and port of the IBM HTTP Server that contains the HTTP plugin and that is accessible through the sysplex distributor. The VIPA wpsplex2.boeblingen.de.ibm.com distributes requests for port 80 to which the IBM HTTP Server is listening.

   # The parameters of the (virtual) host that the portal is accessed through # # Default: localhost (host.name = wpsplex2.boeblingen.de.ibm.com host.name = wpsplex2.boeblingen.de.ibm.com host.port.http = 80 host.port.https =

6. For each server instance of WebSphere Portal, edit the file webcontainer.conf in the directory:

   WS_CONFIG_PATH/controlinfo/envfile/SYSPLEXNAME/WPS_SERVERNAME*

   Where, * is A, B, C, and so on, depending on the number of systems in your sysplex. Add the host and port name of the IBM HTTP Server. If you have several HTTP servers with different names and ports where you are planning to run WebSphere Application Server plugins, add each of them for each server instance to the variable host.default_host.alias.

   The following is an example of the setup for server instance WSPORTA on system WPS3:

   host.default_host.alias=wpsplex2.boeblingen.de.ibm.com:8082, wpsplex2:8082,boewps3.boeblingen.de.ibm.com:8082, boewps3:8082, wpsplex2.boeblingen.de.ibm.com, wpsplex2

   The following is an example of the setup for server instance WSPORTB on system WPS4:

   host.default_host.alias=wpsplex2.boeblingen.de.ibm.com:8082, wpsplex2:8082,boewps4.boeblingen.de.ibm.com:8082, boewps4:8082, wpsplex2.boeblingen.de.ibm.com, wpsplex2

   Note that apart from the HTTP server host and port name wpsplex2, the home IP names of the systems boewps3 and boewps4 are also added. This is done for test purposes only.

7. Enable the LDAP of WebSphere Portal in the sysplex, as described in 5.2.8, "Enable LDAP in the sysplex" on page 157, for each system on which you want to have this LDAP started. Enabling the portal LDAP is the same as enabling the LDAP of WebSphere Application Server in a sysplex.

   Start the portal LDAP server, for example, in the test environment:

   RO WPS3,S BBOLDAT RO WPS4,S BBOLDAT

Configure IBM HTTP Server and the HTTP Server Plugin

WebSphere Portal for z/OS and OS/390 supports the use of an external HTTP server or IBM HTTP Server on the same system where WebSphere Portal runs.

If you intend to implement such an HTTP setup with Network Dispatcher, WebSphere Edge Server, or WebSphere Advanced Edition HTTP plugin (introduced with WebSphere Application Server V4.0.1 PTFs UQ90051, UQ90052, and UQ70037), refer to redbook Enabling High Availability e-Business on eServer zSeries, SG24-6850.

The plugin used for this configuration is the new HTTP plugin for IBM HTTP Server running on z/OS and OS/390 that was introduced with PTF UQ74160 Service Level W401500. The plugin is required for routing HTTP requests.

The configuration files for the Web server, such as httpd.conf and plugin-cfg.xml, are kept separately on each system. They are staged in HFS path /local/websrv. As shown in Figure 5-2 on page 155, the path /local is resolved to /$SYSNAME/local. That means, there are actually two separate directories /WPS3/local/websrv and /WPS4/local/websrv.

1. Configure the HTTP server for the systems in the sysplex. Example 5-8 is a sample configuration for each IBM HTTP Server on WPS3 and WPS4 in the configuration file httpd.conf.

   Example 5-8: httpd.conf file for WPS3 and WPS4

   UserId PUBLIC . . . # ====================================== # *** WAS W401500 PLUG-IN directives *** # ====================================== ServiceSync On # ServerInit /usr/lpp/WebSphere/WebServerPlugIn/bin/ihs390WASPlugin_http.so:init_exit /local/websrv/plugin-cfg.xml Service /wps/* /usr/lpp/WebSphere/WebServerPlugIn/bin/ihs390WASPlugin_http.so:service_exit Service /webapp/* /usr/lpp/WebSphere/WebServerPlugIn/bin/ihs390WASPlugin_http.so:service_exit Service /PolicyIVP/* /usr/lpp/WebSphere/WebServerPlugIn/bin/ihs390WASPlugin_http.so:service_exit ServerTerm /usr/lpp/WebSphere/WebServerPlugIn/bin/ihs390WASPlugin_http.so:term_exit . . . SSLClientAuth PASSTHRU

2. Configure the plugin-cfg.xml file. Example 5-9 shows the plugin configuration setup in the file plugin-cfg.xml for WPS3.

   Example 5-9: Plugin-cfg.xml for WPS3

   <?xml version="1.0"?> <Config> <Log Name="/tmp/http/plugin.log" LogLevel="Trace" /> <ServerGroup Name="IVPGroup"> <ClusterAddress Name="dvipa2"> <Transport Hostname="wpsplex2.boeblingen.de.ibm.com" Port="8081" Protocol="http" /> </ClusterAddress> <Server Clone Name="BBOASR2A"> <Transport Hostname="boewps3.boeblingen.de.ibm.com" Port="8081" Protocol="http" /> </Server> <Server Clone Name="BBOASR2B"> <Transport Hostname="boewps4.boeblingen.de.ibm.com" Port="8081" Protocol="http" /> </Server> </ServerGroup> <ServerGroup Name="PortalGroup"> <ClusterAddress Name="dvipa2"> <Transport Hostname="wpsplex2.boeblingen.de.ibm.com" Port="8082" Protocol="http" /> </ClusterAddress> <Server Clone Name="WSPORTA"> <Transport Hostname="boewps3.boeblingen.de.ibm.com" Port="8082" Protocol="http" /> </Server> <Server Clone Name="WSPORTB"> <Transport Hostname="boewps4.boeblingen.de.ibm.com" Port="8082" Protocol="http" /> </Server> </ServerGroup> <VirtualHostGroup Name="default_host"> <VirtualHost Name="*:80"/> <VirtualHost Name="localhost:80"/> <VirtualHost Name="wpsplex2.boeblingen.de.ibm.com:80"/> <VirtualHost Name="boewps3.boeblingen.de.ibm.com:80"/> </VirtualHostGroup> <UriGroup Name="IVP_URIs"> <Uri Name="/webapp/*"/> <Uri Name="/PolicyIVP/*"/> </UriGroup> <UriGroup Name="Portal_URIs"> <Uri Name="/wps/*" affinityCookie="sesessionid"/> </UriGroup> <Route ServerGroup="IVPGroup" UriGroup="IVP_URIs" VirtualHostGroup="default_host"/> <Route ServerGroup="PortalGroup" UriGroup="Portal_URIs" VirtualHostGroup="default_host"/> </Config>

   Example 5-10 shows the plugin configuration setup in the file plugin-cfg.xml for WPS4.

   Example 5-10: Plugin-cfg.xml for WPS4

   <?xml version="1.0"?> <Config> <Log Name="/tmp/http/plugin.log" LogLevel="Trace" /> <ServerGroup Name="IVPGroup"> <ClusterAddress Name="dvipa2"> <Transport Hostname="wpsplex2.boeblingen.de.ibm.com" Port="8081" Protocol="http" /> </ClusterAddress> <Server Clone Name="BBOASR2A"> <Transport Hostname="boewps3.boeblingen.de.ibm.com" Port="8081" Protocol="http" /> </Server> <Server Clone Name="BBOASR2B"> <Transport Hostname="boewps4.boeblingen.de.ibm.com" Port="8081" Protocol="http" /> </Server> </ServerGroup> <ServerGroup Name="PortalGroup"> <ClusterAddress Name="dvipa2"> <Transport Hostname="wpsplex2.boeblingen.de.ibm.com" Port="8082" Protocol="http" /> </ClusterAddress> <Server Clone Name="WSPORTA"> <Transport Hostname="boewps3.boeblingen.de.ibm.com" Port="8082" Protocol="http" /> </Server> <Server Clone Name="WSPORTB"> <Transport Hostname="boewps4.boeblingen.de.ibm.com" Port="8082" Protocol="http" /> </Server> </ServerGroup> <VirtualHostGroup Name="default_host"> <VirtualHost Name="*:80"/> <VirtualHost Name="localhost:80"/> <VirtualHost Name="wpsplex2.boeblingen.de.ibm.com:80"/> <VirtualHost Name="boewps4.boeblingen.de.ibm.com:80"/> </VirtualHostGroup> <UriGroup Name="IVP_URIs"> <Uri Name="/webapp/*"/> <Uri Name="/PolicyIVP/*"/> </UriGroup> <UriGroup Name="Portal_URIs"> <Uri Name="/wps/*" affinityCookie="sesessionid"/> </UriGroup> <Route ServerGroup="IVPGroup" UriGroup="IVP_URIs" VirtualHostGroup="default_host"/> <Route ServerGroup="PortalGroup" UriGroup="Portal_URIs" VirtualHostGroup="default_host"/> </Config>

From the z/OS or OS/390 console, start WebSphere Portal on your systems via the command:

RO <yourSy1>,S WPS_PROCNAME.$WPS_SERVERNAMEA,srvname='$WPS_SERVERNAMEA' RO <yourSy2>,S WPS_PROCNAME.$WPS_SERVERNAMEB,srvname='$WPS_SERVERNAMEB'

For example, in the test environment:

RO WPS3,S WSPORT.WSPORTA,srvname='WSPORTA' RO WPS4,S WSPORT.WSPORTB,srvname='WSPORTB'

Start IBM HTTP Server, for example, in the test environment:

RO WPS3,S WEBSRV3 RO WPS4,S WEBSRV3

Connectivity

Figure 5-7 on page 167 illustrates how WebSphere Portal, IBM HTTP Server, and the sysplex distributor are connected and communicate in the test environment.

Figure 5-7: Connectivity in the test environment

The client request on wpsplex2.boeblingen.de.ibm.com/wps/portal is distributed by the sysplex distributor (1) to IBM HTTP Server on WPS3 (2). The WebSphere Application Server plugin of IBM HTTP Server checks this HTTP request for session information. As there is no match with any entry that is configured in the file plugin-cfg.xml, it routes the request back to the sysplex distributor with port 8082 (3) because of a standard rule in plugin-cfg.xml that applies in that case.

<ClusterAddress Name="dvipa2"> <Transport Hostname="wpsplex2.boeblingen.de.ibm.com" Port="8082" Protocol="http" />

In a case where a standard rule matches, the plugin trace shows:

st: htrequestGetCookie: Looking for cookie: 'sesessionid' st: htrequestGetCookie: No cookie found for: 'sesessionid' websphereParseSessionID: Parsing session id from '/wps/portal' websphereParseSessionID: Failed to parse session id websphereFindServer: Have a cluster address server so using it: dvipa2 websphereFindTransport: Finding the transport websphereFindTransport: Setting the transport: wpsplex2.boeblingen.de.ibm.com on port 8082

The sysplex distributor then routes the request to the server WSPORTA that is listening on port 8082 (4). WSPORTA returns the login page to the client (5). The client fills in the user ID and password, and sends the login page back to the sysplex distributor (6). The sysplex distributor this time distributes the request to IBM HTTP Server on WPS4 (7). The WebSphere Application Server plugin routes the request back to the sysplex distributor because the standard rule matches again (8). The sysplex distributor distributes the request to server WSPORTA on WPS3 (9) and WSPORTA returns a cookie and a welcome message (10). The user is now logged on, and any subsequent request to WebSphere Portal contains session information in the request header. Like before, subsequent requests first get distributed on port 80 by the sysplex distributor (11) to an IBM HTTP Server (12). Because there is session information in the request header, the WebSphere Application Server plugin of IBM HTTP Server directly routes the request to WSPORTA (13), which answers directly (14).

The following rule matches if the HTTP request contains session information.

<Server Clone Name="WSPORTA"> <Transport Hostname="boewps3.boeblingen.de.ibm.com" Port="8082" Protocol="http" </Server>

When the rules match, the HTTP plugin trace shows:

websphereParseSessionID: Parsing session id from 'msp=2; w3ibmProfile=2000120605... sesessionid=0000ar4zaJBx-NTcMwqh8nCFUmO:WSPORT.WSPORTA' websphereParseCloneID: Adding clone id 'WSPORT.WSPORTA' websphereParseCloneID: Returning list of clone ids group: serverGroupFindClone: Looking for clone group: serverGroupFindClone: Match for clone 'WSPORTA' websphereHandleSessionAffinity: Setting server to WSPORTA websphereFindTransport: Finding the transport websphereFindTransport: Setting the transport: boewps3.boeblingen.de.ibm.com on port 8082