图数据库在CMDB领域的应用

【导语】上期的图数据库介绍中,我们对什么是图数据库,以及图数据库所擅长的领域做了一个初步的介绍,也收到了众多的反馈和咨询,特别要求我们对图数据库在一些具体行业的应用能做一些深入介绍。为此,从本期文档开始,笔者将用一系列文章对图数据库在一些专门领域的部署和应用做专题介绍。第一期,将讲述图数据库在CMDB领域的建模和应用场景。

传统CMDB的弊端

CMDB,英文名Configuration Management Database,即配置管理数据库,常常被认为是构建其他ITIL流程的基础而优先考虑,ITIL项目的成败与是否成功建立CMDB有非常大的关系。

从2000年开始,CMDB开始在国内企业慢慢推广开来,分别经过了最初的资产信息电子化阶段、开始与ITSM流程协同配合阶段,一直到配置自动化发现引入阶段,目前随着云计算技术的发展,CMDB的场景已经从传统的资产台账管理逐步演化到流程协同管理、影响分析、配置比对、云化资源管理等方面,但在CMDB的技术架构上,无论是开源产品还是商业化产品都没有明显改进,发展比较缓慢。这在一定程度上也影响了CMDB场景的拓展。

接下来我们将分析当前CMDB建设遇到的一些常见问题。

缺乏合理化、整体化的规划

需求不清晰,定义了不合理的配置广度和深度。

大而全还是小而深——选择犹豫不决

这种决策机制在项目初期往往耗费了大量时间,但随着新技术的不断涌现,这种方式已经无法适应越来越敏捷的IT环境,这种相对静态的CMDB模型已经不能满足纳管新IT组件的要求。

采用了不正确的管控策略

按照经典ITIL的管控和项目实施机制,配置管理规划,尤其是CMDB模型的规划往往由项目组承担,一旦规划完成后整个模型也就变得很难再进行扩展,应该说这里采用的是一种集中管控的策略。
但在实际IT运维工作中,我们发现对于CMDB使用最多的是各个二线团队,不同团队之间对于CMDB深度和广度的要求,以及管控方式都有较大差别。

配置管理人员职责定义不清晰

配置经理、配置管理员、配置Owner之间职责不清晰

ITIL或ISO20000中对于这三类角色的定义往往过于宽泛,没有进一步考虑实际运维人员的运维场景,以及使用的运维工具,导致职责定义和实际做事方式脱节。

角色职责和岗位的对应不明晰

在没有ITIL以前,在企业IT部门或数据中心往往找不到一个现成岗位对于IT配置信息进行集中管理,而是每个人各管一摊。

实施ITIL后,究竟由哪个部门的哪个岗位承担配置经理这一职责往往是最让人伤脑筋的,最后往往是赶鸭子上架。这种角色定义方式最终导致体系无法运转。

配置管理成了IT运维的负担

这其实是CMDB在企业落地所面临的最大挑战,无法充分调动运维人员的积极性,主要体现在:

初始数据收集工作量大

存量的配置数据往往基数很大,一般配置的量级在5000以上,考虑到云化环境的海量运维场景,这个基数还会更大。

随着分布式应用架构以及微服务架构的兴起,未来一套新应用系统上线引入新的配置项数量也无法简单通过手工输入的方式来完成。

单一的自动化配置发现工具只是一种幻想

如前所说,约从2007年开始,业内引入了自动发现工具用以解决配置数据的初始化问题,但由于这类工具往往由某个厂商提供,导致了配置发现的局限性,企业往往也要付出较大成本。

投产后由于变更频繁,数据无法保证及时准确

以往企业一般采用变更操作驱动配置修改(人工修改或自动化发现修改)的方式以确保配置数据的准确性,这种方式往往会出现配置信息的不一致。

如何让人人“乐于”参与

这里的参与主要体现在两个方面:

  • 需要使用与自己相关的配置数据时,CMDB可以立即提供;
  • 遇到CMDB无法提供的数据时,IT部门可自行在一定标准和约束下扩展满足本部门运维CMDB模型,支撑部门级的运维场景。

配置数据的价值无法呈现

缺乏清晰的场景定义,包括流程价值、监控价值、BSM价值、云价值等

单一流程驱动CMDB的场景,无法让CMDB中的数据流动起来,随着时间的推移CMDB中的数据就逐渐腐败——不及时也不准确。

同时,CMDB在技术上作为一个“数据库”,要让其中的数据能够流动起来,必须明确与之匹配的运维场景。

场景是用来描述与CMDB中某些配置项交互的一组活动,满足IT部门某一方面的运维管理目标,这一目标可以被度量、跟踪、改进、可视化,与此同时&#

基于数据库存储引擎的 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 的其他相关业务属性可直 接存储到对应节点和关系对象本身。 除资源节点关系表外,所有的表在数据库中都可以认为是具有某些特 定属性节点的集合
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值