IBM Tivoli Intelligent Think Dynamic Orchestra Tor Pre Proof-Of-Concept Cookbook For Business Partners Redp3830

Front cover
IBM Tivoli Intelligent ThinkDynamic Orchestrator

Pre Proof-of-Concept Cookbook for Business Partners
Installation and customization
Data center modeling
Workload simulation
Edson Manoel Tony French
ibm.com/redbooks
Redpaper
International Technical Support Organization IBM Tivoli Intelligent ThinkDynamic Orchestrator Pre Proof-of-Concept Cookbook for Business Partners February 2004
Note: Before using this information and the product it supports, read the information in Notices on page vii.
First Edition (February 2004) This edition applies to IBM Tivoli Intelligent ThinkDynamic Orchestrator Version 1.1.0 and IBM Tivoli Provisioning Manager Version 1.1.0.
Copyright International Business Machines Corporation 2004. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Recommended reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x The team that wrote this Redpaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Chapter 2. Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 General questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 ITITO components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1 Power units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2 Network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.4 Spare pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.5 Applications and customers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.6 Other devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3.7 Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Chapter 3. Installing the demonstration systems . . . . . . . . . . . . . . . . . . . 25 3.1 Installation process overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.1 Recommended installation directories . . . . . . . . . . . . . . . . . . . . . . . 28 3.1.2 User IDs and passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.2 Installing and configuring TIOdbsrv - Windows . . . . . . . . . . . . . . . . . . . . . 30 3.2.1 Creating the required user IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.2.2 Installing and configuring Cygwin . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2.3 Configuring SSH communications . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2.4 Installing and configuring IBM DB2 UDB V8.1.2 on Windows . . . . . 34 3.2.5 Installing and configuring IBM Directory Server V5.1 . . . . . . . . . . . . 39 3.3 Installing and configuring TIOsrv - Windows . . . . . . . . . . . . . . . . . . . . . . . 45 3.3.1 Creating the required user IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.3.2 Installing and configuring Cygwin . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.3.3 Configuring SSH communications . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.3.4 Installing IBM DB2 Universal Database V8.1.2 Client. . . . . . . . . . . . 48 3.3.5 Installing and configuring IBM Directory V5.1 Client . . . . . . . . . . . . . 50
Copyright IBM Corp. 2004. All rights reserved.
iii
3.3.6 Installing IBM WebSphere Application Server Base V5.0. . . . . . . . . 52 3.3.7 Install the IBM WebSphere fixpack 1 and required fixes. . . . . . . . . . 55 3.3.8 Installing IBM Tivoli Intelligent ThinkDynamic Orchestrator . . . . . . . 67 Chapter 4. Creating the demonstration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.1.1 WordPad or Notepad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.1.2 Cooktop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.1.3 XMLSpy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.2 Designing the data center model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.2.1 ITITO GUI method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.2.2 The XML method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.2.3 DOCTYPE element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.2.4 Power supplies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.2.5 Network components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.2.6 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.2.7 Spare pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.2.8 ITITO configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4.2.9 Customers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 4.3 Sample XML files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.3.1 Cookbook example DCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.3.2 Redbook example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 4.4 Loading the data center model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 4.4.1 Tip for creating XML files using text editors . . . . . . . . . . . . . . . . . . . 94 4.5 Configuring the simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 4.5.1 Data center model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 4.5.2 The tdnetworks file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 4.6 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Chapter 5. Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.1 Introduction to ITITO and the scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 108 5.1.1 ITITO: A quick overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 5.2 Data center assets and resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.2.1 Show the switch fabric and inventory resources . . . . . . . . . . . . . . . 110 5.2.2 Show the customer the resource pools. . . . . . . . . . . . . . . . . . . . . . 111 5.3 Customer applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 5.4 Real-time performance monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Appendix A. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 System requirements for downloading the Web material . . . . . . . . . . . . . 120 How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
iv
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Product manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Contents
vi
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.
vii
Trademarks
The 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
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.
ix
Recommended reading
The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this Redpaper.
Product manuals:
IBM Tivoli Intelligent Orchestrator and Tivoli Provisioning Manager Release Notes, SC32-1422 IBM Tivoli Intelligent Orchestrator and Tivoli Provisioning Manager Operators Guide, SC32-1421 IBM Tivoli Intelligent Orchestrator and Tivoli Provisioning Manager Installation Guide, SC32-1420 IBM Tivoli Provisioning Manager and Intelligent Orchestrator Overview Guide, SC32-1419
Online resources:
IBM Tivoli Intelligent ThinkDynamic Orchestrator Product Web page:
http://www.ibm.com/software/tivoli/products/intell-orch/
IBM Tivoli Provisioning Manager Product Web page:

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

http://www.redbooks.ibm.com/redbooks/pdfs/sg247003.pdf
The team that wrote this Redpaper

This Redpaper was produced by a team of specialists from around the world working at the International Technical Support Organization, Austin Center. Edson Manoel is a Software Engineer at IBM Corporation, International Technical Support Organization, Austin Center, working as an IT Specialist in the Systems Management area. Prior to joining the ITSO, Edson worked in the IBM Software Group as a Tivoli Technology Ambassador and within IBM Brazil Professional Services Organization as a Certified IT Specialist. He was involved in numerous projects, such as designing and implementing systems
management solutions for IBM customers and Business Partners. Edson holds a bachelors 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 Sara C. Brumfield Theo Winkelmann Leonard Hand ITSO Austin Center ITITO Level 2 Support, IBM Software Group On Demand Sales Enablement, IBM Software Group Senior Consulting I/T Architect, IBM Global eBusiness Solution Center
Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll team with IBM technical professionals, Business Partners and/or customers. Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability. Find out more about the residency program, browse the residency index, and apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us! We want our papers to be as helpful as possible. Send us your comments about this Redpaper or other Redbooks in one of the following ways: Use the online Contact us review redbook form found at:
ibm.com/redbooks
Preface
xi
Send your comments in an Internet note to:

redbook@us.ibm.com
Mail your comments to: IBM Corporation, International Technical Support Organization Dept. JN9B Building 003 Internal Zip 2834 11400 Burnet Road Austin, Texas 78758-3493
xii
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 customers technical specialists to determine which of the customers 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.
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
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 customers 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 customers requirements. This chapter contains some guidelines to help in this area.
2.1 Interviews
To demonstrate to a customer how ITITO can be used in their environments, it is necessary to conduct a number of interviews with various specialists. Building an ITITO data center model can require a detailed level of information including, for example, MAC addresses and information about which ports on the network switch to which each network interface card (NIC) connects. For the purposes of a demonstration, however, it is not strictly necessary to gather the finest detail, but it may be advisable so that any subsequent Proof of Concepts (POC) project has a head start. The initial interviews should determine if the customer has any applications that are suitable for automating with ITITO and selecting a number that can be used to build the demonstration system. We recommend that at least two applications, but no more than four, be selected to build the demonstration.
2.2 General questions

During the initial interview with the customer, these questions may be useful to gain an overview of the customers environment and operating practices: 1. Does the customer have any applications that use clusters of similar servers to provide a service? Tip: If the customer has mainly mainframe-based computing and is not planning to change to a distributed architecture, they are not an ideal candidate. ITITO fits very well for applications that support horizontal scaling (that is, Web, application servers). 2. Do the servers in these clusters run single applications or many? Tip: If the customer runs more than one application in each server, this application might not be suitable for automation by ITITO. 3. Typically, how many servers make up these clusters? 4. Do these clusters of servers use load balancers or application servers to control the utilization of each server? 5. Does the customer provide sufficient servers to meet peak loads? What is the average utilization of the servers in these application clusters? 6. How does the customer plan for peak loads (for example, year-end accounting, special promotions, or sales)? Does the customer:
Wait for the load to materialize and then take action as above? Build extra servers for each application and incorporate these into the clusters? Do nothing? (Longer response times at peak times are normal!) 7. How does the customer handle peak loads in their applications? Does the customer: Have a number of extra servers dedicated to each application? Reconfigure other application servers? Have a spare pool of servers that can be built to order? 8. When the peak loads subside, does the customer: Return any servers that were added to the application cluster to their previous state? Leave the servers in place for the next peak? 9. If the customer returns servers to their previous state, how long does this typically take? 10.Do the customers applications have peak loads at different times? 11.Could the customer conceivably use servers that are idle for one application in another application that is undergoing a peak load? 12.Does the customer maintain a large number of dedicated test servers for each application, or does the customer use a general pool of test servers? Tip: The more the better: ITITO provides a great starting point in a non-production environment and allows the customer to recover, redeploy, or eliminate redundant servers in the test environment. 13.Typically, what is the utilization of the test server environments? 14.Are the applications written in-house or are they 100% shrink-wrapped from the software vendor (that is, no customization)? Does the customer perform their own development and testing? Tip: ITITO can enhance the management and maintenance of customized or homegrown applications. If the customer has a 100% shrink-wrapped environment and rarely makes changes to their production/staging environments, they are less qualified as a prospective customer. 15.Does the customer operate applications over multiple data centers? 16.Does the customer have control over their network environment, or is it outsourced to a network provider?
Chapter 2. Planning
Tip: If the customers network is totally outsourced, they might not have sufficient access to perform the dynamic reconfiguration that ITITO is capable of providing. 17.What are the customers predominant operating systems (for example, AIX, Solaris, HP/UX, Microsoft Windows, or Linux)? Tip: If the customer uses mainly OS/390 or non UNIX/Intel operating systems, they might be less qualified as a prospect. 18.Does the customer have any blade servers? If so which types/makes (HP, IBM, and so on)? 19.How many and what type of network switches is the customer using (that is, Cisco, Extreme, Foundry, and so on)? Tip: Our application is better suited for Level 3 (network layer) switches, but we can also work with Level 2 (data layer) switches. 20.What level of redundancy is provided for at the network equipment level, if any? 21.What type of network and systems management software is the customer using (OpenView, Tivoli, CA UniCenter, and so on)? Tip: Helps determine the level of sophistication present in the network operations center. 22.What kind of storage infrastructure is in place (that is, Storage Area Network, or SAN, Network Attached Storage, Redundant Array of Independent Disks, or RAID)? 23.What are the customers dominant relational database management systems (Oracle, DB2, Microsoft SQL Server, MySQL, or other)? And, are clustered database solutions being used? 24.What is the application server software, if any (WebSphere, Weblogic, Resin, Jboss, or other)? The ideal outcome of these questions is to locate two to four applications that have the following characteristics: Clustered architecture
A low average utilization with idle servers available for peak demand Or, A pool of spare servers that are provisioned for peak demand Use similar hardware and operating system platforms Operate in a network that the customer has control over Alternatively, if the customer wants to provision application test environments from a pool of common servers rather than maintain separate test environments for each application, ITITO can be a suitable tool for this, too. The following table can be used to collect and summarize the data from these questions:
Table 2-1 Capturing customer planning information skeleton Application # Servers Operating systems # Web servers # Databases Avg. util % # Spare servers
2.3 ITITO components

After a limited number of suitable applications are identified, it is necessary to gather additional technical details in order to build an ITITO data center model. To simplify the data center model building, these components have been broken down into the following categories: Power units Network configuration Software configuration Spare pools Customers, applications, and clusters Other devices The following sections contain tables showing the required attributes that need to be collected for each component type. The shaded cells in these tables are for additional data that is not essential for a demonstration but is necessary for a full ITITO build or Proof of Concept.
Chapter 2. Planning
2.3.1 Power units

For the purposes of a demonstration, power units are optional in ITITO. It is possible to define the power units and to associate devices with these power units. It is also possible to manage the power units through an IP connection. For a demonstration, it will usually only be necessary to collect the names of the units for later reference by other devices:
Table 2-2 Power units data collection skeleton Power unit name Manufacturer Model Device model
Note: The only devices that are supported by Version 1.1 of ITITO are as follows:
Table 2-3 Power units data collection example Manufacturer APC APC 7901 9606 Model Device model APC-7901-SNMP APC-9606-SNMP
Note: It is also possible to define network interface cards (NICs) on a power unit and associate it with a port on a network switch, but it was found that the data center model would not load if this were done. However, it is possible to define the interface from the ITITO GUI.
2.3.2 Network configuration

The ITITO network configuration consists of the following main components: Switch fabric Subnetworks Switches Load balancers Virtual IPs Access control lists (ACLs) Each of the main components is addressed separately. Most devices in ITITO require a number of service access points that define the mechanisms and authentication information (user IDs and passwords) that are used to communicate with the device. For a demonstration, these are not
required. However, if the customer is willing to provide this information, and if the demonstration is likely to lead to a Proof of Concept or implementation, the information can be collected in advance. This is addressed in the last segment of this section.
Switch fabric
The switch fabric is an ITITO concept. For most customers, it will normally only be necessary to define one switch fabric. All that is needed is the name of the fabric. The customers name is recommended to be included here. This name will be used in a number of other components later.
Table 2-4 Switch fabric data collection skeleton Switch fabric name
Subnetworks
Every subnet in use by the applications defined in Section 2.2 on page 4 must be defined to ITITO. In addition, the VLAN that is associated with the subnet must be recorded.
Table 2-5 Subnet data collection skeleton Subnet address Netmask VLAN
It is possible to define a name for each subnetwork, but we recommend that this not be specified so that the name defaults to the subnet address, because this is easier to understand while using the GUI. When ITITO is used to provision servers, it can assign an IP address to a new server from the next available within a subnet. In this way, ITITO acts in a similar way as a DHCP server, although technically, it assigns a permanent address. For subnets where ITITO is permitted to assign addresses, it will usually be necessary to block certain addresses. Otherwise, ITITO will assign a duplicate address. In particular, each subnet will have a gateway address that should be blocked, and any permanent servers on the subnet should also be blocked. A number of ranges can be defined if necessary.
Chapter 2. Planning
Subnet address
Blocked range start
Blocked range end
Switches
Each network switch device that is used by the applications determined in Section 2.2 on page 4 should be recorded here:
Table 2-6 Switch data collection skeleton Switch name Manufacturer Model IP address Switch fabric Device model
Switches often have separate modules containing a number of ports. Every port that connects a device in the ITITO environment must be defined here and will be used later in the device definitions. It is not necessary to define every port on every switch, just the ones to be controlled by ITITO.
Table 2-7 Switch port data collection skeleton Switch name Switch modules Switch port VLAN Port type
The valid types of ports for ITITO Version 1.1 are: Ethernet Fast Ethernet Gigabyte
10
VLAN Unknown It is not essential to define the port types, because this does not affect the demonstration, although the ports will show up as unknown type in the GUI. If any switch is connected to any of the power units identified in 2.3.1, Power units on page 8, the attached power unit should be recorded here:
Table 2-8 Switch/power units data collection Switch name Power unit Power outlet
The following switches are supported by ITITO Version 1.1:

Table 2-9 Switch data collection example Manufacturer Cisco Cisco Cisco Cisco IBM Extreme Foundry Others 6500 6500 3548 2621 Blade Center 4port GB 48i Foundry Switch Dummy Switch Model Device model Cisco 6500 Switches Hybrid Mode Cisco 6500 Switches Native IOS Mode Cisco 3548 Cisco 2621 Blade Center 4p GB Eth Extreme 48i Foundry Switch Dummy Switch
If the customer has other switches than these, it will be necessary to code custom device drivers during any Proof of Concept or implementation. Fortunately, for a demonstration, it is only necessary to use the dummy switch device model for all devices. This allows the switch operations to be simulated during the demonstration.
Routers and firewalls

Routers are defined as switches in ITITO, but they also require network interfaces, route definitions, and access control lists.
Chapter 2. Planning
11
The basic definition table for a router is as follows:

Table 2-10 Router data collection skeleton Router name Manufacturer Model IP address Switch fabric Device model Firewall
Routers will usually have a number of interfaces that control the routing between subnets. The data required for these components is as follows:
Table 2-11 Router interface data collection skeleton Router name Interface name IP address Managed
Each interface can support a number of routes, which need to be specified in the following table:
Table 2-12 Router interface route data collection skeleton Router name Interface name Route Gateway ACL
The following router is a valid device in ITITO Version 1.1:

Table 2-13 Router information data collection example Manufacturer Cisco 2621 Model Cisco 2621 Device model
Access control lists

For each router or firewall that controls traffic between subnetworks, an access control list (ACL) should be defined. These appear on the GUI as a distinctive icon that connects subnetworks. Each ACL can have multiple rules that are unidirectional. Usually at least two rules will be defined, permitting traffic in both directions between a pair of subnets.
12
Table 2-14 Access Control List data collection skeleton ACL name Rule # Target Source subnet Destination subnet
The Target column contains the operational mode of the rule: either permit or deny. Each rule can specify protocols or port ranges to permit or deny, but for the purposes of a demonstration, this should not be necessary.
Load balancers
Load balancers require the following information to enable them to be defined to ITITO:
Table 2-15 Load balancer data collection sample Name Manufacturer Model Type Device model
The following load balancers are valid devices in ITITO Version 1.1:
Table 2-16 Load balancer data collection example Manufacturer Cisco Alteon Model 11000 LoadBalancer Dummy LB Device model Cisco CSS Alteon LoadBalancer Dummy LB Type arrowpoint-load-balancer
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.
Chapter 2. Planning
13
Virtual IPs
Any pre-existing virtual IPs can be defined to ITITO if required, although they will usually take no part in the demonstration. The information required is shown in the following table:
Table 2-17 Virtual IP data collection skeleton Virtual IP name Load balancer Virtual IP address First input port in range Last input port in range Output port
Each application cluster (see 2.3.5, Applications and customers on page 16) that ITITO is to provision automatically will need a unique virtual IP definition for the cluster.
2.3.3 Software
Software configuration in ITITO is divided into three categories: Software package Software patch Software stack We address each of these in the following sections.
Software package
Each single piece of software or data that the customers applications require to be provisioned must be defined to ITITO as a software object. This typically includes operating systems, databases, middleware, applications, data, and so on. For each software package that is to be automatically deployed, it is necessary to collect the following information:
Table 2-18 Software package data collection skeleton Software name Version Type Package path Install path
14
There are two valid entries for type: OPERATING_SYSTEM SOFTWARE For the purposes of the demonstration, package and install paths are optional.
Software patches
Software patches are optional for the demonstration. If any patches or service packs are required by the customer, they need the following basic information for the demonstration:
Table 2-19 Software patch data collection skeleton Patch name Type Package path Install path
As with the software packages, package path and install path are optional for a demonstration.
Software stacks
Software stacks are an ITITO concept to group together a number of software packages and software patches so that the stack represents all of the software that must be installed on each type of server when it is provisioned into an application cluster. Each distinct type of server required by any application cluster needs a corresponding software stack. In addition, if any spare pool has to have an initial set of software defined, the software stack should be defined for this state, too. Typically, this could mean that a base operating system is installed on servers in a spare pool with no applications. Software stacks require the following information:
Table 2-20 Software stack data collection skeleton Software stack name Software product Position
The software stack names must match the software products or patches, or both, defined in the previous sections. The Position column determines the installation order.
Chapter 2. Planning
15
2.3.4 Spare pools

If the customer has pools of spare servers already available for their applications, information about the names, connections, and types of these machines needs to be determined and entered in the following tables. If the customer does not have any existing pools of machines, for the demonstration, a number of servers will need to be defined to create a spare pool. The customer should be advised that this is a fundamental principle behind ITITO. These pools require the following definitions:
Table 2-21 Spare pool network data collection skeleton Spare pool name VLAN Switch fabric
Any number of servers can be defined for each pool with the following attributes:
Table 2-22 Spare pool data collection skeleton
Connected to switch module Network interface card Connected to switch port Server name
Connected to switch
Spare pool name
IP address
For ITITO to operate correctly with pooled servers, we strongly advise that each server has at least two network interface cards (NICs), one of which is dedicated to the management LAN. If any NIC has multiple IP addresses, these should be recorded here, too. MAC addresses are optional for the demonstration, but will show up as unknown in the GUI if not specified.
2.3.5 Applications and customers

In this section, it is necessary to gather information about the various applications that a customer wants to provision with ITITO. The basic data
16
MAC addr.
Managed
required is shown in the following table. For a demonstration, at least two applications should be defined.
Table 2-23 Customer/application data collection skeleton Customer name or business unit Application Priority Application cluster
Each ITITO implementation can have many customers defined, each of which can have multiple applications, each of which can have multiple application clusters. An application cluster is defined to be a set of servers that provide the same service to an application. The servers are expected to be virtual clones of each other. The priority of each application should be set according to the following table:
Table 2-24 Application priority data collection example Service plan Platinum Gold Silver 10 Priority Interpretation Better priority service Medium priority service Poorer priority service
Each application cluster requires the following additional definitions:

Table 2-25 Cluster information data collection skeleton Application cluster Virtual IP Managed
Load balancer
Min. servers
Max. servers
Switch fabric
VLAN
Pool
Chapter 2. Planning
17
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 clusters servers. The Virtual IP column refers to the virtual IPs defined in Virtual IPs on page 14. Note: It is also possible to configure the service level agreement properties: maximum response time and maximum time available. We recommend that you talk about this during the demonstration. If any cluster has any dedicated servers assigned to it (and usually there will be at least one), these must also be defined. The data required for these is shown in the following table:
Table 2-26 Cluster network data collection skeleton Application cluster Connected to switch Connected to switch module Connected to switch port IP address Managed
Network interface card
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.
18
MAC address
Server name
2.3.6 Other devices

ITITO supports a number of other data center management devices including: Boot servers Terminal servers Blade center management servers These devices might be essential for the operation of a data center, but do not really play any part in a demonstration of ITITO. If it is desirable to show the configuration and that the product supports these devices, they should be included.
Boot servers
If any servers are to be provisioned by bare-metal builds, it will be necessary to define a boot server for each set of servers that are configured to use the same boot server. Boot servers require the following information to be defined:
Table 2-27 Boot server data collection skeleton Name Manufacturer Software IP address Device model
Each boot server can also have a network interface card and network interfaces as with other servers in spare pools and clusters:
Table 2-28 Boot server network information collection skeleton Connected to switch Connected to switch module Connected to switch port IP address MAC addr. Managed Device model Rembo Boot Server RDM Server Network interface card
The following boot servers are valid devices in ITITO Version 1.1:
Table 2-29 Boot servers supported by ITITO V1.1 Manufacturer Rembo IBM Software Auto-Deploy Remote Deployment Manager
Boot server name
Chapter 2. Planning
19
IBM IBM IBM Sun HP
Network Installation Manager zVM Boot Server Cluster Systems Management Jump Start Rapid Deployment Pack
NIM Server zVM Boot Server CSM Management Server JumpStart Server RDP Server
If a boot server is used to deploy an operating system, this attribute can be added to the corresponding software stack for the operating system. This is optional for the demonstration.
Table 2-30 Boot server/operating system data collection skeleton Software stack name Boot server
Terminal servers
Terminal servers can be defined to ITITO like boot servers except that there are no supplied device drivers for terminal servers in Version 1.1 of the product:
Table 2-31 Terminal server data collection skeleton Name IP address
Network interface cards and network interfaces can be defined as with other servers:
Table 2-32 Terminal server network information data collection skeleton Connected to switch Connected to switch module Connected to switch port IP address MAC addr. Managed Network interface card Terminal server name
20
Blade center management servers

Each blade system is managed by a central management server that controls all aspects of the blade servers. ITITO uses the blade center management server to perform operations on the blade servers such as reboot, power on, and reconfiguration. If the customer uses blade servers, it might be desirable to show the blade center management server, although the demonstration will make no visible changes to the blade center management server itself. The blade center management server can be defined like the boot server and terminal servers:
Table 2-33 Blade center management server data collection skeleton Name Manufacturer Software IP address Device model
The following blade systems have device drivers in Version 1.1 of ITITO:
Table 2-34 Blade center management servers supported by ITITO V1.1 Manufacturer RLX Technologies HP Blade system ServerBlades Proliant Blade Servers Device model RLX Blade Server Proliant BL Server
Network interface cards and network interfaces can also be defined if required:
Table 2-35 Blade server network information data collection skeleton Connected to Switch Connected to switch module Connected to switch port IP address MAC addr. Managed Network interface card
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:
Blade server name
Chapter 2. Planning
21
Table 2-36 Blade servers data collection skeleton Server name Blade admin server Blade slot
2.3.7 Scoping
This section discusses the process of settling the scope of the demonstration. This should be agreed with the customer prior to beginning work on the development of the demonstration system. The main objective of a customized demonstration is to show the customer what ITITO can do for them in their environment. It will not usually be necessary to show the full extent of their environment, and indeed, could be counter-productive if attempted. From the data gathered, a representative sample of components should be chosen to be used in the demonstration. For example, if a customer has an application that has 100 servers working as a cluster, it is only really necessary to show a few. Also, if a customer has platforms that are not ideal for ITITO such as Tandems or z/OS, it would be better to focus on the ones that are. Ultimately, if two applications can be agreed on with one, two, or three clusters in each and one to five servers for each cluster, the demonstration should be feasible, representative, and worthwhile. Provided with this document and included in the text is an XML file that contains the following: One customer Two applications Two clusters in each application One dedicated server in each cluster One common resource pool One switch One router One load balancer Three software stacks Six software packages This should be sufficient to demonstrate the key features of ITITO and could perhaps be used simply by changing the names of the applications clusters and pools to the customers own names.
22
The files provided with this document are described in 4.3, Sample XML files on page 91.
Chapter 2. Planning
23
24
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.
25
3.1 Installation process overview

Our installation scenario is to be considered as an example only. The following are the names of both servers used during the installation process. These names most likely should be changed to the naming standards of the customer. The server hosting both the IBM DB2 Server and the IBM Directory server will be named TIOdbsrv. The server hosting the IBM Tivoli Intelligent ThinkDynamic Orchestrator server will be named TIOsrv. The following table provides the recommended hardware for each server. This is the hardware we used in the ITSO lab environment and we recommend it as a minimum configuration. Note: The values provided in the following table may differ form the information provided in the IBM Tivoli Intelligent Orchestrator and Tivoli Provisioning Manager Release Notes, SC32-1422. They represent the hardware used at the time of writing this Redpaper and serve as our recommendation for a minimum of a two server configuration.
Table 3-1 Recommended hardware for Windows 2000 Server IBM Compatible Server: 2.4 GHz Intel Pentium processor or equivalent 2GB RAM 30 GB disk
The following table provides a list of the various products that will need to be installed and configured on each server during the installation procedure per operating system. Please note that both servers must be running the same operating system.
Table 3-2 Required software - Windows 2000 TIOdbsrv Windows 2000 Server Cygwin Version 1.3.22 or later IBM DB2 Universal Database Workgroup Unlimited Edition V8.1.2 IBM Directory Server, V5.1 TIOsrv Windows 2000 Server Cygwin Version 1.3.22 or later IBM DB2 Universal Database V8.1.2 Client IBM Directory Server V5.1 Client
26
TIOdbsrv
TIOsrv IBM WebSphere Application Server Base Edition V5.0.1 IBM WebSphere Application Server Base Edition V5.0.1 Client IBM Tivoli Intelligent ThinkDynamic Orchestrator V1.1.0
The following picture provides an overview of the entire installation process and can be used as reference during the installation.
Phase 1
Define the User IDs
Define user tioadmin user ID with Administrator / root authority on both servers Define user tioldap user ID with Administrator / root authority on both servers UNIX only: define the mqm user ID in the mqm group. Also create mqbrkrs group and ensure that tioadmin, root and mqm users IDs belongs to it.
TIO Database Server
TIO Server
Phase 2
Prepare SSH communications

SSH TIO Server TIO Database Server
Install all the prerequisite packages for SSH communication between Servers (CygWin for Windows, openssh for AIX) on both Servers Configure SSH and generate a RSA key on the TIO Server Configure SSH on the TIO database Server Copy the RSA key to the TIO database Server Test 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 3
Prepare the TIO database Server

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

Data source LDAP DB
Install the remaining prerequisite packages Install IBM DB2 Universal Database V8.12 Client Install IBM Directory Server V5.1 Client Install IBM Websphere Application Server Base Edition V5.0 Install IBM Websphere Application Server Base Edition V5.0 Fixpack 1 Apply 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 Client Install IBM Tivoli Intelligent ThinkDynamic Orchestrator V1.1.0 Verify the installation
Central Data Warehouse TIO DB
TIO Database Server
TIO Server
Figure 3-1 ITITO installation overview
Chapter 3. Installing the demonstration systems
27
3.1.1 Recommended installation directories

The following table provides a list of recommended installation directories for each product used during the installation process. Note that file paths containing spaces must not be used, as it will cause problems during the installation and configuration process.
Table 3-3 Recommended installation directories Product Cygwin Version 1.3.22 IBM DB2 Universal Database Workgroup Unlimited Edition V8.1.2 IBM Directory Server, V5.1 IBM DB2 Universal Database V8.12 Client IBM Directory Server V5.1 Client 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 Installation Directory c:\cygwin c:\IBM\sqllib c:\IBM\ldap c:\IBM\sqllib c:\IBM\ldap c:\IBM\WebSphere\AppServer c:\IBM\WebSphere\AppClient c:\cygwin\home\thinkcontrol
3.1.2 User IDs and passwords

The following table illustrates the user IDs that will be either created during the application install process or created by you, the implementer, before the actual install process begins.
Table 3-4 User IDs and passwords User name tioadmin Password <user defined> Description Used to log onto the OS to install IBM Tivoli Intelligent ThinkDynamic Orchestrator Comment This user ID must be created manually on both servers prior to the installation
28
User name tioldap
Password <user defined>
Description Used by IBM Tivoli Intelligent ThinkDynamic Orchestrator to connect to the Directory Server This user ID will be the instance owner of the IBM Tivoli Intelligent ThinkDynamic Orchestrator database
Comment This user ID must be created manually on the machine hosting the IBM Directory Server prior to the installation Created during the IBM DB2 installation on the server hosting the IBM Tivoli Intelligent ThinkDynamic Orchestrator database This user ID must be created manually on both servers prior to the installation Defined automatically by the WebSphere installation process Defined on the Directory Server automatically by the IBM Tivoli Intelligent ThinkDynamic Orchestrator installation process Defined on the Directory Server automatically by the IBM Tivoli Intelligent ThinkDynamic Orchestrator installation process Created during the IBM Directory installation process
tiodb
<user defined>
mqm
<user defined>
Used by WebSphere MQ
wasadmin
wasadmin
Used by WebSphere as administration account
tioappadmin
tioappadmin
This is the IBM Tivoli Intelligent ThinkDynamic Orchestrator superadmin and is used to log into the Web console Used by IBM Tivoli Intelligent ThinkDynamic Orchestrator for system initiated actions
tiointernal
internal
cn=root
<user defined>
root user ID for the IBM Directory LDAP Server
29
3.2 Installing and configuring TIOdbsrv - Windows

In this section we describe the steps to setup the machine hosting database and the LDAP directory used by the IBM Tivoli Intelligent ThinkDynamic Orchestrator on Microsoft Windows 2000 Server. The high level install steps are presented in the following figure.
Create tioadmin user id
Create tioldap user id
Download and install Cygwin
Install and configure DB2 Install and configure IBM Directory Server
Figure 3-2 TIOdbsrv installation steps
The following sections explain each step of the above flow in detail.
3.2.1 Creating the required user IDs

Create a local user accounts tioadmin and tioldap as follows: 1. Under Computer Management choose System Tools -> Local users and groups -> Users and add the users tioadmin and tioldap. 2. Select the newly created users and make both of them members of the Administrators group. 3. Select the user ID tioadmin and set its Local Path to: C:\Cygwin\home\thinkcontrol 4. Select the user ID tioldap and set its Local Path to: C:\IBM\ldap
30
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 Cygwins BASH Shell and can be obtained at the following URL:
http://www.cygwin.com/
Ensure you are logged on to the TIOdbsrv machine using the tioadmin user account specified above. Attention: Cygwin Version 1.3.22 or higher must be installed. At the time of writing this Redpaper, Cygwin Version 1.5.5-1 was the current version available for downloading and it was used during our install process.
Important: Before you download Cygwin ensure you are logged on using the tioadmin user account specified above and that the tioadmin user has the correct profile properties and is a member of Administrators. 1. Open a browser and go the Cygwin home page: http://www.cygwin.com Select the Install or Update now! option. 2. Choose to open the setup.exe application from its current location 3. The Cygwin Setup window starts the installation wizard, select Next 4. Select Install from Internet 5. Accept default installation directory (C:\Cygwin), All Users and DOS options 6. Accept default Package directory 7. Choose the appropriate internet settings. We selected Direct Connection. 8. Select a FTP site from the available list 9. During the Cygwin installation, on the Select Package panel, it is important to select the correct Categories. The installation wizard provides a series of pre-selected packages as default for installation. However, IBM Tivoli Intelligent ThinkDynamic Orchestrator requires additional packages under the Lib and Net categories. The following table describes the required packages that need to be installed in addition the default selection. To select those packages, click the + sign of the Libs and Net categories, and click the Skip button next to the desired package to change the installation option from Skip to Install.
31
Tip: We recommend selecting and installing all of the Cygwin packages.
Additional Cygwin packages Cygwin Package Libs Net Action Accept default packages PLUS Regex Accept default packages PLUS OpenSSH and OpenSSL
10.When the installation completes, select to create icon on desktop. Select Finish.
3.2.3 Configuring SSH communications

When the Cygwin installation completes click on the Cygwin icon to open a bash shell window and perform the following steps to configure SSH: Important: Verify that all servers in your configuration are setup correctly in either DNS and or /etc/hosts. 1. Move to the /usr/bin directory and issue the host configuration ssh-host-config command, as shown in the following example. When prompted for environment variables, press Enter to accept the defaults.
$ cd /usr/bin $ ./ssh-host-config -y Generating /etc/ssh_host_key Generating /etc/ssh_host_rsa_key Generating /etc/ssh_host_dsa_key Generating /etc/ssh_config file Privilege separation is set to yes by default since OpenSSH 3.3. However, this requires a non-privileged account called 'sshd'. For more info on privilege separation read /usr/doc/openssh/README.privsep. Warning: The following function requires administrator privileges! Generating /etc/sshd_config file Added ssh to /cygdrive/c/WINNT/system32/drivers/etc/services Added ssh to /etc/inetd.conf Do you want to install sshd as service? Which value should the environment variable CYGWIN have when sshd starts? It's recommended to set at least "ntsec" to be able to change user context without password. Default is "binmode ntsec tty". CYGWIN= The service has been installed under LocalSystem account.
32
Host configuration finished. Have fun!
2. Export the CYGWIN variable.

$ export CYGWIN=ntsec
Tip: This command will set an environment variable for products to reference as a global variable. 3. Move to the /var directory and change the attributes of the directory named empty.
$ cd /var $ chmod 700 empty
4. Start the SSH service as follows:

$ cygrunsrv -S sshd
5. Move to the home directory of the tioadmin user ID and issue the ssh-keygen command to generate the RSA key. You should have an output similar to the following example.
$ cd $ pwd /home/thinkcontrol $ ssh-keygen -t rsa -N "" Generating public/private rsa key pair. Enter file in which to save the key (/home/thinkcontrol/.ssh/id_rsa): Created directory '/home/thinkcontrol/.ssh'. Your identification has been saved in /home/thinkcontrol/.ssh/id_rsa. Your public key has been saved in /home/thinkcontrol/.ssh/id_rsa.pub. The key fingerprint is: fd:ca:21:d3:3f:db:fd:d9:56:b2:30:68:16:43:1c:11 tioadmin@tio12
6. Move to the .ssh directory and create the authorized_keys file:

$ pwd /home/thinkcontrol $ cd .ssh $ cat id_rsa.pub > authorized_keys
7. To configure SSH to accept connections from new hosts without prompting for confirmation, create a file in the /home/thinkcontrol/.ssh directory called config. Edit the config file and add the line StrictHostKeyChecking no as follows:
# cd /home/thinkcontrol/.ssh # touch config # vi config
Add in the following line:

StrictHostKeyChecking no
33
Type the config file. The output should read as follows:

8. To verify that SSH is configured properly, try to access your own machine using the ssh command as shown in the following example.
$ ssh tioadmin@localhost Warning: Permanently added 'localhost' (RSA) to the list of known hosts. Fanfare!!! You are successfully logged in to this server!!! $ exit logout Connection to localhost closed.
3.2.4 Installing and configuring IBM DB2 UDB V8.1.2 on Windows

This section describes the installation and configuration of IBM DB2 Universal Database, Workgroup Unlimited Edition V8.1.2 on Windows. It also shows the required configuration steps required by IBM Tivoli Intelligent ThinkDynamic Orchestrator. Note: Ensure you perform the IBM DB2 installation logged on as tioadmin. Use the DB2 installation media provided with the IBM Tivoli Intelligent ThinkDynamic Orchestrator product. This ensures that you get the correct version and level of DB2 installed. 1. Logged on as tioadmin, move to the drive where the IBM DB2 CD is mounted and run the setup.exe command to start the installation. From the installation window, select Install Product. 2. Select the product we want to install: IBM DB2 Workgroup Server Unlimited Edition and click Next. 3. The Welcome to the DB2 Setup wizard window opens. Click Next. 4. Accept the License Agreement by selecting I accept the terms in the license agreement option. 5. The Select the installation type window opens. Select the Custom Install option. 6. Select Install DB2 Workgroup Server Unlimited Edition on this computer. 7. The Select features window opens, as shown in the next figure. Select the following packages: Client support Administration tools Server support
34
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.
35
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:
36
C:\IBM\SQLLIB\BIN>d: <-- This is the CDROM drive D:\>cd \db2\license D:>db2licm -a ./db2wsue.lic DBI1402I License added successfully. DBI1426I This product is now licensed for use as specified in the License Acceptance and License Information documents pertaining to the licensed copy of this product. USE OF THE PRODUCT CONSTITUTES ACCEPTANCE OF THE TERMS OF THE IBM LICENSE ACCEPTANCE AND LICENSE INFORMATION DOCUMENTS, LOCATED IN THE FOLLOWING DIRECTORY: "C:\IBM\SQLLIB\license\en"
19.Reboot the system
Create database and database schema

After installing IBM DB2 perform the following steps to create the database and the database schema used by IBM Tivoli Intelligent ThinkDynamic Orchestrator. Important: You must logon to your system using the tiodb user ID to be successful with the DB2 configuration. 1. Logon to the system as the tiodb user ID. 2. Open a DB2 command window. 3. Create the database for IBM Tivoli Intelligent ThinkDynamic Orchestrator by entering the following command:
db2 create database <db_name>
Where, <db_name> is the name of the database you want to create. Make sure the database name follow the DB2 naming conventions and that you record it as you will require it when installing IBM Tivoli Intelligent ThinkDynamic Orchestrator. You can confirm the creation of the database by issuing the following command:
db2 list database directory C:\IBM\SQLLIB\BIN>db2 create database ITITODB DB20000I The CREATE DATABASE command completed successfully. C:\IBM\SQLLIB\BIN>db2 list database directory System Database Directory Number of entries in the directory = 2 Database 1 entry: Database alias = ITITODB Database name = ITITODB Database drive = C:\DB2 Database release level = a.00 Comment =
37
Directory entry type Catalog database partition number Database 2 entry: Database alias Database name Database drive Database release level Comment Directory entry type Catalog database partition number C:\IBM\SQLLIB\BIN>
= Indirect = 0 = = = = = = = TOOLSDB TOOLSDB C:\DB2 a.00 Indirect 0
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.sql C:\IBM\SQLLIB\BIN>db2 connect to ITITODB user tiodb Enter current password for tiodb: Database Connection Information Database server = DB2/NT 8.1.2 SQL authorization ID = TIODB Local database alias = ITITODB C:\IBM\SQLLIB\BIN>db2 -tvf tablespace.sql CREATE BUFFERPOOL IBM16K SIZE 250 PAGESIZE 16K NOT EXTENDED STORAGE DB20000I The SQL command completed successfully. CREATE BUFFERPOOL IBM8K SIZE 250 PAGESIZE 8K NOT EXTENDED STORAGE DB20000I The SQL command completed successfully. CREATE REGULAR TABLESPACE IBM8KSPACE PAGESIZE 8K MANAGED BY SYSTEM USING ('IBM8KSPACE') BUFFERPOOL IBM8K DROPPED TABLE RECOVERY OFF DB20000I The SQL command completed successfully. CREATE REGULAR TABLESPACE IBM16KSPACE PAGESIZE 16K MANAGED BY SYSTEM USING ('IBM16KSPACE') BUFFERPOOL IBM16K DROPPED TABLE RECOVERY OFF DB20000I The SQL command completed successfully. CREATE TEMPORARY TABLESPACE IBM8KTEMPSPACE PAGESIZE 8K MANAGED BY SYSTEM USING ('IBM8KTEMPSPACE') BUFFERPOOL IBM8K DROPPED TABLE RECOVERY OFF DB20000I The SQL command completed successfully. CREATE TEMPORARY TABLESPACE IBM16KTEMPSPACE PAGESIZE 16K MANAGED BY SYSTEM USING ('IBM16KTEMPSPACE') BUFFERPOOL IBM16K DROPPED TABLE RECOVERY OFF DB20000I The SQL command completed successfully. C:\IBM\SQLLIB\BIN>
38
3.2.5 Installing and configuring IBM Directory Server V5.1

In this section we show the installation and configuration steps of IBM Directory Server, V5.1. In a IBM Tivoli Intelligent ThinkDynamic Orchestrator environment the IBM Directory Server can be installed on any system using any supported operating system. In our case study scenario, we decided to install IBM Directory Server on the same machine as the IBM DB2 server. In any case, an LDAP client must be installed on the IBM Tivoli Intelligent ThinkDynamic Orchestrator machine to allow it to communicate with the IBM Directory server. To install and configure IBM Directory Server 5.1, perform the following steps: 1. Log on to the system as tioadmin. 2. Ensure that the user ID tioldap has been created using the guidelines presented in 3.1.2 User IDs and passwords on page 30. Important: This implementation of LDAP can be in a shared environment but it will still need to have a dedicated LDAP ID (tioldap) created to service the IBM Tivoli Intelligent ThinkDynamic Orchestrator application. 3. Insert the IBM Directory Server, 5.1 CD in the drive and start the setup.exe located in the \ids_ismp folder to start the installation. 4. Select Language of choice for the installation process. English is set to default. 5. The installation wizard starts the installation process click Next. 6. Accept the License Agreement by selecting I accept the terms in the license agreement option. 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
39
GSKit Attention: If you are installing IBM Directory Server on a dedicated server, which is not the IBM DB2 server, ensure the DB2 option is selected. IBM Directory Server requires that a local database be installed.
Figure 3-5 Select IBM Directory Server components
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.
40
After installing IBM Directory perform the following steps to create the database and configure the IBM Directory server used by IBM Tivoli Intelligent ThinkDynamic Orchestrator: Important: You must logon to your system using the tioadmin user ID in order to be successful with the IBM Directory configuration. 17.At the system restart, logon as tioadmin. 18.Ensure the thinkdynamics.schema file located in the /samples directory on the IBM Tivoli Intelligent ThinkDynamic Orchestrator CD has been copied to the IBM Directory installation directory. 19.The IBM Directory Server Configuration Tool window opens. The Configuration Tool can also be opened by Click START > Programs > IBM Directory Server 5.1 > Directory Configuration. 20.Select Administrator DN/password and set the LDAP Administrator to cn=root and enter a password. Make sure you record the password, as you will need during the IBM Tivoli Intelligent ThinkDynamic Orchestrator installation.
41
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.
42
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.
43
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
44
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 - Windows

In this section we describe the steps to setup the machine hosting the IBM Tivoli Intelligent ThinkDynamic Orchestrator Server on Microsoft Windows 2000 Server. The high-level install steps are presented in the following figure.
Create tioadmin User ID
Download and install Cygwin
Configure SSH
Install and configure DB2 Client
Install and configure IBM Directory Client
Install and configure IBM WerbSphere Server
Apply IBM WebSphere FixPak 1 and required fixes
Install and configure IBM WerbSphere Client
Install and configure IBM Tivoli Intelligent ThinkDynamic Orchestrator
Figure 3-9 TIOsrv installation steps
45
The following sections explain each step of the above flow in detail.
3.3.1 Creating the required user IDs

Create a local user account tioadmin as follows: 1. Under Computer Management choose System Tools -> Local users and groups -> Users and add the user tioadmin. 2. Select the newly created user and make it members of the Administrators group. 3. Select the user ID tioadmin and set its Local Path to: C:\Cygwin\home\thinkcontrol
3.3.2 Installing and configuring Cygwin

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

The SSH configuration follows similar guidelines as described in 3.2.3, Configuring SSH communications on page 32, except the fact that there is no need to generate a new RSA public key. Here we provide the entire SSH configuration process required to allow the IBM Tivoli Intelligent ThinkDynamic Orchestrator to communicate with the IBM DB2 server via SSH. When the Cygwin installation completes click on the Cygwin icon to open a bash shell window and perform the following steps to configure SSH: Important: Verify that all servers in your configuration are setup correctly in either DNS and or /etc/hosts 1. Move to the /usr/bin directory and issue the host configuration program ssh-host-config as shown in the following example. When prompted for environment variables, press Enter to accept the defaults.
46
$ cd /usr/bin $ ./ssh-host-config -y Generating /etc/ssh_host_key Generating /etc/ssh_host_rsa_key Generating /etc/ssh_host_dsa_key Generating /etc/ssh_config file Privilege separation is set to yes by default since OpenSSH 3.3. However, this requires a non-privileged account called 'sshd'. For more info on privilege separation read /usr/doc/openssh/README.privsep. Warning: The following function requires administrator privileges! Generating /etc/sshd_config file Added ssh to /cygdrive/c/WINNT/system32/drivers/etc/services Added ssh to /etc/inetd.conf Do you want to install sshd as service? Which value should the environment variable CYGWIN have when sshd starts? It's recommended to set at least "ntsec" to be able to change user context without password. Default is "binmode ntsec tty". CYGWIN= The service has been installed under LocalSystem account. Host configuration finished. Have fun!
2. Export the CYGWIN variable.

$ export CYGWIN=ntsec
Tip: This command will set an environment variable for products to reference as a global variable. 3. Move to the /var directory and change the attributes of the directory named empty.
$ cd /var $ chmod 700 empty
4. Start the SSH service as follows:

$ cygrunsrv -S sshd
5. Move to the home directory of the tioadmin user ID and create the .ssh directory.
$ cd $ pwd /home/thinkcontrol $ mkdir .ssh
6. Copy the key files from the IBM DB2 server machine (TIOdbsrv) to c:\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:
47
id_rsa id_rsa.pub authorized_keys Note: You will need to configure SSH communications and copy the key files on all other servers in your environment that are running Cygwin and need to communicate with the IBM Tivoli Intelligent ThinkDynamic Orchestrator server. 7. To configure SSH to accept connections from new hosts without prompting for confirmation, create a file in the /home/thinkcontrol/.ssh directory called config. Edit the config file and add the line StrictHostKeyChecking no as follows:
# cd /home/thinkcontrol/.ssh # touch config # vi config
Add in the following line:

List the config file. The output should read as follows:

8. To verify that SSH is configured properly, try to access the ITITO database server machine using the ssh command as shown in the following example.
$ ssh tioadmin@tio12 Warning: Permanently added 'tio12,9.3.187.163' (RSA) to the list of known hosts. Fanfare!!! You are successfully logged in to this server!!! $ exit logout Connection to tio12 closed.
3.3.4 Installing IBM DB2 Universal Database V8.1.2 Client

This section provides instructions to install the IBM DB2 Universal Database V8.12 Client. Note: Ensure you perform the IBM DB2 installation logged on as tioadmin. Use the DB2 installation media provided with the IBM Tivoli Intelligent ThinkDynamic Orchestrator product. This ensures that you get the correct version and level of DB2 installed.
48
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. 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 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.
49
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 50000 db2 catalog db <db_name> as <db_name> at node <db_node>
Where, the variables are defined as follows: db_node A local, user-defined alias for the node to be cataloged. This is an arbitrary name used to identify the node. It should be a meaningful name to make it easier to remember. dbserver_hostname The hostname of the IBM DB2 server. db_name Specifies the name of the database to catalog. This is the name of the database created for the IBM Tivoli Intelligent ThinkDynamic Orchestrator server. 13.You can test the catalog by issuing the following commands:
db2 connect to <db_name> user tiodb C:\IBM\SQLLIB\BIN>db2 catalog tcpip node tio11 remote tio12 server 50000 DB20000I The CATALOG TCPIP NODE command completed successfully. DB21056W Directory changes may not be effective until the directory cache is refreshed. C:\IBM\SQLLIB\BIN>db2 catalog db ITITODB as ITITODB at node tio11 DB20000I The CATALOG DATABASE command completed successfully. DB21056W Directory changes may not be effective until the directory cache is refreshed. C:\IBM\SQLLIB\BIN>db2 connect to ITITODB user tiodb Enter current password for tiodb: Database Connection Information Database server = DB2/NT 8.1.2 SQL authorization ID = TIODB Local database alias = ITITODB C:\IBM\SQLLIB\BIN>
3.3.5 Installing and configuring IBM Directory V5.1 Client

In this section we show the installation and configuration steps of IBM Directory V5.1 Client on Windows. In our case study scenario the IBM Directory Server is installed on the same machine as the DB2 server. In any configuration of choice,
50
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: 1. Log on to the system as tioadmin. 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. 6. Accept the License Agreement by selecting I accept the terms in the license agreement option. 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. 9. The Select the installation type window opens. Select the Custom Install option. 10.The Select features window opens, as shown below. Select the following packages: Client SDK
51
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.0

In this section we describe the IBM WebSphere Application Server Base Edition V5.0. Later it will be required to install the IBM WebSphere Fixpack 1 to comply with the IBM Tivoli Intelligent ThinkDynamic Orchestrator required version of IBM WebSphere: V5.0.1. Note: Ensure you perform the IBM WebSphere Application Server installation logged on as tioadmin.
52
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: 1. Log on to the system as tioadmin. 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 5. Accept the License Agreement by selecting I accept the terms in the license agreement option. 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
53
8. The Installation path window opens. Select the installation path for the various components to be installed. Here are the installation paths used in our scenario. Make sure there are no spaces in the installation path.
WebSphere installation directories Product IBM WebSphere Application Server Base Edition V5.0.1 IBM Embedded Messaging Server and Client IBM HTTP Server Installation Directory c:\IBM\WebSphere\AppServer c:\IBM\WebSphere\MQ c:\IBM\HTTPServer
9. The install wizard prompts for the node name and hostname of the computer. Supply the fully qualified DNS name on the Hostname field. In our scenario we used the following: Node Name: tio11 Host Name: tio11.itsc.austin.ibm.com 10.Select both IBM WebSphere and IBM HTTP Server to run as a Windows service. Also, specify the tioadmin user ID and password so that those services run under tioadmin authority.
Figure 3-13 WebSphere runs as Windows service
54
Attention: If a dialog appears with message ID INST0056E, click OK and continue. No further action is required. 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 fixes

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

After installing IBM WebSphere Application Server Base Edition V5.0 you must install the fixpack 1, which is shipped with IBM Tivoli Intelligent ThinkDynamic Orchestrator. Note: When installing the fixpack 1, ensure that the IBM WebSphere Application Server, IBM HTTP and IBM HTTP Administration services are stopped. The installation will fail if these services are running. Here we provide the steps for installing the IBM WebSphere fixpack 1. 1. Still logged on as tioadmin, ensure that the IBM WebSphere Application Server, IBM HTTP and IBM HTTP Administration services are stopped. 2. Start the fixpack install process by opening a DOS prompt window and moving to the <IBM WebSphere installation directory>\bin directory and initializing the WebSphere command line environment by running the following script:
cd \IBM\WebSphere\AppServer\bin setupCmdLine.bat
55
3. Move to the drive where the IBM WebSphere fixpack 1 cd is mounted. Run the following script:
updateWizard.bat
Tip: Do not run the updateWizard.bat file through the GUI. 4. The Welcome to the Update installation wizard for IBM WebSphere window opens. Click Next. 5. The update wizard checks the current level of IBM WebSphere installed. Click Next. 6. The Select the installation type window opens. Select Install fix packs. 7. The update wizard prompts for the location of the fixpack 1. 8. Select the fixpack to be installed (was50_fp1_win).
Figure 3-14 IBM WebSphere Fix Pack 1 installation
9. Select to upgrade the following components: IBM HTTP Server Embedded Messaging 10.At the Start copying files window you have the chance to review the update options. Click Next to initiate the update.
56
When the update wizard completes, the following dialog is displayed.
Figure 3-15 IBM WebSphere Fix Pack 1 installation completed
Apply the MQ CSD03 fix

The MQ CSD03 fix is located in the /patches/csd03 directory in the IBM Tivoli Intelligent ThinkDynamic Orchestrator CD. Note: When installing the MQ CSD03 fix, ensure that the IBM WebSphere Application Server is stopped. The installation will fail if this service is running. Here we provide the steps for installing the MQ CSD 03 fix. 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.
57
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>mqver Name: WebSphere MQ Version: 530.3 CSD03 CMVC level: p530-CSD03J BuildType: IKAP - (Production)
Apply the IY43610 fix

The IY43610 fix is located in the /patches/I_43610 directory in the IBM Tivoli Intelligent ThinkDynamic Orchestrator CD. Note: When installing the IY43610 fix, ensure that the IBM WebSphere Application Server and the WebSphere Embedded Messaging services are stopped. The installation will fail if this service is running. Here we provide the steps for installing the IY43610 fix. 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
58
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 fix

The IY44803 fix is located in the /patches/I_44803 directory in the IBM Tivoli Intelligent ThinkDynamic Orchestrator CD. 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. Here we provide the steps for installing the IY44803 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> 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\bin java\lib
4. Create the following directories:

tools tools\java doc
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
59
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 fix

The PQ75055 fix is located in the /patches/WAS_PQ75055 directory in the IBM Tivoli Intelligent ThinkDynamic Orchestrator CD. Note: When installing the PQ75055 fix, ensure that the IBM WebSphere Application Server and the WebSphere Embedded Messaging services are stopped. The installation will fail if this service is running. Here we provide the steps for installing the PQ75055 fix. 1. Still logged on as tioadmin, ensure that the IBM WebSphere Application Server and the WebSphere Embedded Messaging services are stopped. 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\bin setupCmdLine.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\AppServer mkdir 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:
60
updateWizard.bat
Tip: Do not run the updateWizard.bat file through the GUI. The Wizard may open up in the background. 9. Choose a Language of choice for install screens. 10.The Welcome to the Update installation wizard for IBM WebSphere window opens. Click Next. 11.The update wizard checks the current level of IBM WebSphere installed. Click Next. 12.The Select the installation type window opens. Select Install fixes. 13.The update wizard prompts for the location of the PQ75055 fix. Attention: On the fix directory panel, ensure the directory path is: <WebSphere install directory>\update\efixes\.. (type in both dots)
Figure 3-17 PQ75055 installation directory
14.Select the fix to be installed (PQ75055).
61
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:
62
Figure 3-19 IBM WebSphere PQ75055 fix installation completion
Install and configure WebSphere Application Client V5.0.1

In this section we describe the IBM WebSphere Application Client V5.0.1 Note: Ensure you perform the IBM WebSphere Application Server installation logged on as tioadmin. Use the IBM WebSphere Application Client installation media provided with the IBM Tivoli Intelligent ThinkDynamic Orchestrator product. This ensures that you get the correct version and level of IBM WebSphere Application Client installed. To install IBM WebSphere Application Client V5.0, perform the following steps: 1. Log on to the system as tioadmin. 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
63
5. Accept the License Agreement by selecting I accept the terms in the license agreement option. 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. 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. 9. The install wizard prompts for the hostname and port number of the WebSphere Server computer. Supply the fully qualified DNS name on the
64
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. Note: Ensure you perform the following steps logged on 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.ConfigFile login.config.url.1=file:/<WAS_Client_instdir>/properties/wsjaas_client.conf
Where, <WAS_Client_instdir> is the WebSphere Application Client installation directory.

# Class to instantiate as the javax.security.auth.login.Configuration provider login.configuration.provider=com.ibm.security.auth.login.ConfigFile # Default login configuration file login.config.url.1=file:/C:/IBM/WebSPhere/AppClient/properties/wsjaas_clien t.conf
Important: You must use forward slashes in the directory path for the line, including the WebSphere Application Client installation directory. 17.Move to the <WebSphere Client Install Directory>\properties directory. 18.Edit the sas.client.props and locate the line:
com.ibm.CORBA.loginSource=prompt
And change it to:

com.ibm.CORBA.loginSource=none
Change the default transaction log size

Perform the following steps to change the default transaction log size:
65
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.
66
Figure 3-21 Changing the transaction log size
8. Click OK to make the changes effective. 9. Save the changes before exiting the BM WebSphere Application Server Administrative Console. 10.Stop and Start the IBM WebSphere Server service using the Windows Services tool.
3.3.8 Installing IBM Tivoli Intelligent ThinkDynamic Orchestrator

This section provides instructions on installing IBM Tivoli Intelligent ThinkDynamic Orchestrator on the TIOsrv machine running Windows 2000 Server.
67
Important: Before proceeding with the installation steps, ensure that the following activities are completed. The machine hosting the IBM Tivoli Intelligent ThinkDynamic Orchestrator database and Directory Server have been setup and all prerequisite software is configured and operational. This has been covered in 3.2, Installing and configuring TIOdbsrv - Windows on page 30. All the prerequisite software for IBM Tivoli Intelligent ThinkDynamic Orchestrator are installed, configured and up and running. This has been covered in this section. Ensure that SSH communication between the TIOsrv machine and TIOdbsrv machine is operational. Note: Ensure you perform the IBM Tivoli Intelligent ThinkDynamic Orchestrator installation logged on as tioadmin. To install and configure IBM Tivoli Intelligent ThinkDynamic Orchestrator perform the following steps: 1. Log on to the system as tioadmin. 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.
68
Figure 3-22 IBM Tivoli Intelligent ThinkDynamic Orchestrator welcome window
5. Accept the License Agreement by selecting I accept the terms in the license agreement option. 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.
69
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.
70
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.
71
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.
72
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.
73
Figure 3-27 Installation Summary window
74
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
75
4.1 Tools
The ITITO data center model (DCM) can be built in one of two ways: Defining each component using the Web management GUI Importing the DCM definitions using one or more XML files The advantage of the Web management GUI is that it is easy, although a bit time-consuming, but the main disadvantage is that the data center model cannot be reused on any other project because there is no export facility in ITITO Version 1.1. Conversely, building the DCM using XML files can be quite complex, time-consuming, and prone to errors. The main advantage of this method is that it can be re-used, copied, and extended more easily at any time in the future. Building the DCM is the recommended method, and a number of XML files are provided as examples. A number of software packages are available to edit XML. These range from very simple to very complex and expensive. The selection of tools is largely a matter of choice and budget. Some advice and guidelines are presented here. The tools discussed are: WordPad or Notepad Cooktop XMLSpy We discuss the benefits and disadvantages of each tool separately.
4.1.1 WordPad or Notepad

These editors provide absolutely no assistance with editing XML files. They do not guide, validate, or display the XML elements in different colors. A significant degree of familiarity with XML structures is recommended if either of these editors is chosen. On the plus side, they are always available on every Windows-based system, and if quick changes are required, they might be all that is needed.
4.1.2 Cooktop
This is a freeware dedicated XML editor that can be obtained from: http://www.xmlcooktop.com. Cooktop is a Windows-only editor that has a small download and footprint and provides the following useful facilities: It displays the XML file with color-coded text. It can validate the XML file against the DTD definition file.
76
It can display the structure of the XML elements graphically. Cooktop has the following disadvantages: It does not allow you to change the XML structures graphically. Some users have reported problems with some of the macros used in Tivoli Orchestrator. The following screen capture shows a typical session using the Cooktop XML editor:
Figure 4-1 Cooktop XML editor
Chapter 4. Creating the demonstration
77
This screen capture below shows the XML structure view from Cooktop:
Figure 4-2 Cooktop XML structure view
4.1.3 XMLSpy
XMLSpy is a licensed product from Altova systems, available at: http://www.altova.com. XMLSpy is available on a 30-day trial basis and requires registration with Altova. The tool provides the following features: It allows the XML files to be created and maintained either graphically or text based. It displays XML with color coding. It validates the XML against the DTD file. It does not permit invalid items to be inserted. It is possible to cut and paste structures. It is possible to shrink elements that are not being worked on, thus making it easier to see the current items. XMLSpy does have the following limitations: Using the graphical editor can be quite daunting at first and requires a fair bit of practice. It is expensive.
78
It does have some bugs! The following screen capture shows a typical session using the graphical editor in XMLSpy:
Figure 4-3 XMLSpy XML editor
4.2 Designing the data center model

This section describes the data center modeling process.
4.2.1 ITITO GUI method

If you choose the GUI method, we recommend that you clean up the ITITO database. It will be necessary to reinitialize the ITITO database with a blank DCM. This is best achieved by following these steps: 1. Edit the reinit-exec.bat file in c:\cygwin\home\thinkcontrol\tools.
79
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 method

The ITITO data center model consists of one XML file that contains a number of different elements and attributes. Each element has a specific set of child elements or attributes according to the design schema, also known as the DTD file. For ITITO, the basic data center model file has the following requirements. The minimum form of the XML file consists of a DOCTYPE element and a datacenter element. The datacenter element, however, is not valid without at least one valid child element. In this example, the child element is the switch-fabric element with a name Default, as shown here:
80
<?xml version="1.0" encoding="ISO-8859-1"?>  <!-DCM: Empty Author: A N Other Info: This DCM is totally empty awaiting customization --> <!DOCTYPE datacenter SYSTEM "xmlimport.dtd"> <datacenter> <switch-fabric name="Default"/> </datacenter>
All other elements must be placed between the <datacenter> begin and </datacenter> end tags. This example will initialize the ITITO data center model with nothing but a switch fabric called Default.
4.2.3 DOCTYPE element

Within the DOCTYPE element, it is possible to code reusable segments of XML (entities) that are included in elements defined later. For the demonstration, the following entities should be included in the !DOCTYPE definition:
<!ENTITY workload-cluster SYSTEM "workload-cluster.xml"> <!ENTITY resourcepoolconfig SYSTEM "resourcepool.xml"> <!ENTITY dataacquisitionconfig SYSTEM "dataacquisition.xml"> <!ENTITY simulator-cpu ' <dae-driver device="server" classname="com.thinkdynamics.kanaha.dataacquisitionengine.NullDriver"> </dae-driver> <dae-signal name="cpu-utilization" device="server" metric="cpu-utilization" aggregation="average" filter="low-pass-filter"> </dae-signal> '> <!ENTITY simulator-arrival-rate ' <dae-driver device="load-balancer" classname="com.thinkdynamics.kanaha.dataacquisitionengine.NullDriver"> </dae-driver> <dae-signal name="arrival-rate" device="load-balancer" metric="arrival-rate" aggregation="any" filter="low-pass-filter"> </dae-signal> <dae-signal name="raw-arrival-rate" device="load-balancer" metric="arrival-rate" aggregation="any"> </dae-signal>
81
'> <!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 supplies

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

The network components in ITITO consist of the following elements: Switch fabric Subnetworks Switches Routers and firewalls Load balancers (variety of switch) Access control lists (ACLs)
Switch fabric
The switch fabric element in ITITO is just a name to which other elements refer. Multiple switch fabrics can be defined if required. For demonstrations, it is recommended that only one be used. The customers name can be used if required, as shown in the following example:
<switch-fabric name="Customer Network"> </switch-fabric>
82
Subnetworks
Each subnetwork identified in Subnetworks on page 9 should be entered using the subnetwork element together with the VLAN and switch fabric name, as shown in the following example:
<subnetwork ipaddress="192.168.1.0" netmask="255.255.255.0"> <vlan vlan-number="101" fabric="Customer Network"/> </vlan> </subnetwork>
We recommend that you define all of the subnetworks in one group at this point in the XML file to aid in locating them when the data center model grows. In addition, it is a good idea to define the subnetwork of the ITITO server. For the demonstration system (discussed in Chapter 5, Demonstration on page 107) the ITITO server is on an IP address of 192.168.192.168, so there should be an additional subnet defined as follows:
<subnetwork ipaddress="192.168.192.0" netmask="255.255.255.0"> <vlan vlan-number="192" fabric="Customer Network"> </vlan> </subnetwork>
Switches
Every switch, switch module, and switch port identified in Switches on page 10 should be defined in the data center model using the switch element, as shown in the following example:
<switch name="Switch 1" is-device-model="Dummy Switch" fabric="Customer Network" ipaddress="192.168.1.253"> <switch-module name="fa0"> <switch-port vlan="101" port-number="1" layer1-interface-type="FastEthernet"> </switch-port> <switch-port vlan="101" port-number="2" layer1-interface-type="FastEthernet"> </switch-port> <switch-port vlan="101" port-number="3" layer1-interface-type="FastEthernet"> </switch-port> <switch-port vlan="101" port-number="4" layer1-interface-type="FastEthernet"> </switch-port> <switch-port vlan="192" port-number="5" layer1-interface-type="FastEthernet"> </switch-port> <switch-port vlan="101" port-number="6" layer1-interface-type="FastEthernet"> </switch-port>
83
<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-port vlan="101" port-number="12" layer1-interface-type="FastEthernet"> </switch-port> <switch-port vlan="102" port-number="13" layer1-interface-type="FastEthernet"> </switch-port> <switch-port vlan="102" port-number="14" layer1-interface-type="FastEthernet"> </switch-port> <switch-port vlan="103" port-number="15" layer1-interface-type="FastEthernet"> </switch-port> <switch-port vlan="103" port-number="16" layer1-interface-type="FastEthernet"> </switch-port> </switch-module> <power-outlet power-unit="Power Unit 1" outlet-number="1"> </power-outlet> </switch>
Note: For this switch, there is a reference to a power unit. If power units are not required, this can be omitted. We recommend that you define all of the switches in one group for clarity.
Routers and firewalls

In ITITO routers and firewalls are types of switches. Each router and firewall identified in Routers and firewalls on page 11 should be defined using the switch element and a number of network-interface child elements. Firewalls should be identified with the firewall element, which takes no parameters. In this example, the network interface contains a reference to an access control list that is defined later.
<switch name="Router 1" is-device-model="Dummy Switch" fabric="Customer Network"> <network-interface name="Management" ipaddress="192.168.1.254" managed="false"> <route subnetwork="192.168.2.0" gateway="192.168.1.254"> </route> <route subnetwork="192.168.3.0" gateway="192.168.1.254"> </route> <acl-ref type="1" name="ACL-1" enabled="true"> </acl-ref>
84
</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 balancers
Load balancers are defined with the load-balancer element. The following example shows the definition of a dummy load balancer to be used for demonstration purposes only:
<load-balancer name="Load Balancer 1" is-device-model="Dummy LB" type="arrowpoint-load-balancer" ipaddress="192.168.1.252"> </load-balancer>
Virtual IPs
Each virtual IP name used by the load balancers should be defined using the virtual-ip address, as shown in this example:
<virtual-ip name="Web Sales" load-balancer="Load Balancer 1" virtual-ip-address="192.168.1.250" in-tcp-port-first="80" in-tcp-port-last="80" out-tcp-port="80"/> </virtual-ip>
85
Each cluster that is to demonstrate automatic provisioning should reference a virtual IP, so ensure that one is defined for each of these clusters.
4.2.6 Software
The three categories of software (software package, software patch, and software stack identified in 2.3.3, Software on page 14 are defined, as shown in the following examples.
Software package
Software packages are defined with the software element type, for example:
<software name="Windows 2000" version="2000" package_path="d:\repository\Win2000" type="OPERATING_SYSTEM" install_path="c:\winnt"> </software>
Software patch
Any software patches required can be defined using the software-patch element:
<software-patch name="Windows 2000 Service Pack 4" package_path="c:\" reboot="true"> </software-patch>
Software stack
Finally, software packages and software patches are grouped into software stacks using a combination of the software-stack and software-stack-product elements, as shown in this example:
<software-stack name="Windows 2000 Server"> <software-stack-product product-name="Windows 2000" position="1" expected-state="running"> </software-stack-product> <software-stack-product product-name="Windows 2000 Service Pack 4" position="2" expected-state="running"/> </software-stack-product> </software-stack>
4.2.7 Spare pools

Each collection of spare similar servers identified in 2.3.4, Spare pools on page 16 should be defined by the spare-pool element containing a number of server elements, in turn, containing NIC and network-interface elements.
86
Note: For these servers, it is usually a good idea to have multiple network interface cards at least one of which is reserved for managing the server and is marked as not managed by ITITO. Other network cards can be set to managed, which will allow ITITO to assign change and remove IP addresses (network interfaces) when required. Obviously, if all the network interface cards are set to managed, ITITO could attempt to change the IP address of the network interface it is using to communicate with the server with unpredictable results!
<spare-pool name="Intel Pool" os-type="" vlan="101" 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 configuration

There are a number of general settings for ITITO that control the operation of the whole system that need to be defined in the data center model. These settings include global parameters, data acquisition parameters, and also the inclusion of macros for certain components.
87
These configuration parameters are defined with the kanaha-config element that has a single child element of dcm-object. One of the most important elements that should be created under the dcm-object element is a properties element with the ID of 0. This element contains the global variables for the whole system including items such as the operations mode, the default source host and directory for software packages, and the temporary path. For a demonstration, the actual locations of the software packages are not important, but can be useful to show the customer where these values are defined. Some parameters available include:
Table 4-1 Deployment engine global variables Component RESOURCE_BROKER DEPLOYMENT_ENGINE DEPLOYMENT_ENGINE DEPLOYMENT_ENGINE DEPLOYMENT_ENGINE DEPLOYMENT_ENGINE DEPLOYMENT_ENGINE DEPLOYMENT_ENGINE DEPLOYMENT_ENGINE Name OperationsMode-current PackageUtilPath PackageScriptPath PackageTempFilePath PackageIntermediateHost PackageRepositoryHost PackageRepositoryDir PackageWebHost PackageWebDir Value (with samples) manual /opt/zip /home/thinkcontrol/script /tmp 192.168.1.200 192.168.1.200 /usr/local/kanaha/upload 192.168.1.200 /usr/local/kanaha/apps
The following example shows a typical kanaha-config element that we recommend you load in the demonstration data center model:
<kanaha-config> <dcm-object id="0"> <property component="RESOURCE_BROKER" name="OperationsMode-current" value="manual"> </property> <property component="APPLICATION_CONTROLLER" name="predictor-prediction-interval-msec" value="900001"> </property> <property component="APPLICATION_CONTROLLER" name="predictor-type.1.class" value="com.thinkdynamics.kanaha.controller.appcontroller.predictor.DefaultP redictor"> </property> <property component="APPLICATION_CONTROLLER"
88
name="predictor-type.1.enable" value="true"> </property> <property component="APPLICATION_CONTROLLER" name="predictor-type.2.class" value="com.thinkdynamics.kanaha.controller.appcontroller.predictor.LinearTr endPredictor"> </property> <property component="APPLICATION_CONTROLLER" name="predictor-type.2.enable" value="false"> </property> <property component="APPLICATION_CONTROLLER" name="predictor-type.3.class" value="com.thinkdynamics.kanaha.controller.appcontroller.predictor.OneDayPr edictor"> </property> <property component="APPLICATION_CONTROLLER" name="predictor-type.3.enable" value="false"> </property> <property component="APPLICATION_CONTROLLER" name="predictor-type.4.class" value="com.thinkdynamics.kanaha.controller.appcontroller.predictor.OneWeekP redictor"> </property> <property component="APPLICATION_CONTROLLER" 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">
89
</property> &resourcepoolconfig; &dataacquisitionconfig; </dcm-object> </kanaha-config>
The first parameter listed here is the global operations mode of the ITITO system. In this case, it is set to manual, although it could be set to automatic if required. For a demonstration, it might be advisable to start the demonstration in manual mode and then to switch to automatic using the GUI after the basic principles have been shown. This will be explained more in the next chapter.
4.2.9 Customers
Each customer, application, cluster, and dedicated server identified in 2.3.5, Applications and customers on page 16 must be defined using the customer, application, cluster, and server elements that must be defined in the corresponding hierarchy. The following example shows a single server for one cluster in an application for one customer:
<customer name="Customer"> <application name="Internet Sales" priority="1"> <cluster name="Sales Web Servers" min-servers="1" max-servers="5" vlan="102" fabric="Customer Network" pool="Intel Pool" managed="true" is-device-model="Simulator" virtual-ipaddress="Sales Web"> <with-load-balancer name="Load Balancer 1"/> <server name="SalesWebSrv01"> <nic connected-to-switch="Switch 1" connected-to-module="fa0" connected-to-port="13" managed="false"> <network-interface name="Local Area Connection" ipaddress="192.168.2.3"/> </network> </nic> </server> </cluster> </application> </customer>
Note: The virtual IP address is set for this cluster. This is important for the simulator to be able to provision servers automatically.
90
4.3 Sample XML files

Included with this document are some sample XML files that can be used as a reference or to help the reader get started. Two examples are available: The Cookbook example, from which the segments in the previous section were taken. The XML file used in Provisioning On Demand: Introducing IBM Tivoli Intelligent ThinkDynamic Orchestrator, SG24-8888. Both examples have corresponding simulator definitions. In addition, the demonstration system itself contains a data center model and simulator parameters for the U.S. open environment.
4.3.1 Cookbook example DCM

The example that provided the fragments of XML in the previous section is based on the following physical design of a data center. See Figure 4-4 on page 92. In this data center, there are two applications: Human Resources and Internet Sales. Each is a two-tier application with a Web server tier and a database tier. The Web servers of each use Intel machines and Microsoft IIS, but the database servers use SQL server on Intel and DB2 on AIX, respectively. Each tier/cluster has one dedicated server, that is, a server that is not under ITITO control. The SQL server machine is not to take part in automatic provisioning. The production servers are all attached to switch Prod-SW-1 and have dedicated VLANs. The load balancer Load Balancer 1 balances the workload. There is a pool of eight Intel machines with dual network cards. One card is attached to the production network switch, and the other is attached to a management LAN using Switch 1. There is also a pool of one RS/6000 machine that is similarly attached and can be used to provide some relief to the Human Resources database when required. All the spare pools are in VLAN 101. The ITITO server is attached to the management LAN, but has its own VLAN. Finally, traffic is routed between all the VLANs by the router Router 1. This XML can be found in the file Demo-Cookbook.xml. The simulator parameters can be found in the file: Demo-Cookbook-tdnetwork.xml
91
Figure 4-4 Sample network infrastructure
4.3.2 Redbook example

Full details of the redbook example can be found in Provisioning On Demand: Introducing IBM Tivoli Intelligent ThinkDynamic Orchestrator, SG24-8888. The data center model for the redbook has been modified to use the simulator rather than the real servers and load balancers. The redbook data center model can be found in the file Redbook-simulator.xml.
92
The simulator parameters for the redbook example can be found in the file Redbook-tdnetworks.xml.
4.4 Loading the data center model

The XML data center model must be placed in the \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. Note: Be patient! This process can take 30-45 minutes, depending on the hardware used to support the environment. To follow the progress, you can open a new command window and enter the following command in order to see the entries put into the log file:
tail f %tc_home%\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.
93
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. b. c. d. e. Add subnetworks. Add switches. Add ACLs. Add routers, firewalls, and load balancers. Add virtual IPs.
3. Add the software configuration. 4. Add any miscellaneous components: a. Add terminal servers. b. Add blade center management servers. c. Add boot servers. 5. Add the spare pools. 6. Add the ITITO configuration. 7. Finally, add the customer configuration.
4.4.1 Tip for creating XML files using text editors

If a text editor is used to build the XML file, it can get rather large and unwieldy. One method of coping with this is to create separate files for each component type and then to assemble them prior to loading. For example, a number of files are available: Header section in the 1-Header.xmf file. Power supply section in the 2-power-units.xmf file. Networks section in the 3-Networks.xmf file. Software, software stack, and software patch in the 4-software.xmf file. Boot server definition. A Rembo server example is provided in the 5-bootserver.xmf file. Resource pools in the 6-pools.xmf file. ITITO variables in the 7-configvariables.xmf file. Customer definition in the 8-customer.xmf file. Terminal server, blade server, and so on in the 9-other.xmf file.
94
Finally, the datacenter terminator tag in the 10-trailer.xmf file. Note: The extension .xmf is used here to distinguish the files from XML files and means an XML fragment. It will then be possible to concatenate the files together (in the right order, from 1 to 10) into an XML file with the following command:
Cat xmf_file >> DCM-file.xml
Where, xmf_file is the fragment file described above. The XML file can then be loaded as before. Furthermore, it is a good idea to have separate files for each type of component as long as they have the correct prefix, for example, 5-SparePool-Intel.xmf, 5-SparePool-Linux.xmf, or 5-SparePool-AIX.xmf.
4.5 Configuring the simulator

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

Each cluster that takes part in the simulation must have the source of the data acquisition data defined and a simulation workload model associated with this source. The data acquisition properties are defined in the XML data center model, and the simulation workload model is defined in the tdnetwork.xml file. For the purposes of a demonstration, each cluster requires a dcm-object element to be defined as follows within the kanaha-config element:
<dcm-object type="cluster" name="Sales Web Servers"> &workload-cluster; <data-acquisition> &simulator-cpu; &simulator-arrival-rate; </data-acquisition> </dcm-object>
In this case, the texts &workload-cluster;, &simulator-cpu;, and &simulator-arrival-rate; refer to entities defined in the DOCTYPE element and
95
essentially are variable names that refer to macros. If the XML file is viewed with a Web browser, it can be seen that the variable name is replaced with the full definition from the DOCTYPE element. It is also possible to define these data acquisition properties within each cluster, but we recommend for simplicity in defining demonstrations that they are just defined in the kanaha-config element.
4.5.2 The tdnetworks file

The tdnetworks file consists of three main sections under the simulator element: Cluster-type Schedule Application traffic functions The simulator element contains the enable attribute that allows the simulator to be running at startup or stopped.
The tdnetworks cluster type element

The cluster-type element allows for different scaling factors to be applied to the traffic functions by particular types of cluster. However, it appears that in the Version 1.1 of ITITO that only one type of cluster is supported: UNKNOWN. This element is used to set the arrival rate, CPU utilization, and response times for the cluster type. In ITITO V1.1, the response times are not used, so they can be ignored. The CPU utilization parameter sets the percent of CPU used by a single transaction and the constant CPU percent. These parameters are specified as fractions of 1.
The tdnetworks schedule element

The schedule element controls startup and the sampling interval of the simulator. This element has two attributes expressed in milliseconds: Startup-delay Iteration
The tdnetworks application traffic element

Finally, the application traffic function allows a simulated workload to be applied to each cluster by using various functions; it is possible to increase or decrease the workload in smooth ramps or steps using the various parameters available.
96
The simulator provides two functions for simulating a workload: a step function and a ramp function. The step function simulates a constant workload for a specified duration, and the ramp function simulates a rising or falling workload from an initial position. The step function requires the following parameters: Duration (in milliseconds) Amplitude (expressed as a percentage of the max_amplitude defined for the application) The ramp function requires the following parameters: Slope (expressed as a ratio of transactions/millisecond, for example, 45 degrees upwards = 1, and 45 degrees downwards = -1) Duration (in milliseconds) Initial value (expressed as a percentage of the max) Important: For a demonstration of automatic provisioning, it will be necessary to define a workload for each of the customers applications. Note that the workload is set at the application level and not cluster. If the customer is able to provide a graph of a typical workload for each application, this could be used to build the simulator functions. For example, the following graph might represent two typical workloads: An office environment where there is little work before 9:00 a.m., then as staff come into work, the workload increases until lunch when it dips down until the afternoon before tailing off for the evening. A Web environment where there are a number of users before 9:00 a.m., then as the users go into work, the workload drops until lunch when some users might log on again before going back to work in the afternoon until the evening then there is a steady workload. In this example, surprisingly nobody is using the Internet application in the afternoon!
97
Workload
1200 1000 800 Workload % 600 400 200 0
00 00 0 0 0 0 0 0 :0 :0 6: 8: :0 :0 :0 :0 16 18 10 12 14 20 22 :0 0
Office workload Internet workload
Time
Figure 4-5 Workload during the day
When looking at the workload depicted above, it is obvious that the representation is focused on the relative amount of work that needs to be performed, not on any actual numbers. When trying to simulate this workload, we need to establish some point of reference by which we can quantify the amount of work. For example, does 100% workload mean 5 or 1000000 simultaneous transactions? For the purpose of the discussion, we assume in the following that 100% workload is achieved at 1000 simultaneous transactions. Now, with a proper reference point to set the scales of the above chart, we also need to know how much one transaction loads a system in our configuration. The correlation between a transaction and cpu-load allows us to translate workload into processing need, and thus simulate CPU usage and allocation of servers. For the sake of the discussion, let us assume that one transaction generates 5% load on a system. Here, we do not distinguish between different types of systems, because all the systems that will be allocated to support a workload will have similar configurations, and thus the use of a general number for load per transaction will not influence the calculations.
98
The simulator functions required to simulate the above office workload are as follows:
Table 4-2 Simulator functions for the sample Office workload Function StepFunction RampFunction StepFunction RampFunction StepFunction RampFunction StepFunction RampFunction StepFunction -1 Slope Duration 12000 6000 12000 6000 12000 6000 12000 6000 30000 100 20 50 100 100 100 20 100 Initial value Amplitude 20
The simulator functions that represent the above Internet workload are as follows:
Table 4-3 Simulator functions for the sample Office workload Function StepFunction RampFunction StepFunction RampFunction StepFunction RampFunction StepFunction RampFunction StepFunction RampFunction StepFunction -1 -3 -1 Slope Duration 18000 6000 6000 6000 12000 6000 12000 6000 12000 6000 12000 100 75 100 100 0 25 100 75 25 Initial value Amplitude 75
99
Calculating the number of systems

Knowing the workload over time as a percentage of the total workload, unfortunately, does not indicate how many transactions are being initiated or how much computing power is required to support the workload. To deduce the number of servers required running the workload, we have to look at the cluster_type properties again and combine these with our workload numbers. From the cluster_type element, the value for the scale property tells us how much cpu-load each transaction generates and the value for the constant property indicates what the system overhead, or idle load, is. For a max_amplitude of an application of 1000000 and a scale of 0.05, we can deduct that the total requirement for CPU at 75% workload is:
75%*1000000 transactions *0.05 %cpu/transaction = 37500 %cpu = 375 cpus
This almost translates to a requirement for 375 servers each using all their capacity to support our workload. When calculating the required servers, we have to adjust this number to account for the fact that each system cannot provide 100% CPU to support the workload. First of all, the system needs a few cycles for system overhead, which is represented by the constant property of the cpu_utilization parameter of the cluster_type entry. In the following, we assume that the value for constant is 0.01. In addition, the systems are never fully 100 percent committed to specific workload. From the Service Level Objective specified for the application, Platinum, Gold, or Silver, we know that more resources will be allocated to the application clusters when the average CPR utilization reaches a predefined cut_off value. The default values are 75%, 80%, and 90%, respectively. This implies that for an application with a Silver SLA, new systems are allocated when the average CPU load reaches 90%. Taking the idle load into account, we realize that the fraction of each system that will be used to execute our workload is:
Effective_CPU = Cut_off constant
For a Silver application with a constant of 0.01, the effective_CPU will be:
Effective_CPU = 0.90 0.01 = 0.89
Therefore, to adjust the calculation of needed required servers to account for these factors, the formula for the total number of required servers for to support a workload is:
Workload% * ( max_amplitude * scale) / (cut_off constant)
Using the numbers in our example, we get:

75% * (1000000 * 0.05)/100*(0.90 0.01) = 422 servers 4.5.2.3.2 Calculating the RampFunction slope
100
As seen above, when working with RampFunctions you have to specify the starting point, in terms of the percent fraction of the max_amplitude, and a slope to describe the curve. This can seem somewhat awkward compared to specifying starting and ending workload percentages, so in the following example, we demonstrate how to calculate slope based on pure workload data. As described earlier, the slope is a number indicating the growth (or decline) of transactions per time unit, and you might remember that the amplitudes denote fractions (in percent) of the max_amplitude defined for an application. Combining this information you can deduct that the slope, in terms of transaction increase or decrease over time, can be calculated as follows:
Slope = (Max_amplitude * (Ending_amplitude Starting-amplitude)/100) / duration
Please note that the starting_amplitude is also known as initial_value. To deduct the amplitudes, as percentages of max_amplitude, we have to involve the scale attribute of the cpu_utilization parameter of the cluster_type entry. The scale specifies how much one transaction loads a system. Combining this information with the amplitudes allows us to work with CPU load instead of slopes. Assuming the following:
Scale = 0.05 (5% cpu load for each transaction) Max_amplitude = 100000 Initial_value= 23% cpu Duration= 60000 milliseconds (one minute) Desired ending amplitude = 75%
We can calculate the slope as follows:

Workload_growth (ending_load starting_load) = 75%-23% = 52% Growth in transactions: workload_growth *max_amplitude = 0.52*1000000 = 520000 transactions slope = transactions / duration520000/60000 = 8.6667
Now that we know how much the workload increases over time, we can calculate the number of additional servers needed to support this load:
Growth in CPU demand: growth in transactions*scale = 520000*0.05 = 26000 %cpu Growth # of servers = Growth in CPU demand/100*(cut_off constant) = 26000/(0.90-0.01)*100 = 293 servers
To determine the amount of servers needed to support this resulting workload, we see:
101
Ending server demand_ = (starting load*max_amplitude + slope*duration)*scale/(cut_off constant) = (0.23*1000000 + 8.6667*60000) * 0.05/(0.90 0.01)*100 = 422 servers
Note: To ease the calculations of workload and the required number of servers to sustain this, we have provided a small, self-explaining spreadsheet to help you. The simulator parameters, which can be found in the provided Demo-Cookbook-tdnetwork.xml, needed to generate a workload for two applications, Human Resources and Internet Sales of our Demo-Cookbook (Demo-Cookbook.xml) DCM, are as follows:
<?xml version="1.0"?>  <td_network> <Version>0.80-032001</Version> <simulator enable="true"> <cluster-type name="UNKNOWN">  <simulation-parameters name="arrival-rate" noise-scale="0.0" output-ratio="0.25"> </simulation-parameters> <simulation-parameters name="cpu-utilization" scale="0.05" constant="0.01" max="1"> </simulation-parameters> <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">  <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" amplitude="100"> </function> <function function_type="RampFunction" slope="-2" duration="6000" 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" amplitude="100"> </function> <function function_type="RampFunction" slope="-3" duration="6000" 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="">
103
</function> <function function_type="StepFunction" duration="12000" amplitude="100"> </function> <function function_type="RampFunction" slope="-1" duration="6000" init_value="100" amplitude=""> </function> <function function_type="StepFunction" duration="12000" amplitude="75"> </function> </app_function> </application_traffic_functions> </simulator> </td_network>
Simulating multiple workloads

When using the simulator to demonstrate multiple workloads orchestrated simultaneously by ITITO, you should be aware of the limitation in the current release, which only allows for the UNKNOWN cluster_type entry. The effect of not being able to specify multiple cluster_types forces you to use the same value for the constant property (the system overhead) for all applications, no matter which platforms are used to support the application-specific workload. This can be regarded as a small inconvenience, which can be overcome by defining the smallest value for the constant property and adding extra transactions to selected workloads to simulate extra idle load. Assuming that you have three workloads running on three different platforms with the current characteristics:
App1 App2 App3 real_scale=0.05 idle_load=0.01 real_scale=0.01 idle_load=0.05 real_scale=0.02 idle_load=0.03 real_max_amplitude=1000 real_max_amplitude=10000 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,
104
because you can only specify one value the scale property, you must specify the lowest one of the applications you will be simulating, and adjust the max-amplitude for the other applications accordingly. In our example, we would specify a common value for scale of 0.01, which comes from App2. Using this value for all the applications, the simulated workload for App1 would be one fifth of the anticipated workload and half of the anticipated workload for App3. Because all workloads are specified as percentages of the max_amplitude, all we need to do to compensate for the lower scale is to multiply the real_max_amplitude for App1 and App3 by a factor of (real_scale/scale), which is 5 and 2, respectively, for the two applications in question.
4.6 Testing
Before demonstrating the system to the customer, it should be adequately tested, and ideally, a complete walk through of the demonstration should be performed first. Ensure that the following key areas are working: The GUI loads and the switch fabric can be opened. The icon view of the switch fabric is available. Drill down to a switch to view the ports, and so on. Optionally, use the GUI to turn a switch port on or off. (Only attempt this if the switch has the dummy switch device driver.) Open a resource pool and examine the servers. Make sure that the NICs and interfaces are defined as needed. Open a software package and check its contents. Check that the software package is included in relevant software stacks. Open the customer and make sure that the applications and clusters are defined correctly. Display the server view from a cluster that will use automatic provisioning. Make sure that the simulator is generating a workload for the servers in these clusters. (They will have a bar chart of CPU utilization if it is.) Switch a cluster into manual mode. Add a server to the cluster. Check that the deployment succeeded and that the server was added. Return to the switch fabric view and ensure that the managed port on the server has been moved to a new VLAN. Remove a server from the cluster. Check that it was removed successfully.
105
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.
106
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
107
5.1 Introduction to ITITO and the scenario

You should probably start with the presentation with a quick overview of ITITO. You should familiarize the customer with the main capabilities of ITITO, especially the ones you have agreed to demonstrate during the initial interview. The following section has been extracted from Provisioning On Demand: Introducing IBM Tivoli Intelligent ThinkDynamic Orchestrator, SG24-8888.
5.1.1 ITITO: A quick overview

The following figure shows a typical example of a data center running three applications, in which one application needs additional resources to attend to user demand, while the other two have enough, or even extra, resources allocated to them. Traditional, manual provisioning practices do not make it practical to move resources from one application to another to meet short-term peaks in demand. Instead, we engage in what we call the just-in-case provisioning cycle:
Figure 5-1 Traditional just-in-case provisioning
108
IBM has changed the provisioning paradigm from just-in-case to just-in-time with IBM Tivoli Intelligent ThinkDynamic Orchestrator by managing resources information and to enhance automation. ITITO dynamically moves computing resources to support the applications with the greater immediate impact on the business just-in-time to meet user demand. Therefore, an organization can reach higher levels of automation and rapidly respond to fluctuating business demands on the IT infrastructure, in line with the overall business goals of the organization. ITITO automates the traditional, manual provisioning process, performance measurement, capacity planning, and infrastructure deployment. ITITO operates in a closed loop that performs automatic resource requirements prediction, based on predefined service level objectives and agreements, and automates infrastructure deployment. This just-in-time cycle ensures that each application has the resource it needs, when it needs it, without static over provisioning.
Figure 5-2 Orchestrated Just-in-Time provisioning
Although any application can be allocated to any server at any time, a server could be built specifically for an application when it needs it and is subsequently deallocated when it is no longer needed by the application.
Chapter 5. Demonstration
109
5.2 Data center assets and resources

When the demonstration has been created, it should represent a network configuration that you and the customer have agreed upon. Show the customer the schematic representation of the environment you have created.
5.2.1 Show the switch fabric and inventory resources

Select the Data center assets and resources tab > toggle Inventory > toggle Switch Fabrics > select the customer switch fabric you created > change the view to icon view. You should now have a diagram similar to the following:
Figure 5-3 The switch fabric network details - icon view
110
Click the switch. This will show the customer the VLANs in more detail and which switch ports are connected to the servers:
Figure 5-4 Switch network details - icon view
You can also drill down to a single server view by selecting any of the servers:
Figure 5-5 Server network details - icon view
All the resources are listed under the Inventory toggle. Show any resources you think the customer may be interested in seeing. They should all be configured to the requirements agreed upon when setting up the environment. Remember to switch the view back to the details view.
5.2.2 Show the customer the resource pools

Select the Data center assets and resources tab -> toggle Resource Pools. Ensure the correct servers are in each pool. Select one of the pools and show the servers. Talk about their current status: If they are brown, they are assigned to a cluster and application, if they are green, they are unassigned, and so forth. The following diagram shows servers in the Intel Pool. For example, x330-2 and x330-7 are assigned to the Sales Web Servers cluster part of the Internet Sales
111
application, and x330-4 is assigned to the HR Web Servers cluster part of the Human Resources application.
Figure 5-6 Servers in the pre-POC environment
5.3 Customer applications

Show the customer the applications that are being provisioned. 1. Select the Customer applications tab -> toggle Customers -> select the customer name. You now see the names of the applications that you have agreed with the customer should be provisioned. 2. Select one of these applications -> select the Clusters tab. You now see the names of the clusters that are part of the application and information about the clusters:
112
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:
113
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:
114
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
115
5.4 Real-time performance monitoring

As long as it has been set up, the simulator changes the utilization of the servers and automatically adds and removes servers from the applications. Servers can also be added manually or semi-automatically. 1. For the servers to automatically be added and removed from applications ensure all the applications are set to automatic mode, as follows. Select the Customer applications tab -> toggle the Customer tag -> select the customer name -> select the application -> set the Operating Mode on the pull-down menu to automatic -> select Change. 2. Now show the overall server utilization and performance as the servers are being added to and removed from applications: Select the Data center assets and resources tab -> toggle Inventory -> select Servers -> on the Servers tab from the top pull-down menus, select All for Cluster and All for Pool -> select Search. You should now have a view similar to the following figure:
Figure 5-13 Servers view - provisioning details
This view shows you all the servers in your environment, which application/cluster they are assigned to, and to which pool they belong. Watch the server utilization move up and down on the right side. As the utilization increases for an application, you will see extra servers being assigned, and as demand drops, servers being unassigned.
116
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.
117
118
Appendix A.
Additional material
This Redpaper refers to additional material that can be downloaded from the Internet as described below.
Locating the Web material

The Web material associated with this Redpaper is available in softcopy on the Internet from the IBM Redbooks Web server. Point your Web browser to:
ftp://www.redbooks.ibm.com/redbooks/REDP3830
Select the Additional materials and open the directory that corresponds with the Redpaper form number, REDP3830.
Using the Web material

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

The following system configuration is recommended: Hard disk space: Operating System: Processor: Memory: 1 MB minimum Microsoft Windows any any
How to use the Web material

Create a subdirectory (folder) on your workstation, and unzip the contents of the Web material zip file into this folder.
120
Related publications
The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this Redpaper.
IBM Redbooks
For information on ordering these publications, see How to get IBM Redbooks on page 122. Note that some of these documents referenced here may be available in softcopy only. 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 manuals
These publications are also relevant as further information sources: IBM Tivoli Intelligent Orchestrator and Tivoli Provisioning Manager Release Notes, SC32-1422 IBM Tivoli Intelligent Orchestrator and Tivoli Provisioning Manager Operators Guide, SC32-1421 IBM Tivoli Intelligent Orchestrator and Tivoli Provisioning Manager Installation Guide, SC32-1420
121
IBM Tivoli Provisioning Manager and Intelligent Orchestrator Overview Guide, SC32-1419
Online resources
These Web sites and URLs are also relevant as further information sources: IBM Tivoli Intelligent ThinkDynamic Orchestrator Product Web page http://www.ibm.com/software/tivoli/products/intell-orch/ IBM Tivoli Provisioning Manager Product Web page http://www.ibm.com/software/tivoli/products/prov-mgr/ Cwgwin http://www.cygwin.com/ WebSphere Application Server manuals http://www.ibm.com/software/webservers/appserv/was/library/ IBM DB2 manuals http://www.ibm.com/software/data/db2/library/ Software Support http://www.ibm.com/software/support IBM Web infrastructure orchestration http://www.ibm.com/software/tivoli/features/web-svr-prov/solution.ht ml IBM Application Framework for e-business http://www.research.ibm.com/journal/sj/401/flurry.html
How to get IBM Redbooks

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

IBM Support and downloads:
ibm.com/support
IBM Global Services:

ibm.com/services
Related publications
123
124
Back cover
IBM Tivoli Intelligent ThinkDynamic Orchestrator

Redpaper
INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION
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.
BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL 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

REDP-3830-00

IBM Tivoli Intelligent Think Dynamic Orchestra Tor Pre Proof-Of-Concept Cookbook For Business Partners Redp3830

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

IBM Tivoli Intelligent Think Dynamic Orchestra Tor Pre Proof-Of-Concept Cookbook For Business Partners Redp3830

Hochgeladen von

Copyright:

Verfügbare Formate

Front cover

IBM Tivoli Intelligent ThinkDynamic Orchestrator

Data center modeling

Edson Manoel Tony French

Copyright IBM Corp. 2004. All rights reserved.

Pre Proof-of-Concept Cookbook for Business Partners

Pre Proof-of-Concept Cookbook for Business Partners

Copyright IBM Corp. 2004. All rights reserved.

Pre Proof-of-Concept Cookbook for Business Partners

Copyright IBM Corp. 2004. All rights reserved.

IBM Tivoli Provisioning Manager Product Web page:

IBM Web Infrastructure Orchestration, SG24-7003

The team that wrote this Redpaper

Pre Proof-of-Concept Cookbook for Business Partners

Become a published author

Send your comments in an Internet note to:

Pre Proof-of-Concept Cookbook for Business Partners

Data center modeling

Copyright IBM Corp. 2004. All rights reserved.

Pre Proof-of-Concept Cookbook for Business Partners

Copyright IBM Corp. 2004. All rights reserved.

2.2 General questions

Pre Proof-of-Concept Cookbook for Business Partners

Pre Proof-of-Concept Cookbook for Business Partners

2.3 ITITO components

2.3.1 Power units

2.3.2 Network configuration

Pre Proof-of-Concept Cookbook for Business Partners

Blocked range start

Blocked range end

Pre Proof-of-Concept Cookbook for Business Partners

The following switches are supported by ITITO Version 1.1:

Routers and firewalls

The basic definition table for a router is as follows:

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

Access control lists

Pre Proof-of-Concept Cookbook for Business Partners

Pre Proof-of-Concept Cookbook for Business Partners

2.3.4 Spare pools

Spare pool name

2.3.5 Applications and customers

Pre Proof-of-Concept Cookbook for Business Partners

Each application cluster requires the following additional definitions:

Network interface card

Pre Proof-of-Concept Cookbook for Business Partners

2.3.6 Other devices

Boot server name

IBM IBM IBM Sun HP

Pre Proof-of-Concept Cookbook for Business Partners

Blade center management servers

Blade server name

Pre Proof-of-Concept Cookbook for Business Partners

Pre Proof-of-Concept Cookbook for Business Partners

Installing the demonstration systems

Copyright IBM Corp. 2004. All rights reserved.

3.1 Installation process overview

Pre Proof-of-Concept Cookbook for Business Partners

Define the User IDs

TIO Database Server

Prepare SSH communications

Prepare the TIO database Server

TIO Database Server