Introducing ibm tivoli service level advisor sg246611
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Introducing ibm tivoli service level advisor sg246611

on

  • 4,219 views

 

Statistics

Views

Total Views
4,219
Views on SlideShare
4,219
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Introducing ibm tivoli service level advisor sg246611 Document Transcript

  • 1. Front coverIntroducing IBM TivoliService Level AdvisorAchieve proactive SLA managementensuring service qualityGenerate reports and identifytrends toward SLA violationsManage Service Leveland meet customerexpectations Edson Manoel J.B. Baker Filippo Giannelli Frans Sadie Sarie Weberibm.com/redbooks
  • 2. International Technical Support OrganizationIntroducing IBM Tivoli Service Level AdvisorJuly 2002 SG24-6611-00
  • 3. Take Note! Before using this information and the product it supports, be sure to read the general information in “Notices” on page xvii.First Edition (July 2002)This edition applies to the IBM Tivoli Service Level Advisor Version 1.1 and Tivoli Enterprise DataWarehouse Version 1.1 products.Comments may be addressed to:IBM Corporation, International Technical Support OrganizationDept. JN9B Building 003 Internal Zip 283411400 Burnet RoadAustin, Texas 78758-3493When you send information to IBM, you grant IBM a non-exclusive right to use or distribute theinformation in any way it believes appropriate without incurring any obligation to you.© Copyright International Business Machines Corporation 2002. All rights reserved.Note to U.S Government Users – Documentation related to restricted rights – Use, duplication or disclosure is subject torestrictions set forth in GSA ADP Schedule Contract with IBM Corp.
  • 4. Contents Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiPart 1. All about IBM Tivoli Service Level Advisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 IT Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Service Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4 Ensuring service quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.5 Service Level Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.6 Why bother with Service Level Management . . . . . . . . . . . . . . . . . . . . . . 14 Chapter 2. IBM Tivoli Service Level Advisor general overview . . . . . . . . 17 2.1 Overview of IBM Tivoli Service Level Advisor . . . . . . . . . . . . . . . . . . . . . . 18 2.2 IBM Tivoli Service Level Advisor components . . . . . . . . . . . . . . . . . . . . . 19 2.2.1 ITSLA Task Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2.2 ITSLA Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.3 ITSLA Reports Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.4 ITSLA Database Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2.5 Tivoli Enterprise Data Warehouse Server . . . . . . . . . . . . . . . . . . . . . 25 2.2.6 Tivoli Enterprise Data Warehouse Control Center . . . . . . . . . . . . . . 25 2.2.7 IBM Console Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.2.8 ITSLA ETL programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.3 Important ITSLA concepts and terminology . . . . . . . . . . . . . . . . . . . . . . . 26 2.4 A glimpse into Tivoli Enterprise Data Warehouse . . . . . . . . . . . . . . . . . . . 34 2.5 IBM Tivoli Service Level Advisor Target ETLs . . . . . . . . . . . . . . . . . . . . . 37 2.5.1 ITSLA Registration ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.5.2 ITSLA Process ETL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.6 The SLA Management process of ITSLA . . . . . . . . . . . . . . . . . . . . . . . . . 40© Copyright IBM Corp. 2002 iii
  • 5. 2.6.1 Step 1: Define and agree on Service Level Agreements . . . . . . . . . 42 2.6.2 Step 2: Select applications for source data . . . . . . . . . . . . . . . . . . . . 43 2.6.3 Step 3: Populate the ITSLA Database . . . . . . . . . . . . . . . . . . . . . . . 43 2.6.4 Step 4: Define schedules and create offerings . . . . . . . . . . . . . . . . . 43 2.6.5 Step 5: Define customers and create orders. . . . . . . . . . . . . . . . . . . 44 2.6.6 Step 6: Populate the ITSLA Measurement Data Mart database . . . . 44 2.6.7 Step 7: Evaluate data for violations and trends. . . . . . . . . . . . . . . . . 45 2.6.8 Step 8: Notification of SLA violations and trends . . . . . . . . . . . . . . . 45 2.6.9 Step 9: Access SLA reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.7 Applications providing measurement data . . . . . . . . . . . . . . . . . . . . . . . . 46 2.7.1 Becoming an ITSLA-enabled application . . . . . . . . . . . . . . . . . . . . . 46 Chapter 3. Implementation planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.1 IBM Tivoli Service Level Advisor data flow . . . . . . . . . . . . . . . . . . . . . . . . 53 3.2 Planning for supporting applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.2.1 IBM WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.2.2 IBM DB2 Universal Database Enterprise Edition . . . . . . . . . . . . . . . 57 3.2.3 Tivoli Enterprise Data Warehouse . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.3 Planning for IBM Tivoli Service Level Advisor . . . . . . . . . . . . . . . . . . . . . . 61 3.3.1 Physical considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.3.2 Architecture considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.3.3 Planning considerations for source applications . . . . . . . . . . . . . . . . 69 3.4 Planning for event notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 3.4.1 SNMP Trap notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 3.4.2 TEC Event notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 3.4.3 E-mail notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 3.5 Planning worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Chapter 4. Getting IBM Tivoli Service Level Advisor up and running . . . 79 4.1 Example scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.2 Setting up the TEDW Server machine . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.2.1 IBM DB2 UDE Server for UNIX installation . . . . . . . . . . . . . . . . . . . . 82 4.2.2 TEDW Central Warehouse and TEDW Data Mart installation . . . . . 86 4.3 Setting up the ITSLA Database Server machine. . . . . . . . . . . . . . . . . . . . 88 4.3.1 Creating the ITSLA Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 4.4 Setting up the TEDW Control Center machine . . . . . . . . . . . . . . . . . . . . . 90 4.4.1 IBM DB2 UDE Server for Windows installation . . . . . . . . . . . . . . . . . 91 4.4.2 Tivoli Enterprise Data Warehouse Control Center installation . . . . . 92 4.4.3 ITSLA ETL programs installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.4.4 Source ETLs installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 4.4.5 TEDW Control Center basic configuration . . . . . . . . . . . . . . . . . . . 100 4.4.6 Configuring the ODBC connections . . . . . . . . . . . . . . . . . . . . . . . . 103 4.5 Setting up the ITSLA Server machine . . . . . . . . . . . . . . . . . . . . . . . . . . . 106iv Introducing IBM Tivoli Service Level Advisor
  • 6. 4.5.1 IBM DB2 Client installation on AIX . . . . . . . . . . . . . . . . . . . . . . . . . 106 4.5.2 Cataloging the ITSLA Databases . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.5.3 TEDW Reports Interface installation . . . . . . . . . . . . . . . . . . . . . . . . 109 4.5.4 ITSLA Server component installation . . . . . . . . . . . . . . . . . . . . . . . 113 4.5.5 ITSLA Task Drivers installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1234.6 Setting up the ITSLA Reports machine . . . . . . . . . . . . . . . . . . . . . . . . . . 126 4.6.1 IBM WebSphere installation and configuration . . . . . . . . . . . . . . . . 127 4.6.2 ITSLA Reports Server installation . . . . . . . . . . . . . . . . . . . . . . . . . . 130Chapter 5. Administering IBM Tivoli Service Level Advisor . . . . . . . . . . 1335.1 Source ETLs management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 5.1.1 ETL Warehouse Target and Sources configuration . . . . . . . . . . . . 134 5.1.2 Schedule and run Source ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1375.2 Target ETLs management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 5.2.1 Registration Target ETL management . . . . . . . . . . . . . . . . . . . . . . 142 5.2.2 Process Target ETL management . . . . . . . . . . . . . . . . . . . . . . . . . 1505.3 User creation and management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 5.3.1 IBM SLA Console user management . . . . . . . . . . . . . . . . . . . . . . . 158 5.3.2 ITSLA Report users management. . . . . . . . . . . . . . . . . . . . . . . . . . 1635.4 Management of ITSLA components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 5.4.1 Management of offerings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 5.4.2 Management of orders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1795.5 Timing considerations for the ITSLA environment . . . . . . . . . . . . . . . . . 193 5.5.1 Scheduling ETLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 5.5.2 ITSLA evaluation schedule and time zone considerations . . . . . . . 1955.6 Trace and message log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 5.6.1 Handler configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 5.6.2 Message log files management . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 5.6.3 Trace log files management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2015.7 Startup and shutdown procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 5.7.1 IBM Tivoli Service Level Advisor components startup . . . . . . . . . . 205 5.7.2 ITSLA components shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2085.8 Backup and restore of ITSLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 5.8.1 Backing up the ITSLA environment. . . . . . . . . . . . . . . . . . . . . . . . . 210 5.8.2 Restoring the ITSLA environment . . . . . . . . . . . . . . . . . . . . . . . . . . 214Chapter 6. Service level Reports with ITSLA . . . . . . . . . . . . . . . . . . . . . . 2176.1 Logging into Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 6.1.1 Default Reports users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 6.1.2 The Ranking algorithm and categories . . . . . . . . . . . . . . . . . . . . . . 2216.2 Using Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 6.2.1 Reporting categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 6.2.2 Viewing Reports using different search criteria . . . . . . . . . . . . . . . . 229 Contents v
  • 7. 6.2.3 Additional features of Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 6.3 Administrating Reports users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 6.3.1 Creating Reports users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 6.3.2 Listing and deleting Reports users . . . . . . . . . . . . . . . . . . . . . . . . . 239 6.3.3 Disabling Reports user authentication . . . . . . . . . . . . . . . . . . . . . . 240 6.4 Reports customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 6.4.1 Integrating Reports with existing Web sites . . . . . . . . . . . . . . . . . . 242 6.4.2 Customizing the appearance of Reports . . . . . . . . . . . . . . . . . . . . . 250 6.4.3 Alternative methods for authenticating users . . . . . . . . . . . . . . . . . 255 6.5 Viewing Reports with third-party software . . . . . . . . . . . . . . . . . . . . . . . . 257 6.5.1 Using BrioQuery Designer with Reports . . . . . . . . . . . . . . . . . . . . . 257 6.5.2 Viewing Reports using Seagate Crystal Reports . . . . . . . . . . . . . . 269 6.5.3 Using BusinessObjects with Reports . . . . . . . . . . . . . . . . . . . . . . . 277 Chapter 7. Performance maximization techniques . . . . . . . . . . . . . . . . . 289 7.1 Initial considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 7.2 ITSLA Database Server tuning considerations . . . . . . . . . . . . . . . . . . . . 291 7.3 IBM DB2 Performance tuning considerations . . . . . . . . . . . . . . . . . . . . . 291 7.3.1 Small environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 7.3.2 Medium environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 7.3.3 Large environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 7.4 IBM WebSphere performance tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 7.5 IBM HTTP Server performance tuning . . . . . . . . . . . . . . . . . . . . . . . . . . 295 7.6 Presentation Services Web Console tuning . . . . . . . . . . . . . . . . . . . . . . 295 7.6.1 Medium environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 7.6.2 Large environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 7.7 Operating system performance tuning . . . . . . . . . . . . . . . . . . . . . . . . . . 296 7.7.1 Windows environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 7.7.2 AIX environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 Chapter 8. Troubleshooting the ITSLA . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 8.1 IBM DB2 Universal Database Enterprise Edition . . . . . . . . . . . . . . . . . . 300 8.1.1 Installation and configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 8.1.2 Databases creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 8.1.3 Administration issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 8.1.4 Important initial IBM DB2 commands . . . . . . . . . . . . . . . . . . . . . . . 311 8.2 Tivoli Enterprise Data Warehouse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 8.2.1 TEDW installation and configuration . . . . . . . . . . . . . . . . . . . . . . . . 312 8.2.2 TEDW administration issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 8.3 IBM WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 8.3.1 Installation and configuration issues . . . . . . . . . . . . . . . . . . . . . . . . 315 8.3.2 Administration issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 8.4 IBM Tivoli Service Level Advisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316vi Introducing IBM Tivoli Service Level Advisor
  • 8. 8.4.1 Installation issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 8.4.2 Configuration issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 8.4.3 Administration issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 8.4.4 Un-installation issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 8.5 IBM Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 8.5.1 Logon problems (UNIX platforms). . . . . . . . . . . . . . . . . . . . . . . . . . 338 8.5.2 Administration problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 8.6 TEDW Source ETLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 8.6.1 Installation issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 8.6.2 Configuration issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 8.6.3 Administration issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 8.7 IBM Tivoli Service Level Advisor Reports . . . . . . . . . . . . . . . . . . . . . . . . 344 8.7.1 Accessing Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 8.7.2 Administration issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 8.7.3 Workarounds for ITSLA Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 348Part 2. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 Appendix A. Hints and tips for un-installing ITSLA . . . . . . . . . . . . . . . . . 353 Un-installing the ITSLA core components . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 Un-installing ITSLA Task Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 Un-installing ITSLA Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 Un-installing ITSLA Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 Un-installing the ITSLA Target ETL programs . . . . . . . . . . . . . . . . . . . . . . . . 359 Remove the ITSLA Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 Un-installing the support applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 Appendix B. Service Management according to the ITIL . . . . . . . . . . . . 365 The ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 Service Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 Service Delivery disciplines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 Capacity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 Availability Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 Cost Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 Contingency Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 Service Level Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 Measuring service quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 The role of Service Level Management . . . . . . . . . . . . . . . . . . . . . . . . . . 385 The objectives of Service Level Management . . . . . . . . . . . . . . . . . . . . . 386 Specifying service levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 Service Support disciplines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 Help Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 Problem Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 Contents vii
  • 9. Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 Software Control and Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 Appendix C. IBM Tivoli Service Level Advisor Databases . . . . . . . . . . . 403 The ITSLA Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404 The ITSLA Measurement Data Mart database. . . . . . . . . . . . . . . . . . . . . . . . 407 Appendix D. Command reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 Introduction to the ITSLA CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 General usage overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 Default bundles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 Basic CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 Useful commands for ITSLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 ETL commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 Offering and order commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 Escalation commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 Appendix E. Source ETLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 Introduction to the Source ETLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 IBM Tivoli Business Systems Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 TBSM Source ETL objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 TBSM Source ETL process description . . . . . . . . . . . . . . . . . . . . . . . . . . 421 TBSM Source ETL measurement types . . . . . . . . . . . . . . . . . . . . . . . . . . 421 IBM Tivoli Enterprise Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 TEC Source ETL objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 TEC Source ETL processes descriptions . . . . . . . . . . . . . . . . . . . . . . . . . 422 TEC Source ETL measurement types . . . . . . . . . . . . . . . . . . . . . . . . . . . 423 IBM Tivoli Monitoring for Transaction Performance (TWSM) . . . . . . . . . . . . . 423 TWSM Source ETL objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423 TWSM Source ETL processes description . . . . . . . . . . . . . . . . . . . . . . . . 424 TWSM Source ETL measurement types. . . . . . . . . . . . . . . . . . . . . . . . . . 425 IBM Tivoli Distributed Monitoring (DM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 DM Source ETL objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 DM Source ETL processes descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . 425 DM measurement types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 Related publications . . . . . . . . . . . . . . . . . . . . . . ...... ....... ...... . 429 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...... ....... ...... . 429 Other resources . . . . . . . . . . . . . . . . . . . . . . . . ...... ....... ...... . 429 Referenced Web sites . . . . . . . . . . . . . . . . . . . . . . ...... ....... ...... . 430 How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . ...... ....... ...... . 431 IBM Redbooks collections . . . . . . . . . . . . . . . . . ...... ....... ...... . 431viii Introducing IBM Tivoli Service Level Advisor
  • 10. Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433 Contents ix
  • 11. x Introducing IBM Tivoli Service Level Advisor
  • 12. Figures 1-1 IT Service perceived by the end user and in reality . . . . . . . . . . . . . . . . . 6 1-2 Service Delivery life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1-3 Service Delivery in context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1-4 Point-solution based management infrastructure . . . . . . . . . . . . . . . . . 10 1-5 Customer, service provider, and service management . . . . . . . . . . . . . 11 1-6 Service Level Management iterative process . . . . . . . . . . . . . . . . . . . . 12 2-1 ITSLA core and logical components relationship . . . . . . . . . . . . . . . . . . 20 2-2 ITSLA Database component access . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2-3 ITSLA Measurement Data Mart access . . . . . . . . . . . . . . . . . . . . . . . . . 24 2-4 A typical TEDW environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2-5 ITSLA Registration ETL process model . . . . . . . . . . . . . . . . . . . . . . . . . 38 2-6 ITSLA Process ETL process flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2-7 How TSLA collects and stores measurement data . . . . . . . . . . . . . . . . 40 2-8 End-to-Eend SLA Management process flow . . . . . . . . . . . . . . . . . . . . 41 2-9 A typical Service Level Management process flow . . . . . . . . . . . . . . . . 42 3-1 ITSLA data flow scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3-2 ITSLA architecture component placement . . . . . . . . . . . . . . . . . . . . . . . 65 4-1 Installation scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4-2 Install DB2 V7 - DB2 UDB Enterprise Edition . . . . . . . . . . . . . . . . . . . . 83 4-3 Create DB2 Services - DB2 Instance db2inst1 . . . . . . . . . . . . . . . . . . . 84 4-4 Administration Server screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4-5 Install type dialogue window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4-6 Select features dialogue window - TEDW Central Data Warehouse . . . 87 4-7 TEDW Central Data Warehouse and Data Mart installation . . . . . . . . . 88 4-8 Select DB2 Enterprise Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4-9 Select features dialogue window - TEDW control server . . . . . . . . . . . . 93 4-10 TEDW control server installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4-11 Path to the installation media for the ITSLA ETL programs . . . . . . . . . . 96 4-12 ITSLA ETL programs installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 4-13 TEDW Source ETLs setup type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 4-14 Path to the installation media for the application packages . . . . . . . . . . 99 4-15 TEDW Source ETLs installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4-16 TWH_MD as control database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4-17 DYK_PROC_DYK_DM_TARGET user ID information . . . . . . . . . . . . 102 4-18 ODBC configuration - System DSN tab . . . . . . . . . . . . . . . . . . . . . . . . 103 4-19 Install DB2 V7 - DB2 Administration Client . . . . . . . . . . . . . . . . . . . . . 107 4-20 Create DB2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 4-21 Install type dialogue window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110© Copyright IBM Corp. 2002 xi
  • 13. 4-22 Select features dialogue window - TEDW Report Interface . . . . . . . . . 110 4-23 Tivoli Presentation Services ports panel . . . . . . . . . . . . . . . . . . . . . . . 111 4-24 TEDW Report Interface installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 4-25 ITSLA Server component installation. . . . . . . . . . . . . . . . . . . . . . . . . . 114 4-26 ITSLA Database dialogue window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 4-27 ITSLA Measurement Data Mart database dialogue window . . . . . . . . 116 4-28 Port information for the ITSLA Server installation . . . . . . . . . . . . . . . . 117 4-29 ITSLA event notifications window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 4-30 Configuring SNMP Trap event notification . . . . . . . . . . . . . . . . . . . . . . 119 4-31 Configuring Tivoli Enterprise Console event notification . . . . . . . . . . . 120 4-32 Configuring e-mail notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 4-33 Configuring e-mail notification - Part 2 . . . . . . . . . . . . . . . . . . . . . . . . . 122 4-34 ITSLA Server installation confirmation window . . . . . . . . . . . . . . . . . . 123 4-35 ITSLA Task Drivers component installation . . . . . . . . . . . . . . . . . . . . . 124 4-36 ITSLA Task Drivers communication ports . . . . . . . . . . . . . . . . . . . . . . 125 4-37 ITSLA Task Drivers installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 4-38 IBM WebSphere Application Server configuration panel . . . . . . . . . . . 128 4-39 IBM WebSphere configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 4-40 ITSLA Reports component installation. . . . . . . . . . . . . . . . . . . . . . . . . 130 4-41 Specify a node name for you ITSLA Report Server . . . . . . . . . . . . . . . 131 4-42 ITSLA Report Server installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 5-1 Properties window of Warehouse Sources . . . . . . . . . . . . . . . . . . . . . 135 5-2 Tables of Warehouse Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 5-3 Processes folder of TAPM Subject Areas . . . . . . . . . . . . . . . . . . . . . . 139 5-4 Set to Production mode TAPM Source ETL steps . . . . . . . . . . . . . . . . 141 5-5 Select schedule for Registration ETL. . . . . . . . . . . . . . . . . . . . . . . . . . 145 5-6 Registration ETL Schedule window . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 5-7 Work in Progress selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 5-8 Immediately run the first step of the Registration ETL . . . . . . . . . . . . . 148 5-9 See log information for failed ETL Registration step . . . . . . . . . . . . . . 149 5-10 Configuration of Notification for the Registration ETL . . . . . . . . . . . . . 150 5-11 Select Schedule for Process ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 5-12 Define Schedule for Process ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 5-13 Start Work in Progress tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 5-14 Manually run the first step of the Process Target ETL . . . . . . . . . . . . . 155 5-15 Start Notification dialogue for Process ETL . . . . . . . . . . . . . . . . . . . . . 156 5-16 IBM Web Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 5-17 User creation task in the General window . . . . . . . . . . . . . . . . . . . . . . 161 5-18 Service offering specialist role selection . . . . . . . . . . . . . . . . . . . . . . . 162 5-19 IBM Console starting page for service offering specialist user . . . . . . 163 5-20 Log in with user Sawyer to ITSLA Reports . . . . . . . . . . . . . . . . . . . . . 166 5-21 Manage Offerings window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 5-22 Create Schedule window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169xii Introducing IBM Tivoli Service Level Advisor
  • 14. 5-23 Create Period window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1705-24 Select Schedule window with a new schedule defined . . . . . . . . . . . . 1725-25 Resource Type tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1735-26 Select QoS ROUNDTRIPTIME metric to configure . . . . . . . . . . . . . . . 1745-27 SLO Configuration dialogue window . . . . . . . . . . . . . . . . . . . . . . . . . . 1765-28 Configuration dialogue window for SLO breach values . . . . . . . . . . . . 1775-29 Create Customized Offering Components window . . . . . . . . . . . . . . . 1785-30 Confirm Offering window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1795-31 Manage Orders window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1805-32 Select Customer dialogue window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1815-33 Create Customer window with a new realm defined . . . . . . . . . . . . . . 1825-34 Select Customer dialogue window with new customer defined . . . . . . 1835-35 Assign Resources to order offering component . . . . . . . . . . . . . . . . . . 1845-36 Include Resources dialogue window . . . . . . . . . . . . . . . . . . . . . . . . . . 1855-37 Select Resource Definition Type dialogue window . . . . . . . . . . . . . . . 1865-38 Select Resources window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1875-39 Include Resources window with a new component defined. . . . . . . . . 1885-40 Assign Resources window with a complete offering component . . . . . 1895-41 The Manage Orders screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1905-42 SLA State screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1915-43 View Violation screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1925-44 Data Flow in the ITSLA environment . . . . . . . . . . . . . . . . . . . . . . . . . . 1935-45 Configure logging for IBM Console environment . . . . . . . . . . . . . . . . . 1995-46 Properties dialogue window for tracing handler . . . . . . . . . . . . . . . . . . 2005-47 Enable trace logging on the IBM Console . . . . . . . . . . . . . . . . . . . . . . 2046-1 Reports sign-on screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2186-2 Customer user view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2196-3 Executive user view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2206-4 Operations user view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2216-5 Operations user ranking categories . . . . . . . . . . . . . . . . . . . . . . . . . . . 2256-6 Trends Report screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2276-7 Violations Report screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2286-8 Results Report screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2296-9 Time Period drop-down menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2316-10 SLA Type drop-down menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2326-11 The Search field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2336-12 Maximum rows to display feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2346-13 Additional Web links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2356-14 Report graph using Results Report category . . . . . . . . . . . . . . . . . . . . 2366-15 Graph Data page view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2376-16 BrioQuery Database Connection Wizard . . . . . . . . . . . . . . . . . . . . . . . 2596-17 Query screen for DYK_CAT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2606-18 Dragging Violationview to the Content window . . . . . . . . . . . . . . . . . . 261 Figures xiii
  • 15. 6-19 Adding the selected items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 6-20 Limiting the items for query processing . . . . . . . . . . . . . . . . . . . . . . . . 263 6-21 Query results for limited Violationview . . . . . . . . . . . . . . . . . . . . . . . . . 264 6-22 New report screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 6-23 Report results table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 6-24 Two-dimensional graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 6-25 Three-dimensional graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 6-26 Report gallery with Custom button selected . . . . . . . . . . . . . . . . . . . . 270 6-27 Choose SQL Table window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 6-28 Insert fields and report design page. . . . . . . . . . . . . . . . . . . . . . . . . . . 272 6-29 Select Expert being used to limit the violation dates . . . . . . . . . . . . . . 273 6-30 The preview screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 6-31 Chart Expert box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 6-32 The Data tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 6-33 Report preview screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 6-34 Define Universe Parameters window . . . . . . . . . . . . . . . . . . . . . . . . . . 278 6-35 Parameters of database connection window . . . . . . . . . . . . . . . . . . . . 279 6-36 Second step of Universe creation process . . . . . . . . . . . . . . . . . . . . . 280 6-37 Select Universe as data access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 6-38 Query Panel - Report for SLA violations Universe . . . . . . . . . . . . . . . . 282 6-39 Business Object Report for max violations . . . . . . . . . . . . . . . . . . . . . 283 6-40 Apply templates to report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 6-41 BusinessObject customized report . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 6-42 Create a condition in a BusinessObjects query . . . . . . . . . . . . . . . . . . 286 6-43 List of consumer names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 6-44 BusinessObjects window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 B-1 The Service Management disciplines . . . . . . . . . . . . . . . . . . . . . . . . . 368 B-2 Key relationships among Service Management disciplines . . . . . . . . . 371 B-3 Performance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 B-4 Service Delivery quality perception . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 B-5 Levels of service and customer satisfaction . . . . . . . . . . . . . . . . . . . . 384 B-6 Service level specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 B-7 Incident priority. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 B-8 Cycles of change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 B-9 The Change Advisory Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 B-10 The SC&D process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401xiv Introducing IBM Tivoli Service Level Advisor
  • 16. Tables 3-1 Default TCP/IP port numbers used by the TEDW . . . . . . . . . . . . . . . . . 60 3-2 Ports used by the ITSLA components . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3-3 Hardware requirements for ITSLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3-4 Single machine installation hardware requirements for ITSLA . . . . . . . 63 3-5 Software requirements for ITSLA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3-6 ITSLA Web browser support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3-7 Supported source Tivoli applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3-8 Planning worksheet for IBM WebSphere Application Server . . . . . . . . . 76 3-9 Planning worksheet for databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 3-10 Planning worksheet for ITSLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 3-11 Planning worksheet or event notification . . . . . . . . . . . . . . . . . . . . . . . . 78 4-1 ITSLA Databases installation scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 4-2 Measurement source codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 4-3 Tivoli source databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5-1 IBM Tivoli source application and Warehouse Source and Targets . . 134 5-2 Subject Areas and related Tivoli applications . . . . . . . . . . . . . . . . . . . 138 5-3 IBM SLA roles and associated tasks on the IBM Web Console . . . . . 159 5-4 View values and authorization levels for Report users . . . . . . . . . . . . 164 5-5 User manipulation commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 5-6 Local times for SLA evaluation and peak period start times . . . . . . . . 196 5-7 Locations of message log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 5-8 Available ITSLA trace loggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 5-9 Commands to start ITSLA components . . . . . . . . . . . . . . . . . . . . . . . . 206 5-10 Commands to shutdown ITSLA components. . . . . . . . . . . . . . . . . . . . 208 6-1 Users and associated ranking categories . . . . . . . . . . . . . . . . . . . . . . 223 6-2 Included JSP files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 6-3 Available query and display classes . . . . . . . . . . . . . . . . . . . . . . . . . . 245 6-4 Available filter parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 6-5 Available input field names for searching . . . . . . . . . . . . . . . . . . . . . . 248 6-6 Available parameters for maximum rows to display. . . . . . . . . . . . . . . 250 6-7 Customizable table column parameters. . . . . . . . . . . . . . . . . . . . . . . . 251 6-8 Customizable table properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 6-9 Customizable graph properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 7-1 Definition of small, medium, and large ITSLA environment . . . . . . . . . 290 8-1 /etc/systems parameters on Sun Solaris . . . . . . . . . . . . . . . . . . . . . . . 301 8-2 Parameters for a Sun Solaris IBM DB2 server . . . . . . . . . . . . . . . . . . 302 8-3 IBM DB2 command reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 C-1 DYK_CAT database tables for the DB2ADMIN schema . . . . . . . . . . . 404© Copyright IBM Corp. 2002 xv
  • 17. C-2 DYK_CAT database tables for the MM schema . . . . . . . . . . . . . . . . . 405 C-3 DYK_CAT database views for the DB2ADMIN schema . . . . . . . . . . . 406 C-4 DYK_DM database tables for the DYK schema . . . . . . . . . . . . . . . . . 407 D-1 Order commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 D-2 Offering commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415xvi Introducing IBM Tivoli Service Level Advisor
  • 18. NoticesThis 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. Consultyour 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 IBMproduct, program, or service may be used. Any functionally equivalent product, program, or service thatdoes not infringe any IBM intellectual property right may be used instead. However, it is the usersresponsibility 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 licenseinquiries, 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 suchprovisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATIONPROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS ORIMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimerof 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 madeto the information herein; these changes will be incorporated in new editions of the publication. IBM maymake improvements and/or changes in the product(s) and/or the program(s) described in this publication atany time without notice.Any references in this information to non-IBM Web sites are provided for convenience only and do not in anymanner serve as an endorsement of those Web sites. The materials at those Web sites are not part of thematerials 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 withoutincurring any obligation to you.Information concerning non-IBM products was obtained from the suppliers of those products, their publishedannouncements or other publicly available sources. IBM has not tested those products and cannot confirmthe accuracy of performance, compatibility or any other claims related to non-IBM products. Questions onthe 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 themas 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 businessenterprise is entirely coincidental.COPYRIGHT LICENSE:This information contains sample application programs in source language, which illustrates programmingtechniques on various operating platforms. You may copy, modify, and distribute these sample programs inany form without payment to IBM, for the purposes of developing, using, marketing or distributing applicationprograms conforming to the application programming interface for the operating platform for which thesample 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 ofdeveloping, using, marketing, or distributing application programs conforming to IBMs applicationprogramming interfaces.© Copyright IBM Corp. 2002 xvii
  • 19. TrademarksThe following terms are trademarks of the International Business Machines Corporation in the United States,other countries, or both: AIX® Perform™ SP2® DB2® pSeries™ Tivoli® DB2 Universal Database™ Redbooks™ Tivoli Enterprise™ IBM® Redbooks(logo)™ Tivoli Enterprise Console® Informix® RETAIN® TME® Netfinity® RS/6000® WebSphere® NetView® SP™ xSeries™The following terms are trademarks of International Business Machines Corporation and Lotus DevelopmentCorporation in the United States, other countries, or both: Lotus® Notes® Word Pro®The following terms are trademarks of other companies:ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the UnitedStates, other countries, or both.Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in theUnited States, other countries, or both.Java and all Java-based trademarks and logos are trademarks or registered trademarks of SunMicrosystems, 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 SecureElectronic Transaction LLC.Other company, product, and service names may be trademarks or service marks of others.xviii Introducing IBM Tivoli Service Level Advisor
  • 20. Preface IBM Tivoli Service Level Advisor Version 1.1 is a Service Level Management solution for providers of IT Services. It simplifies and automates the process of managing service level agreements, enabling IT organizations to proactively manage and report on service levels from across the management infrastructure. In a nutshell, IBM Tivoli Service Level Advisor Version 1.1 enables you to: Define services from a user perspective, including response time and availability metrics. Automate service level agreement validation and receive alerts for service level agreement violations. Identify and fix performance and availability problems before they occur. Provide flexible, Web-based reports to clients, executives, and IT staff. The primary objective of this Redbook is to introduce the new IBM Tivoli offering for defining and managing service level agreements, and is targeted at the technical professional responsible for providing services in an IT organization. It can be used as a reference book upon the deployment of IBM Tivoli Service Level Advisor Version 1.1 guiding you during the planning, installation, configuration, administration, and troubleshooting, as well as general product usage phases, with focus on how to effectively deploy this product in a way that quickly generates real business value for customers. This redbook is a valuable addition to existing product documentation and should be read in conjunction with the official product documentation, which complements some of the concepts explained in this book. General knowledge of the Tivoli Framework, general Tivoli applications, Business Intelligence and database implementation, and Web application servers is assumed.The team that wrote this redbook This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Austin Center.© Copyright IBM Corp. 2002 xix
  • 21. Edson Manoel is a Software Engineer at IBM Corporation - International Technical Support Organization, Austin Center. He applies his extensive field experience as an IT Specialist to his work at the ITSO in the Systems Management area. Prior to joining the ITSO, Edson worked in the IBM Software Group as a Tivoli Technology Ambassador and in IBM Brasil Professional Services Organization as a Certified IT Specialist. He was involved in numerous projects, designing and implementing systems management solutions for IBM customers and Business Partners. Edson holds a BSc degree in Applied Mathematics from Universidade de Sao Paulo, Brazil. J.B. Baker is a Software Engineer for the IBM Tivoli Software Group in Research Triangle Park, North Carolina. He holds a degree in Psychology and Anthropology from the University of North Carolina at Chapel Hill. Upon graduation, he joined IBM in 1999 where he served as a Systems Administrator for the e-Business Web Content Hosting Group, until joining IBM Tivoli in 2000. He is a Cisco Certified Network Associate and is currently pursuing a Certification for Information System Security Professional (CISSP). Filippo Giannelli is an IT Specialist at IBM Integrated Technology Services, Italy. He has three years of experience in the Information Technology field. He has worked at IBM for three years. He holds a Masters degree in Electronic Engineering from Universita La Sapienza in Rome. His areas of expertise include the architecture and implementation of Tivoli Solutions in the Configuration and Operation area, in the Application Management area, and the Web Services, Management area. Frans Sadie is an Advisory IT Specialist at IBM Integrated Technology Services, South Africa. He has six years of experience in the Information Technology field. He holds a Bachelors of Commerce degree in Industrial Psychology from the Rand Afrikaans University and a Honours Bachelors of Commerce Degree in Business Management from the University of South Africa. His areas of expertise include the architecture, design, and implementation of Tivoli systems management solutions, as well as business process design and re-engineering. His product experience includes the Tivoli Core products and the “Tivoli Manager for” product suite on the AIX and Windows platforms. He is a Certified Tivoli Consultant in Tivoli Framework, Tivoli Inventory, and Tivoli Distributed Monitoring. Sarie Weber is an IT Specialist from Pretoria, South Africa. She joined IBM South Africa in 1997 and is currently working in IBM Integrated Technology Services. She has experience in the Information Technology field. She holds a Honours BSc degree in Computer Science from the Potchefstroom University. Her areas of expertise include the Tivoli range of core products, AIX, and Windows. She is certified in Tivoli Framework, Tivoli Distributed Monitoring, and Tivoli Inventory.xx Introducing IBM Tivoli Service Level Advisor
  • 22. Thanks to the following people for their contributions to this project: International Technical Support Organization, Austin Center Bart Jacob, Morten Moeller, Chris Blatchley, Julie Czubik IBM Tivoli Service Level Advisor Development, Performance, and Quality Assurance teams Kathy Hebblethwaite, Bryan Ellington, Ping Chang, Jayne Regan, Chris Karstens, Kevin Kuhner, Eswara Kosaraju, Steve Tremper, Brian Jeffrey IBM Tivoli Early Support Programs Jon O Austin and Gary Forghetti IBM Tivoli Market Management Business Impact & Event Solutions Michael Tabron IBM Tivoli Worldwide Sales Enablement David Hobbs Technical Evangelism, EMEA Product Management Lewis TrokeBecome a published author Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. Youll team with IBM technical professionals, Business Partners and/or customers. Your efforts will help increase product acceptance and customer satisfaction. As a bonus, youll develop a network of contacts in IBM development labs, and increase your productivity and marketability. Find out more about the residency program, browse the residency index, and apply online at: ibm.com/redbooks/residencies.htmlComments welcome Your comments are important to us! Preface xxi
  • 23. 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 Send your comments in an Internet note to: redbook@us.ibm.com Mail your comments to: IBM Corporation, International Technical Support Organization Dept. JN9B Building 003 Internal Zip 2834 11400 Burnet Road Austin, Texas 78758-3493xxii Introducing IBM Tivoli Service Level Advisor
  • 24. Part 1Part 1 All about IBM Tivoli Service Level Advisor In this part we provide a great deal of information on all aspects of IBM Tivoli Service Level Advisor concepts, architecture, planning, installation, configuration, product administration, and product usage.© Copyright IBM Corp. 2002 1
  • 25. 2 Introducing IBM Tivoli Service Level Advisor
  • 26. 1 Chapter 1. Introduction The primary topics of the discussions in this chapter are the principles behind Service Level Management from an IT Service Delivery organization standpoint, as close as possible to those presented in the Information Technology Infrastructure Library (ITIL) published by the British government’s Central Computing and Telecommunications Agency (CCTA), and from those in the context of the IBM approach to Service Level Management with IBM Tivoli Service Level Advisor. This chapter contains the following topics: IT Services Service Delivery Service Management Service Level Management Service Level Agreements© Copyright IBM Corp. 2002 3
  • 27. 1.1 Overview In the context of delivering services in a complex IT environment, accomplishing a high level of customer satisfaction requires the IT function of an organization to have a full understanding of and insight into the different aspects of its operation and performance in terms of efficiency and effectiveness. When the IT organization fails to ensure operational performance the business may turn to an outsourcer that may quickly, accurately, and economically meet its needs. To prevent this defection, an IT organization must improve service delivery while spending less money. Service Level Management can offer IT organizations the ability to deliver the level of service that will keep their businesses competitive. Running a customer focused, cost conscious information technology (IT) organization is not an easy task. Today an increasing number of businesses are putting pressure on their IT departments to think of themselves as competitive corporate allies. This originates primarily from three main reasons: 1. Desire to reduce costs Businesses are constantly seeking ways to reduce costs, and IT costs are not immune. This has given rise to an increasing number of outsourcing service providers, each promising to deliver reliable service while off-loading the costly burdens of staffing, procuring, and maintaining an IT organization. Enterprises that do not outsource are demanding more accountability from their IT organizations as well as demanding that IT aligns with business goals, not the other way around. In both cases, there is the concept of a service level agreement, which represents a contract of service delivery between IT and its customers. As a result, IT departments need management services that focus on and support business processes and service delivery rather than just simple monitoring of the IT resources, such as disk space monitoring and server availability. 2. Use of IT Services to gain a competitive advantage Businesses have recognized that electronic and online services can be a significant competitive weapon. Beating competition is almost always achieved through speed to market. Therefore IT teams need to be able to respond quickly in deploying services such as online procurement, consumer purchasing mechanisms, and supply-chain delivery in response to the aggressive goals of their companies.4 Introducing IBM Tivoli Service Level Advisor
  • 28. Given that there often are significant amount of money at risk (win if the IT department deploys successfully, and lose if the services become unavailable or inaccessible) there must be a flexible but very robust set of management tools and services deployed as part of the IT infrastructure. Systems like this involve networks, servers, and application management to succeed, as well as focus on the overall service delivery. 3. Increased pace of change Competition continues to quicken the pace of change. As companies turn more and more to the network in order to market, sell, and deliver their products and services, they must now focus on quick delivery from IT. These requirements force IT organizations to continuously improve productivity and reduce costs while maintaining and delivering a consistent high level of service. IT organizations are being forced to improve alignment with their internal customers and developing a competitive mind set using the concept of Service Level Management. Service Level Management can also provide the tool that enables IT to match the service delivered to the real business need. Before jumping into the details of Service Level Management, we will take a look at the concepts of IT Services, Service Delivery, and Service Management. We will stay as close as possible to the definitions provided by the ITIL, as it provides the best practices for the management of an IT infrastructure. Appendix B, “Service Management according to the ITIL” on page 365, provides a great deal of information on service management in terms of the ITIL.1.2 IT Services For the purpose of the current discussion, the following definition of IT Service will be used in this redbook: A set of related functions provided by IT systems that supports one or more business areas and facilitates the achievement of corporate objectives and business goals in a timely and cost-effective manner. This service can be made up of IT and non-IT facilities and fulfills one or more needs of the customer. Such services should be perceived by the customers as being a self-contained, coherent whole. Examples are software, hardware, and communication facilities. Figure 1-1 on page 6 shows a customer receiving IT Services without realizing that there is an entire structure in place working together in order to fulfill the customer’s requirements. Chapter 1. Introduction 5
  • 29. Monitoring Implementing Troubleshooting IT Services Planning Customer Figure 1-1 IT Service perceived by the end user and in reality There are a couple of questions that come from the above definition: Who does provide the service? In order to provide a service in a timely and cost-effective manner, the service provider is required to provide all the equipment, skills, procedures, and documentation required to support the service, and ensure that the service is reliable, efficient, and correct. This may be very costly and resource-consuming to overcome, so instead of realizing all of the above within the IT department, more and more companies choose to acquire one or more sub-services from external providers. In this case the IT department is still the service provider to the users, but the IT department itself may be also be the receiver the true provider of the service. This lets us know that a service can rely on other services and still be perceived by the end receiver of the service as a hole entity. Who pays for the service? Another question raised by the definition is that of accountability. The word service suggests that the users of the service are customers, and this in turn suggests that the service provider is paid to provide the service. In the context of IBM Tivoli Service Level Advisor, a customer is a party that enters into an agreement with the service provider on the level the service will be delivered.6 Introducing IBM Tivoli Service Level Advisor
  • 30. Customers can be given access to the results of those agreements. Customers can be internal (members of a department within the enterprise) or external (a member, department, or company) associated with a service provider.1.3 Service Delivery Delivering an IT Service requires careful planning of deploying, monitoring, supporting, and reporting. The main motivation to perform all these tasks is that customers’ expectations must be met. This also supports the decision-making while planning the service delivery. The actual execution of the tasks is taken care of by processes in the Service Support area. However, the responsibility of ensuring that the required infrastructure, capacity, and operational procedures are in place lies within the Service Delivery area. Refer to “Service Delivery disciplines” on page 371 for additional details. The IT Service Delivery life cycle does not vary from that of other services. See Figure 1-2. Service Delivery P Pl an an lv e Re sso ep STO P po Di or t t P Pl Plan an an loy D ep Service Support Figure 1-2 Service Delivery life cycle Chapter 1. Introduction 7
  • 31. Once the various components have been deployed they must be monitored to verify that the targets are met. If this is not the case, corrections have to be applied in order to meet the targets, and of course it must be verified that the corrections have no impacts other than those anticipated. Pro-active monitoring of the components is not the only way of identifying problems that might put the service delivery in jeopardy. The end users play an important role by reporting irregularities and disturbances to the Service Delivery. A Help Desk must be established to receive, register, and (if possible) answer calls from end users, which are often known as incidents. If no solution to the problem is available, the Problem Management processes will be used to provide one. In addition to problems reported by end users, the Help Desk may also receive incidents generated by the tools monitoring the components that make up a service. Most of these automatically generated incidents can be associated with well-known solutions—tasks recovering or circumventing the problematic situation. Some of these well-known solutions may be invoked automatically—either directly by the monitoring tools generating the incident, or by the tools used by the Help Desk. Other incidents may require manual intervention or authorization before the well-known solutions can be applied. Finally, the last group of incidents has no known solutions associated with them. These incidents are handled by the Help Desk and passed on to Problem Management for problem diagnosis and resolution, Change Management for authorization, and finally to the group responsible for deploying the change for implementation.8 Introducing IBM Tivoli Service Level Advisor
  • 32. problem Help Desk incident Change request change Delivery solution report Approved Change Problem Management request Software Delivery & Control Change Management Figure 1-3 Service Delivery in context It is evident that in order to keep a consistently high level of any service, changes that effect the provider’s ability to deliver the service must be authorized, planned, and executed thoroughly. The service provider must have procedures in place to help assess the impact of a change to any component in the service hierarchy. Also, procedures to apply the changes securely and to verify that the change actually had the desired impact are needed.1.4 Ensuring service quality Providing a service requires a dedicated and focused infrastructure consisting of hardware, software, communication equipment and facilities, documentation, and skills required to support the provision of the IT Service. In order to monitor the components of a service, general and/or service-specific monitoring tools have to be deployed either as an integral part of the service deployment or as independent, self-contained service. These monitors are typically implemented as part of the service components themselves or as integral part of component-specific tools used to manage the components. The capabilities of the monitoring tools may—or may not—support management and operation of the service from, and reporting to, a central command center. This functionality, however, is a necessity when delivering services, partly because of the need to allow the support staff to fulfill their mission, and partly to enable centralized diagnosis and reporting of all the components of a service. Chapter 1. Introduction 9
  • 33. In other words, an extra layer of service has to be established in order to provide functions and facilities that enable managing of the service from a central command center. These functions must include monitoring, event forwarding and escalation, measurement data gathering, and status reporting from the service components, and allow for operation and configuration of the components from the central command center. This service layer is called the management services layer. Server Service Server Service service III monitoring Server Service I events service II reporting service I Server System Mgmt. Subsystem Server System Mgmt. service III Subsystem Service I operation service II System Mgmt. Tools configuration service I Client System Mgmt. Subsystem Client System Mgmt. Subsystem Client I System Mgmt. Tools Client Service Client Service Client Service I Figure 1-4 Point-solution based management infrastructure It goes without saying that the general management service of choice must be so versatile that the majority of—if not all—services delivered are supported. The management service will have to have a modular structure to enable deployment of special functions for specific services, while reusing the basic functions provided by the management service. In this way the basic management can be extended to fit the specific needs of a given mix of services - operating systems, subsystems, networking, and applications alike. Based on this, we define Service Management as: The management of an IT infrastructure of hardware, software, communications equipment and facilities, documentation, and skills used to provide the required service at the required level of quality.10 Introducing IBM Tivoli Service Level Advisor
  • 34. According to this definition, service management relies upon the internal IT infrastructure management and the technical environment, as well as managing third-party contractors. IT Service Management IT Service Provision Customer Third-Party Hardware management Service IT infrastructure management Provider Skills Software Documentation Figure 1-5 Customer, service provider, and service management1.5 Service Level Management Service Level Management is the process of negotiating, defining, and managing the levels of IT Service that are required and cost-justified. The Service Management goal is important because it emphasizes the quantification of services. Therefore, when defining the objectives for the Service Level Management processes, the deliverable should be specified in quantifiable terms. Examples of such definitions are as follows: IT Services are catalogued. IT Services are quantified in terms that both customer and IT provider understand. Internal and external targets of IT Services are defined and agreed upon. Achievement of agreed service targets is reached. Chapter 1. Introduction 11
  • 35. The quantification of objectives applies to all three parts of the scope of the Service Level Management process and involves the management of IT Services between the customer organization and the IT Services organization, the IT Services organization and its external suppliers, and the IT Services organization and its internal departments. According to this we can define Service Level Management (SLM) as follows: The iterative, disciplined, proactive methodology and procedures used to ensure that adequate levels of service are delivered to all IT users in accordance with business priorities and at acceptable cost. Negotiate/Define implementation Review Manage Figure 1-6 Service Level Management iterative process A key to the success of Service Level Management is correctly quantifying the services being provided. Unless there is an agreed-upon method of how services are to be measured, there is no way of knowing whether targets have been met or not. Service Level Management is responsible for understanding and documenting the customer requirements and translating them into a set of understandable measures.12 Introducing IBM Tivoli Service Level Advisor
  • 36. Service Level Management is a means for the lines of business (LOB) and ITorganization to explicitly set their mutual expectations for the content and extentof IT Services. It also allows them to determine in advance what steps will betaken if these conditions are not met. The concept and application of ServiceLevel Management allows IT organizations to provide a business-oriented,enterprise-wide service by varying the type, cost, and level of service for theindividual LOB.In order to accomplish Service Level Management and really manage the qualityof service provided by an internal IT organization or by an external serviceprovider, establishing Service Level Agreements is a must. For the context of thisredbook, we define Service Level Agreement (SLA) as follows:An agreement or contract between a service provider and a customer of thatservice, which sets expectations for the level of service with respect toavailability, performance, and other measurable objectives.There are various types of Service Level Agreements. From an IT organizationstandpoint, the most common are: Internal or in-house SLAs These are agreements negotiated between the service provider, such as an IT department, and an in-house user or department. These kinds of SLAs are sometimes used by the company as an important selling point to external customers, ensuring the high quality of the company products. External SLAs These are agreements that a company may establish when purchasing services from an external provider. For example, company A may hire an Internet services provider (ISP) to host its Web site requiring 100 percent availability. If company A gets less than acceptable service from its ISP, without this SLA in place, company A may not have many options to force the ISP to address the problem or to terminate their contract without penalties.There are a number of components that make up an SLA, including the following: Term Defines the period of time the SLA will cover. Scope Defines the services covered in the agreement. Limitations Define what must happen in order for the requested service levels to be provided. Chapter 1. Introduction 13
  • 37. Service level objectives Define the level of services that both the customer and the service provider agree on. This is a specification of a metric that is associated with a guaranteed level of service. Service level indicators Define the means by which the service level objectives can be measured. Non-performance Defines what happens if the service provider does not meet the objectives. Exclusions Specifies what is not covered in the SLA. Reviews Establish scheduled reviews between the customer and the service provider. Reporting is the most important way this can be accomplished and is a key component of Service Level Management. Once established, Service Level Agreements help with the following: Allows for the IT organization to better understand customer service requirements Controls customer expectations for levels of service to be delivered Allows for a clear understanding of priorities when handling service problems1.6 Why bother with Service Level Management There are six compelling reasons to establish a Service Level Management discipline in your company or with your service provider: Satisfying clients The IT Service provider must understand what the customer perceives as good service. The customer must understand what is reasonable to expect from the IT Service provider given limitations in hardware, network performance, staff, and so on. Communication between an IT service provider and a customer is an essential part of Service Level Management. There must be an agreement of what constitutes acceptable service against which service levels can be measured. When IT service providers meet expectations, customers can clearly see their expectations are being met and confidence increases.14 Introducing IBM Tivoli Service Level Advisor
  • 38. Managing expectationsOften, customers who were satisfied with service yesterday want betterservice today, and even better tomorrow. Some savvy ones may just want tomaintain service levels knowing that more users are receiving IT Services. Tomanage such a situation, an IT service provider and customer must negotiatea SLA. Both parties may later renegotiate the agreement as needed.Regulating resourcesWhen both the IT service provider and customer monitor service levelsclosely, they can become aware of developing problems in overcapacity orlack of resources and can be proactive by taking corrective actions.Marketing internal IT ServicesIn the old days, the only contact between the IT service provider andcustomers happened when something went wrong. This situation was alwaysseen as a roadblock to achieving business goals. With a Service LevelManagement process in place, an IT service provider can document the factthat it is providing good services supporting the business.Controlling costsWith a Service Level Management process in place, IT service providers canclarify which areas if of its services need improvement and requiresinvestment, and which areas still perform at satisfactory levels. This helps withthe decision-making process and justification as to whether investments arenecessary to upgrade service levels.Establishing a defensive strategyIT service providers can demonstrate in measurable terms that they are worththe customers investments. With precise SLA and effective reporting,customers’ perceptions of a good service can be eased and most likelycustomers will be less likely to purchase IT Services from a different ITservice provider. In the case of an internal IT organization, it can dispersearguments for outsourcing. Chapter 1. Introduction 15
  • 39. 16 Introducing IBM Tivoli Service Level Advisor
  • 40. 2 Chapter 2. IBM Tivoli Service Level Advisor general overview IBM Tivoli Service Level Advisor (ITSLA) Version 1.1 is a Service Level Management solution for providers of IT Services. It simplifies and automates the process of managing service level agreements, enabling IT organizations to proactively manage and report on service levels from across the management infrastructure. Our approach to introducing IBM Tivoli Service Level Advisor Version 1.1 in this chapter is to: Give an overview of ITSLA. Explain the ITSLA product core components as well as all the additional components that are required by ITSLA Explain the main concepts, terms, and definitions used by the product. Give a brief introduction to the Tivoli Enterprise Data Warehouse (TEDW) and explain how it is leveraged by ITSLA. Explore the functionality of ITSLA. Explain which Tivoli applications are providing data to be used by ITSLA, as well as how third-party applications can participate in the Service Level Management. Detail the end-to-end SLA Management process of ITSLA.© Copyright IBM Corp. 2002 17
  • 41. 2.1 Overview of IBM Tivoli Service Level Advisor Service Level Management is one of the many processes involved in the delivery of IT Services. It is intended to improve client satisfaction by facilitating the management of client expectations and ensuring IT service delivery. IBM Tivoli Service Level Advisor Version 1.1 is a Service Level Management solution that enables providers of IT Services in an enterprise to manage service level agreements. The following are the main characteristics of IBM Tivoli Service Level Advisor: Simplifies and automates the Service Level Management by providing a way to define and record service level agreements based on the definitions of service level objectives. Facilitates the development of a customer-service oriented culture within the IT service organization. Provides a line of business for an enterprise with service delivery information based on the Service Level Management definition. Analyzes trends and tendencies so that potential problems can be identified and corrected before they occur. Makes use of existing Tivoli applications deployed and can be extended to use non-Tivoli applications to provide an end-to-end enterprise picture of service level agreement compliance. Sends alerts for violations or trends toward violations so that notification of problems or potential problems can be integrated into an automated help desk or Change Management process. Helps you to understand the business characteristics and needs of the clients and the service components required to fulfill those needs. Automatically prepares a variety of Web-based reports on violations and trends, with drill-down capability, which saves on manpower required to gather and report statistics. ITSLA also allows you to make use of third-party reporting tools, providing extra flexibility on Service Level Management reporting. Aids in maintaining a baseline for IT Service capabilities. Automates service level agreement validation and receives alerts for service level agreement violations. IBM Tivoli Service Level Advisor allows you to leverage your existing investment in performance and availability monitoring applications and reduce your cost of Service Level Management while you align your IT management with business needs. Currently, it is common for enterprises to have various distributed18 Introducing IBM Tivoli Service Level Advisor
  • 42. performance and availability monitoring applications deployed that collect measurement data and provide some type of threshold management, central event management with correlation and escalation, and other basic monitoring functions. IBM Tivoli Service Level Advisor uses the data provided by those applications and enables you to: Define offerings that can be offered with differentiated service levels based on a set of service level objectives. Create customer profiles and associate them with specific service level agreements. Set up a schedule for the collection, evaluation, and analysis of the data at customized intervals. Analyze the data to detect violations of service level agreements or trends toward future violations. Send notifications when violations or trends are detected, enabling support personnel to take preventive action and maintain agreed-upon levels of performance and availability across your enterprise. Provide regular Web-based reports of evaluation results that might indicate a need for corrective action or to verify that levels of service are being maintained.2.2 IBM Tivoli Service Level Advisor components IBM Tivoli Service Level Advisor can be categorized in three core functional units: ITSLA Task Drivers ITSLA Server ITSLA Reports Server There are also several other logical components that are used to complete the IBM Tivoli Service Level Advisor solution. They are: ITSLA Database Server; hosting both the ITSLA Database and the ITSLA Measurement Data Mart databases Tivoli Enterprise Data Warehouse (TEDW) Server Tivoli Enterprise Data Warehouse Control Center, also known as Data Warehouse Center or Control Server IBM Console Server ITSLA Extract, Transform, and Load data (ETL) programs Source Application ETL programs Chapter 2. IBM Tivoli Service Level Advisor general overview 19
  • 43. Figure 2-1 shows the relationship between the core and the logical components of IBM Tivoli Service Level Advisor. Source Application Databases ITSLA Server Source ETLs ITSLA ETL ITSLA ITSLA Database Reports Server TEDW ITSLA ETL TEDW TEDW Central ITSLA Control Center Server Warehouse Database ITSLA ITSLA Server Task Measurement Drivers Data Mart and IBM ConsoleFigure 2-1 ITSLA core and logical components relationship The following sections are dedicated to explaining each of the IBM Tivoli Service Level Advisor components. Certain terms and concepts used throughout the following sections will also de defined in the context of IBM Tivoli Service Level Advisor. Section 2.3, “Important ITSLA concepts and terminology” on page 26, as well as the official product documentation, can be used as an additional source of reference.2.2.1 ITSLA Task Drivers The ITSLA Task Drivers component of IBM Tivoli Service Level Advisor is used to perform the following administrative tasks: Define service level offerings as well as specify breach values for associated metrics. Define orders and manage those that are active. Define schedules states once a level of service is defined. Schedule states can be specified as peak, standard, prime, off-hours, and so on. Schedule evaluation and trend analysis of measurement data, as well as the frequency of their execution.20 Introducing IBM Tivoli Service Level Advisor
  • 44. The ITSLA Task Drivers component leverages the IBM Console for all its tasks and must be installed on the same machine where the IBM Console Server components are installed. There are two versions of the IBM Console: The Java Console and the Web Console. The Web-based version of the IBM Console is used primarily for all administrative tasks, except for the viewing of message logs and tracing enablement. For these tasks, the ITSLA Task Drivers utilize the IBM Java-based Console. For additional information on viewing message logs and enabling the tracing function using the Java-based console, refer to Chapter 5, “Administering IBM Tivoli Service Level Advisor” on page 133. For additional information on the IBM Console Server see 2.2.7, “IBM Console Server” on page 25.2.2.2 ITSLA Server The ITSLA Server component provides the core functions required for Service Level Management practices. These functions include processing the service level agreement orders, evaluation and trend analysis, and storing the analysis results. The ITSLA Server can also be used to send notifications of service level agreement violations or trends toward a service level agreement violation. Measurement data that is stored in the ITSLA Measurement Data Mart database is accessed by the ITSLA Server in order to perform trend analysis, with the results being stored in the ITSLA Database. Section 2.6, “The SLA Management process of ITSLA” on page 40, provides details on how data is handled by the ITSLA Server.2.2.3 ITSLA Reports Server The ITSLA Reports Server component is composed of Java-based servlets running on the IBM WebSphere Application Server, which accesses data stored in the ITSLA Database to provide service level reports. Depending on the access rights of a user, a predetermined Web portal page will be assigned after a successful login, providing the user with access to SLA results and summary reports in the form of tables and graphs. Chapter 6, “Service level Reports with ITSLA” on page 217, provides a great deal of information regarding ITSLA reports. Chapter 2. IBM Tivoli Service Level Advisor general overview 21
  • 45. 2.2.4 ITSLA Database Server The ITSLA Database Server component consists of an IBM DB2 Universal Database Enterprise Edition Server hosting both the ITSLA Database and the ITSLA Measurement Data Mart databases. It is not a requirement to have both databases installed on the same machine or even located in the same DB2 instance. For more information when planning the ITSLA Database environment refer to 3.3, “Planning for IBM Tivoli Service Level Advisor” on page 61. ITSLA Database Data that is stored in the ITSLA Database can be organized into the following three categories: Information needed to create offerings and orders, such as resources, measurement types, component names, and attributes The actual offerings and orders that make up the defined service level agreements Evaluation and trend analysis data for report creation Figure 2-2 on page 23 depicts how each of the ITSLA components utilizes the ITSLA Database. Each component uses the ITSLA Database in the following way: ITSLA Task Drivers for creating and storing offerings and orders ITSLA Server for storing data evaluation and trend analysis results ITSLA Reports for viewing the results of data evaluation and trend analysis Data is inserted in the ITSLA Database via the Target ITSLA ETL Registration, which is run through the Tivoli Enterprise Data Warehouse Control Center. For more information regarding the Registration Target ETL, refer to 2.5, “IBM Tivoli Service Level Advisor Target ETLs” on page 37.22 Introducing IBM Tivoli Service Level Advisor
  • 46. ITSLA Server ITSLA Task Evaluation offering and Drivers data orders Trend analysis ITSLA Database ITSLA Database Server Registration Reporting ETL data ITSLA Reports TEDW Control Server CenterFigure 2-2 ITSLA Database component accessITSLA Measurement Data MartGenerally speaking, a data mart contains a subset of corporate data that is ofvalue to a specific business unit, department, or set of users. This subsetconsists of historical, summarized, and possibly detailed data captured fromtransaction processing systems or from a central enterprise database. In thecontext of IBM Tivoli Service Level Advisor, the ITSLA Measurement Data Mart isthe persistent data storage for the summarized performance and availabilitymonitoring application data that is obtained from the Tivoli Enterprise DataWarehouse database.Figure 2-3 on page 24 shows which IBM Tivoli Service Level Advisorcomponents use the ITSLA Measurement Data Mart database. Chapter 2. IBM Tivoli Service Level Advisor general overview 23
  • 47. ITSLA Database Server Process ETL ITSLA ITSLA TEDW Control Measurement Database Center Data Mart ITSLA Server Figure 2-3 ITSLA Measurement Data Mart access There are two types of data that are pulled from the Tivoli Enterprise Data Warehouse database and stored in the ITSLA Measurement Data Mart database: Measurement data that applies to the enabled data types specified in the ITSLA Database Resources that are of interest to currently active service level agreements Once this data has been inserted in the ITSLA Measurement Data Mart database, the ITSLA Server evaluates the data for violations or trends toward violations and stores the results in the ITSLA Database. Data is inserted in the ITSLA Measurement Data Mart database via the Target ITSLA ETL Process ETL, which is run through the Tivoli Enterprise Data Warehouse Control Center. For more information regarding the Process Target ETL, refer to 2.5, “IBM Tivoli Service Level Advisor Target ETLs” on page 37.24 Introducing IBM Tivoli Service Level Advisor
  • 48. 2.2.5 Tivoli Enterprise Data Warehouse Server 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 Enterprise Data Warehouse (TEDW) server is an IBM DB2 Universal Database Enterprise Edition server that contains the TEDW Central Data Warehouse databases. These databases are populated with operational data from Tivoli and/or other third-party applications for historical analyses and evaluated by IBM Tivoli Service Level Advisor.2.2.6 Tivoli Enterprise Data Warehouse Control Center The Tivoli Enterprise Data Warehouse Control Center is the IBM DB2 Universal Database Enterprise Edition server containing the TEDW control database (TWH_MD) that manages the Tivoli Enterprise Data Warehouse environment. From the Tivoli Enterprise Data Warehouse Control Center, you can also manage all databases located in your ITSLA environment.2.2.7 IBM Console Server The IBM Console is a distributed, device-independent, and platform-independent presentation layer for most of the Tivoli products, enabling the user to perform numerous ITSLA administrative tasks through an easy to use graphical user interface. As explained in 2.2.1, “ITSLA Task Drivers” on page 20, the IBM Console has two versions: The Java-based version and the Web-based version. The IBM Java Console can only be run from the machine where Tivoli Presentation Services is installed. The IBM Web Console can be accessed by any machine in the company intranet by connecting to the IBM Console Server machine using a supported Web browser. Each of the two IBM Console types is used for different tasks: The IBM Web Console for performing administrative tasks in the ITSLA environment, such as managing users and creating orders The IBM Java Console for message log viewing and enabling tracing2.2.8 ITSLA ETL programs ETL is an acronym for Extract, Transform, and Load. These are processes that extract data from a source database, transform the data to fit a generic schema, and load the data into a target database. Chapter 2. IBM Tivoli Service Level Advisor general overview 25
  • 49. There are two types of ETLs necessary to make data from source databases ITSLA-enabled: Source ETL Sometimes referred as Warehouse Enablement Packs, these are the ETL processes that extract the raw data from the source application databases and load it into the TEDW Central Data Warehouse database. There is a specific Source ETL for each IBM Tivoli Service Level Advisor enabled application. The list of the ITSLA-enabled Tivoli applications can be found in 2.7, “Applications providing measurement data” on page 46. The Tivoli Source ETLs are shipped on a separate CD with the IBM Tivoli Service Level Advisor installation media. Target ETL Also referred to as Data Mart ETL, these are programs that extract data from the TEDW Central Data Warehouse Database for further processing. In IBM Tivoli Service Level Advisor there are two Target ETLs, as follows: – Registration ETL The Registration ETL extracts information about the types of measurement data available and loads it into the ITSLA Database. – Process ETL The Process ETL extracts all performance and availability data from the TEDW Central Data Warehouse database and loads it into the ITSLA Measurement Data Mart database for evaluation. The ITSLA Target ETLs are shipped on a separate CD with the IBM Tivoli Service Level Advisor installation media.2.3 Important ITSLA concepts and terminology This section provides you with an important list of terms and definitions, in the IBM Tivoli Service Level Advisor context. This is a glossary that will be used throughout this redbook. Availability Measurement of how often a service is accessible to a defined customer set, measured as a percentage of up-time versus total time. Scheduled outages (no-service periods) are not counted against the availability measurement. (Note that a service may be unavailable even though the components used to provide the service are all available, and vice-versa.)26 Introducing IBM Tivoli Service Level Advisor
  • 50. Breach valueThis is the value at which a service level objective is considered as not beingmet. A service level agreement is violated if a breach value for one or more ofits service level objectives is exceeded.Business schedule or ScheduleA timeline of the operations of a business, with the timeline segmented intodifferent operational states. Valid states include peak, off-hours, andno-service (scheduled downtime for maintenance).ChangeAn action to modify the properties of a customer order.ComponentThe basic unit of service used to create a service offering. A component is anentity about which measurements are collected for reporting purposes. Forexample, a component can be a specific Web site or a particular applicationrunning on a Web application server.Component typeIn the IBM Tivoli Service Level Advisor environment, a grouping mechanismto group similar types of system resources (firewalls, servers, routers, etc.)that have common metrics. Each component type in the data model has a setof metrics and attributes that apply to all components of that type. The TivoliEnterprise Data Warehouse includes many types of monitoring data. In IBMTivoli Service Level Advisor, you can selectively filter for those componenttypes of interest. The component type specifies the kind of enterpriseresource that is evaluated by the service level objective.Configure service level objectiveThe process of customizing a customer order by selecting the resources toinclude in the service level agreement according to the type of measurementsspecified in the service level objective definition.CustomerA party that enters into a service level agreement with the provider of aparticular service. Customers are associated with available service levelagreement orders. Customers can be given access to the results of servicelevel agreement evaluation and trend analyses to validate their service levelagreements. Customers can be internal (members of a department within theenterprise) or external (a member, department, or company) associated witha service provider. Chapter 2. IBM Tivoli Service Level Advisor general overview 27
  • 51. Customer order This is the action of setting up a service level agreement by associating customers with service offerings. Data collection The process of obtaining performance and availability metric data from source applications for storage and later evaluation. Dependency The relationship between service level agreements in which the validation of one service level agreement is dependent upon the validation of another service level agreement. Typically used when one or more service level agreements internal to a service provider organization are monitored for the purpose of guaranteeing an external customers service level agreement. End time In IBM Tivoli Service Level Advisor, the end time of a defined period in the schedule that is associated with a particular state of peak, standard, or no-service hours. Evaluation The examination of performance and availability data from one or more monitoring applications to determine if a violation or a trend toward violation of a service level agreement has occurred. Frequency In IBM Tivoli Service Level Advisor this can have one of the following meanings: – In business schedules How often the associated period is active – In metric evaluation How often the evaluation is to be performed Measurement and Metric A standard of measurement or a measurable quantity, associated with guaranteed service levels to create service level objectives. Metrics evaluate performance, availability, or utilization of resources. For example, response time, CPU and disk utilization.28 Introducing IBM Tivoli Service Level Advisor
  • 52. Measurement sourceThe source application from where a measurement originates. Performanceand availability measurements are collected by the source application andwritten to a central data warehouse for later processing. A measurementsource can provide measurement for one or more components. The followingare examples of measurement sources:– IBM Tivoli Monitoring for Transaction Performance (TAPM)– IBM Tivoli Monitoring for Transaction Performance (TWSM)– IBM Tivoli Business Systems Manager– IBM Tivoli Enterprise Console– IBM Tivoli MonitoringFor additional information on how the above applications are providing SLAdata, refer to 2.7, “Applications providing measurement data” on page 46.No-serviceThe state of a period in a business schedule in which service levelagreements are not evaluated. This time is typically used for “down time" ormaintenance hours that do not count against the service level objectivesestablished in service level agreements.OfferingIn IBM Tivoli Service Level Advisor, this describes a service with guaranteedservice levels. Offerings are associated with business schedules and form thebuilding blocks for customer orders and service level agreements. Offeringscan be differentiated to provide service level choices to customers (like"Gold," "Silver," and "Bronze" levels of service). An offering must be in thepublished state to be included in a service level agreement order.Offering componentThis supplies the metrics for offerings and customer orders. At the time of anoffering creation, one or more offering components are selected. IBM TivoliService Level Advisor checks to determine the number of measurementsources for a component. Chapter 2. IBM Tivoli Service Level Advisor general overview 29
  • 53. Offering state In IBM Tivoli Service Level Advisor, the state of a service offering. Valid values include: – Draft The offering is being created. It is not yet published and available to be included in a customer order. – Published The offering has been defined and is made available for inclusion in customer orders. – Withdrawn A previously published offering that has been removed from the list of available offerings and can no longer be included in customer orders. Order In IBM Tivoli Service Level Advisor, the process by which an SLA is entered into the Tivoli Service Level Management solution. Includes customer information, a service offering, and the specific elements that make up the SLA. For example, customer Accounting signs up for the Gold offering for the www.000.com/accounting Web site. Order ID The assigned identification number that distinguishes one customer order from another. Peak The state of a period in a business schedule that defines hours in which levels of service are the most critical to the customer during peak business hours. Typically defines a more severe level of service than that specified for standard hours. Period A component of a business schedule that divides the timeline into named intervals, such as critical, peak, prime, standard, low impact, off-hours, and no-service. The general meaning of those intervals is defined by the customer during service level agreement negotiations. For example, you may define different service level objectives (thresholds) for each period, depending on how critical that particular period is for the business. Published offering This is an offering that is complete and is made available to customers to be included in a service level agreement.30 Introducing IBM Tivoli Service Level Advisor
  • 54. RealmIn IBM Tivoli Service Level Advisor, a grouping of customers that is used toorganize customer information and, in some cases, to control access to thatinformation. Customers might be grouped by region, by company, by adivision within a company, or by some other logical grouping. Customers canbe assigned to one or more realms.ReportsReports summarize the evaluated measurement data for a service levelagreement. IBM Tivoli Service Level Advisor provides three types of reports,as follows:– Results reports show monitoring information for the peak or standard states of a specified metric in an order.– Violations reports display the service level agreement violations during a specified period of time.– Trends reports display trends towards the violation of breach values, that is, tendencies to violate service level agreements.Refer to Chapter 6, “Service level Reports with ITSLA” on page 217 fordetailed information on IBM Tivoli Service Level Advisor reports.ResourceA hardware, software, or data entity that is managed by Tivoli managementsoftware. In IBM Tivoli Service Level Advisor, the entity is monitored byperformance and availability monitoring applications.RollbackRefers to the capability of IBM Tivoli Service Level Advisor to return to the lastvalid state if there is a failure during customer order deployment orcancellation, enabling failed orders to be restarted or deleted.ServiceAny task performed by one person or group for another person or group.Refer also to the definition provided in 1.2, “IT Services” on page 5.Service elementA component that provides a piece of an overall service. Service elementsare the building blocks used to construct service offerings and customerorders. Chapter 2. IBM Tivoli Service Level Advisor general overview 31
  • 55. Service level agreement (SLA) In IBM Tivoli Service Level Advisor, an agreement or contract between a service provider and a customer of that service, which sets expectations for the level of service with respect to availability, performance, and other measurable objectives. Service level objective (SLO) This is a specification of a metric that is associated with a guaranteed level of service that is defined in a service level agreement. The service level objective is part of an offering and is associated with a business schedule so that different breach values can be set for each schedule period. Choices include peak, critical, standard, prime, off-hours, and no-service. Service Level Management (SLM) The disciplined, proactive methodology and procedures used to ensure that adequate levels of service are delivered to all IT users in accordance with business priorities and at acceptable cost. Effective Service Level Management requires the IT organization to thoroughly understand each service it provides, including the relative priority and business importance of each. Service Level Management is the continuous process of measuring, reporting, and improving the quality of service provided by the IT organization to the business. For additional information refer to 1.4, “Ensuring service quality” on page 9. Service offering In IBM Tivoli Service Level Advisor, a defined level of service that associates a business schedule, including specified peak, standard, and no-service periods, with particular metrics to be evaluated. Service provider A person or organization that provides a service to a customer based on a service level agreement.32 Introducing IBM Tivoli Service Level Advisor
  • 56. SLA stateThe state of an active service level agreement. An SLA state can assume oneof the following values:– Violation One or more breach values have been exceeded, indicating that the agreed-upon level of service is not being met.– Steady All levels of service are currently being met and there is no detected trend toward a violation of the SLA.– Trend A trend toward a future violation of an SLA has been detected.– None The SLA has not yet been fully processed. This is an initial state.StandardThe state of a period in a business schedule that defines hours in which levelsof service are not as critical as they are during peak business hours.Start timeIn IBM Tivoli Service Level Advisor, start time may have one of the followingmeanings:– In defining business schedules, this is the start time of a defined period in the schedule that is associated with a particular state of peak, standard, or no-service hours.– In defining the schedule for metric evaluation, this is the time that the evaluation will be initiated.TrendTrend is a series of related measurements that indicates a defined direction ora predictable future result.Trend analysisThe examination of related measurements to determine whether a breachlevel for a level of service is being approached, so that corrective action canbe taken to prevent a violation of a service level agreement.ViewThe display of the details of a business schedule, period, offering, customer,or realm. Chapter 2. IBM Tivoli Service Level Advisor general overview 33
  • 57. Violation The state of a service level agreement when one or more service level objectives are not met. Service level agreement violations can be used to trigger a remediation policy for affected customers. Web report Service level agreement results made available through a series of Java servlets. Each report servlet can be integrated independently into the service providers existing Web content. Using Web server authentication, report data can be restricted by customer or realm. Displayed on a users Web browser showing the results of evaluation and trend analysis of service level agreement data to validate a service level agreement or to assist in identifying problem areas and taking corrective action. Withdrawn order An order that has been removed from the list of active orders that is being managed to guarantee levels of service. It is important to note that withdrawn orders are not deleted, but are no longer active. Withdrawn offering An offering that had been published, but which has since been withdrawn and is not available to customers for inclusion in a service level agreement.2.4 A glimpse into Tivoli Enterprise Data Warehouse As explained in 2.2.5, “Tivoli Enterprise Data Warehouse Server” on page 25, the Tivoli Enterprise Data Warehouse is an application used to collect and manage data from various Tivoli and non-Tivoli system management applications. The data is imported into the TEDW databases through ETLs from the source application databases, stored in the TEDW Central Warehouse Database, and further processed for historical analysis and evaluation. It is IBM Tivoli’s strategy to have most of its products providing ETLs so that the TEDW Central Data Warehouse database can be populated with meaningful systems management data. The IBM Tivoli Service Level Advisor Version 1.1 is the first product to fully leverage and utilize Tivoli Enterprise Data Warehouse.34 Introducing IBM Tivoli Service Level Advisor
  • 58. Customers can benefit from using Tivoli Enterprise Data Warehouse in variousways, such as: TEDW collects historical data from many applications into one central place. TEDW collects the underlying data about customers’ network devices/connections, desktops/servers, applications/software, and the problems and activities that have gone on to manage the infrastructure. This allows the customers to construct an end-to-end view of their enterprise and view the components independent of specific applications used to monitor and control resources. TEDW adds value to raw data. TEDW performs data aggregation (such as daily, weekly) and allows the user to restrict the amount of data stored in the central data repository. The data is also cleaned and consolidated in order to allow the data model of the central repository to share common dimensions. For example, TEDW ensures that time, host name, and IP address are the same dimensions across all the applications. TEDW allows the correlation of information from many Tivoli applications. TEDW can also be used to derive added value by correlating data from many Tivoli applications. It allows reports to be written, which correlate cross application data. TEDW uses open, proven interfaces for extracting, storing, and sharing the data. TEDW can extract data from any application (Tivoli and non-Tivoli) and store it in a common central database. TEDW also provides transparent access for third-party BI solutions (CWM standard), such as IBM DB2 OLAP, Crystal Decisions, Cognos, BusinessObjects, Brio Technology, 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). TEDW provides a Web-based reporting front end, called the Reporting Interface, but the open architecture provided by the TEDW 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. TEDW provides robust security mechanism. TEDW 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, TEDW can address most of the security requirements related to limiting access to specific data to those customers/business units with a need to know. Chapter 2. IBM Tivoli Service Level Advisor general overview 35
  • 59. TEDW provides a scalable architecture. Since TEDW depends on the proven and industry standard RDBMS technology, it provides a scalable architecture for storing and retrieving the data. Figure 2-4 depicts a typical Tivoli Enterprise Data Warehouse configuration with IBM Tivoli Service Level Advisor.Source Applications Business Intelligence and Reporting Tools ITM TEDW Environment IBM TEC BRIO Data Mart ETL Data Mart TAPM TEDW Central Data Mart Business ETL Data ETL Objects Warehouse Data Mart Data Mart ETL TWSM Crystal Reports TBSM Cognos TEDW TEDW Control Control (Metadata) Center Third Party OthersFigure 2-4 A typical TEDW environment The TEDW Control Center is the system that contains the TEDW Control database, which contains metadata for Tivoli Enterprise Data Warehouse and from which you manage all of your TEDW environment. The default internal name for the TEDW Control database is TWH_MD. The TEDW Control Center also manages the communication between the various components, such as the TEDW Central Data Warehouse, the data marts, and the Report Interfaces.36 Introducing IBM Tivoli Service Level Advisor
  • 60. The TEDW stores raw historical data from all Tivoli and third-party application databases in the TEDW Central Data Warehouse database. The internal name of the TEDW Central Data Warehouse database is TWH_CDW. Once the data has been inserted into the TWH_CDW database, it is available for either the TEDW ETLs to load to the TEDW Data Mart database (the internal name of the TEDW 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. In the context of IBM Tivoli Service Level Advisor, the ITSLA Target ETL programs move all applicable data from the TWH_CDW database to both the ITSLA Database and the ITSLA Measurement Data Mart databases. For the IBM Tivoli Service Level Advisor, the internal name of the ITSLA Measurement Data Mart database is DYK_DM and the ITSLA Database is DYK_CAT. The following section goes into more detail on the ITSLA Target ETL programs.2.5 IBM Tivoli Service Level Advisor Target ETLs As explained in 2.2.8, “ITSLA ETL programs” on page 25, the two Target ETLs that ITSLA uses are the Registration ETL and the Process ETL. These ETLs are processes scheduled and run from within the TEDW Control Center interface.2.5.1 ITSLA Registration ETL The Registration Target ETL is responsible for transferring measurement type data and component type information from the TEDW Central Data Warehouse database to the ITSLA Database (the internal default name of the ITSLA Database is DYK_CAT). The Registration Target ETL is run once after IBM Tivoli Service Level Advisor is installed and periodically thereafter when new measurement data types are added to the TEDW Central Data Warehouse database. The Registration Target ETL is made up of different SQL steps, as shown in Figure 2-5 on page 38. Chapter 2. IBM Tivoli Service Level Advisor general overview 37
  • 61. Figure 2-5 ITSLA Registration ETL process model The Registration Target ETL scheduling is configured through the TEDW Control Center interface. It is very important to schedule this ETL to run on a daily basis to ensure both that the ITSLA Database contains the most updated version of your measurement data and that all new measurement data types will be added to your environment. It is also worthwhile to mention that the Registration ETL is the very first ITSLA ETL program to run and should always run prior to the Process Target ETL interface. Chapter 5, “Administering IBM Tivoli Service Level Advisor” on page 133, provides more information on how, why, and when to run the Registration ETL.2.5.2 ITSLA Process ETL The primary purpose of the Process Target ETL is to transfer data from the TEDW Central Data Warehouse database to the ITSLA Measurement Data Mart database (the internal default name of the ITSLA Measurement Data Mart is DYK_DM). The Process Target ETL must run daily and can be scheduled to run38 Introducing IBM Tivoli Service Level Advisor
  • 62. with either the TEDW Control Center scheduler or by the Central Data Warehouse administrator tool. Chapter 5, “Administering IBM Tivoli Service Level Advisor” on page 133, provides more information on how, why, and when to run the Process ETL. The Process Target ETL is comprised of different SQL steps, as shown in Figure 2-6.Figure 2-6 ITSLA Process ETL process flow Being that the data inside the ITSLA Measurement Data Mart database is used for the service level agreement evaluation and trend analysis, there are two important considerations to make when running the Process Target ETL: The Process Target ETL should not run until after all Source Application ETLs have inserted their data inside the TEDW Central Data Warehouse database. The Process Target ETL must finish processing before the ITSLA Server starts the data evaluation process, otherwise the evaluation process might not give consistent results. Chapter 2. IBM Tivoli Service Level Advisor general overview 39
  • 63. 2.6 The SLA Management process of ITSLA IBM Tivoli Service Level Advisor, as a product, does not gather or store any performance, availability, or Service Level Management applicable data. It relies instead on other Tivoli and third-party performance and availability applications to collect and store this data in their own separate databases. For instance, Tivoli Web Services Manager might monitor transaction times for a specified Web site and store this data continuously in its database. IBM Tivoli Service Level Advisor would then use this database as a source for Service Level Management analysis. All data is then transferred and formatted by the source application Source ETLs into the TEDW Central Warehouse database repository. After this has completed, the two ITSLA Target ETLs are then run separately and consecutively to populate their respective databases with the applicable data. IBM Tivoli Service Level Advisor can then analyze and evaluate the data and generate reports of service level violations or trends toward potential service level violations. Figure 2-7 gives an overview of how ITSLA works. ITSLA EnvironmentSource Applications Environment ITSLA Source So Server Appl 1 urc eE TL 1 ETL Source tration Sourc eE Regis Appl 2 TL 2 ITSLA TEDW ITSLA Reports Central Database Server Warehouse Pro ce ss E T L N L ITSLA ET ce Database ITSLA ur So Server Task Source ITSLA Appl N Measurement Drivers Data Mart and IBM ConsoleFigure 2-7 How TSLA collects and stores measurement data After the ITSLA Server has completed its data evaluation and trend analysis, you may view the evaluation results provided by the ITSLA Reports Server through a supported Web browser. Now, let us take a close look at the overall Service Level Management process of ITSLA, as it is depicted in Figure 2-8 on page 41.40 Introducing IBM Tivoli Service Level Advisor
  • 64. 1 1 12 1 10 2 11 12 1 9 3 10 2 8 4 9 3 7 6 5 8 4 7 6 5 1 2 3 Agree SLAs 4 Populate Select ITSLA Define source Database Define Schedules & Customers & data Registration Create ETL Create 9 Offerings Orders 5 Access Reports via Web browser 11 12 1 10 2 9 3 8 4 7 5 6 12 11 1 10 2 9 3 7 SLA 8 5 4 or 7 6 ITSLA TEDW Central Database violation Data and trend Warehouse Evaluation Warehouse Warehouse Center Center Scheduler Administrator Populate ITSLA 8 ITSLA Measurement 6 Measurement Data Mart Event Data Mart Process ETL Escalation and NotificationFigure 2-8 End-to-Eend SLA Management process flow The steps are numbered in the diagram above and are explained further in the sections below. The SLA Management process can be explained in the following steps: Step 1: Define and agree on Service Level Agreements with your customers. Step 2: Select the applications that will provide source data. Step 3: Populate the ITSLA Database with measurement and resource type information. Step 4: Define schedules and create offerings. Step 5: Define customers and create orders. Step 6: Populate the ITSLA Measurement Data Mart database with data from the TEDW Central Warehouse database. Step 7: Evaluate the data for violations and trends. Chapter 2. IBM Tivoli Service Level Advisor general overview 41
  • 65. Step 8: Notification of SLA violations and trends toward potential violations. Step 9: Access the SLA reports through a supported Web browser.2.6.1 Step 1: Define and agree on Service Level Agreements Before service level agreements can be managed they must be agreed upon by you and your customers. This can be a written agreement or a verbal agreement and must include details like peak hours and off-peak hours and service levels applicable to each timeframe. Implement Review Manage Figure 2-9 A typical Service Level Management process flow The following are the basic steps for Service Level Management: 1. Implement the service level agreement. – Create a draft service level agreement – Negotiate the service level with the customer – Agree on the final service level that will be provided 2. Manage the service being delivered against the agreement. – Continually monitor and analyze achieved service levels – Report frequently on achieved service levels and service level violations 3. Review the service level agreement with your customer based on the results from step 2 and update where applicable.42 Introducing IBM Tivoli Service Level Advisor
  • 66. 4. Begin with step 1 again. Service Level Management is an ongoing process requiring continuous maintenance. Refer to 1.3, “Service Delivery” on page 7, for more information on service delivery management.2.6.2 Step 2: Select applications for source data After defining a service level agreement, you must decide which source applications will be used to provide measurement data and populate the TEDW Central Data Warehouse database. Select only the applications that can provide meaningful data for service level analysis. This will optimize your IBM Tivoli Service Level Advisor solution, as time will not be wasted on moving redundant data to the TEDW Central Data Warehouse database, or data that cannot be used for Service Level Management. As no data is initially enabled to be transferred from the TEDW Central Data Warehouse database to the ITSLA Databases, you will need to enable every application you plan to use with IBM Tivoli Service Level Advisor. Refer to 5.2, “Target ETLs management” on page 142 for more information on enabling source applications.2.6.3 Step 3: Populate the ITSLA Database The Registration Target ETL is used to populate the ITSLA Database with information about the types of measurement data available in the TEDW Central Data Warehouse database. This process collects data associated with the source applications that you enabled in step 2. The Registration Target ETL extracts the data from the TEDW Central Data Warehouse database, transforms and formats the data so that it is compatible with the ITSLA Database schema, and then loads the information into the ITSLA Database. The Registration Target ETL is run either manually by the TEDW Data Warehouse administrator, or scheduled to run within the TEDW Control Center.2.6.4 Step 4: Define schedules and create offerings Once the ITSLA Database has been populated with the types of measurement data available in the TEDW Central Data Warehouse database, you will need to create an offering. This is done by accessing the IBM Console and doing the following: 1. Create an offering by inserting the offering name, a description of the offering, and the SLA type related to the offering. Chapter 2. IBM Tivoli Service Level Advisor general overview 43
  • 67. 2. Select an existing schedule or create a new schedule that defines the business hours of operation, such as peak hours, standard hours, and others. 3. Add one or more offering components to the offering. The available list will depend on the measurement and resource type information available in the ITSLA Database. 4. Define the service level objectives for the various metrics associated with each offering component, specifying minimum, maximum, and average breach values for each metric. 5. Define evaluation and trend analysis schedules. 6. Publish the offering to make it available for use. Refer to 5.4.1, “Management of offerings” on page 167, for more information on creating offerings.2.6.5 Step 5: Define customers and create orders The next step is to define which customers will be associated with the offerings, thereby creating an order. The customers you define can be grouped into realms in the cases that you would like to separate their data and reports according to their locations, divisions, companies, and so on. Select an offering from the list of published offerings and select specific resources in the enterprise for which the customer wants service levels to be managed. The list of available resources can potentially be very large and can be filtered to enable you to quickly select the desired resource. After the order has been created, you can submit the order to IBM Tivoli Service Level Advisor, where it will be scheduled for evaluation based on the times provided for the selected resources. For more information regarding the order creation process, refer to 5.4.2, “Management of orders” on page 179.2.6.6 Step 6: Populate the ITSLA Measurement Data Mart database The next step consists of populating the ITSLA Measurement Data Mart database with data from the TEDW Central Data Warehouse database via the Process Target ETL. This process will transform the source application data into a format that is suitable for the ITSLA Measurement Data Mart database. Evaluations will then run directly against the data that is located in the ITSLA Measurement Data Mart database.44 Introducing IBM Tivoli Service Level Advisor
  • 68. The Process Target ETL is either run manually by the TEDW Data Warehouse administrator or scheduled to run within the TEDW Control Center component. For more information regarding the Process ETL and populating the ITSLA Measurement Data Mart database, refer to 5.2, “Target ETLs management” on page 142.2.6.7 Step 7: Evaluate data for violations and trends When an order is submitted to IBM Tivoli Service Level Advisor for evaluation, it includes the schedules that were defined in “Step 4: Define schedules and create offerings” on page 43. Data from the ITSLA Measurement Data Mart database will then be extracted by the ITSLA Server and evaluated, based on the selected resources and breach values defined in the order. IBM Tivoli Service Level Advisor will analyze the data for violations against the defined service levels and will search for trends toward potential violations, storing the results in the ITSLA Database. For more information regarding measurement data evaluation and analysis, refer to Chapter 5, “Administering IBM Tivoli Service Level Advisor” on page 133.2.6.8 Step 8: Notification of SLA violations and trends When IBM Tivoli Service Level Advisor is installed, you have the option of configuring event notification in case violations or trends toward future violations are received. These event notification methods include SNMP Traps, TEC Event forwarding, and e-mail. If any of these options were not chosen during installation, they can be configured from the IBM Tivoli Service Level Advisor command line interface. Depending on the method you select, notification will be sent to the desired personnel you choose during configuration, who can then take the necessary corrective action. Refer to 4.5.4, “ITSLA Server component installation” on page 113, for details on how to enable events notification.2.6.9 Step 9: Access SLA reports All service level agreement reports can be accessed through the ITSLA Reports Server using a Java-enabled Web browser. These reports can be graphical or in table format, and can be filtered to display only vital information with selected time intervals. The reports are based on WebSphere servlets and can be integrated into your current Web environment. Report users are defined in the IBM Console and access can be restricted to allow required views only. Chapter 2. IBM Tivoli Service Level Advisor general overview 45
  • 69. Chapter 6, “Service level Reports with ITSLA” on page 217, provides a great deal of information on IBM Tivoli Service Level Advisor reporting mechanisms and options.2.7 Applications providing measurement data You will find that the Service Level Management process is often more successful when a variety of data is collected from several source applications, often referred to as measurement source applications. The Tivoli Enterprise Data Warehouse effectively combines data from multiple source applications, such as IBM Tivoli Monitoring for Transaction Performance, with other Legacy or third-party applications an enterprise may have already deployed. The generic schema provided by Tivoli Enterprise Data Warehouse facilitates this combining and storing of data, allowing the data to be cross-referenced, and thereby providing a more comprehensive and informative look at your source application measurement data. IBM Tivoli Service Level Advisor takes advantage of service level measurements collected by measurement source applications. The following are examples of measurement sources provided by Tivoli: IBM Tivoli Monitoring for Transaction Performance (TAPM) IBM Tivoli Business Systems Manager IBM Tivoli Enterprise Console IBM Tivoli Monitoring IBM Tivoli Monitoring for Transaction Performance (TWSM) When an application provides data to participate in the Service Level Management process, it is referred to as an ITSLA-enabled application. Any application that already collects some sort of measurement data can also become a measurement source application, therefore ITSLA-enabled. The following section explains the methodology on how applications may become ITSLA-enabled.2.7.1 Becoming an ITSLA-enabled application This section provides a brief description on the steps one may perform in order to make an application ITSLA-enabled. There are three main steps required for this process: 1. Develop the application-specific Source ETL. 2. Configure the connection to the source database. 3. Enable the application in the ITSLA Server.46 Introducing IBM Tivoli Service Level Advisor
  • 70. Developing the application-specific Source ETLThis section gives a brief description of the major steps required for the SourceETL development. These steps are based on the IBM manuals Tivoli EnterpriseData Warehouse Enabling an Application Version 1.1, GC32-0745, andIntroduction to Tivoli Enterprise Data Warehouse, SG24-6607. Assume that anIBM Tivoli Service Level Advisor environment is already functional. While adetailed description of each of these steps is outlined in the mentionedreferences, below is a list of the steps:1. Initial data analysis. Applications may collect a wide variety of data types and store them in different formats, such as relational databases and log files. It must be determined what data types are needed to be stored in the Tivoli Enterprise Data Warehouse database, and thus into the ITSLA Database.2. Get acquainted with the Tivoli Enterprise Data Warehouse database generic schema. The Tivoli Enterprise Data Warehouse database consists of several tables that need to be updated by the ETL process. A very thorough understanding of the logical design of such tables allows a smooth ETL development. The following tables should be carefully researched. A table description along with the actual table name is provided: – Component (COMP) – Component attribute (COMPATTR) – Component relationship (COMPRELN) – Measurement (MSMT) – Extract control (EXTRACT_CONTROL) – Extract log (EXTRACT_LOG) – Prune measurement control (PRUNE_MSMT_CONTROL)3. Use the Tivoli Enterprise Data Warehouse application enablement template. This step establishes how application data should be mapped into the Tivoli Enterprise Data Warehouse database table, ensuring that applications follow the specifications when storing data in the Tivoli Enterprise Data Warehouse database.4. Follow the Tivoli Enterprise Data Warehouse naming conventions. In order to prevent object name conflicts, a requirement for naming conventions has been established. The initial step is to decide on an application-specific product code, known as measurement source code, which consists of three characters, including at least one number (for example, MM3). Once the product code is decided for the application, the naming convention provides guidelines for all the application-specific objects that need to be created. These guidelines are fully described in Tivoli Enterprise Data Warehouse Enabling an Application Version 1.1, GC32-0745. Chapter 2. IBM Tivoli Service Level Advisor general overview 47
  • 71. 5. Develop scripts to insert static data. These SQL scripts are used during the installation of the Source ETL and enable application-specific static data to be properly placed into the Tivoli Enterprise Data Warehouse database. 6. Review extract control design. The extract control method enables measurement data to be extracted from the application-specific data repository on an incremental basis. 7. Review timestamps. All time values inserted into the Tivoli Enterprise Data Warehouse must be in Universal Time Coordinated (UTC) format. Ensure that the application provides time information using UTC. 8. Review Tivoli Enterprise Data Warehouse common tasks. There are common tasks that applications must perform when inserting data into the Tivoli Enterprise Data Warehouse database. Tivoli Enterprise Data Warehouse Enabling an Application Version 1.1, GC32-0745, provides a complete description for all these tasks. 9. Develop the Source ETL code. These are SQL scripts that query the application-specific data repository and populate the Tivoli Enterprise Data Warehouse database according to the guidelines provided by the application enablement templates. A process in the Tivoli Enterprise Data Warehouse Control Center should also be defined. Configure the connection to the source database Consider that a database connection must be set between the TEDW Central Data Warehouse database and the source application database. In order to create such a connection, you must install on the TEDW Control Center machine the source application database client and configure it to communicate with the source application database server. An Open Database Connectivity (ODBC) connection must then be created and configured in order to be able to transfer the data from the source application database to the TEDW Central Data Warehouse. Enabling the application in the ITSLA Server Once the Source ETL has populated the Tivoli Enterprise Data Warehouse database with application-specific measurement data, IBM Tivoli Service Level Advisor should be notified of the existence of the new set of data, so that the Target ETLs can move the data into both the ITSLA Database and the ITSLA48 Introducing IBM Tivoli Service Level Advisor
  • 72. Measurement Data Mart databases. The information on which application mustbe included during data collection is determined based on theapplication-specific three digit product code. The complete description of thistask is found in 5.2, “Target ETLs management” on page 142. Chapter 2. IBM Tivoli Service Level Advisor general overview 49
  • 73. 50 Introducing IBM Tivoli Service Level Advisor
  • 74. 3 Chapter 3. Implementation planning IBM Tivoli Service Level Advisor is dependent on a number of supporting applications and components, making planning an essential task in order to ensure a successful deployment. Before installing IBM Tivoli Service Level Advisor into your enterprise environment, you should consider the hardware and software requirements, the physical locations of where you want to install the various functional pieces of IBM Tivoli Service Level Advisor, and their dependencies on the other applications that support the IBM Tivoli Service Level Advisor solution. IBM Tivoli Service Level Advisor and its supporting applications can be installed on a single machine in your enterprise, or across multiple machines with certain dependencies.© Copyright IBM Corp. 2002 51
  • 75. The main topics concerning planning discussed in this chapter are: Description of an ITSLA data flow scenario Planning for supporting applications Planning for IBM Tivoli Service Level Advisor Physical considerations Architecture considerations Source applications considerations Planning for event notification Planning worksheets52 Introducing IBM Tivoli Service Level Advisor
  • 76. 3.1 IBM Tivoli Service Level Advisor data flow In order to better understand how to plan an IBM Tivoli Service Level Advisor environment implementation, we will describe a typical ITSLA data flow scenario with all the components making up the IBM Tivoli Service Level Advisor solution. The scenario will help in understanding the main constraints to be considered during the project implementation phase. Possible areas of consideration are as follows: The single points of failure in the IBM Tivoli Service Level Advisor environment The network load and the configuration of communication among the IBM Tivoli Service Level Advisor solution components The hardware requirements The synchronization between the different activities in an IBM Tivoli Service Level Advisor environment, for example, the Source ETL and Target ETL data transfer, the IBM Tivoli Service Level Advisor evaluation of service level agreements, and the access to the IBM Tivoli Service Level Advisor reports provided by the ITSLA Reports Server component The scenario described is shown in Figure 3-1 on page 55. The legend used in that scenario is related to a specific activity and explained as follows: A1, A2, ..., An These letters represent the data transfer activity performed by the Source ETLs, moving data from the source application databases to the TEDW Central Warehouse database. This potentially large data transfer is initiated, executed, and managed by the TEDW Control Center component. If the TEDW Control Center is installed on a separate machine from the TEDW Central Warehouse database, the data passes from the source application databases through the TEDW Control Center machine to arrive at the TEDW Central Warehouse database, resulting in a dramatic increase in network traffic. The Source ETLs must not run concurrently, as the data transfer could fail. B This letter represents the data transfer executed by the Target Registration ETL, which moves the data from the TEDW Central Warehouse database to the ITSLA Database. The data flow is initiated, executed, and managed by the TEDW Control Center component. If the TEDW Control Center is installed on a separate machine from the TEDW Central Warehouse database, the data passes from the TEDW Central Warehouse database Chapter 3. Implementation planning 53
  • 77. through the TEDW Control Center machine to the ITSLA Database, resulting in an increase in network traffic. C This letter represents the data transfer executed by the Target Process ETL, which moves the data from the TEDW Central Warehouse database to the ITSLA Measurement Data Mart database. The ITSLA Server analyzes this data to find SLA violations and trends that might indicate a violation is imminent. The data flow is initiated, executed, and managed by the TEDW Control Center. If the TEDW Control Center is installed on a separate machine from the TEDW Central Warehouse database, the data passes from the TEDW Central Warehouse database through the TEDW Control Center machine to the ITSLA Measurement Data Mart database, resulting in an increase in network traffic. D, E These letters represent the ITSLA Web Console and Java Console data flow. All administrative tasks are performed through the ITSLA Web Console, while the trace and message logging configuration and viewing are ITSLA Java Console tasks. The ITSLA Task Drivers component is responsible for managing the ITSLA Console data movement. Keep in mind that the ITSLA Java Console can only be accessed on the machine where the ITSLA Task Drivers component is installed, while the ITSLA Web Console can be accessed by any machine with a supported Web browser. One area that must be taken into consideration is the network traffic generated between the ITSLA Task Drivers machine and the ITSLA Database Server machine. F The ITSLA Task Drivers component is responsible for inserting the defined offerings and orders into the ITSLA Database. G The ITSLA Server performs the service level agreements evaluation on the data stored into the ITSLA Measurement Data Mart database and stores the results in the ITSLA Database. The amount of data transferred is dependent on the amount of data analyzed during the evaluation process.54 Introducing IBM Tivoli Service Level Advisor
  • 78. H, I When the service level evaluation performed by the ITSLA Server has completed, users will be able to connect to the ITSLA Reports Server through a Web browser to view the evaluation results and do reporting. The ITSLA Reports Server accesses the SLA violations and trend analysis data stored in the ITSLA Database through an IBM DB2 database client and creates the customized reports for the end users. The number of users connected to the ITSLA Reports Server is a very important parameter to take into consideration during the planning phase. Source Target ETLs ETLs ITSLA Reports Console TEDW Control Center (Web Browser) (DB2 Server) Source Application 1 Database A1 B ITSLA H Database I TEDW Server TEDW Central Warehouse A2 (DB2 Server) Source Application 2 C Database ITSLA Measurement ITSLA Data Mart Reports ITSLA Server F Database Server (WebSphere) An (DB2 Server) ITSLA Task Drivers Source Application N (Tivoli Presentation Services) G Database E D ITSLA Server ITSLA Java Console ITSLA Web Console (Web Browser)Figure 3-1 ITSLA data flow scenario In the next sections the supporting applications required by the numerous IBM Tivoli Service Level Advisor components are described, along with their software and hardware requirements. Recommendations for the placement of each supporting application is also included. Chapter 3. Implementation planning 55
  • 79. 3.2 Planning for supporting applications This section gives a brief introduction into planning for supporting applications. For specific information, refer to the product support manuals and related publications for each application. As explained in 2.2, “IBM Tivoli Service Level Advisor components” on page 19, IBM Tivoli Service Level Advisor uses the following supporting applications, which must be correctly installed and configured before installation of IBM Tivoli Service Level Advisor can commence: IBM WebSphere Application Server IBM DB2 Universal Database Enterprise Edition Tivoli Enterprise Data Warehouse3.2.1 IBM WebSphere Application Server The IBM Tivoli Service Level Advisor Reports Server component runs in the same environment as the IBM WebSphere Application Server. The IBM WebSphere Application Server is used for the publishing of reports servlets, allowing them to be accessed through a supported Web browser. IBM Tivoli Service Level Advisor ships with the media and a single license for IBM WebSphere Application Server Advanced Edition Single-Server 4.0.1. Entitlement for this license is for the IBM Tivoli Service Level Advisor environment only. Hardware and software requirements The hardware and software requirements depend on the number of users accessing the ITSLA Reports Server component, as well as whether the ITSLA Reports Server component shares the same hardware with any other IBM Tivoli Service Level Advisor components (distributed installation). In any case, the hardware requirement is the same one indicated for the ITSLA Reports Server component. If you have already deployed a the IBM WebSphere Application Server production environment in your enterprise, for performance reasons, we recommended that you do not share it with the IBM Tivoli Service Level Advisor environment and use a brand new installation of IBM WebSphere Application Server. Generally you may use the IBM WebSphere Application Server Advanced Edition Single-Server 4.0.1 licence provided and install it on the same machine as the ITSLA Reports Server component.56 Introducing IBM Tivoli Service Level Advisor
  • 80. For more information concerning hardware and software requirements and on optimizing the IBM WebSphere Application Server, visit the WebSphere Infocenter at the following link: http://www-3.ibm.com/software/webservers/appserv/infocenter.html Network considerations The IBM WebSphere Application Server utilizes two specific TCP/IP ports when used with IBM Tivoli Service Level Advisor: 9090 Port used by IBM WebSphere Application Server for administration purposes 9080 Port used by IBM WebSphere Application Server for communication with the ITSLA Reports Server component Logical design considerations If you already have an IBM WebSphere Application Server infrastructure in place, IBM Tivoli Service Level Advisor may be integrated into this existing environment. The following are IBM WebSphere Application Server versions currently supported by IBM Tivoli Service Level Advisor: IBM WebSphere Application Server SE 3.5 IBM WebSphere Application Server Advanced Edition (AE), Version 4.0.1, 4.0.2 IBM WebSphere Application Server Advanced Edition Single-Server (AES), Versions 4.0.1, 4.0.23.2.2 IBM DB2 Universal Database Enterprise Edition The Tivoli Enterprise Data Warehouse and IBM Tivoli Service Level Advisor databases runs in an IBM DB2 Universal Database Enterprise Edition Version 7.2 (Fixpack 5 included) environment. IBM Tivoli Service Level Advisor ships with the media and a single license for IBM DB2 Universal Database Enterprise Edition Version 7.2. Entitlement for this license is for the IBM Tivoli Service Level Advisor environment only. Hardware and software requirements For hardware and software requirements for IBM DB2 Universal Database Enterprise Edition Version 7.2, visit the IBM DB2 Universal Database Enterprise Edition online support page at the following link: http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v7pubs.d2w/ en_main Chapter 3. Implementation planning 57
  • 81. Note: The IBM DB2 Universal Database Enterprise Edition Data Warehouse Center component can run only on either Windows NT or Windows 2000; therefore, the TEDW Control Center component, which depends on the IBM DB2 Universal Database Enterprise Edition Data Warehouse Center, will only run on those operating systems. Network considerations If you intend to run the IBM DB2 Universal Database Enterprise Edition instances and databases for the TEDW Central Warehouse on a Windows NT or Windows 2000 platform, you can eliminate network traffic between the TEDW Control Center and the TEDW Central Warehouse components by having them installed on the same machine. For a detailed list of the TCP/IP ports used by IBM DB2 Universal Database Enterprise Edition refer to Tivoli Enterprise Data Warehouse Installing and Configuring Version 1.1, GC32-0744. Logical design considerations If you already have an IBM DB2 Universal Database Enterprise Edition Version 7.2 environment in your enterprise, the TEDW Central Warehouse and IBM Tivoli Service Level Advisor databases can be installed in the current environment. You may also have the option to upgrade the current environment to Version 7.2 (Fixpack 5 included). All source applications providing data for IBM Tivoli Service Level Advisor ETLs (also known as Warehouse Enablement Packs or warehouse packs), as well as the ITSLA ETL programs (Process and Registration ETLs), must be installed on the same physical machine as the TEDW Control Center component. All the data being transferred from the source applications databases to the TEDW Central Warehouse database, as well as from the TEDW Central Warehouse database to the ITSLA Database and ITSLA Measurement Data Mart, passes though the TEDW Control Center machine. It is very important to understand this when planning for the database placement in your environment. For planning information on IBM DB2 Universal Database Enterprise Edition, refer to DB2 UDB Administration Guide: Planning Version 7, SC09-2946.58 Introducing IBM Tivoli Service Level Advisor
  • 82. 3.2.3 Tivoli Enterprise Data Warehouse When planning for your Tivoli Enterprise Data Warehouse installation, be sure to take into account not only the space required for the Tivoli Enterprise Data Warehouse application files, but also the following: The accumulation of large amounts of historical data generated by the source applications in the TEDW Central Warehouse database. As this data will grow over time, allocate space generously, keeping in mind that the data warehouse contains a purge utility to help you manage your warehouse content and space. Space for TEDW Data Marts and Reports, both prepackaged with warehouse packs and those created or customized by your company. Space for report output, which is stored in the control database (TWH_MD database) on the TEDW Control Center component. Space for each warehouse pack, making sure to account for both the installed files and the additional historical data that might be collected by the warehouse pack. Consider that the TEDW Data Mart database (TWH_MART database) is not used by the IBM Tivoli Service Level Advisor solution, as IBM Tivoli Service Level Advisor has its own data mart database, the ITSLA Measurement Data Mart database. The TEDW Data Mart database, however, may be used for other applications. Refer to the Introduction to Tivoli Enterprise Data Warehouse, SG24-6607, for placement and sizing considerations for the TEDW Data Mart database. Hardware and software requirements Refer to Tivoli Enterprise Data Warehouse Release Notes Version 1.1, GI11-0857, for information about hardware prerequisites, specific database and operating system support, and product prerequisites. Network considerations You must allocate TCP/IP port numbers for Tivoli Enterprise Data Warehouse for the following purposes: Communication between the TEDW Control Center and the remote TEDW Central Warehouse database Communication between the TEDW Control Center and the remote ITSLA Database Server machine Communications for the IBM Console Secure Sockets Layer (SSL) encryption connections to the IBM Console (optional) Chapter 3. Implementation planning 59
  • 83. Note: You must pay attention when specifying TCP/IP port numbers during the Tivoli Enterprise Data Warehouse installation, as specifying port numbers that are already in use by other programs causes the installation to lock up. Table 3-1 lists the default port numbers used by the Tivoli Enterprise Data Warehouse, the names of the ports during the install process, descriptions of what the ports are used for, and whether the default values can be changed:Table 3-1 Default TCP/IP port numbers used by the TEDW Default Name of port in Description Can the default be changed? port InstallShield Wizard number 50000 Database port for In a distributed installation, used Yes, during IBM DB2 Universal TEDW Control Center by the TEDW Data Mart server, Database Enterprise Edition TEDW Central Data Warehouse Server installation. Database port for server, and TEDW report server TEDW Central Data to communicate with the TEDW Refer to the IBM DB2 Universal Warehouse Control Center server Database Enterprise Edition installation documentation for Database port for the more information. TEDW Data Mart 80 IBM HTTP Server IBM HTTP Server port used by Yes, during installation of the port Tivoli Presentation Services TEDW Reports Interface. HTTP Server for HTTP communications 8008 IBM HTTP Used by Tivoli Presentation Yes, during installation of the Administration port Services HTTP Administration TEDW Reports Interface. 8010 Server For IBM Used by Server for IBM Console Yes, during installation of the Console IPC port (part of Tivoli Presentation TEDW Reports Interface. Services) 8007 Web Console port Used by Web Services for the Yes, during installation of the IBM Console (part of Tivoli TEDW Reports Interface. Presentation Services) 8040 Web Console IPC Used by Web Services for the Yes, during installation of the port IBM Console (part of Tivoli TEDW Reports Interface. Presentation Services) 8030 IBM Console IPC port Used by the IBM Console (part of Yes, during installation of the Tivoli Presentation Services) TEDW Reports Interface.60 Introducing IBM Tivoli Service Level Advisor
  • 84. Default Name of port in Description Can the default be changed?port InstallShield Wizardnumber8050 Not applicable Used by Server for IBM Console No. (part of Tivoli Presentation Services)443 Not applicable Used by Tivoli Presentation Yes, using Tivoli Presentation Services HTTP Server for secure Services HTTP Administration. HTTP communications (HTTPS) Logical design considerations You can deploy Tivoli Enterprise Data Warehouse one of two ways: As a single system installation, with all the components installed on a single system. This cannot be done on a UNIX platform, as the TEDW Control Center component can only run on the Windows platform. This is convenient for demonstrations, as an educational or test platform, and for companies that do not plan to have many users concurrently analyzing data and that do not need to capture and analyze large amounts of data in the warehouse. As a distributed installation, with the components installed on multiple systems and platforms in your enterprise, including UNIX servers. Multiple components can be installed on one system, provided that the operating system supports those components. An important consideration is for users to be able to access your warehouse data in more than one way, as follows: Using a Web browser and the IBM Console graphical user interface, users can create, customize, and run reports that access data marts through the report interface. Using other reporting, OLAP, and analytical tools, users can access data in the data marts using an interface that is already in use in your business. Refer to Introduction to Tivoli Enterprise Data Warehouse, SG24-6607, for more information on Tivoli Enterprise Data Warehouse components placement, as well as Web browser and security considerations.3.3 Planning for IBM Tivoli Service Level Advisor In this section we will discuss the physical and the architectural considerations for IBM Tivoli Service Level Advisor planning. Chapter 3. Implementation planning 61
  • 85. As described in 2.2, “IBM Tivoli Service Level Advisor components” on page 19, IBM Tivoli Service Level Advisor has three core components to install and configure: ITSLA Server ITSLA Reports Server ITSLA Task Drivers Any of these three components can be installed separately, or in any possible combination with another to form a distributed installation. The components communicate with each other using the TCP/IP ports described in Table 3-2. Table 3-2 Ports used by the ITSLA components Port number Purpose Description 9990 Command line The Command Line Interface (CLI) interface port service port used to communicate with the ITSLA Server, the ITSLA Reports Server, and the ITSLA Task Drivers. The CLI Service is installed with the ITSLA Server component. 9980 ITSLA Server Used for communication between the Communication port ITSLA Server and the ITSLA Task Drivers.3.3.1 Physical considerations The following section describes the hardware, software, and Web browser requirements for IBM Tivoli Service Level Advisor. As this is for reference only, consult IBM Tivoli Service Level Advisor Release Notes Version 1.1, GI11-0908, for detailed information. Hardware requirements Each component of the IBM Tivoli Service Level Advisor has the minimum hardware requirements described in Table 3-3. Table 3-3 Hardware requirements for ITSLA Hardware and operating CPU Memory HDD system IBM eServer pSeries 375 MHz or 1 GB or 1 GB or (RS/6000) - AIX higher higher higher IBM eServer xSeries (Netfinity) 650 MHz or 1 GB or higher 1 GB or higher and other Intel Pentium brands - higher Microsoft Windows or Linux62 Introducing IBM Tivoli Service Level Advisor
  • 86. Hardware and operating CPU Memory HDD system Sun SPARC - Solaris 400 MHz or 1 GB or higher 1 GB or higher higher Note: Large configurations significantly increase the amount of memory required for the Reports Server and Web-based console. For example: 512 MB may only support 10 - 15 concurrent users 1 GB may only support 25 - 30 concurrent usersIf all components in your environment will be installed on a single machine, werecommend the information shown in Table 3-4.Table 3-4 Single machine installation hardware requirements for ITSLA Hardware and operating CPU Memory HDD system IBM eServer xSeries (Netfinity) Dual 2 GB or higher 2 GB or higher and other Intel Pentium brands - Processor 1 Microsoft Windows GHz or higherSoftware requirementsTable 3-5 describes the software requirements of IBM Tivoli Service LevelAdvisor in terms of supported operating systems, relational databases, and Javaruntime environment.Table 3-5 Software requirements for ITSLA Platform Operating system Java Runtime Database Environment ITSLA Server Windows NT 4.0 SP 6+ 1.3.0 SR10 7.2 Client Windows 2000 Advanced with Server Edition SP2+ Fixpack 5 Windows 2000 Server SP2+ Linux RedHat 7.1 Linux SuSE 7.1 AIX 4.33, 5.1 Solaris 2.7, 2.8 1.3.1_01 Chapter 3. Implementation planning 63
  • 87. Platform Operating system Java Runtime Database Environment ITSLA Reports Windows NT 4.0 SP 6+ 1.3.0 SR10 7.2 Client Server Windows 2000 Advanced with Server Edition SP2+ Fixpack 5 Windows 2000 Server SP2+ Linux RedHat 7.1 Linux SuSE 7.1 AIX 4.33, 5.1 Solaris 2.7, 2.8 1.3.1_01 ITSLA Task Drivers Windows NT 4.0 SP 6+ 1.3.0 SR10 7.2 Client Windows 2000 Advanced with Server Edition SP2+ Fixpack 5 Windows 2000 Server SP2+ Linux RedHat 7.1 Linux SuSE 7.1 AIX 4.33, 5.1 Solaris 2.7, 2.8 1.3.1_01 ITSLA Database Windows NT 4.0 SP 6+ 1.3.0 SR10 7.2 Server Server Windows 2000 Advanced with Server Edition SP2+ Fixpack 5 Windows 2000 Server SP2+ AIX 4.33, 5.1 Solaris 2.7, 2.8 1.3.1_01 Web browser support IBM Tivoli Service Level Advisor supports the Web browsers for the listed operating systems and language locales shown in Table 3-6. Table 3-6 ITSLA Web browser support Operating system Locale Internet Netscape Explorer Windows NT 4.0 SP6+ jp, zh_CN, zh_TW 5.x, 6.0 4.78 Windows 2000 Advanced Server SP2+ ko 5.x, 6.0 None Others 5.x, 6.0 4.6x, 4.7x64 Introducing IBM Tivoli Service Level Advisor
  • 88. Operating system Locale Internet Netscape Explorer AIX 4.33, 5.1 All None 4.6x, 4.7x Solaris 2.7, 2.8 Linux RedHat 7.1 Linux SuSE 7.13.3.2 Architecture considerations IBM Tivoli Service Level Advisor and its components are normally deployed inside the back office of the enterprise, protected behind firewalls. This eliminates the need for an additional security infrastructure to be deployed. The IBM Tivoli Service Level Advisor source applications and their databases may reside elsewhere in the enterprise or in the same protected infrastructure. Figure 3-2 gives a graphical overview of a possible IBM Tivoli Service Level Advisor deployment. Source Application Databases ITSLA Server Source ETLs ITSLA ITSLA ETL Web Server Task Drivers ITSLA IBM Database Console ITSLA TEDW TEDW Reports TEDW Central ITSLA ETL Server Server ITSLAControl Center Warehouse Database ITSLA Server Source ETLs Measurement Data Mart Web Server Source Application Databases Web browser clients Web browser clients ITSLA Administrators Firewall 2 Firewall 1 Back office DMZ Internet More Secure Less SecureFigure 3-2 ITSLA architecture component placement Chapter 3. Implementation planning 65
  • 89. As a speculation in the above scenarios, if the ITSLA Reports component whereas installed on one of the Web Servers in the DMZ, and not on a server in the back office, ports 9090 and 9080 would need to be opened on Firewall 2, as shown in Figure 3-2 on page 65, to allow communication between the Web browsers in the back office area and the ITSLA Reports Server. In addition to that, in order to allow communication between the ITSLA Reports Server and the ITSLA Database Server, the ports used for database communication will need to be opened in the same firewall (the DB2 UDB default ports used for server-client communication are 50000 and 50001). Also, in order to allow CLI communication between the ITSLA Server, ITSLA Task Drivers, and the ITSLA Reports Server, you will need to open the ITSLA CLI port chosen during the installation process in the firewall (the default ITSLA CLI port is 9990). Architectural considerations for the ITSLA Server The ITSLA Server is the management server for IBM Tivoli Service Level Advisor and can be installed on a machine in the back office intranet, which satisfies the hardware and software requirements. During the time period when service level agreement evaluations are being performed by the ITSLA Server, you must consider the potentially heavy network traffic between the ITSLA Server and the ITSLA Measurement Data Mart database. All service level agreements evaluations are scheduled based on the time zone of the ITSLA Server, which must be taken into consideration for a distributed installation across time zones. Section 5.5.2, “ITSLA evaluation schedule and time zone considerations” on page 195, provides additional information on scheduling service level agreement evaluations and time zone considerations. If the ITSLA Server is installed on a different physical machine from the ITSLA Database and ITSLA Measurement Data Mart database, then you must install and configure IBM DB2 Universal Database Enterprise Edition Client on the machine with the ITSLA Server, as this component is responsible for performing SLA evaluation on the data stored in the ITSLA Measurement Data Mart database and inserting the results into the ITSLA Database. Section 4.5, “Setting up the ITSLA Server machine” on page 106, provides additional information on how to catalog the ITSLA Databases. Architectural considerations for the ITSLA Reports Server By providing Java-based report servlets, the ITSLA Reports Server enables a customer to access IBM Tivoli Service Level Advisor service level reports via a supported Web browser.66 Introducing IBM Tivoli Service Level Advisor
  • 90. The ITSLA Reports Server component runs in the same environment as the IBMWebSphere Application Server and must be installed on the same physicalmachine. If your current infrastructure utilizes IBM WebSphere ApplicationServer SE Version 3.5 or IBM WebSphere Application Server AE (any version),then the reports servlets will have to be manually integrated into the IBMWebSphere Application Server environment. It is recommended that you useIBM WebSphere Application Server AES 4.0.1 or later.The ITSLA Reports Server component runs on top of the IBM HTTP Server,which is installed along with the ITSLA Reports Server component. If you alreadyhave other Web Server software like Microsoft IIS or IBM Apache server up andrunning on the same physical machine, you will need to change the defaultinstallation port numbers for the ITSLA Reports IBM HTTP Server. Note: if there is already a Web server such as Microsoft IIS on the system where you plan to install the ITSLA Report Server, you must uninstall or disable that Web server, or specify different port numbers for the HTTP Server port and HTTP Administration port for Tivoli Presentation Services during the Reports Interface installationDuring the installation of the ITSLA Reports Server you will be asked for the nodename of where the IBM WebSphere Application Server is running. This name isassigned during IBM WebSphere Application Server installation and might be theshort name or the fully qualified name of the machine.If the ITSLA Reports Server component is installed on a different physicalmachine from the ITSLA Database and ITSLA Measurement Data Martdatabases, then you must install and configure IBM DB2 Universal DatabaseEnterprise Edition client on the ITSLA Reports Server machine. Section 4.5,“Setting up the ITSLA Server machine” on page 106, provides additionalinformation on how to catalog the ITSLA Databases.Architectural considerations for the ITSLA Task DriversThe ITSLA Task Drivers are one of the components of the ITSLA installation andintegrates into the IBM Console Server. These task drivers provide a Web-basedgraphical user interface from which administration tasks are performed throughthe IBM Web Console and the IBM Java Console.The ITSLA Task Drivers component is installed on the same physical machinerunning the three main pieces of Tivoli Presentation Services and are installedduring TEDW Report Interface component installation: Server for IBM Console Web Services for IBM Console and IBM Console Chapter 3. Implementation planning 67
  • 91. Note: The Server for IBM Console, the Web Services for IBM Console, and the IBM Console are all referred to as the IBM Console Server. If the ITSLA Task Drivers and the IBM Console Server are installed on a different physical machine from the ITSLA Database and ITSLA Measurement Data Mart database, then you must install and configure IBM DB2 Universal Database Enterprise Edition client on the machine with the ITSLA Task Drivers. Section 4.5, “Setting up the ITSLA Server machine” on page 106, provides additional information on how to catalog the ITSLA Databases. Architectural considerations for the Target ETL IBM Tivoli Service Level Advisor ships with two ETL programs constituted of two different steps: The Target Registration ETL and the Target Process ETL. The ITSLA Target ETLs must be installed on the same physical machine as the TEDW Control Center. The ITSLA Database and Measurement Data Mart databases (whose default names are DYK_CAT and DYK_DM, respectively) should be installed and created, and the TEDW Control Center configured before the Target ETLs are installed. As described in Section 3.1, “IBM Tivoli Service Level Advisor data flow” on page 53, the Target ETLs are responsible for the data flow between the TEDW Central Warehouse database and the ITSLA Databases. If the TEDW Control Center, TEDW databases, and ITSLA Databases are all installed on separate machines, consider the impact on network performance the Target ETLs data movement could have. Architectural considerations for the ITSLA Databases The ITSLA Databases can be created on the same physical machine or on separate machines. They can be created on the same physical machine as the Data Warehouse or even in the same IBM DB2 Universal Database Enterprise Edition instance, depending on scalability, performance, and availability considerations. It is recommended, though not necessary, that separate instances are created for the TEDW Central Warehouse, ITSLA Database, and ITSLA Measurement Data Mart databases for the following reasons: Installation of the ITSLA Database and ITSLA Measurement Data Mart databases requires the stopping, starting, and termination of the instance, which will interrupt any other applications connected to that instance. The ITSLA solution performs better when separate instances are used.68 Introducing IBM Tivoli Service Level Advisor
  • 92. The databases are better protected from data loss. Maintenance and backup purposes. Tip: For each IBM Tivoli Service Level Advisor database you create, approximately 30 to 50 MB of space is initially required to hold the database tables. Approximately the same amount of memory is also required.3.3.3 Planning considerations for source applications IBM Tivoli Service Level Advisor currently supports the Tivoli products (listed in Table 3-7) as default source applications able to insert data in the Tivoli Enterprise Data Warehouse databases. Table 3-7 Supported source Tivoli applications Product Version Patches required IBM Tivoli Monitoring 3.7 3.7-DMN-0018 IBM Tivoli Monitoring for Transaction 1.7 1.7-WSM-0003 Performance (TWSM) IBM Tivoli Monitoring for Transaction 2.1 N/A Performance (TAPM) IBM Tivoli Enterprise Console 3.7.1 N/A IBM Tivoli Business Systems Manager 1.5 1.5-BSM-0034 The Source ETLs for the above applications are shipped with the source application installation media, while the ITSL Target ETLs can be found on the IBM Tivoli Service Level Advisor installation media. As described in 4.4, “Setting up the TEDW Control Center machine” on page 90, all ETL programs are installed from their respective installation media through the TEDW installation process. If you already have source application databases defined in your environment, you will need to configure an ODBC connection on the machine where the TEDW Control Center component is installed in order to allow communication between the source application’s ETL and the TEDW Central Warehouse database. In order to ensure connectivity, a database client must be installed on the TEDW Control Center machine for all source databases. For example, if the IBM Tivoli Monitoring (Distributed Monitoring TDS) source database uses an Oracle Chapter 3. Implementation planning 69
  • 93. database, and the IBM Tivoli Enterprise Console source database uses an Informix database, then both the Oracle client and the Informix client must be installed and configured on the TEDW Control Center machine, as well as the ODBC connections to those databases. For more information on changing your ODBC connection information, refer to 4.4.6, “Configuring the ODBC connections” on page 103. Consider that the data transfer from the source application databases to the TEDW Central Data Warehouse is the heaviest in the IBM Tivoli Service Level Advisor environment, and the time it takes strongly depends on the amount of data to transfer, and from the network speed. The source application ETLs perform this data transfer and it is advisable to not run them concurrently, otherwise the data movement process could fail. IBM Tivoli Monitoring In order for IBM Tivoli Service Level Advisor to use IBM Tivoli Monitoring (ITM) data, the Tivoli Decision Support (TDS) product with the Server Performance Prediction guide has to be installed and configured in your enterprise. For more information on installing and configuring TDS, refer to the Tivoli Decision Support Installation Guide, GC32-0438, and Tivoli Decision Support for Server Performance Prediction TDS_Guide_for_SPP_21 , which is provided with the IBM Tivoli Monitoring Source ETL installation media. Some considerations on the IBM Tivoli Monitoring Source ETL follow: The source database for the IBM Tivoli Monitoring Source ETL is the Tivoli Decision Support database for which the RIM object SPR_RIM is configured. Patch 3.7-DMN-0018 is required for the IBM Tivoli Monitoring application and must be installed prior to running the IBM Tivoli Monitoring Source ETL. For more information, refer to Tivoli Distributed Monitoring Warehouse Enablement Pack: Implementation Guide, which is provided with the IBM Tivoli Monitoring Source ETL installation media. IBM Tivoli Monitoring for Transaction Performance (TWSM) Some considerations for the IBM Tivoli Monitoring for Transaction Performance (TWSM) Source ETL follow: The source database for the IBM Tivoli Monitoring for Transaction Performance (TWSM) Source ETL is the WebServices Courier database.70 Introducing IBM Tivoli Service Level Advisor
  • 94. Patch 1.7-WSM-0003 along with eFix 1.7-WSM-0003e is required for the IBM Tivoli Monitoring for Transaction Performance (TWSM) application and must be installed prior to running the IBM Tivoli Monitoring for Transaction Performance (TWSM) Source ETL. The eFix can be downloaded at the following site by using the anonymous user: ftp://ftp.tivoli.com/support/patches/LA/1.7-WSM-0003E.almondbutterFor more information, refer to Tivoli Web Services Manager WarehouseEnablement Pack: Implementation Guide, which is provided with the IBM TivoliMonitoring for Transaction Performance (TWSM) Source ETL installation media.IBM Tivoli Monitoring for Transaction Performance (TAPM)Some considerations for the IBM Tivoli Monitoring for Transaction Performance(TAPM) Source ETL follow: The source database for the IBM Tivoli Monitoring for Transaction Performance (TAPM) Source ETL is the TAPM database for which the TAPM RIM object is configured. No additional patches are required for IBM Tivoli Monitoring for Transaction Performance (TAPM).For more information, refer to Tivoli Application Performance ManagerWarehouse Enablement Pack: Implementation Guide, which is provided with theIBM Tivoli Monitoring for Transaction Performance (TAPM) Source ETLinstallation media.IBM Tivoli Enterprise ConsoleSome considerations for the IBM Tivoli Enterprise Console Source ETL follow: The source database for the IBM Tivoli Enterprise Console Source ETL is the TEC Event database for which the TEC RIM object is configured. No additional patches are required for the IBM Tivoli Enterprise Console.For more information, refer to Tivoli Enterprise Console Warehouse EnablementPack: Implementation Guide, which is provided with the IBM Tivoli EnterpriseConsole Source ETL installation media.IBM Tivoli Business Systems ManagerSome considerations for the IBM Tivoli Business Systems Manager Source ETLfollow: The source database for the IBM Tivoli Business Systems Manager Source ETL is the TBSM Microsoft SQL database. Chapter 3. Implementation planning 71
  • 95. Patch 1.5-BMS-0034 is required for the IBM Tivoli Business Systems Manager application and must be installed prior to running the IBM Tivoli Business Systems Manager Source ETL. For more information, refer to Tivoli Business Systems Manager Warehouse Enablement Pack: Implementation Guide, which is provided with the IBM Tivoli Business Systems Manager Source ETL installation media.3.4 Planning for event notification When IBM Tivoli Service Level Advisor evaluates measurement data, an event notice can be sent to alert management or support personnel when violations or potential violations have been discovered, enabling them to take corrective action to maintain agreed-upon levels of service to the customer. The IBM Tivoli Service Level Advisor event notification function also provides information on IBM Tivoli Service Level Advisor application problems. Any of the following notification methods can be used, either separately or concurrently: SNMP Trap TEC Event E-mail The event notification method is specified during the IBM Tivoli Service Level Advisor installation, but can be activated, changed, or configured through a set of IBM Tivoli Service Level Advisor CLIs.3.4.1 SNMP Trap notification You can configure IBM Tivoli Service Level Advisor to send notification events in the form of SNMP Traps to Tivoli NetView or any other SNMP managers. In order to configure ITSLA to send a SNMP Trap, you will need to provide during the following information during installation: Destination host name This is the fully qualified host name of the destination machine acting as the receiving SNMP management station for SNMP Traps. Destination port This is the SNMP Trap destination port number. A default value of 162 is provided. Specify a different port number if needed. Community name This is an optional field containing the SNMP Trap service community name. A default value of public is provided.72 Introducing IBM Tivoli Service Level Advisor
  • 96. Since IBM Tivoli Service Level Advisor does not filter SNMP Traps sent to the configured SNMP manager, you must either configure for SNMP ITSLA traps to be sent, or not to be sent at all. Because of this, you must configure a filter on your SNMP manager in order to discard SNMP Traps being sent by IBM Tivoli Service Level Advisor that you do not need. For more information on the MIB that is used to format the SNMP Traps for ITSLA events, see the SNMP Trap event notification section of Administrator’s Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835. In addition, you will have to configure the ITSLA SNMP Trap definition on your SNMP manager. If your SNMP Trap receiver is NetView for Windows NT, IBM Tivoli Service Level Advisor traps can be created and formatted by using the example provided in “Event escalation” on page 325.3.4.2 TEC Event notification By using the non-TME connection method, IBM Tivoli Service Level Advisor can be configured to send a TEC Event if you already have a functional TEC Server in your environment. As IBM Tivoli Service Level Advisor itself cannot directly execute a program or a task as a response to an event, you can configure the event to be forwarded to TEC, where rules can then be written to execute the desired program or task. The TEC Event Server must be configured to receive IBM Tivoli Service Level Advisor events. To configure IBM Tivoli Service Level Advisor to send a TEC Event, you will need the following information: TEC Event server host name This is the fully qualified host name where the Tivoli Enterprise Console event server is installed. TEC Event server port If the event server is installed on a Windows machine, enter the port number that the event server uses to listen on for events. The typical port value is 5529. IBM Tivoli Service Level Advisor provides a baroc file, SLM.baroc, located in the ITSLA_Inst_Dir/tec directory, where ITSLA_Inst_Dir is the ITSLA Server installation directory. SLM.baroc is the SLA Event class definition file for the TEC server, with the defined event classes listed below: SLA-Base-Event SLA-Violation-Event SLA-Trend-Event SLA-Trend-Cancel-Event Chapter 3. Implementation planning 73
  • 97. The SLM.baroc file must be imported and compiled in the TEC rule base in order to enable the IBM Tivoli Service Level Advisor events reception on the TEC server. The content of the SLM.baroc file is given in Example 3-1 on page 74. For more information on how to import and compile baroc files on the TEC server, consult the TEC documentation.Example 3-1 Contents of the SLM.baroc fileTEC_CLASS: SLA-Base-Event ISA EVENT DEFINES { source: default = "IBM Tivoli Service Level Advisor"; sub_source: default = "Service Level Agreement Manager"; metricName: STRING; componentName: STRING; componentLongName: STRING; consumerName: STRING; customerOrderID: STRING; offeringName: STRING; realm: STRING; accountID: STRING; serviceElementName: STRING; scheduleState: STRING; };ENDTEC_CLASS: SLA-Violation-Event ISA SLA-Base-Event DEFINES { startDate: STRING; endDate: STRING; minMetricValue: STRING; minBreachValue: STRING; maxMetricValue: STRING; maxBreachValue: STRING; avgMetricValue: STRING; avgBreachValue: STRING; };ENDTEC_CLASS: SLA-Trend-Event ISA SLA-Base-Event DEFINES { elementInstanceID: STRING; minProjectedDate: STRING; maxProjectedDate: STRING; avgProjectedDate: STRING; };END74 Introducing IBM Tivoli Service Level Advisor
  • 98. TEC_CLASS: SLA-Trend-Cancel-Event ISA SLA-Base-Event DEFINES { elementInstanceID: STRING; };ENDTEC_CLASS: SLM-Application-Event ISA EVENT DEFINES { source: default = "IBM Tivoli Service Level Advisor"; };END IBM Tivoli Service Level Advisor provides a sample TEC rule that automates the closing of IBM Tivoli Service Level Advisor trend events. However, if you want to receive only certain types of events, you must create and configure your own TEC rule to discard the undesired events, as IBM Tivoli Service Level Advisor does not filter the events sent to TEC. The TEC rule file name is slm.rls and is located in the same directory as the SLM.baroc file. The content of the slm.rls file is given in Example 3-2. Example 3-2 Contents of the slm.rls file rule: trend_cancel: ( event: _event of_class SLA-Trend-Cancel-Event where [ status: equals OPEN , metricName: _metricName , elementInstanceID: _elementInstanceID , componentName: _componentName, scheduleState: _scheduleState ] , reception_action: ( all_instances(event: _trn_ev of_class SLA-Trend-Event where [ metricName: equals _metricName, elementInstanceID: equals _elementInstanceID, componentName: equals _componentName, scheduleState: equals _scheduleState, status: outside [CLOSED] ] ), Chapter 3. Implementation planning 75
  • 99. change_event_status(_trn_ev, CLOSED), drop_received_event ) ).3.4.3 E-mail notification If you would like to notify specific support and management personnel when SLA violations or trends occur, or when the IBM Tivoli Service Level Advisor application experiences problems, IBM Tivoli Service Level Advisor can be configured to send multiple e-mails based on the information regarding violation, trend, or application events. To configure IBM Tivoli Service Level Advisor to send an e-mail, you will need to decide on the following information: SMTP Server host name This is the fully qualified host name of the SMTP Server to handle the e-mail messages. To-list e-mail addresses Here you have the list of e-mail addresses, separated by commas, for the people you want notifications to be sent to. CC-list e-mail addresses Here you add one or more e-mail addresses, separated by commas, for additional people you want to notify on the message. This might be reserved for supervisory personnel or other people who may not deal directly with the violation or trend information, but who want to stay informed.3.5 Planning worksheets The following tables provide some planning worksheets to aid the planning and installation of IBM Tivoli Service Level Advisor and supporting applications. Table 3-8 Planning worksheet for IBM WebSphere Application Server Planning for IBM WebSphere Application Server Node name of IBM WebSphere Application Server Host name and IP address of IBM WebSphere Application Server76 Introducing IBM Tivoli Service Level Advisor
  • 100. Planning for IBM WebSphere Application Server Currently installed IBM WebSphere Application Server version IBM WebSphere Application Server installation directoryTable 3-9 Planning worksheet for databases Planning for databases TEDW Control Center component host name and IP address TEDW Server host name and IP address TEDW Central Warehouse instance name TEDW Central Warehouse instance user name/password ITSLA Measurement Data Mart Server host name and IP address ITSLA Measurement Data Mart database instance name ITSLA Measurement Data Mart database instance user name/password ITSLA Database Server host name and IP address ITSLA Database instance name ITSLA Database instance user name/passwordTable 3-10 Planning worksheet for ITSLA Planning for IBM Tivoli Service Level Advisor ITSLA Server host name and IP address ITSLA Reports Server host name and IP address (must be installed on the IBM WebSphere Application Server machine) ITSLA Task Drivers server host name and IP address (must be installed on the Tivoli Presentation Services machine) Chapter 3. Implementation planning 77
  • 101. Table 3-11 Planning worksheet or event notification Planning for event notification Notification by SNMP Trap Destination host name Destination port Community name (optional) Notification by TEC Event TEC Server host name TEC Server port Notification by e-Mail SMTP server host name To-list of e-mail addresses CC-list of e-mail addresses (optional)78 Introducing IBM Tivoli Service Level Advisor
  • 102. 4 Chapter 4. Getting IBM Tivoli Service Level Advisor up and running This chapter describes the installation and configuration procedures in order to have IBM Tivoli Service Level Advisor (ITSLA) up and running. The installation process will be presented using a typical environment as example. The installation and configuration of the following ITSLA components and prerequisite applications are discussed in this chapter: IBM DB2 Universal Database Enterprise Edition Tivoli Enterprise Data Warehouse Server Tivoli Enterprise Data Warehouse Control Center IBM WebSphere Application Server IBM Console Server ITSLA Database Server ITSLA Task Drivers ITSLA Server ITSLA Reports Server ITSLA ETL programs© Copyright IBM Corp. 2002 79
  • 103. 4.1 Example scenario In this section we present the scenario used to describe the installation process of the various components and prerequisite applications of an ITSLA environment. This may be used as a start point to anyone responsible for the deployment of the IBM Tivoli Service Level Advisor Version 1.1 product. We also assume no preexisting components will be used, and describe the steps of a brand new installation. Please refer to Chapter 3, “Implementation planning” on page 51, for hardware and software requirements, as well as for tips and hints on how to best design your ITSLA environment and leverage existing production environments. AIX 4.3.3 DB2 Server AIX 4.3.3 1 TEDW Central Data Warehouse 2 DB2 Server TEDW Data Mart ITSLA Databases creation TEDW Server ITSLA Database Server TWH_CWD DYK_DM DYK_CAT ITSLA ITSLA Measurement Database TWH_MART Data Mart Central offering Trend and Reporting Control orders analysis 5 data 3 4 AIX 4.3.3 Windows 2000 DB2 Client DB2 Server AIX 4.3.3 TEDW Reports Interface TWH_MD TEDW Control Center DB2 Client (IBM Console) ITSLA ETLs IBM WebSphere ITSLA Server Source ETLs ITSLA Reports Server ITSLA Task Drivers TEDW Control Center ITSLA Server ITSLA ReportsFigure 4-1 Installation scenario As shown in Figure 4-1, our environment is composed of five machines, as follows: 1. TEDW Server machine a. RS6000 running AIX 4.3.380 Introducing IBM Tivoli Service Level Advisor
  • 104. b. IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (Fixpack 5 included) c. Tivoli Enterprise Data Warehouse Central Data Warehouse d. Tivoli Enterprise Data Warehouse Data Mart2. ITSLA Database Server machine a. RS6000 running AIX 4.3.3 b. IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (Fixpack 5 included) c. ITSLA Databases creation3. TEDW Control Center machine a. PC Server running Windows 2000 ASE SP2 b. IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (Fixpack 5 included) c. Tivoli Enterprise Data Warehouse Control Center d. ITSLA ETL programs (Process and Registration ETLs) e. All Source ETL programs4. ITSLA Server machine a. RS6000 running AIX 4.3.3 b. IBM DB2 Universal Database Enterprise Edition Client Version 7.2 (Fixpack 5 included) c. IBM Console Server d. ITSLA Server e. ITSLA Task Drivers5. ITSLA Reports machine a. RS6000 running AIX 4.3.3 b. IBM DB2 Universal Database Enterprise Edition Client Version 7.2 (Fixpack 5 included) c. IBM WebSphere Application Server d. ITSLA Reports ServerThe installation process for each of the above machines will be explained in thefollowing sections. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 81
  • 105. Note: We provide the installation steps for each one of the above components on IBM AIX 4.3.3 and Microsoft Windows 2000 Advanced Server Edition only. If you are planning to use any other operating system platform, you should refer to the official product documentation.4.2 Setting up the TEDW Server machine This machine will serve as the host of the Central Warehouse Repository database. The following components are needed: IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (Fixpack 5 included) Tivoli Enterprise Data Warehouse Central Data Warehouse Tivoli Enterprise Data Warehouse Data Mart4.2.1 IBM DB2 UDE Server for UNIX installation This section describes the IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (Fixpack 5 included) installation process on AIX. Note: Use the DB2 installation media provided with the Tivoli Enterprise Data Warehouse product. This ensures that you get the correct version and Fixpack of DB2 installed. 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 on page 83, appears. Select the DB2 UDB Enterprise Edition option.82 Introducing IBM Tivoli Service Level Advisor
  • 106. Figure 4-2 Install DB2 V7 - DB2 UDB Enterprise Edition3. A New DB2 instance should be created for the TEDW databases. We specified the DB2 instance name db2inst1, as shown in Figure 4-3 on page 84. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 83
  • 107. Figure 4-3 Create DB2 Services - DB2 Instance db2inst1 4. Next the DB2 Warehouse Control Database screen appears. Select Set up DB2 Warehouse Control Database. We used the default name for the DB2 Warehouse Control database, dwcntrl. 5. Figure 4-4 on page 85 shows the values we used on the option Create the Administration Server.84 Introducing IBM Tivoli Service Level Advisor
  • 108. Figure 4-4 Administration Server screen6. The installation process creates and sets the values of several environment variables, DB2SYSTEM, for example.7. At the end of the installation process, you may check the installation log file created at /tmp/db2setup.log.8. 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 The output must include the following path: INSTHOME/sqllib/java12/db2java.zip Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 85
  • 109. 4.2.2 TEDW Central Warehouse and TEDW Data Mart installation In this section we describe the steps to install the TEDW Central Warehouse and TEDW Data Mart components on AIX. 1. From the directory where the TEDW CDROM is mounted, enter the following command to start the installation wizard: # ./setup_unix.sh 2. The InstallShield Wizard dialogue window for Tivoli Enterprise Data Warehouse Installation is the first window to appear. Click Next. 3. The dialogue window for the type of installation appears as shown in Figure 4-5. Select Custom/Distributed and the directory name where you want to install TEDW. In our environment, we used the default value /opt/TWH. Figure 4-5 Install type dialogue window 4. From the Select features for TEDW dialogue window, as shown in Figure 4-6 on page 87, select Central Data Warehouse and Data Mart. Click Next.86 Introducing IBM Tivoli Service Level Advisor
  • 110. Figure 4-6 Select features dialogue window - TEDW Central Data Warehouse5. The host name dialogue window appear. Verify that this is the correct host name for the installation. Enter the fully qualified host name of the TEDW Central Data Warehouse machine. Click Next.6. The installation process asks for a valid DB2 user ID in order to create the required TEDW databases. In our example it is db2inst1. This machine will host the following databases, as shown in Figure 4-1 on page 80: – TWH_CWD – TWH_MART Enter the valid DB2 user ID and password that was created during the DB2 installation and type in the fully qualified host name of the TEDW Server; then verify that the database port number is correct. Click Next.7. The installation setup program prompts for a valid DB2 user ID and password to be used to access the TEDW Control Center machine. We used db2admin. It also asks for the fully qualified host name and TCP/IP communication port.8. The overview of selected features dialogue window appear, as shown in Figure 4-7 on page 88. Click Install to start the installation. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 87
  • 111. Figure 4-7 TEDW Central Data Warehouse and Data Mart installation 9. The InstallShield Wizard window appears and informs you of whether the installation was successful. Verify that the installation was successful by making sure there is no error massage in the installation window. Also, check the TWH.log file to ensure all warning messages can safely be ignored. Click Finish to exit the wizard.4.3 Setting up the ITSLA Database Server machine This machine will serve as a DB2 database server hosting all databases used by ITSLA. The following steps need to be performed in order to have the ITSLA Database Server machine installed: 1. Install IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (Fixpack 5 included) for UNIX. 2. Create ITSLA Databases. The installation of the IBM DB2 Universal Database Enterprise Edition Server should follow the steps provided in 4.2.1, “IBM DB2 UDE Server for UNIX installation” on page 82. The following section describes the ITSLA Databases creation process.88 Introducing IBM Tivoli Service Level Advisor
  • 112. 4.3.1 Creating the ITSLA Databases The creation of all ITSLA Databases should be performed manually. ITSLA provides scripts to accomplish this task for several different platforms, such as SUN Solaris, Linux, Windows, and IBM AIX. The scripts that will create the databases are on the ITSLA CD in the following directories: IBM AIX cdrom_dir/database/scripts/aix4-r1 Sun Solaris cdrom_dir/database/scripts/solaris2 Linux cdrom_dir/database/scripts/linux_ix86 Windows cdrom_dir :databasescriptsw32-ix86 Table 4-1 shows the DB2 database to be created and the associated script. Table 4-1 ITSLA Databases installation scripts ITSLA Database name DB2 Database name Script (.sh or .bat) ITSLA Database DYK_CAT dyk_cat_dbinst ITSLA Measurement Data Mart DYK_DM dyk_dm_dbinst The following steps were used to create the ITSLA Databases on AIX: 1. Log in as a DB2 instance owner. 2. Navigate to the db2_instance_dir/sqllib directory, where db2_instance_dir is the home directory of the DB2 instance. 3. Source the DB2 environment variables: # . db2profile 4. Insert the ITSLA product CD in the CD-ROM drive and mount the CD. 5. Start the database creation scripts from the appropriate directory by entering the following command: – For the DYK_CAT database: # ./CDROM_Dir/database/scripts/aix4-r1/dyk_cat_dbinst.sh – For the DYK_DM database: # ./CDROM_Dir/database/scripts/aix4-r1/dyk_dm_dbinst.sh 6. Each of the scripts is interactive and prompts you for the following information (we used most of the provided defaults values): – The DB2 instance owner user ID. In our case we used db2inst1. – The password for your DB2 user ID. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 89
  • 113. – The name for the ITSLA Database and ITSLA Measurement Data Mart databases. The default values are DYK_CAT and DYK_DM, respectively. – The home directory of the DB2 instance of the DYK_CAT or the DYK_DM database. Default value: /home/db2inst1. – The territory used for data entered into the DYK_CAT or the DYK_DM database. Default value is US. – The fully qualified path of the file you would like the output of the script to be directed to. We used /tmp/dyk_cat.log and /tmp/dyk_dm.log. – The fully qualified path of the file you would like the table verification output to be directed to. We used /tmp/dyk_cat_ver.log and /tmp/dyk_dm_ver.log. – It prompts you if an old version of the ITSLA Databases should be dropped. As a new installation the default value is N. – Make sure you choose to enable LOGRETAIN for recovery on the DYK_CAT and DYK_DM databases. 7. Check the log files in the directories you have specified for any errors that may have occurred during the database creation. 8. Check the log files in the directories you have specified to verify that all of the database tables were successfully created. For the DYK_CAT database a total of 75 tables are created (53 tables and views with the one schema and 22 tables with the other schema), and for the dyk_dm database a total of nine tables are created. For additional details on DYK_CAT and DYK_DM databases, refer to Appendix C, “IBM Tivoli Service Level Advisor Databases” on page 403.4.4 Setting up the TEDW Control Center machine This machine will serve as the control center of our environment. It will use the TEDW control database containing the metadata for Tivoli Enterprise Data Warehouse (TWH_MD) and will be used to manage our ITSLA ETLs and the data warehouse environment. The following are the components that need to be installed in this machine: IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (Fixpack 5 included) for Windows Tivoli Enterprise Data Warehouse Control Center ITSLA ETL programs (Process and Registration ETLs) All Source ETL your environment may require. Set up the ODBC connections90 Introducing IBM Tivoli Service Level Advisor
  • 114. The following sections describe the installation and configuration steps in order to have the TEDW Control Center machine up and running.4.4.1 IBM DB2 UDE Server for Windows installation This section describes the IBM DB2 Universal Database Enterprise Edition Server Version 7.2 (Fixpack 5 included) installation process on Windows. Note: Use the DB2 installation media provided with the IBM Tivoli Service Level Advisor product. This ensures that you get the correct version and Fixpack of DB2 installed. 1. Load the DB2 installation media provided with ITSLA. 2. Select Start -> Run. Type in D:setup.exe and click OK to start the installation. From the Installation window, select Install. 3. The Select Products window opens. From this window you can select the component(s) of DB2 for Windows you would like to install. Select DB2 Enterprise Edition as shown in Figure 4-8. Click Next. Figure 4-8 Select DB2 Enterprise Edition 4. The Select Installation Type window opens. Select the installation type you prefer. We selected Typical. 5. For the destination directory, we used C:SQLLIB. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 91
  • 115. 6. For the DB2 administrative user ID, we selected db2admin. 7. After a few minutes the Install OLAP Starter Kit window opens. Select Do not install the OLAP Starter Kit and then Finish. 8. Install the IBM DB2 eFix. In addition to the installation steps, it is necessary to apply the DB2 eFix. (APARs JR16650 and JR16766). The e-fixes are available on the following Tivoli Enterprise Data Warehouse support Web site, under the Tivoli Enterprise Data Warehouse category: http://www.ibm.com/software/sysmgmt/products/support The eFix consists of two files: iwh2exp2.exe and iwh2imp2.exe. We need to copy these files over the ones installed by the DB2 installation, as follows: a. Rename D:sqllibbiniwh2exp2.exe to D:sqllibbiniwh2exp2.exe.old. b. Rename D:sqllibbiniwh2imp2.exe to D:sqllibbiniwh2imp2.exe.old. c. xcopy iwh2exp2 D:sqllibbin. d. xcopy iwh2imp2 D:sqllibbin. 9. 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_DIRjava12 usejdbc2 Where DB2_DIR is the DB2 installation directory. The usejdbc2 command will copy the appropriate version of db2java.zip into the DB2_DIRjava12 directory. 10.Reboot the machine.4.4.2 Tivoli Enterprise Data Warehouse Control Center installation In this section we describe the steps to install the TEWD Control Center component on Windows. 1. Select Start -> Run. Type in D:setup.exe and click OK to start the installation. 2. The dialogue box for the type of installation appears. Select Custom/Distributed and the directory name where you want to install TEDW. In our environment, we used C:TWH. 3. From the Select features for TEDW dialogue window, as shown in Figure 4-9 on page 93. Select Tivoli Enterprise Data Warehouse control server. Click Next.92 Introducing IBM Tivoli Service Level Advisor
  • 116. Figure 4-9 Select features dialogue window - TEDW control server4. The host name dialogue window appears. Verify that this is the correct host name for the TEDW Control Center machine. Click Next.5. The local system DB2 configuration dialogue window appear. The installation process asks for a valid DB2 user ID in order to create the required TEDW database. Enter the valid DB2 user ID and password that was created during the DB2 installation on your local system. In our case, we used db2admin. This machine will host the database TWH_MD, as shown in Figure 4-1 on page 80. Click Next.6. The overview of selected features dialogue window appears as shown in Figure 4-10 on page 94. Click Install to start the installation. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 93
  • 117. Figure 4-10 TEDW control server installation 7. The complete installation window appears. Select No, I will restart my system at a later time. Click Next. 8. The InstallShield Wizard window appears informing you as to whether the installation was successful. Verify that the installation was successful by making sure there are no error massages in the installation window. Also, check the TWH.log file to ensure all warning messages can safely be ignored. Click Finish to exit the wizard. 9. Reboot your system.4.4.3 ITSLA ETL programs installation As explained in 2.5, “IBM Tivoli Service Level Advisor Target ETLs” on page 37, ITSLA uses Process and Registration ETLs. The following steps are required to install the ITSLA ETL programs. In this section we describe the steps 1 and 2, as steps 3 and 4 are described in detail in 5.2, “Target ETLs management” on page 142. 1. Import the ITSLA ETLs into the TEDW Control Center machine. 2. Provide the TEDW Control Center with correct user information for proper source and target database access. 3. Enable source applications data collection. 4. Enable and schedule ITSLA ETL programs to run.94 Introducing IBM Tivoli Service Level Advisor
  • 118. Importing the ITSLA ETL programsAll ITSLA ETL programs must be imported into the TEDW Control Centermachine. You need both the Tivoli Enterprise Data Warehouse and the IBM TivoliService Level Advisor products installation media.1. Select Start -> Run. Type in D:setup.exe and click OK to start the installation, where D is the CDROM directory.2. When the InstallShield Wizard dialogue window for Tivoli Enterprise Data Warehouse Installation appears, click Next.3. The dialogue window for the type of installation appears. Select Application installation only and the directory name where the TEDW components are installed. We used C:TWH. Click Next to continue.4. The host name dialogue window appears. Verify that this is the correct host name for the TEDW Control Center machine. Click Next.5. The local system DB2 configuration dialogue 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 dialogue window appears, as shown in Figure 4-11 on page 96. You should provide the location of the ITSLA ETLs programs. Change the TEDW CD in the CD-ROM drive with the ITSLA installation CD. Specify the path to the twin_app_install_list.cfg file (by default in the CD_drive:tedw_appsdyk directory) on the ITSLA CD 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. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 95
  • 119. Figure 4-11 Path to the installation media for the ITSLA ETL programs 7. The overview of selected features dialogue window appears as shown in Figure 4-12. Click Install to start the installation. Figure 4-12 ITSLA ETL programs installation96 Introducing IBM Tivoli Service Level Advisor
  • 120. 8. Once the installation is finished, check the log files for any errors.4.4.4 Source ETLs installation As explained in 2.7, “Applications providing measurement data” on page 46, there are five Tivoli applications providing service level measurement data to ITSLA. In our environment scenario, use used the following applications: IBM Tivoli Enterprise Console IBM Tivoli Business Systems Manager IBM Tivoli Monitoring for Transaction Performance (TAPM and TWSM) IBM Tivoli Monitoring Each application above provides its own Source ETL, also known as warehouse packs, installation and configuration processes. In order to avoid confusion, we provide in this section a generic installation procedure and recommend that the installation instructions for each specific Source ETL should also be followed. Also see Tivoli Enterprise Data Warehouse Installing and Configuring Version 1.1, GC32-0744, for additional information. The following steps provide a typically Source ETL installation: 1. Use the Tivoli Enterprise Data Warehouse installation program to install the Source ETLs. Click Next. 2. The dialogue window for the type of installation appears, as shown in Figure 4-13 on page 98. Select Application installation only and the directory name where the TEDW components are installed. We used C:TWH. Click Next to continue. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 97
  • 121. Figure 4-13 TEDW Source ETLs setup type 3. The host name dialogue window appears. Verify that this is the correct host name for the TEDW Control Center machine. Click Next. 4. The local system DB2 configuration dialogue 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. 5. The path to the installation media for the application packages dialogue window appears, as shown in Figure 4-14 on page 99. You should provide the location of the source application ETL program. In order to install the Source ETLs provided by ITSLA, change the TEDW CD installation media with the IBM Tivoli Service Level Advisor Version 1.1 Source ETL installation media. Specify the path to the twh_app_install_list.cfg file. If you intend to install all Source ETLs provided by ITSLA, then use the path CD_drive:, where CDROM_Dir is the CDROM drive containing the IBM Tivoli Service Level Advisor Version 1.1 Source ETL installation media. You can also install individual Source ETL applications by providing the path CD_Drive:MCODE, where MCODE is the standard three-letters measurement source code. Table 4-2 on page 99 provides the measurement source code for all Tivoli applications.98 Introducing IBM Tivoli Service Level Advisor
  • 122. Table 4-2 Measurement source codes Tivoli application Measurement source code IBM Tivoli Monitoring for Transaction Performance APF (TAPM) IBM Tivoli Enterprise Console ECO IBM Tivoli Business Systems Manager GTM IBM Tivoli Monitoring DMN IBM Tivoli Monitoring for Transaction Performance BWM (TWSM) 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.Figure 4-14 Path to the installation media for the application packages6. The overview of selected features dialogue window appears, as shown in Figure 4-14. Click Install to start the installation. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 99
  • 123. Figure 4-15 TEDW Source ETLs installation 7. Once the installation is finished, check the log files for any errors. 8. Perform any pre-installation configuration steps specified by the Source ETL documentation. For example, this might include tasks such as: – Creating additional tables in an existing database. – Installing additional product patches. – Configuring the source database user name and password. Follow the steps provided in “Providing user ID information to the various databases” on page 101. – Establishing an ODBC connection. This will be discussed in the next section.4.4.5 TEDW Control Center basic configuration This section gives instructions for the basic configuration steps for the TEDW Control Center machine. Specifying the Meta Data database to the TEDW Control Center You need to specify which Meta Data database will be used. In our environment scenario, the TEDW Control Center machine hosts the TWH_MD database, which will serve as the Meta Data database.100 Introducing IBM Tivoli Service Level Advisor
  • 124. Perform the steps as follows:1. Start the IBM DB2 Control Center utility by selecting Start -> Programs -> IBM DB2 -> Control Center.2. On the IBM DB2 Control Center utility, start the IBM DB2 Data Warehouse Center utility by selecting Tools -> Data Warehouse Center.3. The Data Warehouse Center logon windows appears. Select Advanced. Verify that the Control database field contains TWH_MD, as shown in Figure 4-16.Figure 4-16 TWH_MD as control databaseProviding user ID information to the various databasesYou should inform the TEDW Control Center of user access information for everyTarget and Source ETL installed. For the IBM Tivoli Service Level Advisor,Target, Registration, and Process ETLs. The procedure presented here mustalso be used for any new Source ETL installed in the TEDW Control Center. Thefollowing steps should be followed:1. Start the IBM DB2 Control Center utility by selecting Start -> Programs -> IBM DB2 -> Control Center. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 101
  • 125. 2. On the IBM DB2 Control Center utility, start the IBM DB2 Data Warehouse Center utility by selecting Tools -> Data Warehouse Center. The Data Warehouse Center logon windows appears. 3. Log into the IBM DB2 Data Warehouse Center utility using the local DB2 administrator user ID. In our case, db2admin. 4. In the Data Warehouse Center window, expand the Warehouse Targets folder. There are two entries for the ITSLA ETL programs that need to be configured, as follows: – DYK_REG_DYK_CAT_TARGET for the Registration ETL – DYK_PROC_DYK_DM_TARGET for the Process ETL 5. You should edit the properties of each one of the above entries. In order to do that, right click it and select Properties and then select the Database tab. Fill in the user ID information. For our environment the values are shown in Figure 4-17, using the DYK_PROC_DYK_DM_TARGET as an example. Figure 4-17 DYK_PROC_DYK_DM_TARGET user ID information 6. For the Source ETLs, in the Data Warehouse Center window, expand the Warehouse Source folder, right click the appropriate Source ETL, select Properties and then select the Database tab. Fill in the user ID information.102 Introducing IBM Tivoli Service Level Advisor
  • 126. This step is described in detail in 5.1.1, “ETL Warehouse Target and Sources configuration” on page 134.4.4.6 Configuring the ODBC connections Since the TEDW Control Center machine hosts all the ETLs, it needs to have access to the various databases as follows: TEDW databases (TWH_CWD and TWH_MART) ITSLA Databases (DYK_CAT and DYK_DM) All source application databases ODBC connections on the TEDW Control Center machine should be created as described in the following sections. ODBC connections with the TEDW databases The TEDW Control Center installation program automatically creates the ODBC connections to the TWH_CWD and TWH_MART databases. You can check the ODBC connection as follows: 1. On Microsoft Windows 2000, select Start -> Programs -> Administrative Tools -> Data Sources (ODBC). 2. Click the System DSN tab, as shown in Figure 4-18. Click Add. Figure 4-18 ODBC configuration - System DSN tab Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 103
  • 127. ODBC connections with the ITSLA Databases The ITSLA product provides scripts for creating the ODBC connections with the ITSLA Databases. The dyk_dm_odbc.bat script catalogs an ODBC data source to the DYK_DM database and the dyk_cat_odbc.bat script catalogs an ODBC data source to the DYK_CAT database. These scripts are located in the CD_drive:databasescriptsw32_ix86 directory, where CD_drive is the CDROM containing the ITSLA installation media. You should only modify the scripts if you need to change the TCPIP port that the DB2 instance running on the TEDW Control Center machine uses to communicate with the remote DB2 server running on the ITSLA Database Server machine to a value different from 50000. ODBC connections with the source applications As described in 4.4.4, “Source ETLs installation” on page 97, we have installed in our environment all the source applications’ ETLs provided by Tivoli. Table 4-3 gives the names of the databases in which Tivoli applications store measurement data. ODBC connections to these databases in the TEDW Control Center machine should be created so that the respective Source ETL can process the data. Table 4-3 Tivoli source databases Source applications Source database IBM Tivoli Monitoring for Transaction Performance (TAPM) TAPM_RIM IBM Tivoli Enterprise Console TEC IBM Tivoli Business Systems Manager GTM_DB IBM Tivoli Monitoring DMN_RIM IBM Tivoli Monitoring for Transaction Performance (TWSM) BWM_TWSM Each one of the above application’s Source ETL comes with its own installation and configuration process. The ODBC connections for some may be created during the Source ETL installation. In addition to that, if you have developed in-house Source ETLs, those also provides their own source database that needs to be accessed by the TEDW Control Center machine during the ETL execution. If you need to manually create ODBC connections to a source database, you may use the script shown in Example 4-1 on page 105.104 Introducing IBM Tivoli Service Level Advisor
  • 128. Example 4-1 ODBC creation script: TEDW_odbc.bat@echo offecho This program catalogs an ODBC datasource on the TEDW Control Servermachineecho .setlocalrem -- ------------------------------------------------------ --rem -- PLEASE EDIT THE VARIABLES BELOW FOR YOUR INSTALLATION --rem Set the name of the odbc datasourceset GEN_DATASRC=%1rem Set the hostname of the database server containing the SOURCE databaseset DB2SRVRNAME=%2rem Set the alias of the cataloged database manager instance nodeset NODE_ALIAS=CAT_ODBCrem Set the port DB2 uses to communicate with the remote db serverset SRVR_PORT=50000if "%GEN_DATASRC%" == "" goto ABENDif "%DB2SRVRNAME%" == "" goto ABENDrem -- ------------------------- --rem -- Start the ODBC cataloging --db2 catalog tcpip node %NODE_ALIAS% remote %DB2SRVRNAME% server %SRVR_PORT%db2 catalog database %GEN_DATASRC% at node %NODE_ALIAS%db2 catalog system odbc data source %GEN_DATASRC%goto TERMINATEecho got to localrem db2 catalog system odbc data source %GEN_DATASRC%goto FIN:ABEND cls echo Usage: echo "TEDW_odbc data_source remote_hostname" goto END:TERMINATE db2 terminate:END endlocal Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 105
  • 129. 4.5 Setting up the ITSLA Server machine The ITSLA Server machine in our environment will combine all the core Service Level Management functions performed by both the ITSLA Server and ITSLA Task Drivers components, such as orders and offerings definitions, data evaluation and trend analysis, and so on. The ITSLA Server machine will host the following components: IBM DB2 Universal Database Enterprise Edition Client Version 7.2 (Fixpack 5 included) for UNIX TEDW Reports Interface (ITSLA uses the IBM Console Server component of the TEDW Reports Interface) ITSLA Server component ITSLA Task Drivers component The installation of the above components will be discussed in the following sections.4.5.1 IBM DB2 Client installation on AIX This section describes the IBM DB2 Universal Database Enterprise Edition Client Version 7.2 (Fixpack included) installation process on AIX. Note: Use the DB2 installation media provided with the IBM Tivoli Service Level Advisor product. This ensures that you get the correct version and Fixpack of DB2 installed. 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-19 on page 107, appears. Select the DB2 Administration Client option.106 Introducing IBM Tivoli Service Level Advisor
  • 130. Figure 4-19 Install DB2 V7 - DB2 Administration Client3. A new DB2 instance should be created. We kept all the default values for the user name, group name, and home directory, as shown in Figure 4-20.Figure 4-20 Create DB2 Services Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 107
  • 131. 4. The DB2 Setup Utility screen appears. The installation process creates and sets the values of several environment variables. 5. At the end of the installation process you may check the installation log file created at /tmp/d2setup.log. 6. 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 The output must include the following path: INSTHOME/sqllib/java12/db2java.zip4.5.2 Cataloging the ITSLA Databases Since the ITSLA Server machine contains both the ITSLA Server and the ITSLA Task Drivers components, it needs access to the databases hosted by the ITSLA Database Server machine as follows: DYK_DM DYK_CAT ITSLA provides the dyk_catalog.sh script to accomplish this task for all the supported platforms. The scripts that will catalog the remote server containing the ITSLA Databases and the ITSLA Databases can be found on the ITSLA installation CD in the following directories: IBM AIX cdrom_dir/database/scripts/aix4-r1 Sun Solaris cdrom_dir/database/scripts/solaris2 Linux cdrom_dir/database/scripts/linux_ix86 Where cdrom_dir is the directory where the ITSLA installation media is mounted.108 Introducing IBM Tivoli Service Level Advisor
  • 132. The script is interactive and prompts you for the following information. In our environment scenario, we used the provided defaults. The host name of the systems that contain the ITSLA Databases: In our case, the ITSLA Database Server machine. A local alias name for the remote node that contains the ITSLA Databases. Default value: dyk_node. The TCP/IP port number or service name for communication with the DB2 server. Default value is 50000. The name for the ITSLA Database and ITSLA Measurement Data Mart databases. The default values are DYK_CAT and DYK_DM, respectively. The local alias of the cataloged ITSLA Database and ITSLA Measurement Data Mart databases. The default values are DYK_CAT and DYK_DM, respectively The fully qualified path of the file you would like the output of the script to be directed to. We used /tmp/dyk_catalog.log.4.5.3 TEDW Reports Interface installation The installation of the TEDW Reports Interface is required in order to have the IBM Console presentation layer deployed. This presentation layer is also know as Tivoli Presentation Services. The IBM Console will enable execution of ITSLA administrative tasks in our environment. When installing the TEDW Reports Interface, both versions of the IBM Console (Java-based and Web-based) will be installed during the Tivoli Presentation Services installation step. The following steps describe the installation process of the TEDW Reports Interface on an AIX system. 1. From the directory where the TEDW CD-ROM is mounted, enter the following command to start the installation wizard: # ./setup_unix.sh 2. The InstallShield Wizard dialogue window for Tivoli Enterprise Data Warehouse Installation is the first window to appear. Click Next. 3. The dialogue window for the type of installation appears, as shown in Figure 4-21 on page 110. Select Custom/Distributed and the directory name where you want to install TEDW. In our environment, we used the default value /opt/TWH. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 109
  • 133. Figure 4-21 Install type dialogue window 4. From the Select features for TEDW dialogue window, as shown in Figure 4-22, select Report interface. Click Next. Figure 4-22 Select features dialogue window - TEDW Report Interface110 Introducing IBM Tivoli Service Level Advisor
  • 134. 5. The host name dialogue window appears. Verify that this is the correct host name for the installation on the local system. Enter the fully qualified host name of the TEDW Reports Interface machine. Click Next.6. The installation process asks for a valid DB2 user ID. Enter the valid DB2 user ID and password that was created during the local machine DB2 Client installation. In our case, db2inst1. Click Next.7. The Tivoli Presentation Services dialogue window appears, as shown in Figure 4-23. Confirm that none of the default ports are being used by another application.Figure 4-23 Tivoli Presentation Services ports panel Note: If you change the directory name for the Tivoli Presentation Services, do not specify a directory name that has a blank in it. The default directory name is /opt/PS on UNIX systems. If any of these ports are being used by another application, change the values and choose Next.8. The Install additional languages dialogue window appears. Leave this box unchecked and click Next.9. The installation setup program prompts for a valid DB2 user ID and password to be used to access the TEDW Control Center machine. We used db2admin. It also asks for the fully qualified host name and TCP/IP communication port. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 111
  • 135. 10.The remote system DB2 configuration for the TEDW Central Data Warehouse server dialogue window appears. Enter the valid DB2 user ID and password that were created during the DB2 installation on the TEDW Central Data Warehouse server. We used db2inst1. Type in the fully qualified host name of the TEDW Central Data Warehouse server, and verify that the database port number is correct. Click Next. 11.The remote system DB2 configuration for the TEDW Data Mart server dialogue window appears. Enter the valid DB2 user ID and password that were created during the DB2 installation on the TEDW Data Mart server. We used db2inst1. Type the fully qualified host name of the TEDW Data Mart server (in our example, the host name is the same as the TEDW Central Data Warehouse server) and verify that the value for the database port number is correct. Click Next. 12.The overview of selected features dialogue window appears, as shown in Figure 4-24. Click Install to start the installation. Figure 4-24 TEDW Report Interface installation 13.The InstallShield Wizard window appears informing you as to whether the installation was successful. Verify that the installation was successful by making sure there are no error messages in the installation window. Also check the TWH.log file to ensure that all warning messages can safely be ignored. Click Finish to exit the wizard. 14.Even though the installation process showed you the installation results in the previous step, you must wait for the Tivoli Presentation Services help set to be112 Introducing IBM Tivoli Service Level Advisor
  • 136. rebuilt. The help set contains the user assistance for the IBM Console. This process happens asynchronously and might not be completed by the time the wizard has finished the installation of the remaining components of TEDW the Reports Interface. Do not restart the system until the help set is complete. To determine whether the help set rebuild is complete, look for the completion message in the Tivoli Presentation Services installation log. This log is in the file PS_directory/log/fwp_mcr/stdoutn, where PS_directory is the Tivoli Presentation Services installation directory. In our case, /opt/PS. Look for the message (Example 4-2) in the most recent stdoutn file. In some cases, the message can be in the second most recent stdoutn file. Example 4-2 Successful Presentation Services help setup completion message FWP1734I The utility that was started by the Management Component Repository to build the help set has completed successfully. This process may take up to 30 or 40 minutes. 15.Reboot the machine.4.5.4 ITSLA Server component installation In order to have the ITSLA Server component installed you should perform the following steps: 1. From the directory where the ITSLA CD-ROM is mounted, enter the following command to start the installation wizard: # ./install.sh 2. The InstallShield Wizard dialogue window for IBM Tivoli Service Level Advisor installation is the first window to appear. Click Next. 3. The dialogue window for the ITSLA Server installation directory appears. We used the default value /opt/TSLA. Click Next. 4. The ITSLA installation options dialogue window appears, as shown in Figure 4-25 on page 114. Uncheck the SLM Reports and the SLM Task Drivers options and make sure that only the IBM Tivoli Service Level Advisor 1.1 and SLM Server options are selected. Click Next. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 113
  • 137. Figure 4-25 ITSLA Server component installation 5. The dialogue window for the ITSLA Database appears as shown in Figure 4-26 on page 115. In the dialogue window you are prompted to provide the information below. We kept all the default values. Database name Specifies the name of the ITSLA Database. Default value is dyk_cat. User ID The DB2 user information for remote access to the ITSLA Databases installed in the ITSLA Database Server machine. Default value is db2inst1. Password This is the sign-on password for the above user ID. DB Server host name This is the fully qualified host name of the machine that contains the ITSLA Database component. DB Server port number This is the communication port number or the service name of the database manager instance that contains the ITSLA Database component. Default value is 50000.114 Introducing IBM Tivoli Service Level Advisor
  • 138. Remote database instance This is an optional field that specifies the name of the server instance that contains the ITSLA Database component. Click Next to continue.Figure 4-26 ITSLA Database dialogue window6. The dialogue window for the ITSLA Measurement Data Mart appears as shown in Figure 4-27 on page 116. In the dialogue window you are prompted to provide the information below. We kept all the default values. Database name Specifies the name of the ITSLA Measurement Data Mart database. Default value is dyk_dm. User ID The DB2 user information for remote access to the ITSLA Databases installed on the ITSLA Database Server machine. Default value is db2inst1. Password This is the sign-on password for the above user ID. DB Server host name This is the fully qualified host name of the machine that contains the ITSLA Measurement Data Mart component. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 115
  • 139. DB Server port number This is the communication port number or the service name of the server database manager instance that contains the ITSLA Database component. Default value is 50000. Remote database instance This is an optional field that specifies the name of the server instance that contains the ITSLA Measurement Data Mart component. Click Next to continue. Figure 4-27 ITSLA Measurement Data Mart database dialogue window 7. Next you will be presented with a dialogue window prompting you for the home directory of the DB2 instance on the local machine. We used the default value /home/db2inst1. Click Next. 8. The port numbers dialogue window for the ITSLA Server communication port and command line interface port appear. Only change the default values if there is a conflict with port number in your system. As shown in Figure 4-28 on page 117, you should specify the following information: ITSLA communication port This port will be used for communication between the ITSLA Server and the ITSLA Task Drivers components. Default value is 9980.116 Introducing IBM Tivoli Service Level Advisor
  • 140. Command line interface port This port will be used for command line interface procedures. Default value is 9990. CLI password protection Specify whether or not you want your command line interface commands to be password protected. If you select this option, CLI commands that are issued must be entered by specifying an additional parameter, -p password. Click Next to continue.Figure 4-28 Port information for the ITSLA Server installation9. The dialogue window for notification of ITSLA events (violation, trend, trend cancelled, and application events) appears as shown in Figure 4-29 on page 118. If you want to enable event notification, check one or more of the check boxes. Click Next to provide additional configuration information for each of your selected notification methods. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 117
  • 141. Note: ITSLA event notification can also be configured after installation using the scmd escalate command. For additional information refer to Chapter 5, “Administering IBM Tivoli Service Level Advisor” on page 133, and the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833. Figure 4-29 ITSLA event notifications window 10.By selecting the SNMP Trap option for event notification, SNMP, the configuration window as shown in Figure 4-30 on page 119, will appear. You will be prompted to provide the following information: Destination host name This is the fully qualified host name of the destination machine acting as the receiving SNMP management station for SNMP Traps. Destination port This is the SNMP Trap destination port number. A default value of 162 is provided. Specify a different port number if needed. Community name This is an optional field containing the SNMP Trap service community name. A default value of public is provided.118 Introducing IBM Tivoli Service Level Advisor
  • 142. Figure 4-30 Configuring SNMP Trap event notification Click Next to continue.11.By Selecting the TEC Event option for event notification, the TEC configuration window, as shown in Figure 4-31 on page 120, will appear. You will be prompted to provide the following information: TEC Event Server host name This is the fully qualified host name where the Tivoli Enterprise Console event server is installed. TEC Event Server port If the event server is installed on a Windows machine, enter the port number that the event server uses to listen on for events. The typical port value is 5529. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 119
  • 143. Figure 4-31 Configuring Tivoli Enterprise Console event notification Click Next to continue. 12.By selecting the E-mail option to send e-mail messages to one or more addresses when an event occurs, the configuration window, as shown in Figure 4-32 on page 121, will appear. Provide the following information: SMTP Server host name This is the fully qualified host name of the SMTP Server to handle the e-mail messages. This is a required field. To-list e-mail addresses Here you add one or more e-mail addresses, separated by commas, for the people you want notifications to be sent to. This is a required field. No error checking is performed on the e-mail addresses entered here.120 Introducing IBM Tivoli Service Level Advisor
  • 144. CC-list e-mail addresses Here you add one or more e-mail addresses, separated by commas, for additional people you want notify with the message. This might be reserved for supervisory personnel or other people who may not deal directly with the violation or trend information, but who want to stay informed. No error checking is performed on the e-mail addresses entered. Click Next to continue with the configuration of the e-mail notification method.Figure 4-32 Configuring e-mail notification13.You will be prompted to format the e-mail notifications as shown in Figure 4-33 on page 122. Specify the following: E-mail subject line This is a subject line for the e-mail message. Violation message This is the text of the e-mail message that is sent when a service level agreement violation is detected. Trend message This is the text of the message that is sent when a trend toward a potential violation has been detected. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 121
  • 145. Trend canceled message This is the text of the message that is sent when a previously identified trend toward a violation no longer exists. Figure 4-33 Configuring e-mail notification - Part 2 Click Next to continue with the installation. 14.The confirmation dialogue window of the various ITSLA features that you intend to install appear as shown in Figure 4-34 on page 123. Click Next to start the installation.122 Introducing IBM Tivoli Service Level Advisor
  • 146. Figure 4-34 ITSLA Server installation confirmation window 15.The InstallShield Wizard window appears after a few minutes informing you as to whether the installation of ITSLA was successful. Click Finish to exit the wizard.4.5.5 ITSLA Task Drivers installation The IBM Tivoli Service Level Advisor Task Drivers must be installed on the same machine as the IBM Console. In order to have the ITSLA Tasks Drivers component installed, perform the following steps: 1. From the directory where the ITSLA CD-ROM is mounted, enter the following command to start the installation wizard: # ./install.sh 2. The InstallShield Wizard dialogue window for IBM Tivoli Service Level Advisor installation is the first window to appear. Click Next. 3. The dialogue window for the ITSLA Server installation directory appears. We used the default value /opt/TSLA. Click Next. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 123
  • 147. 4. The ITSLA installation options dialogue window appears, as shown in Figure 4-35. Uncheck the SLM Server and the SLM Reports options and make sure that only the IBM Tivoli Service Level Advisor 1.1 and SLM Task Drivers options are selected. Click Next. Figure 4-35 ITSLA Task Drivers component installation 5. The dialogue window for the ITSLA Database appears as shown in Figure 4-26 on page 115. In the dialogue window you are prompted to provide the information below. We kept all the default values. Database name Specifies the name of the ITSLA Database. Default value is dyk_cat. User ID The DB2 user information for remote access to the ITSLA Databases installed on the ITSLA Database Server machine. Default value is db2inst1. Password This is the sign-on password for the above user ID. DB Server host name This is the fully qualified host name of the machine that contains the ITSLA Database component.124 Introducing IBM Tivoli Service Level Advisor
  • 148. DB Server port number This is the communication port number or the service name of the server database manager instance that contains the ITSLA Database Server. Default value is 50000. Click Next to continue.6. The Installation proceeds by asking the fully qualified host name and communication port for the ITSLA Server machine. You should provide the values used during the installation of the ITSLA Server component, as shown in Figure 4-36. ITSLA Server host name The fully qualified host name of the machine on which the ITSLA Server is located. ITSLA Server communication port The default value of 9980. Click Next to continue.Figure 4-36 ITSLA Task Drivers communication ports7. The confirmation dialogue window appears as shown in Figure 4-37 on page 126. Click Next to start the installation. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 125
  • 149. Figure 4-37 ITSLA Task Drivers installation 8. A dialogue window appears after a few minutes informing you as to whether the installation of ITSLA Task Drivers was successful. It also informs you that the installation program will attempt to restart Tivoli Presentation Services. Click Next to continue. 9. The InstallShield Wizard window appears informing you that it has successfully installed ITSLA. Click Finish to exit the wizard. Do not restart your system right away. It may take some time for the Tivoli Presentation Services to come back up.4.6 Setting up the ITSLA Reports machine The ITSLA Reports machine will serve our environment by performing all the core functions for Service Level Management reporting. The ITSLA Reports machine will host the following components: IBM DB2 Universal Database Enterprise Edition Client Version 7.2 (Fixpack 5 included) for UNIX IBM WebSphere Application Server ITSLA Reports Server126 Introducing IBM Tivoli Service Level Advisor
  • 150. The installation of the IBM DB2 Universal Database Enterprise Edition Client Version 7.2 (Fixpack 5 included) for UNIX has already been discussed in 4.5.1, “IBM DB2 Client installation on AIX” on page 106. The installation of all the other components will be discussed in the following sections.4.6.1 IBM WebSphere installation and configuration The IBM WebSphere Application Server will provide the support environment for the Java-based servlets of the ITSLA Reports Server component. For our environment, we decided to use the IBM WebSphere Application Server AES 4.0.1, as it allows us to have an automated integration of the reports servlets. If you decide to use any other supported version of IBM WebSphere Application Server, the ITSLA Reports servlets must be integrated manually. Please refer to Getting Started with IBM Tivoli Service Level Advisor Version 1.1, SC32-0834, for instructions. In this section we describe the IBM WebSphere Application Server installation steps on AIX. In order to install IBM WebSphere Application Server AES 4.0.1, perform the following steps: 1. Logged in as a user with root authority, issue the following command from the directory where the IBM WebSphere Application Server CD-ROM is mounted: # ./install.sh. 2. You are then prompted to select the type of installation. We have selected Typical Installation, as 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. On the following screen you need to specify the installation directories. We used the default values /usr/WebSphere/AppServer and /usr/HTTPServer. 4. A final installation window informs you that the setup program has finished. 5. When the installation of WebSphere completes successfully, the screen, shown in Figure 4-38 on page 128 appears. Select Start the Application Server. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 127
  • 151. Figure 4-38 IBM WebSphere Application Server configuration panel 6. Open a Web Browser and type in the following URL: http://WebSphere_Server:9090/admin Where WebSphere_Server can either be the WebSphere server’s host name or IP address. 7. On the Administrator Console window, shown in Figure 4-39 on page 129, expand Resources -> JDBC Drivers -> Db2JdbcDriver. Click Db2JdbcDriver. Update the Server Class Path with the fully qualified path of the DB2 file db2java.zip. The path is the same specified during the JDBC code level upgrade described in 4.5.1, “IBM DB2 Client installation on AIX” on page 106. Click Save.128 Introducing IBM Tivoli Service Level Advisor
  • 152. Figure 4-39 IBM WebSphere configuration 8. 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. 9. The IBM WebSphere Application Server runs as root and requires access to the IBM DB2 environment. You should insert the following at the end of root’s .profile file: ./home/db2inst1/sqllib/db2profile Assuming that the db2inst1 is the IBM DB2 instance owner. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 129
  • 153. 4.6.2 ITSLA Reports Server installation The IBM Tivoli Service Level Advisor Reports Server components must be installed on the same machine as the IBM WebSphere. In order to have the ITSLA Reports Server component installed, perform the following steps: 1. From the directory where the ITSLA CD-ROM is mounted, enter the following command to start the installation wizard: # ./install.sh 2. The InstallShield Wizard dialogue window for IBM Tivoli Service Level Advisor installation is the first window to appear. Click Next. 3. The dialogue window for the ITSLA Server installation directory appears. We used the default value /opt/TSLA. Click Next. 4. The ITSLA installation options dialogue window appears as shown in Figure 4-40. Uncheck the SLM Server and the SLM Task Drivers options and make sure that only the IBM Tivoli Service Level Advisor 1.1 and SLM Reports options are selected. Click Next. Figure 4-40 ITSLA Reports component installation 5. The dialogue window for specifying the installation directory location of the IBM WebSphere Application Server appears. As described in the previous section, we used the provided default value /usr/WebSphere/AppServer. Click Next to continue.130 Introducing IBM Tivoli Service Level Advisor
  • 154. 6. The dialogue window for specifying the IBM WebSphere Application Server node name appears, as shown in Figure 4-41. You need to specify the name that the IBM WebSphere Application Server assigned to the node that identifies the machine on which WebSphere is running. Note: This name is not necessarily your machine host name. It might be either the short name or the fully qualified name for the machine that was assigned during the WebSphere installation. Be sure to look this name up and do not assume it is your machine host name. Note also that this node name is case-sensitive.Figure 4-41 Specify a node name for you ITSLA Report Server7. The dialogue window for the ITSLA Database appears as shown in Figure 4-26 on page 115. In the dialogue window you are prompted to provide the information below. We kept all the default values. Database name Specifies the name of the ITSLA Database. Default value is dyk_cat. User ID The DB2 user information for remote access to the ITSLA Databases installed on the ITSLA Database Server machine. Default value is db2inst1. Chapter 4. Getting IBM Tivoli Service Level Advisor up and running 131
  • 155. Password This is the sign-on password for the above user ID. DB Server host name This is the fully qualified host name of the machine that contains the ITSLA Database component. DB Server port number This is the communication port number or the service name of the server database manager instance that contains the ITSLA Database component. Default value is 50000. Click Next to continue. 8. The confirmation dialogue window of the various ITSLA features that you intend to install appears as shown in Figure 4-42. Click Next to start the installation. Figure 4-42 ITSLA Report Server installation 9. The InstallShield Wizard window appears after a few minutes informing you as to whether the installation of ITSLA was successful. Click Finish to exit the wizard.132 Introducing IBM Tivoli Service Level Advisor
  • 156. 5 Chapter 5. Administering IBM Tivoli Service Level Advisor This chapter provides an overview of the administrative tasks to be performed in order to manage the IBM Tivoli Service Level Advisor environment. The following topics are discussed: Source ETLs management Target ETLs management User creation and management Management of ITSLA components Timing considerations for the ITSLA environment Trace and message log files Startup and shutdown procedures Backup and restore of ITSLA© Copyright IBM Corp. 2002 133
  • 157. 5.1 Source ETLs management The Source ETL process is required by the Tivoli Enterprise Data Warehouse for applications wanting to make their data available in the TEDW Central Warehouse database. The entire Source ETL process comprises the extraction of application data from the local application source tables, the transformation of such data through various calculations, and the storage of the resulting data into the TEDW Central Warehouse database target tables. The ITSLA administrator is responsible for running the Source ETL process through the DB2 Warehouse Center Interface. Source ETLs management is made up of three main activities: Verifying the correct configuration of ETL Warehouse Targets and Sources Scheduling and running the ETL Notifying of the ETL result The next sections will provide information on how to correctly configure the ETLs, describe how to schedule and run the ETLs, and how to be notified of the ETLs results.5.1.1 ETL Warehouse Target and Sources configuration Before running the ETL processes, you must make sure that the Warehouse Sources and the Warehouse Targets specific to the Tivoli application are correctly defined (user name, password, host name, system data source). The Warehouse Sources, Warehouse Targets, and each related Tivoli source application that are ITSLA-enabled are shown in Table 5-1.Table 5-1 IBM Tivoli source application and Warehouse Source and Targets Tivoli application Warehouse sources Warehouse targets name name IBM Tivoli Monitoring for Transaction APF_TAPM_Source APF_TWH_CDW_Target Performance (TAPM) IBM Tivoli Business Systems Manager GTM_OBJECT_Source GTM_TWH_CDW_Target IBM Tivoli Monitoring for Transaction BWM_TWSM_Source BWM_TWH_CDW_Target Performance (TWSM) IBM Tivoli Monitoring DMN_RIM_Source DMN_TWH_CDW_Target IBM Tivoli Enterprise Console ECO_TEC_Source ECO_TWH_CDW_Target134 Introducing IBM Tivoli Service Level Advisor
  • 158. The ETL Warehouse Sources configuration To define the Warehouse Sources, open the DB2 Warehouse Center from the Tools menu, expand the Warehouse Sources folder, right click each Warehouse Source shown in Table 5-1 on page 134 and select Properties. In the Properties window select the Data Source tab. Figure 5-1 shows an example of the configuration for the TAPM Warehouse Source. Verify that the following parameters are correct: Data source name (the database name of where the Tivoli application stores its data) System name (the host name of the database where the data resides) User ID and password (used to access the database where the Tivoli application stores its data)Figure 5-1 Properties window of Warehouse Sources Chapter 5. Administering IBM Tivoli Service Level Advisor 135
  • 159. In addition to that, you must also do the following for the Warehouse Sources: 1. From the Data Warehouse Center window, expand the Warehouse Sources folder and then the item related to the Tivoli Application you have chosen (i.e: for the TAPM, the item is APF_TAPM_Source). 2. Click the Tables folder. The tables in the warehouse source are displayed on the right-hand side of the window. 3. If the Schema property is empty and the Name of the tables include the schema name, right click each table and select Properties. The Properties window opens. 4. On the Source Table page, modify the Table Schema and Table name properties with the values of the Tivoli Application database source. (This depends on how you created the Tivoli Application database. Refer to the Tivoli Application related documentation for further details). For the IBM Tivoli Monitoring for Transaction Performance (TAPM) application, the table name should be the table name without the word “TAPM” to prevent problems when exporting the metadata to an ETL interchange file (*.tag), which can be imported into another Data Warehouse Center. Important: The source application database must exist and be cataloged as an ODBC System DSN in order to correctly configure the Data Source parameters in the Properties window (Figure 5-1 on page 135). See Introduction to Tivoli Enterprise Data Warehouse, SG24-6607, for information about configuring ODBC connections for source application databases. The ETL Warehouse Targets configuration To ensure the correct definition of the Warehouse Targets do the following: 1. Open the DB2 Data Warehouse Center from the Tools menu, and expand the Warehouse Targets folder. 2. Right click each Warehouse Target, as shown in Table 5-1 on page 134, and select Properties. 3. From the Properties window, select the Database tab and verify that the following parameters are correct: – Database name (the name of the Central Data Warehouse) – System name (the name of the DB2 system that hosts the TEDW Central Warehouse) – User ID and password (the parameters used to access the TEDW Central Warehouse) Figure 5-2 on page 137 displays the Warehouse Target table screen.136 Introducing IBM Tivoli Service Level Advisor
  • 160. Figure 5-2 Tables of Warehouse Targets5.1.2 Schedule and run Source ETL This section describes the SQL processes that compose a Source ETL for the Tivoli applications and how to schedule and run a Source ETL process using the IBM Tivoli Monitoring for Transaction Performance (TAPM) as an example. The basic steps described here for TAPM are valid for all other Tivoli source applications, whether differently specified or not. A Source ETL is responsible for transferring data from the source application database to the TEDW Central Warehouse Target tables. Different SQL processes exist for each Tivoli source application that implements the Source ETL functionality. To locate these SQL processes, open the DB2 Data Warehouse Center, and expand the Subject Areas folder on the left side of the window. The mapping between the Subject Areas items and the Tivoli source Chapter 5. Administering IBM Tivoli Service Level Advisor 137
  • 161. applications is shown in Table 5-2. Expanding any of the Subject Areas will reveal a Processes folder containing the SQL processes for implementing the Source ETL process. Each SQL Process is made up of different steps, which you can see by expanding the process item.Table 5-2 Subject Areas and related Tivoli applications Subject Area Tivoli application APF_TivoliApplicationPerformanceManagement_v1.1.0_ IBM Tivoli Monitoring for Transaction Subject_Area Performance (TAPM Version 2.1) BWM_TivoliWebServicesManager_v1.7.0_Subject_Area IBM Tivoli Monitoring for Transaction Performance (TWSM Version 1.7) DMN_ApplicationEnablement_v3.7.0_Subject_Area IBM Tivoli Monitoring (Classic Edition Version 3.7) ECO_Tivoli_Enterprise_Console_v3.7.1_Subject_Area IBM Tivoli Enterprise Console Version 3.7.1 GTM_Tivoli_Business IBM Tivoli Business Systems Manager _System_Manager_v1.5_Subject_Area Version 1.5 In order to schedule and run the ETL Source Processes for IBM Tivoli Monitoring for Transaction Performance (TAPM), perform the following steps: 1. From the Data Warehouse Center window, expand the Subject Areas folder. 2. Expand the item related to the Tivoli source application TAPM, that is APF_TivoliApplicationPerformanceManagement_v1.1.0_Subject_Area. 3. Expand the Processes item, as shown in Figure 5-3 on page 139.138 Introducing IBM Tivoli Service Level Advisor
  • 162. Figure 5-3 Processes folder of TAPM Subject Areas 4. Inside the Processes folder there are two different processes: – APF_c05_Initialize_Process This is an initialization process that has one step: APF_c05_s010_init. The APF_c05_s010_init step resets the values of the Tivoli Enterprise Data Warehouse Extract_Control and Prune_Msmt_Control tables, which are used respectively to incrementally extract the ETL processes and to remove old data from the MSMT table by a warehouse process. After you run this step, all TAPM-related data will be loaded in the TEDW Central Warehouse database through the APF_c10_CDW_Process process. Therefore, it should be run only once. Chapter 5. Administering IBM Tivoli Service Level Advisor 139
  • 163. – APF_c10_CDW_Process This process is made up of five steps that load the TAPM data first from the RIM database into the Tivoli Enterprise Data Warehouse staging tables and then inside the TEDW Central Warehouse database. This process populates the component, component attribute, and measurement tables. It should be run on a periodical basis (daily, weekly, or monthly, depending on the amount of data to transfer). 5. To schedule APF_c05_Initialize_Process, right click it and select Schedule. Schedule it to run only once, and click Add>. Then click Notification and configure how to be notified of the process result. Click OK to finish the schedule. 6. In order for the schedule to be accepted, the APF_c05_Initialize_Process process must be changing from Development mode to Production mode. To set the APF_c05_s010_init step to Production mode, right click it and select Mode -> Production. 7. To schedule APF_c10_CDW_Process, right click it and select Schedule. Define the schedule you desire, and click Add>. Then click Notification and configure how to be notified of the process result. Click OK to finish the schedule. 8. To set the APF_c10_CDW_Process steps, select all the steps by holding the CTRL key, right clicking the selection, and selecting Mode -> Production, as shown in Figure 5-4 on page 141. Important: If you want to modify the ETL scheduling, you must set the SQL steps to the Development or Test mode. If the SQL steps are in Production mode, you will not be able to modify the schedule settings. Additionally, if there is a need to change an existing ETL schedule, it will be quicker for you to change from Production mode to Test mode, instead of going back to Development.140 Introducing IBM Tivoli Service Level Advisor
  • 164. Figure 5-4 Set to Production mode TAPM Source ETL steps Note: This section describes how to schedule the processes for TAPM. Inside the IBM Tivoli Business Systems Manager ETL Processes folder, there is only one process: GTM_co5_LOBState_Process. This process is responsible for both the initialization and the load process. To schedule this process, right click it and select Schedule. Define the schedule in the Schedule window and click OK. The Source ETL processes will run according to the given schedule. The time needed to perform the Source ETL process depends on the network bandwidth, the power of the machine involved hosting both the TEDW Central Warehouse and the Tivoli source applications databases, the Tivoli application load during Chapter 5. Administering IBM Tivoli Service Level Advisor 141
  • 165. the Source ETL process, and the amount of data to be transferred. Remember that the Source ETL processes must complete their processing before the Target ETLs are run, in order to populate the ITSLA Databases with the latest available data.5.2 Target ETLs management Target ETLs are responsible for transferring data from the TEDW Central Warehouse database to the ITSLA local databases by extracting, transforming, and loading the data. This data includes data measurements from source applications, along with information regarding the various types of data that are available for use in defining and creating SLAs. As explained in 2.5, “IBM Tivoli Service Level Advisor Target ETLs” on page 37, these Target ETLs are referred to as the Process Target ETL and the Registration Target ETL.5.2.1 Registration Target ETL management The Registration Target ETL is in charge of moving the measurement data type, component name, and attribute information of the Tivoli source application from the TEDW Central Warehouse database to the ITSLA Database (DYK_CAT). The Registration Target ETL is typically run when it is first installed to populate the ITSLA Database with measurement types already present in the TEDW Central Warehouse database, and any time new measurement types are added to the TEDW Central Warehouse database. Registration Target ETL management consists of the following: Source application data collection enablement Scheduling and running the Registration ETL Notification on the results of the Registration ETL processes The next sections provide information on how to perform these activities. Source application data collection enablement You can define which source applications can move their data from the TEDW Central Warehouse database to the ITSLA Database through a set of CLI commands. IBM Tivoli Service Level Advisor initially comes with no source applications enabled; therefore, you must define these enabled applications before the Registration Target ETL is run.142 Introducing IBM Tivoli Service Level Advisor
  • 166. In order to list the available source applications and to see if they are enabled fordata collection, perform the following steps: Source the ITSLA environment, dependent on your operating system: – For Windows, run the slmenv.bat file from the ITSLA installation directory. – For UNIX, execute . ./slmenv.sh from the ITSLA installation directory. Run the following command from an ITSLA command line on the ITSLA Server: scmd etl getAppsYou will obtain an output similar to that found in Example 5-1.Example 5-1 scmd etl getApps command output# scmd etl getAppsMeasurement Source Code: BWMApplication Name: Tivoli Web Services ManagerFlag: YMeasurement Source Code: APFApplication Name: Tivoli Application Performance ManagementFlag: YMeasurement Source Code: DMNApplication Name: Distributed Monitoring Classic EditionFlag: YMeasurement Source Code: GTMApplication Name: Tivoli Business System ManagerFlag: YMeasurement Source Code: ECOApplication Name: Tivoli Enterprise ConsoleFlag: N#If you have developed your own Source ETL for use with a third-party applicationand do not see your application listed in the command output (Example 5-1), youmust run the following command so that data can be transferred from the TEDWCentral Warehouse database:scmd etl addApplicationData Source_Code “Application_Name” Chapter 5. Administering IBM Tivoli Service Level Advisor 143
  • 167. There are five Tivoli source applications that come already defined in the ITSLA Database. If you want to enable a source application that has already been defined, type the following command: scmd etl enable Measurement Source Code The Measurement Source Code is a three letter designation, which for the Tivoli source applications, can be found with the scmd etl getApps command output. By default all source applications are disabled. If you want to disable a source application that you mistakenly enabled or no longer need, issue the following command: scmd etl disable Measurement Source Code Important: You cannot disable a source application if data for that application is currently being used in a defined customer offering or order. In order to list which offerings and orders are associated with the source application in question, issue the scmd etl disable Source_Code list command. More detailed information on scmd commands can be found either in the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833, or in the Appendix D, “Command reference” on page 409. Note: The information for which source applications must be included in the Registration ETL process is written inside the Extract_Filter table in the ITSLA Database. The Registration ETL uses this table to define which source applications to include. Scheduling and running the Registration Target ETL The Registration Target ETL extracts data from the TEDW Central Warehouse database, transforms these records to a format suitable for IBM Tivoli Service Level Advisor, and loads the data into the ITSLA Database (DYK_CAT). It must run prior to the Process Target ETL, due to the fact that the Process Target ETL reads data from inside the ITSLA Database to decide which types of measurement data are needed. Being the Registration Target ETL responsible for placing this information inside the ITSLA Database, running the Process Target ETL before the Registration Target ETL will result in a loss of data or updated information not to be inserted. The Registration Target ETL needs to be scheduled daily, in order to insert any new measurement data collected by the Tivoli source applications into the ITSLA Database. To schedule the Registration ETL do the following steps: 1. From the DB2 Warehouse Center window, expand the Subject Areas folder.144 Introducing IBM Tivoli Service Level Advisor
  • 168. 2. Expand DYK_IBMTivoliServiceLevelAdvisor_v1.1.0_Subject_Area and the Processes folder. 3. Right click the DYK_m05_Populate_Registration_Datamart_Process process and select Schedule, as shown in Figure 5-5.Figure 5-5 Select schedule for Registration ETL 4. The Schedule window is shown in Figure 5-6 on page 146. Configure the Interval, Frequency, Day, Start Date and Time, End Date and Time parameters, and click Add. Chapter 5. Administering IBM Tivoli Service Level Advisor 145
  • 169. Figure 5-6 Registration ETL Schedule window 5. Click OK to accept the Registration ETL schedule. 6. The process steps are located on the right-hand side of the Data Warehouse Center window. They are in the form *_snnn_*, where nnn is the step number. Holding the CTRL key, select all the steps, right click the selected items, and choose Mode -> Production. This will set the ETL into production mode, enabling the schedule you just created. Now that the Registration ETL is scheduled, you can decide to either wait for the process to start at the scheduled time, or to run the Registration Target ETL immediately by performing the following steps: 1. From the Data Warehouse Center window, select Warehouse -> Work in Progress, as shown in Figure 5-7 on page 147.146 Introducing IBM Tivoli Service Level Advisor
  • 170. Figure 5-7 Work in Progress selection 2. Find the first step of the Registration Target ETL scheduled to run. The first step of the Registration ETL is labeled DYK_m05_s010_Populate_Stage_Data, and its Status column value must be Scheduled. Right click it and select Run now, as shown in Figure 5-8 on page 148. Chapter 5. Administering IBM Tivoli Service Level Advisor 147
  • 171. Figure 5-8 Immediately run the first step of the Registration ETL 3. The Work in Progress window shows the ETL steps status. 4. Wait for the ETL steps to complete successfully. If one of the steps fails, right click it and then select Show Log, as shown in Figure 5-9 on page 149.148 Introducing IBM Tivoli Service Level Advisor
  • 172. Figure 5-9 See log information for failed ETL Registration step 5. Examine the log details message window. Refer to 8.6.3, “Administration issues” on page 343, for guidance on how to determine the problem. Registration ETL results notification setup To be notified of the Registration ETL result, perform the following steps: 1. From the DB2 Warehouse Center window, expand the Subject Areas folder. 2. Expand DYK_IBMTivoliServiceLevelAdvisor_v1.1.0_Subject_Area and the Processes folder. 3. Right click the DYK_m05_Populate_Registration_Datamart_Process process and select Notification. The Notification window opens, as shown in Figure 5-10 on page 150. Chapter 5. Administering IBM Tivoli Service Level Advisor 149
  • 173. Figure 5-10 Configuration of Notification for the Registration ETL 4. Choose which Registration Target ETL result you would like to be notified for (success, failure, and/or completion), the users to notify, the Mail server to use, and the content of the e-mail. 5. Click OK to complete the Notification task.5.2.2 Process Target ETL management The Process Target ETL is in charge of moving measurement data from the TEDW Central Warehouse database into the ITSLA Measurement Data Mart database (DYK_DM). The Process Target ETL also reads from the ITSLA Database the measurement type data to insert in the ITSLA Measurement Data Mart database. The Process Target ETL implements an incremental extract feature, transferring only the latest data that was inserted since the last time the Process Target ETL was run. The Process Target ETL should run only after all enabled Source Application ETLs have inserted their data inside the TEDW150 Introducing IBM Tivoli Service Level Advisor
  • 174. Central Warehouse database and after the initial run of the Registration TargetETL. More considerations regarding the scheduling of the Process Target ETLare discussed in 5.5, “Timing considerations for the ITSLA environment” onpage 193.Process Target ETL management consists of the following: Scheduling and running the Process Target ETL Notification of the Process Target ETL results Expiration of measurement data managementScheduling and running the Process Target ETLsThe Process Target ETL is in charge of moving data from the TEDW CentralWarehouse database (TWH_CDW) to the ITSLA Data Mart database (DYK_DM).The data stored in the ITSLA Measurement Data Mart database is used toperform the SLA evaluation. In order to have a consistent and reliable SLAevaluation, the Process Target ETL must run daily for the latest availableinformation to be inserted in the ITSLA Database. Being that the SLA evaluationfrequency for IBM Tivoli Service Level Advisor has a minimum value of one perday, the Process Target ETL must run at least once a day in order to provide thedata for the evaluation process. It must run after the completion of theRegistration Target ETL in order to extract relevant source application informationfrom the ITSLA Database to insert to the ITSLA Measurement Data Martdatabase.In order to schedule the Process Target ETL, perform the following steps:1. From the DB2 Warehouse Center window, expand the Subject Areas folder.2. Expand DYK_IBMTivoliServiceLevelAdvisor_v1.1.0_Subject_Area and the Processes folder.3. Right click the DYK_m10_Populate_Measurement_Datamart_Process process and select Schedule, as shown in Figure 5-11 on page 152. Chapter 5. Administering IBM Tivoli Service Level Advisor 151
  • 175. Figure 5-11 Select Schedule for Process ETL 4. The Schedule Window is shown in Figure 5-12 on page 153. Configure the Interval, Frequency, Day, Start Date and Time, End Date and Time parameters, and click Add.152 Introducing IBM Tivoli Service Level Advisor
  • 176. Figure 5-12 Define Schedule for Process ETL 5. Click OK to accept the Registration ETL schedule. 6. The process steps are located on the right-hand side of the Data Warehouse Center window. They are in the form *_snnn_*, where nnn is the step number. Holding the CTRL key, select all steps, right click the selected items, and choose Mode -> Production. Now that the Process ETL is scheduled, you can decide to either wait for the process starting at the scheduled time, or you can run the Process ETL immediately by performing the following steps: 1. From the Data Warehouse Center window, select Warehouse -> Work in Progress, as shown in Figure 5-13 on page 154. Chapter 5. Administering IBM Tivoli Service Level Advisor 153
  • 177. Figure 5-13 Start Work in Progress tool 2. Find the first step of the Process Target ETL scheduled to run. The first step of the Process Target ETL is labeled DYK_m10_s010_Populate_SLM_Msmt_Staging, and its Status column value must show Scheduled. Right click it and select Run now, as shown in Figure 5-14 on page 155.154 Introducing IBM Tivoli Service Level Advisor
  • 178. Figure 5-14 Manually run the first step of the Process Target ETL 3. The Work in Progress window shows the ETL step status. 4. Wait for the ETL to complete successfully. If one of the steps fails, right click it and select Show Log. 5. Examine the log details message window. Refer to 8.6.3, “Administration issues” on page 343, for guidance on how to determine the problem. Process ETL results notification setup In order to be notified of the Process ETL result, perform the following steps: 1. From the DB2 Warehouse Center window, expand the Subject Areas folder. 2. Expand DYK_IBMTivoliServiceLevelAdvisor_v1.1.0_Subject_Area and the Processes folder. Chapter 5. Administering IBM Tivoli Service Level Advisor 155
  • 179. 3. Right click the DYK_m10_Populate_Measurement_Datamart_Process process and select Notification. The Notification window opens, as shown in Figure 5-15.Figure 5-15 Start Notification dialogue for Process ETL 4. Choose which Process Target ETL result you would like to be notified for (Success, Failure, Completion), the users to notify, the mail server to use, and the content of the e-mail. 5. Click OK to complete the Notification task.156 Introducing IBM Tivoli Service Level Advisor
  • 180. Expiration of measurement data management IBM Tivoli Service Level Advisor analyzes availability and performance measurement data stored in the ITSLA Measurement Data Mart database. The ITSLA Measurement Data Mart database can grow very quickly, depending on the amount of data your applications capture and insert into the TEDW Central Warehouse database. Data inside the ITSLA Measurement Data Mart is initially set to be deleted after a default expiration interval of 63 days. This time interval is customizable through CLI commands. In order to customize the expiration time interval, perform the following steps: 1. Open a command prompt interface (or a shell window) on the ITSLA Server machine. 2. Type in the following command to obtain the set expiration time interval: scmd etl getDataExpiration The output of this command is shown in Example 5-2. Example 5-2 scmd etl getDataExpiration command output # scmd etl getDataExpiration The data is set to expire every 63 days # 3. To change the time interval expiration data to 30 days, type the following command: scmd etl setData Expiration 30 More detailed information on scmd commands can be found either in the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833, or Appendix D, “Command reference” on page 409.5.3 User creation and management In the IBM Tivoli Service Level Advisor solution, there are two different types of users who can be managed by the ITSLA administrator as follows: IBM SLA Console users are responsible at different levels to define and manage the service level agreements in the company. Chapter 5. Administering IBM Tivoli Service Level Advisor 157
  • 181. Through the IBM Web Console, depending on their authorization level, they may perform one or more of the following tasks: – Manage schedules – Manage offerings – Manage customers – Manage orders – Manage realms IBM SLA Report users have access to IBM SLA reports, which can be accessed through a supported Web browser. They can be created and customized through a set of CLI commands executed on the ITSLA Server. They have no access to the IBM Console and cannot perform any of the administration tasks used by the IBM ITSLA Console users. In the following sections, information on how to manage IBM SLA Console users and SLA Report users is provided.5.3.1 IBM SLA Console user management The ITSLA administrator is in charge of creating, defining, and customizing the users depending on their responsibilities in managing the service levels of the company. IBM Tivoli Service Level Advisor uses the same role-based concept for access control to administer its security features as the Tivoli Enterprise Data Warehouse product. For more information on the concept of a role-based security policy, refer to Introduction to Tivoli Enterprise Data Warehouse, SG24-6607. During the installation process, IBM Tivoli Service Level Advisor creates the following predefined portfolio roles in the IBM Console: SLA administrator Grants the user access to all tasks related to managing and creating offerings, orders, schedules, customers, and realms. Further, the SLA administrator can perform administrative tasks, such as the back up and restore of product code and measurement data, and logging and tracing functions. Service ordering specialist Creates service offerings and associated schedules, making them available for customer orders. Customer order specialist Able to create and manage customers and realms and can associate customers with defined service offerings.158 Introducing IBM Tivoli Service Level Advisor
  • 182. Mapping between the SLA predefined roles and SLA tasks is indicated inTable 5-3.Table 5-3 IBM SLA roles and associated tasks on the IBM Web Console IBM SLA role Task group and associated tasks Service offering specialist Administer service offering. Manage schedules. Manage offerings. Customer order specialist Administer customer orders. Manage realms. Manage customers. Manage orders. SLA administrator Administer SLM. Manage schedules. Manage offerings. Manage realms. Manage customers. Manage orders. Administer users and roles. Work with Reports.ITSLA user creation and customizationThe creation and customization of ITSLA users is achieved through the IBM WebConsole. In the following steps we show how to create a user with the serviceoffering specialist role in our environment. Note: There are two different versions of the IBM Console included with IBM Tivoli Service Level Advisor. The icon located on the desktop labeled IBM Console is Java-based and is used primarily for turning the tracing function on and off and viewing the message logs. The Web-based IBM Console should be used for all administrative purposes, such as what is covered in the following sections.1. Open a supported Web browser and enter the following URL: http://hostname:port/IBMConsole Where hostname is the machine where Web Services for IBM Console Server is running and port is the appropriately assigned port.2. Log on as the superadmin user, where the default password is password. The superadmin user has full access to all resources and is granted all roles.3. The IBM Web Console is shown in Figure 5-16 on page 160. Chapter 5. Administering IBM Tivoli Service Level Advisor 159
  • 183. Figure 5-16 IBM Web Console 4. On the left side of the console, you will find the task groups available to the user. You can perform any task inside the task groups, since the superadmin user has been used to log in with. 5. Click the Administer Users and Roles task group to expand it, and then click the Create a User task. On the right side of the window, the Create a user dialogue window opens in the General window, as shown in Figure 5-17 on page 161.160 Introducing IBM Tivoli Service Level Advisor
  • 184. Figure 5-17 User creation task in the General window 6. Enter the values your prefer in the designated fields. For our example, the user name will be set to Michael and password to default. 7. Click the Roles tab to define the level of authorization to give to the user. 8. The IBM Console User role is assigned by default and is necessary to access the IBM Console. For our example, the service offering specialist role was also assigned to the user, as shown in Figure 5-18 on page 162. Note: The Primary role defines only which banner and welcome page are shown on the IBM Console for that user. Chapter 5. Administering IBM Tivoli Service Level Advisor 161
  • 185. Figure 5-18 Service offering specialist role selection 9. Click OK to create the user. 10.Now sign off the IBM Web Console and log on as user Michael, password default. 11.The IBM Web Console is shown in Figure 5-19 on page 163. As depicted, the user Michael has access only to the Administer Service Offering task group and can perform the Manage Schedules and Manage Offerings tasks.162 Introducing IBM Tivoli Service Level Advisor
  • 186. Figure 5-19 IBM Console starting page for service offering specialist user The mapping between the ITSLA predefined roles, task groups, and tasks are shown in Table 5-3 on page 159.5.3.2 ITSLA Report users management After the ITSLA Server evaluates the violations and trends of measurement data against the defined service levels agreements, the evaluation results are aggregated into reports that can be accessed through a supported Web browser. Chapter 6, “Service level Reports with ITSLA” on page 217, provides a great deal of information on ITSLA reports. Depending on the assigned authentication level, an ITSLA user can be provided with very broad or very limited access to report data. Chapter 5. Administering IBM Tivoli Service Level Advisor 163
  • 187. The level of authentication assigned to the user depends on the four different variables defined below: Consumer Also known as a customer, the ITSLA user can be associated with a consumer and will only be able to see the reports for that specific consumer. Realm A realm is a group of customers, as defined in 5.4.2, “Management of orders” on page 179. The Web Report user can view only reports regarding these groups of customers. Portal page The initial Web page that the user views after a successful login to the reports server. There are three possible values: executive.jsp, customer.jsp, and operations.jsp. These values are Web portal pages located on the ITSLA Reports Server. View This variable sets the authorization level of the users and can assume three different values (1, 2, and 3). The values and their associated authorization levels are described in Table 5-4. Table 5-4 View values and authorization levels for Report users View value Authorization level 1 Unrestricted: A user can see reports for any customer or realm. 2 Restricted: A user can access reports of a specific customer or a specific realm, or both. 3 External: A user can access reports of a specific customer or a specific realm, or both. However, a user cannot view data marked for internal use only. For more information regarding a Report users authorization level, refer to 6.3.1, “Creating Reports users” on page 237. The installation creates three default user IDs with the view value set to unrestricted, as follows: Executive This user accesses reports starting from the executive.jsp portal page, which displays the Customer Ranking view. Default user password is password. Customer This user accesses reports starting from the customer.jsp portal page, which displays the Customer Order Ranking view. Default user password is password.164 Introducing IBM Tivoli Service Level Advisor
  • 188. Operations This user accesses reports starting from the operations.jsp portal page, which displays the Offering Component Ranking view. Default user password is password. ITSLA Report user creation The following steps define the process to create a new ITSLA Reports user: 1. On the ITSLA Server machine, open a command prompt (or shell window) and source the ITSLA environment by running the slmenv script from the ITSLA installation directory. 2. Type the following command to list the current users of ITSLA Reports: scmd sla listUser The output of the command is shown in Example 5-3.Example 5-3 scmd sla listUser command output# scmd sla listUsername view consumer realm page--------------------------------------------------------------------------------------------customer unrestricted customer.jsp?fsd=mtdexecutive unrestricted executive.jsp?fsd=mtdoperations unrestricted operations.jsp?fsd=r7d# 3. For our example, a user will be defined with an ID of Sawyer, a password of Jack, and data access for only the MyCompany consumer and realm Test. The user is created with the following command: scmd sla AddUser -name Sawyer -password Jack -view 2 -consumer MyCompany -realm Test -page customer.jsp The output of the command is shown in Example 5-4.Example 5-4 scmd sla AddUser command output# scmd sla AddUser -name Sawyer -password Jack -view 2 -consumer MyCompany -realm Test -pagecustomer.jspDYKSL0017I A user was added successfully. Authority=2:restricted user, userID=Sawyer,password=Jack consumer=MyCompany, realm=Test, page=customer.jsp# 4. Logging in to the ITSLA Report server as user Sawyer will display a screen like that shown in Figure 5-20 on page 166. Chapter 5. Administering IBM Tivoli Service Level Advisor 165
  • 189. Figure 5-20 Log in with user Sawyer to ITSLA Reports Table 5-5 contains a list of commands used to manage the ITSLA Report users. For further information refer to Appendix D, “Command reference” on page 409, or the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833. Table 5-5 User manipulation commands Web Report user command Description scmd sla listUser Lists the users and their characteristics. scmd sla addUser Creates a new user able to access reports when logging in to the ITSLA Reports Server. scmd sla changeUser Changes the permissions of a user scmd sla deleteUser Deletes a user.166 Introducing IBM Tivoli Service Level Advisor
  • 190. 5.4 Management of ITSLA components In this section we will describe how to create and manage the ITSLA elements that form a service level agreement contract. The IBM Tivoli Service Level Advisor elements that comprise a service level agreement contract are offerings, schedules, orders, customers, and realms. These elements’ definitions and relation to the ITSLA environment have already been covered in 2.3, “Important ITSLA concepts and terminology” on page 26. In this section, information regarding the creation, configuration, and customization of the ITSLA elements through the IBM Console is discussed.5.4.1 Management of offerings An offering is a template used to outline one or more services that are part of a defined service level agreement. Offerings must be associated with a business schedule that define when and how in the business timeline the service level objectives are evaluated. The following steps describe how to create an offering through the IBM Web Console. 1. Log on to the IBM Web Console as a user with the service offering specialist role or SLM Administrator role (for information on the ITSLA user roles, see 5.3.1, “IBM SLA Console user management” on page 158). For our example, the superadmin user is used. 2. After the IBM Web Console opens, select the Task Group Administer Service Offerings to view the available tasks, and click the Manage Offerings task. The Manage Offering window is shown in Figure 5-21 on page 168. 3. Click the Create button. 4. Insert the offering name, a description of the offering, and the SLA type related to the offering. There are three SLA types available for use: External Refers to service levels provided to your end users by the service provider. Reports for the service level evaluation results can be accessed by the end users. Internal Refers to internal service levels in your company that cannot be accessed by external end users. Outsourced Refers to the user of a service and the service provider. In the event that the service provider is a customer who is using ITSLA, and whose SLA services are being monitored by another provider, no evaluation or monitoring of metric values by ITSLA will result for the customer. Chapter 5. Administering IBM Tivoli Service Level Advisor 167
  • 191. Select the SLA type you prefer and click Next. For our example, the External SLA Type was selected.Figure 5-21 Manage Offerings window 5. The Select Schedule window opens. Use an existing schedule by clicking the related radio button, or create a new schedule by clicking Create Schedule. 6. After the Create Schedule window opens, as shown in Figure 5-22 on page 169, insert a schedule name and decide on the period you would like to assign to the schedule. As the period table is initially empty, create a new period by clicking Create Period. Note: A schedule is made up of periods that divide the timeline into specific intervals, with all periods having a specific state (critical, prime, standard, off-hours, no impact, or no-service). Each period defines the importance of the time frame for the metrics evaluation. For instance, the no-service state is usually defined for a maintenance period or any other period when you do not want metric evaluations to take place.168 Introducing IBM Tivoli Service Level Advisor
  • 192. Figure 5-22 Create Schedule window 7. The Create Period window is displayed, as shown in Figure 5-23 on page 170. Chapter 5. Administering IBM Tivoli Service Level Advisor 169
  • 193. Figure 5-23 Create Period window Insert the following parameters: a. Select the desired period state. There are seven available period states, each described below: Critical Indicates a time interval during which there is a very high usage of the business application. Service level objective (SLO) values may need to be set higher than usual during this time period. Peak Indicates a time interval during which the provided service level is of high importance. The SLO values may be set to a higher than usual value, but lower than the Critical period value.170 Introducing IBM Tivoli Service Level Advisor
  • 194. Prime During this time interval, the business application performance is important, but is not as critical as the previously defined states. Consider setting the SLO values to a value slightly higher than what would be considered normal for the respective business application. Standard Denotes a time interval during which the business application must provide an acceptable level of service. The values for each SLO may represent a normal setting for the business application. Low-impact Indicates a time interval during which there is a low usage of the particular business application. Service Level Objective values may be set to a lower than normal value during this period. Off-hours During this time period, the business application will not experience much usage, therefore setting the Service Level Objectives to a very low value is acceptable. No-service Maintenance periods are usually placed within this time period. During this interval, ITSLA will continue to collect data, but Service Level Objectives can not be defined because ITSLA evaluations will not occur. b. Select the desired Time Interval parameters: • Start time of the period • End time of the period • Appropriate time zone c. Define the repeating frequency: Single date, daily, weekly, monthly. d. Click OK. Note: The time zone chosen for the period is relative to the local time zone where the ITSLA Server is located. For more information on the time zone considerations, refer to 5.5, “Timing considerations for the ITSLA environment” on page 193.8. Your new schedule is shown as being available, as displayed in Figure 5-24 on page 172. Click Next to continue. Chapter 5. Administering IBM Tivoli Service Level Advisor 171
  • 195. Figure 5-24 Select Schedule window with a new schedule defined 9. The Create Customized Offering Components window opens, containing the available metrics for the offering. Click Create to create and configure a new offering component.172 Introducing IBM Tivoli Service Level Advisor
  • 196. Figure 5-25 Resource Type tree 10.The Create Offering Component dialogue window is displayed. Expand the Resource Type Tree to view the source application components that are available to choose from, as shown in Figure 5-25. Components that are available will be shown in bold. Be sure to fully expand each component section so that all available components can be viewed. If an application has not been enabled, it will not appear in the this list. Refer to “Source application data collection enablement” on page 142, for more information. 11.Selecting one of the available components will insert the name of the chosen component into the Selected Resource Type form. For our example, the Tivoli Web Services Manager QoS Job was chosen as the offering component to configure. Click Next to continue. Chapter 5. Administering IBM Tivoli Service Level Advisor 173
  • 197. Figure 5-26 Select QoS ROUNDTRIPTIME metric to configure 12.The Select Metrics window opens, displaying the available metrics for the chosen component. For our example, the ROUNDTRIPTIME metric was chosen, as shown in Figure 5-26. Click Configure after selecting the desired metric. 13.The Configure Service Level Objective screen appears, as shown in Figure 5-27 on page 176. The parameters available for the SLO configuration are as follows: – Include metric in offering: Check this box to include the metric in the offering. – Internal use only: Check this box if the metric data is for internal use only. Checking this box will cause the associated metric data to not be included in the SLA Reports that users can view through the ITSLA Report Interface.174 Introducing IBM Tivoli Service Level Advisor
  • 198. – Interval for SLO evaluation: This parameter sets the SLO evaluation frequency, which determines how often data inside the ITSLA Databases are analyzed for SLO violations. Available values are daily, weekly, and monthly.– Start time Hours and Minutes for the SLO evaluation: Start time of the SLO evaluation.– Time Zone for SLO evaluation: Local times for the start time of the SLO evaluation. Consider that the time zone specified is relative to the ITSLA Server time zone. For more information on time zone issues, refer to Chapter 5.5, “Timing considerations for the ITSLA environment” on page 193.– Interval for SLO trend analysis: This parameter sets the SLO trend analysis frequency, determining how often data inside the ITSLA Databases is analyzed to find trends toward potential SLO violations. Available values are daily, weekly, and monthly. Note: The evaluation is performed on data collected from the day before the evaluation start date. Chapter 5. Administering IBM Tivoli Service Level Advisor 175
  • 199. Figure 5-27 SLO Configuration dialogue window 14.Click the Breach Values tab. The Breach values screen is displayed, as shown in Figure 5-28 on page 177. Each parameter is defined as follows: – Minimum, Maximum and Average: These values set the threshold for the chosen metric. Performance and availability data collected by the source applications are inserted in the TEDW Central Warehouse in an hourly format. Depending on the source application data, the maximum, minimum, and average value is weighted over a one hour period and is then inserted into the TEDW Central Warehouse. During SLA violation processing, the maximum and minimum values are evaluated to the highest and lowest single hourly value reported, respectively, during the evaluation period. These values must be defined for any period in the schedule.176 Introducing IBM Tivoli Service Level Advisor
  • 200. Note: Certain source applications will not have the minimum, maximum, and average field, but instead will only have an average field. For instance, the IBM Tivoli Business Systems Manager application metrics has only the average value. – In the drop-down menu, determine if the violation will occur when the actual average is higher than the supplied average or is lower than the actual average. For example, if you would like to receive a violation notice when the average response time of a Web application is greater than a certain value, choose actual average greater than supplied average and insert the desired value in the Average field. Another example may be if you want to receive a violation when a server’s disk free-space is under a certain value. In this case, you would choose actual average less than supplied average and would insert the desired value in the Average field.Figure 5-28 Configuration dialogue window for SLO breach values Chapter 5. Administering IBM Tivoli Service Level Advisor 177
  • 201. 15.Click OK when the SLO breach value configuration is complete. You can configure all the remaining metrics following the same steps. When you are finished configuring the metrics, click Next in the Select Metrics window. 16.The Define Component Information window opens. This component name and its description will appear at the time of creating the customer order. Insert a name and a description and click Finish to complete the offering component creation.Figure 5-29 Create Customized Offering Components window 17.The Create Customized Offering Components window opens, as shown in Figure 5-29. If you would like to add additional components to your offering, click the Create button, and follow the same steps starting with step 10 on page 173. When you are finished adding components, click Next. 18.The Confirm Offering dialogue window displays, as shown in Figure 5-30 on page 179. At this time you can choose to save the offering as a draft in order to work on it later, or to publish the offering so that is available for customers. Click Finish to complete the offering creation.178 Introducing IBM Tivoli Service Level Advisor
  • 202. Figure 5-30 Confirm Offering window5.4.2 Management of orders The offerings and their related schedule creation processes have been defined in 5.4.1, “Management of offerings” on page 167. You may now complete the SLA creation process by associating customers and realms with previously created offerings and schedules. This association, along with the specification of particular resources to include in the SLA contract, is called an order. Order creation The order creation process consists of the following steps: 1. Log on to the IBM Web Console with the customer order specialist, or SLM Administrator role (see 5.3, “User creation and management” on page 157, for further details). Chapter 5. Administering IBM Tivoli Service Level Advisor 179
  • 203. 2. Click the Administer Customer Orders task group to expand it and click Manage Orders to start the order creation process. The Manage Orders window opens, as shown in Figure 5-31. Click Create.Figure 5-31 Manage Orders window 3. The Select Customer dialogue window displays, as shown in Figure 5-32 on page 181. Click Create Customer to associate a new customer with the order or select from an existing customer in the provided list.180 Introducing IBM Tivoli Service Level Advisor
  • 204. Figure 5-32 Select Customer dialogue window 4. The Create Customer window opens. Choose an existing realm from the Realms table or click Create Realm to define a new one. 5. If you decide to create a new realm, insert a realm name and description and click OK. For our example, the All XYZ Customers realm is used. Chapter 5. Administering IBM Tivoli Service Level Advisor 181
  • 205. Figure 5-33 Create Customer window with a new realm defined 6. After creating the realm you are presented with the Create Customer screen, as shown in Figure 5-33. The new realm is now present in the Realms table. Select one of the realms and insert a customer name and description. For our example, the Second XYZ Customer is defined as the new customer. Click OK.182 Introducing IBM Tivoli Service Level Advisor
  • 206. Figure 5-34 Select Customer dialogue window with new customer defined 7. The Select Customer window opens, as shown in Figure 5-34. After selecting the desired customer click Next to continue. 8. The Select Offering window opens. Choose the offering that is to be associated with the customer and click Next. Chapter 5. Administering IBM Tivoli Service Level Advisor 183
  • 207. Figure 5-35 Assign Resources to order offering component 9. The Assign Resources window opens, as shown in Figure 5-35. The offering components table is displayed in the window. For each offering component you must assign the resources that will be evaluated for this customer order. Select the desired component and click Assign. For our example, the Tivoli Web Services Manager QoS Job was selected.184 Introducing IBM Tivoli Service Level Advisor
  • 208. Figure 5-36 Include Resources dialogue window 10.The Include Resources window opens, as shown in Figure 5-36. Initially, the Resources table will appear empty. You must add the resources to the chosen offering component that will be included in the service level evaluation. Click Add. 11.The Select Resource Definition Type window opens, allowing you to choose a filter to create a list of resources. There are three filtering criteria: – Specifying a resource name: The fully qualified path names you specify are used to create the static resources list. If you choose to use a wild card character (*), all the component resources are displayed in the list. – Specifying resource attributes: The resource attribute names you specify are used to create a static list of resources. Chapter 5. Administering IBM Tivoli Service Level Advisor 185
  • 209. – Specifying a resource list rule: If you choose a wild card value, a list of all resources that match the wild card value will be inserted in the resources list of the offering component. If a new resource is inserted in the ITSLA Databases and matches the wild card value, then new associated resources will be automatically added to the list. For our example, the Specify a resource name filter option is selected, as shown in Figure 5-37. Click Next.Figure 5-37 Select Resource Definition Type dialogue window 12.In the Filter Resources by Name dialogue window, specify the resource name filter. For our example, the wild card (*) character is used, which will display all resources. Click Next to display the resource list.186 Introducing IBM Tivoli Service Level Advisor
  • 210. Figure 5-38 Select Resources window 13.The Select Resources window displays the resources that can be included in the service level evaluation. In this dialogue window, each resource monitored by the different Tivoli applications is displayed. For our example, a specific Web site being monitored by the IBM Tivoli Monitoring for Transaction Performance (TWSM) application is selected, as shown in Figure 5-38. You may select as many resources here as you would like. Click Finish. Chapter 5. Administering IBM Tivoli Service Level Advisor 187
  • 211. TFigure 5-39 Include Resources window with a new component defined 14.The Include Resources window opens with the new resource defined, as shown in Figure 5-39. If you would like to add a new resource to the resource table, go back to step 9 on page 172. When you finish, click OK.188 Introducing IBM Tivoli Service Level Advisor
  • 212. Figure 5-40 Assign Resources window with a complete offering component 15.The Assign Resources window opens, displaying the new offering component whose state is complete, as shown in Figure 5-40. If you would like to assign additional resources, click the Assign button. If not, click Next. 16.The last window of the order creation process opens. Review the order details and then click Submit to activate the Service Level Agreement. Viewing an order’s SLA state Once the order has been submitted, it is placed in the Complete state. When an order is in this state, the associated SLA is ready for analysis and the results will be made available for reporting following the evaluation. If you are logged in to the IBM Web Console with a user who has the customer order specialist or Administrator role assigned, you can view and manage the available submitted orders by expanding the Administer Customer Orders task and selecting Manage Orders. Figure 5-41 on page 190 displays the Manage Orders screen. Chapter 5. Administering IBM Tivoli Service Level Advisor 189
  • 213. Figure 5-41 The Manage Orders screen A great deal of information regarding your orders can be found on this screen, such as the order ID, the customer name, the offering that is associated with the particular order, the SLA state, the order state, and the date on which the order was last modified. If you would like to find out more information for a particular order, select the order and click View at the bottom of the screen. You will now be presented with the View Order screen. This screen will provide you with most of the information located on the Manage Orders screen, but with some additional functionality. On the left side of the View Order screen, under the General heading, you can choose from three additional views: SLA State, Order State, and Offering Components. If the order you selected to view is in the Violation state, you can click the SLA State tab to view the violations that have been received. Figure 5-42 on page 191 shows what the SLA State screen may display.190 Introducing IBM Tivoli Service Level Advisor
  • 214. Figure 5-42 SLA State screen You can view when the violation was detected and for what metric and component the violation was received. To see the actual metric and breach values that caused the violation, select the violation you wish to view and click the View Violation button located under the table. The View Violation screen is shown in Figure 5-43 on page 192. Click the Close button to leave this screen and return to the View Order screen. By clicking the Order State tab on the View Order screen, you can view the state of the selected order along with the state of the associated offering components. Click the Close button to leave this screen. Clicking the Offering Components tab on the View Order screen will display the offering components that are part of the order. You can drill down deeper into each component by selecting it and clicking the View Resources button. Through the next series of screens, you can view the settings you made when creating each offering component. Chapter 5. Administering IBM Tivoli Service Level Advisor 191
  • 215. Figure 5-43 View Violation screen Order deletion It is possible to delete customer orders once they have been submitted if the defined SLA is no longer needed. However, the following criteria must be first met before an order can be deleted: The order state of the order you would like to delete must be Canceled, Failed, or Deploy Failed. In the ITSLA Database, there can be no violation or trend data associated with the order you want to delete. If it is necessary to delete an order that does not meet the above criteria, contact Tivoli Customer Support.192 Introducing IBM Tivoli Service Level Advisor
  • 216. 5.5 Timing considerations for the ITSLA environment The basic data flow in the IBM Tivoli Service Level Advisor environment is shown in Figure 5-44. Source ETLs are responsible for transferring and transforming source application data into the format required by the Tivoli Central Data Warehouse. Refer to 2.7, “Applications providing measurement data” on page 46, for how to enable an application to insert data into the Tivoli Data Warehouse and become ITSLA-enabled. The Registration Target ETL and Process Target ETL are the ITSLA Target ETL processes that transfer data, respectively, from the TEDW Central Warehouse database to the ITSLA Database and the ITSLA Measurement Data Mart databases. L ITSLA ET n Database iot tra is eg Source ETL R Source TEDW Central Application Data Warehouse Pr Database oc es s ET L ITSLA Measurement Data Mart Figure 5-44 Data Flow in the ITSLA environment When the latest available data is inserted in the ITSLA Databases, IBM Tivoli Service Level Advisor can begin evaluating and analyzing the data for service level agreement violations and for possible violation trends. In the following sections, information is provided regarding the scheduling of ETLs and the ITSLA evaluation process. Chapter 5. Administering IBM Tivoli Service Level Advisor 193
  • 217. 5.5.1 Scheduling ETLs In order for all source application data to be transferred efficiently, the source application administrator and the Tivoli Enterprise Data Warehouse administrator must devise a common data transfer policy. It is the responsibility of the Tivoli Enterprise Data Warehouse administrator to choose a time period that is most suitable for the scheduling and running of the Source ETLs, so that the data transfer process will experience optimal network performance. This will depend not only on the network capacity, but also on the amount of data being transferred by the Source ETLs. The following rules should be considered when scheduling the ETLs: The Source ETL data transfer must complete before the Registration Target ETL begins processing. The Registration Target ETL must run and complete its SQL steps before the Process Target ETL begins its processing. The Registration Target ETL populates the ITSLA Database with data from the TEDW Central Warehouse, and the Process Target ETL reads data from the ITSLA Database to determine what data is to be transferred to the ITSLA Measurement Data Mart. The Process Target ETL must start its data transfer after the Registration Target ETL completes, so that the most recent source application data is available. Furthermore, the Process Target ETL transfers data from the TEDW Central Warehouse database to the ITSLA Measurement Data Mart database, where IBM Tivoli Service Level Advisor then evaluates this data against the defined service level agreement. The Process Target ETL must be scheduled to run daily, so that the latest data available can be included in the evaluation process. The Registration Target ETL must run when new measurement data types are inserted by the Source ETLs into the TEDW Central Warehouse database, or when new source applications add their data into the TEDW Central Warehouse database. In a complex environment with many different source applications and many new data measurement types being added daily to the TEDW Central Warehouse database, it is advisable to run the Registration Target ETL daily. Because of this, the source application administrator must communicate to the Tivoli Enterprise Data Warehouse administrator any changes in the data collection policy.194 Introducing IBM Tivoli Service Level Advisor
  • 218. 5.5.2 ITSLA evaluation schedule and time zone considerations IBM Tivoli Service Level Advisor evaluates the data inside its data marts in order to determine violations and trends toward potential violations for SLOs configured during order creation (see 5.4.2, “Management of orders” on page 179). The start time and the frequency of the SLO evaluation and trend analysis is determined during the configuration of the service level objectives (see step 12 on page 174). At the configured start time, IBM Tivoli Service Level Advisor begins the evaluation process, where the time interval of the analysis depends on the following frequencies: Daily frequency In the case of a daily evaluation frequency, the evaluation begins on the day before the evaluation starts. For instance, a daily frequency time interval defines the start time as 12:00 AM on the previous day and the end time as 11:59 PM on the current evaluation day. Weekly frequency In the case of a weekly evaluation frequency, the time range of the evaluation begins at 12:00 AM on the Sunday of the previous week and ends at 11:59 PM on the Sunday of the current week. Monthly frequency In the case of a monthly evaluation frequency, the time range of the evaluation begins at 12:00 AM on the first day of the previous month and ends at 11:59 PM on the last day of the previous month. In the evaluation scheduling process you must also consider the topic of time zones. Time zones are specified during the SLO evaluation and trend analysis configuration, and should be kept in mind when defining the business schedule periods (see step 7 on page 169). The following time zone issues must be considered when defining a service level agreement: The time zone of the customer that has a SLA with your company The time zone used by the ITSLA Server component The time zone of the ITSLA administrator (the administrator might be located in a different time zone from the ITSLA Server) Consider that when you define a time zone on the ITSLA Server, it is always relative to the ITSLA Server’s time zone. For example, if you set an evaluation starting at 1:00 AM Eastern Standard Time (EST), and the ITSLA Server is located in Los Angeles using Pacific Standard Time (PST), then the evaluation start time will be set for 10:00 PM (EST is three hours ahead of PST). Keep in mind that when you set a daily evaluation frequency for a SLO, the evaluation will Chapter 5. Administering IBM Tivoli Service Level Advisor 195
  • 219. occur on the day before the ITSLA evaluation start date. For example, if there is an evaluation start date set for Tuesday at 1:00 AM EST, and the ITSLA Server is using PST, the evaluation will begin on Monday at 10:00 PM PST and will analyze data for the day before Monday, being Sunday. Time zone example Consider the following example scenario to better understand the time zone issue, keeping in mind the business schedule: The ITSLA Server is located in Rome (GMT + 01:00). The ITSLA administrator manages the ITSLA Server from a Web browser located in New York (GMT - 05:00). The SLA contract is with a customer located in Tokyo (GMT + 09:00). The SLA contract with the customer in Tokyo contains a business schedule that defines a peak period starting at 8:00 AM and ending at 11:00 AM Tokyo time, which the ITSLA administrator in New York will define using the Tokyo time zone via the ITSLA Web interface. The evaluation frequency is daily, and the start time is set by the administrator to 4:00 AM Rome time, since the ITSLA Server is in Rome and the evaluation period is to begin at 12:00 AM in Tokyo. Because the evaluation needs a certain amount of time to complete (depending on the amount of data to analyze and the available bandwidth), for example, up to one hour, the customer will be able to access reports starting at 1:00 AM Tokyo time. In this scenario, the business schedule has been customized based on customer needs, but sometimes the schedule is defined in the context of a service, and not for a specific customer. Keep in mind, the business schedule of a service must always refer to the time zone where the customers of the service area are located. Table 5-6 Local times for SLA evaluation and peak period start times Location Evaluation start time Peak period start time Rome 4:00 AM 12:00 AM New York 10:00 PM 6:00 PM Tokyo 12:00 AM 8:00 AM5.6 Trace and message log files In an ITSLA environment, two types of log files exist: Message text Trace data log files196 Introducing IBM Tivoli Service Level Advisor
  • 220. They are both collected by loggers, which are IBM Tivoli Service Level Advisor software objects. Data collected by loggers are directed to log files by software objects called handlers.5.6.1 Handler configuration You can determine how you would like to log trace and message data through the handler configuration. There are three types of handlers: Multi-file handler The message and trace data is sent to a rotating set of log files. Serial file handler The message and trace data is sent to a serial log file. Console handler Writes messages to the console or system.out. The handler object name of the trace log files is trcFile.slm, while the handler object name of the message log files is msgFile.slm. There are three different environments for which you are able to configure handlers: ITSLA Server ITSLA Reports IBM Console Through the handler configuration you can define the number of log files and their dimensions for each environment. Handler configuration for the ITSLA Server environment In order to change the number of log files and their dimensions, perform the following steps on the ITSLA Server machine: 1. Initialize and source the ITSLA CLI environment by performing the following: – For Windows, from the ITSLA installation directory, run the slmenv.bat file. – For UNIX, from the ITSLA installation directory, execute . ./slmenv.sh. 2. To change the maximum size of the message log files, run the following commands: scmd log handler msgFile.slm -set maxFileSize=dimension_of_log_file If you want to change the maximum size of the trace data log files, run the following command: scmd log handler trcFile.slm -set maxFileSize=dimension_of_log_file Where maxFileSize is the key needed to change the dimension, and the dimension_of_log_file parameter is a numeric value that expresses the log file dimension in KB. The default dimension of log files is 512 KB. Chapter 5. Administering IBM Tivoli Service Level Advisor 197
  • 221. 3. To change the maximum number of message log files run the following command: scmd log handler msgFile.slm -set maxFiles=max_number_of_log _files And to change the maximum number of trace log files run the following command: scmd log handler trcFile.slm -set maxFiles=max_number_of_log _files Where maxFiles is the key needed to change the number, and the max_number_of_log_files parameter is a numeric value that expresses the maximum number of log files. For more information regarding the scmd log handler command, refer to the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833. Handler configuration for the ITSLA Reports environment Configuring the handler for the ITSLA Reports environment follows the same steps outlined in the previous section. You can replicate the steps provided in the previous section, substituting the scmd log handler command with the logutil handler command. The command examples remain the same, as shown below: logutil handler msgFile.slm -set maxFileSize=1024 logutil handler trcFile.slm -set maxFileSize=2048 For more information on the logutil handler command, refer to the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833. Handler configuration for the IBM Console environment In order to configure handlers for the IBM Console environment, perform the following steps: 1. Log on to the IBM Java Console as the superadmin user. 2. From the task groups on the left-hand side of the screen, expand Administer Logging, click Configure Logging, and select Handlers, as shown in Figure 5-45 on page 199. 3. Locate the trcFile.slm and the msgFile.slm handlers on the right side of the window. 4. Right click the handler you want to configure and select Edit Properties. For our example, the trcFile.slm handler is chosen.198 Introducing IBM Tivoli Service Level Advisor
  • 222. Figure 5-45 Configure logging for IBM Console environment 5. The trcFile.slm properties dialogue window is displayed, as shown in Figure 5-46 on page 200. From here you can decide the maximum size of the log files and the number of trace log files. 6. Stop and restart the Server for IBM Console and Web Services for IBM Console processes (see 5.7, “Startup and shutdown procedures” on page 204, for more information on starting and shutting down the IBM Tivoli Service Level Advisor components). Chapter 5. Administering IBM Tivoli Service Level Advisor 199
  • 223. Figure 5-46 Properties dialogue window for tracing handler5.6.2 Message log files management Message log files for the IBM Tivoli Service Level Advisor environment are available for the ITSLA Server, ITSLA Reports, and ITSLA Task Drivers (IBM Console) components environment. There are two message log file name formats: SLMMessagex.log The message logger inserts message data starting from the SLMMessage1.log file. When the file reaches its maximum dimension, it is renamed SLMMessage2.log and a new SLMMessage1.log file is created and populated. The maximum dimension of the message log files and their number is decided during the msgFile.slm handler configuration (see 5.6.1, “Handler configuration” on page 197).200 Introducing IBM Tivoli Service Level Advisor
  • 224. SLMSerialMessagex.log The message logger inserts message data with the same process described in the previous point. This is a serialized format log file, and its contents can be viewed using the log viewer function of the IBM Java Console. The location of each message log file type is shown in Table 5-7, where ITSLA_Install_Dir is the installation directory of ITSLA, and PS_Dir is the directory where the Tivoli Presentation Services is installed. Table 5-7 Locations of message log files ITSLA component Location ITSLA Server ITSLA_Install_Dir/log/SLMServer ITSLA Reports ITSLA_Install_Dir/log/SLMReport ITSLA Task Drivers (IBM Console) PS_Dir/log/fwp_mcr, PS_Dir/log/fwp_wc There are two separate log file directories for the ITSLA Task Drivers, with fwp_mcr representing the MCR component of the Server for IBM Console, and fwp_wc representing the WC component of Web Services for IBM Console. There are a number of ways to view the ITSLA message logs, dependent on your operating system: For UNIX, you may use the command tail -f message_log to view the message logs. For Windows, you can use the Notepad or your preferred text editor. The IBM Java Console may also be used to view the message logs. For more information on using the IBM Java Console for viewing message logs, refer to the Administrator’s Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835.5.6.3 Trace log files management Trace log files for the ITSLA environment are available for the ITSLA Server, ITSLA Reports, and the ITSLA Task Drivers (IBM Console) components environment. The trace log files are activated to diagnose problems and are used mainly by IBM support personnel. In the following section, information is provided to help you activate the different trace logger for the specific environments and to provide meaning for the different available trace loggers. Chapter 5. Administering IBM Tivoli Service Level Advisor 201
  • 225. The trace log files are located in the same directories as the message log files (see 5.6.2, “Message log files management” on page 200), with a naming format of SLMTracey.log, where y can be a number from 1 to 3. The SLMTrace1.log file always contains the most recent information. The SLMTracey.log file has a maximum dimension determined by the handler configuration (see 5.6.1, “Handler configuration” on page 197). When the SLMTrace1.log file has reached its maximum size, it is renamed to SLMTrace2.log and a new SLMTrace1.log file is created and filled with trace data. Table 5-8 lists the available IBM Tivoli Service Level Advisor trace loggers, along with their associated subcomponents and descriptions. Table 5-8 Available ITSLA trace loggers Trace logger group Subcomponent Description name dykal adapter Trace logger for the adapter layer. The ds subcomponents are shown for the cli adapter, the data source (ds), the CLI cm Service (cli), Configuration cfg Management (cm), configuration (cfg), log and logging (log). dylws Trace logger for the data collector. dyket Trace logger for the ETL processes. dykgu Trace logger for the GUI. dyktik Trace logger for Database API Code. dykme common Trace logger for the Metric Evaluator mem Manager and its components. scheduler dykom Trace logger for the Order Manager. dykrp Trace logger for the Report Server. dyksd sdml Trace logger for the Service Definition Catalog. dyksl Trace logger for the Service Level Agreement component. dykut Trace logger for the Common code.202 Introducing IBM Tivoli Service Level Advisor
  • 226. In order to activate the tracing activity for the ITSLA Server and Reportsenvironments, perform the following steps:1. Initialize and source the ITSLA CLI environment by performing the following: a. For Windows, from the ITSLA installation directory, run the slmenv.bat file. b. For UNIX, from the ITSLA installation directory, execute . ./slmenv.sh.2. List the available trace loggers: a. For the ITSLA Server environment, type the following command: scmd log trace -list b. For the ITSLA Reports environment, type the following command: logutil trace -list3. Enable the trace loggers: a. For the ITSLA Server environment, use the output listed from the command given in Step 2a above and type the following: scmd log trace -g [group/subcomponent] -set isLogging=true b. For the ITSLA Reports environment, use the output listed from the command given in Step 2b above and type the following: logutil trace -g [group/subcomponent] -set isLogging=true Where group and subcomponent are chosen from Table 5-8 on page 202.In order to turn on tracing for the ITSLA Task Drivers (IBM Console), perform thefollowing steps:1. Log in to the IBM Java Console as the superadmin user.2. Select Administer Logging -> Configure Logging.3. Under Types of Logging Elements, select Trace Loggers.4. Right click of the trace loggers available for the IBM Console and select Enable, as shown in Figure 5-47 on page 204.5. Stop and restart the Server for IBM Console and Web Services for IBM Console services. Chapter 5. Administering IBM Tivoli Service Level Advisor 203
  • 227. Figure 5-47 Enable trace logging on the IBM Console The trace loggers available for the IBM Console environment are: dykgu, dyksd, dyktik, dykut, dykal, dykal.cm, dykal.adapter, and dykal.ds. For more information about the trace log format and filtering masks configuration, refer to the Administrator’s Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835.5.7 Startup and shutdown procedures Startup and shutdown procedures are described in Administrator’s Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835. A compact reference is included in the following sections for the steps necessary to startup and shutdown components in the ITSLA environment for both the UNIX and the Windows environment.204 Introducing IBM Tivoli Service Level Advisor
  • 228. 5.7.1 IBM Tivoli Service Level Advisor components startup Table 5-9 on page 206 lists the commands necessary to start the IBM Tivoli Service Level Advisor components. Each component is shown in the order in which it must be started. If there is more than one way to start the ITSLA component, each startup option is listed as well. Windows environment In a Windows environment, the IBM Tivoli Service Level Advisor components can be started a number of ways, each of which is explained in Table 5-9 on page 206. You may start each component by using one of the following: The appropriate command line interface (CLI) If it was installed as a service, through Services in the Control Panel By selecting the application, if available, through Start -> Programs -> Application_Name Table 5-9 on page 206 includes the following variables, which are described here: PS_Dir Directory where Tivoli Presentation Services is installed ITSLA_Server_Inst_Dir Directory where the ITSLA Server is installed IBM_Console_Machine Host name of the machine where the IBM Console Server is installed IBM_HTTP_Port Port used by the IBM HTTP server WebSphere_Dir Directory where WebSphere is installed db2_inst_dir Home directory of the database administrator who created the instance HTTP_Dir Directory where the IBM HTTP Server is installed The variable definitions remain the same as in Table 5-10 on page 208. UNIX environment In a UNIX environment, you may need to source the IBM DB2 profile. From a command prompt, navigate to the DB2_Inst_Home/sqllib directory and run the following command: . ./db2profile Chapter 5. Administering IBM Tivoli Service Level Advisor 205
  • 229. Table 5-9 Commands to start ITSLA components Component Windows start commands UNIX start command Server for IBM Console Services Access the Windows Run ps -ef | grep mcr to see if the Services administration tool, mcr.sh process is started. If it is right click Server for IBM not started, navigate to Console and select Start. PS_Dir/bin/generic_unix and At a command prompt, execute the command ./mcr.sh. access the PS_Dirbinw32-ix86 directory and execute the command mcr.bat. At a command prompt, execute the command net start ps_mcr. Web Services for IBM Console Access the Windows Run ps -ef | grep wc to see if the Services administration tool, wc.sh process is started. If it is right click Web Services for not started, navigate to IBM Console and select PS_Dir/bin/generic_unix and Start. execute the command ./wc.sh. At a command prompt, access the PS_Dirbinw32-ix86 directory and execute the command wc.bat. At a command prompt, execute the command net start ps_wc. ITSLA Server Access the Windows Navigate to the Services administration tool, ITSLA_Inst_Dir/bin and execute right click IBM Tivoli Service the command Level Advisor and select ./slm_service_start.sh. Start. At a command prompt, execute the command net start tslm. IBM WebSphere Application Select Start -> Programs -> Source the DB2 Profile and from Server AES 4.0 and 4.01 IBM WebSphere -> a command prompt navigate to Application Server -> Start the WebSphere_Dirbin directory Application Server. and execute the command At a command prompt, ./startServer.sh. access the WebSphere_Dirbin directory and execute the command startServer.bat.206 Introducing IBM Tivoli Service Level Advisor
  • 230. Component Windows start commands UNIX start commandIBM WebSphere Application Select Start -> Programs -> From a command prompt,Server SE 3.5 IBM WebSphere -> navigate to the Application Server V3.5 -> WebSphere_Dir/bin directory Start Application Server. and execute the command At a command prompt, ./startServer.sh. access the WebSphere_Dirbin directory and execute the command startServer.bat.IBM HTTP Server Access the Windows From a command prompt, Services administration tool, navigate to the HTTP_Dir/bin right click IBM HTTP Server directory and execute the and select Start. command . ./apachectl start. At a command prompt, execute the command net start “IBM HTTP Server”.IBM HTTP Administration Server Access the Windows From a command prompt, Services administration tool, navigate to the HTTP_Dir/bin right click IBM HTTP directory and execute the Administration and select command . ./adminctl start. Start. At a command prompt execute the command net start “IBM HTTP Administration”. The ITSLA environment has three main consoles that you can work with. Each console may be started in the following ways: ITSLA Web Console This is the main ITSLA console that is accessed through the following URL: http://IBM_Console_Machine:IBM_HTTP_Port/IBMConsole The default user with the ITSLA administrative role is superadmin and the default password is password. ITSLA Java Console This console is used mainly for reviewing message logs and turning tracing on and off. You can access this console in a Windows environment by double clicking the IBM Console icon on the Windows Desktop. In a UNIX environment, locate and run the jc.sh script. Chapter 5. Administering IBM Tivoli Service Level Advisor 207
  • 231. WebSphere Admin Console This console is used primarily to administer the WebSphere and ITSLA Report Server. In order to access this console in a Windows environment select Start -> Programs -> IBM WebSphere -> Application Server -> Administrator’s Console. To access this console in a UNIX environment, navigate to the WebSphere_Dir/bin directory and execute the following command: . ./adminclient.sh hostname_of_WebSphere_Server_machine5.7.2 ITSLA components shutdown Table 5-10 lists the commands necessary to shut down the ITSLA components. Each component is shown in the order in which it must be shut down. If there is more than one way to shut down the ITSLA components, each shutdown option is listed as well.Table 5-10 Commands to shutdown ITSLA components Component Windows shutdown UNIX shutdown command commands IBM HTTP Server Access the Windows From a command prompt Services administration tool, navigate to the HTTP_Dir/bin right click IBM HTTP Server directory and execute the and select Stop. command . ./apachectl stop. At a command prompt execute the command net stop “IBM HTTP Server”. IBM HTTP Administration Server Access the Windows From a command prompt Services administration tool, navigate to the HTTP_Dir/bin right click IBM HTTP directory and execute the Administration and select command . ./adminctl stop. Stop. At a command prompt execute the command net stop “IBM HTTP Administration”. IBM WebSphere Application At a command prompt, From a command prompt Server SE 3.5 and IBM access the WebSpherebin navigate to the WebSphere Application Server directory and execute the WebSphere_Dir/bin directory 4.0 and 4.01 command stopServer.bat. and execute the command . ./stopServer.sh.208 Introducing IBM Tivoli Service Level Advisor
  • 232. Component Windows shutdown UNIX shutdown command commandsITSLA Server Access the Windows Navigate to the Services administration tool, ITSLA_Server_Inst_Dir/bin right click IBM Tivoli Service directory and execute the Level Advisor and from the command context menu select Stop. ./slm_service_stop.sh. At a command prompt execute the command net stop tslm.Web Services for IBM Console Access the Windows Run ps -ef | grep wc to check if Services administration tool, the wc.sh process is running. If it right click Web Services for is running, navigate to the IBM Console and select PS_Dir/bin/generic_unix Stop. directory and execute the At a command prompt, command . ./stopwc.sh. access the PS_Dirbinw32-ix86 directory and execute the command stopwc.bat. At a command prompt execute the command net stop ps_wc.Server for IBM Console Services Access the Windows Run ps -ef |grep mcr to see if the Services administration tool, mcr.sh process is running. If it is right click Server for IBM running, navigate to Console and select Stop. PS_Dir/bin/generic_unix and At a command prompt, execute the command access the . ./stopmcr.sh. PS_Dirbinw32-ix86 directory and execute the command stopmcr.bat. At a command prompt execute the command net stop ps_mcr.5.8 Backup and restore of ITSLA The IBM Tivoli Service Level Advisor environment maintenance is assured by regular backups in order to have an updated image of the environment if problems occur. A backup and restore procedure is provided if your company does not already have a backup strategy in place. Chapter 5. Administering IBM Tivoli Service Level Advisor 209
  • 233. The IBM Tivoli Service Level Advisor environment components that should be backed up are listed below: ITSLA Server ITSLA Task Drivers ITSLA Report ITSLA Databases, which are the ITSLA Database and the ITSLA Measurement Data Mart Tivoli Enterprise Data Warehouse databases WebSphere customized report servlets for the ITSLA environment Before starting any backup or restore procedure, be sure to unschedule the Registration Target ETL in order to produce consistent backups. If the Registration Target ETL happens to run during a backup procedure, the ITSLA environment may become inconsistent. Be sure to shut down the ITSLA Server, ITSLA Reports, and ITSLA Task Drivers prior to the back up or restore. Following these procedures, reschedule the Registration Target ETL and restart the ITSLA components. In this section, information regarding backup and restore procedures for the IBM Tivoli Service Level Advisor components is provided. To ensure a successful backup and restore, follow the order defined in the following sections.5.8.1 Backing up the ITSLA environment In order to obtain a successful backup of the IBM Tivoli Service Level Advisor environment, perform the steps in the following sections. Unschedule the Registration Target ETL To unschedule the Registration Target ETL, you must place the ETL in Test Mode, which will remove the currently defined schedule (refer to“Scheduling and running the Registration Target ETL” on page 144, for information about the Registration Target ETL schedule). ITSLA installation directories backup IBM Tivoli Service Level Advisor has three components that must be backed up: ITSLA Server ITSLA Reports Server ITSLA Task Drivers210 Introducing IBM Tivoli Service Level Advisor
  • 234. A backup can be made for each of the installation directories by running the slmbackup script. In the case of a distributed install, the slmbackup script must be run on each machine simultaneously where an ITSLA component is installed. For example, if the ITSLA Server and ITSLA Reports Server are installed on the same machine, and the ITSLA Task Drivers are installed on another machine, you will need to run the slmbackup script on both machines, with the backup being stored locally. Before executing the slmbackup command, the ITSLA environment must be initialized by running the slmenv.bat or slmenv.sh scripts, depending on your operating system. The backup script is located in the ITSLA installation directory and has the following syntax: slmbackup {backup_directory [-auto] | -start} Where backup_directory is the directory that will contain the backup image. If you are creating a backup directory on UNIX, ensure that the directory is write-enabled. The -auto option forgoes user confirmation before the backups, while the -start option is used to restart ITSLA after the backup has completed. As an example, we will make a backup of the ITSLA Task Drivers, which is installed on a Windows machine. A directory labeled ITSLA Backup is created and will contain the backup images. From a command line with the ITSLA environment variables sourced, the following command is run: slmbackup “C:ITSLA Backup” The script executes the following actions: 1. The ITSLA components are stopped in order to be backed up. 2. In order to have a consistent backup of each ITSLA component, the script reminds you to shut down the ITSLA components not installed on the machine and to run the slmbackup command on the other machines in order to synchronize the backup for the other ITSLA components, as shown in Example 5-5.Example 5-5 Output of slmbackup scriptC:Program FilesITSLA>slmbackup "C:ITSLA Backup"DYKUT0100I -- Starting backup of IBM Tivoli Service Level Advisor. --DYKUT0186W ** WARNING: To successfully back up IBM Tivoli Service Level Advisor, the SLMServer, IBM Console Server including the SLM Task Drivers, and the SLM Report Server must beshutdown and remain shutdown. This process will properly shutdown each server as necessary torun the backup procedures. Do not attempt to run IBM Tivoli Service Level Advisor until allbackup operations have complete.DYKUT0152I The directory C:ITSLA BackupDYK200205101538 does not exist. It will be creatednow. Chapter 5. Administering IBM Tivoli Service Level Advisor 211
  • 235. DYKUT0102I IBM Tivoli Service Level Advisor will be backed up toC:ITSLABackupDYK200205101538200205101538.zip.DYKUT0108I -- Stopping the IBM Console Server including the SLM Task Drivers. --The Web Services for IBM Console service is not started.More help is available by typing NET HELPMSG 3521.The Server for IBM Console service is not started.More help is available by typing NET HELPMSG 3521.DYKUT0109I -- Stopping the SLM Server. --The IBM Tivoli Service Level Advisor service is not started.More help is available by typing NET HELPMSG 3521.DYKUT0111I The three IBM Tivoli Service Level Advisor servers, the SLM Server, the IBM ConsoleServer including the SLM Task Drivers and the SLM Report Server are required to be shut down tocontinue.DYKUT0112I The following IBM Tivoli Service Level Advisor servers are not located on thisinstallation and need to be shutdown: the SLM Reports.DYKUT0116I This backup procedure, slmbackup, must be performed on each machine where the SLMServer, SLM Task Drivers or SLM Reports options of IBM Tivoli Service Level Advisor areinstalled to verify each is shutdown before obtaining synchronized backup images.Issue the slmbackup command on the machine containing the installation of the SLM Reports.When all slmbackup procedures have reached this point, press the Enter key to continue.DYKUT0125I -- IBM Tivoli Service Level Advisor Installation Directory Backup. --DYKUT0184I -- Performing backup of the IBM Tivoli Service Level Advisor installation directoryfor the SLM Task Drivers and SLM Server. --DYKUT0157I Completed IBM Tivoli Service Level Advisor Installation Directory backup for the SLMTask Drivers and SLM Server with the file C:ITSLA BackupDYK200205101538200205101538.zip.DYKUT0127I To complete all IBM Tivoli Service Level Advisor installation directory backups, thebackup image of the installation directories for the SLM Reports need to complete. Allow thebackup of those servers to complete before restarting IBM Tivoli Service Level Advisor.DYKUT0123I The IBM Console Server was found on this machine at C:PS.Backup procedures for the IBM Console Server and SLM Database should be performed beforerestarting IBM Tivoli Service Level Advisor.DYKUT0138I -- IBM Tivoli Service Level Advisor Installation Directory Backup Complete. --C:Program FilesITSLA>212 Introducing IBM Tivoli Service Level Advisor
  • 236. 3. The ITSLA Task Drivers installation directories are backed up and placed in a zipped format in the following directory path: C:/ITSLA Backup/DYK/200205101538/200205101538.zip Where 200205101538 is the backup timestamp.If you want to restart the ITSLA components after the backup completes, executethe following command:slmbackup -startKeep in mind that during the backup process, the ITSLA components must notbe active, and only when all the ITSLA environment components (ITSLADatabase Server, Tivoli Enterprise Data Warehouse, WebSphere reportsservlets) have been backed up can you restart the ITSLA components.ITSLA Database component backupIn order to back up the ITSLA Database component, you must use the db2backup command on the ITSLA Database Server machine. Perform the followingsteps to create a backup:1. Open an IBM DB2 command line.2. Execute the following command: db2 backup database ITSLA_DB_Name user Admin_User using Admin_Password to backup_directory Where: – ITSLA_DB_Name is the ITSLA Database name chosen during the ITSLA installation (DYK_CAT, for example). – Admin_User is a DB2 user with administrative privileges. – Admin_Password is the password of the administrative user. – Backup_Dir is the directory where database backup images will be located. This directory must be created prior to running the backup.If you receive a message when trying to back up a database that states thedatabase is currently in use, use the db2 terminate or db2 force applicationall command to free the databases from current activity.Note the timestamp after the database backup has completed, as this will beused in the case that a restore is necessary. Consult your database administratorin order to schedule and develop a common backup strategy.Restarting the ITSLA environmentAfter you have backed up the ITSLA components, you can restart the ITSLAenvironment by following the instructions given in the 5.7, “Startup and shutdownprocedures” on page 204. Chapter 5. Administering IBM Tivoli Service Level Advisor 213
  • 237. The Registration Target ETL must be rescheduled in order for the ITSLA environment to function properly. Refer to 5.2.1, “Registration Target ETL management” on page 142, for information on how to schedule the Registration Target ETL.5.8.2 Restoring the ITSLA environment In order to restore the IBM Tivoli Service Level Advisor environment from an existing backup, the Registration Target ETL must first be unscheduled and the ITSLA components must be shut down. Refer to 5.8.1, “Backing up the ITSLA environment” on page 210, for more information. If irreparable damage has occurred to the ITSLA Server, and you must reinstall the environment, be sure to use the same naming conventions for all directories where the product was initially installed. If the machine itself is damaged, and you must reinstall on another machine, make sure that the new machine is configured with the same host name and disk partition configuration. The restore procedure is made up of a number of steps, as described in the following sections. ITSLA installation directories and report servlets restore The IBM Tivoli Service Level Advisor components installation directories contain the configuration information needed to restore the ITSLA environment. If the ITSLA components have all been installed on the same machine, the restore procedure is to be executed only on that machine. If the ITSLA components are installed on separate machines, the restore procedure must be executed on each machine where the installation directories are located. The timestamp of the backup must be the same for each component restored, otherwise the restore procedure will not be successful. The slmrestore and slmrestorestart scripts are used to restore the ITSLA installation directories. If the ITSLA components are installed on different machines, you must execute the following steps on each machine: 1. From the ITSLA product CD, execute the following command: slmrestore directory timestamp Where directory is the directory where the backup is located, and timestamp is the timestamp of the backup (refer to “ITSLA installation directories backup” on page 210).214 Introducing IBM Tivoli Service Level Advisor
  • 238. 2. The slmrestore utility analyzes the system to determine which ITSLA components are installed before shutting them down. If other components are installed on other machines, slmrestore prompts you to shut down the other components and start the slmrestore on the other machines in order to have a consistent restore.3. The installation directories are restored.4. The ITSLA Report servlets for IBM WebSphere Application Server Versions 4.0 and 4.0.1 are automatically restored. For other IBM WebSphere Application Server versions, a manual restore must be performed, as described in Getting Started with IBM Tivoli Service Level Advisor Version 1.1, SC32-0834. Important: On the ITSLA Server machine, the ITSLA_Inst_Dir/cfg directory must be removed before starting the restore procedure. This step is not required if you have recently reinstalled the ITSLA Server. If this step is necessary, stop the ITSLA Server and Reports Server before removing the cfg directory, if these components are located on the same machine.ITSLA Databases restoreThe databases to be restored in a IBM Tivoli Service Level Advisor environmentare the ITSLA Database (DYK_CAT) and the Tivoli Enterprise Data Warehousedatabases. This section describes the process for the ITSLA Database. Forinstructions on the Tivoli Enterprise Warehouse databases, please refer to TivoliEnterprise Data Warehouse Installing and Configuring Version 1.1, GC32-0744.To list all of the backups available for restore, run the following command from aDB2 command prompt:db2 list history backup all for db_nameWhere db_name is the database previously backed up. In the command outputyou will find the start time of the backups and the location—two values that mustbe used during a restore. Important: The ITSLA Database restore must be executed using a backup performed at the same time period of the ITSLA directories backup, otherwise the restore procedure will not be successful.The ITSLA Database restore is achieved through the IBM DB2 command listedbelow:db2 restore database db_name user DB2_user using DB2_password frombackup_directory taken at DB2_timestamp> Chapter 5. Administering IBM Tivoli Service Level Advisor 215
  • 239. Where: db_name Is the name of the database to be restored. In our case, the database name is the ITSLA Database, whose default name is DYK_CAT. DB2_user Is the DB2 user chosen to execute the restore procedure. You must choose a user with administrative privileges, usually db2admin or db2inst1 by default. DB2_password Is the DB2_user password. backup_directory Is the directory where the database backup is located. The value of this parameter is equal to the location variable for the ITSLA Database backup, obtained through the db2 list history backup command previously executed. DB2_timestamp Is the backup timestamp. The value of this parameter is the value of the start time variable for the ITSLA Database, obtained with the db2 list history backup command previously executed. Restarting the ITSLA environment When the restore procedure has successfully completed, you can restart the ITSLA components and reschedule the Registration Target ETL and Process Target ETL. To restart the ITSLA components, refer to the relevant procedures indicated in 5.7.1, “IBM Tivoli Service Level Advisor components startup” on page 205, or you can execute the command slmrestorerestart on any machine where the ITSLA components are installed. You must also reschedule and run the Registration Target ETL and Process Target ETL. To do this, refer to 5.2, “Target ETLs management” on page 142.216 Introducing IBM Tivoli Service Level Advisor
  • 240. 6 Chapter 6. Service level Reports with ITSLA IBM Tivoli Service Level Advisor provides a reports feature that allows the viewing of violation and trend data stored in the ITSLA Database. Depending on the user’s role who is responsible for accessing the reports, there are a number of customizable features for this Web-based component. Whether you would like to view violations for a single customer over the past week, or the customer ranking for a group of customers covering the previous quarter, IBM Tivoli Service Level Advisor can provide these features and more with the single click of a button. In the following sections you will learn more about the different features and functions of IBM Tivoli Service Level Advisor Reports, such as: Logging into Reports Using Reports Administrating Reports users Reports customization Viewing Reports with third-party software© Copyright IBM Corp. 2002 217
  • 241. 6.1 Logging into Reports In order to log into IBM Tivoli Service Level Advisor Reports, you must know the name of your ITSLA Reports Server, and the port that IBM WebSphere is using for reports. Unless you have manually changed the port definition, the default is set to 9080. Enter the following URL in your desired Web browser to connect to Reports: http://ITSLA_Reports_Server:port/SLMReport In Figure 6-1 the Report Sign on screen is shown. As you will notice, in order to access the features of Reports, you must supply this page with a user name and password. The following section provides information concerning the default users created during the installation of IBM Tivoli Service Level Advisor Reports.Figure 6-1 Reports sign-on screen218 Introducing IBM Tivoli Service Level Advisor
  • 242. 6.1.1 Default Reports users There are three users set up by default for Reports, those being customer, executive, and operations, with the password set to password. Each user is initially configured with a different Report view; however, all default users have been created with unrestricted view access, meaning they are able to see information regarding all customers across all realms. Each user and default view are defined below: The customer user will initially see the Customer Order Ranking view via the customer.jsp page, as shown in Figure 6-2. This view displays all order IDs with their associated customers, the number of violations and trends for that customer, and the customer’s rank in descending order in a month-to-date time period. More information concerning order ranking can be found in 6.1.2, “The Ranking algorithm and categories” on page 221.Figure 6-2 Customer user view Chapter 6. Service level Reports with ITSLA 219
  • 243. The executive user will initially see the Customer Ranking view by logging into the executive.jsp page, as shown in Figure 6-3. This view displays the same information within the same time period as the customer view, minus the order IDs.Figure 6-3 Executive user view The operations user will initially see the Offering Component Ranking view by using the operations.jsp page, as shown in Figure 6-4 on page 221. The offering components, the number of violations and trends associated with each offering component, and the offering component ranking are displayed on this page in a rolling seven-day time period.220 Introducing IBM Tivoli Service Level Advisor
  • 244. Figure 6-4 Operations user view6.1.2 The Ranking algorithm and categories When viewing reports, you will notice that the last column in every view has a customer-associated number labeled Rank. Along with this, you may discover that dependent upon the view you are using, you have different choices to select from under the Category heading. These two Reports features are expanded upon in the following sections. Chapter 6. Service level Reports with ITSLA 221
  • 245. Understanding the ranking algorithm When viewing the reports using any of the ranking categories, you will see that they are placed in order according to their rank. This ranking feature is compiled by an algorithm that prioritizes the SLA items using a number of variables, such as the number of violations, the number of trends, and the number of customer orders. The algorithm is defined below: Ranking = (Mult1 + NumOfViolations) + (Mult2 + NumOfTrends) + CustOrders Each variable of the ranking algorithm is defined below: Mult1 This weighting factor is set to 4000 for external SLOs, or 2000 for internal SLOs. NumOfViolations The number of violations. Mult2 This weighting factor is set to 3000 for external SLOs, or 1000 for internal SLOs. NumOfTrends The number of trends. CustOrders The number of customer orders. Take for example the following scenario. A customer has six violations and two trends across a total of four customer orders with all external SLOs. The customer rank would be as follows: Ranking = (4000 * 6) + (3000 * 2) + 4 = 30004 An SLO is determined to internal or external depending on whether or not during the service level objective configuration the particular metric was chosen to be included in the external customer reports. If the appropriate box was checked during the SLO configuration, the SLO is external; if the box was not checked, the SLO is internal. When ranking customer orders, the algorithm used is only slightly different, with CustOrders always equal to 1. Also, NumOfViolations and NumOfTrends is equal to the number of violations and trends associated only with that particular violation or order. Using the same scenario as described previously, with Order 1000 having three violations and one trend, Order 1001 having two violations and one trend, and Order 1002 having one violation and no trends, the customer order ranking would be as follows: Order 1000 Ranking = (4000 * 3) + (3000 * 1) + 1 = 15001 Order 1001 Ranking = (4000 * 2) + (3000 * 1) + 1 = 11001 Order 1002 Ranking = (4000 * 1) + (3000 * 0) + 1 = 4001222 Introducing IBM Tivoli Service Level Advisor
  • 246. Ranking categoriesEach of the three default users created by Reports is associated with threeseparate, unique views. Depending on which of the three default users you log inwith, you will have a different selection of ranking categories to select from whenviewing the reports. Table 6-1 lists the available ranking categories for eachdefault user.Table 6-1 Users and associated ranking categories User Category Customer Customer Order Ranking Executive Customer Ranking Customer Order Ranking Realm Ranking SLA Type Ranking Operations Customer Ranking Customer Order Ranking Offering Component Ranking Resource Ranking SLA Type Ranking Realm RankingEach ranking category details different information regarding customers and theirorders. A definition of each ranking category is included below:Customer ranking Each customer, along with the associated number of trends and violations, are displayed. These are ordered in descending order according to their rank. For those logging into the executive.jsp page, this is the default view.Customer Order ranking Each customer order ID, customer, number of trends and violations, and rank are displayed by this category. The order IDs are listed in order of each order’s rank. When logging into the customer.jsp page, this is the only ranking category available. Chapter 6. Service level Reports with ITSLA 223
  • 247. Offering Component ranking Each offering component is listed separately, along with its associated violations, trends, and rank. This is the default ranking category when logging into the operations.jsp page. Resource ranking Each resource selected in an order is listed in this ranking, along with the associated violations and trends. The rank for each resource is calculated across all orders with which the resource is associated. SLA Type ranking Each SLA type (external, internal, and outsourced) is shown with the numbers of trends and violations associated with all the SLA type’s orders. They are listed according to their rank. Realm ranking Each realm is listed separately, along with the number of trends and violations for every customer and order belonging to that realm. Each realm is listed in descending order according to its rank, which is calculated for all customers and orders in the particular realm. In Figure 6-5 on page 225 you see the ranking categories available for the default operations user. These ranking categories will be different depending on the default user you logged in with or the user roles you have been assigned.224 Introducing IBM Tivoli Service Level Advisor
  • 248. Figure 6-5 Operations user ranking categories6.2 Using Reports After logging into Reports and exploring the different ranking category views, you are now ready to explore the different features of IBM Tivoli Service Level Advisor Reports. In the following sections you will learn how to effectively use Reports and how to utilize its many different features.6.2.1 Reporting categories When signing in to the executive.jsp or operations.jsp page, there are additional selections under the Category drop-down box. For the default executive user, there is only one additional selection, entitled Overall Report. Chapter 6. Service level Reports with ITSLA 225
  • 249. For the default operations user, there are three additional selections, as listed below: Trends Report Violations Report Results Report Overall Report A description of each report category is given below: Trends Report This report provides a wealth of information concerning all trends that have been detected. Not only does it display the breach value and its associated order resource, but this reporting category also shows the SLA type, customer and order id, the associated metric, schedule state, and the projected violation date, which predicts when another violation will occur. Figure 6-6 shows what this screen may look like.226 Introducing IBM Tivoli Service Level Advisor
  • 250. Figure 6-6 Trends Report screen Violations Report The violations report displays the same type of information as the Trends Report, but focuses only on all violations received. There are a total of 11 columns containing violation-specific information, ranging from SLA Type and Metric to the Breach Value and Actual Value. A portion of the Violations Report screen is shown in Figure 6-7. Chapter 6. Service level Reports with ITSLA 227
  • 251. Figure 6-7 Violations Report screen Results Report This report category lists particular metric and order information according to the order ID. Information included in this report screen is the customer, order id, metric, resource, offering component, schedule state, offering, breach value, actual value, and error percentage. See Figure 6-8 on page 229 for more details on this screen. Overall Report A collection of the above three reports.228 Introducing IBM Tivoli Service Level Advisor
  • 252. Figure 6-8 Results Report screen6.2.2 Viewing Reports using different search criteria Using the different reporting categories will provide you with in-depth information concerning the status of your SLAs. But by using different search criteria, you will have the ability to locate your SLA information covering any time period, from the last 24 hours to the previous 365 days. Along with searching by time period, you may also search for results according to the configured SLA type. These areas are covered in detail in the following sections. Chapter 6. Service level Reports with ITSLA 229
  • 253. Specifying time periods There are a number of time periods that can be selected when viewing Reports. The Time Period drop-down menu is located under the Filter Criteria heading near the top of the page. Figure 6-9 on page 231 shows a portion of the Time Period drop-down menu. The time periods available to select from are included in the following list: All Dates Today Yesterday Last Week Last Month Last Quarter Last Year Week to date Month to date Quarter to date Year to date Rolling 24 hours Rolling 7 days Rolling 4 weeks Rolling 30 days Rolling 365 days230 Introducing IBM Tivoli Service Level Advisor
  • 254. Figure 6-9 Time Period drop-down menu In order to select a specific time period with which to filter the search criteria, click the drop-down menu and select the desired time period. Those periods that include the term rolling are defined from the present time to the time period specified in the criteria. For example, if on Friday at 18:00 EST you specify Rolling 24 hours for your search criteria, the results starting from Thursday 18:00 EST to the present time will be displayed. After selecting the time period, the Go button to view the results. Specifying SLA type Aside from the time period, you may also search for results by filtering on the SLA Type. This drop-down menu is located to the right of the Time Period drop-down menu. Chapter 6. Service level Reports with ITSLA 231
  • 255. There are four selections to chose from when filtering on the SLA Type, as listed below: All Internal External Outsourced Figure 6-10 shows the SLA Type drop-down menu. After selecting the desired SLA type, click the Go button to view your results.Figure 6-10 SLA Type drop-down menu6.2.3 Additional features of Reports There are a number of other features related to IBM Tivoli Service Level Advisor Reports that are included in the following sections. These features allow you to locate the desired results you are searching for more quickly and will also aid you in performing everyday tasks.232 Introducing IBM Tivoli Service Level Advisor
  • 256. Using the Search field to locate specific results When viewing results using the ranking categories, you may narrow your search to include only a specific customer or a particular customer order ID by using the Search field, located just above the report table. The search function is available for all ranking categories, with the exception of the SLA Type Ranking and the Offering Component Ranking categories. For example, when viewing results using the Customer Order Ranking category, you may further filter your results by including the order ID number in the Search field. After entering what you want to search for, click the Search button to return your results. Figure 6-11 shows how the Search field appears on the Reports page.Figure 6-11 The Search field Chapter 6. Service level Reports with ITSLA 233
  • 257. Changing the number of displayed rows When viewing results on the Reports page, a default number of 10 rows is displayed on the screen. If you have a large amount of customers, orders, or offering components, you may want to change the number of rows shown so that you are able to view them all on one page. The Web link entitled Maximum rows to display, located just above the report table, will enable you to perform this task. Click the number of rows you would like to display and wait for the screen to refresh. An example is shown in Figure 6-12 below.Figure 6-12 Maximum rows to display feature Using the provided Web links There are three additional Web link features located in the upper right corner of the Reports page that allow you to perform various functions. The description of each Web link is given below: Print Tips When clicked, this Web link will open an additional Web page that provides you with useful printing tips when using Microsoft Internet Explorer. Refresh Click this Web link to refresh the current Reports page. Sign Off If for any reason you would like to sign off from the current Reports page, clicking this Web link will sign you off and return you to the initial log on screen. Figure 6-13 on page 235 displays the additional Web links.234 Introducing IBM Tivoli Service Level Advisor
  • 258. Figure 6-13 Additional Web links Using graphs in Reports When using the Results Report category to filter your results, you will notice that the numbers located in the Actual Values column are highlighted as Web links. Clicking each of these values will take you to another screen containing graphical data related to the specific metric and value you selected. You may also change the time period associated with the graphical data by using the Time Period drop-down menu located just above the results table and graph. Figure 6-14 on page 236 gives an example of a graph for the ROUNDTRIPTIME metric in which the assigned maximum value has been violated. The time period for this graph was set to Last Month. Chapter 6. Service level Reports with ITSLA 235
  • 259. Figure 6-14 Report graph using Results Report category Just below the graph is a Web link entitled Graph Data. By clicking this link you will be taken to another page displaying each evaluation time and related actual value associated with the metric you chose from the Results Report view page. Figure 6-15 on page 237 shows the page that is displayed by clicking the Graph Data link.236 Introducing IBM Tivoli Service Level Advisor
  • 260. Figure 6-15 Graph Data page view6.3 Administrating Reports users It may become necessary for additional Reports users to be created, rather than having to rely on the default users provided during installation. In the following sections, you will learn not only how to create additional Reports users but also how to customize these users’ profiles to better suit your environment.6.3.1 Creating Reports users There are many options to choose from when creating Reports users. You may decide some users need access to all reports, covering all customers and realms. Other users may need to be restricted, so that they can only view reports dealing with a particular customer and realm ID. Additionally, external users may Chapter 6. Service level Reports with ITSLA 237
  • 261. be created to view only external data for a particular customer and realm. You may also change the user’s profile at any time via the command line. The information you need to create and change users is included in the following sections. Using the command line to create a Reports user You have many available options when creating a Reports user using the scmd sla addUser command. The syntax for this command is as follows: scmd [ -p current_password] sla addUser -name user_name [-password password] -view {1 | 2 | 3} [-consumer consumer] [-realm realm] [-page page] Each available option is described below: -p current_password If password protection has been enabled, you must supply directly after scmd to run this command. -name name This is the user name you assign the user to log into the Reports page. -password password Specifies the password for the user being created, or, if left blank, a password will be automatically generated and passed back to you. -view {1 | 2 | 3} Each view is associated with a particular privilege for the user. View 1 allows unrestricted access to all viewable reports. View 2 provides restricted access, allowing only the viewing of specified customers and realms. View 3 provides external access to users, allowing the user to view only customers and realms specified whose data has been flagged as not internal. If no view is specified, the user will have no restrictions to viewing reports. -consumer consumer Specifies an already defined customer whose reports the user will be allowed to view. If no consumer is specified, the user will be able to view reports for all customers specified in the -realm flag. If no consumer or realm is specified, the user will be allowed access to all customers and realms. -realm realm An already defined realm ID is specified in this option. If no consumer is specified in the -consumer flag, using the -realm flag will allow the user to view all customers’ reports across this particular realm ID.238 Introducing IBM Tivoli Service Level Advisor
  • 262. -page page Specifies the page view to be used after successfully logging in. Three options are associated with this command flag: customer.jsp, executive.jsp, and operations.jsp. The operations.jsp page is used if no page is specified. Refer to 6.1.1, “Default Reports users” on page 219, for more information concerning the contents of these pages. Using the command line to change a user’s access There may come a time when you would like to change a user’s access privileges, whether it be allowing a user to view all reports or restricting the user to viewing only a certain customer’s reports in a particular realm. Whatever the case may be, the command syntax used to change a user contains the exact same flags as the scmd sla addUser command; only the initial command is different. The command syntax is as follows: scmd [ -p current_password] sla changeUser -name user_name [-password password] -view {1 | 2 | 3} [-consumer consumer] [-realm realm] [-page page] For more information regarding each flag, refer to “Using the command line to create a Reports user” on page 238.6.3.2 Listing and deleting Reports users Listing and deleting Reports users is simple using the command line. The following sections provide information on how to perform each of these steps. Listing Reports users Use the following command syntax to list all available Reports users. You must use the -p flag if password protection is enabled: scmd [-p password] sla listUser Chapter 6. Service level Reports with ITSLA 239
  • 263. Example 6-1 displays what the command output may look like.Example 6-1 scmd sla listUser command output# scmd sla listUsername view consumer realm page--------------------------------------------------------------------------------------------customer unrestricted customer.jsp?fsd=mtdexecutive unrestricted executive.jsp?fsd=mtdoperations unrestricted operations.jsp?fsd=r7dSawyer restricted MyCompany Test customer.jspMartir restricted MyCompany Test customer.jsp# Deleting Reports users Use the following command syntax to delete a Reports user: scmd [-p password] sla deleteUser -name name You must use the -p flag if password protection is enabled. You must also specify the user name of the user you would like to delete after the -name flag. For more information regarding the commands you have seen in this section, please refer to the Command Reference for IBM Tivoli Service Level Advisor Version 1.1, SC32-0833.6.3.3 Disabling Reports user authentication User authentication is turned on by default for IBM Tivoli Service Level Advisor. In order to turn this function off, there are a number of steps to perform, as listed below: 1. Before doing anything, you must stop the IBM WebSphere Application Server by issuing the stopServer command. 2. Locate and edit the web.xml file, which can be found in the following directories, depending on your WebSphere version: – For IBM WebSphere Application Server AES and AE: WAS_Dir/installedApps/SLMReport.ear/SLMReport.war/WEB-INF – For IBM WebSphere Application Server 3.5: WAS_Dir/hosts/default_hosts/SLMReport/web 3. Add the lines in bold to the web.xml file, as shown in Example 6-2.240 Introducing IBM Tivoli Service Level Advisor
  • 264. Example 6-2 Disabling user authentication<?xml version= “1.0” encoding= “UTF=8”?><!DOCTYPE web-app PUBLIC “-//Sun Microsystems, Inc.//DTD Web Application2.2//EN” “http://java.sun.com/j2ee/dtds/web-app_2_2.dtd”> <web-app id=”WebApp_ID”> <display-name>SLM Report Servlets</display-name> <description>IBM Tivoli Service Level Advisor reportingservlets</description> <servlet id=”Servlet_1”> <servlet-name>slmReport</servlet-name> <servlet-class>com.tivoli.managed.gui.report.servlets.SLMReport</servlet-class><init-param id=”InitParam_1”> <param-name>slm.configLocation</param-name> <param-value>d:/Tslm/cfg</param-value> </init-param> <init-param id=”InitParam_2”> <param-name>slm.logLocation</param-name> <param-value>d:/Tslm/log/SLMReport</param-value> </init-param><!--Disable Authentication <init-param id=”InitParam_3”> <param-name>slm.authentication</param-name> <param-value>sessions</param-value> </init-param>--> <load-on-startup>5</load-on-startup> </servlet> <welcome-file-list id=”WelcomeFileList_1”> <welcome-file>index.jsp</welcome-file> </welcome-file-list></web-app>4. After saving and closing the web.xml file, restart the IBM WebSphere Application Server with the startServer command.For more information regarding disabling user authentication, refer to theAdministrator’s Guide for IBM Tivoli Service Level Advisor Version 1.1,SC32-0835. Chapter 6. Service level Reports with ITSLA 241
  • 265. 6.4 Reports customization IBM Tivoli Service Level Advisor provides the user the ability to customize the look and feel of Reports as needed. Even though Reports is ready for immediate use, customization may be desired in order to better suit a given environment. The following sections will address a number of Reports features that may be customized, including login, Reports appearance, and search components. For more information regarding the customization of Reports, refer to the Administrator’s Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835.6.4.1 Integrating Reports with existing Web sites IBM Tivoli Service Level Advisor Reports can be viewed using its own set of Web pages or can be integrated into an existing customer Web site. The following sections will introduce you to the Java Server Pages (JSP files) that are utilized by Reports and will provide you with the information necessary to integrate Reports into your own Web site. Reports and JSP files In order to make the integration of Reports into a customer’s Web site easier, IBM Tivoli Service Level Advisor Reports uses Java Server Pages (JSP files). These files can be modified as needed by the user, dependent on the changes they would like to make. The files are located in the following directory path, where WAS_Dir is the installation directory of IBM WebSphere Application Server: WAS_Dir/AppServer/installedApps/SLMReport.ear/SLMReport.war Table 6-2 provides a list of the JSP files included with IBM Tivoli Service Level Advisor. This table can also be found in the Administrator’s Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835. Table 6-2 Included JSP files JSP file Description graph.jsp Displays the bar graph linked to the Results Report. Input filters are available to restrict the data to custGraph.jsp specific metrics, offering components, customers, orders, offerings, metric value type (min., max, opGraph.jsp average), schedule, period, start and end dates, and SLA type (internal, external, outsourced). index.jsp Displays the login screen and prompts the user for a user ID and password in order to access reports.242 Introducing IBM Tivoli Service Level Advisor
  • 266. JSP file Descriptionindex2.jsp Java Beans-based user authentication.links.jsp Displays the drop-down selection box at the top of most JSPs, enabling the user to jump from page tocustlinks.jsp page by selecting it from the drop-down list.execLinks.jspperiods.jsp Displays the drop-down selection box at the top of some JSPs, enabling the user to customize the time period for the report display.custReportDetail.jsp Displays the Report Details Report tables, including results, trends, and violations, all in one page. TheexecReportDetail.jsp custReportDetail.jsp and opCustReportDetail.jsp display five report tables:opCustReportDetail.jsp Order information Business scheduleopReportDetail.jsp Service level objective results Violations TrendsresultsDetail.jsp Displays the Results Report table.slaTypes.jsp Determines the type of SLA: Internal, external, or outsourced.trendsDetail.jsp Displays the Trends Report table.violationsDetail.jsp Displays the Violations Report table.printRefreshOff.jsp Create Web links in the upper-right portion of the Web page labelled Print Tips, Refresh, and Sign Off.category.jsp Create category drop-down menus for different user roles. Category.jsp is for operations users,custCategory.jsp custCategory.jsp is for customer users, and execCategory.jsp is for executive users.execCategory.jspfilterCriteria.jsp Create drop-down lists for Time Period and SLA Type selection.filterValues.jsp Displays the filter values. The filterValues.jsp file is for all of the pages except the graph. ThegraphFilterValues.jsp graphFilterValues.jsp file is used for the graph page only. Chapter 6. Service level Reports with ITSLA 243
  • 267. JSP file Description maximumRowsToDisplay.jsp Displays the link enabling the user to specify the number of rows to display, such as 10, 20, 30, 40, or 50 rows at a time. xxxFormRedirect.jsp Gets the filters passed in from the previous page and re-displays them when the user clicks Go next to the Category, Time Period, or SLA Type drop-down menus. getFilters.jsp Gets the filters and sets them into a session for the printRefreshOff.jsp file to use. Understanding and using the Report servlets To integrate Reports into your existing Web site, you must actually embed the provided Report servlets into your HTML code. When doing this, there are a total of three servlets that will be imbedded—one main class named SLMReport, which calls the other two classes. One of the remaining classes issues a call to the database to retrieve the data and the other class will display the retrieved data for viewing. A JSP include statement will appear (as shown in Example 6-3) in the appropriate JSP file. Example 6-3 JSP include statement <jsp:include page=”/servlet/com.tivoli.managed.gui.report.servlets.SLMReport ?qi=com.tivoli.managed.gui.report.servlets.SLMFilterRankQuery &di.com.tivoli.managed.gui.report.servlets.SLMFilterRankDisplay &filter=fco &link=custReportDetail.jsp &fontcolor=black &fontsize=2 &titlefontsize=2 &bgcolor=#EDEDEB &tablewidth=500” flush=”true”/> If you are operating in a non-English environment, you should include the UTF-8 character set in the JSP, as shown below: <%@ page contentType=”text/html; charset=UTF-8” %> As a side note, the include statement in Example 6-3 will appear in a single, continuous line, as opposed to the separate line format.244 Introducing IBM Tivoli Service Level Advisor
  • 268. Directly under the first line in Figure 6-3, you will notice the next two lines beginwith ?qi and &di. These two entries represent the query interface and displayinterface parameters, respectively. There are a number of parameters that maybe substituted in their place, depending on the default view you prefer whenviewing the results. Table 6-3 lists the available query and display classes. Thistable may also be found in the Administrator’s Guide for IBM Tivoli Service LevelAdvisor Version 1.1, SC32-0835.Table 6-3 Available query and display classes Query class Display class Link needed? SLMResultsDataQuery SLMResultsDetailTable Yes SLMViolationsQuery SLMViolationsDetailTable No SLMTrendsQuery SLMTrendsDetailTable No SLMResultsQuery SLMResultsGraph No SLMResultsQuery SLMGraphDetailTable No SLMFilterRankQuery SLMFilterRankDisplay Yes SLMOrderInfoQuery SLMOrderInfoTable No SLMScheduleDataQuery SLMScheduleDetailTable NoFor the classes with a Yes in the Link Needed? column, you must use a linkparameter (in Example 6-3 on page 244), which will specify which Web page orJSP file will be visited next. An example of this link parameter follows:&link=custReportDetail.jspAs shown in Figure 6-3 on page 244, the SLMFilterRankQuery andSLMFilterRankDisplay classes were used, which display the trends, violations,and ranking of each customer. This results listing is specified in the filter=fco line,directly below where the display class is specified. You may change this value ifyou wish to use other filters instead of the customer filter. The following are thefilters that you may choose: fcu fst fco frn fslatype fsrc Chapter 6. Service level Reports with ITSLA 245
  • 269. Table 6-4 on page 246 includes the complete list of filters. This table can also be found in the Administrator’s Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835. Using different filtering parameters Numerous filtering parameters may be used when querying the ITSLA Database. Use of a particular filter will display data, if desired, for specific customers, orders, resources, metrics, and other areas. For example, when using the executive.jsp file, the fcm filter parameter is used when searching on a particular customer. A portion of the executive.jsp file is included in Example 6-4. Example 6-4 The fcm filter specified in the executive.jsp file <form action=”servlet/com.tivoli.managed.gui.report.servlets.SLMFilterSearch” method=GET> <%=rsc.getString(“CustomerSearchRequest”)%><br> <a href=”executive.jsp?<%rowViewParam%>”><%=rsc.getString(“Customerviewall”) %> </a><br><br> <LABEL for=”execCustomerSearch”><%=rsc.getString(“CustomerSearch”)%></LABEL> <tr><td valign=top><font face=Arial size=2> <input type=text name=”fcm” size=22 id=”execCustomerSearch”> <input type=”submit” value=”<%rsc.getString(“Search”)%>”> </form> When searching on a particular customer, this search will query the database using the fcm parameter. Table 6-4 lists all available filter parameters. This table can also be found in the Administrator’s Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835. Table 6-4 Available filter parameters Filter parameter Parameter name Customer fcu Customer order fco Metric name fmn Resource frsc Offering component fst Schedule state fss Service offering fso Start date fsd End date fed246 Introducing IBM Tivoli Service Level Advisor
  • 270. Filter parameter Parameter name Customer match (searching) fcm Resource match frscm Customer order match fcom Offering component match focrm SLA type match fslam Realm match frm Value type fvt (min=1; avg=2; max=3); for example, fvt=3 SLA type fslatype (external=1; internal=2; outsource=3; all=0) Filter (used in customer.jsp, filter (available values: fcu, fco, fst, fslatype, frn, frsc) executive.jsp, operations.jsp, and all filterRanking.jsp) Realm name frnImplementing the Refresh featureIf you would like to include the Refresh feature in your own Web site, use theHTML code shown Example 6-5 when placing it in the printRefreshOff.jsp file:Example 6-5 Refresh feature<table width=100% border=0 cellspacing=0 cellpadding=0><tr><td width=99% valign=bottom align=right><font size=2 face=Arial><a href=”printTips.jsp” target=”blank”><%=rsc.getString(“PrintTips”)%></a><!---- Refresh ---><! -- For refreshing, pass in the filters to keep the same query. Do not passin the page parameter so that the servlet will know that it needs to go to thedatabase again. --><a href=”<%=currentPage*?*filters*allRowViewParams.toString()%>”><%=rsc.getString(“Refresh”)%></a>When clicking the Refresh link, a query is reissued against the database, causingthe information in the results table to be updated.Integrating the Logout linkYou may include the Logout link in your Web site, which the user can use to logout of the current Reports session. Refer to Example 6-6 to include this link. Chapter 6. Service level Reports with ITSLA 247
  • 271. Example 6-6 Example of the Logout link <a href=”servlet/com.tivoli.managed.gui.report.servlets.SLMLogout ?link-../index.jsp&tablewidth=450”><%rsc.getString(“SignOff”)%></a> <td width=l%><br> It is very important to include the link to the index.jsp page in the above code, as when invoking the Logout servlet, the current session will be invalidated. The index.jsp directory path is relative to the location of the servlet directory. Integrating the Search function Users have the ability to search for certain components, such as customers, orders, realms, or resources, in some of the JSP files. By passing the SLMFilterSearch class, the search HTML form can be found in the executive.jsp file, as shown in Example 6-7. Example 6-7 Using the Search function <table border=0 width=600 bgcolor=”#C6D1DC” cellpadding=3 cellspacing=0> <tr><td><font face=Arial size=2> <form action=”servlet/com.tivoli.managed.gui.report.servlets.SLMFilterSearch” method=GET> <%=rsc.getString(“CustomerSearchRequest”)%><br> <a href=”executive.jsp?<%=rowViewParam%>”<%=rsc.getString(“Customerviewall”) %></a> <br><br> <LABEL for=”execCustomerSearch”><%=rsc.getString(“CustomerSearch”)%></LABEL> <tr><td valign=top><font face=Arial size=2> <input type=text name=”fcm” size=22 id=”execCustomerSearch”> <input type=”submit” value=”<%=rsc.getString(“Search”)%><“> </form> As you may notice, fcm is defined for the Input field name, which means that a customer will be searched for. There are additional field names that may be specified when implementing this search function. Table 6-5 shows the available field names. You may also find this table in the Administrator’s Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835. Table 6-5 Available input field names for searching Searching for Input field name Customers fcm Resources frscm Customer orders fcom248 Introducing IBM Tivoli Service Level Advisor
  • 272. Searching for Input field name Realm names frmUsing maximum rows to displayAs shown in Figure 6-12 on page 234, the Reports results table includes afeature that allows the user to display a chosen number of rows per page. Thesesettings are set in the maximumRowsToDisplay.jsp file, as shown inExample 6-8.Example 6-8 The maximum rows to display Java code<%0 page contentType=”text/html; charset-UTF-8” %><%0 page import=”com.tivoli.managed.gui.repot.servlets.SLMReportJSPResources”%><%0 page import=”java.utilResourceBundle” %><%0 page import=”com.tivoli.managed.gui.report.servlets.SLMReportData” %><jsp:include page=”getFilters.jsp” flush=”true”/><%//Get the current page nameString currentPage = request.getParameter(“page”);String rowStr = request.getParameter(“row”);String valueType = request.getParameter(“fvt”);//for graph pagesString rowView = null;//get filtersSLMReportData repData = (SLMReportData)session.getAttribute(“filters”);String filters = null;if(repData != null)filters = repData.getFilters();if(valueType != null && !valueType.equals(**))filters = filters + “&fvt=”+valueType;//resourcesResourceBundle rsc = null;if (rsc == null) rsc = ResourceBundle.getBundle(“com.tivoli.managed.gui.report.servlets.SLMReportJSPResources”,request.getLocale());//Get row viewif(rowStr != null){rowView = request.getParameter(rowStr);}//display maximum row numbersint lastRowView = 50;int rowViewInt = 10;if(rowView!=null) Chapter 6. Service level Reports with ITSLA 249
  • 273. rowViewInt = Integer.parseInt(rowView); for(int i=10; i<=lastRowView; i=i+10){ if(rowViewInt==i) out.println(“<font size=2 face=Arial color=black>”+i+”</font> |”); else out.println(“<a href=”+currentPage+”?”+filters+”&”+rowStr+”=”+i+”>”+i+”</a> |”); }//end for You can call the maximumRowsToDisplay.jsp file from a main page, such as opCusotmerRanking.jsp, as shown below: <jsp:include page=”maximumRowsToDisplay.jsp?page=opCustomerRanking.jsp&row=rrow” flush=”true”/> This includes the available parameters to control the maximum number of rows to be displayed for various reports. This table can also be found in the Administrator’s Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835. Table 6-6 Available parameters for maximum rows to display Row parameter Defined parameter name Result Reports rsltrow Trend Reports trndrow Violations Reports viorow Graph grow (for graph data table) Cusotmer, order ID, resource, realm, SLA rrow type, and offering component6.4.2 Customizing the appearance of Reports There are many different options available when customizing the appearance features of the IBM Tivoli Service Level Advisor Reports. Whether you would like to include your own company logo or change the appearance of certain Reports buttons, the follow sections help you change the appearance of Reports to your liking.250 Introducing IBM Tivoli Service Level Advisor
  • 274. Using your own company logoIf you would like to replace the graphic that is provided at the top of the Web pagewith your own company logo, replace the SLMbanner1.gif line in Example 6-9with the name of your own graphic image.Example 6-9 HTML code for inserting a company logo<!---------------- Banner ---------------><table width=1000 height=78 border=0 cellspacing=0 cellpadding=0><tr><td align=top><img src=”SLMbanner1.gif” alt=”Banner”></table>Back and Next button substitutionYou have the option to change the appearance of the Back and Next buttons inReports. Replace the backButton.gif and nextButton.gif files with the graphic filesof your choosing, but keep the file names the same.Changing the appearance of the Reports results tableWhen viewing the Reports results, the actual results are organized withindifferent columns in a table. The names of these columns and the order in whichthey are displayed is controlled by a single Report servlet. You may alter thenames of these columns by including the new parameter name in thecustomer.jsp file. Table 6-7 includes the label parameters matched with theirassociated parameter names. You can also find this table and related informationin the Administrator’s Guide for IBM Tivoli Service Level Advisor Version 1.1,SC32-0835.Table 6-7 Customizable table column parameters Label parameter Parameter name Customer lcu Order ID lco Metric lmn Resource lrsc Offering component lst Schedule state lss Offering lso Detection date ldd Projected violation date lpvd Chapter 6. Service level Reports with ITSLA 251
  • 275. Label parameter Parameter name Breach value lbv Violation value lvv Violation date lvd Mean value lmv Graph lg Projected state lps State ls Number of trends ltn Actual value lmav Max (maximum metric value type) lmax (such as max in the results report under the Metric Value column) Avg (average metric value type) lavg Min (minimum metric value type) lmin %Error (confidence factor) lcf Evaluation time lget SLA type lsla Realm lrn Rank lrk Number of violations lvn Internal use only liu Start time lstt End time lett Frequency lfq Time zone ltz Details lsd Units lmu252 Introducing IBM Tivoli Service Level Advisor
  • 276. If you would like to change the Customer column heading to My Customer, locatethe customer.jsp file and at the bottom of the page, under the !----insert servletbelow----- heading, edit the lines seen in bold in Example 6-10.Example 6-10 Changing the default column name<jsp:include page=”/servlet/com.tivoli.managed.gui.report.servlets.SLMReport?qi=com.tivoli.managed.gui.report.servlets.SLMFilterRankQuery&di=com.tivoli.managed.gui.report.servlets.SLMFilterRankDisplay&filter=fco&link=custReportDetail.jsp&fontcolor=black&fontsize=2&titlefontsize=2&bgcolor=#EDEDEB&tablewidth=500&lcu=My+Customer”flush=”true”/>Denote a space in the changed column name with the + symbol.In addition to changing the names of the columns, you may also change theappearance of the actual results table. Whether you would like to change the fontsize, the font color, or even the table cell spacing, you may add these values tothe same line in the customer.jsp file as shown in Example 6-10 on page 253.Table 6-8 gives a listing of the available table properties that may be changed.Table 6-8 Customizable table properties Table property Parameter specified Default value Table background color bgcolor #EDEDEB Font size fontsize 2 Font color fontcolor Black Font face fontface Arial Title font size titlefontsize 2, always bold Title font color titlefontcolor Black Title font face titlefontface Arial Title background color titlebgcolor #CFDAE3 Table width tablewidth 100 percent Table border border 0 Table cell spacing cellspacing 2 Chapter 6. Service level Reports with ITSLA 253
  • 277. Table property Parameter specified Default value Table cell padding cellpadding 2 Follow the same convention as used in Example 6-10 on page 253 by using the & character to separate each property to append. Each separate line is actually contained within one long continuous line in the customer.jsp file, so the & character must be used to space each parameter entered, as shown below: &fontcolor=blue&cellspacing=0&tabelwidth=450 This information and more can be found in the Administrator’s Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835. Changing the appearance of the data graphs Just as you may change the appearance of the Reports results table, you may also alter the appearance of the data graphs that are displayed when selecting certain metric data from the Results table. Locate the graph.jsp file and follow the same alteration format as described previously by using the & character to separate each additional entry. Alterations to the graph are made under the !-------Graph Chart --------- section in the graph.jsp file. Table 6-9 displays the graph properties that may be customized. Table 6-9 Customizable graph properties Customized property Parameter for the property Chart area background chartAreaBg (for example, chartAreaBg=blue) Plot area background plotAreaBg (color name only) Chart background chartBg (color name only) Legend visible legendVisible (true or false; for example, legendVisible=true) Header text headerText (name of header; for example, headerText=graph+title) Graph encoder ge (png or jpeg) Grid visible gridVisible (true or false) Grid color gridColor (color name only) Chart type data1ChartType (area, bar, plot) Chart height chartHeight (integer; for example, chartHeight=400)254 Introducing IBM Tivoli Service Level Advisor
  • 278. Customized property Parameter for the property Chart width chartWidth (integer) There are a total of 13 colors to choose from when changing the graph properties. Below is a list of these colors, as also listed in the Administrator’s Guide for IBM Tivoli Service Level Advisor Version 1.1, SC32-0835: Black Blue Cyan Dark gray Gray Green Light gray Magenta Orange Pink Red White Yellow6.4.3 Alternative methods for authenticating users If you already have a user authentication method set up for your Web server, you can use a Java Bean to authenticate your users. If this is the case, the ITSLA Database will not be used for this purpose, and it will be up to you to determine how each user is matched with the appropriate view, consumer, portal page, and realm. In order to use a Java Bean for user authentication, perform the following steps: 1. With the user currently logged on to the Web server, provide the view, consumer, portal page, and realm values to the Java Bean. 2. Call the SLMBeanAuthentication servlet class by creating an HTML form button called View Reports. This form will maintain the appropriate level of user access while the user is signed in by using the view, consumer, portal page, and realm properties for user access control. You can find examples of these customization steps in the index2.jsp file, which is shipped with IBM Tivoli Service Level Advisor. Setting authentication values in a Java Bean The user authentication values can be set in a Java Bean by following the sample code provided in Example 6-11. Chapter 6. Service level Reports with ITSLA 255
  • 279. Example 6-11 Sample code for setting user authentication values <jsp:useBean id=”Login” class=”com.tivoli.managed.gui.report.servlets.SLMUserInfoImpl” scope=”session” /> <jsp:setProperty name=”Login” property=”consumer” value=”<%=consumer%>/> <!--- to set directly and assume that the value is restricted, the line will be like this: jsp:setProperty name=”Login” property=”consumer” vaue=”restricted”--> <jsp:setProptery name=”Login” property=”realm” value=”<%realm%>/> <jsp:setProtpery name=”Login” property=”view” value=”<%view%>/> <jsp:setProperty name=”Login” property=”portalPage” value=”<%=portalPage%>”/> In this example, the SLMUserInfoImpl class is called and passes the values for consumer, realm, portal page, and view. To set the property directly without using a variable, follow Example 6-12. Example 6-12 Setting the property directly <jsp:useBean id=”Login” class=”com.tivoli.managed.gui.report.servlets.SLMUserInfoImpl” scope=”session”/> <jsp:setProperty name=”Login”property=”view”value=”restricted “/> Sample code for HTML form button In order to create a View Reports button, follow the code in Example 6-13. Example 6-13 Creating a View Reports button <FORM action=”servlet/com.tivoli.managed.gui.report.servlets.SLMBeanAuthentication” method=POSI> <INPUT type=submit name=submit value=”<%rsc.getString(“ViewReports”)%>”> </FORM> When this button is clicked, the user name’s authentication values will be passed to the Java Bean and the authentication level for that user will be set for the current session. Whatever reports page is specified by the customer will then be displayed.256 Introducing IBM Tivoli Service Level Advisor
  • 280. 6.5 Viewing Reports with third-party software If you would like to view IBM Tivoli Service Level Advisor Reports results in a different viewing format than the one provided, there are a number of third-party reporting applications that can be used. By inserting different tables, graphs, and executive summaries into your report, you will be able to better understand how your IBM Tivoli Service Level Advisor environment is functioning. The following sections will introduce you to several third-party applications that the Redbooks team used and will provide you with examples of each. Before continuing, you must know that there are three default views provided by Reports for viewing results with the desired third-party software. These views are as follows: Resultview: Uses SLO results information to build a report. Violationview: Uses information gathered from all violations to build a report. Trendview: Trend-related information is used to build a report. The three third-party applications that were used for this redbook were BrioQuery Designer, Seagate’s Crystal Reports, and BusinessObjects. As a general rule, if you are not currently using one of these three applications, refer to the following: 1. Create a connection through your software to the ITSLA Database (DYK_CAT). 2. When asked to select the components to include in your report, select of the three views discussed previously, as shown in the list below: – Resultview – Violationview – Trendview 3. If you chose the Resultview, you may notice a component in that view labeled Evaluator Type. An average of all the average values is shown if the evaluator type is set to 4; if the evaluator type is 5, then you are viewing a sum of all the average values. 4. Using the desired format, create the report.6.5.1 Using BrioQuery Designer with Reports There are a number of options you may choose from when using BrioQuery Designer to create and view your reports. In the following sections, you will learn about the different features offered by BrioQuery Designer and how to create reports by using this tool. Chapter 6. Service level Reports with ITSLA 257
  • 281. Note: For the following sections, we used Brio Enterprise Version 6.0. BrioQuery Designer is just one component of the Brio.Enterprise package. Additionally, this section of the redbook is not meant to be used as a concise informational resource for the Brio product. For more information regarding your level of Brio products, please refer to the appropriate documentation that was shipped with the product. Required steps before report creation Before actually creating your report, there are a number of steps that must be performed. You must first create a connection to the DYK_CAT database, choose one of the available three views you wish to include in the query, and finally process that query so that you can create a report from its results. Each step is expanded on in the following sections. Creating a database connection The following steps describe how to create a database connection. 1. When first starting BrioQuery Designer, you will be presented with a screen asking you if you would like to create a new document or work with an existing document. Under the Create a New Document section, select the A New Database Connection File radio button and click OK. 2. The Database Connection Wizard will appear on the next screen, as shown in Figure 6-16. Assuming that you already have an ODBC connection to the ITSLA Database (DYK_CAT), under the What connection software do you want to use? section, select ODBC from the drop-down menu. Directly under that, in the What type of database do you want to connect to? section, choose DB2 from the drop-down menu and click Next.258 Introducing IBM Tivoli Service Level Advisor
  • 282. Figure 6-16 BrioQuery Database Connection Wizard3. The next screen will ask you to connect to the data source. You must supply the fields with your DB2 user name and password, along with the database you would like to connect to, which in this case will be DYK_CAT. The database selection is located in the Host drop-down menu, and the selections are chosen from your ODBC connection information. Click Next to continue.4. The Meta Connection Wizard screen appears next and asks you to choose between opening the wizard on the current connection or using a different connection. The On the Current Connection radio button is selected for you as default. Click Next.5. Accept the defaults on the next screen and click Next. The last screen will ask you to click Finish to save your settings as a connection file, which can be modified later if desired. This file is saved with a .oce extension. Click Yes when it asks if you would like to save the settings, and name the file something recognizable so that you will not forget later.Choosing a view and query processingAfter saving the database connection file, the Query screen will appear, asshown in Figure 6-17. Chapter 6. Service level Reports with ITSLA 259
  • 283. Figure 6-17 Query screen for DYK_CAT In the bottom left-hand corner, you will notice an expandable section labeled Tables, which contains all the tables located in the DYK_CAT database. Click the + sign to expand this section. Scrolling through the tables will reveal the three views described in “Viewing Reports with third-party software” on page 257. These views are located near the bottom of the selections. Follow the steps below to choose a view and to query that process. 1. Select either Resultview, Trendview, or Violationview and drag it to the Content window, as shown in Figure 6-18.260 Introducing IBM Tivoli Service Level Advisor
  • 284. Figure 6-18 Dragging Violationview to the Content window 2. After dragging the view (which is now considered a Topic) to the content window, you should see a list of items related to that view. As shown in Figure 6-18, there are 17 items related to the Violationview. Right click in the top of the view where the view name is located and select Add Selected Items. Each item located in the view’s list will appear at the top the screen in the Request section, as shown in Figure 6-19 on page 262. You can right click each of these items in the Request section and remove them if you do not want to include them in the query. Note: After adding all the selected items, we also added the Val item again to prepare for the chart we will create later. This item will appear as Val2 in the Request section at the top of the page. Reasons for doing this will be explained in “Creating a graph” on page 266. Chapter 6. Service level Reports with ITSLA 261
  • 285. Figure 6-19 Adding the selected items 3. If you would like to limit the information that will later be processed in the query, select the item in the view’s list, right click, and select Limit. You will then be presented with a Limit box for the item you selected. In this window, click the Show Values box to list the values associated with the selected item. For example, in Figure 6-20 on page 263 we only want to see the violations for one customer. After selecting and right clicking the Consumer Name item, we clicked the Show Values box to list the customers who have violations. From the list of customers, we selected the Home Banking customer so that only their violations will be processed in the query. After clicking OK, you should see in the top right-hand corner of the page the Limits link now appearing as Limits(1). You can click this link to display all the limits you have selected.262 Introducing IBM Tivoli Service Level Advisor
  • 286. Figure 6-20 Limiting the items for query processing4. You are now ready to process the query. At the top of the screen in the toolbar, click the Process button. After the processing has completed, you will receive a screen similar to the one shown in Figure 6-21 on page 264. There are a number of features to point out concerning this screen. – The results from your query will be displayed in the Contents window. – You can view all items that were included in the query in the bottom left-hand corner of the screen under Query. – Under Sections in the upper left-hand corner of the screen, you can toggle between the Query and Results views by clicking each. If you would like to limit your query even more, do so from the Query section. If you feel that you did not limit your query sufficiently before processing, in the Results section click inside the column you wish to limit, right click, and select Limit. You can then choose which values you wish to show in your report, as described in step 3 on page 262. You can also select the entire column and remove the ones you do not wish to view. Chapter 6. Service level Reports with ITSLA 263
  • 287. Figure 6-21 Query results for limited Violationview Choosing and creating your report After the query has been processed, you are now ready to choose the type of information that will be included in your report. At the top of the screen, clicking the Insert menu will provide you with a list of tools you can to use to compile a report. In this example, we will be creating a report on IBM Tivoli Business Systems Manager (TBSM) violations received for the Home Banking customer, which will include a report table and a vertical bar graph. Creating a report table Perform the following steps to create a new report.264 Introducing IBM Tivoli Service Level Advisor
  • 288. 1. To create your report, click the Insert menu at the top of the screen and select New Report. A screen similar to the one shown in Figure 6-22 will appear. Notice that in the upper left-hand corner of the screen under Sections, a Report section has appeared.Figure 6-22 New report screen 2. In the bottom left-hand corner of the screen you will see all the items listed from the query results. Drag the items you would like to include in the table to the appropriate panels at the bottom of the screen labeled Report Group1, Table Dimensions, and Table Facts. In our example, we chose to include the Consumer Name for Report Group 1, along with Metric Name, Viol Date, Val, and Breach Avg Val for the Table Dimensions. This table will include TBSM LOB state green metric violations received for the week of 04/23/02 for the Home Banking customer. Figure 6-23 on page 266 displays the resulting table. Chapter 6. Service level Reports with ITSLA 265
  • 289. Figure 6-23 Report results table 3. You may add any number of results items to the panels at the bottom of the screen. Any item added to the Table Facts panel will result in an additional row placed at the bottom of the table displaying an arithmetic function of that item. For example, you could include a sum of all Violations received or an average of the breach values. For our example, this was not necessary. Creating a graph You can also choose to include a graph in your report. For our example, we will construct a bar graph that corresponds with the values located in the report table that we just created. The steps needed to create a graph are listed below. 1. Click the Insert menu at the top of the screen and select New Chart. You will be taken to a blank screen with three panels located at the bottom labeled Y-facts, Z-categories, and X-categories. A Chart section will also appear in the upper left-hand corner of the screen under Sections.266 Introducing IBM Tivoli Service Level Advisor
  • 290. 2. You will find that creating the graph is similar to creating the report table, by dragging the items listed in the bottom left-hand corner of the screen to the appropriate panel. For our example, we placed Val in the Y-Facts panel, with Viol Date and Val2 in the X-Categories panel. Figure 6-24 displays the result.Figure 6-24 Two-dimensional graph Tip: Be sure to place an item with a value in the Y-Facts panel. Items placed in this panel will provide the bars with their values. The main reason a second Val item was added to the query was so that we could have one Val in the Y-Facts panel, while Val2 provides the violation values on the X axis. This is not necessary, but it helps add more description to the graph. Chapter 6. Service level Reports with ITSLA 267
  • 291. 3. The graph can also be made to appear three-dimensional by adding an item to the Z-Categories panel. In Figure 6-25 we added the Val2 item to make the graph three-dimensional.Figure 6-25 Three-dimensional graph 4. You can add text to the graph by double clicking each title. For example, when a graph is initially created, the title Chart will appear at the top the page. Double click this title and add the desired text in the text box. You can do this for each title that appears in the contents window. 5. The type of graph that is created can be changed by clicking the Format menu at the top of the page and selecting Chart Type. From there you can choose from a number of different types of charts. Including a graph into the report After you have finished constructing your graph, you may now integrate it into your report. Perform the following steps to add your graph to the report page.268 Introducing IBM Tivoli Service Level Advisor
  • 292. 1. Select the Results view under Section in the upper left-hand corner of the page. 2. In the Query box located in the bottom left-hand corner of the screen, scroll down until you notice an icon labeled Chart. Select Chart and drag it to the Contents window, directly under the reports table you created earlier. If the chart seems too small, you may resize it by clicking it and pulling the handles to the desired width and height. Double clicking the graph will take you back to the Chart view where you can make additional changes to the graph. These changes automatically show up in the Reports view. 3. You can now save and print the file. Each BrioQuery file will be saved with a *.bqy extension.6.5.2 Viewing Reports using Seagate Crystal Reports Seagate Crystal Reports provides you with the ability to include a number of different report and chart types to help enhance the viewing of your IBM Tivoli Service Level Advisor results. Creating a report The reporting format used by Crystal Reports is much different from the format implemented by BrioQuery and BusinessObjects. Included in this section are required steps to begin creating your report. Note: For our examples, we used Seagate Crystal Reports Version 7 Professional. If you are using a different version or need more information than what is supplied here, please consult the product documentation. 1. Open the Report Designer and click the New icon in the top left-hand corner of the screen. A screen labeled Report Gallery will open, providing you with a list of report experts that will help you design your report. Click the Custom button in the bottom right-hand corner of the screen. This will open another panel, shown in Figure 6-26 on page 270, allowing you to choose from different custom reports and data types. Click the SQL/ODBC button. Chapter 6. Service level Reports with ITSLA 269
  • 293. Figure 6-26 Report gallery with Custom button selected 2. The Log On Server box appears, from which you will need to choose the DYK_CAT ODBC data source and click OK. The contents of this window include sample sources created by Crystal Reports, along with the ODBC data sources you have defined on your machine. 3. If you have not already set up a connection to this database, you may be prompted for a user name and password. After entering these, the Choose SQL Table screen will appear. From this list you may choose one of the three views as described in 6.5, “Viewing Reports with third-party software” on page 257. For our example, we will choose the Violationview, as shown in Figure 6-27 on page 271. Click OK after choosing your view.270 Introducing IBM Tivoli Service Level Advisor
  • 294. Figure 6-27 Choose SQL Table window4. An Insert Fields box will appear in front of the report design page. Choose as many fields as you would like, and drag them to a position on the Report Design page. When dragging the fields, place them in the Details section of the page, as shown in Figure 6-28 on page 272. Their names will also appear in the Page Header section, which will appear as column headings after building the report. Click Close after inserting the desired fields. Chapter 6. Service level Reports with ITSLA 271
  • 295. Figure 6-28 Insert fields and report design page 5. You may adjust the section in the design page as necessary to make more or less room for the fields you just inserted. If you prefer to include only information for one customer or violations just for a specific day, select the field you just inserted, right click and choose Select Expert. In this box, as shown in Figure 6-29 on page 273, you have a wide variety of options to choose from when limiting your data. For example, if you would like to include only violations that were received over the weekend, choose the is one of option from the drop-down menu and then choose your dates in the second drop-down menu that appears. You may even choose other fields to limit by clicking the New button.272 Introducing IBM Tivoli Service Level Advisor
  • 296. Figure 6-29 Select Expert being used to limit the violation dates6. If you would like to place text in any of the other sections of the report, such as in the report header or report footer, you can use the text object feature by either clicking the icon in the toolbar (ab) or by selecting Insert -> Text Object. Drag the text box to the section where you would like to place the text. If your design page is now set up the way you want it, you can view a preview of your report by clicking the lightning bolt in the toolbar or pressing the F5 key. When you do this, a new tab will appear in the top left-hand corner of the design page, labeled Preview. Click this tab to see a preview of your report. An example is shown in Figure 6-30 on page 274. Chapter 6. Service level Reports with ITSLA 273
  • 297. Figure 6-30 The preview screen 7. If you do not like the way the data appears in the preview screen, you can go back to the design tab and readjust the columns. After making changes, refresh the data each time for your changes to take effect. Building a chart After refreshing the text portion of your report, you can now insert a chart. Follow the steps listed below to begin building a chart. 1. Click the Chart button in the toolbar or select Insert -> Chart. 2. The Chart Expert screen will appear, as shown in Figure 6-31 on page 275. From this screen you can choose from a variety of charts to insert. For our example, the bar chart was chosen.274 Introducing IBM Tivoli Service Level Advisor
  • 298. Figure 6-31 Chart Expert box3. There are five tabs located in the Chart Expert box. After selecting the type of chart you would like to use, click the Data tab to select what data you would like to include in your chart. Figure 6-32 on page 276 shows the Data tab of the Chart Expert box. To select the data to include, click the available field and click the arrow to the right of the box, depending on where you would like to move the field. The top box on the right side of the Data tab represents the X-axis. Data that is placed here should represent a category, such as consumer name or violation date. There is also a drop-down menu just above the box that provides you with two options: On change of and For each record. These selections determine how your values are plotted in the chart. For our example, we chose Consumer_Name and Viol_Date. The bottom box, labeled Show Value(s):, represents the Y-axis. Data that represents a value should be placed in this box. For our example, we chose Val, the violation value for average. If you do not want the data to be summarized, select the field you placed in the box and place a check-mark in the Don’t summarize values box. Chapter 6. Service level Reports with ITSLA 275
  • 299. Figure 6-32 The Data tab 4. On the Axes tab, you can decide how the chart displays each axis in terms of gridlines, data values, and number of divisions. 5. On the Options tab, chart customization features are displayed, allowing you to change the chart color, the way the data values are displayed, and the visibility and placement of the legend. The legend is useful when using dates for the data points. 6. You can add titles, subtitles, and footnotes to your chart on the Text tab. 7. After configuring your chart, click the OK button in the Chart Expert to view a preview of your chart. If you do not like the way it appears, you can right click the chart and go back to the Chart Expert to change the data values. A preview of our example appears in Figure 6-33 on page 277.276 Introducing IBM Tivoli Service Level Advisor
  • 300. Figure 6-33 Report preview screen 8. You will notice on the Design tab, that the chart is automatically placed in the Report Header section. If you would like to place this chart somewhere else, drag the chart to the desired section. You may need to resize the sections if this is the case.6.5.3 Using BusinessObjects with Reports The BusinessObjects product used in the IBM Tivoli Service Level Advisor environment is useful in consolidating the SLA violation data in an elaborated report form. In this section we provide some examples of how to integrate the BusinessObjects User module technology with IBM Tivoli Service Level Advisor data. The BusinessObjects platform allows you to elaborate the IBM Tivoli Service Level Advisor data in such a way to personalize the information to be used at different levels in the enterprise. Chapter 6. Service level Reports with ITSLA 277
  • 301. Business Object integration with ITSLA In order to integrate the BusinessObjects product with IBM Tivoli Service Level Advisor you have to create a BusinessObjects Universe. A Universe is a business-oriented mapping of the data structure found in databases, such as tables, columns, and joins, and can represent any specific application, system, or group of users. In the BusinessObjects User module, Universes enable end users to build queries from which they can generate and perform analysis and reports. Therefore, it is important to build the Universe in such a way as to obtain all the data needed to create the desired reports. Creating a Universe The following steps describe Universe creation: 1. In the Windows environment, select Start -> Programs -> BusinessObjects 5.1 -> Designer. 2. Click the Quick Design Wizard icon on the control bar. The Quick Design Wizard screen opens. Click Begin. Figure 6-34 Define Universe Parameters window278 Introducing IBM Tivoli Service Level Advisor
  • 302. 3. The Quick Design Wizard - Step 1 of 4 window opens, as shown in Figure 6-34. In this dialogue window you have to enter the Universe name (we chose the name Report for SLA Violations) and choose an existing database connection or create a new one. We created a new connection to the ITSLA Database (DYK_CAT), which contains the SLA violations data. To create a new connection, perform the following steps: a. Click New. b. From the Add a Connection dialogue window, Select the IBM DB2 CAE network driver and click OK to define the parameters for the connection. Note: In our case, BusinessObjects is installed on the same machine where the ITSLA Database is located. View the BusinessObjects documentation for information regarding the software and configuration requirements for the connection to the database.Figure 6-35 Parameters of database connection window c. The IBM DB2 CAE window opens, as shown in Figure 6-35. Supply the following fields with the relevant connection information for the ITSLA Database: • Choose a name for the connection. Chapter 6. Service level Reports with ITSLA 279
  • 303. • From the Database engine drop-down menu select DB2 UDB v7. • Insert the user name and the password of an administrative user of the ITSLA Database (we chose the user db2admin). • Select DYK_CAT from the Data source name field and click Test to test the connection. If the connection is successful, click OK. Figure 6-36 Second step of Universe creation process 4. Click Next. The Create Initial Classes and Objects window opens, as shown in Figure 6-36. In this step you select the tables, views, and columns that you want to use for your reports. After expanding the DB2ADMIN folder, click RESULTVIEW, TRENDVIEW, and VIOLATIONVIEW. These views contain the violation and trend data for ITSLA. Click Add>> to choose the tables as Universe classes and objects. Click Next. 5. The Create Measure Objects window opens. In this step you are asked to create calculations (called measure objects) that will be useful in defining and creating your report. For example, if you want to know the number of violations of the maximum value defined for the Service Levels Objectives, do the following steps: a. In the VIOLATIONVIEW table, select the MAX_VAL column. b. Click Count>>. c. On the left side of the window, the measure object Number of Max Val displays.280 Introducing IBM Tivoli Service Level Advisor
  • 304. d. Create as many measure objects as your report requires. We chose to also insert the measure object Number of Val.6. Select Next and then click Finish to complete the Universe creation.Report creation examplesIn the following sections, we will create two example reports usingBusinessObjects, which will show the capability of the BusinessObjects/ITSLAintegration.First exampleFor our first example, we would like to find out how many violations for a servicelevel objective maximum value per customer occurred since the beginning of theservice. The production of this report is achieved through the following steps:1. Open the BusinessObjects interface, selecting Start -> Programs -> BusinessObjects 5.1 -> BusinessObjects. The BusinessObjects window opens, and the create reports wizard automatically starts.2. Choose the Generate Standard Reports radio button and click Begin.Figure 6-37 Select Universe as data access Chapter 6. Service level Reports with ITSLA 281
  • 305. 3. The Specify Data Access window opens, as shown in Figure 6-37. In this dialogue window you specify in which way you would like to access the data. We chose to access the data by using the Universe we just created. 4. The Select Universe dialogue window opens. We select the Report for SLA violations Universe that we created in “Business Object integration with ITSLA” on page 278. Click Finish.Figure 6-38 Query Panel - Report for SLA violations Universe 5. The Query Panel of the chosen Universe displays, as shown in Figure 6-38. The Query Panel allows you to build the SQL queries to access data. You can find the classes and objects of the Universe on the left-hand side of the screen. 6. Expand the Violationview folder, select the Consumer Name and Viol Date objects, and double click them. Expand the Reports for SLA violations Measures folder, select Number of Max Val calculation, and double click it. Note: Number of Max Val is the calculation defined during the Universe creation, and it is the number of violations of a maximum value set for the service level objectives.282 Introducing IBM Tivoli Service Level Advisor
  • 306. 7. Click Run. The BusinessObjects default report displays, as shown in Figure 6-39 on page 283.Figure 6-39 Business Object Report for max violations 8. To customize the report, right click Report 1 in the lower left-hand side of the window and select Apply Templates, as shown in Figure 6-40 on page 284. Chapter 6. Service level Reports with ITSLA 283
  • 307. Figure 6-40 Apply templates to report 9. When the Apply a Template window opens, you must select one of the templates. The BusinessObjects product allows you to easily customize the graphics. We have obtained, with some customization, the report shown in Figure 6-41 on page 285.284 Introducing IBM Tivoli Service Level Advisor
  • 308. Figure 6-41 BusinessObject customized report The created report can be saved in a BusinessObjects format, an HTML document, or as a PDF file. Second example In this example, we show how to obtain a report for a single customer, focusing on which component (in the customer order) has the highest number of SLA violations. Execute steps 1 through 5 from the previous “First example” on page 281. The Query Panel displays, as shown in Figure 6-38 on page 282. Execute the following steps to customize the report: 1. Expand the ViolationView folder, select and then double click the following objects: Consumer Name, Component Name, Viol Date Val objects. Expand the Reports for SLA violations Measures folder and double click the Number of Val object. Chapter 6. Service level Reports with ITSLA 285
  • 309. 2. If you would like to initiate a query on a specific customer, you must create a condition. To create a condition execute the following steps: a. Drag and drop the Consumer Name object to the Conditions window, as shown in Figure 6-42.Figure 6-42 Create a condition in a BusinessObjects query b. In the Operators window on the left, double click the Matches pattern operator. From the Operands window, double clicking Show list of values will display a list of customer names, as shown in Figure 6-43 on page 287. We chose the Home Banking consumer name. Click OK. By creating this condition, the query retrieves data belonging only to the Home Banking consumer.286 Introducing IBM Tivoli Service Level Advisor
  • 310. Figure 6-43 List of consumer names3. Click Run to execute the query. The BusinessObjects window displays, as shown in Figure 6-44 on page 288. Chapter 6. Service level Reports with ITSLA 287
  • 311. Figure 6-44 BusinessObjects window 4. You may customize your report in this window. The information contained within this report refers to the violations received for a sole customer from only one component. You will notice in Figure 6-44 that the Home banking LOB component has been selected, along with the Val object, which indicates the percentage of uptime for the Home banking application.288 Introducing IBM Tivoli Service Level Advisor
  • 312. 7 Chapter 7. Performance maximization techniques IBM Tivoli Service Level Advisor is dependent on a number of supporting applications and components that need to be tuned up for proper performance. This chapter gives tips and hints for performance enhancement of critical components and supporting applications of an IBM Tivoli Service Level Advisor environment. The focus regarding performance tuning discussed in this chapter are for the following components: ITSLA Database Server IBM DB2 Universal Database Enterprise Edition IBM WebSphere Application Server IBM HTTP Server Tivoli Presentation Services Supported Operating Systems© Copyright IBM Corp. 2002 289
  • 313. 7.1 Initial considerations The following sections provide performance tuning tips for small, medium, and large configurations. As these may not be the best settings for your environment, a suggested approach would be to use these values as a starting point and then to monitor system performance, making changes where necessary. For the purposes of this chapter, a small, medium, and large environment is defined as described in Table 7-1.Table 7-1 Definition of small, medium, and large ITSLA environment ITSLA components Small Medium Large Customers 10 100 500 Realms 1 10 20 Offerings 3 25 50 Schedules 10 50 100 Customer orders 100 2000 5000 Metric evaluators 100 4000 10000 Metric evaluations 300 12000 30000 Component types 10 10 10 Component resources 100 1000 5000 For more information on tuning your respective applications, refer to the following publications and URLs: 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 http://www.db2mag.com/db_area/archives/2001/q4/hayes.shtml290 Introducing IBM Tivoli Service Level Advisor
  • 314. 7.2 ITSLA Database Server tuning considerations In order to prevent database connection failure errors on the ITSLA Database Server, you may need to change the value of the maxConnections parameter. This value should be equal to or less than the MAXAGENTS value defined in the database schema. In order to find the MAXAGENTS value, issue the following command from a DB2 command line: db2 get dbm cfg | grep MAXAGENTS For all operating systems, the maxConnections value is defined in the datasource properties file in the following locations, with a default value set to 25: For the ITSLA Server sdc datasource /$SLM_BASEDIR/cfg/default/com/tivoli/managed/spi/host_name/ds/sdc/.properti es For the ITSLA Server dmt datasource /$SLM_BASEDIR/cfg/default/com/tivoli/managed/spi/host_name/ds/dmt/.properti es For the Presentation Services Server sdc datasource /PS_DIR/cfg/fwp_ps/com/tivoli/managed/spi/host_name/ds/sdc/.properties7.3 IBM DB2 Performance tuning considerations Depending on the size of your environment, there are many options available when tuning your IBM DB2 Universal Database Enterprise Edition servers’ performance. Follow the recommendations given in the following sections to help maximize your DB2 server’s potential.7.3.1 Small environments If your environment can be categorized as a small environment according to Table 7-1 on page 290, consider making the following changes to your IBM DB2 Universal Database Enterprise Edition servers: Specify the amount of memory allocated for the database system monitor data, in 4 KB pages: db2 update dbm cfg using mon_heap_sz 50 Change the average number of active applications connecting to the DYK_CAT database: db2 connect to dyk_cat user DB2_user using DB2_password db2 update db cfg for DYK_CAT using avg_appls 5 Chapter 7. Performance maximization techniques 291
  • 315. Specify the number of asynchronous page cleaners for the DYK_DM database: db2 connect to dyk_dm user DB2_user using DB2_password db2 update db cfg for DYK_DM using num_iocleaners 2 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. db2 update db cfg for DYK_DM using logfilsiz 2500 db2 update db cfg for DYK_DM using logprimary 10 db2 update db cfg for DYK_DM using logsecond 40 For more information on the database and database manager parameter configurations, refer to DB2 UDB Command Reference Version 7, SC09-2951.7.3.2 Medium environments If your environment is categorized as a medium-sized environment according to Table 7-1 on page 290, consider making the changes listed below to your IBM DB2 Universal Database Enterprise Edition servers. In a medium environment, it is also recommended that you take advantage of multiple hard disks, which will allow you to define multiple ioservers and iocleaners. Specify the amount of memory allocated for the database system monitor data, in 4 KB pages: db2 update dbm cfg using mon_heap_sz 80 Make the following changes to the DYK_CAT database configuration: db2 connect to dyk_cat user DB2_user using DB2_password db2 update db cfg for DYK_CAT using avg_appls 5 db2 update db cfg for DYK_CAT using dbheap 10000 db2 update db cfg for DYK_CAT using sortheap 8000 db2 update db cfg for DYK_CAT using num_iocleaners 6 db2 update db cfg for DYK_CAT using num_ioservers 5 db2 update db cfg for DYK_CAT using dft_prefetch_sz 32 db2 alter bufferpool IBMDEFAULTBP size 25000 Make the following changes to the DYK_DM database configuration: db2 connect to dyk_dm user DB2_user using DB2_password db2 update db cfg for DYK_DM using dbheap 2000 db2 update db cfg for DYK_DM using num_iocleaners 5 db2 update db cfg for DYK_DM using num_ioservers 4292 Introducing IBM Tivoli Service Level Advisor
  • 316. db2 update db cfg for DYK_DM using dft_prefetch_sz 32 db2 alter bufferpool IBMDEFAULTBP size 10000 db2 alter bufferpool DM_BUFF2 size 10000 db2 alter tablespace DM_RGLR prefetchsize 64 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. db2 connect to dyk_dm user DB2_user using DB2_password db2 update db cfg for DYK_DM using logfilsiz 2500 db2 update db cfg for DYK_DM using logprimary 10 db2 update db cfg for DYK_DM using logsecond 118In order to optimize your IBM DB2 Universal Database Enterprise Editionenvironment for querying, perform the following:1. Execute the runstats and reorgchk commands on the DYK_DM 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. For more information on these two commands, refer to Chapter 8, “Troubleshooting the ITSLA” on page 299.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.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 CPUs ability to process it, thus 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: 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: Chapter 7. Performance maximization techniques 293
  • 317. db2 update db cfg for DBNAME using DFT_DEGREE X#7.3.3 Large environments If your environment is categorized as a large environment according to Table 7-1 on page 290, follow the recommendations in “Medium environments” on page 292, and make the following additional changes: Make the following changes to the DYK_DM database configuration: db2 alter bufferpool STG_BUFF size 1000 db2 alter bufferpool IBMDEFAULTBP size 10000 Make the following change to the TWH_CDW database configuration: db2 alter tablespace USERSPACE1 prefetchsize 64 Enable parallel I/O for every table space by issuing the following command: db2set DB2_PARALLEL_IO=* In addition to these configuration changes, you may also want to consider assigning multiple physical hard disks to the IBM Tivoli Service Level Advisor databases. Notes on DB2 and large systems The DYK_DM default log file size will support up to 450 k data points. When running large ETL extracts over 450 k data points, be sure to increase the amount of log file space (1130 bytes per data point). Each data point in DYK_DM increases the size of the database by approximately 500 bytes, but during ETL processing, the size may increase by as much as 2500 bytes per data point being extracted. For more information regarding the topics found in the DB2 performance tuning section, refer to the following manuals: 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-29517.4 IBM WebSphere performance tuning The default values and setup of IBM WebSphere Application Server are suitable for small environments, and no changes are necessary. For medium and large environments, we recommend that you change the value of the parameter maximumHeapSize to 768 MB. This value is defined in the server-cfg.xml file, which is located in the /$WAS_HOME/config directory.294 Introducing IBM Tivoli Service Level Advisor
  • 318. We also recommend that you follow the instructions provided in the IBM WebSphere Application Server product documentation.7.5 IBM HTTP Server performance tuning For small, medium, and large configurations, we recommend that you change the following options in the httpd.conf file. httpd.conf is located in the /http_server_dir/conf directory: Example 7-1 http.conf parameters KeepAlive Off MinSpareServer 2 MaxSpareServer 10 StartServers 2 MaxClients 1507.6 Presentation Services Web Console tuning Depending on the size of your environment, consider making the changes as listed below. For a small environment, the provided default values are appropriate and no change is recommended.7.6.1 Medium environments For medium environments, we recommend that you set the maximum heap size to 512 MB by performing the following, depending upon your operating system: On a Windows platform: a. Select Start -> Run, and type in regedit in the Run box. b. From the regedit screen, navigate through the path HKEY_LOCAL_MACHINE -> SYSTEM -> CurrentControlSet -> Services -> pc_wc -> Parameters. c. Double click the jvmOption8 value and change it to -Xmx512m. Chapter 7. Performance maximization techniques 295
  • 319. On a UNIX platform: a. Locate the wc.sh file in the /PS_Dir/bin/private/generic_unix directory path. b. Change the $JVMARG = $JVMARG -Xmx384m value to $JVMARG = $JVMARG -Xmx512m.7.6.2 Large environments For large environments, we recommend that you set the maximum heap size to 768 MB by performing the following, depending upon your operating system: On a Windows platform: a. Select Start -> Run, and type in regedit in the Run box. b. From the regedit screen, navigate through the path HKEY_LOCAL_MACHINE -> SYSTEM -> CurrentControlSet -> Services -> pc_wc -> Parameters. c. Double click the jvmOption8 value and change it to -Xmx768m. On a UNIX platform: a. Locate the wc.sh file in the /PS_Dir/bin/private/generic_unix directory path. b. Change the $JVMARG = $JVMARG -Xmx384m value to $JVMARG = $JVMARG -Xmx768m.7.7 Operating system performance tuning Depending on your operating system, consider making the following changes to enhance the performance of your IBM Tivoli Service Level Advisor environment. As we have only worked with Windows and AIX environments in the ITSO lab, we do not provide performance suggestions for the other supported platforms. For additional information on performance optimizations, refer to the official operating system documentation.7.7.1 Windows environments If you are using a Windows NT or Windows 2000 server for the ITSLA Reports Server with IBM WebSphere Application Server, you can significantly improve performance by optimizing your system traffic instead of file sharing.296 Introducing IBM Tivoli Service Level Advisor
  • 320. Perform the following steps to make these changes: 1. Navigate through the path Start -> Settings -> Control Panel -> Network and Dial-up Connections -> Local Area Connection. 2. Click Properties on the Local Area Connection screen, and select File and Printer Sharing for Microsoft Networks. 3. Select the option Maximize data throughput for networking applications.7.7.2 AIX environments In order to enable large file support, ensure that the Soft FILE size value is set to -1 for the IBM DB2 Universal Database Enterprise Edition administrative user. This parameter defines the largest soft file size, in 512-byte blocks, that this user can create or extend when invoking a process. Perform the following steps to make this change: From the SMIT menu, navigate through the path Security & Users -> Users -> Change/Show Characteristics of a User. Type in the name of the IBM DB2 administrative user in the entry field. Scroll down to the Soft FILE size line and change the value listed to -1. Chapter 7. Performance maximization techniques 297
  • 321. 298 Introducing IBM Tivoli Service Level Advisor
  • 322. 8 Chapter 8. Troubleshooting the ITSLA During the course of setting up and configuring an IBM Tivoli Service Level Advisor environment, you may encounter various error codes and situations that could add significant time to deployment of this solution. This chapter’s intent is to address the potential problems one may come across and to provide solutions that will remedy these issues. Some of this information can be found in the numerous documents included with the product, but all have been included in this redbook to provide an all-in-one reference point. The main topics of discussion concerning possible trouble areas are as follows: IBM DB2 Universal Database Enterprise Edition Tivoli Enterprise Data Warehouse IBM WebSphere Application Server IBM Tivoli Service Level Advisor IBM Console TEDW Source ETLs IBM Tivoli Service Level Advisor Reports© Copyright IBM Corp. 2002 299
  • 323. 8.1 IBM DB2 Universal Database Enterprise Edition At the core of the IBM Tivoli Service Level Advisor lies the IBM DB2 Universal Database Enterprise Edition. In this section you will find pertinent information that will help you install, configure, and administer your IBM DB2 environment.8.1.1 Installation and configuration This section includes troubleshooting hints and tips that may be useful when installing and configuring IBM DB2 Universal Database Enterprise Edition. User and group setup Prior to installing IBM DB2 on UNIX systems, be sure to set up the IBM DB2 administrative user and group. The group should include the database administrator, root, and sys users. To not be confusing, the IBM DB2 administrative user name should be indicative of its purpose and should have the newly created IBM DB2 group assigned as its primary group. IBM DB2 Java Database Connectivity (JDBC) levels The JDBC 1.1 drivers are loaded by default during the IBM DB2 installation. When implementing an IBM Tivoli Service Level Advisor environment, JDBC 2.0 drivers are required. If the IBM DB2 server and client drivers are at different levels, unexpected results may occur. To verify whether the correct JDBC drivers are being used, perform the following steps for your respective operating system: For Windows, navigate to the DB2_DIRjava directory, where DB2_DIR is the IBM DB2 location, and note the size of the db2java.zip file. If the size of the file is 1,347 KB, you are running JDBC level 2.0. If the file size is equal to 1,132 KB, then JDBC level 1.0 is installed and you must upgrade to JDBC 2.0. Refer to “Manually updating the JDBC level” on page 301 for more information. For UNIX, log in as the database instance owner and source db2profile located in the DB2_INST_DIR/sqllib directory, where DB2_INST_DIR is the instance home of the ITSLA Databases. Check the CLASSPATH variable by running the following command: echo $CLASSPATH If DB2_INST_DIR /sqllib/java12/db2java.zip is included in the command output, the JDBC level is 2.0. If DB2_INST_DIR/sqllib/java/db2java.zip is located in the command output, you are running JDBC level 1.0 and must update to JDBC level 2.0. Refer to Section , “Manually updating the JDBC level” on page 301 for more information.300 Introducing IBM Tivoli Service Level Advisor
  • 324. Manually updating the JDBC levelThe JDBC level is automatically updated when IBM Tivoli Service Level Advisoris installed. If, after following the above steps your JDBC level is still at level 1.0,perform the following steps, dependent upon the operating system, to update toJDBC level 2.0. For Windows, issue the following command from the DB2_DIRjava 12 directory, where DB2_DIR is the IBM DB2 installation location: usejdbc2 The correct version of db2java.zip should now be copied into the DB2_DIRjava directory. For UNIX, find the userprofile script in the DB2_DIR/sqllib directory and add the following line: . DB2_DIR/sqllib/java12/usejdbc2 If the userprofile script does not exist, add the above line to the end of the db2profile script located in the DB2_DIR/sqllib directory.After you have completed the above steps, run the steps described in “IBM DB2Java Database Connectivity (JDBC) levels” on page 300 to verify that the JDBClevel was updated correctly.Sun Solaris specific changesIf the IBM DB2 server is being installed on a Sun Solaris system, additionalchanges will have to be made to the /etc/system file in order for the databaseserver and client to function correctly.The values that need to be changed on the Solaris IBM DB2 client are listed inTable 8-1.Table 8-1 /etc/systems parameters on Sun Solaris Parameter Value msgsys:msginfo_msgmax 65535 msgsys:msginfo_msgmnb 65535 msgsys:msginfo_msgseg 8192 msgsys:msginfo_msgssz 16 Chapter 8. Troubleshooting the ITSLA 301
  • 325. There are a couple of points that need to be made concerning the provided chart. First, the parameters msgsys:msginfo_msgmax and msgsys:msginfo_msgmnb must be set to 65535 or higher. It is very important that the chart is followed exactly or fatal errors may occur to the Solaris system. Secondly, in order for these changes to take effect, the system must be rebooted. In order to update these values, the appropriate lines must be added to the /etc/system file. The appropriate command syntax is given below: set parameter_name=value Where parameter_name represents the parameter you want to change and value is the number you would like to assign to that parameter. To set the parameter msgsys:msginfo_msgmnb to a value of 65535, add the following line to the end of the /etc/system file: set msgsys:msginfo_msgmnb = 65535 The values that must be added to a Solaris IBM DB2 server are slightly different and are based on the amount of memory installed. Table 8-2 gives the information to be used when installing the IBM DB2 Universal Database on Solaris.Table 8-2 Parameters for a Sun Solaris IBM DB2 server Kernel parameter 64 - 128 MB 128 - 256 MB 256 - 512 MB 512 MB + msgsys:msginfo_msgmax 65535 65535 65535 65535 msgsys:msginfo_msgmnb 65535 65535 65535 65535 msgsys:msginfo_msgmap 130 258 258 258 msgsys:msginfo_msgmni 128 256 256 256 msgsys:msginfo_msgssz 16 16 16 16 msgsys:msginfo_msgtql 256 512 1024 1024 msgsys:msginfo_msgseg 8192 16384 32768 32768 shmsys:shminfo_shmmax 67108864 134217728 268435456 536870912 shmsys:shminfo_shmseg 16 16 16 16 shmsys:shminfo_shmmni 300 300 300 300 semsys:seminfo_semmni 128 256 512 1024302 Introducing IBM Tivoli Service Level Advisor
  • 326. Kernel parameter 64 - 128 MB 128 - 256 MB 256 - 512 MB 512 MB + semsys:seminfo_semmap 130 258 514 1026 semsys:seminfo_semmns 256 512 1024 2048 semsys:seminfo_semmnu 256 512 1024 2048 semsys:seminfo_semume 50 50 50 50 The values for the shmsys:shminfo_shmmax parameter should be set to the suggested value in the given table or 90 percent of the physical memory in bytes, whichever is higher. For example, if you have 512 MB of physical memory in your Solaris system, set the shmsys:shminfo_shmmax parameter to 48183821 (512 * 0.9 * 1024 * 1024). To set the values for the given parameters, use the syntax given below in the /etc/system file: set shmsys:shminfo_shmmax = 184968806 Remember to reboot the system in order for the kernel parameter changes to take effect. Instance creation failure on UNIX platforms You may create the IBM DB2 instance manually if you receive an error while creating the instance during the initial IBM DB2 setup on UNIX systems. Perform the following steps in order to manually create the IBM DB2 instance: 1. Verify that the IBM DB2 administrative user and group have been created successfully with the appropriate privileges. 2. Depending on your operating system, change to the following directory: – For AIX: /usr/lpp/db2_07_01/instance – For Solaris: /opt/IBMdb2/V7.1/instance – For Linux: /usr/IBMdb2/V7.1/instance 3. Issue the following command, where dbadmin_name is the name of the database administrative account, and new_instance_name is the name of the new instance, which should be identical to the db2admin_name parameter: db2icrt -a SERVER|CLIENT -u db2admin_name new_instance_name8.1.2 Databases creation This section includes error codes and messages that may be encountered when attempting to create an IBM Tivoli Service Level Advisor database or when trying to connect to an existing database. Critical information concerning the following error messages can be found in the dyk_cat.log and dyk_dm.log files. Chapter 8. Troubleshooting the ITSLA 303
  • 327. Failure when running database creation scripts The following errors may be seen during database creation. SQL1005N message The error message is as follows: SQL1005N: The database alias already exists in either the local database directory or system database directory. Before trying to re-add the databases with the provided scripts, perform the following steps: 1. Run the following command from the IBM DB2 command line: db2 list db directory 2. If either or both the DYK_CAT and DYK_DM databases are not included in the listing, perform with the following steps: a. Issue the following command, where missing_db is the missing database and any_db is a generic catalog entry: db2 catalog db missing_db as any_db b. Make sure the any_db you catalogued was created successfully by running the following command: db2 list db directory c. After you verify that the catalog was successful, drop the database: db2 drop db any_db d. If you receive a failure when attempting to drop the database, uncatalog the database and then terminate all connections: db2 uncatalog db any_db db2 terminate 3. Attempt to run the database creation scripts again. SQL1032N message The error message is as follows: SQL1032N: No start database manager command was issued SQLSTATE=57019 This error usually means that the database manager is currently not operative. Attempt to start the IBM DB2 server by issuing the db2start command. SQL1403N message The error message is as follows: SQL1403N: The username and/or password supplied is incorrect SQLSTATE=08004304 Introducing IBM Tivoli Service Level Advisor
  • 328. If the user name and password used during the database creation wereincorrect, or if the user does not have the appropriate privileges to run thecreation scripts, you may receive this error. Check the user name and passwordcombination, or check the user’s privileges before running the creation scriptsagain.Connecting to databasesWhen attempting to connect to the IBM Tivoli Service Level Advisor databases,you may encounter the error codes or messages in the following section. If theprovided solutions do not resolve the problem, please refer to the DB2 UDBTroubleshooting Guide Version 7, GC09-2850.SQL1224N messageThis error code can contain many different meanings within an IBM Tivoli ServiceLevel Advisor environment. Typically, this error code indicates that all sharedmemory segments for IBM DB2 have been exhausted. You may also see thiserror if any of the IBM Tivoli Service Level Advisor components are installed onthe same machine as the ITSLA Database Server component. The meaning ofthis error code differs if the IBM DB2 server is located on an AIX or Solarissystem.If you get the SQL1224N message on AIX, you may need to configure IBM DB2to use extended shared memory if the IBM Tivoli Service Level Advisordatabases reside on the same machine as any of the other IBM Tivoli ServiceLevel Advisor installation options. To enable extended shared memory on AIX,perform the following steps:1. Add EXTSHM=ON to the /etc/environment file.2. Run the following command from an IBM DB2 command line: db2set DB2ENVLIST=EXTSHM3. Add the following lines to sqllib/db2profile: EXTSHM=ON export EXTSHM4. Reboot the machine for the changes to take effect.If you get the SQL1224N message on Solaris, an incorrect configuration on theSolaris database server may exist. Use Table 8-2 on page 302 to confirm thecorrect kernel parameter values in the /etc/system file. These values must beentered exactly as shown in order for IBM DB2 to function as expected. Moreinformation on these values can be found in DB2 UDB Quick Beginnings forUNIX Version 7, GC09-2970. Chapter 8. Troubleshooting the ITSLA 305
  • 329. SQL30081N message When attempting to connect to remote IBM Tivoli Service Level Advisor databases, this error code indicates that the IBM DB2 client or server is not set up correctly to communicate with other IBM DB2 systems. The steps below are provided to help troubleshoot the above error message. 1. Verify that the IBM DB2 system to be reached can be pinged by the DNS host name and IP address. 2. If a connection is still unable to be established, issue the following commands to ensure that the IBM DB2 server is functioning properly: a. From a IBM DB2 command line, run the following command: db2 get dbm cfg Check the SVCENAME parameter in the above command’s output. If no value exists, more than likely the instance was created manually, and there is no value associated with IBM DB2 in the services file. If there is a value associated with SVCENAME, continue on to step b. The services file is located in the following areas, dependent upon operating system: • For Windows, WIN_DIRsystem32driversetc. • For UNIX, /etc directory. If there is no value in the services file, add the following lines to the end of the file: db2cinstance_name 50000/tcp #Connection port for instance_name db2iinstance_name 50001/tcp #Interrupt port for instance_name For example, if your instance name is db2admin, the first line would look like this: db2cdb2admin 50000/tcp #Connection port for db2admin The interrupt line would follow the same format as the connection line, with only the port being changed. Below is an example of the interrupt line: db2idb2admin 50001/tcp #Interrupt port for db2admin After adding the appropriate lines to the services file, you will need to switch to the IBM DB2 administrative user and issue the following command: db2 update dbm cfg using svcename connection entry in services file For example, if your connection line entry was db2cdb2admin, the command would be as follows: db2 update dbm cfg using svcename db2cdb2admin306 Introducing IBM Tivoli Service Level Advisor
  • 330. After issuing the above command, the IBM DB2 instance must be stopped and restarted. The instance should now be listening on TCP/IP port 50000.b. Search on the port assigned to IBM DB2 in the services file to verify that no other application is using the same port. You may check the port’s status by using the following command: netstat -a |grep port_number If any application is found utilizing the IBM DB2 port specified in the services file, there are a number of options available to resolve this issue: i. End the service that is using the port. ii. Reboot the machine to clear the port from use. iii. Choose another port and configure IBM DB2 to use that port following the instructions above. If you do decide to configure another port for IBM DB2, remember to delete the old entries in the services file, as conflicting services will cause IBM DB2 to function improperly.c. After the above steps have been completed and verified, check the DB2COMM environment variable by issuing the following command from a IBM DB2 command line: db2set Output from this command should contain a number of IBM DB2 environment variables. The DB2COMM variable is specific to IBM DB2 communication and is the variable to be searched for in the db2set command’s output. You should see DB2COMM=TCPIP (if TCP/IP is the communication protocol being used). If the correct information is not provided in the output, run the following command from the same window: db2set DB2COMM = TCPIP This will set the IBM DB2 communication protocol to TCP/IP. If you are using another protocol, check the DB2 UDB Command Reference Version 7, SC09-2951, for more details.d. Stop and restart the IBM DB2 server using the following commands: db2 stop force db2startIf you have set everything up correctly, a SQL1063N message should befound after the IBM DB2 server has been restarted. If you do not see thismessage, and instead see a SQL1054N message in your logs, your IBM DB2server is still not functioning properly. Refer back to the above steps andrecheck the values entered, or consult DB2 UDB Administration Guide:Implementation Version 7, SC09-2944, for additional assistance. Chapter 8. Troubleshooting the ITSLA 307
  • 331. IBM Console or Reports user interface unresponsive There may be a IBM DB2 connection problem if no control is returned when selecting links in either the IBM Console or Reports. Whenever network connectivity is lost, the IBM DB2 client may appear to be hung when trying to communicate with the IBM DB2 server. Try to ping the IBM DB2 server to verify connectivity by issuing the following command: ping db2_server_hostname If you are unable to ping the server, contact the appropriate system administrator for additional assistance, or refer to the TCP/IP Problems section in the DB2 UDB Troubleshooting Guide Version 7, GC09-2850.8.1.3 Administration issues This section includes numerous errors one may receive while administrating the IBM DB2 Universal Database Enterprise Edition environment and covers different scenarios to help improve the performance of your IBM DB2 server. Verifying ODBC data sources If you have not done so already, run the following command from a IBM DB2 command line to verify the creation of the ODBC data sources for the IBM Tivoli Service Level Advisor databases: db2 list system odbc data sources The DYK_CAT and DYK_DM databases should be included in the above command’s output. If they are not listed, you can create the data sources manually, as described in 4.4.6, “Configuring the ODBC connections” on page 103. To further verify the successful creation of the ODBC data sources, attempt to connect to the IBM Tivoli Service Level Advisor databases by issuing the following command for each database: db2 connect to db_name user userid using password Where db_name is either DYK_CAT or DYK_DM, userid is the IBM DB2 administrative user name, and password is the IBM DB2 administrative user’s password.308 Introducing IBM Tivoli Service Level Advisor
  • 332. If errors are received when running the above commands, verify each of thefollowing steps: Verify that the remote host name can be reached. Issue the following command where remote_host is the host name used in the ODBC data source: ping remote_host If you cannot reach the host, or you need to reconfigure the remote host to be defined, run the following commands from an IBM DB2 command line: db2 uncatalog node ODBC_node db2 uncatalog db db_name db2 uncatalog system odbc data source datasource_name db2 terminate After completing the above steps, rerun the ODBC data source creation scripts as described in 4.4.6, “Configuring the ODBC connections” on page 103. The local database server and remote database node must be configured to use the same port number in order for the ODBC data sources to function properly. The ODBC data source creation scripts that are packaged with IBM Tivoli Service Level Advisor default to port 50000. If the ports are not the same on the two systems, you will never be able to connect to the ODBC data source. To change this port number, refer to 4.4.6, “Configuring the ODBC connections” on page 103.Exceeding maximum connectionsIf you receive an error in your IBM DB2 logs stating that the maximum number ofconnections has been reached, your IBM DB2 server has reached its maximumlimit for allowing database connections. Every time a Sample Contents operationis used within the IBM DB2 Control Center, a connection is opened to thatdatabase. This connection remains open until the IBM DB2 Control Center isshut down. Once the maximum number of connections has been met, IBM TivoliService Level Advisor and other applications will not be allowed to access thedatabase.By default, IBM DB2 allows a maximum of 40 d