更高难度：云时代下的CMDB

前言

最近在社区屡次看到CMDB的分享，大可能是在探讨CMDB如何建设（How）的问题，虽然如何建设的问题很是重要，但在当今人人谈云的云化时代下，究竟该创建一个什么样（What）的CMDB更为重要。

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

1. 本人相对于传统行业更为熟悉

2. 传统企业的运维理念和组织架构设定和互联网不一样，进而致使了运维工具架构、选择、以及IT标准化策略等方面的不一样

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是我现阶段设定的一个目标，将来也但愿经过开源的方式实现的一个项目。

CMDB建设常见问题

回顾十几年的CMDB建设，你们广泛的反映是CMDB建设很困难，下面我有必要分析一下当前CMDB建设遇到的一些常见问题。

1. 缺少合理化、总体化的规划

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

• 在大而全? 仍是小而深? 方面犹豫不决：
  这种决策机制在项目初期每每耗费了大量时间，但随着新技术的不断涌现，这种方式已经没法适应愈来愈敏捷的IT环境，咱们发现一种相对静态的CMDB模型已经不能知足纳管新IT组件的要求。

  如何解决？

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

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

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

  如何解决？

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

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

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

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

  如何解决？

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

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

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

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

  如何解决？

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

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

这实际上是CMDB在企业落地所面临的最大挑战，没法充分调动运维人员的积极性，主要体如今：

• 初始数据收集工做量大：
  存量的配置数据每每基数很大，通常配置的量级在5000以上，考虑到云化环境的海量运维场景，这个基数还会更大。

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

  如何解决？

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

• 单一的自动化配置发现工具只是一种幻想：
  如前所说，约从2007年开始，业内引入了自动发现工具用以解决配置数据的初始化问题，但因为这类工具每每由某个厂商提供，致使了配置发现的局限性，企业每每也要付出较大成本。

  如何解决？

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

• 投产后因为变动频繁，数据没法保证及时准确：
  以往企业通常采用变动操做驱动配置修改（人工修改、或自动化发现修改）的方式以确保配置数据的准确性，这种方式每每出现了配置信息的不一致。

  如何解决？

  创建基于配置基线驱动的IT环境变动（操做）架构，即创建经过配置修改事件触发变动操做的事件响应模型。
  对于将来软件定义环境，这种架构是一种必然选择。

• 如何让人人“乐于”参与：
  这里的参与主要体如今二个方面：
  1）须要使用与本身相关的配置数据时，CMDB能够当即提供；
  2）遇到CMDB没法提供的数据时，IT部门可自行在必定标准和约束下扩展知足本部门运维CMDB模型，支撑部门级的运维场景。

  如何解决？

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

4. 配置数据的价值没法呈现

• 缺少清晰的场景定义，包括流程价值、监控价值、BSM价值、云价值等：
  单一流程驱动CMDB的场景，没法让CMDB中的数据流动起来，随着时间的推移CMDB中的数据就逐渐腐败—不及时也不许确。

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

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

  如何解决？

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

• 缺少有效、明确的配置数据集成策略：
  如前所述，CMDB是一个逻辑上的数据库，其中的数据须要和企业现有IT环境中的多类数据源进行整合，一套行之有效的数据集成策略和ETL（数据抽取、转换、转载）工具也必不可少。

  如何解决？

  创建数据集成策略，引入ETL。

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

云化时代的特色以及带来的挑战

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

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

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

云化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 + 场景

云化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月份开源第一个版本。

今天就分享这些内容，请你们多多指教！谢谢你们！还有一些具体细节，今天因为时间的缘由就不展开了，欢迎具体探讨。

精彩互动

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：

1. 创建场景驱动理念，确保配置数据有人去使用；

2. 经过技术手段提高配置数据的自动化率，确保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