CN101901242A

CN101901242A - 联合的配置数据管理

Info

Publication number: CN101901242A
Application number: CN2009102530868A
Authority: CN
Inventors: O·图布曼; B·科伦菲尔德; U·B·多尔; A·西蒂安
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 2008-10-30
Filing date: 2009-10-30
Publication date: 2010-12-01
Also published as: US20100115100A1; EP2182448A1

Abstract

本发明涉及联合的配置数据管理。公开了一种***，实现为对处理器进行程序设计，以及相应的方法，用于联合与网络对象的配置有关的数据搜索功能。所述***包括保存与网络对象有关的数据的外部数据存储器，配置管理数据库CMDB和耦合到所述CMDB和所述数据存储器的CMDB服务器。CMDB服务器包括识别网络对象的联合引擎及向外部数据存储器查询协调数据并创建在所述网络对象与联合的数据之间的关系的映射引擎。

Description

联合的配置数据管理

技术领域

本发明涉及联合的(federated)配置数据管理。

背景技术

当前的信息技术(IT)环境使用多种IT管理工具。通常，每一个这样的工具都具有相关联的其自己的数据存储器。在这种环境中，用户(人或机器)不具有获得散布在这些各种数据存储器中的数据的完整视图的能力。另外，用户不能看见聚合数据(aggregated data)，它会与在IT环境中执行的特定应用相关联。缺乏总体数据视图以及不能看见数据聚合产生了信息瓶颈以及用以组装完整且准确的数据视图的额外的开销(时间和金钱)，并导致常常根据不完整信息做出的决定。最后，在具有不可相关数据的这些当前IT环境中，管理者常常不能预期到基础结构变化的效果。

发明内容

公开了一种***，实现为对处理器进行程序设计，用于联合与网络对象的配置有关的数据搜索功能。***包括一个或多个外部数据存储器接口，其中，数据存储器包括与网络对象有关的数据；连接到CMDB的配置管理数据库(CMDB)适配器，及耦合到CMDB和数据存储器的CMDB服务器。CMDB服务器包括联合引擎，其包括用于识别网络对象的装置。CMDB服务器还包括耦合到联合引擎的映射引擎。映射引擎包括向外部数据存储器查询协调数据(reconciliation data)的装置以及创建在所述网络对象与联合的数据之间的关系的装置。

还公开了一种在处理器上实现的方法，用于联合与网络对象的配置有关的数据搜索功能。该方法包括以下步骤：从客户端接收拓扑查询语言(topologicalquery language，TQL)查询，所述查询包括一个或多个节点；识别将受到查询的网络对象；在配置管理数据库(CMDB)与一个或多个外部数据存储器之间协调所识别的网络对象；联合查询，包括将查询分为子查询，其中，查询中的每一个节点都转换为相关联的子查询；将子查询应用于协调的网络对象；及向客户端返回子查询的结果。

附图说明

详细描述将参考以下附图，其中，相似的数字指代相似的项目，其中：

图1显示了示例性的联合的配置数据管理***的所选择组件；

图2A-2C示出了用于创建联合的查询的示例性过程；

图3示出了图1的***的示例性操作；及

图4A-4I示出了图3的操作的细节和示例性工作流。

具体实施方式

任何大型现代化的组织都可以使用不同的***来产生、存储和搜索组织的关键性数据。***的、尤其是包括这些***的数据存储器的该多样性起因于许多因素，包括在组织的工作单位中缺乏配合、采用新技术的不同比率、组织的工作单位的合并、收购与地理分割。从这些各种***中组合信息使得组织更有效地利用数据存储器包含的数据。

考虑两个组织合并以构成新的组织的示例。新的组织继承了原始组织的数据存储器。这些数据存储器中的许多会在不同的关系数据库管理***的控制下工作。在合并后，新的组织要能够从两组数据存储器中访问客户信息，以便使用现有的和新的应用程序来分析其新的投资组合(portfolio)，并且通常是通过公共接口来使用两个组织的所组合的资源。即使可以在不同数据库中并以不同格式存储客户数据，新的组织也要能够识别公共的客户并合并他们的账户。另外，新的组织必须能够将遗留的数据与可从外部数据源获得的新数据(例如在互联网上的数据或来自其业务伙伴的数据)进行组合。使这些各种各样的数据源相集成造成了实质性的难题。

存在许多机制来对数据进行集成。这些包括专用解决方案、应用集成框架、工作流(或者业务过程集成)框架、具有入门型(portal-style)或元搜索引擎集成的数字图书馆、数据仓库和数据库联合(database federation)。

数据仓库和数据库联合为用户提供强大的高级查询语言，其可以用于组合、对比、分析以及用其它方式操纵其数据。用于优化查询的技术即使在非程序性地提出查询的情况下，也确保了有效地应答查询，极大地方便了应用开发。通过将数据从一个或多个数据源加载到关系数据库中的新定义的模式(schema)中来构建数据仓库。在加载过程中常常提炼(cleanse)并变换数据。在基础源中的变化可以导致加载过程的变化，但保护了进行数据分析的应用程序部分。新数据源可以在模式中引入变化，要求为新数据定义新的加载过程。SQL(结构化查询语言)视图可以进一步保护应用程序免于这种演变(evolution)。然而，不是关系数据库管理***的标准部分的数据源的任何功能都必须在仓库中再次实现或者再次实现为应用程序的一部分。

仅基于仓库建立(warehousing)的解决方案出于各种原因会是不可能的或者成本较高的。例如，将数据从其原始位置移动到数据仓库并不总是可行的，如上所述，仓库建立伴随着其自身的维护和实施成本。对传统数据仓库建立的改进是数据库联合。

数据库联合指的是一种架构，在其中，由数据库管理***组成的中间件提供对多个不同种类数据源的统一访问。对数据源进行联合；就是说，由数据库管理***将它们链接在一起成为统一的***，以创建联合的数据库。

在现有技术中，通常通过手动地执行与联合的数据库不同的应用程序来访问联合的数据。例如，联合的数据可以保存在第二数据库里中(可以通过单独的数据库管理***来访问)或者不同的产品(例如单独的配置管理应用程序)中。可以通过开发定制的源集成逻辑或通过调用第二应用程序的预定的或固定的实例来访问以此方式联合的数据。

在这些方法的第一个中，为每一个联合的数据库开发定制逻辑(即，软件)，其允许与特定数据存储器更自动化的交互。在第二个方法中，将第二应用程序用于手动地搜索所期望的数据。在第三个方法中，提供了到应用程序的链接，该应用程序可以操纵联合的数据对象的实例，但有可能不能够修改这个链接的调用(包括参数传送)。

本文公开的联合的配置数据管理***克服了当前联合的数据管理***的缺陷。该联合的配置数据管理***提供数据透明性，其意味着与用户屏蔽了基础数据源的差别、特性和实现方式。这个透明性允许如同全部数据都在单个数据库中一样来应用数据查询，尽管实际上，可以将数据存储在数据源的不同种类的集合中。在没有硬件、软件、数据模型、接口或协议的限制的情况下，联合的配置数据管理***还支持异质性(heterogeneity)，或者容纳宽范围的数据源的能力。联合的配置数据管理***还增加了可扩展性，或者动态地增加新数据源的能力，以便满足业务变化的需要，以及开放性，或者运行未改变的应用程序的能力：既不移动也不修改数据，并且接口保持相同。

因为联合的配置数据管理***为其用户屏蔽了需要获知是什么数据源、那些数据存储器运行在什么硬件和软件上、如何访问那些数据源(经由什么编程接口或语言)，甚至如何建模并管理存储在那些数据存储器中的数据，单个查询可以访问来自多个数据源的数据，按需要连接(join)及限制、聚合和分析数据。此外，数据存储器可以根本不是数据库***，作为代替，例如，可以是从传感器到平面文件到应用程序到XML(可扩展标记语言)的源。

以下的描述涉及联合的配置数据管理***的特定实现，尤其涉及IT***配置管理***，包括使用拓扑查询语言来访问外部数据源，及配置管理数据库(CMDB)，其中至少存储了到外部数据源的链路。然而，本领域技术人员会意识到，联合的数据库管理***可以用于除配置管理之外的许多其他目的。

配置管理是负责保留包括它们的关系在内的与传递IT服务所需的配置项有关的信息的过程。配置管理的主要目的是在需要它的时间和地点，通过向所有IT服务管理过程提供准确的数据来加强IT服务的传递的基础。

配置管理在配置项(CI)的生命周期中从始至终管理与配置项有关的信息。CI是需要管理的任何组件，以便传递IT服务。CI通常包括硬件、软件、建筑物、人和正式文件，例如过程文件和SLA。将与每一个CI有关的信息记录在配置管理数据库(CMDB)内的配置记录中。配置记录是包含配置项的细节的记录。每一个配置记录文件都为单个CI的生命周期提供文件。

CMDB是用于在与配置记录相关联的CI的生命周期中从始至终管理配置记录的数据库。CMDB记录每一个CI的属性及与其他CI的关系。CMDB还可以包含链接到CI的其他信息，例如事件、问题或变化记录。CMDB由配置管理来维护并由所有IT服务管理过程使用。

CMDB通常仅存储CI的关键信息。连接到配置管理数据库的客户端常常需要使用CI数据，除了存储在CMDB中的数据之外该CI数据被存储在单独的数据存储器中。为了呈现从本地CMDB以及一个或多个远程数据存储器采集(pull)的CI数据的无缝视图，CMDB需要提供联合特征。

联合特征使客户端能够在无需获知数据的实际位置的情况下，使用CMDB应用编程接口(API)向多个数据源请求配置项数据。联合特征搜索多个在地理上和技术上不同的IT***，以便从多个单独的数据源定位相关数据并进行变换。CMDB透明地组合来自多个数据源的数据，并将组合的数据返回给客户端。

然而，为了给CMDB的客户端呈现无缝的数据存在几个困难。首先，用于单个CI的数据可以位于两个或多个联合的数据源中。另外，联合的数据源可以为两个或多个CI提供属性。由于在数据源类型、数据存储器访问机制和数据模式中的差别，CMDB从两个或多个数据源检索信息会存在困难。CMDB还会难以获知每一个数据源中存储了哪一个配置项和属性。

另外，两个或多个联合的数据存储器可以为CI的相同属性提供数据。例如，在联网的计算机***中，可以由在一个数据存储器中的名称(例如，HP R1)和在另一个数据存储器中的互联网地址(例如，128.00.00.1)来指代路由器。在这种情况下，由于确定应优先给出哪一个属性数据的实例，CMDB会难以组合属性数据。换句话说，CMDB会不能确定对于给定属性数据可以依赖于哪一个数据源。在由每一个数据源为给定属性提供的数据在任何方面都不同的情况下，这会是严重的问题。因此，本文描述的用于联合的配置数据管理的***必须能够将这两个身份(identity)识别并协调为属于单个硬件设备，即路由器。

为了提供对在这些各种数据存储器中的CI的增强的访问，以下描述一种示例性的联合的配置数据管理***及相应方法，该***具体的是一种联合通用CMDB(uCMDB)***。

在描述这个示例性的联合uCMDB***中，将使用以下术语：

数据存储器是任何数据存储***，包括CMDB，或者其他数据库，外部CI和关系位于其中。

外部CI是配置项，其不是源于uCMDB***。就是说，外部CI是定义在uCMDB类(class)模型中的一个类，其特定实例存储在外部存储器中，而不是uCMDB中。

拓扑指代在对象之间的拓扑状态(即，关系或链接)。对象还可以具有非拓扑状态；就是说，随着时间的属性和行为。拓扑中的关系本质上是严格的二进制的(binary)。就是说，每一个关系都确切地链接两个拓扑管理的对象。通过将关系自身表示为拓扑管理的对象来对程度(degree)n的关系进行建模，直至构建了二进制模型来描述程度n的关系。使用这个方法，可以聚合是较大资源的一部分的各个对象。聚合的对象假定了包括该聚合的对象的各个对象的拓扑状态。

拓扑查询语言(TQL)指的是面向对象的框架，用于描述应用程序和业务服务，并包括物理的和逻辑的对象、其属性及其彼此的关系。TQL实现了图形视图的创建，其设计为捕获在IT服务、应用程序与基础结构组上的项(包括CI)的有关的相关性(即关系)。联合的TQL(FTQL)是在其定义中包括外部CI的TQL。

图1示出了示例性的联合uCMDB***100，其结合了以上定义的元件和特征。包括***100的组件可以作为硬件、软件、固件或硬件、软件和固件的组合而存在。

***100包括uCMDB服务器200，其借助外部数据存储器适配器120耦合到外部数据存储器110，并通过适配器242耦合到uCMDB 240，其存储配置数据。外部数据存储器110可以是任何数据存储设备，包括外部CMDB。可以以JAVA程序设计语言来开发外部数据存储器适配器120。可替换的，可以使用普通OOB适配器，仅仅改变适配器的XML配置。

同样耦合到uCMDB服务器200的是客户端150。客户端150可以是任何计算设备，例如包括，PC或服务器。客户端150发出TQL查询140并作为应答接收TQL结果130。

uCMDB服务器200从外部数据存储器110接收CI方式的输入。uCMDB服务器200从客户端150接收TQL查询140，并将查询140的结果130提供回到客户端150。如所示的，TQL结果130包括外部CI 125。

uCMDB服务器200包括数据提供方(provider)接口210(其与外部数据存储器110通信，并通过相关联的外部数据存储器适配器120从外部数据存储器110接收CI)，以及联合引擎220和映射引擎230。

联合引擎220通常使用识别规则来识别网络对象并驱动协调过程。在一个实施例中，将识别规则组织为识别组，每一条规则都指定了在确定匹配时应考虑何种属性，待匹配的对象类型及规则所用于的发现源或数据集。识别组可以包含任何数量的规则，另外，可以进行排序，以便以给定顺序处理组中的各个规则。联合引擎220还包括协调引擎(未示出)，用于通过使用识别规则来协调在外部存储器110和uCMDB 240中所识别的网络组件的身份。

如图1所示，***100在几个数据存储器110上执行联合活动。***100及相关联的方法(例如见图3)能够在无需任何数据复制的情况下，使来自uCMDB 240的配置数据与来自外部数据存储器110的数据相关。就是说，使用联合的查询来实时执行数据联合。为了允许数据检索，为每一个外部数据存储器110提供数据存储器适配器120。数据存储器适配器120提供相关联的数据存储器的指定能力，并从数据存储器110检索所需数据。通过数据存储器110的适配器240做出对该数据存储器的每一个请求(FTQL查询140)。

联合TQL查询使用联合引擎220和映射引擎230来创建在不同外部存储器CI与uCMDB CI之间的适当的外部关系。在协调了uCMDB CI与外部CI之后执行映射。

图2A-2C呈现了在uCMDB 240与外部存储器110之间的示例性的联合查询。在该示例中，uCMDB 240将特定网络组件(服务器)识别为主机(host)1和主机2；服务中心(外部数据存储器)110将网络组件识别为服务器11和服务器12。服务中心110还为服务器存储许可证信息(ticket information)。因此，uCMDB 240保存借助自动发现而发现的CI，服务中心110管理与由uCMDB 240保存的CI有关的许可证信息。在图2A-2C中所示的示例中的联合目的在于将许可证与uCMDB CI相关联。服务中心的适配器(未示出)将外部类模型转换为新的类模型(“事件(incident)”)，并提供新的链接“包含_事件(contains_incident)”和在主机与扩充类“事件”之间的链接。另外，联合引擎220协调主机与事件。参考图2A，将FTQL查询300(链接主机与事件的查询)从客户端130提供给映射引擎230，以产生映射310。映射310将uCMDB 240的主机和服务中心110的服务器相关联。就是说，主机1映射到服务器11，主机2映射到服务器12。FTQL查询300的结果是联合的TQL结果305，其显示了在主机与事件之间的相关性。以下的工作流示出了上述实时的联合：

映射引擎230将FTQL查询300分为至少两个子查询，其中在子查询中的所有节点都涉及相同的数据存储器。将每一个子查询通过虚拟关系连接到其他子查询。见图2B，其中，将原始FTQL查询300分为两个子查询(分割FTQL307)，主机和事件。

在将FTQL查询300分为子查询307之后，uCMDB服务器200计算每一个子查询拓扑，并通过在子查询的适当节点之间创建虚拟关系来连接两个适当的子查询。见图2C，其中，分割了图2A的原始FTQL查询300，结果产生uCMDB子查询311和服务中心子查询313。借助这两个子查询311和313，uCMDB服务器200计算产生的FTQL拓扑结果315。因此，主机1与服务器11相关联，主机2与服务器12相关联，其中，在uCMDB 240中定义主机，在服务中心(外部数据存储器)110中定义服务器。事件14与服务器11相关联，事件16与服务器12相关联，其中，在服务中心110中定义事件。因此，主机1映射到事件14，主机2映射到事件16，将在uCMDB 240中的对象映射到服务中心110中的对象。

图3是序列图，其示出了图1的uCMDB***100的示例性操作400。图3中所示的***100的组件包括客户端150、联合引擎220、映射引擎230、uCMDB数据库240和外部数据存储器适配器120。图4A-4I示出了由操作400创建并使用的各种对象。操作400在步骤401处开始，此时客户端150通过接口250向uCMDB服务器200提出FTQL查询140。将FTQL查询140传送到联合引擎220，其分析(步骤402)查询，以确定数据请求的式样(pattern)。在分析了式样后，联合引擎220识别在主机与事件之间的虚拟关系，并将这个关系提供给映射引擎230。映射引擎230将FTQL 140分为两个子查询：uCMDB子查询141和服务中心子查询143(见图4A和4B)。

返回到图3，在步骤403处，联合引擎220在uCMDB 240上运行TQL子查询(即，图4B的uCMDB子查询141)，并接收外部拓扑结果145，如图4C所示。

返回到图3，在步骤404处，联合引擎220将拓扑结果145传送到映射引擎230，映射引擎230向联合引擎220返回图4D中所示的适当的数据搜索式样(srcTQL)161。搜索式样161包含连接(关联)从两个单独的数据存储器接收的数据所需的信息。注意，式样161包括用于数据存储器的主机名称和地址。

返回到图3，在步骤405处，联合引擎220在uCMDB 240上运行TQL映射请求，并作为应答接收外部拓扑结果。在图3的步骤406处。联合引擎220向映射引擎230提供拓扑结果，并作为应答接收TQL子查询搜索式样163(见图4E)，以便在外部数据源110上运行。在步骤407处，将TQL子查询搜索式样提供给适配器120，其返回用于外部数据存储器110的外部拓扑结果165，如图4F所示。

在图3的步骤408处，联合引擎220连接来自外部存储器110的子查询搜索式样与trgTQL 165，并将这个连接提供给映射引擎230，其返回原始FTQL的拓扑结果167，如图4G所示。原始FTQL的拓扑结果在适配器120上运行，在图4H中显示了结果。接下来，在图3中的步骤409处，联合引擎220在子查询中的对象之间创建虚拟链接，并将这些链接连同结果所需的布局(layout)一起提供(步骤410)给uCMDB 240。最后，在步骤411处，将所需的链接和布局提供给适配器120，将结果返回给联合引擎220。图4I显示了在uCMDB 240和数据存储器110上运行了分割的FTQL查询之后组合的FTQL查询的结果173。在步骤412处，由映射引擎230通过接口250将原始FTQL查询的结果提供给客户端130。

各种公开的实施例可以实现为方法、***和/或装置。作为一个示例，将示例性实施例实现为一个或多个计算机软件程序，以实施本文所述的方法。软件实现为一个或多个模块(也称为编码子例程，或者面向对象程序设计中的“对象”)。对于不同可替换的实施例，软件的位置不同。例如，软件程序设计代码由计算机或服务器的一个处理器或多个处理器从一些类型的长期存储介质中访问，该长期存储介质例如半导体、磁性和光学设备，包括可移动盘或硬盘驱动器。代码可以分布在这种介质上，或者可以从一个计算机***的内存或存储器通过到其他计算机***的一些类型的网络而分发给网络操作员，用于由操作员使用这些其他***。可替换地，将程序设计代码包含在内存中(例如手持便携式电子设备的内存中)，由处理器使用总线来访问。用于将软件程序设计代码包含在内存中、物理介质上和/或经由网络分发软件代码的技术和方法是公知的，本文将不再进一步论述。

本文所用的词语和描述仅作为示例性方式来提出，并不意图作为限制。本领域技术人员会认识到，如在随后的权利要求中定义的本发明的精神和范围及其等价物内的许多改变都是可能的，其中，所有词语都以其最宽泛的可能的意义来理解，除非另有指明。

Claims

1.一种***，实现为对处理器进行程序设计以便联合与网络对象的配置有关的数据搜索功能，包括：

一个或多个外部数据存储器适配器，用于访问包括与网络对象有关的数据的数据存储器；

配置管理数据库(CMDB)适配器，用于访问CMDB；

CMDB服务器，耦合到所述CMDB和所述数据存储器，其中，所述CMDB服务器包括：

联合引擎，包括用于识别所述网络对象的装置，及

映射引擎，耦合到所述联合引擎，包括用于查询所述外部数据存储器的装置，及

用于创建在所述网络对象与联合的数据之间的关系的装置。

2.如权利要求1所述的***，还包括客户端接口，用于将客户端连接到所述CMDB服务器。

3.如权利要求1所述的***，其中，由虚拟关系来连接子查询。

4.如权利要求1所述的***，其中，规则集包括所述网络对象的名称。

5.如权利要求1所述的***，其中，规则集包括所述网络对象的功能。

6.如权利要求1所述的***，其中，所述网络对象是硬件设备，包括服务器、路由器、交换机和内存设备。

7.如权利要求1所述的***，其中，所述网络对象是软件和固件中的一个，包括操作***和应用程序。

8.一种在处理器上实现的方法，用于联合与网络对象的配置有关的数据搜索功能，包括：

从客户端接收拓扑查询语言(TQL)查询，所述查询包括一个或多个节点；

识别将受到查询的网络对象；

在配置管理数据库(CMDB)与一个或多个外部数据存储器之间协调所识别的网络对象；

联合查询，包括将查询分为子查询，其中，查询中的每一个节点都转换为相关联的子查询；

将所述子查询应用于协调的网络对象；及

向所述客户端返回所述子查询的结果。

9.如权利要求8所述的方法，其中，所述网络对象是硬件资源。

10.如权利要求8所述的方法，其中，所述网络对象是软件资源。

11.如权利要求8所述的方法，其中，协调所识别的网络对象包括将规则集应用于所述识别的网络对象，其中，所述规则集包括对象名称和对象功能。