• No results found

Chapter 4. Business Service Management sample implementation

4.3 Implementation overview

4

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.

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.

IBM HTTP Server WebSphere Apps Server

DB2 database

IBM HTTP Server WebSphere Apps Server

BSM2

BSM7

IBMTIV2

Figure 4-2 Business process decomposition

The Service Level Agreement for the Web Commerce business process is described in Table 4-1 on page 90.

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.

Business Process:

Web Commerce

Application:

Web Store

WebServer

Application Server

Database

Application:

Customer Service

WebServer

Application Server

Database BSM2 - IBM HTTP Server

BSM7 - IBM HTTP Server

BSM2 - WebSphere BSM7 - WebSphere

IBMTIV2 - DB2 - ITSOBAN1

BSM2 - IBM HTTP Server BSM7 - IBM HTTP Server

BSM2 - WebSphere BSM7 - WebSphere

IBMTIV2 - DB2 - ITSOCS

Table 4-1 Service level objective for Web Commerce business process

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

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

Constraint: Hit rate for less than 10 hit per seconds 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

Constraint: Hit rate for less than 10 hit per seconds

򐂰 4.2.5, “Business System View design” on page 95 discusses the translation of the business process decomposition into impact monitoring using the Business System View

򐂰 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

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

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 Tivoli Framework 4.1

IBM Tivoli Monitoring 5.1.1 IBM Tivoli Enterprise Console 3.8

Tivoli Management Agent Web Services Courier TBSM Event Enablement

IBM HTTP Server WebSphere Apps Server TMA + ITM Web Infrastructure

DB2 database TMA + ITM Databases

IBM Tivoli Service Level Advisor 1.2

IBM Tivoli Business Systems Manager

BSM1

IBM HTTP Server WebSphere Apps Server TMA + ITM Web Infrastructure

IBM Tivoli Data Warehouse 1.1.1

BSM3

Tivoli Internet Management Server BSM9

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

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.

ITM_PM

Apache_PM WAS_PM DB2_PM WinSrv_PM UNIXSrv_PM

ITM_Apache_Pr ITM_WAS_Pr ITM_DB2_Pr ITM_Win_Pr ITM_UNIX_Pr

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.

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

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.

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

User Role BSV

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.

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.

Figure 4-8 Collection schedule

4.2.7 Service Level monitoring

2:00

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.

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 Tivoli Management Framework 4.1 IBM Tivoli Monitoring 5.1.1

IBM Tivoli Monitoring Component Services 5.1 IBM Tivoli Monitoring for *

DB2 Universal Database Version 7.1 IBM Tivoli Enterprise Console 3.8

IBM Tivoli Business Systems Manager distributed edition 2.1.1

IBM Tivoli Monitoring for Transaction Performance:

Web Service Courier endpoint IBMTIV5 Windows 2000 Server Tivoli Management Framework 4.1

IBM Tivoli NetView 7.1.3 BSM9

TIMS

Windows 2000 Server IBM Tivoli Monitoring for Transaction Performance 5.2:

Internet Management Server BSM4, BSM8

QoS endpoint

Windows IBM Tivoli Monitoring for Transaction Performance 5.2:

QoS Endpoint

STI endpoints Windows IBM Tivoli Monitoring for Transaction Performance 5.2:

STI endpoint

Windows 2000 Resource Kit Windows Support Tools MKS Toolkit V8

Microsoft SQL Server 2000 IBM TBSM Base Services BSM3

TBSM console and propagation server

Windows 2000 Advanced Server

Windows 2000 Resource Kit Windows Support Tools MKS Toolkit V8

IBM TBSM Base Services BSM5

TDW database server

TDW Control Server

Windows 2000 Server DB2 Universal Database Server V7.1 FixPack 5 IBM Console Presentation Services

Tivoli Data Warehouse enablement packs

Related documents