On demand provisioning of portal servers in a clustered environment, Part 4: Prepare to replicate and cluster

Install an automation package and configure the data center model

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 outlines how to set up Tivoli Intelligent Orchestrator in preparation for replicating and clustering portal servers. You'll learn how to install the WebSphere® Portal Provisioning Automation Package and how to customize the data center model for automation. Defining potential target servers with Intelligent Orchestrator is also covered.

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 February 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 install the WebSphere Portal automation package and how to configure the data center model definitions required by the automation package.

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 IBM Tivoli Intelligent Orchestrator (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 takes you through the steps required to install the WebSphere Portal provisioning automation package and how to customize the data center model definitions as required by the automation package. We'll also look at how to define potential target servers within Intelligent Orchestrator and the steps required for on demand operation.

Prerequisites

A Tivoli Intelligent Orchestrator management server must be installed and minimally configured. For this series we focus on version 2.1, though many of the principles discussed are also applicable to other versions. For help on installing Intelligent Orchestrator, see Resources.


Installing the automation package

Use the following steps to install the Portal Infrastructure Provisioning (PIP) automation package into Intelligent Orchestrator. On the Intelligent Orchestrator server, to install the driver:

  1. Copy pip.tcdriver to the %TIO_HOME%/drivers directory.
  2. Change the directory to: %TIO_HOME%/tools.
  3. Run tc-driver-manager.cmd installDriver pip. On non-Windows® systems, use the tc-driver-manager.sh command.
  4. Run tc-driver-manager.cmd listAllStr, which lists the drivers on the Intelligent Orchestrator system as well as their version and installation status. Verify the status of the PIP driver is "Installed."

Adding and modifying software definitions

Intelligent Orchestrator provides constructs for defining individual pieces of software and for grouping the software products into software stacks that can be installed as part of one operation. A software product definition can point to things such as install packages and provides a way to perform a customized installation. In most cases, there are actually three definitions for each software product: one for Windows, one for Linux®, and one for AIX®.

Software definitions can be added to the data center model by using the Intelligent Orchestrator Web interface or by defining them in an Extensible Markup Language (XML) format and importing them into Intelligent Orchestrator. Often, support for software is added in the form of automation packages, so it is appropriate to use XML to define the software and include the XML file in the automation package. The format to be used in the XML file is defined in the xmlimport.dtd file, which resides in the xml directory of the Intelligent Orchestrator system.

Editing the pip-software.xml file and importing the definitions

All of the software definitions required for this solution have been provided in the pip-software.xml file. You can modify this template by simply opening the file in the editor of your choice, then importing the result into Intelligent Orchestrator using the xmlimport tool.

For portability reasons, UNIX® path names are used wherever path definitions are required. For Windows platforms, support for UNIX paths are provided by Cygwin, and the Cygwin convention /cygdrive/drive letter/.. is used when creating paths (for example, /cygdrive/c/windows is the same as c:\windows). Short names should be specified whenever there are spaces in the path names; for example, c:\program files should be specified as /cygdrive/c/progra~1.

  1. Review the installation directories for each piece of defined software. These variables will have the format pip.xxxxPath or pip.xxxLocation. In most cases, the default directories have been used throughout, so changes to this are only required if the installation is to be performed on non-standard directories.
  2. Review the pip.imageFile variable for each piece of defined software. This is the name of the installation archive that's used for the respective piece of software.
  3. Review the settings for PIP WebSphere Application Server Deployment Manager {os}. Specify the WebSphere cell name, admin id and password, and SOAP port to be used for managing the portal server cluster.
  4. Review the settings for PIP Sample Portal Application {os} and PIP WPS51 {os}. Specify the DB2 server and connection properties and the database names required by the portal application. Specify the WebSphere Deployment Manager name and cluster name the portal server belongs to.
  5. Copy the edited file into the %TIO_HOME%/xml directory.
  6. Run the following command to import the definitions into the data center model:
    %TIO_HOME%\tools\xmlimport.cmd file:pip-software.xml

    On UNIX systems, use xmlimport.sh.

Configuring the data center model

The data center model is an abstraction (stored in a database) of all of the physical and logical assets under Intelligent Orchestrator management. These assets include the servers, switches, load balancers, application software, VLANs, security policies, service level agreements, and so on that are defined through the management interface.

The database facilitates the information transfer between all of the other Intelligent Orchestrator components and makes it possible for the components to read and update information according to any resource manipulations that have been performed. Information required to communicate with the managed assets, such as authentication and interface methods to use, is also stored in the central database.

Editing the pip-sample-datacenter.xml file and importing the definitions

All of the additional data center definitions required for this solution have been provided in the pip-sample-datacenter.xml file. Many of the items defined here are not actually relevant for provisioning portal specifically but are "plumbing" items required by Intelligent Orchestrator for wiring all the definitions together. You can make modifications to this template by simply opening the file in the editor of your choice, then importing the result into Intelligent Orchestrator using the xmlimport tool.

  1. Review the definitions for the Intelligent Orchestrator management server. The variable pip.ITIOServerName is used to defined the name of the management server. The server itself is defined under the PIP Management Servers - spare pool definition. Review the repository directory definition and verify the server IP address and security settings defined within the SAP definitions.
  2. Review the spare pool definitions for PIP Windows Spare Pool and PIP Linux Spare Pool. This is where all of the servers to be used as part of the solution will be initially defined. Verify that each potential target server has a definition in the appropriate spare pool and that each server has IP properties and security information defined accordingly.
  3. Copy the edited file into the %TIO_HOME%/xml directory.
  4. Run the following command to import the definitions into the data center model:
    %TIO_HOME%\tools\xmlimport.cmd file:pip-sample-datacenter.xml

    On UNIX systems, use xmlimport.sh.

Setting up data center model properties to enable on demand operation

The orchestration function of Intelligent Orchestrator supports three modes of operation:

Manual
The user initiates all actions and recommendations.
Semi-automatic
Intelligent Orchestrator recommends actions to the user to meet operating goals but does not make the actions.
Automatic
Intelligent Orchestrator orchestrates the recommendations and enforces the actions upon the data center model to meet operating goals.

You can select the operating mode on a cluster basis per customer, or you can set the operating mode under the global configuration tab in Intelligent Orchestrator.

For the automatic mode to operate correctly, Intelligent Orchestrator must be configured to receive CPU information from the servers in the data center model. See Resources for guidance in properly setting up CPU monitoring for Intelligent Orchestrator.


Setting up server security

This section discusses security setup for the Intelligent Orchestrator management server and managed servers. To use Intelligent Orchestrator to manage the deployment of software on managed servers, communication using the Secure Shell (SSH) protocol must be enabled. For Windows systems you can do this by installing the CYGWIN product and using its SSH package. SSH is available as a package on Linux, AIX, or Solaris systems.

There are two distinct efforts for setting up the security for Intelligent Orchestrator and managed servers:

Setting up SSH

If you are using Windows servers, use the Intelligent Orchestrator product documentation to learn how to obtain CYGWIN and the required packages to install. The product documentation also covers the necessary steps to configure SSH, which we highlight here.

  1. Open a Cygwin bash shell window. To generate host keys, switch to the /usr/bin directory and run ./ssh-host-config -y. When prompted for environment variables, select Enter to accept the defaults.
  2. Switch to the /var directory and enter export CYGWIN=ntsec, then chmod 700 empty.
  3. Start the Cygwin service by running the cygrunsrv -S sshd command.
  4. Enter cd to return to the Cygwin home directory. To generate the user keys, enter:
    ssh-keygen -t rsa -N ""

    When prompted, accept the defaults by selecting Enter.
  5. Switch to the ./.ssh directory by entering cd .ssh
  6. Run the command
    cat id_rsa.pub > authorized_keys
  7. To configure SSH to accept connections from new hosts without prompting for confirmation, create a file called config in the /home/thinkcontrol/.ssh directory. The file should contain the line StrictHostKeyChecking no
  8. To verify that SSH is configured properly, ensure the Cygwin service is started. To log in to the local host through SSH, enter ssh tioadmin@<localhost>, where <localhost> is your hostname. If SSH is properly configured, you will see the following message:
    "Fanfare!!!   You are successfully logged in to this server!"
  9. Exit the bash shell by entering exit.
  10. Copy the id_rsa.pub file, which contains the public keys, into the authorized_keys file of the administrative account of any server in the data center that the IBM Tivoli Intelligent ThinkDynamic Orchestrator server must communicate with or manage.

    For managed servers this requires that you concatenate the id_rsa.pub file onto the existing authorized_keys file in the target users .ssh directory.

Configuring SAPs in the data center model

For Intelligent Orchestrator to automatically use the correct IBM Rational® Software Architect (RSA) credentials when interacting with managed servers, you must configure the SAP credential for each of these servers in the data center model. SAPs are defined in the Credentials tab in the Server definition in the data center model, as shown in Figure 1.

  1. For each managed server, go to the Credentials tab in the Intelligent Orchestrator user interface for that server.
  2. Be sure that there is an RSA SAP defined for SSH. These definitions came from the sample_datacenter.xml mentioned previously and should have been modified to fit the target environment before being imported in the data center model.
  3. Click Edit for this SAP and make sure the username is appropriate for the user on the target node.
Figure 1. Intelligent Orchestrator Server credentials
Solution flow diagram

Summary

In this tutorial, you learned how to install the WebSphere Portal Provisioning Automation Package and how to customize the data center model for automation. We discussed the required software definitions and the appropriate places to make customizations.The tutorial also covered defining potential target servers within Intelligent Orchestrator and how to set up security between the management server and target servers. In the next and final article in this series, we'll talk about putting all of the pieces together and running the solution, migrating the solution to Intelligent Orchestrator v3.1, and close with some final thoughts. We look forward to seeing you back!

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, WebSphere
ArticleID=103315
ArticleTitle=On demand provisioning of portal servers in a clustered environment, Part 4: Prepare to replicate and cluster
publish-date=02072006