Exploring the Future Potential of AI-Enabled Smartphone Processors
Ibm tivoli intelligent think dynamic orchestrator pre proof of-concept cookbook for business partners redp3830
1. 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
2.
3. International Technical Support Organization
IBM Tivoli Intelligent ThinkDynamic Orchestrator
Pre Proof-of-Concept Cookbook for Business
Partners
February 2004
10. Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
AIX® ibm.com® RS/6000®
DB2 Universal Database™ OS/390® Tivoli®
DB2® Redbooks™ WebSphere®
IBM® Redbooks (logo) ™ z/OS®
The following terms are trademarks of other companies:
Intel, Intel Inside (logos), and Pentium are trademarks of Intel Corporation in the United States, other
countries, or both.
Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.
Other company, product, and service names may be trademarks or service marks of others.
viii Pre Proof-of-Concept Cookbook for Business Partners
12. Recommended reading
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this Redpaper.
Product manuals:
IBM Tivoli Intelligent Orchestrator and Tivoli Provisioning Manager Release
Notes, SC32-1422
IBM Tivoli Intelligent Orchestrator and Tivoli Provisioning Manager Operator’s
Guide, SC32-1421
IBM Tivoli Intelligent Orchestrator and Tivoli Provisioning Manager Installation
Guide, SC32-1420
IBM Tivoli Provisioning Manager and Intelligent Orchestrator Overview Guide,
SC32-1419
Online resources:
IBM Tivoli Intelligent ThinkDynamic Orchestrator Product Web page:
http://www.ibm.com/software/tivoli/products/intell-orch/
IBM Tivoli Provisioning Manager Product Web page:
http://www.ibm.com/software/tivoli/products/prov-mgr/
IBM Redbooks™:
Provisioning On Demand: Introducing IBM Tivoli Intelligent ThinkDynamic
Orchestrator, SG24-8888
http://www.redbooks.ibm.com/redbooks/pdfs/sg248888.pdf
IBM Web Infrastructure Orchestration, SG24-7003
http://www.redbooks.ibm.com/redbooks/pdfs/sg247003.pdf
The team that wrote this Redpaper
This Redpaper was produced by a team of specialists from around the world
working at the International Technical Support Organization, Austin Center.
Edson Manoel is a Software Engineer at IBM Corporation, International
Technical Support Organization, Austin Center, working as an IT Specialist in the
Systems Management area. Prior to joining the ITSO, Edson worked in the IBM
Software Group as a Tivoli Technology Ambassador and within IBM Brazil
Professional Services Organization as a Certified IT Specialist. He was involved
in numerous projects, such as designing and implementing systems
x Pre Proof-of-Concept Cookbook for Business Partners
13. management solutions for IBM customers and Business Partners. Edson holds a
bachelor’s degree in Applied Mathematics from Universidade de Sao Paulo,
Brazil.
Tony French is a Tivoli Services Consultant in the U.K. He has 21 years of
experience in the IT industry, including six years experience in Tivoli Software.
His areas of expertise include IBM Tivoli Intelligent ThinkDynamic Orchestrator,
IBM Tivoli Business Systems Manager, and the Tivoli Framework suite of
products. He has written extensively about IBM Tivoli Business Systems
Manager.
Thanks to the following people for their contributions to this project:
Morten Moeller ITSO Austin Center
Sara C. Brumfield ITITO Level 2 Support, IBM Software Group
Theo Winkelmann On Demand Sales Enablement, IBM Software Group
Leonard Hand Senior Consulting I/T Architect, IBM Global eBusiness
Solution Center
Become a published author
Join us for a two- to six-week residency program! Help write an IBM Redbook
dealing with specific products or solutions, while getting hands-on experience
with leading-edge technologies. You'll team with IBM technical professionals,
Business Partners and/or customers.
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you'll develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our papers to be as helpful as possible. Send us your comments about
this Redpaper or other Redbooks in one of the following ways:
Use the online Contact us review redbook form found at:
ibm.com/redbooks
Preface xi
14. Send your comments in an Internet note to:
redbook@us.ibm.com
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. JN9B Building 003 Internal Zip 2834
11400 Burnet Road
Austin, Texas 78758-3493
xii Pre Proof-of-Concept Cookbook for Business Partners
16. Guidance on configuring the ITITO simulator for the customized data center
model.
Demonstration
Guidelines demonstrating the key features of the ITITO product.
Provisioning and orchestrating, including:
– Data center assets and resources
– Customer applications
– Real-time performance monitoring
2 Pre Proof-of-Concept Cookbook for Business Partners
18. 2.1 Interviews
To demonstrate to a customer how ITITO can be used in their environments, it is
necessary to conduct a number of interviews with various specialists. Building an
ITITO data center model can require a detailed level of information including, for
example, MAC addresses and information about which ports on the network
switch to which each network interface card (NIC) connects. For the purposes of
a demonstration, however, it is not strictly necessary to gather the finest detail,
but it may be advisable so that any subsequent Proof of Concepts (POC) project
has a head start.
The initial interviews should determine if the customer has any applications that
are suitable for automating with ITITO and selecting a number that can be used
to build the demonstration system. We recommend that at least two applications,
but no more than four, be selected to build the demonstration.
2.2 General questions
During the initial interview with the customer, these questions may be useful to
gain an overview of the customer’s environment and operating practices:
1. Does the customer have any applications that use clusters of similar servers
to provide a service?
Tip: If the customer has mainly mainframe-based computing and is not
planning to change to a distributed architecture, they are not an ideal
candidate. ITITO fits very well for applications that support horizontal
scaling (that is, Web, application servers).
2. Do the servers in these clusters run single applications or many?
Tip: If the customer runs more than one application in each server, this
application might not be suitable for automation by ITITO.
3. Typically, how many servers make up these clusters?
4. Do these clusters of servers use load balancers or application servers to
control the utilization of each server?
5. Does the customer provide sufficient servers to meet peak loads? What is the
average utilization of the servers in these application clusters?
6. How does the customer plan for peak loads (for example, year-end
accounting, special promotions, or sales)? Does the customer:
4 Pre Proof-of-Concept Cookbook for Business Partners
19. – Wait for the load to materialize and then take action as above?
– Build extra servers for each application and incorporate these into the
clusters?
– Do nothing? (Longer response times at peak times are normal!)
7. How does the customer handle peak loads in their applications? Does the
customer:
– Have a number of extra servers dedicated to each application?
– Reconfigure other application servers?
– Have a spare pool of servers that can be built to order?
8. When the peak loads subside, does the customer:
– Return any servers that were added to the application cluster to their
previous state?
– Leave the servers in place for the next peak?
9. If the customer returns servers to their previous state, how long does this
typically take?
10.Do the customer’s applications have peak loads at different times?
11.Could the customer conceivably use servers that are idle for one application
in another application that is undergoing a peak load?
12.Does the customer maintain a large number of dedicated test servers for
each application, or does the customer use a general pool of test servers?
Tip: The more the better: ITITO provides a great starting point in a
non-production environment and allows the customer to recover, redeploy,
or eliminate redundant servers in the test environment.
13.Typically, what is the utilization of the test server environments?
14.Are the applications written in-house or are they 100% “shrink-wrapped” from
the software vendor (that is, no customization)? Does the customer perform
their own development and testing?
Tip: ITITO can enhance the management and maintenance of customized
or homegrown applications. If the customer has a 100% shrink-wrapped
environment and rarely makes changes to their production/staging
environments, they are less qualified as a prospective customer.
15.Does the customer operate applications over multiple data centers?
16.Does the customer have control over their network environment, or is it
outsourced to a network provider?
Chapter 2. Planning 5
20. Tip: If the customer’s network is totally outsourced, they might not have
sufficient access to perform the dynamic reconfiguration that ITITO is
capable of providing.
17.What are the customer’s predominant operating systems (for example, AIX®,
Solaris, HP/UX, Microsoft Windows, or Linux)?
Tip: If the customer uses mainly OS/390® or non UNIX®/Intel® operating
systems, they might be less qualified as a prospect.
18.Does the customer have any blade servers? If so which types/makes (HP,
IBM, and so on)?
19.How many and what type of network switches is the customer using (that is,
Cisco, Extreme, Foundry, and so on)?
Tip: Our application is better suited for Level 3 (network layer) switches,
but we can also work with Level 2 (data layer) switches.
20.What level of redundancy is provided for at the network equipment level, if
any?
21.What type of network and systems management software is the customer
using (OpenView, Tivoli, CA UniCenter, and so on)?
Tip: Helps determine the level of sophistication present in the network
operations center.
22.What kind of storage infrastructure is in place (that is, Storage Area Network,
or SAN, Network Attached Storage, Redundant Array of Independent Disks,
or RAID)?
23.What are the customer’s dominant relational database management systems
(Oracle, DB2®, Microsoft SQL Server, MySQL, or other)? And, are clustered
database solutions being used?
24.What is the application server software, if any (WebSphere®, Weblogic,
Resin, Jboss, or other)?
The ideal outcome of these questions is to locate two to four applications that
have the following characteristics:
Clustered architecture
6 Pre Proof-of-Concept Cookbook for Business Partners
21. A low average utilization with idle servers available for peak demand
Or,
A pool of spare servers that are provisioned for peak demand
Use similar hardware and operating system platforms
Operate in a network that the customer has control over
Alternatively, if the customer wants to provision application test environments
from a pool of common servers rather than maintain separate test environments
for each application, ITITO can be a suitable tool for this, too.
The following table can be used to collect and summarize the data from these
questions:
Table 2-1 Capturing customer planning information skeleton
Applic- # Operating # # Avg. #
ation Servers systems Web Data- util Spare
servers bases % servers
2.3 ITITO components
After a limited number of suitable applications are identified, it is necessary to
gather additional technical details in order to build an ITITO data center model.
To simplify the data center model building, these components have been broken
down into the following categories:
Power units
Network configuration
Software configuration
Spare pools
Customers, applications, and clusters
Other devices
The following sections contain tables showing the required attributes that need to
be collected for each component type. The shaded cells in these tables are for
additional data that is not essential for a demonstration but is necessary for a full
ITITO build or Proof of Concept.
Chapter 2. Planning 7
22. 2.3.1 Power units
For the purposes of a demonstration, power units are optional in ITITO. It is
possible to define the power units and to associate devices with these power
units. It is also possible to manage the power units through an IP connection. For
a demonstration, it will usually only be necessary to collect the names of the units
for later reference by other devices:
Table 2-2 Power units data collection skeleton
Power unit name Manufacturer Model Device model
Note: The only devices that are supported by Version 1.1 of ITITO are as
follows:
Table 2-3 Power units data collection example
Manufacturer Model Device model
APC 7901 APC-7901-SNMP
APC 9606 APC-9606-SNMP
Note: It is also possible to define network interface cards (NICs) on a power
unit and associate it with a port on a network switch, but it was found that the
data center model would not load if this were done. However, it is possible to
define the interface from the ITITO GUI.
2.3.2 Network configuration
The ITITO network configuration consists of the following main components:
Switch fabric
Subnetworks
Switches
Load balancers
Virtual IPs
Access control lists (ACLs)
Each of the main components is addressed separately.
Most devices in ITITO require a number of service access points that define the
mechanisms and authentication information (user IDs and passwords) that are
used to communicate with the device. For a demonstration, these are not
8 Pre Proof-of-Concept Cookbook for Business Partners
23. 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 9
24. Subnet address Blocked range start Blocked range end
Switches
Each network switch device that is used by the applications determined in
Section 2.2 on page 4 should be recorded here:
Table 2-6 Switch data collection skeleton
Switch IP Switch
Manufacturer Model Device model
name address fabric
Switches often have separate modules containing a number of ports. Every port
that connects a device in the ITITO environment must be defined here and will be
used later in the device definitions. It is not necessary to define every port on
every switch, just the ones to be controlled by ITITO.
Table 2-7 Switch port data collection skeleton
Switch name Switch modules Switch port VLAN Port type
The valid types of ports for ITITO Version 1.1 are:
Ethernet
Fast Ethernet
Gigabyte
10 Pre Proof-of-Concept Cookbook for Business Partners
25. 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 Model Device model
Cisco 6500 Cisco 6500 Switches Hybrid Mode
Cisco 6500 Cisco 6500 Switches Native IOS Mode
Cisco 3548 Cisco 3548
Cisco 2621 Cisco 2621
IBM Blade Center Blade Center 4p GB Eth
4port GB
Extreme 48i Extreme 48i
Foundry Foundry Switch Foundry Switch
Others Dummy Switch Dummy Switch
If the customer has other switches than these, it will be necessary to code
custom device drivers during any Proof of Concept or implementation.
Fortunately, for a demonstration, it is only necessary to use the dummy switch
device model for all devices. This allows the switch operations to be simulated
during the demonstration.
Routers and firewalls
Routers are defined as switches in ITITO, but they also require network
interfaces, route definitions, and access control lists.
Chapter 2. Planning 11
26. The basic definition table for a router is as follows:
Table 2-10 Router data collection skeleton
Router Switch Device
Manufacturer Model IP address Firewall
name fabric model
Routers will usually have a number of interfaces that control the routing between
subnets. The data required for these components is as follows:
Table 2-11 Router interface data collection skeleton
Router name Interface name IP address Managed
Each interface can support a number of routes, which need to be specified in the
following table:
Table 2-12 Router interface route data collection skeleton
Router name Interface name Route Gateway ACL
The following router is a valid device in ITITO Version 1.1:
Table 2-13 Router information data collection example
Manufacturer Model Device model
Cisco 2621 Cisco 2621
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 Pre Proof-of-Concept Cookbook for Business Partners
27. Table 2-14 Access Control List data collection skeleton
ACL name Rule # Target Source subnet Destination subnet
The Target column contains the operational mode of the rule: either permit or
deny.
Each rule can specify protocols or port ranges to permit or deny, but for the
purposes of a demonstration, this should not be necessary.
Load balancers
Load balancers require the following information to enable them to be defined to
ITITO:
Table 2-15 Load balancer data collection sample
Name Manufacturer Model Type Device model
The following load balancers are valid devices in ITITO Version 1.1:
Table 2-16 Load balancer data collection example
Manufacturer Model Device model Type
Cisco 11000 Cisco CSS arrowpoint-load-balancer
Alteon LoadBalancer Alteon LoadBalancer
Dummy LB Dummy LB
Each load balancer can have existing virtual IP addresses defined to it. When
ITITO is operational, it will create and delete virtual IPs as it provisions servers
into application clusters on demand.
Load balancers can also be used as switches. In this case, they will need to be
defined as switches in “Switches” on page 10.
Chapter 2. Planning 13
28. Virtual IPs
Any pre-existing virtual IPs can be defined to ITITO if required, although they will
usually take no part in the demonstration. The information required is shown in
the following table:
Table 2-17 Virtual IP data collection skeleton
Virtual IP Load Virtual IP First input Last input Output
name balancer address port in range port in range port
Each application cluster (see 2.3.5, “Applications and customers” on page 16)
that ITITO is to provision automatically will need a unique virtual IP definition for
the cluster.
2.3.3 Software
Software configuration in ITITO is divided into three categories:
Software package
Software patch
Software stack
We address each of these in the following sections.
Software package
Each single piece of software or data that the customer’s applications require to
be provisioned must be defined to ITITO as a software object. This typically
includes operating systems, databases, middleware, applications, data, and so
on.
For each software package that is to be automatically deployed, it is necessary
to collect the following information:
Table 2-18 Software package data collection skeleton
Software name Version Type Package path Install path
14 Pre Proof-of-Concept Cookbook for Business Partners
29. 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
30. 2.3.4 Spare pools
If the customer has pools of spare servers already available for their applications,
information about the names, connections, and types of these machines needs
to be determined and entered in the following tables. If the customer does not
have any existing pools of machines, for the demonstration, a number of servers
will need to be defined to create a spare pool. The customer should be advised
that this is a fundamental principle behind ITITO.
These pools require the following definitions:
Table 2-21 Spare pool network data collection skeleton
Spare pool name VLAN Switch fabric
Any number of servers can be defined for each pool with the following attributes:
Table 2-22 Spare pool data collection skeleton
switch module
interface card
Connected to
Connected to
Server name
switch port
Spare pool
Connected
IP address
MAC addr.
Managed
to switch
Network
name
For ITITO to operate correctly with pooled servers, we strongly advise that each
server has at least two network interface cards (NICs), one of which is dedicated
to the management LAN. If any NIC has multiple IP addresses, these should be
recorded here, too.
MAC addresses are optional for the demonstration, but will show up as unknown
in the GUI if not specified.
2.3.5 Applications and customers
In this section, it is necessary to gather information about the various
applications that a customer wants to provision with ITITO. The basic data
16 Pre Proof-of-Concept Cookbook for Business Partners
31. required is shown in the following table. For a demonstration, at least two
applications should be defined.
Table 2-23 Customer/application data collection skeleton
Customer name or
Application Priority Application cluster
business unit
Each ITITO implementation can have many customers defined, each of which
can have multiple applications, each of which can have multiple application
clusters. An application cluster is defined to be a set of servers that provide the
same service to an application. The servers are expected to be virtual clones of
each other. The priority of each application should be set according to the
following table:
Table 2-24 Application priority data collection example
Service plan Priority Interpretation
Platinum Better priority service
Gold Medium priority service
Silver 10 Poorer priority service
Each application cluster requires the following additional definitions:
Table 2-25 Cluster information data collection skeleton
Application
Virtual IP
Managed
balancer
servers
servers
cluster
Switch
fabric
VLAN
Load
Max.
Pool
Min.
Chapter 2. Planning 17
32. In this table, Pool is the server pool from which the application cluster provisions
and returns servers (resource pool). Each application cluster can be managed or
unmanaged. This value should be set to true or false. If the cluster is
unmanaged, ITITO will make no attempt to provision servers for this cluster.
Typically, this option is used for clusters that provide database facilities. It is
usually desirable to show these clusters in the ITITO GUI, but not to actually
make changes to them automatically. The Load Balancer column is used to
identify the load balancer that is associated with the cluster’s servers. The Virtual
IP column refers to the virtual IPs defined in “Virtual IPs” on page 14.
Note: It is also possible to configure the service level agreement properties:
maximum response time and maximum time available. We recommend that
you talk about this during the demonstration.
If any cluster has any dedicated servers assigned to it (and usually there will be
at least one), these must also be defined. The data required for these is shown in
the following table:
Table 2-26 Cluster network data collection skeleton
Application
Connected
Connected
Connected
IP address
Managed
to switch
to switch
to switch
interface
Network
address
module
cluster
Server
name
MAC
card
port
For servers that are permanently assigned to a cluster, the network interface
cards should usually not be managed by ITITO. As with pool servers, the MAC
addresses are optional, but will show up as unknown in the GUI if not specified.
18 Pre Proof-of-Concept Cookbook for Business Partners
33. 2.3.6 Other devices
ITITO supports a number of other data center management devices including:
Boot servers
Terminal servers
Blade center management servers
These devices might be essential for the operation of a data center, but do not
really play any part in a demonstration of ITITO. If it is desirable to show the
configuration and that the product supports these devices, they should be
included.
Boot servers
If any servers are to be provisioned by bare-metal builds, it will be necessary to
define a boot server for each set of servers that are configured to use the same
boot server. Boot servers require the following information to be defined:
Table 2-27 Boot server data collection skeleton
Name Manufacturer Software IP address Device model
Each boot server can also have a network interface card and network interfaces
as with other servers in spare pools and clusters:
Table 2-28 Boot server network information collection skeleton
Connected
Connected
Connected
IP address
MAC addr.
Managed
to switch
to switch
to switch
interface
Network
module
server
name
Boot
card
port
The following boot servers are valid devices in ITITO Version 1.1:
Table 2-29 Boot servers supported by ITITO V1.1
Manufacturer Software Device model
Rembo Auto-Deploy Rembo Boot Server
IBM Remote Deployment Manager RDM Server
Chapter 2. Planning 19
34. IBM Network Installation Manager NIM Server
IBM zVM Boot Server zVM Boot Server
IBM Cluster Systems Management CSM Management Server
Sun Jump Start JumpStart Server
HP Rapid Deployment Pack RDP Server
If a boot server is used to deploy an operating system, this attribute can be
added to the corresponding software stack for the operating system. This is
optional for the demonstration.
Table 2-30 Boot server/operating system data collection skeleton
Software stack name Boot server
Terminal servers
Terminal servers can be defined to ITITO like boot servers except that there are
no supplied device drivers for terminal servers in Version 1.1 of the product:
Table 2-31 Terminal server data collection skeleton
Name IP address
Network interface cards and network interfaces can be defined as with other
servers:
Table 2-32 Terminal server network information data collection skeleton
Connected
Connected
Connected
IP address
MAC addr.
Managed
to switch
to switch
to switch
interface
Terminal
Network
module
server
name
card
port
20 Pre Proof-of-Concept Cookbook for Business Partners
35. Blade center management servers
Each blade system is managed by a central management server that controls all
aspects of the blade servers. ITITO uses the blade center management server to
perform operations on the blade servers such as reboot, power on, and
reconfiguration. If the customer uses blade servers, it might be desirable to show
the blade center management server, although the demonstration will make no
visible changes to the blade center management server itself. The blade center
management server can be defined like the boot server and terminal servers:
Table 2-33 Blade center management server data collection skeleton
Name Manufacturer Software IP address Device model
The following blade systems have device drivers in Version 1.1 of ITITO:
Table 2-34 Blade center management servers supported by ITITO V1.1
Manufacturer Blade system Device model
RLX Technologies ServerBlades RLX Blade Server
HP Proliant Blade Servers Proliant BL Server
Network interface cards and network interfaces can also be defined if required:
Table 2-35 Blade server network information data collection skeleton
Connected
Connected
Connected
IP address
MAC addr.
to Switch
Managed
to switch
to switch
interface
Network
module
server
Blade
name
card
port
Servers in spare pools or in clusters can be associated with the relevant blade
center management server. This information can be appended to servers in the
relevant spare pools and clusters:
Chapter 2. Planning 21
36. 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 Pre Proof-of-Concept Cookbook for Business Partners
37. The files provided with this document are described in 4.3, “Sample XML files” on
page 91.
Chapter 2. Planning 23
38. 24 Pre Proof-of-Concept Cookbook for Business Partners
40. 3.1 Installation process overview
Our installation scenario is to be considered as an example only. The following
are the names of both servers used during the installation process. These names
most likely should be changed to the naming standards of the customer.
The server hosting both the IBM DB2 Server and the IBM Directory server will
be named TIOdbsrv.
The server hosting the IBM Tivoli Intelligent ThinkDynamic Orchestrator
server will be named TIOsrv.
The following table provides the recommended hardware for each server. This is
the hardware we used in the ITSO lab environment and we recommend it as a
minimum configuration.
Note: The values provided in the following table may differ form the
information provided in the IBM Tivoli Intelligent Orchestrator and Tivoli
Provisioning Manager Release Notes, SC32-1422. They represent the
hardware used at the time of writing this Redpaper and serve as our
recommendation for a minimum of a two server configuration.
Table 3-1 Recommended hardware for Windows 2000 Server
IBM Compatible Server:
2.4 GHz Intel Pentium® processor or equivalent
2GB RAM
30 GB disk
The following table provides a list of the various products that will need to be
installed and configured on each server during the installation procedure per
operating system. Please note that both servers must be running the same
operating system.
Table 3-2 Required software - Windows 2000
TIOdbsrv TIOsrv
Windows 2000 Server Windows 2000 Server
Cygwin Version 1.3.22 – or later Cygwin Version 1.3.22 – or later
IBM DB2 Universal Database™ IBM DB2 Universal Database V8.1.2 Client
Workgroup Unlimited Edition V8.1.2
IBM Directory Server, V5.1 IBM Directory Server V5.1 Client
26 Pre Proof-of-Concept Cookbook for Business Partners
41. TIOdbsrv TIOsrv
IBM WebSphere Application Server Base
Edition V5.0.1
IBM WebSphere Application Server Base
Edition V5.0.1 Client
IBM Tivoli Intelligent ThinkDynamic
Orchestrator V1.1.0
The following picture provides an overview of the entire installation process and
can be used as reference during the installation.
Phase 1 Define the User IDs
Define user tioadmin user ID with Administrator / root authority on both servers
Define user tioldap user ID with Administrator / root authority on both servers
UNIX only: define the mqm user ID in the mqm group. Also create mqbrkrs group TIO TIO
and ensure that tioadmin, root and mqm users IDs belongs to it.
Database Server
Server
Phase 2 Prepare SSH communications
Install all the prerequisite packages for SSH communication between Servers (CygWin for
SSH
Windows, openssh for AIX) on both Servers
Configure SSH and generate a RSA key on the TIO Server TIO
Configure SSH on the TIO database Server Server
Copy the RSA key to the TIO database Server TIO
Test SSH communication from the TIO Server to the TIO database Server Database
Repeat the process for all servers in the Data Center to be managed by IBM Tivoli Intelligent Server
ThinkDynamic Orchestrator
Phase 3 Prepare the TIO database Server
Data source
LDAP DB
Install the remaining prerequisite packages
Install IBM DB2 Universal Database Workgroup Unlimited Edition V8.1.2
Create the database to be used by IBM Tivoli Intelligent ThinkDynamic Orchestrator
Populate the database using the provided tablesapce.sql file Central Data
TIO Warehouse
TIO DB
Install IBM Directory Server, V5.1 Database
Create the LDAP database and configure IBM Directory Server, V5.1 with the provided suffixes Server
and ldap.ldif file
Verify the installation
Phase 4 Prepare the TIO Server
Data source
LDAP DB
Install the remaining prerequisite packages
Install IBM DB2 Universal Database V8.12 Client
Install IBM Directory Server V5.1 Client TIO
Install IBM Websphere Application Server Base Edition V5.0 Server
Central Data
Install IBM Websphere Application Server Base Edition V5.0 Fixpack 1 Warehouse
TIO DB
TIO
Apply the MQ CSD03 patch to IBM Websphere Database
Apply the MQ fixes for embedded messaging to IBM WebSphere (IY43610 and IY44803) Server
Install IBM Websphere Application Server Base Edition V5.0 Client
Install IBM Tivoli Intelligent ThinkDynamic Orchestrator V1.1.0
Verify the installation
Figure 3-1 ITITO installation overview
Chapter 3. Installing the demonstration systems 27
42. 3.1.1 Recommended installation directories
The following table provides a list of recommended installation directories for
each product used during the installation process. Note that file paths containing
spaces must not be used, as it will cause problems during the installation and
configuration process.
Table 3-3 Recommended installation directories
Product Installation Directory
Cygwin Version 1.3.22 c:cygwin
IBM DB2 Universal Database Workgroup c:IBMsqllib
Unlimited Edition V8.1.2
IBM Directory Server, V5.1 c:IBMldap
IBM DB2 Universal Database V8.12 Client c:IBMsqllib
IBM Directory Server V5.1 Client c:IBMldap
IBM WebSphere Application Server Base c:IBMWebSphereAppServer
Edition V5.0.1
IBM WebSphere Application Server Base c:IBMWebSphereAppClient
Edition V5.0.1 Client
IBM Tivoli Intelligent ThinkDynamic c:cygwinhomethinkcontrol
Orchestrator V1.1.0
3.1.2 User IDs and passwords
The following table illustrates the user IDs that will be either created during the
application install process or created by you, the implementer, before the actual
install process begins.
Table 3-4 User IDs and passwords
User name Password Description Comment
tioadmin <user defined> Used to log onto the OS This user ID must be
to install IBM Tivoli created manually on
Intelligent both servers prior to
ThinkDynamic the installation
Orchestrator
28 Pre Proof-of-Concept Cookbook for Business Partners
43. User name Password Description Comment
tioldap <user defined> Used by IBM Tivoli This user ID must be
Intelligent created manually on
ThinkDynamic the machine hosting
Orchestrator to connect the IBM Directory
to the Directory Server Server prior to the
installation
tiodb <user defined> This user ID will be the Created during the
instance owner of the IBM DB2 installation
IBM Tivoli Intelligent on the server hosting
ThinkDynamic the IBM Tivoli
Orchestrator database Intelligent
ThinkDynamic
Orchestrator
database
mqm <user defined> Used by WebSphere This user ID must be
MQ created manually on
both servers prior to
the installation
wasadmin wasadmin Used by WebSphere as Defined
administration account automatically by the
WebSphere
installation process
tioappadmin tioappadmin This is the IBM Tivoli Defined on the
Intelligent Directory Server
ThinkDynamic automatically by the
Orchestrator IBM Tivoli Intelligent
superadmin and is used ThinkDynamic
to log into the Web Orchestrator
console installation process
tiointernal internal Used by IBM Tivoli Defined on the
Intelligent Directory Server
ThinkDynamic automatically by the
Orchestrator for system IBM Tivoli Intelligent
initiated actions ThinkDynamic
Orchestrator
installation process
cn=root <user defined> root user ID for the IBM Created during the
Directory LDAP Server IBM Directory
installation process
Chapter 3. Installing the demonstration systems 29
44. 3.2 Installing and configuring TIOdbsrv - Windows
In this section we describe the steps to setup the machine hosting database and
the LDAP directory used by the IBM Tivoli Intelligent ThinkDynamic Orchestrator
on Microsoft Windows 2000 Server. The high level install steps are presented in
the following figure.
Create tioadmin user
id
Create tioldap user id
Download and install
Cygwin
Install and configure
DB2
Install and configure
IBM Directory Server
Figure 3-2 TIOdbsrv installation steps
The following sections explain each step of the above flow in detail.
3.2.1 Creating the required user IDs
Create a local user accounts tioadmin and tioldap as follows:
1. Under Computer Management choose System Tools -> Local users and
groups -> Users and add the users tioadmin and tioldap.
2. Select the newly created users and make both of them members of the
Administrators group.
3. Select the user ID tioadmin and set its Local Path to:
C:Cygwinhomethinkcontrol
4. Select the user ID tioldap and set its Local Path to:
C:IBMldap
30 Pre Proof-of-Concept Cookbook for Business Partners
45. 3.2.2 Installing and configuring Cygwin
Cygwin is used as an Open SSH environment for the IBM Tivoli Intelligent
ThinkDynamic Orchestrator application to communicate with all other
applications through the use of Cygwin’s BASH Shell and can be obtained at the
following URL:
http://www.cygwin.com/
Ensure you are logged on to the TIOdbsrv machine using the tioadmin user
account specified above.
Attention: Cygwin Version 1.3.22 or higher must be installed. At the time of
writing this Redpaper, Cygwin Version 1.5.5-1 was the current version
available for downloading and it was used during our install process.
Important: Before you download Cygwin ensure you are logged on using the
tioadmin user account specified above and that the tioadmin user has the
correct profile properties and is a member of Administrators.
1. Open a browser and go the Cygwin home page: http://www.cygwin.com
Select the Install or Update now! option.
2. Choose to open the setup.exe application from its current location
3. The Cygwin Setup window starts the installation wizard, select Next
4. Select Install from Internet
5. Accept default installation directory (C:Cygwin), All Users and DOS options
6. Accept default Package directory
7. Choose the appropriate internet settings. We selected Direct Connection.
8. Select a FTP site from the available list
9. During the Cygwin installation, on the Select Package panel, it is important to
select the correct Categories. The installation wizard provides a series of
pre-selected packages as default for installation. However, IBM Tivoli
Intelligent ThinkDynamic Orchestrator requires additional packages under the
Lib and Net categories. The following table describes the required packages
that need to be installed in addition the default selection. To select those
packages, click the + sign of the Libs and Net categories, and click the Skip
button next to the desired package to change the installation option from Skip
to Install.
Chapter 3. Installing the demonstration systems 31
46. Tip: We recommend selecting and installing all of the Cygwin packages.
Additional Cygwin packages
Cygwin Package Action
Libs Accept default packages PLUS Regex
Net Accept default packages PLUS OpenSSH and OpenSSL
10.When the installation completes, select to create icon on desktop. Select
Finish.
3.2.3 Configuring SSH communications
When the Cygwin installation completes click on the Cygwin icon to open a bash
shell window and perform the following steps to configure SSH:
Important: Verify that all servers in your configuration are setup correctly in
either DNS and or /etc/hosts.
1. Move to the /usr/bin directory and issue the host configuration ssh-host-config
command, as shown in the following example. When prompted for
environment variables, press Enter to accept the defaults.
$ cd /usr/bin
$ ./ssh-host-config -y
Generating /etc/ssh_host_key
Generating /etc/ssh_host_rsa_key
Generating /etc/ssh_host_dsa_key
Generating /etc/ssh_config file
Privilege separation is set to yes by default since OpenSSH 3.3.
However, this requires a non-privileged account called 'sshd'.
For more info on privilege separation read
/usr/doc/openssh/README.privsep.
Warning: The following function requires administrator privileges!
Generating /etc/sshd_config file
Added ssh to /cygdrive/c/WINNT/system32/drivers/etc/services
Added ssh to /etc/inetd.conf
Do you want to install sshd as service?
Which value should the environment variable CYGWIN have when
sshd starts? It's recommended to set at least "ntsec" to be
able to change user context without password.
Default is "binmode ntsec tty". CYGWIN=
The service has been installed under LocalSystem account.
32 Pre Proof-of-Concept Cookbook for Business Partners
47. 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
Chapter 3. Installing the demonstration systems 33
48. Type the config file. The output should read as follows:
StrictHostKeyChecking no
8. To verify that SSH is configured properly, try to access your own machine
using the ssh command as shown in the following example.
$ ssh tioadmin@localhost
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
Fanfare!!!
You are successfully logged in to this server!!!
$ exit
logout
Connection to localhost closed.
3.2.4 Installing and configuring IBM DB2 UDB V8.1.2 on Windows
This section describes the installation and configuration of IBM DB2 Universal
Database, Workgroup Unlimited Edition V8.1.2 on Windows. It also shows the
required configuration steps required by IBM Tivoli Intelligent ThinkDynamic
Orchestrator.
Note: Ensure you perform the IBM DB2 installation logged on as tioadmin.
Use the DB2 installation media provided with the IBM Tivoli Intelligent
ThinkDynamic Orchestrator product. This ensures that you get the correct
version and level of DB2 installed.
1. Logged on as tioadmin, move to the drive where the IBM DB2 CD is mounted
and run the setup.exe command to start the installation. From the installation
window, select Install Product.
2. Select the product we want to install: IBM DB2 Workgroup Server Unlimited
Edition and click Next.
3. The Welcome to the DB2 Setup wizard window opens. Click Next.
4. Accept the License Agreement by selecting I accept the terms in the
license agreement option.
5. The Select the installation type window opens. Select the Custom Install
option.
6. Select Install DB2 Workgroup Server Unlimited Edition on this computer.
7. The Select features window opens, as shown in the next figure. Select the
following packages:
– Client support
– Administration tools
– Server support
34 Pre Proof-of-Concept Cookbook for Business Partners
49. Also select the installation path. Ensure there are no spaces in the installation
path. We used C:IBMSQLLIB.
Figure 3-3 Select DB2 Server components
8. Choose Language of choice - English is default.
9. The Set user information for DB2 Administration Server window open, as
shown in next figure. Here you have to specify the user ID tiodb as it will be
the instance owner of the IBM Tivoli Intelligent ThinkDynamic Orchestrator
database. The user ID tiodb will be created with the proper authority by the
DB2 installation process. Make sure you record the password as you will be
prompted for this password during the IBM Tivoli Intelligent ThinkDynamic
Orchestrator installation.
Chapter 3. Installing the demonstration systems 35
50. 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 Pre Proof-of-Concept Cookbook for Business Partners
51. C:IBMSQLLIBBIN>d: <-- This is the CDROM drive
D:>cd db2license
D:>db2licm -a ./db2wsue.lic
DBI1402I License added successfully.
DBI1426I This product is now licensed for use as specified in the
License Acceptance and License Information documents pertaining to the
licensed copy of this product. USE OF THE PRODUCT CONSTITUTES
ACCEPTANCE OF THE TERMS OF THE IBM LICENSE ACCEPTANCE AND LICENSE
INFORMATION DOCUMENTS, LOCATED IN THE FOLLOWING DIRECTORY:
"C:IBMSQLLIBlicenseen"
19.Reboot the system
Create database and database schema
After installing IBM DB2 perform the following steps to create the database and
the database schema used by IBM Tivoli Intelligent ThinkDynamic Orchestrator.
Important: You must logon to your system using the tiodb user ID to be
successful with the DB2 configuration.
1. Logon to the system as the tiodb user ID.
2. Open a DB2 command window.
3. Create the database for IBM Tivoli Intelligent ThinkDynamic Orchestrator by
entering the following command:
db2 create database <db_name>
Where, <db_name> is the name of the database you want to create.
Make sure the database name follow the DB2 naming conventions and that
you record it as you will require it when installing IBM Tivoli Intelligent
ThinkDynamic Orchestrator.
You can confirm the creation of the database by issuing the following
command:
db2 list database directory
C:IBMSQLLIBBIN>db2 create database ITITODB
DB20000I The CREATE DATABASE command completed successfully.
C:IBMSQLLIBBIN>db2 list database directory
System Database Directory
Number of entries in the directory = 2
Database 1 entry:
Database alias = ITITODB
Database name = ITITODB
Database drive = C:DB2
Database release level = a.00
Comment =
Chapter 3. Installing the demonstration systems 37