Composite Application Provisioning With IBM Tivoli Provisioning Manager V3.1 Redp4222

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 Orchestrators 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
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
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
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
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
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
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
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 environments 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
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
xv
xvi
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.
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
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.
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
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
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 Orchestrators 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
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
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.
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 Orchestrators 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. 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. 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
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
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.
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 systems 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
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 Quick find input field Quick find result pane Logoff Help Home Product and Session pane Content pane
Navigation 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
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.)
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 Orchestrators operational status and overview exercise. You can now import the workflows and the device drivers for the SWU environment.
10
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.
11

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
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
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
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
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 netview.dir netview.server Component Deployment Engine Deployment Engine Value c:/usr/ov TIOServer
4. From the Workflows page, assign the device driver called Discovery NetView.
18
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.
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
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
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
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.
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
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
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
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
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
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.
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
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.
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
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 Administrator Password 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
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
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
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
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.
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
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
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
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.
41

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
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
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 SWU_VLAN-001 SWU_VLAN-100 SWU_VLAN-110 SWU_VLAN-120 SWU_VLAN-130 VLAN 001 100 110 120 130 Subnet 192.168.1.0/24 192.168.1.100/28 192.168.1.110/28 192.168.1.120/28 192.168.1.130/28 Subnet mask 255.255.255.0 255.255.255.240 255.255.255.240 255.255.255.240 255.255.255.240 Blocked range 192.168.1.1 - 192.168.1.199 192.168.100.250 192.168.100.254 192.168.110.250 192.168.110.254 192.168.120.250 192.168.120.254 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.
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
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
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
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
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
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
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
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.
53

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

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
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
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.
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
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.
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
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
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 Capability type OS Capability name os.familiy Capability value Windows 2000 Server SP4
72
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.
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
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.
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
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,
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
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 PLACEHOLDER PLACEHOLDER INSTALLATION Name defaults response-file 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
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
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
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
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.
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
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.
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
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
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
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.
89
90
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.
91

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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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.
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
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.
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
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,
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
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
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
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
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
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
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
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.
119

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
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
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.
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
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
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
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.
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 database.family database.version Value DB2 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
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
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 packages 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
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.
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
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 stacks 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.
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
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.
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
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 servlet.version Value 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
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
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.
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 Software Definition Attribute name version vendor title description is-draft software-capability Value SWU IBM DB2 Client 8.2 8.2 IBM IBM DB2 Client 8.2 DB2 Client False name value software-capability name value supported-requirement-type DATABASE database.family DB2 Client database.version 8.2 Subattribute Value
140
Object Software Package
Attribute name is-device-model locale version priority file-repository status file name path software-requirement
Value
Subattribute
Value
SWU IBM DB2 Client 8.2 Simulated Installable SoftwareSimulator_SoftwareInstallable en_US 8.2 0 SWU_FileRepository tested
/ name type enforcement hosting accept-non-exi sting value os.family OS MANDATORY " true false Windows 2000 Server SP4"
Software Resource Template
name software-resource-type software-resource-device-mod el multiplicity-type software-configuration-type is-selected template-param
SWU IBM DB2 Client Installation INSTALLATION SoftwareSimulator_SoftwareInstallation Unspecified Regular true name value is-changeable InstallDir "C:/ibm/sqllib" true
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
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>
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
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.
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
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 defaults response-file HTTP Server Installation without default instance Intended use Helper template to set up defaults Helper template to create a response file for the HTTP Server installation Template for installation without instances to support raw installation or installation on the hosting platform
147
Software resource template name SWU HTTP Installation with...
Intended use 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. Templates used to control the configuration of the cluster domain for the HTTP servers
ClusterResource...
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
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
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
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
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
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
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
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.
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
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.
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
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.
159
160
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.
161

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
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
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.
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
layer software definitions on page 166, and review the automatically created definitions.
Table 9-1 SWU Composite Database Module software product definition Object Software Definition Attribute name version vendor title description is-draft software-capability Value Subattribute Value
SWU Composite Database Module 1.0 SWU SWU Composite Database Module for composite application database layer False name value software.name Composite Database software.version 1.0
software-capability
name value
167
Object
Attribute software-capability
Value
Subattribute name value
Value software.vendor SWU
supported-requirement-type software-requirement
APPLICATION name type enforcement Hosting Accept-non-existing value database.version DATABASE MANDATORY true false 8.2 database.family DATABASE MANDATORY true false DB2
software-requirement
name type enforcement Hosting Accept-non-existing value
Table 9-2 SWU Composite Database software package definition Object Software package Attribute name is-device-mod el locale version priority file-repository status file name Value Subattribute Value
SWU Composite Database Installable SoftwareSimulator_SoftwareInstallable" en_US 1.0 0 SWU_FileRepository tested
168
Object
Attribute path
Value /
Subattribute
Value
software-requirement
name type enforcement hosting accept-non-existing value
os.family OS MANDATORY true false Windows 2000 Server SP4"
Table 9-3 SWU Composite Database software resource template definition Attribute Software Resource Template INSTALLATION name software-resource-type software-resource-device-model multiplicity-type software-configuration-type is-selected template-param Value Subattribute Value
SWU Composite Database Installation INSTALLATION SoftwareSimulator_SoftwareInstallation Unspecified Regular true name value is-changeabl e InstallDir "C:/ibm/sqllib" true Database Instance INSTANCE SoftwareSimulator_SoftwareI nstance Unspecified Regular
INSTANCE
name software-resource-type software-resource-device-model multiplicity-type software-configuration-type
169
Attribute is-selected template-param
Value
Subattribute true name value
Value
resource-na me SWU Composite DB Module Database Instance true
is-changeabl e CONFIGURATION name software-resource-type software-resource-device-model Database Definition CONFIGURA TION SoftwareSim ulator_Softwa reResource Unspecified Regular true name value is-changeabl e APPLICATION_D ATA name resource-name
multiplicity-type software-configuration-type is-selected template-param
SWU Composite DB Module Database Definition true Database Data
170
Attribute software-resource-type software-resource-device-model
Value
Subattribute APPLICATIO N-DATA SoftwareSim ulator_Softwa reResource Unspecified Regular true
Value
multiplicity-type software-configuration-type is-selected template-param name value is-changeabl e
resource-name SWU Composite DB Module Database Data 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
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
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.
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
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.
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
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.
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
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.
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
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
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
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.
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
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.
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
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
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
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.
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
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.
191
192
10
Chapter 10.
Exercise 10: Defining the composite application load balancer and the virtual IP
193

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
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
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.
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
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
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 wes.clientGateway wes.commandLocation wes.returnAddress Component Deployment engine Deployment engine Deployment engine Value 192.168.100.254 /cygdrive/c/winnt/system32 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
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.
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
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 wes.clientGateway wes.commandLocation wes.returnAddress Component Deployment engine Deployment engine Deployment engine Value 192.168.100.254 /cygdrive/c/winnt/system32 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.
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
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.
205
206
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.
207

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 environments starting and ending points
208
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
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.
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
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 cpu-utilization.aggregation cpu-utilization.device cpu-utilization.filter cpu-utilization.metric server.driver Component Data acquisition engine Data acquisition engine Data acquisition engine Data acquisition engine Data acquisition engine Value average server low-pass-filter cpu-utilization 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
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
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.
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 Name Tier Number Managed By Intelligent Orchestrator Locale Resource Pool Overflow Servers Server Template ClusterDomain Value SWU_Composite_Application_Template 5 checked English SWU_Pristine_Server_Pool min: 1, max: 4 none 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 Attribute Name Owner NIC VLAN Association Value SWU_Composite_Application_Template SWU_Composite_Application_Tier SWU_VLAN-120
216
Attribute Interface Subnetwork Resource Pool Software Stack
Value 192.168.120.240/28 SWU_Pristine_Server_Pool 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 Name Tier Number Managed By Intelligent Orchestrator Locale Resource Pool Overflow Servers Server Template ClusterDomain Value SWU_Composite_Web_Tier 5 checked English SWU_Pristine_Server_Pool min: 1, max: 3 none none
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 Attribute Name Owner NIC VLAN Association Interface Subnetwork: Resource Pool Software Stack Value SWU_Composite_Web_Template SWU_Composite_Web_Tier SWU_VLAN-110 192.168.110.240/28 SWU_Pristine_Server_Pool SWU_Composite_Web_Stack
218
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.
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
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.
221
222
12
Chapter 12.
Exercise 12: Defining the cluster domain for the Web layer
223

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
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
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.
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
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
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
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.
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
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.
233
234
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.
235

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
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
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
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
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
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
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
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
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.
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
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
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
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.
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
Back cover

Understand the Tivoli Provisioning Manager software model Automate the creation of virtualized resources Control the application clusters
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. In addition, descriptions of the Tivoli Provisioning Manager V3.1 software model is provided. 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

Composite Application Provisioning With IBM Tivoli Provisioning Manager V3.1 Redp4222

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Composite Application Provisioning With IBM Tivoli Provisioning Manager V3.1 Redp4222

Uploaded by

Copyright:

Available Formats

Front cover

Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1

Copyright IBM Corp. 2006. All rights reserved.

Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1

Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1

Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1

Copyright IBM Corp. 2006. All rights reserved.

Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1

8-10 8-11 8-12 8-13 8-14 8-15 8-16 8-17 8-18

Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1

Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1

Copyright IBM Corp. 2006. All rights reserved.

Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1

Copyright IBM Corp. 2006. All rights reserved.

Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1

The objective of this workshop

Copyright IBM Corp. 2006. All rights reserved.

Figure 1 shows the end result of completing this tutorial successfully.

Figure 1 An overview of the tutorial

Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1

Figure 2 Sample architecture of a composite application

The technical environment of the workshop

Figure 3 The SWU tutorial environment

Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1

An outline of the exercises

Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1

Become a published author

Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1

Exercise 1: Introducing the IBM Tivoli Intelligent Orchestrator V3.1

Copyright IBM Corp. 2006. All rights reserved.

1.1 The objective of this exercise

1.2 Verifying the Tivoli Intelligent Orchestrator operations

1.2.1 Verifying the Tivoli Intelligent Orchestrators operational status

1.2.2 Logging in to the Tivoli Intelligent Orchestrator Server system

Figure 1-1 Starting VMware

Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1

Figure 1-2 The SWU2006-3759 VMware image

Chapter 1. Exercise 1: Introducing the IBM Tivoli Intelligent Orchestrator V3.1

Figure 1-3 The SWU2006-3759 desktop

1.2.3 Verifying the connectivity

Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1

1.2.4 Starting the Tivoli Intelligent Orchestrator Server

Figure 1-4 Starting the Tivoli Intelligent Orchestrator using TIO_Start

Chapter 1. Exercise 1: Introducing the IBM Tivoli Intelligent Orchestrator V3.1

Figure 1-5 Opening the Services window

Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1

1.2.5 Signing in to the Tivoli Intelligent Orchestrator console

Figure 1-6 Signing in to the Tivoli Intelligent Orchestrator

Chapter 1. Exercise 1: Introducing the IBM Tivoli Intelligent Orchestrator V3.1

Navigation pane Command input field

Figure 1-7 The Tivoli Intelligent Orchestrator console

Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1

Chapter 1. Exercise 1: Introducing the IBM Tivoli Intelligent Orchestrator V3.1

Figure 1-8 The Tivoli Intelligent Orchestrator help environment

Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1

Exercise 2: Preparing the environment

Copyright IBM Corp. 2006. All rights reserved.

2.1 The objective of this exercise

2.2 Importing the IBM Software University automation packages

2.2.1 Importing the tcdriver

Composite Application Provisioning with IBM Tivoli Provisioning Manager V3.1

Figure 2-1 SWU workflows

Chapter 2. Exercise 2: Preparing the environment