Introduction

At the end of Part 5 of this series, the user is in a WebSphere Portal Server Network Deployment (ND) environment and has the ability to deploy any number of WebSphere Business Monitor 6.0.2 (Monitor) enterprise archive (EAR) files, to as many nodes and servers as the user wants to federate. With the obvious benefits of ND enhancing the Monitor topology, the user could control a much more robust monitoring environment. However, if the user deploys several Monitor EAR files to one server, it processes events for awhile and then crashes, this means all subsequent events will not be processed. Depending on your topology, the events might remain in the application's queues. This single point of failure is highly undesirable.

Clustering with WebSphere Business Monitor V6.0.2

The solution to the problem is clustering. Monitor 6.0.2 does not enforce any specific event sequencing. To ensure that the events being processed are in the order in which they were received, only one active instance of any Monitor model version may be running in a cell. If the server on which the EAR file is running were to suddenly crash, the other servers do not take over the needed processing. Monitor 6.0.2 leverages clustering to provide high availability to the end user.

Inside a cluster, there can be any number of homogeneous servers (all of the servers have the same configuration regardless of hardware). Certain aspects can be tweaked for performance or stress reasons, but basically the configurations of all cluster members are identical. If you deploy a Monitor EAR file and target the cluster as a deployment target, the EAR file will only run on one specific cluster member at a time. If that server crashes, another cluster member picks up processing once it knows that the other server has crashed. The single point of failure is thus eliminated.

There is one caveat with clustering WebSphere Business Monitor 6.0.2. Without implementing event-sequencing rules, the other benefit of clustering cannot be leveraged. Your overall throughput of monitored events will not increase due to clustering. Throughput is the output or production over a unit of time. Since you will only ever have one instance of an application active, the same amount of production will always be performed over any given period of time. Implementation of event-sequencing rules allows for multiple instances of the same version to be running at the same time. During any given period of time, with N total instances running, you would be able to process approximately N times as many events in the same time period as before, depending on hardware and external load balancing. The ability to run multiple application instances inside of the same cell will hopefully be supported in future releases of Monitor.

Even without the advantages of increasing your overall throughput, the provided failover support and ability to create homogeneous Monitor servers with minimal effort are two great reasons to cluster your Monitor ND environment. The next section walks you through some best-practice steps to creating your first Monitor server cluster.

Back to top

Clustering Monitor servers

1. In the admin console, go to Servers > Clusters, and click New.
   
   Figure 1. Create a new cluster
   
   
   
2. Enter a name for the new cluster, and ensure the Do not include an existing server in this cluster radio button is checked. Click Next.
   
   Figure 2. Enter cluster information
   
   
   
3. Enter a name for the new cluster member and then select a Monitor-enabled node.

   A Monitor-enabled node has had Monitor installed with Launchpad and then federated over, or has been previously hand-enabled. (Hand-enabling Monitor nodes is covered later in this article.)

   In the Select Template panel, click the Existing Application Server radio button and select your federated Monitor server from the drop-down box. Click Apply. Repeat this step for each desired cluster member on any Monitor-enabled node. It is advisable to always generate unique HTTP ports. As soon as the desired number of cluster members are added, click Next.

   
   
   Figure 3. Create cluster members from Monitor template
   
   
   
4. Verify the Summary panel and click Finish. Save your changes after the creation completes.
   
   Figure 4. Verify summary panel
   
   
   
5. You can now manage your cluster of Monitor servers from the cluster scope, as if they were one server.
6. You can now move any existing Monitor applications into your new cluster. All you have to do is change the deployment target of your application; from the Admin Console go to Applications > Enterprise Applications > [AppName] > Map modules to servers and select the newly created cluster as the deployment target.

Clustering summary

• Remember to only deploy the same number of models on your new cluster as you would for any single server. Because the applications and servers are now clustered does not necessarily mean greater point-in-time performance. Any server in the cluster can be running 0 through N number of instances for N number of model versions. You cannot guarantee that just because the server is clustered that it will only be running a subset of the applications at any one time.
• When you remove a cluster, you are also removing the cluster members. Once a cluster member is added to the cluster, there is no way of extracting the server back out again. This is generally not a problem, but if you inadvertently delete your cluster, you will also lose all of the members inside that cluster.

  Be careful when you add servers to clusters as cluster members (not preferable), or when you create cluster members from a template of an existing server (preferable). The above method for creating the Monitor cluster creates the cluster members by using our federated 'server1' as the server template.

• Monitor servers and Monitor cluster members can only be created on Monitor-enabled nodes. These are nodes that have had Monitor installed on them by Launchpad and then federated over. Or, you can perform the following steps to Monitor-enable a base node. (This is an unsupported method, but is quicker than installing with Monitor Launchpad.)
  1. If the following Java™ archive (JAR) files do not exist in the node's ProcServer/lib, copy them from a Monitor-enabled node's ProcServer/lib:
     • aasserver.jar
     • monABXUtils.jar
     • monAddNodeDMgrHook.jar
     • monBaseBeans.jar
     • monBootstrap.jar
     • monceiutil.jar
     • monCommonUtilities.jar
     • mondblayer.jar
     • monEventDefinition.jar
     • monExpression.jar
     • monHaAccessMBean.jar
     • monkpi.jar
     • monLifecycle.jar
     • monLifecycleSPI.jar
     • monMMUtilities.jar
     • monModel.jar
     • monOmInstallHook.jar
     • monReplicationManager.jar
     • monReplicationManager_templates.jar
     • monrepository.jar
     • monresources.jar
     • monschemagenerator.jar
     • monschemagenrt.jar
     • monSPI.jar
     • monSPIImpl.jar
     • monutil.jar
     • monValidator.jar
     • monWBIDSUtilities.jar
     • servergen.jar
     • ws-wbi-monitor.jar
  2. Create the following WebSphere variables at the node scope for the node you are enabling:
     
     

     Name	Value
     WBMONITOR_HOME	<MonitorHome> (ie C:\IBM\WebSphere\Monitor)
     WBMONITOR_NODE	<NodeName>
     WBMONITOR_SERVER	<ServerName> (default: server1 should be acceptable)
     WBMONITOR_WBM_MONSRV	installed

     
     
     
  3. Verify that the following Java Virtual Maching (JVM) properties are set in the WebSphere admin console. (These will be set if you create a cluster member from a template of a federated Monitor server. This step is just for verification.)

     In the admin console, go to Servers > Application Servers > ClusterMemberName > Java and Process Management > Process Definition > Java Virtual Machine.

     • Add the following to the generic JVM arguments field (all on one line):

       -Dmonitor.repository.schema=<SCHEMANAME> (default: REPOS) -Dmonitor.datamart.schema=<SCHEMANAME> (default: WBI)

       
       
       
       
       Figure 5. JVM arguments
       
       
       
     • Add the following custom properties:
       
       

       Name	Value
       WBI_AAM_RUNTIME_SCHEMA	<SchemaName> (default: WBI)
       mon.install.root	<MonitorHome> (default: C:/IBM/WebSphere/Monitor) These need to be UNIX slashes
       ws.ext.dirs	${CEI_HOME}/lib;${CEI_HOME}/client

       
       
       
  4. In the admin console, stop any servers that are currently running. On each of the machines, restart the Node Agents via the command line. Then restart each of the servers using the admin console.
  
  
  

Back to top

Dashboard federation

In this series you have learned to create a monitor installation in an Network Deployment environment, including the monitor servers, Common Event Infrastructure (CEI) server, event-generation servers, and messaging engine servers in the ND cell. You are probably wondering why we have not yet included the portal dashboard machine in this ND cell. There are considerable additional steps to include a portal machine into a ND cell. Because many administrators prefer to have all components of a system included in the cell, this section covers the federation of the portal server with dashboards into the ND cell.

You should federate the portal node to the deployment manager prior to configuring any dashboard portlets or before importing any data into the Alphablox database (DB). As with the Monitor server node, install dashboards prior to federation. The following instructions assume:

• You have a remote DB server configured and ready.
• Security is turned off on both the portal machine and the ND cell.
• The cell you will be federating to already has at least one Monitor server in the cell.

The portal federation will only work if your WebSphere Process Server machines have been upgraded to Fix Pack 1 (6.0.2.1).

Prepare WebSphere Portal

To prepare WebSphere Portal for federation into the WebSphere Process Server ND cell:

1. Convert the WebSphere Portal databases from Cloudscape™ to DB2®.

   You have two options for this conversion:

   • Use the DB transfer wizard (recommended for simple portal configurations). You must catalog your remote databases so that the wizard sees them as local when running.
     1. Run <wp_root>/config/wizard/configwizard.bat
     2. On the Welcome panel, click Next.
     3. On the Task Selection panel, select Transfer data to another database, as shown here.
        
        
        Figure 6. Select transfer data to another database
        
        
        

        Click Next.

     4. On the Database Type Selection panel, select IBM DB2 Universal Database.
        
        Figure 7. Select database type
        
        
        

        Click Next.

     5. On the Properties File Location panel, enter the location of the .properties file you would like to use.

        Leave the default and click Next.

     6. On the Database Instances Information panel, enter the directory where your db2java.zip is located.
        
        Figure 8. Input your db instance information
        
        
        

        Click Next.

     7. On the WebSphere Portal Server Database (WPSDB) Information panel, enter your wpsdb database information. If your databases are remote, make sure you have cataloged the databases on your portal machine.
        
        Figure 9. Input your WPSDB database information
        
        
        

        Click Next.

     8. On the WMM Database Information panel, enter your wmmdb database information. If your databases are remote, make sure you have cataloged the them on your portal machine.

        In the example, the wmm tables are put in the WPSDB.

        
        
        Figure 10. Input your WMMDB DB information
        
        
        

        Click Next.

     9. On the Database Transfer Confirmation panel, click Next.
     10. On the Database Transfer Completion panel, verify that your data has transferred successfully and click Finish.
   • Use the DB transfer script (recommended for complex portal configurations).

     Locate <wp_root>/config/wpconfig.properties. This will allow for the transfer of data to a remote database and to all supported portal databases (Feedback, likeminds, wmm, WPSDB, and JCR DB).

   After transferring your Cloudscape database to DB2, verify that portal is still operational.

2. Increase timeout variables for deployment manager and the portal node to be federated.
   • Increase the ConnectionIOTimeOut value for the WebSphere Portal application server and the deployment manager.

     For the dashboard server:

     • Log in to the administrative console for the WebSphere Portal node.
     • Change the timeout values for the WebSphere Portal application server:
     1. Navigate to Application Servers > WebSphere Portal > Web container settings > Web container transport chains.
     2. Increase the timeout values. For each entry listed in the Web container transport chains section, complete the following steps to increase the timeout values:
        
        Figure 11. Select your transport chain
        
        
        
        • Click HTTP Inbound Channel.
          
          Figure 12. Select the HTTP Inbound Channel
          
          
          
        • Change the Read timeout value to 180.
        • Change the Write timeout value to 180.
          
          Figure 13. Update the Read/Write timeout
          
          
          
        • Click OK.
        • Repeat until all transport chains are updated.
        • Save the configuration changes.

     For the deployment manager, log in to the administrative console for the deployment manager.

     1. Click System Administration > Deployment Manager > Web container transport chains.
     2. Increase the timeout values for the deployment manager as you did above for the WebSphere Portal node. Use the same property names and values as you did for the WebSphere Portal node.

     Restart the WebSphere Portal application server and the deployment manager server. Increase the request timeout for the SOAP client:

     1. On both the dashboard and deployment manager machines, change the timeout request for the SOAP client.
     2. Edit the soap.client.props file in the following directory: <was_profile_root>/properties
     3. Change the line to:

        com.ibm.SOAP.requestTimeout=6000

        
        

3. Update the heap size for both the deployment manager and the portal node to be federated.
   • On the dashboard machine, locate the setupCmdLine file: <was_profile_root>/bin/setupCmdLine.

     Add the following line to that file:

     SET JVM_EXTRA_CMD_ARGS=" -Djava.security.properties=% WAS_HOME%/java/jre/lib/security/java.security -Xms256m -Xmx1024m"

     
     

   • On the deployment manager machine, update the maximum Java heap size used by the deployment manager.

     In the deployment manager administrative console, select System administration > Deployment manager > Java and Process Management > Process Definition > Java Virtual Machine.

     1. Update the value in the Maximum Heap Size field. A value of at least 1024 MB is recommended.
     2. Click OK, and save your changes.

Federate your WebSphere Portal to your deployment manager

4. On the dashboard machine, run the addnode command.

   Ensure that the deployment manager server is running and the portal server are running. From the server system, to be added:

   • <was_profile_root>\bin\
   • Run the following:

     addnode <DMGR Hostname> -includeapps -trace

     
     

Post portal federation steps

5. On the dashboard machine that was just federated into the cell, update the wpsconfig.properties file to show federation and a new cell.

   The location of the file is: <wp_root>/config/wpconfig.properties. Change the CellName property to the new cell name of the portal node.

6. Update the deployment manager configuration for the new WebSphere Portal node.

   Run the following command from the <wp_root>/config directory:

   WPSconfig.bat post-portal-node-federation-configuration

   
   

7. On the dashboard machine that was federated into the cell, edit the wpconfig.properties file.

   Ensure that WebSphere Portal can be accessed using the values specified for the WpsHostName and WpsHostPort properties.

8. Verify that dashboards are working.

   Your URL will be: <Your Fully Qualified Domain Name of Portal machine>/wps/portal

Back to top

Summary

You now have all of your WebSphere Business Monitor components under the control of one deployment manager. Those components are Monitor server(s), Monitor dashboard, and Monitor admin console. All applications and servers will now be started and stopped through the deployment manager. All of your portal databases have been configured to use DB2, and any previous data has been transferred to the DB2 databases on your DB2 server.

After following the topics and instructions in this series, you should now be able to set up a variety of WebSphere Business Monitor installations, ranging from a simple single machine installation used for model creation and verification to an advanced Network Deployment configuration that can have all or some of the monitor components controlled by the deployment manager machine.

The authors hope the installation articles have been helpful and invite you to e-mail them with any questions. Stay tuned for future installments in this series by subscribing to an RSS feed.

Resources

Learn

• In other parts of this series:
  • Part 1 introduces the core elements of a monitor model by walking through an example.
  • Part 2 walks through installing and configuring a basic IBM WebSphere Business Monitor V6.0.2 deployment.
  • Part 3 explains how to install and configure an advanced IBM WebSphere Business Monitor V6.0.2 deployment.
  • Part 4 gives an overview of the WebSphere Business Monitor server's dashboard views, and how to use them for monitoring.
  • Part 5 explores dimensional analysis, a technique that can help you model your data to achieve your goals for efficient and informative reporting.
  
  
• RSS feed for this series. (Find out more about RSS.)
  
  
• Get an Introduction to clusters from the WebSphere Application Server Network Deployment InfoCenter.
  
  
• For more on portal federation, read about Clustering and WebSphere Portal.
  
  
• In the Architecture area on developerWorks, get the resources you need to advance your skills in the architecture arena.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  
• Check out IBM on demand demos to learn more details about various software products and technologies from IBM.
  
  
• Stay current with developerWorks technical events and webcasts.
  
  

Get products and technologies

• Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the authors

Rick Osowski has worked with WebSphere Business Monitor for nearly 2 years. Rick graduated from Penn State University with a degree in Computer Science. Rick employs his previous WebSphere Application Server and UNIX® experience on a daily basis while installing, deploying, and testing WebSphere Business Monitor.

Alex Peay has worked on the WebSphere Business Monitor project for 3 years. Alex graduated from Brigham Young University with a degree in Information Systems Management. Prior to working with IBM, Alex was a project manager at a start-up company.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Clustering with WebSphere Business Monitor V6.0.2
• Clustering Monitor servers
• Dashboard federation
• Summary
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America