On demand provisioning of portal servers in a clustered environment, Part 5: Run the solution

And migrate the automation package to Tivoli Intelligent Orchestrator V3.1

This series focuses on how the Advanced Design and Technology team uses IBM Tivoli® automation products for rapid deployment of replicated and clustered portal servers. This tutorial, which is the final installment in the series, explains how to use the Portal Provisioning Automation Package and run the team's solution. It covers how to assign server roles, staging strategies for portal servers, using Tivoli Intelligent Orchestrator (Intelligent Orchestrator) to add or remove servers from the portal cluster, and migrating the automation package to Intelligent Orchestrator V3.1. Finally, you'll leave with a few thoughts about how to use the workflows to automate the deployment of other software components.

Share:

Bob DeLima (bdelima@us.ibm.com), Senior Software Engineer, IBM

Bob DeLimaBob DeLima is a Senior Software Engineer for the IBM Software Group System House, Advanced Technology group in Research Triangle Park, NC. Bob is currently involved in advanced technology projects in the areas of high availability, provisioning, solution integration, and scenario-based software development. Contact Bob at bdelima@us.ibm.com.



Ron Doyle (rdoyle@us.ibm.com), Senior Technical Staff Member, IBM

Ron DoyleRon Doyle is a Senior Technical Staff Member in Software Group Strategy, working in the Advanced Design and Technology group in Research Triangle Park, NC. Ron is currently working on projects involving dynamic resource provisioning, software automation, and systems management. Ron can be reached at rdoyle@us.ibm.com.



07 March 2006

Before you start

The dramatic rise in the functions and scalability of middleware solutions are fueling a tremendous increase in their use to meet expanding business requirements. WebSphere® Portal Server is a key middleware product used for delivering dynamic information, executing business processes, and interacting with portal users. Its advanced features are accomplished by leveraging layered software products such as IBM WebSphere Application Server, DB2® Universal Database™, and IBM Tivoli Directory Server.

As a developer, you can leverage middleware to build your own applications, portlets, and dynamic content. This tutorial shows you how to operate the Portal Provisioning Automation Package, how to run our solution, and how to migrate the automation package to IBM Tivoli Intelligent Orchestrator V3.1.

About this series

This series from the Advanced Design and Technology team focuses on using IBM Tivoli automation products for rapid deployment of portal servers. We invite you to follow along as our team uses Intelligent Orchestrator to create a solution that automatically performs all the required steps to leverage data center assets to replicate portal servers, and to expand and shrink portal server clusters based on demand.

About this tutorial

This tutorial steps you through the operation of the Portal Provisioning Automation Package. It explains:

Prerequisites

Several assumptions are made about the supporting middleware required by this solution. Though we've provided skeletons that can be expanded to include installation of IBM HTTP Server and IBM WebSphere Network Deployment Manager, it is assumed that these pieces of middleware have already been installed and configured. The prerequisites are:

  • IBM HTTP Server is installed on a server that is defined in the {os} spare pool -- {os} being the installed operating system.
  • IBM WebSphere Network Deployment Manager is installed on a server that is defined in the {os} spare pool, and all WebSphere cell and cluster definitions have been configured.
  • An initial WebSphere Portal Server instance is installed and configured with all of the customer applications, and is defined as the initial cluster member for the WebSphere cluster.
  • A DB2 server is installed and set up as the application database server for the portal applications. The database properties should be recorded in the appropriate DCM definitions for the portal applications.
  • The repository has been set up and all of the required installation images have been created and saved in the repository, as specified in Part 4 of this series. The DCM settings have all been set accordingly to point to the correct image files.

Get more advice on choosing the correct materials for your needs in the next section, and in Resources.


Assigning servers to their specific roles

As mentioned previously in this series, spare pools were used extensively to facilitate the setup and management of servers and any required middleware. Initially, all servers used by our solution reside in the {os} spare pool. The general notion is that servers in the pools have only the operating system installed, and moving the server into other resource pools drives the installation of a software stack that is required for the server to assume a given role.

Because the focus of our solution is provisioning portal servers, we do not actually drive installation of HTTP Server, DB2 Server, or WebSphere Network Deployment Manager.

Initialization instructions

To assign server roles, from the Intelligent Orchestrator management console:

  1. In the left pane of the console, locate and click on the PIP {os} Spare Pool. In the right pane, locate the server that IBM HTTP Server was installed on and move the server to the Partner Interface Process (PIP) HTTP Server Pool - {os}. This drives the software stack installation for IBM HTTP Server. As noted previously, this really only provides some setup functions that are required, and assumes HTTP Server is already installed. The supporting workflows can easily be modified to also drive installation, if required.
  2. In the left pane of the console, locate and click on the PIP {os} Spare Pool. In the right pane, locate the server that WebSphere Network Deployment Manager was installed on and move the server to the PIP DM Server Pool - {os}. This drives the software stack installation for WebSphere Network Deployment Manager. This really only provides some required setup functions, and assumes WebSphere Network Deployment Manager is already installed. The supporting workflows can easily be modified to also drive installation, if required.
  3. We are now ready to drive the creation of new portal server instances. In the left pane of the console, locate and click on the PIP {os} Spare Pool. In the right pane, click on any remaining servers and move the servers to the PIP Portal Staging Pool - {os}. This drives the entire software stack installation for the new portal server instance. The supporting workflows will drive the installation and configuration of the PIP supporting files, DB2 Runtime Client, WebSphere Application Server EE and required fixpacks, and finally the custom portal server image containing all the required portal applications. Depending on the hardware and operating system, this can take two to three hours.

Staging strategies for portal servers

Depending on requirements, several different strategies can be adopted for creating new portal server instances. Though the process to create a new portal server has been greatly streamlined by this solution, it can still take two to three hours to create a new server instance. Our basic strategy was to create a staging pool that lets us preinstall and configure the portal server prior to it actually being required by the target customer application. Then, as load dictates, portal servers can be pulled out of the staging pools as needed, and the bring-up time is greatly reduced to only the amount of time it takes to add the new server to the WebSphere cluster.

It is certainly possible to skip the staging step altogether and simply have the customer's portal cluster (as defined in Intelligent Orchestrator) pull directly from the PIP {os} Spare Pool. All that would be required is to change the pool from which the sample portal cluster draws from PIP Portal Staging Pool - {os} to PIP [os} Spare Pool, and add the PIP sample portal software stack - {os} as a required software stack for the cluster. The approach you take should be dictated by the customer requirement.


Running the solution

As described earlier, associating software stacks with resource pools in Intelligent Orchestrator lets a specific set of software be automatically installed when servers are assigned to a resource pool. Using resource pools to create a staging area of servers with the appropriate software installed enables the rapid deployment of WebSphere Portal Server nodes to existing clusters. By following the instructions for assigning servers to specific roles and creating staging servers with resource pools, the necessary components for clustering with WebSphere Portal Server are set in place.

This section discusses how to use Intelligent Orchestrator to control the addition or removal of servers from the portal cluster, using workflows that interact with WebSphere Deployment Manager to control the node federation, and server cluster membership.

Operating instructions

To add a server to a cluster using Intelligent Orchestrator in manual mode:

  1. The administrator uses the Customer Cluster view and requests the addition of a server in the dialog box, as shown in Figure 1.
  2. Entering a number and selecting Add causes Intelligent Orchestrator to invoke the Cluster.AddServer logical device operation (LDO), which in turn invokes the workflow assigned to this LDO in the PIP tcdriver discussed previously in this series.
  3. The workflow walks through the steps of obtaining a server from the appropriate resource pool and interacting with Deployment Manager to add an instance of WebSphere Portal Server on this node, then joining this to the cluster.
  4. When initially setting up the solution, it is required that, using the steps outlined above, you manually add the HTTP Server to the HTTP cluster definition.
Figure 1. Intelligent Orchestrator Customer Cluster view
Intelligent Orchestrator Customer Cluster view

If the operating mode in Intelligent Orchestrator is set to automatic, the CPU load of the servers in the cluster is monitored by Intelligent Orchestrator, and the Cluster.AddServer LDO is invoked automatically when the CPU load exceeds the threshold specified for this cluster in Intelligent Orchestrator. The same path of workflow execution is followed as in the manual case.

The Intelligent Orchestrator view of a cluster before and after a server addition are shown in Figures 1 and 2. The CPU load has now been evenly distributed among the servers in the cluster.

Figure 2. TIO Customer Cluster view after server addition
TIO Customer Cluster view after server addition

Migrating the Portal Provisioning Automation Package to Intelligent Orchestrator V3.1

The workflows and automation package we've presented in this series were created with Intelligent Orchestrator Version 2.1. In the meantime, Intelligent Orchestrator Version 3.1, which offers many functional enhancements, was released. The structure of how software is represented in Intelligent Orchestrator changed in Version 3.1, so workflows and drivers for software written for the new version should be structured to fit into the new model. The differences in the software model representation are well documented in the Intelligent Orchestrator InfoCenter (see Resources).

To move the PIP driver to Intelligent Orchestrator Version 3.1, we followed the workflow migration instructions in the Intelligent Orchestrator V3.1 documentation. Further details beyond what we outline here for using the APDE to migrate workflows, or for issues around migration problems, are in the product documentation. The 3.1 version of our automation package is available by request on an as-is basis. We are working to make it available through the Tivoli Orchestration and Provisioning Automation Library site.

Migration instructions

The main steps for migrating an automation package are:

  1. Verify the TIO_installdir\migration\custom_automation_mig directory is empty or does not exist.
  2. Verify that the automation package to be migrated is not installed and to list all installed packages, enter: tc-driver-manager.cmd listAllStr
  3. To uninstall the package type:tc-driver-manager.cmd uninstallDriver package_name
  4. In a Cygwin window (for Windows), go to $TIO_installdir/migration/scripts and run: ./wf_migrate.sh dcm

The results of the workflow migration are stored in the file %TIO_LOGS%\migration\workflows directory. Review the contents of the log file to verify the migration and identify any migration errors.

Besides the automation package, we provided sample DCM assets for use in assisting the deployment of Portal Provisioning into Intelligent Orchestrator V2.1. These XML files were used to create templates for servers and resource pools to help with a quicker deployment of the solution. We've updated the XML file that defines server and resource pool templates, and plan to make it available with the 3.1 version of the automation package.


Final thoughts

In this series we presented how to quickly replicate WebSphere Portal Servers and automate the addition or removal of cluster members. You can use these two processes independently for creating staging servers, rolling out development or test machines, or for managing a production environment of WebSphere Portal Servers.

You can use the PIP automation package we created with the Intelligent Orchestrator for driving the base installation of the components of this solution, and for managing the cluster membership. The workflows are also useful as implementations of specific functions, or as examples if you want to use Intelligent Orchestrator or Tivoli Provisioning Manager (TPM) to automate the deployment of other software components.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Tivoli (service management) on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Tivoli (service management), Tivoli
ArticleID=105455
ArticleTitle=On demand provisioning of portal servers in a clustered environment, Part 5: Run the solution
publish-date=03072006