Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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