首页> 自动化运维> 初识CMDB

[文章]初识CMDB

收藏
0 639 0

 初识CMDB

 

在刚接触DevOps的概念时,一直以为DevOps就是自动化交付流水线。其实DevOps是一个更大的概念,持续交付是实现DevOps的一种必要功能,自动化交付平台是实现持续交付的核心功能之一,而本文的主角CMDB是支撑自动化交付平台的核心基础模块。

 

CMDB的全称是Configuration Management Database配置管理数据库,但这是比较老旧的叫法了,现在主流的叫法是面向应用的CMDB或面向业务的CMDB

 

那现在我们就来说说,CMDB是干嘛的?或者说CMDB有什么作用?

 

用一句简短的话来说,CMDB就是管理各种资源,并让其他的人或者自动化平台能够使用这些资源。那什么是资源呢?在CMDB的概念里,一切都是都是资源。这句话很奇妙,太抽象了,难以理解。

 

“资源”其实跟JAVA语言里的“对象”挺类似的。在这里跟大家举例说一下,一般场景下的资源都有哪些?

网络区域资源、主机资源、应用资源、进程资源、业务资源、模块资源等等等等。

当然我这里举例都是比较大的范围。

具体到小的资源,就包括程序包、版本号、配置文件,参数等等。

这么多资源管理起来肯定是有相当的难度的,所以在CMDB建设的初期,我们就得控制好范围和颗粒度

 

既然知道有哪些资源,那我们就要去管理,那怎么管理呢?这里就又引出一个概念“模型”,这就是CMDB的核心

当资源越来越多的时候,且资源与资源的之间,相互关系、属于关系、依赖关系越来越复杂。管理的难度就越来越大,这时候需要一套能够灵活创建、调度、配置资源的平台

而通过建立模型,可以很清楚的知道有哪些资源,资源与资源之间的关系也能瞬间理清,以视图形式展示,那更是一目了然。

 

如图:蓝鲸CMDB的模型管理图



 

如图:蓝鲸CMDB的模型拓扑图



这里已经跟大家介绍了CMDB的一些相关概念。

 

现在给大家讲一下CMDB的建设因素:

 

首先 CMDB 建立在足够的消费场景下,和足够大的运维管理规模。因为管理规模不大,所以各个管理业务维护数据的成本并不高,传统的自给自足的管理方式也hold得住。但当管理的规模一旦扩大起来,会导致各领域的运维数据相互孤立,数据不一致,维护的成本也会成倍增加。

一个好的CMDB建设:

1、定义消费场景在先;

2、以应用为中心,控制好范围和颗粒度,保证数据的完整性,准确性,一致性;

3、打通运维流程,实现数据读写与闭环;

4、应该集成统一监控;

5、自动采集、足够灵活;

建设CMDB初期,各个运维业务对配置数据的掌控力会下降,从而导致成本徒然增加,但这是一个过渡期,当CMDB稳定下来,运维的标准化程度越高,成本会下降得越快。如图:

 

自动化运维
最近热帖
{{item.Title}} {{item.ViewCount}}
近期热议
{{item.Title}} {{item.PostCount}}