WebSphere Extended Deployment Topology

 

+

Search Tips   |   Advanced Search

 

 

Server types

Such a topology can include three different server types:

  1. WAS application server

    Any application server that is created and managed by WAS.

  2. Generic server

    Any server that can be stopped and started by a WAS Node Agent is called a generic server.

  3. Foreign server

    A server that does not fit into one of the previous definitions. For example, a foreign server might be a non-WebSphere application server such as Apache Geronimo, Tomcat, JBoss, and so on. A foreign server also might be a database or other type of server. We are using two foreign servers in our sample topology for this book.

 

Node types

A topology that consists of WebSphere and non-WebSphere servers can include four different node types:

  1. WebSphere Extended Deployment (XD) node

    This machine hosts a WebSphere XD Node Agent, plus any other server types.

  2. WAS node

    A WAS node hosts a WAS v5.1 or v6.0 (and higher) Node Agent, plus any other server types. These machines do not run WebSphere XD. They might be monitored with the remote agent that is supplied with the WebSphere XD for Mixed Server Environments software.

  3. Pure external node

    A machine that runs foreign servers is called a pure external machine or node. It does not run a WAS Node Agent, but supports external monitoring with the remote agent.

  4. Foreign node

    Any machine that runs foreign servers and does not support monitoring.

The last two definitions are not necessarily related to managed and unmanaged nodes in a WebSphere cell. Creating an unmanaged node only means that the Deployment Manager stores information about that node in the configuration files. As a result of this, unmanaged nodes can have custom properties.

Pure external and foreign nodes might be unmanaged, but also might not have any information stored in the configuration files. Nodes that do not have any information stored in the configuration files are neither managed nor unmanaged and will therefore not show up in the cell topology.

As an example, we can add a pure external machine that is running the remote agent as an unmanaged node to our cell. But doing so is not necessary unless we need to configure custom properties for the node because we cannot use the default configuration.

 

Deployment targets

A deployment target is a place that can contain a processing tier. There are five kinds of deployment targets:

  • WAS application servers that are not clustered.

  • A static cluster of WAS application servers.

  • A dynamic cluster of WAS application servers.

  • Generic server cluster

    A generic server cluster is a collection of transport endpoints that can be used as a target for an On Demand Router (ODR) routing rule. Generic server clusters are not collections of generic servers. Servers in a generic server cluster can be foreign or generic servers.

  • External cluster

    An external cluster is used for foreign and generic servers that are not referenced by generic server clusters. For example, an external cluster might reference database servers.

    External clusters cannot be a target, and cannot contain target servers. Servers that belong to an external cluster can run on any type of machine. We must explicitly configure the server placement and speeds of the unmonitored nodes in the ODR cell using the external.placement custom property.

 

The sample topology

For the purpose of this redbook, we have set up a sample topology that allows us to demonstrate the various functions and features of IBM WebSphere XD V6.0.

The Domain Firewall is not part of the cell configuration. However, the unmanaged Web server nodes are part of the cell and thus the xdcell boundaries also seem to include the firewall in the graphic.

Communication between the Deployment Manager and the Web servers is via the Web server administrative port (8008) for unmanaged nodes and via the WebSphere file synchronization service for managed nodes. Thus we need to open port 8008 in the firewall when running Web servers on unmanaged nodes.

The plugin-cfg.xml file is transferred from an ODR to the Web servers.

The sample topology consists of...

WebSphere Network Deployment Edge Component Load Balancer For distributing workload between the two Web servers. For production systems, make highly available because as this is the entry point into our environment.
protocol and domain firewalls For creation of a DMZ containing the Load Balancer and Web servers. On-demand routers hould not sit in the DMZ.
Two IBM HTTP servers with plugins The Web server systems are configured as unmanaged nodes in our WebSphere cell (which is called xdcell).
Two On-Demand Routers To receive requests from the Web servers and distribute them to the application servers based on routing and service policies and dynamic weights.
Three nodes running WebSphere XD For hosting various node groups, dynamic and static clusters and different applications in each of the clusters.
Two scaleout systems running Apache Geronimo These two nodes are pure external nodes that run the remote agent. Configure unmanaged nodes for them in the xdcell.
Two Deployment Manager systems For high availability, one of them is active and the other one is a standby. The Deployment Manager profile is located on a shared file system such as the IBM Storage Area Network File System (SAN FS) or Network File System V4.
Database server. For production systems, the DB server should have some kind of backup for highly availability. This can, for example, be achieved by using clustering software such as IBM HACMP or IBM Tivoli System Automation.

 

Hardware and software

This section lists the hardware and software we used to setup the redbook sample topology. Refer to this Web site for a complete list of hardware and software requirements: 

http://www.ibm.com/software/webservers/appserv/extend/doc/latest/prereqxd.html

 

Hardware

Our sample topology uses the following 14 systems...

  1. Five IBM eServer pSeries systems running AIX 5L 5.2

    These systems host the two Web servers, the primary Deployment Manager and two application server nodes.

  2. Six IBM eServer xSeries systems running Linux

    These systems host the two On Demand Routers (ODRs), the backup Deployment Manager, one of the application server nodes, the database, and one of the Apache Geronimo servers.

  3. Two IBM eServer xSeries systems running Windows operating systems

    These systems host the Load Balancer and the second Apache Geronimo server.

  4. Two firewalls

    Note that we do not cover how to configure the firewalls in this redbook.


 

Software

IBM WebSphere XD V6.0 requires IBM WebSphere ND V6.0.2 or higher. It supports the same operating systems as WebSphere ND except for z/OS and i5/OS.

IBM WebSphere ND V6.0.2 requires additional interim fixes before installing WebSphere XD. These prerequisite interim fixes are provided on the WebSphere XD installation CD but we must install them.

For additional infomation about installing WebSphere XD with IBM WebSphere ND V6.0.2 refer to this technote: 

http://www.ibm.com/support/docview.wss?rs=180&uid=swg21213278

Tip: Fixpack 1 for IBM WebSphere ND V6.0.2 includes these interim fixes and the correct update installer version, therefore IBM recommends to install IBM WebSphere ND V6.0.2.1.

 

Software to install for the sample topology

The sample topology requires the following software...

  • IBM WebSphere ND V6.0.2.1, including these components:
    • IBM HTTP Server V6.0
    • WebSphere Web server plug-in
    • Edge Components (Load Balancer component)
    • Application server
  • IBM WebSphere XD V6.0
  • WebSphere XD for Mixed Server Environments
  • DB2 UDB 8.2
  • Apache Geronimo
  • All test applications

List of software to be installed on the systems in the redbook topology.

System(s)

Software to install

Load Balancer (LB)

Load Balancer component of WebSphere ND's Edge Components

Web servers (web1, web2)

IBM HTTP Server V6.0

WebSphere ND Web server plug-ins

On demand routers (odr1, odr2)

IBM WebSphere ND V6.0.2.1

IBM WebSphere XD V6.0

Application server nodes (node1, node2, node3)

IBM WebSphere ND V6.0.2.1

IBM WebSphere XD V6.0

Deployment Manager nodes (dmgr1, dmgr2)

IBM WebSphere ND V6.0.2.1

IBM WebSphere XD V6.0

Database (DB)

DB2 Universal Database™ V8.2 (DB2 UDB V8.2)

Non-WebSphere nodes (scaleout1, scaleout2)

Apache Geronimo

WebSphere XD for Mixed Server Environments

 

Installation and configuration

This section provides instructions on how to set up the systems, install the needed software and configure the sample topology. Whenever appropriate, we point to the section in this or another redbook that covers that configuration step in detail.

 

Installation and configuration summary

We assume that our database server is already set up and running. These are the steps needed to set up the WebSphere part of our sample topology:

  1. Install IBM WebSphere ND V6.0.2.1 on the Deployment Manager nodes (dmgr1 and dmgr2).

    Be certain these two conditions are met. The primary and backup Deployment Manager must share the same master configuration repository and workspace area. Thus we need to make sure that the two systems have a suitable shared file system available, for example IBM SAN FS or NFS version 4. We can install the WebSphere binaries into the shared file system or individually on each system. The Deployment Manager profile must reside on the shared file system. Because we use different operating systems (AIX and Linux) for our two Deployment Managers, we install the binaries locally on each system and create only the profile on the shared file system.

  2. Create a Deployment Manager profile on dmgr1. Again, the profile must reside on the shared file system. Our cell is called xdcell. Start the Deployment Manager. Do not create the profile on the second Deployment Manager machine yet.

  3. Install IBM WebSphere ND V6.0.2.1 on each application server and on each On Demand Router node (node1, node2, node3, odr1, odr2).

  4. Create custom profiles on each of the application server and ODR nodes. During creation of the custom profiles, add them to the xdcell on dmgr1 to create a cell containing all machines. Verify the cell topology in the Administrative Console.

  5. Stop everything. This includes the Deployment Manager, the application servers, and the Node Agents on the application server and ODR nodes.

  6. Install IBM WebSphere XD V6.0 on the Deployment Manager nodes, each application server node, and the ODR nodes.

  7. Start the Deployment Manager on the primary Deployment Manager machine (dmgr1).

  8. Start the Node Agents on the application server and ODR nodes.

  9. Create the two On Demand Router servers on the ODR nodes (odr1 and odr2).

  10. Install IBM HTTP Server V6.0.2.1 and the IBM WebSphere ND V6.0.2.1 Web server plug-ins on the Web server nodes (web1 and web2). Configure the HTTP server as desired.

  11. Create two unmanaged nodes for the Web servers on the Web server nodes (web1 and web2). Then create and configure the two Web servers in the cell.

  12. Install and configure the Load Balancer system.

  13. Configure the Apache Geronimo servers. This includes installing Apache Geronimo (including a test application) and WebSphere XD for Mixed Server Environments, optionally creating unmanaged nodes (scaleout1 and scaleout2), and creating a generic server cluster that defines the endpoints of the Apache Geronimo servers.

After the initial installation and configuration of the nodes is finished, we can then further configure our cell. This includes setting up the highly available Deployment Manager, creating node groups, clusters (both static and dynamic), installing applications, configuring health policies, ODR routing and service policies, and so on.

 

Installing IBM WebSphere ND V6.0.2.1

We need to install IBM WebSphere ND V6.0.2.1 on the following nodes:

  • Both Deployment Manager nodes (dmgr1 and dmgr2)
  • All application server nodes (node1, node2, node3)
  • All ODR nodes (odr1 and odr2 in our topology)

In order to install IBM WebSphere ND V6.0.2.1, we first need to install IBM WebSphere ND V6, then install the V6.0.2 refresh pack followed by the V6.0.2.1 fix pack. We can obtain WebSphere refresh and fix packs from the Recommended Updates for WAS Base and ND editions Web site.

Alternatively, go to the WAS support Web site

We can also download the refresh and fix packs for IBM HTTP Server V6.0 and the Web server plug-ins from this Web site.

 

Creating the Deployment Manager profile

After we have successfully installed the IBM WebSphere ND V6.0.2.1 software on all nodes, it is now time to configure the profiles. The first profile that needs to be created is the Deployment Manager profile on one of the Deployment Manager machines - in our case dmgr1. The profile must be created on the shared file system as we intend to configure a highly available Deployment Manager for our topology.

If this is your first WebSphere ND V6 installation you might find it helpful to first read IBM WebSphere ND V6 Installing your application serving environment.

Information on installing refresh packs and fix packs is found in the article Installing maintenance packages.

 

Creating a profile using the Profile creation wizard

We can launch the Profile creation wizard using the appropriate command for our platform, for example:

  • pctLinux.bin
  • pctAIX.bin
  • pctWindows.exe

The command is found in the install_root/bin/ProfileCreator directory. Note that this directory only contains the command for the local operating system, that is, on a Linux machine we only find the pctLinux.bin command.

The Profile creation wizard can also be started from the launchpad at the end of the WAS installation. However, this is not recommended if we need to also install WebSphere refresh and fix packs.

After the Profile creation wizard has been launched, we first need to select the Create a deployment manager profile option. On the following two panels we can specify the profile name and directory. Further configuration includes the node, host, cell name, and ports. The default values for these settings are based on the host name of our system and take existing configurations into account.

We have used the following settings for our primary Deployment Manager:

  • Node name: dmgr1
  • Host name: dmgr1.ibmredbooks.com
  • Cell name: xdcell
  • Port value assignment: Because this is the first profile on the system, we were able to use the default ports. If we cannot use the default ports, write down at least the SOAP connector port and the Administrative Console port.

Verify that the profile was created without errors before pressing the Finish button. If we have errors, check the log at this Web address: 

    install_root/logs/wasprofile/wasprofile_create_profile_name.log

We also find logs for individual actions in: 

    profile_home/logs

 

Starting the Deployment Manager

The next step is to start the Deployment Manager using the First Steps menu that we can launch from the Profile creation is complete panel or using the startManager command. The startManager command is profile-aware and must be issued from the profiles' /bin directory, in our case this is: 

    install_root/profiles/dmgr1/bin/startManager.sh

We can open the Administrative Console to further verify that the Deployment Manager was successfully started (using http://dmgr1:9060/admin ).

 

Configuring a highly available Deployment Manager

It is not possible to configure a highly available (HA) Deployment Manager before installing WebSphere XD. Therefore, this configuration step is deferred for now.

 

Creating custom profiles for application server and ODR nodes

When the Deployment Manager is up and running, we can create custom profiles on each of the application server nodes (node1, node2, and node3) as well as on the ODR nodes (odr1 and odr2).

Launch the Profile creation wizard on each of these five nodes using the appropriate command. In our case, we have AIX and Linux systems so we used the pctAIX.bin and pctLinux.bin commands respectively. We need to specify the following settings:

  • Select the Create a custom profile option.

  • On the Federation panel we need to enter information about our Deployment Manager. In our case, we used dmgr1 for the Deployment Manager host name and the default of 8879 for the SOAP port.

  • If the Deployment Manager is active during custom profile creation, we can immediately federate the node into the existing cell. We wanted to take advantage of this option so we left the Federate this node later using the addNode command box deselected. If the Deployment Manager is not active or cannot be accessed during custom profile creation, check this box and use the addNode command later to federate the node into the cell.

  • Enter a profile name and directory on the following panels. The profile directory defaults to the chosen profile name under the install_root/profiles directory.

  • Enter the node and host names. The default values are based on the host name of our system. The node name must be unique within the cell and our system will show up under this name in the cell topology. We used node1, node2, node3, odr1, and odr2 respectively for our five nodes.

  • The Port value assignments panel is shown if we choose to federate the node during custom profile creation. Existing profiles and their ports are taken into account. Normally we don't need to change anything on this panel but we might want to write down the ports if they are not the default ones.

Once again, verify that the profile was created without errors and check the log if errors occurred.

It is also possible to create application server profiles instead of custom profiles. In this case, however, we need to manually federate the nodes later using the addNode command. Also, we will find an application server called server1 for each node that was created and added in this way in the cell topology.

 

Verifying the WebSphere ND installation

After we have successfully created the custom profiles on all nodes, open the Administrative Console and verify the cell topology using either of these approaches:

  • Select System administration | Nodes. We can see the Deployment Manager node dmgr1 as well as node1, node2, node3, odr1, and odr2.

  • Select System administration | Node agents. We can see five nodeagents on the appropriate nodes.

  • Select System administration | Cell | Local Topology. Expand the tree diagram and verify the cell topology. We can see a nodeagent on each of the nodes but no application servers.

 

Installing IBM WebSphere XD V6.0

After we have installed IBM WebSphere ND V6.0.2.1 and configured the basic cell topology, the next step is to install WebSphere XD on the Deployment Manager system and all application server and ODR nodes. Follow these steps:

 

References

Here are some Web sites where we can find additional information:

 

Stopping the running environment

We must first stop everything in our cell:

  • Issue the command command...

    install_root/profiles/profile_name/bin/stopNode.sh

    ...on each of the nodes (node1, node2, node3, odr1, and odr2) to stop the Node Agents.

  • Run the command...

    install_root/profiles/profile_name/bin/stopManager.sh

    ...on the Deployment Manager system to stop the Deployment Manager.

 

Installing the WebSphere XD software

After all Node Agents and the Deployment Manager have stopped, we can now install the IBM WebSphere XD V6.0 software on all systems. We can perform the installation using the launchpad, or have the installation run silently.

A WebSphere XD installation is based on an existing WebSphere ND environment. Therefore we assume that we have finished installation of IBM WebSphere ND V6.0.2.1 and the basic configuration of the cell as described in the previous sections.

These are the steps when using the GUI:

  1. Start launchpad using the install command. Here we can select to either install the full IBM WebSphere XD V6.0 package or WebSphere XD for Mixed Server Environments.

    For the Deployment Manager system, select to install WebSphere XD V6.0. Click Next.


  2. Read the infomation about the Welcome panel and click Next .

  3. Review the license and accept it by clicking Next . A prerequisite checking is performed after accepting the license. Hopefully our system meets all prerequisites and we can continue the installation by clicking Next again.

  4. On the following panel we can select the existing WAS installation location. The path of our IBM WebSphere ND V6.0.2.1 installation should be displayed in the table. Select the correct installation that we want to upgrade to WebSphere XD.

    If our existing configuration's directory is not displayed in the table, we can use the Browse button to navigate to it or enter the path manually into the location field. Note that this path must point to the install_root directory, for example /usr/IBM /WebSphere/AppServer and not to the profile directory!

    Click Next.


  5. The Profile augmentation panel is displayed. Profile augmentation means that we make an existing profile compatible with WebSphere XD.

    A list of all existing profiles under the previously selected WebSphere installation location is displayed. Select all profiles that we want to augment. We have only the Deployment Manager profile configured on this system, so select dmgr1 and click Next.

    We can augment profiles also using the WebSphere XD Profile wizard. Use this wizard if we didn't augment a profile during installation or if we want to create a new profile in WebSphere ND after we installed IBM WebSphere XD V6.0.

    The Profile wizard is found in the install_root/bin/ProfileCreator/XD directory. Launch pcatAIX.bin, pcatLinux.bin, pcatWindows.exe, and so on, depending on our platform.


  6. The Summary panel is shown. Review the summary information and click Next to start the installation process.

  7. Click Finish when IBM WebSphere XD V6.0 is successfully installed.

  8. Repeat the installation and profile augmentation process on each application server node (node1, node2, and node3) and on both On Demand Router nodes (odr1 and odr2).

We must also install IBM WebSphere XD V6.0 on the second Deployment Manager system. However, this requires either that a correct profile is already configured or that we create the profile later using the WebSphere XD Profile wizard.

We decided to first install IBM WebSphere XD V6.0 and then use the WebSphere XD Profile wizard to create the second Deployment Manager's profile.

 

Restarting the environment

After we have installed IBM WebSphere XD V6.0 on all nodes, we can restart the Deployment Manager and the Node Agents. Run the command...

install_root/profiles/profile_name/bin/startManager.sh

...on the Deployment Manager system.

 

Verifying the WebSphere XD environment

The Administrative Console allows us to further configure our WebSphere XD environment now. Before doing so, however, it is recommended that we first get familiar with the new Administrative Console functions and that we verify our current configuration:

Open the Administrative Console using http://dmgr1:9060/admin to review our environment. All nodes should be displayed in the cell topology, the Node Agents should be started and synchronized, there are no application servers or clusters configured, and so forth.

There are several new options available in the navigation tree, such as...

The Guided Activities link is very helpful when configuring new functions for the first time.

The basic environment is now up and running. However, we also want to include Web servers and Apache Geronimo servers into the topology. Also, the ODRs must be further configured.

 

Creating On Demand Routers in the topology

As soon as we have a federated node in our cell, we can create an On Demand Router configuration on it. We already have created custom profiles and federated them for the two nodes, odr1 and odr2, that will host our ODRs in The next step is to create the ODR configurations themselves which can be done in two ways:

 

Using the Administrative Console

ODRs are created, configured and deleted in the Administrative Console under...

Servers | On Demand Routers

 

Using a wsadmin script

A wsadmin script called createodr.jacl comes with WebSphere XD and is located on the Deployment Manager node in the install_root/bin directory. This script creates an On Demand Router with the servername odr on node ODRNode. The script must be changed if we want to use different server and node names.

 

Installing IBM HTTP Server V6.0.2.1

The IBM HTTP Server V6.0.2.1 software is installed on two systems (web1 and web2) in our sample topology.

The approach for installing IBM HTTP Server V6.0.2.1 is the same as for installing WebSphere and WebSphere refresh and fix packs - first we install V6.0, then the V6.0.2 refresh pack followed by the V6.0.2.1 fix pack.

We can download IBM HTTP Server V6.0 refresh and fix packs from the same download site as WAS fixes.

 

References

These documents and Web sites provide useful information:

  • IBM HTTP Server V6.0 User's Guide at

    ftp://ftp.software.ibm.com/software/webserver/appserv/library/v60/ihs_60.pdf

  • The WebSphere InfoCenter also contains the IBM HTTP Server V6.0 product documentation.

  • Chapter 8, "Managing Web servers" of the redbook WAS V6 System Management and Configuration Handbook, SG24-6451.

  • Chapter 8, "Implementing the sample topology" of the redbook IBM WebSphere V6 Scalability and Performance Handbook, SG24-6392 also contains some IBM HTTP Server V6.0 installation and configuration information.

 

Installing IBM HTTP Server V6.0

IBM HTTP Server installation is easy. It can be started from the same launchpad as is used to run WebSphere V6 installations.

Write down the installation path and ports that we enter (or accept) during the installation. These are needed later when we configure the Web servers in the WebSphere cell.

 

Installing IBM HTTP Server V6.0.2 refresh pack and V6.0.2.1 fix pack

The approach for installing IBM HTTP Server refresh and fix packs is identical to installing WebSphere refresh and fix packs.

The refresh/fix pack should be extracted to the IBM HTTP Server V6.0 install_rootdirectory.

Read the readme files, make a backup of any existing installation/configuration, and to rename or remove an existing install_root/updateinstaller directory before extracting the refresh or fix pack.

 

Tips for configuring and running IBM HTTP Server V6.0

In WAS V6 all Web server configuration is done through the WebSphere Administrative Console (Web server and plug-in settings). The IBM HTTP Server administration server does no longer provide a separate HTML Administrative Console.

After we have configured our Web servers in the cell, we can start and stop them directly from the WebSphere Administrative Console rather than issuing a start command on the Web server machine. This requires however that the administration server is started on the Web server machine. To start the administration server in AIX use this command: 

    install_root/bin/adminctl start

The Web server configuration in the cell allows to automatically generate Web server plug-in files and to propagate them to the Web servers. However, on UNIX and Linux operating systems we need to change some file permissions or this function will not work. This is explained in the InfoCenter articles Running the setupadm script and Setting permissions manually.

 

Installing WebSphere Web server plug-ins V6.0.2.1

The Web server plug-in software must be installed on both Web server machines.

 

References

Find more infomation about this topic in these publications:

  • WebSphere InfoCenter
  • Chapter 8, "Managing Web servers" of the redbook WAS V6 System Management and Configuration Handbook, SG24-6451
  • Chapter 8, "Implementing the sample topology" of the redbook IBM WebSphere V6 Scalability and Performance Handbook, SG24-6392

 

Installing Web server plug-ins V6.0

We can either launch the installation from the WebSphere installation launchpad or at the end of the IBM HTTP Server V6.0 installation.

There are only a few settings that need to be specified during the plug-in installation. These two settings might not be apparent:

  • Scenario choice: We must select whether the Web server runs on a WebSphere node (in other words, a machine that runs a Node Agent) or not. The options presented are local (which means on a WebSphere node) or remote. In our sample topology both Web servers are remote.

  • Web server definition name: Enter the name we plan to use when defining this Web server in the cell.

     

    Installing WebSphere Web server plug-ins V6.0.2 refresh pack and V6.0.2.1 fix pack

    The approach for installing Web server plug-ins refresh and fix packs is also identical to installing WebSphere refresh and fix packs.

    The refresh or fix pack should be extracted to the Web server plug-ins install_rootdirectory.

    Read the readme files, make a backup of any existing installation configuration, and to rename or remove an existing install_root/updateinstaller directory before extracting the refresh or fix pack.

     

    Creating unmanaged nodes for the Web servers and Apache Geronimo servers

    It is possible to add unmanaged nodes to the cell configuration in IBM WebSphere ND V6. This allows for further configuration of that node in the cell.

     

    Creating and configuring Web servers in the cell

    Once an unmanaged node is configured, we can add a Web server configuration to it. To add web1 and web2:

    1. Select Servers | Web servers and click New.

    2. Select the appropriate node (web1) and enter the server name web1. The server name is a WebSphere object name, not a host name. The host name is implied when we pick the node. Click Next.

    3. On the next window we must enter several Web server properties, such as its type (IHS, Apache, IIS and so on), port, installation path and plug-in installation path. Fill in all fields and click Next.

    4. On the next window, enter the administration properties, such as User ID and Password, for the Web server. Click Next.

    5. On the following window we simply select The IHS WebServer Template and click Next.

    6. Finally, on the last window verify the summary and click Finish.

    7. Save our changes and synchronize with the nodes.

    8. Repeat steps 1 to 7 to create the web2 Web server definition on node web2.

     

    Installing and configuring the Load Balancer

    This configuration is out of the scope of this redbook but is explained in great detail in chapter 5 of IBM WebSphere V6 Scalability and Performance Handbook, SG24-6392. The configuration steps that need to be performed are:

    1. Install the Load Balancer software.

    2. Configure the Load Balancer to forward requests to the Web servers.

    3. Configure the Web servers to receive requests from the Load Balancer.

    4. Configure Load Balancer high availability.

     

    Installing WebSphere XD for Mixed Server Environments

    WebSphere XD for Mixed Server Environments allows us to manage software other than WAS and machines that do not run a WAS Node Agent.

    When using WebSphere XD for Mixed Server Environments, a remote agent sends average CPU utilization, node speed, and number of CPUs to the plug-in that polls the remote agent for CPU information. The gathered information is reported to the autonomic request flow manager which makes sure that workload is then distributed according to system capacity, utilization, and - optionally - service policies.

    Installing WebSphere XD for Mixed Server Environments installs this remote agent on the non-WebSphere XD systems, in our case on the Apache Geronimo servers.

    Perform this installation on both Apache Geronimo systems, scaleout1 (in our topology on Windows) and scaleout2 (on Linux).

    1. The installation CD has directories for each operating system, therefore we must first go to the appropriate directory. From here, launch the install command.

    2. Select to install WebSphere XD for mixed server environment, Version 6.0 and click Next.

    3. Click Next again on the Welcome panel.

    4. Review the license and accept it by clicking Next.

    5. Now we have to enter the installation path. We installed into the default paths of /opt/MixedServer on Linux and C:\Program Files\MixedServer on Windows. Clicking Next starts the install process.

    6. Verify that the software was successfully installed and click Finish.

    Now we can start using the remote agent.

     

    Setting up the Apache Geronimo environment

    We used J2EE 1.4 certified Apache Geronimo 1.0-M5 during our tests.

    DayTrader, our sample application for this scenario, requires at least the Apache Geronimo 1.0-M5 version.

    We can also use WAS Community Edition which is based on Apache Geronimo.

     

    Creating a generic server cluster in the cell

    The final steps before we can forward requests from the ODRs to the Apache Geronimo servers are:

    • Creating a generic server cluster that holds the endpoints of the Apache Geronimo servers, the host names and application serving port. Generic server clusters are created in the Administrative console under...

      Servers | Generic Server Clusters

    • Configuring routing rules and, optionally, service policies in the ODRs. Routing rules and service policies are defined under...

      Servers | On Demand Routers | ODR_Name | On Demand Router Properties | Generic Server Cluster Routing Policies

      ...and...

      Servers | On Demand Routers | ODR_Name | On Demand Router Properties | Generic Server Cluster Service Policies

     

    Redbook scenarios and configurations

    We use our sample topology to demonstrate the various WebSphere XD features throughout this book. We have configured node groups, dynamic and static clusters, application servers, Web servers, ODRs, generic server clusters, and so on. This section gives we an overview of the WebSphere objects the examples and configurations in this book are based on.

     

    Web server and ODR configuration

    As we have seen in the previous configuration sections, we have configured two Web servers and two ODRs. These are separated by the domain firewall. The ODRs forward requests to three WebSphere nodes (node1, node2, and node3).

    Figure 2-15 Web server, ODR and node configuration

    The ODRs also forward requests to two Apache Geronimo servers to demonstrate the non-WebSphere support of WebSphere XD.

     

    Node group configuration

    We have created two node groups called RedbookNodegroup1 and RedbookNodegroup2. These node groups are distributed among the three nodes (node1, node2, node3) in our topology to show we the new V6 feature of overlapping node groups. RedbookNodegroup1 spans node1 and node2 while RedbookNodegroup2 spans node2 and node3.

    Details on node groups can be found in Chapter 3, Setting up WebSphere XD for dynamic operations.

     

    Dynamic cluster configuration

    Based on these two node groups we have then created three dynamic clusters called RedbookCluster10, RedbookCluster11, and RedbookCluster20.

    • RedbookCluster10 is configured within RedbookNodegroup1 and has eight cluster members. This dynamic cluster is configured to allow a maximum of four servers per node and to have at least two instances started at all times.

    • RedbookCluster11 is configured within RedbookNodegroup1 and has two cluster members. It is configured to have only one server per node (no vertical stacking) and to have one instance started at all times.

    • RedbookCluster20 is configured within RedbookNodegroup2. It is configured to have a maximum of two servers per node and to have one instance started at all times.

    Figure 2-17 Sample dynamic cluster configuration for RedbookCluster10 and 11

    Figure 2-18 Sample dynamic cluster configuration for RedbookCluster20

     

    Static cluster configuration for WebSphere Partitioning Facility and ObjectGrid

    WebSphere Partitioning Facility and ObjectGrid require a static cluster configuration, therefore we also have a static cluster called RedbookClusterWPFOG which is used for the WebSphere Partitioning Facility and ObjectGrid chapters. This cluster consists of three cluster members (WPFOG1, WPFOG2, and WPFOG3).

     

    Generic server cluster configuration for Apache Geronimo

    WebSphere XD for Mixed Server Environments allows us to monitor the CPU utilization of non-WebSphere XD servers (generic or foreign servers). This information is sent to the ODRs and allows the ODRs to forward an appropriate amount of requests to these servers based on their CPU utilization (dynamic workload management).

    To take advantage of this feature, we need to configure a generic server cluster in our cell and then configure the ODRs with forwarding rules and optionally service policies for the generic server cluster. We have two Apache Geronimo servers in our environment and created a generic server cluster called GeronimoSC for them.

    Figure 2-20 Sample topology generic cluster server configuration

     

    Applications

    We used different applications for the various scenarios covered in this book. This section gives we an introduction to the applications themselves and lists the scenarios that use the applications.

     

    Trade 6.0.1

    Trade 6 is the sample application that is used for most chapters in this book.

    The IBM Trade Performance Benchmark Sample for WAS (called Trade 6 throughout this book) is the fourth generation of the WebSphere end-to-end benchmark and performance sample application. It is a stock trading application and allows us to buy and sell stock, to check our portfolio, register as a new user, and so on. We use DB2 UDB V8.2 as the backend database.

    The Trade benchmark is designed and developed to cover the significantly expanding programming model and performance technologies associated with WAS. This application provides a real-world workload, enabling performance research and verification test of the JavaTM 2 Platform, Enterprise Edition (J2EETM) 1.4 implementation in WAS, including key performance components and features. For details on how Trade 6 exploits all of these functions, read the document tradeTech.pdf which can be found inside the installation package.

    Trade 6 demonstrates several new features in WebSphere V6. All Trade-versions are WebSphere-version dependent, so Trade 6 will only work with WAS V6.

    Installing and configuring Trade 6 involves downloading the code, setting up a database, creating WebSphere resources, and installing the application in a dynamic cluster. This is explained in detail in Appendix A, Trade 6.

     

    DayTrader

    DayTrader is the Trade 6 equivalent for open source application servers. It offers and exploits similar functions as Trade 6. We use DayTrader for our scale-out to non-WebSphere XD servers scenario. DayTrader is installed on the two Apache Geronimo servers and using Cloudscape as its backend database. In our topology the database is installed locally on the Apache Geronimo servers.

     

    Downloading DayTrader

    We can obtain DayTrader by visiting this Web site: 

    https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_US&source=wsced

    This site requires an IBM ID and password - such as a PartnerWorld or developerWorks ID. We can register for an ID if needed.

    After signing in, we are presented with several download options. Select to download the Sample J2EE applications (wasce_samples-1.0.0.1.zip).

     

    DBChecking

    The DBChecking application is a utility application that illustrates how highly available singleton services can be used to maintain some global information that needs to be accessible to all cluster members. In our scenario, the global information that is maintained by the singleton service is the status of the database. This state is propagated to the application instances running on all cluster members so that the database is not accessed by the application when it is down. The DBChecking application achieves this by using WebSphere Partitioning Facility for the singleton service and ObjectGrid for maintaining the database state on all cluster members.

     

    Downloading DBChecking

    The DBChecking sample application was created as part of this redbook project and can be downloaded from the redbook repository. 

      http://www.ibm.com/software/webservers/appserv/extend/doc/latest/prereqxd.html

    Although Internet Explorer 6.0 and Mozilla 1.4 or 1.7 are supported browsers for the Administrative Console, IBM recommends to use Internet Explorer if we wish to display the Runtime Operations views that WebSphere XD offers you.

    To display these views, we need to install the Adobe Scalable Vector Graphics (SVG) Viewer. We can download the SVG Viewer from: 

    http://www.adobe.com/svg/viewer/install/main.html

    However, at the time of writing this redbook, the SVG Viewer did not support Mozilla, only Internet Explorer and Netscape Navigator.

    Mozilla emulates some of these views but they might not scale correctly and some views (such as the Runtime Map) cannot be displayed at all.

    While Mozilla Firefox 1.5 has native SVG support, Firefox still displays an error that the SVG viewer is required and can thus also not be used.

     

    Unmanaged nodes for IBM HTTP Server V6.0

    If an unmanaged node hosts an IBM HTTP Server V6.0, then this Web server can be fully managed (configured, started, stopped) from the Administrative Console. We want to take advantage of having one administrative interface for the entire topology, therefore we need to first add two unmanaged nodes for our Web servers to the cell.

     

    Unmanaged nodes for foreign servers

    Unmanaged nodes can also host foreign servers, in our case the Apache Geronimo servers scaleout1 and scaleout2. It is only necessary to add unmanaged nodes for foreign servers if one (or more) of the following is true:

    1. If we want the remote agent to listen for requests from a port other than the default port.
    2. If we are using a custom statistics collector plug-in to obtain node speed and average CPU utilization for the work profiler.
    3. If our nodes are multi-homed, that is, they have more than one network interface card or multiple host names.

    Adding unmanaged nodes for foreign servers allows us to define custom properties for these nodes. For example, if the remote agent listens for incoming requests from a port other than the default port, then we need to specify the stats.collector.remote.agent.port custom property with the correct port value on the unmanaged node.

     

    Creating unmanaged nodes

    To create unmanaged nodes follow these steps:

    1. Select System administration | Nodes | Add Node.

    2. Select Unmanaged node and click Next.

    3. In the next window enter the new node name, web1, its host name, web1.ibmredbooks.com or just web1, and select the OS on which it runs.

    4. Click OK.

    5. Repeat steps 1 to 4 to also configure an unmanaged node for web2.

    6. Optionally add scaleout1 and scaleout2 as unmanaged nodes.

    7. Save and synchronize the changes.

    After the unmanaged nodes have been created, we can now configure Web servers in the cell or define custom properties for the foreign servers.

     

    Starting and stopping the remote agent

    To start the remote agent, open a command prompt and navigate to the directory where the remote agent is installed.

    To start the remote agent on the default port, 9980, issue the ./startAgent.sh or startagent.bat command.

    If we start the remote agent using startAgent from the bin directory, the Java Runtime Environment (JRE™) that is used is the one that it bundled with the installer. The JRE is installed in the _uninstXD/_jvm directory.

    We can also supply the port number as a parameter to the startAgent script if the default port is used by another process that is running on the node. In this case, issue startAgent.sh/bat portnumber.

    By default, the remote agent can be run by any user. We can limit access to the directory that contains the remote agent for increased security.

    To stop the remote agent, use the command window where we started the remote agent. Enter quit and press Enter. We can also stop the remote agent by pressing Control-C or by using the UNIX kill command.

     

    Installing Apache Geronimo

    Installing Apache Geronimo is easy. We basically only have to extract the downloaded archive using an appropriate unzipping and untar tool for our platform. Extract the archive into the desired geronimo_install_root directory.

    Be aware that. most likely, the files will not be extracted directly into the specified directory but into a subdirectory which is named according to the Geronimo version we are installing (for example, geronimo-1.0). Therefore IBM recommends verifying the correct path to the /bin directory after extracting the files.

     

    Starting Apache Geronimo

    To start Apache Geronimo, go to the geronimo_install_root directory and issue this command: 

    java -jar geronimo_install_root/bin/server.jar

    This starts Apache Geronimo using the default ports. For example, port 8080 is used for application serving. We need this port number later in the generic server cluster configuration. Thus, if our Apache Geronimo installation does not use the default ports, take note of the ports in use. The ports are listed in the Listening on Ports section during the server startup. Look for the Connector HTTP/HTTPS ports to find the application serving ports.

    When using Apache Geronimo 1.0 and higher, we might get errors during the server start that are related to DayTrader not yet being installed. We can ignore these for now but need to restart the server after DayTrader has been installed.

     

    Installing the DayTrader application

    DayTrader is one of the sample applications that comes with WAS Community Edition. We can download DayTrader also separately.

    Extract the downloaded archive into the desired daytrader_home directory on the machine that hosts the Apache Geronimo server.

    The README file in the daytrader_home directory contains detailed instructions on how to install the application. Verify that java is in the system path before following the instructions from the README file.

    Basically, installing DayTrader consists of three parts:

    1. Building the DayTrader EAR file

      This should build the daytrader-ear-1.0.ear in the ear/target/ directory.

    2. Creating the database for DayTrader

      Next we must create the database needed by DayTrader. There are various database options: the embedded Cloudscape™ database that comes with Apache Geronimo, a remote Cloudscape database, Oracle, or DB2. We used the embedded database for our tests.

    3. Installing the application on the Apache Geronimo servers

      The last step is to deploy DayTrader on our Apache Geronimo servers using the command line deployer.

      Restart our Apache Geronimo server after successful installation and verify that DayTrader has started without errors.

     

    Using DayTrader

    We should now be able to access DayTrader using this URL: 

        http://hostname:8080/daytrader/

    So in our environment, we use the following URLs on our two systems: 

        http://scaleout1:8080/daytrader/


        http://scaleout2:8080/daytrader/

    This launches the DayTrader start page.

    The DayTrader GUI has changed significantly between the different versions available. So depending on the DayTrader version we have installed, this might look quite different.

    Before we can actually use DayTrader, we need to populate the underlying database. To do so, click the Configuration link in the navigation frame. This launches the DayTrader configuration window (again, this can look different depending on our DayTrader version).

    Now click the (Re-)populate Trade Database link to start populating the database.

    Figure 2-13 DayTrader configuration panel

    As soon as the database is successfully populated, we can go back to the DayTrader start page, log in and start using it.

    Figure 2-14 DayTrader home