Category — Application Discovery

We have the start of a pretty good integration between TBSM v4 and TADDM, Tivoli’s Application Discovery and Dependency Mapping product. I say it’s a start because it has a looong way to go to get to where it needs to be for the typical client’s use. There are plenty of challenges with this integration, from performance, scalability and customization.

Within TADDM, you’re pretty much confined to three main containment model constructs. The computer system, the business application and the business service. Within TBSM v4, you can create containment models for anything your heart desires. Getting TADDM’s very configuration item (CI) view of the world to align to reality as built within TBSM v4 is, to say the least, challenging.

Our development organization made a lot of assumptions in their initial release of this integration. Some may be right, but in most cases, clients will want to customize how things are mapped across from TADDM into TBSM v4. The concepts I’m writing about on TBSM Design Patterns will be something you’ll want to map into these eventually. Aligning your own custom templates, integrating your own events and metrics, etc. all requires the careful hacking of XML files and potentially customizing the ESDA policies that drive the SCR. Customizing the Tivoli CDM, custom DLA’s and a GUI based integration that covers mapping TADDM resources to TBSM templates and models is ultimately needed as well.

Here are some resources to help get you started. I strongly encourage you to consider ISST Services to help you along in this journey. It’s not for the faint of heart.

• Installing the Discovery Library Toolkit
• Discovery Library Toolkit
• Discovery Library Toolkit and TADDM Configuration
• Tuning for the Discovery Library Toolkit
• TADDM - TBSM Integration White Paper
• Assigning Different Templates to Services Imported from the SCR
• Discovery Process in TBSM v4 - Mechanism and Customization
• Troubleshooting the Discovery Library Toolkit

Very TADDM specific resources that may be of help. Consider these as you try to speak the same language as your TADDM administrators do.

• Using the Data Model to display data in TADDM
• IBM Tivoli Common Data Model: Guide to Best Practices
• Discovery Library Integration Framework
• IBM Tivoli Common Data Model: Guide to Best Practices

A couple of useful TADDM OPAL contributions for those interested in learning how to get more from your application discovery and mapping investment.

—

Best Practices for using TADDM Sensors

Discovery is performed using sensors which are currently built and deployed as part of the TADDM product. The sensor asks, figuratively, the host and the applications how they are configured and who they are talking to.

This paper does not include detail on the complete list of sensors. Over time this list will be enhanced as we attempt to document all Tivoli Application Dependency Discovery Manager (TADDM) supported sensors, as well as the new ones that are added with every release. The following sensors are addressed:

Apache, DB2 database, IIS, Oracle database, Oracle Application Server, SAP - CCMS and SLD, SQL server database, Weblogic, pplication Server, Websphere Application Server, Windows OS

Tivoli Application Dependency Discovery Manger’s Flexible Approach to Discovery Whitepaper

Tivoli Application Dependency Discovery Manager’s (TADDM) flexible approach to discovery and automatic mapping of dependencies from layer 2 through 7 enables its users with the visibility and necessary agility requisite to improve service availability at their firms. TADDM’s unique approach of combining agent-less and credential-free discovery in configurable discovery profiles facilitates its user’s control over where they discover, what they discover and how deep they go. TADDM allows users continue to leverage their best practices for the business, but now armed with the powerful data analysis TADDM provides in order to make the best informed decisions for their firm.

A new Tivoli OPAL submission for TBSM 4.1 and the integration with the Tivoli TADDM and CCMDB product. If you want to know the gory details of how to customize the integration to fit it into the more realistic solutions you may be building within TBSM 4.1, this is something you will want to review.

-snip-

The TBSM 4.1 Discovery Library Toolkit provides the capability to import discovered resources and relationships from either the CCMDB (formerly known as TADDM) or from IDML books produced by discovery library adapters such as the TMS, ITCAMfSOA, or z/OS DLAs. This whitepaper describes the discovery process and provides the information on how to customize this process to better meet their enterprise requirements.

http://www.ibm.com/software/tivoli/opal?NavCode=1TW10BM01

Some videos on EMC’s AppDisco stuff - former nLayers products. You have to register first to see this stuff - they should be using YouTube these days and stop collecting info on folks!

—-
Learn how to get the most from EMC Smarts Application Discovery Manager. Through this series of videos, EMC’s Glenn O’Donnell, principal product marketing manager, discusses the benefits of automated change, configuration, and incident management. See what Application Discovery Manager can do for you.

EMC on Smarts Application Discovery Manager

Review the basics of EMC’s Smarts Application Discovery Manager (ADM) and learn how you can benefit from automatic, real-time discovery of applications and their distributed components. http://www.accelacomm.com/jlp/eTEXTCHALK1062707/7/80060916/

EMC on Defining a Configuration Management Database Strategy

Discover how you can easily automate data collection, relationship mapping, and object-oriented federation—all with EMC’s Smarts Application Discovery Manager. http://www.accelacomm.com/jlp/eTEXTCHALK2062707/7/80060916/

EMC on Automating Data Center and Server Consolidation

If you’re looking to remove the risk from your data center and server consolidation efforts, watch this video.
http://www.accelacomm.com/jlp/eTEXTCHALK3062707/7/80060916/

I’m enjoying my holiday break and have been able to get caught up some on my “to-do” list. I’ve submitted the following best practice, how to and engagement methodology “field guides” to the internal Tivoli Services knowledge library (ICE). I assume that any IBM’er can request access to this repository. I plan to get these released via the OPAL repository process for general client and partner use as well. Ping me for more information.

How To:

• Incorporating Text, String or VARCHAR Data into Netcool/RAD 3.0 or TBSM 4.1 Tree View Scorecards
• Enabling a Full Netcool/RAD 3.0 - TBSM 4.1 Internal Database Schema and Data Backup

Best Practices:

• Back Up Best Practices for Netcool/RAD 3.0 and TBSM 4.1

Engagement Methodology:

• Netcool/RAD 3.0 and TBSM 4.1 Requirements Discovery Interview Questions
• Netcool/RAD 3.0 and TBSM 4.1 Application Discovery and Modeling Interview
• Netcool/RAD 3.0 and TBSM 4.1 Template Portfolio
• Netcool/RAD 3.0 and TBSM 4.1 Service Instance Portfolio

I was able to work through the last few issues I was having thanks to the tips and tricks section of the ITCCMDB redbook.

Discovery started after defining a simple scope range for the RHEL system I run in a VMware image on my laptop. There is lots of flexibility here to control what’s discovered and what’s excluded. The initial discovery consisted of basic port scans, ping, ICMP and ssh probes of my host to see what was happening. Various sensors are triggered based on what it finds and a very basic set of information is collected.

Conducting a more detailed discovery was as simple as configuring proper credentials for my RHEL image and applications so the discovery process can log in and collect much richer information. Full information about my RHEL image, DB2 database, etc. was collected after adding this information and rediscovering.

I’ve now got a lot of discovered information about what’s installed in my RHEL environment (Netcool/OMNIbus, Netcool/RAD 3.0, Netcool/NGF, Netcool/License Manager, Netcool/Security Manager, ITCCMDB (CDTS/CMDB)). Most of this makes sense to me as I’m familiar with all of those application characteristics. However, there’s not enough context to really know what 192.168.228.2 port 4100 is. Creating custom servers profiles allows you to add the right context to the discovered information for grouping everything into applications and services. There are quite a few out-of-the-box custom servers that you’d expect to find in a large IT environment so you’re likely to have a lot of information after your first discovery. Building custom servers is where you’ll spend a lot of time in custom service and application environments.

There’s a lot of flexibility in how to build custom server profiles. The simplest way was to match a port that was discovered, such as port 4100. I know this port is for the Netcool/ObjectServer. I can add more parameters that must match such as the program name “nco_objsvr” to be sure that I get an accurate match for future discoveries. Any future discovery information matching port 4100 and “nco_objsvr” will now show up as Netcool/ObjectServer applications.

It’s in the custom server profile that I also can define what configuration files, software modules or application descriptors that I want to discover and track. What I like about this is you can actually download and track the contents of configuration files, directories or if something changes with a module or binary.

I’ve got a lot to play with now. Next steps are building business services and applications. Stay tuned.

With the announcement today or EMC picking up NLayers (who they already heavily OEM’d for their Application Discovery product), Symantec picking up Relicore and IBM picking up Collation, the attention has obvioulsy been on the application and service layer. (where the $$$ is)

There’s been relatively little consolidation in any of the Network Change and Configuration Management (NCCM) plays out there aside from Opsware and Rendition Networks last year. I’m not too sure on the takeup rates of any one vendor’s solution (Voyance, Alterpoint, Intelliden, Emprisa Networks, etc.), but I’ve yet to see anyone really focus on one of these platforms to really complement application discovery and mapping within the CMDB other than the “we integrate with X” statement.

The CMDB of the future will need the same rich level of information just like in the application and service domains - even more so as networks become more complex with many more logical configurations (tunnels, VPNs, QoS, CoS, advanced ACL’s, routing protocols, etc.). The same can be said of security/firewall change and configuration management. (I don’t know anyone playing in this space.) Any CMDB without this type of information will be seriously incomplete.

Today’s networks may have been designed to be transparent to the applications and services they support, but Murphy is always out there and the router jockey’s having free reign in the network can’t be a good thing. The sum of all the parts must be consolidated in the CMDB with equal emphasis on depth and breadth of information, not just on the application layer.

* Another thought to ponder - does EMC/SMARTS have plans to get into the CMDB business or would they just lump this into the whole Information Lifecycle Management (ILM) story.