Ibm tivoli intelligent think dynamic orchestrator pre proof of-concept cookbook for business partners redp3830

Front cover

IBM Tivoli Intelligent
ThinkDynamic Orchestrator
Pre Proof-of-Concept Cookbook for Business Partners

Installation and customization

Data center modeling

Workload simulation

Edson Manoel
Tony French

ibm.com/redbooks Redpaper

International Technical Support Organization

IBM Tivoli Intelligent ThinkDynamic Orchestrator
Pre Proof-of-Concept Cookbook for Business
Partners

February 2004

Note: Before using this information and the product it supports, read the information in
“Notices” on page vii.

First Edition (February 2004)

This edition applies to IBM Tivoli Intelligent ThinkDynamic Orchestrator Version 1.1.0 and IBM
Tivoli Provisioning Manager Version 1.1.0.
© Copyright International Business Machines Corporation 2004. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Recommended reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
The team that wrote this Redpaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 2. Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 General questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 ITITO components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 Power units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 Network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.4 Spare pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.5 Applications and customers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.6 Other devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.7 Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Chapter 3. Installing the demonstration systems . . . . . . . . . . . . . . . . . . . 25
3.1 Installation process overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.1 Recommended installation directories . . . . . . . . . . . . . . . . . . . . . . . 28
3.1.2 User IDs and passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Installing and configuring TIOdbsrv - Windows . . . . . . . . . . . . . . . . . . . . . 30
3.2.1 Creating the required user IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.2 Installing and configuring Cygwin . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.3 Configuring SSH communications . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.4 Installing and configuring IBM DB2 UDB V8.1.2 on Windows . . . . . 34
3.2.5 Installing and configuring IBM Directory Server V5.1 . . . . . . . . . . . . 39
3.3 Installing and configuring TIOsrv - Windows . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.1 Creating the required user IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.2 Installing and configuring Cygwin . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.3 Configuring SSH communications . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.4 Installing IBM DB2 Universal Database V8.1.2 Client. . . . . . . . . . . . 48
3.3.5 Installing and configuring IBM Directory V5.1 Client . . . . . . . . . . . . . 50

© Copyright IBM Corp. 2004. All rights reserved. iii

3.3.6 Installing IBM WebSphere Application Server Base V5.0. . . . . . . . . 52
3.3.7 Install the IBM WebSphere fixpack 1 and required fixes. . . . . . . . . . 55
3.3.8 Installing IBM Tivoli Intelligent ThinkDynamic Orchestrator . . . . . . . 67

Chapter 4. Creating the demonstration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.1.1 WordPad or Notepad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.1.2 Cooktop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.1.3 XMLSpy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.2 Designing the data center model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.2.1 ITITO GUI method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.2.2 The XML method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.2.3 DOCTYPE element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.2.4 Power supplies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.2.5 Network components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.2.6 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.2.7 Spare pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.2.8 ITITO configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.2.9 Customers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.3 Sample XML files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.3.1 Cookbook example DCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.3.2 Redbook example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.4 Loading the data center model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.4.1 Tip for creating XML files using text editors . . . . . . . . . . . . . . . . . . . 94
4.5 Configuring the simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.5.1 Data center model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.5.2 The tdnetworks file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.6 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Chapter 5. Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.1 Introduction to ITITO and the scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.1.1 ITITO: A quick overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.2 Data center assets and resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.2.1 Show the switch fabric and inventory resources . . . . . . . . . . . . . . . 110
5.2.2 Show the customer the resource pools. . . . . . . . . . . . . . . . . . . . . . 111
5.3 Customer applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.4 Real-time performance monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Appendix A. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
System requirements for downloading the Web material . . . . . . . . . . . . . 120
How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

iv Pre Proof-of-Concept Cookbook for Business Partners

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Product manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Contents v

vi Pre Proof-of-Concept Cookbook for Business Partners

Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such provisions
are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES
THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.

This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.

COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.

© Copyright IBM Corp. 2004. All rights reserved. vii

Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:

AIX® ibm.com® RS/6000®
DB2 Universal Database™ OS/390® Tivoli®
DB2® Redbooks™ WebSphere®
IBM® Redbooks (logo) ™ z/OS®

The following terms are trademarks of other companies:

Intel, Intel Inside (logos), and Pentium are trademarks of Intel Corporation in the United States, other
countries, or both.

Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.

Other company, product, and service names may be trademarks or service marks of others.

viii Pre Proof-of-Concept Cookbook for Business Partners

Preface

IBM® has changed the provisioning paradigm from “just-in-case” to “just-in-time”
on demand provisioning with IBM Tivoli® Intelligent ThinkDynamic Orchestrator
(ITITO) and IBM Tivoli Provisioning Manager, for managing resource information
and enhancing automation.

IBM Tivoli Intelligent ThinkDynamic Orchestrator and IBM Tivoli Provisioning
Manager automate the traditional manual provisioning process, performance
measurement, capacity planning, and infrastructure deployment. IBM Tivoli
Intelligent ThinkDynamic Orchestrator operates in a closed loop that performs
automatic resource requirements prediction, based on predefined service level
objectives and agreements, and automates infrastructure deployment. This
just-in-time cycle ensures that each application has the resource it needs, when
it needs it — without static over provisioning.

The primary objective of this IBM Redpaper is to provide step-by-step
instructions about how to set up a stand-alone IBM Tivoli provisioning solution
environment to be used for demonstrating the functions and features of the
products, using customer data and mapping customer infrastructure and
workloads.

General knowledge is assumed of communication network architecture and
design, network security architecture and design, data center environment
infrastructure and operations, Java™ and XML coding, database and Web
application servers.

This document is intended to be read and used by pre-sales systems engineers
and services personnel to build customized demonstrations of the IBM Tivoli
Intelligent ThinkDynamic Orchestrator. A significant amount of knowledge of
ITITO is expected, and the reader should ideally have attended the ITITO basic
and advanced training classes.

The reader should be familiar with the following topics:
XML and XML concepts
Network topologies
Switch, router, firewall, and load balancer configuration
Software packaging
Distributed systems architectures and configuration

This Redpaper is a valuable addition to and can be read in conjunction with the
existing product documentation. See the following recommended reading.

© Copyright IBM Corp. 2004. All rights reserved. ix

Recommended reading
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this Redpaper.

Product manuals:
IBM Tivoli Intelligent Orchestrator and Tivoli Provisioning Manager Release
Notes, SC32-1422
IBM Tivoli Intelligent Orchestrator and Tivoli Provisioning Manager Operator’s
Guide, SC32-1421
IBM Tivoli Intelligent Orchestrator and Tivoli Provisioning Manager Installation
Guide, SC32-1420
IBM Tivoli Provisioning Manager and Intelligent Orchestrator Overview Guide,
SC32-1419

Online resources:
IBM Tivoli Intelligent ThinkDynamic Orchestrator Product Web page:
http://www.ibm.com/software/tivoli/products/intell-orch/
IBM Tivoli Provisioning Manager Product Web page:
http://www.ibm.com/software/tivoli/products/prov-mgr/

IBM Redbooks™:
Provisioning On Demand: Introducing IBM Tivoli Intelligent ThinkDynamic
Orchestrator, SG24-8888
http://www.redbooks.ibm.com/redbooks/pdfs/sg248888.pdf
IBM Web Infrastructure Orchestration, SG24-7003
http://www.redbooks.ibm.com/redbooks/pdfs/sg247003.pdf

The team that wrote this Redpaper
This Redpaper was produced by a team of specialists from around the world
working at the International Technical Support Organization, Austin Center.

Edson Manoel is a Software Engineer at IBM Corporation, International
Technical Support Organization, Austin Center, working as an IT Specialist in the
Systems Management area. Prior to joining the ITSO, Edson worked in the IBM
Software Group as a Tivoli Technology Ambassador and within IBM Brazil
Professional Services Organization as a Certified IT Specialist. He was involved
in numerous projects, such as designing and implementing systems

x Pre Proof-of-Concept Cookbook for Business Partners

management solutions for IBM customers and Business Partners. Edson holds a
bachelor’s degree in Applied Mathematics from Universidade de Sao Paulo,
Brazil.

Tony French is a Tivoli Services Consultant in the U.K. He has 21 years of
experience in the IT industry, including six years experience in Tivoli Software.
His areas of expertise include IBM Tivoli Intelligent ThinkDynamic Orchestrator,
IBM Tivoli Business Systems Manager, and the Tivoli Framework suite of
products. He has written extensively about IBM Tivoli Business Systems
Manager.

Thanks to the following people for their contributions to this project:
Morten Moeller ITSO Austin Center
Sara C. Brumfield ITITO Level 2 Support, IBM Software Group
Theo Winkelmann On Demand Sales Enablement, IBM Software Group
Leonard Hand Senior Consulting I/T Architect, IBM Global eBusiness
Solution Center

Become a published author
Join us for a two- to six-week residency program! Help write an IBM Redbook
dealing with specific products or solutions, while getting hands-on experience
with leading-edge technologies. You'll team with IBM technical professionals,
Business Partners and/or customers.

Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you'll develop a network of contacts in IBM development labs, and
increase your productivity and marketability.

Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html

Comments welcome
Your comments are important to us!

We want our papers to be as helpful as possible. Send us your comments about
this Redpaper or other Redbooks in one of the following ways:
Use the online Contact us review redbook form found at:
ibm.com/redbooks

Preface xi

Send your comments in an Internet note to:
redbook@us.ibm.com
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. JN9B Building 003 Internal Zip 2834
11400 Burnet Road
Austin, Texas 78758-3493

xii Pre Proof-of-Concept Cookbook for Business Partners

1

Chapter 1. Introduction
This document describes a method to build a customized demonstration of IBM
Tivoli Intelligent ThinkDynamic Orchestrator (ITITO) for any customer. It is
expected that such a task can be achieved over a period of three working days,
consisting of the following major activities:

Planning
Interviewing the customer and the customer’s technical specialists to
determine which of the customer’s applications are suitable to be automated
with ITITO and the nature and extent of the components that make up these
applications.
Negotiating with the customer to remove components that are either not
necessary to demonstrate the product or would be too time-consuming to
build.

Data center modeling
Some discussion of the software tools that might be useful.
Installation instructions for installing the IBM Tivoli Intelligent ThinkDynamic
Orchestrator management servers on Microsoft® Windows® Server 2000.
Using the information gathered in the interviews to create a data center model
definition in XML format for loading into ITITO.
Some examples of data center elements that can be used as templates.

© Copyright IBM Corp. 2004. All rights reserved. 1

Guidance on configuring the ITITO simulator for the customized data center
model.

Demonstration
Guidelines demonstrating the key features of the ITITO product.
Provisioning and orchestrating, including:
– Data center assets and resources
– Customer applications
– Real-time performance monitoring

2 Pre Proof-of-Concept Cookbook for Business Partners

2

Chapter 2. Planning
In this chapter, we discuss the planning required to build a customized
demonstration of ITITO. Planning typically involves interviewing the customer to
obtain a fairly detailed audit of the environment that they would like to automate
with ITITO. Obviously, the customer’s expectations and requirements are often
significantly greater than can be achieved in the time frame usually permitted to
build a demonstration, so the planning process should involve negotiations to
reveal elements of the customer’s requirements. This chapter contains some
guidelines to help in this area.


2.1 Interviews
To demonstrate to a customer how ITITO can be used in their environments, it is
necessary to conduct a number of interviews with various specialists. Building an
ITITO data center model can require a detailed level of information including, for
example, MAC addresses and information about which ports on the network
switch to which each network interface card (NIC) connects. For the purposes of
a demonstration, however, it is not strictly necessary to gather the finest detail,
but it may be advisable so that any subsequent Proof of Concepts (POC) project
has a head start.

The initial interviews should determine if the customer has any applications that
are suitable for automating with ITITO and selecting a number that can be used
to build the demonstration system. We recommend that at least two applications,
but no more than four, be selected to build the demonstration.

2.2 General questions
During the initial interview with the customer, these questions may be useful to
gain an overview of the customer’s environment and operating practices:
1. Does the customer have any applications that use clusters of similar servers
to provide a service?

Tip: If the customer has mainly mainframe-based computing and is not
planning to change to a distributed architecture, they are not an ideal
candidate. ITITO fits very well for applications that support horizontal
scaling (that is, Web, application servers).

2. Do the servers in these clusters run single applications or many?

Tip: If the customer runs more than one application in each server, this
application might not be suitable for automation by ITITO.

3. Typically, how many servers make up these clusters?
4. Do these clusters of servers use load balancers or application servers to
control the utilization of each server?
5. Does the customer provide sufficient servers to meet peak loads? What is the
average utilization of the servers in these application clusters?
6. How does the customer plan for peak loads (for example, year-end
accounting, special promotions, or sales)? Does the customer:


– Wait for the load to materialize and then take action as above?
– Build extra servers for each application and incorporate these into the
clusters?
– Do nothing? (Longer response times at peak times are normal!)
7. How does the customer handle peak loads in their applications? Does the
customer:
– Have a number of extra servers dedicated to each application?
– Reconfigure other application servers?
– Have a spare pool of servers that can be built to order?
8. When the peak loads subside, does the customer:
– Return any servers that were added to the application cluster to their
previous state?
– Leave the servers in place for the next peak?
9. If the customer returns servers to their previous state, how long does this
typically take?
10.Do the customer’s applications have peak loads at different times?
11.Could the customer conceivably use servers that are idle for one application
in another application that is undergoing a peak load?
12.Does the customer maintain a large number of dedicated test servers for
each application, or does the customer use a general pool of test servers?

Tip: The more the better: ITITO provides a great starting point in a
non-production environment and allows the customer to recover, redeploy,
or eliminate redundant servers in the test environment.

13.Typically, what is the utilization of the test server environments?
14.Are the applications written in-house or are they 100% “shrink-wrapped” from
the software vendor (that is, no customization)? Does the customer perform
their own development and testing?

Tip: ITITO can enhance the management and maintenance of customized
or homegrown applications. If the customer has a 100% shrink-wrapped
environment and rarely makes changes to their production/staging
environments, they are less qualified as a prospective customer.

15.Does the customer operate applications over multiple data centers?
16.Does the customer have control over their network environment, or is it
outsourced to a network provider?

Chapter 2. Planning 5

Tip: If the customer’s network is totally outsourced, they might not have
sufficient access to perform the dynamic reconfiguration that ITITO is
capable of providing.

17.What are the customer’s predominant operating systems (for example, AIX®,
Solaris, HP/UX, Microsoft Windows, or Linux)?

Tip: If the customer uses mainly OS/390® or non UNIX®/Intel® operating
systems, they might be less qualified as a prospect.

18.Does the customer have any blade servers? If so which types/makes (HP,
IBM, and so on)?
19.How many and what type of network switches is the customer using (that is,
Cisco, Extreme, Foundry, and so on)?

Tip: Our application is better suited for Level 3 (network layer) switches,
but we can also work with Level 2 (data layer) switches.

20.What level of redundancy is provided for at the network equipment level, if
any?
21.What type of network and systems management software is the customer
using (OpenView, Tivoli, CA UniCenter, and so on)?

Tip: Helps determine the level of sophistication present in the network
operations center.

22.What kind of storage infrastructure is in place (that is, Storage Area Network,
or SAN, Network Attached Storage, Redundant Array of Independent Disks,
or RAID)?
23.What are the customer’s dominant relational database management systems
(Oracle, DB2®, Microsoft SQL Server, MySQL, or other)? And, are clustered
database solutions being used?
24.What is the application server software, if any (WebSphere®, Weblogic,
Resin, Jboss, or other)?

The ideal outcome of these questions is to locate two to four applications that
have the following characteristics:
Clustered architecture


A low average utilization with idle servers available for peak demand
Or,
A pool of spare servers that are provisioned for peak demand
Use similar hardware and operating system platforms
Operate in a network that the customer has control over

Alternatively, if the customer wants to provision application test environments
from a pool of common servers rather than maintain separate test environments
for each application, ITITO can be a suitable tool for this, too.

The following table can be used to collect and summarize the data from these
questions:

Table 2-1 Capturing customer planning information skeleton
Applic- # Operating # # Avg. #
ation Servers systems Web Data- util Spare
servers bases % servers

2.3 ITITO components
After a limited number of suitable applications are identified, it is necessary to
gather additional technical details in order to build an ITITO data center model.
To simplify the data center model building, these components have been broken
down into the following categories:
Power units
Network configuration
Software configuration
Spare pools
Customers, applications, and clusters
Other devices

The following sections contain tables showing the required attributes that need to
be collected for each component type. The shaded cells in these tables are for
additional data that is not essential for a demonstration but is necessary for a full
ITITO build or Proof of Concept.


2.3.1 Power units
For the purposes of a demonstration, power units are optional in ITITO. It is
possible to define the power units and to associate devices with these power
units. It is also possible to manage the power units through an IP connection. For
a demonstration, it will usually only be necessary to collect the names of the units
for later reference by other devices:

Table 2-2 Power units data collection skeleton
Power unit name Manufacturer Model Device model

Note: The only devices that are supported by Version 1.1 of ITITO are as
follows:

Table 2-3 Power units data collection example
Manufacturer Model Device model

APC 7901 APC-7901-SNMP

APC 9606 APC-9606-SNMP

Note: It is also possible to define network interface cards (NICs) on a power
unit and associate it with a port on a network switch, but it was found that the
data center model would not load if this were done. However, it is possible to
define the interface from the ITITO GUI.

2.3.2 Network configuration
The ITITO network configuration consists of the following main components:
Switch fabric
Subnetworks
Switches
Load balancers
Virtual IPs
Access control lists (ACLs)

Each of the main components is addressed separately.

Most devices in ITITO require a number of service access points that define the
mechanisms and authentication information (user IDs and passwords) that are
used to communicate with the device. For a demonstration, these are not


required. However, if the customer is willing to provide this information, and if the
demonstration is likely to lead to a Proof of Concept or implementation, the
information can be collected in advance. This is addressed in the last segment of
this section.

Switch fabric
The switch fabric is an ITITO concept. For most customers, it will normally only
be necessary to define one switch fabric. All that is needed is the name of the
fabric. The customers name is recommended to be included here. This name will
be used in a number of other components later.

Table 2-4 Switch fabric data collection skeleton
Switch fabric name

Subnetworks
Every subnet in use by the applications defined in Section 2.2 on page 4 must be
defined to ITITO. In addition, the VLAN that is associated with the subnet must
be recorded.

Table 2-5 Subnet data collection skeleton
Subnet address Netmask VLAN

It is possible to define a name for each subnetwork, but we recommend that this
not be specified so that the name defaults to the subnet address, because this is
easier to understand while using the GUI.

When ITITO is used to provision servers, it can assign an IP address to a new
server from the next available within a subnet. In this way, ITITO acts in a similar
way as a DHCP server, although technically, it assigns a permanent address.
For subnets where ITITO is permitted to assign addresses, it will usually be
necessary to block certain addresses. Otherwise, ITITO will assign a duplicate
address. In particular, each subnet will have a gateway address that should be
blocked, and any permanent servers on the subnet should also be blocked. A
number of ranges can be defined if necessary.


Subnet address Blocked range start Blocked range end

Switches
Each network switch device that is used by the applications determined in
Section 2.2 on page 4 should be recorded here:

Table 2-6 Switch data collection skeleton
Switch IP Switch
name address fabric

Switches often have separate modules containing a number of ports. Every port
that connects a device in the ITITO environment must be defined here and will be
used later in the device definitions. It is not necessary to define every port on
every switch, just the ones to be controlled by ITITO.

Table 2-7 Switch port data collection skeleton
Switch name Switch modules Switch port VLAN Port type

The valid types of ports for ITITO Version 1.1 are:
Ethernet
Fast Ethernet
Gigabyte


VLAN
Unknown

It is not essential to define the port types, because this does not affect the
demonstration, although the ports will show up as unknown type in the GUI.

If any switch is connected to any of the power units identified in 2.3.1, “Power
units” on page 8, the attached power unit should be recorded here:

Table 2-8 Switch/power units data collection
Switch name Power unit Power outlet

The following switches are supported by ITITO Version 1.1:

Table 2-9 Switch data collection example

Cisco 6500 Cisco 6500 Switches Hybrid Mode

Cisco 6500 Cisco 6500 Switches Native IOS Mode

Cisco 3548 Cisco 3548


IBM Blade Center Blade Center 4p GB Eth
4port GB

Extreme 48i Extreme 48i

Foundry Foundry Switch Foundry Switch

Others Dummy Switch Dummy Switch

If the customer has other switches than these, it will be necessary to code
custom device drivers during any Proof of Concept or implementation.
Fortunately, for a demonstration, it is only necessary to use the dummy switch
device model for all devices. This allows the switch operations to be simulated
during the demonstration.

Routers and firewalls
Routers are defined as switches in ITITO, but they also require network
interfaces, route definitions, and access control lists.


The basic definition table for a router is as follows:

Table 2-10 Router data collection skeleton
Router Switch Device
Manufacturer Model IP address Firewall
name fabric model

Routers will usually have a number of interfaces that control the routing between
subnets. The data required for these components is as follows:

Table 2-11 Router interface data collection skeleton
Router name Interface name IP address Managed

Each interface can support a number of routes, which need to be specified in the
following table:

Table 2-12 Router interface route data collection skeleton
Router name Interface name Route Gateway ACL

The following router is a valid device in ITITO Version 1.1:

Table 2-13 Router information data collection example


Access control lists
For each router or firewall that controls traffic between subnetworks, an access
control list (ACL) should be defined. These appear on the GUI as a distinctive
icon that connects subnetworks. Each ACL can have multiple rules that are
unidirectional. Usually at least two rules will be defined, permitting traffic in both
directions between a pair of subnets.


Table 2-14 Access Control List data collection skeleton
ACL name Rule # Target Source subnet Destination subnet

The Target column contains the operational mode of the rule: either permit or
deny.

Each rule can specify protocols or port ranges to permit or deny, but for the
purposes of a demonstration, this should not be necessary.

Load balancers
Load balancers require the following information to enable them to be defined to
ITITO:

Table 2-15 Load balancer data collection sample
Name Manufacturer Model Type Device model

The following load balancers are valid devices in ITITO Version 1.1:

Table 2-16 Load balancer data collection example
Manufacturer Model Device model Type

Cisco 11000 Cisco CSS arrowpoint-load-balancer

Alteon LoadBalancer Alteon LoadBalancer

Dummy LB Dummy LB

Each load balancer can have existing virtual IP addresses defined to it. When
ITITO is operational, it will create and delete virtual IPs as it provisions servers
into application clusters on demand.

Load balancers can also be used as switches. In this case, they will need to be
defined as switches in “Switches” on page 10.


Virtual IPs
Any pre-existing virtual IPs can be defined to ITITO if required, although they will
usually take no part in the demonstration. The information required is shown in
the following table:

Table 2-17 Virtual IP data collection skeleton
Virtual IP Load Virtual IP First input Last input Output
name balancer address port in range port in range port

Each application cluster (see 2.3.5, “Applications and customers” on page 16)
that ITITO is to provision automatically will need a unique virtual IP definition for
the cluster.

2.3.3 Software
Software configuration in ITITO is divided into three categories:
Software package
Software patch
Software stack

We address each of these in the following sections.

Software package
Each single piece of software or data that the customer’s applications require to
be provisioned must be defined to ITITO as a software object. This typically
includes operating systems, databases, middleware, applications, data, and so
on.

For each software package that is to be automatically deployed, it is necessary
to collect the following information:

Table 2-18 Software package data collection skeleton
Software name Version Type Package path Install path


There are two valid entries for type:
OPERATING_SYSTEM
SOFTWARE

For the purposes of the demonstration, package and install paths are optional.

Software patches
Software patches are optional for the demonstration. If any patches or service
packs are required by the customer, they need the following basic information for
the demonstration:

Table 2-19 Software patch data collection skeleton
Patch name Type Package path Install path

As with the software packages, package path and install path are optional for a
demonstration.

Software stacks
Software stacks are an ITITO concept to group together a number of software
packages and software patches so that the stack represents all of the software
that must be installed on each type of server when it is provisioned into an
application cluster. Each distinct type of server required by any application
cluster needs a corresponding software stack. In addition, if any spare pool has
to have an initial set of software defined, the software stack should be defined for
this state, too. Typically, this could mean that a base operating system is
installed on servers in a spare pool with no applications.

Software stacks require the following information:

Table 2-20 Software stack data collection skeleton
Software stack name Software product Position

The software stack names must match the software products or patches, or both,
defined in the previous sections. The Position column determines the installation
order.


2.3.4 Spare pools
If the customer has pools of spare servers already available for their applications,
information about the names, connections, and types of these machines needs
to be determined and entered in the following tables. If the customer does not
have any existing pools of machines, for the demonstration, a number of servers
will need to be defined to create a spare pool. The customer should be advised
that this is a fundamental principle behind ITITO.

These pools require the following definitions:

Table 2-21 Spare pool network data collection skeleton
Spare pool name VLAN Switch fabric

Any number of servers can be defined for each pool with the following attributes:

Table 2-22 Spare pool data collection skeleton

switch module
interface card

Connected to

Connected to
Server name

switch port
Spare pool

Connected

IP address

MAC addr.
Managed
to switch
Network
name

For ITITO to operate correctly with pooled servers, we strongly advise that each
server has at least two network interface cards (NICs), one of which is dedicated
to the management LAN. If any NIC has multiple IP addresses, these should be
recorded here, too.

MAC addresses are optional for the demonstration, but will show up as unknown
in the GUI if not specified.

2.3.5 Applications and customers
In this section, it is necessary to gather information about the various
applications that a customer wants to provision with ITITO. The basic data


required is shown in the following table. For a demonstration, at least two
applications should be defined.

Table 2-23 Customer/application data collection skeleton
Customer name or
Application Priority Application cluster
business unit

Each ITITO implementation can have many customers defined, each of which
can have multiple applications, each of which can have multiple application
clusters. An application cluster is defined to be a set of servers that provide the
same service to an application. The servers are expected to be virtual clones of
each other. The priority of each application should be set according to the
following table:

Table 2-24 Application priority data collection example
Service plan Priority Interpretation

Platinum Better priority service

Gold Medium priority service

Silver 10 Poorer priority service

Each application cluster requires the following additional definitions:

Table 2-25 Cluster information data collection skeleton
Application

Virtual IP

Managed
balancer
servers

servers
cluster

Switch
fabric
VLAN

Load
Max.

Pool
Min.


In this table, Pool is the server pool from which the application cluster provisions
and returns servers (resource pool). Each application cluster can be managed or
unmanaged. This value should be set to true or false. If the cluster is
unmanaged, ITITO will make no attempt to provision servers for this cluster.
Typically, this option is used for clusters that provide database facilities. It is
usually desirable to show these clusters in the ITITO GUI, but not to actually
make changes to them automatically. The Load Balancer column is used to
identify the load balancer that is associated with the cluster’s servers. The Virtual
IP column refers to the virtual IPs defined in “Virtual IPs” on page 14.

Note: It is also possible to configure the service level agreement properties:
maximum response time and maximum time available. We recommend that
you talk about this during the demonstration.

If any cluster has any dedicated servers assigned to it (and usually there will be
at least one), these must also be defined. The data required for these is shown in
the following table:

Table 2-26 Cluster network data collection skeleton
Application

Connected

Connected

Connected

IP address
Managed

to switch

to switch

to switch
interface
Network

address
module
cluster

Server
name

MAC
card

port

For servers that are permanently assigned to a cluster, the network interface
cards should usually not be managed by ITITO. As with pool servers, the MAC
addresses are optional, but will show up as unknown in the GUI if not specified.


2.3.6 Other devices
ITITO supports a number of other data center management devices including:
Boot servers
Terminal servers
Blade center management servers

These devices might be essential for the operation of a data center, but do not
really play any part in a demonstration of ITITO. If it is desirable to show the
configuration and that the product supports these devices, they should be
included.

Boot servers
If any servers are to be provisioned by bare-metal builds, it will be necessary to
define a boot server for each set of servers that are configured to use the same
boot server. Boot servers require the following information to be defined:

Table 2-27 Boot server data collection skeleton
Name Manufacturer Software IP address Device model

Each boot server can also have a network interface card and network interfaces
as with other servers in spare pools and clusters:

Table 2-28 Boot server network information collection skeleton
Connected

Connected

Connected

IP address

MAC addr.
Managed
to switch

to switch

to switch
interface
Network

module
server
name
Boot

card

port

The following boot servers are valid devices in ITITO Version 1.1:

Table 2-29 Boot servers supported by ITITO V1.1
Manufacturer Software Device model

Rembo Auto-Deploy Rembo Boot Server

IBM Remote Deployment Manager RDM Server


IBM Network Installation Manager NIM Server

IBM zVM Boot Server zVM Boot Server

IBM Cluster Systems Management CSM Management Server

Sun Jump Start JumpStart Server

HP Rapid Deployment Pack RDP Server

If a boot server is used to deploy an operating system, this attribute can be
added to the corresponding software stack for the operating system. This is
optional for the demonstration.

Table 2-30 Boot server/operating system data collection skeleton
Software stack name Boot server

Terminal servers
Terminal servers can be defined to ITITO like boot servers except that there are
no supplied device drivers for terminal servers in Version 1.1 of the product:

Table 2-31 Terminal server data collection skeleton
Name IP address

Network interface cards and network interfaces can be defined as with other
servers:

Table 2-32 Terminal server network information data collection skeleton
Connected

Connected

Connected

IP address

MAC addr.
Managed
to switch

to switch

to switch
interface
Terminal

Network

module
server
name

card

port


Blade center management servers
Each blade system is managed by a central management server that controls all
aspects of the blade servers. ITITO uses the blade center management server to
perform operations on the blade servers such as reboot, power on, and
reconfiguration. If the customer uses blade servers, it might be desirable to show
the blade center management server, although the demonstration will make no
visible changes to the blade center management server itself. The blade center
management server can be defined like the boot server and terminal servers:

Table 2-33 Blade center management server data collection skeleton
Name Manufacturer Software IP address Device model

The following blade systems have device drivers in Version 1.1 of ITITO:

Table 2-34 Blade center management servers supported by ITITO V1.1
Manufacturer Blade system Device model

RLX Technologies ServerBlades RLX Blade Server

HP Proliant Blade Servers Proliant BL Server

Network interface cards and network interfaces can also be defined if required:

Table 2-35 Blade server network information data collection skeleton
Connected

Connected

Connected

IP address

MAC addr.
to Switch

Managed
to switch

to switch
interface
Network

module
server
Blade

name

card

port

Servers in spare pools or in clusters can be associated with the relevant blade
center management server. This information can be appended to servers in the
relevant spare pools and clusters:


Table 2-36 Blade servers data collection skeleton
Server name Blade admin server Blade slot

2.3.7 Scoping
This section discusses the process of settling the scope of the demonstration.
This should be agreed with the customer prior to beginning work on the
development of the demonstration system.

The main objective of a customized demonstration is to show the customer what
ITITO can do for them in their environment. It will not usually be necessary to
show the full extent of their environment, and indeed, could be
counter-productive if attempted. From the data gathered, a representative
sample of components should be chosen to be used in the demonstration. For
example, if a customer has an application that has 100 servers working as a
cluster, it is only really necessary to show a few.

Also, if a customer has platforms that are not ideal for ITITO such as Tandems or
z/OS®, it would be better to focus on the ones that are.

Ultimately, if two applications can be agreed on with one, two, or three clusters in
each and one to five servers for each cluster, the demonstration should be
feasible, representative, and worthwhile.

Provided with this document and included in the text is an XML file that contains
the following:
One customer
Two applications
Two clusters in each application
One dedicated server in each cluster
One common resource pool
One switch
One router
One load balancer
Three software stacks
Six software packages

This should be sufficient to demonstrate the key features of ITITO and could
perhaps be used simply by changing the names of the applications clusters and
pools to the customers’ own names.


The files provided with this document are described in 4.3, “Sample XML files” on
page 91.


3

Chapter 3. Installing the demonstration
systems
This chapter describes the installation procedures to get IBM Tivoli Intelligent
ThinkDynamic Orchestrator installed for our pre-POC demonstration scenario.
Our installation consists of two servers, one hosting an IBM DB2 database server
and LDAP Directory, and the second being the IBM Tivoli Intelligent
ThinkDynamic Orchestrator server. This is considered a typical two server
scenario.

In the case of a two server installation, as described in this chapter, both servers
must be running the same operating system. In this chapter, we provide
instructions for installing IBM Tivoli Intelligent ThinkDynamic Orchestrator on
Microsoft Windows 2000 Server.

The instructions given in this chapter are very detailed and explicit. These
instructions are not the only way to install IBM Tivoli Intelligent ThinkDynamic
Orchestrator and its related prerequisites, and are meant to be followed to
successfully install and set up a IBM Tivoli Intelligent ThinkDynamic Orchestrator
environment.


3.1 Installation process overview
Our installation scenario is to be considered as an example only. The following
are the names of both servers used during the installation process. These names
most likely should be changed to the naming standards of the customer.
The server hosting both the IBM DB2 Server and the IBM Directory server will
be named TIOdbsrv.
The server hosting the IBM Tivoli Intelligent ThinkDynamic Orchestrator
server will be named TIOsrv.

The following table provides the recommended hardware for each server. This is
the hardware we used in the ITSO lab environment and we recommend it as a
minimum configuration.

Note: The values provided in the following table may differ form the
information provided in the IBM Tivoli Intelligent Orchestrator and Tivoli
Provisioning Manager Release Notes, SC32-1422. They represent the
hardware used at the time of writing this Redpaper and serve as our
recommendation for a minimum of a two server configuration.

Table 3-1 Recommended hardware for Windows 2000 Server
IBM Compatible Server:

2.4 GHz Intel Pentium® processor or equivalent

2GB RAM

30 GB disk

The following table provides a list of the various products that will need to be
installed and configured on each server during the installation procedure per
operating system. Please note that both servers must be running the same
operating system.

Table 3-2 Required software - Windows 2000
TIOdbsrv TIOsrv

Windows 2000 Server Windows 2000 Server

Cygwin Version 1.3.22 – or later Cygwin Version 1.3.22 – or later

IBM DB2 Universal Database™ IBM DB2 Universal Database V8.1.2 Client
Workgroup Unlimited Edition V8.1.2

IBM Directory Server, V5.1 IBM Directory Server V5.1 Client


TIOdbsrv TIOsrv

IBM WebSphere Application Server Base
Edition V5.0.1

IBM WebSphere Application Server Base
Edition V5.0.1 Client

IBM Tivoli Intelligent ThinkDynamic
Orchestrator V1.1.0

The following picture provides an overview of the entire installation process and
can be used as reference during the installation.

Phase 1 Define the User IDs
Define user tioadmin user ID with Administrator / root authority on both servers
Define user tioldap user ID with Administrator / root authority on both servers
UNIX only: define the mqm user ID in the mqm group. Also create mqbrkrs group TIO TIO
and ensure that tioadmin, root and mqm users IDs belongs to it.
Database Server
Server

Phase 2 Prepare SSH communications
Install all the prerequisite packages for SSH communication between Servers (CygWin for
SSH
Windows, openssh for AIX) on both Servers
Configure SSH and generate a RSA key on the TIO Server TIO
Configure SSH on the TIO database Server Server
Copy the RSA key to the TIO database Server TIO
Test SSH communication from the TIO Server to the TIO database Server Database
Repeat the process for all servers in the Data Center to be managed by IBM Tivoli Intelligent Server

Phase 3 Prepare the TIO database Server
Data source
LDAP DB
Install the remaining prerequisite packages
Install IBM DB2 Universal Database Workgroup Unlimited Edition V8.1.2
Create the database to be used by IBM Tivoli Intelligent ThinkDynamic Orchestrator
Populate the database using the provided tablesapce.sql file Central Data
TIO Warehouse
TIO DB
Install IBM Directory Server, V5.1 Database
Create the LDAP database and configure IBM Directory Server, V5.1 with the provided suffixes Server
and ldap.ldif file
Verify the installation

Phase 4 Prepare the TIO Server
Data source
LDAP DB
Install the remaining prerequisite packages
Install IBM DB2 Universal Database V8.12 Client
Install IBM Directory Server V5.1 Client TIO
Install IBM Websphere Application Server Base Edition V5.0 Server
Central Data
Install IBM Websphere Application Server Base Edition V5.0 Fixpack 1 Warehouse
TIO DB
TIO
Apply the MQ CSD03 patch to IBM Websphere Database
Apply the MQ fixes for embedded messaging to IBM WebSphere (IY43610 and IY44803) Server
Install IBM Websphere Application Server Base Edition V5.0 Client
Install IBM Tivoli Intelligent ThinkDynamic Orchestrator V1.1.0
Verify the installation

Figure 3-1 ITITO installation overview

Chapter 3. Installing the demonstration systems 27

3.1.1 Recommended installation directories
The following table provides a list of recommended installation directories for
each product used during the installation process. Note that file paths containing
spaces must not be used, as it will cause problems during the installation and
configuration process.

Table 3-3 Recommended installation directories
Product Installation Directory

Cygwin Version 1.3.22 c:cygwin

IBM DB2 Universal Database Workgroup c:IBMsqllib
Unlimited Edition V8.1.2

IBM Directory Server, V5.1 c:IBMldap

IBM DB2 Universal Database V8.12 Client c:IBMsqllib

IBM Directory Server V5.1 Client c:IBMldap

IBM WebSphere Application Server Base c:IBMWebSphereAppServer
Edition V5.0.1

IBM WebSphere Application Server Base c:IBMWebSphereAppClient
Edition V5.0.1 Client

IBM Tivoli Intelligent ThinkDynamic c:cygwinhomethinkcontrol
Orchestrator V1.1.0

3.1.2 User IDs and passwords
The following table illustrates the user IDs that will be either created during the
application install process or created by you, the implementer, before the actual
install process begins.

Table 3-4 User IDs and passwords
User name Password Description Comment

tioadmin <user defined> Used to log onto the OS This user ID must be
to install IBM Tivoli created manually on
Intelligent both servers prior to
ThinkDynamic the installation
Orchestrator


User name Password Description Comment

tioldap <user defined> Used by IBM Tivoli This user ID must be
Intelligent created manually on
ThinkDynamic the machine hosting
Orchestrator to connect the IBM Directory
to the Directory Server Server prior to the
installation

tiodb <user defined> This user ID will be the Created during the
instance owner of the IBM DB2 installation
IBM Tivoli Intelligent on the server hosting
ThinkDynamic the IBM Tivoli
Orchestrator database Intelligent
ThinkDynamic
Orchestrator
database

mqm <user defined> Used by WebSphere This user ID must be
MQ created manually on
both servers prior to
the installation

wasadmin wasadmin Used by WebSphere as Defined
administration account automatically by the
WebSphere
installation process

tioappadmin tioappadmin This is the IBM Tivoli Defined on the
Intelligent Directory Server
ThinkDynamic automatically by the
Orchestrator IBM Tivoli Intelligent
superadmin and is used ThinkDynamic
to log into the Web Orchestrator
console installation process

tiointernal internal Used by IBM Tivoli Defined on the
Intelligent Directory Server
ThinkDynamic automatically by the
Orchestrator for system IBM Tivoli Intelligent
initiated actions ThinkDynamic
Orchestrator

cn=root <user defined> root user ID for the IBM Created during the
Directory LDAP Server IBM Directory


3.2 Installing and configuring TIOdbsrv - Windows
In this section we describe the steps to setup the machine hosting database and
the LDAP directory used by the IBM Tivoli Intelligent ThinkDynamic Orchestrator
on Microsoft Windows 2000 Server. The high level install steps are presented in
the following figure.

Create tioadmin user
id

Create tioldap user id

Download and install
Cygwin

Install and configure
DB2

Install and configure
IBM Directory Server
Figure 3-2 TIOdbsrv installation steps

The following sections explain each step of the above flow in detail.

3.2.1 Creating the required user IDs
Create a local user accounts tioadmin and tioldap as follows:
1. Under Computer Management choose System Tools -> Local users and
groups -> Users and add the users tioadmin and tioldap.
2. Select the newly created users and make both of them members of the
Administrators group.
3. Select the user ID tioadmin and set its Local Path to:
C:Cygwinhomethinkcontrol
4. Select the user ID tioldap and set its Local Path to:
C:IBMldap


3.2.2 Installing and configuring Cygwin
Cygwin is used as an Open SSH environment for the IBM Tivoli Intelligent
ThinkDynamic Orchestrator application to communicate with all other
applications through the use of Cygwin’s BASH Shell and can be obtained at the
following URL:
http://www.cygwin.com/

Ensure you are logged on to the TIOdbsrv machine using the tioadmin user
account specified above.

Attention: Cygwin Version 1.3.22 or higher must be installed. At the time of
writing this Redpaper, Cygwin Version 1.5.5-1 was the current version
available for downloading and it was used during our install process.

Important: Before you download Cygwin ensure you are logged on using the
tioadmin user account specified above and that the tioadmin user has the
correct profile properties and is a member of Administrators.

1. Open a browser and go the Cygwin home page: http://www.cygwin.com
Select the Install or Update now! option.
2. Choose to open the setup.exe application from its current location
3. The Cygwin Setup window starts the installation wizard, select Next
4. Select Install from Internet
5. Accept default installation directory (C:Cygwin), All Users and DOS options
6. Accept default Package directory
7. Choose the appropriate internet settings. We selected Direct Connection.
8. Select a FTP site from the available list
9. During the Cygwin installation, on the Select Package panel, it is important to
select the correct Categories. The installation wizard provides a series of
pre-selected packages as default for installation. However, IBM Tivoli
Intelligent ThinkDynamic Orchestrator requires additional packages under the
Lib and Net categories. The following table describes the required packages
that need to be installed in addition the default selection. To select those
packages, click the + sign of the Libs and Net categories, and click the Skip
button next to the desired package to change the installation option from Skip
to Install.


Tip: We recommend selecting and installing all of the Cygwin packages.

Additional Cygwin packages

Cygwin Package Action

Libs Accept default packages PLUS Regex

Net Accept default packages PLUS OpenSSH and OpenSSL

10.When the installation completes, select to create icon on desktop. Select
Finish.

3.2.3 Configuring SSH communications
When the Cygwin installation completes click on the Cygwin icon to open a bash
shell window and perform the following steps to configure SSH:

Important: Verify that all servers in your configuration are setup correctly in
either DNS and or /etc/hosts.

1. Move to the /usr/bin directory and issue the host configuration ssh-host-config
command, as shown in the following example. When prompted for
environment variables, press Enter to accept the defaults.
$ cd /usr/bin
$ ./ssh-host-config -y
Generating /etc/ssh_host_key
Generating /etc/ssh_host_rsa_key
Generating /etc/ssh_host_dsa_key
Generating /etc/ssh_config file
Privilege separation is set to yes by default since OpenSSH 3.3.
However, this requires a non-privileged account called 'sshd'.
For more info on privilege separation read
/usr/doc/openssh/README.privsep.
Warning: The following function requires administrator privileges!
Generating /etc/sshd_config file
Added ssh to /cygdrive/c/WINNT/system32/drivers/etc/services
Added ssh to /etc/inetd.conf
Do you want to install sshd as service?
Which value should the environment variable CYGWIN have when
sshd starts? It's recommended to set at least "ntsec" to be
able to change user context without password.
Default is "binmode ntsec tty". CYGWIN=
The service has been installed under LocalSystem account.


Host configuration finished. Have fun!
2. Export the CYGWIN variable.
$ export CYGWIN=ntsec

Tip: This command will set an environment variable for products to reference
as a global variable.

3. Move to the /var directory and change the attributes of the directory named
empty.
$ cd /var
$ chmod 700 empty
4. Start the SSH service as follows:
$ cygrunsrv -S sshd
5. Move to the home directory of the tioadmin user ID and issue the ssh-keygen
command to generate the RSA key. You should have an output similar to the
following example.
$ cd
$ pwd
/home/thinkcontrol
$ ssh-keygen -t rsa -N ""
Generating public/private rsa key pair.
Enter file in which to save the key (/home/thinkcontrol/.ssh/id_rsa):
Created directory '/home/thinkcontrol/.ssh'.
Your identification has been saved in /home/thinkcontrol/.ssh/id_rsa.
Your public key has been saved in /home/thinkcontrol/.ssh/id_rsa.pub.
The key fingerprint is:
fd:ca:21:d3:3f:db:fd:d9:56:b2:30:68:16:43:1c:11 tioadmin@tio12
6. Move to the .ssh directory and create the authorized_keys file:
$ pwd
/home/thinkcontrol
$ cd .ssh
$ cat id_rsa.pub > authorized_keys
7. To configure SSH to accept connections from new hosts without prompting for
confirmation, create a file in the /home/thinkcontrol/.ssh directory called
config. Edit the config file and add the line StrictHostKeyChecking no as
follows:
# cd /home/thinkcontrol/.ssh
# touch config
# vi config
Add in the following line:
StrictHostKeyChecking no


Type the config file. The output should read as follows:
8. To verify that SSH is configured properly, try to access your own machine
using the ssh command as shown in the following example.
$ ssh tioadmin@localhost
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
Fanfare!!!
You are successfully logged in to this server!!!
$ exit
logout
Connection to localhost closed.

3.2.4 Installing and configuring IBM DB2 UDB V8.1.2 on Windows
This section describes the installation and configuration of IBM DB2 Universal
Database, Workgroup Unlimited Edition V8.1.2 on Windows. It also shows the
required configuration steps required by IBM Tivoli Intelligent ThinkDynamic
Orchestrator.

Note: Ensure you perform the IBM DB2 installation logged on as tioadmin.

Use the DB2 installation media provided with the IBM Tivoli Intelligent
ThinkDynamic Orchestrator product. This ensures that you get the correct
version and level of DB2 installed.
1. Logged on as tioadmin, move to the drive where the IBM DB2 CD is mounted
and run the setup.exe command to start the installation. From the installation
window, select Install Product.
2. Select the product we want to install: IBM DB2 Workgroup Server Unlimited
Edition and click Next.
3. The Welcome to the DB2 Setup wizard window opens. Click Next.
4. Accept the License Agreement by selecting I accept the terms in the
license agreement option.
5. The Select the installation type window opens. Select the Custom Install
option.
6. Select Install DB2 Workgroup Server Unlimited Edition on this computer.
7. The Select features window opens, as shown in the next figure. Select the
following packages:
– Client support
– Administration tools
– Server support


Also select the installation path. Ensure there are no spaces in the installation
path. We used C:IBMSQLLIB.

Figure 3-3 Select DB2 Server components

8. Choose Language of choice - English is default.
9. The Set user information for DB2 Administration Server window open, as
shown in next figure. Here you have to specify the user ID tiodb as it will be
the instance owner of the IBM Tivoli Intelligent ThinkDynamic Orchestrator
database. The user ID tiodb will be created with the proper authority by the
DB2 installation process. Make sure you record the password as you will be
prompted for this password during the IBM Tivoli Intelligent ThinkDynamic
Orchestrator installation.


Figure 3-4 Set the DB2 administrator user to tiodb

10.The Set up administration contact list window opens. Select Local - Create a
contact list on this system.
11.Click Next at the Configure DB2 instances window.
12.At the Prepare the DB2 tools catalog choose Prepare the DB2 tools catalog
in a local database.
13.Accept the default values at the Specify a local database to store the DB2
tools catalog window.
14.At the Specify a contact for health monitor notification choose Defer the task
until after installation is complete.
15.At the Request satellite information screen choose Defer this task until after
installation is complete.
16.At the Start copying files window you have the chance to review the
installation options. Click on Install to initiate the installation.
17.Then the installation completes, open a DB2 command window: Start -> IBM
DB2 -> Command Line Tools -> Command Window.
18.Issue the db2licm command to add the license provided by IBM Tivoli
Intelligent ThinkDynamic Orchestrator:


C:IBMSQLLIBBIN>d: <-- This is the CDROM drive
D:>cd db2license
D:>db2licm -a ./db2wsue.lic
DBI1402I License added successfully.
DBI1426I This product is now licensed for use as specified in the
License Acceptance and License Information documents pertaining to the
licensed copy of this product. USE OF THE PRODUCT CONSTITUTES
ACCEPTANCE OF THE TERMS OF THE IBM LICENSE ACCEPTANCE AND LICENSE
INFORMATION DOCUMENTS, LOCATED IN THE FOLLOWING DIRECTORY:
"C:IBMSQLLIBlicenseen"
19.Reboot the system

Create database and database schema
After installing IBM DB2 perform the following steps to create the database and
the database schema used by IBM Tivoli Intelligent ThinkDynamic Orchestrator.

Important: You must logon to your system using the tiodb user ID to be
successful with the DB2 configuration.

1. Logon to the system as the tiodb user ID.
2. Open a DB2 command window.
3. Create the database for IBM Tivoli Intelligent ThinkDynamic Orchestrator by
entering the following command:
db2 create database <db_name>
Where, <db_name> is the name of the database you want to create.
Make sure the database name follow the DB2 naming conventions and that
you record it as you will require it when installing IBM Tivoli Intelligent
ThinkDynamic Orchestrator.
You can confirm the creation of the database by issuing the following
command:
db2 list database directory
C:IBMSQLLIBBIN>db2 create database ITITODB
DB20000I The CREATE DATABASE command completed successfully.
C:IBMSQLLIBBIN>db2 list database directory
System Database Directory
Number of entries in the directory = 2
Database 1 entry:
Database alias = ITITODB
Database name = ITITODB
Database drive = C:DB2
Database release level = a.00
Comment =


Directory entry type = Indirect
Catalog database partition number = 0
Database 2 entry:
Database alias = TOOLSDB
Database name = TOOLSDB
Database drive = C:DB2
Database release level = a.00
Comment =
Directory entry type = Indirect
Catalog database partition number = 0
C:IBMSQLLIBBIN>
4. Copy the tablespace.sql script located in the /samples directory on the IBM
Tivoli Intelligent ThinkDynamic Orchestrator CD to your IBM DB2 installation
directory (in our case C:IBMSQLLIBBIN).
5. Create the tablespace for the database by performing the following steps:
db2 connect to <db_name> user tiodb using <tiodb_pwd>
Where, <db_name> is the name of the database you created in the previous
step, and <tiodb_pwd> is the password for user ID tiodb.
Then run the following command:
db2 -tvf tablespace.sql
C:IBMSQLLIBBIN>db2 connect to ITITODB user tiodb
Enter current password for tiodb:
Database Connection Information
Database server = DB2/NT 8.1.2
SQL authorization ID = TIODB
Local database alias = ITITODB
C:IBMSQLLIBBIN>db2 -tvf tablespace.sql
CREATE BUFFERPOOL IBM16K SIZE 250 PAGESIZE 16K NOT EXTENDED STORAGE
DB20000I The SQL command completed successfully.
CREATE BUFFERPOOL IBM8K SIZE 250 PAGESIZE 8K NOT EXTENDED STORAGE
CREATE REGULAR TABLESPACE IBM8KSPACE PAGESIZE 8K MANAGED BY SYSTEM USING
('IBM8KSPACE') BUFFERPOOL IBM8K DROPPED TABLE RECOVERY OFF
CREATE REGULAR TABLESPACE IBM16KSPACE PAGESIZE 16K MANAGED BY SYSTEM
USING ('IBM16KSPACE') BUFFERPOOL IBM16K DROPPED TABLE RECOVERY OFF
CREATE TEMPORARY TABLESPACE IBM8KTEMPSPACE PAGESIZE 8K MANAGED BY SYSTEM
USING ('IBM8KTEMPSPACE') BUFFERPOOL IBM8K DROPPED TABLE RECOVERY OFF
CREATE TEMPORARY TABLESPACE IBM16KTEMPSPACE PAGESIZE 16K MANAGED BY
SYSTEM USING ('IBM16KTEMPSPACE') BUFFERPOOL IBM16K DROPPED TABLE
RECOVERY OFF
C:IBMSQLLIBBIN>


3.2.5 Installing and configuring IBM Directory Server V5.1
In this section we show the installation and configuration steps of IBM Directory
Server, V5.1. In a IBM Tivoli Intelligent ThinkDynamic Orchestrator environment
the IBM Directory Server can be installed on any system using any supported
operating system. In our case study scenario, we decided to install IBM Directory
Server on the same machine as the IBM DB2 server. In any case, an LDAP client
must be installed on the IBM Tivoli Intelligent ThinkDynamic Orchestrator
machine to allow it to communicate with the IBM Directory server.

To install and configure IBM Directory Server 5.1, perform the following steps:
1. Log on to the system as tioadmin.
2. Ensure that the user ID tioldap has been created using the guidelines
presented in 3.1.2 User IDs and passwords on page 30.

Important: This implementation of LDAP can be in a shared environment but
it will still need to have a dedicated LDAP ID (tioldap) created to service the
IBM Tivoli Intelligent ThinkDynamic Orchestrator application.

3. Insert the IBM Directory Server, 5.1 CD in the drive and start the setup.exe
located in the ids_ismp folder to start the installation.
4. Select Language of choice for the installation process. English is set to
default.
5. The installation wizard starts the installation process click Next.
7. Because this installation process occurs in the IBM DB2 server machine, the
install should detect that IBM DB2 is already installed.
8. Select the installation path. Ensure there are no spaces in the installation
path. We used C:IBMLDAP.
9. Choose a language of choice for the IBM Directory Server. English is set to
default.
10.The Select the installation type window opens. Select the Custom Install
option.
11.The Select features window opens, as shown in next figure. Select the
following packages:
– Client SDK
– Web Administration
– Server
– IBM WebSphere Application Server - Express


– GSKit

Attention: If you are installing IBM Directory Server on a dedicated server,
which is not the IBM DB2 server, ensure the DB2 option is selected. IBM
Directory Server requires that a local database be installed.

Figure 3-5 Select IBM Directory Server components

installation options. Click on Next to initiate the installation.
13.The installation wizard installs all the selected applications and presents the
IBM Directory Server V5.1 Readme files.
14.We recommend that you choose to restart your system at a later time
because there is still one step left to complete the install process. Choose No,
I will restart my system at a later time. Click Next and then Finish.
15.Copy the thinkdynamics.schema file located in the /samples directory on the
IBM Tivoli Intelligent ThinkDynamic Orchestrator CD to your IBM Directory
installation directory (in our case C:IBMLDAP).
16.Reboot the system.


After installing IBM Directory perform the following steps to create the database
and configure the IBM Directory server used by IBM Tivoli Intelligent
ThinkDynamic Orchestrator:

Important: You must logon to your system using the tioadmin user ID in order
to be successful with the IBM Directory configuration.

17.At the system restart, logon as tioadmin.
18.Ensure the thinkdynamics.schema file located in the /samples directory on
the IBM Tivoli Intelligent ThinkDynamic Orchestrator CD has been copied to
the IBM Directory installation directory.
19.The IBM Directory Server Configuration Tool window opens.
The Configuration Tool can also be opened by Click START > Programs >
IBM Directory Server 5.1 > Directory Configuration.
20.Select Administrator DN/password and set the LDAP Administrator to
cn=root and enter a password. Make sure you record the password, as you
will need during the IBM Tivoli Intelligent ThinkDynamic Orchestrator
installation.


Figure 3-6 Configure the LDAP Administrator to IBM Directory Server

21.Select Configure database and follow the prompts to create a new database.
a. When prompted for a user ID to configure the database provide tioldap.
The user tioldap will be the instance owner for the LDAP database used by
IBM Tivoli Intelligent ThinkDynamic Orchestrator.
b. When prompted for the database name, enter the database name of
choice. Make sure the database name follows the IBM DB2 naming
conventions. Record the database name as it will be required during the
IBM Tivoli Intelligent ThinkDynamic Orchestrator installation process. In
our case study scenario use used LDAPDB.
c. Follow the wizard final steps to create the database and accept the default
values. At the end, you will have the chance to review the database
settings before creating the database.
22.Select Manage suffixes and set the Suffix DN to dc=ibm,dc=com.


Figure 3-7 Managing IBM Directory Server suffixes

23.Select Manage Schema files and create the schema for the LDAP database.
Browse to the thinkdynamics.schema file you copied to your IBM Directory
installation director and click Add, to add the file to the Current schema files
list. Click OK.
24.Select Import ldif data and populate the database with the information
provided in the ldap.dif file. Browse to the /samples directory on the IBM Tivoli
Intelligent ThinkDynamic Orchestrator CD and select the ldap.ldif file. Make
sure the Standard import radio button is selected and click Import.
Expect to see an output similar to the following on the Task messages
section:
Plugin of type DATABASE is successfully loaded from
C:IBMLDAPlibback-config.dll.
ldif2db: 37 entries have been successfully added out of 37 attempted.
Close the IBM Directory Server Configuration Tool.


25.Open a command line and start the embedded WebSphere server by running
the following command:
C:IBMldapAppsrvbinstartserver server1
If you have changed the default installation directory, substitute the
appropriate path in the command above.
26.Open the IBM Directory Server Web console by opening a Web browser and
going to the following URL:
http://localhost:9080/IDSWebApp/IDSjsp/Login.jsp
27.Select LDAP Host name to Console Admin, log in using the user ID
superadmin and password secret, then click Login.
28.Expand Console Administration, click on Manage Console Servers, and click
Add to add your IBM Directory server to the list.
29.Enter the host name of the IBM Directory server machine and click OK.

Figure 3-8 Logging in to the IBM Directory Server Web Administration Tool


30.Start the IBM Directory server service by opening DOS command line and
running the following command:
C:IBMldapbinibmslapd
If you changed the default installation directory, substitute the appropriate
path in the command above.
31.Log out of the Web console and log in using the IBM Directory server just
defined using the user ID cn=root and the password you set during the IBM
Directory server configuration.
32.Expand Directory management and select Manage entries. Select
dc=ibm,dc=com and click Expand.
Verify that all the entries from the ldap.dif file are listed.

3.3 Installing and configuring TIOsrv - Windows
In this section we describe the steps to setup the machine hosting the IBM Tivoli
Intelligent ThinkDynamic Orchestrator Server on Microsoft Windows 2000
Server. The high-level install steps are presented in the following figure.

Create tioadmin User ID

Download and install Cygwin

Configure SSH

Install and configure DB2 Client

Install and configure IBM Directory Client

Install and configure IBM WerbSphere Server

Apply IBM WebSphere FixPak 1 and required fixes

Install and configure IBM WerbSphere Client

Install and configure IBM Tivoli Intelligent ThinkDynamic Orchestrator

Figure 3-9 TIOsrv installation steps


The following sections explain each step of the above flow in detail.

3.3.1 Creating the required user IDs
Create a local user account tioadmin as follows:
1. Under Computer Management choose System Tools -> Local users and
groups -> Users and add the user tioadmin.
2. Select the newly created user and make it members of the Administrators
group.
3. Select the user ID tioadmin and set its Local Path to:
C:Cygwinhomethinkcontrol

3.3.2 Installing and configuring Cygwin
Instructions for obtaining, installing and configuring Cygwin are provided in 3.2.2,
“Installing and configuring Cygwin” on page 31. Please follow those instructions
for setting up Cygwin on the IBM Tivoli Intelligent ThinkDynamic Orchestrator
server machine.

3.3.3 Configuring SSH communications
The SSH configuration follows similar guidelines as described in 3.2.3,
“Configuring SSH communications” on page 32, except the fact that there is no
need to generate a new RSA public key. Here we provide the entire SSH
configuration process required to allow the IBM Tivoli Intelligent ThinkDynamic
Orchestrator to communicate with the IBM DB2 server via SSH.

When the Cygwin installation completes click on the Cygwin icon to open a bash
shell window and perform the following steps to configure SSH:

Important: Verify that all servers in your configuration are setup correctly in
either DNS and or /etc/hosts

1. Move to the /usr/bin directory and issue the host configuration program
ssh-host-config as shown in the following example. When prompted for
environment variables, press Enter to accept the defaults.


$ cd /usr/bin
$ ./ssh-host-config -y
Generating /etc/ssh_host_key
Generating /etc/ssh_host_rsa_key
Generating /etc/ssh_host_dsa_key
Generating /etc/ssh_config file
Privilege separation is set to yes by default since OpenSSH 3.3.
However, this requires a non-privileged account called 'sshd'.
For more info on privilege separation read
/usr/doc/openssh/README.privsep.
Warning: The following function requires administrator privileges!
Generating /etc/sshd_config file
Added ssh to /cygdrive/c/WINNT/system32/drivers/etc/services
Added ssh to /etc/inetd.conf
Do you want to install sshd as service?
Which value should the environment variable CYGWIN have when
sshd starts? It's recommended to set at least "ntsec" to be
able to change user context without password.
Default is "binmode ntsec tty". CYGWIN=
The service has been installed under LocalSystem account.
Host configuration finished. Have fun!
2. Export the CYGWIN variable.
$ export CYGWIN=ntsec

Tip: This command will set an environment variable for products to
reference as a global variable.

3. Move to the /var directory and change the attributes of the directory named
empty.
$ cd /var
$ chmod 700 empty
4. Start the SSH service as follows:
$ cygrunsrv -S sshd
5. Move to the home directory of the tioadmin user ID and create the .ssh
directory.
$ cd
$ pwd
/home/thinkcontrol
$ mkdir .ssh
6. Copy the key files from the IBM DB2 server machine (TIOdbsrv) to
c:cygwinhomethinkcontrol.ssh directory on the IBM Tivoli Intelligent
ThinkDynamic Orchestrator server machine (TIOsrv). The keys are located in
the c:cygwinhomethinkcontrol.ssh directory and are the following:


id_rsa
id_rsa.pub
authorized_keys

Note: You will need to configure SSH communications and copy the key files
on all other servers in your environment that are running Cygwin and need to
communicate with the IBM Tivoli Intelligent ThinkDynamic Orchestrator
server.

7. To configure SSH to accept connections from new hosts without prompting for
confirmation, create a file in the /home/thinkcontrol/.ssh directory called
config. Edit the config file and add the line StrictHostKeyChecking no as
follows:
# cd /home/thinkcontrol/.ssh
# touch config
# vi config
Add in the following line:
List the config file. The output should read as follows:
8. To verify that SSH is configured properly, try to access the ITITO database
server machine using the ssh command as shown in the following example.
$ ssh tioadmin@tio12
Warning: Permanently added 'tio12,9.3.187.163' (RSA) to the list of
known hosts.
Fanfare!!!
You are successfully logged in to this server!!!
$ exit
logout
Connection to tio12 closed.

3.3.4 Installing IBM DB2 Universal Database V8.1.2 Client
This section provides instructions to install the IBM DB2 Universal Database
V8.12 Client.

Note: Ensure you perform the IBM DB2 installation logged on as tioadmin.

Use the DB2 installation media provided with the IBM Tivoli Intelligent
ThinkDynamic Orchestrator product. This ensures that you get the correct
version and level of DB2 installed.


1. Logged on as tioadmin, move to the directory where IBM DB2 and run the
setup.exe command to start the installation. From the installation window,
select Install Products.
2. Select the product we want to install: DB2 Administration Client.
3. The Welcome to the DB2 Setup wizard windows opens. Click Next.
option.
6. Select Install DB2 Administration Client on this computer.
7. The Select features window opens, as shown below. Select the following
package:
– Client support
Also select the installation path. Ensure there are no spaces in the installation
path. We used C:IBMSQLLIB.

Figure 3-10 DB2 Client install options

8. Choose Language of choice - English is default.


9. At the Configure NetBios screen, click Next.
installation options. Click on Install to initiate the installation.
11.When the installation completes, open a DB2 command window: Start -> IBM
DB2 -> Command Line Tools -> Command Window.
12.Run the following commands from the DB2 command line processor to
catalog and connect to the IBM Tivoli Intelligent ThinkDynamic Orchestrator
database on the IBM DB2 server:
db2 catalog tcpip node <db_node> remote <dbserver_hostname> server 50000
db2 catalog db <db_name> as <db_name> at node <db_node>
Where, the variables are defined as follows:
db_node A local, user-defined alias for the node to be
cataloged. This is an arbitrary name used to identify
the node. It should be a meaningful name to make it
easier to remember.
dbserver_hostname The hostname of the IBM DB2 server.
db_name Specifies the name of the database to catalog. This is
the name of the database created for the IBM Tivoli
Intelligent ThinkDynamic Orchestrator server.
13.You can test the catalog by issuing the following commands:
db2 connect to <db_name> user tiodb
C:IBMSQLLIBBIN>db2 catalog tcpip node tio11 remote tio12 server 50000
DB20000I The CATALOG TCPIP NODE command completed successfully.
DB21056W Directory changes may not be effective until the directory
cache is refreshed.
C:IBMSQLLIBBIN>db2 catalog db ITITODB as ITITODB at node tio11
DB20000I The CATALOG DATABASE command completed successfully.
DB21056W Directory changes may not be effective until the directory
cache is refreshed.
C:IBMSQLLIBBIN>db2 connect to ITITODB user tiodb
Enter current password for tiodb:
Database Connection Information
Database server = DB2/NT 8.1.2
SQL authorization ID = TIODB
Local database alias = ITITODB
C:IBMSQLLIBBIN>

3.3.5 Installing and configuring IBM Directory V5.1 Client
In this section we show the installation and configuration steps of IBM Directory
V5.1 Client on Windows. In our case study scenario the IBM Directory Server is
installed on the same machine as the DB2 server. In any configuration of choice,


an LDAP client must be installed on the IBM Tivoli Intelligent ThinkDynamic
Orchestrator machine to allow it to communicate with the IBM Directory server.

To install and configure IBM Directory Client V5.1, perform the following steps:
2. Ensure that the IBM Directory Server is up and running before continuing.
3. Insert the IBM Directory Server, 5.1 CD in the drive and start the setup.exe
located in the ids_ismp folder to start the installation.
4. Select Language of choice for the installation process. English is set to
default.
5. The installation wizard starts the installation process click Next.
7. Select the installation path. Ensure there are no spaces in the installation
path. We used C:IBMLDAP.
8. Choose a language of choice for the IBM Directory Client. English is set to
default.
option.
10.The Select features window opens, as shown below. Select the following
packages:
– Client SDK


Figure 3-11 LDAP Client install options

installation options. Click on Next to initiate the installation.
12.The installation wizard installs the selected application (Client SDK) and
presents the IBM Directory V5.1 Client Readme file.
13.It is recommended to choose to restart your system at this time. Click Next
and then Finish.
14.Reboot the system.

3.3.6 Installing IBM WebSphere Application Server Base V5.0
In this section we describe the IBM WebSphere Application Server Base Edition
V5.0. Later it will be required to install the IBM WebSphere Fixpack 1 to comply
with the IBM Tivoli Intelligent ThinkDynamic Orchestrator required version of IBM
WebSphere: V5.0.1.

Note: Ensure you perform the IBM WebSphere Application Server installation
logged on as tioadmin.


Use the IBM WebSphere Application Server installation media provided with the
IBM Tivoli Intelligent ThinkDynamic Orchestrator product. This ensures that you
get the correct version and level of IBM WebSphere Application Server installed.

To install IBM WebSphere Application Server Base Edition V5.0, perform the
following steps:
2. Move to the nt directory of the drive the IBM WebSphere Application Server
CD is mounted and issue the following command to start the installation
process:
install.exe
3. Choose a language to be used during the install process.
4. The Welcome to the IBM WebSphere install wizard window opens. Click Next
6. The installation wizard checks the prerequisites. The Select the installation
type window opens. Select Custom Install.
7. The Select features window opens, as shown in the next figure. From the
default selection list, deselect the Application Server Samples option.

Figure 3-12 WebSphere install options


8. The Installation path window opens. Select the installation path for the various
components to be installed.
Here are the installation paths used in our scenario. Make sure there are no
spaces in the installation path.

WebSphere installation directories

Product Installation Directory

IBM WebSphere Application Server Base Edition c:IBMWebSphereAppServer
V5.0.1

IBM Embedded Messaging Server and Client c:IBMWebSphereMQ

IBM HTTP Server c:IBMHTTPServer

9. The install wizard prompts for the node name and hostname of the computer.
Supply the fully qualified DNS name on the Hostname field. In our scenario
we used the following:
Node Name: tio11
Host Name: tio11.itsc.austin.ibm.com
10.Select both IBM WebSphere and IBM HTTP Server to run as a Windows
service. Also, specify the tioadmin user ID and password so that those
services run under tioadmin authority.

Figure 3-13 WebSphere runs as Windows service


Attention: If a dialog appears with message ID INST0056E, click OK and
continue. No further action is required.

installation options. Click Next to initiate the installation.
12.Choose to wether or not to register the product at this time.
13.When the installation completes, the IBM WebSphere First Steps window
opens. Select Exit and then Finish to end the install process.

3.3.7 Install the IBM WebSphere fixpack 1 and required fixes
In this section we provide the installation steps for upgrading IBM WebSphere
Application Server Base Edition with the required fixpack1 and fixes. The
following steps need to be performed:
1. Install IBM WebSphere fixpack 1.
2. Apply the MQ CSD03 fix.
3. Apply the IY43610 fix.
4. Apply the IY44803 fix.
5. Apply the PQ75055 fix.

Install IBM WebSphere fixpack 1
After installing IBM WebSphere Application Server Base Edition V5.0 you must
install the fixpack 1, which is shipped with IBM Tivoli Intelligent ThinkDynamic
Orchestrator.

Note: When installing the fixpack 1, ensure that the IBM WebSphere
Application Server, IBM HTTP and IBM HTTP Administration services are
stopped. The installation will fail if these services are running.

Here we provide the steps for installing the IBM WebSphere fixpack 1.
1. Still logged on as tioadmin, ensure that the IBM WebSphere Application
Server, IBM HTTP and IBM HTTP Administration services are stopped.
2. Start the fixpack install process by opening a DOS prompt window and
moving to the <IBM WebSphere installation directory>bin directory and
initializing the WebSphere command line environment by running the
following script:
cd IBMWebSphereAppServerbin
setupCmdLine.bat


3. Move to the drive where the IBM WebSphere fixpack 1 cd is mounted. Run
the following script:
updateWizard.bat

Tip: Do not run the updateWizard.bat file through the GUI.

4. The Welcome to the Update installation wizard for IBM WebSphere window
opens. Click Next.
5. The update wizard checks the current level of IBM WebSphere installed. Click
Next.
6. The Select the installation type window opens. Select Install fix packs.
7. The update wizard prompts for the location of the fixpack 1.
8. Select the fixpack to be installed (was50_fp1_win).

Figure 3-14 IBM WebSphere Fix Pack 1 installation

9. Select to upgrade the following components:
– IBM HTTP Server
– Embedded Messaging
10.At the Start copying files window you have the chance to review the update
options. Click Next to initiate the update.


When the update wizard completes, the following dialog is displayed.

Figure 3-15 IBM WebSphere Fix Pack 1 installation completed

Apply the MQ CSD03 fix
The MQ CSD03 fix is located in the /patches/csd03 directory in the IBM Tivoli
Intelligent ThinkDynamic Orchestrator CD.

Note: When installing the MQ CSD03 fix, ensure that the IBM WebSphere
Application Server is stopped. The installation will fail if this service is running.

Here we provide the steps for installing the MQ CSD 03 fix.
Server is stopped.
moving to the patchesCsd03 directory of the IBM Tivoli Intelligent
ThinkDynamic Orchestrator CD and running the following program
WINDOWS_CSD03_U200187A.exe
3. Follow the wizard instructions to extract the file for the fix.
4. When the file extraction finishes, click Install to begin the CSD 03 fix
installation.


Figure 3-16 WebSphere MQ CSD 03 install

5. At the end of the installation, verify the version of the WebSphere MQ by
running the mqver command:
C:IBMWebSphereAppServerbin>mqver
Name: WebSphere MQ
Version: 530.3 CSD03
CMVC level: p530-CSD03J
BuildType: IKAP - (Production)

Apply the IY43610 fix
The IY43610 fix is located in the /patches/I_43610 directory in the IBM Tivoli

Note: When installing the IY43610 fix, ensure that the IBM WebSphere
Application Server and the WebSphere Embedded Messaging services are
stopped. The installation will fail if this service is running.

Here we provide the steps for installing the IY43610 fix.
Server and the WebSphere Embedded Messaging services are stopped.
2. Move to the <WebSphere MQ install directory>bin directory. In our case the
installation directory is c:IBMWebSphereMQ. Take a backup copy of the
existing files:
– imqb23vn.dll
– imqc23vn.dll
– imqs23vn.dll
– imqb23in.dll


– imqc23in.dll
– imqs23in.dll
moving to the patchesI_43610 directory of the IBM Tivoli Intelligent
ThinkDynamic Orchestrator CD.
4. Copy the IY43610.windows.zip file to a working directory (c:temp for
example) and unzip the file:
unzip IY43610.windows.zip
5. Copy the files to the <MQ install directory>bin directory replacing the existing
files with these new versions.

Apply the IY44803 fix
The IY44803 fix is located in the /patches/I_44803 directory in the IBM Tivoli

Note: When installing the IY44803 fix, ensure that the IBM WebSphere

Here we provide the steps for installing the IY44803 fix.
2. Move to the <WebSphere MQ install directory> directory. In our case the
installation directory is c:IBMWebSphereMQ.
3. Take a backup copy of following directories under the WebSphere MQ
installation directory:
javabin
javalib
4. Create the following directories:
tools
toolsjava
doc
moving to the patchesI_44803 directory of the IBM Tivoli Intelligent
ThinkDynamic Orchestrator CD.
6. Copy the IY44803.windows.zip file to a working directory (c:temp for
example) and unzip the file:
unzip IY44803.windows.zip


7. Copy the files to the appropriate directory replacing the existing files with
these new versions as follows:
– Copy all the files under bin to C:IBMWebSphereMQjavabin
– Copy all the files under lib to C:IBMWebSphereMQjavalib
– Copy the one file under doc to C:IBMWebSphereMQdoc
– Copy the content under samples to C:IBMWebSphere MQtoolsjava

Apply the PQ75055 fix
The PQ75055 fix is located in the /patches/WAS_PQ75055 directory in the IBM
Tivoli Intelligent ThinkDynamic Orchestrator CD.

Note: When installing the PQ75055 fix, ensure that the IBM WebSphere

Here we provide the steps for installing the PQ75055 fix.
2. Start the fix install process by opening a DOS prompt window and moving to
the <IBM WebSphere installation directory>bin directory and initializing the
WebSphere command line environment by running the following script:
cd IBMWebSphereAppServerbin
setupCmdLine.bat
3. Move to the <WebSphere install directory> directory and create a directory
named update. In our case the installation directory is c:IBMWebSphere.
cd IBMWebSphereAppServer
mkdir update
4. Copy the apar_PQ75055.zip file from the patchesWAS_PQ75055 directory
on the IBM Tivoli Intelligent ThinkDynamic Orchestrator CD to the update
directory.
5. Copy the WindowsUpdateInstaller.zip file from the
patchesWAS_PQ75055UpdateInstallerwin directory on the IBM Tivoli
Intelligent ThinkDynamic Orchestrator CD to the update directory.
6. Unzip the WindowsUpdateInstaller.zip file.
unzip WindowsUpdateInstaller.zip
7. Unzip the apar_PQ75055.zip file.
unzip apar_PQ75055.zip
8. Start the update wizard by running updateWizard.bat from command line:


updateWizard.bat

Tip: Do not run the updateWizard.bat file through the GUI. The Wizard
may open up in the background.

9. Choose a Language of choice for install screens.
10.The Welcome to the Update installation wizard for IBM WebSphere window
opens. Click Next.
11.The update wizard checks the current level of IBM WebSphere installed. Click
Next.
12.The Select the installation type window opens. Select Install fixes.
13.The update wizard prompts for the location of the PQ75055 fix.

Attention: On the fix directory panel, ensure the directory path is:
<WebSphere install directory>updateefixes.. (type in both dots)

Figure 3-17 PQ75055 installation directory

14.Select the fix to be installed (PQ75055).


Figure 3-18 IBM WebSphere PQ75055 installation

15.In the Start copying files window you have the chance to review the update
options. Click Next to initiate the update. The next dialog you will see is the
update wizard completion window shown below:


Figure 3-19 IBM WebSphere PQ75055 fix installation completion

Install and configure WebSphere Application Client V5.0.1
In this section we describe the IBM WebSphere Application Client V5.0.1

Note: Ensure you perform the IBM WebSphere Application Server installation
logged on as tioadmin.

Use the IBM WebSphere Application Client installation media provided with the
IBM Tivoli Intelligent ThinkDynamic Orchestrator product. This ensures that you
get the correct version and level of IBM WebSphere Application Client installed.

To install IBM WebSphere Application Client V5.0, perform the following steps:
2. Move to the nt directory of the drive the IBM WebSphere Application Client
CD is mounted and issue the following command to start the installation
process:
install.exe
3. Choose a language to be used during the install process.
4. The Welcome to the IBM WebSphere install wizard window opens. Click Next


6. The installation wizard checks the prerequisites. The Select the installation
type window opens. Select Custom Install.
7. The Select features window opens, as shown in the next figure. From the
default selection list, deselect the Samples option.

Figure 3-20 WebSphere Client install options

8. The Installation path window opens. Select the installation path for the various
components to be installed. We used c:IBMWebSphereAppClient
Make sure there are no spaces in the installation path.

Attention: The IBM WebSphere Application Client must be installed in the
WebSphere home directory. If you selected a custom installation directory
for WebSphere Application Server, then you must install the Application
Client in the same directory as WebSphere Application Server. For
example, if you installed WebSphere Application Server in
C:IBMWebSphereAppServer, then the WebSphere Application Client
should be installed in C:IBMWebSphereAppclient.

9. The install wizard prompts for the hostname and port number of the
WebSphere Server computer. Supply the fully qualified DNS name on the


Hostname field and accept the default. In our scenario we used the fully
qualified hostname of our IBM Tivoli Intelligent ThinkDynamic Orchestrator
server machine:
tio11.itsc.austin.ibm.com
11.Choose to whether or not to register the product at this time.
12.When the installation completes, select Finish to end the install process.
13.Reboot your system at this point.
14.Log on to the system as tioadmin.

Note: Ensure you perform the following steps logged on as tioadmin.

15.Move to the <WebSphere Client Install Directory>javajrelibsecurity
directory.
16.Edit the java.security file and add the following at the very end of the file
login.configuration.provider=com.ibm.security.auth.login.ConfigFile
login.config.url.1=file:/<WAS_Client_instdir>/properties/wsjaas_client.conf
Where, <WAS_Client_instdir> is the WebSphere Application Client
installation directory.
# Class to instantiate as the javax.security.auth.login.Configuration
provider
login.configuration.provider=com.ibm.security.auth.login.ConfigFile
# Default login configuration file
login.config.url.1=file:/C:/IBM/WebSPhere/AppClient/properties/wsjaas_clien
t.conf

Important: You must use forward slashes in the directory path for the line,
including the WebSphere Application Client installation directory.

17.Move to the <WebSphere Client Install Directory>properties directory.
18.Edit the sas.client.props and locate the line:
com.ibm.CORBA.loginSource=prompt
And change it to:
com.ibm.CORBA.loginSource=none

Change the default transaction log size
Perform the following steps to change the default transaction log size:


1. Start the IBM WebSphere Server service using the Windows Services tool.
2. Start the IBM WebSphere Application Server Administrative Console by
selecting Programs -> IBM WebSphere -> Application Server ->
Administrative Console
3. Provide an User ID to be used for logging purposes only.
4. In the navigation pane, select Server -> Application Servers.
5. Select server1 under the server list. This displays the properties of the
application server, server1, in the content pane.
6. Select the Transaction Service link, to display the properties page for the
transaction service.
7. Under the Configuration Tab, change the value of the Transaction log
directory attribute to the following value:
<WebSphere_install_directory>/tranlog/server1;10M
Where, <WebSphere_install_directory> is the IBM WebSphere Application
Server installation directory. For example, in our scenario we used:
C:IBMWebSphereAppServer/tranlog/server1;10M

Important: You have to use back slashes on the IBM WebSphere
Application Server installation directory and forward slashes on the rest of
the path.


Figure 3-21 Changing the transaction log size

8. Click OK to make the changes effective.
9. Save the changes before exiting the BM WebSphere Application Server
Administrative Console.
10.Stop and Start the IBM WebSphere Server service using the Windows
Services tool.

3.3.8 Installing IBM Tivoli Intelligent ThinkDynamic Orchestrator
This section provides instructions on installing IBM Tivoli Intelligent
ThinkDynamic Orchestrator on the TIOsrv machine running Windows 2000
Server.


Important: Before proceeding with the installation steps, ensure that the
following activities are completed.

The machine hosting the IBM Tivoli Intelligent ThinkDynamic Orchestrator
database and Directory Server have been setup and all prerequisite software
is configured and operational. This has been covered in 3.2, “Installing and
configuring TIOdbsrv - Windows” on page 30.
All the prerequisite software for IBM Tivoli Intelligent ThinkDynamic
Orchestrator are installed, configured and up and running. This has been
covered in this section.
Ensure that SSH communication between the TIOsrv machine and TIOdbsrv
machine is operational.

Note: Ensure you perform the IBM Tivoli Intelligent ThinkDynamic
Orchestrator installation logged on as tioadmin.

To install and configure IBM Tivoli Intelligent ThinkDynamic Orchestrator perform
the following steps:
2. Set the system PATH variable to include the IBM Tivoli Intelligent
ThinkDynamic Orchestrator binary files as follows:
Click Start-> Settings-> Control Panel-> System-> Advanced Tab. Click
the Environment Variables button and add the following line to the System
PATH variable:
C:cygwinhomethinkcontrolbin
If you installed Cygwin in a custom directory, substitute that path.
3. Mount the IBM Tivoli Intelligent ThinkDynamic Orchestrator CD into the CD
drive. Move to the to the /install directory and run the setupwin32.exe
command.
4. The Welcome to the IBM Tivoli Intelligent ThinkDynamic Orchestrator install
wizard window opens. Click Next.


Figure 3-22 IBM Tivoli Intelligent ThinkDynamic Orchestrator welcome window

6. Because IBM Tivoli Intelligent ThinkDynamic Orchestrator leverages the
Cygwin application, the installation wizard prompt for the Cygwin installation
directory.
7. The IBM Directory Server Information window opens. Provide the following
information about LDAP (defined during the IBM Directory Server
configuration):
– LDAP Administrator user ID and password. This is the root user ID.
– Fully qualified hostname of the IBM Directory Server machine
– TCPIP port number used to communicate with the IBM Directory Server.


Figure 3-23 IBM Directory Server information

8. On the IBM WebSphere Configuration panel, specify the DNS suffix name of
the IBM Tivoli Intelligent ThinkDynamic Orchestrator server and the directory
where IBM WebSphere Application Server is installed.


Figure 3-24 IBM WebSphere Application Server information

After you click Next, the installation wizard will verify that it can communicate
with the IBM WebSphere Application Server and that the IBM WebSphere
Application Server is properly configured for IBM Tivoli Intelligent
ThinkDynamic Orchestrator. This may take a few minutes.
9. The IBM DB2 Server Information window opens. Provide the following
information about IBM DB2 (defined during the IBM DB2 Server
configuration).
a. Remote Alias for the IBM Tivoli Intelligent ThinkDynamic Orchestrator
database. In our scenario we defined the alias as the same name as the
database name created in the TIOdbsrv machine: ITITODB.
b. The user ID and password of the IBM Tivoli Intelligent ThinkDynamic
Orchestrator database owner. This is the tiodb user ID.
c. The fully qualified hostname of the IBM DB2 Database Server.
d. TCPIP port number used to communicate with the IBM DB2 Database
Server.
e. The IBM DB2 Client installation directory on the IBM Tivoli Intelligent
ThinkDynamic Orchestrator machine.


Figure 3-25 IBM DB2 Server information

10.At the Installation Preview window you have the chance to review the


Figure 3-26 Installation Preview window

11.As IBM Tivoli Intelligent ThinkDynamic Orchestrator is being installed, a panel
displays showing the progress of the installation. The installation is complete
when the summary panel displays. If you would like to start the IBM Tivoli
Intelligent ThinkDynamic Orchestrator services immediately, click the check
box.


Figure 3-27 Installation Summary window


4

Chapter 4. Creating the demonstration
This section explains how to build the ITITO data center model and contains the
following sections:
A discussion of the tools that can be used to build the data center model
Guidance on converting the gathered data into an XML input file
Sample XML files
Advice about loading the data center model
Advice about configuring the ITITO simulator to provide a sample load for the
demonstration
Some areas to test before demonstrating


4.1 Tools
The ITITO data center model (DCM) can be built in one of two ways:
Defining each component using the Web management GUI
Importing the DCM definitions using one or more XML files

The advantage of the Web management GUI is that it is easy, although a bit
time-consuming, but the main disadvantage is that the data center model cannot
be reused on any other project because there is no export facility in ITITO
Version 1.1.

Conversely, building the DCM using XML files can be quite complex,
time-consuming, and prone to errors. The main advantage of this method is that
it can be re-used, copied, and extended more easily at any time in the future.
Building the DCM is the recommended method, and a number of XML files are
provided as examples.

A number of software packages are available to edit XML. These range from very
simple to very complex and expensive. The selection of tools is largely a matter
of choice and budget. Some advice and guidelines are presented here. The tools
discussed are:
WordPad or Notepad
Cooktop
XMLSpy

We discuss the benefits and disadvantages of each tool separately.

4.1.1 WordPad or Notepad
These editors provide absolutely no assistance with editing XML files. They do
not guide, validate, or display the XML elements in different colors. A significant
degree of familiarity with XML structures is recommended if either of these
editors is chosen. On the plus side, they are always available on every
Windows-based system, and if quick changes are required, they might be all that
is needed.

4.1.2 Cooktop
This is a freeware dedicated XML editor that can be obtained from:
http://www.xmlcooktop.com. Cooktop is a Windows-only editor that has a small
download and footprint and provides the following useful facilities:
It displays the XML file with color-coded text.
It can validate the XML file against the DTD definition file.


It can display the structure of the XML elements graphically.

Cooktop has the following disadvantages:
It does not allow you to change the XML structures graphically.
Some users have reported problems with some of the macros used in Tivoli
Orchestrator.

The following screen capture shows a typical session using the Cooktop XML
editor:

Figure 4-1 Cooktop XML editor

Chapter 4. Creating the demonstration 77

This screen capture below shows the XML structure view from Cooktop:

Figure 4-2 Cooktop XML structure view

4.1.3 XMLSpy
XMLSpy is a licensed product from Altova systems, available at:
http://www.altova.com. XMLSpy is available on a 30-day trial basis and requires
registration with Altova. The tool provides the following features:
It allows the XML files to be created and maintained either graphically or text
based.
It displays XML with color coding.
It validates the XML against the DTD file.
It does not permit invalid items to be inserted.
It is possible to cut and paste structures.
It is possible to shrink elements that are not being worked on, thus making it
easier to see the current items.

XMLSpy does have the following limitations:
Using the graphical editor can be quite daunting at first and requires a fair bit
of practice.
It is expensive.


It does have some bugs!

The following screen capture shows a typical session using the graphical editor
in XMLSpy:

Figure 4-3 XMLSpy XML editor

4.2 Designing the data center model
This section describes the data center modeling process.

4.2.1 ITITO GUI method
If you choose the GUI method, we recommend that you clean up the ITITO
database. It will be necessary to reinitialize the ITITO database with a blank
DCM. This is best achieved by following these steps:
1. Edit the reinit-exec.bat file in c:cygwinhomethinkcontroltools.


2. In the reinit-exec.bat file, comment out the line that contains the following with
a REM statement:
set DCMCFG_FILE=example.xml
3. Open a command prompt.
4. Run the batch file:
toolsreinit.bat
When this completes, the ITITO database will be completely cleared.

The advantages of the GUI are as follows:
It is easy to add components.
The GUI provides lists of relevant components in some pull-down menus.
It is not possible to insert incorrect objects.
It can be quite quick for a small system.

The disadvantages of the GUI are as follows:
It is not currently possible to export the data into an XML format and then
reuse it in another system.
If the ITITO system is reinitialized, all work is lost.
It can be very tedious to add a large number of objects using the GUI.
It can be prone to errors if a lot of similar objects are added.

No specific instructions are provided in this document to guide the reader in
creating a data center model using the GUI. It is assumed that the reader will be
familiar with the ITITO GUI and will understand how to use it to create the data
center components from the data collected. Details can be found in the redbook
Orchestrator, SG24-8888.

4.2.2 The XML method
The ITITO data center model consists of one XML file that contains a number of
different elements and attributes. Each element has a specific set of child
elements or attributes according to the design schema, also known as the DTD
file. For ITITO, the basic data center model file has the following requirements.

The minimum form of the XML file consists of a DOCTYPE element and a
datacenter element. The datacenter element, however, is not valid without at
least one valid child element. In this example, the child element is the
switch-fabric element with a name Default, as shown here:


<?xml version="1.0" encoding="ISO-8859-1"?>


<!DOCTYPE datacenter SYSTEM "xmlimport.dtd">
<datacenter>
<switch-fabric name="Default"/>
</datacenter>

All other elements must be placed between the <datacenter> begin and
</datacenter> end tags.

This example will initialize the ITITO data center model with nothing but a switch
fabric called Default.

4.2.3 DOCTYPE element
Within the DOCTYPE element, it is possible to code reusable segments of XML
(entities) that are included in elements defined later. For the demonstration, the
following entities should be included in the !DOCTYPE definition:

<!ENTITY workload-cluster SYSTEM "workload-cluster.xml">
<!ENTITY resourcepoolconfig SYSTEM "resourcepool.xml">
<!ENTITY dataacquisitionconfig SYSTEM "dataacquisition.xml">
<!ENTITY simulator-cpu '
<dae-driver device="server"
classname="com.thinkdynamics.kanaha.dataacquisitionengine.NullDriver">
</dae-driver>
<dae-signal name="cpu-utilization" device="server"
metric="cpu-utilization" aggregation="average"
filter="low-pass-filter">
</dae-signal>
'>
<!ENTITY simulator-arrival-rate '
<dae-driver device="load-balancer"
classname="com.thinkdynamics.kanaha.dataacquisitionengine.NullDriver">
</dae-driver>
<dae-signal name="arrival-rate" device="load-balancer"
metric="arrival-rate" aggregation="any" filter="low-pass-filter">
</dae-signal>
<dae-signal name="raw-arrival-rate" device="load-balancer"
metric="arrival-rate" aggregation="any">
</dae-signal>

'>
<!ENTITY null-load-balancer-dae '
<dae-driver device="load-balancer"
classname="com.thinkdynamics.kanaha.dataacquisitionengine.ZeroValueDriver">
</dae-driver>
<dae-signal name="arrival-rate" device="load-balancer"
</dae-signal>
<dae-signal name="raw-arrival-rate" device="load-balancer"
</dae-signal>
’>

Essentially, these entities are instructions to the simulator and provide
information about how the data is acquired and delivered to the various
components.

4.2.4 Power supplies
If power supplies are required, these can be included simply by including a
power-unit element with the name of the power unit and the device model, as
shown in the following example:
<power-unit name="Power Unit 1" is-device-model="APC-7901-SNMP">
</power-unit>

4.2.5 Network components
The network components in ITITO consist of the following elements:
Switch fabric
Subnetworks
Switches
Load balancers (variety of switch)

Switch fabric
The switch fabric element in ITITO is just a name to which other elements refer.
Multiple switch fabrics can be defined if required. For demonstrations, it is
recommended that only one be used. The customer’s name can be used if
required, as shown in the following example:
<switch-fabric name="Customer Network">
</switch-fabric>


Subnetworks
Each subnetwork identified in “Subnetworks” on page 9 should be entered using
the subnetwork element together with the VLAN and switch fabric name, as
shown in the following example:
<subnetwork ipaddress="192.168.1.0" netmask="255.255.255.0">
<vlan vlan-number="101" fabric="Customer Network"/>
</vlan>
</subnetwork>

We recommend that you define all of the subnetworks in one group at this point
in the XML file to aid in locating them when the data center model grows.

In addition, it is a good idea to define the subnetwork of the ITITO server. For the
demonstration system (discussed in Chapter 5, “Demonstration” on page 107)
the ITITO server is on an IP address of 192.168.192.168, so there should be an
additional subnet defined as follows:
<subnetwork ipaddress="192.168.192.0" netmask="255.255.255.0">
<vlan vlan-number="192" fabric="Customer Network">
</vlan>
</subnetwork>

Switches
Every switch, switch module, and switch port identified in “Switches” on page 10
should be defined in the data center model using the switch element, as shown in
the following example:
<switch name="Switch 1" is-device-model="Dummy Switch"
fabric="Customer Network" ipaddress="192.168.1.253">
<switch-module name="fa0">
<switch-port vlan="101" port-number="1"
layer1-interface-type="FastEthernet">
</switch-port>
</switch-port>
</switch-port>
</switch-port>
</switch-port>
</switch-port>


</switch-port>
</switch-port>
</switch-port>
</switch-port>
</switch-port>
</switch-port>
</switch-port>
</switch-module>
<power-outlet power-unit="Power Unit 1" outlet-number="1">
</power-outlet>
</switch>

Note: For this switch, there is a reference to a power unit. If power units are
not required, this can be omitted. We recommend that you define all of the
switches in one group for clarity.

In ITITO routers and firewalls are types of switches. Each router and firewall
identified in “Routers and firewalls” on page 11 should be defined using the
switch element and a number of network-interface child elements. Firewalls
should be identified with the firewall element, which takes no parameters. In this
example, the network interface contains a reference to an access control list that
is defined later.
<switch name="Router 1" is-device-model="Dummy Switch"
fabric="Customer Network">
<network-interface name="Management" ipaddress="192.168.1.254"
managed="false">
<route subnetwork="192.168.2.0" gateway="192.168.1.254">
</route>
</route>
<acl-ref type="1" name="ACL-1" enabled="true">
</acl-ref>


</network-interface>
<network-interface name="TIO" ipaddress="192.168.192.254"
managed="false">
</route>
<acl-ref type="1" name="ACL-2" enabled="true">
</acl-ref>
<firewall/>
<power-outlet power-unit="Power Unit 1" outlet-number="2">
</power-outlet>
</switch>

Each ACL identified in “Access control lists” on page 12 should be defined using
the acl element, as shown in the following example:
<acl name="ACL-1">
<rule position="1" target="permit" source-subnet="192.168.1.0"
destination-subnet="192.168.2.0">
</rule>
<rule position="2" target="permit" source-subnet="192.168.2.0"
destination-subnet="192.168.1.0">
</rule>
</acl>

For the purposes of a demonstration, it will probably not be necessary to define
the ports used by each ACL.

Load balancers
Load balancers are defined with the load-balancer element. The following
example shows the definition of a dummy load balancer to be used for
demonstration purposes only:
<load-balancer name="Load Balancer 1" is-device-model="Dummy LB"
type="arrowpoint-load-balancer" ipaddress="192.168.1.252">
</load-balancer>

Virtual IPs
Each virtual IP name used by the load balancers should be defined using the
virtual-ip address, as shown in this example:
<virtual-ip name="Web Sales" load-balancer="Load Balancer 1"
virtual-ip-address="192.168.1.250" in-tcp-port-first="80"
in-tcp-port-last="80" out-tcp-port="80"/>
</virtual-ip>


Each cluster that is to demonstrate automatic provisioning should reference a
virtual IP, so ensure that one is defined for each of these clusters.

4.2.6 Software
The three categories of software (software package, software patch, and
software stack identified in 2.3.3, “Software” on page 14 are defined, as shown in
the following examples.

Software package
Software packages are defined with the software element type, for example:
<software name="Windows 2000" version="2000"
package_path="d:repositoryWin2000" type="OPERATING_SYSTEM"
install_path="c:winnt">
</software>

Software patch
Any software patches required can be defined using the software-patch element:
<software-patch name="Windows 2000 Service Pack 4" package_path="c:"
reboot="true">
</software-patch>

Software stack
Finally, software packages and software patches are grouped into software
stacks using a combination of the software-stack and software-stack-product
elements, as shown in this example:
<software-stack name="Windows 2000 Server">
<software-stack-product product-name="Windows 2000" position="1"
expected-state="running">
</software-stack-product>
<software-stack-product product-name="Windows 2000 Service Pack 4"
position="2" expected-state="running"/>
</software-stack-product>
</software-stack>

4.2.7 Spare pools
Each collection of spare similar servers identified in 2.3.4, “Spare pools” on
page 16 should be defined by the spare-pool element containing a number of
server elements, in turn, containing NIC and network-interface elements.


Note: For these servers, it is usually a good idea to have multiple network
interface cards at least one of which is reserved for managing the server and
is marked as not managed by ITITO. Other network cards can be set to
managed, which will allow ITITO to assign change and remove IP addresses
(network interfaces) when required. Obviously, if all the network interface
cards are set to managed, ITITO could attempt to change the IP address of
the network interface it is using to communicate with the server with
unpredictable results!

<spare-pool name="Intel Pool" os-type="" vlan="101"
<server name="x330-1">
<nic managed="false" connected-to-switch="Switch 1"
connected-to-module="fa0" connected-to-port="1">
<network-interface name="Management" ipaddress="192.168.1.3"
managed="false"/>
</nic>
<nic managed="true" connected-to-switch="Switch 1"
connected-to-module="fa0" connected-to-ort="11">
</nic>
</server>
</spare-pool>

ITITO requires that the ITITO servers are defined to the system and placed in a
resource pool. For this demonstration, it is not strictly necessary, but it is
worthwhile showing this by including the following resource pool definition:
<spare-pool name="TIO Server" os-type="" vlan="192"
<server name="wink">
<nic managed="false" connected-to-switch="Switch 1"
connected-to-module="fa0" connected-to-port="5">
<network-interface managed="false" ipaddress="192.168.192.168"/>
</nic>
</server>
</spare-pool>

4.2.8 ITITO configuration
There are a number of general settings for ITITO that control the operation of the
whole system that need to be defined in the data center model. These settings
include global parameters, data acquisition parameters, and also the inclusion of
macros for certain components.


These configuration parameters are defined with the kanaha-config element that
has a single child element of dcm-object.

One of the most important elements that should be created under the dcm-object
element is a properties element with the ID of 0. This element contains the global
variables for the whole system including items such as the operations mode, the
default source host and directory for software packages, and the temporary path.
For a demonstration, the actual locations of the software packages are not
important, but can be useful to show the customer where these values are
defined. Some parameters available include:

Table 4-1 Deployment engine global variables
Component Name Value (with samples)

RESOURCE_BROKER OperationsMode-current manual

DEPLOYMENT_ENGINE PackageUtilPath /opt/zip

DEPLOYMENT_ENGINE PackageScriptPath /home/thinkcontrol/script

DEPLOYMENT_ENGINE PackageTempFilePath /tmp

DEPLOYMENT_ENGINE PackageIntermediateHost 192.168.1.200

DEPLOYMENT_ENGINE PackageRepositoryHost 192.168.1.200

DEPLOYMENT_ENGINE PackageRepositoryDir /usr/local/kanaha/upload

DEPLOYMENT_ENGINE PackageWebHost 192.168.1.200

DEPLOYMENT_ENGINE PackageWebDir /usr/local/kanaha/apps

The following example shows a typical kanaha-config element that we
recommend you load in the demonstration data center model:
<kanaha-config>
<dcm-object id="0">
<property component="RESOURCE_BROKER" name="OperationsMode-current"
value="manual">
</property>
<property component="APPLICATION_CONTROLLER"
name="predictor-prediction-interval-msec" value="900001">
</property>
name="predictor-type.1.class"
value="com.thinkdynamics.kanaha.controller.appcontroller.predictor.DefaultP
redictor">
</property>


name="predictor-type.1.enable" value="true">
</property>
value="com.thinkdynamics.kanaha.controller.appcontroller.predictor.LinearTr
endPredictor">
</property>
name="predictor-type.2.enable" value="false">
</property>
value="com.thinkdynamics.kanaha.controller.appcontroller.predictor.OneDayPr
edictor">
</property>
</property>
value="com.thinkdynamics.kanaha.controller.appcontroller.predictor.OneWeekP
redictor">
</property>
</property>
<property component="DEPLOYMENT_ENGINE" name="PackageUtilPath"
value="/opt/zip">
</property>
<property component="DEPLOYMENT_ENGINE" name="PackageScriptPath"
value="/home/thinkcontrol/script">
</property>
<property component="DEPLOYMENT_ENGINE" name="PackageTempFilePath"
value="/tmp">
</property>
<property component="DEPLOYMENT_ENGINE" name="PackageIntermediateHost"
value="192.168.1.200">
</property>
<property component="DEPLOYMENT_ENGINE" name="PackageRepositoryHost"
value="192.168.1.200">
</property>
<property component="DEPLOYMENT_ENGINE" name="PackageRepositoryDir"
value="/usr/local/kanaha/upload">
</property>
<property component="DEPLOYMENT_ENGINE" name="PackageWebHost"
value="192.168.1.200">
</property>
<property component="DEPLOYMENT_ENGINE" name="PackageWebDir"
value="/usr/local/kanaha/apps">


</property>
&resourcepoolconfig;
&dataacquisitionconfig;
</dcm-object>
</kanaha-config>

The first parameter listed here is the global operations mode of the ITITO
system. In this case, it is set to manual, although it could be set to automatic if
required.

For a demonstration, it might be advisable to start the demonstration in manual
mode and then to switch to automatic using the GUI after the basic principles
have been shown. This will be explained more in the next chapter.

4.2.9 Customers
Each customer, application, cluster, and dedicated server identified in 2.3.5,
“Applications and customers” on page 16 must be defined using the customer,
application, cluster, and server elements that must be defined in the
corresponding hierarchy.

The following example shows a single server for one cluster in an application for
one customer:
<customer name="Customer">
<application name="Internet Sales" priority="1">
<cluster name="Sales Web Servers" min-servers="1" max-servers="5"
vlan="102" fabric="Customer Network" pool="Intel Pool"
managed="true" is-device-model="Simulator"
virtual-ipaddress="Sales Web">
<with-load-balancer name="Load Balancer 1"/>
<server name="SalesWebSrv01">
<nic connected-to-switch="Switch 1"
connected-to-module="fa0" connected-to-port="13"
managed="false">
<network-interface name="Local Area Connection"
ipaddress="192.168.2.3"/>
</network>
</nic>
</server>
</cluster>
</application>
</customer>

Note: The virtual IP address is set for this cluster. This is important for the
simulator to be able to provision servers automatically.


4.3 Sample XML files
Included with this document are some sample XML files that can be used as a
reference or to help the reader get started. Two examples are available:
The Cookbook example, from which the segments in the previous section
were taken.
The XML file used in Provisioning On Demand: Introducing IBM Tivoli
Intelligent ThinkDynamic Orchestrator, SG24-8888.

Both examples have corresponding simulator definitions. In addition, the
demonstration system itself contains a data center model and simulator
parameters for the U.S. open environment.

4.3.1 Cookbook example DCM
The example that provided the fragments of XML in the previous section is based
on the following physical design of a data center. See Figure 4-4 on page 92.

In this data center, there are two applications: Human Resources and Internet
Sales. Each is a two-tier application with a Web server tier and a database tier.
The Web servers of each use Intel machines and Microsoft IIS, but the database
servers use SQL server on Intel and DB2 on AIX, respectively. Each tier/cluster
has one dedicated server, that is, a server that is not under ITITO control. The
SQL server machine is not to take part in automatic provisioning.

The production servers are all attached to switch Prod-SW-1 and have dedicated
VLANs. The load balancer Load Balancer 1 balances the workload.

There is a pool of eight Intel machines with dual network cards. One card is
attached to the production network switch, and the other is attached to a
management LAN using Switch 1. There is also a pool of one RS/6000®
machine that is similarly attached and can be used to provide some relief to the
Human Resources database when required. All the spare pools are in VLAN
101.

The ITITO server is attached to the management LAN, but has its own VLAN.

Finally, traffic is routed between all the VLANs by the router Router 1.

This XML can be found in the file Demo-Cookbook.xml.

The simulator parameters can be found in the file:
Demo-Cookbook-tdnetwork.xml


Figure 4-4 Sample network infrastructure

4.3.2 Redbook example
Full details of the redbook example can be found in Provisioning On Demand:
Introducing IBM Tivoli Intelligent ThinkDynamic Orchestrator, SG24-8888.

The data center model for the redbook has been modified to use the simulator
rather than the real servers and load balancers.

The redbook data center model can be found in the file Redbook-simulator.xml.


The simulator parameters for the redbook example can be found in the file
Redbook-tdnetworks.xml.

4.4 Loading the data center model
The XML data center model must be placed in the cygwinhomethinkcontrolxml
folder, although the actual name of the file is unimportant. To load the XML file
and reinitialize the database it is necessary to do the following:
1. Edit the file reinit-exec.bat in cygwinhomethinkcontroltools.
2. Change the line that contains set DCMCFG_FILE=example.xml in the
reinit-exec.bat file so that the new XML file is specified, for example:
set DCMCFG_FILE=Demo-Cookbook.xml
3. Open a command window.
4. Make sure the directory is homethinkcontrol.
5. Run the command toolsreinit.bat.

Note: Be patient! This process can take 30-45 minutes, depending on the
hardware used to support the environment.

To follow the progress, you can open a new command window and enter the
following command in order to see the entries put into the log file:
tail –f %tc_home%logsreinit.log

After no new lines are added, the process has completed.

If this command returns with no Java errors, the data center model has loaded
successfully, and ITITO can now be started. If any errors have been identified, it
is necessary to debug these and reinitialize the database before proceeding.

It can be quite tricky to determine the nature of any loading errors. The best
method consists of locating the type of element in which the error has occurred.
This is much easier if all the elements are grouped together as recommended.
Typical errors include:
Referring to a non-existing element.
Missing attributes for an element.
Specifying an incorrect format for an IP address.
Specifying an alphanumeric character where a numeric is expected.
Specifying a device driver that does not exist.


As a last resort, it might be necessary to remove elements of the XML file and
reload to determine which parts are not correct.

If problems are experienced, it is sometimes helpful to build each section of the
XML file in turn. If you follow this order, referential errors can be avoided:
1. Configure the XML file with power supplied only.
2. Add the network components:
a. Add subnetworks.
b. Add switches.
c. Add ACLs.
d. Add routers, firewalls, and load balancers.
e. Add virtual IPs.
3. Add the software configuration.
4. Add any miscellaneous components:
a. Add terminal servers.
b. Add blade center management servers.
c. Add boot servers.
5. Add the spare pools.
6. Add the ITITO configuration.
7. Finally, add the customer configuration.

4.4.1 Tip for creating XML files using text editors
If a text editor is used to build the XML file, it can get rather large and unwieldy.
One method of coping with this is to create separate files for each component
type and then to assemble them prior to loading. For example, a number of files
are available:
Header section in the 1-Header.xmf file.
Power supply section in the 2-power-units.xmf file.
Networks section in the 3-Networks.xmf file.
Software, software stack, and software patch in the 4-software.xmf file.
Boot server definition. A Rembo server example is provided in the
5-bootserver.xmf file.
Resource pools in the 6-pools.xmf file.
ITITO variables in the 7-configvariables.xmf file.
Customer definition in the 8-customer.xmf file.
Terminal server, blade server, and so on in the 9-other.xmf file.


Finally, the datacenter terminator tag in the 10-trailer.xmf file.

Note: The extension .xmf is used here to distinguish the files from XML files and
means an XML fragment.

It will then be possible to concatenate the files together (in the right order, from 1
to 10) into an XML file with the following command:
Cat xmf_file >> DCM-file.xml

Where, xmf_file is the fragment file described above.

The XML file can then be loaded as before.

Furthermore, it is a good idea to have separate files for each type of component
as long as they have the correct prefix, for example, 5-SparePool-Intel.xmf,
5-SparePool-Linux.xmf, or 5-SparePool-AIX.xmf.

4.5 Configuring the simulator
The ITITO simulator is configured using a number of parameters in the data
center model and also in the tdnetwork.xml file in the
/cygwin/home/thinkcontrol/config folder.

4.5.1 Data center model
Each cluster that takes part in the simulation must have the source of the data
acquisition data defined and a simulation workload model associated with this
source.

The data acquisition properties are defined in the XML data center model, and
the simulation workload model is defined in the tdnetwork.xml file.

For the purposes of a demonstration, each cluster requires a dcm-object element
to be defined as follows within the kanaha-config element:
<dcm-object type="cluster" name="Sales Web Servers">
&workload-cluster;
<data-acquisition>
&simulator-cpu;
&simulator-arrival-rate;
</data-acquisition>
</dcm-object>

In this case, the texts &workload-cluster;, &simulator-cpu;, and
&simulator-arrival-rate; refer to entities defined in the DOCTYPE element and


essentially are variable names that refer to macros. If the XML file is viewed with
a Web browser, it can be seen that the variable name is replaced with the full
definition from the DOCTYPE element.

It is also possible to define these data acquisition properties within each cluster,
but we recommend for simplicity in defining demonstrations that they are just
defined in the kanaha-config element.

4.5.2 The tdnetworks file
The tdnetworks file consists of three main sections under the simulator element:
Cluster-type
Schedule
Application traffic functions

The simulator element contains the enable attribute that allows the simulator to
be running at startup or stopped.

The tdnetworks cluster type element
The cluster-type element allows for different scaling factors to be applied to the
traffic functions by particular types of cluster. However, it appears that in the
Version 1.1 of ITITO that only one type of cluster is supported: UNKNOWN.

This element is used to set the arrival rate, CPU utilization, and response times
for the cluster type. In ITITO V1.1, the response times are not used, so they can
be ignored.

The CPU utilization parameter sets the percent of CPU used by a single
transaction and the constant CPU percent. These parameters are specified as
fractions of 1.

The tdnetworks schedule element
The schedule element controls startup and the sampling interval of the simulator.

This element has two attributes expressed in milliseconds:
Startup-delay
Iteration

The tdnetworks application traffic element
Finally, the application traffic function allows a simulated workload to be applied
to each cluster by using various functions; it is possible to increase or decrease
the workload in smooth ramps or steps using the various parameters available.


The simulator provides two functions for simulating a workload: a step function
and a ramp function. The step function simulates a constant workload for a
specified duration, and the ramp function simulates a rising or falling workload
from an initial position.

The step function requires the following parameters:
Duration (in milliseconds)
Amplitude (expressed as a percentage of the max_amplitude defined for the
application)

The ramp function requires the following parameters:
Slope (expressed as a ratio of transactions/millisecond, for example, 45
degrees upwards = 1, and 45 degrees downwards = -1)
Duration (in milliseconds)
Initial value (expressed as a percentage of the max)

Important: For a demonstration of automatic provisioning, it will be necessary
to define a workload for each of the customer’s applications. Note that the
workload is set at the application level and not cluster.

If the customer is able to provide a graph of a typical workload for each
application, this could be used to build the simulator functions. For example, the
following graph might represent two typical workloads:
An office environment where there is little work before 9:00 a.m., then as staff
come into work, the workload increases until lunch when it dips down until the
afternoon before tailing off for the evening.
A Web environment where there are a number of users before 9:00 a.m., then
as the users go into work, the workload drops until lunch when some users
might log on again before going back to work in the afternoon until the
evening then there is a steady workload. In this example, surprisingly nobody
is using the Internet application in the afternoon!


Workload

1200

1000

800

Workload % Office workload
600
Internet workload

400

200

0
00

00

0

0

0

0

0

0

0
:0

:0

:0

:0

:0

:0

:0
6:

8:

10

12

14

16

18

20

22
Time

Figure 4-5 Workload during the day

When looking at the workload depicted above, it is obvious that the
representation is focused on the relative amount of work that needs to be
performed, not on any actual numbers. When trying to simulate this workload, we
need to establish some point of reference by which we can quantify the amount
of work. For example, does 100% workload mean 5 or 1000000 simultaneous
transactions?

For the purpose of the discussion, we assume in the following that 100%
workload is achieved at 1000 simultaneous transactions.

Now, with a proper reference point to set the scales of the above chart, we also
need to know how much one transaction loads a system in our configuration. The
correlation between a transaction and cpu-load allows us to translate workload
into processing need, and thus simulate CPU usage and allocation of servers.

For the sake of the discussion, let us assume that one transaction generates 5%
load on a system. Here, we do not distinguish between different types of
systems, because all the systems that will be allocated to support a workload will
have similar configurations, and thus the use of a general number for load per
transaction will not influence the calculations.


The simulator functions required to simulate the above office workload are as
follows:

Table 4-2 Simulator functions for the sample Office workload
Function Slope Duration Initial value Amplitude

StepFunction 12000 20

RampFunction 6000 20


RampFunction -1 6000 100






The simulator functions that represent the above Internet workload are as
follows:

Table 4-3 Simulator functions for the sample Office workload
Function Slope Duration Initial value Amplitude








RampFunction 6000





Calculating the number of systems
Knowing the workload over time as a percentage of the total workload,
unfortunately, does not indicate how many transactions are being initiated or how
much computing power is required to support the workload. To deduce the
number of servers required running the workload, we have to look at the
cluster_type properties again and combine these with our workload numbers.

From the cluster_type element, the value for the scale property tells us how much
cpu-load each transaction generates and the value for the constant property
indicates what the system overhead, or idle load, is. For a max_amplitude of an
application of 1000000 and a scale of 0.05, we can deduct that the total
requirement for CPU at 75% workload is:
75%*1000000 transactions *0.05 %cpu/transaction = 37500 %cpu = 375 cpus

This almost translates to a requirement for 375 servers each using all their
capacity to support our workload.

When calculating the required servers, we have to adjust this number to account
for the fact that each system cannot provide 100% CPU to support the workload.
First of all, the system needs a few cycles for system overhead, which is
represented by the constant property of the cpu_utilization parameter of the
cluster_type entry. In the following, we assume that the value for constant is 0.01.

In addition, the systems are never fully 100 percent committed to specific
workload. From the Service Level Objective specified for the application,
Platinum, Gold, or Silver, we know that more resources will be allocated to the
application clusters when the average CPR utilization reaches a predefined
cut_off value. The default values are 75%, 80%, and 90%, respectively. This
implies that for an application with a Silver SLA, new systems are allocated when
the average CPU load reaches 90%. Taking the idle load into account, we realize
that the fraction of each system that will be used to execute our workload is:
Effective_CPU = Cut_off – constant

For a Silver application with a constant of 0.01, the effective_CPU will be:
Effective_CPU = 0.90 – 0.01 = 0.89

Therefore, to adjust the calculation of needed required servers to account for
these factors, the formula for the total number of required servers for to support a
workload is:
Workload% * ( max_amplitude * scale) / (cut_off – constant)

Using the numbers in our example, we get:
75% * (1000000 * 0.05)/100*(0.90 – 0.01) = 422 servers
4.5.2.3.2 Calculating the RampFunction slope


As seen above, when working with RampFunctions you have to specify the
starting point, in terms of the percent fraction of the max_amplitude, and a slope
to describe the curve. This can seem somewhat awkward compared to
specifying starting and ending workload percentages, so in the following
example, we demonstrate how to calculate slope based on pure workload data.

As described earlier, the slope is a number indicating the growth (or decline) of
transactions per time unit, and you might remember that the amplitudes denote
fractions (in percent) of the max_amplitude defined for an application. Combining
this information you can deduct that the slope, in terms of transaction increase or
decrease over time, can be calculated as follows:
Slope =
(Max_amplitude * (Ending_amplitude – Starting-amplitude)/100) / duration

Please note that the starting_amplitude is also known as initial_value.

To deduct the amplitudes, as percentages of max_amplitude, we have to involve
the scale attribute of the cpu_utilization parameter of the cluster_type entry. The
scale specifies how much one transaction loads a system. Combining this
information with the amplitudes allows us to work with CPU load instead of
slopes.

Assuming the following:
Scale = 0.05 (5% cpu load for each transaction)
Max_amplitude = 100000
Initial_value= 23% cpu
Duration= 60000 milliseconds (one minute)
Desired ending amplitude = 75%

We can calculate the slope as follows:
Workload_growth (ending_load – starting_load) = 75%-23% = 52%
Growth in transactions: workload_growth *max_amplitude =
0.52*1000000 = 520000 transactions
slope = transactions / duration520000/60000 = 8.6667

Now that we know how much the workload increases over time, we can calculate
the number of additional servers needed to support this load:
Growth in CPU demand: growth in transactions*scale =
520000*0.05 = 26000 %cpu
Growth # of servers = Growth in CPU demand/100*(cut_off– constant) =
26000/(0.90-0.01)*100 = 293 servers

To determine the amount of servers needed to support this resulting workload,
we see:


Ending server demand_ =
(starting load*max_amplitude + slope*duration)*scale/(cut_off – constant)
= (0.23*1000000 + 8.6667*60000) * 0.05/(0.90 – 0.01)*100
= 422 servers

Note: To ease the calculations of workload and the required number of
servers to sustain this, we have provided a small, self-explaining spreadsheet
to help you.

The simulator parameters, which can be found in the provided
Demo-Cookbook-tdnetwork.xml, needed to generate a workload for two
applications, Human Resources and Internet Sales of our Demo-Cookbook
(Demo-Cookbook.xml) DCM, are as follows:
<?xml version="1.0"?>

<td_network>
<Version>0.80-032001</Version>
<simulator enable="true">
<cluster-type name="UNKNOWN">

<simulation-parameters name="arrival-rate" noise-scale="0.0"
output-ratio="0.25">
</simulation-parameters>
<simulation-parameters name="cpu-utilization" scale="0.05"
constant="0.01" max="1">
<simulation-parameters name="response-time" scale="1.0" constant="77.0"
max="100">
</cluster-type>

<schedule startup-delay="5000" iteration-period="20000">

</schedule>
<application_traffic_functions>


<app_function app_name="Human Resources" max_amplitude="1000000">
<!--This Application has a workload model that resembles the typical
daytime office hours workload. I.e a peak at 9:am steady workload until

12:00 a drop until 2 and a peak until 5pm and not much overnight.-->
<function function_type="StepFunction" duration="12000" amplitude="20">
</function>
<function function_type="RampFunction" slope="2" duration="6000"
init_value="20" amplitude="100">
</function>
<function function_type="StepFunction" duration="12000"
amplitude="100">
</function>
<function function_type="RampFunction" slope="-1" duration="6000"
</function>
</function>
</function>
amplitude="100">
</function>
</function>
<function function_type="StepFunction" duration="30000" amplitude="0"/>
</app_function>
<app_function app_name="Internet Sales" max_amplitude="1000000">

</function>
init_value="75" amplitude="">
</function>
</function>
</function>
amplitude="100">
</function>
init_value="100">
</function>
</function>

</function>
amplitude="100">
</function>
</function>
</function>
</app_function>
</application_traffic_functions>
</simulator>
</td_network>

Simulating multiple workloads
When using the simulator to demonstrate multiple workloads orchestrated
simultaneously by ITITO, you should be aware of the limitation in the current
release, which only allows for the UNKNOWN cluster_type entry.

The effect of not being able to specify multiple cluster_types forces you to use the
same value for the constant property (the system overhead) for all applications,
no matter which platforms are used to support the application-specific workload.
This can be regarded as a small inconvenience, which can be overcome by
defining the smallest value for the constant property and adding extra
transactions to selected workloads to simulate extra idle load.

Assuming that you have three workloads running on three different platforms with
the current characteristics:
App1 real_scale=0.05 idle_load=0.01 real_max_amplitude=1000

You would specify the lowest of the three idle_load values (0.001, the one from
App1) as the value for the constant property of the Unknown cluster_type
definition. To signal to the simulator that the idle_load in fact is higher than 1% for
App2 and App3, you have to increase all workload percentages to take the higher
idle_load into account. The increase must match the missing idle_load in terms
of %cpu, so for each application, you have to add (idle_load
–constant)*max_amplitude*scale percent workload for each value for
initial_value and amplitude in the application_load statements. For App2, the
value will be (0.05 – 0.01)* 10000*0.01 = 4% or 0.04. For App3, the increase is
(0.03 – 0.01)*500*0.02 = 0.2% or 0.002.

The limitation of supported cluster_type entries in the current implementation of
ITITO also applies to the value for the scale property. It is highly unlikely that all
application transactions load the supporting platforms equally. Therefore,


because you can only specify one value the scale property, you must specify the
lowest one of the applications you will be simulating, and adjust the
max-amplitude for the other applications accordingly.

In our example, we would specify a common value for scale of 0.01, which comes
from App2. Using this value for all the applications, the simulated workload for
App1 would be one fifth of the anticipated workload and half of the anticipated
workload for App3. Because all workloads are specified as percentages of the
max_amplitude, all we need to do to compensate for the lower scale is to multiply
the real_max_amplitude for App1 and App3 by a factor of (real_scale/scale),
which is 5 and 2, respectively, for the two applications in question.

4.6 Testing
Before demonstrating the system to the customer, it should be adequately tested,
and ideally, a complete walk through of the demonstration should be performed
first. Ensure that the following key areas are working:
The GUI loads and the switch fabric can be opened.
The icon view of the switch fabric is available.
Drill down to a switch to view the ports, and so on.
Optionally, use the GUI to turn a switch port on or off. (Only attempt this if the
switch has the dummy switch device driver.)
Open a resource pool and examine the servers. Make sure that the NICs and
interfaces are defined as needed.
Open a software package and check its contents.
Check that the software package is included in relevant software stacks.
Open the customer and make sure that the applications and clusters are
defined correctly.
Display the server view from a cluster that will use automatic provisioning.
Make sure that the simulator is generating a workload for the servers in these
clusters. (They will have a bar chart of CPU utilization if it is.)
Switch a cluster into manual mode.
Add a server to the cluster. Check that the deployment succeeded and that
the server was added.
Return to the switch fabric view and ensure that the managed port on the
server has been moved to a new VLAN.
Remove a server from the cluster. Check that it was removed successfully.


Switch the demonstration to automatic mode.
Make sure that servers are added and removed from the application clusters
as the workload rises and falls.
Select the Overview and make sure that the 3D view is working.


5

Chapter 5. Demonstration
This section explains the main points for demonstrating ITITO and contains the
following sections:
Introduction to ITITO and the scenario
Data center assets and resources
Customer applications
Real-time performance monitoring


5.1 Introduction to ITITO and the scenario
You should probably start with the presentation with a quick overview of ITITO.
You should familiarize the customer with the main capabilities of ITITO,
especially the ones you have agreed to demonstrate during the initial interview.

The following section has been extracted from Provisioning On Demand:
Introducing IBM Tivoli Intelligent ThinkDynamic Orchestrator, SG24-8888.

5.1.1 ITITO: A quick overview
The following figure shows a typical example of a data center running three
applications, in which one application needs additional resources to attend to
user demand, while the other two have enough, or even extra, resources
allocated to them. Traditional, manual provisioning practices do not make it
practical to move resources from one application to another to meet short-term
peaks in demand. Instead, we engage in what we call the just-in-case
provisioning cycle:

Figure 5-1 Traditional just-in-case provisioning


IBM has changed the provisioning paradigm from just-in-case to just-in-time with
IBM Tivoli Intelligent ThinkDynamic Orchestrator by managing resources
information and to enhance automation. ITITO dynamically moves computing
resources to support the applications with the greater immediate impact on the
business just-in-time to meet user demand. Therefore, an organization can reach
higher levels of automation and rapidly respond to fluctuating business demands
on the IT infrastructure, in line with the overall business goals of the organization.

ITITO automates the traditional, manual provisioning process, performance
measurement, capacity planning, and infrastructure deployment. ITITO operates
in a closed loop that performs automatic resource requirements prediction,
based on predefined service level objectives and agreements, and automates
infrastructure deployment. This just-in-time cycle ensures that each application
has the resource it needs, when it needs it, without static over provisioning.

Figure 5-2 Orchestrated Just-in-Time provisioning

Although any application can be allocated to any server at any time, a server
could be built specifically for an application when it needs it and is subsequently
deallocated when it is no longer needed by the application.

Chapter 5. Demonstration 109

5.2 Data center assets and resources
When the demonstration has been created, it should represent a network
configuration that you and the customer have agreed upon. Show the customer
the schematic representation of the environment you have created.

5.2.1 Show the switch fabric and inventory resources
Select the Data center assets and resources tab –> toggle Inventory –>
toggle Switch Fabrics –> select the customer switch fabric you created –>
change the view to icon view.

You should now have a diagram similar to the following:

Figure 5-3 The switch fabric network details - icon view


Click the switch. This will show the customer the VLANs in more detail and which
switch ports are connected to the servers:

Figure 5-4 Switch network details - icon view

You can also drill down to a single server view by selecting any of the servers:

Figure 5-5 Server network details - icon view

All the resources are listed under the Inventory toggle. Show any resources you
think the customer may be interested in seeing. They should all be configured to
the requirements agreed upon when setting up the environment. Remember to
switch the view back to the details view.

5.2.2 Show the customer the resource pools
Select the Data center assets and resources tab -> toggle Resource Pools.

Ensure the correct servers are in each pool. Select one of the pools and show
the servers. Talk about their current status: If they are brown, they are assigned
to a cluster and application, if they are green, they are unassigned, and so forth.

The following diagram shows servers in the Intel Pool. For example, x330-2 and
x330-7 are assigned to the Sales Web Servers cluster part of the Internet Sales


application, and x330-4 is assigned to the HR Web Servers cluster part of the
Human Resources application.

Figure 5-6 Servers in the pre-POC environment

5.3 Customer applications
Show the customer the applications that are being provisioned.
1. Select the Customer applications tab -> toggle Customers -> select the
customer name.
You now see the names of the applications that you have agreed with the
customer should be provisioned.
2. Select one of these applications -> select the Clusters tab.
You now see the names of the clusters that are part of the application and
information about the clusters:


Figure 5-7 Application clusters

3. Select the Servers tab.
You now see the names of the servers running the application, the clusters
they belong to, and their utilization:

Figure 5-8 Active servers for an application

4. Select the Properties tab.
You now see the Application Data where you can set SLA levels for the
application:


Figure 5-9 Application service objective details

5. Select one of the application clusters in the left column and select the Info
tab.
Here, you can see which servers are provisioned for the application and the
operating mode of the cluster. This page also shows you which pool the
servers are from or that the servers are dedicated to the cluster:

Figure 5-10 Active servers in a cluster

6. Change the Operating Mode to manual.
7. Type 1 into the Overflow service box, and select Add. (Set the refresh rate
to 10 sec.)
This manually provisions a server to this application. You will see a new
server from the pool appear in the cluster and the utilization of the other
servers reduces:


Figure 5-11 Manually provisioning a server

8. Change the Operating Mode back to automatic before you continue.
9. Select the Deployments tab -> set the Status to all -> select Search.
This shows you a history of all the successful and failed deployments of
servers to this cluster:

Figure 5-12 Server Add workflow transitions


5.4 Real-time performance monitoring
As long as it has been set up, the simulator changes the utilization of the servers
and automatically adds and removes servers from the applications. Servers can
also be added manually or semi-automatically.
1. For the servers to automatically be added and removed from applications
ensure all the applications are set to automatic mode, as follows.
Select the Customer applications tab -> toggle the Customer tag -> select
the customer name -> select the application -> set the Operating Mode on the
pull-down menu to automatic -> select Change.
2. Now show the overall server utilization and performance as the servers are
being added to and removed from applications:
Select the Data center assets and resources tab -> toggle Inventory ->
select Servers -> on the Servers tab from the top pull-down menus, select All
for Cluster and All for Pool -> select Search.

You should now have a view similar to the following figure:

Figure 5-13 Servers view - provisioning details

This view shows you all the servers in your environment, which
application/cluster they are assigned to, and to which pool they belong. Watch
the server utilization move up and down on the right side. As the utilization
increases for an application, you will see extra servers being assigned, and as
demand drops, servers being unassigned.


3. Hover your curser over the server names.
This will show you that the servers are in maintenance (red), available
(green), assigned (gold), or dedicated (silver).
4. Show the semi-automatic mode.
Select one of the applications from the Assigned to field -> select the
Clusters tab -> set the Operating Mode to semi-automatic from the
pull-down menu -> select Change -> select the Deployment tab -> set the
refresh rate to 10 sec -> from the Status pull-down menu, select Waiting for
Approval -> select Search.
The next time a server needs to be added to the application, an execution
request will show on the management GUI, as shown in the following figure:

Figure 5-14 Approving an operation in semi-automatic mode

If you approve the above request, a server will be removed from the application.

To check if the task you have approved has been executed successfully, from
the Status pull-down menu, select Deployed -> Search.


A

Appendix A. Additional material
This Redpaper refers to additional material that can be downloaded from the
Internet as described below.

Locating the Web material
The Web material associated with this Redpaper is available in softcopy on the
Internet from the IBM Redbooks Web server. Point your Web browser to:
ftp://www.redbooks.ibm.com/redbooks/REDP3830

Select the Additional materials and open the directory that corresponds with
the Redpaper form number, REDP3830.

Using the Web material
The additional Web material that accompanies this Redpaper includes the
following files:
File name Description
REDP3830.zip Data center model and workload simulation used during
the project.


System requirements for downloading the Web material
The following system configuration is recommended:
Hard disk space: 1 MB minimum
Operating System: Microsoft Windows
Processor: any
Memory: any

How to use the Web material
Create a subdirectory (folder) on your workstation, and unzip the contents of the
Web material zip file into this folder.


Related publications

The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this Redpaper.

IBM Redbooks
For information on ordering these publications, see “How to get IBM Redbooks”
on page 122. Note that some of these documents referenced here may be
available in softcopy only.
Orchestrator, SG24-8888.
IBM Web Infrastructure Orchestration, SG24-7003
Implementing Systems Management Solutions using IBM Director,
SG24-6188
WebSphere Edge Server New Features and Functions in Version 2,
SG24-6511
Unattended Pristine Installation with IBM Tivoli Configuration Manager,
SG24-6627
IBM WebSphere V5.0 for Linux, Implementation and Deployment Guide:
WebSphere Handbook Series, REDP-3601
IBM WebSphere V5.0 Performance, Scalability, and High Availability:
WebSphere Handbook Series, SG24-6198

Product manuals
These publications are also relevant as further information sources:
IBM Tivoli Intelligent Orchestrator and Tivoli Provisioning Manager Release
Notes, SC32-1422
IBM Tivoli Intelligent Orchestrator and Tivoli Provisioning Manager Operator’s
Guide, SC32-1421
IBM Tivoli Intelligent Orchestrator and Tivoli Provisioning Manager Installation
Guide, SC32-1420


IBM Tivoli Provisioning Manager and Intelligent Orchestrator Overview Guide,
SC32-1419

Online resources
These Web sites and URLs are also relevant as further information sources:
IBM Tivoli Intelligent ThinkDynamic Orchestrator Product Web page
http://www.ibm.com/software/tivoli/products/intell-orch/
IBM Tivoli Provisioning Manager Product Web page
http://www.ibm.com/software/tivoli/products/prov-mgr/
Cwgwin
http://www.cygwin.com/
WebSphere Application Server manuals
http://www.ibm.com/software/webservers/appserv/was/library/
IBM DB2 manuals
http://www.ibm.com/software/data/db2/library/
Software Support
http://www.ibm.com/software/support
IBM Web infrastructure orchestration
http://www.ibm.com/software/tivoli/features/web-svr-prov/solution.ht
ml
IBM Application Framework for e-business
http://www.research.ibm.com/journal/sj/401/flurry.html

How to get IBM Redbooks
You can search for, view, or download Redbooks, Redpapers, Hints and Tips,
draft publications and Additional materials, as well as order hardcopy Redbooks
or CD-ROMs, at this Web site:
ibm.com/redbooks


Help from IBM
IBM Support and downloads:
ibm.com/support

IBM Global Services:
ibm.com/services

Related publications 123

Back cover ®

IBM Tivoli Intelligent
Pre Proof-of-Concept Cookbook for Business Partners
Redpaper

Installation and This IBM Redpaper provides advice for Business
customization
INTERNATIONAL
Partners about how to plan for, implement, and
demonstrate IBM Tivoli Intelligent ThinkDynamic
TECHNICAL
Data center Orchestrator Version 1.1.0 and IBM Tivoli Provisioning
SUPPORT
modeling Manager Version 1.1.0 in a pre-proof-of-concept ORGANIZATION
simulated environment.
Workload simulation
This environment can be used to demonstrate the BUILDING TECHNICAL
capabilities of the IBM Tivoli orchestration and INFORMATION BASED ON
provisioning solutions using customer data, in order to PRACTICAL EXPERIENCE
gain customer acceptance for the next phase of the sell
cycle — to engage the Business Partner in a real IBM Redbooks are developed by
proof-of-concept of IBM Tivoli Intelligent ThinkDynamic the IBM International Technical
Orchestrator or IBM Tivoli Intelligent Provisioning Support Organization. Experts
from IBM, Customers and
Manager. Partners from around the world
create timely technical
information based on realistic
scenarios. Specific
recommendations are provided
to help you implement IT
solutions more effectively in
your environment.

For more information:
ibm.com/redbooks

REDP-3830-00

Ibm tivoli intelligent think dynamic orchestrator pre proof of-concept cookbook for business partners redp3830

More Related Content

What's hot (19)

Similar to Ibm tivoli intelligent think dynamic orchestrator pre proof of-concept cookbook for business partners redp3830 (20)

More from Banking at Ho Chi Minh city (20)

Recently uploaded (20)

Ibm tivoli intelligent think dynamic orchestrator pre proof of-concept cookbook for business partners redp3830