ibm tivoli intelligent think dynamic orchestrator pre proof of-concept cookbook for business...

ibm.com/redbooks Redpaper

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

Edson ManoelTony French

Installation and customization

Data center modeling

Workload simulation

Front cover

http://www.redbooks.ibm.com/


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

February 2004

International Technical Support Organization

© Copyright International Business Machines Corporation 2004. All rights reserved.Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADPSchedule Contract with IBM Corp.

First Edition (February 2004)

This edition applies to IBM Tivoli Intelligent ThinkDynamic Orchestrator Version 1.1.0 and IBMTivoli Provisioning Manager Version 1.1.0.

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

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixRecommended reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xThe team that wrote this Redpaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xBecome a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

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

Chapter 2. Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 General questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 ITITO components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1 Power units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.2 Network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.4 Spare pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.5 Applications and customers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.6 Other devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.7 Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Chapter 3. Installing the demonstration systems . . . . . . . . . . . . . . . . . . . 253.1 Installation process overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.1 Recommended installation directories . . . . . . . . . . . . . . . . . . . . . . . 283.1.2 User IDs and passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Installing and configuring TIOdbsrv - Windows . . . . . . . . . . . . . . . . . . . . . 303.2.1 Creating the required user IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.2 Installing and configuring Cygwin . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2.3 Configuring SSH communications . . . . . . . . . . . . . . . . . . . . . . . . . . 323.2.4 Installing and configuring IBM DB2 UDB V8.1.2 on Windows . . . . . 343.2.5 Installing and configuring IBM Directory Server V5.1 . . . . . . . . . . . . 39

3.3 Installing and configuring TIOsrv - Windows . . . . . . . . . . . . . . . . . . . . . . . 453.3.1 Creating the required user IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.3.2 Installing and configuring Cygwin . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.3.3 Configuring SSH communications . . . . . . . . . . . . . . . . . . . . . . . . . . 463.3.4 Installing IBM DB2 Universal Database V8.1.2 Client. . . . . . . . . . . . 483.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. . . . . . . . . 523.3.7 Install the IBM WebSphere fixpack 1 and required fixes. . . . . . . . . . 553.3.8 Installing IBM Tivoli Intelligent ThinkDynamic Orchestrator . . . . . . . 67

Chapter 4. Creating the demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.1.1 WordPad or Notepad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.1.2 Cooktop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.1.3 XMLSpy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.2 Designing the data center model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.2.1 ITITO GUI method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.2.2 The XML method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.2.3 DOCTYPE element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.2.4 Power supplies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.2.5 Network components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.2.6 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.2.7 Spare pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.2.8 ITITO configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874.2.9 Customers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.3 Sample XML files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.3.1 Cookbook example DCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.3.2 Redbook example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4.4 Loading the data center model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.4.1 Tip for creating XML files using text editors . . . . . . . . . . . . . . . . . . . 94

4.5 Configuring the simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954.5.1 Data center model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954.5.2 The tdnetworks file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

4.6 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Chapter 5. Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075.1 Introduction to ITITO and the scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 108

5.1.1 ITITO: A quick overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085.2 Data center assets and resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

5.2.1 Show the switch fabric and inventory resources . . . . . . . . . . . . . . . 1105.2.2 Show the customer the resource pools. . . . . . . . . . . . . . . . . . . . . . 111

5.3 Customer applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1125.4 Real-time performance monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Appendix A. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

System requirements for downloading the Web material . . . . . . . . . . . . . 120How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

iv Pre Proof-of-Concept Cookbook for Business Partners

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Product manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Help 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

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

AIX®DB2 Universal Database™DB2®IBM®

ibm.com®OS/390®Redbooks™Redbooks (logo) ™

RS/6000®Tivoli®WebSphere®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 readingThe 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’sGuide, 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


The team that wrote this RedpaperThis 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 CenterSara C. Brumfield ITITO Level 2 Support, IBM Software GroupTheo Winkelmann On Demand Sales Enablement, IBM Software GroupLeonard Hand Senior Consulting I/T Architect, IBM Global eBusiness

Solution Center

Become a published authorJoin 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 welcomeYour 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

http://www.redbooks.ibm.com/residencies.html

http://www.redbooks.ibm.com/residencies.html


http://www.ibm.com/redbooks/


� Send your comments in an Internet note to:

[email protected]

� Mail your comments to:

IBM Corporation, International Technical Support OrganizationDept. JN9B Building 003 Internal Zip 283411400 Burnet RoadAustin, Texas 78758-3493

xii Pre Proof-of-Concept Cookbook for Business Partners

http://www.redbooks.ibm.com/contacts.html

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.

1

© 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

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


2.1 InterviewsTo 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 questionsDuring 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?

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

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:

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).

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


– 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 theirprevious 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?

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?

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?

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.

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.

Chapter 2. Planning 5

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

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)?

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)?

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

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.

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

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

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


� A low average utilization with idle servers available for peak demandOr,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

2.3 ITITO componentsAfter 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.

Applic-ation

#Servers

Operating systems

# Web

servers

# Data-bases

Avg.util%

# Spare

servers


2.3.1 Power unitsFor 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

Table 2-3 Power units data collection example

2.3.2 Network configurationThe 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

Power unit name Manufacturer Model Device model

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

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.


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 fabricThe 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

SubnetworksEvery 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

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.

Switch fabric name

Subnet address Netmask VLAN


SwitchesEach 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

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

The valid types of ports for ITITO Version 1.1 are:

� Ethernet� Fast Ethernet� Gigabyte

Subnet address Blocked range start Blocked range end

Switch name

Manufacturer ModelIP

addressSwitch fabric

Device model

Switch name Switch modules Switch port VLAN Port type


� 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

The following switches are supported by ITITO Version 1.1:

Table 2-9 Switch data collection example

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 firewallsRouters are defined as switches in ITITO, but they also require network interfaces, route definitions, and access control lists.

Switch name Power unit Power outlet


Cisco 6500 Cisco 6500 Switches Hybrid Mode

Cisco 6500 Cisco 6500 Switches Native IOS Mode

Cisco 3548 Cisco 3548


IBM Blade Center 4port GB

Blade Center 4p GB Eth

Extreme 48i Extreme 48i

Foundry Foundry Switch Foundry Switch

Others Dummy Switch Dummy Switch


The basic definition table for a router is as follows:

Table 2-10 Router data collection skeleton

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

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

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

Table 2-13 Router information data collection example

Access control listsFor 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.

Router name

Manufacturer Model IP addressSwitch fabric

Device model

Firewall

Router name Interface name IP address Managed

Router name Interface name Route Gateway ACL




Table 2-14 Access Control List data collection skeleton

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 balancersLoad balancers require the following information to enable them to be defined to ITITO:

Table 2-15 Load balancer data collection sample

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

Table 2-16 Load balancer data collection example

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.

ACL name Rule # Target Source subnet Destination subnet

Name Manufacturer Model Type Device model

Manufacturer Model Device model Type

Cisco 11000 Cisco CSS arrowpoint-load-balancer

Alteon LoadBalancer Alteon LoadBalancer

Dummy LB Dummy LB


Virtual IPsAny 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

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 SoftwareSoftware configuration in ITITO is divided into three categories:

� Software package� Software patch� Software stack

We address each of these in the following sections.

Software packageEach 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

Virtual IP name

Load balancer

Virtual IP address

First input port in range

Last input port in range

Output port

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 patchesSoftware 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

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

Software stacksSoftware 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

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.

Patch name Type Package path Install path

Software stack name Software product Position


2.3.4 Spare poolsIf 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

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

Table 2-22 Spare pool data collection skeleton

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 customersIn this section, it is necessary to gather information about the various applications that a customer wants to provision with ITITO. The basic data

Spare pool name VLAN Switch fabric

Sp

are

po

ol

nam

e

Ser

ver

nam

e

Net

wo

rk

inte

rfac

e ca

rd

Co

nn

ecte

d

to s

wit

ch

Co

nn

ecte

d t

o

swit

ch m

od

ule

Co

nn

ecte

d t

o

swit

ch p

ort

IP a

dd

ress

Man

aged

MA

C a

dd

r.


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

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

Each application cluster requires the following additional definitions:

Table 2-25 Cluster information data collection skeleton

Customer name or business unit

Application Priority Application cluster

Service plan Priority Interpretation

Platinum Better priority service

Gold Medium priority service

Silver 10 Poorer priority service

Ap

plic

atio

n

clu

ster

Min

. se

rver

s

Max

. se

rver

s

VL

AN

Sw

itch

fa

bri

c

Po

ol

Lo

ad

bal

ance

r

Vir

tual

IP

Man

aged


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.

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

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.

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.

Ap

plic

atio

n

clu

ster

Ser

ver

nam

e

Net

wo

rk

inte

rfac

e ca

rd

Man

aged

Co

nn

ecte

d

to s

wit

ch

Co

nn

ecte

d

to s

wit

ch

mo

du

le

Co

nn

ecte

d

to s

wit

ch

po

rt

IP a

dd

ress

MA

C

add

ress


2.3.6 Other devicesITITO 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 serversIf 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

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

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

Table 2-29 Boot servers supported by ITITO V1.1

Name Manufacturer Software IP address Device model

Bo

ot

serv

er

nam

e

Net

wo

rk

inte

rfac

e ca

rd

Co

nn

ecte

d

to s

wit

ch

Co

nn

ecte

d

to s

wit

ch

mo

du

le

Co

nn

ecte

d

to s

wit

ch

po

rt

IP a

dd

ress

Man

aged

MA

C a

dd

r.

Manufacturer Software Device model

Rembo Auto-Deploy Rembo Boot Server

IBM Remote Deployment Manager RDM 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

Terminal serversTerminal 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

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

Table 2-32 Terminal server network information data collection skeleton

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

Software stack name Boot server

Name IP address

Term

inal

se

rver

n

ame

Net

wo

rk

inte

rfac

e ca

rd

Co

nn

ecte

d

to s

wit

ch

Co

nn

ecte

d

to s

wit

ch

mo

du

le

Co

nn

ecte

d

to s

wit

ch

po

rt

IP a

dd

ress

Man

aged

MA

C a

dd

r.


Blade center management serversEach 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

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

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

Table 2-35 Blade server network information data collection skeleton

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:

Name Manufacturer Software IP address Device model

Manufacturer Blade system Device model

RLX Technologies ServerBlades RLX Blade Server

HP Proliant Blade Servers Proliant BL Server

Bla

de

serv

er

nam

e

Net

wo

rk

inte

rfac

e ca

rd

Co

nn

ecte

d

to S

wit

ch

Co

nn

ecte

d

to s

wit

ch

mo

du

le

Co

nn

ecte

d

to s

wit

ch

po

rt

IP a

dd

ress

Man

aged

MA

C a

dd

r.


Table 2-36 Blade servers data collection skeleton

2.3.7 ScopingThis 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.

Server name Blade admin server Blade slot


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


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


3.1 Installation process overviewOur 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.

Table 3-1 Recommended hardware for Windows 2000 Server

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

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.

IBM Compatible Server:

2.4 GHz Intel Pentium® processor or equivalent

2GB RAM

30 GB disk

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™ Workgroup Unlimited Edition V8.1.2

IBM DB2 Universal Database V8.1.2 Client

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


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

Figure 3-1 ITITO installation overview

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

TIOdbsrv TIOsrv

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

Phase 1

TIODatabase

Server

Install all the prerequisite packages for SSH communication between Servers (CygWin for Windows, openssh for AIX) on both ServersConfigure SSH and generate a RSA key on the TIO ServerConfigure SSH on the TIO database ServerCopy the RSA key to the TIO database ServerTest SSH communication from the TIO Server to the TIO database Server

Repeat the process for all servers in the Data Center to be managed by IBM Tivoli Intelligent ThinkDynamic Orchestrator

Phase 2

Install the remaining prerequisite packagesInstall IBM DB2 Universal Database Workgroup Unlimited Edition V8.1.2Create the database to be used by IBM Tivoli Intelligent ThinkDynamic OrchestratorPopulate the database using the provided tablesapce.sql fileInstall IBM Directory Server, V5.1Create the LDAP database and configure IBM Directory Server, V5.1 with the provided suffixes and ldap.ldif fileVerify the installation

Phase 3

Define the User IDs

Prepare SSH communications

Prepare the TIO database Server

Phase 4 Prepare the TIO Server

TIO Server

TIODatabase

Server

SSH

TIODatabase

Server

Central DataWarehouseTIO DB

Data sourceLDAP DB

Install the remaining prerequisite packagesInstall IBM DB2 Universal Database V8.12 ClientInstall IBM Directory Server V5.1 ClientInstall IBM Websphere Application Server Base Edition V5.0Install IBM Websphere Application Server Base Edition V5.0 Fixpack 1Apply the MQ CSD03 patch to IBM Websphere Apply the MQ fixes for embedded messaging to IBM WebSphere (IY43610 and IY44803)Install IBM Websphere Application Server Base Edition V5.0 ClientInstall IBM Tivoli Intelligent ThinkDynamic Orchestrator V1.1.0Verify the installation

TIO Server

SSH

TIODatabase

Server

TIO ServerCentral Data

WarehouseTIO DB

Data sourceLDAP DB

Chapter 3. Installing the demonstration systems 27

3.1.1 Recommended installation directoriesThe 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

3.1.2 User IDs and passwordsThe 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

Product Installation Directory

Cygwin Version 1.3.22 c:\cygwin

IBM DB2 Universal Database Workgroup Unlimited Edition V8.1.2

c:\IBM\sqllib

IBM Directory Server, V5.1 c:\IBM\ldap

IBM DB2 Universal Database V8.12 Client c:\IBM\sqllib

IBM Directory Server V5.1 Client c:\IBM\ldap


c:\IBM\WebSphere\AppServer

IBM WebSphere Application Server Base Edition V5.0.1 Client

c:\IBM\WebSphere\AppClient

IBM Tivoli Intelligent ThinkDynamic Orchestrator V1.1.0

c:\cygwin\home\thinkcontrol

User name Password Description Comment

tioadmin <user defined> Used to log onto the OS to install IBM Tivoli Intelligent ThinkDynamic Orchestrator

This user ID must be created manually on both servers prior to the installation


tioldap <user defined> Used by IBM Tivoli Intelligent ThinkDynamic Orchestrator to connect to the Directory Server

This user ID must be created manually on the machine hosting the IBM Directory Server prior to the installation

tiodb <user defined> This user ID will be the instance owner of the IBM Tivoli Intelligent ThinkDynamic Orchestrator database

Created during the IBM DB2 installation on the server hosting the IBM Tivoli Intelligent ThinkDynamic Orchestrator database

mqm <user defined> Used by WebSphere MQ

This user ID must be created manually on both servers prior to the installation

wasadmin wasadmin Used by WebSphere as administration account

Defined automatically by the WebSphere installation process

tioappadmin tioappadmin This is the IBM Tivoli Intelligent ThinkDynamic Orchestrator superadmin and is used to log into the Web console

Defined on the Directory Server automatically by the IBM Tivoli Intelligent ThinkDynamic Orchestrator installation process

tiointernal internal Used by IBM Tivoli Intelligent ThinkDynamic Orchestrator for system initiated actions

Defined on the Directory Server automatically by the IBM Tivoli Intelligent ThinkDynamic Orchestrator installation process

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

Created during the IBM Directory installation process

User name Password Description Comment


3.2 Installing and configuring TIOdbsrv - WindowsIn 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.

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 IDsCreate 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:\Cygwin\home\thinkcontrol

4. Select the user ID tioldap and set its Local Path to: C:\IBM\ldap

Create tioldap user id

Download and install Cygwin

Install and configure DB2

Install and configure IBM Directory Server

Create tioadmin user id


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.

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.

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.


http://www.cygwin.com


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

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

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 -yGenerating /etc/ssh_host_keyGenerating /etc/ssh_host_rsa_keyGenerating /etc/ssh_host_dsa_keyGenerating /etc/ssh_config filePrivilege 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 fileAdded ssh to /cygdrive/c/WINNT/system32/drivers/etc/servicesAdded ssh to /etc/inetd.confDo you want to install sshd as service?Which value should the environment variable CYGWIN have whensshd starts? It's recommended to set at least "ntsec" to beable to change user context without password.Default is "binmode ntsec tty". CYGWIN=The service has been installed under LocalSystem account.

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

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


Host configuration finished. Have fun!

2. Export the CYGWIN variable.

$ export CYGWIN=ntsec

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

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


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@localhostWarning: Permanently added 'localhost' (RSA) to the list of known hosts.Fanfare!!!You are successfully logged in to this server!!!$ exitlogoutConnection to localhost closed.

3.2.4 Installing and configuring IBM DB2 UDB V8.1.2 on WindowsThis 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.

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

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


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

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:\IBM\SQLLIB\BIN>d: <-- This is the CDROM driveD:\>cd \db2\licenseD:>db2licm -a ./db2wsue.licDBI1402I 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:\IBM\SQLLIB\license\en"

19.Reboot the system

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

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 directoryC:\IBM\SQLLIB\BIN>db2 create database ITITODBDB20000I The CREATE DATABASE command completed successfully.C:\IBM\SQLLIB\BIN>db2 list database directorySystem Database DirectoryNumber of entries in the directory = 2Database 1 entry:

Database alias = ITITODBDatabase name = ITITODBDatabase drive = C:\DB2Database release level = a.00Comment =

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


Directory entry type = IndirectCatalog database partition number = 0

Database 2 entry:Database alias = TOOLSDBDatabase name = TOOLSDBDatabase drive = C:\DB2Database release level = a.00Comment =Directory entry type = IndirectCatalog database partition number = 0C:\IBM\SQLLIB\BIN>

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:\IBM\SQLLIB\BIN).

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.sqlC:\IBM\SQLLIB\BIN>db2 connect to ITITODB user tiodbEnter current password for tiodb:Database Connection InformationDatabase server = DB2/NT 8.1.2SQL authorization ID = TIODBLocal database alias = ITITODBC:\IBM\SQLLIB\BIN>db2 -tvf tablespace.sqlCREATE BUFFERPOOL IBM16K SIZE 250 PAGESIZE 16K NOT EXTENDED STORAGEDB20000I The SQL command completed successfully.CREATE BUFFERPOOL IBM8K SIZE 250 PAGESIZE 8K NOT EXTENDED STORAGEDB20000I The SQL command completed successfully.CREATE REGULAR TABLESPACE IBM8KSPACE PAGESIZE 8K MANAGED BY SYSTEM USING('IBM8KSPACE') BUFFERPOOL IBM8K DROPPED TABLE RECOVERY OFFDB20000I The SQL command completed successfully.CREATE REGULAR TABLESPACE IBM16KSPACE PAGESIZE 16K MANAGED BY SYSTEM USING ('IBM16KSPACE') BUFFERPOOL IBM16K DROPPED TABLE RECOVERY OFFDB20000I The SQL command completed successfully.CREATE TEMPORARY TABLESPACE IBM8KTEMPSPACE PAGESIZE 8K MANAGED BY SYSTEM USING ('IBM8KTEMPSPACE') BUFFERPOOL IBM8K DROPPED TABLE RECOVERY OFFDB20000I The SQL command completed successfully.CREATE TEMPORARY TABLESPACE IBM16KTEMPSPACE PAGESIZE 16K MANAGED BY SYSTEM USING ('IBM16KTEMPSPACE') BUFFERPOOL IBM16K DROPPED TABLE RECOVERY OFFDB20000I The SQL command completed successfully.C:\IBM\SQLLIB\BIN>


3.2.5 Installing and configuring IBM Directory Server V5.1In 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.

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:\IBM\LDAP.

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

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.


– GSKit

Figure 3-5 Select IBM Directory Server components

12.At the Start copying files window you have the chance to review the 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:\IBM\LDAP).

16.Reboot the system.

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.


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:

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.

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


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:\IBM\LDAP\libback-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:\IBM\ldap\Appsrv\bin\startserver 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:\IBM\ldap\bin\ibmslapd

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 - WindowsIn 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.

Figure 3-9 TIOsrv installation steps

Create tioadmin User ID

Download and install Cygwin

Configure SSH

Install and configure DB2 Client

Install and configure IBM Directory Client

Apply IBM WebSphere FixPak 1 and required fixes

Install and configure IBM WerbSphere Client

Install and configure IBM Tivoli Intelligent ThinkDynamic Orchestrator

Install and configure IBM WerbSphere Server


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

3.3.1 Creating the required user IDsCreate 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:\Cygwin\home\thinkcontrol

3.3.2 Installing and configuring CygwinInstructions 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 communicationsThe 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:

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.

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


$ cd /usr/bin$ ./ssh-host-config -yGenerating /etc/ssh_host_keyGenerating /etc/ssh_host_rsa_keyGenerating /etc/ssh_host_dsa_keyGenerating /etc/ssh_config filePrivilege 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 fileAdded ssh to /cygdrive/c/WINNT/system32/drivers/etc/servicesAdded ssh to /etc/inetd.confDo you want to install sshd as service?Which value should the environment variable CYGWIN have whensshd starts? It's recommended to set at least "ntsec" to beable 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

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:\cygwin\home\thinkcontrol\.ssh directory on the IBM Tivoli Intelligent ThinkDynamic Orchestrator server machine (TIOsrv). The keys are located in the c:\cygwin\home\thinkcontrol\.ssh directory and are the following:

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


� id_rsa� 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:


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@tio12Warning: Permanently added 'tio12,9.3.187.163' (RSA) to the list of known hosts.Fanfare!!!You are successfully logged in to this server!!!$ exitlogoutConnection to tio12 closed.

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

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.

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.

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


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.



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:\IBM\SQLLIB.

Figure 3-10 DB2 Client install options

8. Choose Language of choice - English is default.


9. At the Configure NetBios screen, click Next.

10.At the Start copying files window you have the chance to review the 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 50000db2 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 tiodbC:\IBM\SQLLIB\BIN>db2 catalog tcpip node tio11 remote tio12 server 50000DB20000I The CATALOG TCPIP NODE command completed successfully.DB21056W Directory changes may not be effective until the directory cache is refreshed.C:\IBM\SQLLIB\BIN>db2 catalog db ITITODB as ITITODB at node tio11DB20000I The CATALOG DATABASE command completed successfully.DB21056W Directory changes may not be effective until the directory cache is refreshed.C:\IBM\SQLLIB\BIN>db2 connect to ITITODB user tiodbEnter current password for tiodb: Database Connection Information Database server = DB2/NT 8.1.2 SQL authorization ID = TIODB Local database alias = ITITODBC:\IBM\SQLLIB\BIN>

3.3.5 Installing and configuring IBM Directory V5.1 ClientIn 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:\IBM\LDAP.

8. Choose a language of choice for the IBM Directory Client. English is set to default.


10.The Select features window opens, as shown below. Select the following packages:

– Client SDK


Figure 3-11 LDAP Client install options

11.At the Start copying files window you have the chance to review the 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.0In 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.

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: tio11Host 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

WebSphere installation directories

Product Installation Directory


c:\IBM\WebSphere\AppServer

IBM Embedded Messaging Server and Client c:\IBM\WebSphere\MQ

IBM HTTP Server c:\IBM\HTTPServer


11.At the Start copying files window you have the chance to review the 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 fixesIn 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 1After installing IBM WebSphere Application Server Base Edition V5.0 you must install the fixpack 1, which is shipped with IBM Tivoli Intelligent ThinkDynamic Orchestrator.

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 \IBM\WebSphere\AppServer\binsetupCmdLine.bat

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

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.


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

updateWizard.bat

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.

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


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

Figure 3-15 IBM WebSphere Fix Pack 1 installation completed

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

Here we provide the steps for installing the MQ CSD 03 fix.

1. Still logged on as tioadmin, ensure that the IBM WebSphere Application Server is stopped.

2. Start the fixpack install process by opening a DOS prompt window and moving to the \patches\Csd03 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.

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.


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:\IBM\WebSphere\AppServer\bin>mqverName: WebSphere MQVersion: 530.3 CSD03CMVC level: p530-CSD03JBuildType: IKAP - (Production)

Apply the IY43610 fixThe IY43610 fix is located in the /patches/I_43610 directory in the IBM Tivoli Intelligent ThinkDynamic Orchestrator CD.

Here we provide the steps for installing the IY43610 fix.

1. Still logged on as tioadmin, ensure that the IBM WebSphere Application 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:\IBM\WebSphere\MQ. Take a backup copy of the existing files:

– imqb23vn.dll– imqc23vn.dll– imqs23vn.dll– imqb23in.dll

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.


– imqc23in.dll– imqs23in.dll

3. Start the fixpack install process by opening a DOS prompt window and moving to the \patches\I_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 fixThe IY44803 fix is located in the /patches/I_44803 directory in the IBM Tivoli Intelligent ThinkDynamic Orchestrator CD.

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:\IBM\WebSphere\MQ.

3. Take a backup copy of following directories under the WebSphere MQ installation directory:

java\binjava\lib

4. Create the following directories:

toolstools\javadoc

5. Start the fixpack install process by opening a DOS prompt window and moving to the \patches\I_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

Note: When installing the IY44803 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.


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:\IBM\WebSphere\MQ\java\bin– Copy all the files under \lib to C:\IBM\WebSphere\MQ\java\lib– Copy the one file under \doc to C:\IBM\WebSphere\MQ\doc– Copy the content under \samples to C:\IBM\WebSphere MQ\tools\java

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

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 \IBM\WebSphere\AppServer\binsetupCmdLine.bat

3. Move to the <WebSphere install directory> directory and create a directory named update. In our case the installation directory is c:\IBM\WebSphere.

cd \IBM\WebSphere\AppServermkdir update

4. Copy the apar_PQ75055.zip file from the \patches\WAS_PQ75055 directory on the IBM Tivoli Intelligent ThinkDynamic Orchestrator CD to the update directory.

5. Copy the WindowsUpdateInstaller.zip file from the \patches\WAS_PQ75055\UpdateInstaller\win 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:

Note: When installing the PQ75055 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.


updateWizard.bat

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.

Figure 3-17 PQ75055 installation directory

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

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

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


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.1In this section we describe the IBM WebSphere Application Client V5.0.1

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

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



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:\IBM\WebSphere\AppClient

Make sure there are no spaces in the installation path.

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

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:\IBM\WebSphere\AppServer, then the WebSphere Application Client should be installed in C:\IBM\WebSphere\Appclient.


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

10.At the Start copying files window you have the chance to review the installation options. Click Next to initiate the installation.

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.

15.Move to the <WebSphere Client Install Directory>\java\jre\lib\security 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.ConfigFilelogin.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 providerlogin.configuration.provider=com.ibm.security.auth.login.ConfigFile# Default login configuration filelogin.config.url.1=file:/C:/IBM/WebSPhere/AppClient/properties/wsjaas_client.conf

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 sizePerform the following steps to change the default transaction log size:

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

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


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:\IBM\WebSphere\AppServer/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 OrchestratorThis section provides instructions on installing IBM Tivoli Intelligent ThinkDynamic Orchestrator on the TIOsrv machine running Windows 2000 Server.


� 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.

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:\cygwin\home\thinkcontrol\bin

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.

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

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


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 installation options. Click Next to initiate the installation.


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


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


4.1 ToolsThe 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 NotepadThese 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 CooktopThis 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.


http://www.xmlcooktop.com

� 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 XMLSpyXMLSpy 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.


http://www.altova.com

� 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 modelThis section describes the data center modeling process.

4.2.1 ITITO GUI methodIf 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:\cygwin\home\thinkcontrol\tools.


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:

tools\reinit.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 Provisioning On Demand: Introducing IBM Tivoli Intelligent ThinkDynamic Orchestrator, SG24-8888.

4.2.2 The XML methodThe 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 elementWithin 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"

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" filter="low-pass-filter"></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 suppliesIf 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 componentsThe network components in ITITO consist of the following elements:

� Switch fabric� Subnetworks� Switches� Routers and firewalls� Load balancers (variety of switch)� Access control lists (ACLs)

Switch fabricThe 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>


SubnetworksEach 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>

SwitchesEvery 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 vlan="101" port-number="2"





layer1-interface-type="FastEthernet"></switch-port>


<switch-port vlan="101" port-number="7" layer1-interface-type="FastEthernet">

</switch-port><switch-port vlan="101" port-number="11"






layer1-interface-type="FastEthernet"></switch-port>

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

</switch>

Routers and firewallsIn 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 subnetwork="192.168.3.0" gateway="192.168.1.254"></route><acl-ref type="1" name="ACL-1" enabled="true"></acl-ref>

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.


</network-interface><network-interface name="TIO" ipaddress="192.168.192.254"

managed="false"><route subnetwork="192.168.1.0" gateway="192.168.192.254"></route><acl-ref type="1" name="ACL-2" enabled="true"></acl-ref>

</network-interface><firewall/><power-outlet power-unit="Power Unit 1" outlet-number="2"></power-outlet>

</switch>

Access control lists (ACLs)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 balancersLoad 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 IPsEach 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 SoftwareThe 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 packageSoftware packages are defined with the software element type, for example:

<software name="Windows 2000" version="2000" package_path="d:\repository\Win2000" type="OPERATING_SYSTEM" install_path="c:\winnt">

</software>

Software patchAny 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 stackFinally, 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 poolsEach 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.


<spare-pool name="Intel Pool" os-type="" vlan="101" fabric="Customer Network">

<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"/></network-interface>

</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" fabric="Customer Network">

<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 configurationThere 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.

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!


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

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><property component="APPLICATION_CONTROLLER"

name="predictor-type.1.class" value="com.thinkdynamics.kanaha.controller.appcontroller.predictor.DefaultPredictor">


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


name="predictor-type.1.enable" value="true"></property><property component="APPLICATION_CONTROLLER"

name="predictor-type.2.class"value="com.thinkdynamics.kanaha.controller.appcontroller.predictor.LinearTrendPredictor">


name="predictor-type.2.enable" value="false"></property><property component="APPLICATION_CONTROLLER"

name="predictor-type.3.class"value="com.thinkdynamics.kanaha.controller.appcontroller.predictor.OneDayPredictor">


name="predictor-type.3.enable" value="false"></property><property component="APPLICATION_CONTROLLER"

name="predictor-type.4.class"value="com.thinkdynamics.kanaha.controller.appcontroller.predictor.OneWeekPredictor">


name="predictor-type.4.enable" value="false"></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 CustomersEach 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 filesIncluded 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 DCMThe 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 exampleFull 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 modelThe XML data center model must be placed in the \cygwin\home\thinkcontrol\xml 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 \cygwin\home\thinkcontrol\tools.

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 home\thinkcontrol.

5. Run the command tools\reinit.bat.

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%\logs\reinit.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.

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


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 editorsIf 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 simulatorThe 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 fileThe 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 elementThe 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 elementThe 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 elementFinally, 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)

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!

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.


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.

Workload

0

200

400

600

800

1000

1200

6:00

8:00

10:00

12:00

14:00

16:00

18:00

20:00

22:00

Time

Wor

kloa

d % Office workload

Internet workload


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

Table 4-2 Simulator functions for the sample Office workload

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

StepFunction 12000 20

RampFunction 6000 20


RampFunction -1 6000 100






Function Slope Duration Initial value Amplitude








RampFunction 6000





Calculating the number of systemsKnowing 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 servers4.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 = 100000Initial_value= 23% cpuDuration= 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 transactionsslope = 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

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><simulation-parameters name="response-time" scale="1.0" constant="77.0"

max="100"></simulation-parameters>

</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

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.

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"

init_value="100" amplitude="50"></function><function function_type="StepFunction" duration="12000" amplitude="50"></function><function function_type="RampFunction" slope="1" duration="6000"

init_value="50" amplitude="100"></function><function function_type="StepFunction" duration="12000"


init_value="100" amplitude="20"></function><function function_type="StepFunction" duration="30000" amplitude="0"/>

</app_function><app_function app_name="Internet Sales" max_amplitude="1000000">

<function function_type="StepFunction" duration="18000" amplitude="75"></function><function function_type="RampFunction" slope="-1" duration="60000"

init_value="75" amplitude=""></function><function function_type="StepFunction" duration="60000" amplitude="25"></function><function function_type="RampFunction" slope="2" duration="60000"

init_value="25" amplitude=""></function><function function_type="StepFunction" duration="12000"


init_value="100"></function><function function_type="StepFunction" duration="12000" amplitude="0"></function><function function_type="RampFunction" slope="3" duration="6000"

init_value="0" amplitude="">

</function><function function_type="StepFunction" duration="12000"


init_value="100" amplitude=""></function><function function_type="StepFunction" duration="12000" amplitude="75"></function>

</app_function></application_traffic_functions></simulator></td_network>

Simulating multiple workloadsWhen 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=1000App2 real_scale=0.01 idle_load=0.05 real_max_amplitude=10000App3 real_scale=0.02 idle_load=0.03 real_max_amplitude=500

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 TestingBefore 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.


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


5.1 Introduction to ITITO and the scenarioYou 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 overviewThe 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 resourcesWhen 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 resourcesSelect 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 poolsSelect 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 applicationsShow 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 monitoringAs 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.


Appendix A. Additional material

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

Locating the Web materialThe 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 materialThe additional Web material that accompanies this Redpaper includes the following files:

File name DescriptionREDP3830.zip Data center model and workload simulation used during

the project.

A


ftp://www.redbooks.ibm.com/redbooks/

System requirements for downloading the Web materialThe following system configuration is recommended:

Hard disk space: 1 MB minimumOperating System: Microsoft WindowsProcessor: anyMemory: any

How to use the Web materialCreate 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 RedbooksFor 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.

� Provisioning On Demand: Introducing IBM Tivoli Intelligent ThinkDynamic 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 manualsThese 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 resourcesThese Web sites and URLs are also relevant as further information sources:

� IBM Tivoli Intelligent ThinkDynamic Orchestrator Product Web pagehttp://www.ibm.com/software/tivoli/products/intell-orch/

� IBM Tivoli Provisioning Manager Product Web pagehttp://www.ibm.com/software/tivoli/products/prov-mgr/

� Cwgwinhttp://www.cygwin.com/

� WebSphere Application Server manualshttp://www.ibm.com/software/webservers/appserv/was/library/

� IBM DB2 manualshttp://www.ibm.com/software/data/db2/library/

� Software Supporthttp://www.ibm.com/software/support

� IBM Web infrastructure orchestrationhttp://www.ibm.com/software/tivoli/features/web-svr-prov/solution.html

� IBM Application Framework for e-businesshttp://www.research.ibm.com/journal/sj/401/flurry.html

How to get IBM RedbooksYou 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







http://www.research.ibm.com/journal/sj/401/flurry.html

http://www.ibm.com/software/tivoli/features/web-svr-prov/solution.html

http://www.ibm.com/software/webservers/appserv/was/library/

http://www.ibm.com/software/data/db2/library/

http://www.ibm.com/software/support


Help from IBMIBM Support and downloads:

ibm.com/support

IBM Global Services:

ibm.com/services

Related publications 123

http://www.ibm.com/support/

http://www.ibm.com/support/

http://www.ibm.com/services/

http://www.ibm.com/services/

®

REDP-3830-00

INTERNATIONAL TECHNICALSUPPORTORGANIZATION

BUILDING TECHNICALINFORMATION BASED ONPRACTICAL EXPERIENCE

IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and 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

Redpaper

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

Installation and customization

Data center modeling

Workload simulation

This IBM Redpaper provides advice for Business Partners about how to plan for, implement, and demonstrate IBM Tivoli Intelligent ThinkDynamic Orchestrator Version 1.1.0 and IBM Tivoli Provisioning Manager Version 1.1.0 in a pre-proof-of-concept simulated environment.

This environment can be used to demonstrate the capabilities of the IBM Tivoli orchestration and provisioning solutions using customer data, in order to gain customer acceptance for the next phase of the sell cycle — to engage the Business Partner in a real proof-of-concept of IBM Tivoli Intelligent ThinkDynamic Orchestrator or IBM Tivoli Intelligent Provisioning Manager.

Back cover




ibm tivoli intelligent think dynamic orchestrator pre proof of-concept cookbook for business...

Technology

ibm product

copyright ibm

ibm directory v5

ibm websphere fixpack

ibm directory server

ibm db2 udb v8

concept cookbook

ibm db2 universal database