Business Service Management Best anagement Best Practices

Transcription

Front cover
Business Service
Management
anagement Best
Practices
ctices
All you need to understand Business
Service Management
Business process mapping to
monitoring and service level
Integration of IBM TBSM
and IBM TSLA
Budi Darmawan
Kimberly Cox
Bahaeldin Ragab
ibm.com/redbooks
International Technical Support Organization
Business Service Management Best Practices
June 2004
SG24-7053-00
Note: Before using this information and the product it supports, read the information in
“Notices” on page vii.
First Edition (June 2004)
This edition applies to IBM Tivoli Business Systems Management V2.1.1 and IBM Tivoli Service
Level Advisor version 1.2.1.
© Copyright International Business Machines Corporation 2004. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Chapter 1. Introduction to Business Service Management. . . . . . . . . . . . . 1
1.1 IT organization evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 The IBM on demand Automation Blueprint . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Business Service Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Discussion scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Chapter 2. Business Service Management concepts . . . . . . . . . . . . . . . . 11
2.1 Business Service Management concept . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.1 Service Level Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.2 Implementation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 IBM Tivoli product mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Overview of IBM Tivoli Business Systems Manager . . . . . . . . . . . . . . . . . 20
2.3.1 IBM Tivoli Business Systems Manager components . . . . . . . . . . . . 21
2.3.2 IBM Tivoli Business Systems Manager servers . . . . . . . . . . . . . . . . 22
2.3.3 Important concepts in IBM Tivoli Business Systems Manager . . . . . 24
2.3.4 IBM Tivoli Business Systems Manager distributed object types . . . . 27
2.4 Overview of Tivoli Data Warehouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.1 Benefits of using Tivoli Data Warehouse . . . . . . . . . . . . . . . . . . . . . 30
2.4.2 Tivoli Data Warehouse structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4.3 Tivoli Data Warehouse components . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.5 Overview of IBM Tivoli Service Level Advisor . . . . . . . . . . . . . . . . . . . . . . 36
2.5.1 How IBM Tivoli Service Level Advisor works . . . . . . . . . . . . . . . . . . 37
2.5.2 Inside the IBM Tivoli Service Level Advisor . . . . . . . . . . . . . . . . . . . 38
2.5.3 IBM Tivoli Service Level Advisor databases . . . . . . . . . . . . . . . . . . . 40
2.5.4 The Service Level Management life cycle with TSLA . . . . . . . . . . . . 41
Chapter 3. Planning for Business Service Management . . . . . . . . . . . . . . 43
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2 Sources of information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3 Information collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.1 Business process decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
© Copyright IBM Corp. 2004. All rights reserved.
iii
3.3.2 Documentation of Service Level objectives . . . . . . . . . . . . . . . . . . . 54
3.3.3 Understanding the current monitoring environment . . . . . . . . . . . . . 56
3.4 Designing the solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.4.1 Solution structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4.2 Hardware and software configuration . . . . . . . . . . . . . . . . . . . . . . . . 63
3.4.3 Monitoring standard and required modification . . . . . . . . . . . . . . . . . 68
3.4.4 IBM TBSM object type selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.4.5 Business System View design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.4.6 Data collection design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.4.7 Service Level management design . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Chapter 4. Business Service Management sample implementation . . . . 87
4.1 Sample environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.2 Constructing the solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.2.1 Solution structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.2.2 Solution configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.2.3 Monitoring architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.2.4 Object class selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.2.5 Business System View design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.2.6 Data collection design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.2.7 Service Level monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.3 Implementation overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.4 IBM Tivoli Monitoring profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.4.1 Profile Managers and IBM Tivoli Monitoring profiles. . . . . . . . . . . . 101
4.4.2 Detailed profile setting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.5 IBM Tivoli NetView monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.6 Web transaction response time monitoring . . . . . . . . . . . . . . . . . . . . . . . 120
4.6.1 Quality of Service monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.6.2 Synthetic Transaction Investigator monitoring . . . . . . . . . . . . . . . . 126
4.7 Defining TEC rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
4.7.1 Adding IBM Tivoli Monitoring rules . . . . . . . . . . . . . . . . . . . . . . . . . 132
4.7.2 IBM Tivoli Monitoring for Transaction Performance rules . . . . . . . . 133
4.7.3 IBM Tivoli NetView rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
4.7.4 Assembling a new TEC rule base . . . . . . . . . . . . . . . . . . . . . . . . . . 139
4.7.5 IBM Tivoli Business Systems Manager customization . . . . . . . . . . 140
4.7.6 Defining TBSM object types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
4.7.7 Setting object hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
4.7.8 Defining business systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.7.9 Defining TBSM operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4.8 Configuring Tivoli Data Warehouse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
4.8.1 Collecting information from IBM Tivoli Monitoring. . . . . . . . . . . . . . 152
4.8.2 Collecting information from Web Services Courier . . . . . . . . . . . . . 153
4.8.3 Enabling ETL in Tivoli Data Warehouse . . . . . . . . . . . . . . . . . . . . . 154
iv
4.9 Customizing IBM Tivoli Service Level Advisor . . . . . . . . . . . . . . . . . . . . 160
4.9.1 Defining the operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Contents
v
vi
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such provisions
are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES
THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
vii
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Eserver®
Eserver®
Redbooks (logo)
™
e-business on demand™
ibm.com®
z/OS®
AIX 5L™
AIX®
CICS®
Database 2™
Domino®
DB2 Universal Database™
DB2®
IBM®
IMS™
Lotus Notes®
Lotus®
NetView®
Notes®
Redbooks™
Redbooks (logo)™
Tivoli Enterprise™
Tivoli Enterprise Console®
Tivoli®
TME®
WebSphere®
The following terms are trademarks of other companies:
Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other
countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other company, product, and service names may be trademarks or service marks of others.
viii
Preface
This IBM® Redbook discusses Business Service Management best practices.
Business Service Management is a key component of IBM’s on demand
Automation Blueprint. It is the top layer of the system management discipline,
enabling IT management to be related to the business.
The ultimate goal of the IT infrastructure is to leverage its value to support the
business. IT infrastructure management should then be aimed at minimizing
disruption to the business processes and functions. This goal is realized with the
Business Service Management (formerly also called Business Impact
Management).
Using Business Service Management, IT resources management is aligned with
the business processes and functions:
򐂰 Establishing a Service Level Agreement with IT users
򐂰 Understanding how IT resources impact business processes
򐂰 Ensuring IT resources fulfill the Service Level Agreement and minimizing
disruption to business functions
This redbook describes the relevant concepts, as well as planning for and
implementing Business Service Management. The implementation is described
using a sample business function of an e-business solution.
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.
Budi Darmawan is a Project Leader at the International Technical Support
Organization, Austin Center. He writes extensively and teaches IBM classes
worldwide on all areas of systems management. Before joining the ITSO four
years ago, Budi worked in IBM Global Services in IBM Indonesia as Lead
Implementer and Solution Architect. His areas of expertise include Tivoli® core
product implementation, database systems and business intelligence, z/OS®
systems management and general performance management. He currently
specializes in Business Service Management.
Kimberly Cox is a Senior IT Specialist for the US IBM Tivoli Business Systems
Manager services team. She has worked at IBM for five years. She holds a
ix
Masters degree in Computer Science and Engineering from Pennsylvania State
University. Her areas of expertise include the architecture and implementation of
IBM Tivoli Business Systems Manager / Distributed. She has also developed and
taught a course for training services in the deployment of IBM Tivoli Business
Systems Manager / Distributed.
Bahaeldin Ragab is a Tivoli Certified Enterprise Consultant for the IBM/IT
Service and Solution in Germany. He has six years of experience in the area of
Information Technology. He holds a degree in Electrical-Biomedical Engineering
from Dresden University of Technology. His areas of expertise include designing,
implementing and troubleshooting systems management solutions. In the last
five years, he has implemented more that 20 Tivoli deployments for most of the
big business companies in Germany and Austria.
Thanks to the following people for their contributions to this project:
Editor, Edson Manoel
International Technical Support Organization, Austin Center
Debbie Bandera, Mark Masercola, JB Baker, Marianne Haerdth
Tivoli Systems
x
Become a published author
Join us for a two- to six-week residency program! Help write an IBM Redbook
dealing with specific products or solutions, while getting hands-on experience
with leading-edge technologies. You'll team with IBM technical professionals,
Business Partners and/or customers.
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you'll develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our 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:
[email protected]
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. 0SJB Building 003 Internal Zip 2834
11400 Burnet Road
Austin, Texas 78758-3493
Preface
xi
xii
1
Chapter 1.
Introduction to Business
Service Management
This chapter provides an introduction to Business Services Management and
describes how IBM Tivoli answers this challenge with the IBM Tivoli products
portfolio. The following topics are discussed in this chapter:
򐂰 1.1, “IT organization evolution” on page 2 discusses the changes in the IT
organization over time from the traditional glass house to the on demand
environment
򐂰 1.2, “The IBM on demand Automation Blueprint” on page 4 shows the on
demand infrastructure components and the automation blueprint as one of its
main structure
򐂰 1.3, “Business Service Management” on page 8 introduces the Business
Service Management definition and concepts
򐂰 1.4, “Discussion scope” on page 9 details the structure and scope of the
discussion in this redbook
1
1.1 IT organization evolution
As shown in the IBM automation blueprint, Business Service Management is the
top level of the necessary automation platform that delivers the on demand
operating environment.
The IT organization is an evolutionary journey from a technology focused
organization to a business driven organization. IT organizations have
implemented several management models to increase their productivity. These
models have always been somewhat driven by market development and the
need for more productivity. The mainframe era was about administrative
productivity while the PC and client-server era was about personal productivity.
Increasing productivity has always meant more complexity for both business
management and IT service delivery. This complexity has introduced rigid
business processes, proprietary and fragmented applications and under-utilized,
inflexible IT infrastructures. Both IT service delivery and Business Process
Management were focused on technology and technology trends; the results
were complexity, autonomy, redundant capabilities and fragmented management
views with no integration between enterprises resources.
Figure 1-1 shows the IT organization evolution path.
FUTURE
Business Value
Value-net
optimized
Or
a
PAST
Fragmented
infrastructure
Integrated
infrastructure
IT Infrastructure
Figure 1-1 IT service delivery evolution
2
on
ati
y
vit
cti
du
PRESENT
Enterprise
optimized
Process
optimized
niz
ga
ro
lP
Dynamic
infrastructure
Recently, e-business has changed the rules for Business Process Design and IT
Service Delivery. Boundaries between systems and applications have begun to
correspond with the business boundaries in the extended enterprise. This offers
the opportunity to understand the dependency between business and system
and increase flexibility and dynamics in each area to improve the organizational
productivity.
Successful IT service organizations have changed the way they are running their
business accordingly. They are now focused on business responsibilities,
dependencies and measurement systems. This enables them to align their
management approach with the next era, the e-business on demand™ era. The
trends of business organization, business process, application, data and
infrastructure in comparison to the aforementioned business and IT service
delivery approaches is summarized in Table 1-1.
Table 1-1 Business evolution
Past
Present
Future
Organization/ Business Design
򐂰
Independent operation of
divisions and business
processes
򐂰
Limited coordination with
supplies or partners
򐂰
Constant reinvestments in
skills with lower ROI on
resources
򐂰
Targeted global
brand/customer coordination
򐂰
Bias toward “own and
operate” for majority of
processes; limited/no
outsourcing
򐂰
Shared services for
back-office activities such as
IT, HR and procurement
򐂰
Cross division & geographic
harmonization of critical
processes
򐂰
Focus on core business
processes; outsource
non-core (process,
applications. and
infrastructure
Business process adapts to
packaged application
򐂰
Full value chain visibility
򐂰
Account-specific services
򐂰
Composite software and
Web Services tie together
cross-function processes
and workflow
򐂰
Dynamic, flexible business
processes
Business Process
Business processes operate
independently
򐂰
򐂰
Viable application providers
rare
򐂰
Highly efficient but very rigid
processes prevail
򐂰
Re-engineering movement
takes some hold
򐂰
򐂰
Heavy focus on common
IT-driven enterprise
processes to drive standards
Optimization at division level
- selective trading partner
collaboration efforts
򐂰
Chapter 1. Introduction to Business Service Management
3
Past
Present
Future
Applications
򐂰
Applications focused on
“spot solutions”
򐂰
Limited cross-application
integration
򐂰
Highly inefficient to operate
or change
򐂰
Process logic limited to
specific applications
򐂰
Wide-scale adoption of
packaged solutions designed
to meet the business needs
򐂰
Leading application
functionality delivered online,
as needed
򐂰
Bias toward “own and
operate” majority of core
applications; limited/no
outsourced management
򐂰
Smart business integration
applications provide alerts,
monitoring, triggers and
trade partner orchestration
򐂰
Architecture will enable
application flow and logic to
uncoupled
򐂰
Open and core data
standards adopted
universally
򐂰
Importance of data integrity
and management
sophistication
Radio Frequency identifier
standards adopted &
operational
򐂰
Data and insights shared
internally and with partners
Standards movement
emerging
򐂰
360° view of consumer, value
chain
򐂰
Intelligent infrastructure with
enhanced remote data
centers capabilities
򐂰
Partnership between IT
environment and business
requirements; rapid adoption
of emerging technologies
򐂰
On demand services
Data
򐂰
Data is isolated in individual
areas with limited functional
communication
򐂰
Duplicate systems and
multiple versions and copies
of non-shared data
򐂰
No standards or common
structures
򐂰
Incomplete view of consumer
behavior
򐂰
򐂰
򐂰
Harmonization of customer
and product data (for
example, master files) driven
by applications and
cross-divisional efforts
Infrastructure
򐂰
Internal data centers support
each division within an
enterprise
򐂰
Bias toward own vs. rent
capabilities
򐂰
In-house technical
management; inflexible and
cost inefficient
򐂰
Remote data centers support
divisions
򐂰
Limited outsourcing of some
IT capabilities such as legacy
applications.
򐂰
Lack of open, adaptable and
flexible operability to
accommodate complex IT
1.2 The IBM on demand Automation Blueprint
In the e-business on demand environment, enterprises need to shift their
operation to the on demand state. Resource allocation, process modelling and
cost structure need to be flexible with unparalleled connectivity. Also required is
the ability to adapt to changes in the marketplace quickly and without a huge
4
investment in time, money and resources. Operations needs to be streamlined to
achieve lower costs and improved quality of service.
The on demand operation needs the IT operation to be managed as one
cooperative entity. IT operations need to align with business strategy and to be
more responsive, to focus on core competencies, to benefit from variable cost
structures and to be resilient to external threats. The value within the IT
infrastructure is unlocked to be applied to solving business problems. It is an
integrated platform, based on open standards, to enable rapid deployment and
integration of business applications and processes. Combined with an
environment that allows true virtualization and automation of the infrastructure,
the on demand operating environment enables delivery of IT capability on
demand.
The on demand solution offerings can be categorized to address three main
capabilities:
򐂰 Integration: the efficient and flexible combination of resources to optimize
operations across and beyond the enterprise
򐂰 Virtualization: the pooling of IT resources for simplified access and improved
utilization
򐂰 Automation: the capability to reduce the complexity of management to enable
better use of assets, improve availability and resiliency and reduce costs
based on business policy and objectives.
The IBM Tivoli solution is the base of providing the automation. Automation is
extremely critical to allow businesses to achieve resiliency, efficiency,
responsiveness and flexibility. The IBM automation platform shows the structure
of the automation component in providing on demand automation capability.
The IBM automation blueprint is shown in Figure 1-2 on page 6.
5
Business Service Management
Policy Based Orchestration
Availability
Assurance
Optimization
Provisioning
Virtualization
Software Resources
System Resources
Figure 1-2 IBM automation blueprint
The IBM Automation Blueprint is a game-changing plan for reducing the
complexity of technology to allow focus on the business goals, allowing the
application of resources to business objectives rather than the management of
technology. The blueprint enables enterprises to implement automation in an
evolutionary fashion that acknowledges the heterogeneous nature of the
infrastructure.
At the bottom of the blueprint is the foundation – the software and system
resources with native automation capabilities required for higher level
automation functions. Many of these resources may be virtualized to the other
capabilities. Here, the key point is that in order to achieve the highest levels of on
demand automation, resources need to be virtualized so that they can be
dynamically provisioned as business policies require.
Above the resources are the key automation capabilities:
򐂰 Availability helps ensure that systems are available 24x7.
򐂰 Reliance or security keeps your systems protected from threats and provides
the functions for a great user experience in accessing applications and data
they need, while keeping out unwelcome users.
6
򐂰 Optimization provides tools to make the most of the resources you have, so
that they are running at peak performance and efficiency and providing you
with the maximum return on your investment.
򐂰 Provisioning focuses on the self-configuring, dynamic allocation of individual
elements of your IT infrastructure, so that identities or storage or servers are
provisioned as business needs dictate.
The next layer, Policy-Based Orchestration, helps customers automatically
control all the capabilities of the four areas we just discussed so that the entire IT
infrastructure is responding dynamically to changing conditions according to
defined business policies. This orchestration builds on the best practices of the
customer’s collective IT experience, and helps to ensure that complex
deployments are achieved with speed and quality – on demand.
Finally, Business-driven Service Management capabilities provide the tools you
need to manage Service Levels, meter system usage and bill customers for that
usage, as well as model, integrate, connect, monitor and manage your business
processes end-to-end for complete linkage of IT and business processes. Being
able to view IT resources in the context of business systems is a unique
capability that we need.
Now let’s understand how the Business Service Management relates to other
components of the IBM Automation Blueprint. The Business Service
Management manages Service Level attainment and uses the Policy-Based
Orchestration to modify the environment should there be any potential that the
Service Level cannot be met with the current configuration. Let’s use an
example.
򐂰 A Web Services environment, a configuration with a set of Web servers and
Web application server, working with a load balancer.
򐂰 Due to a very popular seasonal offering, it is experiencing a large number of
additional requests.
򐂰 When it has detected that the number of requests are high enough to warrant
new servers, the Policy Based Orchestration requests those from the
resources pool.
򐂰 The new servers resource is initialized using the Provisioning tower and
configured by the Optimization tower.
򐂰 The Policy-Based Orchestration should also modify security from the
Reliance tower and initiate monitoring of the new servers from the Availability
tower.
򐂰 Now the new servers should be available to handle the additional load from
the Web requests.
7
򐂰 Business Service Management measurement indicates that the surge of
requests can now be handled within the promised Service Level.
The basic implementation of Business Service Management that we cover in this
redbook basically involves the Availability monitoring tower and the Business
Service Management layer. We do not cover the Policy-Based Orchestration or
the other tower that is needed to present a fully autonomic computing.
1.3 Business Service Management
Service Management is defined 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.
Business Service Management is an application of service management
principles to manage the Service Levels for a business function. IT operations
should manage IT infrastructure to support the business functions as dictates by
the application of Service Level Agreements.
The Service Level Agreement is the key factor in Business Service Management.
It addresses the business consumer of IT resources and also dictates the scope
of IT systems management. A Service Level Agreement is defined as 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.
The business entity is typically responsible for a business process. A business
process can be perceived as a collection of IT resources that make up the
business process. Each IT resource in the business process may belong to one
or more business processes. Each IT resource needs to be monitored and
measured in order to ensure its availability and calculate the Service Level
attainment. Figure 1-3 on page 9 shows a sample business process.
8
These Resources combined
DB2
WebSphere
=
CICS
Web Catalog
Order Processing
Figure 1-3 Defining Business Systems
Thus, Business Service Management can be viewed as the task to manage the
Service Level with the business consumer for a specific business process to
ensure that the Service Level Agreement is fulfilled. The following are several
aspects of Business Service Management:
򐂰 It consists of identifying the components of a business system
򐂰 It involves measuring the performance and availability of those components
򐂰 It ensures that the components are performing within the Service Level
objective
򐂰 It alerts to any deviation or potential deviation from the Service Level
objective
1.4 Discussion scope
This redbook discussion will cover concepts, planning and implementation
samples of Business Service Management. The ultimate objective of Business
Service Management is to have a defined Service Level Agreement (SLA) with
all IT consumers; the IT systems management tools are then geared toward
achieving and measuring it.
The concept and planning discussion presents a generic discussion of the
Business Service Management. Full implementation of Business Service
Management takes a long period of time and typically is implemented gradually,
9
one business element at a time. However, in our implementation discussion, due
to time constraints, we show a single business element implementation.
Also, the implementation of Business Service Management in this redbook is
geared towards a distributed environment instead of a mainframe-centric
environment. There are some differences in the mainframe environment on the
basis of the products and components used.
This book is divided into the following chapters:
򐂰 Chapter 1, “Introduction to Business Service Management” on page 1
introduces Business Service Management and provides a general
introduction to this book.
򐂰 Chapter 2, “Business Service Management concepts” on page 11 explains
the basic concepts of the Business Service Management: the scope and
reach of the Business Service Management, what its components are, its
implication on your business.
򐂰 Chapter 3, “Planning for Business Service Management” on page 43 shows
some important aspects of planning the implementation of Business Service
Management: what is the necessary information that you need to gather?
Who are the important source of information that you need to talk to? How do
you process these pieces of information and select the important ones?
򐂰 Chapter 4, “Business Service Management sample implementation” on
page 87 illustrates a sample implementation of an e-business system’s
implementation of Business Service Management. The implementation spans
the Service Level commitment and further use of the tools.
10
2
Chapter 2.
Business Service
Management concepts
This chapter discusses concepts, design considerations and implementation of
Business Service Management. The discussion is based on the following:
򐂰 2.1, “Business Service Management concept” on page 12 defines Business
Service Management. We also describe Service Level Management issues
and show a glimpse of the planning and implementation process.
򐂰 2.2, “IBM Tivoli product mapping” on page 18 shows the available IBM
software that delivers Business Service Management today and how it maps
to the IBM on demand Automation Blueprint.
򐂰 2.3, “Overview of IBM Tivoli Business Systems Manager” on page 20
provides an overview of IBM Tivoli Business Systems Manager.
򐂰 2.4, “Overview of Tivoli Data Warehouse” on page 28 provides an overview of
Tivoli Data Warehouse.
򐂰 2.5, “Overview of IBM Tivoli Service Level Advisor” on page 36 provides an
overview of IBM Tivoli Service Level Advisor.
11
2.1 Business Service Management concept
In Chapter 1, “Introduction to Business Service Management” on page 1, we
have seen that Business Service Management is the top level of the IBM
Automation Blueprint. Business Service Management aligns IT operations with
business objectives. It gives business functions the maximum leverage from IT
resources.
Business Service Management includes the following components:
򐂰 Business: The term business or business process has relative scope
depending on the person that uses it. Typically, it represents the process or
processes that someone has a stake in. For a Sales Manager, business may
mean the sales quota calculation; for a Warehouse Supervisor, the inventory
application may be his or her business.
򐂰 Service: The term service in this context means Service Level. It is the level of
service that needs to be maintained for the business so it can operate
optimally. It guarantees that the business process is available when it is
needed.
򐂰 Management: The term management indicates that the Service Level for the
business process must be planned, monitored, measured and maintained.
Business Service Management integrates systems management information
from heterogeneous environments and different technologies in the overall
business context to be consistent with the mental models used to make decisions
about the direction and operation of the business. This means that every piece of
the delivered IT services and resources should be manageable, measurable and
defined in a business context.
A holistic Business Service Management must deliver a solution that helps
organizations to gain the following:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
Align IT-infrastructure with business goals
Leverage the existing systems management infrastructure
Simplify end-to-end management
Reduce support and licensing costs
Satisfy line of business customers with quality service delivery
Meet Service Level commitments and ensure peak business system
performance
With Business Service Management, the value of IT can be communicated to
line-of-business executives to enable them to know exactly how well their
business function performs from the IT perspective, either using a real-time
status or historically. The achievement of the IT operation for the line-of-business
executives is their attainment of the Service Level Agreement.
12
In order to understand more about Business Service Management, let’s put the
basic concept in place. The next section will discuss Service Level Management.
2.1.1 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 Level
Management goal is important because it emphasizes quantification of services.
Therefore, the objectives of the Service Level must be quantifiable, measurable
and realistic.
Important: It is not enough to define a Service Level as:
A “good” response time on transaction A
The following definition is more suitable:
90% of the response time of transaction A, measured from the Quality of
Service endpoint, should be below 3 seconds
The latter definition:
򐂰 Is quantifiable, 3 seconds response time
򐂰 Identifies the measurement method
򐂰 Is realistic as it accommodates small deviations only: measures 90% of
transactions
The definition of Service Level objectives requires that:
򐂰 IT Services be catalogued.
򐂰 IT Services be quantified in terms that both customer and IT provider
understand.
򐂰 Internal and external targets of IT Services be defined and agreed upon.
򐂰 Achievement of agreed service targets be reached.
The quantification of objectives applies to all aspects of the management of IT
Services between:
򐂰 The customer organization and the IT Services organization
򐂰 The IT Services organization and its external suppliers
򐂰 The IT Services organization and its internal departments
According to this, Service Level Management (SLM) can also be thought of as an
iterative, disciplined, proactive methodology and procedures used to ensure that
Chapter 2. Business Service Management concepts
13
adequate levels of service are delivered to all IT users in accordance with
business priorities and at acceptable cost.
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.
Service Level Management is a means for the lines of business (LOB) and IT
organization to explicitly set their mutual expectations for the content and extent
of IT Services. It also allows them to determine in advance what steps will be
taken if these conditions are not met. The concept and application of Service
Level Management allows IT organizations to provide a business-oriented,
enterprise-wide service by varying the type, cost, and level of service for the
individual LOB.
In order to accomplish Service Level Management and really manage the quality
of service provided by an internal IT organization or by an external service
provider, establishing Service Level Agreements is a must.
Depending on the maturity of the IT organization, SLA may be formally defined
and signed since SLA exists as an objective for the IT provider team to maximize
its service. It is imperative in the full implementation of Business Service
Management that SLA be formally defined.
For the context of this redbook, we define Service Level Agreement (SLA) as
follows: 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 Management is the key factor in a successful Business Service
Management solution for the following reasons:
򐂰 Client satisfaction measures
The IT Service provider must understand what the customer perceives as
good service. The customer must understand what it 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
򐂰 Managing expectation
Often, customers who were satisfied with service yesterday want better
service today, and even better tomorrow. Some savvy ones may just want to
maintain Service Levels knowing that more users are receiving IT services.
To manage such a situation, an IT service provider and customer must
negotiate an SLA. Both parties may later renegotiate the agreement as
needed.
򐂰 Regulating resources
When both the IT service provider and customer monitor Service Levels
closely, they can become aware of developing problems in overcapacity or
lack of resources and can be proactive by taking corrective actions.
򐂰 Marketing for IT services
In the old days, the only contact between the IT service provider and
customer happened when something went wrong. This situation was always
seen as a roadblock to achieving business goals. With a Service Level
Management process in place, an IT service provider can document the fact
that it is providing good services, supporting the business.
򐂰 Controlling costs
With a Service Level Management process in place, IT service providers can
clarify which areas if of its services need improvement and requires
investment, and which areas still perform at satisfactory levels. This helps with
the decision-making process and justification as to whether investments are
necessary to upgrade Service Levels.
2.1.2 Implementation considerations
Deploying Business Service Management solution is a big challenge that can be
achieved using several different approaches. The following are some important
implementation considerations:
򐂰 Implementation is performed in stages. This means that you implement
Business Service Management for critical business processes first and build
on that for other business processes. The first part of the implementation
typically take longer as users are getting used to the concepts and
requirements. The critical business processes are implemented first to get a
larger participant to the project that can accelerate the acceptance of the
solution and building the mindshare of how the solution should be configured.
򐂰 Implementation is performed in iteration. The first take of designing a
business system from a business process is rarely complete nor accurate.
The decision and reasoning behind the component selection and criteria
should be documented so that perfecting the implementation into a complete,
15
accurate and usable solution can be done without destroying what has been
considered before.
򐂰 The Business view of IT resources is dynamic since the resources are
allocated and re-allocated every day or every hour. Change management
must be considered in the implementation process. Depending on the nature
and scale of the business, some change process can be a manually initiated
operation or an automatic one.
Business Service Management solution are driven by the Service Level
Agreements. IT service delivery goals should be aligned with the SLA. The
Business Service Management solution should start with the consolidation of
Service Level Agreements.
Figure 2-1 shows the conceptual components of Business Service Management.
Service Level Agreement
Components
DB2 Database
Monitors
Real time status
Event based
Aggregated business system
Metrics
Target
Availability
98%
# of transaction 100/sec
response time < 2sec
Database availability
Transaction rate
Response time
Ensure SLA Attainment
Historical data
Collected in database
Measured against SLA
Measure SLA Attainment
Figure 2-1 Business Service Management components
Implementation of Business Service Management includes a lot of planning and
data gathering. This planning and data gathering relates to understanding the
business systems and its interaction and how IT resources are used within the
business system. Also, the planning needs to collect and consolidate Service
Level Agreements (if they exist) to understand how the business systems metrics
are committed from both the IT organization and users.
We found it useful in planning for the deployment Business Service Management
solution to use the following top-down approach:
򐂰 Business process decomposition
16
Identifying in the customer environment how business processes are
structured is key to performing the Business Service Management
implementation. Hence, the first phase is to understand the business
processes and try to decompose it into its components:
– Components that are business critical for the service delivery process
(databases, application server)
– Critical sub components (business critical Servlets or JSPs)
򐂰 Service Level Agreement analysis and consolidation
A key to the success of Business Service Management implementation is
precisely quantifying all (internal and external) delivered services. Once we
get the business process structure and its components, the Service Level
needs to be analyzed and consolidated. The Service Level information needs
to be documented. The documentation must reflect a clear description of the
following:
– Delivered services and their components
– Service level objectives
– Measurement metrics and method
򐂰 Current system monitoring environment and historical data collection
The current environment needs to be evaluated for monitoring reuse,
excessive monitoring and for identifying additional monitoring requirements.
Historical data is needed to perform Service Level reporting; this data needs
to be collected from the monitoring subsystem.
򐂰 Detailed design
The most critical factor to the design of a Business Service Management
solution is the monitoring and event management design. A failure in the
implementation can be caused by a design flaw in the monitoring and event
management level due to lack of information about the target business
functions.
The component decomposition level provides you with the appropriate
information that helps you to get around such drawbacks. Equipped with
component decomposition data, you can now proceed to a level of detail that
supports you to select the appropriated monitors and events. Once you have
determined the appropriate monitors, you have to find out which events can
deliver precise information about the health and performance of the target
business system. You must also define correlation matrixes and rules to route
these events to the right destinations (TEC, TBSM). In addition, each event
should unambiguously be associated with clear defined actions, so that your
help desk can easily execute the appropriate tasks. The following details
should also be included in the detailed design.
– TBSM configuration (Business System Views)
– SLM configuration details (offerings, order, ETLs, peak time)
17
The above steps are discussed in more detail in Chapter 3, “Planning for
Business Service Management” on page 43. Once all the necessary planning
information is received, we are ready to deploy the solution. This solution
deployment is discussed in Chapter 4, “Business Service Management sample
implementation” on page 87. The deployment of Business Service Management
includes the deploy Service Level Management components and the business
monitoring components.
2.2 IBM Tivoli product mapping
From the Automation Blueprint, let’s see what products we can use to achieve
the Business Service Management. The IBM Tivoli product for the Business
Service Management is shown in Figure 2-2.
Real time Management
Predictive Management
IBM Tivoli Business Systems
Manager
IBM Tivoli Service Level Advisor
Tivoli Data Warehouse
Availability
Event Correlation and Automation
IBM Tivoli Enterprise Console
IBM Tivoli NetView
Monitor Systems and Applications
IBM Tivoli Monitoring
IBM Tivoli Monitoring for
Figure 2-2 Product mapping
The Business Service Management layer contains solutions that help
organizations more closely align IT with business goals, meet Service Level
commitments and ensure peak business system performance while reducing
support and licensing costs. This helps customers increase their ability to
18
execute by ensuring that they can focus their limited resources on the most
important areas of their business. There are two groups of products in this layer:
򐂰 Real-time monitoring group, which evaluates the business function health in
real time to alert operation personnel of any degradation. The product in this
group is:
– IBM Tivoli Business Systems Manager
򐂰 Predictive monitoring group, which collects performance metrics from the
Availability subsystem and measures them against the Service Level. The
products in this group are:
– IBM Tivoli Service Level Advisor
– Tivoli Data Warehouse
The Availability layer contains a solution that performs the monitoring of Software
and System resources to ensure their availability. There are two groups of
products in this layer:
򐂰 Event Correlation and Automation group consolidates tools that work across
multiple environments to identify the root cause of problems, based on the
information gathered across individual systems and platforms, and either
notify support staff or correct the problem automatically. IBM Tivoli has
developed the following products to address this layer:
– IBM Tivoli NetView® Family
– IBM Tivoli Enterprise™ Console
򐂰 Monitor System and Application group provides tools that help continuously
gather information about, configure, and monitor individual middleware
elements, applications and the supporting IT infrastructure, which includes
hardware, databases, software and networks. Some examples are:
–
–
–
–
–
IBM Tivoli Monitoring for Database
IBM Tivoli Monitoring for Application
IBM Tivoli Monitoring for Business Integration
IBM Tivoli Monitoring for Web Infrastructure
To understand the Business Service Management implementation further, we will
present important concepts for the IBM Tivoli Business Systems Manager, Tivoli
Data Warehouse and IBM Tivoli Service Level Advisor in the following sections
since they hold key concepts on the solution that we deploy later.
More information on other Availability layer product that we used can be read
about in the respective product documentation or the following Redbooks:
19
򐂰 IBM Tivoli Monitoring Version 5.1: Advanced Resource Monitoring,
SG24-5519
򐂰 IBM Tivoli Monitoring for Databases Database Management Made Simple,
SG24-6613
򐂰 IBM Tivoli Monitoring for Business Integration, SG24-6625
򐂰 Introducing IBM Tivoli Monitoring for Web Infrastructure, SG24-6618
򐂰 Unveil Your e-business Transaction Performance with IBM TMTP 5.1,
SG24-6912-00
򐂰 Tivoli NetView 6.01 and Friends, SG24-6019
򐂰 Early Experiences with Tivoli Enterprise Console 3.7, SG24-6015
2.3 Overview of IBM Tivoli Business Systems Manager
For detailed information on IBM Tivoli Business Systems Manager, refer to Tivoli
Business Systems Manager V2.1 End-to-end Business Impact Management,
SG24-6610. This section only discusses the major product features that we use
in the Business Service Management implementation.
IBM Tivoli Business Systems Manager is a real time, event-driven systems
management product that can be use for Business Service Management. IBM
Tivoli Business Systems Manager can manage and monitor systems,
applications, middleware and other related systems management component on
the context of their related line of business. While traditional systems
management tools are focused on technology and deliver only fragmented views
of the enterprise infrastructure health, IBM Tivoli Business Systems Manager
works with these legacy tools to view outages as they relate to the impact of the
overall line of business.
There is an out-of-the-box integration for IBM Tivoli products with IBM Tivoli
Business Systems Manager. Automatic resource discovery is provided to
register existing resources and adopt the Business System Views for dynamic
environment changes. IT personnel can then customize their own views in
relation to the resources under their responsibility, a line of business, a
department, a vertical area of responsibility, a geographical area or a specific set
of resources.
Table 2-1 on page 21 emphasizes the features of Tivoli Business Systems
Manager with focus on the advantages and benefits associated with them.
20
Table 2-1 The benefits and advantages of TBSM features
Features
Advantages
Benefits
Provides business context
for IT, enables greater
accountability to business
user needs and improves
ability to prioritize and
optimize
Allows IT staff to view IT
resources in the context of
critical business services
and to prioritize actions
based on business impact
and make intelligent
trade-off
Provides business context
for IT. Enables greater
accountability to business
user needs. Improves
ability to prioritize and
optimize
Shows the relationship
between applications
Allows IT staff to make
intelligent trade-off, to
easily spot inefficiencies
and problems, and to
quickly diagnose the root
cause of complex failure
scenarios
Increases availability
(uptime) of critical
business systems
Automatically discovers
and builds graphical views
of applications
Allows for the placement of
discovered resources into
containers that represent
critical Business Systems
and Applications
Speeds implementation
time and reduces errors
and ensures the currency
and accuracy of
management view
Dynamically adjusts the
Business System View for
components added,
modified, or deleted
Automatically keeps the
Business System View
up-to-date by avoiding the
problem of manual entry
leading to obsolete
information displays
Reduces errors and
improves productivity
2.3.1 IBM Tivoli Business Systems Manager components
IBM Tivoli Business Systems Manager is made up of three major components:
򐂰 Base Services, which is the main component for IBM Tivoli Business Systems
Manager. It contains the following functions:
– Stores objects and events data in a relational database
– Receives events from the z/OS sources for insertion into the database
– Receives distributed systems events using either the Enterprise Console
listener or the Common Listener
– Processes events and applies them to monitored objects, enables event
propagation up the monitoring hierarchy for business system monitoring
– Serves IBM Tivoli Business Systems Manager workstation for operators to
manage the business systems
21
򐂰 Mainframe resources feeds: this provides support for the z/OS resources for
IBM Tivoli Business Systems Manager. It processes events from various
z/OS applications and subsystems. The following z/OS resources are
supported:
򐂰
򐂰
򐂰
򐂰
򐂰
z/OS operating systems
Batch jobs and scheduler systems
Online transaction systems such as IMS™, CICS® and DB2®
Storage systems
Application such as WebSphere® and HTTP Server
򐂰 Distributed resource feeds: this provides the support for distributed
environments. The following distributed resources can be managed by IBM
Tivoli Business Systems Manager:
– IBM Tivoli Enterprise Console® 3.6.2, or later
– IBM Workload Scheduler 8.1
– IBM Tivoli NetView
– IBM Tivoli Monitoring
– IBM Tivoli Monitoring for Database, Application, Business Integration, Web
Infrastructure, and Collaboration
– BMC Patrol 3.4
– CA TNG 2.1, 2.2 and 2.4
– NetQ AppManager 4.02
2.3.2 IBM Tivoli Business Systems Manager servers
A typical IBM Tivoli Business Systems Manager implementation uses a set of
Intel® servers running Windows® 2000 or NT. The following lists the functionality
of these servers:
򐂰 Database server
This server runs Microsoft® SQL Server. It hosts the data repository for the
IBM Tivoli Business Systems Manager. This machine performs a central role
in IBM Tivoli Business Systems Manager.
򐂰 History server
This server is where all the actions and events processed are archived for
reporting and auditing purposes. It contains a physical copy of the database
server database. The contents of the active database are replicated regularly
to the History Server to maintain a history of all the collected events.
22
򐂰 Console server
This server provides support and functionality for Console-based IBM Tivoli
Business Systems Manager Clients.
򐂰 Propagation server
This server processes events and calculates propagation actions.
򐂰 Event Handler server
This server receives and processes events from z/OS. SNA clients or Host
Integration client software is required, even when only TCP/IP communication
is used.
򐂰 Host Integration server
This server enables Windows-based applications to communicate with z/OS
based applications. This server was called SNA server in the previous
versions of IBM Tivoli Business Systems Manager. This server is only used
for SNA based communication so there is no need for it on TCP/IP based
installations.
򐂰 Web Console application server
This server handles requests associated with the IBM Tivoli Business
Systems Manager Web-based clients. This component provides a lighter
client with just a Web browser interface. It provides somewhat less
functionality than the regular console.
򐂰 Health Monitor Server
This server monitors the health and availability of the other IBM Tivoli
Business Systems Manager servers and their related components.
The overall flows of IBM Tivoli Business Systems Manager components is shown
in Figure 2-3 on page 24.
23
z\OS
Source/390
Tivoli Data
Warehouse
Tivoli NetView
for z\OS
TBSM Servers
Host Integration
Server
Event Handler
Server
History
Server
Web Console
Propagation
Server
Console
Server
Database
Server
Web Console
Server
Console
Agent
Listener
Common Listener
Service
Health Monitor
Server
Health Monitor
Client
Tivoli
Management
Region
Task Server
TEC
Event Enablement
Distributed Data
Source.
( Netview, ITM)
Figure 2-3 TBSM flowchart
2.3.3 Important concepts in IBM Tivoli Business Systems Manager
In IBM Tivoli Business Systems Manager, there are several concepts that you
should be familiar with to work with the product. Understanding the following
concepts helps you get a better understanding of the product:
򐂰 Business Systems Views
򐂰 Object discovery processing
򐂰 Event propagation
Business Systems View
A Business System View is a representation of a group of diverse but
interdependent enterprise resources that are used to deliver specific business
functionality. These resources can include applications or other resources that
are distributed over different networks and installed on different platforms.
24
For example, a Web banking application that is distributed over database
mainframe systems, application servers, firewall, intranet and Internet can be
considered a Business System View.
IBM Tivoli Business Systems Manager provides a flexible user interface that
enables viewing resources that are of interest to a user (such as a Manager of
the Web Services group) or a group of users (such as the Web banking support
team) in a way that reflect the business process that is monitored, the so-called
Business System View. A Business System View is a hierarchical view that
displays IT resources that relate to a business process.
A Business System View consists of the following:
򐂰 The system resources that provide the business function
򐂰 The appropriate prioritization of resources used to determine the health of the
business system
򐂰 The relationship between system resources may be shown
A Business System View can be created from the console or automatically upon
receiving events. Effective Business System Views consider only resources
important to the target business systems. An important factor in defining
Business System Views is who will actually use the business system. A help
desk may need a Business System View based more on the physical
organization of systems and applications. A CIO, on the other hand, may want a
Business System View that shows all the business processes in the enterprise,
but not at the level of detail needed by the help desk.
Business System Views can be built according to the following aspects:
򐂰
򐂰
򐂰
򐂰
An application or a set of applications (Web Banking)
A department (Accounting department)
A vertical area of responsibility (ITSO)
A geographic region (EMEA)
Resources are represented as icons within the Business System View. To easily
determine the root causes of a business system outage, IBM Tivoli Business
Systems Manager provide you with three viewing perspectives.
򐂰 Tree View, which lists the hierarchy of all resources
򐂰 Hyper View, which is best viewing option for displaying large number of
resources at one glance.
򐂰 Table view, which shows resources in a table format. This view is equipped
with column filtering and sorting capabilities.
Additionally, you can invoke the following views from any resources in the
Business System View:
25
򐂰 Business impact view, which shows resources that are affected and their
relation to the impact causing resource.
򐂰 Event view, which displays the events that triggered the resource state
change.
Object discovery processing
Before IBM Tivoli Business Systems Manager can monitor resources and their
performance characteristics, its object type must be registered to IBM Tivoli
Business Systems Manager, as discussed in 2.3.4, “IBM Tivoli Business
Systems Manager distributed object types” on page 27. The object must then be
discovered in the discovery process. This enables the Tivoli Business Systems
Manager to identify and classify these resources. Distributed resources can be
discovered and monitored through the following interface:
򐂰 Agent Listener
IBM Tivoli Enterprise Console events can be forwarded through this interface.
IBM Tivoli Enterprise Console rules can be developed to forward events to the
IBM Tivoli Business Systems Manager database. The first event from a
resource triggers the creation of the object as the discovery process.
򐂰 Common Listener
The Common Listener transport provides bulk and delta transactions. The
bulk transaction populates the IBM Tivoli Business Systems Manager
database with snapshots of the instrumented environments. The delta
transaction keeps the IBM Tivoli Business Systems Manager database
updated as new resources are introduced or removed from the instrumented
environments.
Event propagation
Event processing is the process of capturing business-critical events from IBM
Tivoli Enterprise Console or Common Listener and routing them to IBM Tivoli
Business Systems Manager. This events are then processed and stored in the
IBM Tivoli Business Systems Manager database.
Basically, events affect the status of a resource. State changes are propagated
upward to affect the resource's parents; to facilitate the determination of the
status of Business System Views. Propagation is the process that allows events
to escalate or propagate up the All Resources view or Business System Views.
Propagation is implemented by generating a child event to the parent resources.
In the distributed implementation, all events are of the type Exceptions.
Depending on their priority, exceptions can be processed to affect the object alert
state. If the exception threshold for the object in a specific priority bucket is
exceeded, the object alert state is changed and child events are generated.
26
2.3.4 IBM Tivoli Business Systems Manager distributed object types
In IBM Tivoli Business Systems Manager, an object type represents an IT
component class, such as a machine, database or application. The object type
can have multiple event sources mapped to that object type. Examples of object
types can include Node, WindowsServer, OracleDatabase, CustomApp, Hub,
NetworkDevice, and so on.
Each object type can have:
򐂰
򐂰
򐂰
򐂰
򐂰
An icon associated with it
Events that can show up under it
A set of tasks associated with it
One or more URLs associated with it
One or more local applications associated with it
An object type can have multiple instances. Each actual IT component will be an
instance of that object type. For example, if you have an object type of NTServer
and you have three NT servers called ServerA, ServerB, and ServerC, then you
would have three instances of NTServer, which are NTServer on ServerA,
NTServer on ServerB, and NTServer on ServerC. The Properties Page for each
object instance lists the events that have been received for that object instance.
Object types can be as granular as desired. One should consider the following:
򐂰 All instances of a given object type will have the same icon, tasks, and URLs
򐂰 Each instance will only display the events that have come in for that instance
(even though the object type will have to have all possible events types for
that object type defined to it)
򐂰 An instance of any given object type can appear in any or all Business
System Views
򐂰 Multiple DM profiles can map to the same object, but a single DM profile can
only map to one object type
In an IBM Tivoli Business Systems Manager distributed implementation, there
are two kinds of object types:
򐂰 Distributed Monitoring (DM) objects that receive events from the Tivoli
Distributed Monitoring product
򐂰 Generic objects
DM object types
DM object instances can only be discovered by a Tivoli Distributed Monitoring or
IBM Tivoli Monitoring event, or to put it more precisely, can only be discovered by
events forwarded to Event Enablement using the binary ihstztec. In addition to
Tivoli Distributed Monitoring or IBM Tivoli Monitoring events, generic events can
27
appear under a DM object instance once the object instance has been
discovered.
When DM object types are defined, they are associated with one or more Tivoli
Distributed Monitoring or IBM Tivoli Monitoring profiles. Any given Tivoli
Distributed Monitoring or IBM Tivoli Monitoring profile name can be associated
with only one object type, yet multiple Tivoli Distributed Monitoring or IBM Tivoli
Monitoring profile names can be associated with the same DM object type in IBM
Tivoli Business Systems Manager. When a Tivoli Distributed Monitoring or IBM
Tivoli Monitoring event reaches IBM Tivoli Business Systems Manager, the
profile name is used to determine the IBM Tivoli Business Systems Manager
object class.
Object instances will not appear on the IBM Tivoli Business Systems Manager
console until a Tivoli Distributed Monitoring or IBM Tivoli Monitoring event
associated with that object instance has been received by IBM Tivoli Business
Systems Manager. Scripts can be used to send artificial events to IBM Tivoli
Business Systems Manager if you want to populate it ahead of time with object
instances.
Generic object types
Generic object types are usually defined for events that are coming from sources
other than Tivoli Distributed Monitoring or IBM Tivoli Monitoring, or to put it more
precisely, when the event is forwarded to Event Enablement with the binary
ihstttec. Only generic events can show up under generic object types – the only
way to post a DM event to a generic object instance is to treat the event as a
generic event.
In order for an instance of a generic object type to appear on a IBM Tivoli
Business Systems Manager console, a generic event must be forwarded to IBM
Tivoli Business Systems Manager for the given instance. Scripts can be used to
send artificial events to IBM Tivoli Business Systems Manager if you want to
populate it ahead of time with object instances.
2.4 Overview of Tivoli Data Warehouse
For more information on Tivoli Data Warehouse, refer to Introduction to Tivoli
Data Warehouse, SG24-6607.
The key point of Tivoli Data Warehouse is that all historical data from different
management applications is collected in one centralized database, the Tivoli
Data Warehouse. The schemas of this database are open and published.
Systems management data from third party applications can also be easily
integrated. This architecture is shown in Figure 2-4 on page 29.
28
Customers / Partners Business Intelligence Front End
Service Level Management
Out-of-the-box Report Templates
3rd Party
Applications
TWH
DB
SAP Lotus Xchg MGR etc...
TEC
TAPM DM (monitors)
INV
Framework
Net
View
TWSM
TWSM
TWSA
TWSA
Security
Security
Storage
Figure 2-4 Reporting with Tivoli Data Warehouse
In the Tivoli Data Warehouse, all data is aggregated and correlated for use by
reporting and third party OLAP tools and also by planning, trending, analysis,
accounting, and data mining tools.
Tivoli Data Warehouse applications also provide static standard reports using a
Web console reporting tool. In Release 1 of Tivoli Data Warehouse, the following
classes of reports are supported:
򐂰 Two-dimensional representation of measurements versus
components/groups of components
– Graphical report
– Tabular report
򐂰 Measurements versus time
We will discuss the architecture of Tivoli Data Warehouse in more detail in 2.4.3,
“Tivoli Data Warehouse components” on page 33.
29
Important: Tivoli Data Warehouse is not an independent product. It is
delivered free with all Tivoli Data Warehouse-enabled applications. All
enabled Tivoli source applications will be shipped with the necessary Tivoli
Data Warehouse components to import their data into the central data
warehouse.
2.4.1 Benefits of using Tivoli Data Warehouse
Customers can benefit from using Tivoli Data Warehouse in various ways:
򐂰 Tivoli Data Warehouse collects historical data from many Tivoli applications
into one central place.
Tivoli Data Warehouse 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.
򐂰 Tivoli Data Warehouse adds value to raw data.
Tivoli Data Warehouse performs data aggregation (for example, daily or
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, Tivoli Data Warehouse ensures that time, hostname, and IP
address are the same dimensions across all the applications.
򐂰 Tivoli Data Warehouse allows the correlation of information from many Tivoli
applications.
Tivoli Data Warehouse can be used to derive added value by correlating data
from many Tivoli applications.
򐂰 Tivoli Data Warehouse uses open, proven interfaces for extracting, storing,
and sharing the data.
Tivoli Data Warehouse can extract data from any application (Tivoli and
non-Tivoli) and store it in a common central database. The Tivoli Data
Warehouse application also provides transparent access for third party BI
solutions (CWM standard), such as IBM DB2 OLAP, Crystal Decisions,
Cognos, Business Objects, Brio Technology, and Microsoft OLAP Server.
CWM stands for Common Warehouse Metadata, an industry standard
specification for metadata interchange defined by the Object Management
Group (see http://www.omg.org). Tivoli Data Warehouse provides a
Web-based reporting front end, called the Report Interface, but the open
30
architecture provided by the Tivoli Data Warehouse allows other BI front ends
to be used to access the data in the central warehouse. The value here is
flexibility. Customers can use the reporting application of their choice, and
are not limited to any application.
򐂰 All Tivoli applications will provide standard out-of-the-box reports.
All Tivoli applications will provide standard out-of-the-box reports and report
templates, utilizing the Tivoli Data Warehouse’s common central warehouse.
These reports will provide similar information to those provided by many of
the TDS guides today. As mentioned earlier, Tivoli will also develop and
provide (as separate products) high value, cross-product reporting
applications or killer applications such as Tivoli Service Level Advisor.
򐂰 Tivoli Data Warehouse provides robust security mechanism.
Tivoli Data Warehouse provides a robust security mechanism by allowing
data marts to be built with data from subsets of managed resources. By
providing database level authorization to access those data marts, Tivoli Data
Warehouse can address most of the security requirements related to limiting
access to specific data to those customers/business units with a need to
know.
򐂰 Tivoli Data Warehouse provides a scalable architecture.
Since Tivoli Data Warehouse depends on the proven and industry standard
relational database management system (RDBMS) technology, it provides a
scalable architecture for storing and retrieving data.
2.4.2 Tivoli Data Warehouse structure
The Tivoli Data Warehouse is an application used to collect and manage data
from various Tivoli and non-Tivoli system management applications. The data is
imported from the source applications, stored centrally, and further processed to
fit the needs of the end users. Here we describe the basic components of the
Tivoli Data Warehouse in the logical order of the data flow.
31
Tivoli Warehouse
Control Server:
IBM DB2®
DWC
Warehouse
Metadata
Tivoli Reporting Services
Source Apps
DM
ETL
Inventory
ETL
TEC
Source App
ETL
Tivoli
Reporting
Interface
Central Data
Warehouse
ETL
Data Marts
Data Marts
Data Marts
Data Marts
Data Marts
Data Marts
ETL
Business Intelligence Tools
IBM
Cognos
Brio
Business
Objects
Figure 2-5 Components of the Tivoli Data Warehouse
The first step to introduce Tivoli Data Warehouse is to enable the source
applications. This means providing all tools and customization necessary to
import the source operational data into the central data warehouse. All
components needed for that task are collected in so-called warehouse packs for
each source application.
One important part of the warehouse packs are the ETL programs. The
abbreviation ETL stands for extract, transform and load data. In principle, ETL
programs process data in three steps. First, they extract the data from a data
source. Then the data is validated, transformed, aggregated, and/or cleansed so
that it fits the format and needs of the data target. Finally, the data is loaded into
the target database.
In Tivoli Data Warehouse, there are two types of ETLs. The central data
warehouse ETL pulls the data from the source applications and loads it into the
central data warehouse (see Figure 2-5). The central data warehouse ETL is
also known as source ETL or ETL1. The second type of ETL is the data mart
ETL, which is discussed later.
32
The central data warehouse (CDW) is the database that contains all
enterprise-wide historical data (with hour as the lowest granularity). This data
store is optimized for the efficient storage of large amounts of data and has a
documented format that makes the data accessible to many analysis solutions.
The database is organized in a very flexible way, which lets you store data from
new applications without adding or changing tables.
The data mart ETL extracts a subset of historical data from the central data
warehouse that contains data tailored to and optimized for a specific reporting or
analysis task. This subset of data is used to create data marts. The data mart
ETL is also known as target ETL or ETL2.
A data mart is a subset of the historical data that satisfies the needs of a specific
department, team, or customer. A data mart is optimized for interactive reporting
and data analysis. The format of a data mart is specific to the reporting or
analysis tool you plan to use. Each application that provides a data mart ETL
creates its data marts in the appropriate format.
Tivoli Data Warehouse provides a Report Interface (RI) that creates static
two-dimensional reports of your data using the data marts. The RI is a role-based
Web interface that can be accessed with a simple Web browser without any
additional software installed on the client. You can also use other tools to perform
OLAP analysis, business intelligence reporting, or data mining.
The Control server is the system that contains the control database which itself
contains metadata for Tivoli Data Warehouse and from which you manage your
data warehouse. The Control server controls communication between the
Control server, the central data warehouse, the data marts, and the Report
Interface.
The Control server uses the Data Warehouse Center to define the ETL
processes and the star schemas used by the data marts. You use the Data
Warehouse Center to schedule, maintain, and monitor these processes.
2.4.3 Tivoli Data Warehouse components
A distributed installation is recommended for most production systems and for
customers who already run their database servers on UNIX® systems. Each of
the aforementioned components of Tivoli Data Warehouse can exist on a
separate machine. Such a configuration is illustrated in Figure 2-6 on page 34.
33
Figure 2-6 A distributed Tivoli Data Warehouse configuration
We will provide further information about the four components, including
prerequisites such as DB2 installations and supported operational systems.
However, always first thoroughly review Tivoli Data Warehouse Release Notes,
GI11-0857, before planning your installation.
The Control server is the system that contains the control database for Tivoli
Data Warehouse and from which you manage your data warehouse. Supported
operating systems are Windows NT® and Windows 2000.
Before you install the Tivoli Data Warehouse component on the Control server,
you have to install IBM DB2 Universal Database™ Enterprise Edition on this
machine first. The Control server uses the DB2 Server, the Data Warehouse
Center, and the warehouse agent.
34
The Data Warehouse Center on your Control server automates the data
warehouse processing. You can use it to define the ETL processes that move
and transform data into the central data warehouse and the star schemas used
by the data marts. Then you can use the Data Warehouse Center to schedule,
maintain, and monitor these processes. The warehouse agent is a part of the
DB2 Warehouse Manager. In this configuration, the warehouse agent runs only
on the Control server.
The system on which you install the Control server must connect to the
operational data stores of your enterprise, which potentially reside on other
systems and in relational databases other than DB2. To enable the Control
server to access these data sources, you must install the appropriate database
client for each data source on the Control server system.
The central data warehouse server contains the DB2 databases only. In this
configuration, no pieces of the Tivoli Data Warehouse software or DB2
Warehouse components are needed on this server. Supported operating
systems are Windows NT, Windows 2000, AIX®, and Solaris.
The same applies to the Data mart server. For this reason, in a typical
configuration, the central data warehouse and the data marts will be on one
database server.
The Report Interface server (or Report server) provides tools and a graphical
user interface to create and display reports that help you analyze the data in your
warehouse to answer questions that are important to your business. The Report
Interface uses Tivoli Presentation Services. If it is already installed in your
enterprise, you must install the Report Interface component on the system that
hosts the server for IBM Console.
The Report Interface requires a DB2 runtime client to access data in the DB2
instances on the central data warehouse, data mart, and Control servers. You
must manually install the IBM DB2 product before installing the Report Interface
component. When installing the IBM DB2 product from the CDs provided with
Tivoli Data Warehouse, any one of the following components is sufficient:
򐂰 DB2 Enterprise Edition
򐂰 DB2 Application Development Client
򐂰 DB2 Administration Client (this component has the smallest footprint)
Supported operating systems for the Report server are Windows NT, Windows
2000, AIX, Solaris, and Linux. It performs best on Windows NT and Windows
2000 systems.
35
2.5 Overview of IBM Tivoli Service Level Advisor
For more information of IBM Tivoli Service Level Advisor, refer to Introducing IBM
Tivoli Service Level Advisor, SG24-6611. This section provides a basic overview
of the product, its components and functions as needed to understand and
implement Business Service Management.
IBM Tivoli Service Level Advisor is a Service Level Management product that
helps IT Service delivery organizations to increase the business value of their
delivered service, understanding the measurement and Service Level attainment
within their organization.
This Service Level understanding can helps them to do the following:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
Maintain productivity and customer satisfaction
Verify end user Service Levels
Analyze historical data to predict future Service Levels
Manage costs, and improve planning by assuring offered services
Measure, manage, and report on availability and performance
Automate Service Level Management based on Service level objectives
Evaluate service delivery based on business schedules
Provide Web-based customer report
Directly associate IT operations with business requirements
Table 2-2 emphasizes the features of the IBM Tivoli Service Level Advisor while
focusing on the advantages and benefits associated with them.
Table 2-2 The IBM Tivoli Service Level Advisor summary
36
Features
Advantages
Benefits
Automated Service Level
agreement evaluation
Eliminates the process of
manually reviewing and
correlating
component-level reports
against customer Service
Level agreements
Improves IT resource
productivity, and reduces
education and training
costs required to support
component Service Level
management products
IBM patent-pending trend
analysis
Identifies IT service
delivery problems before
they occur, allowing you to
take action to maintain
Service Levels rather than
simply report them
Maintains customer
productivity and
satisfaction with the
services they depend on to
meet business objectives
Features
Advantages
Benefits
Manage Service Level
definition and business
schedules across existing
IT infrastructure
Leverages existing
systems management
applications, and
associates service delivery
with business operations
Provides business level
management of IT
infrastructure and
increases return on
investment of existing
systems management
tools
Flexible, Web-based
reporting
Identifies problem areas,
providing executive
summary, and detailed
operations status of
Service Level agreements
Helps communicate the
business value of IT
resources and can justify
cost expenditures
Provides open, extensible
aggregation point for all
systems management
data (including non-Tivoli
data), as well as
cross-domain reporting
Leverages business
intelligence tools for data
mining, and provides an
open interface to include
additional monitoring data
in Service Level
agreements
2.5.1 How IBM Tivoli Service Level Advisor works
The IBM Tivoli Service Level Advisor depends on the collected performance and
availability data from a variety of monitoring and performance tools to deliver
SLA reports and SLA trends identification. This flow is shown in Figure 2-7 on
page 38.
37
ITSLA Environment
Source Applications Environment
Source
Appl 1
So
Source
Appl 2
Sourc
urc
e
SLM
Server
ET
L1
e ETL
n ETL
tratio
Regis
2
TEDW
Central
Warehouse
Source
Appl N
ce
ur
So
L
ET
SLM
Reports
Server
ITSLA
Database
Pr o
ces
N
s ET
L
ITSLA
Measurement
Data Mart
ITSLA
Database
Server
SLM
Task
Drivers
and
IBM
Console
Figure 2-7 Data flow in the IBM Tivoli Service Level Advisor
Enterprise Monitoring tools and Business System monitoring tools basically store
their availability and performance data in their own databases, the source
database. This data is then moved into the central data warehouse using Tivoli
Data Warehouse at a regular scheduled interval using an Extract Transform Load
(ETL) program. After all the source ETLs have written the latest data into the
central data warehouse, the IBM Tivoli Server Level Advisor ETL moves a subset
of this data into the SLM Measurement Data Mart, where they can be processed
and analyzed against defined Service Level objectives.
2.5.2 Inside the IBM Tivoli Service Level Advisor
IBM Tivoli Service Level Advisor components are shown in Figure 2-8 on
page 39.
38
Evaluation
data
SLM Server
offering and
orders
Trend
analysis
SLM Task
Drivers
ITSLA
Database
Registration
ETL
ITSLA
Database Server
Reporting
data
SLM Reports
Server
TEDW Control
Center
Figure 2-8 ITSLA Database component access
򐂰 The SLM Server
The SLM Server is the main administration component. It performs the
following tasks:
–
–
–
–
Order creation and processing
Performance evaluation and trends analysis of the measurement data
Storing the results of the analysis
Notification on trends toward SLA violation
򐂰 The Report Server
The Report Server is a Web application based on standard Java™-based
servlets. The Report Server is hosted on an IBM WebSphere application
server. The servlet summarizes the results of the TSLA Measurement Data
Mart evaluation process and stores them in table and graph form. Information
can then be displayed, such as:
– Actual Service Level
– SLA violations statistics
– Trends toward SLA violation
򐂰 The SLM Task Drivers
The SLM Task Drivers are a Web-based user interface which utilizes the IBM
Console for all its tasks. It uses the Java console for all its tasks except for
viewing of message logs and tracing enablement. This can be done with the
help of the Java-based console. The core function of the SLM Task Drivers
can be summarized with the following:
39
–
–
–
–
Service level offering and orders creation
Definition of peak times, off hour, down times and orders
Managing active orders
Specifying breach values for metrics associated with offerings
򐂰 IBM Tivoli Service Level Advisor database server
The database server hosts the IBM Tivoli Service Level Advisor databases.
򐂰 Tivoli Data Warehouse control center
Data warehouse ETL scheduling and management is performed from this
machine.
2.5.3 IBM Tivoli Service Level Advisor databases
IBM Tivoli Service Level Advisor uses the following data repositories for getting
the SLA-related data:
򐂰 The central data warehouse of the IBM Tivoli Data Warehouse (TWH_CDW)
The central data warehouse is the single point of data integration for all
systems management data. This includes data from the entire distributed IT
environment Tivoli products. Tivoli Data Warehouse provides an open
integration point for Data-to-Business transformation. Moreover, the Tivoli
Data Warehouse provides the following features:
– Foundation for Business Service Management
– Single place for IT management data consolidation
– Open repository for all management data from any vendor, Industry
standard warehouse
– The warehouse is bundled with and automatically populated by all Tivoli
products
– Analysis for predictive management and continuous IT improvements
– Scalable solution
򐂰 The SLM Database (DYK_CAT)
The SLM Database is the configuration repository of the IBM Tivoli Service
Level Advisor. It holds the configuration and definitions data, such as
resource types and metrics that can be referenced during the creation of
offerings and orders. In addition, all the offerings and orders that are already
created are stored in the SLM Database. Moreover, all analysis and trend
evaluation results are stored in this database. The SLM Database is updated
on a regular basis with the latest resource types and metrics data from the
central data warehouse using the Registration ETL.
򐂰 The SLM Measurement Data Mart (DYK_DM)
This data repository stores all performance and monitoring data collected
from IBM Tivoli Data Warehouse upon the execution of the Process ETL. The
40
Process ETL moves a subset of the central data warehouse to this repository
for processing and analysis. The SLM Measurement Data Mart is updated on
a regular basis with the latest metric data from the central data warehouse
using the Process ETL.
2.5.4 The Service Level Management life cycle with TSLA
Service Level Management is an ongoing process. Both the service provider and
customer must adjust the Service Level objectives to achieve the best Service
Level with reasonable costs and efforts regularly.
The following summarizes the Service Level Management life cycle:
1. Service Level Agreement creation
a. Negotiate with your customer to determine the Service level objectives
b. Create a draft Service Level agreement
c. Review the defined Service Level agreement with your customer
d. Agree on the final Service Level agreement
2. Monitor and report the Service Level. The IBM Tivoli Service Level Advisor
steps in the Service Level game, as a monitoring and management tool. The
overall Service Level management process of the IBM Tivoli Service Level
Advisor can be summarized as such:
– Configure the IBM Tivoli Data Warehouse to move SLA-related data from
the data provider local database into its central data warehouse.
– Populate SLM database with the source applications resource types and
metrics. This is done with the Registration ETL, manually or by schedule.
– Create an offering with the SLA-related objectives.
– Associate the offering with your target customer and thereby create an
order.
– Schedule and populate the SLM Measurement Data Mart with the source
application SLA-related data.
– Analyze and evaluate the data, notify of SLA violations and potential
trends of SLA violations.
– Deliver SLA reports.
3. Review the Service Level results with your customer based on the SLA
reports.
4. Start with Step 1 again.
41
42
3
Chapter 3.
Planning for Business
Service Management
In this chapter, we will cover the principles behind Business Service
Management to assist in planning for a successful implementation. We discuss
many useful tips and techniques based on actual implementations.
This chapter includes the following sections:
򐂰 3.1, “Overview” on page 44 lays down the important planning objectives for
Business Service Management implementation.
򐂰 3.2, “Sources of information” on page 45 lists the personnel or roles that need
to be interviewed to get the information about Business Service Management
solution.
򐂰 3.3, “Information collection” on page 47 describes the information collection
process, tips and samples.
򐂰 3.4, “Designing the solution” on page 61 explains the solution design, once
the information is collected.
43
3.1 Overview
A common challenge with Business Service Management is the starting point.
Everyone wants to have a successful implementation, but it can be difficult to
define. The most important is to start with the basics; you must collect business
information and IT information. This information collection and analysis is the
scope of this chapter discussion. We categorize this phase as planning the
implementation.
Planning for Business Service Management involves a thorough understanding
of the business structure of the enterprises that need Business Service
Management. The business structure includes the positioning of business
processes. These business processes need to be understood and associated
with the IT resources to see the implications of an IT resource outage to the
business process, since this will affect the Service Level.
The planning process is performed in a collaborative effort by the implementers
and various personnel from the enterprise, including application sponsors,
operations control and those responsible for individual component monitoring.
The process is mainly performed using interviews and discussions to collect
necessary information for the implementation.
In this chapter, we describe the person roles that we recommend for gathering
the information, provide sample questions to ask, and show sample spreadsheet
templates to fill out. The main goal of the planning phase is a robust
representation of all relevant business process components, with measurable
Service Level objectives. The interim goals of the project that also need to be
satisfied are as follows:
򐂰 Manage services at the business level
– Relate IT infrastructure to business requirements
– Historical, real-time, and predictive analysis and reporting
򐂰 Improve IT resource productivity
– Prioritize management based on business impact
– Reduce SLA evaluation and SLA reporting time and cost
򐂰 Communicate IT value and delivery of service
– Provide Web-based customer reports
– Directly associate IT operations with business requirements
򐂰 Maintain high customer satisfaction
– Manage Service Levels proactively
– Prove Service Levels are met
44
The basic steps of planning for Business Service Management are described in
more detail in 3.3, “Information collection” on page 47.
3.2 Sources of information
This section discusses the people that should be contacted during the planning
stages of a Business Service Management implementation. The contact can be
in the form of interviews or a moderated discussion so that information can be
verified on the spot. Table 3-1 lists the roles that need to be contacted and the
information that can be gathered.
It is useful to start with a moderated discussion to level set the Business Service
Management expectations. Interviews are then useful for following up and
gathering more specific requirements.
Table 3-1 Personnel roles
Role
Description
Information
Business Process
Owner
The Business Process Owner is
typically the head of the line of
business who runs the business
process. As the owner, this individual
understands the overall picture of the
business process and is able to state
the purpose of the business service.
Scope and purpose of the business
process
Identify stake holders
Get Service Level Agreement
information
Business process
manager
Some enterprises have a different
custodian who is responsible for the
business process and a manager who
is responsible for the business
process.
Get Service Level Agreement
information
Business process
users
The typical business users are the
end-users of the business
components. They use the IT
applications for the business process.
Describe the business components
Identify vital components for them
Get user view of the process
Who are the users of the business
service?
Who are the customers of this
business service?
Application developer
and system analyst
Developers and system analysts
understand the application system that
makes up the business components.
They design and customize the code.
Identify critical transaction
Identify databases and application
components and their connections
Understand the impact of an outage
Chapter 3. Planning for Business Service Management
45
Role
Description
Information
Business component
owner
The individuals responsible for the
components of the business process.
Contrary to the Business Process
Owner, the business component
owner is responsible for part of the
overall business process.
Scope and purpose of the business
process
Business support
This group is responsible for
monitoring availability of the business
components.
Know the how monitoring is performed
Understand the groups that are
responsible for the support
System operator
The system operator manages
day-to-day operations of IT
components.
Important components that need
monitoring
Most likely spot where problems can
occur
Business structure insight
Helpdesk personnel
First level problem determination
personnel
Primary communication with business
users
Able to state where the business
service is deployed
Heavily relies on the use of tools for
Problem and change
coordinators
They manage and monitor the problem
management and change
management processes
To provide the business impact of
problems and change.
Tivoli Framework
administrator
Personnel that manage the Tivoli
Management Framework structure
and define profiles
Current monitoring structure
Network/LAN
administrator
They ensure that the corporate
network is running securely and
optimize its performance
Current and recommended network
structure
Windows system
administrator
Manage Windows domain structure
and users
Domain administration, hostnames,
naming convention structure
Future TBSM
administrator
Person roles that will use the IBM Tivoli
Business Systems Manager console
What resources are important to them
How they want the BSV to be impacted
Service Level
coordinator
Person who manages Service Level
Agreements and measure its
attainment
Understand what and how Service
Levels are measured and monitored
46
3.3 Information collection
As discussed in 2.1.2, “Implementation considerations” on page 15, the basic
steps of Business Service Management information collection are:
򐂰 Performing business process decomposition as detailed in 3.3.1, “Business
process decomposition” on page 48
– Identifying the business process
– Identifying the components of the business process
– Identifying the component relationships
򐂰 Documenting Service Level objectives as discussed in 3.3.2, “Documentation
of Service Level objectives” on page 54
򐂰 Current monitoring environment evaluation s detailed in 3.3.3, “Understanding
the current monitoring environment” on page 56
These steps are expanded in the sub-sections. Some of the information given in
3.2, “Sources of information” on page 45 is necessary for the sections mentioned
above. This is shown in Figure 3-1.
Business Process
Decomposition
Service Level
documentation
Current Environment
Analysis
Business Process Owner
Business Process Manager
Network administrator
Windows Administrator
Business Component Owner
Tivoli administrator
End-user
SLA Coordinator
CIO / IT Manager
System Analyst
Application Developer
Helpdesk
System Operator
Figure 3-1 Personnel roles and information collected
Now let’s go into more detail about the information that needs to be collected.
47
3.3.1 Business process decomposition
This stage of planning includes an analysis of business processes and its
components. A business process, from an IT perspective, consists of a set of
applications that serve a specific business objective. Each application can also
be broken down into components made up of IT resources.
The decomposition of a business process in this context consists of mapping
business processes to the IT resources that affect it. The impact of a certain IT
resource also needs to be evaluated to define its role in the overall business
process. This mapping is illustrated in Figure 3-2.
Business Process:
Corporate Email
Business Process:
e-Business
Application:
Email
Server C
Server D
Server Z
RouterA
Hub1
Hub2
Application:
Online Store
Application:
Intranet
Server 1
Server 2
Server 3
Server A
Server B
Server C
Email Servers
WebServer
WebServer
Backup Servers
Application Server
Application Server
Network Infrastructure
Firewalls
Firewalls
Authentication service
Authentication service
Firewall 1
Firewall 2
RouterA
RouterB
Hub1
ISP conn
LDAP server
Policy Server
Web Seal
Figure 3-2 Business process decomposition
As shown in Figure 3-2, the decomposition process breaks down business
processes into applications and then into specific components. These
components then relate to the IT resources. Some IT resources may be used by
multiple business processes; for example, in Figure 3-2, Server C is a
WebSphere Application Server and also a Domino® server.
The major decomposition steps are:
򐂰 “Identifying the business process” on page 49
򐂰 “Defining the applications” on page 50
48
򐂰 “Identifying the components of an application” on page 51
򐂰 “Identifying the component relationships” on page 53
Identifying the business process
A business process is a logical group of applications that together deliver a
specific function to one or more users. Examples of business processes include:
򐂰
򐂰
򐂰
򐂰
A corporate e-mail system
A payroll system
An online banking application
An e-business application
The business process definition contains:
򐂰 High-level description
򐂰 Information about functions provided by the business process
򐂰 Description of the contribution to the business mission
򐂰 Information about impact to the business mission if it becomes unavailable
򐂰 Schematic description of the business process, which typically resides in a
separate document. It should describe how each application is integrated to
create this business process.
򐂰 Relationship to other business processes. Some of these relationships are
straightforward since the business processes have an impact on each other,
while others may be abstract because resources are shared.
In the Business Service Management implementation, these business processes
are the entity that will be managed. The overall business processes build the
structure of the enterprise. Each business processes should have specific
Service Level objectives to which the IT department should adhere. Thus, the
performance of IT is measured by the attainment of these Service Level
objectives for each business process.
As the managed entity, the list of business processes is used to form the basic
measurement and monitoring object. The business processes will be
decomposed into IT resources that can effectively monitor them to attain Service
Level objectives.
In the course of listing the business processes, it may be beneficial to consider
the following questions:
򐂰 Have all department or divisions been represented in the business
processes?
򐂰 Are there any business processes that cannot be allocated on the
organization chart?
49
Sometimes you may find a business process that is nmapped to a much different
level than a corporate division, but it makes sense to categorize it as a business
process since it needs to have a Service Level Agreement for IT usage, such as
the Help desk and IT operation staff.
After collecting and validating this information from the Business Process
Owners or Business Process Managers, the list of these business processes
should be filed. A sample is provided in Table 3-2.
Table 3-2 Business Process definition table
Name
Finance
Supplier management
Web Store
Description
Manage financial asset
Contact goods provider
Online ordering
Contribution
General services
Getting in-flow of goods
Generate revenue
Impact of outage
Unable to process
ledger
Late fulfillment
Loss of revenue
Structure
Account Receivable;
Account Payable;
General Ledger
EDI transaction to
suppliers
Web server farm
Relationship
Corporate wide
services
Functions
Note: We will show the decomposition of these three business processes as
an example in this section. This is by no means a complete business process
list for an enterprise.
Defining the applications
Now that we have the list of business processes, we can start the decomposition
process to understand how IT resources affect business processes. In this stage,
typically, you inventorize the application that is used by the business process to
perform its function. These applications can then be evaluated further for the
detailed components that make them up.
The application list contains the following attributes:
򐂰 The purpose of the application
򐂰 The users and/or customers of the application
򐂰 The owner of the application
򐂰 Platform deployed
򐂰 Custodian of these applications
50
򐂰 Current support structure (is the application supported as a whole or are the
piece parts supported by different groups?)
First in finding the applications that make up a business process, we need to
collect information from the Business Process Owner or manager, such as:
򐂰 What are the applications within the business process?
򐂰 Is there any application to be used with a real customer?
򐂰 Which application(s) do you consider critical in the business process?
An interview with the business process users will be useful, with question such
as:
򐂰 What application are you using to perform your day-to-day work?
Further qualification of the applications found needs to be performed. This
qualification usually goes to the Business Process Owner and later to the
application owner or business component owner.
Some questions may also be asked to the system analyst or application
developer to get a better idea of how the application is structured and what the
components within the application are.
򐂰 Are there business flow diagrams for this application?
򐂰 Are there data flow diagrams for this application?
򐂰 Is there an architecture document for this application?
A sample application list is shown in Table 3-3.
Table 3-3 Application list
Name
Business process
User
Support structure
Account
Receivable
Finance
accounting; cashier
in-house
Account Payable
Finance
accounting; cashier
in-house
General Ledger
Finance
accounting
in-house
EDI transaction
system
Supplier
Management
supplier;
purchasing
in-house
EDI provider
Web store
application
Web store
External
in-house
Identifying the components of an application
Each application to be managed comes with a different set of components. We
have broken down business processes into the applications that make up the
51
business process. We have also collected information about the application
structure. We can now identify the components of the application.
From the application business flow or data flow, components can be identified.
Further discussion with the application developer, system analyst and application
owner can be beneficial. Information about the components of an application
should include the following:
򐂰 Machine or server name that hosts the application
򐂰 Operating system name and version of the server
򐂰 Application process running; this can be a transaction system, application
server or any entity that made up the application
򐂰 Data access information, such as database name and database machine
A sample set of components is shown in Table 3-4
Table 3-4 Application components
Name
Server
Operating
System
Application
processes
Data access
Account
Receivable
finar.mycorp.com
AIX
WebSphere AS
FIN_AR@findb
finweb.mycorp.com
Linux RH 7.3
Apache
-
findb.mycorp.com
AIX
DB2 UDB
Batch
-
finap.mycorp.com
AIX
WebSphere AS
FIN_AP@findb
finweb.mycorp.com
Linux RH 7.3
Apache
-
findb.mycorp.com
AIX
DB2 UDB
Batch
-
fingl.mycorp.com
AIX
WebSphere AS
FIN_GL@findb
finweb.mycorp.com
Linux RH 7.3
Apache
-
findb.mycorp.com
AIX
DB2 UDB
Batch
-
Account Payable
General Ledger
52
Name
Server
Operating
System
Application
processes
Data access
EDI transaction
system
spl1.mycorp.com
Win2K Server
SP4
EDI client
SP1@spldb
spl2.mycorp.com
Win2K Server
SP4
In-house
application server
SP1@spldb
ORDER_DB@we
bi
spldb.mycorp.com
Win2K Server
SP4
DB2 UDB
-
webi.mycorp.com
AIX 5L™ V5.1
DB2 UDB
webs.mycorp.com
AIX 5L V5.1
WebSphere AS
CUST_DB
ORDER_DB
PRODUCT_DB
(all at webi)
webo.mycorp.com
AIX 5L V5.1
IBM HTTP Server
-
webi.mycorp.com
AIX 5L V5.1
DB2 UDB
Batch
-
webf1.mycorp.com
AIX 4.3.3
Firewall
-
webf2.mycorp.com
AIX 4.3.3
Firewall
-
Web store
application
Further information is needed for each IT component to get a detailed
understanding of each component and the necessary information for the
monitoring evaluation. This information needs to be obtained either from the
application owner or the application programmer. The questions are:
򐂰
򐂰
򐂰
򐂰
What are the availability measures of the particular component?
What is the mission critical nature of the component?
What is the application failure and recovery information?
What are the daemons and processes that are essential to the applications?
Identifying the component relationships
When the components of a business process have been identified, within an
application context or not, we need to figure out the relationship between the
components. This relationship information is needed to understand the
interaction and impact of an outage that may happen for a single component.
The relationship is typically derived from a business flow diagram and data flow
diagram. Other relationships that represent categorization of resources may also
be useful as the management of these resources is typically also categorized in
53
certain ways that may be different than the business process boundary. For
example:
򐂰 Grouping by function: alll Web servers (for e-commerce, intranet,
supply-chain)
򐂰 Grouping by location: all servers in Latin America (for finance, human
resources and so on)
򐂰 Grouping by support team: all Windows servers
A dependency relationship must also be built. This will allow identification of a
potential bottleneck or Achille’s heel of the business process. A table such as
Table 3-5 may help to define these relationships.
Table 3-5 Business components relationships
Business
Component
Depends On
Impacts
Comments
3.3.2 Documentation of Service Level objectives
When the enterprise already has a Service Level Agreement between the IT
producer and IT consumer, these pieces of information are important to get
up-front. The Service Level Agreement can be formal (a signed document) or
informal. The informal Service Level Agreement is harder to manage because it
relies mostly on the expectations of both sides. However, it is obvious that the IT
producer will try to maximize the service with a constraint on budget (resources
or personnel), while the IT consumer will insist on maximum service to get their
work done.
A Service Level Agreement defines the following:
򐂰
򐂰
򐂰
򐂰
򐂰
Definition of the involved parties, IT producer and IT consumer
Definition of the Service Level objectives and metrics
Definition of the measurement mechanism on the service metric
Definition of the data collection and processing of the measurement data
Optionally, definition of the constraint boundaries of the defined Service Level
In the implementation of Business Service Management, a Service Level
Agreement serves as the base for building the solution for business processes.
The Service Level Agreements are established for every business process. The
IT producer creates monitoring in the context of attaining the Service Level
54
objective. Historical information from the monitoring system is collected and
summarized into the Service Level measurement database to be compared with
the documented objective. Constrain condition need to be included in the
measurement.
Service level objectives are the primary focus of the Service Level Agreement
since they are the negotiable piece of information. Service Level objectives are
defined for each critical application in the business process, and sometimes for
all applications. An effective Service Level objective must be:
򐂰 Understood and agreed upon by both parties
򐂰 Achievable by controlling and managing service elements and IT resources
as needed and consistent with business needs and budget for delivery cost
򐂰 Measurable, so that it can be evaluated and reported
򐂰 Able to represent the overall health of the business process
When the enterprise does not have a Service Level Agreement, implementation
of Business Service Management can be done from the reactive implementation
of the Service Level. The monitoring is implemented without any specific target,
the objective being to maximize the availability. Sometimes, the Service Level
Agreement is defined later, using the output of the monitoring as the IT producer
understands what Service Level it can achieve.
Table 3-6 on page 56 shows sample Service Level objectives for our example.
Note: Here we put the constraint on the business process level; some put the
constraint on the application level.
55
Table 3-6 Service level objective
Business
process
Application
Metric
Objective
Measurement
Finance
Account
Receivable
ARposting
response
time
Less than 2 secs on
backend processing for
95% of transactions
Quality of Service
monitoring for specified
Web intranet transaction
Account
Payable
APposting
response
time
Less than 2 secs on
95% of transactions
Quality of Service
General
Ledger
GLposting
response
time
Less than 2 secs on
95% of transactions
Quality of Service
Reconcile
batch run
time
Less than 90 minutes for
weekly job and less than
120 for monthly job
Batch report
Constraint: Less than 50 transaction per minute
Supplier
Manageme
nt
EDI
transaction
system
Order
submission
response
time
Less than 5 seconds for
95% of the transactions
Robot simulated
transaction to a dummy
vendor
Constraint: Less than 100 transactions per hour
Web store
Web store
application
Search
transaction
Less than 7 secs on
95% of transactions
Synthetic transaction
measurement with a set of
agreed keyword searches
Add to
basket
transaction
Less than 3 secs on
95% of transactions
measurement with 1 to 10
items in the basket
Check out
transaction
Less than 10 secs on
95% of transactions
measurement with 10
items in the basket
Constraint: Hit rate for less than 20 hit per seconds
3.3.3 Understanding the current monitoring environment
The monitoring subsystem needs to be evaluated to be able to support the
Business Service Management. From the Business Service Management’s
perspective, the monitoring subsystem goals are as follows:
56
򐂰 To know when an outage or a potential outage of a business process
component occurs so that the IT personnel can proactively fix the problem or
potential problem so it will not disrupt the Service Level.
򐂰 To record the measurement of an IT component metric for Service Level
attainment.
This monitoring is tightly coupled with automation. A potential outage needs to be
fixed as soon as possible to keep Service Level Agreement attainment. This fix
can be performed by the system (automatically) using an automation or event
processing subsystem or manually. It is not within the scope of this redbook to
discuss event automation.
The current monitoring environment is compared to the monitoring requirement
for the IT components in the business system to find what needs to be monitored
that is not already being monitored and what is monitored that does not need to
be. Or in other words, we are comparing the current monitoring system against
what is required for accurate and efficient Business Service Management.
We need to inventorize the monitors and match the result against the monitoring
requirement for the IT resources for the business process. Such a listing of
monitoring inventory should include the following:
򐂰 What is currently monitored? Are all components that make up the
applications in business systems monitored? Are there any monitors that do
not correspond to a component? The monitoring list may include the following
items:
–
–
–
–
–
Application or service availability
System availability
End-to-end transactions response time
Network components monitoring
Log files monitoring
򐂰 What type of monitoring is deployed?
– Unsatisfactory only: monitoring for unsatisfactory condition to alert the
operator. This type of monitoring is very hard to integrate in an automated
Business Service Management solution.
– Unsatisfactory/Satisfactory: when resources get back to a satisfactory
level, an additional event is generated to notify the management system
that the resource has recovered. It need to be ensured that all pairs of
events are generated and can be correlated.
– Levels of performance: this kind of monitoring deals with different levels of
unsatisfactory performance.
57
– Heartbeats: keeps monitoring subsystems aware of resources that are
satisfactory; when a heartbeat fails to come, it may be that the resource is
becoming unavailable or the monitoring subsystem is unavailable.
򐂰 What information is provided in the event? For each monitoring tool, we need
to evaluate the event structure, such as:
– Event format (SNMP, TEC event or other)
– Severity information levels
– Sender identifier and granularity, by hostname, process, application
instance and so on
– Additional descriptive information formats
򐂰 Is there any metric collection mechanism? What is the data format: text file,
binary file, RDBMS?
Monitoring can be performed by an IBM/Tivoli software or by a third party
monitoring tool. We will discuss these requirements in the following sections.
Tivoli monitoring solution consideration
The Tivoli monitoring solution is based on either Tivoli Distributed Monitoring
product or IBM Tivoli Monitoring product families. Additionally, network
monitoring is based on IBM Tivoli NetView and IBM Tivoli Switch Analyzer. Most
of these products are based on Tivoli Management Framework. Additional
information of the Tivoli management environment is recommended, such as:
򐂰 What type of Tivoli Infrastructure is there?
Is it a single TMR or multiple TMRs?
Are they configured as hub and spoke; multiple separate TMRs; or fully
interconnected TMRs?
򐂰 How are monitoring profiles defined?
How is the Profile Manager hierarchy defined?
Are profiles created by a certain grouping (by system; application; specific
server)?
Are multiple profiles pushed to a server to represent the different functions of
that server?
򐂰 Are Tivoli Tasks implemented?
For multiple TMRs, where are the Task Libraries defined?
򐂰 Is there automation in IBM Tivoli Enterprise Console?
What events trigger automation?
What is the current IBM Tivoli Enterprise Console event load?
򐂰 Who owns the monitoring/who can change it if the need arises?
Are all TMR functions controlled by a single group?
How is the separation of duty achieved?
58
The information in Table 3-7 lists the Tivoli event management applications that
can be present in your environment. Typically, the events generated by these
applications may be forwarded directly to IBM Tivoli Enterprise Console or can
be processed using the Common Listener interface. It is recommended that you
use IBM Tivoli Enterprise Console for forwarding since it is much more flexible
and versatile.
Table 3-7 Tivoli event management application checklist
Product
Version
Event
to
TEC
Comments
Tivoli Framework
N/A
Provides number of test and production TMRs
Describes setup (for example: hub-spoke)
N/A
Provides number of test and production IBM Tivoli
Enterprise Consoles and describe setup (such as
standalone or hub-spoke)
Tivoli Distributed Monitoring
(DM)
These events must be forwarded to IBM Tivoli
Enterprise Console.
IBM Tivoli Monitoring (ITM)
Resources can be discovered and monitored
through the Common Listener without requiring
IBM Tivoli Enterprise Console but it is
recommended that monitoring events be
forwarded to IBM Tivoli Business Systems
Manager through IBM Tivoli Enterprise Console.
IBM Tivoli NetView
Tivoli Workload Scheduler
(TWS)
This does not include TWS on the mainframe.
Resources are discovered using Common Listener
Tivoli Manager for *
Discuss each separate Tivoli Manager for products
in its own line
IBM Tivoli Monitoring for *
Discuss each separate IBM Tivoli Monitoring for
products in its own line
The Tivoli Manager for * and IBM Tivoli Monitoring for * products need to be
individually specified on their own rows. They identify the additional canned
monitor supplied by IBM Tivoli.
59
Non-Tivoli monitoring applications
Non-Tivoli monitoring and event generator applications to be integrated with a
Tivoli solution for Business Service Management need to be able to interact with
the Tivoli solution. The following needs to be true:
򐂰 Event monitoring must interface using either of these two methods:
– Events are being sent to IBM Tivoli Enterprise Console.
– There is a Common Listener feed.
򐂰 Historical information for the metric must be stored.
The information in Table 3-8 can assist in identifying this and other required
setups for non-Tivoli monitoring applications. Add additional non-Tivoli products
that are used to manage the customer distributed environment to the table as
appropriate.
Table 3-8 Non-Tivoli event management applications checklist
Product
Version
Event
to
TEC
Comments
BMC PATROL
Computer Associates Unicenter
TNG
List resource types monitored.
NetIQ AppManager
HP OpenView
These events must be forward to IBM Tivoli
Enterprise Console prior to the start of the project.
Getting these events to IBM Tivoli Enterprise
Console is outside the scope of this proposed
project.
60
Product
Version
Event
to
TEC
Candle Command Center
Comments
These events must be forward to IBM Tivoli
Enterprise Console prior to the start of the project.
Getting these events to IBM Tivoli Enterprise
Console is outside the scope of this proposed
project.
3.4 Designing the solution
When most of the information collection has been performed, the next planning
phase is the solution design. The design uses the information collected from 3.3,
“Information collection” on page 47 and continuously interacts with the involved
parties as discussed in 3.2, “Sources of information” on page 45.
Restriction: The design discussed here only involves a IBM Tivoli based
solution. A different configuration and structure may be needed to
accommodate non-Tivoli monitoring tools.
A Business Service Management solution design starts with the decomposition
of business processes and the Service Level objectives. The individual
breakdown of IT components that needs to be monitored to guarantee Service
Level attainment provides the base on the overall solution design.
There are several design sections detailing the implementation of Business
Service Management. Those are:
򐂰 3.4.1, “Solution structure” on page 62 provides the big picture of what
software product can be used in the solution.
򐂰 3.4.2, “Hardware and software configuration” on page 63 lists a detailed view
of servers and required software to implement the functions; specific
considerations are provided for major elements.
򐂰 3.4.3, “Monitoring standard and required modification” on page 68 discusses
the creation of a monitoring standard based on the information input.
򐂰 3.4.4, “IBM TBSM object type selection” on page 69 provides some
considerations on deciding what objects needs to be defined in IBM Tivoli
Business Systems Manager and how these objects will be monitored.
򐂰 3.4.5, “Business System View design” on page 74 discusses the translation of
the business process decomposition into impact monitoring using the
Business System View.
61
򐂰 3.4.6, “Data collection design” on page 80
򐂰 3.4.7, “Service Level management design” on page 82
3.4.1 Solution structure
The software structure for an IBM Tivoli solution is shown in Figure 3-3.
Operating System
Monitors
ITM for
Database
ITM for
Messaging
ITM for Trans.
Performance
ITM for Web
Infrastructure
ITM for
Application
ITM for
Business
Integration
Application, Middleware,
Database and
Performance Monitors
Network Monitors
IBM Tivoli NetView
Batch Management
IBM Tivoli Business Systems Manager
IBM Tivoli Workload Scheduler
Figure 3-3 Solution structure
As shown in Figure 3-3, the solution includes the following components:
򐂰 Operating system, application, middleware, database and response time
monitoring using the IBM Tivoli Monitoring product family
򐂰 Network monitoring using IBM Tivoli NetView
򐂰 Batch management using IBM Tivoli Workload Scheduler
򐂰 Automation and initial correlation through IBM Tivoli Enterprise Console
򐂰 Historical data collection through Tivoli Data Warehouse
򐂰 Real-time business system management using IBM Tivoli Business Systems
Manager
򐂰 Service level management using IBM Tivoli Service Level Advisor
62
Although the number of software elements to be implemented seems daunting, it
should be understood that implementation should be done in stages. It is true,
though, that the initial implementation is the longest and most complicated since
it encompasses the most software to be implemented and also the largest
changes in the operation paradigm.
3.4.2 Hardware and software configuration
The complete hardware configuration environment is shown in Figure 3-4. It
shows one of the possible configurations. Depending on system load and
bandwidth constraint, it may require more or fewer machines.
Tivoli Management Region
Gateways TWS Domain Manager NetView
Tivoli Internet Management
TMR Server
RIM host TEC Server
Web Services Courier
TIMS Server
QoS endpoint
STI endpoints
IBM Tivoli Service Level Advisors
TDW Database TDW Control TSLA Database TSLA Admin
Server
Center
Server
Server
IBM Tivoli Business
Systems Manager
TBSM Console & TBSM Database
Propagation Server
Server
TSLA Reporting
Server
Figure 3-4 Overall hardware solution
Table 3-9 on page 64 discusses the role of each machine in Figure 3-4 for the
solution and the requirement.
63
Table 3-9 Software configuration list
Machine role
Suggested OS
Software list
TMR Server
UNIX based
Tivoli Management Framework 4.1
IBM Tivoli Monitoring 5.1.1
IBM Tivoli Monitoring Component Services 5.1
Control the overall operation of the Tivoli Management Framework. This example
indicates a single TMR solution. Depending on your structure requirement, you may
need multiple TMRs in your environment. A TMR can typically manage several
hundreds thousands endpoints.
Gateways
Windows or UNIX based
These are endpoint communication gateways. The operations to the endpoints are
managed by these gateways. You need a gateway for up to 1000 endpoints. You want
the communication from the endpoints to a gateway to be secure. Each gateway will
also be responsible for uploading data through Common Listener and the data
warehouse for the endpoints for which it responsible.
RIM host
UNIX based
DB2 Universal Database 7.1
The RIM host and database server for the Framework environment will host the data
for IBM Tivoli Enterprise Console and historical data for IBM Tivoli Monitoring. It is also
a good place to put MDist distribution status database. As a RIM host, it must be a
managed node. It contains the DB2 database server code.
TEC Server
UNIX based
IBM Tivoli Enterprise Console 3.8
IBM Tivoli Business Systems Manager distributed edition
2.1.1
This server performs event analysis and correlation. There may only be a single Event
Server in a TMR. If this is an existing Tivoli installation, you may want to evaluate the
current Event Server load and estimate whether you need another TEC server.
NetView server
UNIX based
IBM Tivoli NetView 7.1.3
IBM Tivoli NetView monitors and manages network communication and devices. It
alerts the operator of network outages, such as a failing router or hub.
64
Machine role
Suggested OS
Software list
TWS Domain
Manager
UNIX based
Tivoli Job Scheduling Services 8.2
TWS connector 8.2
IBM Tivoli Workload Scheduler 8.2
IBM Tivoli Workload Scheduler manages, schedules and monitors batch jobs. The
domain manager performs the primary control over the scheduling network. Typically,
you would use multiple domain manager to enable local job dependency resolution in
each domain.
TIMS server
UNIX based
IBM Tivoli Monitoring for Transaction Performance 5.2:
Internet Management Server
The Tivoli Internet Management Server control Internet management portion of IBM
Tivoli Monitoring for Transaction Performance. The admin function is based on a Web
browser interface.
QoS endpoint
Windows
QoS Endpoint
The Quality of Server endpoint performs response time measurement of incoming
traffic to a Web server.
STI endpoint
Windows
IBM Tivoli Monitoring for Transaction Performance 5.2: STI
endpoint
STI (Synthetic Transaction Investigator) investigates and performs Web transaction to
ensure the transaction is available and monitors the response time.
TBSM database
server
Windows 2000
Advanced Server
Windows 2000 Resource Kit
Windows Support Tools
MKS Toolkit V8
Microsoft SQL Server 2000
IBM TBSM Base Services
IBM Tivoli Business Systems Manager central component using Microsoft SQL Server
as the data repository. It requires a very powerful Windows Intel machine such as dual
Pentium® 4 - 2 GHz with 2 GB of RAM. Dual network adapters are also
recommended.
TBSM console
and propagation
server
Windows 2000
Advanced Server
MKS Toolkit V8
IBM Tivoli Business Systems Manager console and propagation server. It requires a
powerful Windows intel machine such as a single Pentium 4 - 2 GHz with 1 GB of
RAM. Dual network adapters are also recommended.
65
Machine role
Suggested OS
Software list
TDW database
server
AIX 5L on 375 MHz
DB2 Universal Database Server v7.1 FixPack 5
IBM Console Presentation Services
Tivoli Data Warehouse enablement packs
This machine hosts the Central Data warehouse (TWH_CDW) database, star schema
(TWH_MART) database as well as the metadata (TWH_MD) database that contains
the ETL information. This is a mostly read-only database for reporting; update
happens only during scheduled ETL runs. At least 1 GB of memory and 100 GB of disk
are recommended.
TDW Control
Server
Windows 2000 Server
DB2 Universal Database v7.1 FixPack 5 Administrative
Client
This machine serves as the administration console for Tivoli Data Warehouse. It runs
the Java interface for DB2 Warehouse Control Center. It requires 1 GB of memory.
TSLA database
server
AIX 5L on 375 MHz
TSLA admin
server
DB2 Universal Database Server v7.1 FixPack 5
This machine hosts the DYK_CAT and DYK_DM databases for IBM Tivoli Service
Level Advisor. Depending on the load of the system, this machine can be merged with
the TDW database server as they both are primarily read-only except for scheduled
ETL runs. At least 1 GB of memory and 100 GB of disk are recommended.
DB2 Universal Database v7.1 FixPack 5 Client
IBM Tivoli Service Level Advisor 1.2 Server
This machine runs the administration server for IBM Tivoli Service Level Advisor.
Administrator connects to this machine using a Web browser to administer SLA,
metrics, offering and so on.
TSLA reporting
Server
DB2 Universal Database v7.1 FixPack 5 Client
IBM Tivoli Service Level Advisor 1.2 Task Drivers
IBM Tivoli Service Level Advisor 1.2 Reports
This machine monitors Service Level attainment from the data in the database against
the expected Service Level threshold and generates reports using the reporting
interface.
Refer to the documentation in “Related publications” on page 165 for sizing
information and installation procedures for the software mentioned in Table 3-9
on page 64.
Tivoli Management Framework considerations
There may be some modification to the structure of the Tivoli Management
Framework for the Business Service Management implementation. The following
needs to be considered:
66
򐂰 Gateway placement: each gateway is responsible for inserting monitoring
data in the Tivoli Data Warehouse, and if you are using the Common Listener,
the gateway sends status information to the IBM Tivoli Business Systems
Manager server.
򐂰 IBM Tivoli Enterprise Console’s Event Server structure, whether there is any
forwarding rule to collect events from various areas in the enterprise or there
is only one central Event Server. If events are forwarded from various Event
Servers, the event analysis needs to be performed from all the Event Servers,
not the central Event Server, although it is most likely that IBM Tivoli Business
Systems Manager will get the events from the central Event Server.
򐂰 Monitoring profiles and Profile Manager structure. The monitors need to be
inventorized and listed so that they are easy to analyze.
The analysis of the Tivoli Management Framework structure may prove the need
for an additional server, such as RIM data collection servers for collecting
historical data or additional Event Servers should the load of the current Event
Server not prove adequate.
IBM Tivoli Business Systems Manager considerations
The IBM Tivoli Business Systems Manager implementation in the distributed
area requires two physical servers. These servers should be defined using static
IP addresses and reside in the same Windows domain. It is recommended that
you have these servers connected in a full-duplex redundant fast Ethernet.
We will now list some important questions for designing the configuration for IBM
Tivoli Business Systems Manager:
򐂰 What is the estimated number of events that the customer will be sending to
IBM Tivoli Business Systems Manager?
򐂰 What is the break down of those events that go through the IBM Tivoli
Enterprise Console?
򐂰 Will firewalls exist between IBM Tivoli Business Systems Manager servers
and any of the management applications that will be sending or receiving
events to or from it?
򐂰 Does the facility to execute Tivoli Tasks or open URLs from IBM Tivoli
Business Systems Manager need to be configured?
򐂰 Will IBM Tivoli Business Systems Manager be integrated with a Problem
management application?
򐂰 Will IBM Tivoli Business Systems Manager be integrated with a Change
Management application?
򐂰 Will a failover environment for IBM Tivoli Business Systems Manager be
configured?
67
򐂰 Will a history server for archival information and reporting be used in IBM
Tivoli Business Systems Manager?
Tivoli Data Warehouse and IBM Tivoli Service Level Advisor
It is not recommended that you merge all processing into one machine. Most of
the processes use Java heavily, therefore the memory requirement is quite high.
The recommended configuration consists of:
򐂰 IBM Tivoli Service Level Advisor server that hosts administration of the
Service Level processing.
򐂰 IBM Tivoli Service Level Advisor reporting server that reports the Service
Level attainment.
򐂰 Tivoli Data Warehouse control server this is the management server for the
data warehouse.
򐂰 Tivoli Data Warehouse database server and IBM Tivoli Service Level Advisor
database server; these servers may be separate or merged since the
processing is mostly scheduled for running the ETL programs.
3.4.3 Monitoring standard and required modification
Based on the monitoring input that has been collected, a monitoring scheme
standard needs to be developed. This monitoring scheme standard is beneficial
in re-aligning existing monitors and in the creation of new monitors.
Our environment mainly uses the IBM Tivoli Monitoring product family and IBM
Tivoli NetView for the monitoring. Events are pooled through IBM Tivoli
Enterprise Console instead of using the Common listener interface. If the events
come from a non-Tivoli application, events can be received through the Common
Listener.
One must also understand the change management procedures. Not all monitors
might be in place, or they might be in place, but not sending enough information
to the IBM Tivoli Enterprise Console.
Monitors need to provide the following:
򐂰 Ability to log and collect historical data when required. This collection should
have a minimal impact on the overall system and monitoring application’s
performance.
򐂰 Each alert event must have a clearing event associated with it. If the clearing
event cannot be produced, a mechanism should be in place to synchronize
the object states.
򐂰 Event management policies should be in place: how long are events kept, do
archives exist, and so on.
68
򐂰 Event automation, correlation and forwarding rules need to be documented
as appropriate
One step of the planning is to collect all the generated events and historical
metrics, either from a log file or a database table, and try to match the rules
above with the current settings to see the discrepancy.
Here are some typical situations:
򐂰 A non-Tivoli product does not have interface to the data warehouse. Most
products do collect data into a historical database for analysis. An interface
for these monitoring products needs to be developed and coded so that data
feed from this history can be collected into the Tivoli Data Warehouse.
򐂰 Tivoli Distributed Monitoring is typically not set to collect historical information.
This can be enabled individually in the Sentry profile setting. Furthermore, an
alert resolution is not provided by default; a specific resolution (HARMLESS
event) must be sent when the metric goes below threshold.
򐂰 Monitoring lapses with Tivoli Distributed Monitoring are easy to deal with by
clearing or restarting the monitoring engine. This will re-send all valid alerts or
resolutions.
򐂰 IBM Tivoli Monitoring implementation provides an automatic clearing event
called TMW_Clearing with a reference to the actual alert. This is very useful
in matching events.
򐂰 Historical collection for IBM Tivoli Monitoring needs to be enabled manually in
the Tmw2k profile dialog.
򐂰 Resynchronizing the status with the IBM Tivoli Monitoring resources needs to
be developed by the installation. When the monitoring engine restarts, the
resolution is not automatically sent (since it does not remember previous
states); only alerts will be sent when the threshold is exceeded again.
3.4.4 IBM TBSM object type selection
From IBM Tivoli Business Systems Manager, object types or classes need to be
defined and event feeds enabled for the class. This decision is related to:
򐂰 Types of interface that will be used to feed IBM Tivoli Business Systems
Manager, whether events will come from IBM Tivoli Enterprise Console or
from Common Listener. See “Interface selection” on page 70.
򐂰 The object type selection; basically, there are two types of dynamic objects
that can be used: the DM object type and Generic object type. See “Object
type selection” on page 71.
69
򐂰 Granularity of the object representation, having the whole database instance
level, the database level, the tablespace level or the table level. See “Object
class granularity” on page 73.
All these decisions are influenced by the business process decomposition result
and performance trade-offs that should be inspected with care. The following
section discusses these selections in detail.
Interface selection
There are two ways to bring events from the distributed monitoring environment
into IBM Tivoli Business Systems Manager: the Common Listener or the Agent
Listener.
򐂰 The Common Listener is a generic interface; it can send bulk discovery, delta
discovery and event information to IBM Tivoli Business Systems Manager as
needed. This interface is coded as in the monitoring subsystem to send
specific information to IBM Tivoli Business Systems Manager as specified by
the interface.
򐂰 The Agent Listener receives events from IBM Tivoli Enterprise Console
through the Event Enablement subsystem. These events are processed by
the IBM Tivoli Enterprise Console engine before being sent to the Agent
listener.
Table 3-10 lists the considerations regarding the IBM Tivoli Business Systems
Manager distributed interface selections.
Advantages
Table 3-10 IBM Tivoli Business Systems Manager distributed interface
70
through IBM Tivoli Enterprise Console
through the Common Listener
Event correlation in IBM Tivoli Enterprise Console
Built-in bulk and delta discovery for object
instance creation
Lots of field experience means higher reliability
No IBM Tivoli Enterprise Console rule work
You can handle ITM events with either the DM
Classic EE binary ihstzIBM Tivoli Enterprise
Console, or the generic EE binary ihsttIBM Tivoli
Enterprise Console. Note that ihsttIBM Tivoli
Enterprise Console is probably best for new
deployments.
Clearing events handled automatically
Event rate higher at IBM Tivoli Business
Systems Manager than with IBM Tivoli
Enterprise Console -> IBM Tivoli Business
Systems Manager
Disadvantages
Initial discovery possible only by running scripts.
Discovered objects don't have an endpoint
name in the label, so when you drag them
into a BS you don't know which one is
which.
Requires rules to forward clearing events
Limited field experience means lower
reliability
Event rate lower at IBM Tivoli Business Systems
Manager than with Common Listener
Tip: Most implementation is currently done using the IBM Tivoli Enterprise
Console feed because it is more flexible to accommodate changes and
customization based on the customer’s requirements.
You can map a IBM Tivoli Enterprise Console event to a Common Listener
discovered object because the SQL stored procedure that processes IBM Tivoli
Enterprise Console events will pass the event to the Common Listener if it
doesn't recognize the object class. The challenge for Common Listener
discovered objects is that you need to know the instance ID used when the
object was discovered.
This is very important if you mix IBM Tivoli Enterprise Console events with
Common Listener-discovered objects; be very careful not to duplicate through
IBM Tivoli Enterprise Console what you are going through the Common Listener
feed. An example may be an IBM Tivoli NetView implementation that met with
duplicate status and timing problems; the status may never be right. As long as
what is coming through IBM Tivoli Enterprise Console are completely different
events, you should be fine.
Object type selection
In the implementation of IBM Tivoli Business Systems Manager, new objects
need to be defined for custom interfaces through IBM Tivoli Enterprise Console.
These custom interfaces typically fall into a Generic object type of DM object
type as discussed in 2.3.4, “IBM Tivoli Business Systems Manager distributed
object types” on page 27.
Each object type can have a set of automated tasks or URLs associated with it.
These tasks and URLs are typically used to perform further investigation and
problem resolution. The URLs are easy to define since they are static URLs.
Automated tasks are defined in a Tivoli Management Framework’s Task
Libraries. These tasks must be executed at a target endpoint or managed node.
The Task Library and the execution target must be known in the local Tivoli
Management Region (TMR) where the Event Server that forwards the discovery
event resides or be registered using a wupdate command from the remote TMR.
71
If necessary, the IBM Tivoli Business Systems Manager’s tgmtaskconfig
command can be used to redirect task execution requests to alternate task
servers. This tgmtaskconfig command is effective for each IBM Tivoli Enterprise
Console basis. The target endpoint name is retrieved from the hostname slot of
the event.
Table 3-11 shows some considerations for selecting the object class.
Table 3-11 Object class selection consideration
DM Object class
Generic Object class
One object per server limit
Enforced
Does not exist
Clearing event
Must be defined in the profile of the
DM monitor or automatic for ITM
monitor
Must be coded using TEC rules that
correlate events
Status discovery
Only from a DM event, Generic
events that are forwarded to a DM
object type will not cause an
instance icon to appear on the IBM
Tivoli Business Systems Manager
console.
Any event forwarded using the
Generic event exit will trigger
discovery.
TEC integration
DM or ITM monitor will provide the
necessary information on identifying
the object type and instance.
Generic events must have
information in them to be able to
uniquely identify an object type and
instance. If necessary, a generic
event source may need to be
modified.
To ensure that generic events that map to a DM object type will always appear on
the IBM Tivoli Business Systems Manager console, there are a few techniques
that can be used:
򐂰 For each generic event that IBM Tivoli Enterprise Console receives, the IBM
Tivoli Enterprise Console can forward two events to the IBM Tivoli Business
Systems Manager. The first event will be a DM event to create the instance
icon if it is not already there; the second event will be the generic event that
will now appear on the console.
򐂰 If the list of all possible instances is known, a script can be created to draw
the initial view on the IBM Tivoli Business Systems Manager console.
Subsequently, when the generic event arrives at the IBM Tivoli Enterprise
Console, the instance icon that it should map to would already be drawn.
Note that when new servers enter the IBM Tivoli Business Systems Manager
managed environment, initial instances will need to be created for them.
72
An alternative to creating a script is to add a heartbeat monitor to each DM profile
related to IBM Tivoli Business Systems Manager. This heartbeat monitor would
ensure that the initial instance is drawn.
When the event source can be customized, it may be beneficial to add slots such
as TBSM_class and TBSM_object_name slots so the object mapping can be
made much simpler.
Object class granularity
An object type should represent a machine or an application, with, possibly,
multiple event sources mapping to that object type. The object type can be
defined as granular if you want. Typically, an object type that represents a single
monitor is discouraged.
For example, let’s say you are monitoring a relational database management
system. What are the object types that you can make?
򐂰 You can make a single database object per server; this means that all kinds of
events from the database monitoring will be fed into that object.
򐂰 You can make an object type for each different instance of the database. The
instances are more granular than just a database system. This allows
differentiation of each database instance. Typically, there are one to three
instances defined in a machine.
򐂰 You can define additional object types for the content of each instance such
as for each tablespace and for the bufferpools and other pools within the
database instance that can be monitored. It will be easier to see which object
is the cause of the outage when an event is received, but the downside is that
there may be too many objects on the screen for an operator to manage; a
typical database instance may have hundreds of tablespaces. Events and
monitors overhead may be too much to monitor at this level of detail.
An object type may have multiple event sources mapping to the object type. This
will help to narrow down the number of object types to be created. For example, a
Server object type may be getting events from an IBM Tivoli Monitoring monitor,
from IBM Tivoli NetView and a log file adapter on that machine. Another example
is a Web Server getting events from IBM Tivoli Monitoring monitor, from IBM
Tivoli NetView, a log file adapter monitoring access.log file and an IBM Tivoli
Monitoring for Transaction Performance Site Investigator. In IBM Tivoli Business
Systems Manager, these events can be viewed as distinct events from the Event
Viewer by clicking View -> Event instead of the Property page; the Property
page retrieves much more information, so it is is slower and has more of an
impact on the system.
For each object type, custom modifications should be listed, such as tasks and
URLs that should be defined. Table 3-12 on page 74 is a sample table that is
73
useful to fill out after deciding on IBM Tivoli Business Systems Manager object
types. The table will help summarize the objects and its event sources.
Table 3-12 Lists of IBM Tivoli Business Systems Manager object types
Object Type
Event Source
Association
of event to
object
Class ID
Tivoli Task
Libraries
URL(s)
3.4.5 Business System View design
The design of the Business System View relates to translating the business
process decomposition into a usable view. The view should show the correlated
status of the business entity (business processes or applications) as a Business
System View object affected by real IT objects that it contains with respect to
their priority. The Business System Views also allows the enterprise to know
what caused a problem and see which business processes are impacted.
A Business System View represents a collection of IT objects and components. It
should be designed and built by considering the business requirements and
operational needs. In this way, the Business System Views can quickly alert an
operator of the impact of a specific component outage with respect to the
business processes as a whole. These components can reside on mainframes,
distributed systems, or both. They can span all technologies and all
organizations of a company. This redbook deals with a distributed application,
however, the concepts can also be applied to a mainframe implementation.
The primary input of the Business System View structure should come from the
business process decomposition information. Most of the business processes
and the critical applications identified previously are likely candidates to be a
Business Systems View. These business processes and critical applications
represent a valid business entity that is comprised of IT components. The status
of the Business System View represents the operational status of the business
process or critical application. Any indication of outage may compromise the
Service Level attainment of the business entity, and therefore needs to be
resolved.
Additional Business System View requirements come from the future operator of
the IBM Tivoli Business Systems Manager console. They need to be able to
74
quickly pinpoint problems or potential outages quickly and effectively within the
vast number of devices and IT components that they are responsible for. These
requirements may indicate the need for specialized Business System Views that
allow resource assignment and fast action on outage or potential outage by
alerting the correct personnel. You need to ensure that all Business System
Views have a potential user (operator) and all users (operators) have all the
Business System Views they need.
This Business Systems View information should be documented in a
spreadsheet. Information that is needed in the spreadsheet should include:
Business System View name and description
Business System View purpose
Business System View user (stake holder)
Members information:
– Component type
– Selection rule
– Relative priority
򐂰 Alerts and events that affect each members
򐂰
򐂰
򐂰
򐂰
A good Business System View should represent the business entity correctly and
effectively. For the stake holder, an IBM Tivoli Business Systems Manager
Business System View should accurately display the logical cause/effect
relationship between components. Ask yourself whether the following questions
have been answered:
򐂰 Does the Business System View correctly show the effect of an outage?
򐂰 Does the Business System View assist one in quickly finding the source of the
problem?
򐂰 Does the Business System View quickly identify the impact of the outage to
other business entities?
Business System Views
A business system is a group of diverse but interdependent applications and
other system resources that interact to accomplish specific business functions. A
business system can contain applications or other resources that run on a variety
of platforms, including host, distributed, and network environments. For example,
a banking business system designed to support transactions over the Web
typically includes a Web server running outside the company’s intranet that is
connected directly to the Internet and a firewall that provides secure connectivity
to a machine running a custom business component; an example might be loan
processing. The loan processing business component usually runs on a
distributed platform and interfaces to business components running on a host
computer. The host handles all bank transactions. This business system
75
presents challenges to a system manager because it crosses the typically
isolated environments of the host and distributed systems.
Another example of a business system is an e-mail system. E-mail business
systems include all instances of e-mail business components that are being used
in your network. You might have a mix of Lotus® Notes® servers and clients,
POP mail or Microsoft Exchange servers and clients, and other e-mail business
components.
An e-mail business system includes definitions that can tell whether each of its
entities is a server, a client, or both. It also includes definitions of the monitors
that collect status information for each component in the business system, as
well as definitions of the relationships between the components in the business
system.
Business System View structure
The key to designing the Business System Views is to understand the business
process structure and the availability of the monitors that will be needed. From
the previous planning stages, we should have the following information:
򐂰
򐂰
򐂰
򐂰
Business process lists
Critical applications for business processes
IT components for each application that reflect the health of the application
Monitors for the IT components
It is beneficial to document all the above information in a spreadsheet so that
they are easily referred to and understood. There should be a documented
method on how the relationship of the IT components should be shown to a
Business System View. There are several ways that the components can be
shown in a Business System View. Let’s use an example to illustrate this.
A Web-based application contains the following:
򐂰 BSM2 and BSM8 are the servers; these are where the HTTP Server and
WebSphere Application Server reside.
򐂰 IBMTIV2 is the database server; this is where the DB2 database server runs.
The IT components that affect Web application BSV are:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
76
BSM2 HTTP Server
BSM8 HTTP Server
BSM2 WebSphere Application Server
BSM8 WebSphere Application Server
IBMTIV2 DB2 database
BSM2 Operating System health
BSM8 Operating System health
򐂰
򐂰
򐂰
򐂰
򐂰
IBMTIV2 Operating System health
BSM2 Network interface
BSM8 Network interface
IBMTIV2 Network interface
Router1 router
The following shows how Business System Views can be built. The possible
views are shown in Figure 3-5.
Web application
Web application
BSM2 HTTP
Server
BSM8 HTTP
Server
BSM2 WebSphere
BSM8 WebSphere
IBMTIV2 DB2
BSM2 Network
card
BSM8 Network
card
IBMTIV2 Network
card
BSM2 OS
Web application
BSM2 Network
card
BSM2 OS
BSM2 HTTP
Server
BSM2 WebSphere
BSM8 Network
card
BSM8 OS
BSM8 HTTP
Server
BSM8 WebSphere
IBMTIV2 Network
card
IBMTIV2 OS
BSM8 OS
IBMTIV2 DB2
IBMTIV2 OS
BSM2 HTTP
Server
BSM2 Network
card
BSM2 OS
BSM8 HTTP
Server
BSM8 Network
card
BSM8 OS
BSM2 WebSphere
BSM2 Network
card
BSM2 OS
BSM8 WebSphere
BSM8 Network
card
BSM8 OS
IBMTIV2 DB2
IBMTIV2 Network
card
IBMTIV2 OS
Web application
BSM2 HTTP
Server
BSM8 HTTP
Server
BSM2 WebSphere
BSM8 WebSphere
IBMTIV2 DB2
Networking
BSM2 Network
card
BSM8 Network
card
IBMTIV2 Network
card
Operating
Systems
BSM2 OS
BSM8 OS
IBMTIV2 OS
No Hierarchy
Original Hierarchy
Inverted Hierarchy
Grouped Resources
Figure 3-5 Possible Business System Views
Let’s discuss the Business System Views structure shown in Figure 3-5.
򐂰 No hierarchy: using this method, all resources that the BSV depends on are
laid out flat under the BSV object.
򐂰 Original hierarchy: using this method, all resources are laid out under the BSV
according to its physical tree hierarchy. The objects that affect the BSV
directly are listed as the leaf node of the BSV tree.
򐂰 Inverted hierarchy: using this method, all resources that a BSV depends on
are listed as the first-level BSV, and each resource that indirectly affects the
BSV is placed under the resource it affects. This method provides the best
cause/effect relationship of the objects.
򐂰 Grouped resources: using this method, all resources that a BSV depends on
are made first-level dependants of the BSV. Other resources on which the
BSV is not directly dependent are grouped in one or more sub-BSVs.
77
Table 3-13 shows the pros and cons of each method. The following criteria were
evaluated:
򐂰 Logical cause/effect relationship of the object: does the causal relationship of
the objects in the view generate the correct propagation behavior? For
example, if the host cannot be pinged, then it causes the server application to
be unavailable.
򐂰 Ease of identifying a problem: determine whether a problem is directly caused
by the BSV component or by something else the component is dependent on.
This can be seen from a tree view or a hyperview.
򐂰 Ease of maintenance: as with automatic placement of an object under the
BSV view, automatic instance filtering can only be implemented for objects
under BSV folder objects, not a BSV logical object from a physical object.
򐂰 Effect on the business impact view: we call this a fan effect because the
business impact view looks like a fan with many parents for an object; thus,
we cannot really perform a business impact analysis.
Based on Table 3-13, we decided to use the separate BSV design for
implementing our BSV.
Table 3-13 Pro and cons of BSVs creation
Type
Cause effect
Identification
Maintenance
Business
impact
No hierarchy
No
No
Automated
Not affected
Original
hierarchy
Some
Yes
No
Not affected
Inverted
hierarchy
Yes
Yes
No
Great impact
Separate BSV
Some
Yes
Automated
Not affected
There are two methods for creating Business Systems Views:
򐂰 Drag and drop – This method involves dragging objects from the All
Resources tree and dropping them into a Business Systems View.
򐂰 Automated (dynamic) – Objects registered using the IBM Tivoli Business
Systems Manager discovery process can be included in a dynamically
created Business Systems View.
78
Important: The two methods for creating Business Systems Views cannot be
used in conjunction to create a single Business Systems View. You need to
choose which method to use. When naming convention do exist, it is
preferable to use the Automated method.
Additional considerations
Additional considerations for the Business System View design are as follows:
򐂰 Naming convention: a key aspect of defining an automated business system.
An automated business system allows association between discovered
objects in IBM Tivoli Business Systems Manager to Business System Views.
This will allow low maintenance of the Business System View creation.
򐂰 Priority determination: each object in the Business System View has a priority
to determine how much effect its outage has on the Business System View’s
status. This status needs to be evaluated and determined carefully to allow
the Business System View status to reflect an actual business process or
application status.
򐂰 Change management for Business System Views operation changes needs
to be established. What happens if a machine is reallocated to a different
function, or maybe additional capacity is added or removed for a certain on
demand function?
– Maintenance considerations:
•
•
•
Components that go away
Components that change function
Components that are added
– How do you know about changes in the infrastructure that impact the
application?
– How do you know about changes to the application?
򐂰 Reporting
– Who will be the target(s) for the view(s)/report(s)?
– How do reports need to be made available, and how often?
– Is reporting required for every view?
򐂰 Build small reusable business systems.
Limit the number of resources and nested business systems.
Limit to 10 000 within each business system.
򐂰 Considerations for operators:
IBM Tivoli Business Systems Manager operators need to be listed and
categorized. You need to decide the roles they will be assuming in the IBM
79
Tivoli Business Systems Manager structure. There are four roles in IBM Tivoli
Business Systems Manager:
–
–
–
–
Super Administrator
Administrator
Operator
Restricted Operator
Additionally, for each group of operators, you need to gather their usage
requirements, such as:
– What are the relevant Business System Views?
– What are the required actions that they will perform?
– Do all the components they are responsible for belong in the Business
System Views that are relevant?
Additional Business System Views may be needed for certain operators.
3.4.6 Data collection design
The historical monitoring design for the Business Service Management
implementation relates to the implementation of IBM Tivoli Service Level Advisor
with its underlying product, Tivoli Data Warehouse.
Data source and ETL planning
For each data source, Tivoli Data Warehouse loads the data using an ETL
(Extract-Transform-Load) program. These are typically called Source ETLs.
Measurement data sources need to be identified and listed. Appropriate ETL
programs need to be installed or developed for non-standard monitoring tools.
Data is initially loaded into the Central Data Warehouse (CDW); this needs to be
completed before the second batch of ETL needs to be dealt with. The second
set of ETLs are called Target ETLs. The ETLs that load data into IBM Tivoli
Service Level Advisor database are considered target ETLs.
ETL programs perform data collection in a scheduled manner. You define the
schedule according to which ETLs should be run. You need to understand how
data is collected for the data source to define the schedule. Figure 3-6 on
page 81 shows the data flow for Tivoli Data Warehouse.
80
ITM_DB
TWH_MART
Target ETL
Source ETL
Objects
TWH_CDW
DYK_MART
DYK_CAT
WSC_DB
Figure 3-6 Tivoli Data Warehouse data flow
The following are specific considerations for some of the data sources:
򐂰 The IBM Tivoli Monitoring historical database is only loaded at midnight each
day. Therefore, the most effective load of IBM Tivoli Monitoring data will be
after midnight.
򐂰 The IBM Tivoli Business Systems Manager objects database is extremely
busy, so it is preferable to perform the ETL load in an off-peak period.
򐂰 The WSC_DB from the IBM Tivoli Monitoring for Transaction Performance is
loaded with a schedule that is specified from the Web interface.
Sizing estimate
The primary concern of a data warehousing application is sizing. Refer to the
redbook Planning a Tivoli Enterprise Data Warehouse Project, SG24-6608 to get
sizing and other planning information.
A Microsoft Excel spreadsheet is provided as a part of the redbook above at:
ftp://www.redbooks.ibm.com/redbooks/SG246608/SG246608.zip
When completed, it shows important aspects of database size and expected ETL
runtime. The input parameters include:
򐂰
򐂰
򐂰
򐂰
Enabled application
Estimated machine processing throughput
Measurement collected per hour
Time to keep the history data
A sample sizing spreadsheet window is shown in Figure 3-7 on page 82.
81
Figure 3-7 Sizing spreadsheet
3.4.7 Service Level management design
From the Service Level objective list that you acquired from 3.3.2,
“Documentation of Service Level objectives” on page 54, you can start building
the components of the Service Level Advisor. The building blocks of IBM Tivoli
Service Level Advisor are shown in Figure 3-8 on page 83.
82
Schedule:
Prime Time
M - F: 8 - 18 EST
S - Su: 8 - 12 EST
Offering:
Web performance -Gold
Schedule:
Continuous
All days 0 - 24 EST
Offering:
Web performance -Silver
Order
Finance Intranet
Performance
Realm: Corporate
Customer:
Finance
Order
Web Store
Internet
Performance
Customer:
Web Store
Customer:
Supplier Mgmt
Schedule:
Workdays
M - F 9 -17 EST
Offering:
Application performance
Order
EDI Performance
Figure 3-8 IBM Tivoli Service Level Advisor components
Data feeds
Historical data needs to be collected. This information is mainly coming from the
monitoring subsystems.
Defining the realms and customers
The different business processes that the IT department serves can be broken
down into realms and customers.
򐂰 Realm
In IBM Tivoli Service Level Advisor, a grouping of customers is used to
organize customer information and, in some cases, to control access to that
information. Customers might be grouped by region, by company, by divisions
within a company, or using some other logical grouping. Customers can be
assigned to one or more realms.
򐂰 Customer
A party that enters into a Service Level Agreement with the provider of a
particular service is a customer. Customers are associated with available
Service Level Agreement orders. Customers can be given access to the
results of Service Level Agreement evaluations and trend analyses to validate
their Service Level Agreements. Customers can be internal (members of a
department within the enterprise) or external (a member, department, or
company), associated with a service provider.
83
Defining service offerings
A service offering is a set of definitions of which IT services are grouped together.
Typically, an offering consists of a set of IT component definitions that can be
mapped later to one or more customers. This component selection reflects a
certain type of customer.
򐂰 Offering
In IBM Tivoli Service Level Advisor, this describes a service with guaranteed
Service Levels. Offerings are associated with business schedules and form
the building blocks for customer orders and Service Level Agreements.
Offerings can be differentiated to provide Service Level choices to customers
(like "Gold," "Silver," and "Bronze" levels of service). An offering must be in
the Published state to be included in a Service Level Agreement order.
򐂰 Offering component
This supplies the metrics for offerings and customer orders. At the time of an
offering creation, one or more offering components are selected. IBM Tivoli
Service Level Advisor checks to determine the number of measurement
sources for a component.
For example, a Web Services service offering contains the following information:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
Transaction response time
Server availability
Database availability
HTTP Server availability
WebSphere application server availability
Overall Business System View availability
The above information is often referred to as components and metrics:
򐂰 Component
The basic unit of service used to create a service offering. A component is an
entity about which measurements are collected for reporting purposes. For
example, a component can be a specific Web site or a particular application
running on a Web application server.
򐂰 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.
The whole offering can be defined to several business processes as long as they
are all using Web-based applications with a database back office.
84
Time-wise, an offering is qualified with a period and schedules.
򐂰 Business schedule or schedule
A timeline of the operations of a business, with the timeline segmented into
different operational states. Valid states include peak, off-hours, and
no-service (scheduled downtime for maintenance).
򐂰 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.
Mapping customers with offering
After the customers and the offerings are defined, you must deal with the
mapping process. In IBM Tivoli Service Level Advisor terms, this is called
creating an order.
In IBM Tivoli Service Level Advisor, the order is the process by which an SLA is
entered into the IBM Tivoli Service Level Advisor. It 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.
85
86
4
Chapter 4.
Business Service
Management sample
implementation
In this chapter, we describe the details of the implementation step for Business
Service Management in a sample environment. We will walk through the major
implementation tasks and show how certain actions can be achieved. The
discussion is divided into the following sections:
򐂰 4.1, “Sample environment” on page 88 presents the sample environment in
which we will work
򐂰 4.2, “Constructing the solution” on page 90 details the creation of the solution.
򐂰 4.3, “Implementation overview” on page 99 outlines the implementation steps.
87
4.1 Sample environment
A typical implementation for Business Service Management is usually performed
in stages. Stages are chosen based on the business function that needs to be
implemented first. You need to choose the most important business function in
your enterprise to implement first because this accelerates usage and buy-in for
the application.
Implementation starts when the planning tasks described in Chapter 3, “Planning
for Business Service Management” on page 43 are completed. You are then
ready to start the actual work.
The sample environment which we manage is a simple e-business situation with
two sets of Web and Web application servers with a single database. This is a
very simplified case since we are constrained by time to implement the
environment. The environment used is shown in Figure 4-1.
BSM2
IBMTIV2
IBM HTTP Server
WebSphere Apps Server
BSM7
DB2 database
IBM HTTP Server
Figure 4-1 Sample application environment
We assume that this Web application is part of a Web store business process.
We have performed the decomposition as discussed in 3.3.1, “Business process
decomposition” on page 48 and the result is shown in Figure 4-2 on page 89.
88
Business Process:
Web Commerce
Application:
Web Store
Application:
Customer
Service
BSM2 - IBM HTTP Server
BSM2 - WebSphere
BSM7 - WebSphere
IBMTIV2 - DB2 - ITSOBAN1
WebServer
WebServer
Application Server
Application Server
Database
Database
BSM2 - WebSphere
BSM7 - WebSphere
IBMTIV2 - DB2 - ITSOCS
Figure 4-2 Business process decomposition
Note: The application environment which we discuss here is a very simplified
Web environment. We have put aside the fact that a true e-business
application will contain at least a firewall and authentication system.
The Service Level Agreement for the Web Commerce business process is
described in Table 4-1 on page 90.
Chapter 4. Business Service Management sample implementation
89
Table 4-1 Service level objective for Web Commerce business process
Application
Metric
Objective
Measurement
Web Store
Transfer
transaction
Less than 3 secs on backend
processing for 95% of
transactions
Quality of Service monitor
samples every 5 transactions
Availability
98% available for standard time
of 6AM to 11PM
90% available for the rest
Synthetic transaction samples
every minutes
Customer
Service
e-Ticket open
transaction
Less than 3 secs on backend
processing for 95% of
transactions
Quality of Service monitor
samples every 5 transactions
Availability
98% available for standard time
of 6AM to 11PM
90% available for the rest
Synthetic transaction samples
every minutes
In this sample implementation, we will define the environment from scratch,
assuming there is no current monitoring scheme and all monitoring is performed
using IBM software.
Now we will go through the design phase that is discussed in 3.4, “Designing the
solution” on page 61 to construct the result.
4.2 Constructing the solution
In this section, we will assign the appropriate solution for the design phases
discussed in 3.4, “Designing the solution” on page 61. The design is performed in
the following stages:
򐂰 4.2.1, “Solution structure” on page 91 is where we select the products to be
used
򐂰 4.2.2, “Solution configuration” on page 91 lists a detailed view of servers and
required software to implement the functions
򐂰 4.2.3, “Monitoring architecture” on page 93 discusses the creation of a
monitoring standard based on the information input
򐂰 4.2.4, “Object class selection” on page 94 provides some considerations for
deciding what objects needs to be defined in IBM Tivoli Business Systems
Manager and how these objects will be monitored
90
򐂰 4.2.5, “Business System View design” on page 95 discusses the translation of
the business process decomposition into impact monitoring using the
򐂰 4.2.6, “Data collection design” on page 96
򐂰 4.2.7, “Service Level monitoring” on page 98
4.2.1 Solution structure
Based on the discussion in 3.4.1, “Solution structure” on page 62, we determine
the necessary software for our solution.
򐂰 For the monitoring function, we make use of the following products:
–
–
–
–
IBM Tivoli Monitoring for Databases: DB2
IBM Tivoli Monitoring for Web Infrastructure: Apache Web Server
IBM Tivoli Monitoring for Web Infrastructure: WebSphere Application
Server
– IBM Tivoli Monitoring for Transaction Performance: Web Performance
– IBM Tivoli NetView
򐂰 For the real-time monitoring of the Business Service Management:
– IBM Tivoli Enterprise Console
– IBM Tivoli Business Systems Manager
򐂰 For the historical reporting and Service Level management, we use:
– Tivoli Data Warehouse
– IBM Tivoli Service Level Advisor
4.2.2 Solution configuration
From the discussion in 3.4.2, “Hardware and software configuration” on page 63,
we select the machines that we will use in our solution. The resulting
environment is shown in Figure 4-3 on page 92.
91
IBMTIV1
IBMTIV5
Tivoli Framework 4.1
Tivoli Management Agent
Web Services Courier
TBSM Event Enablement
BSM6
IBM Tivoli Service Level Advisor 1.2
Tivoli NetView V7.1.3
TBSM Adapter
BSM9
BSM5
Tivoli Internet Management Server
BSM4
IBM Tivoli Data Warehouse 1.1.1
BSM2
BSM1
IBMTIV2
Quality of Service
endpoint
Browsers
BSM8
IBM HTTP Server
TMA + ITM Web Infrastructure
BSM7
DB2 database
TMA + ITM Databases
Quality of Service
endpoint
IBM Tivoli Business
Systems Manager
BSM3
IBM HTTP Server
TMA + ITM Web Infrastructure
Figure 4-3 Sample application environment with monitoring function
In our sample environment, the management machines are more than the actual
managed environment. Most of the infrastructure that we use here is scalable to
manage a very large number of servers, but we use it to manage a very simple
environment.
In a real-world implementation, these are the changes that we recommend for
the management environment:
򐂰 Separate the IBM Tivoli Enterprise Console server from the Tivoli
Management Framework server
򐂰 Use a dedicated endpoint for the Web Services Courier endpoint, instead of
having it reside on the Tivoli Management Framework
򐂰 Consider dedicating a separate database server instead of using the Tivoli
Management Framework Server
92
򐂰 Use a separate administration server and runtime server for the IBM Tivoli
Service Level Advisor
򐂰 Other servers, such as the Tivoli Data Warehouse server, IBM Tivoli Business
Systems Manager servers, IBM Tivoli NetView server and Tivoli Internet
Management Server have been configured on their own machines,
appropriately.
4.2.3 Monitoring architecture
The monitoring implementation uses the following three different schemas:
򐂰 “IBM Tivoli Monitoring profiles” on page 93
򐂰 “Internet monitoring jobs” on page 94
򐂰 “IBM Tivoli NetView network monitoring” on page 94
IBM Tivoli Monitoring profiles
The monitoring approach that we use is a minimalist approach. We will only
monitor resources to fulfill the Service Level Agreement. Therefore, it is
important to make the SLA as comprehensive as possible for the business user,
while retaining the flexibility for the IT department to fulfill it.
IBM Tivoli Monitoring has provided several built-in functions for our purposes,
such as:
򐂰 An automated resolution event called TMW_Clearing for any outstanding
event
򐂰 A heartbeat function for the monitoring engine
򐂰 Recording of historical data into RDBMS
IBM Tivoli Monitoring profiles need to be synchronized whenever the monitoring
engine is stopped. When the monitoring engine restarts, it is not aware of its last
state and does not send any resolution events. This should be addressed using a
script that triggers events when a monitoring engine starts.
Our naming convention uses Profile Manager with the suffix PM and Profiles with
the suffix Pr. We implement the Profile Manager structure as shown in Figure 4-4
on page 94.
93
ITM_PM
ITM_Apache_Pr
ITM_WAS_Pr
ITM_DB2_Pr
ITM_Win_Pr
ITM_UNIX_Pr
Apache_PM
WAS_PM
DB2_PM
WinSrv_PM
UNIXSrv_PM
Figure 4-4 Profile Manager structure
As shown in Figure 4-4, we created a Profile Manager container for each
category of subscribers. These subscribers then map to the IBM Tivoli
Monitoring profiles in the ITM_PM Profile Manager. Note that ITM_PM is a
database Profile Manager, while the other Profile Managers are dataless Profile
Managers.
Internet monitoring jobs
For Internet monitoring using the IBM Tivoli Monitoring for Transaction
Performance, we use the Quality of Service function to monitor the back-end
response time and the Synthetic Transaction Investigator to measure the Web
site availability. This is the primary indicator of the Service Level that we will use.
IBM Tivoli NetView network monitoring
As with any Web-based solution, network monitoring is critical. The network has
to be up and available for the components to function. We use IBM Tivoli
NetView to monitor the network part of the solution.
4.2.4 Object class selection
Details for this are given in 3.4.4, “IBM TBSM object type selection” on page 69.
For flexibility and customizable features, we decided to use the IBM Tivoli
Enterprise Console interface instead of the Common Listener. While the
Common Listener function has fewer implementation tasks, it also has fewer
customization options.
94
For granularity of objects, we decided to use the default object types provided by
the IBM Tivoli Monitoring solutions. These objects have been configured using
the IBM Tivoli Enterprise Console and evaluated for performance and granularity.
4.2.5 Business System View design
Details for this are given in 3.4.5, “Business System View design” on page 74.
We decided to use the separate Business System View because it can easily be
automated in its creation and also because it provides an easy configuration for
the resources that directly affect the business process and those that do not.
The business system configuration is shown in Figure 4-5.
Online Store
Customer
Service
Web Store
Account
Payable
All Systems
Networking
Windows
Machines
IT Resources
UNIX machines
Account
Receivable
Finance
Web resources
General Ledger
Supplier
EDI
Databases
Figure 4-5 Business System View design
The expected users of IBM Tivoli Business Systems Manager and the Business
System Views that they will use are listed in Table 4-2.
Table 4-2 Business System View assignment
User
Role
BSV
Business Process Owners
Restricted
Operator
Business process BSVs
Application owners
Restricted
Operator
Application BSVs
UNIX administrator
Operator
UNIX machines
Windows administrator
Operator
Windows Machines
Network administrator
Operator
Networking
95
User
Role
BSV
Web administrator
Operator
Web resources
Database administrator
Operator
Databases
IT manager
Administrator
IT resources
TBSM administrator
Super
Administrator
All BSVs; All resources view
Helpdesk
Operator
IT resources
CEO
Restricted
Operator
All systems
4.2.6 Data collection design
For data collection design, as discussed in 3.4.6, “Data collection design” on
page 80, we used the planning spreadsheet.
First, we entered the necessary information for our environment in the App
Properties tab, as shown in Figure 4-6 on page 97.
96
Figure 4-6 Tivoli Data Warehouse planning spread sheet
We also changed the throughput for the ETL because it depends a good deal on
the performance of the machine hosting the databases. In our environment, all
databases reside in the same machine source, so we have quite a low
throughput; also, the IBM Tivoli Business Systems Manager source resides in a
Microsoft SQL Server database. We changed the throughput into 1000 rows for
most of the sources and 500 rows for the IBM Tivoli Business Systems Manager
source. We also modified the target ETL throughput into 2000 rows.
The resulting sizing information is shown in Figure 4-7 on page 98.
97
Figure 4-7 Result of the sizing database
Based on the results shown in Figure 4-7, the total processing of the ETL
programs is estimated at 1 hour and 23 minutes. Therefore, the window to run
the ETL can be allocated from midnight to 2 a.m. A sample run schedule is
shown in Figure 4-8.
23:00
24:00
1:00
2:00
AMY_m10_build
StarSchema_Pro
cess
ITM_DB
collection
GWA_m10_ETL
2_ Process
AMX_c05_ETL1_
Process
WSC_DB
collection
BWM_c10_Load
_Warehouse_
Process
DYK_m05_
Populate_
Registration_
Datamart_Proces
DYK_m10_
Populate_
Measurement_
Datamart_Proces
IZY_m05_Dimen
sion_Process
IZY_m10_Fact_P
rocess
CTD_m05_ETL2
_ Process
GTM_c05_
LOBState_
Process
Timeline
Figure 4-8 Collection schedule
4.2.7 Service Level monitoring
For the Service Level monitoring solution, as discussed in 3.4.7, “Service Level
management design” on page 82, we use the following scheme.
98
The Service Level structure for the IBM Tivoli Service Level Advisor can be
summarized to monitor the following:
򐂰 Business System status for the related business system (a green percentage)
򐂰 WebSphere transaction rate
򐂰 Transaction response time from the QoS system
4.3 Implementation overview
In this redbook, we will not discuss installation steps and processes for the
software product that we use. Refer to the product documentation for installation
instructions. Other references are provided in “Related publications” on
page 165. This implementation also starts after the design process which we
discuss in 4.2, “Constructing the solution” on page 90.
The implementation procedure consists of the following high-level steps:
1. The first step is to implement the server with all its prerequisite software and
management software. These steps will not be discussed in this redbook. A
summary of the installed software is provided in Table 4-3 on page 100.
2. We define the monitors; this includes configuring IBM Tivoli NetView maps,
defining IBM Tivoli Monitoring profiles and defining Tivoli Internet
Management jobs. The discussion is provided in 4.4, “IBM Tivoli Monitoring
profiles” on page 101, 4.5, “IBM Tivoli NetView monitoring” on page 112 and
4.6, “Web transaction response time monitoring” on page 120.
3. For the real-time monitoring section, you need to monitor and collect all the
metrics from the installed monitors. In our environment, these metrics are
collected, analyzed and applied using the IBM Tivoli Enterprise Console. See
4.7, “Defining TEC rules” on page 132.
4. We configure IBM Tivoli Business Systems Manager object types as shown in
4.7.6, “Defining TBSM object types” on page 140.
5. For the real-time monitoring section, you create the business systems that
represent the business functions. These business systems must be defined
with flexibility to adapt to the changing environment. See 4.7.8, “Defining
business systems” on page 144.
6. Operator defininition is discussed in 4.7.9, “Defining TBSM operators” on
page 147.
7. For historical data collection, we need to set up Tivoli Data Warehouse to
collect data from the monitoring application. See 4.8, “Configuring Tivoli Data
Warehouse” on page 151.
99
8. For Service Level monitoring, we need to set up IBM Tivoli Service Level
Advisor offerings, customers and orders. See 4.9.1, “Defining the operation”
on page 160.
The installed software shown in Table 4-3 is a subset of the overall software
configuration shown in Table 3-9 on page 64.
Table 4-3 Software configuration list
Machine name
Operating System
Software list
IBMTIV1
TMR Server
Gateway
RIM host
AIX 5L
DB2 Universal Database Version 7.1
IBM Tivoli Business Systems Manager distributed
edition 2.1.1
IBM Tivoli Monitoring for Transaction Performance:
Web Service Courier endpoint
IBMTIV5
Windows 2000 Server
IBM Tivoli NetView 7.1.3
BSM9
TIMS
Windows 2000 Server
Internet Management Server
BSM4, BSM8
QoS endpoint
Windows
QoS Endpoint
STI endpoints
Windows
STI endpoint
BSM1
TBSM database
server
Windows 2000
Advanced Server
MKS Toolkit V8
Microsoft SQL Server 2000
BSM3
TBSM console and
propagation server
Windows 2000
Advanced Server
MKS Toolkit V8
BSM5
TDW database
server
TDW Control Server
Windows 2000 Server
DB2 Universal Database Server V7.1 FixPack 5
Tivoli Data Warehouse enablement packs
100
Machine name
Operating System
Software list
BSM6
TSLA database
server
TSLA admin server
TSLA reporting
Server
Windows 2000 Server
IBM Tivoli Service Level Advisor 1.2 Server
IBM Tivoli Service Level Advisor 1.2 Task Drivers
IBM Tivoli Service Level Advisor 1.2 Reports
BSM, BSM7
Web and Web
Application Servers
Windows 2000 Server
IBM HTTP Server V1.3.16
WebSphere Application Server V4.0.3
IBMTIV2
Database Server
AIX 4.3.3
4.4 IBM Tivoli Monitoring profiles
IBM Tivoli Monitoring profiles are Tivoli Management Framework based profiles.
These profiles are created using the Tivoli Desktop interface. Each profile is
created inside a container called a Profile Manager. The Profile Manager lists the
potential subscribers for the profile. The IBM Tivoli Monitoring profile object is
called Tmw2kProfile.
4.4.1 Profile Managers and IBM Tivoli Monitoring profiles
A Profile Manager window is shown in Figure 4-9 on page 102.
101
Figure 4-9 Profile Manager
We created a Tmw2kProfile for each type of monitoring that we use. The profile
consists of the list of resource models contained within it. For each resource
model, the following information is specified:
򐂰 The indications or metrics that are evaluated in the resource models
򐂰 The threshold of each indication and how many violations cause an alert (see
Figure 4-12 on page 105)
򐂰 The responses that can be triggered
򐂰 The logging option for the resource model
The window to define the Tmw2kProfile object is shown in Figure 4-10 on
page 103.
102
Figure 4-10 Creation of Tmw2kProfile
Click Add. We will then add a new resource model to the Tmw2kProfile object.
The Add resource model window is shown in Figure 4-11 on page 104.
103
Figure 4-11 Resource model configuration window
These are the descriptions of the fields and buttons for the Add Resource Model
window shown in Figure 4-11:
104
Category
Lists the existing resource model categories depending
on the installed products.
Resource Model
Lists the resource models in the selected category.
Cycle time
Determines the interval at which the resource model will
check its indications.
Threshold list
Lists possible indications and their thresholds; when
selected, the threshold entry is shown.
Indication button
Opens the indication setting dialog.
Parameters button
Sets monitoring filters and logging parameters.
Schedule button
Determines the time interval within which this profile can
be active.
Logging button
Offers a selection of logging options to use.
The Indication window is shown in Figure 4-12..
Figure 4-12 Indication setting
In Figure 4-12, the following can be configured:
򐂰 Occurences and holes setting
򐂰 Event triggering setup
򐂰 Action tasks
In Figure 4-13 on page 106, the parameter dialog is shown.
105
Figure 4-13 Parameter setting
The parameter setting window in Figure 4-13 allows you to select which metrics
will actually be logged in the historical database and also the monitoring filter, in
this case the Application Names to monitor for SQL statement activity.
The logging option is shown in Figure 4-14 on page 107.
106
Figure 4-14 Logging option
You should specify the logging option to log TEDW data for collection to Tivoli
Data Warehouse.
After you have all the resource models defined, back in the Tmw2kProfile
window (as shown in Figure 4-10 on page 103), click Edit -> Properties and
enable the event forwarding function, as shown in Figure 4-15 on page 108.
107
Figure 4-15 Event setting
You also need to enable the forwarding setting. Either forward to IBM Tivoli
Enterprise Console or to IBM Tivoli Business Systems Manager directly using
Common Listener. We decided to use the interface to IBM Tivoli Enterprise
Console.
4.4.2 Detailed profile setting
In this section, we show the detailed settings of the Resource Models in our
Tmw2kProfiles objects. The settings are selected based on the monitoring need.
All these events are sent to IBM Tivoli Enterprise Console.
Apache Web Server monitoring
Apache Web Server monitoring provides the following functions:
򐂰 Makes sure that the process is always running; the operator needs to be
notified when the process is not running and cannot be started automatically.
򐂰 Counts the hit rate for reporting, then reports any exceptionally high hit rate.
򐂰 Reports excessive numbers of error requests, perhaps resulting from a Denial
of Service attack.
108
Note: Depending on the setup of your environment, you may want to have the
authentication fail if it is performed by the Web server; a typical
implementation performs authentication outside of the Web server itself.
We create the profile ITM_Apache_Pr with the content shown in Table 4-4.
Table 4-4 Monitoring resource models
Resouce model
Indication and threshold
Logging attribute
Apache_
Performance
Apache_THR_FailedLoginPerSec
5.000000
Apache_THR_ServerFailuresPerSec
5.000000
Apache_THR_FailedPagesPerSec
20.000000
Apache_THR_KBytesPerSec 70.000000
Apache_THR_RequestsPerSec
50.000000
Server.ServerName,WebSiteName
GWA_Server_failures_count
GWA_Failed_pages
GWA_Failed_connections_count
GWA_Hit_count
GWA_Requests_rate
GWA_Successful_login_count
GWA_Failed_login_count
GWA_Kbytes_rate
Apache_
WebSiteAvailability
N/A
Server.ServerName,WebSiteName
GWA_Website_running
GWA_Website_stopped
WebSphere Application Server monitoring
WebSphere Application Server is a critical piece of the application. All the
transactions are handled there. The monitoring aim is to maximize the availability
and performance of the Web transaction. Therefore, the following monitoring is
performed:
򐂰 Monitor and log the status of the WebSphere Application Server
򐂰 Monitor and log the JVM memory usage to ensure that there is enough
storage available for the application
Note: Our application runs as servlets, without EJB; therefore, we only use
the WebApplication monitor, without the EJB monitor or transaction
monitor.
򐂰 Monitoring for DB2 connection contention
򐂰 Monitoring for number of HTTP sessions
The ITM_WAS_Pr profile that we define to address the WebSphere component
is summarized in Table 4-5 on page 110.
109
Resouce model
Indication and threshold
Logging attributes
WebSphereAS_
ApplicationServer
_ 10
N/A
Name,AdminServerName:
WebSphere_server_state_up
WebSphere_server_state_down
WebSphere_server_state_initializing
WebSphere_server_state_unknown
WebSphereAS_
JVMRuntime_10
WebSphereAS_high_JVMRuntime_
usedMemory 95.000000
Name,ApplicationServer.Name,Admin
Server.Name
Total_JVM_memory
Used_JVM_memory
WebSphereAS_
ThreadPool_10
WebSphereAS_high_ThreadPool_
activeThreads 95.000000
Name,AdminServer.Name,ApplicationS
erver.Name
Active_threads_to_pool_size_ratio
WebSphereAS_
WebApps_10
WebSphereAS_high_Servlet_errors
0.000000
WebSphereAS_high_Servlet_response
_time 750.000000
"Name,AdminServer.Name,Application
Server.Name,WebApplication.Name
Name,AdminServer.Name:
Servlet_request_rate
Average_servlet_response_time
Concurrent_servlet_requests
Servlet_error_rate
WebSphereAS_
HTTP_Sessions_
10
WebSphereAS_high_HTTPSessions_
liveSessions 1000
Name,ApplicationServer.Name,Admin
Server.Name
Live_servlet_sessions
DB2 monitoring
The database monitoring needs to ensure the performance of the database to
fulfill requests from the WebSphere Application Server. This result in the
following monitoring:
򐂰 Monitoring and logging of the availability of the DB2 instance
򐂰 Monitoring of the Buffer Pool hit ratio, one of the most important parameters
of DB2 performance
򐂰 Monitoring of the DB2 subsystem connection and tablespaces status
򐂰 Monitoring of locks and deadlocks
The DB2 monitoring details are shown in Table 4-6 on page 111.
110
Resouce model
Indication and Threshold
Parameters
DB2 Buffer Pools
High_AvgPoolReadTime 200
High_AvgPoolWriteTime 200
Low_PctBufferPoolHits 90
High_AvgSyncReadTime 200
Low_AvgAsyncWritesPerPoolWrite 30
Low_PctIndexHits 90
High_AvgSyncWriteTime 200
High_AvgPoolIOTime 200
Low_AvgAsyncReadsPerPoolRead 50
High_AvgSyncIOTime 200
High_AvgPoolWritesPerPoolRead 100
N/A
DB2 Activity
Old_LastBackupTimestamp 2
High_PctConnectionsUsed 80
High_ConnectionErrors 100
High_CurrentConnections 50
High_SpaceUsedDMSTablespace 85
High_SpaceUsedSMSTablespace 0
High_MostRecentConnectResponse 5
High_ConnWaitingForHost 30
N/A
DB2 Instance
Status
High_PctConnectionsExecuting 75
DB2 locks and
Deadlocks
High_AppPctLockListUsed 50
High_AvgLockEscalationConn 5
High_AvgLocksHeld 5
High_AppDeadlocks 6
High_DeadlocksDelta 4
High_AppLockEscalations 6
High_PctIntDeadlockedRollbacks 80
High_DBPctLockListUsed 50
High_PctDeadlockRollbacks 80
High_LockEscalationsDelta 3
High_LockTimeoutsDelta 10
N/A
Windows server monitoring
For Windows server, we monitor the following attributes:
򐂰
򐂰
򐂰
򐂰
CPU utilization
Memory usage
Free disk space
Network card activity
The contents of the ITM_WinOS_Pr profile are shown in Table 4-7 on page 112.
111
Resouce model
Parameters
Memory
PctMemoryFree 10
-
Network Interface
Card
Utilization 90%
Physical Disk
Free space 50 MB
Processor
CPU utilization 95%
C:\
UNIX server monitoring
For the UNIX server, we monitor the following attributes:
򐂰
򐂰
򐂰
򐂰
CPU utilization
Memory usage
Free disk space
Network card activity
The contents of the ITM_UNIXOS_Pr profile are shown in Table 4-8.
Resouce model
Parameters
CPU
Utilization 95%
File System
Free space 50 MB
/var, /home/db2inst1
Memory
PctMemoryFree 10
-
Network Interface
Utilization 90%
-
4.5 IBM Tivoli NetView monitoring
To enable access to NetView from a remote Web console (either with the Web
Console Application or from within a browser applet), be sure to register and start
the netviewd daemon. You can do this by issuing \usr\OV\bin\ovaddobj
\usr\OV\lrf\netviewd.lrf from a command line.
Next, define at least one user by using the nvsetup application in order to gain
access to NetView through the Web console. You will need a user definition to
access NetView data from within IBM Tivoli Business Systems Manager.
To add a user, execute the \usr\OV\bin\nvsetup utility or click Tivoli NetView ->
Administration -> Server Setup to display the setup dialog as shown in
112
Figure 4-16. In this dialog, select Web Server from the drop-down list and click
Configure Web Console Security.
Figure 4-16 Invoking Web console Security from nvsetup
Alternatively, you can start the configuration utility from the native NetView
console by clicking Administer -> Security Administration -> Web Console
Security. In both cases, the Java-based Web Console Security application
opens with the initial dialog box shown in Figure 4-17 on page 114.
113
Figure 4-17 The Web Console Security dialog box
In this dialog, you can add and edit users, roles, and views. Clicking Selected ->
Add or selecting the Add icon in the button row will open the Add User dialog
Figure 4-18 The Add User dialog box
114
Enter a user name and a password. For now, assign the SuperUser role to the
new user. Because an IBM Tivoli Business Systems Manager user might need to
access all of the network topology, select No scoping restrictions for the Scope
field. Click OK to close the dialog box, then click File -> Save to save the new
user definition. You will be asked to restart the Web server to activate the
changes. Reply Yes to restart the Web server.
Now from the NetView setup window, go to the Discovery tab and click Edit for
the seed file. The seed file editor is shown in in Figure 4-19.
Figure 4-19 NetView seed file editor
We want to limit the discovery to our environment only, as shown in Figure 4-20
on page 116.
115
Figure 4-20 Adding discovery filter to our subnet only
Configuring IBM Tivoli Enterprise Console forwarding is done by clicking Tivoli
NetView -> Administration -> Configure IBM Tivoli Enterprise Console
Adapter. The following configuration assumes that we have a Managed Node
installed in the ibmtiv5 where we run NetView. Without this, you would need to
use a connection that is not secure by specifying the IP address of the IBM Tivoli
Enterprise Console, its operating system, and its port.
The configuration of the adapter is done through the dialog shown in Figure 4-21
on page 117.
116
Figure 4-21 Configuring TEC adapter
As shown in Figure 4-21, the only events that we will send are the Link_Down
and Link_Up events and those will be sent for all the SmartSets.
Because commands launched from IBM Tivoli Business Systems Manager to
NetView are executed locally, the NetView Web console must be installed on all
workstations that will be used to access IBM Tivoli Business Systems Manager
and its Java console. NetView provides a download page with install images of
the NetView Web console for various platforms. You can access this download
page by connecting to NetView Server using a Web browser. In our case, the
download page is:
http://ibmtiv5:8080/download
and 8080 is the default port on which the NetView Web server listens. A
download page is shown in Figure 4-22 on page 118.
117
Figure 4-22 The NetView Web Console download page
For a Windows-based workstation, select nvwcinstal.exe and download the file.
This is a Windows install image which you can install on the target workstation.
Note: With the current implementation of the NetView IBM Tivoli Business
Systems Manager adapter, a launch of the NetView Web Console from the
IBM Tivoli Business Systems Manager Java console will not work with the
default path the Web Console installer suggests. One component installed on
the IBM Tivoli Business Systems Manager side, nvlaunch.jar, only supports
file paths in the classic 8.3 notation. We recommend that you change the
install directory during the NetView Web Console install to something like
c:\NVWC, as shown in Figure 4-23.
118
Figure 4-23 Changing the default path for the NetView Web Console
The install procedure creates an object on your Windows desktop. Double-click
that icon to launch the Web Console and open the login window as shown in
Figure 4-24.
ibmtiv5
Figure 4-24 Web Console login window
119
Type in your user ID, password, the hstname of your NetView sever, and the port
on which the NetView Web Console is listening.
After a successful logon, select File -> Open from the menu to display a map
inside the Web Console as shown in Figure 4-25.
Figure 4-25 Open a map
4.6 Web transaction response time monitoring
We need to define and manage the response time for the Web Services
transactions. We capture this information using the IBM Tivoli Monitoring for
Transaction Performance: Web Performance. This product used to be called the
Tivoli Web Services Manager.
120
There are two tools that we used:
򐂰 The Quality of Service monitor, which collects a sample response time of
actual end-user experiences for browsing the Web site
򐂰 The Synthetic Transaction Investigator monitor, which monitors the availability
and response time for a certain transaction
The IBM Tivoli Monitoring for Transaction Performance uses the Web browser to
administer its function. We log in to the Internet Management Server as shown in
Figure 4-26. The URL for us is http://bsm9/.
Figure 4-26 Log in to the Tivoli Internet Management Server
The initial menu that we were presented with is shown in Figure 4-27 on
page 122.
121
Figure 4-27 Initial TMTP menu
4.6.1 Quality of Service monitoring
We create Quality of Service jobs to monitor the critical transaction response
time on our Web servers. The jobs are called:
򐂰
򐂰
򐂰
򐂰
QOS_bsm2_transfer_01QOS job for bsm2 endpoint with transaction transfer
QOS_bsm7_transfer_01QOS job for bsm7 endpoint with transaction transfer
QOS_bsm2_eopen_01QOS job for bsm2 endpoint with transaction eopen
QOS_bsm7_eopen_01QOS job for bsm7 endpoint with transaction eopen
The following steps are taken to create the QOS jobs:
1. From the menu, select Quality of Service -> Create Quality of Service Job.
2. Assign the endpoint for the job as shown in Figure 4-28 on page 123. Click
Next.
122
Figure 4-28 QOS job - choose endpoint
3. Assign the Schedule for the job as shown in Figure 4-29; the definition shown
is for a continuous job. Click Next.
Figure 4-29 QOS job - define schedule
123
4. Assign the parameters for the job; we select the target URI condition for the
transaction that we want to monitor, as shown in Figure 4-30 on page 124.
Click Next.
Figure 4-30 QOS job - job parameter
5. Define the monitoring constraint (threshold) and event severity to be
generated, as shown in Figure 4-31 on page 125. Click Next.
124
Figure 4-31 QOS job - define constraint
6. Save the job as shown in Figure 4-32. Click Save.
Figure 4-32 QOS job - saving
7. Click Quality of Service -> Configure Events to configure event forwarding
to IBM Tivoli Enterprise Console. We only want to forward the response time
events that we want to be forwarded to IBM Tivoli Enterprise Console. The
result is shown in Figure 4-33 on page 126.
125
Figure 4-33 QOS events configuration
4.6.2 Synthetic Transaction Investigator monitoring
We also create Synthetic Transaction Recording for both the transfer and eopen
transactions using the STI Recorder, as follows:
1. Download the STI Recorder from the Web interface by clikcing Synthetic
Transaction Investigator -> Download Transaction Recorder.
2. Start the Recorder by selecting Programs -> Tivoli -> Synthetic
Transaction Investigator Recorder. The login dialog is shown in Figure 4-34
on page 127. It is the Web target realm login, not the Management Server
login.
126
Figure 4-34 Login to STI Recorder
3. Record the sample transaction flow and save it to the Management Server by
clicking the Save Transaction button. Authentication to the Management
Server is now required. The Save Transaction dialog is shown in Figure 4-35
on page 128.
127
Figure 4-35 Save a transaction
The STI jobs that we create are called:
򐂰
򐂰
򐂰
򐂰
STI_bsm2_transfer_01STI job for transfer to bsm2 endpoint
STI_bsm7_transfer_01STI job for transfer to bsm7 endpoint
STI_bsm2_eopen_01STI job for eopen to bsm2 endpoint
STI_bsm7_eopen_01STI job for eopen to bsm7 endpoint
The following procedure creates the STI jobs:
1. Click Synthetic Transaction Investigator -> Create Transaction Playback.
2. Specify the endpoint to use as shown in Figure 4-36 on page 129. Click Next.
128
Figure 4-36 STI job - specify endpoint
3. Specify the schedule to use as shown in Figure 4-37. Click Next.
Figure 4-37 STI job - continuous schedule
4. Specify the transaction to play back as shown in Figure 4-38 on page 130.
Click Next.
129
Figure 4-38 STI job - recorded transaction
5. Specify the proxy information as shown in Figure 4-39. Click Next.
Figure 4-39 STI job - proxy
6. Specify the constraint as shown in Figure 4-40 on page 131. Click Next. Here
you can define the response time measurement, HTTP return code and
content evaluation.
130
Figure 4-40 STI job - constraint definition
7. Specify the job name to use as shown in Figure 4-41. Click Save.
Figure 4-41 STI job - saving
131
8. Configure STI events by clicking Synthetic Transaction Investigator ->
Configure Events. The events that we choose for forwarding are shown in
Figure 4-42.
Figure 4-42 STI events configuration
4.7 Defining TEC rules
Since we decided to use IBM Tivoli Enterprise Console to transfer all events from
the monitoring systems to IBM Tivoli Business Systems Manager, we need to
prepare the IBM Tivoli Enterprise Console.
The IBM Tivoli Enterprise Console is based on a set of definitions called a rule
base. A rule base contains event format definitions in a format called baroc and
processing logic written in the Prolog language called rulesets. This information
needs to be customized to be able to send events to IBM Tivoli Business
Systems Manager.
4.7.1 Adding IBM Tivoli Monitoring rules
For the IBM Tivoli Monitoring product modules, there are default tasks, baroc
files and rulesets that are supplied by IBM. These supplied baroc files and
rulesets are listed in Table 4-9 on page 133.
132
Table 4-9 Files to be imported to rule base
Baroc and ruleset files location
Task or script
Apache HTTP server
generic_unix/TME/Apache/tec/
itmapache_tec_config_evtsvr.sh
CREATE “new_rule_base path
rule_base_activation”
forWebSphere Application
Server
generic_unix/TME/WSAPPSVR/tec
/
WebSphere Event Tasks ->
Configure_Event_Server
forDB2 database
generic/ITM/DB2/TECClasses/
DB2ManagerAdminTasks ->
ECC_Configure_TEC_Classes
IBM Tivoli Business
Systems Manager
aix4-r1/TDS/EventService/config/tb
smstatus/tbsmstatus.baroc
ihsttec.sh
aix4-r1/TMNT_TEC/
-
The tasks or scripts provided in Table 4-9 allow the creation of new rule bases
with the necessary baroc and ruleset files.
Warning: Be sure to evaluate the final rule to ensure that all necessary
rulesets are included in the Event Server target rules. Some of the tasks and
scripts actually left out rulesets for other modules.
4.7.2 IBM Tivoli Monitoring for Transaction Performance rules
For IBM Tivoli Monitoring for Transaction Performance, a baroc file is supplied in
the Internet Management Server, at $INSTHOME/TIMS/lib/TranPerf.baroc. You
need to include this baroc file in the final rule base manually. There are no default
processing rulesets for these events.
From 4.6, “Web transaction response time monitoring” on page 120, we forward
the following events to the IBM Tivoli Enterprise Console (both the violation and
recovery events):
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
QoS Backend Service Time
QoS Page Display Time
QoS Round Trip Time
STI Round Trip Time
STI Overall Transaction Time
STI Undesired Content found
STI URL not available
133
Violation events are sent as Critical, while recovery events are sent as Harmless.
There are rules to apply these events to our business system objects, so we
need to do the following:
1. To indicate the event type in the event, we use the sub-origin slot, which is
originally empty. A rule excerpt for this is shown in Example 4-1. We create
similar rules for all event classes that we want to work on.
Example 4-1 Rule to set sub-origin field
rule:
rule_WSM_QOS_Round_Trip_Time_Violation: (
description: 'WSM-QOS-Round-Trip-Time-Violation',
event: _event of_class 'WSM-QOS-Round-Trip-Time-Violation',
reception_action: (
bo_set_slotval(_event, sub_origin, 'WSM-QOS-Round-Trip-Time-Violation')
)
).
2. For failure events of Critical severity, we must indicate forwarding using the
IBM Tivoli Business Systems Manager exit ihstttec. However, since we want
to indicate to IBM Tivoli Business Systems Manager that the event actually
belongs to the Web server engine, instead of to the endpoint engine, we need
to perform some mapping. The forwarding rule is similar to that shown in
Example 4-2. The rule invokes a shell script in
$BINDIR/TME/TEC/scripts/TMTP_to_TBSM.sh.
Example 4-2 Forwarding rule - violation
rule:
rule_TMTP_Critical: (
description: 'TMTP violation events',
event: _event of_class within ['WSM-Quality-Of-Service',
'WSM-Synthetic-Transaction-Investigator']
where [
severity: equals 'CRITICAL'
],
reception_action: (
exec_program(_event,
'scripts/TMTP_to_TBSM.sh’, ‘’, [ ],
'YES'),
)
).
3. We also need to indicate that a recovery event must be sent to IBM Tivoli
Business Systems Manager. The rule to do this is shown in Example 4-3 on
page 135. You will notice that this rule is similar to the one shown in
134
Example 4-2. However, we prefer to split the rule to accomodate any different
processing that may be needed for the violation and recovery events.
Example 4-3 Forwarding rule - recovery
rule_TMTP_Harmless: (
description: 'TMTP recovery events',
event: _event of_class within ['WSM-Quality-Of-Service',
'WSM-Synthetic-Transaction-Investigator']
where [
severity: equals 'HARMLESS'
],
reception_action: (
'scripts/TMTP_to_TBSM.sh’, ‘’, [ ],
'YES'),
)
).
4. Now we need the script TMTP_to_TBSM.sh. When a script is invoked by an
IBM Tivoli Enterprise Console rule, it has access to the event’s information
slots in environment variables. The following translation is used for mapping
slot values to IBM Tivoli Business Systems Manager attributes:
-b (TBSM class)
TMTP;5.1
-m (message)
from msg slot
-h (hostname)
parsed from jobName slot
-i
hostname
-d
hostname
-p
from sub-origin slot contain class name
-s (severity)
from severity slot
Example 4-4 on page 136 shows the excerpt from TMTP_to_TBSM.sh.
135
Example 4-4 TMTP_to_TBSM.sh
#!/bin/sh
if [ "$severity" = "CRITICAL" ];
then
$TEC_BIN_DIR/../../TDS/EventService/ihstttec -b "TMTP;5.1" -i "$hostname"
-p "$EVENT_CLASS" -s "$severity" -t "EXCEPTION" -q "$origin" -m "$msg"
else
$TEC_BIN_DIR/../../TDS/EventService/ihstttec -b "TMTP;5.1" -i "$hostname"
-p "$EVENT_CLASS" -s "HARMLESS" -t "EXCEPTION" -q "$origin" -m "$msg"
fi
fi
4.7.3 IBM Tivoli NetView rules
Class files for NetView related events are provided from IBM Tivoli Enterprise
Console by default. We need to define forwarding rules to IBM Tivoli Business
Systems Manager. As discussed in 4.7.2, “IBM Tivoli Monitoring for Transaction
Performance rules” on page 133, rules are coded to forward events using ihstttec
exit.
A sample NetView event is shown in Figure 4-43 on page 137.
136
Figure 4-43 Detailed NetView event
The NetView event that we want to forward only relates to Server interface
events. These events have a class of TEC_ITS_NODE_STATUS. The mappings
that we perform from the ihstttec exit are:
-b (TBSM class)
NetView;7.1.4
-m (message)
from msg slot
-h (hostname)
parsed from jobName slot
-i
hostname
-d
hostname
-p
from sub-origin slot contain class name
-s (severity)
from severity slot
137
The mapping is performed using the rules shown in Example 4-5.
Example 4-5 NetView interface rule
rule:
forward_netview_event_to_tbsm:
(
event: _event of_class within ['TEC_ITS_NODE_STATUS'],
reception_action:
(
'scripts/netview_tbsm_forward.sh',
'',
[],
'YES')
)
).
rule:
forward_netview_manage_event_to_tbsm:
(
event: _event of_class within ['TEC_ITS_INTERFACE_MANAGE'],
reception_action:
(
'scripts/netview_tbsm_forward.sh',
'',
[],
'YES')
)
).
The NetView forwarding script netview_tbsm_forward.sh is shown in
Example 4-6.
Example 4-6 Sample netview_tbsm_forward.sh
#!/bin/sh
set -x
if [ "$EVENT_CLASS" = "TEC_ITS_INTERFACE_MANAGE" ];
then
$TEC_BIN_DIR/../../TDS/EventService/ihstttec -b "NetView Interface;7.1.4" -i
"$hostname" -p "DISCOVER" -s "HARMLESS" -t "MSG" -q "$origin" -m "DISCOVER"
else
if [ "$ifstatus" = "DOWN" ];
138
then
$TEC_BIN_DIR/../../TDS/EventService/ihstttec -b "NetView Interface;7.1.4"
-i "$hostname" -p "$EVENT_CLASS" -s "$severity" -t "EXCEPTION" -q "$origin" -m
"$msg"
else
$TEC_BIN_DIR/../../TDS/EventService/ihstttec -b "NetView Interface;7.1.4"
-i "$hostname" -p "$EVENT_CLASS" -s "HARMLESS" -t "EXCEPTION" -q "$origin" -m
"$msg"
fi
fi
4.7.4 Assembling a new TEC rule base
There are default tasks that are set up to customize IBM Tivoli Enterprise
Console related to the IBM Tivoli Monitoring, as shown in Table 4-9 on page 133.
However, since this process is quite cumbersome, and some of those tasks
modify the rule base, ignoring other modifications, we found it is better to include
them manually using the following steps.
Tip: The steps here present the command line approach. It is possible to use
the Tivoli Desktop to perform these steps.
1. Define a new rule base; we call it BSM_rb and allocate the directory under
/tivoli/db/rb/BSM_rb:
wrb -createrb BSM_rb -d /tivoli/db/rb/BSM_rb
2. Copy the default rule base into BSM_rb:
wrb -copyrb BSM_rb Default
3. Import new baroc class files into BSM_rb:
wrb -imprbclass <baroc file> BSM_rb
4. Import the new ruleset files into BSM_rb:
wrb -imprbrules <rls file> BSM_rb
5. Activate the rule base target domain for the rules:
wrb -imptgtrule <rls file> BSM_rb
6. Compile the new rule base:
wrb -comprules BSM_rb
7. Load the rule base:
wrb -loadrb BSM_rb
139
8. Restart the Event Server:
wstopesvr
wstartesvr
4.7.5 IBM Tivoli Business Systems Manager customization
This section discusses customization for IBM Tivoli Business Systems Manager
in this sample Business Service Management implementation.
4.7.6 Defining TBSM object types
New objects needs to be defined in IBM Tivoli Business Systems Manager for
collecting events from the IBM Tivoli Enterprise Console. For some of the default
objects, this can be achieved using the standard installation program provided by
IBM Tivoli Monitoring modules.
In our configuration, we need to run the installation programs for the following
modules in the IBM Tivoli Business Systems Manager database server:
򐂰 IBM Tivoli Monitoring for Database: DB2
򐂰 IBM Tivoli Monitoring for Web Infrastructure: Apache Web Server
򐂰 IBM Tivoli Monitoring for Web Infrastructure: WebSphere Application Server
When the installation program for these products has been run, the table
GEM_LookupCID is shown, as in Figure 4-44 on page 141.
140
Figure 4-44 GEM_LookupCID
Additionally, we need to define custom objects that are not implemented from the
IBM Tivoli Monitoring modules. The following objects are not defined by default:
򐂰
򐂰
򐂰
򐂰
Windows Operating System health
UNIX Operating System health
IBM Tivoli Monitoring for Transaction Performance: QOS objects
IBM Tivoli Monitoring for Transaction Performance: STI objects
We define generic objects to represent these objects and place them under the
appropriate network node object.
Here is how we define the additional object types:
1. Define the product structure:
gemgenprod.sh
gemgenprod.sh
gemgenprod.sh
gemgenprod.sh
-S
-S
-S
-S
BSM1
BSM1
BSM1
BSM1
-U
-U
-U
-U
sa
sa
sa
sa
-P
-P
-P
-P
sa
sa
sa
sa
-m
-m
-m
-m
ITSO
ITSO
ITSO
ITSO
-p
-p
-p
-p
WinOS -v 1.0
UNIXOS -v 1.0
TMTP -v 5.1
NetView -v 7.1.4
141
2. Define the icon:
gemimageimport.sh
gemimageimport.sh
gemimageimport.sh
gemimageimport.sh
gemimageimport.sh
gemimageimport.sh
gemimageimport.sh
gemimageimport.sh
-S
-S
-S
-S
-S
-S
-S
-S
BSM1
BSM1
BSM1
BSM1
BSM1
BSM1
BSM1
BSM1
-U
-U
-U
-U
-U
-U
-U
-U
sa
sa
sa
sa
sa
sa
sa
sa
-P
-P
-P
-P
-P
-P
-P
-P
sa
sa
sa
sa
sa
sa
sa
sa
-p
-p
-p
-p
-p
-p
-p
-p
UNIXOS -v 1.0 -l -i UNIXOSl.jpg
UNIXOS -v 1.0 -s -i UNIXOSs.jpg
WinOS -v 1.0 -l -i WinOSl.jpg
WinOS -v 1.0 -s -i WinOSs.jpg
TMTP -v 5.1 -l -i TMTPl.jpg
TMTP -v 5.1 -s -i TMTPs.jpg
NetView -v 7.1.4 -l -i NVl.jpg
TMTPSTI -v 7.1.4 -s -i NVs.jpg
3. Restart the services using the svc_control -s and svc_control -g
commands.
4.7.7 Setting object hierarchy
Initial configuration of the IBM Tivoli Business Systems Manager enterprise
definition for the Agent listener interface is also recommended to get a consistent
result.
GEM_EEhostToEnterprise
Maps the event enablement host name to the
Enterprise object. We map our machine ibmtiv1 to
ITSO enterprise.
GEM_LocationToRegion
The Network Region object name is derived from
the location. The default derivation is to take the
second qualifier of the location name.
GEM_HostnameToLocation The TCP/IP host name is used to obtain the
Network Location parameter. The default location
is derived from the second and third part of the
TCP/IP host name.
The contents of these tables are shown in Figure 4-45 on page 143.
142
Figure 4-45 Name mapping tables
With that structure in place, and our IP domain called itsc.austin.ibm.com®, the
final structure of the object will be: ITSO enterprise -> austin -> itsc.austin as
Figure 4-46 IBM Tivoli Business Systems Manager hierarchy
143
4.7.8 Defining business systems
Tip: Although we showed our approach using a step-by-step definition and
opening up all event flows at once, most of the time it is much better to let the
event flow gradually and just build from there. Once all the definitions are in
place, you can stop the event flow and delete all object instances in the IBM
Tivoli Business Systems Manager database, then start the discovery process
again. Since we used only the IBM Tivoli Enterprise Console interface, this
approach is possible. If you are also using a Common Listener interface, you
need to synchronize the status with the discovery status in the Common
Listener. Also note that the IBM Tivoli Monitoring module stores discovery
states in a file; this file needs to be adjusted.
We create the business system definition using the Automated Business System
function of IBM Tivoli Business Systems Manager. The ABS processing
schematic is shown in Figure 4-47.
Config file
absConfig.ksh
alobListPattern
alobListCriteriaAlob
dynamic_object_create_path_detail
dynamic_object_create_path
Update ObjPathCache
ABS Discovery Process
ABS Creation Process
evQueueObject
alobQueueCreateLOB
ev_auto_create_object_parm
ObjPathCache
Object creation or update triggers
tI_EV<cid>_C
tU_EV<cid>_C
tU_EV<cid>_A
ABS Table Purge
Figure 4-47 ABS processing
1. A trigger captures the modification, and the new or changed attribute data is
queued in the table evQueueObject.
2. The UpdateObjPathCache job runs as scheduled (15 minutes by default) and
updates the resource relationships in the table ObjPathCache.
3. The ABS Discovery Process job, scheduled every minute, checks the
evQueueObject table and, if the criteria provided in the last configuration file
have been met, populates the tables alobQueueCreateLob and
ev_auto_create_object_param with the new data. This job processes only the
144
events with a ctime lower than or equal to the start time of the last successful
completion of the UpdatePathCache job. Events created after this time will be
queued until the next successful running of the UpdateObjPathCache job.
4. The ABS Creation Process job, scheduled every minute, processes the data
stored in the tables populated by the ABS Discovery Process job and creates
or updates the BSV.
5. The ABS Table Purge job, scheduled to run occasionally, removes data older
than 30 days from the tables used by the automated BSV processing system.
The configuration file for this Automated Business System is shown in
Example 4-7.
Example 4-7 Automated Business System configuration
PatternList
ListName
Operand
Pattern
Pattern
1
2
3
4
5
6
7
8
9
10
11
12
13
Class
G02U
G029
G02G
G02W
WNPC
G02G
G02G
G02W
NODE
G02U
G029
G02D
G02G
Attribute
TCPHost
TCPHost
name
TCPHost
name
name
name
name
name
name
name
name
name
CriteriaToPattern
Criteria Pattern
1001
1
1002
2
1003
3
1004
4
1005
5
1006
6
1007
7
1008
8
1009
9
1010
10
1011
11
1012
12
1013
13
When
Current
Current
Current
Current
Current
Current
Current
Current
Current
Current
Current
Current
Current
Operator
LIKE
LIKE
LIKE
LIKE
LIKE
LIKE
LIKE
LIKE
LIKE
LIKE
LIKE
LIKE
LIKE
Operand1 Operand2
%
BSM%
TRADE3%
BSM%
BSM%
TEC%
ITM%
%
%
%
%
%
%
PatternRelated
1
2
3
4
5
6
7
8
9
10
11
12
13
145
Path
Path
PP_0_0
PP_0_1
PP_0_2
PP_0_3
PP_0_4
PP_0_5
PP_0_6
PP_0_0
PP_0_1
PP_0_2
PP_0_3
PP_0_4
PP_0_0
PP_0_1
PP_0_2
PP_0_3
PP_0_4
PP_0_3
PP_0_4
PP_0_5
PP_0_5
PP_0_6
PP_0_6
PP_1_0
PP_1_1
PP_1_2
PP_1_3
PP_1_4
PP_1_5
PP_1_0
PP_1_0
PP_1_1
PP_1_1
PP_1_2
PP_1_3
PP_1_2
PP_1_3
PP_1_4
PP_1_5
PP_1_4
PP_1_5
Level
1
1
1
1
1
1
1
2
2
2
2
2
3
3
3
3
3
4
4
2
3
2
3
1
1
1
1
1
1
2
3
2
3
2
2
3
3
2
2
3
3
CriteriaToPath
Criteria Path
1001
PP_0_0
1002
PP_0_1
146
Name
All systems
All systems
All systems
All systems
All systems
All systems
All systems
Web Store
Web Store
Web Store
Web Store
Web Store
Servers
Servers
Finance
Supplier
IT Resources
IT Resources
IT Resources
IT Resources
IT Resources
IT Resources
Networking
Servers
Web resources
Web resources
Databases
Databases
Level
3
3
Pattern
1
2
Variable Value
name
<1:name>
name
<2:name>
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
PP_0_2
PP_0_3
PP_0_4
PP_0_5
PP_0_6
PP_1_0
PP_1_1
PP_1_2
PP_1_3
PP_1_4
PP_1_5
3
4
4
3
3
3
3
3
3
3
3
3
4
5
6
7
8
9
10
11
12
13
name
name
name
name
name
name
name
name
name
name
name
<3:name>
<4:name>
<5:name>
<6:name>
<7:name>
<8:name>
<9:name>
<10:name>
<11:name>
<12:name>
<13:name>
The configuration file can be defined manually or using the Java tool as discssed
in the redbook Tivoli Business Systems Manager V2.1 End-to-end Business
Impact Management, SG24-6610. The tool can be downloaded from:
ftp://www.redbooks.ibm.com/redbooks/sg246610/ABSjava.zip
We load the Automated Business System configuration using the following
procedure:
1. Load the Automated Business System definition using the command:
sh absconfig.ksh -SBSM1 -Usa -Psa -iBSMBSV.txt
2. Activate the SQL Server Agent jobs from the Enterprise Manager for the
following jobs:
– UpdateObjPathCache
– ABS Discovery Process
– ABS Creation Process
3. As an IBM Tivoli Business Systems Manager Super Administrator, open the
Business System View and close all other views except All Business
Systems. Select Console -> Save Workspace to save the workspace.
4.7.9 Defining TBSM operators
IBM Tivoli Business Systems Manager operators are defined using Windows
user definitions from the IBM Tivoli Business Systems Manager Console Server.
The user definition is then connected to an IBM Tivoli Business Systems
Manager specific Windows group to get the appropriate roles.
We define operators by using the following steps:
1. From the My Computer icon, right-click and select Manage; alternatively, you
can click Administrative Tools -> Computer Management.
147
2. In the Computer Management Window, select Local User and Group ->
Users in the tree view, then select Action -> New User; this is shown in
Figure 4-48.
Figure 4-48 Defining a new user
3. Specify the new user’s attributes as shown in Figure 4-49.
Figure 4-49 Defining a user
148
4. Click Create; the user will be created. You are still in the New User dialog and
can create another user.
5. When you are done creating users, go to the Groups folder. Select the IBM
Tivoli Business Systems Manager groups (TBSM_Operators) , right-click
and select Properties as shown in Figure 4-50.
Figure 4-50 Group list
6. The group property dialog is shown in Figure 4-51 on page 150. Click Add
and specif y the users that should be in the group.
149
Figure 4-51 Group property dialog
7. Associating Business System View with operators is done by authorizing the
operator to use a Workspace. As a IBM Tivoli Business Systems Manager
super administrator, open the Console. Click Console -> Open Workspace
and you will be presented with the workspace list as shown next.
Figure 4-52 Open workspace list
8. Click Edit and the list of available users with the role of operator or restricted
operator will be shown, as in Figure 4-53 on page 151.
150
Figure 4-53 Selecting users for the workspace
4.8 Configuring Tivoli Data Warehouse
Data needs to be collected into the Tivoli Data Warehouse. This data is extracted
from the source databases, which are product-specific databases from each of
the products.
The data collection that we perform is shown in Figure 4-54.
ITM_DB
AM
GW W,
A, AMX
IZ , A
Y,
CT MY
D
DYK_CAT
GTM
Objects
DYK
TWH_CDW
M
BW
DYK_DM
WSC_DB
Figure 4-54 Data collection
151
As shown In Figure 4-54 on page 151, the collection is performed from our data
sources:
򐂰 ITM_DB: historical database from IBM Tivoli Monitoring; since this database
contains all IBM Tivoli Monitoring data, information from IBM Tivoli Monitoring
for Database and IBM Tivoli Monitoring for Web Infrastructure products are
also stored here.
򐂰 Objects: IBM Tivoli Business Systems Manager objects database in Microsoft
SQL Server contains data about Business System Views states.
򐂰 WSC_DB: Web Services Courier contains response time information from the
Web-based transaction.
The data collection is performed using the Extract-Transform-Load (ETL)
programs supplied with each product. These ETLs are indicated using
three-letters AVA codes as shown in Figure 4-54 on page 151. These AVA codes
represent the products, like so:
AMX
IBM Tivoli Monitoring based components
AMY
IBM Tivoli Monitoring for Operating Systems
IZY
IBM Tivoli Monitoring for Web Infrastructure: WebSphere Application
Server
GWA
IBM Tivoli Monitoring for Web Infrastucture: Apache HTTP Server
CTD
IBM Tivoli Monitoring for Databases: DB2
GTM
IBM Tivoli Business Systems Manager
BWM
IBM Tivoli Monitoring for Transaction Performance: Web
Performance
DYK
4.8.1 Collecting information from IBM Tivoli Monitoring
IBM Tivoli Monitoring data collection needs to have the data collection feature
installed in the Tivoli Framework. The data collection collects data in the
historical database, typically called ITM_DB, using a set of RIM objects. A RIM
object is a Tivoli Management Framework resource used to communicate with a
relational database. The IBM Tivoli Monitoring data is collected from the Tivoli
Management Framework gateway. The gateway collects historical information
from the endpoints and stores them locally. Every midnight, it loads the historical
data into the ITM_DB using a RIM object called itm_rim_<nodename>. For
example, our gateway ibmtiv1 collects data using RIM itm_rim_ibmtiv1.
For IBM Tivoli Monitoring, we need to enable the data collection feature to start
collecting historical data. This is achieved using the following procedure:
152
1. Define the database schema using the files under
$BINDIR/TME/Tmw2k/TDS/rdbcfg; the files are:
cr_db
cr_tbl
twh_enabl_update
Creating the database
Creating the schema
Enabling update for warehouse database
2. Define the RIM object using the wcrtrim command. For our DB2 UDB in the
AIX environment, we run the following command:
wcrtrim -v DB2 -h ibmtiv1 -d ITM_DB -u db2inst1 -H /usr/lpp/db2_07_01 -I
/home/db2inst1 itm_rim_ibmtiv1
3. Define data collection parameters using the wdmconfig command:
wdmconfig -m ibmtiv1 -D datacollector.db_purge_interval = 40
-D datacollector.rim_name = itm_rim_ibmtiv1
-D datacollector.delay = 1
-D datacollector.sleep_time = 1
The configuration is stored in the file $DBDIR/dmml/.config.
4. Initiate data collection using the wdmcollect command; to initiate collection
from endpoint BSM2 every two hours, use the command:
wdmcollect -e BSM2 -s 2
You can see the XML file result under
$DBDIR/dmml/tedw/datacollector.status.
4.8.2 Collecting information from Web Services Courier
Data collected by the IBM Tivoli Monitoring for Transaction Performance can be
collected into the historical database hosted by the Web Services Courier. The
collection set up is performed using the Web browser interface. Use the following
procedure:
1. Use a Web browser and log on to the IBM Tivoli Monitoring for Transaction
Performance’s Internet Management Server. Supply the appropriate user ID
and password; click Logon.
2. From the portfolio menu, select Historical Data Collection -> Configure
Data collection.
3. Set the time that the data collection job will run and load the relational
database into the Web Services Courier, then click Save. See Figure 4-55 on
page 154.
153
Figure 4-55 Configure Data collection for Internet Management function
4.8.3 Enabling ETL in Tivoli Data Warehouse
The ETL programs are installed using the Tivoli Data Warehouse installation
programs. ETL programs and processes are managed using the IBM DB2 Data
Warehouse Center. Data Warehouse Center is launched from the DB2 control
center.
You start the DB2 control center using the command db2cc. From the DB2
control center, select Tools -> Data Warehouse Center.
The following steps need to be followed after the ETLs have been installed.
1. Setting up ODBC connection to data sources
– For the DB2 database, use the DB2 Client Configuration Assistant. Issue
the command db2cca to start it. Click the Add button to start the Add
database wizard. Our DB2 Client Configuration Assistant window is shown
154
Figure 4-56 DB2 Client Configuration Assistant
– For the IBM Tivoli Business Systems Manager Objects database in
Microsoft SQL Server, use the ODBC Connection Manager applet under
Administrative Tools -> Data Sources (ODBC). The ODBC applet is
Figure 4-57 ODBC System DSN list
2. Start DB2 Control Center using the command db2cc. From the DB2 control
center, select Tools -> Data Warehouse Center as shown in Figure 4-58 on
page 156.
155
Figure 4-58 DB2 Control Center to invoke Data Warehouse Center
3. Enter your DB2 administrator user ID and password. Select the Advanced
button and ensure that the control database name is TWH_MD instead of
DWCTRLDB. Click OK and then OK again. This is shown in Figure 4-59.
Figure 4-59 Login to Data Warehouse Center
4. From the Data Warehouse Center, expand the Warehouse Sources and
Warehouse Targets folders and update all the database definitions.
Right-click each definition and select Properties as shown in Figure 4-60 on
page 157.
156
Figure 4-60 Opening database property
5. Change the database property pages for all the database sources and targets
under the folders Warehouse Source and Warehouse Target. Enter the
appropriate user ID for the databases. A sample property page for a source
database is shown in Figure 4-61.
Figure 4-61 Data source properties
157
6. Now expand the Subject Areas folder. It will show the ETL processes. Expand
the processes until you reach the specific steps. Right-click and select
Schedule as shown in Figure 4-62.
Figure 4-62 Defining schedule
7. Put in the daily schedule with a specific start time. The overview schedule is
shown in Figure 4-8 on page 98. Since it is based also on the time estimate in
Figure 4-7 on page 98, we will use the schedule in Table 4-10. The table only
contains processes necessary for IBM Tivoli Service Level Advisor.
Table 4-10 Time schedule for collection process
Process name
Start time
AMX_c05_ETL1_Process
00:20
BWM_c10_Load_Warehouse_Process
23:40
DYK_m05_Populate_Registration_Datamart_Process
01:00
DYK_m10_Populate_Measurement_Datamart_Process
01:30
GTM_c05_LOBState_Process
23:00
The schedule definition dialog is shown in Figure 4-63 on page 159.
158
Figure 4-63 Schedule definition dialog
8. Back in the ETL processes, now we can promote the mode of processing to
Production. Setting the mode to Production means that all the changes are
final and the ETL will be processed by schedule. The promote menu is shown
159
Figure 4-64 Promoting ETL process
4.9 Customizing IBM Tivoli Service Level Advisor
This section discusses customization for IBM Tivoli Service Level Advisor in our
Business Service Management implementation.
4.9.1 Defining the operation
Administrative functions for IBM Tivoli Service Level Advisor are performed
through the IBM Console. The IBM Console interface is typically installed in the
SLA Server. Point your Web browser to the IBM Tivoli Service Level Advisor
server; we use port 9008 with the URL http://bsm6:9008/IBMConsole as shown
160
Figure 4-65 Login to IBM Console
The main window of IBM Tivoli Service Level Advisor is shown in Figure 4-66.
Figure 4-66 Main window of IBM Tivoli Service Level Advisor
161
The menu items (or portfolio) in Figure 4-66 on page 161 include the following
functions:
򐂰 User and roles administration
򐂰 IBM Console
򐂰 Work with report
򐂰 Administer Service offering
򐂰 Administer customer
򐂰 Administer SLM
The following users need to be defined:
򐂰 Service Level Manager
򐂰 Business process owners or Business process managers
򐂰 IT manager(s)
򐂰 Chief Information Officer
162
Abbreviations and acronyms
ABS
Automated Business Systems
TDS
Topology Display Services
AIX
Advanced Interactive
Executive
TDW
TEC
BSV
TEDW
CDW
Central Data Warehouse
Tivoli Enterprise Data
Warehouse
CIO
Chief Information Officer
TMR
Tivoli Management Region
CPU
Central Processing Unit
TMTP
DB2
Database 2™
Transaction Performance
EJB
Enterprise Java Bean
TSLA
ETL
Extract Transform Load
IBM Tivoli Service Level
Advisor
HTTP
Hypertext Transfer Protocol
UDB
Universal Database
IBM
International Business
Machines Corp.
URI
Universal Resource Identifier
URL
Universal Resource Locator
ITSO
International Technical
Support Organization
JVM
Java Virtual Machine
LOB
Line of Business
ODBC
Open Database Connectivity
OLAP
Online Analytical Processing
QOS
Quality of Service
RDBMS
Relational Database
Management Systems
RIM
RDBMS Interface Module
SLA
Service Level Agreement
SLM
Service Level Management
SNMP
Simple Network Management
Protocol
SQL
Structured Query Language
STI
Synthetic Transaction
Investigator
TBSM
IBM Tivoli Business Systems
Manager
TCP/IP
Transmission Control Protocol
Internet Protocol
163
164
Related publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this redbook.
IBM Redbooks
For information on ordering these publications, see “How to get IBM Redbooks”
on page 166. Note that some of the documents referenced here may be available
in softcopy only.
򐂰 IBM Tivoli Monitoring Version 5.1: Advanced Resource Monitoring,
SG24-5519
򐂰 IBM Tivoli Monitoring for Databases Database Management Made Simple,
SG24-6613
򐂰 IBM Tivoli Monitoring for Business Integration, SG24-6625
򐂰 Introducing IBM Tivoli Monitoring for Web Infrastructure, SG24-6618
򐂰 Unveil Your e-business Transaction Performance with IBM TMTP 5.1,
SG24-6912-00
򐂰 Tivoli NetView 6.01 and Friends, SG24-6019
򐂰 Early Experiences with Tivoli Enterprise Console 3.7, SG24-6015
򐂰 Tivoli Business Systems Manager V2.1 End-to-end Business Impact
Management, SG24-6610
򐂰 Introducing IBM Tivoli Service Level Advisor, SG24-6611
򐂰 Introduction to Tivoli Enterprise Data Warehouse, SG24-6607
򐂰 Planning a Tivoli Enterprise Data Warehouse Project, SG24-6608-00
Other publications
These publications are also relevant as further information sources:
򐂰 Release notes:
– Tivoli Management Framework Release Notes v4.1, GI11-0890-00
– IBM Tivoli Monitoring Release Notes v5.1.1, GI10-5797-02
– IBM Tivoli Enterprise Console Release Notes v3.8, GI11-0777-02
165
– IBM Tivoli NetView 7.1.3 for UNIX Release Notes, GI11-0927-02
– IBM Tivoli Workload Scheduler Release Notes v8.2.0, SC23-1277-00
– IBM Tivoli Business Systems Manager Release Notes v2.1.1,
SC23-4841-01
– Tivoli Enterprise Data Warehouse Release Notes v1.1, GI11-0857-00
– Release Notes for IBM Tivoli Service Level Advisor v1.2.1, SC09-7777-02
򐂰 Installation guides:
– Tivoli Management Framework Enterprise Installation Guide v4.1,
GC32-0804-00
– IBM Tivoli Enterprise Console Installation Guide v3.8, GC32-0823-00
– IBM Tivoli Monitoring Road Map Typical Installation v5.1, GI11-0938-00
– IBM Tivoli Monitoring for Databases Installation and Setup Guide v5.1.1,
SC23-4854-00
– IBM Tivoli Business Systems Manager Installation and Configuration v2.1,
GC32-0800-00
– Tivoli Enterprise Data Warehouse Installing and Configuring v1.1,
GC32-0744-00
– Administrator's Guide for IBM Tivoli Service Level Advisor v1.2.1,
SC32-1250-00
How to get IBM Redbooks
You can search for, view, or download Redbooks, Redpapers, Hints and Tips,
draft publications and Additional materials, as well as order hardcopy Redbooks
or CD-ROMs, at this Web site:
ibm.com/redbooks
Help from IBM
IBM Support and downloads
ibm.com/support
IBM Global Services
ibm.com/services
166
Index
A
ABS 74
ABS Creation Process job 145
ABS Discovery Process job 144
ABS Table Purge job 145
absconfig.ksh 147
access.log 73
AIX 35
AMX 152
AMY 152
Apache 108
applications 50
automated business system 74
automation 5
Automation Blueprint
mapping 18
automation blueprint 4
availability 6
B
baroc files 132
base services 21
book organization 10
BSV 74
BSV structure
grouped resources 77
inverted hierarchy 77
no hierarchy 77
original hierarchy 77
Business Driven organization 2
business intelligence reporting 33
business process decomposition 48
business processes 50
business schedule 85
Business Service Management 8
concepts 12
deployment option 16
design 61
implementation consideration 15
information collection 47
planning overview 44
business system 75
Business System View 24
Business System View design 74
Business System View structure 95
BWM 152
C
CDW
See central data warehouse
commands
gemgenprod 141
gemimageimport 141
nvwcinstal 118
svc_control 142
wcrtrim 153
wdmcollect 153
wdmconfig 153
wrb 139
wstartesvr 140
wstopesvr 140
Common Warehouse Metadata 30
component 84
component relationship 53
Console server 23
Control server 33
correlation 30
Crystal Decisions 30
CTD 152
current monitoring environment 56
customer 83
D
data collection design 80, 96
Data mart 33
data mining 33
data warehouse sizing 81
database monitoring 110
Database server 22
DB2 Administration Client 35
DB2 Application Development Client 35
DB2 database 35
DB2 Enterprise Edition 35
decomposition 48
deployment option 16
discussion scope 9
167
Distributed resource feeds 22
DM object 27
download page 117
DYK 152
E
end-to-end view 30
environment 88
ETL 152
ETL programs 32, 80
ETL run schedule 98
Event Handler server 23
Event propagation 26
evolution 2
Extract 32
Extract, Transform and Load
See ETL
Extract-Transform-Load 152
L
F
forwarding 116
G
gemgenprod 141
gemimageimport 141
Generic object types 28
Graphical report 29
GTM 152
GWA 152
H
hardware configuration 63
Health Monitor Server 23
historical data 30
History server 22
Host Integration server 23
hostname 30
I
IBM Tivoli Business Systems Manager 20
Base Services 21
components 23
consideration 67
object types 27
overview 20
servers 22
IBM Tivoli Monitoring for Transaction Performance
168
121
IBM Tivoli Service Level Advisor 36
components 38
data repositories 40
databases 40
flow 37
overview 36
ihstttec 28
ihstztec 27
Indication window 105
informal SLA 54
information collection 47
information provider 45
integration 5
interview roles 45
IP address 30
IT organization 2
IZY 152
lines of business 14
Load 32
LOB 14
logging option 106
M
Mainframe resources feeds 22
Managed Node 116
measurement 84
metadata interchange 30
metric 84
monitoring implementation 93
monitoring scheme 68
monitoring solution consideration 58
monitoring standard 68
N
NetView commands
nvsetup 112
ovaddobj 112
NetView console 113
non-Tivoli applications 31
nvsetup 112–113
nvwcinstal.exe 118
O
Object discovery 26
Object Management Group 30
object type granularity 73
object type selection 69
offering 84
offering component 84
OLAP
analysis 33
OLAP tools 29
on demand environment 4
open interface 30
optimization 6
order 85
ovaddobj 112
P
parameter setting 106
period 85
personnel roles 45
product mapping 18
Profile Manager 93, 101
Profiles 93
profiles 93
Propagation server 23
provisioning 6
Q
Quality of Service 121
quantifiable objective 13
R
raw data 30
Realm 83
real-world implementation 92
recorder 126
Redbooks Web site 166
Contact us xi
relationship 53
reliance 6
Resource Model 104
RI
See Report Interface
roles 114
rule base 132
rulesets 132
S
scalable architecture 31
schedule 85, 98
Service Level Agreement 54
Service Level Management 13, 41
life cycle 41
Service Level monitoring 98
Service Level objective 13, 54
Service Management 7
Site Investigator 73
sizing 81
sizing information 97
SmartSets 117
Solaris 35
solution design 61
standard RDBMS technology 31
STI recorder 126
svc_control 142
Synthetic Transaction Investigator 121
T
Tabular report 29
TBSM commands
absconfig 147
TBSM tables
GEM_EEHostToEnterprise 142
GEM_HostnameToLocation 142
GEM_LocationToRegion 142
TEC forwarding 116
Tivoli Data Warehouse 28
benefit 30
components 31
overview 28
Tivoli Enterprise Data Warehouse
data mart 33
ETL processes 33
ETL programs 32
source applications 32
warehouse packs 32
Tivoli Management Framework
consideration 66
TMW_Clearing 93
Tmw2k profiles 93
top-down deployment 16
Transform 32
Types of ETLs
Central Data Warehouse 32
data mart 32
sample environment 88
Index
169
U
UNIX Server 112
UpdateObjPathCache 144
V
virtualization 5
W
warehouse pack 32
wcrtrim 153
wdmcollect 153
wdmconfig 153
Web Console application server 23
Web Console Security 113
Web Server monitoring 108
WebSphere Application Server 109
Windows 2000 35
Windows NT 35
Windows Server 111
wrb 139
wstartesvr 140
wstopesvr 140
170
(0.2”spine)
0.17”<->0.473”
90<->249 pages
Back cover
®
Business Service
Management Best
Practices
All you need to
understand Business
Service Management
Business process
mapping to
monitoring and
service level
Integration of IBM
TBSM and IBM TSLA
This IBM Redbook discusses Business Service Management best
practices. Business Service Management is a key component of
IBM’s on demand Automation Blueprint. It is the top layer of the
system management discipline which enables IT management to
be related to the business.
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
The ultimate goal of the IT infrastructure is to leverage its value to
support the business. The IT infrastructure management should
then be aimed at minimizing disruption to business processes and
functions. This goal is realized with the Business Service
Management (formerly also called Business Impact
Management).
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
Using Business Service Management, IT resources management
is aligned with the business processes and functions:
- Establishing a Service Level Agreement with IT users
- Understanding how IT resources impact business processes
- Ensuring IT resources fulfill the Service Level Agreement and
minimizing disruption to business functions
This redbook describes the relevant concepts, as well as planning
for and implementing Business Service Management. The
implementation is described using a sample business function of
an e-business solution.
IBM Redbooks are developed by
the IBM International Technical
Support Organization. Experts
from IBM, Customers and
Partners from around the world
create timely technical
information based on realistic
scenarios. Specific
recommendations are provided
to help you implement IT
solutions more effectively in
your environment.
For more information:
ibm.com/redbooks
SG24-7053-00
ISBN 0738497975

Business Service Management Best anagement Best Practices

Transcription

Similar documents

Registration of payment

Hardware Support

Information Technology Lifecycle Management

Tivoli Theatre - Tivoli Stage Crew

A3RMT - IBM Joint Brochure - A3 Remote Monitoring Technologies

Ponani Gopalakrishnan. Ponani Gopalakrishnan.

pdf

the Tivoli Networks Global Radio brochure