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
ThinkDynamic Orchestrator

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:
StrictHostKeyChecking no
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 =


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

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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (19)

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

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

Mais de Banking at Ho Chi Minh city

Mais de Banking at Ho Chi Minh city (20)

Último

Último (20)

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