Tivoli Users Group Home
www.tivoli-ug.org
General Inquiries
info@tivoli-ug.org
Council Email
gtug-council@tivoli-ug.org
Council Home
http://www.tivoli-ug.org/gtug
GTUG Council Mission
To extend the effectiveness of Tivoli user groups - as
well as expanding Tivoli user group networking
capabilities globally.
Want to be informed?
Update your Newsletter profile!
|
| |
Greetings!
This bimonthly newsletter is sent to you on behalf of
the Global Tivoli User Group (GTUG) council and as a
registered member of the Tivoli Global User Group
Community.
|
| |
| |
| |
| Sponsors | | | 
The TUG community is looking for sponsors to our
TUG Newsletter. Please consider promoting your
business through the TUG community.More info
| |
|
| User Group News | | |
We welcome these New User Groups to our
community!
P2P
Peer to Peer Knowledge Exchange
is a capability designed to facilitate the exchange of
ideas, information and experiences among the Tivoli
user group members. Peer to Peer allows you to
collaborate on a local TUG level or with the community
at large. Calling all TUG members to become
helpers!
Executive Corner
Check out the Executive
Corner where you can hear from Tivoli executives
who want to address your concerns and share
thoughts about their area of expertise. Our current
executive, James Chong, VP of Application Development
shares his thoughts on the just newly
announced Composite Application
Products.
MP3 Winners and Survey Results page
NEW: September TUG website satisfaction survey
results are now available in the Survey Results page. We have
created a new page on the TUG website that allows
you to check out the results and action items from the
TUG surveys.
CONGRATULATIONS to the following winners of the
MP3 Players:
TUG website satisfaction survey
winners:
Andrea Depiero
John Beiswanger
Kurt Coroles
Philip Meadway
Steve Marshall
Certification survey winners:
Al Stein
Yves Vlamijnck
Jane Curry
Dave Murray
Elise Kushner
Magnus Haglund
Chris Six
Yan Stamboulis
Mark Dynes
| | |
| Product News and Tools | | |
COMING SOON: Update to the Tivoli
Passport Advantage Tool
Effective November 14, 2005 the Passport Advantage
Online tool will be enhanced to better meet your needs.
Below, please find some of the enhancements that you
should expect to see via Passport Advantage
Online.
- A "download and media finder" simplifying the
process of searching for software downloads and
media.
- User capability to set download and media
preferences.
- Access to software fixes and patches from Passport
Advantage Online.
- Reporting capabilities for migrated licenses and
summarized reports.
- More intuitive product descriptions for media parts
and licenses (electronic images are not included).
- and MUCH more
For a visual picture of what to expect checkout the Passport Advantatage
presentation.FREE Trial Code of Tivoli
Continuous Data
Protection for Files now available.
Download today for continuous file backup without
scheduling, tapes or worries!
IBM Tivoli Monitoring v6.1 hits the
streets in November!
Features include:
- A single, customizable workspace portal (the Tivoli
Enterprise Portal) presents rich visualization of
information across the enterprise for centralized,
simplified management.
- Easy to use warehouse with advanced reporting
capability - includes historical and real-time information
side by side to predict and more quickly resolve
situations.
- Situation Editor lets you easily define and maintain
complex thresholds, situations and alerts for staff
efficiency
- Lightweight architecture for quick deployment,
easier management and less resource consumption
- Hundreds of out of the box best practices for staff
efficiency and effectiveness
- Use either agent or agent less technology
depending on your needs
For more information check out the News section of the TUG website!
|
|
|
| Events and Training Information | | |
Availability Summits
Want to improve the overall availability and
performance of your entire infrastructure by detecting
bottlenecks and predicting potential problems? Attend
one of the many IBM Tivoli
Availability Summits events that are taking place
around the world.
Technical Webcast by Tivoli Development
NOW AVAILABLE, please visit the replay of a webcast
titled "Ensuring the Optimization and
Performance of your J2EE Business Applications"
that Kendall Lock, Director of Tivoli Composite
Application Development recorded on Oct 25, 2005.
Please join Kendall for an in-depth, technical discussion
about how the latest IBM Tivoli performance
automation technologies can be used to efficiently
pinpoint code segments that fail or cause performance
bottlenecks in both pre- and post-production
environments. A use case and demonstration was also
presented during the session.
2006 Tivoli Technical User Conference
UPDATE
Mark your calendars now for the Tivoli Technical User
Conference, April 23 - 27, 2006 at the Hilton hotel in
Chicago, IL. Other conference locations are yet to be
determined.
Looking to gain more knowledge?
Check out our updated Events page for
upcoming events. Also many TUGs are scheduling
meetings soon so check out the upcoming meetings in
the events page.
Education
Check out the selected 2005 Tivoli Technical User
Conference sessions that were
audio taped and now available. Also selected
presentations from the TTUC are
available for download on the TUG website.
IBM Tivoli Monitoring 6.1 Training
The following two instructor led courses will be
available in November 2005.
IBM Tivoli Monitoring 6.1 for Administrators - 3 days
IBM Tivoli Monitoring 6.1 for Operators - 1 day
Free Tivoli Implementation Foundation Skills
Courses
For the month of October IBM Tivoli is offering
customers 2 Tivoli Implementation Foundations Skills
web based courses, FREE of charge. Each course is a
$199 value.
Tivoli Implementation Foundation Skills: Unix Shell
Scripting
Tivoli Implementation Foundation Skills: XML
To enroll go to:
http://www.cgselearning.com/tivoliskills/
Complimentary TSM Concepts Poster and Web
Based Training Classes
This Free TSM poster provides a detailed visual
overview of TSM concepts. The Web Based Training
classes cover topics of interest to both new and
experienced TSM administrators. Find out more
here
TSM Differences Training CD Available Free to User
Group Members
Contact your User Group Leader to find out how to get
your free copy.
|
| |
| FEATURE: Tivoli Advisor Article | | | Deep Technical Artilces - Tivoli Advisor
Issue 6 of the Tivoli Advisor is now available for
download. You will find articles on the following:
- IBM IT Service Management Update
- Managing Transaction Performance part II
- Tivoli's 'Mcollect' - how does it work?
- IBM Tivoli Monitoring Version 6.1
architecture
In cooperation with the Editors of the Tivoli Advisor we
will from time to time feature articles from the Tivoli
Advisor. We hope you enjoy this new feature of the
TUG Community Newsletter.Tivoli's 'MCollect' - how does it work?
Written by Angela Leonard, L2 Inventory Support,
Tivoli software
Mcollect is a Framework service used by IBM Tivoli
Configuration Manager's (ITCM) Inventory component
for asynchronous collection of scanned data.
Inventory scans server/client machines for both
hardware and software data that is then picked up by
the MCollect service and sent back through the
Framework repeater hierarchy to Inventory's
configuration repository. There are many components
of MCollect that are necessary to understand and
configure properly in order for MCollect to function at
an optimal level.
CTOCs
The data transferred by MCollect is referred to as a
collection which contains a CTOC (Collection Table of
Contents) and the datapack file (the actual scanned
data). The CTOC contains information about the
Collection and its destination. When the scan
completes on the Tivoli Management Agent (also known
as TME endpoint, or simply endpoint), Endpoint_prog1
(MCollect process that runs on the endpoint) assembles
the collection and sends an upcall to the collector
running the endpoint's gateway. This upcall method is
mc_request_collection which lets the collector know
there's data to be retrieved from the endpoint. Once
the gateway collector registers the CTOC in the input
queue for that collector, it will send a downcall method
(mc_get_data) back to the endpoint and retrieve the
data.
Datapack Files
Datapack files, i.e. INV0001.DAT, are compressed
binary files constructed by the Endpoint_prog1 process
on the endpoint upon completion of the scan. They
reside in the $LCFDIR\inv\SCAN directory on the
endpoint. The datapack file contains the actual data
that will ultimately get updated in the Inventory
configuration repository. When the mc_get_data runs
on the endpoint, an IOM channel is opened to the
gateway collector and the datapack file is sent. After
the gateway collector confirms the datapack file has
been retrieved successfully into the depot on the
collector, it creates an INV0001.DON file on the
endpoint in the $LCFDIR\inv\SCAN\mcollect directory.
This is a zero-byte file which indicates the datapack
was successfully uploaded to the gateway collector. A
subdirectory (with the same name as the CTOC id) is
created in the collector's depot which is where the
datapack file is stored.
Collectors
The collector process, Collector_prog1, is multi-
threaded and can be installed on a Framework managed
node or gateway. Its function is to store a collection
and then forward it on to other Collectors or to the
Data Handler (last Collector in the MCollect chain).
MCollect, or Scalable Collection Services, must be
installed on a managed node in order to use it as a
Collector.
Collector Components
There are three different types of resources used to
control the flow of CTOCs and datapack files between
two Collectors or a Collector and the Data Handler.
The queues (input and output) reside in the Collector's
runtime directory and are used as temporary storage
areas for the CTOCs. The depot is a subdirectory
created in the runtime directory and its function is to
store the datapack file. The Collector's scheduler
controls the timing and flow of data.
Queues
The Collector's queues are used to hold CTOCs that are
currently processing. There are four queues for each
Collector: Input, Output, Error, and Deferred.
Each queue uses a checkpoint file for backing up its
contents. MCollect stores these files in the run-time
directory for that Collector. The Collector uses the
checkpoint files (binary files named checkpointGL_
[queue]qfile.dat) to recover the queue if it is stopped
or goes down prematurely. The CTOC is appended to
the checkpoint file when it is added to the
corresponding queue. The same occurs when the
CTOC is removed from a queue. It is removed from the
corresponding checkpoint file.
Stored in the same directory as the checkpoint files are
the CTOC_log.dat files. This log file tracks the status
of all completed collections. The contents of these
files can be viewed using the wcstat command.
wcstat -q ioed
@Gateway:<gwname>
The options i, o, e, and d can be combined or ran
separately (I - input, o - output, e - error and d -
deferred). Running the wcstat command with one
option at a time, gives a more accurate representation
of the current status of the CTOCs. For example:
wcstat -q o
@Gateway:cm2003rct
CTOC ID: c18618220741145925993
CTOC Properties:
PRIORITY: 1
SOURCE_NAME: kdtivp05
SOURCE_OID:
1861822074.2026.19
ORIGINATOR_OID:
1861822074.11459.517+
SOURCE_METHOD:
mc_get_data
DEST_OID:
1861822074.2323.25
DEST_METHOD:
mc_request_collection
WRITE_COMPLETETION_FILE: /usr/local/Tivoli/lcf/inv/SC
AN/mcollect/INV02073.DON
DATAPACK: 6366
Client Properties:
inventory_scan_id: 2073
Collection Status: WAIT_UPSTREAM
#Retries: 0
This output indicates the mc_request_collection has
run on the data handler and the gateway is waiting on
the data handler to respond with the
mc_get_data.
Depots
Every collector, Managed Node, Gateway, and Inv Data
Handler, contains a depot directory used to store scan
data collected from a downstream collector or
endpoint.
The depot has subdirectories, one for each CTOC
currently in the output queue. The depot also contains
the Collector's index.dpo file which contains a reference
to each collection's data files. The default size of the
Collector's depot is 40M. The size of the depot can be
increased, only, not decreased. The syntax of this
command is:
wcollect -z <depot size>
<Collector name>
The CTOC is placed in the input queue of an upstream
Collector as a result of the mc_request_collection
initiated by the downstream Collector. The upstream
Collector will run the mc_get_data on the downstream
Collector and retrieve the data pack file from its
depot. The depot directory must be located on a file
system with lots of free space. If the upstream
Collector doesn't have enough space to store the data
pack file in its depot, this causes an error and the
CTOC is moved to the error queue. The depot
directory (a subdirectory of the run-time location) can
be changed via the wcollect -l command which
moves the run-time location.
Scheduler
A Collector's scheduler daemon is a multi-threaded
process used to send and receive CTOCs. There are
several Collector parameters that can be configured to
control the bandwidth and the schedule used to
transmit the data.
The Collector process (Collector_prog1 on gateway and
managed node collectors; inv_rcv_meths on
InvDataHandler collector) spawns input and output
threads that moves the CTOCs from queue to queue
and retrieves the data pack files. Input threads
process CTOCs in a Collector's input queue or error
queue by retrieving the datapack files from a
downstream Collector or endpoint. CTOCs in a
Collector's output queue are processed by a
mc_request_collection upcall to transfer the CTOC to
the input queue of the upstream Collector or Inv Data
Handler. The input and output threads can be
configured via the wcollect command:
wcollect -i 10 @Gateway:cm2003rct-gw
wcollect -o 10 @Gateway:cm2003rct-gw
The input and output threads along with the depot
chunk size are used to control the amount of data
transmitted at any time. For example, if the Collector
has 10 output threads and its depot chunk size is
configured to 5K, then it will transfer up to 10
simultaneous 5K chunks of data for a total of 100K of
bandwidth. Data will continue being transferred at this
rate as long as data is in the Collector's depot. The
chunk size can be configured via the wcollect command:
wcollect -c 512 @Gateway:cm2003rct-gw
A Collector's configuration can be viewed by running:
wcollect @Gateway:cm2003rct-gw
Collector: @Gateway:cm2003rct-gw
debug_level = FATAL (error messages
only)
debug_log_size = 1 MB
runtime_location =
depot_size = 40 MB
depot_chunk = 512 KB
thread_idle_down_time = 60 seconds
thread_sleep_time = 5 seconds
max_input_threads = 10
max_input_retries = 10
max_output_threads = 10
retry_delay_time = 1 seconds
offlinks =
log_completed_ctoc = true
Collection Manager
The Collection Manager (found on the TMR) manages
the routes used by the Collectors for moving data
through the collection hierarchy. The Collection
Manager relies on a map of the repeater hierarchy (held
in memory) for determining the routes used by the
Collectors. The repeater hierarchy is defined using
the "wrpt range=<value>" command. Please refer
to the Framework Reference Manual for details.
Data Handler
The Data Handler is the last Collector in the MCollect
chain, so, its responsibilities are to unpack and decode
the datapack file and send it to the RIM (RDBMS
Interface Module) object, invdh_1. Just like its
downstream Collectors, it has a depot and queues, as
well.
The operation of the Data Handler process,
inv_rcv_meths, is similar to that of a Collector. There
are a couple of differences between the Data Handler
process and the Collector process. The first being the
location of the runtime directory. The Collector's
runtime directory location is $DBDIR/mcollect, by
default. And the Data Handler's runtime directory is
$DBDIR/inventory. The second difference is the fact
that there can only be one Data Handler per TMR. The
Data Handler is created on the TMR when Inventory
Server is installed. If the Data Handler is moved to
another Managed Node, then, Inventory Server must
be installed on that machine.
In large environments, it's recommended that the Data
Handler is moved to a dedicated Managed Node. This
will ensure there's enough memory, CPU, and disk space
to support the Data Handler function. This is due to
the large amount of processing that takes place during
the Data Collection process.
The Data Handler's input threads function the same as
the Gateway Collector's input threads, they receive
CTOCs and data pack files. These threads can be
configured via the 'wcollect -i <value>
@InvDataHandler:inv_data_handler' command.
The Data Handler's output threads are used to unpack
and send data to the RIM. These threads can be
configured via the 'wcollect -o <value>
@InvDataHandler:inv_data_handler' command.
The wcollect command can be used to start, stop, or
configure the Data Handler. Instead of specifying the
Gateway Collector or Managed Node Collector, the Data
Handler object would be specified. For example:
wcollect -d 3 @InvDataHandler:inv_data_handler
This changes the debug level of the Data Handler's
mcollect.log to 3.
Status Collector
MCollect's Status Collector is responsible for keeping
track of all active Inventory distributions. The Status
Collector's process, inv_stat_meths, is a separate
process from the Data Handler process, but, is
considered to be part of the Data Handler component
and runs on the same Managed Node. When an
Inventory scan is initiated, the Status Collector
maintains information for each endpoint, for example,
whether it was successful, still pending, or
failed.
The Data Handler reports the status of each target to
the Status Collector by passing a list of endpoints to
the inv_stat_meths process. At this point, the Status
Collector assigns a scan id to the distribution and all
nodes are listed as pending. As the CTOCs get
processed by the Data Handler and scan data gets
inserted into the database, the Status Collector
process updates the endpoints' status as either
successful or failed.
The Status Collector process maintains a subdirectory
of the Data Handler's runtime directory called
status_dir. Status information for all active Inventory
scans is located in this directory. This information is
stored in two binary files called inv_scan_id.cfg and
inv_scan_XX.cfg, where XX is the scan ID of a running
Inventory scan. The inv_scan_id.cfg file is a single file
that contains the last scan ID given out by the Status
Collector. The Status Collector uses these files to
report the current status for each endpoint involved
with the scan. When the Data Handler process reports
that a scan is complete, these files are
deleted.
Status information for all active scans can be viewed
via the wgetscanstat command:
wgetscanstat -a -s -f -p
-a Will show all active scans.
-s From the active scans, which endpoints
were successful
-f From the active scans, which endpoints
failed
-p From the active scans, which endpoints
are still pending
Callback Object
The callback object process, inv_cb_meths, runs on
the TMR and gets invoked when the
mc_request_collection fails on the gateway collector
and is unable to upload the datapack file. The Callback
object uses MDist2 to send the data to the TMR (the
CTOC is stored in $DBDIR) and then on to the Data
Handler. This serves as the backup collection method
for MCollect.
MCollect can run smoothly with all components tuned
to the customer's environment. Those components
being each Collector and the Data Handler, taking into
account the input and output threads along with the
depot size and depot chunk size. The MCollect
commands, wcollect, wcstat, and wgetscanstat, can
assist with monitoring the success of the data transfer
along with the configuring of collectors and viewing the
status of the collections.
| | |
| In our own words - GTUG council | | |
Proof of Technology Program (POT) - a customer
percpective
Belgacom kicked off a CCMDB Proof of Technology
(POT) with IBM mid-September. The focus of the POT
was two fold: 1) focus on technology, . 2) put the
baseline of the ITIL processes in place. The
technology part is going surprisingly well. The IT
service management product that is based on IBM WBI
& portal technology was pre-installed on a loaner
laptop from IBM. The next step was to configure the
application so it could receive feeds from IBM Tivoli
Configuration Manager (TCM).
Configuration went well and data was synchronized
between TCM and CCMDB within an hour where some
scenarios could be exercised. In its early stages of the
product, and there are some nice features available out
of the box. CCMDB has a nice viewer GUI that provides
relationship information about CIs and and the impact
to CIs in the context of change management. The
change management component has limited
functionality but the same features of release
management will be applied to change management
also. Some of the features within the release
management are visualization of the process flow and a
nice release calendar. Another component tested was
the integration of TCM software distribution with
release management.
From a process perspective, a baseline needs to be
established as to were within the process maturity
model you are. IBM conducted interviews with various
process owners to understand the baseline and
recommend steps to go forward. This interview process
is valuable because it identifies the process maturity
level and what needs to be done to take it to the next
level. Overall, the POT is proving to be valuable for
both IBM and the customers. Why don't you consider
participating in the Proof of
Technology Program too!
TEC/NetView Futures, What to Expect
In an effort to address the autonomic computing and
process oriented solutions requirements, IBM is
developing standardized event structure, delivery and
correlation technologies that will be used across all IBM
software to provide a common base for event
management. The following are brief description of the
components:
- CBE: A consistent, standardized, specification
for the definition of normalized log and event
information for various domains (business, security,
network, system, etc)
- CBE adoption is being driven by Autonomic
Computing
- CBE is the base of the OASIS WEF (Web Event
Format) standard just approved as part of WSDM
- CEI: A readily available, reliable, scalable and
embeddable event infrastructure that supports
submission, persistence and distribution of event data
based on CBE
- Support for WS-Notification standard APIs
- ACT: An embeddable, cross domain, correlation and
automation component composed by run time and
tools.
- Common environment for business rules and event
correlation
Event sources such as IT infrastructure, business
applications, middleware and others generate CBE
events to CEI. Event consumers receive events
through subscription to CEI. ACT (active correlation)
can be applied to CBE before or after the events get to
CEI.
It is important to highlight that TEC will be a major
consumer of the CBE/WEF events coming from CEI
environments.
TEC Next Steps
- TEC will be tightly integrated with ITM 6.1. To
be available 4Q 2005 with ITM 6.1.
- Workspace with TEC event view in TEP
- Management and correlation of ITM situations in
TEC
- Synchronization of events and ITM situations
- TEC 3.9 Feature Option: Management of CBE/WEF
Events in TEC. To be available in Jan/06.
- Ability to manage, visualize, correlate, automate
and report on CBE/WEF events in TEC.
- Web services interface to send CBE/WEF events
based on WS-Notification standards
- CEI server extension to forward events to TEC
- Requires TEC 3.9 and CEI 6.0+
TEC Future (2006 and beyond)
Some examples of areas that are candidates to be
addressed in TEC future releases
- Richer visualization in TEP
- Self-management of TEC infrastructure in TEP
- Enhanced on-line and historical reports through
TEP/TDW 2.1
- Event correlation rules builder in TEP
Distributed NetView Next Steps
Distributed NetView will be further integrated with TEC
and TEP within ITM 6.1 (to be available by 4Q/05 with
ITM 6.1). In TEP console, events generated within a
TEC view in a TEP workspace can have a launch in
context to NetView to bring up NetView web console to
look at network maps. From Distributed NetView
customers will be able to drill-down to layer 2 level.
The Switch Analyzer will continue to provide well
integrated layer 2 device support tightly integrated
with the Distributed NetView product.
Distributed NetView (2006 and beyond)
Some examples of areas that are candidates to be
addressed Distributed NetView future releases:
- Richer visualization in TEP
- More protocol currency (like SNMP v3, IPv6)
- Enhanced management capabilities ( for example
MPLS, VoIP)
- More network performance capabilities
- Self-management of Distributed NetView
infrastructure in TEP
- Enhanced on-line and historical reports through
TEP/TDW 2.1
For more information about TEC and
NetView check out the archived TUG Webcast and
Q&A document from the September 22 TUG webcast.
If you have been forwarded this Newsletter and would like to subscribe please click here.
| |
|
|
