CMDB

2019/11/28 13:59
阅读数 193

通俗浅薄的解释一下CMDB

从上述百度百科的定义来看,还是有些苦涩难懂的。我们从应用场景切入来理解CMDB,可能更加容易一些:

场景一:应用运维工程师从业务线/产品线的角度去,去查看某个业务线/产品线有多少个应用系统、哪些是核心的应用系统,这些应用系统是不是部署那些主机上,是否存在单点问题,资源是否合理分布等等。在一般的运维过程中,每个应用系统的信息都存在,但这些关键信息可能都是散乱的,比如用物理机部署的可能在某一个工具上维护,用云主机部署的却是在云平台上进行维护,给整体的分析带来了不便,使得无法从更高的业务角度来判断和分析资源情况。

场景二:在日常的运维管理中,我们需要面临很多的IT资源,有物理形态的,比如机房、机柜、网络设备、安全设备、物理服务器、SAN存储、刀箱等等;有数字形态的,比如云平台、云主机、IP、操作系统、中间件、数据库、代码等等。其中的任何一个资源出现故障,可能都会影响到业务的稳定运行,那么我们怎么来统一管理这些IT资源、怎么来理清这些资源之间的关联关系、它们之间又是如何相互影响的。

CMDB的提出就是要解决这些问题的,以提高运维的效率、甚至以达到智能运维的目的。从管理角度看,CMDB的核心就是对这些IT资源进行管理。为了进行有效的管理,CMDB有这些IT资源必要的属性信息(注意不是最完整、最全面的信息),及这些IT资源之间是如何相互关联、相互影响的关联信息。从运维角度,可以一句话来简单描述就是:

“CMDB知道一个IT资源的必要信息,也知道这个IT资源发生变动后,会影响到哪些IT资源及业务”

在CMDB中,还有两个比较费脑细胞的概念就是“模型”及“关联关系”:

  •  模型:我们通过模型定义各个资源对象(可以理解为:对于这些资源对象,我们需要关注哪些信息--类似数据库中的表有哪些字段一样)。
  •  关联关系:定义说明这些对象之间的关联关系,比如应用和云主机是运行关系,某某应用运行在某某云主机上,某某云主机运行了某某应用。

这就是CMDB的模型之说,文章的后面我们通过实际例子来正式说明。定义好了这些模型、关联关系后就要把这些模型实例化,类似我们往表中插入一行数据一样,这行数据有主键key、各个字段属性、各个外健等等。

下面,我们将从产品理念、产品架构、资源模型、原型设计、应用场景方面进行来说明我们如果构建一个符合多云架构、符合“双态运维”的轻量级CMDB产品。

产品理念和目标

产品理念:以应用场景为驱动,建立高效化、轻量化的运维数据枢纽。

产品目标构建符合多云架构、符合“双态运维”的轻量级CMDB,并形成运维数据中心枢纽,该数据枢纽能够支持多种业务场景,比如资产管理、资源可视化、运维监控、自动化运维、多云管理等等

产品框架规划设计

CMDB产品功能规划上,我们做了一个最简化的组成,即由模型管理、数据中心、资源管理、采集平台、资源可视化等组成,具体如下:

CMDB 在功能架构上由如下核心内容组成:

  • 模型管理:
    • 模型定义:通过模型把需要管理的IT资源进行定义,描述IT资源的各种信息属性,以便用户能快速、清楚的了解资源情况。
    • 关联关系:预先定义各种关联关系(比如运行、归属、组成、属于、默认关联、使用等),然后通过这些关联关系来描述各个模型之间的相互关系,比如某某应用运行在某某主机上。
    • 模型拓扑:通过拓扑图形能够直观、便捷的对模型之间的关联关系进行展现和管理。
  • 资源实例数据中心:
    • 创建模型:根据模型定义,创建资源模型。如果数据中心建立在Mysql上,表现为创建Table;如果数据中心建立在MongoDB上,表现为创建collection。
    • 存储数据:存储采集平台从各个地方采集过来的数据; 存储资源管理模块手工录入或者模板导入的数据。
  • 资源管理
    • 资源实例录入和编辑:提供一个可视化的界面,用户可以对资源实例的属性、关联关系进行增加、编辑和删除等。
  • 资源可视化
    • 资源查询,提供界面可以快速查找各种IT资源。
    • 常见视图:从应用运维工程师角度(含业务系统客户),构建了业务视角;从云平台运维工程师角度,构建了云平台视角;从IDC运维工程师角度,构建了IDC视角;从存储工程师角度,构建了存储视角。
    • 视角拓扑定义:可以从其他工作角色来自定义新的视图。
  • 采集平台
    • Agent : 通过在资源端安装Agent ,实时或者定时采集数据。
    • 自动发现:通过规则自动发现模型之间的关联关系或补齐修改资源属性。
    • 批量导入:支持数据的大批量导入。
    • API同步:提供接口,让外部系统能够实时把资源属性进行更新。
    • 第三方同步:比如通过ETL工具,从其他数据库同步。

当CMDB构建好后,就可以向各种应用场景提供服务,比如资源可视化、运维监控、自动化运维、技术运营、智能运维等等。

核心流程规划设计

从业务操作流程来看其实并不复杂:

  1. 模型管理模块定义好模型
  2. 数据中心根据定义,创建模型。
  3. 从过手工录入或者自动采集实例化资源。
  4. 通过数据中心构建各种可视化应用,包括资源查阅、资源拓扑展现、运维大屏之类的可视化应用。
  5. 通过数据中心提供其他应用。

模型规划设计(核心部分)

传统CMDB模型的缺点

在传统CMDB项目的实施过程中,大家都是看了仿佛都是各种各样的模型、五花八门的配置项目,然后,项目工作都落入定义各种配置项中去,笔者了解到之前的CMDB项目中也s落入这个陷阱而导致项目失败。虽然我们看到项目过于关注模型而导致失败,但是也从侧面说明了模型的重要性。开发一套CMDB系统并不是一件困难的事,但是用好一个CMDB系统却是一件困难的事。如何用好CMDB系统,规划设计一套可用的CMDB模型是一个关键。那么,我们又应该如何规划CMDB模型才能满足我们的产品目标呢?

在如何规划设计CMDB模型前,我们先先说说传统的CMDB模型,传统的CMDB基本都是由国外的大厂家开发的,产品围绕数据中心以基础资源管理为主,模型配置项也极其繁杂,比如明细到了某个插座的型号、位置之类的,似乎要穷举所有资源的所有属性才摆休。传统CMDB常常需要运维人员进行各种配置项后才能使用,即没有一个可以开箱即用的模型,这个配置的过程基本把运维人员挡在系统门外,最后,肯定是不如Excel来得方便。另外是过分依赖人工维护,缺少自动化发现及自动采集功能,数据维护工作量巨大,系统投入产出比严重失调,最后也是不了了之。对于敏态运维DevOps的支持,更是无从谈起。

新一代CMDB模型的出发点

为此,在规划设计CMDB模型时,我们可以如下几点出发

  1. 要从业务应用角度出发,不能从IDC的资源管理出发,毕竟所以的IT资源归根到底都是为业务服务的。
  2. 至少要存在一套可以开箱使用的模型,不能只是提供一个工具的平台,而把难题丢给了用户。谨记“开发一套CMDB系统并不是一件困难的事,但是用好一个CMDB系统却是一件困难的事
  3. 模型属性尽量精简化,只需要必要属性信息,而不是穷举所有属性信息。
  4. 人工维护是必要的,但是能够系统自动化就要系统自动化,手工录入是一个迫不得已的手段。
  5. 要场景应用为驱动,反推和检验模型。
  6. 模型要考虑多云架构、考虑内外部资源
  7. 模型是为了管理,不能为了模型而模型,不能因为各种配置项、各种配置属性,而把精力放在库表的设计和管理上。

一个开箱即用的CMDB模型

如下是笔者为了满足多云架构及“双态运维”初步规划的CMDB模型规划:

当然,笔者只是做一个开箱即用的简要模型,但可以满足80%以上的运维管理要求。

常见的关联关系

 

比如,应用和云主机是运行关系,某某应用运行于某某云主机上,某某云主机运行了某某应用,其中应用是源、主机是目标。

如何定义模型属性

重复一句:“尽量精简化,只需要必要属性信息,而不是穷举所有属性信息。”

如何定义模型关联关系

建立源与目标的概念,任何一个对象在不同关联关系中都不同的定位。下面以云主机为例,

  • 云主机与云平台是归属关系,云主机是源,云平台是目标。
  • 云主机与应用是运行关系,云主机却是目标,应用却是源。

如下图:

当然,我们也可以通过拓扑方式更加直观来管理这些关联关系:

确定好有哪些模型,如何定义这些模型及模型之间的关联关系,那么模型工作基本就可以告一段落了。接下来就是如何根据定义实例化这些模型。

实例化模型有些需要注意的地方

实例化数据库的选择

传统的CMDB是基于关系型数据库实现的,使得整个库表架构极其复杂,可读性极差,对外接口更是复杂了。新一代CMDB利用MongoDB这非结构化数据库能够更加适合CMDB的建模,推荐的做法是:

  • 利用Mysql等关系型数据库,存储模型的定义。
  • 利用MongoDB等NOSQL文档存储数据库,以json的格式存储资源实例。

实例和视图分开

CMDB数据中心同时事务数据库及数据仓库的功能,为了能够满足数据实时更新的同时,也要满足各种运维的监控及分析。因此,建议分成实例库和视图库:

尽量减少人工录入

手工录入是一个迫不得已的手段,能够采集就自动采集,能够自定发现的就自动发现。

常见资源可视化视角需求

实现核心模型,即业务、应用和主机Host的关系。运维人员可以

从云主机host 为起点向拓展云平台、宿主机、网络设备、存储等。

扩展模型3,以机房为起点拓展机柜、网络设备、安全设备、物理主机、存储设备、云平台。

以云平台为起点拓展机柜、机房、网络设备、存储设备、物理主机。

通过不同的视图可以满足不同用户对资源整体管控。

总结

一句话:开发一套CMDB系统并不是一件困难的事,但是用好一个CMDB系统却是一件困难的事

作者:老格,擅长产品规划和设计,擅长解决方案,擅长PPT制作,是一个懂技术的产品PM,会设计的售前咨询。

http://www.woshipm.com/pd/1915187.html

http://www.woshipm.com/evaluating/1759977.html

展开阅读全文
打赏
0
0 收藏
分享
加载中
请问有联系邮箱吗,咨询些事情
08/20 10:17
回复
举报
更多评论
打赏
1 评论
0 收藏
0
分享
返回顶部
顶部