以场景驱动的CMDB数据治理经验分享

基于图数据库存储引擎的 CMDB 系统 传统数据中心的资源对象与关系类型较为单一，CMDB 系统可以通过关系 型数据库对资源对象和关系数据进行分析和处理。 随着云计算、大数据等技术的高速发展与应用，数据中心资源对象的数 据规模越来越大， 资源对象之间的关系也更加复杂。 传统数据中心的资源对 象与关系类型较为单一，CMDB（Configuration Management Data Base，配 置管理数据库） 系统可以通过关系型数据库对资源对象和关系数据进行分析和 处理。 在云计算环境应用带来大规模图类型数据的场景下， 关系型数据库的 处理能力逐渐不足。 本文主要研究通过图数据库存储引擎处理大规模资源对象与关系数据， 为 CMDB 系统提供高效可靠的数据存储应用方案。 同时结合实验对比分析图 数据库和传统关系型数据库在大规模资源对象与关系数据上的查询存储性能 及优势特点，借助图数据库存储引擎来提升数据中心 CMDB 系统在故障分析、 风险预测等运维功能上的数据应用处理能力。 云计算平台模型分析 云计算技术通过虚拟化为业务系统提供了虚拟机、云硬盘、虚拟网络、 负载均衡等虚拟化的基础设施资源， 同时， 这些虚拟化的基础设施资源依赖数 据中心最底层的物理基础设施。 在数据中心中， 从底层物理基础设施到业务 系统之间， 云计算环境的承接产生了多层且复杂的关系。 每一层的资源节点 对象都与上层的业务系统存在关系，关系类型包括依赖、影响、关联等。 如图 1 所示， 从底层基础设施到上层应用业务系统需要跨越虚拟资源层上的多 个资源节点和对象。 云计算环境中业务系统、虚拟资源、基础设施相互关联，当某个节点出 现问题时， 需要通过关联关系找到其他受影响节点以定位整个故障域的影响范 围，并及时采取对应的措施。 由于自身设计结构的问题，关系型数据库在处 理不同对象组成的多种类型关联关系的图数据时， 只能依靠多表连接操作的方 式进行存储。 这种存储方式在处理关系运算上表现很差， 随着数据量和关系 深度的增加，无法在理想的时间内运算出结果。 随着图数据理论研究日趋完善，在开源社区里逐渐出现了很多优秀的开 源图数据库。 图数据库区别于传统关系型数据库， 专门针对图数据的关系进 行建模和存储， 同时还提供了一套全新针对图数据的查询语法—Cypher。 本 文将以其中比较具有代表性的 Neo4j 开源图数据库为工具， 对比传统关系型数 据库 PostgreSQL，并结合在数据中心中应用越来越广泛的 OpenStack 开源云 计算环境，进行研究分析，旨在梳理云计算环境中不同层面之间的对象关系， 结合图计算方法对其中的实际应用场景模型进行分析， 提出符合实际应用场景 的基于图数据库存储引擎的 CMDB 系统建设方案。 CMDB 系统应用分析 数据种类及规模分析 目前，在行业私有云建设中，为实现面向应用的智能运维，运维系统需 要实现从基础设施层到虚拟化层， 再到应用层的自动化、 可视化。 其中， CMDB 对各种资源的关系数据记录是系统的核心，资源之间的关系搜索是难点。 以中国铁路主数据中心铁路云的规模为例，计算节点的规模达上千个， 虚拟机的规模达上万个，虚拟机上承载的容器、服务进程、日志文件、配置文 件等规模达百万、千万个以上。 假 设 资 源 节 点 对 象 为 N ， 关 系 对 象 为 R ， 资 源 节 点 集 合 为 ： （式 1) 排除资源节点自身与自身的关系， 资源节点间的单一类型关系全集合为： (式 2) 由式 1 和式 2 可以得到资源节点集合元素的个数与资源节点间的关系集 合元素的个数计算表达式为： (式 3) 由式 3 可知，理想状态下，当资源节点数量级为万级别时，资源节点间 单一关系类型的关系数量级为亿级。 目前，CMDB 处理如此巨大的关系数据是十分困难的。 在实际场景中， 资源节点对象 N 还包含一些其他业务信息的属性，如 IP 地址、位置编号以及 软硬件信息等。 关系对象 R 中一般包括关系类型、相关联两个节点信息等。 关系数据库与图数据库区别 关系数据库将数据存储在具有固定结构 （架构） 的表中， 每列具有名称、 类型、长度、约束等。 表与表之间的引用通过将一个表的主键作为另一个表 的重复外键来实现。 对于多对多的关系数据，需要 JOIN 表（或关系表）作 为连接表之间的桥梁。 区别于关系型数据库主外键的数据结构表达方式，图数据库中仅使用节 点、 关系 （边） 来表示和存储数据。 节点和关系可以保存任意数量的属性 （key- value pairs） 。 上述资源节点对象 N 和关系对象 R 的其他相关业务属性可直 接存储到对应节点和关系对象本身。 除资源节点关系表外，所有的表在图数据库中都可以认为是具有某些特 定属性节点的集合