原文地址:http://024mj.blog.51cto.com/10252785/1767521

1. 前言

最近在社区多次看到 CMDB 的分享,大多是在探讨 CMDB 如何建设(How)的问题,虽然如何建设的问题非常重要,但在当今人人谈云的云化时代下,究竟该建立一个什么样(What)的 CMDB 更为重要。

首先要说明的是,今天在这里的分享都建立在传统企业存量环境中,暂时不考虑互联网企业。这种假设的考虑主要基于两个方面:

  • 本人相对于传统行业更为熟悉
  • 传统企业的运维理念和组织架构设定和互联网不同,进而导致了运维工具架构、选择、以及 IT 标准化策略等方面的不同

2.CMDB 发展史

我先简要回顾一下十几年来 CMDB 的建设历程。

2004 年

我从 04 年开始参与国内某银行的 CMDB 建设,这时 CMDB 的典型场景是资产信息的电子化。配置信息的采集主要采用 Excel 导入的方式,CMDB 模型需要提前预设,不具备动态扩展能力,暂且称之为 CMDB1.0。

2006 年

到了 06 年,我在某银行主导实施了国内第一个基于 BMC Atrium CMDB 架构的 CMDB 项目,这时的 CMDB 开始侧重于与其他 ITSM (IT Service Management,IT 服务管理 ) 流程的协同以及故障、变更影响分析等诊断场景。

但由于配置数据的初始化工作仍然需要手工 Excel 导入,同时配置信息的更新也不及时(无法在一个变更窗口内更新完成),导致上层场景没有发挥作用。这个阶段我们称之为 CMDB2.0。

2007 年

从 07 年开始,配置自动化发现工具的引入,帮助企业极大简化了配置数据初始化工作。

2008 年

紧接着,08 年左右业界提出变更闭环的概念,即在变更结束后重新进行配置自动发现并更新配置信息。相比 CMDB2.0 阶段,配置信息更新实时性有一定程度提高。

2012 年

12 年一些银行开始尝试通过配置自动发现工具实现配置比对场景,尤其是灾备与生产环境配置比对,以及集群环境内任意两节点间的配置比对。

近几年

应该说,配置自动发现工具一定程度上降低了配置数据初始化和维护的难度,但限于配置自动发现工具的技术局限,发现时间往往较长,发现的信息也存在一定盲区, 同时还需使用 root 等管理员账号,这些约束一定程度上影响了自动发现工具的实际使用效果。这个阶段我们称之为 CMDB3.0。

云化 CMDB 时代

随着云计算在 10 年国内的兴起,大约在 12 年后逐步在大型企业内部落地。落地过程中,我们发现云化资源的管理是一件比 CMDB 管理更为棘手的事情。

为此我们帮助国内一些银行实施了云化资源管理平台,除了管理以往 CMDB 中常见的物理配置外,进一步丰富了 LPAR、端口、HBA 卡、LV、VG 等逻辑配置。这个阶段我暂且称之为云化 CMDB1.0。

从 CMDB 在国内发展的历程看,随着客户对于 CMDB 认知不断深化,CMDB 的场景已经从传统的资产台账管理逐步演化到流程协同管理、影响分析、配置比对、云化资源管理等方面,但在 CMDB 的技术架构上,无论是开源产品还是商业化产品都没有一个明显的改进,发展比较缓慢。这在一定程度上也影响了 CMDB 场景的拓展。

为了便于大家有更为直观的认识,我整理了下表罗列了不同阶段 CMDB 的特点

需要说明的是,云化 CMDB2.0 是我现阶段设定的一个目标,未来也希望通过开源的方式实现的一个项目。

3.CMDB 建设常见问题

回顾十几年的 CMDB 建设,大家普遍的反映是 CMDB 建设很困难,下面我有必要分析一下当前 CMDB 建设遇到的一些常见问题。

3.1. 缺乏合理化、整体化的规划

需求不清晰,定义了不合理的配置广度和深度。

在大而全? 还是小而深? 方面犹豫不决:

这种决策机制在项目初期往往耗费了大量时间,但随着新技术的不断涌现,这种方式已经无法适应越来越敏捷的 IT 环境,我们发现一种相对静态的 CMDB 模型已经不能满足纳管新 IT 组件的要求。

如何解决?

用一种更为灵活的 CMDB 模型扩展机制。

采用了不正确的管控策略:

按照经典 ITIL 的管控和项目实施机制,配置管理规划,尤其是 CMDB 模型的规划往往由项目组承担,一旦规划完成后整个模型也就变得很难再进行扩展,应该说这里采用的是一种集中管控的策略。

但在实际 IT 运维工作中,我们发现对于 CMDB 使用最多的是各个二线团队,不同团队之间对于 CMDB 深度和广度的要求,以及管控方式都有较大差别。

如何解决?

基于集中分布式的理念建立 CMDB 管控体系

3.2. 配置管理人员职责定义不清晰

配置经理、配置管理员、配置 Owner 之间职责不清晰:

按照 ITIL 或 ISO20000 中对于这三类角色的定义往往过于宽泛,没有进一步考虑实际运维人员的运维场景,以及使用的运维工具,导致职责定义和实际做事方式脱节。

如何解决?

结合运维场景、运维工具、流程角色职责,对于各角色的职责进行重定义。

角色职责和岗位的对应不明晰:

在没有 ITIL 以前,在企业 IT 部门或数据中心往往找到不到一个现成岗位对于 IT 配置信息进行集中管理,而是每个人各管一摊。

实施 ITIL 后,究竟由哪个部门的哪个岗位承担配置经理这一职责往往是最让人伤脑筋的,最后往往是赶鸭子上架。这种角色定义方式最终导致体系无法运转。

如何解决?

基于集中分布式的理念设定角色和岗位的对应关系

3.3. 配置管理成了 IT 运维的负担

这其实是 CMDB 在企业落地所面临的最大挑战,无法充分调动运维人员的积极性,主要体现在:

初始数据收集工作量大:

存量的配置数据往往基数很大,一般配置的量级在 5000 以上,考虑到云化环境的海量运维场景,这个基数还会更大。

随着分布式应用架构以及微服务架构的兴起,未来一套新应用系统上线引入新的配置项数量也无法简单通过手工输入的方式来完成。

如何解决?

借助自动化手段进行数据采集

单一的自动化配置发现工具只是一种幻想:

如前所说,约从 2007 年开始,业内引入了自动发现工具用以解决配置数据的初始化问题,但由于这类工具往往由某个厂商提供,导致了配置发现的局限性,企业往往也要付出较大成本。

如何解决?

建立适配多类自动化工具的 CMDB 架构,将企业现有的脚本、监控工具、自动化工具、云平台都转化为配置数据的提供方。

投产后由于变更频繁,数据无法保证及时准确:

以往企业一般采用变更操作驱动配置修改(人工修改、或自动化发现修改)的方式以确保配置数据的准确性,这种方式往往出现了配置信息的不一致。

如何解决?

建立基于配置基线驱动的 IT 环境变更(操作)架构,即建立通过配置修改事件触发变更操作的事件响应模型。对于未来软件定义环境,这种架构是一种必然选择。

如何让人人“乐于”参与:

这里的参与主要体现在二个方面:

1)需要使用与自己相关的配置数据时,CMDB 可以立即提供;

2)遇到 CMDB 无法提供的数据时,IT 部门可自行在一定标准和约束下扩展满足本部门运维 CMDB 模型,支撑部门级的运维场景。

如何解决?

建立小、快、灵的 CMDB 架构,支撑快速扩展、快速纳管、快速交付数据。

3.4. 配置数据的价值无法呈现

缺乏清晰的场景定义,包括流程价值、监控价值、BSM 价值、云价值等:

单一流程驱动 CMDB 的场景,无法让 CMDB 中的数据流动起来,随着时间的推移 CMDB 中的数据就逐渐腐败―不及时也不准确。

同时,CMDB 在技术上作为一个“数据库”,要让其中的数据能够流动起来,必须明确与之匹配的运维场景。

场景是用来描述与 CMDB 中某些配置项交互的一组活动,满足 IT 部门某一方面的运维管理目标,这一目标可以被度量、跟踪、改进、可视化,与此同时,CMDB 的价值也随之呈现。

如何解决?

建立基于场景驱动的 CMDB 解决方案集合;

缺乏有效、明确的配置数据集成策略:

如前所述,CMDB 是一个逻辑上的数据库,其中的数据需要和企业现有 IT 环境中的多类数据源进行整合,一套行之有效的数据集成策略和 ETL(数据抽取、转换、转载)工具也必不可少。

如何解决?

建立数据集成策略,引入 ETL。

通过以上分析,我们回顾了 CMDB 的历史发展过程,以及建设过程中遇到的挑战。接下来我们看看云化环境下 CMDB 又将面临什么新问题。

4. 云化时代的特点以及带来的挑战

应该说动态变化是云化环境下最大的挑战,无论对于配置模型还是配置数据的更新都提出了全新要求。我们势必不能再参考现有 CMDB 产品架构去定义或满足云化 CMDB 的要求。

对于互联网或互联网业务而言,海量会是一个比较大的问题,这里的关键可能不是海量存储的问题,而是如何在海量配置信息中快速配置定位、查找和可视化。

对于传统企业而言,异构永远是首要解决的问题,针对这个特点,以往厂商提出过联邦的技术,但一直没有找到可行的落地方法。这里我尝试借助类似于 ETL 的机制,实现多数据源的整合。

5. 云化 CMDB 应具备的典型特征和范式

下面我们进入今天讨论的第三部分:云化 CMDB 应具备的典型特征和范式

在云化时代,CMDB 需要从原有的单一工具转变为一种企业 IT 服务能力,即 CMDB As A Service(以下为了便于叙述,使用云化 CMDB 代替)。

云化 CMDB:是指 CMDB 消费者可以通过网络随时随地获取、维护、管理 CMDB。

服务要素

如 IaaS 中服务要素是指 IT 基础架构,在云化中的服务要素包括三个层面:

1. 配置模型:用以描述 CMDB 的深度和广度,在技术上体现为一组配置标签(如服务器、网络、应用等,或生产环境、测试环境等)、与配置标签相关联的配置对象、以及用于描述配置对象的属性集合。

配置模型是用以描述配置项的元数据,其描述了某一配置项应该具备的属性,以及该配置项与其他配置项之间的逻辑关系,以及与配置项相关的一组操作。

2. 配置项:用以描述某一配置对象的具体实例。如对于 Server 这个配置对象,其具体的 IT 环境中可能表现为 IBM Server01,IBM Server02,IBM Server03 等服务器实例。

3. 配置项的关联操作:这个层面是对 ITIL 的补充。操作用来描述某个配置项在实际特定的 IT 环境中允许进行的一组行为集合。

举例来说,对于 IBM Server01 配置项来说,可能有的操作包括启动、停止;对于比较复杂的应用系统 APP 01 来说,可能有的操作就包括启动、停止、重启、配置等。

如果说配置项属性是对配置项的静态描述,那么配置项操作就是对配置项的动态描述,其描述了消费者可以对当前配置项施加的动作。

上述服务要素并不能单独存在,这就像数据库管理系统中的数据一样,在没有被业务系统使用前,都只是一堆 0 和 1 组成的数据,必须放到某个特定的上下文中才具备其特定的含义。

这里说的业务系统其实说的就是场景。配置场景描述 CMDB 与某个具体运维活动或业务活动之间的关系,在一个场景中可能同时触发一组关联操作。

在没有 JDBC 或 ODBC 标准接口前,存放在数据库管理系统中的数据只能通过特定的数据库管理平台才能进行增、删、查、改操作,这种方式严重制约了数据库中的数据对外提供服务和消费,给业务系统的开发带来了极大的不便利性。

同理,在 CMDB As A Service 理念中,我们也需要通过把服务要素 API 化,将 CMDB 的服务能力真正暴露出去,以便于场景进行调用。

CMDB API 与服务要素一一对应,包括三个层次:

1. 配置模型的增、删、查、改(类似于 DML);

2. 配置数据的增、删、查、改;配置项关系建立、移除(类似于 DDL);

3. 配置操作的增、删、查、改;并建立配置操作与特定的 IT 运维自动化工具的关联(包括脚本、专业自动化运维工具、云平台、监控平台等等);

注:其实 Puppet、Chef 在架构上已经采取了类似的理念,这里我们希望再往上抽象一个层次

通过上述要素的组合,我给出云化 CMDB 的定义:

云化 CMDB=模型 + 操作 + 数据 + API + 场景

6. 云化 CMDB 的基本架构

下面我们进入今天分享的最后一部分内容:云化 CMDB 的基本架构。

整个云化 CMDB 平台自下而上分为四个层次,分别是:

1. 系统管理层:该层为系统的使用提供了最基本的支持,包括组织、人员、角色、权限的管理。支持定义各类角色和权限的管理,有完整的角色管理和权限管理功能,权限配置支持组嵌套。并通过与外部 IT 管理云平台集成实现用户的统一认证功能

2. CMDB 服务要素层:按照云化 CMDB 的理念,服务要素包括模型、数据和操作,与之对应的分别是模型维护、配置项维护和操作维护功能。

3. API 层:通过封装底层 CMDB 服务要素层的功能要素,对外提供模型管理 API、配置项管理 API 和操作 API

4. 场景层:场景层采用了一种可扩展的方式进行设计,CMDB ETL 和配置可视化是 CMDB 的两个基本场景:

场景一:其中 CMDB ETL 主要实现对于多外部配置数据源的数据抽取、转化和处理,并将处理的结果通过 API 层的配置项 API 进行数据录入,并记录配置数据的变化,建立配置基线,并围绕基线形成基线比对等功能;

场景二:配置可视化主要针对配置数据提供一种展示(图形、声音、文字等)手段,包括配置拓扑展现(以图形化方式展现配置项间的关联关系)、配置项多维度查询、配置报表以及预警功能。

除了基本场景外,开发人员可以通过 API 层的功能,并结合基本场景实现自定义场景,比如在本次项目中实现架构标准配置比对功能就是一种基于配置比对功能基础上的新场景应用。

除了以上层次,平台提供了 CMDB 管理门户的 GUI 界面,便于系统管理员和配置管理相关用户对于模型、配置项进行维护、查询。
目前已经参考上述架构启动开源云化 CMDB 项目,并实现了模型动态扩展,模型/配置数据 API、配置基线、配置比对、ETL 和可视化场景,预计 7 月份开源第一个版本。

今天就分享这些内容,请大家多多指教!谢谢大家!还有一些具体细节,今天由于时间的原因就不展开了,欢迎具体探讨。

7. 精彩互动

Q1:云平台下运维与传统运维的最大差异包括哪个方面?从而导致运维平台进入一个新的发展时期。

A:云化环境下最大的挑战是配置信息的动态变化,以往在配置手工更新往往需要几个小时甚至几天时间,等更新后其实 CMDB 中已经是脏数据了。

Q2:海量配置对比的实现原理和准确性程度如何?

A:基本思路是将数据库记录级比对(传统 CMDB 技术实现)转变为文本级比对。比对过程中可以识别新增、修改、删除属性、配置项等信息。

Q3:如果已经有一个偏资产管理流程数据的 cmdb 了,那么想用这个云化 cmdb 思路落地是不是只能重构了?

A:是。

Q4:配置主动发现这个最重要。怎么去区分逻辑属性,物理属性,动态属性,静态属性,关联配置项目,怎么与资产关联?

A:应该说配置主动发现采用的是一种轮询查找机制,我希望在新的云化 CMDB 中采用的思路是配置事件驱动的模式进行配置更新。

比如在 IaaS 中,我们要申请一台 VM,在申请的过程中已经收集了 VM 相关信息,以及安装的数据库、中间件实例等配置信息,从这个例子中我们发现变更-配置更新是一体的,也就不需要配置自动发现工具。

当然在实际环境中,我们要两者结合。配置自动发现工具也不局限于特定的如 ADDM、TADDM 这类工具,可以扩展到监控、脚本等工具。

Q5:cmdb etl 如何解释?我知道 etl 但和 cmdb 一起完全没有概念,请解释,谢谢!

A: CMDB 从本质来说就是一个数据库,我们要解决的是如何允许多个外部数据源同时录入配置数据,那么数据源之间会出现冲突,这就需要一个合理的技术去解决。

ETL 其实在数仓里应用多年,我们完全可以借鉴过来加以利用。这个方案在三个大行已经得到了应用。当时我们用的是 Kettl。

Q6: 怎么区分模型还是场景?

A:模型其实简单说就是数据库的表结构,场景其实就是使用数据库的应用程序。

Q7: 我觉得 cmdb 到后面就是个 aws 的 json 格式的 api 接口,殊途同归,不晓得老师怎么看?

A:这个问题比较有意思,从接口的发展趋势看,类似于 RestFul 的 API 目前已经是事实标准,在云化 CMDB 中所有 API 也将通过这种方式提供。

Q8:例如不管是阿里云还是 aws,所有的运维活动都是围绕资源天然集成,似乎已经失去了传统环境下配置驱动流程的意义了?

A:这个是个好问题。一个非常有意思的是无论是 AWS、还是 Openstack 都没有集中存放配置的管理组件。
前不久,AWS 发布了 AWSConfig,这个组件其实就是负责 AWS 上所有配置信息的集中管理,并已经和 20 多个软件厂商实现了整合,同时我们 Netflix 上也看到了类似的项目。

所以,答案已经比较明显了,配置管理的这类需求还很普遍。

Q9:在云环境下,资源都是服务,运维服务和资源服务天然的联动集成,我个人感觉云环境下 cmdb 的功能更多是一个 ci 全景的可视查询,还有其他场景吗?

A:可视查询是从配置消费角度看到的一个典型场景,从配置提供的角度看,由于云化环境涉及了计算、网络、存储虚拟化,以及大量自动化运维工具,因此比较复杂的是配置数据提供场景。例如,如何在一个 VM 的交付过程中,实时的更新配置信息。

Q10:cmdb 在建设初期怎么发挥价值?或者说,如何在运维工作中发挥更大作用,而不只是一个电子台帐?

A:建立场景驱动理念,确保配置数据有人去使用;通过技术手段提升配置数据的自动化率,确保 CI 项中的属性绝大多数都能被某种自动化工具覆盖。

Q11:请问下 CMDB 里的数据准确性是怎么保证的?

A:非云化环境,一般通过事后审计的方式,识别有问题的配置项,然后进行手工修正。

云化环境,由于环境都是软件定义的,基础架构的变更和配置更新是同时发生的,理论上来说 CMDB 中的数据是云化环境的快照。今天分享的内容主要侧重在云化环境。

Q12: 逻辑关联信息,可以定义吗?如何进行关联关系的维护?

A:这个问题涉及模型定义问题。如果你有 Puppet 和 Chef 的经验,我们就可以看到这种关系的定义。关系是一种特殊的 CI 属性,在设计时,必须确保可以通过自动化工具提供数据。

在实际项目中,我们会形成上面的两个表格。

Q13:如何将 cmdb1.0 和 2.0 合并在一起实现?自动发现配置方面有没有成型的解决方案?

A:上面只是处于表述的原因,将 CMDB 分为 1.0 和 2.0,从实现角度看是可以同时考虑的。自动发现配置方面常见的商业方案有 BMC ADDM 和 IBM TADDM,开源的暂时没有找到类似的解决方案,一般功能都比较散。

Q14: 老师, 你好. 能讲讲你们 Apache kylin 主要拿来做什么吗?

A:可参考 http://www.oschina.net/p/kylin-olap