BCO Lookup Tables Explained

One of the strongest and distinctive BMC Capacity Optimization features is the ability to import capacity-relevant metrics from virtually any enterprise data source, being it a monitoring platform, a configuration management system, an asset inventory or even flat files or generic database tables.

Making diverse data flows from heterogeneous sources work together requires a high degree of flexibility. BCO Lookup Tables address exactly this need.

In this post we describe the capabilities enabled by Lookup Tables, together with best practices collected thanks to Moviri long-standing experience of BCO implementation and management projects.

Introducing Lookup Tables

BCO extracts data from sources using tasks. A task interfaces with a single source and has its specific settings. Each task has its own Lookup Table (LT for short) where it keeps tracks of the entities whose data it has previously extracted.

You can think of LT as the “Contact List” of each task. Every time a task has to load some data it goes through its contact list, if contact is already present the task simply adds more data to an existing BCO entity, otherwise a new contact is added and a new BCO entity is at the same time created.

A task may also “share” its LT with other tasks, so that measurements coming from different sources can be merged into the same BCO entity. Take the example of a CMDB source, managed by task C, and a servers’ performance monitoring source, managed by task M. In the contact list analogy and without sharing, the two tasks would build up over time separate contact lists. When C finds a new contact a new BCO entity is created, even if that same contact is also present in task M contact list. Whereas with sharing C is able to “peek” for known contacts into M contact list, therefore enriching existing BCO entity with more data, instead of duplicating entities. After peeking, C copies the contact into its own LT, for future use (e.g. if M is deleted). For our purposes, we won’t go into the mechanisms used to do the actual “contact” (i.e. the LT entry) matching, which may be addressed in a separate post.

What you can do with Lookup Tables

As anticipated, Shared Lookup Tables are useful when you want to load different information from separate tasks into same entities, avoiding duplications. Two main use cases:

• Different measurements from distinct management systems enrich the same BCO entity. E.g. a server gets configuration data (HW Vendor, CPU Model…) from a CMDB while it gets performance data (CPU Utilization, Swap rate…) from a monitoring tool.
• As measurement systems change over time, BCO can keep continuous data series for measured objects. E.g. if the enterprise monitoring platform is migrated from vendor X to vendor Y, the memory utilization pattern for servers is maintained without disruption in BCO.

On the other hand Private Lookup Tables are handy when testing specific integrations, because they provide isolation with respect to already existing entities.

This isolation is actually achieved also specifying clusters of tasks sharing LTs. Take the example of task C, managing CMDB, sharing LT with task M, managing the monitoring tool. Suppose now we need to integrate an asset inventory, e.g. to load rack position information for already managed servers. In order to test the integration of the three sources we can setup, on the same BCO instance, a second cluster of tasks Ct, Mt and At, managing respectively the CMDB, the monitoring tool and the asset inventory. This second cluster of tasks will create its own separate test entities. After verifying everything works correctly we’ll drop Ct, Mt and At, together with the associated entities and data, then we’ll create a new task A and safely share its LT with C and M for steady “production” usage.

Sharing direction and Master Lookup Table practice

As you may have noticed, there is an actual sharing direction between tasks that share LTs. This however does not affect the way entities are identified, i.e. “C shares LT with M” is completely equivalent to “M shares LT with C”. For sake of simplicity, BCO prevents the creation of sharing graphs or hierarchies, enforcing that in a single cluster of tasks sharing LTs only one task can “share”, while all others will “receive” the sharing. This entails that in a sharing group there is one task that has the special role of connecting all other tasks’ LTs.

As a best practice, it is advisable that this special task does not manage any data flow, and serves only as the point of connection for the tasks actually interacting with the data sources. The best practice provides two benefits:

• It makes the connecting task more easily identifiable. It is usually named “Master lookup Table” task.

• It makes the sharing group independent from the specific data sources, as any associated task can be removed or substituted without impacting the others.

Except for testing purposes (or other very specific cases which could be discussed separately), there is no valid reason not to include all “production” tasks in the Master Lookup sharing group: either data sources have some entities in common and therefore they do need to be merged, or sources do not have common entities and therefore sharing would do no harm, but will prepare in case some common entities appear in the future. The best practice can be thus extended to share the Master Lookup Table with any task actively bearing metrics into BCO.

Limit entities creation

In latest BCO versions a further functionality has been made available: a task can be prevented from creating new entities, and thus allowed only to load metrics to existing ones. Used in conjunction with sharing groups the feature enables to elect only certain tasks to define the scope of the entities imported into BCO.

Moviri faced this use case for a large IT service provider that adopted BCO. The request was to use BCO specifically for one of the provider end-customers. The monitoring platform though included the whole servers’ estate, and there were no means of configuring the task managing that source to restrict the extraction according to the needs. However, we were able to configure the task managing the CMDB data source only to import that specific end-customer servers’, and then flagged that task alone as allowed to create entities. After putting the two tasks in the same sharing group we transparently achieved the desired scope delimitation for the BCO instance.

Conclusions

Lookup Tables are a simple yet powerful tool that enables BCO to manage concurrently active data flow tasks, interacting with several sources. Using provided hints and best practices, collected on the field, you can effectively leverage Lookup Tables to keep isolated or merge entities loaded from distinct sources, to best support your capacity management activities.