Abstract:
Disclosed are methods and systems to provide coordinated identification of data items across a plurality of distributed data storage repositories (datastores). In one disclosed embodiment, a single configuration management database (CMDB) controls identification rights for all CIs as they are first identified in a master/slave relationship with all other CMDBs in the distributed environment. In a second embodiment, a plurality of CMDBs divide identification rights based upon coordination identification rules where certain CMDBs are assigned authoritative identification rights for CIs matching the rules of a particular CMDB in the distributed environment. In a third embodiment, one or more of the plurality of CMDBs may also have advisory identification rights for CIs which do not already have an identifiable unique identity and can coordinate with an authoritative CMDB to establish an identity for CIs.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application pertains to subject matter that is related to the subject matter described in commonly owned U.S. patent application Ser. No. 11/204,189 filed on 15 Aug. 2005 entitled “A System and Method for Resource Reconciliation in an Enterprise System” by Richard Mayfield et al., which is hereby incorporated by reference in its entirety. 
     
    
     BACKGROUND 
       [0002]    This disclosure relates generally to the field of distributed datastores and a cooperative identification methodology for physical and logical items which may have an associated information record in more than one of the distributed repositories. Because an item might have properties distributed across datastores, a unique identifier could help programmers and users of the distributed datastore coordinate maintenance of the data associated with the item. In the context of this disclosure, the item will be referred to as a Configuration Item or (CI) as used in the context of a system enterprise management system. However, this is only for clarity of explanation and not intended to limit the scope of this disclosure to only CIs and CMDBs (explained below). Any type of distributed datastore could benefit from concepts disclosed herein. 
         [0003]    In one embodiment, this disclosure relates to coordinated identification of Configuration Items (CIs) across a plurality of distributed datastores known as Configuration Management Databases (CMDBs). CMDBs are ITIL®-based (Information Technology Infrastructure Library) datastores. (ITIL is a registered trademark of The Lords Commissioners of Her Majesty&#39;s Treasury acting through The Office of Government Commerce and Central Computer and Telecommunications Agency, United Kingdom.) One example of a distributed datastore is a collection of distributed (and also possibly federated) CMDBs. ITIL-based CMDBs are emerging as a prominent technology for Enterprise Management Software. 
         [0004]    The usefulness of distributed datastores, in particular distributed CMDBs, is dependent on the quality, reliability and security of the data stored in them. A CMDB often contains data about managed resources known as Configuration Items (CIs). ITIL version 3 defines a CI as: “Any Component that needs to be managed in order to deliver an IT Service. Information about each CI is recorded in a Configuration Record within the Configuration Management System and is maintained throughout its Lifecycle by Configuration Management. CIs are under the control of Change Management. CIs typically include IT Services, hardware, software, buildings, people, and formal documentation such as Process documentation and [Service Level Agreements].” Each of these groups of CIs is also typically broken down into specific “classes” of CIs. Typical classes include, but are not limited to, Computer, Hardware, Network, Software, and Location (e.g., physical such as a room, logical such as a domain, or geographical such as a city). Each of these classes can be further broken down into subclasses or other groupings (e.g., based on implementation specifics). For example, the Computer class may be divided into the following four distinct groups: laptop computer, desktop computer, server computer, and mainframe. 
         [0005]    The CMDB serves as a point of integration between various IT management processes. For a variety of reasons there may be more than one CMDB present in a customer environment (i.e., distributed CMDBs). Also, data from multiple sources often needs to be managed directly or by reference in commercial CMDBs. Thus, there was a need to create a standard for federating the data from various CMDBs into a single view that appears seamless and integrated to the end user. This standard, known as the CMDB Federation, or CMDBf, Standard was recently adopted by the Distributed Management Task Force (DMTF) as Document Number DSP0252. 
         [0006]    Some of the goals of CMDBf include: enabling a variety of data consumers to access a federation of management data through a standard access interface; enabling a variety of data providers to participate in a federation of management data through a standard provider interface; and providing an approach for reconciling and combining different information about the same resources. 
         [0007]    Because a given instance of an item (e.g., CI) being tracked via a distributed datastore may exist in a plurality of datastore storage repositories (datastores) a coordinated identification system for the item across the plurality of datastores would be desirable. In an enterprise management situation, a CI may be available across a plurality of CMDBs. Accordingly, a coordinated and authoritative identification of CIs amongst a group of CMDBs operating together would be beneficial. This disclosure presents solutions for this and other related problems. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0008]      FIG. 1  illustrates, in block diagram form, an example of a plurality of datastores, with different identification authority, communicatively coupled to each other. 
           [0009]      FIG. 2  illustrates a flow chart depicting application of logical rules to determine an identification authority for a new item (e.g., CI) according to at least one disclosed embodiment. 
           [0010]      FIG. 3  illustrates a flow chart depicting an embodiment of an identification process for a newly discovered CI where only one datastore has identification rights of any kind (e.g., master and slave). 
           [0011]      FIG. 4  illustrates a flow chart depicting an embodiment of an identification process for a newly discovered CI in datastore B (where datastore B is the authoritative identification entity) even though datastore A may have already had the same CI defined. 
           [0012]      FIG. 5  illustrates a flow chart depicting an embodiment of an identification process for a newly discovered CI comprising an advisory identification entity (datastore B) working in conjunction with an authoritative identification entity (datastore A). 
           [0013]      FIG. 6  illustrates, in block diagram form, an example computing device comprising a program control device. 
       
    
    
     DETAILED DESCRIPTION 
       [0014]    Today it is not uncommon for all configuration items (CIs) to be stored in a single centralized CMDB. However, it is also possible (and over time may become more likely) to have more than one CMDB present in a single customer environment. For example, in a cloud management product there could be two CMDBs. A first CMDB acting as the cloud data store (Cloud CMDB) and the other acting as the centralized enterprise CMDB (Enterprise CMDB). Because both of these CMDBs are in the same customer environment there is a need for coordinated identification of CIs within the customer environment. For ease of understanding, this disclosure is described in the context of two or three CMDB type datastores working together; however, it will be apparent to those of ordinary skill in the art having the benefit of this disclosure that any number of datastores, and not necessarily CMDB type datastores, could benefit from the concepts of this disclosure. 
         [0015]    Evolving from a single monolithic CMDB to a truly distributed CMDB environment involves a number of challenges. One of the challenges is to make sure a given CI is defined with the same identity in all the CMDBs that interact with each other. For example, a CI such as a laptop with hostname XYZ could be present in more than one CMDB. Within a given CMDB each CI is assigned a unique identity and that identity is generally used by applications to interact with the CI. Thus, in a distributed CMDB there could exist a need to ensure any given CI (such as the laptop mentioned above) is given the same identity in each of the CMDB instances. Doing so could be beneficial for various computer system applications by increasing the application&#39;s ability to work seamlessly across any CMDB instance in a distributed CMDB scenario. 
         [0016]    In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the inventive concept. As part of this description, some structures and devices may be shown in block diagram form in order to avoid obscuring the invention. Moreover, the language used in this disclosure has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, reference to the claims being necessary to determine such inventive subject matter. Reference in the specification to “one embodiment” or to “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention, and multiple references to “one embodiment” or “an embodiment” should not be understood as necessarily all referring to the same embodiment. 
         [0017]    It will be appreciated that in the development of any actual implementation (as in any development project), numerous decisions must be made to achieve the developers&#39; specific goals (e.g., compliance with system- and business-related constraints), and that these goals will vary from one implementation to another. It will also be appreciated that such development efforts might be complex and time-consuming, but would nevertheless be a routine undertaking for those of ordinary skill in the information technology support system field having the benefit of this disclosure. 
         [0018]    Referring now to  FIG. 1 , block diagram  100  illustrates a distributed datastore environment comprising three (3) datastores communicatively coupled to each other. The first datastore  110  is named “datastore A” and the second datastore  120  is named “datastore B” as used in the following example embodiments. The third datastore  130  “datastore C” represents another datastore to illustrate that identification authority can be divided in a variety of ways across any number of datastores in a distributed datastore environment. Also, each datastore (e.g., CMDB) may or may not have federated data repositories (not shown) on one or more computer systems throughout the enterprise. 
         [0019]    Referring now to  FIG. 2 , flow chart  200  describes three possible scenarios for creating a unique identifier for a new item (e.g., CI) in the context of a distributed datastore. The three possible scenarios described in this example include 1) no identification rights, 2) “advisory” identification rights (where a datastore can suggest a unique identifier but that suggestion must be accepted by an authority), and 3) authoritative (i.e., absolute) identification rights. Beginning at block  210  a new item is discovered (or defined by a datastore user) and appears for the first time at a datastore. The datastore can then apply rules to the item to determine if identification authority exists for the current datastore (block  220 ). As a result of applying these rules, it could be determined (block  230 ) if this datastore has: no identification rights for this type of item (proceed to block  250 ); advisory identification rights for this type of item (proceed to block  270 ); or authoritative identification rights for this type of item (proceed to block  240 ). If no identification authority exists (block  250 ) rules may optionally be applied again to determine which datastore has the authority and the item could be sent (block  260 ) to that authoritative datastore for identification (e.g., process  300  of  FIG. 3 ). Alternatively, if advisory authority exists (block  270 ) rules could also be applied to determine authoritative datastore for identification and the item could be sent (block  280 ) to that authoritative datastore with a suggested identification for the item as described in process  500  of  FIG. 5 . Finally, if authoritative authority exists in this datastore (block  240 ) an identification process could be invoked and coordination with other datastores could proceed, either now or in the future, in a manner such as described in process  400  of  FIG. 4 . 
         [0020]    Referring now to  FIG. 3 , flow chart  300  describes one embodiment where a first datastore (“datastore B”) has no identification rights whatsoever (i.e., it is a slave of another datastore (“datastore A”) with authoritative identification rights). Beginning at block  310 , datastore B discovers a new CI and because datastore B has no identification rights the identity is not yet populated. At block  320 , information about the new CI is sent to datastore A. Next, at block  330  datastore A determines if this particular CI is already known to datastore A. If so, the YES prong of block  330 , flow continues to block  350  to determine if this particular CI has already been assigned a unique identifier. If so, the YES prong of block  350 , flow continues to block  360  where the identity of the CI can be populated with the already existing unique identifier. Alternatively, the NO prong of block  350 , flow can continue to block  370  where a new identity is created in datastore A because, in this example, datastore A has authoritative identification rights. Next, at block  380 , the identity of the CI can be populated with the authoritative, and now current, identity from datastore A. After all of blocks  340 ,  360  and  380 , flow continues to block  390  where the updated CI (with an authoritative identity) is sent back to datastore B. At the end of this process both datastore A and datastore B are consistent in their use of the authoritative identity supplied by datastore A (block  395 ). 
         [0021]    Referring now to  FIG. 4 , flow chart  400  describes another embodiment where datastore B has authoritative identification rights for any CI (i.e., datastore B is authoritative identification datastore relative to any other datastore). Beginning at block  410 , datastore B discovers and creates a new CI. Block  410  also indicates that datastore B populates the identity of the new CI. Next, at block  420  the new CI is sent to datastore A with the authoritative identity already populated. At block  430 , datastore A determines if the new CI is already defined in datastore A. If not, the NO prong of decision  430 , flow continues to block  440  where datastore A accepts the CI and its authoritative identifier from datastore B. However, if the CI is already present in datastore A, the YES prong of decision  430 , flow continues to decision  450  where it is determined if the CI already has a unique identification in datastore A. If so, the YES prong of decision  450 , flow continues to block  455  where the identity of the CI in datastore A is overwritten because the previous unique identity was not (or is no longer) an authoritative identity. It should be recognized that when a unique identity is overwritten, all references to that unique identifier in a datastore should be updated. Also, other processes may need to be invoked to correct all other external references to the previous unique identifier throughout the enterprise. However, if a unique identity was not present for the CI, the NO prong of decision  450 , flow continues to block  460  where the identity is accepted from datastore B in datastore A and other updates may be avoided. Finally, at block  470 , all datastores have the identical authoritative identity for the CI. 
         [0022]    In general, a case where two datastores already have defined unique identification that is not authoritative could happen. For example, when two or more datastores are already running in an environment prior to setting up a cooperative identification scheme for the distributed datastore environment. However, after the authoritative identity is defined it should remain persistent unless another authoritative identification scheme is established. 
         [0023]    Referring now to  FIG. 5 , flow chart  500  describes another embodiment where datastore B has advisory identification rights for a particular CI (i.e., datastore B is advisory for a certain grouping of CIs and datastore A has authoritative identification rights for the same group of CIs). Beginning at block  510 , datastore B creates a CI and populates its identity with suggested values. At block  520 , the new CI is sent to datastore A with a suggested unique identifier. At block  530 , it is determined if this CI is already present in datastore A. If not, the NO prong of decision  530 , flow continues to block  540  where a CI is created in datastore A. If so, the YES prong of decision  530 , it is determined (at decision  560 ) if the CI already has a unique identifier defined in datastore A. If the CI does not already have a unique identifier, either because it was not previously defined (NO prong of decision  530 ) or because it was defined but did not already have a unique identifier (NO prong of decision  560 ), flow continues to block  550  where the suggested identifier from datastore B could be accepted and become the authoritative unique identification for the CI (block  595 ). Alternatively, if the CI is defined and does have a unique identifier already (the YES prong of decision  560 ), flow continues to block  570  where the suggested identifier is ignored and to block  580  where an updated CI is sent back to datastore B so that datastore B can update itself with the correct authoritative identification for the CI (block  590 ). Finally, all datastores have knowledge of the authoritative identifier from datastore A&#39;s perspective and are consistent (block  595 ). 
         [0024]    As explained here, certain datastores, such as CMDBs, can share the responsibility for performing unique identification for CIs that are new to them. CIs can be new to a CMDB because they are automatically discovered or manually defined by a system administrator (or a combination of both). New CIs should be named consistently across the enterprise to facilitate IT support applications like those used in Business Service Management (BSM). Also, responsibility may be divided amongst the different CIs using a number of techniques. For example, a CMDB may have identification rights for a certain class of CIs, such as all computers. Alternatively, the CMDB could have identification rights for all laptop computers whose hostname begins in the range [a-g]. Basically, any defined set of rules regarding which CMDBs have authoritative, advisory, or no identification responsibility could be used. Different implementation strategies may be better for different types of distributed CMDB environments. In one embodiment, these rules will designate one and only one CMDB to match with authoritative identification rights for applicable CIs when they are discovered. 
         [0025]    Referring now to  FIG. 6 , example computing device  600  is shown. One or more example computing devices  600  may be included in a mainframe or distributed computer (neither shown). Example computing device  600  comprises a programmable control device  610  which may be optionally connected to input devices  660  (e.g., keyboard, mouse, touch screen, etc.), display  670  and/or program storage device (PSD)  680  (sometimes referred to as a direct access storage device DASD). Also, included with program control device  610  is network interface  640  for communication via a network with other computing and corporate infrastructure devices (not shown). Note, network interface  640  may be included within programmable control device  610  or be external to programmable control device  610 . In either case, programmable control device  610  may be communicatively coupled to network interface  640 . Also note, program storage device  680  represents any form of non-volatile storage including, but not limited to, all forms of optical and magnetic storage elements including solid-state storage. 
         [0026]    Program control device  610  may be included in a computing device and be programmed to perform methods in accordance with this disclosure. Program control device  610  may itself comprise processor unit (PU)  620 , input-output (I/O) interface  650  and memory  630 . Processing unit  620  may include any programmable control device including, for example, processors of an IBM mainframe (such as a quad-core z10 mainframe microprocessor). Alternatively, in non-mainframe systems examples of processing unit  620  include the Intel Core®, Pentium® and Celeron® processor families from Intel and the Cortex and ARM processor families from ARM. (INTEL CORE, PENTIUM and CELERON are registered trademarks of the Intel Corporation. CORTEX is a registered trademark of the ARM Limited Corporation. ARM is a registered trademark of the ARM Limited Company.) Memory  630  may include one or more memory modules and comprise random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), programmable read-write memory, and solid state memory. One of ordinary skill in the art will also recognize that PU  620  may also include some internal memory including, for example, cache memory. 
         [0027]    Aspects of the embodiments are described as a method of control or manipulation of data, and may be implemented in one or a combination of hardware, firmware, and software. Embodiments may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by at least one processor to perform the operations described herein. A machine-readable medium may include any mechanism for tangibly embodying information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium (sometimes referred to as a program storage device or a computer readable medium) may include read-only memory (ROM), random-access memory (RAM), magnetic disc storage media, optical storage media, flash-memory devices, electrical, optical, and others. 
         [0028]    In the above detailed description, various features are occasionally grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments of the subject matter require more features than are expressly recited in each claim. 
         [0029]    Various changes in the details of the illustrated operational methods are possible without departing from the scope of the following claims. For instance, illustrative flow chart steps or process steps of  FIGS. 2-5  may be performed in an order different from that disclosed here. Alternatively, some embodiments may combine the activities described herein as being separate steps. Similarly, one or more of the described steps may be omitted, depending upon the specific operational environment the method is being implemented in. In addition, acts in accordance with  FIGS. 2-5  may be performed by a programmable control device executing instructions organized into one or more program modules. A programmable control device may be a single computer processor, a special purpose processor (e.g., a digital signal processor, “DSP”), a plurality of processors coupled by a communications link or a custom designed state machine. Custom designed state machines may be embodied in a hardware device such as an integrated circuit including, but not limited to, application specific integrated circuits (“ASICs”) or field programmable gate array (“FPGAs”). 
         [0030]    It is to be understood that the above description is intended to be illustrative, and not restrictive. For example, the above-described embodiments may be used in combination with each other. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.”