配置管理数据库

配置管理数据库(configuration management database)简称CMDB,是信息技术基础架构库(ITIL)用语,是组织用来储存软件硬件资产(常称为形态项目,CI)资讯的数据库。配置管理数据库可以将形态项目拆解到对应的逻辑层[1]。数据库类似组织的资料仓储,也会记录各资产之间关系的资讯[2]。CMDB提供方式可以了解组织的关键资产以及彼此之间的关系,例如信息系统、upstream来源以及资产之间的相依性、以及资产的downstream目标[3]

目的及益处

配置管理数据库(CMDB)是信息技术基础架构库框架的配置管理英语Configuration Management (ITSM)中的基础概念。可以用CMDB来追踪资产(例如产品、系统、软件、设备、人员)的状态,例如这些资产在特定的时间点是否存在,以及各资产之间的关系。配置管理数据库可以帮助组织了解各元件之间的关系,并且追踪其配置情形。此资讯的维护会允许在任意时间进行特定的动作(例如重建资产)。CMDB也可以用在影响分析英语impact evaluation根本原因分析以及变更管理英语Change management (ITSM)

CMDB的实现一般需要“联合”(Federation),即从其它数据源(如资产管理系统),获取数据并纳入CMDB中,期间数据的控制权仍然在数据源。联合和ETL(资料来源端经过抽取、转置、载入至目的端)解决方案不同,ETL方案会将资料复制进CMDB内。

配置管理数据库可以用在许多的事物上:例如企业智能,软件建立及硬件建立,投资[4]、变更影响分析[5]事故管理

信息技术基础架构库的环境下,使用CMDB是基础服务运作及支援的一部分。CMDB表示IT环境中重要组件的授权配置情形。

内容

配置管理数据库中会记录一些资讯,这些资讯也称为配置项目(CI),其中也会提供配置项目的重要属性以及彼此之间的关系。

配置项目属性及资料

CMDB所记录的属性会依配置项目分类而不同,可能会多达数百个,以下是一些例子:

  • 配置项目唯一识别码英语Unique identifier或识别码
  • 配置项目名称或标示(多半是包括完整名称以及短名称)
  • 配置项目缩写
  • 配置项目叙述
  • 配置项目所有者(组织及人员)
  • 配置项目重要性

属性是用元数据所定义,CMDB也会包括元数据,因此其概念也会和元数据的存储库(一般用来让IT组织运作更有效率)重叠。配置管理会着重如何让资料维持在最近的状态,这以往是元数据存储库的弱点。

配置项目之间的关系

配置项目之间的关系至少会由一个目的配置项目,以及一个相关的来源配置项目所组成。若在更进阶的关系中(例如本体构成要素),会希望有来源配置项目和目的配置项目之间的描述符(descriptor),可以提供一些相关资讯。,例如,“数据库”的关系是“应用程序Y”的成员,描述符也称为是谓词(Predicate)。

配置项目类型

配置项目类型(CI类型,configuration item type)是针对组织希望储存在CMDB的元件或是形态项目资料类型。至少所有的软件、硬件、网络以及储存设备的配置项目类型都要存在CMDB里,并且进行追踪。若企业成熟的话,会开始在CMDB中追踪商业的配置项目类型,例如人员、市场、产品及第三方实体(例如供应商及合作厂商)。这可以让配置项目之间的关系更有意义,CMDB也可以变成知识管理更强力的来源。

CI类型有:

要实现CMDB的关键要素是可以自动发现有关CI的资讯(auto-discovery),并且在其变化时追踪其变化。

逻辑表示

CMDB逻辑结构,也称为是数据库纲要,会以许多型式出现。最常见的二种是关系资料模型语意资料模型英语semantic data model

关系模型是以一阶述词逻辑为基础,所有资料都以三元组表示,而三元组会依关系分组。在关系模型中,相关的纪录会用键(key)相连结,键针对某项目的资料型态定义是唯一的。这种关系模型会有用于指定数据和查询的声明性方法。换句话说,使用者可以直接列出哪一个数据库中有资讯,哪一个数据库需要这些资讯,让数据库系统说明储存资料的资料结库,以及回复请求的提取过程。

语意资料模型英语semantic data model一般会需要资源描述框架,用关系叙述子来映射许多事物之间的关系,可以提供这些事物之间相关性的资讯。

挑战

在创建及维护配置管理数据库时,会有以下的三个挑战:

  • 相关性:需要在配置项目或是纪录的生命周期当中搜集其资料。这代表需要加入流程及工具,在资料出现时搜集其最即时的变化。
  • 维护:企业会持续的变化,有关配置项目的资料以及彼此之间的关系也会持续变化。维护是很重大的工作,常常没有规划到或是预期到。多半企业后来才发现这是最大的挑战。
  • 可用性:许多的配置管理数据库只有数据库功能,没有复杂应用程序的功能、特征或优点,也没复杂的可视化工具来浏览资料,也没有进阶探索的工具。这代表大部分公司需要开发或购置包覆CMDB的应用层。不过,实现这些机能(例如确保数据库是最新的,或是可以和系统互动,执行指令、加入更新、或布置应用程序)可以扩展配置管理数据库的机能以及其可用性。

因为上面这些理由,公司多半会购买配置管理数据库,不太会自行设计、建立、交付及维护配置管理数据库。

联合配置管理数据库

信息技术管理人员可以使用联合的CMDB(联合配置管理数据库)——一个企业级的CMDB——来积累配置、变更和其它离散来源的数据的信息[6]。目标是使用业界标准的接口,使得管理数据的提供者能够把它们的数据集成到紧密结合的、无缝的CMDB中。[7]

该标准的架构于2007年由几家CMDB的供应商的一本白皮书中提出,其中有:ASG Software Solutions、BM软件公司、CA公司富士通惠普公司软件部门、IBM微软[7]。这些成员组成了CMDB联合工作组(CMDBf)。

2009年,分布式管理任务组英语Distributed Management Task Force标准化了CMDBf的规范,提供了跨供应商、标准化的系统管理数据联合的解决方案。[8]

参考文献

  1. ^ Configuration items layers. [2021-03-01]. (原始内容存档于2021-01-24). 
  2. ^ What is CMDB (configuration management database)?. TechTarget. July 2017 [2019-01-14]. (原始内容存档于2021-01-28). 
  3. ^ IT: disconnected from the business? . Axios Systems. 2015-11-10 [2019-01-14]. (原始内容存档于2019-12-06). 
  4. ^ Whitepaper: Ansible in Depth . Ansible. [2019-01-14]. (原始内容存档于2020-11-24). There are many points of integration that can be used to extend Ansible, including: (...) inventory data retrieved from CMDB systems or cloud sources. 
  5. ^ Sauvé, Jacques; Rebouças, Rodrigo; Moura, Antão; Bartolini, Claudio; Boulmakoul, Abdel; Trastour, David. Business-Driven Decision Support for Change Management: Planning and Scheduling of Changes. Springer Berlin Heidelberg. 2006: 173–184. ISBN 978-3-540-47662-7. doi:10.1007/11907466_15. 
  6. ^ TechWorld.com. “The federated CMDB vision.". [2012-07-18]. (原始内容存档于2013-09-28). 
  7. ^ 7.0 7.1 The Federated CMDB Vision white paper. 互联网档案馆存档,存档日期2012-07-11.
  8. ^ Configuration Management Database (CMDB) Federation Specification (PDF). [2012-07-18]. (原始内容存档 (PDF)于2018-08-20). 

外部链接

参见