运维：CMDB好用和用好，差别还是挺大的！

配置管理数据库( Configuration Management Database,CMDB)是一个逻辑数据库，包含了配置项全生命周期的信息以及配置项之间的关系(包括物理关系、实时通信关系、非实时通信关系和依赖关系)。

CMDB存储与管理企业IT架构中设备的各种配置信息，它与所有服务支持和服务交付流程都紧密相连，支持这些流程的运转、发挥配置信息的价值，同时依赖于相关流程保证数据的准确性。

1 背景

随着企业的业务量不断增长，运维所要纳管的网络设备、物理服务器、应用服务器等基础设施都会相应的增加，此时我们需要面对以下几个问题:

• 如何管理基础设施的整个生命周期
• 如何记录基础设施的SN、管理IP、业务IP、维保等信息
• 如何做到虚拟机和物理机的差异性管理
• 如何做到管理IP和业务IP的一致性管理
• 如何关联业务IP和应用服务

这些问题由于不影响业务的正常运行，因此常常被我们所忽略；但是如果管理不得当，在后续的资产盘点、业务扩容等工作中都会让我们头痛不已，为之前工作上的疏忽懊恼不已。

此时我们会不由自主的产生以下几个疑问:

• 我们物理机、虚拟机各有多少？
• 我们的资产都用在哪里了？
• 现在还有没有空闲资产？

与其让问题找到我们，不如我们主动去解决问题，这就是我们运维的一贯作风！

我的理解是，CMDB 在运维体系中承担管理基础设施，为上层应用场景提供可靠的数据支撑的角色。CMDB虽然能够将基础设施进行统一纳管，并且可以和业务应用进行关联，在一定程度上是利好运维的，但"CMDB成为摆设、花瓶"的现象还是存在的。

因此，CMDB好用和用好，差别还是挺大的。

下面我们将结合蓝鲸CMDB从好用和用好的角度来深入了解下。

2 蓝鲸CMDB

为了更好的了解本文，我们先来了解下蓝鲸CMDB。

蓝鲸配置平台（蓝鲸CMDB）是一个基于运维场景设计的企业配置管理服务。主要功能：

1. 拓扑化的主机管理：主机基础属性、主机快照数据、主机归属关系管理；
2. 组织架构管理：可扩展的基于业务的组织架构管理；
3. 模型管理：既能管理业务、集群、主机等内置模型，也能自定义模型；
4. 进程管理：基于模块的主机进程管理；
5. 事件注册与推送：提供基于回调方式的事件注册与推送；
6. 通用权限管理：灵活的基于用户组的权限管理；
7. 操作审计：用户操作行为的审计与回溯；

2.1 实验环境

2.2 好用

1 模型管理

CMDB中的模型是对同类配置实例进行标准格式的定义，例如主机有不同的配置记录：

• 服务器类型
• 管理IP
• 购买日期
• 质保期限
• 固资编号
• 服务器品牌
• 服务器型号
• 机柜
• 机房
• 等等

此时我们可以定义主机模型，以保证相关配置录入CMDB的时候必须包含所需信息。另外，除了属性列表以外，模型还能够定义其他相关字段等。

另外，除了主机模型外，我们还可以按需创建其他模型并对其进行分组:

• 组织架构，如业务
• 业务拓扑，如模型、集群
• 网络，如交换机、路由器、负载均衡、防火墙
• 数据库，如MySQL、Oracle

2.3 业务拓扑

业务拓扑是配置平台进行主机管理的基础，只有建立合适的业务模型，才能结构化的管理好主机。CMDB配置平台提供用户结构自定义、拓扑属性自定义等功能。

通过业务拓扑，我们可以按集群、模块将业务进一步划分，以便将服务器与业务应用进行关联，清晰的了解业务下主机数量。

2.4 多条件筛选

对于已经纳管的服务器，我们可以按不同需求进行多条件筛选，条件可以根据主机相关字段进行，例如：

• 按模块筛选
• 按管理IP筛选
• 按服务器类型筛选
• 按其他字段筛选

通过筛选可以快速解决我们的需求，如：

• 生产环境服务器数量共有多少
• 物理机、虚拟机各是多少
• x.x.x.x 的管理IP
• x.x.x.x 属于哪个业务应用
• x.x.x.x 服务器哪一年购买的，是否维保过期

2.5 权限分离

对应于运维岗位可能进一步划分为基础运维和应用运维的，其中：

• 基础运维，主要负责网络设备、物理机、存储等基础设施；
• 应用运维，主要负责应用服务器、业务应用与业务相关的资源；

由于基础运维和系统运维主要区分在于是否和业务相关，CMDB可以帮助我们进行权限隔离，即:

• 系统权限：可管理所有模型的查询、编辑、删除等
• 业务权限：分角色管理业务下所有集群、模型、主机编辑和转移等

通过权限隔离，我们可以更好的根据岗位进行权限划分，各司其职、各尽其责。

2.6 小结

通过通用的功能，CMDB满足了我们约80%的基础设施管理需求，“好用”可以说是实至名归。但剩余的20%是我们的痛点，CMDB能不能进一步满足我们呢？那么这就需要我们将CMDB用好，来满足我们20%的痛点需求。

3 用好

3.1 服务器上架痛点

背景

由于运维的岗位进一步划分为基础运维和应用运维，针对服务器上架场景基础运维和应用运维的工作如下：

基础运维：

1.新服务器上架；

2.CMDB维录入新服务器的资产信息，如管理IP、品牌、型号、维保等信息；

应用运维：

1.CMDB将服务器转移到相关业务、应用下；

2.在监控平台、堡垒机中添加相关主机信息；

此时可能大家觉得没毛病啊，但是我们忽略了CMDB的主机管理是以业务IP为主键的，这就意味着基础运维在新服务器上架时必须确定服务器的业务IP，否则无法导入CMDB，但业务IP的确定是滞后的，由应用运维确定，此刻我们的上架流程就出现了问题。

3.2 解决方案

分析痛点导致资产无法导入CMDB的原因为业务IP和管理IP同时存在于主机模型中，因此我们需要将他们分别隶属于不同模型。由于业务IP肯定属于主机模型了，因此我们新增并扩充了以下三个模型，并且专门由基础运维管理:

• 机房，主要是机房位置
• 机柜，主要是机位信息
• 物理机，主要是管理IP、品牌、型号、维保等信息

其中我们将硬件服务器的主要字段都放到物理机这个模型中，而主机模型虽然包含了物理机和虚拟机，但是只有业务IP，而不包含管理IP及其他字段信息。

此时大家可能会有一个问题：物理机的业务IP如何与管理IP进行关联，以应对物理机故障的风险？因此我们需要对CMDB进一步深入探索：关联管理。

通过关联管理，我们可以做到：

• 将物理机与机柜、机房进行关联
• 将主机（主要是带有业务IP的物理机）关联到物理机模型，而虚拟机无需关联

通过关联关系，我们可以清晰看到物理机的业务IP、管理IP及机柜、机房信息。

通过新增物理机、机柜、机房模型以及关联关系，在权限隔离的基础上，我们实现了：

• 基础运维与业务运维的操作分离
• 基础运维管理物理机、机房、机柜之间的关系
• 应用运维管理虚拟机、物理机与业务之间的关系

权限隔离、操作分离正好解决了我们服务器上架的痛点。

3.3 CMDB打通堡垒机与监控平台

前面提到的“CMDB为上层应用场景提供可靠的数据支撑”，虽然我们实现了业务与主机的关联，但是CMDB与运维平台的隔离成了我们运维自己的一个痛点。在给业务做好服务的同时，我们也不能亏待了自己啊。

因此我们需要通过“事件注册与推送：提供基于回调方式的事件注册与推送；”实现CMDB打通堡垒机与监控平台，实现：

• CMDB与堡垒机联动，保证堡垒机资产分组与CMDB一致；
• CMDB与监控平台联动，保证监控平台的主机分组和CMDB一致；

我们的目的是保证CMDB数据的权威性，这样做才能够避免"CMDB成为摆设、花瓶"。

CMDB提供的事件推送可以对接第三方系统，因此我们可以自行开发系统来与其对接，完成CMDB打通堡垒机与监控平台的最后一步。