运维:CMDB好用和用好,差别还是挺大的!
CMDB 在运维体系中承担管理基础设施,为上层应用场景提供可靠的数据支撑的角色。CMDB虽然能够将基础设施进行统一纳管,并且可以和业务应用进行关联,在一定程度上是利好运维的,但"CMDB成为摆设、花瓶"的现象还是存在的。...
背景
随着企业的业务量不断增长,运维所要纳管的网络设备、物理服务器、应用服务器等基础设施都会相应的增加,此时我们需要面对以下几个问题:
- 如何管理基础设施的整个生命周期
- 如何记录基础设施的SN、管理IP、业务IP、维保等信息
- 如何做到虚拟机和物理机的差异性管理
- 如何做到管理IP和业务IP的一致性管理
- 如何关联业务IP和应用服务
这些问题由于不影响业务的正常运行,因此常常被我们所忽略;但是如果管理不得当,在后续的资产盘点、业务扩容等工作中都会让我们头痛不已,为之前工作上的疏忽懊恼不已。
此时我们会不由自主的产生以下几个疑问:
- 我们物理机、虚拟机各有多少?
- 我们的资产都用在哪里了?
- 现在还有没有空闲资产?
与其让问题找到我们,不如我们主动去解决问题,这就是我们运维的一贯作风!
配置管理数据库( Configuration Management Database,CMDB)是一个逻辑数据库,包含了配置项全生命周期的信息以及配置项之间的关系(包括物理关系、实时通信关系、非实时通信关系和依赖关系)。
CMDB存储与管理企业IT架构中设备的各种配置信息,它与所有服务支持和服务交付流程都紧密相联,支持这些流程的运转、发挥配置信息的价值,同时依赖于相关流程保证数据的准确性。
我的理解是,CMDB 在运维体系中承担管理基础设施,为上层应用场景提供可靠的数据支撑的角色。CMDB虽然能够将基础设施进行统一纳管,并且可以和业务应用进行关联,在一定程度上是利好运维的,但"CMDB成为摆设、花瓶"的现象还是存在的。
因此,CMDB好用和用好,差别还是挺大的。
下面我们将结合蓝鲸CMDB从好用和用好的角度来深入了解下。
蓝鲸CMDB
为了更好的了解本文,我们先来了解下蓝鲸CMDB。
蓝鲸配置平台(蓝鲸CMDB)是一个基于运维场景设计的企业配置管理服务。主要功能:
- 拓扑化的主机管理:主机基础属性、主机快照数据、主机归属关系管理;
- 组织架构管理:可扩展的基于业务的组织架构管理;
- 模型管理:既能管理业务、集群、主机等内置模型,也能自定义模型;
- 进程管理:基于模块的主机进程管理;
- 事件注册与推送:提供基于回调方式的事件注册与推送;
- 通用权限管理:灵活的基于用户组的权限管理;
- 操作审计:用户操作行为的审计与回溯;
实验环境
业务 | 集群 | 模块 | 主机 | 服务器类型 | 管理IP | 购买日期 |
---|---|---|---|---|---|---|
test1 | cluster2 | app1 | 192.169.5.120 | 物理机 | 172.16.5.120 | 2022-04-18 |
test1 | cluster2 | app2 | 192.169.5.121 | 虚拟机 | 172.16.5.121 | 2022-04-18 |
test1 | cluster1 | app3 | 192.169.5.122 | 虚拟机 | 172.16.5.122 | 2022-04-18 |
test2 | X | X | X | X | X | X |
好用
1.模型管理
CMDB中的模型是对同类配置实例进行标准格式的定义,例如主机有不同的配置记录:
- 服务器类型
- 管理IP
- 购买日期
- 质保期限
- 固资编号
- 服务器品牌
- 服务器型号
- 机柜
- 机房
- 等等
此时我们可以定义主机模型,以保证相关配置录入CMDB的时候必须包含所需信息。
另外,除了属性列表以外,模型还能够定义其他相关字段等。
另外,除了主机模型外,我们还可以按需创建其他模型并对其进行分组:
- 组织架构,如业务
- 业务拓扑,如模型、集群
- 网络,如交换机、路由器、负载均衡、防火墙
- 数据库,如MySQL、Oracle
2.业务拓扑
业务拓扑是配置平台进行主机管理的基础,只有建立合适的业务模型,才能结构化的管理好主机。CMDB配置平台提供用户结构自定义、拓扑属性自定义等功能。
通过业务拓扑,我们可以按集群、模块将业务进一步划分,以便将服务器与业务应用进行关联,清晰的了解业务下主机数量。
3.多条件筛选
对于已经纳管的服务器,我们可以按不同需求进行多条件筛选,条件可以根据主机相关字段进行,例如:
- 按模块筛选
- 按管理IP筛选
- 按服务器类型筛选
- 按其他字段筛选
通过筛选可以快速解决我们的需求,如:
- 生产环境服务器数量共有多少
- 物理机、虚拟机各是多少
- x.x.x.x 的管理IP
- x.x.x.x 属于哪个业务应用
- x.x.x.x 服务器哪一年购买的,是否维保过期
4.权限分离
对应于运维岗位可能进一步划分为基础运维和应用运维的,其中:
由于基础运维和系统运维主要区分在于是否和业务相关,CMDB可以帮助我们进行权限隔离,即:
- 系统权限:可管理所有模型的查询、编辑、删除等
- 业务权限:分角色管理业务下所有集群、模型、主机编辑和转移等
通过权限隔离,我们可以更好的根据岗位进行权限划分,各司其职、各尽其责。
5.小结
通过通用的功能,CMDB满足了我们约80%的基础设施管理需求,“好用”可以说是实至名归。但剩余的20%是我们的痛点,CMDB能不能进一步满足我们呢?那么这就需要我们将CMDB用好,来满足我们20%的痛点需求。
用好
1.服务器上架痛点
背景
由于运维的岗位进一步划分为基础运维和应用运维,针对服务器上架场景基础运维和应用运维的工作如下:
基础运维:
1.新服务器上架;
2.CMDB维录入新服务器的资产信息,如管理IP、品牌、型号、维保等信息;
应用运维:
1.CMDB将服务器转移到相关业务、应用下;
2.在监控平台、堡垒机中添加相关主机信息;
此时可能大家觉得没毛病啊,但是我们忽略了CMDB的主机管理是以业务IP为主键的,这就意味着基础运维在新服务器上架时必须确定服务器的业务IP,否则无法导入CMDB,但业务IP的确定是滞后的,由应用运维确定,此刻我们的上架流程就出现了问题。
解决方案
分析痛点导致资产无法导入CMDB的原因为业务IP和管理IP同时存在于主机模型中,因此我们需要将他们分别隶属于不同模型。由于业务IP肯定属于主机模型了,因此我们新增并扩充了以下三个模型,并且专门由基础运维管理:
- 机房,主要是机房位置
- 机柜,主要是机位信息
- 物理机,主要是管理IP、品牌、型号、维保等信息
其中我们将硬件服务器的主要字段都放到物理机这个模型中,而主机模型虽然包含了物理机和虚拟机,但是只有业务IP,而不包含管理IP及其他字段信息。
此时大家可能会有一个问题:物理机的业务IP如何与管理IP进行关联,以应对物理机故障的风险?
因此我们需要对CMDB进一步深入探索:关联管理。
通过关联管理,我们可以做到:
- 将物理机与机柜、机房进行关联
- 将主机(主要是带有业务IP的物理机)关联到物理机模型,而虚拟机无需关联
通过关联关系,我们可以清晰看到物理机的业务IP、管理IP及机柜、机房信息。
小结
通过新增物理机、机柜、机房模型以及关联关系,在权限隔离的基础上,我们实现了:
- 基础运维与业务运维的操作分离
- 基础运维管理物理机、机房、机柜之间的关系
- 应用运维管理虚拟机、物理机与业务之间的关系
权限隔离、操作分离正好解决了我们服务器上架的痛点。
2.CMDB打通堡垒机与监控平台
前面提到的“CMDB为上层应用场景提供可靠的数据支撑”,虽然我们实现了业务与主机的关联,但是CMDB与运维平台的隔离成了我们运维自己的一个痛点。在给业务做好服务的同时,我们也不能亏待了自己啊。
因此我们需要通过“事件注册与推送:提供基于回调方式的事件注册与推送;”实现CMDB打通堡垒机与监控平台,实现:
- CMDB与堡垒机联动,保证堡垒机资产分组与CMDB一致;
- CMDB与监控平台联动,保证监控平台的主机分组和CMDB一致;
我们的目的是保证CMDB数据的权威性,这样做才能够避免"CMDB成为摆设、花瓶"。
CMDB提供的事件推送可以对接第三方系统,因此我们可以自行开发系统来与其对接,完成CMDB打通堡垒机与监控平台的最后一步。
本章部分在此就不做过多赘述,大家有兴趣的可以参考之前的问题。
《事件推送网关:让cmdb告别“花瓶”》
总结
对CMDB的使用我们也曾停步于好用阶段,但是对于痛点需求没有停止过思考,团队间充分的沟通与讨论让我们克服了这最后20%的痛点,因此运维请相信团队的力量。
更多推荐
所有评论(0)