Download Federation and a CMDB - Avnet Technology Solutions

BEST PRACTICES WHITE PAPER
Client Solutions BSM
e: [email protected]
t: 01 620 4000
w: www.clients.ie/bsm
Federation and a CMDB
Table of Contents
EXECUTIVE SUMMARY .................................................................................................................. 1
WHAT IS FEDERATION? ................................................................................................................. 2
Federation and Configuration Management ............................................................................2
UNDERSTANDING THE CONCEPT OF FEDERATION .................................................................... 2
Library Card Catalog Analogy ................................................................................................... 2
Differentiating Data Types ......................................................................................................... 2
Which Core CI Data Must a CMDB Store? .............................................................................. 3
Value of a Federated CMDB Approach .................................................................................... 3
Don’t Federate Core CI Data .................................................................................................... 3
Data Normalization and Federation .......................................................................................... 4
ACCESSING FEDERATED DATA ..................................................................................................... 4
What Constitutes a Link? ......................................................................................................... 4
Methods for Linking to Federated Data ................................................................................... 4
IMPORTANT BENEFITS OF A FEDERATED CMDB ........................................................................ 5
WHAT SHOULD A FEDERATED CMDB LOOK LIKE? ...................................................................... 5
ADDITIONAL POINTS TO CONSIDER ............................................................................................ 6
Federation: Not the Answer to Everything .............................................................................. 6
CAN I HAVE MULTIPLE CMDBs? ................................................................................................... 6
DIFFERENT APPROACHES TO FEDERATION ................................................................................ 7
Database Federation ................................................................................................................. 7
Virtual Data Stores .................................................................................................................... 7
CONCLUSION .................................................................................................................................. 7
Executive Summary
Growing momentum behind IT Infrastructure Library (ITIL ) initiatives has turned the configuration
®
management database (CMDB) into an industry reality — and the concept of data federation is at the
forefront. Organic development and IT management tool implementations have increased significantly
in recent years, leaving many organizations with data that is pertinent to millions of configuration items
(CIs), such as servers, routers, people, business services, and processes. That data also includes relationships and management data related to the CIs.
In these IT-laden environments, federation can provide the foundation for creating a CMDB that is scalable, adaptable to fit existing IT infrastructures, and addressable by all applications that need to provide
or leverage CMDB data. A federated CMDB should provide an accurate, single representation of data
from which to work, for all IT processes.
This paper discusses the concept of federation, how federation should be approached in the context of
a CMDB, and the key requirements for building a federated CMDB approach.
PA G E > 1
A card catalog provides users with different ways to search
What is Federation?
for library books, based on title, author, category, and so
Federation is a method to provide a single way to access
on. Each method available for finding a single book provides
data held in many different locations. Federation allows data
users to search and utilize data without needing to under-
relationships between multiple book reference cards and
information on where the actual book is stored in the library.
stand exactly where the data resides or the technology
The comparison of the federated approach to a library card
behind accessing the data.
catalog is referenced throughout this white paper.
As an IT organization evolves, many different types of technologies and systems likely have been implemented that
Differentiating Data types
When considering a federated approach to a CMDB, it is
store different types of data for different applications and
first important to understand the different types of data
users. By linking together these disparate data sources,
data federation helps provide a consistent way for users to
access cross-functional data without requiring organizations
to replace their specialized solutions.
that help define a CI and its attributes. This is helpful when
determining which data should be stored in a CMDB and
which data should not.
A configuration item (CI) contains three types of data:
> Core CI data: Data that defines the CI, its attributes, and
Federation and Configuration
Management
relationships with other CIs.
Configuration Management, as an ITIL discipline, focuses
Example: A server, its name, and attributes (such as
on managing and maintaining information about the configu-
amount of memory, CPU speed, location, users) and how
ration of an IT infrastructure. ITIL considers the CMDB to be
that server relates to other CIs like a business service CI.
> Detailed CI data: Data that provides highly detailed
a key component in configuration management.
information about a CI.
When it comes down to it, what a CMDB provides is ac-
Example: Registry information and settings on that
server.
tually pretty simple: a central location for storing basic
records related to the CIs (servers, routers, desktops, busi-
> Related CI data: Information that does not describe the
ness processes, and such) in an organization’s production
CI, but rather provides information about that CI.
environment and the relationships between those CIs.
Example: Help desk tickets, change requests, and other
The CMDB provides a single source of record on which IT
incidents related to that server.
processes rely, providing accuracy and consistency across
processes. However, what ITIL does not define is how to
We can define data about books in a library in the
approach a CMDB implementation or how to organize data
same way:
to create a scalable CMDB solution. This paper focuses on
> Core book data: Information such as author, title,
how federation helps answer the “how” questions related
to CMDB implementations.
year published
> Detailed book data: Chapter information, indexes,
appendix, page information
For more information on other aspects of the CMDB and
detailed examples of what should and should not be considered as CIs, please refer to the “What You Need from
a Configuration Management Database” white paper available at www.bmc.com/cmdb.
> Related data: Data about book reviews, user opinions,
related books that might be of interest
Dissecting the library card catalog helps us understand
which type of data (core, detailed, or related) should be
stored in the card catalog and which data can reside in
Understanding the
Concept of Federation
other locations. For example, a library book’s core data
would be the information that is required for readers to
Library Card Catalog Analogy
be able to find the books they need, such as author and
Consider the concept of federation, as it relates to a CMDB,
title, and must be part of the card catalog.
as being similar to the library card catalog system.
However, additional information related to books does not
What is a library card catalog? The card catalog found in
need to be stored within the card catalog. Think about
every library is a single source in which to find basic infor-
what a card catalog would look like if you were able to
mation on any book in the library system. This is similar to
search and view chapter information, user opinions, and
what a CMDB provides to an IT environment.
PA G E > 2
Objective Measures
Contributing Factors
> Asset name
> Asset type
> Asset ID
> Amount of memory
> Size of hard drive
> Serial number
Measurement Approach
> Operating system registry information
> Bios configuration settings
> Asset documentation
> Patch details
> System settings
> Help desk tickets
> Change requests
> Service level agreements
> Finance information
> Impact analysis
Table 1. Examples of CI data types
so on. That would be overwhelming for the reader search-
and keep all the data consistent and accurate. Additionally,
ing for books, but would also be a daunting task for any
the more data there is in the IT environment, the less scal-
librarian that had to build up and maintain such a detailed
able the CMDB.
repository of book information.
Using the federated CMDB approach, data that should be
In reality, what readers need is a way to access detailed and
stored in the CMDB is sorted out from data that should
related information about books if and when they need it,
not. By providing a simple means to access detailed and
as opposed to having it all stored and available through the
related CI data stored in other repositories, we can build a
card catalog. As long as the card catalog provides a way to
CMDB that will be much easier to manage, maintain, and
find additional information, the reader should be satisfied.
scale while continuing to leverage existing investments in
different IT management technologies. It is this core value
This is also true when we examine CI information in a
proposition that makes the federated CMDB approach so
CMDB. You must decide which core information needs
important (Figure 1).
to be stored in the CMDB and which information can be
kept in other repositories that link to the CMDB. Linking
IT Processes
the CMDB to external data describes the concept of federation and the foundation for building a federated CMDB
approach.
Which Core CI Data Must a CMDB Store?
The CI data designated for storage in a CMDB varies, de-
CMDB
pending on the environment. Just like the card catalog, IT
processes, and users of those processes, must be able
Core CI Data
Desktop Data
Server Data
Network Data
Business Processes
Relationships
to search on information about CIs and how they relate to
other CIs in the environment. This information — such as
the name of an asset, its location, serial numbers, and related business services — is considered core CI data.
Federated CI and Related Data
In addition to core CI data, users may need to access detailed CI data (such as operating system information) or
related CI data (such as actual help desk tickets). Similar to
the card catalog, storing this information within the CMDB
Data
Store #1
Data
Store #2
Data
Store #3
Change Request
Data
Helpdesk
Data
Detailed Server
Data
would require a massive data repository. Instead, this deFigure 1. Federated CMDB model
tailed and related data can be federated and stored in a
separate location. The CMDB can then provide a link to that
data, enabling users to access it when needed. This means
Don’t Federate Core CI Data
that any information the user needs for any CI can be ac-
While it is important to federate related and detailed data, it
cessed from a single location.
is imperative to not overextend the concept to include the
federating of core CI data.
Value of a Federated CMDB Approach
Storing all CI data types in a single CMDB would be ex-
Imagine a card catalog spread out over various locations,
tremely difficult to maintain and manage. The CMDB would
each of which provides different information about books
spend large amounts of processing power trying to organize
in the library. If one of those card catalogs is stored in a
PA G E > 3
building that closes at 5 p.m. every day and you need infor-
tion actually happens. How do you actually access federated
mation about books that are stored in that catalog, you will
data through the CMDB? How do you link to the informa-
be out of luck — and there will be nowhere to access that
tion stored in other data sources?
data. You must wait until the building opens for business
the next day before you can access that catalog and get the
What Constitutes a Link?
information you need.
In the library card catalog, for example, a link could consist
of a card that describes where the reader can go to access
Similarly, if core CI data in your environment is stored in
information about book reviews. Or the card could provide a
multiple data stores and one of those stores becomes
URL that points to a Web site where the reader can access
unavailable, your core CI data is unavailable for use by IT
reviews from other readers, editors, and so on.
processes and users. To ensure that core information is al-
In a CMDB, a link to federated data means that the CMDB
ways available, it is important to store core CI data within
stores information on how and where to access data stored
the CMDB, and not federated from other locations.
in other repositories.
Data Normalization and Federation
Methods for Linking to Federated Data
Another important benefit of a federated CMDB is that it
Linking to federated data refers to methods for accessing
promotes data normalization across CI data stored within
federated data stored in other locations or data repositories.
the CMDB.
The following list describes approaches that can be used to
What is data normalization? – Think about the library card
access federated data through the CMDB.
catalog — it normalizes book data within the catalog by key
> Documentation: Probably the most simplistic concept
attributes such as author and title. Searches based on these
of federation, in this approach you create documentation
attributes are standardized across all books in the library.
within CI details housed in the CMDB, which tells the user
Imagine if the card catalog allowed readers to search the
where the data is and how to access it.
author Ernest Hemingway using multiple formats such as
Example: While viewing a CI, there may be visible docu-
“E. Hemingway,” “Ernest Hemingway,” or “Hemingway,
mentation that tells the user where detailed data about the
Ernest”— but provided no way to understand that all for-
CI exists and how to access it. This is similar to the card
mats refer to the same author. This example can extend
catalog example previously discussed in this white paper.
to include the different ways publishers might define the
> Open external application: The user can open up anoth-
“author” attribute for their books. Without a standardized,
er application that stores information about the CI data
single format for “author” to normalize the book data within
being federated. This allows the end user to interact with
the card catalog, imagine how difficult it would be for read-
this data from another application interface, one that is
ers to search for a certain author. They would need to know
independent of the CMDB user interface. This application
exactly how each publisher defined its author attribute.
could be launched through a Web service, a run-process
command, or other program execution options.
The same holds true for a federated CMDB. When data from
Example: While viewing a CI, the user could click on a
multiple sources is linked into the CMDB, the CMDB creates
button that would launch another application or URL that
a single, consistent way to represent this data. For exam-
would link them to a different interface, one that provides
ple, if multiple discovery sources capture information about
information about detailed or related CI data.
a server, and each source names the server type differently, the CMDB will normalize this data into a single name for
> Open user interface: Leveraging user interface (UI) tech-
nology provided through the CMDB, UIs can be created
use within the CMDB. Resultantly, all IT processes will then
within the CMDB environment that link into a federated
work from a normalized set of data, regardless of where
data store and have the same “look and feel” as the
the data originated. Additionally, users will then have a sin-
CMDB interface.
gle understanding of how to access and search CI attributes
Example: While viewing a CI, a user can link to a UI that
within the CMDB, because every type of CI is represented
was developed with CMDB UI technology, which would
in a single, consistent way.
run in the background and point to data stored in a different data repository.
Accessing Federated Data
Now that we have an understanding of what federation is
There is no right or wrong approach to implementing feder-
and of the different types of CI data that should and should
ated links; it is simply a matter of preference and the level
not be federated, it is important to learn how data federa-
of integration required. You should evaluate each method
PA G E > 4
and understand user requirements to determine which federated link option will work best for federating your data.
What Should a Federated
CMDB Look Like?
The federated CMDB model refines the ITIL concept of a
Important Benefits
of a Federated CMDB
CMDB by breaking up the CMDB and its infrastructure into
three layers (Figure 2) including:
The greatest benefit of the federated approach is that it enables the CMDB to focus its functionality solely on CIs and
> The CMDB itself
> Related data linked to or from the CMDB (the CMDB
their relationships. The overhead required to provide this
extended data)
functionality is not wasted on data that is not considered
> Applications that interact with these two layers (the
core CI data. Additionally, the recommended federated
CMDB environment)
approach means that:
> You need not migrate related data or modify the
CMDB to hold core information. You do not need to
undertake several data migrations and application integrations to move related CI data such as change requests
SLA
Management
or help desk tickets into the CMDB. Applications that
use this data can continue to access it from where it is
currently stored, eliminating the need to modify those
existing applications to work with the CMDB.
CMDB Environment
Applications
Capacity
Management
Software Config.
Management
Change
Management
Application
Management
Discovery
Application 1
Service Impact
Management
Asset
Management
Identity
Management
Discovery
Application 2
Help Desk
Incident
Management
Provisioning
Problem
Management
> Transactional data can be stored in databases that
Requests
are better able to handle a high volume of requests,
CMDB Extended Data
instead of in the CMDB. Data is provided more efficient-
Information related to CIs
ly. Instead of getting all CI data and related information
Extended CMDB
from the CMDB, data consumers can get it from individual data stores and applications that are optimized to
provide the specific type of data being requested.
With requests for related data being handled by other
databases, the CMDB does not need to accommodate
Change
Requests
Capacity
Management
(CDB)
Help Desk
Tickets
Contracts
Service Level
Agreements
Other Data
Related to CIs
Links Between Records
CMDB
all such traffic in addition to CI-related requests. You can
Definitive
Software
Library
Configuration
Items and their
Relationships
spread the load across multiple systems.
> Data is normalized across data sources, optimizing
CI search capabilities for end users. As previously
discussed, data normalization provides a consistent definition for CI data, bringing consistency and accuracy to
Figure 2. Three layers of a federated CMDB infrastructure model
all data stored within the CMDB. Because the CMDB
provides both data normalization and a core set of CI
data elements, end users have a single place to go to
As Figure 2 shows, the CMDB and CMDB extended data
search and access all CI information, even if that informa-
layers, when combined, contain the information ITIL sug-
tion is federated and stored in other data repositories.
gests be stored in a CMDB. Separating this information into
two layers provides a basis for a federated CMDB.
PA G E > 5
The CMDB holds only CIs and their relationships.
Can I Have
Multiple CMDBs?
The CMDB extended data is federated CI data that can be
either related data, detailed data, or less-important CI attri-
The idea of multiple CMDBs in a single production IT envi-
butes that are stored in repositories outside of the CMDB.
ronment is somewhat oxymoronic. A CMDB by definition
is a master system of record. In ITIL terms, the CMDB
The data in the CMDB extended data layer is linked to the CI
needs to be one master record of information about your
data in the CMDB. By definition, federated CI attributes are
CIs and their relationships. The only exception is when an
linked from their instances in the CMDB, allowing requests
organization has IT implementations that are completely
to the CMDB to reach these attributes. However, for other
independent and do not need to interact with each other
types of extended data, the link can be in either or both di-
(i.e., multiple geographies that operate independently).
rections. For example, a change-request record could have a
link through which you can access the instances of the CIs
The repository for the master system of record for core CI
it will change, and each CI instance could have a link through
data is the CMDB. There may be extra configuration stores
which you can access the change requests that affect it.
that contribute CI information into the CMDB and may even
use CMDB technology; but they do not represent the source
Additional Points to Consider
of record for CI data. Instead, these configuration stores can
Federation: Not the Answer to Everything
information as needed.
be linked to the master CMDB to exchange and cross-update
Once we understand the concept and benefits of federation,
it is important to know that there are limitations in what a
In situations where multiple CMDBs or configuration stores
federated CMDB can provide for your IT environment.
exist in an environment, organizations must designate which
data store will become the master CMDB. All other data
A federated CMDB is not the answer to every IT prob-
stores then become configuration stores that can exchange
lem. In other words, a federated CMDB cannot create an
information with the master CMDB. These configuration
“automagic” environment in which all data, everywhere,
stores may function as a CMDB for the processes that
can be accessed anytime by any application for any reason.
leverage them but, because they are not the source of
While federation does provide a means to logically ap-
record for CIs, they are not considered the master CMDB
proach a CMDB implementation, it will not be the answer
(Figure 3).
to all your needs.
IT Processes
A federated CMDB will not provide universal reporting
capability. The CMDB cannot provide access to all data
across your organization through a single query via a single
interface. Although that could be achieved with a huge in-
Master
CMDB
vestment and implementation, it goes beyond the scope
of value that federation provides to a CMDB implementation. What a CMDB will create, however, is a single way
for IT management processes and end users to access all
information about CIs and their relationships, even when
Data
Exchange
Desktop Data
Server Data
Network Data
Business Processes
Relationships
Data
Exchange
information related to those CIs is not being stored in the
same data repository.
Configuration
Store #1
Configuration
Store #2
Configuration
Store #3
Figure 3. Master CMDB model
PA G E > 6
Different Approaches
to Federation
IT Processes
In the IT world, there is more than one definition for “federation.” It is important to remember that some federated
Virtual CMDB
data approaches may not be valid for a federated CMDB
approach. We examine a few of the other approaches in
Data
Store #1
the following sections.
Data
Store #2
Data
Store #3
Business
Process Data
Network Data
Server Data
Desktop Data
Database Federation
Data
Store #4
Database federation should not be confused with CMDB
Figure 4. Virtual CMDB model
federation. In database federation, data can be stored in
separate tablespaces and then federated together so the
information can be searched from a single location. For
one of these systems fails or cannot be accessed, the com-
example, database federation might be used for storing
plete view and understanding of CIs and their relationships
an employee directory, where names starting with A-F are
is instantly lost. For example, if the data store that holds in-
stored on one database table, G-L names are stored on
formation about business processes cannot be accessed, a
another table, and so on. This information is then federated
change manager will not be able to predict whether taking
together so end users can perform a single query to search
that server offline will affect a business process.
across those multiple tables to find a match.
A virtual CMDB must also constantly manage the flow of
There is also a style of database federation that stores, for
data through multiple data sources. When a request is
example, columns a, b, c, and d in one store, and x, y, and z
made for CI data, the CMDB needs to determine where the
in another (segmenting by column instead of by row). This is
data is, access that data (possibly from multiple places), and
essentially the same idea behind the storage of additional CI
then represent that data across data sources in a common
data in the federated CMDB model. However, neither form
way. Because the data is stored in multiple locations, it be-
of database federation allows for the federation of related
comes a challenge to normalize the data so that the CMDB
data that is stored in different data stores, which may or may
represents it in a common way. Without normalizing the
not be a database.
data, it will be difficult to search on CIs and their attributes
within the CMDB because each element may be represented differently in different data stores.
Ultimately, there are definite conceptual similarities, especially between the column-style database federation and
Conclusion
a federated CMDB. However, a key difference between
database federation and CMDB federation is that a CMDB
Federation provides the means for building a CMDB envi-
supports the idea of additional data and extended data,
ronment that successfully can be managed within your IT
while the database federation concept does not.
environment. By understanding and distinguishing between
the different types of data that make up your CIs, you build
Virtual Data Stores
the foundation for defining your federated CMDB and the
The virtual approach to federation refers to the ability to store
data that should and should not be stored within it. The
data in many different locations without a copy in a central
federated approach creates a CMDB environment that is
repository. The term “virtual” is used because a virtual cen-
scalable and easier to maintain.
tral repository is formed across data sources (Figure 4).
The main drawback to a virtual data store, in relation to a
CMDB, is that organizations must rely on every data store
that makes up the virtual environment to be available at all
times in order to access a single view of CI data. When
PA G E > 7
About BMC Software
BMC Software helps IT organizations drive greater business value through better management of technology. Our industry-leading Business
Service Management solutions ensure that everything IT does is prioritized according to business impact, so IT can proactively address business
requirements to lower costs, drive revenue, and mitigate risk. BMC solutions share BMC Atrium™ technologies to enable IT to manage across
the complexity of diverse systems and processes — from mainframe to distributed, databases to applications, service to security. Founded in
1980, BMC Software has offices worldwide and fiscal 2005 revenues of more than $1.46 billion. BMC Software. Activate your business with the
power of IT. For more information, visit www.bmc.com.
BMC Software, the BMC Software logos and all other BMC Software product or service names are registered trademarks or trademarks of BMC Software, Inc.
All other registered trademarks or trademarks belong to their respective companies. ©2005 BMC Software, Inc. All rights reserved. 59249
PA G E > 8