TBSM 4.2 review report template - IBM

bossprettyingΔιαχείριση Δεδομένων

28 Νοε 2012 (πριν από 4 χρόνια και 8 μήνες)

276 εμφανίσεις




IBM TBSM 4.2 migration plan review report

For
AAA
-
company
,
City
,
Country





Revision History:

1.

First version
by
Joe Doe











Date


03.05
.2009

Authors

Joe Doe

(IBM)



TBSM 4.2 @ AAA
-
company
-

Review report

IBM



1




Content

The paragraphs in this document contain the information on current TBSM 4
.2 i
m-
plementation at
AAA
-
company
, as reviewed by IBM and
AAA
-
company
during
01
-
02

May 2009 workshop. It has been the intent of the workshop to review
AAA
-
company

TBSM 4.2 test architecture, BSM model and performance issues in order to assess
and report
AAA
-
company

readiness to move into production TBSM 4.2 deplo
y
ment.


TBSM @
AAA
-
company

aspects:


1.

Architecture

2.

Business services model

3.

Reporting solutions study

4.

Performance issues

5.

Enhancements


Participants to the
1
-
2

May 2009 TBSM workshop @
AAA
-
company
,
City
:



John Smith

AAA
-
company



Mary Simpson

AAA
-
company




Joe Doe





IBM

TBSM 4.2 @ AAA
-
company
-

Review report

IBM



2




1.

Architecture

First subject of review workshop was to confirm that target production TBSM architecture will fulfill
hardware and system requirements for TBSM 4.2 in environment of
AAA
-
compan
y

size, and also that
it will be meeting
AAA
-
company

requirements for high availability and load balancing.


AAA
-
company

will install production TBSM 4.2 in the following deployment model:


Picture
1
. Planned TBSM 4.2 in product
ion architecture



This chapter consists of following points:

1.

Deployment model components

2.

Hardware and system resources

3.

Performance predictions

4.

High availability discussion



TBSM 4.2 @ AAA
-
company
-

Review report

IBM



3




Deployment model components

Production TBSM 4.2 deployment model components are:


2 OMNIbus ObjectServers acting as one virtual ObjectServer


2 TBSM Data servers working in a failover pair


3 independent TBSM Dashboard servers2


ITMAgents for TBSM 4.2, each working with one TBSM Data server


IBM recommends use of 2 ITMAgents for OMNIbus 7.
2, each working with one OMNIbus
ObjectServer


1 EIF probe, listening for events from 3rd party event sources and forwarding to virtual O
b-
jectServer.


IBM recommends use of another EIF probe, running on Srv2 machine, in peer2peer failover
pair with EIF probe

on Srv3.


1 Bidirectional gateway, synchronizing both ObjectServers in virtual pair.


IBM
suggests
assuring high availability between event sources and OMNIbus virtual pair. It
includes use of Uni
-
GW in failover as well as external ObjectServers (Srv5 and

Srv6)


Production TBSM 4.2 architecture includes only components mentioned above. They are
components within blue
-
dotted area on Picture 1, called
TBSM deployment model
.

Other components presented on Picture 1 are components interfacing with TBSM 4.2 only

and are
not a subject of this review.


Hardware and software resources

AAA
-
company

will perfo
r
m production TBSM 4.2 deployment on physical servers with following (or
higher) technical parameters:





TBSM 4.2 @ AAA
-
company
-

Review report

IBM



4



Table
1
. Hardware and software

resources for TBSM 4.2 in production

Server

Specification

Srv1

8 GB RAM, 2x DualCore 2.8GHz, RHEL 5

Srv2

8 GB RAM, 2x QuadCore 3.2, RHEL 5

Srv3

8 GB RAM, 2x QuadCore 3.2, RHEL 5

End users workstations

2 GB RAM, 1x SingleCore 2.4GHz, Windows
XP Pro+MSI
E 7.0

or Mozilla Firefox 3.0
+Sun
JRE 1.6


Servers Srv1 and Srv2 will be
dedicated

for TBSM 4.2 production implementation. No other
software will reside on the same servers in the same time.



Resour
c
es performance

A series of tests were performed on
AAA
-
company

test environment in order to find the best setup,
in terms of memory utilization and performance tuning. Test environment configuration and TBSM
setup were similar to those expected on TBSM production environment, except that test enviro
n-
ment r
e
sou
rces are equip
p
ed with lower amount of memory and CPU cores. Besides that fact, all the
other parameters like deployment model and components location in test are reflecting planned
TBSM production architecture.


Test environment specification is listed in

table 2 below:


Table
2
.
AAA
-
company

test environment

Server

Specification

Components

Srv1

4 GB RAM, 1x DualCore
2.2GHz, RHEL 5

TBSM Dashboard server, cohosting production
Webtop 2.1

Srv2

16 GB RAM, 1x
QuadCore 3.2, RHEL 5

Pri
mary TBSM Dataserver + Dashboard server

Srv3

16 GB RAM, 1x
QuadCore 3.2, RHEL 5

Backup TBSM Dataserver + Dashboard server



TBSM 4.2 @ AAA
-
company
-

Review report

IBM



5



Two tests were performed: TBSM dashboard server on Srv1 (1) and TBSM Data server on Srv2 (2).
Tests were perform to find optimal ja
va heap size values to run TBSM servers with, in order to opt
i-
m
ize memory utilization and application performance. Test (1) was performed by increasing number
of user sessions. Test (2) was performed by increasing number of service templates, instances and

i
n
coming events.

In result of testing, the following parameters were indicated as optimal and sufficient to run produ
c-
tion TBSM with in
AAA
-
company
.


Table
3
. Test results on recommended java heaps size values on TBSM servers

Ser
ver

Java heap size

(Ms


mx)

Test range

TBSM Dashboard server

512 MB
-

2048 MB

5
-

15 concurrent user sessions

TBSM Dataserver

512 MB
-

1024 MB

7’738


10’480 instances

30


31 templates, 60
-
62 rules

4’500


9’285 events


Based on above test results
AAA
-
company

will configure and run their production TBSM enviro
n-
ment.

Because of linear tendency to raise memory utilization on TBSM Dataserver while adding new service
template, which is because of specific business service model described in next chapter,
A
AA
-
company
will monitor TBSM DataServer java heap size usage and adjust heaps size values to cover
new TBSM Dataserver requirements for memory.

Because of linear tendency to raise memory utilization on TBSM Dashboard server while new se
s-
sions are being cre
ated for new users connecting to TBSM,
AAA
-
company

will monitor TBSM Das
h-
board server java heap size usage and adjust heaps size values to cover new TBSM Dashboard server
r
e
quirements for memory.


No tests were performed against java heaps size values on e
nd users workstations. IBM provides fo
l-
lowing recommendation for
AAA
-
company

end users workstations setup, based on
AAA
-
company

end users workstations parameters and overall experience:



TBSM 4.2 @ AAA
-
company
-

Review report

IBM



6



Table
4
. Recommendations for java heaps siz
e values for TBSM console on end user wor
k-
st
a
tions

Machine

Java heap size

(Ms


mx)

Use range

End user workstation

128 MB
-

256 MB

1


100 service instances display


Because of clients workstations parameters (Table 1) and linear tendency between number
of service
instances display and java heaps size values for Java plugins,
AAA
-
company

will monitor end users
workstations java heaps size usage and adjust heaps size values to cover new Java plug
-
in requir
e-
ments for memory.


No tests were performed against

TBSM PostgreSQL database setup. IBM and
AAA
-
company

pe
r-
formed Postgres database tuning, based on performance tuning recommendations for TBSM 4.2 and
no further tuning of TBSM PostgreSQL database is required. Because of periodical import of new se
r-
vice tem
plates and instances package,
AAA
-
company

will perform operation of cleaning Postgres d
a-
tabase with vacuumdb command after each data import, to assure good database performance.



Event flow

TBSM will be fed with events from generally three kinds of event
sources (see Picture 1):


servers events, forwarded to Srv5 EIF probe and ObjectServer


networks events, forwarded to Srv6 EIF probe and ObjectServer


3
rd

party systems events, forwarded to Srv3 EIF probe and virtual ObjectServer


Events come from the e
nvironment: networks, servers and 3
rd

party systems, in uncontrolled nu
m-
ber. To protect TBSM stability and operation in situation of event flood,
AAA
-
company

will maintain
events filtering in EIF probes. It means that
AAA
-
company

will configure Srv3 EIF pr
obe rules to filter
out all that events that are not related to TBSM service templates and instances.

Next, Srv5 and Srv6 EIF probes rules will be updated and synchronized with Srv3 EIF probe rules to
assure sending TBSM
-
related events only through Unigate

Srv5 and Srv6.


TBSM 4.2 @ AAA
-
company
-

Review report

IBM



7



AAA
-
company

will also monitor number of events to prevent potentials event floods and to adjust
EIF probes rules and/or to adjust TBSM Dataserver java heaps size, if increasing events number is e
x-
pected effect and events are to be processed

in TBSM.

IBM recommends to monitor events and collecting events statistics on hourly, daily, weekly etc basis.
That knowledge also will prevent potential event floods and will help to indetify systems, servers and
networks bottlenecks, and therefore will
protect
AAA
-
company

systems stability.

Every event should have a corresponding clearing event. Where this is not possible and manual clea
r-
ing must be done, the event should un
-
ambiguously inform users when the event can be safely
cleared. IBM recommends cr
eating OMNIbus automations, which will delete such events after given
time period.


IBM advise
AAA
-
company

to consider the use of Tivoli Impact


an event enrichment tool that en
a-
bles lookups to be done against received events so that the original event c
an be enhanced with i
n-
form
a
tion not available at the event source.



Authentication, authorization and access

All
AAA
-
company

user accounts are stored in central LDAP repository SunOne. Production TBSM 4.2
will be configured to authenticate users with thei
r LDAP credentials. In
AAA
-
company
, certain LDAP
users are members of certain LDAP groups and SunOne repository is the place to manage associ
a-
tions between those users and groups. No associations between LDAP users and groups will be cr
e-
ated or modified in

TBSM console.


TIP console, which is the frontend application for TBSM, will be the place to manage authorizations,
so associations between LDAP groups and administrative roles in TBSM. Also, certain LDAP groups
will be allowed to view certain business se
rvice instances only, based on what services are owned by
which groups.



High availability discussion

TBSM 4.2 in production environment will work in failover mode. It means that TBSM Primary D
a-
t
a
server will be located on one physical server (Srv2) and Ba
ckup Dataserver will run on another

TBSM 4.2 @ AAA
-
company
-

Review report

IBM



8



phys
i
cal server (Srv3). Each TBSM Dataserver will be monitored by separate instance of ITMAgent for
TBSM. OMNIbus ObjectServers will work in virtual ObjectServers pair.


There won’t be load balancing solution configured
for TBSM Dashboard servers. End users wor
k-
st
a
tions are two kinds: clients workstations connecting to Srv1 outside firewall and administrators
workstations connecting to Srv2 (or Srv3 in case of Srv2 situation
like shutdown or disconnection
),
over the firew
all. This is to secure the access to production TBSM servers. Providing one Dashboard
server for clients and another two for administrators is to secure client users experience against a
d-
ministrative activities on dashboard server. All new changes made and

tested on administrative
Dashboard server (Srv2 and Srv3) will be imported manually onto external Dashboard server, by
AAA
-
company
.


Each TBSM 4.2 Data server will be monitored by ITMAgent for TBSM and data collected will be stored
in external data wareho
use


TDW. There will be only one instance of EIF probe, installed on Srv3,
which
will receive events from external events sources and forward those events to virtual
O
b-
je
c
t
S
erver, managed by
AAA
-
company

TBSM administrators. Srv5 and Srv6 EIF probes are no
t ma
n-
aged by TBSM administrators.
AAA
-
company

will maintain a communication between TBSM admini
s-
tr
a
tors and Srv5 and Srv6 owners to keep all EIF probes rules in sync, as mentioned above in Event
flow point.



Reporting discussion

Currently
,

AAA
-
company mai
ntains

an
internal homegrown reporting system for
reports on
histor
i-
cal
services availability
. Two ITMAgents for TBSM will be installed, each by one TBSM Dataserver (on
Srv2 and Srv3), to monitor business service instances status changes and to store that

histor
i
cal data
on TDW 2.1


data warehouse


on Srv4.

This data, collected by agents, will be used next by
AAA
-
company

reporting system. In the f
u
ture
,

AAA
-
company

will migrate from their homegrown reporting system to IBM Tivoli Common Reporting
system,

int
e
grated with TBSM 4.2, but this is not a subject of this review report.




TBSM 4.2 @ AAA
-
company
-

Review report

IBM



9



2.

Business services model

Second point of the review workshop was to assess business services model and deliverables for
AAA
-
company

clients in order to minimalise time and resour
ces consuming operations and to get the
best value out of TBSM.


Business services objects volumes

Currently business service objects volumes are following:


7’738 service instances (records in test TBSM Postgres database)


30 service templates and 60 rules (records in test TBSM Postgres database)


4’500 unique events a time (records in OMNIbus ObjectServer database)


15 concurrent end users sessions (
AAA
-
company

estimations)


In future
AAA
-
company

expect to maintain:


50’000 service instances


20’000 unique events a time


30 concurrent end users sessions


This means that
AAA
-
company

will have to monitor TBSM Dataservers and Dashboard servers
me
m
ory usag
e and events volumes, as it was described in previous chapter, to adjust TBSM and EIF
probe p
a
rameters, in order to protect TBSM stability and performance shape.


Deploying business services

In
AAA
-
company
, TBSM service model is based on series of intervi
ews with
AAA
-
company

clients.
After each interview, for each business service, TBSM administrator creates CSV file, that includes all
se
r
vice instances, templates, rules and permissions configuration. Next, all CSV files are being parsed

TBSM 4.2 @ AAA
-
company
-

Review report

IBM



10



by Perl script and

radshell commands, creating a model, are generated. Next, all generated radshell
commands are passed to TBSM Radshell API and BSM model gets created in TBSM.


In production TBSM 4.2, each CSV file will be stored on Srv2 server.
AAA
-
company

TBSM administr
a-
tors will start Perl script to parse CSV file’s content and create services in TBSM. To respect TBSM’s
performance and maintenance practices mentioned above, java heaps size reset and cleaning Pos
t-
gres database will be considered to perform by
AAA
-
company

after each data import.

IBM recommends an use of version control and backup mechanism to safe CSV documents and bus
i-
ness service model data source kept inside from risk of loss, until CMDB
-
class solution is joint and
integrated with TBSM in
AAA
-
company
. Th
is could be either version control system or relational d
a-
tabase.


Each
AAA
-
company

interview with their clients, delivers also a set of filter criterias to apply in EIF
probes rules. Events incoming from
AAA
-
company

environment are filtered out and only e
vents r
e-
lated to TBSM business services model are forwarded to virtual ObjectServer. Every time that new
events, related to TBSM are sent to EIF probe but don’t match to EIF probe rules, TBSM administr
a-
tors have to a
d
just probe rules manually to apply new
filters criteria.

In the moment of writing this report, there was no agreement on common events format between
AAA
-
company

organizations. IBM recommended to establish one common event format and me
s-
sage standard in whole
AAA
-
company
, in order to simplify,
automate and optimize events and fault
manag
e
ment.


In general, IBM recommends to establish BSM enablement process in
AAA
-
company
, that would co
n-
stist of number of steps to introduce BSM in new
AAA
-
company

organizations or clients. Such pr
o-
cess could inclu
de predefined forms to fill on requirements to meet and describing interview fo
r
mat
and ou
t
comes, like common event format and customers resources map to business services. Pr
o-
cess
-
oriented approach will help
AAA
-
company

in building more automated and reli
able system to
expand business services management within their organizations.




TBSM 4.2 @ AAA
-
company
-

Review report

IBM



11



Business service model

Service templates and instances and rules created in
AAA
-
company

reflect their clients requirements
and environments.
AAA
-
company

implemented a little b
it different service model, than standard
one. It means that there are two main kinds of templates. First kind are templates including built
-
in
inco
m
ing status rule, to process incoming events against service instances. Second kind is common_t
te
m
plate inc
luding numerical formula rules only to simulate depende
n
cy rules between parent and
children templates and services. This means that there aren’t numerous parent templates and d
e-
pendency rules, but simple 2 levels hierarchy between templates. On the other
hand there’s a n
o-
t
i
c
e
able increase of memory usage while adding new template and associating it with common_t
n
u
merical formula rule.

IBM approves presented business services model as built with available TBSM tools and practices.
However
AAA
-
company

will
monitor usage of memory and java heaps size while expanding business
se
r
vices model, in order to adjust allocated hardware and system resources to new requirements.

TBSM 4.2 @ AAA
-
company
-

Review report

IBM



12



3.

Enhancements

The following list is collecting all thoughts jointly shared during all days o
f
AAA
-
company

workshop
with IBM. The purpose of this list is
to
collect all enhancements for IBM’s consideration during d
e-
signing TBSM in the future. All items on the list below will be submit
t
ed only within regular IBM e
n-
hancement request procedure and do

not have an impact on overall review results.

The following enhancements were reported during the workshop.

1.

Shared data sources and fetchers between TBSM and Webtop

a.

Now Webtop and TBSM objects are separate and sometimes it’s required to create
some of the
m twice, separatly for both products purposes


like data sources and d
a-
tafetchers. It would be more usable to share those objects between all applications
in TIP console.

2.

Deleting maintenance windows definitions in radshell

a.

This is operation now availabl
e only from GUI level and not from radshell. U
s
ers, like
AAA
-
company

administrators, using mostly command
-
line tools would prefer to have
this also in radshell.

3.

Update services with radshell

a.

Now objects can be added or removed but not updated. It results
in loosing original
ServiceID identifier, so collapsing custom canvases.

4.

Uninstallation of selected components only

a.

Installation of TBSM allows to install selected components only. Uninstaller does not
provide such choice. Choice like uninstall dashboard
only, or unin
s
tall OMNIbus only,
should be supported.

5.

Quicker service topology display engine, similar to TBSM 3.1 Hyperview

a.

TBSM 3.1 provided very rapid topology view, called Hyperview, allowing to move
from service to service to spot problem roots quickl
y. What TBSM 4.x is missing


it is
poorer time to information. Displaying even small number of services on service
viewer plugin requires dozens seconds or more. Also resizing view causes loss of a
c-
tual status and another time
-
consuming waiting for display reload.


TBSM 4.2 @ AAA
-
company
-

Review report

IBM



13





6.

More configurable TCR plugin

a.

TCR plugin could be more configurable, that it would be possible to display selected
report sets or reports only, based on parameters passed in TIP. TCR plugi
n could be
configurable from Manage plugins page or by passing par
a
meters in inline iframe url,
while pointing to TCR servlet.

7.

Customizable layout

a.

AAA
-
company

looks for a way to customize TIP layout


background colors, labels,
logos etc. In their fashion
. This could be described on support page or as a whitep
a-
per publication.