关于大数据:结合公司现状浅谈CMDB

本篇文章联合参考资料中的几篇 CMDB 的文章再加上目前公司的现状谈一谈 CMDB。

CMDB 概述

CMDB：configuration management database，配置管理数据库。CMDB 实质上是一个数据库，提供数据的存储、查问、校验等操作，是一个 集中式 的数据托管核心，托管的内容蕴含所有的软硬件资产（configuration items）。各个部门各个团队各个系统上司的各种重要的软硬件资产都属于 CMDB 对立治理的内容。

公司运维现状

资产现状

全国各地区内网不互通。这个就是现状了，因为公司产品是为国家服务，所以全国各地的环境都在各自的内网中，安全性极高，在这种状况下，每个地区都配置了几个运维手工保护当地的环境，内外网齐全隔离。

运维状况现状

因为公司资产地区扩散且网络不互通，因而公司的自动化运维水平根本为 0。整体上来说没有运维开发的岗位，目前的运维依然停留在人工运维联合 shell 脚本的时代，这些其实都算不上自动化运维，前段时间，开始搞 ansible 自动化部署和降级的事件，整个过程都是 shell 脚本实现。为了管制人力老本，甚至否定一些用新技术。拿 Python 这门语言来说，自身很适宜自动化运维，用于自动化降级那是再适宜不过了，尽管底层会依赖 shell，然而 Python 写进去的逻辑必然会更分明，然而下层思考到后续保护人员须要把握 Python 和 shell 两种技术，最终还是否定了 Python，其实也就是否定了自动化运维。转而几种人员去钻研日志核心和 nagios 监控，自动化运维的事件也天然不了了之。

<!–more–>

CMDB 现状

目前公司外面还没有产生建设 CMDB 的萌芽，资产治理部门和运维核心团队有本人的配置库，也就是自建库。然而并没有将产品团队的软件资产列入配置管理的范畴。各个产品团队应用 Confluence 文档服务器或者 Excel 表格（这种状况较多）治理本人的软硬件资源，并称之为资源台账。就服务器而言，常常不晓得一个 ip 对应的服务器是否正在应用，由谁应用，这些信息无所不知。如果各个团队应用自建库，而不是通过文档模式来治理，那这种 CMDB 最多也只能算是各自为政的 CMDB，并不是集中式的数据托管。

CMDB 设计

最简略的设计：一种配置一个表

比方，ip 独自成表，host 独自成表

长处：配置简略直观

毛病：一旦某种配置须要批改字段，就须要批改代码，代码保护老本太高

简单点的设计：列式数据存储

表名，列名，列值，行离开寄存到四张张表(schema, filed, value, entity)

• schema：一个配置表在 schema 中就是一条记录，记录表的信息和形容。
• field：每一列的列名和列相干的 meta 信息都寄存在 field 表中。
• entity：当作 rowid 应用，示意惟一掂量传统意义上的一行数据。
• value：寄存每一条记录的每一列的值，即一个 entity 和一个 field 既能够确定一个值。

表的设计如下图：

整个设计的 sql 如下：

-- MySQL Workbench Forward Engineering

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES';

-- -----------------------------------------------------
-- Schema mydb
-- -----------------------------------------------------

-- -----------------------------------------------------
-- Schema mydb
-- -----------------------------------------------------
CREATE SCHEMA IF NOT EXISTS `mydb` DEFAULT CHARACTER SET utf8 ;
USE `mydb` ;

-- -----------------------------------------------------
-- Table `mydb`.`schema`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`schema` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `name` VARCHAR(45) NOT NULL,
  `desc` TEXT NULL,
  PRIMARY KEY (`id`),
  UNIQUE INDEX `name_UNIQUE` (`name` ASC))
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`field`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`field` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `name` VARCHAR(45) NOT NULL,
  `meta` TEXT NULL,
  `schema_id` INT NOT NULL,
  PRIMARY KEY (`id`),
  INDEX `fk_field_schema_idx` (`schema_id` ASC),
  CONSTRAINT `fk_field_schema`
    FOREIGN KEY (`schema_id`)
    REFERENCES `mydb`.`schema` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`entity`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`entity` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `key` VARCHAR(45) NOT NULL,
  `schema_id` INT NOT NULL,
  PRIMARY KEY (`id`),
  INDEX `fk_entity_schema1_idx` (`schema_id` ASC),
  CONSTRAINT `fk_entity_schema1`
    FOREIGN KEY (`schema_id`)
    REFERENCES `mydb`.`schema` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`value`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`value` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `value` TEXT NOT NULL,
  `field_id` INT NOT NULL,
  `entity_id` INT NOT NULL,
  PRIMARY KEY (`id`),
  INDEX `fk_value_field1_idx` (`field_id` ASC),
  INDEX `fk_value_entity1_idx` (`entity_id` ASC),
  INDEX `ux_value` (`field_id` ASC, `entity_id` ASC),
  CONSTRAINT `fk_value_field1`
    FOREIGN KEY (`field_id`)
    REFERENCES `mydb`.`field` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_value_entity1`
    FOREIGN KEY (`entity_id`)
    REFERENCES `mydb`.`entity` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

数据库查问时须要提供 (entity, schema, field, value) 这样一个四元组能力失去后果。

长处：在线定义，表有变动时不须要批改代码，减少一列只须要向 field 表中插入一个字段。

毛病：简单，增删改查时须要同时操作多个表，对数据的束缚须要在应用层去实现，须要本人封装 ORM，每一列的束缚信息寄存在 field 表的 meta 字段中。

更简单的设计：数据多版本和回滚

减少数据多版本

CMDB 寄存的信息都是十分重要的信息，因而不容许批改数据，每一次批改数据都独自减少一条记录，这样就能够保证数据多版本。因而能够减少一个 snapshot 快照表，用来寄存各个历史版本的数据。snapshot 表的具体设计较简单，暂不应用。

减少回滚

减少数据多版本之后对应的就能够减少一个回滚的性能，多版本根底上的回滚性能能够参考 git 的实现。

CMDB 应用论断

强烈拥护大型集中式 CMDB。CMDB 团队执行力不强，需要多变，短期内看不到价值等多种起因导致在大多数互联网公司 CMDB 是无奈落地的，到目前为止除了华为也没几家公司能把 CMDB 落地直到施展 CMDB 的价值（华为都花了 7 年的工夫，更别说别的公司了）。

如果肯定要应用 CMDB，那只能应用分散式的各自为政的，各个团队应用各个团队的自建库，比方管 IP 库的就专门设计 IP 库，管账号库的就专门设计账号库，数据库之间通过各自提供的 api 通信。然而分散式的毛病是从领导的角度看，看不到全局的数据，因而还须要做一个集中化的 dashboard。

CMDB 代替计划

CMDB 在大多数互联网公司不可行，因而很多公司都另辟蹊径，比方一种形式罕用的形式 Mesos

• Mesos：托管于 Apache 下 C ++ 开发的开源分布式资源管理零碎

Mesos 的调度框架能够有多种语言开发，包含 Python。

参考

• 冰与火之歌，华为 CMDB 是如何炼成的
• 维基 -Configuration management database
• CMDB 教训分享之 – 分析 CMDB 的设计过程

记得帮我点赞哦！

精心整顿了计算机各个方向的从入门、进阶、实战的视频课程和电子书，依照目录正当分类，总能找到你须要的学习材料，还在等什么？快去关注下载吧！！！

朝思暮想，必有回响，小伙伴们帮我点个赞吧，非常感谢。

我是职场亮哥，YY 高级软件工程师、四年工作教训，回绝咸鱼争当龙头的斜杠程序员。

听我说，提高多，程序人生一把梭

如果有幸能帮到你，请帮我点个【赞】，给个关注，如果能顺带评论给个激励，将不胜感激。

职场亮哥文章列表：更多文章

自己所有文章、答复都与版权保护平台有单干，著作权归职场亮哥所有，未经受权，转载必究！