Front cover
Composite Application
Provisioning with IBM Tivoli
Provisioning Manager V3.1
Understand the Tivoli Provisioning
Manager software model
Automate the creation of
virtualized resources
Control the
application clusters
Morten Moeller
ibm.com/redbooks
Redpaper
International Technical Support Organization
Composite Application Provisioning with IBM Tivoli
Provisioning Manager V3.1
November 2006
Note: Before using this information and the product it supports, read the information in
“Notices” on page xvii.
First Edition (November 2006)
This edition applies to Version 3, Release 1, Modification 03 of IBM Tivoli Provisioning Manager
(product number 5724-L09) and IBM Tivoli Intelligent Orchestrator (product number 5724-L10).
This document created or updated on November 22, 2006.
© Copyright International Business Machines Corporation 2006. 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
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
The objective of this workshop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
The technical environment of the workshop. . . . . . . . . . . . . . . . . . . . . . . . . . xxii
An outline of the exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv
Chapter 1. Exercise 1: Introducing the IBM Tivoli Intelligent Orchestrator
V3.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 The objective of this exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Verifying the Tivoli Intelligent Orchestrator operations . . . . . . . . . . . . . . . . 2
1.2.1 Verifying the Tivoli Intelligent Orchestrator’s operational status . . . . . 2
1.2.2 Logging in to the Tivoli Intelligent Orchestrator Server system . . . . . . 2
1.2.3 Verifying the connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.4 Starting the Tivoli Intelligent Orchestrator Server . . . . . . . . . . . . . . . . 5
1.2.5 Signing in to the Tivoli Intelligent Orchestrator console . . . . . . . . . . . 7
Chapter 2. Exercise 2: Preparing the environment . . . . . . . . . . . . . . . . . . 11
2.1 The objective of this exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Importing the IBM Software University automation packages . . . . . . . . . . 12
2.2.1 Importing the tcdriver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Chapter 3. Exercise 3: Discovering and configuring the data center
infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1 Setting up a NetView discovery policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.1 Shortcut: Defining the NetView discovery technology. . . . . . . . . . . . 17
3.1.2 Exercise: Creating the NetView discovery technology . . . . . . . . . . . 17
3.2 Discovering the servers and the network infrastructure . . . . . . . . . . . . . . 19
3.2.1 Shortcut: Executing a discovery technology . . . . . . . . . . . . . . . . . . . 20
3.2.2 Exercise: Discovering the resources . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.3 Viewing the discovered resources . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.4 Accepting and ignoring the changes . . . . . . . . . . . . . . . . . . . . . . . . . 24
© Copyright IBM Corp. 2006. All rights reserved.
iii
3.3 Defining the access points and the credentials . . . . . . . . . . . . . . . . . . . . . 26
3.3.1 Shortcut: Setting the credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.2 Exercise: Defining the credentials. . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Installing the Tivoli Common Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.1 Shortcut: Installing the Tivoli Common Agent . . . . . . . . . . . . . . . . . . 31
3.4.2 Exercise: Installing the Tivoli Common Agent . . . . . . . . . . . . . . . . . . 32
3.5 Discovering the server hardware and software . . . . . . . . . . . . . . . . . . . . . 37
3.5.1 Viewing the hardware resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5.2 Viewing the software resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Chapter 4. Exercise 4: Configuring the SWU networking environment . . 41
4.1 The objective of this exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.1 Shortcut: Creating the network objects . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Defining the networking components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1 Exercise: Defining the network objects . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Defining the virtual local area networks. . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.1 Exercise: Defining the virtual local area networks. . . . . . . . . . . . . . . 46
4.4 Defining the subnets and the switches . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.1 Exercise: Defining the subnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5 Switch definitions for the SWU environment . . . . . . . . . . . . . . . . . . . . . . . 48
4.5.1 Exercise: Defining a switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6 Defining firewalls for the SWU environment . . . . . . . . . . . . . . . . . . . . . . . 50
4.6.1 Exercise: Defining a firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.7 Verifying the network infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Chapter 5. Exercise 5: Configuring the SWU provisioning infrastructure 53
5.1 The objective of this exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.1 Shortcut: Boot server and file repository . . . . . . . . . . . . . . . . . . . . . . 55
5.2 Creating a simulated boot server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2.1 Shortcut: Creating a boot server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2.2 Exercise: Defining a boot server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3 Defining the SWU_FileRepository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3.1 Shortcut: Creating a file repository . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3.2 Exercise: Defining a file repository . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.4 Verifying the provisioning infrastructure components . . . . . . . . . . . . . . . . 62
Chapter 6. Exercise 6: Preparing the software-related objects for the
Pristine systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.1 The objective of this exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.1.1 Shortcut: Pristine pool, server template, and software . . . . . . . . . . . 67
6.2 The SWU Windows 2000 Server SP4 software definitions . . . . . . . . . . . . 69
6.2.1 Shortcut: Creating an operating system . . . . . . . . . . . . . . . . . . . . . . 69
6.2.2 Exercise: Defining the operating system . . . . . . . . . . . . . . . . . . . . . . 70
6.3 Importing the software objects for the installation of IBM Java Runtime
iv
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
Environment V1.4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.3.1 Exercise: Importing the SWU IBM Java Runtime 1.4.1
software objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.4 Creating the SWU_Pristine_Server_Stack . . . . . . . . . . . . . . . . . . . . . . . . 79
6.4.1 Shortcut: Defining the SWU_Pristine_Server_Stack. . . . . . . . . . . . . 79
6.4.2 Exercise: Creating the SWU_Pristine_Server_Stack . . . . . . . . . . . . 80
6.5 Creating the SWU_Pristine_Server_Pool . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.5.1 Creating the SWU_Pristine_Server_Template . . . . . . . . . . . . . . . . . 85
6.5.2 Exercise: Creating the Pristine Server Template . . . . . . . . . . . . . . . 86
6.5.3 Shortcut: Defining the SWU_Pristine_Server_Pool . . . . . . . . . . . . . 87
6.5.4 Exercise: Creating the SWU_Pristine_Server_Pool . . . . . . . . . . . . . 88
6.6 Verifying the creation of the objects for the Pristine servers . . . . . . . . . . . 89
Chapter 7. Exercise 7: Creating virtual servers . . . . . . . . . . . . . . . . . . . . . 91
7.1 The objective of this exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.1.1 Shortcut: Creating the host platform server and the Virtual Server
Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.2 Creating a host platform server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.2.1 Shortcut: Creating the host platform server . . . . . . . . . . . . . . . . . . . 97
7.2.2 Exercise: Defining the host platform server . . . . . . . . . . . . . . . . . . . 98
7.3 Creating the server template for the operating system installation . . . . . 102
7.3.1 Shortcut: Creating the SWU_New_Windows_Server_Template . . 103
7.3.2 Exercise: Defining the SWU_New_Windows_Server_Template . . 103
7.4 Creating the Virtual Server Template . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.4.1 Shortcut: Creating the Virtual Server Template . . . . . . . . . . . . . . . 107
7.4.2 Exercise: Defining the Virtual Server Template . . . . . . . . . . . . . . . 108
7.5 Creating the virtual servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.5.1 Shortcut: Creating the virtual servers . . . . . . . . . . . . . . . . . . . . . . . 111
7.5.2 Exercise: Defining the virtual servers . . . . . . . . . . . . . . . . . . . . . . . 111
7.6 Verifying the creation of the virtual servers . . . . . . . . . . . . . . . . . . . . . . . 114
Chapter 8. Exercise 8: Defining the composite application infrastructure
environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
8.1 The objective of this exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
8.1.1 Shortcut: Creating all the infrastructure software objects . . . . . . . . 122
8.2 Creating the SWU_DB2_Server_Stack. . . . . . . . . . . . . . . . . . . . . . . . . . 123
8.2.1 Shortcut: Creating the DB2 software definitions and the
SWU_DB2_Server_Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
8.2.2 Exercise: Creating a software definition for the DB2 Server using the
wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
8.2.3 Exercise: Creating a software stack . . . . . . . . . . . . . . . . . . . . . . . . 132
8.3 Creating the SWU_WAS_Server_Stack . . . . . . . . . . . . . . . . . . . . . . . . . 134
8.3.1 Shortcut: Create WebSphere Application Server software definitions
Contents
v
and SWU_WAS_Server_Stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
8.4 Creating software definitions for the application server. . . . . . . . . . . . . . 136
8.4.1 Exercise: Manually creating the application layer software objects 136
8.5 Creating the software definitions for the database client. . . . . . . . . . . . . 140
8.6 Creating a software stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
8.7 Creating the SWU_HTTP_Server_Stack . . . . . . . . . . . . . . . . . . . . . . . . 145
8.7.1 Shortcut: Creating the SWU_HTTP_Server_Stack . . . . . . . . . . . . . 146
8.7.2 Exercise: Defining the SWU_HTTP_Server_Stack . . . . . . . . . . . . . 146
8.8 Installing the prerequisite software on the host platform server . . . . . . . 149
8.8.1 Shortcut: Installing the software on the SWU_HostPlatformServer 149
8.8.2 Exercise: Installing the SWU IBM Java Runtime Environment and
registering the SWU IBM Hypertext Transfer Protocol Server . . . . 150
8.9 Verifying the infrastructure software definitions. . . . . . . . . . . . . . . . . . . . 158
Chapter 9. Exercise 9: Defining the composite application software . . 161
9.1 The objective of this exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
9.1.1 Shortcut: Creating all the composite application software objects . 164
9.2 Creating the SWU_Composite_Database_Stack . . . . . . . . . . . . . . . . . . 165
9.2.1 Shortcut: Creating the composite application database layer software
definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
9.2.2 Exercise: Creating the SWU Composite Database Module software
definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
9.3 Exercise: Creating the software stack . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
9.4 Reviewing the SWU_Composite_Application_Stack. . . . . . . . . . . . . . . . 173
9.5 Creating the SWU_Composite_Application_Stack . . . . . . . . . . . . . . . . . 175
9.5.1 Shortcut: Creating the composite application layer
software definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
9.5.2 Exercise: Manually defining the application layer software objects 176
9.6 Reviewing the SWU_Composite_Application_Stack. . . . . . . . . . . . . . . . 177
9.7 Creating the SWU_Composite_Web_Stack . . . . . . . . . . . . . . . . . . . . . . 178
9.7.1 Shortcut: Creating the composite application Web layer software
definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
9.7.2 Exercise: Manually defining the composite application Web layer
software objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
9.8 Reviewing the SWU_Composite_Web_Stack . . . . . . . . . . . . . . . . . . . . . 180
9.8.1 The software product: SWU Composite Web Module. . . . . . . . . . . 180
9.8.2 The software package: SWU Composite Web Module Server
Configuration Installable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
9.8.3 The software package: SWU Composite Web Module Server Pages
Installable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
9.8.4 The SWU_Composite_Web_Stack . . . . . . . . . . . . . . . . . . . . . . . . . 186
9.9 Verifying the infrastructure software definitions. . . . . . . . . . . . . . . . . . . . 187
9.10 Exercise: Installing the SWU composite software products . . . . . . . . . 187
vi
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
Chapter 10. Exercise 10: Defining the composite application load balancer
and the virtual IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
10.1 The objective of this exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
10.1.1 Shortcut: Creating a load balancer and a virtual IP. . . . . . . . . . . . 196
10.2 Defining and initializing the SWU_LoadBalancer . . . . . . . . . . . . . . . . . 197
10.2.1 Shortcut: Creating the load balancer. . . . . . . . . . . . . . . . . . . . . . . 198
10.2.2 Exercise: Defining the load balancer. . . . . . . . . . . . . . . . . . . . . . . 199
10.3 Adding the www.swu.com virtual IP to the load balancer . . . . . . . . . . . 201
10.3.1 Shortcut: Creating a virtual IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
10.3.2 Exercise: Defining a virtual IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
10.4 Verifying the load balancer configuration . . . . . . . . . . . . . . . . . . . . . . . 203
Chapter 11. Exercise 11: Defining the SWU composite application
production environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
11.1 The objective of this exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
11.1.1 Shortcut: Creating composite application tiers and templates . . . 209
11.2 Creating a customer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
11.2.1 Exercise: Defining the SWU_Customer . . . . . . . . . . . . . . . . . . . . 210
11.3 Creating an application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
11.3.1 Exercise: Defining the SWU_Composite_Application . . . . . . . . . . 211
11.4 Creating the application tier for the database layer . . . . . . . . . . . . . . . . 212
11.4.1 Exercise: Defining the SWU_Composite_Database_Tier . . . . . . . 212
11.4.2 Exercise: Defining the SWU_Composite_Database_Template . . 213
11.5 Creating the tier for the application layer. . . . . . . . . . . . . . . . . . . . . . . . 215
11.5.1 Exercise: Defining the SWU_Composite_Application_Template . 216
11.5.2 Exercise: Defining the SWU_Composite_Application Tier . . . . . . 216
11.6 Creating the tier for the Web layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
11.6.1 Exercise: Defining the SWU_Composite_Web_Tier . . . . . . . . . . . 217
11.6.2 Exercise: Defining the SWU_Composite_Web_Template . . . . . . 218
11.6.3 Verifying the production environment . . . . . . . . . . . . . . . . . . . . . . 220
Chapter 12. Exercise 12: Defining the cluster domain for the Web layer223
12.1 The objective of this exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
12.2 Creating the cluster domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
12.2.1 Shortcut: Creating the cluster domain . . . . . . . . . . . . . . . . . . . . . . 227
12.3 Defining the SWU_Composite_VIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
12.3.1 Shortcut: Creating the cluster domain virtual IP . . . . . . . . . . . . . . 228
12.3.2 Exercise: Defining the cluster domain virtual IP . . . . . . . . . . . . . . 229
12.4 Creating the cluster domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
12.4.1 Shortcut: Creating the cluster domain . . . . . . . . . . . . . . . . . . . . . . 229
12.4.2 Exercise: Defining the SWU_Composite_Web_ClusterDomain . . 230
12.5 Verifying the cluster domain definition. . . . . . . . . . . . . . . . . . . . . . . . . . 231
12.5.1 Exercise: Verifying the cluster domain definitions . . . . . . . . . . . . . 231
Contents
vii
Chapter 13. Exercise 13: Deploying the composite application . . . . . . . 235
13.1 The objective of this exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
13.2 Deploying the application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
13.2.1 Exercise: Changing the maintenance mode . . . . . . . . . . . . . . . . . 236
13.2.2 Exercise: Viewing the recommendations . . . . . . . . . . . . . . . . . . . 237
13.2.3 Exercise: Setting the operation mode for a tier . . . . . . . . . . . . . . . 237
13.2.4 Exercise: Using the automatic operation mode. . . . . . . . . . . . . . . 238
13.2.5 Exercise: Using the semiautomatic operation mode . . . . . . . . . . . 241
13.2.6 Exercise: Using the manual operation mode . . . . . . . . . . . . . . . . 243
Appendix A. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
System requirements for downloading the Web material . . . . . . . . . . . . . 250
How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
viii
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
Figures
1-1 Starting VMware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1-2 The SWU2006-3759 VMware image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1-3 The SWU2006-3759 desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1-4 Starting the Tivoli Intelligent Orchestrator using TIO_Start . . . . . . . . . . . . . 5
1-5 Opening the Services window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1-6 Signing in to the Tivoli Intelligent Orchestrator . . . . . . . . . . . . . . . . . . . . . . 7
1-7 The Tivoli Intelligent Orchestrator console . . . . . . . . . . . . . . . . . . . . . . . . . 8
1-8 The Tivoli Intelligent Orchestrator help environment. . . . . . . . . . . . . . . . . 10
2-1 SWU workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3-1 The tutorial logical networking infrastructure. . . . . . . . . . . . . . . . . . . . . . . 15
3-2 Defining the discovery technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3-3 NetView discovery technology policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3-4 Running NetView discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3-5 NetView discovery task execution confirmation . . . . . . . . . . . . . . . . . . . . 21
3-6 NetView discovery successful execution . . . . . . . . . . . . . . . . . . . . . . . . . 22
3-7 The network resources discovered by NetView . . . . . . . . . . . . . . . . . . . . 23
3-8 Changes discovered by NetView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3-9 Discovered subnets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3-10 Subnet change accepted and defined to the DCM . . . . . . . . . . . . . . . . . 25
3-11 Discovered resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3-12 Creating an SSH host service access point . . . . . . . . . . . . . . . . . . . . . . 28
3-13 Adding RSA credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3-14 New RSA authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3-15 Service Access Point device driver associations . . . . . . . . . . . . . . . . . . 29
3-16 Setting default access points for standard operations . . . . . . . . . . . . . . 30
3-17 Defining the client service access point . . . . . . . . . . . . . . . . . . . . . . . . . 30
3-18 Service access points required to communicate with a server using SSH31
3-19 Selecting targets for the Tivoli Common Agent installation . . . . . . . . . . . 33
3-20 Defining credentials for the Common Agent installation . . . . . . . . . . . . . 34
3-21 Common Agent Installation summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3-22 Common Agent installation task running. . . . . . . . . . . . . . . . . . . . . . . . . 35
3-23 Searching for objects by name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3-24 Tivoli Common Agent variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3-25 Tivoli Common Agent credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3-26 The discovered network interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3-27 The discovered hardware resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3-28 Hardware resource details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3-29 The discovered software resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
© Copyright IBM Corp. 2006. All rights reserved.
ix
4-1 Networking exercise: Starting and ending environments . . . . . . . . . . . . . 42
4-2 VLAN definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4-3 Subnet definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4-4 Blocking the IP ranges for the subnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4-5 Subnet inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4-6 Adding a switch definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4-7 Assigning router capabilities to a switch . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4-8 Switch interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4-9 Adding a switch that will host the firewall . . . . . . . . . . . . . . . . . . . . . . . . . 51
4-10 Switch interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4-11 SWU tutorial network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5-1 Provisioning infrastructure implementation: Starting and ending
environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5-2 Defining a boot server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5-3 Boot server interface parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5-4 Boot server device driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5-5 File repository properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5-6 File repository interface parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5-7 File repository device driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5-8 Verifying boot server creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5-9 Verifying file repository creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6-1 Software preparation: Starting point and goal. . . . . . . . . . . . . . . . . . . . . . 64
6-2 Virtual server: Basic software components . . . . . . . . . . . . . . . . . . . . . . . . 65
6-3 SWU Windows 2000 Server SP4 software image properties . . . . . . . . . . 70
6-4 SWU Windows 200 Server SP4 OS properties. . . . . . . . . . . . . . . . . . . . . 71
6-5 Linking the SWU Windows 2000 SP4 image to the operating system . . . 71
6-6 SWU Windows 2000 SP4 operating system installables . . . . . . . . . . . . . 71
6-7 SWU 2000 Server SP4 OS capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6-8 SWU Windows 2000 SP4 OS capability summary . . . . . . . . . . . . . . . . . . 73
6-9 Categorizing the SWU Windows 2000 SP4 OS . . . . . . . . . . . . . . . . . . . . 73
6-10 SWU Windows 2000 Server SP4 installation template . . . . . . . . . . . . . . 74
6-11 Pristine software resource template . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6-12 Creating a template parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6-13 Software resource template with parameters . . . . . . . . . . . . . . . . . . . . . 75
6-14 Creating a software stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6-15 Adding predefined requirement values . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6-16 IBM Java Runtime V1.4.1 software components . . . . . . . . . . . . . . . . . . 77
6-17 The SWU_Pristine_Server_Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6-18 Searching for software definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6-19 Selecting a software resource template when adding a stack entry . . . . 81
6-20 Software stack entry with customized parameters . . . . . . . . . . . . . . . . . 82
6-21 Software stack with one software definition . . . . . . . . . . . . . . . . . . . . . . 82
6-22 Software stack with multiple entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
x
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
6-23 Adding an iterator to the software stack . . . . . . . . . . . . . . . . . . . . . . . . . 84
6-24 Creating the SWU_Pristine_Server_Template . . . . . . . . . . . . . . . . . . . . 86
6-25 Associating a software stack to a template . . . . . . . . . . . . . . . . . . . . . . . 86
6-26 SWU_Pristine_Server_Template properties . . . . . . . . . . . . . . . . . . . . . . 87
6-27 Creating the SWU_Pristine_Server_Pool . . . . . . . . . . . . . . . . . . . . . . . . 88
6-28 Listing the SWU_Pristine objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7-1 Virtual server creation: Starting and ending environments . . . . . . . . . . . . 93
7-2 Creating a host platform server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
7-3 Host platform server: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
7-4 Host platform server: Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7-5 Host platform server: Management interface . . . . . . . . . . . . . . . . . . . . . . 99
7-6 Host platform server: Shared NIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7-7 Associating the OS with the host platform server . . . . . . . . . . . . . . . . . . 101
7-8 Host platform server: Software properties. . . . . . . . . . . . . . . . . . . . . . . . 101
7-9 Host platform server: Device driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7-10 Creating a new server template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7-11 Assigning VLAN to the server template . . . . . . . . . . . . . . . . . . . . . . . . 104
7-12 Associate subnet with VLAN in server template . . . . . . . . . . . . . . . . . . 104
7-13 The server template interface definitions . . . . . . . . . . . . . . . . . . . . . . . 105
7-14 Adding the software stack to the server template . . . . . . . . . . . . . . . . . 105
7-15 Server template properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7-16 The server template device driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7-17 Virtual Server Templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7-18 Virtual Server Template properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7-19 Adding resource requirements to the Virtual Server Template . . . . . . . 109
7-20 Virtual Server Template with new resource requirements . . . . . . . . . . 109
7-21 Virtual Server Template variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7-22 Creating a new virtual server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7-23 Virtual server inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7-24 Virtual servers hosted by the SWU_HostPlatformServer . . . . . . . . . . . 114
7-25 Servers (virtual) in the SWU_Pristine_Server_Pool . . . . . . . . . . . . . . . 115
7-26 Virtual server hardware properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
7-27 Virtual server software associations . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8-1 Application infrastructure implementation: Starting and
ending environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
8-2 SWU_DB2_Server_Stack software components . . . . . . . . . . . . . . . . . . 123
8-3 Import Software Package: Welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
8-4 Import Software Package: Define Software Product . . . . . . . . . . . . . . . . 125
8-5 Import Software Package: Select Package. . . . . . . . . . . . . . . . . . . . . . . 125
8-6 Import Software Package: Choose Installation Method . . . . . . . . . . . . . 126
8-7 Import Software Package: Fill properties . . . . . . . . . . . . . . . . . . . . . . . . 126
8-8 Import Software Package: Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
8-9 SWU Software Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Figures
xi
8-10
8-11
8-12
8-13
8-14
8-15
8-16
8-17
8-18
SWU IBM DB2 Server V8.2 capabilities . . . . . . . . . . . . . . . . . . . . . . . . 128
SWU IBM DB2 Server 8.2 properties . . . . . . . . . . . . . . . . . . . . . . . . . . 129
SWU IBM DB2 Server 8.2 requirements definitions . . . . . . . . . . . . . . . 130
SWU IBM DB2 Server 8.2 requirements . . . . . . . . . . . . . . . . . . . . . . . . 130
SWU IBM DB2 Server V8.2 properties . . . . . . . . . . . . . . . . . . . . . . . . . 131
Creating the SWU_DB2_Server_Stack. . . . . . . . . . . . . . . . . . . . . . . . . 132
SWU_DB2_Server_Stack properties . . . . . . . . . . . . . . . . . . . . . . . . . . 133
SWU_WAS_Server_Stack software components . . . . . . . . . . . . . . . . . 134
Creating the SWU IBM WebSphere Application Server
software product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
8-19 SWU IBM WebSphere Application Server V5.1 capabilities . . . . . . . . . 137
8-20 Associating a software installable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
8-21 Defining a new requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
8-22 Adding a Configuration Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
8-23 Resource templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
8-24 The SWU WebSphere Application Server software stack . . . . . . . . . . 144
8-25 SWU_HTTP_Server_Stack software components . . . . . . . . . . . . . . . . 145
8-26 SWU IBM HTTP Server V2.0 configuration templates . . . . . . . . . . . . . 147
8-27 Using external references in a software resource template . . . . . . . . . 148
8-28 SWU_HostPlatformServer software inventory . . . . . . . . . . . . . . . . . . . 150
8-29 Initializing a software installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
8-30 Software installation: Select Software. . . . . . . . . . . . . . . . . . . . . . . . . . 151
8-31 Software installation: Select Configuration Template . . . . . . . . . . . . . . 152
8-32 Software installation: Customize Template . . . . . . . . . . . . . . . . . . . . . . 152
8-33 Software installation: Select Targets. . . . . . . . . . . . . . . . . . . . . . . . . . . 153
8-34 Software installation: Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
8-35 Software installation: Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
8-36 Software installation: Task Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
8-37 Software installation: Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
8-38 Registering the software installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
8-39 Software inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
8-40 SWU_HostPlatformServer infrastructure software inventory . . . . . . . . 158
8-41 Virtual servers’ hardware inventory. . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
9-1 Composite application components: Starting and ending environments 162
9-2 Composite application software components . . . . . . . . . . . . . . . . . . . . . 163
9-3 SWU_Composite_Database_Stack logical structure . . . . . . . . . . . . . . . 165
9-4 SWU_Composite_Database_Stack properties . . . . . . . . . . . . . . . . . . . . 172
9-5 SWU_Composite_Application_Stack structure . . . . . . . . . . . . . . . . . . . . 173
9-6 SWU Composite Database Installation SRT. . . . . . . . . . . . . . . . . . . . . . 174
9-7 SWU_Composite_Application_Stack logical layout . . . . . . . . . . . . . . . . 175
9-8 The SWU_Composite_Application_Stack . . . . . . . . . . . . . . . . . . . . . . . . 177
9-9 SWU_Composite_Web_Stack logical layout . . . . . . . . . . . . . . . . . . . . . 178
9-10 SWU Composite Web Module requirements and capabilities. . . . . . . . 181
xii
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
9-11 SWU HTTP Installation with PlantsByWebSphere Instance configuration
template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
9-12 SWU Composite Web server installables . . . . . . . . . . . . . . . . . . . . . . . 183
9-13 SWU Composite Web Module Server Configuration
Installable properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
9-14 SWU Composite Web Module Server Configuration Installable device
driver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
9-15 Updating interface properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
9-16 Making an interface managed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
9-17 SWU_HostPlatformServer software inventory . . . . . . . . . . . . . . . . . . . 189
9-18 Sample Web page provisioned by Tivoli Intelligent Orchestrator . . . . . 190
9-19 Removing the SWU Composite Application Module installation . . . . . . 191
10-1 Load balancer and virtual IP definition: Starting and
ending environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
10-2 Load-balanced network infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . 195
10-3 Defining a new SWU_LoadBalancer . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
10-4 SWU_LoadBalancer interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
10-5 Initializing the Load Balancer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
10-6 Adding a virtual IP to RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
10-7 AddVIPtoRIP task execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
10-8 Load balancer with virtual IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
10-9 Connect to load balancer host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
10-10 Select the load balancer host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
10-11 Load balancer properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
11-1 Defining the production environment’s starting and ending points . . . . 208
11-2 Defining the SWU_Customer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
11-3 SWU_Composite Application properties . . . . . . . . . . . . . . . . . . . . . . . . 211
11-4 The SWU_Database_Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
11-5 Server template for the SWU_Database_Tier. . . . . . . . . . . . . . . . . . . . 213
11-6 Adding an NIC to the template VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . 214
11-7 Associating the new interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
11-8 Associating a software stack to the tier template . . . . . . . . . . . . . . . . . 214
11-9 The SWU_Composite_Database_Template . . . . . . . . . . . . . . . . . . . . . 215
11-10 Associating a server template with a tier. . . . . . . . . . . . . . . . . . . . . . . 218
11-11 Supplying an application VIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
11-12 SWU_Composite_Application properties . . . . . . . . . . . . . . . . . . . . . . 220
11-13 Application infrastructure overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
12-1 Cluster domain definition: Starting and ending environments . . . . . . . . 224
12-2 Clustering the network infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . 225
12-3 Defining the cluster domain virtual IP . . . . . . . . . . . . . . . . . . . . . . . . . . 229
12-4 Adding a cluster domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
12-5 Initializing the cluster domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
12-6 Removing a server from a cluster domain . . . . . . . . . . . . . . . . . . . . . . 232
Figures
xiii
12-7 Linking a cluster domain to an application tier . . . . . . . . . . . . . . . . . . . 232
13-1 Recommendations for the SWU_Composite_Application . . . . . . . . . . . 237
13-2 Changing the operation mode of an application tier . . . . . . . . . . . . . . . 238
13-3 Server deployment in progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
13-4 Successful deployment of a server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
13-5 Server assigned to SWU_Composite_Database_Tier . . . . . . . . . . . . . 240
13-6 Deployed server interface properties . . . . . . . . . . . . . . . . . . . . . . . . . . 240
13-7 Deployed server software inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
13-8 Accepting the deployment recommendations . . . . . . . . . . . . . . . . . . . . 241
13-9 Tracking the semiautomated deployment . . . . . . . . . . . . . . . . . . . . . . . 242
13-10 Server deployed to the SWU_Composite_Application_Tier . . . . . . . . 242
13-11 Deploying servers manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
13-12 Manual deployment of two servers in progress. . . . . . . . . . . . . . . . . . 243
13-13 Server inventory during deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 244
13-14 Datacenter overview with servers deployed . . . . . . . . . . . . . . . . . . . . 245
13-15 Deployed cluster resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
13-16 Starting and stopping the cluster resources . . . . . . . . . . . . . . . . . . . . 246
13-17 SWU_Composite_Application server allocation . . . . . . . . . . . . . . . . . 247
13-18 Deprovisioning servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
xiv
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
Tables
3-1 NetView discovery technology variables. . . . . . . . . . . . . . . . . . . . . . . . . . 18
3-2 Password credentials for the SWU environment. . . . . . . . . . . . . . . . . . . . 33
4-1 Networking properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6-1 SWU Windows 2000 SP4 OS capabilities . . . . . . . . . . . . . . . . . . . . . . . . 72
6-2 IBM JRE V1.4.1 software resource templates . . . . . . . . . . . . . . . . . . . . . 79
8-1 SWU IBM DB2 Server 8.2 capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . 128
8-2 SWU IBM WebSphere Application Server V5.1 capabilities . . . . . . . . . . 137
8-3 DB2 Client configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
8-4 HTTP Server configuration templates and their intended use . . . . . . . . 147
9-1 SWU Composite Database Module software product definition . . . . . . . 167
9-2 SWU Composite Database software package definition. . . . . . . . . . . . . 168
9-3 SWU Composite Database software resource template definition . . . . . 169
10-1 SWU_LoadBalancer variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
10-2 Virtual IP variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
11-1 SWU_Database_Tier properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
11-2 SWU_Composite_Application_Template properties . . . . . . . . . . . . . . . 216
11-3 SWU_Composite_Application_Tier properties . . . . . . . . . . . . . . . . . . . 216
11-4 SWU_Composite_Web_Tier properties . . . . . . . . . . . . . . . . . . . . . . . . 217
11-5 SWU_Composite_Web_Template properties . . . . . . . . . . . . . . . . . . . . 218
© Copyright IBM Corp. 2006. All rights reserved.
xv
xvi
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
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 illustrate 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.
© Copyright IBM Corp. 2006. All rights reserved.
xvii
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
DB2®
ibm.com®
Redbooks (logo)
™
DB2 Universal Database™
NetView®
Tivoli®
eServer™
pSeries®
WebSphere®
IBM®
Redbooks™
zSeries®
The following terms are trademarks of other companies:
Enterprise JavaBeans, Java, JavaBeans, JDBC, JRE, and all Java-based trademarks are trademarks of
Sun Microsystems, Inc. in the United States, other countries, or both.
Internet Explorer, Windows Server, Windows, and the Windows logo are trademarks of Microsoft
Corporation in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
xviii
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
Preface
This IBM® Redpaper reproduces the Exercise Guide that was a part of a
three-hour workshop on introducing IBM Provisioning Composite Applications
using IBM Tivoli® Provisioning Manager V3.1 delivered at the IBM 2006
Software University.
By reading through and performing these exercises, you get a quick, self-paced
introduction to the Tivoli Provisioning Manager concepts. You also gain insight
into the software model and the cluster management functions of the Tivoli
Provisioning Manager V3.1.
Throughout this tutorial, references are made to scripts and workflows that were
made available to the students during the workshop. You can download these
resources from the World Wide Web. For more details, refer to Appendix A,
“Additional material” on page 249.
The intent of publishing this workshop material, originally intended for a "live"
audience, is to demonstrate the key capabilities of Tivoli Provisioning Manager
and provide examples on how to design and develop workflows and automation
packages to support the automation of particular steps in the server provisioning
process.
The objective of this workshop
The objective of this tutorial is to transform a stand-alone system containing an
embedded virtual VMware-based IBM Tivoli Intelligent Orchestrator server
system into a provisioning environment that is capable of automatically
provisioning and deprovisioning a composite application infrastructure, including
multiple, clustered instances of the IBM Hypertext Transfer Protocol (HTTP)
Server hosted on virtual servers, in order to support the varying demands for
application-hosting resources.
© Copyright IBM Corp. 2006. All rights reserved.
xix
Figure 1 shows the end result of completing this tutorial successfully.
Figure 1 An overview of the tutorial
As you complete the individual exercises in this tutorial, you gradually build all
the Tivoli Intelligent Orchestrator infrastructure components required to create
the provisioning environment.
xx
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
The model composite application, which is the target of this tutorial, is a
standard, three-layered application system that is made up of a Web layer, an
application layer, and a database layer (Figure 2).
Figure 2 Sample architecture of a composite application
Because of the restrictions present in a tutorial environment, most of the
resources used to implement the composite application are simulated. However,
the software implementation of a load balancer and the implementation of the
Web servers is provided in order to allow you to realize that a subset of the
provisioning operations actually performs tasks that are similar to that seen in a
production environment.
Preface
xxi
The technical environment of the workshop
The environment required to complete this workshop is depicted in Figure 3.
Figure 3 The SWU tutorial environment
xxii
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
In addition, the SWU_2006.tcdriver and the ITSO_Utilities.tcdriver files required
to complete this tutorial have been loaded on the desktop in the Tivoli Intelligent
Orchestrator (TIO) Server system.
Important: If you plan to set up an environment similar to that described in
this IBM Redpaper, follow these guidelines:
򐂰 Ensure that IP names are used throughout the configuration of IBM DB2®,
IBM Directory Server, and Tivoli Intelligent Orchestrator.
򐂰 Before reinit, ensure that the IP address of the Tivoli Intelligent
Orchestrator Server corresponds to the value of the IP Address parameter
in the %TIO_Home%\xml\tpmserver.xml file, and that a blocked range
statement is added to the subnetwork definition in the tpmserver.xml file.
This statement must be similar to:
<blocked-range from="192.168.1.1" to="192.168.1.199" />
򐂰 Ensure host name resolution in the hosts file
򐂰 Set c:\cygwin\bin as the first directory of the PATH on all the systems
򐂰 If Edge Server - Load Balancer is installed, add the following two lines at
the beginning of the %systemroot%\system32\dscontrol.cmd file:
set path=%SYSTEMROOT%;%SYSTEMROOT%\system32;%PATH%
set IBMLBPATH="C:\ibm\edge\lb"
An outline of the exercises
When you perform the exercises in this tutorial, you will become acquainted with
the tasks that must be performed to set up the automated provisioning of a
composite application from the beginning. The exercises described in this
workshop cover the following main areas:
򐂰 Introduction and setup: Exercise 1 and Exercise 2
򐂰 Building the provisioning infrastructure: Exercise 3 - 7
򐂰 Defining the composite application components: Exercise 8 - 10
򐂰 Defining the components for on-demand provisioning: Exercise 11 and
Exercise 12
򐂰 Deploying the composite application: Exercise 13
Preface
xxiii
Following is a brief outline of each of the exercises:
򐂰 “Exercise 1: Introducing the IBM Tivoli Intelligent Orchestrator V3.1”
This includes starting the Tivoli Intelligent Orchestrator, verifying the
operation, logging in, and becoming acquainted with the user interface
򐂰 “Exercise 2: Preparing the environment” on page 11
This includes importing and verifying the tutorial-specific files
򐂰 “Exercise 3: Discovering and configuring the data center infrastructure” on
page 15 (optional)
This includes using the Tivoli Intelligent Orchestrator’s discovery functions to
populate the data center model
򐂰 “Exercise 4: Configuring the SWU networking environment” on page 41
This includes defining the virtual local area networks (VLANs), subnets,
switches, and other networking objects
򐂰 “Exercise 5: Configuring the SWU provisioning infrastructure” on page 53
This includes defining the supporting resources such as boot servers and file
repositories
򐂰 “Exercise 6: Preparing the software-related objects for the Pristine systems”
on page 63
This includes defining the basic software objects for the operating system
(OS) and the Java™ Runtime Environment (JRE™), and creating the server
templates for the Pristine systems
򐂰 “Exercise 7: Creating virtual servers” on page 91
This includes defining the host platform server and creating the virtual servers
򐂰 “Exercise 8: Defining the composite application infrastructure environment” on
page 119
This includes creating software objects for the IBM HTTP Server, the IBM
WebSphere® Server, and the IBM DB2 Server
򐂰 “Exercise 9: Defining the composite application software” on page 161
This includes creating and verifying the software objects for the composite
application modules
򐂰 “Exercise 10: Defining the composite application load balancer and the virtual
IP” on page 193
This includes defining the load balancing setup for the composite application
xxiv
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
򐂰 “Exercise 11: Defining the SWU composite application production
environment” on page 207
This includes defining the composite application structure for Tivoli Intelligent
Orchestrator and creating the server templates for each layer
򐂰 “Exercise 12: Defining the cluster domain for the Web layer” on page 223
This includes defining and verifying the cluster domain definitions for the
application layer
򐂰 “Exercise 13: Deploying the composite application” on page 235
This includes performing and verifying provisioning
Throughout this tutorial, shortcuts (automated procedures to accomplish the
objectives of an exercise) are provided to help you easily complete the exercises
that focus on the topics you have already mastered.
Become a published author
Join us for a two-week 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 will have the opportunity to team
with IBM technical professionals, business partners, and clients.
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you will 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 IBM Redpaper or other IBM Redbooks™ in one of the following ways:
򐂰 Use the online Contact us review IBM Redbook form found at:
ibm.com/redbooks
򐂰 Send your comments in an e-mail to:
redbooks@us.ibm.com
Preface
xxv
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
xxvi
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
1
Chapter 1.
Exercise 1: Introducing the
IBM Tivoli Intelligent
Orchestrator V3.1
This exercise helps you to become familiar with the exercises environment and
teaches you about how to start the Tivoli Intelligent Orchestrator (TIO) Server.
© Copyright IBM Corp. 2006. All rights reserved.
1
1.1 The objective of this exercise
The objective of this exercise is to help you verify the operational status of the
Tivoli Intelligent Orchestrator Server, sign in, and become familiar with the user
interface.
After you complete this exercise, the Tivoli Intelligent Orchestrator Server is
started, and you can log in to the Tivoli Intelligent Orchestrator user interface,
and perform basic navigation in the user interface.
1.2 Verifying the Tivoli Intelligent Orchestrator
operations
Before starting the exercises, verify whether the Tivoli Intelligent Orchestrator is
running on your system, and whether it is configured correctly. The following
exercises are designed to help you accomplish this.
1.2.1 Verifying the Tivoli Intelligent Orchestrator’s operational status
To start the Tivoli Intelligent Orchestrator Server that is hosted on the
SWU2006-3759 VMware image (where SWU stands for IBM Software
University), open the VMware image from the task bar in your tutorial system.
VMware must start automatically in the tutorial machine that is running the local
Windows® OS, and the SWU2006-3759 image must already be running.
1.2.2 Logging in to the Tivoli Intelligent Orchestrator Server system
To log in to the Tivoli Intelligent Orchestrator Server system hosted by the
VMware SWU2006-3759 image, perform the following tasks:
1. Open the VMware application from the task bar at the bottom of your window
by double-clicking the VMware Workstation icon (Figure 1-1).
Figure 1-1 Starting VMware
If the VMware application is not displayed in the window, click it in the task
bar to maximize it.
2
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
2. The VMware image for the tutorial exercises runs in the VMware application.
There is only one tab, SWU2006-3759, in the VMware application window, as
shown in Figure 1-2. Click the SWU2006-3759 tab to get to the TIOServer
system.
Figure 1-2 The SWU2006-3759 VMware image
Chapter 1. Exercise 1: Introducing the IBM Tivoli Intelligent Orchestrator V3.1
3
3. Press Ctrl+Alt+Insert (instead of Ctrl+Alt+Delete) to log in to the TIOServer as
tioadmin with the password smartway, if you have not logged in already. After
you log in, the desktop of the TIOServer system must be visible (Figure 1-3).
Figure 1-3 The SWU2006-3759 desktop
1.2.3 Verifying the connectivity
Now that you have successfully logged in to the Tivoli Intelligent Orchestrator
Server system, verify the connectivity between the tutorial system and the Tivoli
Intelligent Orchestrator Server system by performing the following tasks:
1. From the Tivoli Intelligent Orchestrator Server command line, issue the
following command:
ping <hostsystem>.tivdemo.com
4
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
Verify whether the name can be resolved, and whether the host system
server responds. The address of the host system server is expected to be
192.168.1.21.
Repeat the process using the IP name of tioserver.tivdemo.com and verify
whether your Tivoli Intelligent Orchestrator Server can resolve its own name.
The address of the TIOServer is expected to be 192.168.1.1.
2. From the command line on the host system, issue the following command:
ping hostsystem.tivdemo.com
Verify whether the name can be resolved, and whether the host system
server responds. The address of the host system server is expected to be
192.168.1.21.
Repeat the process using the IP name of tioserver.tivdemo.com and verify
whether the host system can resolve the name of the Tivoli Intelligent
Orchestrator server. The address of the TIOServer is expected to be
192.168.1.1.
3. Issue the exit command to close the command line.
1.2.4 Starting the Tivoli Intelligent Orchestrator Server
To start the Tivoli Intelligent Orchestrator server, perform the following tasks:
1. Click the SWU2006-3759 tab on the VMware application window to go to the
Tivoli Intelligent Orchestrator Server system.
2. Double-click the TIO_Start icon on the Tivoli Intelligent Orchestrator Server
desktop to start the Tivoli Intelligent Orchestrator. TIO_Start is a batch file that
invokes a script to start the IBM WebSphere Application Server and the Tivoli
Intelligent Orchestrator services, including the Web application, the
deployment engine, and the policy engines. The TIO_Start window is
displayed. It takes a few minutes for the Tivoli Intelligent Orchestrator to start
(Figure 1-4).
Figure 1-4 Starting the Tivoli Intelligent Orchestrator using TIO_Start
Chapter 1. Exercise 1: Introducing the IBM Tivoli Intelligent Orchestrator V3.1
5
a. When waiting for the TIO_Start process to be completed, click the Service
icon in the task bar of the Tivoli Intelligent Orchestrator Server or select
Start → Programs → Administrative Tools → Services to open the
Services window (Figure 1-5).
Figure 1-5 Opening the Services window
b. Scroll down the list of services that are installed. Note that DB2-DB2 and
IBM Tivoli Directory Server V5.2 (also known as LDAP) services are
automatically started when the system is started. These are the
prerequisite software for the Tivoli Intelligent Orchestrator. Additionally,
note that IBM WebSphere Application Server V5, IBM_TIO, is not started
automatically.
3. When the TIO_Start window automatically closes, it means that the Tivoli
Intelligent Orchestrator Server is started. In order to verify the status of the
services, open a command line and enter the following command:
%TIO_HOME%\tools\enginestatus all
This displays the status of the three Tivoli Intelligent Orchestrator engines.
The output is similar to that shown in Example 1-1.
Example 1-1 Status of the three Tivoli Intelligent Orchestrator engines
C:\ibm\tivoli\thinkcontrol\tools>%TIO_HOME%\tools\enginestatus all
2005-12-27 12:27:12,017 INFO COPCOM421I The deployment engine is
started.
2005-12-27 12:27:15,772 INFO COPCOM423I The policy engine is
started.
2005-12-27 12:27:18,716 INFO COPCOM484I The agent shell server is
started.
If the status indicates that none of the servers is started, use the Tivoli
Intelligent Orchestrator Stop icon to stop the Tivoli Intelligent Orchestrator
Server, and wait for the Tivoli Intelligent Orchestrator Stop window to close.
Then, repeat step 2 to start the Tivoli Intelligent Orchestrator again. (Such a
situation may occur in systems with resource constraints, such as a tutorial
system.) The second time around, the Tivoli Intelligent Orchestrator starts
successfully.
4. Minimize the VMware application window on the local desktop.
6
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
1.2.5 Signing in to the Tivoli Intelligent Orchestrator console
After the Tivoli Intelligent Orchestrator Server and all its engines are started, you
can begin to use the Tivoli Intelligent Orchestrator browser-based user interface.
To do this, sign in to the Tivoli Intelligent Orchestrator by performing the tasks
steps described here:
1. Start the Internet Explorer® from the tutorial system’s desktop. For
performance reasons, it is recommended that you use a local tutorial system
rather than the VMware image.
2. To access the Tivoli Intelligent Orchestrator user interface, specify the
following URL in the Address field of the Internet Explorer, and press Enter:
http://TIOServer.tivdemo.com:9080/tcWebUI
3. The Tivoli Intelligent Orchestrator Sign On window appears (Figure 1-6).
Enter tioappadmin as the User ID, and tioappadmin as the Password. Click
Log On.
Figure 1-6 Signing in to the Tivoli Intelligent Orchestrator
Chapter 1. Exercise 1: Introducing the IBM Tivoli Intelligent Orchestrator V3.1
7
4. This signs you into the Tivoli Intelligent Orchestrator. The Welcome page
(Figure 1-7) shows that you have signed in as tioappadmin.
Header pane
Logoff
Quick find input
field
Help
Home
Quick find
result pane
Product and
Session pane
Navigation pane
Content pane
Command input
field
Status line
Figure 1-7 The Tivoli Intelligent Orchestrator console
The Tivoli Intelligent Orchestrator user interface consists of the following main
areas:
– The product and session pane
This is the top section of the Welcome page, where you see the product
logo, version information, the user ID (the First Name and the Last Name
fields displayed from the LDAP directory), and the following icons:
•
•
•
Home
Help
Log Off
– The navigation pane
This is the left panel in the Tivoli Intelligent Orchestrator user interface.
From here, you can easily access all the data center assets and resources
known to the Tivoli Intelligent Orchestrator.
– The content pane
This is the right panel in the Tivoli Intelligent Orchestrator user interface.
The Welcome page is displayed after you sign in to the Tivoli Intelligent
8
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
Orchestrator or when you click the Home icon in the upper right corner of
the window. The Welcome page highlights the following:
•
Customer applications
This refers to the applications being managed by the Tivoli Intelligent
Orchestrator.
•
Resource pools
This refers to the standby capacity that can be assigned to
applications.
•
Switch fabrics
This is the network topology underpinning all the network elements
between the applications and the resource pools.
•
Execution history
This is a dynamic query that displays the workflow history when the
browser is opened.
– The command input field
This is used to submit the SOAP commands to the Tivoli Intelligent
Orchestrator, and is located at the bottom of the window. It has the
Command field and the History options.
If you do not see this area, log out and log in again. (To log out, click Log
Off.)
Chapter 1. Exercise 1: Introducing the IBM Tivoli Intelligent Orchestrator V3.1
9
5. Click Help to open the Tivoli Intelligent Orchestrator Online Help. Navigate to
Intelligent Orchestrator → Product overview → Architecture and look at
the main components on the left panel of the Help System (Figure 1-8).
Figure 1-8 The Tivoli Intelligent Orchestrator help environment
6. Close the Help window when you are done.
This concludes the verification of the Tivoli Intelligent Orchestrator’s operational
status and overview exercise. You can now import the workflows and the device
drivers for the SWU environment.
10
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
2
Chapter 2.
Exercise 2: Preparing the
environment
In order to complete the exercises, import a set of data center model (DCM)
object definitions, scripts, and installation image archive files that are prepared
especially for this environment, into your Tivoli Intelligent Orchestrator (TIO)
system in the Tivoli Intelligent Orchestrator Server.
© Copyright IBM Corp. 2006. All rights reserved.
11
2.1 The objective of this exercise
The objective of this exercise is to import the workflows, the device drivers, and
the help files in order to build the IBM Software University (SWU) provisioning
environment. When this exercise is complete, your DCM is populated with the
device drivers and the workflows required to complete the subsequent exercises.
2.2 Importing the IBM Software University automation
packages
In this exercise, you prepare the Tivoli Intelligent Orchestrator environment by
importing the preprepared support workflows, scripts, and Extensible Markup
Language-based (XML-based) DCM definitions.
2.2.1 Importing the tcdriver
Perform the following tasks to import the objects that are to be used in the
exercises:
1. Make the tcdriver files available to the Tivoli Intelligent Orchestrator system
by copying them from the desktop of the Tivoli Intelligent Orchestrator Server
system to the %TIO_HOME%\drivers directory. Overwrite the files that may
already exist in the target directory.
2. Import the required files for the tutorial environment by opening a
command-line interface in the TIOServer system, and issue the following
commands:
%TIO_HOME%\tools\tc-driver-manager fid ITSO_Utilities
%TIO_HOME%\tools\tc-driver-manager fid SWU_2006
These commands import the objects required to complete this exercise. After
the import is complete, the following must be present in the Tivoli Intelligent
Orchestrator Server system:
– A set of additional SWU_....tcdriver files in the %TIO_HOME%\directory
– Scripts and XML files in the %TIO_HOME%\..\SWrepository\SWU path
– Installation archives (.zip files) in the C:\SWUrepository directory
12
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
3. To verify whether the import is successful, use the navigation pane and select
Configuration → Device Drivers → SWU. This must display 11 device
driver objects with names starting with SWU, which were imported from the
tcdriver files (Figure 2-1). All these device drivers contain links to the
workflows that provide specific implementation functionality of the logical
device operations for each type of device to be supported in the SWU
environment.
Figure 2-1 SWU workflows
In addition, a number of XML files are placed in the
%TIO_HOME%\..\SWrepository\SWY\xml directory during the import.
Optionally, you can list these on the Tivoli Intelligent Orchestrator Server
system using the Internet Explorer.
This concludes the preparation exercise. In the exercise described in Chapter 3,
“Exercise 3: Discovering and configuring the data center infrastructure” on
page 15, you define the network infrastructure for the SWU environment.
Chapter 2. Exercise 2: Preparing the environment
13
14
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
3
Chapter 3.
Exercise 3: Discovering and
configuring the data center
infrastructure
The first activity that is to be performed to customize the Tivoli Intelligent
Orchestrator (TIO) solution is to inform the system about the existing networking
infrastructure in the managed environment. In the Pristine IBM Software
University (SWU) environment, this similar to that shown in Figure 3-1.
Figure 3-1 The tutorial logical networking infrastructure
© Copyright IBM Corp. 2006. All rights reserved.
15
Defining the networking infrastructure in the data center model (DCM) can be
achieved as a combination of discovering the existing network components using
the IBM Tivoli NetView® discovery feature that is installed with the Tivoli
Intelligent Orchestrator Server, and the manual definitions for the network
components that either do not exist or cannot be discovered.
NetView is capable of discovering servers, subnets, and switches. However,
because there are no switches in the stand-alone SWU environment, NetView
helps you discover the existing servers and subnets only.
16
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
3.1 Setting up a NetView discovery policy
To discover the components in your infrastructure, define and configure a
discovery technology that points to a particular specialized component that
“knows” the object types you are looking for. After defining, execute the
discovery, and optionally, review the updates that are added to the SWU
environment.
As with other objects in the DCM, define the discovery technologies either from
the user interface or by importing a preprepared set of definitions stored in an
Extensible Markup Language (XML) file.
3.1.1 Shortcut: Defining the NetView discovery technology
An Extensible Markup Language (XML) file for defining the NetView discovery
technology is loaded into the LocalFileRepository in your TIOServer system
when the SWU_2006 tcdriver is installed. To import these definitions into your
DCM, perform one of the following tasks:
򐂰 Execute the SWU_ImportXML workflow by providing a value for the xmlFile
parameter of netviewdiscovery, either by invoking the workflow from the user
interface or by issuing the following command from the Tivoli Intelligent
Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=netviewdiscovery
򐂰 Issue the following command from a command line in the Tivoli Intelligent
Orchestrator Server system:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFile=netviewdiscovery"
Irrespective of the method in which you invoke the workflow, select
Configuration → Deployment Requests to check the status.
When the workflow execution is complete, continue to 3.2, “Discovering the
servers and the network infrastructure” on page 19.
3.1.2 Exercise: Creating the NetView discovery technology
To create the discovery technology for NetView through the user interface,
perform the following tasks:
1. Navigate to Inventory → Infrastructure Management → Discovery
Technologies → Edit → Add Technology. Provide the necessary
information, as shown in the pop-up (Figure 3-2), and click Save. To go to the
Chapter 3. Exercise 3: Discovering and configuring the data center infrastructure
17
details page of the newly defined SWU_NetView_Discovery technology,
double-click the link in the discovery technologies list.
Figure 3-2 Defining the discovery technology
2. From the General page, verify whether policies exist for each type of object
that may be discovered.
3. From the Variables page, add the variables shown in Table 3-1.
Table 3-1 NetView discovery technology variables
Name
Component
Value
netview.dir
Deployment Engine
c:/usr/ov
netview.server
Deployment Engine
TIOServer
4. From the Workflows page, assign the device driver called Discovery NetView.
18
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
5. To control the behavior of the discovery technology, go to the General page
of the SWU_NetView_Discovery discovery technology (Figure 3-3), and verify
whether the policy settings for each object type are similar to the ones shown
in Figure 3-3.
Figure 3-3 NetView discovery technology policies
These policies determine the actions that the Tivoli Intelligent Orchestrator
performs when new objects or changes to the existing objects are discovered.
Important: Ensure that both the Update Policy for Servers and the New Policy
for Subnets have been set to Track Changes, instead of the default values of
Update Device and Add Device. This is necessary to control the contents in
the DCM when operating the SWU environment.
3.2 Discovering the servers and the network
infrastructure
Before using the discovery technology to identify the existing objects in the Tivoli
Intelligent Orchestrator environment, ensure that NetView is running and
performing its share of the task well. To start the NetView service, open a
command line on the TIOServer system, and issue the following command:
net start NetView
After you receive a message indicating that the Tivoli NetView Service is started
successfully or that has already been started earlier, you are ready to start the
discovery task.
Chapter 3. Exercise 3: Discovering and configuring the data center infrastructure
19
3.2.1 Shortcut: Executing a discovery technology
A script for executing a discovery technology is loaded into the
LocalFileRepository when the SWU_2006 tcdriver is installed. To use this script,
perform one of the following tasks:
򐂰 Execute the SWU_DiscoverAll workflow by providing a value for the
discoveryName parameter of SWU_NetView_Discovery, either by invoking
the workflow from the user interface or by issuing the following command
from the Tivoli Intelligent Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_DiscoverAll
discoveryName=SWU NetView Discovery
򐂰 Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_DiscoverAll
"discoveryName=SWU_NetView_Discovery"
When the workflow execution is complete, continue to 3.3, “Defining the access
points and the credentials” on page 26.
3.2.2 Exercise: Discovering the resources
To discover the resources, perform the following tasks:
1. From the Tivoli Intelligent Orchestrator user interface, navigate to Tasks →
Discovery → Discover Devices and provide the necessary runtime
parameters in the New Discovery Task window (Figure 3-4). Provide a task
name, select the newly created SWU_NetView_Discovery technology, opt to
discover the entire network, and schedule the task to run immediately by
20
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
selecting Now. Click OK to continue and confirm the creation of the discovery
task.
Figure 3-4 Running NetView discovery
A status message similar to the one shown in Figure 3-5 is displayed, from
where you can easily access the task execution details.
Figure 3-5 NetView discovery task execution confirmation
Chapter 3. Exercise 3: Discovering and configuring the data center infrastructure
21
2. If time permits, you may want to explore the task execution windows when the
discovery is running. To verify the completion of the task, select Tasks →
Task Status, and verify whether the status of the NetView discovery task is
Succeeded, as shown in Figure 3-6.
Figure 3-6 NetView discovery successful execution
3. To conserve resources in the SWU environment, stop the Tivoli NetView
Service after successful discovery. From the command line of the Tivoli
Intelligent Orchestrator Server system, issue the following command:
net stop NetView
4. To verify the success of your operation, issue the net start command and
confirm that the Tivoli NetView Service does not appear in the list of started
services.
3.2.3 Viewing the discovered resources
The SWU_NetView_Discovery technology provides information about several
object types (servers, subnets, and switches). By modifying the discovery
policies, you control whether or not the newly discovered objects are added
automatically to the DCM.
In the Tivoli Intelligent Orchestrator user interface, information regarding the
newly discovered objects are available from several locations, most of which are
relative to the object types.
To view all the discovered objects, select Inventory → Discovered. To view the
details of an object, select the appropriate group (in this case, the servers), and
double-click the corresponding object (server). In the SWU environment, when
you select the host system server, you will see the details provided by NetView.
They should be similar to the ones shown in Figure 3-7.
22
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
Not surprisingly, the only attributes reported by the NetView Discovery
Technology are network-related, and from the information shown in Figure 3-7,
you can see that the host system server has two Network Interface Cards (NICs)
installed, with each one having an IP interface defined.
Figure 3-7 The network resources discovered by NetView
Note that the Management IP, which is the IP address, will be used whenever the
Tivoli Intelligent Orchestrator Server communicates with the target server. If this
is not assigned correctly, your Tivoli Intelligent Orchestrator Server will not be
able to successfully start any automation operations on the target server.
When you look at the Discovered Devices window (Figure 3-8), you see that only
one server is discovered.
Chapter 3. Exercise 3: Discovering and configuring the data center infrastructure
23
In the stand-alone SWU environment, you will not be able to discover any
switches. However, the environment consists of two servers (the Tivoli Intelligent
Orchestrator Server and a host system) and at least one subnet. Despite all this,
why is only one server discovered?
Figure 3-8 Changes discovered by NetView
The explanation for this discrepancy is that the Tivoli Intelligent Orchestrator
Server is already defined to the DCM, and is therefore not treated as a
discovered server. The reason for the missing information about subnets is due
to the fact that you specifically asked to control the addition of subnets to the
DCM by setting the Add Device policy to Track Changes instead of the default
Add Device. Because of this, no subnets are added automatically. However, the
subnet information is available in the Change Records window, which can be
accessed by selecting Tasks → Configuration Management → Discovered
Changes. This window shows that some new devices have been discovered.
3.2.4 Accepting and ignoring the changes
To view, and to optionally accept or reject changes, click the Edit icon to the right
side of the change record you want to work with. The window that opens
(Figure 3-9) shows that the NetView discovery actually found several subnets. At
this point in the configuration of the SWU environment, you are only interested in
the 192.168.1.0 network, and you want to permanently ignore the information
24
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
pertaining to the VMware adapters that are configured in the TIOServer system.
To permanently ignore the discovery information regarding the objects, select the
objects, set the value for the Action to apply on selected Attributes field as
Update Permanently as shown in Figure 3-9, and click Proceed.
Figure 3-9 Discovered subnets
To accept the change for the 192.168.1.0 subnet, select the subnet and set the
value for the Action to Apply on selected Attributes field as Update DCM, and
click Proceed. After accepting the update action, your Change Records window
must be similar to that shown in Figure 3-10.
Figure 3-10 Subnet change accepted and defined to the DCM
Chapter 3. Exercise 3: Discovering and configuring the data center infrastructure
25
Note: In Figure 3-10, view the values against the Resolution field for the
affected subnets and verify whether the actions you selected are applied as
expected.
After accepting the updated DCM for the discovered 192.168.1.0 subnet, go
back to Inventory → Discovered to verify whether you now have one server
and one subnet, as shown in Figure 3-11.
Figure 3-11 Discovered resources
3.3 Defining the access points and the credentials
Before proceeding with the installation of the Tivoli Common Agent, ensure that
you are able to communicate with and authenticate the discovered servers.
Note: In the Windows environment, the installation of the Tivoli Common
Agent is a relatively simple operation because the Tivoli Intelligent
Orchestrator provides a Windows Server® Message Block server, which in
turn provides the required functionality to authenticate and execute the Tivoli
Common Agent installation scripts on the target systems. However, in
non-Windows environments, manually configure the protocol (typically SSH)
and the authentication information, which is supported by the target server, in
order to install the Tivoli Common Agent.
The protocol and authentication information required to perform device
operations on an object are defined in access points. Although the SWU
environment is Windows-based, you can go ahead and define the credentials as
you would in a mixed environment.
26
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
3.3.1 Shortcut: Setting the credentials
The definition of SSH-based access points and credentials for an object in the
SWU environment may be invoked by executing a workflow, either from a
command line or from the Tivoli Intelligent Orchestrator user interface. To wrap
the parameters used in the SWU environment, a custom workflow and the script
to invoke it from a command line is provided in the SWU_2006 tcdriver in order to
allow you to easily complete the steps outlined in this section.
To create the service access points for an object, perform one of the following
tasks:
򐂰 Execute the SWU_SetDeviceCredentials workflow by providing a value for the
deviceName parameter of <deviceName> (hostsystem, SWU_FileServer, or
similar), either by invoking the workflow from the Tivoli Intelligent Orchestrator
user interface or by issuing the following command from the Tivoli Intelligent
Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0
SWU_SetDeviceCredentials deviceName=<deviceName>
򐂰 Issue the following command from the Tivoli Intelligent Orchestrator Server
system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd
SWU_SetDeviceCredentials "deviceName=<deviceName>"
When the workflow execution is complete, continue to 3.4, “Installing the Tivoli
Common Agent” on page 31.
3.3.2 Exercise: Defining the credentials
The following procedure is common to all the objects that have credentials
assigned to them. However, for servers, the Tivoli Intelligent Orchestrator
provides a wizard to help. This is available when you select Tasks → Server
Management → Add Credentials or from the Edit menu of the Credentials page
of the server object, which provides a facility to clone credentials from other
servers. The following steps outline the general procedure for creating SSH host
and client credentials:
1. Open the Credentials page of the object for which you want to create
credentials, in your case, the server host system. Select Edit → Add Access
Point. Supply the access point information such as minimum name, protocol,
and type, and click Save. For the SSH host access points in the SWU
Chapter 3. Exercise 3: Discovering and configuring the data center infrastructure
27
environment, use the values shown in Figure 3-12. The Credentials page
must now indicate that the SSH host access point is created.
Figure 3-12 Creating an SSH host service access point
2. To add authentication information for the SSH host access point, select
Edit → Add Credentials RSA (Figure 3-13).
Figure 3-13 Adding RSA credentials
28
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
3. In the New RSA authentication dialog, supply the necessary information, as
shown in Figure 3-14, and click Save.
Figure 3-14 New RSA authentication
4. To assign the actual behavior that will be invoked when using the SSH host
access point, associate a device driver by selecting Edit icon to the extreme
right, and selecting View Workflows. This displays the Workflows page of
the access point. Assign the proper device driver by selecting Edit → Assign
Device Driver.
In the SWU environment, use the SSH Service Access Point as shown in
Figure 3-15.
Figure 3-15 Service Access Point device driver associations
5. Use the browser's Back button to return to the Credentials page of the object
for which you are defining credentials. The Credentials page must look similar
to that displayed in Figure 3-16.
Chapter 3. Exercise 3: Discovering and configuring the data center infrastructure
29
Assign the default access point to be used for the predefined device
operations. In the SWU environment, the default for all valid operations,
file-transfer, execute-command, and ping, must be set to SSH host
(Figure 3-16).
Figure 3-16 Setting default access points for standard operations
6. To create the client access point for the SSH protocol, repeat steps 2 through
5. However, in step 3, use the access point information shown in Figure 3-17.
Figure 3-17 Defining the client service access point
30
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
On completion, the Credentials page should look similar to that displayed in
Figure 3-18.
Figure 3-18 Service access points required to communicate with a server using SSH
3.4 Installing the Tivoli Common Agent
The Tivoli Common Agent is a new technology provided with Tivoli Intelligent
Orchestrator V3.1. This allows for easy and secure implementation of specialized
subagents to provide support for certain functions. Upon installation, a number of
subagents that support job distribution, program execution, inventory scanning,
and more are provided. The main advantages of the Tivoli Common Agent are
transparency to operating systems and ease-of-use, because the Tivoli Common
Agent takes care of the authentication issues.
In the SWU environment, the Tivoli Common Agent is used on the two “real”
systems, the Tivoli Intelligent Orchestrator Server and the host system, in order
to automatically discover the installed hardware and software.
3.4.1 Shortcut: Installing the Tivoli Common Agent
The Tivoli Common Agent installation can be invoked by executing a workflow,
either from a command line or from the Tivoli Intelligent Orchestrator user
interface. To wrap the parameters used in the SWU environment, a custom
workflow and a script to invoke it from a command line is provided in the
SWU_2006 tcdriver. This allows you to complete the steps outlined in this
section with ease.
Chapter 3. Exercise 3: Discovering and configuring the data center infrastructure
31
To install the Tivoli Common Agent on a server perform, perform one of the
following tasks:
򐂰 Start the SWU_InstallTCA workflow, providing a value for the serverName
parameter of <serverName> (TIOServer or host system), either by starting
the workflow from the Tivoli Intelligent Orchestrator user interface or by
issuing the following command from the Tivoli Intelligent Orchestrator user
interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_TCAInstall
serverName=<serverName>
򐂰 Issue the following command from the Tivoli Intelligent Orchestrator Server
system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_TCAInstall
"serverName=<serverName>"
To install the Tivoli Common Agent on both the servers in the SWU environment,
issue one of these commands for each of the servers.
When the workflow execution is complete, continue to 3.5, “Discovering the
server hardware and software” on page 37.
3.4.2 Exercise: Installing the Tivoli Common Agent
To install the Tivoli Common Agent using the Tivoli Intelligent Orchestrator user
interface, perform the following tasks:
1. Navigate to Tasks → Server Management → Install Common Agent.
Follow the prompts to select and configure the Tivoli Common Agent on one
or more servers. After reading the introduction and continuing by clicking
Next, you are prompted to select the target systems on which you want to
32
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
install the Tivoli Common Agent. As shown in Figure 3-19, the only selected
system is named vmware01. Click Next to continue.
Figure 3-19 Selecting targets for the Tivoli Common Agent installation
Attention: By default, there are more servers defined other than your Tivoli
Intelligent Orchestrator Server and the host system server, which were
discovered. (The extra servers are defined as model servers during Tivoli
Intelligent Orchestrator installation.)
2. Specify how to authenticate against the target systems for executing the
installation scripts. In the SWU environment, use the credentials shown in
Table 3-2, in the same way they are used in Figure 3-20.
Table 3-2 Password credentials for the SWU environment
User ID
Password
Administrator
smartway
In addition to providing credentials, you can supply a name for the task to be
started (for you to easily identify this task), and decide when the installation
Chapter 3. Exercise 3: Discovering and configuring the data center infrastructure
33
must take place. In the SWU environment, it is recommended that you opt to
install immediately by selecting Now (Figure 3-20). Click Next to continue.
Figure 3-20 Defining credentials for the Common Agent installation
34
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
3. A Summary window is shown, outlining the selections. This window is similar
to that shown in Figure 3-21. Click Finish to submit the installation task at the
specified time.
Figure 3-21 Common Agent Installation summary
4. A task status panel is shown (Figure 3-22), containing the status of the newly
created Install Agent task. Refresh the information by clicking Refresh in the
top right corner.
Figure 3-22 Common Agent installation task running
Chapter 3. Exercise 3: Discovering and configuring the data center infrastructure
35
5. When the task is completed, view the server details in order to verify whether
a couple of variables have been defined for the server in question. Go to the
General page of the server and look at the Variables section.
Tip: The easiest way to obtain information regarding a particular object in
the DCM is to use the Find field at the top of the navigation pane in the top
left corner of the Tivoli Intelligent Orchestrator user interface. Enter the
entire name or a part of the object name in the Find field, click Enter, and
double-click the link that appears immediately under the Find field. See
Figure 3-23.
Figure 3-23 Searching for objects by name
6. If the Tivoli Common Agent installation is successful, two variables that can
be used to identify the Tivoli Common Agent component of the server is
created, as shown in Figure 3-24.
Figure 3-24 Tivoli Common Agent variables
You should also see the settings in the Credentials page. During the
installation of the Tivoli Common Agent, the credentials are set up for the
server in order to provide protocol and authentication information for the
server, which will be used when the Tivoli Intelligent Orchestrator Server
36
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
initiates automation operations. The credentials of a newly installed server
are similar to those shown in Figure 3-25.
Figure 3-25 Tivoli Common Agent credentials
7. Optionally, you can repeat the Tivoli Common Agent installation for the Tivoli
Intelligent Orchestrator Server by using the shortcut method described in
3.4.1, “Shortcut: Installing the Tivoli Common Agent” on page 31.
3.5 Discovering the server hardware and software
After the successful installation of the Tivoli Common Agent, your systems are
scanned to identify basic operational properties such as the operating system,
software installations, and the available hardware and network resources. The
component responsible for this is the CitScanner Tivoli Common Agent
Subagent, which is installed with the Tivoli Common Agent and can be invoked
through the CitScanner Agent Discovery Technology that is defined in the Tivoli
Intelligent Orchestrator environment during installation.
To initiate a new run of the hardware and software discovery or to even create a
task to perform scanning operations periodically, follow the procedure used for
starting NetView discovery, but use the CitScannerAgent discovery technology
instead of SWU_NetView_Discovery.
The CitScannerAgent discovers both hardware and software resources in the
scanned servers. The results can be viewed from the server using the Tivoli
Intelligent Orchestrator user interface.
Chapter 3. Exercise 3: Discovering and configuring the data center infrastructure
37
3.5.1 Viewing the hardware resources
To view the results of the scanning, go to the General page of a server and take
a closer look at the Network Resources and Hardware Resources sections.
As shown in the Network Resources section (Figure 3-26), the NetView
discovery identifies both the real and the loopback NICs on the hostsystem
system.
Figure 3-26 The discovered network interfaces
In addition, the following hardware components are found on the hostsystem
system (Figure 3-27).
Figure 3-27 The discovered hardware resources
38
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
By expanding the individual sections, you can get the details of the available
resources (Figure 3-28).
Figure 3-28 Hardware resource details
If you change the hardware resources on a server by adding, for example, more
memory, and want to make the changes known to the Tivoli Intelligent
Orchestrator immediately, instead of waiting for the next scheduled scan, add or
modify the resources directly by using the Push button to the right of each
resource.
3.5.2 Viewing the software resources
The software resources that are found are visible from the Software page of the
server. Figure 3-29 shows that the Tivoli Common Agent components that you
just installed on the target server is discovered. In addition, the scanner identifies
the correct level of the operating system (Windows 2000 Server Service Pack 4).
What happens is that the scanner looks for the software components registered
in the Windows registry, and matches these with the software identifiers loaded
into the Tivoli Intelligent Orchestrator system during installation. Also, during
installation, a number of software products, which are also known as software
Chapter 3. Exercise 3: Discovering and configuring the data center infrastructure
39
modules, are defined to the Tivoli Intelligent Orchestrator and linked to a specific
software identifier. In this case, the software image known as Windows 2000
Server SP4 is the only software product that is linked to the software identifier
found on the host system.
However, the CitAgentScanner finds 28 additional software identifiers on the
host system. These identifiers are not yet associated with a software product. At
the bottom right of the Software page (Figure 3-29), you see the text “28
unidentified software component(s)”. This represents a link to the facility to
associate software identifiers and software products. Click the link in order to
explore this.
Figure 3-29 The discovered software resources
40
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
4
Chapter 4.
Exercise 4: Configuring the
SWU networking
environment
The starting point for this exercise is a data center model (DCM) containing the
objects that are shown in the frame named A in Figure 4-1. Before proceeding to
the exercises, you must have the basic networking infrastructure defined in the
DCM.
© Copyright IBM Corp. 2006. All rights reserved.
41
4.1 The objective of this exercise
In this exercise, you define the additional networking resources required to
complete the definition of the IBM Software University (SWU) environment
objects shown in the frame named B in Figure 4-1.
After you complete this exercise, the virtual local area network (VLANs),
subnetworks, switches, routers, and firewalls that are required to support the
remaining exercises in this workshop are defined.
Figure 4-1 Networking exercise: Starting and ending environments
All the networking objects that are created reside only in the Tivoli Intelligent
Orchestrator (TIO) DCM, and are not supported by physical devices. The only
exceptions are a few IP interfaces that have already been created in the Tivoli
Intelligent Orchestrator Server system.
42
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
If you are comfortable with the idea of defining network components using the
Tivoli Intelligent Orchestrator user interface, use the shortcut described in 4.1.1,
“Shortcut: Creating the network objects” to complete all the tasks in this exercise.
4.1.1 Shortcut: Creating the network objects
A set of Extensible Markup Language (XML) files for the definition of the objects
is loaded into the LocalFileRepository in your TIOServer system on installation of
the SWU_2006 tcdriver. Following is a list of the relevant files:
򐂰
򐂰
򐂰
򐂰
vlans.xml
subnets.xml
switches.xml
firewalls.xml
All these files are referenced from the file named SWU-NET.xml.
By default, the 192.168.1.1 subnet is defined to Tivoli Intelligent Orchestrator
during installation. In order to redefine it, delete it first. Perform the following
tasks:
1. Delete the 192.168.1.1 subnet by issuing the following command from the
Tivoli Intelligent Orchestrator Server system command line:
%tio_home%\tools\dcmquerycommand
%tio_home%\..\SWrepository\SWU\xml\subnets_delete.dcm
2. To import all the network component definitions in one step, issue the
following commands from the Tivoli Intelligent Orchestrator Server system
command line:
cd %TIO_HOME%\..\SWrepository\SWU\xml
%TIO_HOME%\tools\xmlimport file:SWU_NET.xml
To import the files one-by-one and view the results in the Tivoli Intelligent
Orchestrator user interface, perform one of the following tasks for each of the
files listed earlier, and in the same sequence in which they are listed:
– Start the SWU_ImportXML workflow, providing a value for the xmlFile
parameter of <file_name>, either by starting the workflow from the user
interface or by issuing the following command from the Tivoli Intelligent
Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=<file_name>
Chapter 4. Exercise 4: Configuring the SWU networking environment
43
– Issue the following command from the Tivoli Intelligent Orchestrator
Server system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFile=<file_name>
3. (Optional step) Because of inconsistencies in Tivoli Intelligent Orchestrator
V3.1 Fix Pack 2, update the switch definitions manually in order to make the
Tivoli Intelligent Orchestrator user interface recognize that they perform a
router function or a firewall function or both. Follow the manual procedure
described in 2 on page 49 in order to assign the desired functionality to the
switch and on page 51 in order to assign the firewall functionality. (Even if you
skip this optional step, the exercises are not affected.)
After these steps are completed, continue to 4.7, “Verifying the network
infrastructure” on page 52.
4.2 Defining the networking components
To register the workshop networking infrastructure in the Tivoli Intelligent
Orchestrator DCM, complete the exercise described in 4.2.1, “Exercise: Defining
the network objects”.
4.2.1 Exercise: Defining the network objects
Although the exercises in this tutorial do not demonstrate the capabilities of Tivoli
Intelligent Orchestrator to manage VLANs and the association of specific switch
ports to specific VLANs, the definition of VLANs is included to make the tutorial
as realistic as possible.
To establish the network infrastructure, use the tools available at Inventory →
Network Infrastructure and define the objects in the following sequence:
1.
2.
3.
4.
VLANs
Subnets
Access control lists (ACLs) (not applicable in the SWU environment)
Switches
a. Routers (not applicable in the SWU environment)
b. Firewalls
Tip: When defining the switch objects, you can assign the router or the firewall
functionality or both as part of the switch definition.
44
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
The general networking attributes used in the definition of network objects in the
DCM are provided in Table 4-1.
Table 4-1 Networking properties
Name
VLAN
Subnet
Subnet mask
Blocked range
SWU_VLAN-001
001
192.168.1.0/24
255.255.255.0
192.168.1.1 - 192.168.1.199
SWU_VLAN-100
100
192.168.1.100/28
255.255.255.240
192.168.100.250 192.168.100.254
SWU_VLAN-110
110
192.168.1.110/28
255.255.255.240
192.168.110.250 192.168.110.254
SWU_VLAN-120
120
192.168.1.120/28
255.255.255.240
192.168.120.250 192.168.120.254
SWU_VLAN-130
130
192.168.1.130/28
255.255.255.240
192.168.130.250 192.168.130.254
4.3 Defining the virtual local area networks
Complete the exercise described in 4.3.1, “Exercise: Defining the virtual local
area networks” to define the five VLANs used in the SWU environment or use the
shortcut method outlined in “Shortcut: Creating the network objects” on page 43
to import the file named vlans.xml.
Chapter 4. Exercise 4: Configuring the SWU networking environment
45
4.3.1 Exercise: Defining the virtual local area networks
To define the VLANs required in the SWU environment, perform the following
tasks:
1. Navigate to Inventory → Network Infrastructure → VLANs. Use the Edit →
Add VLAN menu option multiple times and supply a name and a VLAN
number from Table 4-1. When you complete this task, your list of VLANs must
look as shown in Figure 4-2.
Figure 4-2 VLAN definitions
4.4 Defining the subnets and the switches
Complete the exercise described in 4.4.1, “Exercise: Defining the subnets” to
define the five subnets used in the SWU environment or use the shortcut method
outlined in “Shortcut: Creating the network objects” on page 43 to import the file
named subnets.xml. If you opt for the shortcut method, delete the existing
definition of the 192.168.1.1 subnet, as described in 1 on page 43.
46
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
4.4.1 Exercise: Defining the subnets
The subnets required in the SWU environment are listed in Table 4-1 on page 45.
To define these subnets, navigate to Inventory → Network Infrastructure →
Subnets. Then, for each subnet listed in Table 4-1 on page 45, perform the
following tasks:
1. In the Subnets page, use the Edit → Add Subnet menu option and supply
the required information from Table 4-1 on page 45, as shown in Figure 4-3.
Click Save.
Figure 4-3 Subnet definitions
Note: The 192.168.1.1/24 subnet that was defined in the Tivoli Intelligent
Orchestrator during installation does not have to be redefined.
2. To avoid the automatic assignment of addresses that must be reserved for
manual management, click the newly created subnet from the Switch
Inventory window. When the details appear, select the Blocked IPs page and
add the blocked range listed in Table 4-1 on page 45, as shown in Figure 4-4
and click Add.
Figure 4-4 Blocking the IP ranges for the subnet
Chapter 4. Exercise 4: Configuring the SWU networking environment
47
3. Use the browser's Back button to return to the Subnetwork Inventory window.
After all the subnets are created, the Subnet Inventory page looks similar to
that shown in Figure 4-5.
Figure 4-5 Subnet inventory
Note that a number of 10..X.X.X networks have been defined with the base
installation of Tivoli Intelligent Orchestrator. These networks are not used in
the SWU environment.
4.5 Switch definitions for the SWU environment
As depicted in Figure 4-1 on page 42, only one switch is used in the SWU
environment. However, this assumes both switching and routing responsibilities.
To define this to the DCM, complete the exercise described in 4.5.1, “Exercise:
Defining a switch” or use the shortcut method described in 4.1.1, “Shortcut:
Creating the network objects” on page 43 to import the file named switches.xml.
48
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
4.5.1 Exercise: Defining a switch
To define a switch to the DCM, perform the following tasks:
1. Navigate to Inventory → Network Infrastructure → Switches. Use the
Edit → Add Switch menu option and provide the necessary information, as
shown in Figure 4-6. Click Save.
Figure 4-6 Adding a switch definition
2. When completed, the new switch appears in the Switch Inventory. Open the
details of the switch named SWU_Switch-A in order to assign router
functionality and to define interfaces for the switch. To assign the router
functionality, select the check-box against router in the General page and
click Save (Figure 4-8).
Figure 4-7 Assigning router capabilities to a switch
Chapter 4. Exercise 4: Configuring the SWU networking environment
49
3. To assign interfaces, use the Edit → Add Interface menu option from the
General page once for each subnet. Use the address 192.168.nnn.254 for
each interface, where nnn denotes the name of the subnet (1,100,110,120,
and 130) (Figure 4-8).
When this task is completed, the interfaces shown in Figure 4-8 must be
defined.
Figure 4-8 Switch interfaces
The switch definition is complete. In the workshop, there is no requirement to
define the switch ports as in the case of a production environment. If you use the
shortcut method to define the switch, you will see that a set of switch ports are
defined, but are not used in these exercises.
4.6 Defining firewalls for the SWU environment
The SWU environment includes a firewall for protecting the production
environment from threats from the Internet.
To define a firewall to the DCM, complete the exercise defined in 4.6.1, “Exercise:
Defining a firewall”. Alternately, use the shortcut method outlined in 4.1.1,
“Shortcut: Creating the network objects” on page 43 to import the file named
firewalls.xml.
50
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
4.6.1 Exercise: Defining a firewall
To define a firewall to the DCM, perform the following tasks:
1. Navigate to Inventory → Network Infrastructure → Switches. Use the
Edit → Add Switch menu option and provide the necessary information, as
shown in Figure 4-9. Click Save.
Figure 4-9 Adding a switch that will host the firewall
2. When completed, the new switch appears in the Switch Inventory. Open the
details of the switch named SWU_Firewall-A in order to define the
functionality and the interfaces for the switch.
To assign the firewall functionality, select the check boxes against router and
firewall in the General page, and click the adjacent Save button
(Figure 4-10).
From the General page, use the Edit → Add NIC and Edit → Add Interface
menu options to add Network Interface Cards (NICs) and interfaces, as
shown in Figure 4-10.
Figure 4-10 Switch interfaces
Chapter 4. Exercise 4: Configuring the SWU networking environment
51
4.7 Verifying the network infrastructure
To verify whether the required network objects are created, navigate to
Inventory → Network Infrastructure, and verify whether it is similar to the
diagram shown in Figure 4-11.
Figure 4-11 SWU tutorial network topology
This completes the definition of the network infrastructure for the SWU
environment.
52
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
5
Chapter 5.
Exercise 5: Configuring the
SWU provisioning
infrastructure
The starting point for this exercise is the IBM Software University (SWU) data
center model (DCM) containing the objects that are shown in the frame named A
in Figure 5-1.
© Copyright IBM Corp. 2006. All rights reserved.
53
5.1 The objective of this exercise
The objective of this exercise is to define the additional provisioning
infrastructure components, boot server and file repository, which support the
operating system (OS) and the software provisioning processes in the SWU
environment.
After this exercise is completed, the SWU environment objects shown in the
frame named B in Figure 5-1 are defined.
Figure 5-1 Provisioning infrastructure implementation: Starting and ending environments
Figure 5-1 shows that the objects that will be created in the DCM in this exercise
are a few helper objects in the SWU environment, which help achieve the goal of
orchestrating the provisioning a composite application in the tutorial
environment.
54
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
To achieve this goal, you require the following components:
򐂰 A boot server for simulating the installation of the operating systems
򐂰 A file repository for storing the software images
The two newly created objects reside only in the Tivoli Intelligent Orchestrator
DCM and are not supported by the physical devices. However, the IP interfaces
and directories are hosted by the Tivoli Intelligent Orchestrator Server system to
allow full functionality of the file repository in the tutorial environment.
If you are comfortable with defining the file repositories and the boot servers
using the Tivoli Intelligent Orchestrator user interface, use the shortcut described
in 5.1.1, “Shortcut: Boot server and file repository” to complete all the tasks in
this exercise, and continue with Chapter 6, “Exercise 6: Preparing the
software-related objects for the Pristine systems” on page 63.
5.1.1 Shortcut: Boot server and file repository
A set of Extensible Markup Language (XML) files for the definition of the objects
in this exercise is loaded into the LocalFileRepository in your TIOServer system
on installation of the SWU_2006 tcdriver. Following is a list of the relevant files:
򐂰 bootservers.xml
򐂰 filerepositories.xml
These files are referenced from a file named SWU-FILESERVERS.xml.
To import all the definitions in one step, issue the following commands from the
Tivoli Intelligent Orchestrator Server system command line:
cd %TIO_HOME%\..\SWrepository\SWU\xml
%TIO_HOME%\tools\xmlimport file:SWU_FILESERVERS.xml
To import the files one-by-one and view the results in the Tivoli Intelligent
Orchestrator user interface, perform one of the following tasks for each of the
files listed earlier, and in the same sequence in which they are listed:
򐂰 Execute the SWU_ImportXML workflow by providing a value for the xmlFile
parameter of <file_name>, either by invoking the workflow from the user
interface or by issuing the following command from the Tivoli Intelligent
Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=<file_name>
Chapter 5. Exercise 5: Configuring the SWU provisioning infrastructure
55
򐂰 Issue the following command from the Tivoli Intelligent Orchestrator Server
system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFile=<file_name>
When the workflow execution is complete, continue to 5.4, “Verifying the
provisioning infrastructure components” on page 62.
5.2 Creating a simulated boot server
In order to be able to image the virtual servers that are created in your hosting
platform, establish a boot server. Name it SWU_BootServer and assign an address
of 192.168.1.2. In a production environment, this is a dedicated server running
the proper software for supporting bare metal provisioning. However, in the SWU
environment, let it point to an IP address that is defined in the Tivoli Intelligent
Orchestrator Server.
5.2.1 Shortcut: Creating a boot server
An XML file for the definition of a simulated boot server named SWU_BootServer
is loaded into the LocalFileRepository in your TIOServer system on installation of
the SWU_2006 tcdriver. To import these definitions into your DCM, perform one
of the following tasks:
򐂰 Execute the SWU_ImportXML workflow by providing a value for the xmlFile
parameter of bootservers, either by invoking the workflow from the user
interface or by issuing the following command from the Tivoli Intelligent
Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=bootservers
򐂰 Issue the following command from the Tivoli Intelligent Orchestrator Server
system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFile=bootservers"
When the workflow execution is complete, continue to 5.3, “Defining the
SWU_FileRepository” on page 58.
56
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
5.2.2 Exercise: Defining a boot server
To create a boot server, perform the following tasks:
1. Navigate to Inventory → Infrastructure Management → Boot Servers. In
the Boot Servers page, you see that a few boot servers are already defined as
part of the installation. Select Edit → Add Boot Server to create a new one.
Add the properties, as shown in Figure 5-2.
Figure 5-2 Defining a boot server
2. To assign a management interface, select the newly created boot server and
from the General page, select Edit → Add Interface. (In the SWU
environment, because you do not have to work with the Network Interface
Cards (NIC), you do not have to define it.). Add the interface properties, as
shown in Figure 5-3.
Figure 5-3 Boot server interface parameters
Chapter 5. Exercise 5: Configuring the SWU provisioning infrastructure
57
3. To assign a device driver, open the Workflows page. Select Edit → Assign
Device Driver, and select the driver named
SoftwareSimulator_BootServer so that your logical device operation (LDO)
associations are similar to those shown in Figure 5-4.
Figure 5-4 Boot server device driver
4. Assign the proper credentials to the SWU_BootServer. Follow the procedure
outlined in 3.3, “Defining the access points and the credentials” on page 26 or
use the shortcut by issuing the following command from the Tivoli Intelligent
Orchestrator Server command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd
SWU_SetDeviceCredentials "deviceName=<deviceName>"
This concludes the creation of the boot server.
5.3 Defining the SWU_FileRepository
In order to have a place to store the OS images and the application installation
code, use a file repository.
In the SWU environment, you have a system-defined LocalFileRepository that
points to the %TIO_HOME%\..\SWRepository directory in the Tivoli Intelligent
Orchestrator Server. However, in real life, the file repository is most likely to be a
dedicated file server. To mimic this, create a new file repository named
SWU_FileRepository, which has a dedicated IP address of 192.168.1.3.
58
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
5.3.1 Shortcut: Creating a file repository
An XML file for the definition of the SWU_FileRepository is loaded into the
LocalFileRepository in your TIOServer system on installation of the SWU_2006
tcdriver. To import these definitions into your DCM, perform one of the following
tasks:
򐂰 Execute the SWU_ImportXML workflow by providing a value for the xmlFile
parameter of file repositories, either by invoking the workflow from the user
interface or by issuing the following command from the Tivoli Intelligent
Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=filerepositories
򐂰 Issue the following command from the Tivoli Intelligent Orchestrator Server
system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFile=filerepositories"
When the workflow execution is complete, continue to 5.4, “Verifying the
provisioning infrastructure components” on page 62.
Chapter 5. Exercise 5: Configuring the SWU provisioning infrastructure
59
5.3.2 Exercise: Defining a file repository
To create the SWU_FileRepository, perform the following tasks:
1. Navigate to Inventory → Infrastructure Management → File Repositories.
In the File Repositories page, you see that a few file repositories are already
defined as part of the installation. Select Edit → Add File Repository to
create a new file repository and add the relevant properties, as shown in
Figure 5-5.
Figure 5-5 File repository properties
60
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
2. To assign a management interface, select the newly created file repository,
and from the General page, select Edit → Add Interface. (In the SWU
environment, there is no necessity to work with the NIC. Therefore, there is no
requirement to define it.). Add the interface properties as shown in Figure 5-6.
Figure 5-6 File repository interface parameters
3. To assign a device driver, open the Workflows page and select Edit →
Assign Device Driver → LocalFileRepositoryDM. Your LDO associations
look as shown in Figure 5-7.
Figure 5-7 File repository device driver
Chapter 5. Exercise 5: Configuring the SWU provisioning infrastructure
61
4. Assign the proper credentials for the SWU_FileRepository. Follow the
procedure outlined in 3.3, “Defining the access points and the credentials” on
page 26 or use the shortcut by issuing the following command from the Tivoli
Intelligent Orchestrator Server command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd
SWU_SetDeviceCredentials "deviceName=<deviceName>"
This concludes the creation of a file repository.
5.4 Verifying the provisioning infrastructure
components
To verify whether the boot server and the file repository are successfully created,
perform the following tasks:
1. Enter the string SWU_B in the Find input field in the top left corner of the Tivoli
Intelligent Orchestrator user interface navigation pane, and verify whether the
SWU_BootServer is listed as shown in Figure 5-8.
Figure 5-8 Verifying boot server creation
2. Repeat step 1 using an input string of SWU_Fil (Figure 5-9) and verify whether
the SWU_FileRepository appears.
Figure 5-9 Verifying file repository creation
This concludes the creation of the basic SWU provisioning environment.
62
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
6
Chapter 6.
Exercise 6: Preparing the
software-related objects for
the Pristine systems
The starting point for this exercise is the IBM Software University (SWU) data
center model (DCM), which, in the very least, contains the objects that are shown
in the frame named A in Figure 6-1.
© Copyright IBM Corp. 2006. All rights reserved.
63
6.1 The objective of this exercise
In this exercise, you define the basic software components that are applied to
provisionable systems and a resource pool for them to reside in when they are
ready to be provisioned. During this exercise, you link the software components
to a software stack, which in turn is associated with a server template that
functions as a model for all the servers that are added to the resource pool.
After this exercise is completed, the additional resources shown in the frame
named B in Figure 6-1 is configured.
Figure 6-1 Software preparation: Starting point and goal
64
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
Figure 6-1 shows that the objects that will be created in the DCM in this exercise
are those that are required to create a resource pool in which to place the
servers that may eventually be provisioned into the production environment. The
servers are created as part of Chapter 7, “Exercise 7: Creating virtual servers” on
page 91.
In the SWU environment, the virtual servers you create reuse the software
components installed on the host platform server. The server template
associated with the resource pool in which the servers are placed in governs the
configuration of the software components. Therefore, before creating the
resource pool, define the software stack and the server template, and install the
necessary software components on the host platform server in order to enable
the virtual servers to operate as expected.
Note that at this point, the host platform server is not yet created. This is created
later in 7.2, “Creating a host platform server” on page 96.
To facilitate this setup, the software objects shown in Figure 6-2 are required.
Figure 6-2 Virtual server: Basic software components
The goal of this setup is to automatically install or register an operating system
(SWU Windows 2000 Server Service Pack 4) to new virtual servers as and when
they are created, and seamlessly install IBM Java Runtime V1.4.1.
Chapter 6. Exercise 6: Preparing the software-related objects for the Pristine systems
65
To support this in the SWU environment, a set of device drivers for the involved
resource pool, server template, servers, host platform, and software products,
and software packages are provided. These are available in the
SWU_2006.tcdriver. The workflows provided allow the following actions to be
automatically invoked when a new virtual server is created either through the
Tivoli Intelligent Orchestrator user interface interaction or a batch workflow or
LDO invocation, or an execution of a customized workflow that allocates a
number of servers in a sequence:
򐂰 The HostPlatform.CreateVirtualServer LDO allocates the hardware resources
defined in the virtual server template referenced in the call. It then assigns a
device driver to the newly created server, and invokes the Device.Initialize
LDO to load an OS. It then makes the server a member of the
SWU_Pristine_Server_Pool, and executes the SparePool.Initialize LDO to
finalize the hardware and software configuration in accordance with the
server template that is assigned to the resource pool. The device driver and
the pool associations of the new server are controlled by the variables
specified for the virtual server template.
򐂰 The workflow associated with the Device.Initialize LDO registers the SWU
Windows 2000 Server SP4 OS for the server, using the SWU Windows 2000
Server SP4 software product, which in turn relies on the SWU Windows 2000
Server SP4 Image that resides in the SWU_FileRepository referenced by the
SWU_BootServer. In addition, the TCA_Set_Platform_Capabilities workflow
is called to simulate the hardware discovery of the system. This simulated
discovery is used to set the platform.architecture to a value of Virtual, which is
used for software installations to differentiate between the real system and
the virtual system.
Note: In a production implementation in which the virtual servers have their
own OS instead of sharing one from the host platform server, the simulated
discovery is not required. This technique is used only in the SWU
environment to simulate the real virtual servers.
򐂰 The SparePool.Initialize LDO invokes the
ServerTemplate.ConfigureServerByTemplate LDO that is responsible for
reconfiguring the network interfaces and ensuring that the software specified
in the software stack SWU_Pristine_Server_Stack associated with the server
template SWU_Pristine_Server_Template, is installed on the server. In the
SWU environment, the SWU Windows OS with Java Runtime V1.4.1 stack
references the Windows 2000 Server SP4 and the SWU IBM Java Runtime
V1.4.1 for Windows software products.
66
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
Having the right device drivers that provide the workflows that are necessary for
implementing the various functions of each component makes it fairly easy to
bootstrap the virtual servers.
To define the software-related objects to the DCM in the SWU environment, use
the bottom-up approach. Realizing that the objects required to support the
software provisioning process, the SWU_FileRepository and the
SWU_BootServer objects are already defined, the high-level sequence for
defining the missing objects is as follows:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
SWU Windows 2000 Server SP4 software image
SWU Windows 2000 Server SP4 software product
SWU Windows 2000 Server SP4 software stack
SWU IBM Java Runtime V1.4.1 software product
SWU_Pristine_Server_Stack
SWU_Pristine_Server_Template
If you are comfortable with defining software components, server templates, and
resource pools using the Tivoli Intelligent Orchestrator user interface, use the
shortcut described in 6.1.1, “Shortcut: Pristine pool, server template, and
software” on page 67 to complete all the tasks in this exercise, and then continue
with 6.6, “Verifying the creation of the objects for the Pristine servers” on
page 89.
6.1.1 Shortcut: Pristine pool, server template, and software
A set of Extensible Markup Language (XML) files for the definition of the objects
in this exercise is loaded into the LocalFileRepository in your TIOServer system
on installation of the SWU_2006 tcdriver. Following are the relevant files:
򐂰 operatingsystem.xml
򐂰 servertemplatepristine.xml
򐂰 resourcepoolpristine.xml
All these files are referenced from the file named SWU_PRISTINE.xml. In
addition, device drivers for the Java runtime software objects are provided in the
file SWU_IBMJava_JRE_141_Win.tcdriver.
Note that the server template is defined along with the resource pool. By using
the Tivoli Intelligent Orchestrator user interface, the template may be defined on
its own.
Chapter 6. Exercise 6: Preparing the software-related objects for the Pristine systems
67
To import the objects, perform the following tasks:
1. Install the SWU_IBMJava_JRE_141_Win tcdriver by issuing the following
command from the TIOServer system command line:
%TIO_HOME%\tools\tc-driver-manager fid SWU_IBMJava_JRE_141_Win
2. Import the object definitions by issuing the following commands from the
TIOServer system command line:
cd %TIO_HOME%\..\SWrepository\SWU\xml
%TIO_HOME%\tools\xmlimport file:SWU_PRISTINE.xml
or
Import the files one-by-one, and view the results in the Tivoli Intelligent
Orchestrator user interface. To import the files, perform one of the following
actions for each file in the sequence in which it is listed earlier:
– Execute the SWU_ImportXML workflow by providing a value for the
xmlFile parameter of <file_name>, either by invoking the workflow from
the user interface or by issuing the following command from the Tivoli
Intelligent Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=<file_name>
– Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFile=<file_name>"
3. Ensure that the correct device driver is assigned to the template. Use one of
the following methods:
– Execute the SWU_AssignDriverToTemplate workflow by providing a value
for the ServerTemplateName parameter of
SWU_Pristine_Server_Template, either by invoking the workflow from the
user interface or by issuing the following command in the Tivoli Intelligent
Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0
SWU_AssignDriverToTemplate
ServerTemplateName=SWU_Pristine_Server_Template
– Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd
SWU_AssignDriverToTemplate
"ServerTemplateName=SWU_Pristine_Server_Template"
When the workflow execution is complete, continue to 6.6, “Verifying the creation
of the objects for the Pristine servers” on page 89.
68
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
6.2 The SWU Windows 2000 Server SP4 software
definitions
To define the OS image you use in the SWU environment, perform the following
tasks:
1. Create an image (simulated) that allows seamless installation of the Windows
OS.
2. Create an SWU Windows 2000 Server SP4 software product referencing the
image in order to allow you to define the capabilities and the requirements to
help the automated provisioning process.
3. Create the SWU_New_Windows_Server_Template to allow easy
configuration of the new virtual servers.
These steps are necessary to allow the simulated installation of an OS image,
and to register the capabilities with the server that is the target of the installation.
6.2.1 Shortcut: Creating an operating system
An XML file for the definition of the SWU Windows 2000 Server SP4 OS and the
related image is loaded into the LocalFileRepository in your TIOServer system
on installation of the SWU_2006 tcdriver. To import these definitions into your
DCM, perform one of the following tasks:
򐂰 Execute the SWU_ImportXML workflow by providing a value for the xmlFile
parameter of the OS, either by invoking the workflow from the user interface
or by issuing the following command from the Tivoli Intelligent Orchestrator
user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=operatingsystem
򐂰 Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFile=operatingsystem"
When the workflow execution is complete, continue to 6.3, “Importing the
software objects for the installation of IBM Java Runtime Environment V1.4.1” on
page 76.
Chapter 6. Exercise 6: Preparing the software-related objects for the Pristine systems
69
6.2.2 Exercise: Defining the operating system
To create the image, perform the following tasks:
1. Navigate to Inventory → Software Catalog → Installables → Images. Use
the Edit → Add Image Installable menu option to create a new image
installable. In the Create Software Installable page, provide the relevant
information, as shown in Figure 6-3.
Figure 6-3 SWU Windows 2000 Server SP4 software image properties
2. After defining the Image Installable, create the Software Definition that uses
the Installable when an installation is performed. In the SWU environment,
you are working with the restriction that only one Tivoli Common Agent end
point can exist on a single system. Therefore, you cannot discover the existing
hardware and software components on a virtual server, and get the OS linked
automatically to the server.
70
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
3. To create the SWU Windows 2000 Server SP4 software product, navigate to
Inventory → Software Catalog → Definitions → Software Products. Use
the Edit → Add Software Product menu option to create a new software
product definition. Provide the necessary information, as shown in Figure 6-4.
Figure 6-4 SWU Windows 200 Server SP4 OS properties
4. To link the image created earlier with the SWU Windows 2000 Server SP4
software product, which is also known as SoftwareModule, select Edit →
Add Image Installable from the General page of the Software Definition
object, and select the image named SWU Windows 2000 Server SP4 Image
in the field named Images, as shown in Figure 6-5.
Figure 6-5 Linking the SWU Windows 2000 SP4 image to the operating system
The results are visible in the Installable Files section of the General page, as
shown in Figure 6-6.
Figure 6-6 SWU Windows 2000 SP4 operating system installables
Chapter 6. Exercise 6: Preparing the software-related objects for the Pristine systems
71
5. As for the other DCM objects, the operating system software products must
have device drivers assigned. This ensures that the LDOs that are
implemented at the OS level, such as Add_Ip_Address, have
implementations assigned to them. In the SWU environment, assign the
SWD_Windows_OperatingSystemDM device driver to the SWD Windows
20000 Server SP4 software product object through the Workflows page of the
Tivoli Intelligent Orchestrator user interface.
6. The capabilities in the Tivoli Intelligent Orchestrator are grouped into several
capability types. Because the SWU Windows 2000 Server SP4 software
product represents the installation of an OS, the natural capability type to add
to the SWU Windows 2000 Server SP4 software product is the OS capability
type. To add this, select Edit → Add Capability Type → OS capability type,
as shown in Figure 6-7.
Figure 6-7 SWU 2000 Server SP4 OS capabilities
7. To define the capabilities of the SWU Windows 2000 Server SP4 software
product, use the Edit → Add Capability option to add the capabilities.
(Capabilities are matched later with the requirements for other software
packages in order to be able to automatically select the proper installable to
be used for the installation of a particular software product.) Add os.family
capability to the OS capability type, and supply a value of Windows 2000
Server SP4. When finished, open the Requirements and Capabilities section
of the software stack General page, and verify whether the capabilities of the
SWU Windows 2000 Server SP4 software product corresponds to what is
shown in Table 6-1.
Table 6-1 SWU Windows 2000 SP4 OS capabilities
72
Capability type
Capability name
Capability value
OS
os.familiy
Windows 2000 Server SP4
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
If the capabilities do not correspond to the values shown in Table 6-1, add the
relevant information by using the Edit → Add Capability menu option again.
When you have finished, the Requirements and Capabilities section of the
General page must look as shown in Figure 6-8.
Figure 6-8 SWU Windows 2000 SP4 OS capability summary
8. Tivoli Intelligent Orchestrator offers grouping of software definition by
assigning the software product definition to a software category. To assign a
category, select Edit → Add to Software Category → SWU. When you click
Save and expand the Software Category section in the General page, it
should look similar to that shown in Figure 6-9.
Figure 6-9 Categorizing the SWU Windows 2000 SP4 OS
9. To control the behavior of the software instances created as children of the
Software Installation objects created by the SWU Windows 2000 Server SP4
software product, create an Installation Software Resource Template for the
software product, and associate it with the SWU_Windows_InstallationDM
device driver. This ensures that instances of the Windows installation is
assigned a valid device driver.
Chapter 6. Exercise 6: Preparing the software-related objects for the Pristine systems
73
To create the Software Resource Template, go to the General page of the
SWU Windows 2000 Server SP4 software product, and select Edit → Define
Resource Template. Provide the necessary values as shown in Figure 6-10.
Click Save.
Figure 6-10 SWU Windows 2000 Server SP4 installation template
When you click Save, the software resource template appears. When you
expand the Configuration Template section in the General page, a window
similar to the one shown in Figure 6-11 must appear.
10.To control the name applied to the software installation object that is created
when the software product is installed, add a parameter to the Installation
Software Resource Template. The resource-name parameter is used for this
purpose. To add the resource-name parameter, select the Edit → Add
Parameter menu option (Figure 6-11).
Figure 6-11 Pristine software resource template
74
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
Provide a value for the name of the software installation object, as shown in
Figure 6-12 and click Save.
Figure 6-12 Creating a template parameter
When you expand the Configuration Template section again, it must look
as shown in Figure 6-13.
Figure 6-13 Software resource template with parameters
11.To create a software stack for the new Windows-based servers in the SWU
environment, which will only reference the SWU Windows 2000 Server SP4
software product, navigate to Inventory → Software Catalog → Definitions,
and select Software Stacks. Use the Edit → Add Software Stack menu
option to create a new software stack definition, and supply the relevant
information, as shown in Figure 6-14.
Figure 6-14 Creating a software stack
12.Use the Edit → Add Stack Entry menu option to add the SWU Windows
2000 Server SP4 software product to the stack and select the Default
Template as the Software Resource Template to be copied into the software
stack in order to control installations.
Chapter 6. Exercise 6: Preparing the software-related objects for the Pristine systems
75
13.Finally, because you have assigned the value for the os.family capability of
Windows 2000 Server SP4, chances are that you must use this value as a
requirement for other software products or software stacks that rely on this
version of the Windows OS. Before this requirement is added from the Tivoli
Intelligent Orchestrator user interface, define a predefined value.
To add a predefined requirement value, perform the following tasks:
a. Navigate to Configuration → Validation Settings → Requirement
Names. From the Requirement Names window, click the line named
os.family, and select Edit → Add Requirement Predefined Value.
b. In the pop-up that appears, supply the desired value, Windows 2000
Server SP4 in this case, as shown in Figure 6-15, and click Save to add
the predefined value.
Figure 6-15 Adding predefined requirement values
You have defined the software product for the simulated installation of the
Windows 2000 Server SP4 OS to be controlled from the SWU_BootServer, using
a dummy image stored in the SWU_FileRepository. This image is referenced
from a software product definition for which OS:os.family capabilities are defined,
and both an Installation Software Resource Template and a software stack that
uses the software definition are created. In addition, a new predefined value for
the os.family requirement is defined.
6.3 Importing the software objects for the installation of
IBM Java Runtime Environment V1.4.1
The IBM Java Runtime Environment V1.4.1 (Figure 6-16) is required by some of
the components that will be installed in the exercise described in 6.3.1, “Exercise:
Importing the SWU IBM Java Runtime 1.4.1 software objects”. Therefore, ensure
that it is available and registered on the host platform server and the virtual
servers. This implies that you must create another software product with
76
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
associated images, one for the “real” installation on the host platform server, and
one for the simulated installation on the virtual servers. In this case, you must use
the requirements, capabilities, and priorities creatively in order to be able to
control the installable used for each installation.
Figure 6-16 IBM Java Runtime V1.4.1 software components
Note that the OS requirements are not defined at the software definition level in
order to allow the software definition to be expanded to support OS platforms
other than Windows.
The actions that are to be performed during the operation of the software
installable objects are, as usual, defined by associating a specific device driver to
the software installable. The device driver links the LDOs with specific
implementation workflows that perform all the necessary actions. In the SWU
environment, a device driver is provided to perform the installation of the
software installable for the real system. For the virtual servers, use the
system-provided SoftwareSimulater_SoftwareInstallable driver. If no device
driver is associated, the default workflows are used, which is why no device
drivers have to be associated with the software product object, except under
special circumstances.
The parameters controlling the actual installation are stored in the Software
Resource Template. This is defined at the software product level, and may
consist of several related sections that define how DCM objects relating to the
installation are created. For the SWU IBM Java Runtime 1.4.1 software product,
Chapter 6. Exercise 6: Preparing the software-related objects for the Pristine systems
77
the only required Software Resource Template is the Installation Software
Resource Template, which instructs the Tivoli Intelligent Orchestrator to create a
Software Installation object after the SoftwareModule.Install LDO terminates
successfully.
Among the standard parameters of the Software Resource Template is the
device model that is to be assigned to the created objects. The device model in
turn determines the behavior of the object, including assigning a device driver
manually to other objects such as software products, file repositories, and so on.
Multiple Software Resource Templates may be defined for a software product.
However, at usage time, when the installation is scheduled or the software
product is linked to a software stack, one specific Software Resource Template
must be selected and cloned to the receiving object (software installation or
software stack). One implication of this is that changes made to a Software
Resource Template do not affect the cloned copies.
Therefore, to define the software module for the SWU IBM Java Runtime
Environment V1.4.1, import a special tcdriver that provides the device drivers
and workflows used to install, operate, and remove the Java runtime software.
As part of this import, the following objects are created in the DCM:
򐂰 Software installables for Windows (the real installation)
򐂰 Software installables for simulation (for the virtual servers)
򐂰 Software products that reference the images
򐂰 Software resource templates to control the creation of the DCM objects and
the physical installation
6.3.1 Exercise: Importing the SWU IBM Java Runtime 1.4.1
software objects
The tcdriver named SWU_IBMJava_JRE_141_Win.tcdriver is loaded into the
%TIO_HOME%\drivers directory when the SWU_2006.tcdriver is imported. This
tcdriver creates all the objects required to install the IBM JRE V1.4.1 on the host
platform server and the virtual servers in the SWU environment.
To import the tcdriver, perform the following tasks:
1. Issue the following command from the TIOServer system:
%TIO_HOME%\tools\tc-driver-manager fid SWU_IBMJava_JRE_141_Win
78
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
2. After successful import, go back to the Tivoli Intelligent Orchestrator user
interface and verify whether the following DCM objects are created (the
software objects are located in Inventory → Software Catalog):
–
–
–
–
–
Software product: SWU IBM JRE V1.4.1 Windows
Software package: SWU IBM JRE V1.4.1 Windows installable
Software package: SWU IBM JRE V1.4.1 Simulated installable
Device driver: SWU_IBMJava_JRE_141_Win_SoftwareInstallableDM
Device driver: SWU_IBMJava_JRE_141_Win_SoftwareInstallationDM
In addition, open the SWU IBM Java Runtime V1.4.1 Windows software
product and verify whether the following Software Resource Templates are
created:
Table 6-2 IBM JRE V1.4.1 software resource templates
Software Resource
Template type
Name
PLACEHOLDER
defaults
PLACEHOLDER
response-file
INSTALLATION
SWU IBM Java Runtime Environment Windows Installation
6.4 Creating the SWU_Pristine_Server_Stack
In order to facilitate the automatic provisioning of the basic Windows and the JRE
components to the new servers, define a software stack that is associated with
the spare pool for the servers, as shown in Figure 6-2 on page 65.
6.4.1 Shortcut: Defining the SWU_Pristine_Server_Stack
An XML file for the definition of the SWU Windows OS with JRE V1.4.1 software
stack is loaded into the LocalFileRepository in your TIOServer system on
installation of the SWU_2006 tcdriver.
1. To import these definitions into your DCM, perform one of the following tasks:
– Execute the SWU_ImportXML workflow by providing a value for the
xmlFile parameter of softwarestackpristine, either by invoking the workflow
from the user interface or by issuing the following command from the Tivoli
Intelligent Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=softwarestackpristine
Chapter 6. Exercise 6: Preparing the software-related objects for the Pristine systems
79
– Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFile=softwarestackpristine"
2. Ensure that the correct device driver is assigned to the template by using one
of the following methods:
– Execute the SWU_AssignDriverToTemplate workflow by providing a value
for the ServerTemplateName parameter of
SWU_Pristine_Server_Template, either by invoking the workflow from the
user interface or by issuing the following command from the Tivoli
Intelligent Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0
SWU_AssignDriverToTemplate
ServerTemplateName=SWU_Pristine_Server_Template
– Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd
SWU_AssignDriverToTemplate
"ServerTemplateName=SWU_Pristine_Server_Template"
When the workflow execution is complete, continue to 6.5, “Creating the
SWU_Pristine_Server_Pool” on page 84.
6.4.2 Exercise: Creating the SWU_Pristine_Server_Stack
To create the software stack, perform the following tasks:
1. Navigate to Inventory → Software Catalog → Definitions → Software
Stacks. Use the Edit → Add Software Stack menu option to create a new
software stack, and provide the necessary information, as shown in
Figure 6-17. Click Save.
Figure 6-17 The SWU_Pristine_Server_Stack
80
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
2. To add software products to the stack, open the newly created software
stack, and from the General page, select Edit → Add Stack Entry. This
starts the Add Software Stack wizard that prompts you through the process.
a. When the list of eligible software definitions (software products and
software stacks) is displayed, limit the list by entering SWU in the Search
field, as shown in Figure 6-18, and click Search.
Select SWU Windows 2000 Server SP4 Software Definition and click
Next.
Figure 6-18 Searching for software definitions
b. Select the Software Resource Template that you want to use for this
particular software stack. Select the default.xxxx SRT, as shown in
Figure 6-19, and click Next.
Figure 6-19 Selecting a software resource template when adding a stack entry
Chapter 6. Exercise 6: Preparing the software-related objects for the Pristine systems
81
c. Finally, when the Customize Template dialog is displayed, accept the
defaults and click Finish to accept and implement your choices
(Figure 6-20).
Figure 6-20 Software stack entry with customized parameters
This takes you back to the software stack General page, which, at this point,
is similar to that shown in Figure 6-21.
Figure 6-21 Software stack with one software definition
82
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
3. Repeat step 2, but this time around, select the SWU IBM Java Runtime
Environment 1.4.1 Windows software definition and the SWU IBM Java
Runtime Environment Windows Installation Software Resource
Template. When completed, the software stack must look similar to that
shown in Figure 6-22.
Figure 6-22 Software stack with multiple entries
Note the way the software definitions are arranged in the module. This
reflects the sequence in which the various components will be installed.
Chapter 6. Exercise 6: Preparing the software-related objects for the Pristine systems
83
4. Finally, to instruct the TIO/TPM that the software definitions has to be
installed, select Edit → Add Installable to add an iterator by selecting a
value of iterator for the Installable field in the New Installable Association
dialog. The software stack looks similar to that shown in Figure 6-23.
Figure 6-23 Adding an iterator to the software stack
Note that in the SWU environment, there is no necessity to specify the
requirements, capabilities, or workflows for the software stack. In a production
environment, these properties may have to be defined in addition to the stack
entries.
The process of creating the SWU_Pristine_Server_Stack that will be linked to the
resource pool, which will in turn own the Pristine virtual servers hosted by the
host platform server, is complete. This link is facilitated through the use of a
server template.
6.5 Creating the SWU_Pristine_Server_Pool
Before you define the servers that will use the newly created software definition,
define the resource pool in which they will reside. In the SWU environment, use
only one resource pool. Name it SWU Pristine Server Pool.
This pool is the placeholder for all the systems that are candidates for a
provisioning operation in the SWU environment. Because all the servers in a
resource pool are expected to be configured similarly, the easiest way to ensure
consistency is to assign a server template, which governs the networking and
software setup of the servers, to the pool. Initially, the software setup is
84
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
controlled by associating a software stack to the server template. Therefore, in
order to ensure that consistent configurations of the servers are provisioned in
the SWU environment, create the following:
򐂰 The SWU_Pristine_Server_Template
򐂰 The SWU_Pristine_Server_Pool
6.5.1 Creating the SWU_Pristine_Server_Template
In the SWU environment, you rely on the process of creating servers to set up
the hardware of the virtual servers, so that each server has at least two Network
Interface Cards (NICs), one for management purposes and one for production
purposes. The reason for the presence of two NICs instead of multiple interfaces
on the same NIC is that, for security reasons, it is recommended that each
interface is assigned to a different virtual local area network (VLAN). This is
normally handled at the physical (NIC) level. In addition, you can rely on the
HostPlatform.CreateVirtualServer LDO implementation to install an OS, create a
management interface on one of the NICs, and set up service access points and
credentials to communicate with the system.
The expected functionality to be provided by the server template is ensuring that
the software configuration of the server - once deployed to the resource pool to
which the server template is linked - complies with the definitions in the software
stack associated with the server template. The network configuration is assumed
to have been taken care of already.
The specialized workflows that are necessary to achieve this in the SWU
environment are provided in the device drivers installed in your TIOServer
system when you import the SWU_2006.tcdriver. These are available in the
SoftwareUniversity2006 device driver category for easy reference.
SWU_ServerTemplateDM is the device driver that applies to the creation of the
server template.
Chapter 6. Exercise 6: Preparing the software-related objects for the Pristine systems
85
6.5.2 Exercise: Creating the Pristine Server Template
To create the SWU_Pristine_Server_Template for the SWU environment,
perform the following tasks:
1. Navigate to Inventory → Servers → Physical Servers → Server
Templates. Use the Edit → Add Server Template menu option to create a
new template by providing the necessary information, as shown in
Figure 6-24. Click Save.
Figure 6-24 Creating the SWU_Pristine_Server_Template
2. Open the newly created SWU_Pristine_Server_Template. Select Edit →
Associate Software Stack to link a software stack to the server template.
From the New Software Stack dialog, select the
SWU_Pristine_Server_Stack software stack, as shown in Figure 6-25, and
click Save.
Figure 6-25 Associating a software stack to a template
3. To ensure that the expected implementation is invoked when the server
template logical operations are called, go to the Workflows page of the server
template and associate the SWU_ServerTemplateDM device driver to the
SWU_Pristine_Server_Template.
86
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
4. Return to the General page of the SWU_Pristine_Server_Template and verify
whether the content of the server template is similar to that shown in
Figure 6-26.
Figure 6-26 SWU_Pristine_Server_Template properties
The creation of the server template that is to be used for the Pristine servers in
the SWU environment is complete. In 6.5.3, “Shortcut: Defining the
SWU_Pristine_Server_Pool”, you create the SWU_Pristine_Server_Pool and
associate it with the newly created template.
6.5.3 Shortcut: Defining the SWU_Pristine_Server_Pool
An XML file for the definition of the SWU_Pristine_Server_Pool is loaded into the
LocalFileRepository in your TIOServer system on installation of the SWU_2006
tcdriver. To import these definitions into your DCM, perform one of the following
tasks:
򐂰 Execute the SWU_ImportXML workflow by providing a value for the xmlFile
parameter of resourcepoolpristine, either by invoking the workflow from the
user interface or by issuing the following command from the Tivoli Intelligent
Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=resourcepoolpristine
Chapter 6. Exercise 6: Preparing the software-related objects for the Pristine systems
87
򐂰 Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFile=resourcepoolpristine"
When the workflow execution is complete, continue to 6.6, “Verifying the creation
of the objects for the Pristine servers” on page 89.
6.5.4 Exercise: Creating the SWU_Pristine_Server_Pool
To define the SWU_Pristine_Server_Pool, perform the following tasks:
1. Navigate to Inventory → Servers → Physical Servers → Resource Pools.
In the Resource Pools page, use the Edit → Add Resource Pool menu
option and provide the necessary information, as shown in Figure 6-27, and
click Save.
Figure 6-27 Creating the SWU_Pristine_Server_Pool
2. Go to the Workflows window of the SWU_Pristine_Server_Pool and
associate the SWU_SparePoolDM device driver with it.
This concludes the creation of the resource pool that is required to host the
provisionable servers in the SWU environment.
88
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
6.6 Verifying the creation of the objects for the Pristine
servers
To verify the creation of the SWU_Pristine_Server_Pool and the related software
definitions, perform the following tasks:
1. Enter the string SWU_Pri against the Find field of the Tivoli Intelligent
Orchestrator user interface navigation pane (Figure 6-28), and verify whether
the three expected objects are listed.
Figure 6-28 Listing the SWU_Pristine objects
2. Select SWU_Pristine_Server_Pool and verify whether the assigned
template is SWU_Pristine_Server_Template.
3. From the Resource Pool page, select SWU_Pristine_Server_Template and
verify whether the template references the SWU_Pristine_Server_Stack.
4. From the Template page, select SWU_Pristine_Server_Stack and verify
whether it includes the following three entries:
– SWU_Windows_2000_Server_SP4_Stack
– SWU IBM Java Runtime Environment 1.4.1 Windows
– The iterator
The resource pool for the Pristine servers in the SWU environment is now
created, including the underlying server template and the related software stack.
Your next action is to define the hosting platform in order to be able to create
virtual servers and make them available in the SWU_Pristine_Server_Pool. This
is described in “Exercise 7: Creating virtual servers” on page 91.
Chapter 6. Exercise 6: Preparing the software-related objects for the Pristine systems
89
90
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
7
Chapter 7.
Exercise 7: Creating virtual
servers
After the exercise described in Chapter 6, “Exercise 6: Preparing the
software-related objects for the Pristine systems” on page 63 is completed, the
IBM Software University (SWU) data center model (DCM) contains the objects
that are shown in the frame named A in Figure 7-1. This is the starting point for
this exercise.
© Copyright IBM Corp. 2006. All rights reserved.
91
7.1 The objective of this exercise
In this exercise, you define a host platform server capable of sharing its
resources to host multiple logical server partitions (LPARs). In addition, you
define shareable resources and create a number of virtual servers. The shared
resource in the SWU tutorial environment is the Network Interface Card (NIC) of
the TIOServer system. On completion of this exercise, you discover that a
number of IP addresses have been added to the TIOServer Ethernet adapter.
The virtual servers you create are made members of the
SWU_Pristine_Server_Pool, and automatically receive the required software
modules in order to be compliant with the definitions in the
SWU_Pristine_Server_Template.
92
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
On completion of this exercise, the additional resources required to complete the
definition of the SWU environment objects shown in the frame labeled B in
Figure 7-1 are defined.
Figure 7-1 Virtual server creation: Starting and ending environments
Figure 7-1 shows the objects that are created in the DCM in this exercise. These
objects are those that are required to create a resource pool in which to place the
servers that may eventually be provisioned into the production environment. After
the resource pool is defined, continue to the next exercise described in
Chapter 8, “Exercise 8: Defining the composite application infrastructure
environment” on page 119.
As with the resource pools, the configuration of the virtual servers relies on a
template. This template is used to control the allocation of particular resources,
which are owned by the host platform server, to the virtual servers. This is known
as a Virtual Server TemplateVirtual Server Template. In addition to the Virtual
Chapter 7. Exercise 7: Creating virtual servers
93
Server Template, for the SWU environment, make use of a Normal Server
Template with the associated software stack to control the installation of an
operating system (OS) on the virtual servers to be created. Finally, when the
virtual servers are operational, they are moved to the
SWU_Pristine_Server_Pool, which ensures that the software components on the
virtual servers are in compliance with the server template defined for the
resource pool. All this is handled by the logical device operation,
HostPlatform.CreateVirtualServer.
The logic built into the workflow implementing the
HostPlatform.CreateVirtualServer for the SWU environment performs the
following tasks:
򐂰 Uses the Virtual Server Template to allocate the hardware resources
򐂰 Looks up a variable in the Virtual Server Template to identify the server
template to be used to control the IP interface allocation on the host platform
server and installation of the OS installation, based on the software stack
association to the server template
򐂰 Looks up another variable in the Virtual Server Template to identify the
resource pool to move the virtual server into on completion
򐂰 Issues the SparePool.Initialize LDO to make the virtual server compliant with
the pool definitions
In order to make this happen, perform the following:
1.
2.
3.
4.
Create a host platform server
Create the server template for OS installation
Create the Virtual Server Template
Create virtual servers
If you are comfortable with defining virtual servers using the Tivoli Intelligent
Orchestrator user interface, use the shortcut described in 7.1.1, “Shortcut:
Creating the host platform server and the Virtual Server Template” to complete
all the tasks in this exercise.
7.1.1 Shortcut: Creating the host platform server and the Virtual
Server Template
A set of Extensible Markup Language (XML) files for the definition of the objects
in this exercise is loaded into the LocalFileRepository in your TIOServer system
on installation of the SWU_2006 tcdriver. Following are the relevant files:
򐂰 hostplatformservers.xml
򐂰 servertemplatenew.xml
򐂰 virtualservertemplate.xml
94
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
All these files are referenced from the file named SWU_HOSTING.xml. In
addition, in order to create the servers, a workflow called
SWU_CreateVirtualServers is provided.
To establish the foundation for the creation of the virtual servers, perform the
following tasks:
1. Import the object definitions by performing the following tasks:
– Import all the definitions in one step by issuing the following commands
from the TIOServer system command line:
cd %TIO_HOME%\..\SWrepository\SWU\xml
%TIO_HOME%\tools\xmlimport file:SWU_HOSTING.xml
– Alternately, import the files one-by-one, and view the results in the Tivoli
Intelligent Orchestrator user interface. Perform one of the following actions
for each of the files listed earlier, and in the same sequence they are listed
in:
•
Execute the SWU_ImportXML workflow by providing a value for the
xmlFile parameter of <file_name>, either by invoking the workflow from
the user interface or by issuing the following command from the Tivoli
Intelligent Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0
SWU_ImportXML xmlFile=<file_name>
•
Issue the following command from the TIOServer system command
line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFile=<file_name>"
2. (Optional step) Clean up the SWU_NEW resource pool created earlier in
order to be able to define the SWU_New_Windows_Server_Template. Issue
the following commands from the TIOServer system command line:
cd %TIO_HOME%\..\SWrepository\SWU\xml
%TIO_HOME%\tools\dcmquerycommand resourcepoolnew_delete.dcm
3. Ensure that the correct device driver gets assigned to the template. Use one
of the following methods:
– Execute the SWU_AssignDriverToTemplate workflow by providing a value
for the ServerTemplateName parameter of
SWU_New_Windows_Server_Template, either by invoking the workflow
Chapter 7. Exercise 7: Creating virtual servers
95
from the user interface or by issuing the following command from the Tivoli
Intelligent Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0
SWU_AssignDriverToTemplate
ServerTemplateName=SWU_New_Windows_Server_Template
– Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd
SWU_AssignDriverToTemplate
"ServerTemplateName=SWU_New_Windows_Server_Template"
4. Create the virtual servers by starting the SWU_Create_VirtualServers
workflow in one of the following ways:
– Execute the SWU_CreateVirtualServers workflow by providing a value for
the numberOfServers parameter of 6, either by invoking the workflow from
the user interface or by issuing the following command from the Tivoli
Intelligent Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0
SWU_Create_VirtualServers numberOfServers=6
– Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd
SWU_Create_VirtualServers "numberOfServers=6"
After the process of starting the workflow is complete, which, within the
constraints of a tutorial environment, takes a while, continue to 7.6, “Verifying the
creation of the virtual servers” on page 114.
7.2 Creating a host platform server
The first step involved in creating a number of virtual servers is creating a host
platform server, which is the term for a partitionable server in the SWU
environment. This is used to host the virtual servers, which in turn host various
infrastructure components and application instances.
The host platform server consists of a specialized server definition, a dedicated
switch, and a Virtual Server Template that is used to determine how resources
are allocated to the virtual servers hosted by the hosting platform. In the SWU
environment, the only resource that is shared with the virtual servers is the NIC.
96
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
In the SWU environment, you use the TIOServer system to host the IP address
that will be assigned to the hosting platform. In a production environment, the
hosting platform would be a physical or logical partitionable system (such as IBM
eServer™ or VMware ESX Server) that has been discovered or manually added
to the DCM.
Using the Tivoli Intelligent Orchestrator user interface, the dedicated switch is
created seamlessly when the hosting platform is defined.
7.2.1 Shortcut: Creating the host platform server
An XML file for the definition of the SWU_HostPlatformServer and the related
SWU_VirtualServer_Template is loaded into the LocalFileRepository in your
TIOServer system on installation of the SWU_2006 tcdriver. To import these
definitions into your DCM, perform one of the following tasks:
򐂰 Execute the SWU_ImportXML workflow by providing a value for the xmlFile
parameter of hostplatformservers, either by invoking the workflow from the
user interface or by issuing the following command from the Tivoli Intelligent
Orchestrator command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=hostplatformservers
򐂰 Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFile=hostplatformservers"
When the process of creating the workflow is complete, continue to 7.3,
“Creating the server template for the operating system installation” on page 102.
Chapter 7. Exercise 7: Creating virtual servers
97
7.2.2 Exercise: Defining the host platform server
To create the host platform server, perform the following tasks:
1. Navigate to Inventory → Servers → Virtual Servers. In the Virtual Servers
page, select Edit → Add a Host Platform Server, and provide a Name and
Locale, as shown in Figure 7-2. Click Save.
Figure 7-2 Creating a host platform server
The Virtual Servers page is populated with the new host platform server
(Figure 7-3).
Figure 7-3 Host platform server: Overview
98
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
2. To edit the SWU_HostPlatformServer, double-click the link named
SWU_HostPlatformServer in the Name column. This opens the General
page of the SWU_HostPlatformServer shown in Figure 7-4.
Figure 7-4 Host platform server: Properties
3. To assign a management interface, select Edit → Add Interface, and add
the relevant interface properties, as shown in Figure 7-5.
Figure 7-5 Host platform server: Management interface
Chapter 7. Exercise 7: Creating virtual servers
99
4. To define a NIC resource that can be shared with the virtual servers, select
Edit → Add NIC, and provide the relevant information, as shown in
Figure 7-6.
Figure 7-6 Host platform server: Shared NIC
5. Because the SWU_HostPlatformServer will be used actively to manage IP
interfaces for the virtual servers, assign an OS to the host platform server
object in order to provide an implementation for the
OperatingSystem.AddNetworkInterface LDO.
To register the Windows 2000 Server SP4 OS to the
SWU_HostPlatformServer, open the Software page of the host platform
server, and perform these tasks:
100
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
a. Select Edit → Add Software Installation. Provide the relevant
information, as shown in Figure 7-7, and click Save to activate the
registration.
Figure 7-7 Associating the OS with the host platform server
b. The changes you apply are visible in the Software page (Figure 7-8).
Figure 7-8 Host platform server: Software properties
Chapter 7. Exercise 7: Creating virtual servers
101
6. To assign a device driver, open the Workflows page. Select Edit → Assign
Device Driver. Select the driver named SWU_Simulated_HostplatformDM
provided in the SWU_2006.tcdriver. Your LDO associations look as shown in
Figure 7-9.
Figure 7-9 Host platform server: Device driver
7. Assign the proper credentials for the SWU_HostPlatformServer. Follow the
procedure outlined in 3.3, “Defining the access points and the credentials” on
page 26 or use the shortcut, which involves issuing the following command
from the TIOServer command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd
SWU_SetDeviceCredentials "deviceName=SWU_HostPlatformServer"
This completes the creation of the host platform server. You are now ready to
define the server template that is to be used to ensure OS installation on the new
virtual servers hosted by the host platform server.
7.3 Creating the server template for the operating
system installation
The server template used to control IP interface allocation and OS installation on
virtual servers in the SWU environment is called
SWU_New_Windows_Server_Template. To define the template, perform the
tasks described in this section.
102
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
7.3.1 Shortcut: Creating the SWU_New_Windows_Server_Template
An XML file for the definition of the SWU_New_Windows_Server_Template is
loaded into the LocalFileRepository in your TIOServer system on installation of
the SWU_2006 tcdriver. To import these definitions into your DCM, perform one
of the following tasks:
򐂰 Execute the SWU_ImportXML workflow by providing a value for the xmlFile
parameter of servertemplatenew, either by invoking the workflow from the
user interface or by issuing the following command from the Tivoli Intelligent
Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=servertemplatenew
򐂰 Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFile=servertemplatenew"
Because of inconveniences in the XML support in TIO V3.1 FP2, you have to
create the resource pool prior to defining the SWU New Servers Template. To
clean this pool, issue the following command from the TIOServer system
command line:
%TIO_HOME%\tools\dcmquerycommand
%TIO_HOME%\..\SWrepository\SWU\xml\resourcepoolnew_delete.xml
After the process of issuing the dcmquery command is complete, continue to
7.4, “Creating the Virtual Server Template” on page 107.
7.3.2 Exercise: Defining the SWU_New_Windows_Server_Template
To define the SWU_New_Windows_Server_Template manually, perform the
following tasks:
1. Navigate to Inventory → Servers → Physical Servers → Server
Templates. Use the Edit → Add Server Template menu option to provide
the name SWU_New_Windows_Server_Template, as shown in Figure 7-10. Click
Save.
Figure 7-10 Creating a new server template
Chapter 7. Exercise 7: Creating virtual servers
103
2. In the Software Templates Inventory page, select
SWU_New_Windows_Server_Template.
3. In the General page, select Edit → Add NIC to add the generic network
definitions to be associated with the servers that will be configured according
to this template.
In the New Network Interface Card Template pop-up, select the
SWU_VLAN-001 VLAN, as shown in Figure 7-11, and click Save.
Figure 7-11 Assigning VLAN to the server template
4. You are taken back to the General page of the server template, which is
similar to that shown in Figure 7-12. Add an interface to the NIC by selecting
the Edit icon to the far right of the new NIC, and select Add Interface.
In the Subnetwork field of the New Network Interface Template pop-up, select
the subnet named 192.168.1.0/24, and click Save.
Figure 7-12 Associate subnet with VLAN in server template
104
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
The interface is now visible in the Network section of the General page of the
server template (Figure 7-13).
Figure 7-13 The server template interface definitions
5. To force the installation of an OS on the virtual servers, add the SWU
Windows 2000 Server SP4 Stack to the server template (Figure 7-14). Click
Save.
Figure 7-14 Adding the software stack to the server template
Chapter 7. Exercise 7: Creating virtual servers
105
6. Use the Edit → Associate Software Stack menu option to provide the
relevant parameters. The General page must be similar to that shown in
Figure 7-15.
Figure 7-15 Server template properties
7. The last step in the creation of the SWU_New_Windows_Server_Template is
assigning the device driver, which in turn assigns a set of customized
workflows to the template. From the Workflows page, select Edit →
Associate Device Driver, and select the SWU_ServerTemplateDM device
driver as shown in Figure 7-16.
Figure 7-16 The server template device driver
The SWU_New_Windows_Server_Template is created and you are ready to
define the Virtual Server Template for the SWU environment.
106
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
7.4 Creating the Virtual Server Template
As mentioned earlier, the Virtual Server Template is used to control the resource
allocation from the host platform server to the virtual servers. In the SWU
environment, allocate only one NIC resource to each of the virtual servers. This
maps to the managed NIC defined for the SWU_HostPlatformServer.
7.4.1 Shortcut: Creating the Virtual Server Template
An XML file for the definition of the SWU_VirtualServer_Template is loaded into
the LocalFileRepository in your TIOServer system on installation of the
SWU_2006 tcdriver. To import these definitions into your DCM, perform one of
the following tasks:
򐂰 Execute the SWU_ImportXML workflow by providing a value for the xmlFile
parameter of virtualservertemplates, either by invoking the workflow from the
user interface or by issuing the following command from the Tivoli Intelligent
Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=virtualservertemplates
򐂰 Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFile=virtualservertemplates"
When the workflow execution is complete, continue to 7.5, “Creating the virtual
servers” on page 110.
Chapter 7. Exercise 7: Creating virtual servers
107
7.4.2 Exercise: Defining the Virtual Server Template
To create the SWU_VirtualServer_Template, perform the following tasks:
1. Navigate to Inventory → Servers → Virtual Servers → Server Templates.
Select Edit → Add a Server Template and provide a value of
SWU_VirtualServer_Template for the Template Name, and click Save.
This results in the new Virtual Server Template being available in the Virtual
Server Template Inventory page (Figure 7-17).
Figure 7-17 Virtual Server Templates
2. To specify the details of the Virtual Server Template, double-click the name of
the relevant template, in this case, SWU_VirtualServer_Template. The
Virtual Server General page is displayed. Figure 7-18 shows that no resource
requirements have been added at this point.
Figure 7-18 Virtual Server Template properties
108
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
3. To add the resource requirements to the Virtual Server Template, select
Edit → Add a Resource Requirement and provide the relevant information
in order to create a requirement for a single instance of the NIC resource.
Click Save (Figure 7-19).
Figure 7-19 Adding resource requirements to the Virtual Server Template
Figure 7-20 shows how the resource requirement has been added.
Figure 7-20 Virtual Server Template with new resource requirements
4. The workflows that will be executed when a virtual server is allocated to the
host platform server, perform an initial configuration of the hardware and
software resources on the server in accordance with the Virtual Server
Template. It then assigns a device driver to the new virtual server in an
attempt to assign the server to a resource pool. To control these operations,
use the variables defined at the Virtual Server Template level, which holds the
names of the server template, the device driver, and the default pool.
Chapter 7. Exercise 7: Creating virtual servers
109
To define the variables, open the Variables page and select Edit → Add
Variable to define the defaultpoolname, devicedrivername, and
servertemplatename variables, as shown in Figure 7-21.
Figure 7-21 Virtual Server Template variables
The SWU_VirtualServer_Template setup is now complete. Proceed to the next
task, which is creating virtual servers.
7.5 Creating the virtual servers
In order to populate the SWU environment with servers, create a number of
virtual servers that will be provisioned into the composite application tiers in order
to support the composite application. The virtual servers, which will be created in
the SWU environment, will be hosted by the SWU_HostPlatformServer, which, in
the SWU tutorial situation, is defined on an IP address owned by the TIOServer
system. In essence, this setup allows the TIOServer to assume multiple
personalities and appear to the Tivoli Intelligent Orchestrator as multiple servers.
When this exercise is complete, six new virtual servers with names ranging from
SWU-0 to SWU-5 are created.
Virtual servers can be created from the Tivoli Intelligent Orchestrator user
interface by importing an XML file or by executing a workflow that automates the
task. If you are confident about the process of creating virtual servers, do so by
following the procedure described 7.5.1, “Shortcut: Creating the virtual servers”,
and thereafter continue to 7.6, “Verifying the creation of the virtual servers” on
page 114.
110
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
7.5.1 Shortcut: Creating the virtual servers
A workflow for the automated creation of the virtual servers is loaded into the
Tivoli Intelligent Orchestrator system on installation of the SWU_2006 tcdriver.
Create the virtual servers by starting the SWU_Create_VirtualServers workflow
in one of the following ways:
򐂰 Execute the SWU_CreateVirtualServers workflow by providing a value for the
numberOfServers parameter of 6, either by invoking the workflow from the
user interface or by issuing the following command in the Tivoli Intelligent
Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0
SWU_Create_VirtualServers numberOfServers=6
򐂰 Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd
SWU_Create_VirtualServers "numberOfServers=6"
When the workflow execution is complete, continue to 7.6, “Verifying the creation
of the virtual servers” on page 114.
7.5.2 Exercise: Defining the virtual servers
To create the virtual servers manually, perform the following tasks:
1. Navigate to Inventory → Servers → Virtual Servers. Use the Edit →
Allocate a Virtual Server menu option and supply the relevant information,
as shown in Figure 7-22.
Make sure that you specify the host platform SWU_HostPlatformServer and
the Virtual Server Template SWU Virtual Server Template created earlier,
Chapter 7. Exercise 7: Creating virtual servers
111
and select the Use Logical Operation check-box. Click Save after providing
all the information.
Figure 7-22 Creating a new virtual server
The system now executes the HostPlatform.CreateVirtualServer, which in
turn executes the SWU_Simulated_HostPlatform_CreateVirtualServer
workflow that implements the expected behavior because you associated the
SWU_Simulated_HostPlatformDM with the SWU_HostPlatformServer. The
sequence of action that takes place is as follows:
a. From the Virtual Server template, two NICs are allocated to the new server
b. A new IP address is allocated on the SWU_HostPlatformServer (in fact,
this will be in the TIOServer in the SWU environment) and the address is
allocated as the management address of the virtual server and as the
managed address on the SWU_HostPlatformServer
c. The software components, including the OS defined in the SWU New
Servers Stack, are installed on the virtual server
112
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
d. The server is moved to the SWU_Pristine_Server_Pool, and the
SparePool.Initialize LDO is started. This ensures the following:
•
An IP address is allocated in accordance with the definitions in the
server template (SWU_Pristine_Server_Template) associated with the
resource pool
•
The software components that are defined in the software stack
(SWU_Pristine_Server_Stack) associated with the server template for
the resource pool are installed
These steps take a while to complete. To follow the process, navigate to
Configuration → Deployment Requests, and check the status of the
specific deployment request submitted from the Tivoli Intelligent Orchestrator
user interface.
When the HostPlatform.CreateVirtualServer logical operation is completed,
the new virtual server can be seen in the Virtual Servers page. Select
Inventory → Servers → Virtual Servers to access this page. The Virtual
Servers page is similar to that shown in Figure 7-23.
Figure 7-23 Virtual server inventory
Chapter 7. Exercise 7: Creating virtual servers
113
2. To create six virtual servers, repeat step 1 five times or use the procedure
detailed in the shortcut described in 7.5.1, “Shortcut: Creating the virtual
servers” on page 111.
After all the virtual servers are created, your Virtual Server inventory looks as
shown in Figure 7-24.
Figure 7-24 Virtual servers hosted by the SWU_HostPlatformServer
This concludes the process of creating the virtual servers.
7.6 Verifying the creation of the virtual servers
At this point you have created the following:
򐂰 A host platform server
򐂰 A resource pool for the servers that are available to host your composite
application components
򐂰 A number of servers that have an OS, and an IBM JRE 1.4.1 component
installed
114
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
To verify the creation of the virtual servers, perform the following tasks:
1. Navigate to Inventory → Servers → Physical Servers → Resource Pools.
Open SWU_Pristine_Servers_Pool. The resource pool must be similar to
that shown in Figure 7-25.
Figure 7-25 Servers (virtual) in the SWU_Pristine_Server_Pool
Chapter 7. Exercise 7: Creating virtual servers
115
2. In addition, verify from the General page of any server that belongs to the
resource pool, whether an IP address of 192.168.1.2xx is assigned, and
whether a shared NIC is allocated from the SWU_HostPlatformServer, as
shown in Figure 7-26.
Figure 7-26 Virtual server hardware properties
3. Verify the installed software by opening the details of any of the servers in the
resource pool, and take a closer look at the Software page. Pay attention to
the Status field, which tells you whether the software configuration of the
server is compliant with the template. As shown in Figure 7-27, the expected
116
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
status is Compliant. Each server must have a software installation object for
each of the following software definitions:
– SWU_Windows_2000_Server_SP4_Stack
– SWU IBM Java Runtime Environment 1.4.1 Windows
Figure 7-27 Virtual server software associations
4. To conduct a final verification of your success, open a command line in the
TIOServer system and issue the ipconfig command. An IP address in the
192.168.1.2xx range for each of the virtual servers must be visible, as shown
in Example 7-1.
Example 7-1 TIOServer IP configuration
C:\ibm\tivoli\SWrepository\SWU\xml>ipconfig
Windows 2000 IP Configuration
Ethernet adapter Ethernet:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . :
Subnet Mask . . . . . . . . . . . :
IP Address. . . . . . . . . . . . :
Subnet Mask . . . . . . . . . . . :
IP Address. . . . . . . . . . . . :
Subnet Mask . . . . . . . . . . . :
IP Address. . . . . . . . . . . . :
Subnet Mask . . . . . . . . . . . :
IP Address. . . . . . . . . . . . :
tivdemo.com
192.168.1.205
255.255.255.0
192.168.1.204
255.255.255.0
192.168.1.203
255.255.255.0
192.168.1.202
255.255.255.0
192.168.1.201
Chapter 7. Exercise 7: Creating virtual servers
117
Subnet Mask . .
IP Address. . .
Subnet Mask . .
IP Address. . .
Subnet Mask . .
IP Address. . .
Subnet Mask . .
IP Address. . .
Subnet Mask . .
IP Address. . .
Subnet Mask . .
IP Address. . .
Subnet Mask . .
Default Gateway
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
:
:
:
:
:
:
:
255.255.255.0
192.168.1.200
255.255.255.0
192.168.1.5
255.255.255.0
192.168.1.4
255.255.255.0
192.168.1.3
255.255.255.0
192.168.1.2
255.255.255.0
192.168.1.1
255.255.255.0
192.168.1.10
This concludes the creation of the virtual servers. Proceed to “Exercise 8:
Defining the composite application infrastructure environment” on page 119.
118
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
8
Chapter 8.
Exercise 8: Defining the
composite application
infrastructure environment
The starting point for this exercise is the IBM Software University (SWU) data
center model (DCM) with the objects defined representing the components
shown in the frame labeled A in Figure 8-1.
© Copyright IBM Corp. 2006. All rights reserved.
119
8.1 The objective of this exercise
In this exercise, you define the software objects that are necessary to establish
the basic application infrastructure for the composite application. In practical
terms, this means defining software definitions, software packages, and software
stacks for the database, the application, and the Web servers, which in turn host
the composite application components such as server pages, servlets, and
databases.
The objects that you create in this exercise are included in the frame labeled B in
Figure 8-1.
Figure 8-1 Application infrastructure implementation: Starting and
ending environments
120
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
As shown in Figure 8-1, the objects that will be created in the DCM in this
exercise are those that are necessary to prepare the software infrastructure
components to be used in provisioning the composite application. Define the
software stacks and the underlying software definitions and software packages
to be used for the infrastructure components of each of the layers of the SWU
composite application environment.
The SWU composite application you will provision is, like most other composite
applications, based on the following three layers:
򐂰 A Web layer that accepts requests from users and provides browser-based
navigation and interaction facilities
򐂰 An Application layer that executes the code to perform the business
transactions
򐂰 A Database layer that is responsible for data persistence and security
The core components that provide the application infrastructure in the SWU
environment are:
򐂰 IBM Hypertext Transfer Protocol (HTTP) Server V2.0
򐂰 IBM WebSphere Application Server V5.1
򐂰 IBM DB2 Universal Database™ (UDB) Enterprise Edition V8.2
As described here, you must create a unique software stack for each application
tier. Each of these is made up of an infrastructure stack and an
application-specific module. Because you have already prepared the basic
system platforms in the SWU_Pristine_Server_Pool using the
SWU_Pristine_Server_Stack, the stacks for the infrastructure components for
each tier must be based on the SWU Pristine Server Stack and include only the
components required to provide the infrastructural support for the
application-specific modules. These are defined in Chapter 9, “Exercise 9:
Defining the composite application software” on page 161.
This exercise focuses on the components in the frame labeled B in Figure 8-1.
In the SWU tutorial environment, reuse the database and application servers that
are already in place to support the Tivoli Intelligent Orchestrator environment, so
that the object definitions in the DCM are based on the software simulator. For
the Web servers that will be members of a cluster domain, reuse the installed
IBM HTTP Server V2.0 installation and IBM Java Runtime Environment (JRE)
V1.4.1 on the TIOServer. However, for each virtual server that is provisioned to
the SWU Composite Web Tier, an HTTP server instance is created. To provide
the definition templates and the workflows to implement the desired behavior, a
specialized tcdriver for the HTTP Server in the SWU environment is provided.
When installed, all the required definitions are automatically loaded into your
environment.
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
121
The tasks you must complete in this exercise include:
1.
2.
3.
4.
Creating the SWU_DB2_Server_Stack
Creating the SWU_WAS_Server_Stack
Creating the SWU_HTTP_Server_Stack
Installing the prerequisite software on the host platform server
This exercise shows you three different ways of defining software definitions and
software packages, that is, by using a wizard, by creating the objects manually,
and by installing a tcdriver that includes the Extensible Markup Language (XML)
to create the objects.
If you are comfortable defining software components using the Tivoli Intelligent
Orchestrator user interface, use the shortcut described in 8.1.1, “Shortcut:
Creating all the infrastructure software objects” to complete all the tasks in this
exercise, and continue with Chapter 9, “Exercise 9: Defining the composite
application software” on page 161.
8.1.1 Shortcut: Creating all the infrastructure software objects
A workflow for the automated creation of the infrastructure software stacks and
related software objects is loaded into the Tivoli Intelligent Orchestrator system
on installation of the SWU_2006 tcdriver.
To create the software objects for the infrastructure environment, issue the
following commands from the TIOServer system command line:
cd %TIO_HOME%\..\SWrepository\SWU\xml
%TIO_HOME%\tools\tc-driver-manager fid SWU_IBMHttp_20_Win
%TIO_HOME%\tools\xmlimport file:SWU_SOFTWARE.xml
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf
SWU_HostPlatformServer_InstallSW "ServerName=SWU_HostPlatformServer"
When the workflow execution is complete, continue to 8.9, “Verifying the
infrastructure software definitions” on page 158.
122
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
8.2 Creating the SWU_DB2_Server_Stack
To define the DCM objects that are required to create a software stack to support
the composite application database layer, define the following objects
(Figure 8-2):
򐂰 Software package: SWU IBM DB2 Server 8.2 Simulated Installable
򐂰 Software product: SWU IBM DB2 Server 8.2
򐂰 Software stack: SWU_DB2_Server_Stack
Figure 8-2 SWU_DB2_Server_Stack software components
The steps that are to be followed to accomplish this with the help of the Import
Software Package wizard are described in 8.2.2, “Exercise: Creating a software
definition for the DB2 Server using the wizard” on page 124. However, to define
these objects automatically, use the procedure outlined in the shortcut described
in 8.2.1, “Shortcut: Creating the DB2 software definitions and the
SWU_DB2_Server_Stack”.
8.2.1 Shortcut: Creating the DB2 software definitions and the
SWU_DB2_Server_Stack
An XML file for the automated creation of the SWU_DB2_Server_Stack and the
related software objects is loaded into the Tivoli Intelligent Orchestrator system
on installation of the SWU_2006 tcdriver.
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
123
To import these definitions into your DCM, perform one of the following tasks:
򐂰 Execute the SWU_ImportXML workflow by providing a value for the xmlFile
parameter of softwarestackDB2, either by invoking the workflow from the user
interface or by issuing the following command from the Tivoli Intelligent
Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=softwarestackDB2
򐂰 Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFile= softwarestackDB2"
When the workflow execution is complete, continue to 8.3, “Creating the
SWU_WAS_Server_Stack” on page 134.
8.2.2 Exercise: Creating a software definition for the DB2 Server
using the wizard
To create the software definition and the software package for the DB2 Server in
the SWU environment, perform the following tasks:
1. Navigate to Tasks → Software Provisioning → Import Software Package.
The welcome window shown in Figure 8-3 is displayed. Click Next.
Figure 8-3 Import Software Package: Welcome
124
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
2. In the Define Software Product window, configure the basic properties of the
software product that will be created through the wizard. Provide the relevant
information as shown in Figure 8-4, and click Next.
Figure 8-4 Import Software Package: Define Software Product
3. Define the software package (the files to be installed). In this case, the
installation is simulated. Because the DB2 instance on the TIOServer is
already installed, there are no images to define. Select the file repository
SWU_FileRepository, and leave the PackagePath and FileName fields
empty, as shown in Figure 8-5. Click Next to continue.
Figure 8-5 Import Software Package: Select Package
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
125
4. Select the device driver to control the behavior of the installation of this
software product. In the SWU environment, select the driver
SoftwareSimulator_SoftwareInstallable (Figure 8-6), and click Next.
Figure 8-6 Import Software Package: Choose Installation Method
5. Because some drivers require parameters, you are given the option of
supplying them in a page that is similar to the one shown in Figure 8-7.
Because this does not apply in the SWU environment, click Next to continue.
Figure 8-7 Import Software Package: Fill properties
126
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
6. You are presented with a summary of the actions you selected (Figure 8-8).
Verify whether the options are correct, and click Finish to create the software
product and the software package objects for the SWU DB2 Server 8.2.
Figure 8-8 Import Software Package: Summary
7. After the objects are created, you are presented with a list of the available
software products. Limit the scope of the list by entering SWU against the Find
field, and click Enter. Your Software Catalog display must look similar to that
shown in Figure 8-9.
Figure 8-9 SWU Software Catalog
8. To add the requirements and the capabilities, customize the software product
and the software package created by the wizard. In addition, you may want to
rename the software package to avoid confusion in the future.
To edit the software product, double-click the link named SWU IBM DB2
Server 8.2. This brings up the details of the software product.
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
127
To add capabilities to the SWU IBM DB2 Server 8.2 software product,
complete the following tasks:
a. Use the Edit → Add Capability Type menu option to add the capability
DATABASE.
b. Use the Edit → Add Capability menu option twice to add the capabilities
shown in Table 8-1.
Table 8-1 SWU IBM DB2 Server 8.2 capabilities
Name
Value
database.family
DB2
database.version
8.2
c. When you expand the Requirements and Capabilities section of the
General page for the SWU IBM DB2 Server 8.2, information that is similar
to that shown in Figure 8-10 is displayed.
Figure 8-10 SWU IBM DB2 Server V8.2 capabilities
128
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
9. To rename the SWU IBM DB2 Server 8.2 software package, double-click the
name in the Installables section of the General page of the software product.
When the software package details page opens, perform the following tasks:
a. Use the Edit → Properties menu option from the software package
General page. Set the properties according to the information shown in
Figure 8-11 and click Save.
Figure 8-11 SWU IBM DB2 Server 8.2 properties
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
129
b. Use the Edit → Add Requirement menu option to add a requirement for
Windows 2000 Server SP4 to specify that this package is intended for a
specific operating system (OS). The requirement type is OS and the name
os.family, as shown in Figure 8-12. Click Save to return to the General
page.
Figure 8-12 SWU IBM DB2 Server 8.2 requirements definitions
c. When you expand the Requirements section of the software package,
you see that the requirement is defined (Figure 8-13). Note that the name
of the software package is changed.
Figure 8-13 SWU IBM DB2 Server 8.2 requirements
d. Go to the Workflows page of the SWU IBM DB2 Server 8.2 Simulated
Installable, and use the Edit → Assign Device Driver option to assign the
SoftwareSimulator_SoftwareInstallable to the object.
e. To return to the software product definition, click the software product link
named SWU IBM DB2 Server 8.2 in the top-right corner of the software
package’s General page. The software definition page looks as shown in
Figure 8-14.
Note that the name of the Installable has changed, and a Software Type of
DATABASE is assigned.
130
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
Figure 8-14 also shows that a Configuration Template named Default is
created automatically. The type of the template is INSTALLATION, which,
when the software product is installed, ensures the creation of a software
installation object. At this point, there is no necessity to further configure
the Configuration Template.
Figure 8-14 SWU IBM DB2 Server V8.2 properties
You have now completed the process of defining the basic software product to
be used in the SWU environment. You can now include this software package
into a software stack, which will in turn be assigned to an application tier.
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
131
8.2.3 Exercise: Creating a software stack
To create a software stack named SWU_DB2_Server_Stack, perform the
following tasks:
1. Navigate to Inventory → Software Catalog → Definitions → Software
Stacks. Use the Edit → Add Software Stack menu option to create a new
software stack, and name it SWU_DB2_Server_Stack, as shown in Figure 8-15.
Click Save after providing the relevant information for the parameters, as
shown in Figure 8-15.
Figure 8-15 Creating the SWU_DB2_Server_Stack
2. Open the newly created software stack, and use the Edit → Add Stack Entry
to add the SWU_Pristine_Server_Stack. When prompted, select the default
configuration template, and click Finish in the Customize Configuration
Template dialog.
132
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
3. Repeat step 2, and add the SWU IBM DB2 Server 8.2 software product.
Use the Edit → Add Installable menu option to add an iterator. This ensures
that the entries you have just added to the stack are installed in the sequence
specified in the Modules section of the software stack’s General page. This
page must be similar to that shown in Figure 8-16.
Figure 8-16 SWU_DB2_Server_Stack properties
You have created the software stack for the DB2 Server implementations that
support the database layer of the composite application in the SWU
environment. This completes the creation of the SWU_DB2_Server_Stack and
the related software objects. You can now create the stack for the application
layer, as described in 8.3, “Creating the SWU_WAS_Server_Stack”.
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
133
8.3 Creating the SWU_WAS_Server_Stack
To define the DCM objects required to create the software stack to support the
application layer of the composite application, define the following components
(Figure 8-17):
򐂰 Software package: SWU IBM WebSphere Application Server V5.1 Simulated
Installable
򐂰 Software product: SWU IBM WebSphere Application Server V5.1
򐂰 Software stack: SWU_WAS_Server_Stack
Figure 8-17 SWU_WAS_Server_Stack software components
The tasks you must perform required to accomplish this are outlined in 8.4,
“Creating software definitions for the application server” on page 136. However,
to define these objects automatically, use the procedure outlined in 8.3.1,
“Shortcut: Create WebSphere Application Server software definitions and
SWU_WAS_Server_Stack”.
134
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
8.3.1 Shortcut: Create WebSphere Application Server software
definitions and SWU_WAS_Server_Stack
An Extensible Markup Language (XML) file for the automated creation of the
SWU_WAS_Server_Stack and the related software objects is loaded into the
Tivoli Intelligent Orchestrator system on installation of the SWU_2006 tcdriver.
To import these definitions into your DCM, perform one of the following tasks:
򐂰 Execute the SWU_ImportXML workflow by providing a value for the xmlFile
parameter of softwarestackWAS, either by invoking the workflow from the
user interface or by issuing the following command from the Tivoli Intelligent
Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=softwarestackWAS
򐂰 Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFile= softwarestackWAS"
When the workflow execution is completed, continue to 8.7, “Creating the
SWU_HTTP_Server_Stack” on page 145.
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
135
8.4 Creating software definitions for the application
server
Perform the tasks described in 8.4.1, “Exercise: Manually creating the application
layer software objects” to create the necessary software definitions for a
simulated WebSphere Application Server V5.1 installation.
8.4.1 Exercise: Manually creating the application layer software
objects
To create a software product and a software package for the WebSphere
Application Server in the SWU environment, perform the following tasks:
1. Navigate to Inventory → Software Catalog → Definitions → Software
Products. Use the Edit → Add Software Product menu option to create a
new software product. Supply the relevant information, as shown in
Figure 8-18. When you click Save, you are taken back to the Software
Catalog.
Figure 8-18 Creating the SWU IBM WebSphere Application Server
software product
f. From the Software Catalog, click the link named SWU IBM WAS Server
5.1. (You may have to scroll a few pages or filter the list of objects shown to
find it.) This takes you to the General page of the SWU IBM WebSphere
Application Server V5.1 software product.
To define the capabilities for the SWU IBM WebSphere Application Server
V5.1 software product, perform the following tasks:
a. Use the Edit → Add Capability Type menu option and add the capability
SERVLET_ENGINE.
136
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
b. Use the Edit → Add Capability menu option and add the capability
shown in Table 8-18.
Table 8-2 SWU IBM WebSphere Application Server V5.1 capabilities
Name
Value
servlet.version
1.4.2
When you expand the Requirements and Capabilities section of the
General page of the SWU IBM WebSphere Application Server V5.1, the
information shown is similar to that shown in Figure 8-19.
Figure 8-19 SWU IBM WebSphere Application Server V5.1 capabilities
2. To define a software package that will be used to implement the WebSphere
Application Server, use the Edit → Add Installable option and supply the
required information, as shown in Figure 8-20. Click Save when done.
Figure 8-20 Associating a software installable
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
137
3. To define the requirements for the SWU IBM WebSphere Application Server
V5.1 Simulated Installable, open it by clicking the corresponding link in the
SWU IBM WebSphere Application Server V5.1 software product General
page, and use the Edit → Add Requirement menu option. Add a value of
Windows 2000 Server SP4 for the os.family parameter for the OS
requirement type, as shown in Figure 8-21.
Figure 8-21 Defining a new requirement
4. Go to the Workflows page of the SWU IBM WebSphere Application Server
V5.1 Simulated Installable, and use the Edit → Assign Device Driver option
to assign the SoftwareSimulator_SoftwareInstallable to the object.
Use the browser's Back button to return to the SWU IBM WebSphere
Application Server V5.1 software product definition.
138
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
5. Add a Configuration Template to the SWU IBM WebSphere Application
Server V5.1 software product. Use the Edit → Define Configuration
Template menu option, and supply the required parameters for the
Configuration Template, as shown in Figure 8-22.
Ensure that the device driver SoftwareSimulator_SoftwareInstallation is
assigned. This ensures that this device driver and its related workflows are
assigned to the Software Installation objects that will be created when the
software product is installed. Click Save.
Figure 8-22 Adding a Configuration Template
c. Expand the Configuration Templates section (Figure 8-23) in the General
page of the SWU IBM WebSphere Application Server V5.1 software
product and the Default WebSphere Application Server Installation
Template to verify whether the Configuration Template is created
correctly.
Figure 8-23 Resource templates
This completes the creation of the SWU IBM WebSphere Application Server
V5.1 software product.
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
139
8.5 Creating the software definitions for the database
client
Use either the procedure outlined in 8.2.2, “Exercise: Creating a software
definition for the DB2 Server using the wizard” on page 124 or in 8.4.1, “Exercise:
Manually creating the application layer software objects” on page 136 to create
the software definition for an IBM DB2 Client installation. Apply the relevant
information according to what is provided in Table 8-3.
Table 8-3 DB2 Client configuration parameters
Object
Attribute
Value
Software
Definition
name
SWU IBM DB2
Client 8.2
version
8.2
vendor
IBM
title
IBM DB2
Client 8.2
description
DB2 Client
is-draft
False
software-capability
software-capability
supported-requirement-type
140
Subattribute
Value
name
database.family
value
DB2 Client
name
database.version
value
8.2
DATABASE
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
Object
Attribute
Value
Subattribute
Value
Software
Package
name
SWU IBM DB2 Client 8.2 Simulated Installable
is-device-model
SoftwareSimulator_SoftwareInstallable
locale
en_US
version
8.2
priority
0
file-repository
SWU_FileRepository
status
tested
file name
Software
Resource
Template
path
/
software-requirement
name
os.family
type
OS
enforcement
MANDATORY
"
hosting
true
accept-non-exi
sting
false
value
Windows 2000
Server SP4"
name
SWU IBM DB2 Client Installation
software-resource-type
INSTALLATION
software-resource-device-mod
el
SoftwareSimulator_SoftwareInstallation
multiplicity-type
Unspecified
software-configuration-type
Regular
is-selected
true
template-param
name
InstallDir
value
"C:/ibm/sqllib"
is-changeable
true
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
141
Alternately, perform the following tasks to create your own XML for the creation
of the DB2 Client software definition:
1. Open a command line in the TIOServer system, and issue the following
command:
cd %TIO_HOME%\tools
2. To export the current content of your DCM, issue the following command:
Dcmexport swudcm.xml
3. Edit the mydcm.xml file using WordPad:
Write swudcm.xml
4. Locate the line starting with the string </software-module name="SWU IBM
DB2 Server> and delete the previous line and everything towards the top of
the file, except for the first four lines.
5. Locate the first instance of the string </software-module> and delete the
following line and everything until the end of the file, except the last line.
6. Make the following changes to the file:
a. Change all occurrences of the string Server to string Client.
b. Change the value for software-capability name="database.family" to DB2
Client.
c. Delete the following lines:
<software-requirement name="software.version" type="JRE"
enforcement="MANDATORY" hosting="true"
accept-non-existing="false">
<software-requirement-value value="1.4.1" />
</software-requirement>
7. The contents of the swudcm.xml file must now be similar to that shown in
Example 8-1.
Example 8-1 swudcm.xml file
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE datacenter SYSTEM "file:../xml/xmlimport.dtd">
<datacenter>
<software-module
name="SWU IBM DB2 Client 8.2"
version="8.2"
vendor="IBM"
title="IBM DB2 Client 8.2"
description="DB2 Client"
142
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
is-draft="false">
<software-capability name="database.family" value="DB2 Client"
/>
<software-capability name="database.version" value="8.2" />
<supported-requirement-type value="DATABASE" />
<installable-package
name="SWU IBM DB2 Client 8.2 Simulated Installable"
is-device-model="SoftwareSimulator_SoftwareInstallable"
locale="en_US"
version="8.2"
priority="0"
file-repository="SWU_FileRepository"
status="tested">
<file name="-1" path="/" />
<software-requirement
name="os.family"
type="OS"
enforcement="MANDATORY"
hosting="true"
accept-non-existing="false">
<software-requirement-value value="Windows 2000
Server SP4" />
</software-requirement>
</installable-package>
<software-resource-template
name="SWU IBM DB2 Client Installation"
software-resource-type="INSTALLATION"
software-resource-device-model="SoftwareSimulator_SoftwareInstallati
on"
multiplicity-type="Unspecified"
software-configuration-type="Regular"
is-selected="true">
<template-param name="InstallDir" value="C:/ibm/sqllib"
is-changeable="true" />
</software-resource-template>
</software-module>
</datacenter>
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
143
8. Save the file as mydb2client.xml.
9. Issue the following command to import the newly created definitions:
Cd %TIO_HOME%\tools\
Xmlimport file:mydb2client.xml
10.Verify the import using the Find field in the TIO/TPM user interface to search
for objects with names starting with SWU IBM DB2.
8.6 Creating a software stack
To create a software stack for controlling the installation and the configuration of
the software components on servers that will be provisioned into the application
layer of the composite application, follow the procedure outlined in 8.2.3,
“Exercise: Creating a software stack” on page 132, and replace the SWU IBM
DB2 Server 8.2 software product with the SWU IBM WebSphere Application
Server 5.1 and name the software stack SWU_WAS_Server_Stack. In addition, add
the SWU IBM DB2 Client 8.2 software definition as the last entry in the stack.
At the end of the software stack creation procedure, the
SWU_WAS_Server_Stack must be similar to that shown in Figure 8-24.
Figure 8-24 The SWU WebSphere Application Server software stack
144
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
This completes the creation of software objects for the infrastructure support of
the application layer for the execution of business transactions. Proceed to 8.7,
“Creating the SWU_HTTP_Server_Stack” to learn how to define the
infrastructure components to support the hosting of static Web pages.
8.7 Creating the SWU_HTTP_Server_Stack
To define the DCM objects required to create the software stack that provides
support to the Web layers of the composite applications, define the following
objects:
򐂰 SWU IBM Hypertext Transfer Protocol (HTTP) Server V2.0 for Windows
Installable
򐂰 SWU IBM HTTP Server V2.0
򐂰 SWU_HTTP_Server_Stack
Figure 8-25 SWU_HTTP_Server_Stack software components
The tasks you must perform to accomplish this are outlined in 8.7.2, “Exercise:
Defining the SWU_HTTP_Server_Stack” on page 146. However, to define these
objects automatically, you can use the procedure outlined in 8.7.1, “Shortcut:
Creating the SWU_HTTP_Server_Stack”.
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
145
8.7.1 Shortcut: Creating the SWU_HTTP_Server_Stack
An XML file for the automated creation of the SWU_HTTP_Server_Stack and the
related software objects is loaded into the Tivoli Intelligent Orchestrator system
on installation of the SWU_2006 tcdriver. Perform the following tasks:
1. Before importing the software definitions, ensure that the
SWU_IBMHttp_20_Win tcdriver is installed. To install this, issue the following
commands from the TIOServer system command line:
cd %TIO_HOME%\..\SWrepository\SWU\xml
%TIO_HOME%\tools\tc-driver-manager fid SWU_IBMHttp_20_Win
2. To import these definitions into your DCM, perform one of the following tasks:
– Execute the SWU_ImportXML workflow by providing a value for the
xmlFile parameter of softwarestackHTTP, either by invoking the workflow
from the user interface or by issuing the following command from the Tivoli
Intelligent Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=softwarestackHTTP
– Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFile= softwarestackHTTP"
When the workflow execution is complete, continue to 8.8, “Installing the
prerequisite software on the host platform server” on page 149.
8.7.2 Exercise: Defining the SWU_HTTP_Server_Stack
The process involved in creating the SWU_HTTP_Server_Stack is logically
similar to the ones used to create the other two infrastructure stacks. However,
because the HTTP software definitions used in these exercises are based on
real working code, there is not enough time to define all the required software
resource templates and parameters. Instead of creating the software definitions
manually, use the procedure described in 8.7.1, “Shortcut: Creating the
SWU_HTTP_Server_Stack” to create the SWU_HTTP_Server_Stack and the
related objects.
The installation of the SWU_IBMHttp_20_Win.tcdriver adds the following
modifications to your system:
򐂰 Loading the HTTP installation archive (HTTPServer_win_2047.zip) into the
relative directory images\ibm\ihs\2047\win in the SWU_FileRepository root
path (C:\SWUrepository)
򐂰 Loading the composite application server pages into the SWU_FileRepository
146
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
򐂰 Importing and defining a number of workflows and device drives in the device
driver category named SWU. To view these, navigate to Configuration →
Device Drivers → SWU.
The import of the XML file named softwarestackHTTP.xml is responsible for
creating the following objects in the DCM:
򐂰 Software package: SWU IBM HTTP Server V2.0 for Windows Installable
򐂰 Software package: SWU IBM HTTP Server V2.0 Simulated Installable
򐂰 Software product: SWU IBM HTTP Server V2.0 and the related software
configuration templates
If you take a close look at the configuration templates defined for the SWU IBM
HTTP Server V2.0 software product, you will notice that there are a number of
them to select from (Figure 8-26).
Figure 8-26 SWU IBM HTTP Server V2.0 configuration templates
The intended use of these templates are as described in Table 8-4.
Table 8-4 HTTP Server configuration templates and their intended use
Software resource template name
Intended use
defaults
Helper template to set up defaults
response-file
Helper template to create a response file for the
HTTP Server installation
HTTP Server Installation without
default instance
Template for installation without instances to
support raw installation or installation on the
hosting platform
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
147
Software resource template name
Intended use
SWU HTTP Installation with...
Templates for installation of HTTP with active
Apache instances pointing to specific sets of
home pages. These templates will be used
from the software definition of the SWU
Composite Web Module.
ClusterResource...
Templates used to control the configuration of
the cluster domain for the HTTP servers
If you expand the Configuration Template named HTTP Server Installation with
no default instance, you see a number of parameter values with a value of "{1}",
as shown in Figure 8-27.
Figure 8-27 Using external references in a software resource template
During installation, these values are replaced with the values from the
parameters of the Defaults Configuration Template.
Also note that there are no nested configuration templates of the type
INSTANCE. This indicates that no instances will be created - which is exactly the
way you want it with regard to the "raw" HTTP Server installation.
This completes the creation of the software objects for the application
infrastructure environments. In the next exercise described in 8.8, “Installing the
prerequisite software on the host platform server”, use these software objects to
make sure that the host platform server has the basic components installed, so
that they are available for reuse by the virtual servers.
148
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
8.8 Installing the prerequisite software on the host
platform server
For the virtual servers to reuse the software components that reside on the host
platform server, ensure that the SWU Java Runtime Environment V1.4.1 and the
SWU IBM HTTP Server V2.0 software products are installed on the
SWU_HostPlatformServer.
In the SWU tutorial environment, the two components are already installed on
the TIOServer system, which incidentally, also owns the IP address defined for
the SWU_HostPlatformServer. This means that the components are already in
place. However, your DCM is not aware of this, partly because you have not
associated the software definitions with the proper software identifiers, and partly
because no scanning has been performed against the
SWU_HostPlatformServer.
Therefore, you must install or register the software with the
SWU_HostPlatformServer. The workflows provided to perform the installation
discover the existing installations. Thus, there is no harm to the system in case
you want to reinstall instead of merely registering.
8.8.1 Shortcut: Installing the software on the
SWU_HostPlatformServer
A workflow for the automated creation of the infrastructure software stacks and
the related software objects is loaded into the Tivoli Intelligent Orchestrator
system on installation of the SWU_2006 tcdriver.
Register the software objects for the infrastructure environments with the
SWU_HostPlatformServer by starting the SWU_HostPlatformServer_InstallSW
workflow in one of the following ways:
򐂰 Execute the SWU_HostPlatformServer_InstallSW workflow, either by
invoking the workflow from the Tivoli Intelligent Orchestrator user interface or
by issuing the following command from the Tivoli Intelligent Orchestrator user
command line:
MessageTranslatorService createDeploymentRequest 0
SWU_HostPlatformServer_InstallSW ServerName=SWU_HostPlatformServer
򐂰 Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd
SWU_HostPlatformServer_InstallSW "ServerName=SWU_HostPlatformServer
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
149
When the workflow execution is complete, continue to 8.9, “Verifying the
infrastructure software definitions” on page 158.
8.8.2 Exercise: Installing the SWU IBM Java Runtime Environment
and registering the SWU IBM Hypertext Transfer Protocol Server
Software products may be installed or just registered in the DCM. The facility to
register a software resource is particularly useful when dealing with the
preloaded systems, where you only update the DCM without performing an
installation. Normally, the registration is handled by the discovery facilities.
In this exercise, you install the SWU IBM JRE V1.4.1 Windows and register the
SWU IBM HTTP Server V2.0 software products on the
SWU_HostPlatformServer. Because the JRE is a prerequisite for the installation
of the HTTP, start with the SWU IBM JRE V1.4.1 Windows software product.
Before starting the installation, go to the Software page of the
SWU_HostPlatformServer and verify whether the only product installed is the
SWU Windows 2000 Server SP4 operating system, as shown in Figure 8-28.
Figure 8-28 SWU_HostPlatformServer software inventory
150
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
To install the SWU IBM JRE V1.4.1 Windows software product on the
SWU_HostPlatformServer, perform the following tasks:
1. Navigate to Tasks → Software Provisioning → Install Software. You are
guided through the Software Installation Wizard. In the Welcome panel, select
Next, as shown in Figure 8-29.
Figure 8-29 Initializing a software installation
2. In the Select Software window, limit the scope of the software products
displayed by entering SWU IBM against the Software Name field, and click
Search. Then, select the SWU IBM Java Runtime Environment 1.4.1
Windows software product, and click Next (Figure 8-30).
Figure 8-30 Software installation: Select Software
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
151
3. Select the Configuration Template named SWU IBM Java Runtime
Environment Windows Installation, and click Next (Figure 8-31).
Figure 8-31 Software installation: Select Configuration Template
4. Because there is no necessity to modify the default template parameters,
click Next (Figure 8-32).
Figure 8-32 Software installation: Customize Template
152
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
5. In the Select Targets window, limit the scope of the targets displayed by
entering SWU_ against the Search Name field, and click Search. Select
SWU_HostPlatformServer and click Next (Figure 8-33).
Figure 8-33 Software installation: Select Targets
6. You can schedule the installation to take place at a certain time. However, in
the SWU environment, you must install the software product immediately.
Therefore, click Next (Figure 8-34).
Figure 8-34 Software installation: Schedule
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
153
7. Finally, you are presented with the installation summary. Review the settings
and click Finish to submit the installation request (Figure 8-35).
Figure 8-35 Software installation: Summary
8. You are now routed to the Manage Tasks window, where you can follow the
start of the Install Software task. Use the Refresh icon in the top right corner
to update the information in the window, until the tasks are completed
successfully (Figure 8-36).
Figure 8-36 Software installation: Task Status
154
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
9. Go back to the Software page of the SWU_HostPlatformServer and verify
whether the software product is installed (Figure 8-37).
Figure 8-37 Software installation: Verification
This completes the installation of the SWU Java Runtime Environment 1.4.1
Windows on the SWU_HostPlatformServer.
Use the registration-only method to inform the Tivoli Intelligent Orchestrator
System that the HTTP Server is installed on the SWU_HostPlatformServer.
Important: In the SWU environment, the HTTP Server V2.0 is preinstalled on
the TIOServer system, which is the physical host of the IP address used by
the SWU_HostPlatformServer. Because of this, the registration allows you to
successfully operate the HTTP Server because the executables are present.
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
155
To register the SWU IBM HTTP Server V2.0 so that it will be installed in the
SWU_HostPlatformServer, perform the following tasks:
1. Go to the Software page of the SWU_HostPlatformServer and use the Edit →
Add Software Installation menu option to specify the necessary information
for the software installation to register. For the SWU IBM HTTP Server V2.0 in
the SWU environment, provide the necessary information, as shown in
Figure 8-38, and click Save.
Figure 8-38 Registering the software installation
156
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
2. If you expand all the software products in the Software page for the
SWU_HostPlatformServer, a window similar to that shown in Figure 8-39
must be visible.
Figure 8-39 Software inventory
This completes the registration of the SWU IBM HTTP Server V2.0 software
installation.
Register the WebSphere and DB2 Server software products by performing the
following optional tasks (alternately, you can proceed to 8.9, “Verifying the
infrastructure software definitions”):
򐂰 (Optional step) Use the procedure outlined on page 155 to register a
software installation based on the SWU IBM WebSphere Application Server
V5.1 software product and the Default WebSphere Application Server
Installation Configuration Template.
򐂰 (Optional step) Use the procedure outlined on page 155 to register a
software installation based on the SWU DB2 Server V8.2 software product
and the Default Template software configuration template.
This completes the process involved in installing the prerequisite software on the
SWU_HostPlatformServer. Proceed to 8.9, “Verifying the infrastructure software
definitions”.
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
157
8.9 Verifying the infrastructure software definitions
If the steps described earlier are completed successfully, the infrastructure
software components you defined are now registered with the
SWU_HostPlatformServer. By looking at the Software page for this server, you
can verify whether the definitions are consistent. To view the details of the
SWU_HostPlatformServer, perform the following tasks:
1. Enter the string SWU_HostP in the Find field at the top of the navigation pane,
and click SWU_HostPlatformServer.
2. When the General page appears, click the Software tab, and expand the
sections for each software definition that is registered. The information you
see must be similar to that shown in Figure 8-40.
Figure 8-40 SWU_HostPlatformServer infrastructure software inventory
158
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
3. Click the HTTP Server installation name IBM HTTP Server HostPlatform
Installation, and expand the Configuration Template. This reveals the fact
that the Software Configuration Template created when defining the software
module is cloned (note that the name of the software resource template has
an object appended) and that the values for the parameters in the resource
template have been resolved (Figure 8-41).
Figure 8-41 Virtual servers’ hardware inventory
This completes the tasks involved in defining and verifying the infrastructure
software components required to support composite application provisioning.
Proceed to “Exercise 9: Defining the composite application software” on
page 161.
Chapter 8. Exercise 8: Defining the composite application infrastructure environment
159
160
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
9
Chapter 9.
Exercise 9: Defining the
composite application
software
The starting point for this exercise is the IBM Software University (SWU) data
center model (DCM), with the objects defined representing the components
shown in the frame labeled A in Figure 9-1.
© Copyright IBM Corp. 2006. All rights reserved.
161
9.1 The objective of this exercise
In this exercise, you define the software objects that represent your composite
application modules, that is, static Web pages, servlets and Enterprise
JavaBeans™ (EJBs), and database structures and data. These definitions are
required for you to define software stacks that include your composite application
modules, and assign these to server templates, which will in turn, be used to
control the installation and configuration of the servers in the three different
application tiers.
The objects that are created in this exercise are shown in the frame labeled B in
Figure 9-1.
Figure 9-1 Composite application components: Starting and ending environments
162
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
Figure 9-1 shows that the objects that will be created in the DCM in this exercise
are those that are required to prepare the custom software components to be
used in the provisioning of the composite application. Define the software stacks
and the underlying software definitions and software packages that are to be
used for the provisioning of servers to each layer of your composite application.
As shown in Figure 9-2, create a unique software stack for each layer of the
composite application. Each of these is made up of the appropriate infrastructure
stack plus one or more application-specific modules. Because you have already
prepared the infrastructure stacks, the stacks for the application modules for
each layer must be based on the appropriate infrastructure stack and must
include only the components required to provide the application behavior for the
specific layers.
In this exercise, you focus on the components shown in the frame labeled B in
Figure 9-2.
Figure 9-2 Composite application software components
In the SWU tutorial environment, no application-specific modules are provided
for the database and the application layers. Therefore, the object definitions in
the DCM are based on the software simulator. For the Web layer, a set of server
pages are provided. These are eventually provisioned to the virtual servers
provisioned to the SWU Composite Web Tier.
Chapter 9. Exercise 9: Defining the composite application software
163
Following is a list of the tasks to be completed in this exercise:
1.
2.
3.
4.
Creating the SWU_Composite_Database_Stack
Creating the SWU_Composite_Application_Stack
Creating the SWU_Composite_Web_Stack
Verifying the infrastructure software definitions
In the following sections, three different methods of defining the software
definitions and software packages are described, that is, using a wizard, creating
the objects manually, and installing a tcdriver that includes the Extensible
Markup Language (XML) to create the objects.
If you are comfortable defining software components using the Tivoli Intelligent
Orchestrator user interface, use the shortcut described in 9.1.1, “Shortcut:
Creating all the composite application software objects” to complete all the tasks
in this exercise, and continue with “Exercise 9: Defining the composite
application software” on page 161.
9.1.1 Shortcut: Creating all the composite application software
objects
An XML file for the automated creation of the infrastructure software stacks and
the related software objects is loaded into the Tivoli Intelligent Orchestrator
system on installation of the SWU_2006 tcdriver.
To create the software objects for the infrastructure environments, issue the
following commands from the TIOServer system command line:
cd %TIO_HOME%\..\SWrepository\SWU\xml
%TIO_HOME%\tools\xmlimport file:SWU_COMPOSITE.xml
When the workflow execution is complete, continue to 9.9, “Verifying the
infrastructure software definitions” on page 187.
164
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
9.2 Creating the SWU_Composite_Database_Stack
To define the DCM objects required to create a software stack to support the
composite application database layer, define the following objects:
򐂰 Software package: SWU Composite Database Installable
򐂰 Software product: SWU Composite Database Module
򐂰 Software stack: SWU_Composite_Database_Stack
Figure 9-3 SWU_Composite_Database_Stack logical structure
This stack is defined to assign it to a template that governs the resource
allocation and configuration of the servers in the application tier that supports the
database layer.
The tasks you must complete to create these objects manually are described in
9.2.2, “Exercise: Creating the SWU Composite Database Module software
definition” on page 166. However, to define the objects automatically, you can
use the procedure described in 9.2.1, “Shortcut: Creating the composite
application database layer software definitions” on page 166, which is the
recommended method for this tutorial exercise because of the amount of time it
saves.
Chapter 9. Exercise 9: Defining the composite application software
165
9.2.1 Shortcut: Creating the composite application database layer
software definitions
An XML file for the automated creation of the SWU_Composite_Database_Stack
and related software objects is loaded into the Tivoli Intelligent Orchestrator
system on installation of the SWU_2006 tcdriver.
To import these definitions into your DCM, perform one of the following tasks:
򐂰 Execute the SWU_ImportXML workflow by providing a value for the xmlFile
parameter of softwarestackdatabase, either by invoking the workflow from the
user interface or by issuing the following command from the Tivoli Intelligent
Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=softwarestackdatabase
򐂰 Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFile= softwarestackdatabase"
When the workflow execution is complete, continue to 9.4, “Reviewing the
SWU_Composite_Application_Stack” on page 173.
9.2.2 Exercise: Creating the SWU Composite Database Module
software definition
To define the SWU Composite Database Module and the related SWU
Composite Database Installable, use the procedures described in 8.2, “Creating
the SWU_DB2_Server_Stack” on page 123 or 8.3, “Creating the
SWU_WAS_Server_Stack” on page 134, using the information provided in
Table 9-1, Table 9-2, and Table 9-3.
However, due to time constraints, it is recommended that you use the shortcut
method outlined in 9.2.1, “Shortcut: Creating the composite application database
166
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
layer software definitions” on page 166, and review the automatically created
definitions.
Table 9-1 SWU Composite Database Module software product definition
Object
Attribute
Value
Software
Definition
name
SWU Composite Database Module
version
1.0
vendor
SWU
title
SWU Composite Database
description
Module for composite application database layer
is-draft
False
software-capability
software-capability
Subattribute
Value
name
software.name
value
Composite
Database
name
software.version
value
1.0
Chapter 9. Exercise 9: Defining the composite application software
167
Object
Attribute
Value
software-capability
supported-requirement-type
Subattribute
Value
name
software.vendor
value
SWU
name
database.version
type
DATABASE
enforcement
MANDATORY
Hosting
true
Accept-non-existing
false
value
8.2
name
database.family
type
DATABASE
enforcement
MANDATORY
Hosting
true
Accept-non-existing
false
value
DB2
APPLICATION
software-requirement
software-requirement
Table 9-2 SWU Composite Database software package definition
Object
Attribute
Value
Subattribute
Software
package
name
SWU Composite Database Installable
is-device-mod
el
SoftwareSimulator_SoftwareInstallable"
locale
en_US
version
1.0
priority
0
file-repository
SWU_FileRepository
status
tested
Value
file name
168
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
Object
Attribute
Value
path
/
software-requirement
Subattribute
Value
name
os.family
type
OS
enforcement
MANDATORY
hosting
true
accept-non-existing
false
value
Windows 2000 Server SP4"
Table 9-3 SWU Composite Database software resource template definition
Software Resource
Template INSTALLATION
INSTANCE
Attribute
Value
Subattribute
Value
name
SWU Composite Database Installation
software-resource-type
INSTALLATION
software-resource-device-model
SoftwareSimulator_SoftwareInstallation
multiplicity-type
Unspecified
software-configuration-type
Regular
is-selected
true
template-param
name
InstallDir
value
"C:/ibm/sqllib"
is-changeabl
e
true
name
Database Instance
software-resource-type
INSTANCE
software-resource-device-model
SoftwareSimulator_SoftwareI
nstance
multiplicity-type
Unspecified
software-configuration-type
Regular
Chapter 9. Exercise 9: Defining the composite application software
169
Attribute
CONFIGURATION
170
Subattribute
Value
is-selected
true
template-param
name
resource-na
me
value
SWU
Composite
DB Module
Database
Instance
is-changeabl
e
true
name
Database
Definition
software-resource-type
CONFIGURA
TION
software-resource-device-model
SoftwareSim
ulator_Softwa
reResource
multiplicity-type
Unspecified
software-configuration-type
Regular
is-selected
true
template-param
APPLICATION_D
ATA
Value
name
name
resource-name
value
SWU Composite DB Module
Database Definition
is-changeabl
e
true
Database
Data
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
Attribute
Value
Subattribute
software-resource-type
APPLICATIO
N-DATA
software-resource-device-model
SoftwareSim
ulator_Softwa
reResource
multiplicity-type
Unspecified
software-configuration-type
Regular
is-selected
true
template-param
Value
name
resource-name
value
SWU Composite DB Module
Database Data
is-changeabl
e
true
After you have defined the SWU Composite Database Module and SWU
Composite Database Installable, you are ready to build the
SWU_Composite_Database_Stack, which becomes the basis for provisioning
the database-related components of the composite application.
9.3 Exercise: Creating the software stack
Creating the SWU_Composite_Database_Stack involves the same procedure
that is described in 9.3, “Exercise: Creating the software stack” on page 171, with
the following substitutions:
򐂰 The name of the software stack must be SWU_Composite_Database_Stack
򐂰 SWU_Pristine_Server_Stack must be replaced by SWU_DB2_Server_Stack
򐂰 SWU IBM DB2 Server 8.2 must be replaced by SWU Composite Database
Module
Chapter 9. Exercise 9: Defining the composite application software
171
After it is defined, the SWU_Composite_Database_Stack must look similar to
that shown in Figure 9-4.
Figure 9-4 SWU_Composite_Database_Stack properties
172
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
9.4 Reviewing the SWU_Composite_Application_Stack
To look at the definitions that have been created, open the SWU Composite
Database Installation Software Resource Template associated with the
SWU_Composite_Database_Stack, and expand it. A structure of nested
resource templates similar to that shown in Figure 9-5 must be visible.
Figure 9-5 SWU_Composite_Application_Stack structure
Note that the top-level Software Resource Template is of the type
INSTALLATION. This implies that when this software stack is installed, a software
installation object representing the SWU Composite Database Module will be
created on the target server, and the workflows that implement the methods
defined for the software installation object type will be found in the
SoftwareSimulator_SoftwareInstallation device driver.
Chapter 9. Exercise 9: Defining the composite application software
173
Because the Installation Software Resource Template contains nested resource
templates, the objects representing each one of them will also be created on the
target server after the SWU_Composite_Database Stack is installed. As implied
earlier, a hierarchy of INSTALLATION, INSTANCE, CONFIGURATION, and
APPLICATION-DATA objects will be created on the target servers, as shown in
Figure 9-6.
Figure 9-6 SWU Composite Database Installation SRT
This completes the creation of the SWU_Composite_Database_Stack and the
related software objects. You can proceed to work on the creation of the stack for
the application layer by performing the tasks outlined in 9.5, “Creating the
SWU_Composite_Application_Stack”.
174
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
9.5 Creating the SWU_Composite_Application_Stack
To define the DCM objects required to create the software stack to support the
application layer of the composite application, define the following objects
(Figure 9-7):
򐂰 Software package: SWU Composite Application Installable
򐂰 Software product: SWU Composite Application Module
򐂰 Software stack: SWU_Composite_Application_Stack
Figure 9-7 SWU_Composite_Application_Stack logical layout
This stack is defined for assigning it to a template that governs the resource
allocation and configuration of the servers in the application tier that supports the
application layer.
The tasks that are to be performed to accomplish this manually are described in
9.5.2, “Exercise: Manually defining the application layer software objects” on
page 176. However, to define these objects automatically, use the procedure
described in 9.5.1, “Shortcut: Creating the composite application layer software
definitions”, which is the recommended method for this tutorial exercise because
of the time it saves.
Chapter 9. Exercise 9: Defining the composite application software
175
9.5.1 Shortcut: Creating the composite application layer
software definitions
An XML file for the automated creation of the
SWU_Composite_Application_Stack and the related software objects is loaded
into the Tivoli Intelligent Orchestrator system on installation of the SWU_2006
tcdriver.
To import these definitions into your DCM, perform one of the following tasks:
򐂰 Execute the SWU_ImportXML workflow by providing a value for the xmlFile
parameter of softwarestackapplication, either by invoking the workflow from
the user interface or by issuing the following command from the Tivoli
Intelligent Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=softwarestackapplication
򐂰 Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFile= softwarestackapplication"
When the workflow execution is complete, continue to 9.6, “Reviewing the
SWU_Composite_Application_Stack”.
9.5.2 Exercise: Manually defining the application layer software
objects
To define the SWU Composite Application Module and the related SWU
Composite Application Installable, use the procedures described in 8.2, “Creating
the SWU_DB2_Server_Stack” on page 123 or 8.3, “Creating the
SWU_WAS_Server_Stack” on page 134 using the information from the
softwarestackapplication.xml located in the
%TIO_HOME%\..\SWrepository\SWU\xml directory on the TIOServer system.
However, due to time constraints, it is recommended that you use the shortcut
method described in 9.5.1, “Shortcut: Creating the composite application layer
software definitions” on page 176, and review the definitions that are created
automatically.
176
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
9.6 Reviewing the SWU_Composite_Application_Stack
To review the definitions in your DCM, navigate to Inventory → Software
Catalog → Definitions → Software Products. Find the software product
named SWU Composite Application Module, and take a look at the configuration
template. Note the hierarchy of templates and their types.
As with the composite application module for the database layer, the module for
the application layer includes a software resource template that is responsible for
the creation and configuration of software resources on the target server when
the module is installed.
Figure 9-8 The SWU_Composite_Application_Stack
A brief look at the resource template for the SWU Composite Application Module
reveals that a hierarchy of software resources, which is similar to that shown in
Figure 9-8, is built when the SWU Composite Application Module is installed. As
with the database Instance-database-data hierarchy, the application server
hierarchy creates an application server, enterprise archives (EARs), servlets,
and Java Database Connectivity (JDBC™) definitions.
Note that the details of the actual implementation and the use of the parameters
provided in the software resource templates are managed within the workflows
that implement the logical operations for the software module and its related
objects.
This completes the creation of the SWU_Composite_Application_Stack and the
related software objects. Proceed to creating the stack for the Web layer, as
described in 9.7, “Creating the SWU_Composite_Web_Stack”.
Chapter 9. Exercise 9: Defining the composite application software
177
9.7 Creating the SWU_Composite_Web_Stack
The last stack to define is the stack for the Web layer of the composite
application. In the SWU tutorial environment, this is more complex than the
previous one because in this case, the simulated software products are not used.
A working implementation of the IBM Hypertext Transfer Protocol (HTTP) Server
V2.0 is used, which in turn creates instances, configurations, and application
data on the virtual servers hosted by the TIOServer system.
This stack is defined for assigning it to a template that governs the resource
allocation and configuration of the servers in the application tier that supports the
Web layer (Figure 9-9).
Figure 9-9 SWU_Composite_Web_Stack logical layout
To define the software objects that are required to create a software stack to
support the composite application Web layer, define the following:
򐂰 Software package: SWU Composite Web Module Server Configuration
Installable
򐂰 Software package: SWU Composite Web Module Server Pages Installable
178
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
򐂰 Software product: SWU Composite Web Module
򐂰 Software stack: SWU_Composite_Web_Stack
As with the other composite application stacks, the tasks that must be performed
to accomplish this manually are described in 9.7.2, “Exercise: Manually defining
the composite application Web layer software objects”. However, to define these
objects automatically, use the procedure outlined in 9.7.1, “Shortcut: Creating the
composite application Web layer software definitions”, which is the
recommended method for this tutorial exercise because of the time it saves.
9.7.1 Shortcut: Creating the composite application Web layer
software definitions
An XML file for the automated creation of the SWU_Composite_Web_Stack and
the related software objects is loaded into the Tivoli Intelligent Orchestrator
system on installation of the SWU_2006 tcdriver.
To import these definitions into your DCM, perform one of the following tasks:
򐂰 Execute the SWU_ImportXML workflow by providing a value for the xmlFile
parameter of softwarestackweb, either by invoking the workflow from the user
interface or by issuing the following command from the Tivoli Intelligent
Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=softwarestackweb
򐂰 Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFile= softwarestackweb"
When the workflow execution is complete, continue to 9.8, “Reviewing the
SWU_Composite_Web_Stack” on page 180.
9.7.2 Exercise: Manually defining the composite application Web
layer software objects
To define the SWU Composite Web Module and the related SWU Composite
Web Installable, use the procedures described in 8.2, “Creating the
SWU_DB2_Server_Stack” on page 123 or 8.3, “Creating the
SWU_WAS_Server_Stack” on page 134, using the information from the
softwarestackweb.xml located in the %TIO_HOME%\..\SWrepository\SWU\xml
directory on the TIOServer system.
Chapter 9. Exercise 9: Defining the composite application software
179
However, due to time constraints, it is recommended that you use the shortcut
method described in 9.5.1, “Shortcut: Creating the composite application layer
software definitions” on page 176, and review the definitions that are created
automatically.
9.8 Reviewing the SWU_Composite_Web_Stack
To better understand the actions performed by the Tivoli Intelligent Orchestrator
during software provisioning, review the following four objects that were created
earlier:
򐂰 Software product: SWU Composite Web Module
򐂰 Software package: SWU Composite Web Module Server Configuration
Installable
򐂰 Software package: SWU Composite Web Module Server Pages Installable
򐂰 Software stack: SWU_Composite_Web_Stack
9.8.1 The software product: SWU Composite Web Module
To take a closer look at the software product definition for the SWU Composite
Web Module, perform the following tasks:
1. Use either the Find field in the navigation pane of the Tivoli Intelligent
Orchestrator user interface or navigate to Inventory → Software Catalog →
Definitions → Software Products. Then find the software product named
SWU Composite Web Module and open it to view the details.
180
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
2. Start by looking at the General page, and expanding the Requirements and
Capabilities section of the SWU Composite Web Module (Figure 9-10).
Figure 9-10 SWU Composite Web Module requirements and capabilities
When you look at the top of the page where the requirements are defined,
you can see that this software product can only be installed on servers that
are already hosting the WEBSERVER component, and more specifically, a
Web server component that is identified by the specific attributes shown in
Figure 9-10. Incidentally, these attributes are supported by the SWU IBM
HTTP Server V2.0 software product defined in 8.7, “Creating the
SWU_HTTP_Server_Stack” on page 145 and is embedded into the
SWU_HTTP_Server_Stack. In addition, the SWU_HTTP_Server_Stack is
included in the SWU_Composite_Web_Stack to ensure that the prerequisite
components are installed, and that the software compliance is reported
correctly.
Also note that a set of APPLICATION capabilities are defined for this software
product. Although these are not used at this point, they are defined for future
use.
3. Expand the Configuration Template section to see how the resource
templates are being used to control the installation and configuration of the
software components. A closer look at the Configuration Template named
Chapter 9. Exercise 9: Defining the composite application software
181
SWU HTTP Installation with PlantsByWebSphere Instance reveals a
structure similar to the one shown in Figure 9-11.
Figure 9-11 SWU HTTP Installation with PlantsByWebSphere Instance configuration
template
You see that the configuration template of the type INSTALLATION includes
a number of nested child templates that are used to control the creation of
Instances, Application Data, and Configurations.
In the SWU environment, these child templates are used to ensure that the
static pages used for the composite application are loaded on the servers
when the SWU IBM HTTP Server V2.0 software product is installed. The
installation itself is handled through the software package, and is controlled
by the workflows assigned to the SoftwareInstallable.Install LDO through the
device driver association of each of the software packages.
182
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
Controlling the behavior of the objects that are created during the installation
is through the assignment of device models. As shown in Figure 9-11, the
assignment for the specific types are:
– INSTALLATION: SWU_IBMHttp_20_Win_SoftwareInstallationDM
– INSTANCE: SWU_IBMHttp_20_Win_SoftwareInstanceDM
– Application Data: SoftwareSimulator_SoftwareResource
Because stopping and starting an Apache instance is different from
performing the same operation on a WebSphere Application Server instance,
the device model associations are customized for each software product in
order for them to be tailored for specific components. This allows you to
provide the desired functionality for each component.
4. When you look at the top of the General page, you see that two software
packages are defined for this software product (Figure 9-12). Contrary to
normal situations where each software package operates in a
platform-specific manner (hardware, operating system, infrastructure, or
hosting environment), in this instance, both the packages are being used as
part of the provisioning. One controls the creation and configuration of the
Apache instance that hosts the server pages, and the other controls the
pages themselves. This facilitates the reuse of the configuration to support
multiple server page configurations, all of them controlled through the
software resource templates.
Figure 9-12 SWU Composite Web server installables
5. Finally, go to the Workflows page and ensure that no workflows or device
drivers are assigned. This is the normal situation for software products. The
installation specifics are handled through the device driver associations at the
software package level.
Chapter 9. Exercise 9: Defining the composite application software
183
9.8.2 The software package: SWU Composite Web Module Server
Configuration Installable
When you look at the details of the SWU Composite Web Module Server
Configuration Installable (Figure 9-13), note the following:
򐂰 A software package is, in essence, a way of defining a link to a file in a
repository and assigning special processing and prerequisite checking. In this
case, the software package points to a file named SWU_HTTP.conf that
resides in the /SWU/http/conf directory relative to the root directory in the
SWU_FileRepository.
Figure 9-13 SWU Composite Web Module Server Configuration
Installable properties
When you install the SWU_2006.tcdriver at the start of this tutorial, the
c:\SWURepository (the root directory of the SWU_FileRepository) directory is
created. During the installation of the SWU_IBMHttp_20_Win.tcdriver, the
files for the Apache instance configuration and the files for the server pages
are placed in specific locations in this directory.
򐂰 By looking at the details of this software package, you can see that this
package will only be installed on servers that honor the requirements of an
operating system of the Windows 2000 Server SP4 family. Coincidently, this is
the same as the capabilities of the SWU Windows 2000 Server SP4 software
package that is installed on all the virtual servers during creation.
򐂰 In addition, you see that a special device driver is assigned (Figure 9-14).
This contains links to custom-made workflows that are capable of
manipulating the resources referenced by the software package (the file in the
repository) according to our expectations, using the information from the
software resource templates defined for the software product. In this case, the
device driver name is SWU_IBMHttp_20_Win_SoftwareInstallableDM. When
184
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
you open the Workflows page, you see which workflows are assigned to
which logical device operations.
Figure 9-14 SWU Composite Web Module Server Configuration Installable device
driver
Note that the only two operations for a software package are Distribute and
Install. After the installation takes place and the installation object is created
on the target server, and the workflows contained in the device driver for the
software installation object (determined by the assignment in the software
resource template of type INSTALLATION) is invoked to accomplish the tasks
relating to the installation object, such as Uninstall, Add Instance, and Update
DCM (get status). The same is true for instances where the device driver is
specified in the software resource template of the type INSTANCE, and
among the Supported by the Instance Object Type are Start and Stop that are
used to control the operation of Instance.
9.8.3 The software package: SWU Composite Web Module Server
Pages Installable
The other software package associated with the SWU Composite Web Module
software product is similar to the first one. The only difference is that it references
another set of files from the SWU_FileRepository. In this case, it is a compressed
version of the server pages for the SWU Composite Application.
In this instance, we use the same device driver for both the packages, ensuring
that no matter which one is picked by the Tivoli Intelligent Orchestrator for
installation - and we know that it will be the SWU Composite Web Module Server
Configuration Installable because it has the lowest priority, and the requirements
for both the packages are identical - the same set of workflows are used to
implement the functions invoked during installation.
Chapter 9. Exercise 9: Defining the composite application software
185
9.8.4 The SWU_Composite_Web_Stack
You may wonder why a software stack is being used. Why cannot the software
products be installed one-by-one? However, to explore the capabilities of the
server templates that may be linked to a resource pool or an application tier in
order to provide a template for the configuration of servers within that group, the
stack is required. The only way to define a set of software products that must be
installed on a server in a particular group (pool or tier) is by using a stack.
Another reason for using a software stack is because, when software products
are associated with a stack, you determine which installation software resource
template to use in case there are many to choose from. The software resource
template is cloned in the stack, and will not be affected by future configuration
changes to the underlying software product. Therefore, to freeze a particular
configuration, we use the stack. Even if the software product gets associated
with another stack later and the software resource templates change, the cloned
copy in the software stack does not change.
The same is true when installation takes place. If you perform the installation
manually, you can change the parameters in the software resource template.
Because of this, another clone is created in the software installation object. The
parent of the installation clone is the software module (stack or product) that is
used as the source for the installation.
This completes the process involved in creating the
SWU_Composite_Web_Stack and the related software objects. Proceed to 9.9,
“Verifying the infrastructure software definitions”.
186
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
9.9 Verifying the infrastructure software definitions
If you have successfully completed the tasks described until now, you can
successfully install the newly defined composite application modules on the
SWU_HostPlatformServer.
9.10 Exercise: Installing the SWU composite software
products
To verify whether the objects you have just created will actually perform as
intended, try to install the software products on the SWU_HostPlatformServer in
the following sequence:
1. SWU Composite Database Module
2. SWU Composite Application Module
3. SWU Composite Web Module (use the SWU HTTP TPM Instance
Configuration Template)
Because you installed the basic infrastructure packages on the
SWU_HostPlatformServer as part of 8.8, “Installing the prerequisite software on
the host platform server” on page 149, you can rely on the fact that all the
prerequisites for the composite modules have been established. However, the
SWU_HostplatformServer does not meet all the requirements to successfully
install the SWU Composite Web Module. In the implementation workflows, look
for a managed IP interface. The installation will fail if it is not found. Therefore, to
prepare for this exercise, perform the following tasks:
1. Open the SWU_HostPlatformServer General page. Open the Properties
window of one of the interfaces defined for the virtual servers, for example,
192.168.1.200, which is defined for SWU-0. To do this, click the Edit icon to
the far right and select Properties (Figure 9-15).
Figure 9-15 Updating interface properties
Chapter 9. Exercise 9: Defining the composite application software
187
2. In the properties dialog (Figure 9-16), select the check box against Managed,
and click Save.
Figure 9-16 Making an interface managed
3. You are now taken back to the General page. Verify whether the value of the
field labeled Managed for the interface you modified has changed to Yes.
4. You are now ready to install the three SWU Composite modules. Select
Tasks → Software Provisioning → Install Software to initiate each of the
installations and follow the prompts. Remember to use the SWU HTTP Tivoli
Intelligent Orchestrator Instance Configuration Template when installing the
SWU Composite Web Module.
The installation of the SWU Composite Web Module may take a while to be
completed. This installation actually performs actions against the
SWU_HostPlatformServer to define a new Windows Service for Apache and
to load and configure the Hypertext Markup Language (HTML) pages on to
the system.
188
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
While waiting for the SWU Composite Web Module installation to be
completed, look at the software page for the SWU_HostPlatformServer, and
verify whether the composite database and application modules are installed
and registered. The Software Resources section must look similar to that
shown in Figure 9-17, although you may not see the SWU Composite Web
Module yet.
Figure 9-17 SWU_HostPlatformServer software inventory
5. After the SWU Composite Web Module is installed successfully (track the
status from the Tasks → Task Status wizard), verify the installation by
performing the following tasks:
a. Open a command line in the Tivoli Intelligent Orchestrator Server system
and enter the following command:
net start
This command lists all the services that are started on the system, and at
the end of the list, a service with a name similar to the following must be
visible:
SWUSite@SWU_HostPlatformServer@192.168.1.200@85.
You must also recognize the server name and the IP address. This
indicates that the Apache instance for our Web site has started.
Chapter 9. Exercise 9: Defining the composite application software
189
b. Now that you have verified that the service has started, direct your
browser to the following URL:
http://<your-ip-address>:85
If, for example, the IP address which were assigned to the new HTTP
server is 192.168.1.200, use the following:
http://192.168.1.200:85
Verify whether you see the greeting shown in Figure 9-18.
Figure 9-18 Sample Web page provisioned by Tivoli Intelligent Orchestrator
Note that by using the SWU HTTP Tivoli Intelligent Orchestrator Instance
Configuration Template when installing the SWU Composite Web Module,
the label and the URL of the hyperlink named Tivoli Intelligent
Orchestrator user interface is customized on the fly based on the
information in the software configuration template.
6. To clean up the installations, uninstall the SWU composite modules in the
reverse sequence, that is, Web, Application, and Database, and then
unmanage the network interface you modified in step 1 of this exercise. To
uninstall the SWU composite modules in the reverse sequence, perform the
following tasks:
a. Select Tasks → Software Provisioning → Uninstall Software to
uninstall the SWU Composite Web Module. On completion of this task,
your 192.168.1.200:85 site must be inactive, and the
SWUSite@SWU_HostPlatformServer@192.168.1.200@85 service must
be removed from the TIOServer system.
190
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
b. To remove the SWU Composite Application Module installation, either use
the uninstall wizard or the Uninstall or Delete option from the software
installation object associated with the SWU Composite Application Module
on the Software page of the SWU_HostPlatformServer (Figure 9-19).
Figure 9-19 Removing the SWU Composite Application Module installation
The Delete option only deletes the information in the DCM. However,
because this is a simulated installation, no changes are required on the
physical system.
c. Repeat step b for the SWU Composite Database Module.
d. Follow the procedure in step 1 of this exercise to unmanage the network
interface you modified earlier.
This completes the tasks involved in defining and verifying the software modules
for provisioning the composite application. Proceed to “Exercise 10: Defining the
composite application load balancer and the virtual IP” on page 193.
Chapter 9. Exercise 9: Defining the composite application software
191
192
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
10
Chapter 10.
Exercise 10: Defining the
composite application load
balancer and the virtual IP
The starting point for this exercise is the IBM Software University (SWU) data
center model (DCM) containing the objects that are shown in the frame named A
in Figure 10-1.
© Copyright IBM Corp. 2006. All rights reserved.
193
10.1 The objective of this exercise
In this exercise, you define the objects required to accept the incoming
transaction to the composite application, and balance the load between more
Hypertext Markup Language (HTTP) servers in the SWU environment. This
involves defining a load balancer and a virtual IP for the Web layer of the
composite application to the DCM. In Chapter 11, “Exercise 11: Defining the
SWU composite application production environment” on page 207, the virtual IP
is linked to an application tier in order to allow the automated configuration of the
load balancer to support the requirements of an on-demand composite
application system.
The objects that are created in this exercise are shown in the frame labeled B in
Figure 10-1.
Figure 10-1 Load balancer and virtual IP definition: Starting and
ending environments
194
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
In an on-demand environment, the mission of a load balancer is to intelligently
distribute the load between multiple, similarly configured resources that perform
identical functions. This way, more resources can be added when the demand
increases, and the resources can be reallocated when not required.
Figure 10-2 Load-balanced network infrastructure
To have a common entry point to route the requests to any of the resources that
are available to balance the load, a virtual IP is created in the load balancer and
the available resources are registered with that virtual IP.
In the Tivoli Intelligent Orchestrator implementation, an application tier
represents the multiple systems capable of performing identical functions.
Therefore, to provide a way in which to register and deregister servers that are
provisioned into the application tier with the load balancer, the virtual IP for a
specific function must be linked to the application tier. This way, the Tivoli
Intelligent Orchestrator knows what configuration to change and where to
change the configuration when servers are added or removed. Chapter 11,
“Exercise 11: Defining the SWU composite application production environment”
on page 207 shows that the link between the load balancer and the application
tier is easily managed with a server template.
In the SWU tutorial environment, an IBM WebSphere Edge Server V5, is
installed on the Tivoli Intelligent Orchestrator Server system. This is used as the
target for this exercise. However, because of resource constraints in the
Chapter 10. Exercise 10: Defining the composite application load balancer and the virtual IP
195
single-system tutorial environment, the load balancer is not fully functional.
However, during this exercise, you can verify the configuration updates of the
load balancer.
To enable load balancing for the SWU composite application, perform the
following tasks:
1. Define and initialize the SWU_LoadBalancer.
2. Add the www.swu.com virtual IP to the load balancer.
3. Verify the load balancer configuration.
To perform steps 1 and 2 quickly and easily, use the shortcut described in 10.1.1,
“Shortcut: Creating a load balancer and a virtual IP”.
If you are comfortable with defining load balancers and virtual IPs using the Tivoli
Intelligent Orchestrator user interface, use the shortcut described in 10.1.1,
“Shortcut: Creating a load balancer and a virtual IP” on page 196 to complete all
the tasks in this exercise, and move on to Chapter 11, “Exercise 11: Defining the
SWU composite application production environment” on page 207.
10.1.1 Shortcut: Creating a load balancer and a virtual IP
A set of Extensible Markup Language (XML) files and workflows for the
automated creation of the load balancer and the virtual IP used in the SWU
environment is loaded into the Tivoli Intelligent Orchestrator Server system on
installation of the SWU_2006 tcdriver.
To import these definitions, perform one of the following tasks:
򐂰 Create the load balancer by importing the loadbalancers.xml file in one of the
following ways:
– Execute the SWU_ImportXML workflow by providing a value for the
xmlFile parameter of loadbalancers, either by invoking the workflow from
the user interface or by issuing the following command from the Tivoli
Intelligent Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=loadbalancers
– Issue the following command from the Tivoli Intelligent Orchestrator
Server system command line:
%TIO_HOME%\tools\xmlimport
file:%TIO_HOME%\..\SWrepository\SWU\xml\loadbalancers.xml
196
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
򐂰 Initialize the load balancer by starting the SWU_Initialize_LoadBalancer
workflow in one of the following ways:
– Execute the SWU_Initialize_LoadBalancer workflow by providing a value
for the LoadBalancerName parameter of SWU_LoadBalancer, either by
invoking the workflow from the user interface or by issuing the following
command in the Tivoli Intelligent Orchestrator user interface command
line:
MessageTranslatorService createDeploymentRequest 0
SWU_Initialize_LoadBalancer LoadBalancerName=SWU_LoadBalancer
– Issue the following command from the Tivoli Intelligent Orchestrator
Server system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd
SWU_Initialize_LoadBalancer "LoadBalancerName=SWU_LoadBalancer"
򐂰 Create the www.swu.com virtual IP definition by executing the
SWU_Configure_VIP workflow in one of the following ways:
– Execute the SWU_Configure_VIP workflow by either by invoking the
workflow from the user interface or by issuing the following command from
the Tivoli Intelligent Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0
SWU_Configure_VIP VIPName=www.swu.com
– Issue the following command from the Tivoli Intelligent Orchestrator
Server system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_Configure_VIP
"VIPName=www.swu.com"
When the workflow execution is complete, continue to 10.4, “Verifying the load
balancer configuration” on page 203.
10.2 Defining and initializing the SWU_LoadBalancer
Follow the steps outlined in this section to create and initialize the
SWU_LoadBalancer. If you are comfortable with defining load balancers using
the Tivoli Intelligent Orchestrator user interface, use the shortcut described in
10.2.1, “Shortcut: Creating the load balancer” to complete the load balancer
creation and initialization processes.
Chapter 10. Exercise 10: Defining the composite application load balancer and the virtual IP
197
10.2.1 Shortcut: Creating the load balancer
An XML file and a workflow for defining the load balancer are loaded into the
LocalFileRepository in your Tivoli Intelligent Orchestrator Server system on
installation of the SWU_2006 tcdriver. To import these definitions, perform the
following tasks:
1. Create the load balancer by performing one of the following tasks:
– Execute the SWU_ImportXML workflow by providing a value for the
xmlFile parameter of loadbalancers, either by invoking the workflow from
the user interface or by issuing the following command from the Tivoli
Intelligent Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=loadbalancers
– Issue the following command from the Tivoli Intelligent Orchestrator
Server system command line:
%TIO_HOME%\tools\xmlimport
file:%TIO_HOME%\..\SWrepository\SWU\xml\loadbalancers.xml
2. Initialize the load balancer by performing one of the following tasks:
– Execute the SWU_Initialize_LoadBalancer workflow by providing a value
for the LoadBalancerName parameter of SWU_LoadBalancer, either by
invoking the workflow from the user interface or by issuing the following
command from the Tivoli Intelligent Orchestrator user interface command
line:
MessageTranslatorService createDeploymentRequest 0
SWU_Initialize_LoadBalancer LoadBalancerName=SWU_LoadBalancer
– Issue the following command from the Tivoli Intelligent Orchestrator
Server system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd
SWU_Initialize_LoadBalancer "LoadBalancerName=SWU_LoadBalancer"
When the workflow execution is complete, continue to 10.3, “Adding the
www.swu.com virtual IP to the load balancer” on page 201.
To manually define a load balancer to your DCM, perform the steps described in
10.2.2, “Exercise: Defining the load balancer”.
198
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
10.2.2 Exercise: Defining the load balancer
To define the load balancer, perform the following tasks:
1. Navigate to Inventory → Network Infrastructure → Load Balancers.
Create SWU_LoadBalancer by selecting the Edit → Add Load Balancer
menu option and provide the necessary information, as shown in Figure 10-3.
Click Save.
Figure 10-3 Defining a new SWU_LoadBalancer
2. Open the newly created load balancer and assign service access points from
the Credentials page of the SWU_LoadBalancer object. As mentioned earlier
in this book, service access points are used to ensure communication with the
device, in this case, the load balancer. Add the SSH-host and SSH-client
credentials as described in 3.3, “Defining the access points and the
credentials” on page 26. Alternately, start the SWU_SetDeviceCredentials
workflow by supplying the name of the Load Balancer, SWU_LoadBalancer,
as the input parameter.
3. Go to the Networks page to add a management and a nonmanagement
network interface to the load balancer. The existence of the management
interface ensures that the Tivoli Intelligent Orchestrator server can
communicate with it. Use the 192.168.1.5 IP address that is hosted on the
Tivoli Intelligent Orchestrator Server system. The nonmanagement interface
must have an IP address of 192.168.100.253 for the load balancer to reach
the client gateway. You can either name the gateway interface RIP, as shown
in Figure 10-4, or opt for any other name.
Figure 10-4 SWU_LoadBalancer interfaces
Chapter 10. Exercise 10: Defining the composite application load balancer and the virtual IP
199
4. To assign a device driver to the Load Balancer, go to the Workflows page.
Select Edit → Assign Device Driver to assign a driver named
SWU_IBMWES_LoadbalancerDM. This is a modified version of the standard
IBMWES_LoadbalancerDM device driver that enables communication with
the IBM WebSphere Edge Component Load Balancer installed in the Tivoli
Intelligent Orchestrator Server system.
5. The device driver uses a couple of variables to identify the specifics of the
operating environment of the IBM WebSphere Edge Component Load
Balancer running on the Tivoli Intelligent Orchestrator Server. To define
these, go to the Variables page and add the variables listed in Table 10-1.
Table 10-1 SWU_LoadBalancer variables
Name
Component
Value
wes.clientGateway
Deployment engine
192.168.100.254
wes.commandLocation
Deployment engine
/cygdrive/c/winnt/system32
wes.returnAddress
Deployment engine
192.168.100.1
6. The SWU_LoadBalancer is created and customized in the DCM. However,
the implementation must be initialized. Go to the General page and click the
Initialize icon to the far right (Figure 10-5).
Figure 10-5 Initializing the Load Balancer
7. After successful submission, navigate to Configuration → Deployment
Requests, and check the status of the request number indicated in the
message. After the device, initialize LDO, and implementation workflows are
complete, create a virtual IP.
200
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
10.3 Adding the www.swu.com virtual IP to the load
balancer
The virtual IP is used by clients (users) as a common name for the multiple
servers controlled by the load balancer. When users request the service of the
virtual IP, the load balancer redirects the request to a server that has been
defined as supporting the virtual IP. In this section, you define the cluster used to
control the resources in the cluster that supports the virtual IP. However, you
must first create the virtual IP and register it with the DCM.
The virtual IP can be defined to the DCM either by using the Tivoli Intelligent
Orchestrator user interface or by starting the LoadBalancer.CreateVirtualIP LDO.
Both these methods are described in this section. In the shortcut described in
10.3.1, “Shortcut: Creating a virtual IP”, the LDO invocation is embedded into a
workflow that sets up most of the required parameters.
10.3.1 Shortcut: Creating a virtual IP
A workflow for the definition of the www.swu.com VIP is loaded into the Tivoli
Intelligent Orchestrator Server system on installation of the SWU_2006 tcdriver.
In order to use this to configure the www.swu.com virtual IP, perform one of the
following tasks:
򐂰 Execute the SWU_Configure_VIP workflow by either by invoking the workflow
from the user interface or by issuing the following command from the Tivoli
Intelligent Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_Configure_VIP
VIPName=www.swu.com
򐂰 Issue the following command from Tivoli Intelligent Orchestrator Server
system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_Configure_VIP
"VIPName=www.swu.com"
When the workflow execution is complete, move to 10.4, “Verifying the load
balancer configuration” on page 203.
Chapter 10. Exercise 10: Defining the composite application load balancer and the virtual IP
201
10.3.2 Exercise: Defining a virtual IP
To manually create the www.swu.com virtual IP for the SWU composite
application, perform the following tasks:
1. Navigate to Inventory → Network Infrastructure → Load Balancers →
SWU_LoadBalancer. Select the Edit → Add Virtual IP menu option and
provide the necessary information for the parameters, as shown in
Figure 10-6. Click Save to submit the request.
Important: Ensure that the check-box against the Use Logical Operation
field is selected (Figure 10-6).
Figure 10-6 Adding a virtual IP to RIP
2. Optionally, use the link in the message box, as shown in Figure 10-7 to
navigate to the Deployment Request in order to check the status.
Figure 10-7 AddVIPtoRIP task execution
After you have looked at the details of the Deployment Request, use the
browser's Back button to return to the SWU_LoadBalancer General page
after the Deployment Request has succeeded.
Click Refresh in the top-right corner.
202
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
3. Note that the www.swu.com virtual IP appears. Your display must look similar
to that shown in Figure 10-8.
Figure 10-8 Load balancer with virtual IP
4. The final step is to add a variable to the new virtual IP that is used to help
configure the networking infrastructure. Open the virtual IP by double-clicking
the link named www.swu.com, and go to the Variables page. Add the
variables shown in Table 10-2.
Table 10-2 Virtual IP variables
Name
Component
Value
wes.clientGateway
Deployment engine
192.168.100.254
wes.commandLocation
Deployment engine
/cygdrive/c/winnt/system32
wes.returnAddress
Deployment engine
192.168.100.1
This completes the creation of the www.swu.com virtual IP. You can now verify
whether your definitions are working as intended.
10.4 Verifying the load balancer configuration
To check whether the initialization and configuration of the load balancer has
actually taken place, verify the configuration of the load balancer on the
TIOServer system by performing the following tasks:
1. Open the desktop of the TIOServer system and start the Load Balancer
console by clicking the icon
called Load Balancer. The console
takes a while to initialize.
Chapter 10. Exercise 10: Defining the composite application load balancer and the virtual IP
203
After it has initialized, right-click Dispatcher, and select Connect to Host
(Figure 10-9).
Figure 10-9 Connect to load balancer host
2. Select the default host that is presented (Figure 10-10), and click OK.
Figure 10-10 Select the load balancer host
3. Expand the Dispatcher tree until you see that the www.swu.com cluster has
been defined and is using port 85 (Figure 10-11).
Figure 10-11 Load balancer properties
You have now verified the configuration of the load balancer. After completing
the exercise described in Chapter 11, “Exercise 11: Defining the SWU
composite application production environment” on page 207, verify the
assignment of servers to the virtual IP too.
204
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
This completes the process involved in defining and verifying the configuration of
the load balancer and the virtual IP for the composite application system.
Proceed to “Exercise 11: Defining the SWU composite application production
environment”.
Chapter 10. Exercise 10: Defining the composite application load balancer and the virtual IP
205
206
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
11
Chapter 11.
Exercise 11: Defining the
SWU composite application
production environment
The starting point for this exercise is the IBM Software University (SWU) data
center model (DCM), with the objects defined representing the components
shown in the frame labeled A in Figure 11-1.
© Copyright IBM Corp. 2006. All rights reserved.
207
11.1 The objective of this exercise
In this exercise, you define the data center objects that represent your composite
application production environment, customer application, and application tiers.
These definitions are necessary for you to provision the composite application,
drawing on all the definitions you created in the exercises described in the earlier
chapters.
The objects that you create in this exercise are included in the frame labeled B in
Figure 11-1.
Figure 11-1 Defining the production environment’s starting and ending points
208
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
In the Tivoli Information Orchestrator DCM, applications are owned by customers
and comprise one or more application tiers representing the distinct layers of the
composite application. Application tiers may be associated with a number of data
center resources that play supporting roles when servers are being deployed into
a tier. Following are the supporting resources that relate to the
SWU_Composite_Application:
򐂰 Resource pool
This is used as a pointer to a group of servers in which candidates for
provisioning into the application tier are found. In this exercise, you use the
SWU_Pristine_Server_Pool to provide servers to all the three application
tiers.
򐂰 Server template
This is used to control networks and storage and software configuration
changes of the servers that are applied during the provisioning process.
During the course of this exercise, you define unique server templates for
each tier. The software configurations are based on software stacks, as in the
case of Chapter 10, “Exercise 10: Defining the composite application load
balancer and the virtual IP” on page 193.
򐂰 Virtual IP
This is used to control the association of servers in the tier with a load
balancer for the server to receive requests. In this exercise, you use the
www.swu.com virtual IP, which was created earlier.
11.1.1 Shortcut: Creating composite application tiers and templates
An Extensible Markup Language (XML) file for the automated creation of the
production environment for the SWU_Composite_Application is loaded into the
TIOServer system on installation of the SWU_2006 tcdriver.
To import these definitions, perform the following tasks:
1. Execute the SWU_ImportXML workflow by providing a value for the xmlFile
parameter of customers_and_applications, either by invoking the workflow
from the user interface or by issuing the following command from the Tivoli
Interface Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=customers_and_applications
2. Issue the following command from a TIOServer system command line:
%TIO_HOME%\tools\xmlimport
file:%TIO_HOME%\..\SWrepository\SWU\xml\customers_and_applications.x
ml
Chapter 11. Exercise 11: Defining the SWU composite application production environment
209
3. In order to assign the correct device driver for each of the server templates,
run the SWU_AssignDriverToTemplate workflow for each of the following
three templates:
– servertemplates SWU_Composite_Web_Template
– SWU_Composite_Application_Template
– SWU_Composite_Database_Template
Refer to the procedure outlined in step 3 on page 95 of “Shortcut: Creating the
host platform server and the Virtual Server Template” on page 94 for details.
When the workflow execution is complete, continue to 11.6.3, “Verifying the
production environment” on page 220.
Perform the tasks described here in order to manually define a customer, an
application, and the application tiers required to support the
SWU_Composite_Application to your DCM.
11.2 Creating a customer
Creating a customer for the SWU composite application is a simple operation.
11.2.1 Exercise: Defining the SWU_Customer
To define the SWU_Customer for the composite application production
environment, navigate to Applications → Customers and use the Edit → Add
Customer menu option to add a customer named SWU_Customer. Click Save.
Figure 11-2 Defining the SWU_Customer
This completes the creation of the SWU_Customer.
210
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
11.3 Creating an application
The creation of the SWU_Composite_Application is also simple.
11.3.1 Exercise: Defining the SWU_Composite_Application
To define the SWU_Composite_Application for the composite application
production environment, from the General page of the newly created
SWU_Customer, select the Edit → Add Application menu option and provide
the relevant information, as shown in Figure 11-3. Click Save.
Figure 11-3 SWU_Composite Application properties
The selected SLA Service Plan, Platinum, provides the highest priority to the
SWU_Composite_Application. Thus, it receives resources prior to other
applications with lower priority in case of general resource shortage.
Also note that Capacity On Demand is set to On. This enables Tivoli
Intelligent Orchestrator to issue recommendations regarding the allocation
and deallocation of resources to the application.
This completes the creation of the SWU_Composite_Application. Next, you
define the individual application tiers that host the resources for the individual
layers of the composite application.
Chapter 11. Exercise 11: Defining the SWU composite application production environment
211
11.4 Creating the application tier for the database layer
The application tiers, known earlier as clusters, are basically logical
representations in the DCM, representing each layer of the composite
application.
For the SWU_Composite_Application, a server template is used to control the
network and software configuration of the tiers, one server template for each tier.
The order in which the server template and the application tier is defined does
not really matter, but here, in this workshop, the application tier is defined first,
and then the server template.
11.4.1 Exercise: Defining the SWU_Composite_Database_Tier
In order to define the application tier for the servers in the composite application
production environment that implement the database functionality, perform the
following tasks:
1. Open SWU_Composite_Application and select the Edit → Add Tier menu
option, and supply the relevant information, as shown in Figure 11-4. Click
Save.
Figure 11-4 The SWU_Database_Tier
2. Open the new application tier and go the Workflows page. Assign the
SWU_ClusterDM device driver to the application tier.
212
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
3. Go to the Variables page of the tier and add the variables shown in
Table 11-1. This enables the reporting of the actual CPU load for the servers
in this tier.
Table 11-1 SWU_Database_Tier properties
Name
Component
Value
cpu-utilization.aggregation
Data acquisition engine
average
cpu-utilization.device
Data acquisition engine
server
cpu-utilization.filter
Data acquisition engine
low-pass-filter
cpu-utilization.metric
Data acquisition engine
cpu-utilization
server.driver
Data acquisition engine
com.thinkdynamics.kana
ha.dataacquisitionengine
.snmp.WindowsDriver
This completes the creation of the SWU_Composite_Database_Tier.
11.4.2 Exercise: Defining the SWU_Composite_Database_Template
Perform the following tasks to manually create a server template for the
composite application tier that supports the database layer of the application:
1. Navigate to Inventory → Servers → Physical Servers → Server
Templates. In the Server Template Inventory page, select the Edit → Add
Server Template menu option to create a server template named
SWU_Composite_Database_Template. Associate the template with the
SWU_Composite_Database_Tier application tier you created earlier, as
shown in Figure 11-5.
Figure 11-5 Server template for the SWU_Database_Tier
Chapter 11. Exercise 11: Defining the SWU composite application production environment
213
2. Open the new server template and add an Network Interface Card (NIC), an
interface, and a software stack by performing the following tasks:
a. Use the Edit → Add NIC menu option to add an NIC associated with the
virtual local area network (VLAN), in this case, SWU_VLAN-130. Click
Save (Figure 11-6).
Figure 11-6 Adding an NIC to the template VLAN
b. In the new NIC definition, select the Edit → Add Interface menu option
and associate the new interface with the subnetwork, in this case,
192.168.130.240/28. Click Save (Figure 11-7).
Figure 11-7 Associating the new interface
c. Use the Edit → Associate Software Stack menu option to associate the
SWU_Composite_Database_Stack with the server template. Click Save
when finished (Figure 11-8).
Figure 11-8 Associating a software stack to the tier template
214
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
At this point, your software stack should look similar to that shown in
Figure 11-9.
Figure 11-9 The SWU_Composite_Database_Template
This completes the creation of the server template that governs the network and
software configuration of the servers that will be deployed into the
SWU_Composite_Database_Tier.
11.5 Creating the tier for the application layer
The process involved in defining the application layer of the composite
application is similar to that involved in defining the database layer, although the
set of parameters used is different. As with the database layer, control the
network and software configuration of the server in this tier by using a server
template.
Chapter 11. Exercise 11: Defining the SWU composite application production environment
215
11.5.1 Exercise: Defining the
SWU_Composite_Application_Template
To manually create a server template for the application tier used to support the
application layer in the SWU_Composite_Application_Tier composite
application, use the procedure outlined in 11.4.1, “Exercise: Defining the
SWU_Composite_Database_Tier” on page 212 and include the information
provided in Table 11-2.
Table 11-2 SWU_Composite_Application_Template properties
Attribute
Value
Name
SWU_Composite_Application_Template
Tier Number
5
Managed By Intelligent
Orchestrator
checked
Locale
English
Resource Pool
SWU_Pristine_Server_Pool
Overflow Servers
min: 1, max: 4
Server Template
none
ClusterDomain
none
This completes the creation of the SWU_Composite_Application_Tier.
11.5.2 Exercise: Defining the SWU_Composite_Application Tier
To create the server template for the application tier hosting the servers
implementing the application server functions for the
SWU_Composite_Application_Template composite application, follow the
procedure outlined in 11.4.2, “Exercise: Defining the
SWU_Composite_Database_Template” on page 213 and include the information
shown in Table 11-3.
Table 11-3 SWU_Composite_Application_Tier properties
216
Attribute
Value
Name
SWU_Composite_Application_Template
Owner
SWU_Composite_Application_Tier
NIC VLAN Association
SWU_VLAN-120
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
Attribute
Value
Interface Subnetwork
192.168.120.240/28
Resource Pool
SWU_Pristine_Server_Pool
Software Stack
SWU_Composite_Application_Stack
This completes the creation of the SWU_Composite_Application_Template.
11.6 Creating the tier for the Web layer
The process of defining the Web layer of the composite application is similar to
that involved in defining the other tiers. However, because the Web layer is the
one that receives requests from the application users, assign additional
parameters to link this tier with the virtual IP you defined in 10.3, “Adding the
www.swu.com virtual IP to the load balancer” on page 201.
11.6.1 Exercise: Defining the SWU_Composite_Web_Tier
To create an application tier for the servers that host the Web server functionality
of the composite application, perform the following tasks:
1. To create the SWU_Composite_Web_Tier, use the procedure outlined in
“Exercise: Defining the SWU_Composite_Database_Tier” on page 212 and
include the information shown in Table 11-4.
Table 11-4 SWU_Composite_Web_Tier properties
Attribute
Value
Name
SWU_Composite_Web_Tier
Tier Number
5
Managed By Intelligent Orchestrator
checked
Locale
English
Resource Pool
SWU_Pristine_Server_Pool
Overflow Servers
min: 1, max: 3
Server Template
none
ClusterDomain
none
Chapter 11. Exercise 11: Defining the SWU composite application production environment
217
2. To associate the application tier with the www.swu.com virtual IP in order to
provide load balancing for the on-demand environment, open the
SWU_Composite_Web_Tier, and select Edit → Properties. Use the Add
icon at the bottom of the Properties window to associate the www.swu.com
virtual IP with the tier (Figure 11-10). Click Save.
Figure 11-10 Associating a server template with a tier
This completes the creation of the SWU_Composite_Web_Tier.
11.6.2 Exercise: Defining the SWU_Composite_Web_Template
To create the server template for the composite application Web layer, perform
the following tasks:
1. To create the SWU_Composite_Web_Template, use the procedure outlined
in 11.4.2, “Exercise: Defining the SWU_Composite_Database_Template” on
page 213 and include the relevant information shown in Table 11-5.
Table 11-5 SWU_Composite_Web_Template properties
218
Attribute
Value
Name
SWU_Composite_Web_Template
Owner
SWU_Composite_Web_Tier
NIC VLAN Association
SWU_VLAN-110
Interface Subnetwork:
192.168.110.240/28
Resource Pool
SWU_Pristine_Server_Pool
Software Stack
SWU_Composite_Web_Stack
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
2. To enable the automatic addition of servers that are configured according to
the SWU_Composite_Web_Template to the load balancer, link the virtual IP
to the interface definitions in the server template, open the
SWU_Composite_Web_Template. Select Edit → Add Logical Tier, and
supply the relevant information, as shown in Figure 11-11. (Note that the
software definition is provided as a reference point that is to be used when
associating templates with cluster domains, which is, however, not the case
here.) Click Save.
Figure 11-11 Supplying an application VIP
The creation of the SWU_Composite_Web_Template is now complete.
This completes the definition of the production environment for the
SWU_Composite_Application. You are now ready to see how the provisioning
processes work in the SWU environment.
Chapter 11. Exercise 11: Defining the SWU composite application production environment
219
11.6.3 Verifying the production environment
To verify whether the definition of the application has taken effect, perform the
following tasks:
1. Navigate to Applications → Customers → SWU_Customer →
SWU_Composite_Application. Then select View → Icon View to see the
overview shown in Figure 11-12.
Figure 11-12 SWU_Composite_Application properties
Note the way the tiers are placed (according to the numbers) and that the
Effective Mode of the application and all the tiers is Maintenance. Also note
the fact that the Operating Mode of all the tiers and the application itself is set
to Default.
2. Use the Home icon in the top right corner of the Tivoli Intelligent Orchestrator
user interface to go back to the Welcome page.
220
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
3. In the Welcome page, select the Overview tab. This shows the overview of
your data center (Figure 11-13). Note the three tiers of the application and the
highlighted relationship between the tiers and the resource pools.
Figure 11-13 Application infrastructure overview
This completes the process of defining and verifying the production environment
for the composite application system. Proceed to Chapter 12, “Exercise 12:
Defining the cluster domain for the Web layer” on page 223.
Chapter 11. Exercise 11: Defining the SWU composite application production environment
221
222
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
12
Chapter 12.
Exercise 12: Defining the
cluster domain for the Web
layer
The starting point for this exercise is the IBM Software University (SWU) data
center model (DCM) containing the objects that are shown in the frame named A
in Figure 12-1.
© Copyright IBM Corp. 2006. All rights reserved.
223
12.1 The objective of this exercise
In this exercise, you define the objects required to model a cluster of identical
servers (a peer cluster domain) in the SWU environment. This involves defining a
load balancer, a virtual IP, and a cluster domain to the DCM. At a later point in
these tutorial exercises, the virtual IP is linked to an application tier to allow
automated configuration of the load balancer and the cluster domain to support
the new requirements of the on-demand composite application system.
The objects created in this exercise are included in the frame labeled B in
Figure 12-1.
Figure 12-1 Cluster domain definition: Starting and ending environments
224
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
To better understand the setup of the cluster domains and the load balancers, a
diagram of the expected setup (Figure 12-2) is helpful. As shown in Figure 12-2,
you are about to establish a cluster consisting of a number of Hypertext Transfer
Protocol (HTTP) servers managed by the load balancer created in 10.2,
“Defining and initializing the SWU_LoadBalancer” on page 197.
Figure 12-2 Clustering the network infrastructure
Before you define the clusters, review the series of events that will take place
when you provision a new server into a clustered application tier. Following is a
list of these events:
1. Assigning a new IP address because some of the software installations are
sensitive to the IP address used at installation time
2. Installing or instantiating the necessary software or creating the necessary
software instances or both, and then loading the optional configuration and
application data.
3. Updating the cluster manager to make it aware of the existence of the new
HTTP Server resource
Chapter 12. Exercise 12: Defining the cluster domain for the Web layer
225
For the SWU_Composite_Application_Tier, perform the following actions when
deploying a server from the resource pool to the tier:
1. Assign an 192.168.110.24x address.
2. Install a HTTP Server, load the static pages, and ensure that the service is
started on the desired port.
3. Add the new server as a cluster node and add the HTTP Server as a resource
in the cluster. If it applies to your configuration, ensure that the instance is
started.
4. Update the cluster to recognize the new HTTP Server instance.
By using the objects available to aid in this process, the server template
associated with the application tier helps you to determine how to perform the IP
allocation and software installation. The SoftwareResourceTemplates for the
SWU IBM HTTP Server V2.0 determines what to install and how to install. In
addition, the templates control the definition and the allocation of cluster
resources, resource groups, and relationships. The application tier is associated
directly with a server template and a cluster domain, and indirectly with a load
balancer through the association of a virtual IP.
Setting up a cluster domain allows you to control the resources in the application
tier on a finer level than the server level. By defining and grouping the cluster
resources, you can operate any object type across the nodes in the cluster.
In order to define the resources and the groups of resources managed by the
cluster domain, use a software definition that contains three specific software
resource templates, ClusterResources, ClusterResourceGroups, and
ClusterResourceRelationships. Look at the software resource templates defined
for the IBM HTTP Server V2.0 software product, which already includes these
definitions. Although any software product definition can be used, because you
are managing HTTP Server instances, using the HTTP Server software definition
makes sense because you will be given a direct pointer to the physical resources
you control from the cluster.
12.2 Creating the cluster domain
To create the cluster domain, either use the information provided in the shortcut
described in 12.2.1, “Shortcut: Creating the cluster domain”, or carry out the
exercises described subsequently to manually define the
SWU_Composite_Web_Cluster to your DCM.
226
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
12.2.1 Shortcut: Creating the cluster domain
A set of definition files for the automated creation of the cluster domain for the
SWU_Composite_Web_Tier and the related virtual IP is loaded into the
TIOServer system on installation of the SWU_2006 tcdriver.
To create the SWU_Composite_Web virtual IP, perform one of the following
tasks:
򐂰 Execute the SWU_Configure_VIP workflow by either by invoking the workflow
from the user interface or by issuing the following command from the Tivoli
Intelligent Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_Configure_VIP
VIPName= swu_compostite_web
򐂰 Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_Configure_VIP
"VIPName=swu_compostite_web"
To import the cluster domain definitions, perform one of the following tasks:
򐂰 Execute the SWU_ImportXML workflow by providing a value for the xmlFile
parameter of clusterdomains, either by invoking the workflow from the user
interface or by issuing the following command from the Tivoli Intelligent
Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=clusterdomains
򐂰 Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
xmlFile=clusterdomains
When the workflow execution is complete, continue to 12.5, “Verifying the cluster
domain definition” on page 231.
Follow the instructions provided in 12.3, “Defining the SWU_Composite_VIP” to
manually create the SWU_Composite_Web virtual IP and the
SWU_Composite_Web_ClusterDomain.
12.3 Defining the SWU_Composite_VIP
Before creating the cluster domain, create the virtual IP that is to be used as a
common address to access any of the cluster resources. Use the shortcut
described in 12.3.1, “Shortcut: Creating the cluster domain virtual IP” or the
exercise described consequently to create the SWU_Composite_Web virtual IP.
Chapter 12. Exercise 12: Defining the cluster domain for the Web layer
227
12.3.1 Shortcut: Creating the cluster domain virtual IP
A workflow for the automated creation of the cluster domain virtual IP is loaded
into the TIOServer system on installation of the SWU_2006 tcdriver.
To create the SWU_Composite_Web virtual IP, perform one of the following
tasks:
򐂰 Execute the SWU_Configure_VIP workflow either by invoking the workflow
from the user interface or by issuing the following command from the Tivoli
Intelligent Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_Configure_VIP
VIPName=swu_composite_web
򐂰 Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_Configure_VIP
"VIPName=swu_composite_web"
To import the cluster domain definitions, perform one of the following tasks:
򐂰 Execute the SWU_ImportXML workflow by providing a value for the xmlFile
parameter of clusterdomains, either by invoking the workflow from the user
interface or by issuing the following command from the Tivoli Intelligent
Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=clusterdomains
򐂰 Issue the following command from the TIOServer system command line:
%TIO_HOME%\..\SWrepository\SWU\bin\run_wf.cmd SWU_ImportXML
"xmlFIle=clusterdomains.xml"
When the workflow execution is complete, continue to 12.4, “Creating the cluster
domain” on page 229.
Complete the exercise detailed in 12.3.2, “Exercise: Defining the cluster domain
virtual IP” to define the cluster domain virtual IP manually.
228
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
12.3.2 Exercise: Defining the cluster domain virtual IP
Follow the procedure outlined in 10.3, “Adding the www.swu.com virtual IP to the
load balancer” on page 201 to create the SWU_Composite_Web virtual IP with
the definitions provided for the fields shown in Figure 12-3.
Figure 12-3 Defining the cluster domain virtual IP
This completes the creation of the cluster domain virtual IP. Proceed to the task
of creating the cluster domain.
12.4 Creating the cluster domain
To create the cluster domain, perform the tasks described in 12.4.1, “Shortcut:
Creating the cluster domain” or the exercise described in 12.4.2, “Exercise:
Defining the SWU_Composite_Web_ClusterDomain” on page 230.
12.4.1 Shortcut: Creating the cluster domain
An XML file for the automated creation of the
SWU_Composite_Web_ClusterDomain is loaded into the TIOServer system on
installation of the SWU_2006 tcdriver.
To import the cluster domain definitions, perform one of the following tasks:
򐂰 Execute the SWU_ImportXML workflow by providing a value for the xmlFile
parameter of clusterdomains, either by invoking the workflow from the user
interface or by issuing the following command from the Tivoli Intelligent
Orchestrator user interface command line:
MessageTranslatorService createDeploymentRequest 0 SWU_ImportXML
xmlFile=clusterdomains
򐂰 Issue the following command from the TIOServer system command line:
%TIO_HOME%\tools\xmlimport
file:%TIO_HOME%\..\SWrepository\SWU\xml\clusterdomains.xml
Chapter 12. Exercise 12: Defining the cluster domain for the Web layer
229
When the workflow execution is complete, continue to 12.5, “Verifying the cluster
domain definition”.
To define the cluster domain manually, complete the exercise defined in 12.4.2,
“Exercise: Defining the SWU_Composite_Web_ClusterDomain”.
12.4.2 Exercise: Defining the SWU_Composite_Web_ClusterDomain
To create the SWU_Composite_Web_ClusterDomain, perform the following
tasks:
1. Navigate to Applications → Cluster Domains. Use the Edit → Add Cluster
Domain menu option and provide the necessary information, as shown in
Figure 12-4, and click Save.
Figure 12-4 Adding a cluster domain
2. Open the new cluster domain definition. Go to the Workflows page and assign
the device driver SWU_ClusterDomainDM.
This completes the creation of the cluster domain.
230
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
12.5 Verifying the cluster domain definition
Follow the instructions provided in the exercise described in 12.5.1, “Exercise:
Verifying the cluster domain definitions” to verify the cluster domain definitions.
12.5.1 Exercise: Verifying the cluster domain definitions
To verify whether your cluster domain definitions are operational, perform the
following tasks:
1. Navigate to Applications → Cluster Domains. Select the Edit → Config
menu option (Figure 12-5). In the pop-up that appears, select
SWU_HostPlatformServer as the first node in your cluster domain, and click
Save.
Figure 12-5 Initializing the cluster domain
This initializes your cluster domain based on the software resource templates
defined for the software module that is associated with the cluster domain. In
your case, you specified the SWU IBM HTTP Server V2.0 as the software
product. The related software resource templates named ClusterResources,
ClusterResourceGroups, and ClusterResourceRelationships will be used as
the templates for the creation of groups and the resources in the cluster
domain.
Chapter 12. Exercise 12: Defining the cluster domain for the Web layer
231
2. Open the cluster domain and verify whether you have two resource groups
defined. Select Edit → Delete to delete the server (Figure 12-6). The server
was used only to initialize the cluster domain. Because no Apache instances
are going to execute on that server, you can remove it.
Figure 12-6 Removing a server from a cluster domain
3. Link the newly defined cluster domain to the SWU_Composite_Web_Tier for
the cluster resources to be automatically registered when a server is
provisioned to it. To do this, perform the following tasks:
a. Navigate to Applications → Customers → SWU_Customer →
SWU_Composite_Application → SWU_Composite_Web_Tier. Select
the Edit → Properties menu option, and assign
SWU_Composite_Web_ClusterDomain to the tier (Figure 12-7). Click
Save.
Figure 12-7 Linking a cluster domain to an application tier
232
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
This completes the process involved in defining and verifying the cluster
definitions for provisioning the composite application. Proceed to Chapter 13,
“Exercise 13: Deploying the composite application” on page 235, the final
exercise in which you see all the definitions come together.
Chapter 12. Exercise 12: Defining the cluster domain for the Web layer
233
234
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
13
Chapter 13.
Exercise 13: Deploying the
composite application
The starting point for this exercise is the fully configured IBM Software University
(SWU) data center model (DCM) you built in Chapter 12, “Exercise 12: Defining
the cluster domain for the Web layer” on page 223.
© Copyright IBM Corp. 2006. All rights reserved.
235
13.1 The objective of this exercise
In this exercise, you deploy the servers into the application structure created in
Chapter 12, “Exercise 12: Defining the cluster domain for the Web layer” on
page 223, and verify whether the expected actions, such as software
installations, network configurations, and DCM updates, are performed as
intended. In addition, you explore the Tivoli Intelligent Orchestrator's capabilities
to sense and respond in order to facilitate automated, on-demand provisioning.
13.2 Deploying the application
Complete the exercises described here to deploy the
SWU_Composite_Application and experience how the Tivoli Intelligent
Orchestrator allocates resources and reports usage.
13.2.1 Exercise: Changing the maintenance mode
To deploy the servers into an application, you must first make it operational. The
status of the application and all the tiers immediately after the creation is
Maintenance. This status is used whenever changes have to be made to the
configuration of the application or any of the tiers. Whenever an application is in
Maintenance, the Tivoli Intelligent Orchestrator does not perform any actions
against it.
To make the application available, open the SWU_Composite_Application and
use the Management → Out of Maintenance menu option to change the status.
The status of the application and all the tiers is changed to the currently defined
operation mode, which, by default, is Manual.
236
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
13.2.2 Exercise: Viewing the recommendations
Now that the application is operational and the operation mode is Manual, take a
look at the Recommendations page (Figure 13-1).
Figure 13-1 Recommendations for the SWU_Composite_Application
Note that a set of recommendations to deploy one server to each of the tiers
have been issued. This has occurred because Capacity On Demand is activated
for the application, and the minimum number of servers for each tier is greater
than 0.
Because the Tivoli Intelligent Orchestrator is capable of determining whether to
provision or deprovision servers, based on the actual situation and application
mix, you may want to take advantage of this to allow the following:
򐂰 Automated provisioning for the database tier
򐂰 Semiautomatic provisioning for the application tier
򐂰 Manual provisioning for the Web tier
13.2.3 Exercise: Setting the operation mode for a tier
In an SWU environment, where gathering of CPU utilization data is enabled, you
want the Tivoli Intelligent Orchestrator to automatically allocate servers to the
database tier as required. This is risk-free because the tier defines both the
minimum and the maximum number of servers to 1. Therefore, only one server is
deployed.
Chapter 13. Exercise 13: Deploying the composite application
237
To set the operating mode for a tier, perform the following tasks:
1. Ensure that the status of the application the tier belongs to is not
Maintenance. Open the tier and select the desired operation mode from the
Operating Mode field. Click Change when done (Figure 13-2).
Figure 13-2 Changing the operation mode of an application tier
2. Set the desired operation modes for the tiers in the
SWU_Composite_Application by performing these tasks:
a. Set the operational mode of the SWU_Composite_Database_Tier to
Automatic. This enables the Tivoli Intelligent Orchestrator to perform the
deployments automatically.
b. For the application tier, because you want a little more control, set the
operational mode of the SWU_Composite_Application_Tier to
Semiautomatic, which results in recommendations that you can approve
or reject.
c. For the SWU_Composite_Web_Tier, because you want full control, set
the operation mode for this tier to Manual.
13.2.4 Exercise: Using the automatic operation mode
To verify the effect of the new settings, go back to the Recommendations page of
the SWU_Composite_Application and ensure that the status is set to All. Click
Search, and pay attention to the list of recommendations.
238
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
You see that the deployment of a server to the SWU_Composite_Database_Tier
starts automatically as expected (Figure 13-3).
Figure 13-3 Server deployment in progress
After the installation is complete, the overview of the application shows that one
server is allocated to the database tier (Figure 13-4).
Figure 13-4 Successful deployment of a server
Chapter 13. Exercise 13: Deploying the composite application
239
When you open the General page of the server that is deployed, you see that the
assignment has changed. It is now assigned to the
SWU_Composite_Database_Tier. The template associated with the server is the
SWU_Composite_Database_Template (Figure 13-5).
Figure 13-5 Server assigned to SWU_Composite_Database_Tier
Also note that the server still belongs to the SWU_Pristine_Server_Pool, and that
the management IP address is the one assigned when the server was created.
Verify this by opening a command line in the TIOServer system and check the
output of the ipconfig command.
When you look closely at the server that is deployed, in this case, SWU-5, you
see that an interface is allocated on the second or the managed Network
Interface Card (NIC), and that an address in the 192.168.230.240/28 subnet is
assigned just as expected, because these are the settings defined in the server
template associated with the tier (Figure 13-6).
Figure 13-6 Deployed server interface properties
240
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
In the Software page of the server, note that the software products defined for
the stack that was associated with the server template are all installed, and the
server is compliant with the stack (Figure 13-7).
Figure 13-7 Deployed server software inventory
13.2.5 Exercise: Using the semiautomatic operation mode
Setting the operation mode to semiautomatic for the
SWU_Composite_Application_Tier results in a slightly different behavior. To use
the semiautomatic operation mode, perform the following tasks:
1. In the Recommendations page of the SWU_Application, a recommendation
(shown in Figure 13-1 on page 237) is available without any details. However,
opening the Recommendations page, for the
SWU_Composite_Application_Tier shows the semiautomatic mode and
presents you with the option to approve or dismiss the recommendation
(Figure 13-8). Click the Approve icon to accept the deployment.
Figure 13-8 Accepting the deployment recommendations
Chapter 13. Exercise 13: Deploying the composite application
241
After a short while, you see that the deployment is complete (Figure 13-9).
(Remember that all the software in the stack associated with the tier is
simulated.)
Figure 13-9 Tracking the semiautomated deployment
2. Go to the General page of the SWU_Composite_Application_Tier and see
which server is deployed (Figure 13-10).
Figure 13-10 Server deployed to the SWU_Composite_Application_Tier
Note the indication of the CPU utilization. This is displayed because the value
for the display server utilization setting for the SWU_Application is set to True,
and the data acquisition engine variables controlling the data gathering are
defined for each tier.
As with the automatic operation mode, you can view the details of the server
and see that a new network interface in the 192.168.120.240/28 subnet is
allocated and the expected software installed.
242
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
13.2.6 Exercise: Using the manual operation mode
As you may have noticed, the Tivoli Intelligent Orchestrator has also issued a
recommendation to deploy a server to the SWU_Composite_Web_Tier because
the minimum number of servers is set to 1. However, because you defined the
operation mode for this tier as Manual, you are responsible for submitting the
deployment yourself. To do this, perform the following tasks:
1. Go to the SWU_Composite_Web_Tier (Figure 13-11), and enter the number
of servers you wish to deploy in the Overflow service input field in the middle
of the display. Try deploying two servers this time, and click Add. Click
Refresh.
Figure 13-11 Deploying servers manually
2. Note that two servers are chosen and the deployments have started
(Figure 13-12).
Figure 13-12 Manual deployment of two servers in progress
Chapter 13. Exercise 13: Deploying the composite application
243
3. Because the software stack used for the SWU_Composite_Web_Template
actually copies the files to the target servers, these deployments may take a
while. When you wait for this to complete, take a look at the
SWU_Pristine_Server_Pool that provides servers to all the tiers in the
SWU_Composite_Application, and notice the status of each of the servers
(Figure 13-13).
Figure 13-13 Server inventory during deployment
Pay attention to the icons for each server from which you can tell the status.
Also note that the CPU utilization is similar for the two servers that are already
deployed - and at a very high value. Remember that in the SWU tutorial
environment, all the servers are hosted by the same hardware. Therefore,
what you see is the total system utilization when the deployments are taking
place.
4. When the deployments are still taking place and the load on the provisioned
servers is high, you see new recommendations in the SWU_Application
Recommendations page. This is an indication that more servers are required
to support the expected load on the SWU_Composite_Application_Tier. No
recommendations are issued for the SWU_Composite_Database_Tier
because the maximum number of servers is set to 1, and one server is
already deployed.
244
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
5. After the deployment of servers to the SWU_Composite_Web_Tier is
completed, you can verify the deployment by navigating to Home Overview.
Note that the height of the columns representing the application tiers have
changed (Figure 13-14).
Figure 13-14 Datacenter overview with servers deployed
6. To verify whether the load balancer and the virtual IP updates that were
performed during the deployment to the SWU_Composite_Web_Tier, which
is the only tier associated with a virtual IP, open the www.swu.com virtual IP
definition by using the Find field at the top of the navigation pane. Note that
the IP addresses of the two servers have been added to the virtual IP.
7. For further verification, go to the desktop of the TIOServer system and check
the Load Balancer console. You should see that the two servers are allocated
to the cluster. When looking at the Load Balancer console, you may have
noticed that two SWU-n servers are allocated to both the www.swu.com and
the swu_composite_web clusters. This is an indication that the servers are
added as cluster nodes.
Chapter 13. Exercise 13: Deploying the composite application
245
8. To verify resource allocation, open the
SWU_Composite_Web_ClusterDomain (Figure 13-15), and expand both the
defined cluster nodes. Then, verify that both have two resources assigned to
them, one SWU site of type Software-Instance, and one SWUSite
ServerPages instance of type Software-Application-Data.
Figure 13-15 Deployed cluster resources
9. To verify the operation, locate the SWU Instances resource group and use
the Edit icon to the right in order to stop all the instances (Figure 13-16).
Figure 13-16 Starting and stopping the cluster resources
10.Go the TIOServer system, open the Services window, and verify whether the
two SWUSite@SWU…. Services have changed from Started to Stopped. It
may take a while before you see the change in the status.
11.Go back to the IBM Tivoli Provisioning Manager user interface and see how
the status of the resources has changed in the cluster domain window.
246
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
12.To see the total server allocation for the entire application, open the
SWU_Composite_Application, and go the Servers page (Figure 13-17). Here,
you see all the servers that are currently allocated to any tier that belongs to
the application. From this window, you have the option of removing the
servers from the tiers.
Figure 13-17 SWU_Composite_Application server allocation
13.Use the Edit icon to the right to release a server from the
SWU_Composite_Web_Tier (Figure 13-18), which is the only tier for which
this option is available. Because the other tiers are operating in the automatic
mode and the semiautomatic mode, you cannot manually add or remove the
servers.
Figure 13-18 Deprovisioning servers
14.After a while, verify the removal by ensuring the following:
– The cluster resources are unregistered
– The virtual IP associations are gone
– The definitions of services in the TIOServer Windows environment are
removed
– The software products are uninstalled
Chapter 13. Exercise 13: Deploying the composite application
247
– The server is returned to the SWU_Pristine_Server_Pool
– The network interfaces for the 192.168.110.240/28 subnet is deleted, both
from the DCM and from the Windows environment on the TIOServer
system
This concludes the IBM Tivoli Provisioning and Orchestration Provisioning
Composite Applications Workshop tutorial exercises.
248
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
A
Appendix A.
Additional material
This IBM Redpaper refers to additional material that can be downloaded from the
Internet as described here.
Locating the Web material
The Web material associated with this IBM Redpaper is available in soft copy on
the Internet from the IBM Redbooks Web server at:
ftp://www.redbooks.ibm.com/redbooks/REDP4222
Alternatively, you can go to the IBM Redbooks Web site at:
ibm.com/redbooks
Select Additional materials and open the directory that corresponds to the IBM
Redpaper form number, REDP4222.
© Copyright IBM Corp. 2006. All rights reserved.
249
Using the Web material
The additional Web material that accompanies this Redpaper includes the
following files:
File name
REDP4222.zip
Description
Archive of tcdrivers used in the exercises described in this
IBM Redpaper
System requirements for downloading the Web material
The following system configuration is recommended:
Hard disk space:
Operating Environment:
200MB minimum
TIO/TPM V3.1.2
How to use the Web material
To install the tcdrivers required to complete the exercises in this book, perform
the following tasks:
1. Download the REDP4222.zip file from:
ftp://www.redbooks.ibm.com/redbooks/REDP4222
2. Create a subdirectory (folder) on your workstation, and unzip the contents of
the Web material zip file into this folder. You will now have the following two
files in the directory where you unzipped the REDP4222.zip file:
– SWU_2006.tcdriver
– ITSO_Utilities.tcdriver
3. To make both the files available to your TIO/TPM environment, copy them to
the desktop of your TIO/TPM Server.
4. To install the tcdrivers in your TIO/TPM environment, follow the instructions
provided in 2.2.1, “Importing the tcdriver” on page 12.
250
Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1
Back cover
Composite Application
Provisioning with IBM Tivoli
Provisioning Manager V3.1
Understand the Tivoli
Provisioning
Manager software
model
This IBM Redpaper provides detailed how-to instructions for
creating a virtualized environment for the provisioning of
3-tiered composite applications using IBM Tivoli Provisioning
Manager V3.1 with the help of a 13-step walk through of the
activities required to reach your goal.
Automate the
creation of
virtualized resources
In addition, descriptions of the Tivoli Provisioning Manager
V3.1 software model is provided.
Control the
application clusters
This material is intended for IT professionals who specialize
in deployment of systems, middleware, and application
software to support on-demand production environments. A
basic understanding of networking, clustering techniques,
and the functions and features of Tivoli Provisioning Manager
V3.1 will greatly increase the benefits of studying this
material.
This IBM Redpaper is based on material that was originally
developed for a instructor-led workshop. However, it is the
hope of the IBM International Technical Support Organization
that publishing the material to a wider audience will be
helpful and provide guidance on the functions and use of
Tivoli Provisioning Manager V3.1, despite the workshop
environment not being available.
®
Redpaper
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
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