CMDB

发表于 更新于 分类于

背景

之前有提过现阶段要把之前的产品推翻重做，做带中台调性的新监控。其中一块核心的内容就是CMDB，虽然CMDB的设计主要是架构师以及后端同学的活，但是架不住我爱掺合啊，这块的前端是我来弄，所以也有正当理由摸鱼撒。所以简单也做个记录，稍微深入的了解下CMDB这玩意，也不能细说一个是我没那么精通另一个我不得保护我们的产品知识产权吗不然老板不把我弄死啊…跑题了。

开始

CMDB刚开始接触的时候我把它笼统的理解为资产管理，当然这种理解肯定是不对的，太局限。

因为我们的产品大多数情况下都是部署在客户的内网，CMDB在我们产品中的定位：

  • 运维对象管理系统。
  • 支撑监控能力的基础设施。
  • 以应用为核心对象串联其它资源。

识别运维对象，主要分为两个部分：

基础设施层面：网络设备、服务器、存储设备等；

应用层面：应用元信息、告警配置信息等

当我们识别出运维对象和对象间的关系，并形成了统一的标准之后，接下来要做的事情就是将这些标准固化，固化到信息管理平台中，也就形成了我们说的CMDB（配置管理）。

运维对象识别

思路跟下图很像，从消费场景入手，识别对象以及对象具有的元素应该有哪些。

最终细化一下会识别出几种类型，一个是基础资源对象，一个是应用对象，一个是逻辑对象（组织和人），把这几种类型对象按照相应的规则的建立关系，从而管理属性、关系、状态、场景。

发现

前一小结确定了运维对象识别的核心思想，其中一个大的作用就是指导资源发现，我们第一版的发现的方式包含两种：

  • 网络拓扑发现（自动）：通过SNMP扫描网络，发现其中的网络设备，并判定其间的网络连接关系。

  • 指定类型发现（人工或者流程）：用户指定资产类型，发现时不需要依据判定规则。

    下图是我傍的一个后端大佬画的，我悄悄盗过来，镇场面。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
classDiagram

	class 发现规则 {
		+ 判定规则
		+ 收集规则
	}

	
	任务 "1" -- "N" 任务执行
	发现代理 -- 发现结果
	任务执行 -- 发现代理
	任务执行 -- 资产数据
	资产数据 -- CMDB

	发现规则 -- 发现代理
	全局例外 -- 发现代理
	SNMP特殊判定 -- 发现规则
	任务 "1" -- "N" 连接信息

建立关系

首先明确一点，以应用为中心，从应用的视角去看，从应用的角度构建资源管理的关系（拓扑关系）。

看了几篇相关的文章基本上，关系类型可简化为下面几种：

  • 主从关系。这种关系是一种强父子关系，主不存在了，则从就不存在了。比如主机和网卡、硬盘。
  • 依赖关系。是一种对象属性级之间的关联关系，比如说服务器放在机柜上，机柜摆在某个机房内，这是对象级别的关系。通过对象的属性关联来表达。
  • 连接关系。主机和存储、主机和网络设备的关系，是连接关系。这种关系是动态生成的，是一种实例级的关系。

依赖关系和连接关系有什么不同？

  • 依赖是一对多的关系，并且这个关系是靠人维护的，比如说机柜上放了很多服务器。
  • 连接是多对多关系，并且这个关系是因为某种“连接”产生的，比如说服务器连接了交换机。通常是通过自动发现来实现。

我们产品第一版关系设计跟上诉差不太多，只是叫法有一些区别。

比如主从关系：属于、包含。

依赖关系：运行在

连接关系：连接

由于各种原因，大概就整理这么多。

小结

大体围绕CMDB的设计思路如下图。

设计的时候考虑的要点：

  1. 领导要参与，团队理解要一致。通过场景带入的方式。
  2. 领域分析是核心，除非有必要，不然不考虑技术实现。
    1. 为啥DDD，建立研发、产品等各方的通用语言。
    2. 为啥DDD，DDD是一套完整而系统的设计方法，基于这套方法使面对高复杂度的业务，设计思路能更加清晰，设计过程也能更加规范。
  3. 从应用视角切入，应用是核心。
  4. CMDB最好分为两个维度的内容进行共创：配置管理、资源管理（资源管理 ≠ 资产管理）。
  5. 整理的资源都是服务于各种消费场景的，原则上不应该存在游离态的资源。
  6. CMDB的模型定义一定是有层次的，比如分为核心模型和扩展模型。
    1. 核心模型记录业务、应用和主机，有了核心模型系统基本就能跑起来了。
    2. 扩展模型是依赖核心模型扩展出来的，比如基于主机找到关联的机柜等信息，这块信息是有核心模型驱动逐步完善的。

本文引用的图片，如有侵权请联系我删除。

感谢