Professional Documents
Culture Documents
Edson Manoel John Aronis Ron Falciani Sebastien Fardel Aniruddha Parnaik
ibm.com/redbooks
International Technical Support Organization Introducing IBM Tivoli License Manager March 2003
SG24-6888-00
Note: Before using this information and the product it supports, read the information in Notices on page xvii.
First Edition (March 2003) This edition applies to Version 1.1 of IBM Tivoli License Manager. Note: This book is based on a pre-GA version of a product and may not apply when the product becomes generally available. We recommend that you consult the product documentation or follow-on versions of this redbook for more current information.
Copyright International Business Machines Corporation 2003. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii Chapter 1. Introduction to license management . . . . . 1.1 Software License Use Management requirements . . . 1.2 Asset Management and Asset Protection . . . . . . . . . . 1.3 License Use Management. . . . . . . . . . . . . . . . . . . . . . 1.4 License management system . . . . . . . . . . . . . . . . . . . 1.5 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ....... ....... ....... ....... ....... ....... ...... ...... ...... ...... ...... ...... ... ... ... ... ... ... 1 2 5 6 7 9
Chapter 2. IBM Tivoli License Manager general overview. . . . . . . . . . . . . 11 2.1 IBM Tivoli License Manager overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2 IBM Tivoli License Manager physical components . . . . . . . . . . . . . . . . . . 16 2.2.1 IBM Tivoli License Manager Master Catalog . . . . . . . . . . . . . . . . . . 19 2.2.2 Network communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2.3 Data flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3 IBM Tivoli License Manager logical components . . . . . . . . . . . . . . . . . . . 23 2.4 IBM Tivoli License Manager interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.4.1 Web interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.4.2 XML interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.5 Licence Management process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.5.1 Software entitlement process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.6 Example scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.6.1 Microsoft license management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.6.2 Oracle license management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.6.3 IBM Tivoli software license management . . . . . . . . . . . . . . . . . . . . . 45 Chapter 3. Implementation planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.1 Physical design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
iii
3.1.1 ITLM Administration Server considerations . . . . . . . . . . . . . . . . . . . 52 3.1.2 ITLM Runtime Server considerations . . . . . . . . . . . . . . . . . . . . . . . . 52 3.1.3 Scalability limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.1.4 Network considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.1.5 Security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.1.6 Hardware considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.1.7 File systems considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.1.8 Physical design example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.2 Logical design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.2.1 Naming convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.2.2 Customer considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.2.3 Division considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.2.4 Monitored Nodes considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.2.5 Administrator considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.2.6 Logical design example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.3 Disaster and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 3.3.1 Backup and restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 3.3.2 Failover considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 3.4 Planning for IBM Tivoli License Manager . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.4.1 Planning overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3.4.2 Planning for IBM DB2 Universal Database Enterprise Edition . . . . . 71 3.4.3 Planning for HTTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 3.4.4 Planning for Proxy server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 3.4.5 Planning for IBM WebSphere Application Server . . . . . . . . . . . . . . . 80 3.4.6 Planning for IBM Tivoli License Manager Administration server . . . . 86 3.4.7 Planning for IBM Tivoli License Manager Runtime Server . . . . . . . . 90 3.4.8 Planning for IBM Tivoli License Manager Agent . . . . . . . . . . . . . . . . 92 3.4.9 Planning for IBM Tivoli License Manager Catalog Manager . . . . . . . 96 Chapter 4. Getting IBM Tivoli License Manager up and running . . . . . . . 99 4.1 Example scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.2 Setting up the ITLM Administration server . . . . . . . . . . . . . . . . . . . . . . . 102 4.2.1 IBM DB2 Server installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 4.2.2 IBM DB2 Fixpack 7 installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 4.2.3 IBM WebSphere installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 4.2.4 IBM WebSphere Fixpack 4 installation . . . . . . . . . . . . . . . . . . . . . . 107 4.2.5 ITLM Administration server installation . . . . . . . . . . . . . . . . . . . . . . 108 4.2.6 Creating DB2 schema for Administration server on AIX . . . . . . . . . 113 4.2.7 Connecting DB2 database to Administration server on AIX . . . . . . 114 4.2.8 Setting up SSL configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 4.2.9 Setting up event notification for Administration server . . . . . . . . . . 117 4.3 Setting up the ITLM Runtime server on AIX . . . . . . . . . . . . . . . . . . . . . . 118 4.3.1 ITLM Runtime server installation. . . . . . . . . . . . . . . . . . . . . . . . . . . 119
iv
4.3.2 Creating DB2 schema for Runtime server on AIX. . . . . . . . . . . . . . 124 4.3.3 Connecting DB2 database to Runtime server on AIX . . . . . . . . . . . 125 4.3.4 Setting up event notification for Runtime server . . . . . . . . . . . . . . . 126 4.3.5 Registering Runtime server to the Administration server . . . . . . . . 128 4.4 Setting up the ITLM Runtime server on Windows . . . . . . . . . . . . . . . . . . 131 4.4.1 IBM DB2 Server installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 4.4.2 IBM DB2 Fixpack 7 installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 4.4.3 IBM WebSphere installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 4.4.4 IBM WebSphere Fixpack 4 installation . . . . . . . . . . . . . . . . . . . . . . 136 4.4.5 ITLM Runtime Server Installation . . . . . . . . . . . . . . . . . . . . . . . . . . 136 4.4.6 Creating database schema for Runtime server on Windows . . . . . 141 4.4.7 Setting up event notification for ITLM Runtime server . . . . . . . . . . 141 4.4.8 Registering Runtime server to the Administration server . . . . . . . . 142 Chapter 5. Administering IBM Tivoli License Manager . . . . . . . . . . . . . . 143 5.1 Case study: Physical design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 5.2 Analysis and planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 5.3 Infrastructure build and design process . . . . . . . . . . . . . . . . . . . . . . . . . 147 5.4 Test scenarios and pilot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 5.5 Case study: Logical design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 5.6 Managing Customers and administrators . . . . . . . . . . . . . . . . . . . . . . . . 150 5.6.1 Adding a Customer to the Administration server. . . . . . . . . . . . . . . 150 5.6.2 Creating and adding administrators accounts . . . . . . . . . . . . . . . . . 152 5.6.3 Updating or deleting administration account details . . . . . . . . . . . . 153 5.6.4 Creating administrator accounts on the Runtime server . . . . . . . . . 155 5.7 Managing IBM Tivoli License Manager components. . . . . . . . . . . . . . . . 156 5.7.1 Registering a Runtime server with the Administration server . . . . . 156 5.7.2 Creating Divisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 5.7.3 Deploying an Agent on a node . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 5.7.4 Scheduling an inventory scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 5.7.5 Adding application users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 5.8 Managing software entitlement and license pool . . . . . . . . . . . . . . . . . . 166 5.8.1 Gathering customer licensing and procurement information. . . . . . 166 5.8.2 Selecting a product for entitlement or license pool maintenance . . 167 5.8.3 Creating a license pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 5.9 Managing software product components . . . . . . . . . . . . . . . . . . . . . . . . 174 5.9.1 Updating the Master Catalog from the Unknown file table . . . . . . . 176 5.9.2 Importing new releases of the ITLM catalog . . . . . . . . . . . . . . . . . . 182 Chapter 6. Reporting with IBM Tivoli License Manager. . . . . . . . . . . . . . 185 6.1 ITLM pre-defined reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 6.1.1 ITLM Administration server reports . . . . . . . . . . . . . . . . . . . . . . . . . 186 6.1.2 ITLM Runtime Server report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Contents
Tivoli Data Warehouse integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Tivoli Data Warehouse overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Tivoli Data Warehouse concepts and components . . . . . . . . . . . . . . . . . 212 ITLM and TDW integration components . . . . . . . . . . . . . . . . . . . . . . . . . 215 Installation and configuration for TDW integration . . . . . . . . . . . . . . . . . 217 6.6.1 ITLM Warehouse enablement pack installation . . . . . . . . . . . . . . . 217 6.6.2 ITLM Warehouse enablement pack configuration. . . . . . . . . . . . . . 221 6.7 TDW reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 6.7.1 Accessing the reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 6.7.2 Reports available with IBM Tivoli License Manager . . . . . . . . . . . . 231 Chapter 7. Performance maximization techniques . . . . . . . . . . . . . . . . . 235 7.1 Initial considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 7.2 IBM DB2 Performance tuning considerations . . . . . . . . . . . . . . . . . . . . . 239 7.2.1 Small ITLM environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 7.2.2 Medium ITLM environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 7.2.3 Large ITLM environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 7.3 IBM WebSphere performance tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 7.4 IBM HTTP Server performance tuning . . . . . . . . . . . . . . . . . . . . . . . . . . 246 7.5 ITLM components performance considerations . . . . . . . . . . . . . . . . . . . 247 7.6 Operating system performance tuning . . . . . . . . . . . . . . . . . . . . . . . . . . 251 7.6.1 Windows environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 7.6.2 AIX environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Appendix A. ITLM Agent installation using IBM Tivoli Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Software Package structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Software Package variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Software Package version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Software Package definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Installation script structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Agents definition file structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 Appendix B. SSL key creation for IBM Tivoli License Manager . . . . . . . 275 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Creating the SSL key files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Creating the server certificate file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Creating the key trusted store file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Appendix C. IBM Tivoli License Manager databases. . . . . . . . . . . . . . . . 281 The ITLM Administration server database . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 The ITLM Runtime server database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Appendix D. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
vi
Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 System requirements for downloading the Web material . . . . . . . . . . . . . 290 How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Contents
vii
viii
Figures
2-1 2-2 2-3 2-4 2-5 2-6 2-7 2-8 2-9 3-1 3-2 3-3 4-1 4-2 4-3 4-4 4-5 4-6 4-7 4-8 4-9 4-10 4-11 4-12 4-13 4-14 4-15 4-16 4-17 4-18 4-19 4-20 4-21 4-22 5-1 5-2 5-3 5-4 Software licensing requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Software licensing solution: IBM Tivoli License Manager . . . . . . . . . . . 15 Three-tiered client/server architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 17 IBM Tivoli License Manager physical components . . . . . . . . . . . . . . . . 18 IBM Tivoli License Manager logical components . . . . . . . . . . . . . . . . . . 24 IBM Tivoli License Manager software entitlement process . . . . . . . . . . 33 IBM Tivoli License Manager license pool process . . . . . . . . . . . . . . . . . 35 IBM Passport Advantage relationship volume price band level . . . . . . . 47 IBM Passport Advantage aggregation example. . . . . . . . . . . . . . . . . . . 48 IBM Tivoli License Manager physical design example . . . . . . . . . . . . . 58 IBM Tivoli License Manager logical design example . . . . . . . . . . . . . . . 64 Planning overview for IBM Tivoli License Manager . . . . . . . . . . . . . . . . 70 ITLM installation scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Install DB2 V7 - DB2 UDB Enterprise Edition . . . . . . . . . . . . . . . . . . . 103 Create DB2 Services - DB2 Instance db2inst1 . . . . . . . . . . . . . . . . . . 103 Administration Server screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 IBM WebSphere Application Server configuration window . . . . . . . . . 106 IBM WebSphere Application Server Admin console . . . . . . . . . . . . . . 109 Installation type: Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Confirmation of installation options Administration server. . . . . . . . 111 Administration Server in WebSphere Administration Console . . . . . . . 112 Add host alias for port 443 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Type of installation: Runtime server. . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Runtime server installation details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Runtime server communication options . . . . . . . . . . . . . . . . . . . . . . . . 122 Confirmation of installation options Runtime server . . . . . . . . . . . . 123 Tivoli Runtime server in WebSphere administration console. . . . . . . . 124 Select customer to register a Runtime server . . . . . . . . . . . . . . . . . . . 128 Register first Runtime server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Runtime server form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Server is registered (plugged in) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Select DB2 Enterprise Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Confirmation of installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Runtime server in WebSphere administration console . . . . . . . . . . . . 140 Typical implementation scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Creating a customer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Providing customer details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Creating a customer/license administrator account . . . . . . . . . . . . . . . 153
ix
5-5 5-6 5-7 5-8 5-9 5-10 5-11 5-12 5-13 5-14 5-15 5-16 5-17 5-18 5-19 5-20 5-21 5-22 5-23 6-1 6-2 6-3 6-4 6-5 6-6 6-7 6-8 6-9 6-10 6-11 6-12 6-13 6-14 6-15 6-16 6-17 6-18 6-19 6-20 6-21 6-22 6-23 6-24
Updating an administration account. . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Runtime server administrator account details . . . . . . . . . . . . . . . . . . . 155 Registering a Runtime server on the Administration server. . . . . . . . . 157 Registering the Runtime server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Shows the status of the Runtime server . . . . . . . . . . . . . . . . . . . . . . . 159 Adding the Division details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Deploying an Agent on a node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Sample Agent deployment communication letter. . . . . . . . . . . . . . . . . 163 Enter the details for the inventory scan . . . . . . . . . . . . . . . . . . . . . . . . 165 Creating a software entitlement setting for a product . . . . . . . . . . . . . 168 Selecting details of the entitlement settings . . . . . . . . . . . . . . . . . . . . . 169 Provide details for the license pool . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Setting distribution parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 IBM catalog manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Searching the unknown file table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Details to create a new software product . . . . . . . . . . . . . . . . . . . . . . . 180 Information on the new software product . . . . . . . . . . . . . . . . . . . . . . . 181 Select the file to import and update the Master Catalog . . . . . . . . . . . 182 Begin the process to update the Master Catalog . . . . . . . . . . . . . . . . . 183 Parameters for historic snapshot -1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Parameters for historic snapshot -2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Historic snapshot report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Historic snapshot - product / license details - 1 . . . . . . . . . . . . . . . . . . 190 Historic snapshot - product / license details - 2 . . . . . . . . . . . . . . . . . . 191 Historic snapshot - product / license details - 3 . . . . . . . . . . . . . . . . . . 192 Parameters for trend analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Parameters for trend analysis - 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Trend analysis report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Trend analysis report parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Parameters for level analysis - 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Parameters for level analysis - 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Parameters for level analysis - 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Level analysis report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Parameters for software inventory - 1 . . . . . . . . . . . . . . . . . . . . . . . . . 201 Parameters for software inventory - 2 . . . . . . . . . . . . . . . . . . . . . . . . . 203 Software inventory report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Parameters for real-time report - 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Parameters for real-time report - 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Real-time report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Details of software In Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Section of Real-time report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Section of Real-time report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 A typical Tivoli Data Warehouse environment . . . . . . . . . . . . . . . . . . . 213
6-25 6-26 6-27 6-28 6-29 6-30 6-31 6-32 6-33 6-34 6-35 6-36 6-37 6-38 6-39 6-40 7-1 7-2 7-3 A-1 A-2 C-1 C-2
IBM Tivoli License Manager warehouse environment . . . . . . . . . . . . . 216 Path to the installation media for the COD. . . . . . . . . . . . . . . . . . . . . . 219 IBM Tivoli License Manager warehouse pack installation . . . . . . . . . . 220 Installation summary window ITLM warehouse enablement pack . 220 IBM Tivoli License Manager Source ETLs . . . . . . . . . . . . . . . . . . . . . . 223 COD_TLMA_Source user ID information. . . . . . . . . . . . . . . . . . . . . . . 223 IBM Tivoli License Manager Target ETLs . . . . . . . . . . . . . . . . . . . . . . 224 COD_TWH_CDW_Target user ID information . . . . . . . . . . . . . . . . . . 225 Schedule COD_m05_Populate_Mart_Process . . . . . . . . . . . . . . . . . . 226 Schedule configuration for COD_m05_Populate_Mart_Process . . . . . 226 Promoting scheduled processes to production status . . . . . . . . . . . . . 227 Logging on to the IBM Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 IBM Console report menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Report list for IBM Tivoli License Manager . . . . . . . . . . . . . . . . . . . . . 232 Summary report: Products Installed by Division . . . . . . . . . . . . . . . . . 233 Extreme case Report: ITLM Agents Installed by Division . . . . . . . . . . 234 ITLM implementation for small environment . . . . . . . . . . . . . . . . . . . . 236 ITLM implementation for medium environment . . . . . . . . . . . . . . . . . . 237 ITLM implementation for large environment . . . . . . . . . . . . . . . . . . . . 238 Software Package for ITLM Agent installation . . . . . . . . . . . . . . . . . . . 255 Software Package variables definition . . . . . . . . . . . . . . . . . . . . . . . . . 257 ITLM Administration server database schema. . . . . . . . . . . . . . . . . . . 285 ITLM Runtime server database schema . . . . . . . . . . . . . . . . . . . . . . . 288
Figures
xi
xii
Tables
2-1 2-2 2-3 2-4 3-1 3-2 3-3 3-4 3-5 3-6 3-7 3-8 3-9 3-10 3-11 3-12 3-13 3-14 C-1 C-2 Select License 6.0 price level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Software entitlement example for Microsoft Excel . . . . . . . . . . . . . . . . . 41 Software entitlement example for Oracle Database Enterprise Edition . 45 Software entitlement example for IBM Tivoli Configuration Manager . . 49 Planning for Administrator definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Hardware requirements IBM DB2 UDB Enterprise Edition . . . . . . . . 72 Software requirements IBM DB2 UDB Enterprise Edition . . . . . . . . . 73 DB2 network ports for UNIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 DB2 network ports for Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Hardware requirements for IBM WebSphere Application Server . . . . . 81 Software requirements for IBM WebSphere Application Server . . . . . . 82 WebSphere network ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Hardware requirements for ITLM Administration server . . . . . . . . . . . . 87 Software requirements for ITLM Administration server. . . . . . . . . . . . . 87 IBM Tivoli License Manager Administration server network port . . . . . . 89 IBM Tivoli License Manager Runtime server network port . . . . . . . . . . 90 Hardware requirements for IBM Tivoli License Manager Agent . . . . . . 93 Software requirements for IBM Tivoli License Manager Agent . . . . . . . 94 TLMA database tables for the ADM schema . . . . . . . . . . . . . . . . . . . . 282 TLMR database tables for the RTM schema . . . . . . . . . . . . . . . . . . . . 286
xiii
xiv
Examples
4-1 5-1 5-2 5-3 7-1 7-2 A-1 A-2 A-3 B-1 B-2 Changes in the httpd.conf file for UNIX environment . . . . . . . . . . . . . . 115 Setting up the ITLM CLI environment . . . . . . . . . . . . . . . . . . . . . . . . . 176 The expcat command output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 The impcat output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 httpd.conf parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Changes in the system.properties file . . . . . . . . . . . . . . . . . . . . . . . . . 250 Software Package definition for ITLM Agent installation . . . . . . . . . . . 259 Installation script for ITML Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Definition file for the ITLM Agent installation . . . . . . . . . . . . . . . . . . . . 273 SSL key files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Server certificate file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
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 illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces.
xvii
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: AIX 5L AIX Balance CT DB2 Universal Database DB2 eServer IBM IBM eServer Lotus Notes Lotus Notes Perform Redbooks Redbooks (logo) RS/6000 SLC SP SP1 SP2 Tivoli Enterprise Tivoli TME WebSphere XT z/OS
The following terms are trademarks of other companies: ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC. Other company, product, and service names may be trademarks or service marks of others.
xviii
Preface
One of the main portions of the investment required to set up an IT infrastructure now is related to software. The software Asset Management process is becoming more and more important. From a business point of view, this process includes tasks, such as software and vendor evaluation, contract negotiation, budget planning, hardware compliance analysis, software life cycle planning, and software monitoring. There is a need to know exactly what software is installed within the enterprise and, more importantly, how this software is being utilized within the IT infrastructure. Sometimes, enterprises buy corporate licenses, even though the licenses are procured for some specific divisions and wont be used by the rest of the enterprise. Often, organizations are overbuying licenses so as not to expose the enterprise to the risk of non-compliance usage of software products, simply because they are not able to prove or to evaluate how many licenses they really need or use. The license procurement information must be properly reconciled with the software usage and inventory data. This is the only way an enterprise can tell whether it is paying more license fees than necessary or whether it should buy new licenses to be compliant with the product license policies. Currently, many software vendors leave the responsibilities of licence management to enterprises that buy the products. They often dont provide technical support to maintain or apply the product license policies. Furthermore, the organizations have to prove that they are not using more licenses than they are authorized to. IBM Tivoli License Manager offers a technical way to control and apply the software vendors pre-defined licensing policies. It allows the Administrator to easily manage different products in different ways, reflecting the rules of each product license agreement. The primary objective of this redbook is to introduce the new IBM offering for designing and creating a license management solution, and it is targeted at the technical professional responsible for providing license management services in an IT organization. It can be used as a reference book for the deployment of IBM Tivoli License Manager Version 1.1, guiding you during the planning, installation, configuration, administration, tuning, and general product usage phases, focusing on how to effectively deploy this product in a way that quickly generates real business value for customers.
xix
This redbook is a valuable addition to the existing product documentation and should be read in conjunction with the official product documentation, which complements the concepts explained in this book.
xx
The team would like to express special thanks to Domenico Di Giulio, Software Engineer - IBM Rome, for his major contribution and support to this book. Thanks to the following people for their contributions to this project: Joanne Luedtke, Lupe Brown, Wade Wallace, Chris Blatchley, and Budi Darmawan IBM Austin, International Technical Support Organization Gabrielle Velez IBM Rochester, International Technical Support Organization Sandra Freudenberg IBM Boulder, IGS SDTC Pierre-Andr Schranz IBM Switzerland Terry Paul, Murray Taylor, James Jones, Paul Jacobs, Yang Fan, Carolanne Graham, Jayne Muise-Brown IBM Canada Ulrik Soerensen IBM Denmark Carlo Romano IBM Rome David Ertl ITLM Product Manager, IBM Austin
Preface
xxi
Comments welcome
Your comments are important to us! We want our Redbooks to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways: Use the online Contact us review redbook form found at:
ibm.com/redbooks
Mail your comments to: IBM Corporation, International Technical Support Organization Dept. JN9B Building 003 Internal Zip 2834 11400 Burnet Road Austin, Texas 78758-3493
xxii
Chapter 1.
To help put the topic in perspective, the following materials in this section are excerpted from A Requirement for Software License Use Management, which are copyrighted in the License Use Management Project of GUIDE International Corporation, August 29, 1996 , and are included herein with the express permission of the copyright holder: The key factors driving the need for comprehensive license use management are: Escalating software costs The high administrative burden of license compliance control The lack of effective customer control over the use of software Customers must deal with multiple products, from multiple software suppliers, on multiple platforms, with multiple licensing models. Given the exponential growth in complexity, there is a clear requirement for an overall framework for license use management that is: Extensible, flexible and comprehensive Independent of software supplier Independent of platform Independent of operating environment Independent of implementation Adaptable to future technologies
License use management tools, processes, products, and systems must: Meet the needs of both customers and software suppliers Be cost-effective for both customers and software suppliers Provide facilities to define license terms and conditions Record and report use level data Determine, report on, and verify compliance to license terms
Allow customers to control and optimize the use of licenses within the terms and conditions of the license policy Customers and software suppliers agree that software charges should directly correspond to the value or expected value of the software. There is, however, no single universal value metric or way of measuring value. The value metric will differ from product to product and even from customer to customer. In addition, software suppliers are entitled to a fair return on their investments and require assurance that their software assets are protected against intentional and unintentional misuse.
This problem is illustrated in the following example: A customer has a mobile workforce where each member has the capability of selecting the software best suited for the territory. All software is acquired and controlled centrally. This results in hundreds of software licenses that must be managed, involving management of keys, if required, and running tallies of the number of licenses to take advantage of discounts. The implementation of license use management tools and processes is key to the customer in a decentralized, multiple platform environment.
Administrative burden: Customer X supplier
Customer Perspective Use staff to develop applications, not tools Capture all data from all applications on all platforms from all software suppliers within a single framework Select applications on the merit of the application and not if it fits into the existing license management tool Cost-effective customer managed use Software Supplier Perspective Use staff to focus on core business competencies Reduced infrastructure required to support keys and product registration Increased probability that customers will acquire the appropriate number of licenses (or authorizations)
Enhanced interoperability
Customers are faced with heterogeneous, distributed computing environments that challenge their ability to monitor and control the use of licensed software. They need the ability to capture use level data to facilitate product acquisition justification, planning and budgeting for software, implementation of charge-back systems to recover software costs, and workload balancing. They also need the ability to ensure that their use of software products complies with license terms and conditions. For example, a customer has hardware servers from two different suppliers installed at two locations at corporate headquarters. This customer has acquired licenses for 150 users of a software product. Performance on one of the servers has been slow, resulting in multiple user complaints. Without access to use level data, the customer is unaware that 125 users are using the server that has the noted performance problems and only 50 users are accessing the other server. The customer is also unaware that 175 users, which is 25 users beyond the entitled number, are using the application. With the capture of and access to use level data, the customer will have the data necessary to charge the appropriate departments for usage, to balance the workload, and to fairly compensate the software supplier for use.
agreed contractual entitlements. This would typically be managed or controlled through license management tools. The basic challenge to balance both the customers' and the vendors' needs is the need to bridge between contractually defined entitlement levels and the real physical customer IT environments, where actual license deployment and use takes place. This ideally implies on one side a basic requirement for detailed, well-maintained record of entitlements, inventory and use for the customer, and on the other side the presence of license management tools in the customers' IT environment capable of monitoring and counting in a way reflecting the contractually defined rules.
Adding assurance that intellectual property is protected and that software licenses are used within entitled limits Enabling software family packaging and supply before buy merchandising Potentially reducing software distribution costs Regarding license use management, generally IBM's announced direction is to implement self-compliance, that is, Customer Managed Use for IBM-owned use-based priced software products, whereby a customer will not need to request a use-key from IBM which controls the use-levels for which the customer is licensed (a process and license management tool capability known as vendor managed use). During an enrollment process the customer administrator is asked to enter the overall licensed use-level for each product and then the customer can track product use with the license management system by using the administrative tools supplied. Other software contains the ability to communicate product use with the license use management system, allowing a customer to be able to receive information about the licenses used (for example, the number of users or number of resources used or managed) by these products. Changes and/or usage data is logged in special files, which can be used for internal and external audit purposes. A customer can also use the license use management administrative tools to receive reports of use and compare this information to the use levels that have been licensed. As a result customers are able to take action to either increase or decrease product use and license use payments to their suppliers.
management system informs the product of the status; and the product, in an ideal implementation, executes accordingly. The license management system does not directly effect the product execution. It is the product that decides to execute or not, based on information received from the license management system and the license management policy of the vendor. Relevant data is then logged to allow effective customer management and audit capability. Within that context, the following brief descriptive terms are commonly used:
Vendor policies
These policies can be categorized as follows: Customer Managed Use (CMU) This vendor policy requires the customer to set the entitlement against which the license management system will manage compliance. This policy allows two types of implementation, hard and soft compliance. Vendor Managed Use (VMU) Vendors provide customers with product keys reflecting the customer entitlement, against which the license management system will manage compliance. This policy has only one implementation hard compliance. The purpose is vendor asset protection, affording the customer no latitude in managing the installation.
Compliance
Various approaches may be perceived in achieving customer compliance: Trust Completely trust the customer to manage without tools. Soft The customer is provided tools to manage by warning if an (often self-declared) entitlement level is exceeded. An audit trail is established through a secure, audit log of all relevant events. Hard The customer, through use of license management tools, is precluded from non-compliant use. Hard and soft compliance are implemented in the same way with respect to the license management system, which simply determines whether a requested use authorization is within the stated entitlement. It is the reflection of the vendor policy (hard or soft compliance) within the application product being managed that dictates whether the product will execute or not, based on the response from the license management system to the request to execute. Therefore, with Hard
compliance, if the requested execution exceeds the entitlement, the product will not go into execution. If, on the other hand, the vendor policy is Soft compliance, under the same circumstance, the product will go into execution anyway and inform the license system of this fact for logging in its audit database.
1.5 Conclusion
In any definition of asset protection schema and related license management policies, a number of factors should be considered. The challenge for the vendor is to achieve the optimal balance between maximizing revenue recovery against both the administrative cost for the vendor and the potential customer satisfaction impacts due to cost, operational burden, and perceived intrusion. In addition, the balance must consider practical aspects of the business models, such as requirements on vendor operational processes, availability and quality of collected data, rolls of the Business Partners, and the competitive environment. Care must be taken to ensure that any attempt to eliminate software product over-use (willful or overt) will likely require implementation of additional control measures that are not only costly but will also be likely to place an unwarranted burden on all customers. Compliance enforcement should also serve to protect the interests of the compliant customer, and should not willingly favor the non-compliant customer. Another basic parameter to consider is customer and business partner satisfaction. The customer satisfaction considerations for a given compliance enforcement schema will need to include both tangible factors, such as the administrative burden and potential operational limitations imposed, but also less tangible factors, such as the potential perception of a scheme as being intrusive or spying" on the customer. For some customers imposing any level of license management discipline, however reasonable from a vendor's view, might be perceived as painful; while for others, the technical personnel making, for instance, operational capacity allocations potentially affecting software compliance may not be those that manage software entitlements or acquisitions. The compliance enforcement schema therefore needs to be sufficiently robust to cover the great span in the (broad) customer base in terms of business processes and organization, technical capabilities, and particular license management practices. Further, the vendor's asset protection process requirements imposed on the customer need to be balanced as to appear reasonable and a logical component of the over-all business model and the benefits the customer receives from it. A strong logical correlation to the business model will also alleviate at least the rational concerns over potential vendor "spying."
With the advent of IBM Program License Agreement (IPLA), software terms and conditions and pricing models are geared to reflect more directly the customer-perceived value of software, together with capacity-on-demand hardware for distributed systems products. As in the case of z/OS and Workload License Charges (WLC), the dynamic aspect of software execution and pricing demands a consistent, easy-to-use, cross-platform license management tool. The IBM direction to fulfill this quintessential business need is IBM Tivoli License Manager. Ultimately, the customer will be looking for value in terms of help to manage over-all software costs; a successful schema and tool set must therefore provide support for the customer's own asset management processes while ensuring the vendor's asset protection. It is with this intent that IBM Tivoli License Manager is offered.
10
Chapter 2.
11
12
4
The IT Operator starts making an Inventory but as the Software is installed on all machines, the IT Operator requests 100 licences because he could not control how many license are used concurrently. IT Operator
1
There is a need to buy the new version of the CSI HR Software
6
The IT Manager signs the license contract for 100 licenses.
3
The IT Administrator asks the IT Operator to count the number of required licenses for this new version. 80 users in the Financial Division
The IT Administrator, based on the information of the IT Operator, requests 100 licenses.
2
IT Manager
The IT Manager asks the IT Administrator for the number of required licenses for this new version.
IT Administrator
IBM Tivoli License Manager (ITLM) can help enterprises meet the software assets management objectives by accomplishing, often silently, a certain number of tasks described as follows: Collecting information about installed products using an inventory scan technology. Identifying the start and the stop of a software on any machines. Comparing the installed, used and procured licenses. Metering software usage even for products that have no license requirements. Informing Administrators when license usage reaches a defined level. Enforcing license agreements by refusing to start a application in case there are no licenses available. Assigning pool of licenses to users and/or machines.
13
Maintaining a historical software usage information and providing reports allowing the planning of license needs. Providing real-time reports for inventory and software usage information. Continuing with our example using the ACME enterprise, as shown in Figure 2-2, one year has past since ACME enterprise acquired the CSI HR software and now, it is time to negotiate the maintenance contract for this software. The maintenance pricing policy is still based on the number of concurrent users. During the past year, ACME enterprise has deployed the IBM Tivoli License Manager solution. Using this technology, the IT Administrator doesnt need to ask the IT Operator to make an inventory, because IBM Tivoli License Manager makes it automatically. Furthermore, as IBM Tivoli License Manager is able to analyze the start and the stop of software, the IT Administrator analyzes, within the reports provided by IBM Tivoli License Manager, that the average of the concurrent users is 45. So, the maintenance contract could be signed for only 45 licenses instead of 100. This way, ACME enterprise has saved the cost of 55 licenses that have never been used.
14
ITLM collects usage of CSI HR using inventory information and Software entitlement.
5
ITLM stores all information in a RDBMS and can provide historical or/and realtime reports.
1
It is time to negotiate the maintenance contract for the 100 licences of CSI HR Software
7
The IT Manager could negotiate the maintenance contract for only 45 licenses instead of 100.
3
The IT Administrator defines the Software entitlement in ITLM for CSI HR.
6
The IT Administrator reads in the report that only 45 licenses are concurrently used.
IT Manager
The IT Manager asks the IT Administrator if the 100 licenses are still needed.
IT Administrator
An IBM Tivoli License Manager solution can be seen as a three part solution: IBM Tivoli License Manager Components IBM Tivoli License Manager Software Entitlement IBM Tivoli License Manager Reports
15
16
Tier 3
Tier 2
Tier 1
DB2 RDBMS
Agents (Clients)
Runtime server (Application server) DB2 RDBMS (Resource) Administration server (Resource Manager)
DB2 RDBMS
Agents (Clients)
Agents (Clients)
Agents (Clients)
The IBM WebSphere Application Server provides the middle tier in this architecture, allowing clients to interact with data resources as a Relational Database Management System (RDBMS). IBM WebSphere Application Server is an environment for open distributed computing. Users and processes on a wide variety of platforms can interact by using the facilities provided by WebSphere. Both the IBM Tivoli License Manager Administration and Runtime servers are applications running on top of IBM WebSphere Application Server. These applications consist of object-oriented business logic that use a RDBMS for data storage. An application running on IBM WebSphere Application Server consists of the following components, each performing a different function: HTML and JSP pages providing the user interface and program flow. Enterprise beans containing the applications business logic that handle transactional operations and access to databases. Servlets coordinate work between the other components of the application. They also can dynamically generate Web page contents. JavaBean components enable the other types of components to work together.
17
Relational Databases implement persistence and query functions for enterprise beans. In the context of IBM Tivoli License Manager, the RDBMS is provided by IBM DB2 Universal Database Enterprise Edition. Figure 2-4 shows you the complete IBM Tivoli License Manager physical architecture and components. In addition to that, it also describes the complete data flow between the components of each tier as well as between the internal component of the IBM Tivoli License Manager Administration and Runtime servers.
Web Browser B M N
Web Browser
HTTP
C E G I K D H J O
HTTP Server WebSphere Plugin HTTP(s) IBM WebSpere Application Server Administration Server JDBC IBM DB2 WAS40 ITLM Administration server TLMA JDBC
HTTP Server WebSphere Plugin HTTP(s) IBM WebSpere Application Server Runtime Server JDBC IBM DB2 WAS40 ITLM Runtime server TLMR JDBC Agent
ITLM Agent
Master Catalog
Runtime Catalog
Agent Catalog
18
Support applications
As shown in Figure 2-4 on page 18, the IBM Tivoli License Manager solutions are composed of the following support applications: HTTP Server IBM WebSphere Application Server IBM DB2 Universal Database Enterprise Edition An IBM Tivoli License Manager solution mainly uses HyperText Transfer Protocol (HTTP) for its communications. In some cases, HTTPs, which is a secure HTTP, can be used to secure the communication between the Administration server and the Runtime server. The communication among the Web Browsers and the Administration and Runtime servers can also be encrypted. However, there is no possibility of using HTTPs to secure the communication between Agents and Runtime servers. The HTTP requests made by an Agent or by a Runtime server are first received by an HTTP server which must be installed on each Administration and Runtime
19
server. The HTTP server must forward the HTTP request either to the Administration Application server if the request is issued by a Runtime server or to the Runtime Application server if the request is issued by an Agent. To allow such transfer, the IBM WebSphere Application Server application installs a WebSphere plug-in on the HTTP server. This plug-in is able to transfer the HTTP request to the IBM WebSphere Application Server. The following link provides more information about the WebSphere plug-in:
http://www7.software.ibm.com/vadd-bin/ftpdl?1/vadc/wsdd/pdf/presents/WS40ST08.p df
IBM Tivoli License Manager Administration and Runtime servers, as well as the IBM WebSphere Application Server Administration server need to store data in a RDBMS. To access this RDBMS, IBM WebSphere Application Server uses the Java DataBase Connectivity (JDBC) technology. The following link provides more information about JDBC:
http://java.sun.com/docs/books/tutorial/jdbc/
20
and Runtime server, there are separate communication services used to update information of different types. The update rates could be configured on the Runtime server and are common for all Agents connected to the same server. After an inventory scan, upcalls are made by Agents to the Runtime server in order to store the result of the scan.
C D
21
Unknown. This information can later be used to update the Master Catalog. F The Runtime server then performs an update request to upload new Agents registration and Agents inventory information. The update rate for each service can be configured on the Runtime server. Every so often, the Agent performs an update request to know if there is something to download from the Runtime server. The update rate for each service is configured on the Runtime server. The Runtime server downloads all updates, if any, to the requesting Agents. If a new version of the ITLM Agent code is available, it will be automatically downloaded and installed on the requesting Agents at this time, depending on configuration of the Runtime server. Whenever an application is started on the Agent, the Agent informs the Runtime server about the software usage and performs, depending on configuration of the License control in the License pool, a License request. This operation happens even if the application is not part of the Catalog. With this information, the Runtime server has the control, in Real Time, of the software usage in all Agents. The Runtime server responds to the License request and depending on configuration, decides whether the application is allowed to run on the Agent or not. Whenever an application is deployed/installed on the machine where the ITLM Agent is running, the Agent informs the Runtime server about the new software release. Runtime server will send this information back to the Administration server at regular intervals. Every so often, the Runtime server performs an update request to find out if there is something to download from the Administration server. The update rate for each service is configured on the Runtime server. The Administration server then downloads all the updates, if any, to the requesting Runtime server. Every so often, the Administration server informs all Runtime servers that an update of the Licensing information, is available for download. This is the only case where the Administration server contacts the Runtime servers. After receiving the notice from the Administration servers, Runtime servers trigger a new call to download Licensing information without waiting for the next scheduled request.
M N
22
23
version, and so on. It is the starting point of software monitoring, because you can decide to get statistics of a specific software usage or to strictly apply licensing rules to force the appliance of business licensing requirements. These rules are defined in the license pools which are part of the software entitlement logical component. Licence pools can only be applied to a specific software entitlement and can not be used as reference for others entitlements. Figure 2-5 provides you with an overview of all ITLM logical components and the links between them.
Administration server
Administrator
Customer
End Users
Agents
Administration server
An IBM Tivoli License Manager environment can only have a single Administration server. This server is the core of the solution and works as the central arbitrator within the license management strategy. It can manage more than one
Administration server
24
Customer and therefore is not part of a Customers topology, as seen in Figure 2-5 on page 24. This server provides the following functions: Stores and maintains the available information about products catalog, license agreements, license usage, license pool and Customer information in a central repository organized by Customer. Gathers the software usage and installation data collected by the Agents and processed by the Runtime server. Provides a Web interface that can be used to perform administration tasks and produce historical reports of license usage and nodes inventory over time. Forwards e-mail notifications to the licenses administrators upon detection of unlicensed usage of software products and/or information about the status of the Administration server itself. Section 3.1.1, ITLM Administration Server considerations on page 52 provides information on planning the deployment of ITLM Administration servers.
Runtime server
An IBM Tivoli License Manager environment must have at least one Runtime server but more servers can be set up to scale the solution and cover large sites. They are managed directly by the Administration server and they are in charge of the Agents registration process and Agents License Runtime server request. Furthermore, a Runtime server can only be attached to one Customers Topology and therefore only manages the Agents of this Customer. So, a Runtime server is a part of the Customers topology. Each Runtime server provides the following functions:
Receives the results of software scans from the Agents and processes them to build a view of the software installed on each machine. Assigns, releases or blocks at run time the licenses that have been distributed to the server, according to the rules defined by the license procurement information. Monitors the activity of the Agents, notifying the system administrator when an Agent has been stopped or removed from the system. Provides a Web interface that can be used to produce real time reports of license usage. Forwards e-mail notifications to the licenses Administrator upon detection of events that have occurred on the server and its Agents. Section 3.1.2, ITLM Runtime Server considerations on page 52 provides information on planning the deployment of ITLM Runtime servers.
25
Agents
An Agent is a part of the Customers Topology. A small agent footprint must be deployed on each of the Customer machines that are to be monitored by IBM Tivoli License Manager. Agents provide the primary interface of License Agents management. Agents run a very small amount of software, less than 400 Kb of executable on all platforms. Each Agent performs silently and without any user intervention the following functions: Performs a complete inventory of the target machine, providing the Runtime server with the software and hardware information collected. Identifies the starting and the stopping of a software products and communicates this information to the Runtime server so that licenses can be assigned or released at run time. Periodically checks for a software upgrade, so that the user intervention on the target machine is not needed. When planning a IBM Tivoli License Manager deployment, Agents are part of both physical and logical design phases. Refer to 3.1.2, ITLM Runtime Server considerations on page 52 for more information regarding Agents from a physical design point of view and to 3.2.4, Monitored Nodes considerations on page 61 regarding Agents from a logical design point of view.
Administrator
An ITLM Administrator is a user who manages the entire IBM Tivoli License Manager solution or who is in charge of a specific Customer. The ITLM Administrator must be in charge of at least one Customer, but can be responsible for Administrator many different ones. An Administrator is either defined at the ITLM Administration server level and is able to manage the Customer, or is defined at a ITLM Runtime server level and is only able to produce real time reports for the Agents registered to that server. A default ITLM Root user, named tlmroot, is defined by the application and cannot be renamed. This login, and only this, is used to create new Administrators and new Customers. An Administrator performs the following tasks for a Customer: Manages the license management environment including registration of Runtime servers, Divisions, Nodes and Agents. Manages the license entitlement and license pool definition. Produces reports. Receives and reacts to notifications of events.
26
Section 3.2.5, Administrator considerations on page 62 provides observances when planning the deployment of an IBM Tivoli License Manager environment.
Customer
As seen in Figure 2-5 on page 24, a Customer is the owner of all components of its topology, which consists in Runtime Servers, Divisions, Nodes, Agents and Users. Furthermore, Reports, Inventory and software entitlements are part of the Customer Customer organization. As soon as an Administrator is logged on to the IBM Tivoli License Manager environment through one of the Web interfaces, he/she will be asked to select the Customer he/she is in charge of in order to access the specific Customer working area. From there, any changes made on any objects are only applied to that current Customer configuration. Customers are part of the logical design of an IBM Tivoli License Manager solution. Additional information is provided in 3.2.2, Customer considerations on page 60.
Division
A Division is part of the Customers Topology. It is used to group Agents so that they can be logically organized. Division can be selected for some Administration tasks, for example, to define different frequencies of inventory scans, to create specific reports and, especially, to limit access to license pools to a specific group of Agents.
Division
Divisions are part of the logical design of a IBM Tivoli License Manager solution. Additional information is provided in 3.2.3, Division considerations on page 61.
Nodes
Nodes are part of the Customers Topology. A Node is a physical asset representation in an IBM Tivoli License Manager structure. It can be any workstation or server of a Customer organization. For IBM Tivoli License Manager, the Nodes details, such as the location or description fields, of a Node should be related to the Asset Management and/or financial information implemented at the Customers site. This information can be imported from an Asset Management tool or from an Inventory solution already deployed using the IBM Tivoli License Manager XML interface. For more information about the IBM Tivoli License Manager XML interface, refer to 2.4.2, XML interface on page 30. It is important to notice that each Agent of the Customer's Topology will have a corresponding Node. If a Node doesn't already exist for an Agent, during the Agent registration process, a new Node is
27
automatically created in the IBM Tivoli License Manager. However, if a Node is manually created, the Agent is not automatically registered and associated to that Node. For additional information on Nodes and the planning phase of your IBM Tivoli License Manager deployment, refer to 3.2.4, Monitored Nodes considerations on page 61.
Users
Users are part of the Customers Topology. The details of a User correspond to the ones defined for the specific Operating System login used by an end user. License pools restrictions can be applied on Users and, therefore, will allow or will not allow a User to start applications on monitored End Users nodes. Additional information can be found in 5.7.5, Adding application users on page 166.
Inventory Schedule
Before performing Licensing control on an Agent, IBM Tivoli License Manager needs to know what software is installed on that particular node. Inventory scan can be scheduled to repeat at regularly, defined intervals. However, it is planned by Division and, therefore, is related to one Customer only.
Inv. Schedule
Inventory Schedule is part of the Administration Design and more information can be found in 5.7.4, Scheduling an inventory scan on page 164.
Software Entitlement
A software entitlement is a set of rules that defines how software is monitored and under which Licenses conditions are allocated. These rules can be applied on the entire Customer organization or only on a particular Division, Node Software Entitlement or Agent of a specific Customer. Therefore, one software entitlement cannot be applied across multiple Customers. One important part of the software entitlement is the license pool definition. A license pool is a set of licenses for a specific product that are administered as a group with a set of rules governing thresholds, hard stops, license allocation to multiple sessions of the same product, and the availability of the product to Users and Nodes. Software Entitlement is discussed in more detail in 2.5, Licence Management process on page 30, and more information regarding the creation of a software entitlement is provided in 5.8.2, Selecting a product for entitlement or license pool maintenance on page 167.
28
Software Reports
IBM Tivoli License Manager provides two types of reports: real-time and historical information. Real-time reports can be obtained from the Runtime servers and provide information about software usage on a monitored node. Software Reports Historical reports can be obtained only from the Administration server and provide information about software usage for a specified period of time. As shown in Figure 2-5 on page 24, reports are related to a specific Customer. In addition to the reports provided by the Administration and Runtime servers, IBM Tivoli License Manager provides a full integration with IBM Tivoli Data Warehouse. This integration offers additional reports and the capability to create your own. For more information about software Reports, refer to Chapter 6, Reporting with IBM Tivoli License Manager on page 185.
29
Note: The default HTTP port is 80, for a non-secure connection; and 443, for a secure connection. If you plan to use the SSL encryption, you have to specify https instead of http. When logging in for the first time, you must use the default root user which is tlmroot and the default password which is system. For more information regarding how to use the Web interface, refer to IBM Tivoli License Manager License Administrators Guide, GC23-4833
30
and vendors evaluation, contracts negotiation, budget planning, hardware compliance analysis, software life cycle planning, and so on. However, one of the most important steps of this Business process is software monitoring. This is the only way to exactly know what software is installed within an enterprise and, more importantly, which software and how many pieces of it is used within the IT infrastructure. Sometimes, enterprises buy Corporate licenses even though licenses are procured for some specific Divisions and wont be used by the rest of the enterprise. Many organizations are overbuying licenses so as to not expose the enterprise to the risk of non-compliance usage of software products, merely because they are not able to prove or to evaluate how many licenses they really need or use. The license procurement information must be properly reconciled with the software usage and inventory data. This is the only way an enterprise has to tell whether it is paying more license fees than necessary or whether it should buy new licenses to be compliant with the product license policies. Currently, many software vendors leave the responsibilities of license management to the enterprises that buy the products. They often dont provide technical support to maintain or apply the product license policies. Furthermore, the organizations have to prove that they are not using more licenses than they are authorized for. IBM Tivoli License Manager offers a technical way to control and apply the software vendors pre-defined policies. It allows the Administrator to easily manage different products in different ways, reflecting the rules of each products License agreement. Some software requests a License compliance enforcement in risk of facing financial penalties. IBM Tivoli License Manager can apply License enforcement by prohibiting the start of a certain software. The technique used to prevent software usage is a non-intrusive technique, avoiding any risk of damaging application files and data. All software vendors apply pricing policies. However, the License counting process depends on each software vendor. Sometimes, the License counting is based on the number of concurrent users, number of installed or configured processors on machines, number of installed Hard Disks, on the amount of memory, and so on. Furthermore, for the same software, the rules can differ if the License is limited to a user, a group of users, or a Division.
31
example, prevent the usage of critical software that is used for your business production. Hereafter, you will find the complete process that is used to define software entitlement within your IBM Tivoli License Manager solution. This process should also be included in your existing Change Management and Life Cycle strategy so that the software entitlement process can be used in every situation that suggests a software licensing policy change, a new licensing negotiation, or when a new software purchase occurs. We advise you to define and document each process for each software that needs a software entitlement. This information can be used in case of an audit, a skill transfer, a licensing negotiation, a software migration, or any event that solicits knowing the licensing policies of a software. Based on the definition provided in Software Entitlement on page 28, a software entitlement is a set of rules that defines how software is monitored. It is important to understand that a software entitlement is simply a definition of the software you want to monitor. If you want to enforce Licensing restrictions, you need to create license pools within the software entitlement. A license pool is a set of rules governing thresholds, hard stops, license allocation to multiple sessions of the same product, and the availability of the product to Users and Nodes. Figure 2-6 is the process of creating a new software entitlement, and as seen in Figure 2-2 on page 15, the software entitlement is entirely part of the software Asset Management process.
32
New Software
No End
Manage License ?
Yes
Enable Default
Hereafter, the software entitlement definition process is explained in detail. However, for more information regarding each IBM Tivoli License Manager software entitlement option and how to create a software entitlement, refer to 5.8, Managing software entitlement and license pool on page 166. As shown in Figure 2-6 each of the following steps are mandatory to enable a software entitlement: Manage License? The first question is to answer whether or not the software needs to be entitled. For example, an In-House application may not need any licensing
33
policy enforcement, but still you want to get statistics of its usage. In this case you have to create a software entitlement. Monitor SW Usage? You have to decide whether or not you want to track the presence and use of a product. Enabling this option can help you to get software statistics, and more importantly, software usage reports. Apply license checks? This point is important because if you want to apply licensing policies or software usage monitoring, you have to enable license checks. Otherwise, if you dont apply any checks, even if the Agent informs its Runtime server of a start or stop of an application, the Runtime server will not use this information and the end user will be able to start the application, even if there is no communication between the Agent and the Runtime server. Wait for license authorization? This point is dependent on your license policies. It means that the end user will not be able to start the application without receiving authorization from the Runtime server. This is valid for the software or any application defined in a license pool. Apply license restriction? As explained earlier, some software products are subject to strict licensing policies. If you need to apply these polices, you have to create specific license pools. Otherwise, if you only want to monitor software usage and dont want to apply any licensing restriction, you can use the default option and no licensing policies will be applied. If you want to apply licensing rules in your environment, you have to create license pools within a software entitlement. A license pool can be applied to only one software entitlement, therefore, to only one software at a time. However, many license pools can be created for the same software entitlement. This allows you to define many different rules for the same software that have different licensing policies regarding how the software is used. Figure 2-7 shows the process of creating license pools. This process immediately follows the software entitlement definition process.
34
Select a Quantity
No
Yes
No
No
No
No
End
35
Hereafter, the definition process is explained in detail. However, for more information regarding each IBM Tivoli License Manager license pool option and how to create a license pool, refer to 5.8, Managing software entitlement and license pool on page 166. Notice that each of these steps are mandatory to enable a license pool: Select a Capacity Type If a software vendor has defined licensing policies, he needs to provide the counting method he uses to exactly determine the number of licenses you are allowed to use within your enterprise. Normally, such methods are based on the number of concurrent users, the amount of memory installed on a node where the software will be executed, the numbers of online processors, the number of configured processors, or the number of hard disks installed on the machine. Used in conjunction with the IBM Tivoli License Manager license pool quantity option, you can define the upper license limit for a type of counting method. For example, if the capacity type is the number of processors online and the quantity is 10, this license pool will limit the number of licenses to only 10 processors, this could be 10 machines with one processor or 2 machines with 5 processors. Apply Maximum License usage? This is a critical decision, because if it is not correctly evaluated, it could impact your business production. By choosing to apply the maximum license usage, IBM Tivoli License Manager will refuse to serve a new license request by hard stopping the software if the maximum of allowed licenses has already been reached. It means no one will be able to start that particular application if the threshold has been reached. Select a Multi-instance Some software may only count that one license is being used if a new instance of the same software has been started for a second time, or more, on the same machine or same user ID, for example. Another example may be if the software needs to be used by a group of users and is only considered as one license. Select a Target Type The rules you defined for a license pool need to be applied in your monitoring structure, called Topology. However, you are able to apply a set of rules to your entire Customer using the Enterprise option. You can also be more specific in the application of your rules by choosing to limit the availability of a software to one or several Divisions, to one or several Nodes, or to one or several Agents. Using one of these three options, you will be asked to provide an exhaustive list of object names.
36
Assign Login Name In any case and independently of which Target type you choose, you need to provide one User name or a list of Users who will be subject to this License restriction. However, you can select the All option to enable a license pool for every User within your enterprise. Need to create a new License Pool? As already mentioned, the software can respond to many different licensing policies depending in which situation it is used. Within a software entitlement, you are able to define several license pools. Going back to the example of ACME enterprise and the CSI HR software we used in Figure 2-1 on page 13 and in Figure 2-2 on page 15, the license policies for the CSI HR software maybe different for the HR and Financial Divisions, because different modules of the software are used. You can create one license pool with a User Capacity limitation and assign it to the HR Division and create a second one with a Memory Capacity limitation and assign it to the Agents that are part of the Financial Division.
37
Note: The information provided in this section is for illustration and educational purposes only. It may not be used or incorporated in any document as official Microsoft information. The Microsoft License program is called Microsoft Volume Licensing Program. Here are some of the licensing options provided by the Microsoft Volume Licensing program that are dedicated to business organizations and offer different ways to acquire multiple product licenses: Open License 6.0 Select License 6.0 Enterprise Agreement 6.0 Enterprise Subscription Agreement 6.0
38
There are four price levels (Table 2-1) for all select license products acquired within each product pool. The price level is determined by a three year forecast.
Table 2-1 Select License 6.0 price level
Price Level
A B C D
On an annual basis, Microsoft will review the purchase history for the preceding 12 months against the forecasted price level for each product pool. For the first year end review, Microsoft will check to see if 1/3 of the total forecast was met to determine whether the price level needs to be reset. For the second year end review, Microsoft will check that 2/3 of the forecast was met. Depending on the actual purchase history, the price level may be raised upwards, downwards, or remain the same.
39
40
contract period. The ACME enterprise wants to precisely know how many Microsoft Excel licenses are used within the enterprise per year to be sure that the licenses fees match the budget planned. Furthermore, if the ACME enterprise were to purchase 300 additional Microsoft license points, the pricing level would change from A to B, and maybe the pricing conditions could be better. By enabling the software usage, the ACME enterprise will know, before buying new Microsoft Licenses, if the 4,500 Microsoft Excel Licenses are really used, and if by buying only 300 Microsoft points more, the enterprise could saved money.
Software Usage Monitoring License checks License authorization waiting License Pools
Yes Yes No
Name
Select License 6.0
Type
User
Quantity
3,900
Target
Enterprise
Instance
Disabled
Users
All
Hard Stop
No
41
http://www.oracle.com/corporate/pricing/, as of the date of publication of this document. It is offered as a partial summary of some of Oracles licensing programs and policies solely for illustrative purposes and does not purport to be a full, complete, or comprehensive representation of those programs and policies. For a full description of Oracles licensing terms, contact Oracle or your Oracle vendor.
The information provided in this section is for illustration and educational purposes only. It may not be used or incorporated in any document as official Oracle information. The Oracle Database category includes four distinct editions each suitable for different development and deployment scenarios. Enterprise Edition Standard Edition Lite Edition Personal Edition The Oracle Database products are licensed using the two metrics described here: Named User Plus Metric Processor Metric
Processor Metric
This metric is mostly used in environments where the software users cannot be easily identified or counted, like in Internet-based applications. The Processor metric is also used when it is more cost effective than Named User Plus licenses. All processors where the Oracle programs are installed and/or running must be licensed. If the server where the program is installed can be hardware-partitioned and the customer can provide enough information to Oracle to confirm that only part of the server is being used by the Oracle program, then only the part that is being used must be licensed.
42
The Oracle Database products are also licensed, in conjunction with the previous methods, depending in which IT environment they will be used: Development Test/Staging Production Standby
Development
Set up, customization, and modification of software is done in a development environment. Any person doing development work using the software must be licensed. Oracle software for development is governed by a special agreement called the OTN Development License. This agreement grants the individual the right to use the programs only in a development environment. Licenses obtained under this agreement may not be used in test, production, failover or any other environments.
Test/Staging
Test/staging environments are used to verify that new or customized code runs properly. Test/staging environments can be staged on separate servers or on the same servers used to run a development or production environment. Any Oracle software used in test/staging environment must be properly licensed with a full use license under an Oracle license agreement. If a test/staging environment is maintained on the same server as a production or development environment, and that server is fully licensed for all relevant programs on a per processor metric, then no additional Licenses are required for the test/staging environment.
Production
The environment used by end users for business or other operations is called a production environment. All programs used in the production environment must be properly licensed based on the applicable license metrics under an Oracle license agreement.
Standby
In this environment, both the primary and the standby databases must be fully licensed. Additionally, the same metric must be used when licensing the databases in a standby environment.
43
Staging, test, and production environments are installed and running on a server, which has six processors. 10 developers are working on the staging, test, and production environments 500 traders are using the Web site that resides on the production environment The Oracle product that need to be licensed is the Oracle Database Enterprise Edition for the three environments: Test, Staging, and Production. This product can be licensed by Processor or by Named User Plus metric: If licensing by Processor, all processors where the Database is installed and/or running must be licensed. Number of Processor Licenses required: 6 If licensing by Named User, the number of Licenses required is the Named User Plus minimum (25 Named Users Plus per Processor) or the total number of actual users accessing the Database, whichever is greater: a. Named User Plus minimum: 25 * 6 Processors = 150 Named Users Plus b. Total Users: 500 traders + 10 Developers = 510 Named Users Plus Number of Named User Plus Licenses required: 510 If the server is fully licensed by processor then no additional licenses are required to install and/or run other environments that are configured on the same server. The ACME enterprise opted for a Named User Plus License metric and need to achieve 510 Name Users Plus licenses.
44
Table 2-3 Software entitlement example for Oracle Database Enterprise Edition
Software Entitlement for Oracle Database Enterprise Edition Version Vendor Platform
9i Oracle Windows
Software Usage Monitoring License checks License authorization waiting License Pools
Name
Developers Traders
Type
Users Users
Quantity
10 500
Target
Develop. Division Trading Division
Instance
Disabled Disabled
Users
All All
Hard Stop
Yes No
45
use network nodes or switch ports as metric while some security products use a metric based on the number of user accounts that have to be managed. Some IBM Tivoli Software products are also available on IBM ^ z-Series platforms. They are based on the same processor licensing metric. Furthermore, processor licenses for a distributed IBM Tivoli product can be used on zOS and vice-versa as the licenses are based on hardware, not on Operating System, and are interchangeable. Nevertheless, IBM Tivoli Software products that are part of the Host edition or for z-Series brand are priced per Management Services Unit (MSU). It is important to notice that production and test environments both require IBM Tivoli licensed products. If a server is split in several physical partitions, IBM Tivoli Software products will be counted per processor in each physical partition. However, if the server is split in several logical partitions, the products will be counted per processor or per MSU for the entire system. The Enhanced Value-Based Pricing model defines the number of needed IBM Tivoli Software product Licences that a customer environment requires. However, IBM Tivoli Software products are part of the IBM Passport Advantage program, which rewards customers with better pricing based on the volume of their IBM software acquisition and the type of organization. The initial customer order determines the pricing level received by the customer. This is known as the Relationship Suggested Volume Price band level. Passport Advantage is a point-based offering, which means that every product and service listed within the price list carries a predefined point value. The customer's initial order is converted into points, which sets the Relationship Suggested Volume Price band level. There are 10 band levels "A" through "J". See Figure 2-8.
46
Figure 2-8 IBM Passport Advantage relationship volume price band level
Passport Advantage allows the customer to have a common anniversary date for software Maintenance renewals, simplifying management and budgeting for eligible new versions and releases for covered products. The anniversary date is established at the start of the Passport Advantage Agreement. Aggregation on Passport Advantage occurs each quarter. This quarterly aggregation can only better the customer's price level for the remainder of an anniversary period. Figure 2-9 shows an example of a Passport Advantage Aggregation.
47
In this example, the customer makes an initial transaction of 1,000 points. This sets the customer's Relationship Suggested Volume Price band level to "E". During the first quarter, the customer made two additional product purchases: one equal to 500 points, and another equal to 1,000 points, for a total of 1,500 points. At the end of the quarter the customer's purchases are aggregated for that quarter. In this example, the initial transaction of 1,000 points is added to the additional transactions of 1500 points for a total of 2,500 points. This aggregation causes the customer's Relationship Suggested Volume Price to be recalculated to band level "F" for the remainder of the anniversary period, unless additional purchases are made and aggregated forcing the customer's Relationship Suggested Volume Price band level even higher. In the third quarter, the customer made additional product purchases of 1,500 points and 1,000 points, for a total of 2,500 points. This is aggregated to the total number of points earned during the current anniversary, for example, 2,500 points plus 2,500 points. Therefore, aggregation after third quarter will recalculate the customer's Relationship Suggested Volume Price to band level "G" for the remainder of the anniversary period.
48
Software Entitlement for IBM Tivoli Configuration Manager Version Vendor Platform
4.2 IBM Windows
Software Usage Monitoring License checks License authorization waiting License Pools
Yes Yes No
Name
Servers
Type
Processor
Quantity
50
Target
Server Agents
Instance
Disabled
Users
All
Hard Stop
No
49
50
Chapter 3.
Implementation planning
This chapter provides considerations to ensure an effective implementation of IBM Tivoli License Manager (ITLM) across your enterprise. IBM Tivoli License Manager is dependent on a number of supporting applications and components which makes planning an essential task in order to ensure a successful deployment. Before installing IBM Tivoli License Manager, you should consider designing your licence management architecture. This should include a high level design in which the physical and logical design will be defined. You should also consider the hardware and software requirements and their dependencies of the various functional pieces on the other applications that support the IBM Tivoli License Manager solution. The main topics concerned with planning discussions in this chapter are: Considerations regarding the physical design and logical design Disaster Recovery plan Planning overview for the entire IBM Tivoli License Manager solution Planning for supporting applications Planning for IBM Tivoli License Manager
51
52
Assigning Agents to Runtime servers is a critical portion of the physical design. Performance and scalability are the main points for the Runtime servers placement. Note: Before starting the evaluation of the number of Runtime servers for your environment, you must notice that a Runtime Server can be part of only one Customer topology. For more information about the Customer design, refer to 3.2.2, Customer considerations on page 60. The placement of the Runtime servers must respect the rules defined here: Performance Scalability Physical licence requests management
Performance
Each Runtime Server will be connected directly to the Administration server, and they should be located relatively close to their agents within the physical network. So, you may place Runtime servers across a Wide Area Network (WAN) from the Administration server, which makes the Runtime server closer to their monitored nodes. This minimizes network traffic when requesting licence status and should also decrease the security risks, because the communications between the Agents and the Runtime server are not encrypted. Another reason for putting the Runtime servers close to the Agents is the flow of inventory data back from the Agents to the Runtime server Database. This information is then forwarded to the Administration server Database but is encrypted if you decide to enable SSL, and only the differences are sent back to the main Database. For these reasons, if your implementation covers more than one location, we advise that you have a least one Runtime Server at each location. However, for small WAN locations, it makes no sense to deploy a Runtime Server. You may plan to dedicate a Runtime Server on your main site only to manage these WAN locations, and you may place this server in a zone protected by a Firewall or force the usage of a Proxy server.
Scalability
The Runtime server component can also be installed on the same physical machine as the Administration server to support Agents within the same network. However, this configuration is not recommended. From the point of view of scalability, if you install both servers on the same machine, each one of them can only use a share of the hardware and network resources. It is important to notice that the resource usage of the machine during the inventory scan and licence
53
usage control process can be very demanding and other processes on the same machine can be drastically impacted. Furthermore, by installing both servers on the same machine, they will rely on the same incoming method to accept requests, which is the HTTP server. Therefore, if one of the two becomes overloaded, and the HTTP server starts having some problems with the number of pending requests, the other one may start to have overloading problems too. Another point that can impact the Runtime server scalability is the inventory scan process. It is only possible to schedule inventory scans by Division. If all Agents registered on a Runtime server are part of the same Division, the inventory scan process will start for all Agents at the same time, which can overload the Runtime server. An option is to register Agents belonging to large Divisions to multiple Runtime servers. Note that the decision about how to distribute the Agents among Runtime servers does not need to reflect the organizational structure.
54
55
Firewall IBM Tivoli License Manager allows you to use a Proxy server to filter the HTTP communication between the Administration server and the Runtime server and between the Runtime server and its Agents.
56
files of other applications. Furthermore, it is also important that such an application doesnt interfere with the operating system files. The following file systems structure is only an example based on best practices and is only a suggestion for an installation of IBM Tivoli License Manager. For UNIX: /usr/local/DB2/<DB2 instance name> This file system contains the databases definition for the IBM DB2 Universal Database Enterprise Edition instance you will use for the IBM Tivoli License Manager Administration and Runtime Databases. This is specified by <DB2 instance name>. /usr/local/DB2/<DB2 Administration server name> This file system contains the IBM DB2 Universal Database Enterprise Edition binaries and configuration files. /usr/local/HTTPServer This file system contains the IBM HTTP server binaries and configuration files. /usr/local/WebSphere This file system contains the IBM WebSphere Application Server binaries and configuration files. /usr/local/ITLM This file system contains the binaries and configuration files for either the IBM Tivoli License Manager Administration or Runtime server or both. For Windows: E:\lBM\DB2 This file system contains the databases definition for the IBM DB2 Universal Database Enterprise Edition instance you will use for the IBM Tivoli License Manager Administration and Runtime Databases and also the binaries and configuration file for the application. E:\IBM\HTTPServer This file system contains the IBM HTTP server binaries and configuration files. E:\IBM\WebSphere This file system contains the IBM WebSphere Application Server binaries and configuration files.
57
E:\IBM\ITLM This file system contains the binaries and configuration files for either the IBM Tivoli License Manager Administration or Runtime server or both.
E
Medium Site Runtime server Main Site
B
Monitored nodes
Runtime server
C
Monitored nodes Runtime server
Monitored nodes
Administration server
D
Small Site
Monitored nodes
Monitored nodes
Proxy server
Monitored nodes
58
The legend used Figure 3-1 is related to specific decisions of the servers placement and explained as follows: A The IBM Tivoli License Manager Administration server is located in the main site. The machine is attached to a Fast Ethernet network segment dedicated for the enterprise servers. As all Runtime Servers will make a certain number of requests, the network needs to be fast enough not to be a bottle neck. The first IBM Tivoli License Manager Runtime server is in charge of the Agents located in the main site. As this Runtime server will serve a large number of Agents, for scalability and performance reasons, this Runtime server needs to be installed in a dedicated machine. It is also attached to the Fast Ethernet network segment dedicated for the enterprises servers. The second IBM Tivoli License Manager Runtime server is in charge of the Agents located in the DMZ. These Agents will go through a Proxy server to filter the data flow between the enterprise and the DMZ. This Runtime server will also serve as secondary Runtime server for the Agents located in the main site, in case the first Runtime server is overloaded and is not able to answer to all licence requirements. This server could also be located in the same network segment as the previous Runtime server. The third IBM Tivoli License Manager Runtime server is in charge of the WAN Agents. For small remote sites, which can have less than 20 agents, in this case, cost factors were considered and it was decided not to install dedicated Runtime servers on each of the small sites. In this example, all small sites are managed by a dedicated Runtime server. This offers the possibility of using a proxy server to filter the WAN addresses that can use this Runtime server. A fourth IBM Tivoli License Manager Runtime server is installed on the medium remote site. This will increase the performance of the management of that site. Otherwise, if no Runtime is installed on the medium remote site, each agent would contact the Runtime server and upload information across a small bandwidth network which could created a network bottle neck for all others applications.
59
design. The design becomes more complex over time and therefore is harder to modify. A good physical design could be easily invalidated if the logical design is not well planned and executed. The logical design process includes the following high-level considerations: Naming convention Customers and Divisions Monitored Nodes Administrators Logical Design example
Naming policies
During the logical design phase, you should define naming policies based on the following examples. They must be respected during the whole life of the solution and reviewed during each phase of the IBM Tivoli License Manager solution life cycle. For example: Names must not contain spaces or special characters. Names must consist of alphanumeric characters, dash (-) or underscore (_). Names must contain only US ASCII characters (based on the product limitation).
60
The Topology hierarchical structure has and must have only two levels. The first being the Customer, the second is defined by Divisions. If you plan to use IBM Tivoli License Manager to manage different business customers, each of these have to be defined as an ITLM Customer in the logical design and their business Divisions should become ITLM Divisions. However, if you plan to only manage your enterprise and in fact only one business customer, you may plan to define business Divisions as Customers in the logical design and some business sub-divisions as Divisions. This can offer you a higher level of granularity in licence management within your enterprise. You need to provide an Account ID for each Customer. For business customer management, this can be the customer number. Otherwise, the cost center can be used if you plan to use Customers for your business Divisions.
61
environment, you will be able to integrate the two solutions more easily, in order, for example, to charge the software licence usages to a cost center.
Other
At the Runtime server level: The Administrator defined at the Runtime server level is only able to use the Runtime server Web interface and to receive notifications generated by the Runtime server.
62
Note: An Administrator defined at the Administration server level cannot access the Runtime server Web interface. The same is valid for an Administrator defined at the Runtime server level accessing the Administration server Web interface. If an Administrator should access the ITLM servers, he/she needs to be defined on each server. The default Root user is tlmroot and its default password is system. This user ID cannot be deleted nor can its logon name be changed. However, we strongly recommend that its password is changed. This user ID is also defined on each Runtime server and even if you change the password at the Administration server level, you need to change its password on each Runtime server. We recommend that the use of the tlmroot user is restricted only for operations that need these types of privileges, for example, the Administrator definition on Runtime servers. Furthermore, if you plan to audit the security access, we recommend that each user has its own login. We also recommend if a Security Officer is in charge of all IT Security aspects within your enterprise to let him/her manage the Administrator definitions. Some information regarding the financial aspect of the licences can be confidential and may not be accessed by non-authorized persons. Table 3-1 can help you to plan and manage the Administrator definition.
Table 3-1 Planning for Administrator definition
IBM Tivoli License ManagerAdministrator definition User Name Logon Name E-Mail
<Full name of the user> <The name that will be used to access the Web interface> <For servers notification>
Notification
<Yes/No>
Customer
Notification Notification
<Yes/No> <Yes/No>
63
C
IBM EMEA Adm.
D
IBM Tivoli Adm.
E
IBM Switzerland Adm.
F
IBM Switzerland Adm.
HR Division
Financial Division
Consulting Division
IT Division
Analysts
Consultants
Operators
IT Spec.
K
EMEA Runtime server
L
Swiss Runtime server
M
Swiss Runtime server
64
The legend used in that example is related to specific decisions of the logical design and explained as follows: A B C This customer groups all EMEA Divisions that are not specifically related to country. This customer groups all Switzerland Divisions that act only for this country. Because the customer defined in A doesnt have a large number of Nodes and Runtime servers, we decided that one ITLM Administrator is enough. However, this Administrator will have only the Licensing Manager role. The administration tasks of the IBM Corporation environment will be assumed by a World Wide Administration team. We also decided to create the same user on the Customers Runtime server in order for him to get the real time reports. Even if the administration management is made from a central location, we have defined a specific Tivoli Administrator in charge of all administration tasks for these two customers. This Administrator has the Administration server level. We havent created the same user on the Runtime server, because he is in charge of only administration tasks, and doesnt need access the Real time reports. The customer defined in B is bigger than A. We decided to split the responsibilities of the IBM Tivoli License Manager administration for this customer. The first Administrator is in charge of the licence management and has only the Licensing Manager role. The second one is in charge of the Real Time reports on the Runtime servers and is only defined on those servers. To gain more flexibility in licence management, we decided that each business Division of each IBM country or region will be represented as a Division. During the Physical Design phase, we analyzed that, for Customer A, one Runtime Server would be enough regarding the number of nodes to manage and the small network requirements. This Runtime server is defined to support the Divisions G and H. Furthermore, the inventory scan frequency will be different for each Division. This will avoid the overload of the Runtime server during the inventory scan. The Division J has a large number nodes to be managed. Based on this, and the fact that there is no network constraints, we decided to implement two Runtime Servers for the Customer B. In order to avoid an overload of the Runtime server M, some nodes of the Division J are registered to the Runtime server L, which can easily support this overload even if it manages the nodes of Division I. Therefore, the management of Division J is split in two Runtime servers.
E, F
G, H, I, J
L, M
65
66
A high-availability design provides protection against hardware failures primarily through the use of redundant hardware. Sometimes, however, a high availability configuration is not available or it does not work in situations where software has failed, databases have become corrupt, or files have been accidentally deleted. The way to recover from these software failures is to prepare regular maintenance procedures. For every failure scenario, develop and design a corresponding plan of action to recover from these failures. The following section provides a specific maintenance overview for each of the IBM Tivoli License Manager components.
In case of a problem with the IBM DB2 Universal Database Enterprise Edition application itself, you can reinstall the software using the procedure described in Chapter 4, Getting IBM Tivoli License Manager up and running on page 99. When the RDBMS is up and running again, you can restore the Administration and/or Runtime Server databases. However, if you have no back up of these databases, all information regarding the logical design is lost. Important: A database is present on all Runtime Servers and contains information regarding the Agents managed by each of them. Each database on Runtime servers needs to be backed up.
67
done. For more information about how to back up and restore IBM WebSphere Application Server configuration files, refer to this documentation:
http://www-3.ibm.com/software/webservers/appserv/doc/v40/aes/infocenter/was/061 0.html
68
If no SAN solution is deployed in your enterprise, we recommend that the Administration server machine supports at least RAID 0 or RAID 5 capability.
69
Phase 1
1. Install IBM DB2 UDB EE & FP 2. Install HTTP Server 3. Install IBM WebSphere Application Server & FP 4. Install ITLM Administration server 5. Populate ITLM Administration DB 6. Deploy the Logical Design: create Administrators, Customers, Divisions and Runtime Servers. 6a. Nodes and Users could be created if designed
Administration server
TLMA (from 5)
Phase 2
7. Install IBM DB2 UDB EE & FP 8. Install HTTP Server 9. Install IBM WebSphere Application Server & FP 10. Install ITLM Runtime server 11. Populate ITLM Runtime DB N.B.: Physical Design must be respected
Runtime server
Runtime server
Phase 3
11.(opt.) Create Nodes 12. Deploy ITLM Agents
Monitored node
Monitored node
Monitored node
Monitored node
70
Hardware requirements
The hardware requirements mainly depend on the size of your databases and on the administration tools you will use, however Table 3-2 lists the minimum requirements. These requirements are only for the IBM DB2 Universal Database Enterprise Edition, and you should also take in consideration the hardware requirements for the others components.
71
HW
Processor RAM Hard Disk
Intel Platforms
500Mhz Pentium 128 MB minimum 256 MB recommended Server: A typical installation requires a minimum of 245 MB of disk space, this includes the online product documentation, tools, and the Java Runtime Environment. Client: 475 MB of disk space, this includes tools and documentation Total: 720 MB of disk space
Non-Intel Platforms
AIX: RS/6000 at 375Mhz 128 MB RAM minimum 256 MB recommended Server: A typical installation requires a minimum of 300 MB of disk space, this includes the online product documentation, tools, Client: 270 MB of disk space, this includes tools and documentation Total: 570 MB of disk space
Other Network
CD-ROM drive Ethernet or Token Ring card Network connectivity to the internet
CD-ROM drive Ethernet or Token Ring card Network connectivity to the internet
For more information concerning the Hardware requirements for IBM DB2 Universal Database Enterprise Edition 7.2.7 visit the DB2 Technical Support at the following links: For Windows
ftp://ftp.software.ibm.com/ps/products/db2/info/vr7/pdf/letter/db2v6e70.pdf
For UNIX
ftp://ftp.software.ibm.com/ps/products/db2/info/vr7/pdf/letter/db2v3e70.pdf
Software requirements
Before starting the installation of the IBM DB2 Universal Database Enterprise Edition, you should have installed the minimum product levels listed in the Table 3-3. Because only the Microsoft Windows NT Server, Microsoft Windows 2000 Server, and the IBM AIX operating systems are supported by IBM Tivoli License
72
Manager for the Administration and the Runtime servers, only information regarding these operating systems is provided.
Table 3-3 Software requirements IBM DB2 UDB Enterprise Edition
SW
AIX 4.3 or later Windows NT Server 4.0 SP 5 or later Windows 2000 Advanced Server 2000 SP1 or SP2 Windows 2000 Server 2000 SP1 or SP2
WNT Server
W2000 Server
IBM AIX
X
For a complete list of software requirements for IBM DB2 Universal Database Enterprise Edition visit the DB2 Technical Support at the following links: For Windows
ftp://ftp.software.ibm.com/ps/products/db2/info/vr7/pdf/letter/db2v6e70.pdf
For UNIX
ftp://ftp.software.ibm.com/ps/products/db2/info/vr7/pdf/letter/db2v3e70.pdf
It is also important to notice that the installation sequence is IBM DB2 Universal Database Enterprise Edition 7.2 first, and then the IBM DB2 Universal Database Enterprise Edition 7.2 Fix Pack 7. The Fix Pack can be found on the IBM Tivoli License Manager installation media or can be downloaded from the following link:
http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/download.d2 w/report
Attention: If you installed the IBM DB2 Universal Database Enterprise Edition 7.2, in a 32 bit version on an AIX 5L version, you need to install the IBM DB2 Universal Database Enterprise Edition 7.2 Fix Pack 7 also in a 32 bit version instead of IBM DB2 Universal Database Enterprise Edition 7.2 Fix Pack 7, in a 64 bit version. The Release Notes for the IBM DB2 Universal Database Enterprise Edition 7 can be downloaded from the following link:
ftp://ftp.software.ibm.com/ps/products/db2/info/vr7/pdf/letter/db2ire72.pdf
73
The Release Notes for the IBM DB2 Universal Database Enterprise Edition 7.2 Fix Pack 7 can be downloaded from the following link:
ftp://ftp.software.ibm.com/ps/products/db2/info/vr7/pdf/letter/db2ir_v7fp7.pdf
Network considerations
The IBM DB2 Universal Database Enterprise Edition utilizes some specific TCP/IP ports. You can then change these ports, but you need to carefully read the DB2 documentation on how to make the changes. For UNIX: Consider these ports (Table 3-4). The services file for UNIX can be located in the /etc directory.
Table 3-4 DB2 network ports for UNIX
Port
50000
Service Name
db2cdb2<your DB2 instance name> (default is db2cdb2inst1) db2cdb2<your DB2 instance name> (default is db2idb2inst1)
Notes
Connection port used for communication with your DB2 instance. This port is reserved in the services files but is not an official reserved port. Interrupt port used for communication with your DB2 instance. This port is reserved in the services files but is not an official reserved port.
50001
For Windows: Consider these ports (Table 3-5). The services file for Windows could be located in the %SYSTEM32%\drivers\etc directory.
Table 3-5 DB2 network ports for Windows
Port
523
Service Name
db2cDB2DAS00
Notes
Connection port used for communication with the DB2 instance DBsDAS00. This port is officially reserved in the services files. Interrupt port used for communication with the DB2 instance DBsDAS00. This port is officially reserved in the services files. Connection port used for communication with the DB2 instance. This port is reserved in the services files but is not an official reserved port.
524
db2iDB2DAS00
50000
db2cDB2
74
Port
50001
Service Name
db2iDB2
Notes
Interrupt port used for communication with the DB2 instance. This port is reserved in the services files but is not an official reserved port. Connection port used for communication with the DB2CTLSV instance. This port is reserved in the services files but is not an official reserved port. Interrupt port used for communication with the DB2CTLSV instance. This port is reserved in the services files but is not an official reserved port.
50002
db2cDB2CTLSV
50003
db2iDB2CTLSV
For Unix: This user must have the root authority. To select the products you are licensed to install. Regarding the licence agreement provided with IBM Tivoli License Manager for IBM DB2 Universal Database Enterprise Edition, you can install the DB2 UDB Enterprise Edition.
75
For Unix only, to define a new user that will be used for the DB2 Instance. We recommend that you use the default db2inst1 user with its default db2iadm1 group. If this user doesnt exist on your system, the installation process will create it. The destination directory for the installation. Refer to 3.1.7, File systems considerations on page 56 for recommendations. To create a new user which will be used by the Control Center Server to log on to the system. For Windows: We recommend that you use the default db2admin user. If this user doesnt exist on your system, the installation process will create it. You can also decide to use the same user for the following services to log on your system: Administration Server Default instance Console Server instance
You can also decide to create a new user for each service. Except for strong Security requirements, we advise that you use the same user for all of these services. For UNIX: We recommend that you use the default db2as user with its default db2asgrp group. If this user doesnt exist on your system, the installation process will create it. Definition of a Control Database. For Windows: If you decided to use a different user for all services, you will be asked to define a Control Database. We recommend that you use the default values for the database and just change the user who will be become the owner of this Control Database. You will also be asked to define the DB2 super user in this case. For UNIX: We recommend that you use the default name for the Control Database which is dwcntrl. OLAP installation option. You dont need to install the OLAP Starter Kit.
76
Product Registration. This part is important if you want to get product information or support news, but it is not mandatory. During the IBM DB2 Universal Database Enterprise Edition Fix Pack 7 installation: For Windows only, the Control Database Owner password. If you decided to use the default DB2 user, which is db2admin, you need to provide the password of this user. Otherwise, if you have configured a specific user for this Control Database, you should provide the password of this user. For Unix only, the DB2 Instance Owner password. If you decided to use the Default DB2 Instance user, which is db2inst1, you need to provide the password of this user. Otherwise, if you have configured a specific user for this DB2 Instance, you should provide the password of this user.
77
For the ISS server, refer to the Microsoft Knowledge Base Article - 149605 which is located at the following link:
http://support.microsoft.com/default.aspx?scid=kb;en-us;149605
Important: If you plan to use the default HTTP port either for ISS server or IBM HTTP Server, make sure that no other HTTP server installed on your machine is also using the default HTTP port. If there are other HTTP servers installed, you need to change the ports of your other HTTP servers by carefully reading the documentation provided with the application. However, if you decide to change the default HTTP port for the HTTP server you plan to use, you need to report this change also in the VirtualHost section of the WebSphere Administration console. To access the complete IBM HTTP Server reference library visit the IBM HTTP Server InfoCenter at the following link: http://www-3.ibm.com/software/webservers/httpservers/doc/v1319/index.ht ml To access the complete Microsoft Internet Information Services reference library visit the Microsoft support site at the following link: http://support.microsoft.com/default.aspx?scid=fh%3Ben-us%3Biis50&x=4&y =7#faq605
78
HTTPs is a unique protocol that combines SSL and HTTP. A client user can open a URL by specifying https:// to request an SSL-protected document. The standard SSL protocol can be used to encrypt the communication between the Administration and Runtime Server and between the IBM Tivoli License Manager servers and the Web browsers accessing ITLMs Web Interfaces. If you plan to use SSL, you need to configure your HTTP server in order to accept SSL requests. For more information about how to configure the IBM HTTP server for SSL, refer to 4.2.8, Setting up SSL configuration on page 115. Note: SSL uses the port 443 as the default port. This port is officially registered in the services file located in /etc for UNIX and in %SYSTEM32%\drivers\etc for Windows. If you plan to use another default port for SSL, you need to specified this port during the installation of the IBM Tivoli License Manager Runtime Server.
Note: If you plan to use the SSL encryption, you need to configure the VirtualHost section of the WebSphere Administration console with the port you defined for SSL.
79
according to the instructions in the IBM Tivoli License Manager Systems Administrators Guide, GC23-4834.
80
Hardware requirements
The hardware requirements mainly depend on the number of users accessing the IBM Tivoli License Manager Administration and Runtime Server, and Table 3-6 lists the minimum requirements. These requirements are only for the IBM WebSphere Application Server, you should also take into consideration the hardware requirements of the others components.
Table 3-6 Hardware requirements for IBM WebSphere Application Server
HW
Processor RAM Hard Disk
Intel Platforms
500Mhz Pentium 384 MB minimum 512 MB recommended 180 MB free disk space for the base application server 2 GB recommended for a full installation (including DB2 and HTTP server) CD-ROM drive Ethernet or Token Ring card Network connectivity to the internet
Non-Intel Platforms
AIX: RS/6000 at 375Mhz 384 MB RAM minimum 512 MB recommended 220 MB free disk space for the base application server 2 GB recommended for a full installation (including DB2 and HTTP server) CD-ROM drive Ethernet or Token Ring card Network connectivity to the internet
Other Network
For more information concerning the hardware requirements for IBM WebSphere Application Server Advanced Edition 4.0.4 visit the WebSphere Infocenter at the following link:
http://www-3.ibm.com/software/webservers/appserv/doc/v40/prereqs/hardware.htm
Software requirements
Before starting the installation of the IBM WebSphere Application Server Advanced Edition 4.0.4, you should have installed the minimum product levels listed in the Table 3-7. Because only the Microsoft Windows NT Server, Microsoft Windows 2000 Server, and the IBM AIX operating systems are supported by IBM Tivoli License Manager for the Administration and the Runtime servers, only information regarding these operating systems is related.
81
SW
AIX 4.3.3 4330-09 Maintenance Level + APAR IY19277 AIX 5.1 ML1 + APAR IY19236 Windows NT Server 4.0 SP 6a Windows 2000 Advanced Server 2000 SP1 or SP2 Windows 2000 Server 2000 SP1 or SP2 HTTP Server 1.3.19.3 Internet Information Server 5.0 (ISS) DB2 Enterprise Edition 7.2 FP7
WNT Server
W2000 Server
IBM AIX
X
X X X
X X
For a complete list of software requirements for IBM WebSphere Application Server Advanced Edition 4.0.4 visit the WebSphere Infocenter at the following link: http://www-3.ibm.com/software/webservers/appserv/doc/v40/prereqs/ae_v40 4.htm Notice that you need to first install IBM WebSphere Application Server 4.0.1 and secondly to install the IBM WebSphere Application Server 4.0 FixPack 4 to get IBM WebSphere Application Server 4.0.4. The FixPack can be found on the IBM Tivoli License Manager installation media or downloaded from the following link:
http://www-1.ibm.com/support/docview.wss?uid=swg24001635
The Release Notes for the IBM WebSphere Application Server Advanced Edition 4.0.1 can be downloaded from the following link: http://www-3.ibm.com/software/webservers/appserv/doc/v40/ae/infocenter/ was/relnotes401.html
82
The Release Notes for the IBM WebSphere Application Server Advanced Edition 4.0.4 can be downloaded from the following link: http://www-3.ibm.com/software/webservers/appserv/doc/v40/ae/infocenter/ was/404RN.html
Network considerations
The IBM WebSphere Application Server utilizes some specific TCP/IP ports. Refer to the guidelines in Table 3-8 for port assignment, particularly notes about the effects of port changes on other WebSphere components.
Table 3-8 WebSphere network ports
Port
900
Service Name
Bootstrap
Notes
One for each application server. To change it, use the administrative console to modify ORB properties or update the orbSettings object in the application server configuration file. One for each application server. To change it, use the administrative console to modify OLT and Debugger properties. One for each application server. To change it, use the administrative console to modify the trace properties or modify the application server configuration file directly. One for each application server. To change it, use the administrative console to modify LSD properties or update the location service object in the service configuration in the application server configuration file. One for each application server. One for each product installation. To change it, modify the application server configuration file. One for each application server.
2012
7000
9000
9080 9090
9443
83
Port
Random
Service Name
ORB listener port for RMI/IIOP
Notes
One for each application server. To make the value static, add -Dcom.ibm.CORBA.ListenerPort=xxxx where xxxx is a valid TCP port (see guidelines below). For application servers, add the argument to the Command Line Arguments setting of the application server properties.
Important: If you are using or plan to use the WebSM (WEB Systems Management) on AIX 4.x or 5L, it is important to notice that WebSM uses 9090 as the default TCP/IP port. WebSphere also uses TCP/IP port 9090 for its Administration application. You can either change the WebSM default port by updating the websm.cfg file located in /usr/websm, or change the WebSphere default port by carefully reading the information below and the WebSphere documentation. Some considerations on TCP/IP ports: Ports can range from 1024 to 64000. Choose a port that does not conflict with existing ports in use. To check ports in use: Use the netstat -a command View the /etc/services file on UNIX View the %SYSTEM32%\drivers\etc\services file on Windows Ports must be unique in the scope of each physical host. That is, two servers on the same machine cannot have the same port values. The same port numbers can be used for servers running on different physical hosts. Remember to configure firewalls to allow traffic to pass for each assigned port. For security, try to minimize ports.
84
For Windows: This user must also have at least the Act as part of the operating system and the Logon as a service rights defined in the local security settings of the server. For Unix: This user must have the root authority. A Typical or Custom installation. The IBM HTTP Server is part of the IBM WebSphere Application Server Typical Installation. If you plan to use another HTTP Server, you need to use the Custom Installation process and leave the IBM HTTP Server option unchecked. For Windows only, a user already existing on the machine, and its password, which will have the authorities to start the IBM WebSphere Application Server service and/or the IBM HTTP Server service. This user must have at least the Act as part of the operating system and the Logon as a service rights defined in your local security settings. The destination directory for the installation. Refer to 3.1.7, File systems considerations on page 56 for recommendations. A Database to store IBM WebSphere Application Server information. Because the IBM WebSphere Application Server will use an RDBMS to as support database, you should provide the following information: The Type of Database Please refer to the IBM WebSphere Application Server Advanced Edition product documentation for a list of supported databases. The Database name We recommend that you use the standard database name which should be was40. The Database user ID This user must have sufficient authorization to create a database in your database context. We advise that you use the default instance owner user ID, db2admin for Windows, or db2inst1 for UNIX. Directory or URL to access the data Depending on the type of database to de used, you need to provide the full path of the directory in which the database files will be stored or the URL, the name, and the port to access your database.
85
The Hostname of the server on which you plan to install the IBM WebSphere Application Server. The full path of the directory in which the file db2java.zip is located. During the IBM WebSphere Application Server Advance Edition FixPack 4 installation: Licence Acceptance Select the modules to update The following modules must be upgraded: Application Server You need to provide the full path where you have installed the IBM WebSphere Application Server Advance Edition. Application Server JDK JDK IBM HTTP Server If you have installed and decided to use the IBM HTTP Server, you need to upgrade it. You need to provide the full path where you have installed the IBM HTTP Server. Connector Architecture for WebSphere (J2C) Application Server Logs Backups installation file You need to provide a backup directory even if you dont want to backup the files during the upgrade process. The other IBM WebSphere Application Server modules dont need to be installed or upgraded.
Hardware requirements
Hardware requirements mainly depend on the number of users accessing the IBM Tivoli License Manager Administration server, on the number of IBM Tivoli License Manager Runtime servers to be served, and on the number of Agents that will be managed. Table 3-9 lists the minimum hardware requirements and
86
also includes the requirements of the other components, such as IBM DB2 Universal Database Enterprise Edition and IBM WebSphere Application Server.
Table 3-9 Hardware requirements for ITLM Administration server
HW
Processor RAM Hard Disk
Intel Platforms
1.5 Ghz Pentium 1 GB minimum 1 GB recommended 10 GB free disk space for the base application server, for the catalog manager, the components and for the data saved in the RDBMS
Non-Intel Platforms
AIX: RS/6000 at 450 Mhz 1 GB RAM minimum 1 GB recommended 10 GB free disk space for the base application server, for the catalog manager, the components and for the data saved in the RDBMS 100 MB more for the /tmp directory CD-ROM drive Ethernet or Token Ring card Network connectivity to the internet
Other Network
CD-ROM drive Ethernet or Token Ring card Network connectivity to the internet
For more information concerning the Hardware requirements for IBM Tivoli License Manager, refer to IBM Tivoli License Manager Systems Administrators Guide, GC23-4834.
Software requirements
Before the installation of the IBM Tivoli License Manager Administration server, you should have installed the minimum product levels listed in the Table 3-10. Because only the Microsoft Windows NT Server, Microsoft Windows 2000 Server, and the IBM AIX operating systems are supported by IBM Tivoli License Manager for the Administration server, only information regarding these operating systems is listed.
Table 3-10 Software requirements for ITLM Administration server
SW
AIX 4.3.3 4330-02 Maintenance Level AIX 5.1 Windows NT Server 4.0 SP 6a
WNT Server
W2000 Server
IBM AIX
X X
87
SW
Windows 2000 Advanced Server 2000 SP1 or SP2 Windows 2000 Server 2000 SP1 or SP2 HTTP Server 1.3.19.3 Internet Information Server 5.0 (ISS) DB2 Enterprise Edition 7.2 FP7 WebSphere Application Server AE 3.5.6 WebSphere Application Server AE 4.04 Microsoft Internet Explorer 5.5 or higher Netscape Navigator 6.2 or higher
WNT Server
W2000 Server
X
IBM AIX
X X
X X
X X
X X
For a complete list of software requirements for IBM Tivoli License Manager, refer to the IBM Tivoli License Manager Systems Administrators Guide, GC23-4834.
Network considerations
The IBM Tivoli License Manager Administration server utilizes specific TCP/IP ports listed in Table 3-11.
88
Table 3-11 IBM Tivoli License Manager Administration server network port
Port 9085
Service Name
WebSphere Administration port
Notes
This port is used by WebSphere to manage the IBM Tivoli License Manager Administration server. To change this port, read the procedure described in the IBM Tivoli License Manager Systems Administrators Guide, GC23-4834.
Note: The IBM Tivoli License Manager Administration Web interface will be accessed using the standard HTTP port 80 of the HTTP Server. If you have changed this port to another value, you need to use this new port in order to access the IBM Tivoli License Manager Administration Web interface.
89
Network considerations
The IBM Tivoli License Manager Runtime server uses specific TCP/IP port as shown in Table 3-12.
Table 3-12 IBM Tivoli License Manager Runtime server network port
Port 9086
Service Name
WebSphere Runtime port
Notes
This port is used by WebSphere to manage the IBM Tivoli License Manager Runtime server. To change this port, refer to the procedure described in the IBM Tivoli License Manager Systems Administrators Guide, GC23-4834.
Note: The IBM Tivoli License Manager Runtime Web interface will be accessed using the standard HTTP (80) or HTTPs (443) port of the HTTP Server. If you have changed these ports to other values, you need to use these new ports in order to access the IBM Tivoli License Manager Runtime Web interface.
90
Licence Acceptation. You have to accept the licence agreement. Type of installation. Select only the Runtime server installation type. To create the user tlmsrv. This user ID has to be created for RDBMS access. If this user doesnt exist on our system, the installation process will create it. By editing the db.properties file in the <TLM_INTALL_DIR>/admin/conf directory of the Runtime server, you will be able to specify a different user by changing the value of the dbUser clause. However, we recommend that you use the standard tlmsrv user to have the correct rights to access the RDBMS. Configuration of the Runtime server. This step is very important. This will allow the Runtime server to be registered in the IBM Tivoli License Manager environment. However, it is important that the Runtime server is first defined in the Customers Topology at the Administration server before starting the installation. In this case, the Runtime server will be registered at the end of the installation process automatically. Otherwise, you will need to manually start the Runtime server once you have defined it in the Customers Topology. For more information about the Runtime server registration process, refer to 4.4, Setting up the ITLM Runtime server on Windows on page 131. You should provide the following information regarding the Registration process: Customer Name. A Runtime server must be part of only one Customer organization. The value provided must respect the physical and logical policies you defined, according to the description in Physical design on page 52 and Logical design on page 59. Runtime server name. A Runtime server must have a logical name to be identified by the Administration server. This name must be unique for each Runtime server of your entire IBM Tivoli License Manager environment. We advise that you use the fully qualified host name, because this one must be unique in your network environment, according to the description in Physical design on page 52. Runtime server password. This password must be the same as used during the Runtime server definitions in the Customers Topology. If you have decided to create the Runtime server after the installation, you should provide the same
91
password during the registration process. We advise you to use the same password for all Runtime servers within the same Customer organization. However, in case of strong security requirements, one different password can be provided for each Runtime server. Administration server access. In order for the Runtime server to contact the Administration server, you should provide the following: Administration server IP address. You need to provide the IP address of the Administration server. The fully qualified hostname may also be used. Administration server TCP port. This port will be used to communicate with the Administration server. We recommend the use of the default HTTP or HTTPs ports. In case you plan to use a port other than the HTTP and HTTPS default ports, specify the new ports using this parameter. SSL activation. If you plan to use SSL as the communication protocol, you need to provide an SSL password. It will be used to encrypt the communication between the Administration server and the Runtime server. This password can be changed by using the command rtpasswd.bat in the <ITLM_INSTALL_DIR>/runtime/cli directory of the Runtime server. Note: At the end of the IBM Tivoli License Manager Runtime server installation, you need to create and populate the DB2 Database that will be used by the Runtime server. Refer to 4.3.2, Creating DB2 schema for Runtime server on AIX on page 124 for details.
92
Installation using a Software Distribution tool like IBM Tivoli Configuration Manager or Microsoft Systems Management Server. Note: Appendix A, ITLM Agent installation using IBM Tivoli Configuration Manager on page 253 provides an example of an IBM Tivoli Configuration Manager Software package to install Agents.
Hardware requirements
Table 3-13 lists the hardware requirements for the IBM Tivoli License Manager Agent.
Table 3-13 Hardware requirements for IBM Tivoli License Manager Agent
HW
Processor RAM Hard Disk Other Network
Intel Platforms
Any Any 10 MB N/A Ethernet or Token Ring card Network connectivity to the internet
Non-Intel Platforms
Any Any 10 MB N/A Ethernet or Token Ring card Network connectivity to the internet
For more information concerning the hardware requirements for IBM Tivoli License Manager, refer to the IBM Tivoli License Manager Systems Administrators Guide, GC23-4834.
Software requirements
The IBM Tivoli License Manager Agent is currently supported on the following platforms. Support for additional platforms may be addressed in future releases: Windows 95/98 Windows ME Windows 2000 Windows NT 4 Linux Red Hat 7.0 for Intel-kernel 2.2.16-22 Linux SuSE 7.2 for s390-kernel 2.2.16 Linux Red Hat 7.0 for s390-kernel 2.4.9-17 Sun Solaris 2.7/2.8 (64 bit kernel) IBM AIX 4.3/5.1 (32 bit kernel) Before starting the installation of the IBM Tivoli License Manager Agent, you should have installed the minimum product levels listed in Table 3-14.
93
Table 3-14 Software requirements for IBM Tivoli License Manager Agent
SW
Microsoft Internet Explorer 5.0 or higher Netscape Navigator 4.7.x or higher Netscape Navigator 4.7.9
Windows
X
Linux/SUN
IBM AIX
For a complete list of software requirements for IBM Tivoli License Manager, refer to the IBM Tivoli License Manager Systems Administrators Guide, GC23-4834.
Network considerations
The IBM Tivoli License Manager Agent doesnt listen on any TCP port. In fact the Runtime server never contacts the Agent; it is the agent itself which contacts the Runtime server at each defined elapsed time. During this connection, the Runtime server down calls some information on the Agent using ephemeral TCP ports.
94
A Computer label Each agent needs to be uniquely identified. This value can be based, for example, on the following information: Asset Tag number Fully qualified host name Serial number of the machine Logical name depending on the capabilities of the machine
This value will be used to match the Node object of the Customers Topology. If this Tag doesnt correspond to any Nodes, the Agent deployment process will create it.
This value will be used to match the Node object of the Customers Topology. If this Tag doesnt correspond to any Nodes, the Agent deployment process will create it. A Runtime Server By providing a Server Name, the agent will try to register to this server and will become an object of the Customers topology. The value of this field must be either the fully qualified host name or the IP address of the Runtime server. The value provided must respect the physical and logical policies you defined, according to the description in Physical design on page 52 and Logical design on page 59.
95
A TCP port This must be the Runtime server port. By default, the port is the default HTTP port which is 80. If you have planned to use another port the HTTP server, you have to provide the new value for this field. An URL This is the URL of the service process of the Runtime Server. The value must be set to /slmruntime/service. Customer name Even if an Agent will be part of a Division, you still need to provide the name of the Customer. The value you provided for the Division field must also be part of this Customers topology. The value provided for the Customer name must respect the physical and logical policies you defined, according to the description in Physical design on page 52 and Logical design on page 59. Proxy utilization This field cannot be empty, you have to provide either Yes or No as the value. The name of the proxy If you plan to use a proxy server to manage the data flow between the Runtime server and the Agent, you should provide either the fully qualified host name or the IP address of the Proxy server. If you dont plan to use a Proxy server, this field cannot be empty. You have to set this value to none. The port of the Proxy If you plan to use a proxy server to manage the data flow between the Runtime server and the Agent, you should provide the TCP port of the Proxy server. If you dont plan to use a Proxy server, this field cannot be empty. You have to set this value to 0. The trace activation You can enable the trace of the silent installation process. The possible value is y for yes and n for no. The name of the trace file is tlmia.trc and is located in the directory from where you start the installation of the Agent. Note: We advise you to put all of these arguments in double quotation marks ().
96
You can install this tool on any machine, but this component is normally installed on the same machine as the Administration server. The installation of the Catalog Manager doesnt require any specific information. To use it, you must extract the Catalog and Unknown File table from the Administration server Database. Once the changes are made, you must re-import the Catalog to the Administration server database.
97
98
Chapter 4.
99
LAN
As shown in Figure 4-1, our environment is composed of five machines, as follows: 1. IBM Tivoli License Manager Administration Server machine RS6000 running AIX 5.1
100
IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (plus Fixpack 7) IBM WebSphere Application Server Advanced Edition Version 4.0 (plus Fixpack 4) IBM HTTP Server Version 1.3.19.2 (Included in IBM WebSphere Application Server Advanced Edition Version 4.0) IBM Tivoli License Manager Administration Server Version 1.1 2. IBM Tivoli License Manager Runtime Server machine RS6000 running AIX 4.3.3 IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (plus Fixpack 7) IBM WebSphere Application Server Advanced Edition Version 4.0 (plus Fixpack 4) IBM HTTP Server Version 1.3.19.2 (Included in IBM WebSphere Application Server Advanced Edition Version 4.0) IBM Tivoli License Manager Runtime Server Version 1.1 3. IBM Tivoli License Manager Runtime Server machine Intel machine running Windows 2000 Advanced Server (plus Service pack 3) IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (plus Fixpack 7) IBM WebSphere Application Server Advanced Edition Version 4.0 (plus Fixpack 4) IBM HTTP Server Version 1.3.19.2 (Included in IBM WebSphere Application Advanced Server Edition Version 4.0) IBM Tivoli License Manager Runtime Server Version 1.1 4. IBM Tivoli License Manager Agent machines (5 Nos.) Intel machines running Windows 2000 Professional, Windows 2000 Advanced Server, AIX IBM Tivoli License Manager Agent Software 5. IBM Tivoli License Manager Web Client machines(2 Nos.) Intel machines running Windows 2000 Professional Internet Explorer 5.5
101
The installation process for each of the Administration and Runtime server machines will be explained in the following sections. The installation process for the IBM Tivoli License Manager Agents will be covered in 5.7.3, Deploying an Agent on a node on page 160.
1. Log in as a user with root authority, move to the directory where the DB2 7.2 Server for AIX CDROM is mounted, and start the DB2 setup utility, as follows:
# ./db2setup
2. The Install DB2 V7 screen, as shown in Figure 4-2, appears. Select the DB2 UDB Enterprise Edition option.
102
3. A New DB2 instance should be created for the Administration server database. We specified the DB2 instance name db2inst1, as shown in Figure 4-3.
103
4. Next, Figure 4-4 shows the values we used on the option Create the user ID for the DB2 Administration Server.
5. The installation process creates and sets the values of several environment variables, DB2SYSTEM, for example. 6. At the end of the installation process, you may check the installation log file created at /tmp/db2setup.log. 7. The installed JDBC code level needs to be upgraded to Version 2.0. You should log on to the system with a valid DB2 user ID, and issue the following commands: For bash, Bourne, or Korn shell:
# . INSTHOME/sqllib/db2profile # cd /INSTHOME/sqllib/java12/ # . ./usejdbc2
Where, INSTHOME is the home directory of the instance. Verify that the JDBC level is correct by entering the following command:
# echo $CLASSPATH
104
2. Unzip the Fixpack using the following command to get a tar file.
# gzip FP7_U484480.tar.Z
3. Un-tar the Fixpack using the following command to extract the file Fixpack files.
# tar -xvf FP7_U484480.tar
4. Run the following command to install Fixpack from the location you un-tar the Fixpack files.
# ./installFixpack
5. Key in the DB2 instance password if prompted. 6. The installation wizard copies the files and finishes the installation of Fixpack. Note: If you are using a 32-bit IBM DB2 Server, make sure to install the 32-bit Fixpack 7. Or if you are using a 64-bit IBM DB2 Server, make sure to install the 64-bit Fixpack 7.
2. You are then prompted to select the type of installation. We have selected Typical Installation, because it will automatically install all the required components, such as the WebSphere Application Assembly Tool (AAT). If you decide to use a different installation method, make sure you select the AAT option.
105
3. In the next panel, the installation wizard asks for the database information. WebSphere Server uses this database repository to store configuration information. In our scenario we used the local DB2 Server installed on the Administration machine.
Database type: DB2
4. On the next panel you need to specify the installation directories. We used the default values /usr/WebSphere/AppServer and /usr/HTTPServer. 5. A final installation window informs you that the setup program has finished. 6. When the installation of WebSphere completes successfully, the window shown in Figure 4-5 appears. Select Start the Application Server.
106
Where, WebSphere_Server can either be the Administration servers host name or IP address. 8. This step is for IBM WebSphere Application Server Version 3.5.6 only. On the Administrator Console window, expand Resources -> JDBC Drivers -> Db2JdbcDriver. Click Db2JdbcDriver. Update the Server Class Path with the fully qualified path of the DB2 file db2java.zip. 9. You should recycle the IBM WebSphere Application Server by issuing the following commands:
# cd /<WebSphere_AppServer_Install_Directory>/bin # ./stopServer.sh # ./startServer.sh
Where, <WebSphere_AppServer_Install_Directory> is the directory where you installed the IBM WebSphere Application Server. 10.The IBM WebSphere Application Server runs as root and requires access to the IBM DB2 environment. You should insert the following line at the end of roots .profile file:
./home/db2inst1/sqllib/db2profile
2. Un-tar the Fixpack using the following command to extract the file Fixpack files.
# tar -xvf was40_ae_ptf_4_aix.tar
3. Run the following command to install Fixpack from the location you un-tar the Fixpack files.
# ./install.sh
107
4. During the installation of this Fixpack, the setup prompts for many questions. These questions allow you to select the modules that the Fixpack will update. In our case, we answered No to iPlanet and Apache updates, because we were using IBM HTTP Server. 5. Start the WebSphere Server manually.
# cd /<WebSphere_AppServer_Install_Directory>/bin # ./startServer.sh
Where, <WebSphere_AppServer_Install_Directory> is the directory where you installed the IBM WebSphere Application Server. Note: In order to have both the IBM HTTP Server and the IBM WebSphere Application Server you may add startup entries in the inetd.conf file.
2. Make sure IBM HTTP Server is running. To start the HTTP Server, type:
# cd /usr/HTTPServer/bin # ./apachectl start
3. Make sure IBM WebSphere Application Server is running. To start it, type:
# cd /usr/WebSphere/AppServer/bin # ./startupServer.sh
4. To monitor the Administration server installation, you may run the IBM WebSphere Application Server Administration console, as shown in Figure 4-6. In case of a successful installation, the ITLM Administration server will show up in the list of Application Servers, right after the Default Server entry.
# cd usr/WebSphere/AppServer/bin # ./adminclient.sh
108
To install IBM Tivoli License Manager Administration server on AIX, go through the following steps: 1. From the directory where the IBM Tivoli License Manager CDROM is mounted, enter the following command to initialize the installation wizard. For AIX, run the setupaix.bin script. It is located in setup directory of your CDROM.
# cd TLM11/setup # ./setupaix.bin
2. When the installation wizard displays the welcome to the IBM Tivoli License Manager Version 1.1 - server installation window, click Next to continue. 3. The installation wizard displays the next panel that shows you the License Agreement Panel. Click the option I accept, then Next to continue. 4. The dialog window for the IBM Tivoli License Manager installation directory appears. We used the default value /opt/IBM/TLM. Click Next. 5. The next panel enables you to select the installation type. There are three options. Administration, Runtime, and Custom. Select Administration,
109
because we are installing the Administration server. This is shown in Figure 4-7. Click Next to continue.
6. The next window prompts you for the home directory of DB2 instance. We used the default: /home/db2inst1. Click Next. 7. The installation wizard then asks for the password for the user tlmsrv. This user will be used to connect and access the Administration database. This user will be created during the installation. Click Next. Note: In case you decide to install Administration Server and Runtime Server in the same machine, this password is valid for both databases. 8. The confirmation dialog window of the various ITLM features to be installed appears, as shown in Figure 4-8. Click Next to start the installation.
110
9. This completes the first phase of the Administration server installation. In the next window, the installation wizard displays the message saying it has successfully completed the installation. Click Next to proceed with the installation process. Note: At this point you have to make sure WebSphere is running. If WebSphere is not running, the WebSphere configuration will fail and you will not be able to have the Administration server connected to the IBM WebSphere Application Server.
10.The installation wizard will now configure IBM WebSphere Application Server to recognize the newly installed ITLM Administration server. The configuration process may take a few minutes to complete. After completing the configuration, the installation wizard informs you it has successfully completed the configuration. Click Finish to exit the installation.
111
Note: If WebSphere is not running during this phase, the installation will immediately finish the WebSphere configuration stating it has successfully configured the application server. The configuration, of course has not occurred. 11.Now you should start Tivoli License Manager Administration server component. Open the WebSphere Administration Console and check if Tivoli License Manager Administration Server appears below the WebSphere Default Server, as shown in Figure 4-9. It will be in the list of Application Servers. To start the WebSphere Administration Console, issue the following commands:
# cd usr/WebSphere/AppServer/bin # ./adminclient.sh
112
If you are not able to see the Administration Server in the WebSphere Administration Console, refer the IBM Tivoli License Manager Systems Administrators Guide, GC23-4834, for troubleshooting.
3. Check that the DB2 command line is initialized. To do this, enter the command:
$ db2
Type quit to exit and return to the $ shell. 4. If the DB2 command line is not initialized, you must load the DB2 environment. To do this, change to directory /home/db2inst1/sqllib and enter the command:
# . ./db2profile
6. Enter the password for the DB2 instance owner when requested.
113
Note: In case you enter the wrong password, you have to drop the database and run the dbsetup.sh script again:
# db2 drop database tlma # . ./dbsetup.sh
If there is more than one entry like this, find the latest one. 3. Note the <service> value. 4. Log on as the DB2 instance owner to the system where the DB2 Server and Administration server is installed. 5. Load the DB2 environment:
# cd /home/db2inst1/sqllib # . ./db2profile
6. Catalog the tlma database: Because we installed our Administration server and the tlma database on the same machine, we used the following commands:
# db2 uncatalog node <host> # db2 catalog tcpip node <host> remote 127.0.0.1 server <noted value> # db2 catalog database tlma as tlmadb at node tlmnode
If you have the database and server installed on different machines, you have to follow these commands instead:
# db2 catalog tcpip node <host> remote <remote host> server <noted value> # db2 catalog database <database name> as <cataloged name> at node <host>
Where, the values of variables are as follows: <host> The host name or IP address of the machine where the DB2 Server is installed.
114
<noted value> The value you found in the services file. This is a port number if the DB2 Server is on a Windows machine, and a server name if the DB2 server is on an AIX machine.
It is a good idea to backup this file in the same directory before you make any changes to this file.
# cp httpd.conf httpd.conf.ori
2. Example 4-1 shows the entries to added at the end of the http.conf file.
Example 4-1 Changes in the httpd.conf file for UNIX environment
# Load the SSL module for ITLM data encryption between Admin Server and # Runtime Server LoadModule ibm_ssl_module libexec/mod_ibm_ssl_128.so AddModule mod_ibm_ssl.c Listen 443 <VirtualHost IPADDR:443> SSLEnable SSLClientAuth none ServerName HOSTNAME ErrorLog logs/ssl.error_log CustomLog logs/ssl.access_log common Keyfile "/opt/IBM/TLM/admin/keystore/key.kdb" SSLV2Timeout 40 SSLV3Timeout 120 LogLevel debug </VirtualHost> SSLDisable
In Example 4-1, replace IPADDR and HOSTNAME with the IP address and host name of your Administration server. In the Keyfile entry, make sure you use your Administration server installation directory. You must restart the HTTP Server for the changes to take effect.
115
Note: If you plan to install the Administration server on Windows, your http.conf file needs to changed with the following entries:
# Load the SSL module for ITLM data encryption between Admin Server and Runtime Server LoadModule ibm_ssl_module modules/IBMModuleSSL128.dll Listen 443 <VirtualHost IPAADDR:443> SSLEnable SSLClientAuth none ServerName HOSTNAME ErrorLog logs/ssl.error_log CustomLog logs/ssl.access_log common Keyfile "c:/IBM/TLM/admin/keystore/key.kdb" SSLV2Timeout 40 SSLV3Timeout 120 LogLevel debug </VirtualHost> SSLDisable
3. Open the WebSphere Administration Console on the Administration server. 4. Select Virtual Hosts. Make sure there is a host alias entry for the port 443, as shown in Figure 4-10.
116
117
3. Change the #Mail Settings section with appropriate values: smtpServer Enter the host name or IP address of a valid SMTP server. This server will be used to forward the e-mail communications generated by the servers notification component. You can enter the e-mail address to which notifications are to be sent. This setting is optional. Enter the e-mail address that is to be used by the server as the sender address when notifications are generated.
Note: If the Administration server is installed on the same machine as a Runtime server, there are two system.properties files, one in each installation directory. You must define settings in both files to enable both types of notification. The e-mail is not generated if the settings for the SMTP server and the mail sender are not present or not valid.
118
IBM HTTP Server Version 1.3.19.2 (Included in IBM WebSphere Application Server Advanced Edition Version 4.0). IBM Tivoli License Manager Runtime Server Version 1.1.
2. Make sure IBM HTTP Server is running. To start the HTTP Server, type:
# cd /usr/HTTPServer/bin # ./apachectl start
3. Make sure IBM WebSphere Application Server is running. To start it, type:
# cd /usr/WebSphere/AppServer/bin # ./startupServer.sh
4. To monitor the Runtime server installation, you may run the IBM WebSphere Application Server Administration console, as shown in Figure 4-6 on page 109. In case of a successful installation, the ITLM Runtime server will show up in the list of Application Servers, right after the Default Server entry.
# cd usr/WebSphere/AppServer/bin # ./adminclient.sh
To install IBM Tivoli License Manager Runtime server on AIX, go through these: 1. From the directory where the IBM Tivoli License Manager CDROM is mounted, enter the following command to initialize the installation wizard. For AIX, run the setupaix.bin script. It is located in setup directory of your CDROM.
# cd TLM11/setup # ./setupaix.bin
2. When the installation wizard displays the welcome to the IBM Tivoli License Manager Version 1.1 - server installation window, click Next to continue. 3. The installation wizard displays the next panel that shows you the License Agreement Panel. Click the option I accept, and then Next to continue. 4. The dialog window for the IBM Tivoli License Manager installation directory appears. We used the default value /opt/IBM/TLM. Click Next.
119
5. The next window enables you to select the installation type. There are three options: Administration, Runtime, and Custom. Select Runtime, because you are installing the Runtime server. This is shown in Figure 4-11. Click Next to continue. .
6. The next panel prompts you for the home directory of DB2 instance. We used the default: /home/db2inst1. Click Next. 7. The installation wizard then asks for the password for the user tlmsrv. This user will be used to connect and access the Administration database. This user will be created during the installation. Click Next. 8. The following window, shown in Figure 4-12, appears specifically for the Runtime Server installation. These settings are used to authenticate communication between the Runtime server and Administration server. In this window, the installation wizard displays the following options. Click Next to continue. Customer name Mention the name of customer for whom you are installing this Runtime Server. In case this customer has already been defined in the
120
Administration server, the name must match exactly. Runtime Server name Runtime server password Enter the host name for this Runtime server. Specify the password. This password will be used to authenticate this Runtime server when communicating with the Administration server.
Note: These settings are used to authenticate communication between the Runtime server and the Administration server. You must be careful to enter them correctly, both here and when you later register the Runtime server on the Administration server Web interface. If there is any discrepancy between the values entered when installing and registering the server, the Runtime server cannot be plugged into the Administration server. The values you enter for Customer name and Runtime server name must contain only US ASCII characters.
121
9. In the next window, shown in Figure 4-13, you need to specify information to enable the Runtime server to communicate with the Administration server. Enter the following: a. Identify the host machine of the Administration server by entering the host name or the IP address in the Administration server address field. b. The port number for communication. The default for un-encrypted communications is 80. For secure (SSL) communications enter 443. c. Choose the appropriate radio button to specify whether communications with the Administration server, initiated by this Runtime server, should be encrypted. d. If encrypted, enter the SSL Password and confirm it. After the installation, you must follow the instructions given in 4.2.8, Setting up SSL configuration on page 115 to enable the Administration server for SSL and complete the configuration of the Runtime server as an SSL client.
10.The confirmation dialog window of the various ITLM features to be installed appears as shown in Figure 4-14. Click Next to start the installation.
122
11.This completes the first phase of the Runtime server installation. In the next panel, the installation wizard displays the message saying it has successfully completed the installation. Click Next to proceed with the installation process. Note: At this point you have to make sure WebSphere is running. If WebSphere is not running, the WebSphere configuration will fail and you will not be able to have the Runtime server connected to the IBM WebSphere Application Server.
12.The installation wizard will now configure IBM WebSphere Application Server to recognize the newly installed ITLM Runtime server. The configuration process may take a few minutes to complete. After completing the configuration, the installation wizard informs you it has successfully completed the configuration. Click Finish to exit the installation. Note: If WebSphere is not running during this phase, the installation will immediately finish the WebSphere configuration stating it has successfully configured the application server. The configuration, of course, has not occurred.
123
13.Now you should start Tivoli License Manager Runtime server component. Open the WebSphere Administration Console and check if Tivoli License Manager Runtime Server appears below the WebSphere Default Server, as shown in Figure 4-15. It will be in the list of Application Servers. To start the WebSphere Administration Console, issue the following commands:
# cd usr/WebSphere/AppServer/bin # ./adminclient.sh
If you are not able to see the Runtime server in the WebSphere Administration Console, refer to the IBM Tivoli License Manager Systems Administrators Guide, GC23-4834, for troubleshooting.
124
server. In case you decide to use a separate DB2 server, this procedure should be performed on that machine. For creating the DB2 database schema, you have to run the dbsetup.sh script. This script will create a database named tlmr and is located in the opt/IBM/TLM/runtime/db/db2/ directory. Follow this procedure to create and populate the database: 1. Log on to the DB2 server machine with a user with root authority. 2. Switch to DB2 instance owner, in our case db2inst1:
# su - db2inst1
3. Check that the DB2 command line is initialized. To do this, enter the command:
$ db2
Type quit to exit and return to the $ shell. 4. If the DB2 command line is not initialized, you must load the DB2 environment. To do this, change to directory /home/db2inst1/sqllib and enter the command:
# . ./db2profile
6. Enter the password for the DB2 instance owner when requested. Note: In case you enter the wrong password, you have to drop the database and run the dbsetup.sh script again:
# db2 drop database tlmr # . ./dbsetup.sh
125
To catalog the tlmr database, follow these steps: 1. Log on to the machine where the DB2 server is installed as a user with root authority. 2. Check the contents of the services file:
# more /etc/services
If there is more than one entry like this, find the latest one. 3. Note the <service> value. 4. Log on as the DB2 instance owner to the system where the DB2 Server and Runtime server is installed. 5. Load the DB2 environment:
# cd /home/db2inst1/sqllib # . ./db2profile
6. Catalog the tlmr database: Because we installed our Runtime server and the tlmr database on the same machine, we used the following commands:
# db2 uncatalog node <host> # db2 catalog tcpip node <host> remote 127.0.0.1 server <noted value> # db2 catalog database tlmr as tlmrdb at node tlmnode
If you have the database and server installed on different machines, you have to use these commands instead:
# db2 catalog tcpip node <host> remote <remote host> server <noted value> # db2 catalog database <database name> as <cataloged name> at node <host>
Where, the values of variables are as follows: <host> The host name or IP address of the machine where the DB2 Server is installed.
<noted value> The value you found in the services file. This is a port number if the DB2 Server is on a Windows machine, and a server name if the DB2 server is on an AIX machine.
126
To configure event notification on Runtime server, you should define some parameters to be used to send notifications in the system.properties file of the Runtime server. These parameters include: 1. The name of the mail server 2. The mail engine to be used 3. The e-mail address to which notifications are to be sent You can also set one mail recipient to receive notifications in addition to the administrators you have defined. This additional recipient does not need to be an administrator. To define notification settings for the Runtime server, complete these steps: 1. Log on to the Runtime server with a user with root authority. 2. Open the system.properties file in a text editor.
vi /opt/IBM/TLM/runtime/conf/system.properties
3. Change the #Mail Settings section with appropriate values: smtpServer Enter the host name or IP address of a valid SMTP server. This server will be used to forward the e-mail communications generated by the servers notification component.
mailRecipient You can enter the e-mail address to which notifications are to be sent. This setting is optional. mailSender For example:
#Mail Settings smtpServer=itlm_mail.itlm.com mailEngine=Internal mailRecipient=ani@itlm.com mailSender=itlm_a_aix@itlm.com
Enter the e-mail address that is to be used by the server as the sender address when notifications are generated.
Note: If the Administration server is installed on the same machine as a Runtime server, there are two system.properties file, one in each installation directory. You must define settings in both files to enable both types of notification. The e-mail is not generated if the settings for the SMTP server and the mail sender are not present or not valid.
127
2. Key in the appropriate user name and password. The default user name is tlmroot and default password is system. 3. As shown in Figure 4-16, select the customer for which you want to register the Runtime server.
128
4. In the portfolio, click Topology. When the Topology item expands to show a list of sub-items, click Servers. 5. Because this is the first Runtime server in the organization, you will see the following window as shown in Figure 4-17. Click Create.
6. Complete the form with the requested details as shown in Figure 4-18. Click Finish. Name Password The host name of the Runtime server you wish to register with the Administration server. The password of the Runtime server you entered during the installation process. This password is used for the communication between Runtime and Administration server. The IP address of the Runtime server Port is 80 by default. This port is used for the communication between the Runtime server and the agents that will be connected to it.
Address port
129
When you submit the server information, the Runtime server will be plugged in to the Administration server and is ready for use. This is shown in Figure 4-19.
130
These are common causes of failure when plugging in Runtime servers: The Runtime server name entered does not match the name of any installed server. The Runtime server name entered identifies a server that does not belong to the customer you are working with. The password you entered does not match the Runtime password that was specified when the server was installed. If any of these problems occur, an entry is made in the event.log file, which is located on the Administration server machine, in the folder: <TLM_INSTALL_DIR>\admin\log
131
This machine will serve as the host for the Agents connected to it. The following components are needed: IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (plus Fixpack 7) IBM WebSphere Application Advanced Server Edition Version 4.0 (plus Fixpack 4) IBM HTTP Server Version 1.3.19.2 (Included in IBM WebSphere Application Advanced Server Edition Version 4.0) IBM Tivoli License Manager Runtime Server Version 1.1
132
4. The Select Installation Type window opens. Select the installation type you prefer. We selected Typical. 5. For the installation directory we used C:\db2. 6. For the DB2 administrative user, we selected db2admin. 7. After the installation wizard copies the DB2 files onto the machine, the Install OLAP Starter Kit window opens. Select Do not install the OLAP Starter Kit and then Finish. 8. Update Java. The installed JDBC code level needs to be upgraded to Version 2.0. You should open a DOS-command prompt window and issue the following commands:
cd DB2_DIR\java12 usejdbc2
Where, DB2_DIR is the DB2 installation directory. The usejdbc2 command will copy the appropriate version of db2java.zip into the DB2_DIR\java12 directory. 9. Reboot the machine.
133
If you are installing the Fixpack by using the Administrator account of Windows 2000 Advanced Server, please make sure you complete the following steps. Click on Start -> Programs -> Administrative Tools -> Local Security Settings -> User Rights Assignment. In the window you will see lists of user rights. Make sure the Administrator account has the following rights: Act as part of Operating System Create a token object Increase quotas Replace a process level token Note: Once you have installed a Fixpack, you wont be able to un-install it. 1. Stop all database activity before applying this Fixpack. To stop all database activity, enter this in a DB2 command window:
c:\db2\sqllib\bin:\>db2stop c:\db2\sqllib\bin:\>db2admin stop
2. Unzip and extract the Fixpack files to a temporary directory. 3. Run the following command to install the Fixpack from the Fixpack directory.
c:\fp7_wr21311\setup.exe
4. Key in the DB2 instance owner password if the setup prompts for it and click Next. 5. The wizard shows the selection window, click Next to continue. 6. As soon as the installation ends, reboot the machine.
134
2. You are then prompted to select the type of installation. We have selected Typical Installation, because it will automatically install all the required components, such as the WebSphere Application Assembly Tool (AAT). If you decide to use a different installation method, make sure you select the AAT option. 3. In the following window you should specify the installation directories. We used the default values C:\WebSphere\AppServer and C:\IBM HTTPServer. 4. In the next panel, the installation wizard asks for the database information. WebSphere uses this database repository to store configuration information. In our scenario we used the local DB2 Server installed on the Runtime server machine.
Database type: DB2
The DB2 instance owner user ID, password, and home directory:
Database user id: db2admin Database password: Database Path: c:\db2\sqllib
5. A final installation window informs you that the setup program has finished. 6. When the installation of WebSphere completes successfully, the screen, shown in Figure 4-5 appears. Select Start the Application Server. 7. Open a Web Browser and type in the following URL:
http://WebSphere_Server:9090/admin
Where, WebSphere_Server can either be the Runtime server host name or IP address. 8. This step is for IBM WebSphere Application Server Version 3.5.6 only. On the Administrator Console window, expand Resources -> JDBC Drivers -> Db2JdbcDriver. Click Db2JdbcDriver. Update the Server Class Path with the fully qualified path of the DB2 file db2java.zip. 9. You should recycle the IBM WebSphere Application Server by issuing the following commands:
Start Menu -> Programs -> IBM WebSphere -> Application Server V4.0 AE ->Stop Admin Server
Then issue:
Start Menu -> Programs -> IBM WebSphere -> Application Server V4.0 AE ->Start Admin Server
135
Note: IBM HTTP Server and IBM WebSphere may not start automatically after restarting the machine. In this case you will have to start it manually. For Windows you may open the Services panel and change the startup option for IBM HTTP Server and IBM WebSphere from Manual to Automatic. On Windows, if you plan to use IBM HTTP Server, you may have to either stop MS IIS Server or change its HTTP port.
4. During the installation of this Fixpack, the setup prompts many questions. These questions allow you to select the modules that the Fixpack will update. In our case we answered No to iPlanet updates and Apache updates, because we use the IBM HTTP Server.
136
1. From the directory where the IBM Tivoli License Manager CDROM is mounted, enter the following command to initialize the installation wizard. It is located in setup directory of your CDROM.
setupwin32.exe
2. When the installation wizard displays the welcome to the IBM Tivoli License Manager Version 1.1 - server installation window, click Next to continue. 3. The installation wizard displays the next panel that shows you the License Agreement Panel. Click the option I accept and then Next to continue. 4. The dialog window for the IBM Tivoli License Manager installation directory appears. We used the default value C:\IBM\TLM. Click Next. 5. The next panel enables you to select the installation type. There are three options: Administration, Runtime, and Custom. Select Runtime, because you are installing the Runtime server. This is shown in Figure 4-11 on page 120. Click Next to continue. 6. The next panel prompts you for the home directory of DB2 instance. We used C:\DB2\SQLLIB. Click Next. 7. The installation wizard then asks for the password for the user tlmsrv. This user will be used to connect and access the Administration database. This user will be created during the installation. Click Next. 8. The following panel, shown in Figure 4-12 on page 121, appears specifically for Runtime server installation. These settings are used to authenticate communication between Runtime server and Administration server. In this panel, the installation wizard displays the following options. Click Next to continue. Customer name Mention the name of customer for whom you are installing this Runtime Server. In case this customer has already been defined in the Administration server, the name must match exactly. Enter the host name for this Runtime server. Specify the password. This password will be used to authenticate this Runtime server when communicating with the Administration server.
137
Note: These settings are used to authenticate communication between the Runtime server and the Administration server. You must be careful to enter them correctly, both here and when you later register the Runtime server on the Administration server Web interface. If there is any discrepancy between the values entered when installing and registering the server, the Runtime server cannot be plugged in to the Administration server. The values you enter for Customer name and Runtime server name must contain only US ASCII characters. 9. In the next panel (as shown in Figure 4-13 on page 122), you need to specify information to enable the Runtime server to communicate with the Administration server. Enter the following: a. Identify the host machine of the Administration server by entering the host name or the IP address in the Administration server address field. b. The port number for communication. The default for un-encrypted communications is 80. For secure (SSL) communications enter 443. c. Choose the appropriate radio button to specify whether communications with the Administration server, initiated by this Runtime server, should be encrypted. d. If encrypted, enter the SSL Password and confirm it. After the installation, you must follow the instructions given in 4.2.8, Setting up SSL configuration on page 115 to enable the Administration server for SSL and complete the configuration of the Runtime server as an SSL client. 10.The confirmation dialog window appears, as shown in Figure 4-21. Click Next to start the installation.
138
11.This completes the first phase of the Runtime server installation. In the next panel, the installation wizard displays the message saying it has successfully completed the installation. Click Next to proceed with the installation process. Note: At this point you have to make sure WebSphere is running. If WebSphere is not running, the WebSphere configuration will fail and you will not be able to have the Runtime server connected to the IBM WebSphere Application Server.
12.The installation wizard will now configure the IBM WebSphere Application Server to recognize the newly installed ITLM Runtime server. The configuration process may take a few minutes to complete. After completing the configuration, the installation wizard informs you it has successfully completed the configuration. Click Finish to exit the installation. Note: If WebSphere is not running during this phase, the installation will immediately finish the WebSphere configuration stating it has successfully configured the application server. The configuration, of course, has not occurred.
139
13.Now you should start the Runtime server. Open the WebSphere Administration Console and check if the Runtime Server appears below the WebSphere Default Server (as shown in Figure 4-15 on page 124). It will be in the list of Application Servers. To start the WebSphere Administration Console, issue these commands:
Start Menu -> Programs -> IBM WebSphere -> Application Server V4.0 AE -> Administrators Console
If you are not able to see the Tivoli License Manager Administration Server in WebSphere Administration Console, refer the IBM Tivoli License Manager Systems Administrators Guide, GC23-4834, for troubleshooting.
140
4. When requested, enter the password for the user you have logged on as. Note: In case you entered the wrong password, just drop the database and run the dbsetup.bat script again:
db2 drop database tlmr dbsetp.sh
Note: In case your DB2 Server and Runtime server are installed in different machines, you need to create an ODBC connection on the Runtime server to the tlmr database: 1. Run the DB2 Client Configuration Assistant. 2. Click Add and select Search the network. 3. Find the DB2 server machine and select the tlmr database from the list of local databases. 4. In the ODBC folder, clear the check box Register this Database for ODBC. 5. Click Finish.
141
server on page 126 and use the system.properties file located at the C:\IBM\TLM\runtime\conf\ directory.
142
Chapter 5.
143
Managing IBM Tivoli License Manager components Managing software entitlement and license pool details Managing software product components
144
LAN
Finance
HR
IT
Legal
As shown in Figure 5-1, a typical IBM Tivoli License Manager environment consists of: 1. One Administration Server 2. One or more Runtime Servers depending on the number of agents deployed 3. Agents deployed to the various nodes within the customer organization Once the infrastructure has been built, the key aspect in the administration of the IBM Tivoli License Manager environment is analyzing and understanding the customer environment. Through this due diligence, we can begin configuring the
145
administration pieces of IBM Tivoli License Manager. Also from this initial leg work we can determine the following: How the Divisions will be configured in the IBM Tivoli License Manager environment Scheduling of the inventory scans by Division Establish appropriate license pools based on the customers contractual license agreements with software vendors
146
IT standards All the support documentation already in place that may direct the configuration of IBM Tivoli License Manager in the IT infrastructure already in place. Define the customers security and privacy requirements. This will determine who has access to reports and what level of detail should be included in the reports.
147
148
Hub Support/System Architect This persons main role is to configure, install, and test the IBM Tivoli License Manager infrastructure. They develop and maintain the IBM Tivoli License Manager infrastructure including manually deploying, installing, and configuring the ITLM Administration and Runtime servers. Customer Administrator/License Administrator This is the primary individual responsible for the delivery of all the license management services to the account according to contractually defined service level agreements. Responsibilities also include: They identify customer requirements for software license allocations Manually load the information pertaining to procured licenses Audit software licenses Monitor software usage Reconciling and reporting exceptions Allocating and recording software licenses Report Administrator This role can be given to a number of individuals and they are responsible for running the reports that are available within the IBM Tivoli License Manager application. Some run the realtime reports from the Runtime servers, others also run the historical reports available from the Administration server, as well as extract/create new reports using the Tivoli Data Warehouse Reports Interface.
149
unique area for each and every customer. The definition and scope of this part of the logical design will be driven out from the analysis and planning part of the project. For the CSI Corp example we decided to concentrate on a few well known software applications. The applications and their licenses are listed below: IBM Lotus Notes 5.0 - 5000 licenses Microsoft Internet Explorer 6.0 - 1000 licenses Oracle 8 Enterprise Edition 8.0.4 - 50 licenses Adobe Framemaker 6.0 - 3 licenses In our lab we created entitlement settings and license pools based on this licensing information. Refer to 5.8, Managing software entitlement and license pool on page 166.
Produce reports
In our CSI Corp. example the report administrator produced the reports for the fictitious customer. The Customer administrator created the report administrators and they subsequently logged on to the Administration server or Runtime server to generate the reports depending on whether they needed to provide the customer with historical usage reports or real time usage reports.
150
Note: IBM Tivoli License Manager is a Web-based solution and therefore, through a Web browser, all administration tasks can be performed by accessing the IBM Tivoli License Manager Web interfaces. 1. Using a browser, access the Administration server logon page:
http://<server name>:<port>/slmadmin/logon
Upon initial login to IBM Tivoli License Manager we must use the following: User Name: tlmroot Password: system The user name and password are the defaults provided by the IBM Tivoli License Manager product and allows us to login and create Customer accounts and administrator accounts for these Customers. 2. In the portfolio (My Work area), click Administration, then when the Administration item expands to show a list of sub-items, as shown in Figure 5-2, click Customers, and then click Create.
151
3. As shown in Figure 5-3, enter the details of a customer whose licenses you are managing. As you can see we used a fictional company called CSI (CanSwissInd Corp.). When selecting Finish, the Customer details are recorded in the Administration server database. You will receive a validation window that the Customer has been created.
For more detailed instructions, refer to the IBM Tivoli License Manager License Administrators Guide, GC23-4833.
152
1. In the portfolio, click Administration. The Administration item expands to show a list of sub-items. Click Accounts and then click Create. A window similar to Figure 5-4 appears.
2. Enter the details of the user who is to be allowed access to the Web interface. If the administrator is to receive notifications, you must specify the e-mail address to which the notifications are to be sent. 3. Click Finish, and the account details will be recorded in the Administration server database, and you will receive a validation screen that the account has been created.
153
1. In the portfolio, click Administration. The Administration item expands to show a list of sub-items. Under Accounts there will be the list of existing accounts. In our example we selected csiadmin and Change.
2. Since csiadmin is a new account we must select a Customer that this administrator will manage. We must also select a profile for this account, as shown in Figure 5-5. The role defines the users level of access to the Administration server functions, as follows: Administrator Licensing Manager Other The user can perform all tasks on the Administration server Web interface. The user can perform the licensing tasks that are accessed using the Software Entitlement menu option. The user can request any report.
3. Click Finish, and a validation screen will appear confirming the account has been updated.
154
2. In the portfolio, click Administration. A list of accounts is shown. Select Create. Enter the details of the user who is to be allowed to access the Web interface on the Runtime server and who will receive event notifications from the Runtime server. In our example, to ease administration, we decided on creating all ITLM administrator using the same login name: csiadmin.
Note: You will notice that the portfolio options are much fewer on the Runtime server than on the Administration server. From the Runtime server the only options available are the administration option to create administrators and the Software Usage option to run realtime software usage reports on all agents registered with that Runtime server.
155
3. Click Finish. You will receive a validation window that the account has successfully been created.
156
2. Complete the form with the requested details. For more information on completing this form, refer to Chapter 4, Getting IBM Tivoli License Manager up and running on page 99. Information can also be found in the IBM Tivoli License Manager License Administrators Guide, GC23-4833.
157
3. Click Finish. You will receive a validation window that the server has been successfully created. Once you submit the server information, the Runtime server is plugged in to the Administration server and is then ready for use. Note: There is a configuration setting in the system.properties file for the time period for the Runtime server to try a plugin, therefore depending on this setting the Runtime server may not plug in right away. Figure 5-9 shows that the Runtime server (TLM02) from our lab environment defined for the CSI Corp. has been successfully plugged.
158
If any problems occur and the Runtime server fails to plugin to the Administration server, an entry is made in the event.log file, which is located on the Administration server machine, in the folder: <TLM_INSTALL_DIR>\admin\log. This log file can be used for problem determination by the Hub administrator.
159
1. On the Administration server when you first login, select the Customer from the pull down menu then in the portfolio, click Topology. When the Topology item expands to show a list of sub-items, click Divisions and then Create.
2. Assign a name and description for that Division. Click Finish, and you will receive a validation window that the Division has been successfully created. The creation of Divisions is integral in the IBM Tivoli License Manager environment, it is a logical grouping for the agents. Having agents grouped makes it possible to define different frequencies of inventory scans for different groups, select groups of agents for reporting, and limit access to license pools to a specific group or groups of agents.
160
the outsourcer and the customer. The methods are either Web-based or silent mode. Both of these methods require working closely with the customer to gather pertinent information and are described as follows:
161
Division
Select the Division from the drop down list, this will usually be the department the end-user belongs to or any grouping that the customer has decided to use. Select the Runtime server that the Agent will use from the drop down list, this information will have to be provided to the end user.
Server
Computer Label This will be the unique identifier that will be used in the customer environment. It could be an asset tag or any other unique identifier that the customer already is using within their environment or asset management system. 3. Click Finish. Standard security warnings for downloading from a Web site appear. Accept the security warnings by clicking Yes and the registration process will complete with a successful message. As you can see the registration process is quite straight forward, where an end user would not have much difficulty performing this task. If this method is the one to be used to deploy the agents, then the process is as follows: Work with the customer to define Divisions prior to deployment Draft communications letter and send out to the end-users members of each Division within the customer organization Have a company resource designated to respond to problems during deployment The communications letter can contain a link to the Runtime registration URL and the name of the Runtime server that the individual can select from the pull down menu once at the registration page. A sample communications letter may look something like the one shown in Figure 5-12.
162
Beginning contract start date __, 2002, CSI Corporation has contracted with the IT company to provide multiple IT services in an effort to reduce costs, improve IT effectiveness, etc. The IT company, in response for customer requirements is deploying an unique management mechanism to aid us in optimizing our Software Licenses.
This is to inform you that you have been selected for the rollout of this leading-edge technology used for Software License Management. The deployment will begin DATE . You will see no major changes to your IT environment, you simply need to register for the service as follows:
http://<servername>/slmruntime/register Please select the following options from the drop down menus: Division===========> Your department Server============> tlm02.csi.com Computer Label=====> Asset Tag affixed on your machine Fill the web form and click the register button
This transition to a Software License Management strategy is consistent with CSI Corps goals to standardize and improve effectiveness of our IT Hardware and Software environment in support of our business objectives.
Additional information about the Software License Management service may be directed to customer contact and phone or email address. For inquiries or problems experienced during the rollout, you may contact agreed-to help desk, or other IT company resource designated to respond to problems. Thank you for your cooperation.
Figure 5-12 Sample Agent deployment communication letter
163
164
Schedule the scans of different Divisions at different times, to reduce network traffic. We advise you to schedule the scans at off hour times or if a wake on lan (meaning a machine that is not active, but awakes in the event of a request) solution is deployed in the customer environment, then schedule the scans at times when the network traffic is a minimum. To schedule inventory scans, complete these steps on the Administration server: 1. In the portfolio, click Software Inventory, and then when the configuration item expands to show a list of sub-items, click Scheduling. Select a Division from the drop down list and click Next.
2. Complete the requested information based on what has been decided for that particular Division, and then select Finish. A message stating the inventory scan schedule has been successfully completed appears.
165
166
the application AutoCad for this application only a select number of users may need access to this application, those users can belong to the same Division or they can belong to different Divisions throughout the company. Therefore one way to control the use of this application is to create a license pool that is available only to those particular users, instead of allowing the defaults which means that the license is available to the entire enterprise. As already stated, this is driven by the customer and their particular needs. Therefore it is extremely important to understand what the customers needs and expectations are and they will vary from one customer to the next, but IBM Tivoli License Manager is flexible to cater to each and every customers desires.
167
2. Complete the form shown in Figure 5-14 as follows, and then click Next: SW Vendor Select All to allow selection of products from all vendors or select one or more vendors and limit selection of products supplied by those vendors. Select All to allow selection of products installed on all platforms or select one or more platforms and limit selection to products installed on those platforms.
Platform
Product Name To limit the selection criteria by product name matching, enter part of a product name, preceded, followed, or surrounded by wildcard characters (%). All products that have names that match the characters you enter are available for selection on the next form. Leave the field blank if you do not want to use product name matching. Include Indicate whether your selection should include products that already have settings, or products that do not have settings, by selecting the appropriate radio button.
168
3. Select the desired product from the scroll down list provided, and then click Next to show the license information about the product you selected.
4. Complete the Product Settings section, shown in Figure 5-15, by selecting radio buttons as follows: Software monitoring Select Enabled if you want to track the presence and use of this product using IBM Tivoli License Manager. Otherwise, select Disabled. Select User-defined if you want to define license pools for this product. Select Default to use default license pool settings. In this case there is no need to create any license pools as a set of default license rules applies, which states that the entire enterprise can use this product and it is not restricted to a particular Division or set of users. Any license pools that exist are ignored. Run offline Select Yes if the product can be used when there is no connection between the Agent and the Runtime server. Otherwise select No.
License control
169
If you select Yes, the product can be used in off-line mode and no license checks will be made. License rules can be applied only when the Agent is connected to the Runtime server. Server Response Select Required if the agent must wait for a server response before allowing the application to start. Select Not required if the application can start before a response from the Runtime server has been received.
170
2. Complete the Manage License Settings form, shown in Figure 5-16, as follows: Capacity Type Select a capacity type from the drop-down list. The capacity type controls how the number of licenses required is determined when a product starts. There are a number of options, which are: Users Memory Processors Online Processors Configured Disks
Each of these options allows for how a license is assigned when a product starts, for instance, if we select Disks then the number of licenses assigned is equal to the number of hard disks on the requesting node; and, if we select Users, then a license is assigned for each node that starts the application. This allows for different types of license assignment. For instance, if we wanted to monitor the licenses on a mainframe, then we can use either the memory or processors online options. But for the majority of the customers many select the users option. In our case scenario with CSI Corp., we chose
171
Users as the capacity type. Refer to the IBM Tivoli License Manager License Administrators Guide, GC23-4833, for a full description of the options. Hard Stop If you select Yes, the number of licenses available is an absolute maximum. It means that once all licenses are in use, the next license request is refused and the application cannot start. If you select No, the number of licenses available is not an absolute maximum. Once all licenses are in use, the next license request causes a warning event to be generated, but the application is allowed to start. Multi-instance This setting controls the situation where a single license can be used for multiple instances of the product. Select the default, Disabled, if multi-instance licenses are not allowed. Otherwise, select one of the other options from the drop-down list. For a full description of those options, refer to the IBM Tivoli License Manager License Administrators Guide, GC23-4833. Quantity Specify the volume of licenses available in this license pool. This will be the number of licenses that the customer has procured for this particular product. Threshold Specify the percentage of the total licenses in the pool at which to set a threshold for warnings. When the volume of licenses that are in use reaches this percentage, a warning event is generated. Target Type The target type indicates availability of the license pool within the customer monitoring environment. Select Enterprise to make the license pool available to all nodes in the customer environment, or select Division, Node, or Agent to limit availability to selected components. If you choose anything other than Enterprise, you must specify which Divisions, Nodes, or Agents can use this license pool. Start Date Specify the date from which the license pool is available. Expiration Date Specify the date when the license pool will stop being available, this will probably happen when the maintenance agreement of the purchased license ends. Usually a maintenance agreement will allow for free upgrades if a newer version is released for the period of that license agreement. This will all be brought to the forefront during the discussions with the customer. Description Enter a short description of the license pools that will help you to recognize the license pool when it appears in the software usage reports.
172
Creation Mode This is whether you want to create the distribution parameters now or not, by defining the Divisions or users that are entitled to use the license pool and then it will be distributed from the Administration server to the Runtime servers and the metering of that particular license pool takes effect. Select Set distribution now if you want to go immediately to the form where distribution details are defined. Select Set distribution later if you want to defer setting the distribution details. 3. Click Finish to create the license pool. In our example we chose to Set distribution now, which then took us to the next window where we were required to fill in the distribution parameters, as shown in Figure 5-17.
4. Since in our example we decided that the Oracle 8 Enterprise Edition software will be available for all users of CSI Corp., we chose the Allow all option. Otherwise the distribution settings wizard would allow us to select the Divisions, Nodes, and Agents that would be affected by this license pool distribution. Once the distribution settings are done, a confirmation window appears stating that the license pool and the distribution parameters for that license pool were created.
173
IBM Tivoli License Manager is a very dynamic application, and with that flexibility it is adaptable in all types of customer environments, whether they are rapidly changing environments or static environments, therefore IBM Tivoli License Manager has the solution for each of them. One of the primary examples of this flexibility is the updating of the software entitlement, license pool, and distribution parameter settings. As the customer environment rapidly evolves and licenses are procured or expire, IBM Tivoli License Manager allows you to quickly make changes to the software entitlement and license pools. Therefore as the customer needs are continuously changing IBM Tivoli License Manager allows you to stay on top of these changes with simple updates to the software entitlement, license pool, and distribution parameter settings.
Master Catalog
IBM Tivoli License Manager provides an initial Master Catalog when it is installed. The Master Catalog is a central repository of product information. It is created and maintained on the Administration server and a copy is dowloaded to each Runtime server. The Master Catalog contains information about all the software components and related files for the products that are to be monitored. The IBM Tivoli License Manager catalog manager component allows you to add new information to the Master Catalog. There are two sources of new information: The unknown file table, which contains entries for all applications that were detected by agents, but there are no entries already defined in the Master Catalog. The unknown file table is useful in a customer environment for many reasons. One is that a particular customer may have many in-house applications that they want tracked, so this provides a method to identify that software and then
174
merge it into the Master Catalog, therefore providing a way to monitor and report on the usage of this in-house software. New releases/updates of the IBM Tivoli License Manager catalog, which you can merge with the Master Catalog, so that it contains all the entries from the most up to date IBM Tivoli Software Inventory catalog. Updating the ITLM Master Catalog with the latest catalog provided by IBM is essential for new software components and related files recognition, and proper reporting on their usage.
Runtime Catalog
A Runtime Catalog is automatically created on each Runtime Server. It is a subset of the Master Catalog that resides in the Administration server, which contains only information about those products that are installed and discovered by the ITLM Agents that are managed by the Runtime Server. New entries are added to the Runtime Catalog when the Runtime Server receives license entitlement details from the Administration server and when the unknown file table identifies an new application, which has been discovered on a monitored node, that is not in the catalog.
175
Most common tasks that can be done using the IBM catalog manager are: Update the Master Catalog from entries of the Unknown file table. Import new releases of the IBM Tivoli License Manager catalog. Modify existing entries in the master catalog.
5.9.1 Updating the Master Catalog from the Unknown file table
This is an important aspect that shows how flexible IBM Tivoli License Manager is. Many enterprises want to monitor software and applications that have been custom-developed by either a software provider or in-house. By doing so, enterprises have the ability to monitor and meter these applications usage and produce reports efficiently. In our case study we provided an example of an application that was developed by CSI Corp., called CSI HR Tool. The CSI HR Tool has been deployed and used within the enterprise, and has now been discovered by the ITLM Agents. Therefore, there is an entry in the Unknown file table that corresponds to the CSI HR Tool. The steps involved to add CSI HR Tool to the Master Catalog are performed on the Administration server as follows: 1. Initialize the IBM Tivoli License Manager CLI environment. 2. Extract the Master Catalog and the Unknown file table from the ITLM Administration server database into merged catalog file. 3. Modify the existing entry in the Unknown file table for the CSI HR Tool application and make the appropriate changes, for example, identifying it as being developed by the CSI Corp. 4. Import the newly created catalog into the IBM Tivoli License Manager Administration server database. 5. Define software entitlements for the new application, if necessary.
176
* * For general help, type: help * For more detailed help, refer to the System Administrator's Guide. ***************************************************************************** #
At this point, using the expcat command, we have created a new file named catalog.dat stored in /opt/IBM/TLM/admin/cli directory. This file contains all the entries of both the Master Catalog and the Unknown file table merged in a format understandable by the IBM catalog manager tool. Our next step is to find and modify the entry for the CSI HR Tool application.
For a detailed description of performing the tasks using the catalog manager, refer to the IBM Tivoli License Manager License Administrators Guide, GC23-4833.
177
Now we can begin creating software products from the unknown file table as follows: 1. Click Unknown Files Manager. This will take you to the Unknown Files Manager working environment. Next, you can perform a search by either using a name of description, and selecting the corresponding operating system. If you do not use any argument for search, this will bring up a list of all unknown files, by operating system, that were picked up from all the nodes that have ITLM Agents running on them. An example is shown in Figure 5-19.
178
2. Now scroll through the list, select the executable file you want to add to the Master Catalog, and click New. In our example we selected CSI.EXE. This will take us to the Create a new software product window, as shown in Figure 5-20, where we can fill in some pertinent information about that product, such as the name, version, and description of the product, as well as the vendor, and most importantly, the licensing level. Click Create.
179
3. The next panel, shown in Figure 5-21, allows you to edit the application information once again and, if necessary, make any changes to the information you just entered. Click Close to return to the IBM catalog manager window.
180
Now you have successfully created an entry for the CSI HR tool in the merged catalog. The next step is to import this new catalog with the all the changes into the IBM Tivoli License Manager Administration database.
181
Software catalog imported successfully Vendors: 28(read) 1(new) 0(updated) Products: 12090(read) 1(new) 1(updated) Modules: 20051(read) 1(new) 0(updated) #
Launch the IBM Tivoli License Manager catalog manager as shown in Figure 5-18 on page 178 and click Import IBM Catalog. This will take you to a file search window.
Figure 5-22 Select the file to import and update the Master Catalog
Search for and select the new catalog file that you want to import to update the Master Catalog and click Open. Click OK to initiate the import process.
182
This process automatically updates the Administration server database and may take several minutes to complete. IBM will provide updates to the IBM Tivoli License Manager Master Catalog on a regular basis.
183
184
Chapter 6.
185
186
If you are using SSL, to access the login window, use this URL, instead:
https://<admin_server_hostname:443/slmadmin/login
Upon initial login to IBM Tivoli License Manager Web interface, you must use the following: User Name: tlmroot Password: system 2. The next window is a Welcome window. If you have more than one Customer defined, select the Customer for which you want to take the snapshot report. Click Software Usage -> Snapshot. 3. To produce a historical snapshot for the Customer, select the criteria shown as an example in Figure 6-1. Click Next.
Where, the values of variables are as follows: SW Vendor Platform The selection list includes publishers of software whose products can be included in the report. The selection list includes operating systems in use on nodes that are monitored by IBM Tivoli License Manager.
187
Enter a search criteria. Wildcard characters (%) are accepted. The selection list includes Divisions for the Customer that are currently selected. Select a Division to limit the report to nodes within a single Division or accept the default to include Agents from all Divisions. If you want to obtain reports for a particular Agent, or a group of Agents belonging to the same search criteria entered, wildcard characters (%) are allowed.
Agent name
4. In the next window, shown in Figure 6-2, Product name and Agent name drop-down boxes appear. Select the appropriate software for which the report is to be made. On the Agent name, you can select All, showing the usage for all Agents of that particular Division, or select one specific Agent. In the Define the reporting time section, enter the effective date and time for which you want to make the report. By default, the date and time are current. Click Next.
188
5. Figure 6-3 displays the resulting report. The report includes the following sections: A list of the products that meet the selection criteria entered, showing the level of usage of each product at the specified time. Product details of each product included in the report. A list of Agents where each product was in use at the specified time. Details of license pools available for each product at the specified time. A list of sessions that were open at the specified time for each product.
189
You are able to view more report information by scrolling down in the report window. This additional information is shown in subsequent figures in this section. This information is also available by selecting the hyper links in the report page. Figure 6-4 displays the product information and a few parameters set for products Microsoft Internet Explorer and Microsoft PowerPoint, respectively, when creating license pools for these.
190
Figure 6-5 displays the detailed license information for products Microsoft Internet Explorer and Microsoft Power Point, respectively.
Figure 6-6 displays the list of Agents for that Customer on which Microsoft Internet Explorer and Microsoft PowerPoint are installed, respectively. It also gives you detailed information about the Agents.
191
192
Where, the values of variables are as follows: SW Vendor Platform Product name Division The selection list includes publishers of software whose products can be included in the report. The selection list includes operating systems in use on nodes that are monitored by IBM Tivoli License Manager. Enter a search criteria. Wildcard characters (%) are accepted. The selection list includes Divisions for the Customer that are currently selected. Select a Division to limit the report to nodes within a single Division or accept the default to include Agents from all Divisions. If you want to obtain reports for a particular Agent, or a group of Agents belonging to the same search criteria entered, wildcard characters (%) are allowed.
Agent name
4. In the next window, shown in Figure 6-8, Product name and Agent name drop-down boxes appear. Select the proper software for which the report is to be made. On the Agent name, you can select All, showing the trend for all Agents of a particular Division, or select one specific Agent. In the Define the
193
report breakdown section, select the level at which software usage information is to be broken down into separate charts, as follows: Capacity A chart is produced for each different capacity type that is used for the product. For example, if the product has some license pools with capacity type Users and some with capacity type Memory, the report includes two charts, each of which could include usage from several license pools. License A chart is produced for each license pool defined for the product. In the Define the reporting time section, enter the effective date and time for which you want to make the report. By default, the date and time are current. Click Next.
194
5. Figure 6-9 shows the resulting report. This report shows you the software usage by capacity for a selected product. You can also have a report of software usage by license for a selected product.
The latter section of the report is visible by scrolling down the report screen. This additional information is shown in Figure 6-10. You also can redefine the report by changing the Date, Time, and Query by options.
195
196
Where, the values of variables are as follows: SW Vendor Platform Product name Division The selection list includes publishers of software whose products can be included in the report. The selection list includes operating systems in use on nodes that are monitored by IBM Tivoli License Manager. Enter a search criteria. Wildcard characters (%) are accepted. The selection list includes Divisions for the Customer that are currently selected. Select a Division to limit the report to nodes within a single Division or accept the default to include Agents from all Divisions.
197
Agent name
If you want to obtain reports for a particular Agent, or a group of Agent belonging to the same search criteria entered, wildcard characters (%) are allowed.
4. In the next window, shown in Figure 6-12, Product name and Agent name drop-down boxes appear. Select the proper software for which the report is to be made. On the Agent name, you can select All, showing the trend for all Agents of a particular Division, or select one specific Agent. In the Define the reporting period, enter the effective date and time for which you want to make the report. Click Next.
198
5. In the next window, select the values for the usage level threshold (high water mark or average usage), Capacity Type, and report order, as shown in Figure 6-13.
6. Figure 6-14 shows the resulting report. The report gives you the level of usage of selected products on selected nodes. This is for the period you specified. The report presented here is based on the high water mark.
199
200
Where, the values of variables are as follows: SW Vendor Platform The selection list includes publishers of software whose products can be included in the report. The selection list includes operating systems in use on nodes that are monitored by IBM Tivoli License Manager.
201
Enter a search criteria. Wildcard characters (%) are accepted. The selection list includes Divisions for the Customer that are currently selected. Select a Division to limit the report to nodes within a single Division or accept the default to include Agents from all Divisions. If you want to obtain reports for a particular Agent, or a group of Agents belonging to the same search criteria entered, wildcard characters (%) are allowed.
Agent name
4. In the next window, shown in Figure 6-16, Product name and Agent name drop-down boxes appear. Select the proper software for which the report is to be made. On the Agent name, you can select All, showing the trend for all Agents of a particular Division, or select one specific Agent. Select also whether the report will be ordered by product or Agent. In the Define the reporting time, enter the effective date and time for which you want to make the report. Click Next.
202
5. Figure 6-17 displays the resulting report. This example report shows the software inventory for a particular Node of the Finance Division and software vendor Adobe.
203
204
http://<runtime_server_hostname:80/slmruntime/login
If you are using SSL, to get the login window use this URL, instead:
https://<runtime_server_hostname:443/slmruntime/login
Upon initial login to IBM Tivoli License Manager Web interface, you must use the following: User Name: tlmroot Password: system 2. The next window is a Welcome window. If you have more than one Customer defined, select the Customer for which you want to make the snapshot report. Click Software Usage. 3. To produce a historical snapshot for Customer, select the criteria shown as an example in Figure 6-18. Click Next.
Where, the values of variables are as follows: SW Vendor The selection list includes publishers of software whose products can be included in the report.
205
The selection list includes operating systems in use on nodes that are monitored by IBM Tivoli License Manager. Enter a search criteria. Wildcard characters (%) are accepted. The selection list includes Divisions for the Customer that are currently selected. Select a Division to limit the report to nodes within a single Division or accept the default to include Agents from all Divisions. If you want to obtain reports for a particular Agent, or a group of Agents belonging to the same search criteria entered, wildcard characters (%) are allowed.
Agent name
4. In the next window, shown in Figure 6-19, Product name and Agent name drop-down boxes appear. Select the proper software for which the report is to be made. On the Agent name, you can select All, showing the trend for all Agents of a particular Division, or select one specific Agent. Click Next.
5. Figure 6-20 displays the resulting report. In this example the report shows the real-time software usage for a particular Node in the Finance Division and
206
software vendor Adobe. Products may or may not be being used at that particular time. For example, the report shows that the product Adobe Framemaker Version 6.0 was being used (it is highlighted in the figure by a circle).
6. You can drill-down into the report by clicking the hyper-link values in the In Use column. It will take you to the details about that particular product usage, as shown in Figure 6-21. In this report, details of the product and Agent are displayed. The report also shows the user name which is logged in this Agent and the grant date. The grant date is the date and time the licence was assigned. Click Back to go back to the main report page.
207
7. By scrolling down the report window shown in Figure 6-20, you will be able to it view the details of each software listed. This is shown in Figure 6-22 and Figure 6-23. You will also be able to access this information if you click on the software name hyper-links. The information provided there displays product, software entitlement, and license pool information.
208
209
210
programs, from the management application data sources, and further processed for historical analysis and evaluation. Tivolis strategy is to have most of its products providing ETLs so that the Tivoli Data Warehouse databases can be populated with meaningful systems management data. IBM Tivoli License Manager is one of the many products to fully leverage and utilize Tivoli Data Warehouse. The following sections explain how the integration with the Tivoli Data Warehouse can be achieved and how to obtain the IBM Tivoli License Manager reports through Tivoli Data Warehouse.
211
Tivoli Data Warehouse can extract data from any application (Tivoli and non-Tivoli) and store it in a common central database. Tivoli Data Warehouse also provides transparent access for third-party Business Intelligence (BI) solutions (CWM standard), such as IBM DB2 OLAP, Crystal Decisions, Cognos, BusinessObjects, Brio Technology, and Microsoft OLAP Server. CWM stands for Common Warehouse Metadata, an industry standard specification for metadata interchange defined by the Object Management Group (see http://www.omg.org). Tivoli Data Warehouse provides a Web-based reporting front end, called the Reporting Interface, but the open architecture provided by the Tivoli Data Warehouse allows other BI front ends to be used to access the data in the central warehouse. The value here is flexibility. Customers can use the reporting application of their choice; they are not limited to any one. Tivoli Data Warehouse provides a robust security mechanism. Tivoli Data Warehouse provides a robust security mechanism by allowing data marts to be built with data from subsets of managed resources. By providing database level authorization to access those data marts, Tivoli Data Warehouse can address most of the security requirements related to limiting access to specific data to those Customers/business units with a need to know. Tivoli Data Warehouse provides a scalable architecture. Since Tivoli Data Warehouse depends on the proven and industry standard RDBMS technology, it provides a scalable architecture for storing and retrieving the data.
212
ITM
ITM Database
Data Mart
TEC
TEC Database
Data Mart
Target ETLs
Data Mart
TLMA Database
Data Mart
Data Mart
Cognos
Business Objects
Crystal Reports
Third Party
Third-Party Database
It is common for enterprises to have various distributed performance and availability monitoring applications deployed that collect some sort of measurement data and provide some type of threshold management, central event management, and other basic monitoring functions. These applications are referred to as source applications. The first step in obtaining management data is to enable the source applications. This means providing all tools and customizations necessary to import the source operational data into the Tivoli Data Warehouse central data warehouse. All components needed for that task are collected in a so-called warehouse enablement package for each source application. In this chapter, IBM Tivoli License Manager is the source application providing license management and software entitlement information through each of its application components: Administration and Runtime servers. All the data needed for reporting is stored in the TLMA database in the IBM Tivoli License Manager Administration server and is then loaded into the TDW databases. One important part of the warehouse packages are the extract, transform, and load data programs, or, simply, ETL programs. In general, ETL programs process data in three steps. First, they extract the data from a source application database called data source. Then the data is validated, transformed, aggregated, and/or cleansed so that it fits the format and needs of the data target. Finally, the data is loaded into the target database.
213
In Tivoli Data Warehouse, there are two types of ETLs: central data warehouse ETL and data mart ETL. Central data warehouse ETL The central data warehouse ETL pulls the data from the source applications and loads it into the central data warehouse, as shown in Figure 6-24. The central data warehouse ETL is often referred to as source ETL or ETL1. Data mart ETL As shown in Figure 6-24, the data mart ETL extracts a subset of historical data from the central data warehouse, which contains data tailored to and optimized for a specific reporting or analysis task. This subset of data is used to populate data marts. The data mart ETL is also known as target ETL or ETL2. IBM Tivoli License Manager provides a TDW enablement pack composed by source and target ETLs as explained above. As a generic concept, a data warehouse is a structured extensible database environment designed for the analysis of consistent data. The data that is inserted in a data warehouse is logically and physically transformed from multiple source applications, updated and maintained for a long time period, and summarized for quick analysis. The Tivoli Data Warehouse central data warehouse (CDW) is the database that contains all enterprise-wide historical data (with hour as the lowest granularity). This data store is optimized for the efficient storage of large amounts of data and has a documented format that makes the data accessible to many analysis solutions. The database is organized in a very flexible way, which lets you store data from new applications without adding or changing tables. The Tivoli Data Warehouse server is an IBM DB2 Universal Database Enterprise Edition server that hosts the Tivoli Data Warehouse Central Data Warehouse databases. These databases are populated with operational data from Tivoli and/or other third-party applications for historical analyses. A data mart is a subset of the historical data that satisfies the needs of a specific department, team, or Customer. A data mart is optimized for interactive reporting and data analysis. The format of a data mart is specific to the reporting or analysis tool you plan to use. Each application that provides a data mart ETL creates its data marts in the appropriate format. Tivoli Data Warehouse provides a Report Interface (RI) that creates static two-dimensional reports of your data using the data marts. The Report Interface is a role-based Web interface that can be accessed with a simple Web browser without any additional software installed on the client. You can also use other tools to perform OLAP analysis, business intelligence reporting, or data mining.
214
The Tivoli Data Warehouse Control Center is the IBM DB2 Universal Database Enterprise Edition server containing the Tivoli Data Warehouse control database that manages your Tivoli Data Warehouse environment. From the Tivoli Data Warehouse Control Center, you can see all source applications databases in your environment. The default internal name for the Tivoli Data Warehouse Control database is TWH_MD. The Tivoli Data Warehouse Control Center also manages the communication between the various components, such as the Tivoli Data Warehouse Central Data Warehouse, the data marts, and the Report Interfaces. The Tivoli Data Warehouse Control Center uses the DB2 Data Warehouse Center utility to define, maintain, schedule, and monitor the ETL processes. The Tivoli Data Warehouse stores cleansed historical data from all Tivoli and third-party application databases in the Tivoli Data Warehouse Central Data Warehouse database. The database name of the Tivoli Data Warehouse Central Data Warehouse database is TWH_CDW. Once the data has been inserted into the TWH_CDW database, it is available for either the Tivoli Data Warehouse ETLs to load to the Tivoli Data Warehouse Data Mart database (the database name of the Tivoli Data Warehouse Data Mart database is TWH_MART) or to any other application-specific ETL to process the data and load the application-specific Data Mart database. All Tivoli Data Warehouse ETL programs follow a naming convention using a three letter application-specific product code known as measurement source code. Specifically, the measurement source code of the TDW enablement pack for IBM Tivoli License Manager is COD.
215
TLMA Database
Windows 2000 SP3 DB2 EE Server 7.2 FP6 TEDW 1.1 FP2 Server ITLM ETLs
TEDW Server
TWH_MD
1
TLMR Database ITLM Runtime Server ITLM Runtime Server TLMR Database
TWH_CDW
TWH_MART
ITLM Agent
ITLM Agent
From Figure 6-25, the warehouse processing goes through the following steps: 1. All the software usage, license agreement, license usage, Customer information, and inventory information data is rolled up from the Agents to the ITLM Runtime server databases, named TLMR. All the data is then moved to the ITLM Administration server and stored in a central repository database, named TLMA. 2. Using the IBM Tivoli License Manager enablement pack source ETLs, data from the ITLM Administration server database is loaded to the central data warehouse. 3. From this central data warehouse database, the IBM Tivoli License Manager enablement pack target ETL can extract data related to license management and load the TDW data mart database (TWH_MART). 4. Data in the TWH_MART can be shown using the IBM Tivoli License Manager enablement pack predefined reports using the TDW reporting interface. The TDW reporting interface runs on top of the IBM console application. Now, we can start installing the components.
216
217
FixPack6 for IBM DB2 Universal Database Enterprise Edition can be downloaded from the official IBM DB2 technical support Web site at:
http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v7fphis t.d2w/report
Apply the 1.1-TDW-0002 fix for the Tivoli Data Warehouse and one of the following fixes: 1.1-TDW-0005E and 1.1-TDW-FP01a 1.1-TDW-FP02 Note: At the time of writing this book, the TDW fix 1.1-TDW-FP02 was in the beta development phase. You should apply this fix, as soon as it becomes available, because it supersedes the fixes 1.1-TDW-0005E and 1.1-TDW-FP01a. These fixes for Tivoli Data Warehouse can be downloaded from the IBM Tivoli Software support Web site, under the Tivoli Data Warehouse category at:
http://www.ibm.com/software/sysmgmt/products/support/TivoliEnterpriseDataWa rehouse.html
The documentation that accompanies the fixes, provides considerable detail of the steps for installation. Important: The redbook Introduction to Tivoli Enterprise Data Warehouse, SG24-6607, mentions that the Windows Services Warehouse Server and Warehouse Logger must be reconfigured to run as the db2admin user. If you have not made this change, you will see failures when trying to import data into the TWH_CDW database. Please confirm that you have reconfigured these services and restarted them.
The installation can be done using the Tivoli Data Warehouse CLI or the GUI installation program. Here we describe the process using the GUI method. The following steps should be performed in the Tivoli Data Warehouse Control Center server. You need both the Tivoli Data Warehouse and the IBM Tivoli License Manager products installation media. 1. Run the setup.exe from the Tivoli Data Warehouse CD-ROM and click OK to start the installation. 2. When the InstallShield Wizard dialog window for Tivoli Data Warehouse Installation appears, click Next.
218
3. The dialog window for the type of installation appears. Select Application installation only and the directory name where the Tivoli Data Warehouse components are installed. As our TDW Control Center server is installed on a Windows 2000 machine, we used C:\TWH. Click Next to continue. 4. The host name dialog window appears. Verify that this is the correct host name for the Tivoli Data Warehouse Control Center server. Click Next. 5. The local system DB2 configuration dialog window appears. The installation process asks for a valid DB2 user ID. Enter the valid DB2 user ID and password that were created during the DB2 installation on your local system. In our case, we used db2admin. Click Next. 6. The path to the installation media for the application packages dialog window appears, as shown in Figure 6-26. You should provide the location of the IBM Tivoli License Manager warehouse enablement pack program. Change out the Tivoli Data Warehouse CD in the CD-ROM drive with the IBM Tivoli License Manager warehouse enablement pack installation CD. Specify the path to the twh_app_install_list.cfg file (by default, in the CD_drive:\tedw_apps\cod\ directory) in the directory name field. Leave the Now (prevents typing errors) option checked, to verify that the source directory is immediately accessible and that it contains the correct files. Click Next.
7. The overview of selected features dialog window appears, as shown in Figure 6-27. Click Install to start the installation.
219
8. Once the installation is finished, the Installation summary window appears, as shown in Figure 6-28. If the installation was not successful, check the TWHApp.log file for any errors. This log file is located in <TWH_inst_dir>\apps\COD\, where <TWH_inst_dir> is the Tivoli Data Warehouse installation directory.
220
9. After the pack installation conclusion, you must reboot the Tivoli Data Warehouse Control Center server.
Where, <db2pw> is the database administrator password. 2. To determine the actual heap size, issue:
db2 get db cfg for TWH_CDW | grep CTL_HEAP
221
db2start
Where, <ITLM_ADM> is the Tivoli Data Warehouse Server host name, and <DB2_PORT> is the TCP/IP port used by DB2 (the default is 50000). Tip: You can also perform this task using the DB2 Client Configuration Assistant.
222
You should edit the properties of each one of the above entries. To do this, right-click on an entry and select Properties and then select the Database tab. Fill in the database instance owner user ID information. For our environment, the values are shown in Figure 6-30, using the COD_TLMA_Source as an example.
223
5. For the IBM Tivoli License Manager Targets, shown in Figure 6-31, expand the Warehouse Target folder. There are three entries for the IBM Tivoli License Manager target ETL programs that need to be configured, as follows: COD_TWH_CDW_Target COD_TWH_MART_Target COD_TWH_MD_Target
You should edit the properties of each of the above entries. For example, right-click the COD_TWH_CDW_Target, select Properties, and then select the Database tab. Fill in the user ID information as appropriate for your environment, as shown in Figure 6-32.
224
225
226
227
228
Where, <tedwserver> is the name of your warehouse server providing the IBM Console support.
After you log on, you can access the menus on the left side to manage reports, as shown in Figure 6-37.
229
Tip: For users logged on as superadmin, the portfolio and the context menus for reports contain multiple menus. For example, the context menus contain two Create a Report entries and three entries for Properties. Use the first entry in the list of duplicate entries that represents the highest level role authorized to perform that function. At this point, you can create your own reports (assuming you have proper authority), or access existing reports.
230
If you choose to create your own report, you will see a series of dialog boxes that allow you to choose the type of report, the data mart containing the data you want to create the report from, and a variety of other options to enable you to select the actual data and report options you desire. Your options will vary, based on the type of report you are creating.
231
After you select a specific report, you still have options to customize the specific data you want to see. For example, you may want to select a specific time frame or aggregation level. Here we provide two reports as an example: Figure 6-39 shows the Product Installed by Division summary report. Figure 6-40, shows an example of an extreme case report showing IBM Tivoli License Manager Agent Installed by Division.
232
233
The two sample reports shown here are meant to provide you with an idea of the types of reports that are available out-of-the-box with the IBM Tivoli License Manager warehouse enablement pack. There are several other reports that can also be created, and more importantly, the data associated with the monitoring of your software and license management is also available to be accessed by other business intelligence and reporting tools.
234
Chapter 7.
235
In this scenario, the customer is operating from a single location, with few Divisions. There are no WAN connections. The characteristics of small environment are: Less than 2500 nodes No WAN connections Administration server, Database server, and Runtime server on the same physical machine The Runtime server component, on this machine, communicates with the Agents installed on the end user machines. Runtime server also communicates with the external notification system.
236
The Administration server component communicates with the Runtime server on the same machine. Browsers can access the machine where the Administration server and the Runtime server components are installed so that the administrator can view the historical and real-time reports that are available.
ITLM Runtime server Database server ITLM Administration server Database server ITLM Agents
Remote Site
ITLM Agents
In this scenario, the structure is expanded to deal with additional Agents, up to 5000. To maintain performance levels, the Administration server and its database are installed on separate machines and additional a Runtime server is installed for remote site which is connected to the main site via WAN. Each Runtime server is assigned a set of Agents. The characteristics of medium environment are: Up to 5000 nodes Different machines for Administration server and Runtime Up to two remote locations An interface to the notification system is provided on both Runtime servers. Browsers can access the Administration server for maintenance and historical reporting tasks, and the Runtime servers for real-time reports.
237
Agents
Runtime
Agents
Runtime
Admin
Database server
Notification
High Speed
WAN
Agents
Runtime Notification
Agents
Runtime Notification
Agents
Runtime Notification
In the scenario, the administration functions provided by the Administration server are located at a major site. This site has the majority of the nodes. All other sites are geographically away from each other, and are connected to the main site via WAN. Demographic information for all the sites served by the Hub site is collected in the centralized database. The administrators of this site can then access Administration server for maintenance and reporting functions. The characteristics of a large environment are: Total number of nodes up to 15000 Number of nodes up to 2500 per remote site per Runtime server Notification server at each site Can have more than one customer defined in ITLM Administration server, Database server, and Runtime servers installed on different physical machines
238
239
buffer pool, these dirty pages must first be flushed to disk storage and become clean pages, so that prefetchers can find room to place fetched data pages from disk storage. The number of page cleaners may be controlled by the database configuration parameter NUM_IOCLEANERS. This parameter allows you to specify the number of asynchronous page cleaners for a database. These page cleaners write changed pages from the buffer pool to disk before the space in the buffer pool is required by a database Agent. As a result, database Agents should not have to wait for changed pages to be written out so that they may use the space in the buffer pool. This improves overall performance of the database applications. If you set the parameter to zero (0), no page cleaners are started and as a result, the database Agents will perform all of the page writes from the buffer pool to disk. This parameter can have a significant performance impact on a database stored across many physical storage devices; since in this case there is a greater chance that one of the devices will be idle. If no page cleaners are configured, your applications may encounter periodic log full conditions. Logs Changes to data pages in the buffer pool are logged. Agent processes updating a data record in the database update the associated page in the buffer pool, and write a log record into a log buffer. To optimize performance, neither the updated data pages in the buffer pool, nor the log records in the log buffer are written to disk immediately. They are asynchronously written to disk by page cleaners, and the logger, respectively. The logger and the buffer pool manager cooperate and ensure that an updated data page is not written to disk storage before its associated log record is written to the log. This ensures database recovery to a consistent state from the log in the event of a crash such as a power failure. logfilsiz: Represents the size of the log files. logprimary: The primary log files establish a fixed amount of storage allocated to the recovery log files. This parameter allows you to specify the number of primary log files to be preallocated. logsecond: This parameter specifies the number of secondary log files that are created and used for recovery log files (only as needed). Java Heap parameters In general, increasing the size of the Java heap improves throughput until the heap no longer resides in physical memory. After the heap begins swapping to disk, Java performance deteriorates drastically. Therefore, the maximum heap size needs to be low enough to contain the heap within physical memory. MON_HEAP_SZ indicates the amount of memory (in 4K pages) which is allocated for database monitor data (at db2start). The amount of
240
memory needed will depend on the number of snapshot switches which are turned on and active Event Monitors. If the memory heap is insufficient, an error will be returned when trying to activate a monitor and it will be logged to the db2diag.log file. Database heap There is one database heap per database, and the database manager uses it on behalf of all applications connected to the database. It contains control block information for tables, indexes, table spaces, and buffer pools. It also contains space for event monitor buffers, the log buffer (logbufsz), and temporary memory used by utilities. Therefore, the size of the heap will be dependent on a large number of variables. The control block information is kept in the heap until all applications disconnect from the database. Sort Heap Size (sortheap) If the rows to be sorted occupy more than the space available in the sort heap, several sort passes are performed, where each pass sorts a subset of the entire set of rows. Each sort pass is stored in a temporary table in the buffer pool, which might be written to disk. When all the sort passes are complete, these sorted subsets are merged into a single sorted set of rows. A sort is considered to be piped if it does not require a temporary table to store the final, sorted list of data. That is, the results of the sort can be read in a single, sequential access. Piped sorts result in better performance than non-piped sorts and will be used if possible. I/O Servers Configuring enough I/O servers with the num_ioservers configuration parameter can greatly enhance the performance of queries for which prefetching of data can be used. To maximize the opportunity for parallel I/O, set num_ioservers to at least the number of physical disks in the database. It is better to overestimate the number of I/O servers than to underestimate. If you specify extra I/O servers, these servers are not used, and their memory pages are paged out. As a result, performance does not suffer.
241
The following values can be set to prevent transaction failure with an out of transaction space on the DB error. The logfilsiz parameter specifies the amount of disk storage in pages that is allocated to the log files that are used for data recovery. The logprimary and logsecond parameters determine the number of primary and secondary log files that will be used for database recovery. Their size is determined by the number specified when setting the logfilsiz parameter. We recommend that you keep primary and secondary log files on different physical drives. So in case one drive is unusable, you can have access to the log files on another drive. The log file size can be increased or decreased depending on the frequency of updates.
db2 update db cfg for TLMA using logfilsiz 2500 db2 update db cfg for TLMA using logprimary 5 db2 update db cfg for TLMA using logsecond 5
For more information on the database and database manager parameter configurations, refer to the DB2 UDB Command Reference Version 7, SC09-2951.
The sortheap parameter is normally kept 20% of your largest and most accessed table. It may vary according to the environment.
db2 update db cfg for TLMA using sortheap 8000
242
The iocleaners parameter will significantly help tuning performance if you have more than one CPU.
db2 update db cfg for TLMA using num_iocleaners 6
The ioservers parameter tunes the performance of writing to disk. It will significantly help tuning performance if you have more than one physical disks.
db2 update db cfg for TLMA using num_ioservers 5
The prefetch size parameter is normally kept at half of your largest table. It may vary according to the environment.
db2 update db cfg for TLMA using dft_prefetch_sz 32
IBMDEFAULTBP is a default bufferpool, and is normally kept at one fifth of your database size. It may vary according to the environment.
db2 alter bufferpool IBMDEFAULTBP size 25000
The following values can be set to prevent transaction failure with an out of transaction space on the DB error. The logfilsiz parameter specifies the amount of disk storage in pages that is allocated to the log files used for data recovery. The logprimary and logsecond parameters determine the number of primary and secondary log files that will be used for database recovery. Their size is determined by the number specified when setting the logfiles parameter. We recommend that you keep primary and secondary log files on different physical drives. So in case one drive is unusable, you can have access to the log files on another drive. The log file size can be increased or decreased depending on the frequency of updates as follows:
db2 db2 db2 db2 connect to TLMA user <DB2_user> using <DB2_password> update db cfg for TLMA using logfilsiz 2500 update db cfg for TLMA using logprimary 10 update db cfg for TLMA using logsecond 10
To optimize your IBM DB2 Universal Database Enterprise Edition environment for querying, perform the following: 1. Execute the runstats and reorgchk commands on the TLMA database, as it will significantly improve performance. The runstats command will provide statistics on particular database tables and indexes. The reorgchk utility will provide you with the amount of free space available and the amount of space being used. 2. Create a new temporary tablespace using one SMS container on a different operating system file system located on a separate physical disk. Drop the original temporary tablespace so that the new temporary tablespace is used. By simply moving the temporary tablespace to a different physical disk, elapsed time for a query can be cut by almost 25 percent.
243
3. Use a TEMPSPACE tablespace with four container directories. Place the containers on disks that are not otherwise being used by the database. 4. The standard DB2 EXTENTSIZE and PREFETCHSIZE for the TEMPSPACE is 32 - 4 KB pages. DB2 has the ability to prefetch data asynchronously in anticipation of the CPU's ability to process it, therefore minimizing the impact of I/O service delays. PREFETCHSIZE dictates the quantity of data to asynchronously retrieve for each prefetch request. Generally, PREFETCHSIZE should be a multiple of EXTENTSIZE, and the multiple should be equal to the number of containers. 5. Enable intrapartition parallelism using the following command. This will be useful if you have Symmetric Multiprocessing. Do not do this if you have a machine with a single processor.
db2 update dbm cfg using INTRA_PARALLEL YES
Set the default degree of parallelism for the database to X# (where X# equals the number of system processors) using the following command:
db2 update db cfg for TLMA using DFT_DEGREE X#
If you partition database across different physical disks, enable parallel I/O for every table space by issuing the following command:
db2set DB2_PARALLEL_IO=*
For more information regarding the topics found in the DB2 performance tuning section, refer to these documents:
DB2 UDB Version 7.1 Performance Tuning Guide, SC09-2945 DB2 UDB Administration Guide: Implementation Version 7, SC09-2944 DB2 UDB Command Reference Version 7, SC09-2951 Database Performance on AIX for DB2 UDB and Oracle Environments Redbook, SG24-5511 DB2 UDB Version 7.1 Performance Tuning Guide Redbook, SG24-6012
http://www.db2mag.com/db_area/archives/2001/q1/hayes.shtml
244
http://www.db2mag.com/db_area/archives/2001/q4/hayes.shtml
245
performance data. Servers can include application servers, Web servers, and Java applications. WebSphere Application Server provides a service named PmiService that is responsible for retrieving performance data from other servers in the domain and making the data available to interested clients. 3. Performance tuner wizard The Performance tuner wizard is a tool included in WebSphere Application Server Advanced Edition that includes the most common performance related settings associated with the application server. Use Performance Tuner Wizard to optimize the settings for applications, servlets, enterprise beans, data sources and expected load. Parameters that can be set include: Web container: Maximum thread size ORB properties: Pass-by-reference, ORB thread pool size Data source: Connection pool size, statement cache size Database (DB2 only): This calls the DB2SmartGuide, which, in turn, tunes the DB2 database associated with the data source Java Virtual Machine (JVM): Initial and maximum heap size For more information regarding the topics found in this performance tuning section, refer to the IBM WebSphere Application Server product documentation.
246
247
Inventory scans
The number of Agents within a single Division assigned to a single Runtime server can be critical to the performance of the server. This is because the largest load on Runtime server occurs during the inventory scan. Inventory scan is scheduled Division-wise. You must determine an acceptable amount of time for an inventory scan of a Division to be completed, for example, a working day, and then estimate how many Agents in the same Division can be assigned to a single Runtime server.
248
The Agent properties section of the system.properties file for each Runtime server includes settings that define the amount of time required to scan a node. These properties are pcInventoryDuration and serverInventoryDuration. Other considerations are: Inventory scans should be scheduled for times when other Agent activity is low. Scans for Divisions that have Agents assigned to the same Runtime server should not be scheduled so that they coincide or overlap. Before the information is available for reporting it must be transferred to the Runtime server and then to the Administration server.
Database Drivers
You should use the JDBC driver 2.0, because it provides advanced database capabilities (query optimized execution, data sources) that are not available with the version 1.2 driver. This version is a prerequisite of WebSphere 4.0, but not of WebSphere 3.5.6. If you are using WebSphere 3.5.6, you should switch to the JDBC driver 2.0. Instructions for this task are provided in 4.2, Setting up the ITLM Administration server on page 102.
249
The cleaning process for the USAGE table runs regularly at intervals determined by the cleanUsagePeriod property in the system.properties file. The default for this property is one day. You can disable the process by changing the setting of the cleanUsageEnabled property to false. The clean-up process identifies usage transactions that are older than the number of days specified in the maxUsageAge property. These transactions are cleared from the table and the detailed software usage information that they provided is no longer available to the software usage reports. However, a less detailed record is maintained by adding entries to the USAGE_H table. This table includes an entry for each unique combination of license pool, date, and time. The quantity of licenses assigned values for all transactions that match on all three parameters are considered and the highest value is recorded in the USAGE_H entry. In this way, a record of high-water mark is maintained at license pool, date, and time level. This information is accessible using DB2 queries. The cleaning process for the SERVICE table runs regularly at intervals determined by the cleanServicePeriod property. The default for this property is six hours. You can disable the process by changing the setting of the cleanServiceEnabled property to false. The clean-up process identifies entries that are older than the number of days specified in the maxServiceAge property and deletes them. Example 7-2 shows the system.properties file on the Administration server. The parameters which were discussed are highlighted.
Example 7-2 Changes in the system.properties file
################################################################ # ADMIN SERVER SETTINGS # # The following settings affect the behavior of the admin server, and # # have no meaning on the Runtime server. # ################################################################ # Time interval for license usage checking (minutes) hwmScanPeriod=240 # Usage table clean-up enablement cleanUsageEnabled=true # Time interval for usage table cleanup execution (days) cleanUsagePeriod=1 # Max age for the data in the usage table: old data are cleaned (days) maxUsageAge=30 # Server wake-up enablement adminWakeUpEnabled=true # Time interval before Runtime servers are called for update (minutes) adminWakeUpPeriod=15 # Service table clean-up enablement cleanServiceEnabled=true # Time interval for service table cleanup execution (hours) cleanServicePeriod=6
250
# Max age for the data in the service table: old data are cleaned (days) maxServiceAge=7
251
252
Appendix A.
253
This appendix will not discuss how to create a IBM Tivoli Configuration Manager Software Package that uses IBM Tivoli Configuration Manager version 4.1. Information and instructions on how to create the Software Package can be found in the Users Guide for Software Distribution Version 4.2, SC23-4711.
254
The containers used in the above example are related to specific usages and explained as follows: Checking_Prereq This container contains the Check Disk action. It verifies if the amount of free Hard Disk space for the installation files is available. If this prerequisite is missed, the package will stop and its status will be set to IC--E. For more
255
information regarding the ITLM Agent prerequisites, refer to 3.4.8, Planning for IBM Tivoli License Manager Agent on page 92. Package_Files_distribution Once the requirements are fulfilled, we can distribute the image files. If a problem occurs during the files transfer, we have to stop the package and set its status to IC--E. If the complete set of image files is not on the local machine, the installation would fail in any case. Enable_Auto_logon The Windows Agent installation process needs to be authenticated with credentials of either a local or a domain user with Administration rights to the target machine where the ITLM agent is about to be installed. The Software Package must first log on with a pre-defined maintenance user using the Windows Autologon process. If the Autologon activation process fails, we have to stop the package process and set its status to IC--E. Otherwise, the Software Package wont have the proper users rights to proceed with the installation process. Agent_Installation As soon as Auto-logon process succeeds, the installation process can be initialized. However, even if an error occurs during the installation, we would not be able to set the package on failure because we have to turn off the Autologon process. Nevertheless, the installation status is checked at the end of the Software Package process and if the Agent is not correctly installed, its status will be set to IC--E. Before_Installation In this section, we specify the directory for the log files to be used for both the package and the installation script. This needs to be done at this time because the Software Distribution process would not create it. Agent_Setup In this section, we start the installation script which will be explained in the next section. The script is coded using the Perl language. Despite the fact that the Tivoli Endpoint should be capable to start Perl scripts, we have included a Perl version in the package to be sure that the script will be executed. Disable_Auto_Logon Once the installation finished, we have to turn off the Auto-logon process. Remove_Installation_Files We remove the set of installation files to avoid the Hard Disk space usage for useless files.
256
Control_Agent_Installation Because it is not possible to set the package in an error state during the installation process, due to the Auto-logon process, we need to verify if the ITLM Agent has been properly installed. One method is to check the Windows Registry information. If the ITLM Agent PATH variable is correctly set, we assume that the installation was successful. Otherwise, we write an informational message in the log file and set the state of the package to IC--E.
The variables used in the above example are related to specific usages and explained as follows: The name of the package This is especially useful for troubleshooting purposes.
sp_name = "ITLMAgent.1.1"
257
The path of installation files set This variable will be used by other variables that need to refer to a file or a directory within the installation package.
agent_image_path = "c:\temp\itlm_agent_v1r1"
Scripts variables These are variables to be passed on to the installation script. Instead of hard coding them in the Exectue_Program action, we decided to set variables. This offers a more flexible way to adapt the Software Package to any environment.
agent_source_path = "$(agent_image_path)\win32" agent_def_file = "$(agent_image_path)\cust\itlm_agent.def" agent_inst_file = "$(agent_image_path)\win32\installagent.exe" target_log_file = "c:\temp\ITCM_install_logs\zinst_itlm_agent.log"
Registry key To be able to test the viability of the installation, we need to get information from the Windows Registry. This variable refers to the information that the ITLM installation process saves in the Registry for the ITLM Agent.
registry_key_agent="$(REG:HKEY_LOCAL_MACHINE\SOFTWARE\IBM\TLMAgent\AgentPath)"
Flag variables Each container is subject to different condition. For troubleshooting purposes, we set the possibility to execute a container or not. Otherwise, you should delete the container in case you dont want it to be executed. If the value of a flag is different than 0, the Software Package process will not execute the actions defined in that particular container.
flag_checking_prereq = "0" flag_before_installation = "0" flag_enable_auto_login = "0" flag_agent_setup = "0" flag_remove_installation_files = "0" flag_control_agent_installation = "0" flag_disable_auto_logon = "0" flag_package_files_distribution = "0" flag_agent_installation = "0"
258
The file name of the Software Package contains the level and the release, if it exists, of the Software and the level and the release of the Software Package levels in the following format:
<Package Name>_v<Software version>r<Software release>_p<Software Package version>r<Software Package release>
version 1.1 of
The installation is made in a Maintenance Mode using a specific user dedicated only for installation and maintenance machine mode. Version 1.0 - 11.25.2002 - ITSO Lab The information that the Agents needs for its Runtime connection is in a Definition file which should be maintained on a regularly basis. " version = "1.1" copyright = "(C) COPYRIGHT IBM Corporation All Rights Reserved Licences Material - Property of IBM Corporation" web_view_mode = "hidden" undoable = "n" committable = "o" history_reset = n save_default_variables = n creation_time = "2002-11-26 16:53:39" last_modification_time = "2002-11-26 16:54:03" default_variables flag_checking_prereq = "0"
259
flag_before_installation = "0" sp_name = "ITLMAgent.1.1" flag_enable_auto_login = "0" registry_key_agent = "$(REG:HKEY_LOCAL_MACHINE\SOFTWARE\IBM\TLMAgent\Agent path)" target_log_file = "c:\temp\ITCM_install_logs\zinst_itlm_agent.log" agent_def_file = "$(agent_image_path)\cust\itlm_agent.def" flag_agent_setup = "0" agent_image_path = "c:\temp\itlm_agent_v1r1" flag_remove_installation_files = "0" agent_inst_file = "$(agent_image_path)\win32\installagent.exe" flag_control_agent_installation = "0" agent_source_path = "$(agent_image_path)\win32" flag_disable_auto_logon = "0" flag_package_files_distribution = "0" flag_agent_installation = "0" end
log_object_list location = "c:\temp\ITCM_Install_logs" unix_user_id = 0 unix_group_id = 0 unix_attributes = "rwx,rx," end move_removing_host = y no_check_source_host = y lenient_distribution = n default_operation = "install" server_mode = "all|force|force" operation_mode = "not_transactional" log_path = "D:\Tivoli\TivoliCustom\logs\SWD\itlm_agent_v1r1.log" log_mode = "0" log_user_id = 0 post_notice = n before_as_uid = 0 skip_non_zero = n after_as_uid = 0 no_chk_on_rm = n log_gid = 0 log_host_name = "tlm01" versioning_type = "swd" package_type = "refresh" stop_on_failure = y generic_container stop_on_failure = y name = "Checking_Prereq"
260
== 0"
generic_container stop_on_failure = y name = "Package_Files_distribution" condition = "$(flag_package_files_distribution) add directory stop_on_failure = n location = "E:\products\ITLM\Agent" name = "win32" destination = "$(agent_image_path)\win32" add = y descend_dirs = y remove_extraneous = n substitute_variables = n remove_empty_dirs = y unix_owner = "root" unix_user_id = 0 unix_group_id = 0 create_dirs = y remote = n compute_crc = n verify_crc = n compression_method = "stored" delta_compressable = d rename_if_locked = y replace_if_existing = y replace_if_newer = y remove_if_modified = n is_shared = n end
== 0"
add directory stop_on_failure = n location = "E:\products\ITLM\Agent" name = "cust" destination = "$(agent_image_path)\cust" add = y descend_dirs = y remove_extraneous = n
261
substitute_variables = n remove_empty_dirs = y unix_owner = "root" unix_user_id = 0 unix_group_id = 0 create_dirs = y remote = n compute_crc = n verify_crc = n compression_method = "stored" delta_compressable = d rename_if_locked = y replace_if_existing = y replace_if_newer = y remove_if_modified = n is_shared = n end end
== 0"
add win_registry_key parent_key = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" key = "Winlogon" add = n override_permissions = y stop_on_failure = y name = "Winlogon" replace_if_existing = y replace_if_newer = n remove_if_modified = n is_shared = n value replace_if_existing = y replace_if_newer = n remove_if_modified = n is_shared = n name = "DefaultUserName" type = "string" position = "replace" data = "<Administrator User>" end
262
value replace_if_existing = y replace_if_newer = n remove_if_modified = n is_shared = n name = "DefaultPassword" type = "string" position = "replace" data = "<Administrator User Password>" end
value replace_if_existing = y replace_if_newer = n remove_if_modified = n is_shared = n name = "AutoAdminLogon" type = "string" position = "end" data = "1" end
value replace_if_existing = y replace_if_newer = n remove_if_modified = n is_shared = n name = "DontDisplayLastUserName" type = "string" position = "replace" data = "0" end end
263
generic_container stop_on_failure = n name = "Agent_Installation" condition = "$(flag_agent_installation) == 0" generic_container stop_on_failure = n name = "Before_Installation" condition = "$(flag_before_installation)
== 0"
execute_user_program name = "Create the log dir on the machine" transactional = n during_install exit_codes success = 0,0 warning = 1,65535 end path = "$(system_dir)\cmd.exe" arguments = '/c "md $(target_log_dir)"' timeout = 60 unix_user_id = 0 unix_group_id = 0 user_input_required = n output_file_append = n error_file_append = n reporting_stdout_on_server = n reporting_stderr_on_server = y max_stdout_size = 10000 max_stderr_size = 10000 bootable = n retry = 1 end end end
== 0"
264
transactional = n during_install exit_codes success = 0,0 warning = 1,65535 end path = "$(agent_image_path)\cust\perl.exe" arguments = '$(agent_image_path)\cust\zinst_itlm_agent.pl "$(hostname)" "$(agent_def_file)" "$(agent_inst_file)" "$(agent_source_path)" "$(target_log_file)"' timeout = 360 unix_user_id = 0 unix_group_id = 0 user_input_required = n output_file_append = n error_file_append = n reporting_stdout_on_server = y reporting_stderr_on_server = y max_stdout_size = 10000 max_stderr_size = 10000 bootable = n retry = 1 end end end end
== 0"
add win_registry_key parent_key = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" key = "Winlogon" add = n override_permissions = y stop_on_failure = y name = "Winlogon" replace_if_existing = y replace_if_newer = n
265
remove_if_modified = n is_shared = n value replace_if_existing = y replace_if_newer = n remove_if_modified = n is_shared = n name = "DefaultPassword" type = "string" position = "replace" data = "none" end
value replace_if_existing = y replace_if_newer = n remove_if_modified = n is_shared = n name = "AutoAdminLogon" type = "string" position = "replace" data = "0" end
value replace_if_existing = y replace_if_newer = n remove_if_modified = n is_shared = n name = "DontDisplayLastUserName" type = "string" position = "replace" data = "1" end end
266
== 0"
execute_user_program name = "Remove read-only attrib on temp installation files" transactional = n during_install exit_codes success = 0,0 warning = 1,65535 end path = "$(system_dir)\attrib.exe" arguments = '-r "$(agent_image_path)\*.*" /S' timeout = 60 unix_user_id = 0 unix_group_id = 0 user_input_required = n output_file_append = n error_file_append = n reporting_stdout_on_server = n reporting_stderr_on_server = y max_stdout_size = 10000 max_stderr_size = 10000 bootable = n retry = 1 end end
remove directory location = "$(agent_image_path)" name = "$(agent_image_path)" destination = "$(agent_image_path)" remove = y descend_dirs = y remove_empty_dirs = y rename_if_locked = n stop_on_failure = n end end
267
generic_container stop_on_failure = y name = "Control_Agent_Installation" condition = "$(flag_control_agent_installation) (NOT ($(registry_key_agent) LIKE '*itlm'))"
== 0 AND
execute_user_program name = "Force the package failure and show information message" transactional = n during_install exit_codes failure = 0,65535 end path = "$(system_dir)\cmd.exe" arguments = '/c "echo During the control phase, it seems that the ITLM Agent is not right installed."' timeout = 60 unix_user_id = 0 unix_group_id = 0 user_input_required = n output_file_append = n error_file_append = n reporting_stdout_on_server = y reporting_stderr_on_server = y max_stdout_size = 10000 max_stderr_size = 10000 bootable = n retry = 1 end end end end
268
installation files set. However, to extract the information corresponding to the Agent on which the package installation has taken place, we have to read the information provided in the definition file. The installation script is in charge of getting this information from the definition file and starting the standard ITLM Agent installer with the correct arguments for that particular Agent on which the installation is about to begin. The pseudo-code structure for the script is: Test the number of input argument Open the debug log file Open the definition file Read the definition, take out comment lines and save the rest in a table Close the definition file Find the line corresponding to the current Agent Check if Proxy will be used and set correct default value if not Start the standard ITLM Agent installer with specific Agent arguments Check the return code of the standard installation Close the debug log file Hereafter, you will find the complete definition of the installation script for the installation of the ITLM Agent:
Example: A-2 Installation script for ITML Agent
#!/usr/bin/perl # # Product: zinst_itlm_agent.pl # # Description: this script install the ITLM Agent using information stored # in a definition file # # Parameter: # # First: Host name of the machine where the Agent will be installed # Second: Definition file name # Third: Official installation file # Forth: Path of the source dir # Fifth: log file # # Output : 0 = no error during the complete process # 1 = some errors during the complete process # # Author : ITLM Redbook Team
269
# # Date : 11.25.2002 # # Revision : 1.0 # # History : # # (C) COPYRIGHT IBM Corporation # All Rights Reserved # Licensed Material - Property of IBM Corporation # ################################################ # CONFIGURATION PARAMETERS ################################################ $SCRIPT_NAME="zinst_itlm_agent"; $NO_PROXY="no"; $NO_PROXY_NAME="none"; $NO_PROXY_PORT="0"; $RUNTIME_URL="/slmruntime/service"; $AGENT_INST_TRACE="y"; #Enable or disable tracing $DEBUG=1; ################################################ # Main ################################################ if ($#ARGV != 4) { print "Error - Usage: $0 <Machine Host name> <Agent Definition file> <Official installation file> <Source path> <Log file>\n"; exit 1; } ($agent_name,$agent_def_file,$agent_inst_file,$agent_source_path,$debug_file) = @ARGV; #We open the Log file if debug is turned on. open(DBG,">> $debug_file") if ($DEBUG); #Extracting date and time and set the format for month and year ($sec,$min,$hour,$day,$month,$year,$wday,$yday,$isdst)=localtime(time); $month++; $year+=1900; print DBG "***Start $SCRIPT_NAME at $month/$day/$year - $hour:$min***\n" if ($DEBUG);
270
#We open the Agent list file definition if (open(openAgentDefFile,$agent_def_file) == 0) { print DBG "The $agent_def_file File can't be opened.\n" if ($DEBUG); print DBG "***End $SCRIPT_NAME***\n" if ($DEBUG); close(DBG); exit 1; } #We put the content of the file in a table to search the data and take out comment lines #@tmpFile=<openAgentDefFile>; @tmpFile=grep(!/^#/,<openAgentDefFile>); #As the information is saved in the table, the file could be closed close(openAgentDefFile); #We get the parameter line corresponding to the machine where we install the Agent #In this case, we assume that the Agent is unique in the file. if there is more than one, we take the first one. #The i after the closing / is to ignore the Case. @AgentLine=grep(/^$agent_name/i, @tmpFile); #We take out the last carriage (in Perl v5. better to use chomp) chop ($AgentLine[0]); #We put each Agent parameter in a list @AgentAttrib =split(/;/, $AgentLine[0]); #We need to control if the Agent should use a Proxy or not, otherwise we should provide the right default value if ($AgentAttrib[6] eq $NO_PROXY ) { $PROXY_NAME=$NO_PROXY_NAME; $PROXY_PORT=$NO_PROXY_PORT; } else { $PROXY_NAME=$AgentAttrib[7]; $PROXY_PORT=$AgentAttrib[8]; } #For debugging purpose, we save the executed line print DBG "$agent_inst_file \"$agent_source_path\" \"$AgentAttrib[1]\" \"$AgentAttrib[2]\" \"$AgentAttrib[3]\" \"$AgentAttrib[4]\" \"$RUNTIME_URL\" \"$AgentAttrib[5]\" \"$AgentAttrib[6]\" \"$PROXY_NAME\" \"$PROXY_PORT\" \"$AGENT_INST_TRACE\"\n";
271
#We prepare the complete list of the parameters that are necessary for the official agent installation procedure @args = ($agent_inst_file, "$agent_source_path", "$AgentAttrib[1]", "$AgentAttrib[2]", "$AgentAttrib[3]", "$AgentAttrib[4]", "$RUNTIME_URL", "$AgentAttrib[5]", "$AgentAttrib[6]", "$PROXY_NAME", "$PROXY_PORT", "$AGENT_INST_TRACE"); #We execute the official agent installation process $RC=system(@args); #Of course, we need to know if the intsallation is right made or not. if ( $RC != 0 ) { print DBG "There was an error (RC=$RC) during the execution of the official Agent installation script.\n" if ($DEBUG); print DBG "***End $SCRIPT_NAME***\n" if ($DEBUG); close(DBG); exit $RC; } else { print DBG "No error during the execution of the official Agent installation script.\n" if ($DEBUG); } print DBG "***End $SCRIPT_NAME***\n" if ($DEBUG); close(DBG); exit 0;
272
The Proxy usage. If you dont plan to use a Proxy server, you dont need to specify the next two fields The fully qualified host name of the Proxy server if you plan to use one (optional) The TCP port of the Proxy server if you plan to use one (optional) The file could be generated from a Workbook tool like Microsoft Excel or from an Asset Management tool already deployed in your environment. Hereafter, you will find an example of the Agent definition file for the installation of the ITLM Agent:
Example: A-3 Definition file for the ITLM Agent installation
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # Product : itlm_agent.def Description : This file contains the definition of the ITLM agents in order to provide the right parameters for the installation process. For more information regarding each parameters, please refer to the IBM Tivoli Licence Manager System Administrator's Guide, GC23-4834-00 Line syntax: First field: Name of machine where the Agent will be installed fully qualified host name) Second field: Division ID Third fields: Tag of the node Forth field: Runtime server host name Fifth field: Runtime server port (default is 80) Sixth field: Customer name Seventh field: Proxy usage (only yes or no. If no, the next field are optionals) Eighth field: Proxy name Ninth field: Proxy port All fields must be separated by a ";" !! The last line must be a blank line !! The # is used to comment a line Author : ITLM Redbook team Date : 11.25.2002 Revision : 1.0
273
# History : # # (C) COPYRIGHT IBM Corporation # All Rights Reserved # Licensed Material - Property of IBM Corporation # tlm13.itsc.austin.ibm.com;3;TAG_TLM13;9.3.4.248;80;IBM Corporation;no tlm14.itsc.austin.ibm.com;3;TAG_TLM14;9.3.4.248;80;IBM Corporation;yes;tlm04;334
274
Appendix B.
275
Overview
As described in Chapter 2, IBM Tivoli License Manager general overview on page 11 the following communications may be secured over an SSL link: Between the ITLM Administration and Runtime servers Between the ITLM Administration server and Web browsers on the ITLM administrators desktops Between the ITLM Runtime server and Web browsers on the ITLM administrators accessing reports For these communications to be established, an SSL key needs to be used. This key may contain an official certificate issued by an official Certificate Authority or contain your own self-signed certificate. The following sections explain how to create a self-signed certificate to be used in a IBM Tivoli License Manager deployment. For information on how to configure your IBM Tivoli License Manager environment to be SSL enabled, refer to Chapter 4, Getting IBM Tivoli License Manager up and running on page 99.
Where, <java_rte_dir> is the directory where Java runtime is installed, for example /usr/java130/jre. 3. On the gsk5ikm IBM Key Management utility main menu, select Key Database File->New. 4. On the New Key dialog box, choose CMS Key database file as the key database type and fill out with the name of the key file: /tmpkeydir/key.kdb. 5. Click OK.
276
6. In the Password Prompt dialog box enter the password that will be used to encrypt and decrypt the key database files. Also, select Stash the password to a file option. 7. On the Create New Self-Signed Certificate window, fill out at least the following fields: Key Label Common Name Organization The label to identify the key and the certificate, for example, ITLMKEY. The fully qualified hostname of your ITLM Administration Server. In our example, tlm04. Your organization name. For example, IBM Corporation.
8. On the gsk5ikm IBM Key Management utility main menu, select Key Database File->Close. 9. Confirm the SSL files creation as shown in Example B-1.
Example: B-1 SSL key files
# cd /tmpkeydir # ls -lt total 200 -rwxrwxrwx 1 root -rwxrwxrwx 1 root -rwxrwxrwx 1 root -rwxrwxrwx 1 root #
03 02 02 02
277
7. On the Extract Certificate to a file window, make sure you select Data Type equals to Base64-encode ASCII data, the certificate file name (*.arm) and directory location. For example, itlmcert.arm stored at tmpkeydir. 8. Choose Save. 9. On the gsk5ikm IBM Key Management utility main menu, select Key Database File->Close. 10.The content of the server certificate file will be similar to Example B-2.
Example: B-2 Server certificate file
# cd /tmpkeydir # cat itlmcert.arm -----BEGIN CERTIFICATE----MIIBzTCCATagAwIBAgIEPev+bjANBgkqhkiG9w0BAQQFADArMQswCQYDVQQGEwJV UzEMMAoGA1UEChMDSUJNMQ4wDAYDVQQDEwV0bG0wNDAeFw0wMjEyMDIwMDQ0MzBa Fw0wMzEyMDMwMDQ0MzBaMCsxCzAJBgNVBAYTAlVTMQwwCgYDVQQKEwNJQk0xDjAM BgNVBAMTBXRsbTA0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDG1OareK0q 3QHvkL46cieICTRS979lClS8JzpXwrhDx5RdPenzwyGRELx64mWuDNh4NIUtqklL RcRLvSF2KHheC0j/V1m61jGVz3cIWU8qSe1rxEmzPxuwpGSsbL6KUXV/sVWu5OPJ mTqH4nceTuSzc3ZZqnR7o0cVvt89CI8EJwIDAQABMA0GCSqGSIb3DQEBBAUAA4GB AAATQH6LvzNiMjr4mydKq/haD2wflgN3otvL2UtU9gaXd881dpTu3uacYkESzIxP W+g+fd01Py+qWWpGjLXsVGycAKvOSLVEIuSyooSQB2GUZtqt3E6Vrlm81tQDhtup tNbfgRy3VqsfRFLGwnWIPejzHp/tZhi4LfbJtNpHe1aB -----END CERTIFICATE----#
Where, <java_rte_dir> is the directory where Java runtime is installed, for example, /usr/java130/jre. 2. On the ikeyman IBM Key Management utility main menu, select Key Database File->New.
278
3. On the New Key dialog box, choose JKS as the key database type and fill out with the name and location of the key file: key.jks and the tmpkeydir directory. 4. Click OK. 5. In the Password Prompt dialog box enter the password that will be used to encrypt and decrypt the key database file. We recommend that you do not set the expiration time. 6. The Key Database Content area may show several certifications already defined. Click Add to import your own self-signed certificate. Fill in the self-signed certificate file name (*.arm) and location. In our example, the self-signed certificate file name is itlmcert.arm and is stored at tmpkeydir. 7. Enter the label for the self-signed certificate. It should be the same one used during the key database files definition. For example, ITLMKEY. 8. Save the key.jks file by selecting Key Database File->Save.
279
280
Appendix C.
281
Table name
ADMIN_CUST_REL ADMINISTRATOR
Description
Maps ITLM Administrators to Customers Keeps information about the ITLM Administration and Runtime Servers Administrators Stores information on installed ITLM Agents Stores historical information on the relationship between ITLM Agents and Divisions Keeps ITLM Agents events Maintains a history of changes to ITLM Agents Stores information on the products installed on the ITLM Agents Software product categories Keeps the commands issued to ITLM Agents and ITLM Administration and Runtime Servers Maintains software products and its executable modules relation. Stores software products information Keeps configuration data Country (or region) information Keeps information about ITLM Customers, such as Customer name, account ID, and an unique Customer identifier
AGENT AGENT_DIV_HREL
282
Table name
DIVISION DIVISION_H ENDUSER
Description
Represents the ITLM Customer logical organization Keeps historical information of changes to Divisions Keeps information about the ITLM users, such as user ID, name, email address, employee number, etc. Maintains information about software entitlement per ITLM Customer Keeps historical information about the availability of licenses to Divisions, Nodes, or ITLM Agents. Represents the License enrollments of a Division, Nodes, or ITLM Agents Keeps historical information about the availability of licenses to Users Maintains the relationship between licenses and users Stores information about licenses defined in ITLM Represents licenses available to the ITLM Runtime Servers Historical information about licenses, such as volume of licenses in the pool, usage thresholds, etc. Keeps information about the modules used by the applications in order to be identified by the ITLM Agents Stores information about the machines where the ITLM Agent is installed Internal control table Keeps the profiles of the ITLM Administrators Keeps actions not allowed for the ITLM Administrator profile
ENTITLEMENT LIC_TARGET_H
MODULE
283
Table name
SERVER SERVER_H SERVICE UNKNOWN
Description
Maintains information about the ITLM Runtime Servers Historical information about changes to the ITLM Runtime Servers Historical information about services requested to the ITLM Servers Keeps information on the executable files running on the ITLM Agents that have not been yet recognized Maintains information about license usage on ITLM Agents Keeps historical information about license usage on ITLM Agents Summary snapshots of the USAGE_H Table Keeps information about the software vendors
284
285
Table name
ADMINISTRATOR
Description
Keeps information about the ITLM Administration and Runtime Servers Administrators Stores information on installed ITLM Agents Keeps the relationship information between ITLM Agents and the products installed on them Keeps the relationship information between ITLM Agents and the products installed on them that are not yet being controlled by the ITLM Agent Keeps the commands issued to ITLM Agents and ITLM Runtime Servers Maintains software products and its executable modules relation. Stores software products information Keeps configuration data Represents the ITLM Customer logical organization Keeps information about the ITLM users, such as user ID, name, email address, employee number, etc. Represents the License enrollments of a Division, Nodes, or ITLM Agents Maintains the relationship between licenses and users
AGENT AGENT_COMP_REL
AGENT_UNK_REL
LIC_TARGET_REL LIC_USER_REL
286
Table name
LICENSE MODULE
Description
Stores information about licenses defined in ITLM Keeps information about the modules used by the applications in order to be identified by the ITLM Agents Stores information about the machines where the ITLM Agent is installed Keeps the profiles of the ITLM Administrators Keeps actions not allowed for the ITLM Administrator profile Maintains information about the ITLM Runtime Servers Keeps the relationship information between ITLM Runtime Servers and Divisions Keeps information on the executable files running on the ITLM Agents that have not been yet recognized Keeps information about the software vendors
UNKNOWN
VENDOR
287
288
Appendix D.
Additional material
This redbook refers to additional material that can be downloaded from the Internet as described below.
Select the Additional materials and open the directory that corresponds with the redbook form number, SG246888.
289
290
ISO ISP ITCM ITLM ITSO JDBC JDK JVM LAN MN NAT NFS ODBC OLAP RDBMS RFC RPC SNMP SSL SWD TCP/IP TDW TMA TME TMF TMR
International Organization for Standardization Internet Service Provider IBM Tivoli Configuration Manager IBM Tivoli License Manager International Technical Support Organization Java Database Connectivity Java Development Kit Java Virtual Machine Local Area Network Managed Node Network Address Translation Network File System Open Database Connectivity Online Analytical Processing Relational Database Management System Request for Comments Remote Procedure Call Simple Network Management Protocol Secure Sockets Layer Software Distribution Transmission Control Protocol/Internet Protocol Tivoli Data Warehouse Tivoli Management Agent Tivoli Management Environment Tivoli Management Framework Tivoli Management Region
291
UDP URL VMU VPN WAN WAN WAS WLC XML XSLM
User Datagram Protocol Universal Resource Locator Vendor Managed Use Virtual Private Network Wide Area Network Wide Area network IBM WebSphere Application Server Workload License Charges eXtensible Markup Language X-Open Software License use Management
292
Related publications
The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook.
IBM Redbooks
For information on ordering these publications, see How to get IBM Redbooks on page 295.
Other publications
These publications are also relevant as further information sources:
Installing and Configuring Tivoli Enterprise Data Warehouse, GC32-0744 Tivoli Enterprise Data Warehouse Release Notes, GI11-0857 IBM Tivoli License Manager License Administrators Guide, GC23-4833 IBM Tivoli License Manager Warehouse Enablement Pack Implementation Guide (this book is available within the products installation CD-ROMs) IBM Tivoli License Manager Data Dictionary, GC23-4835 IBM Tivoli License Manager Systems Administrators Guide, GC23-4834 IBM Tivoli Configuration Manager Users Guide for Software Distribution Version 4.2, SC23-4711
Online resources
These Web sites are also relevant as further information sources: IBM Tivoli License Manager
http://www-3.ibm.com/software/sysmgmt/products/support/IBMTivoliLicenseMana ger.html
293
Index of /html/Something_about_XSLM/About_XSLM
http://www.xslm.org/html/Something_about_XSLM/About_XSLM/Original_Requireme nts
294
Related publications
295
296
Index
Numerics
1.1-TDW-0002 218 1.1-TDW-0005E 218 1.1-TDW-FP01a 218 1.1-TDW-FP02 218
C
capacity type 36, 171, 194 capacity-on-demand 10 catalog import 181 Catalog Manager 69 catalog.dat 177 catman 177 CDW 214 central data warehouse, see CDW Checking_Prereq 255 clean pages 240 COD 215 Cognos 212 Common Warehouse Metadata, see CWM 212 communications letter 162 compliance 8 Connector Architecture 86 containers 255 contracts negotiation 31 contractual license agreement 147 Control_Agent_Installation 257 CORBA 84 correlation 211 Creation Mode 173 Crystal Decisions 212 Customer 27, 61, 150 Customer Managed Use 8 customer-perceived value 10 CWM 212 CWM standard 212
A
access control 62 ADM schema 282 Administration server 24 Administration server installation 102 administrative burden 3 Administrator 26 Agent deploying 160 Agent install software package 255 Agent trace file 96 Agent_Installation 256 Agents 23, 26 AIX 5L 73 Application Server JDK 86 Asset Management 5, 30, 61 Asset Protection 5 AutoCad 167
B
backup and restore 66 Base64-encode ASCII data 278 baseline data 146 best practices 57 BI 212 bootstrap 83 bottle neck 59 Brio Technology 212 budget planning 31 buffer pool 239 Business Intelligence reporting 214 Business Intelligence, see BI 212 Business Objects 212
D
data mart 214 data mining 214 data warehouse 214 database heap 241 db.properties 89, 91 DB2 Fixes 71 DB2 hardware requirements 71 DB2 installation 102 DB2 instance 103 DB2 performance 239 DB2 schema 113
297
DB2 TCP/IP ports 74 db2java.zip 86, 107 DB2SmartGuide 246 DB2SYSTEM 104 dbsetup.bat 141 dbUser 89, 91 de-militarized zone 58 design process 147 dirty pages 239 disaster and recovery 66 disruption 56 Divisions 23, 27, 61, 149 creating 159 DMZ 58 DYK_DM 244
graphical representation 192 grouping Agents 23, 27, 159 gsk5ikm 276
H
hard stop 32, 172 hardware compliance analysis 31 health reports 228 historical data 211 historical reports 237 host name 211 HTTP Server 69 HTTP Server performance 246 httpd.conf 115 Hub Administrator 152 Hub Support 149 HyperText 55
E
Enable_Auto_logon 256 encryption 55 end-to-end view 211 entitlement 149 entitlement policies 146 ETL 210 ETL programs 213 event notification 117, 126, 155 expcat 177 Expiration Date 172 EXTENTSIZE 244 Extract Transform Load, see ETL extreme case reports 228
I
I/O Servers 241 IBM catalog manager 174 IBM DB2 instance 103 IBM Key Management utility 277 IBM License Policy 45 IBMDEFAULTBP 243 IBMModuleSSL128.dll 116 ikeyman 278 illegal software 147 impcat 181 implementation scenario 145 installation scenario 100 instance 103 INSTHOME 104 interoperability 4 inventory scan 28, 54, 156 scheduling 164 iocleaners 242243 ioservers 242243 IP address 211 IPLA 10 IT standards 147 ITLM reports 228 ITLM Administrator 62 ITLM Agent software package 255 ITLM Agent installer 268 ITLM CLI environment 176
F
failover 68 failure scenario 67 family packaging 7 fictitious company 12 file systems 57 financial information 5 firewall 56
G
gateway server 79 generic authorizations 3 getting statistics 34 governing thresholds 28 grant date 207 granularity 61
298
ITLM commands catman 177 impcat 181 ITLM Enablement Pack 185 ITLM hierarchy 60 ITLM logical components 24 ITLM pack configuration 221 install 217 ITLM performance 247 ITLM root user 30 ITLM topology 60 ITLMKEY 277 ITML commands expcat 177 tlmcli 176 ITML hardware requirements 86
management 166 license use management 2, 6 Licensing Manager 154 licensing policies 146 logbufsz 241 logfilsiz 240, 242 logical design 59, 148 logprimary 240 logsecond 240 LSD 83
M
mailRecipient 118, 127 mailSender 118, 127 Master Catalog 96, 174 extracting 177 importing 182 updating 176 measurement source code 215 metadata interchange 212 Microsoft License Management 37 mod_ibm_ssl_128.so 115 MON_HEAP_SZ 240 monitored nodes 61 multi-instance 36, 172
J
J2C 86 java heap 240 java heap size 245 Java memory usage 56 JDBC code level 104 JDK 86 JVM 246
K
kernel 93 key database 276 key factors 2 Key management utility 276 key trusted store 278 key.jks 279 key.kdb 277 Knowledge base 78
N
naming convention 60 naming policies 60 network considerations 83 Nodes 27 nodes 23, 27 NUM_IOCLEANERS 240 NUM_IOSERVERS 239
O
Object Management Group 212 ODBC 222 OLAP analysis 214 open interface 211 Oracle License Management 41 ORB listener port 84 ORB thread 246 OS performance 251
L
licence requests 54 licence usage efficiency 54 license allocation 32 license authorization 34 license checks 34 license management system 7 license pool 32, 34, 149 creating 170 maintenance 167
Index
299
P
Package_Files_distribution 256 page cleaners 239 parallel I/O 244 performance 53 DB2 239 WebSphere 245 performance tips 236 physical design 52, 145 piped sorts 241 plugged 128 plugged sever 158 PMI 245 PmiService 246 pools 149 prefetch 243 prefetchers 239 PREFETCHSIZE 244 price to value 3 procurement information 166 Proxy server 56, 69
software usage 186, 192, 196, 204 RI 214 roles 62 RTM schema 286 runstats 243 Runtime Catalog 174 Runtime server 23, 25
S
Scalability 53 self-signed certificate 277 Server Certificate file 277 SGML 30 SHARE Inc. 2 silent mode deployment 164 smtpServer 118, 127 software entitlement 23, 31, 149 creating 170 maintenance 167 management 166 software inventory 147 software inventory report 201 software life cycle planning 31 software management 174 software package 255 containers 255 definition 259 level 258 variables 257 version 258 Software Reports 29 software usage reports level analysis 196 real-time usage 204 snapshot 186 trend analysis 192 sortheap 241 source ETL scheduling 225 status 227 spying 9 SSL 156 SSL encryption 55 SSL key database 276 SSL-enabled 78 Standard Generalized Markup Language, see SGML 30 Start Date 172
Q
qualified desktops 39 quantity 172 quarterly aggregation 47 Query by option 195 query functions 18 quick analysis 214 quick recovery 66 quintessential business 10 quotas 75
R
raw data 211 RDBMS 212 real-time reports 237 real-time software usage 155 recovery system 66 Redbooks Web site 295 Contact us xxii reorgchk 243 Report Interface, see RI reports Administration server 186 real-time usage 204 Runtime server 204 software inventory 201
300
T
Tag 61 target ETL scheduling 225 status 227 Target Type 36, 172 TDW 185, 210 configuration 212, 217 TDW Control Center 215 The Open Group 2 Threshold 172 Tivoli Data Warehouse 214 data mart 214 ETL processes 215 ETL programs 213 source applications 213 warehouse packs 213 Tivoli Data Warehouse, see TDW Tivoli Endpoints 164 TLMA 222 TLMA database 282 tlmcli 176 tlmia.trc 96 TLMR database 286 tlmroot 30, 63, 151, 187, 205 tlmsrv 89, 91 Topology 156 tuning DB2 239 tuning HTTP Server 246 tuning ITLM 247 tuning OS 251 tuning tips 236 tuning WebSphere 245 TWH_CDW 215 changes 221 TWH_MART 215 TWH_MD 215 types of ETLs Central Data Warehouse 214
modifying 177 up and running 99 update JDBC level for DB2 104 Users 23, 28 users roles 62
V
validate the solution 148 value metric 3 value-oriented pricing 9 variables 257 Vendor Managed Use 8 vendor policies 8 vendor's asset protection 10 vendor's view 9 vendors policies 31 version 258 viewing reports 228 virtual memory 56 VirtualHost 78 volume licensing program 38 volume pricing 38
W
W3C 30 warehouse pack 213 was40 85 web interface 150 Web-based deployment 161 Web-based solution 11 WebSM 84 WebSphere Application Server hardware requirements 81 WebSphere Application Server TCP/IP ports 83 WebSphere performance 245 WebSphere resource analyzer 245 Wide Web Consortium 30 WLC 10 workforce 4 workload balancing 4 Workload License Charges, see WLC 10
U
Unknown file list 174 Unknown file table 174 extracting 177 managing 176
X
XML documents 30 XML interfaces 11 XSLM 2
Index
301
Z
z/OS 10 zone 53, 58 zSeries 46
302
Back cover
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.