网站备案证书如何打开,网站开发女生,三亚建设信息网站,免费做暧暧网站【导语】在上期的图数据库介绍中#xff0c;我们对什么是图数据库#xff0c;以及图数据库所擅长的领域做了一个初步的介绍#xff0c;也收到了众多的反馈和咨询#xff0c;特别要求我们对图数据库在一些具体行业的应用能做一些深入介绍。为此#xff0c;从本期文档开始我们对什么是图数据库以及图数据库所擅长的领域做了一个初步的介绍也收到了众多的反馈和咨询特别要求我们对图数据库在一些具体行业的应用能做一些深入介绍。为此从本期文档开始笔者将用一系列文章对图数据库在一些专门领域的部署和应用做专题介绍。第一期将讲述图数据库在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是一个逻辑上的数据库其中的数据需要和企业现有IT环境中的多类数据源进行整合一套行之有效的数据集成策略和ETL数据抽取、转换、转载工具也必不可少。 通过以上分析我们回顾了CMDB的历史发展过程以及建设过程中遇到的挑战。下面来看云化环境下CMDB又将面临什么新问题。 图数据库和CMDB 在我们上一篇关于图数据库的文章《图数据库——大数据时代的高铁》中我们已经对图数据库有了一个初步的认识那么最擅长做风控的图数据库为什么也能在CMDB领域大展拳脚呢这就与图数据库天生的技术特性密不可分。 CMDB领域中最基本的单位是CI也就是配置项CMDB最基础的功能就是记录配置项以及它们的重要属性和之间的关系。简单而言CMDB是用以记录IT系统中所有类别及其具体属性以及其间关联关系的。如果你只有那么几台设备手指就能数得过来如果有几十台设备几张表也够了而如果是成百上千台甚至种类就多达几十种呢这就必须要有个资产管理系统否则你怎么知道这台设备的前世今生以及它出了问题应该找谁哪家供应商。 而资产管理系统就够了吗设备要用起来就不能是孤立的多种设备以及设备上的系统、软件必须是连接起来才有意义但资产系统显然管不了这种关联关系。 而如果使用传统的关系数据库很简单的想法是一张表对应一种设备类型表的列就是这种设备的属性。那问题来了我加了一种设备怎么办我需要在数据库里新建一张表这个我还能做因为我是个系统管理员嘛这么简单的DBA入门工作还是能做的但程序怎么办它能认出新加的这张表吗我可不懂Java、JavaScript……于是只好付钱给我的软件供应商让他再帮我加这一类设备。而作为软件提供商就会面临各种各样稀奇古怪的设备类型那软件开发人员能把这些类型都内置在里面吗显然不可能。再一种情况以前我的资产管理系统对于PC服务器只需要记录它的型号、配置即可突然老板跟我说今年要作固定资产登记每台机器加个标签上面是固定资产编号。我又得叫软件提供商提供新版本了…… 简而言之传统的资产管理系统设备类别不可增设备属性也不能增。或者都可增但开发代价太大了不是小公司的开发团队能镇得住的其性能及可维护性也不好。用关系数据库RDBMS)来做CMDB是死路一条。而图数据库为CMDB的未来发展指出了一条阳关大道。 图数据库属于NoSQL的一种其表征数据的核心称之为节点节点采用Key-Value的方式保存数据这一点创造性解决了设备类别CMDB里叫CI类的扩展性可以随意加一种CI类也可以随意在CI类里加一个属性而且它不会影响原有数据也无所谓空与非空。另外图数据库原来主要用于社交网络就是小明认识小红而小红是她妈妈的女儿她妈妈是她爸爸的妻子同时也是老板的下属那小红与老板有什么社交关系就可以查出来了如图1所示。 图1 图数据库中社交图谱的展现 人与人之间的关系太复杂而设备与设备之间的关系CI项与CI项之间的关系也类似应用系统依赖于数据库节点和中间件节点而数据库节点和中间件节点都依赖于操作系统操作系统运行在虚拟机上虚拟机又依赖于物理服务器物理服务器又与存储相连……那么应用系统与存储其实也是有关联的。这样的连接关系如果用关系数据库来表示应该怎么设计实际上是无法表达出来的。 在图2中我们可以根据CI之间的关系定义不同的关系例如CI和CI之间是依赖关系、包含关系、运行于关系、安装在关系以及连接关系等。而且关系的属性种类可以根据实际的需求无限制扩展。 图2 一个图数据库中CI关系图示例 CMDB领域中的图数据模型 图数据库一般都有自己独特的对数据进行描述的方式即以图节点和图边为特征的数据表征形式。在不同领域的数据结构中图模型的表现是完全不一样的。我们将通过一个实际案例来详细了解一下在CMDB领域的图模型是如何建模的。 传统CMDB原始数据分析 传统CMDB都是把数据存储在关系型数据库中并且分多张表存储。接下来我们就把数据从关系型数据库中导出为.csv格式的表格用Excel打开。如图3所示这是一个包含了UPS、STS、配电柜、机柜、物理主机、VM、应用系统等超过20种数据类型的原始数据表格。 图4是原始数据表中配电柜子表的数据演示出于数据隐私的需要我们隐藏了部分字段的真实信息。其他CI的数据我们就不一一示例基本上都大同小异。 图4 配电柜原始数据示例 原始数据关联关系分析 关于什么是图数据库的“节点”和“边”我们不再详述大家可以参考我们上一篇介绍图数据库的文章到这一步我们就直接分析如何根据原始数据建立节点和边的关系数据模型。 第一步是要根据业务需求确认不同CI之间的关系分类如我们在表1中所描述的那样一般情况下CI之间的关系就只有表中呈现的那么多。 表1 CMDB中CI与CI之间的关系列表示例 第二步我们把所有的CI和关系的种类都列出来当然只需要和业务部门充分沟通。图5是一个示例。 图5 CI与CI之间的关系分析 根据分析结果整理出节点类型和边类型 根据步骤一和步骤二的整理结果列出所有的节点类型如图6、图7所示。 图6 图数据库节点类型 图7 图数据库边类型 根据节点类型和边类型画出CMDB系统的图模型 根据已经整理好的节点类型和边类型我们就可以很轻松地把基于图数据库框架的数据模型画出来将来原始关系型数据库中的结构化数据也会以这种数据模型的架构转换成图数据库中的节点和边的数据类型从此不再和关系型数据库有任何关系。 在图8中我们可以看到所有CI之间的关系图谱。图数据库的一个最大优点就是数据建模非常方便直观。传统关系型数据库的DBA可以无需做任何修改就把原始的E-R图直接转换成图数据库的图数据模型这一点对业务部门的使用者而言非常方便。 我们在上文谈及传统CMDB的弊端时曾经说过传统CMDB的建模非常难以把握CI深度的这个度的关系而在图数据库中这都不会存在问题。管理员可以根据业务需求随时修改图8的图模型例如在不同的CI之间建立起边的联系或者新增加一种节点类型CI类型而这一切甚至不需要停机在线状态就可以直接修改生效。 图8 CMDB系统的图数据库系统建模示例 CMDB查询展示 数据模型建好之后接下去只需要把数据导入图数据库即可对于ITIL管理人员来说还是要看一下图数据库是如何解决传统CMDB系统弊端的。 查某一个多个CI向上支撑向下影响的其他CI并支持结果按类别筛选 我们首先来看看在CMDB中遇到的最常见问题查找任意一个CI的影响关系即如果该CI出现问题无论是出现故障还是需要做变更看看这个CI的影响范围以及可能的影响职能部门甚至指定的个人。 在图9中我们查找从指定UPS出发在“结果类型”中填0表示查询所有受影响或支撑的CI在“查询深度”输入框中指定步数输入10则表示查询10步及10步以内受影响或支持的CI。如UPS到开关是一步影响关系UPS到开关再到配电柜就是2步影响关系以此类推。 图9 CI影响范围的查询 在上面的图展示中可以对图进行放大缩小或者对某一块区域的图节点进行放大查看甚至可以对某一个节点进行查看。 查询关联路径选择2个CI看其间的影响关联路径 查找两个CI之间的关联关系也是我们在CMDB系统中经常遇到的问题传统的关系型数据库需要做不同表之间的Join操作数据量一大就会出现计算时间呈指数级别上升往往查询时间会让管理人员无法忍受。而图数据库的查询时间基本上是在几毫秒到十几毫秒之间较之传统的关系型数据库查找时间可以减少几个数量级。 我们在“源节点ID”输入框中输入第一个CI的ID如UPSG在“源节点类型”输入框中输入第一个CI的类型如ups在“宿节点ID”输入框中输入第二个CI的ID如rs-06D51ER在“宿节点类型”输入框中输入第二个CI的类型如ps。则表示需要查询ups为 UPSG和物理主机rs-06D51ER之间的关联路径在“查询深度”输入框中输入步数如10表示查询到的路径最长不超过10步。查询结果见图10。 图10 不同CI之间的影响路径查询 查询某个人管理着哪些CI 查询某个人管理着哪些CI在图数据库上就是查找和这个人有关联关系的节点和边的类型的计算。 我们在CMDB系统中在“节点ID”输入框中输入某个人的姓名在“节点类型”输入框中输入类型如person表示查找某个管理员管理着哪些CI在“最多查出多少个节点”中指定一个数如100表示最多查出100个见图11。 图11 查询某个人管理着哪些CI 类似的查询场景还有查询某个机房有哪些CI如图12所示。 图12 查询某个机房有哪些CI 查询某个IP被哪个CI使用了 查询某个IP被哪个CI使用了这是最为频繁使用的查询传统关系型数据库的查询速度应该也不会慢太多但是关键是我要从查询到的结果出发去进一步查找该CI的信息此时图数据库就可以展现出更直观的方式。在图数据库上只需要点击查询到的CI就可以从该CI出发进一步展现和该CI有关系的其他CI这种查询可以无限制地做下去直到找到管理员需要的信息如图13所示。 图13 查询某个IP正在被哪个CI使用 查询结果可以以多种直观的方式展现 图数据库对查询结果的输出可以非常灵活可以导出为.csv格式的表格性数据但更擅长的还是图形化界面的展示。 图形化界面的展示可以是多种形式例如通过力学排列、树形排列、层叠排列、环形排列等不同形式展现方便查看例图见图14、图15。 图14 力学排列CI查询结果 图15 层叠排列CI查询结果 存在的问题 CMDB已经是IT领域一个并不算新颖的话题甚至有点老生常谈但是通过图数据库来重新构建CMDB系统却给这个似乎已经步入中年的IT技术重新带来了青春。在问题管理、资产管理以及变更管理上都大大提高了既有的工作效率。 虽然如此通过图数据库来重新构建CMDB系统也存在一些待决的问题需要各个CMDB的软件厂商和项目落地的合作伙伴共同去面对和解决。 首先使用图数据库并没有解决原始数据自动化配置发现的问题。图数据库的出现大大拓展了CI的范围广度和深度将之前运维体系所不能甚至不敢涉足到的CI数据也纳入到管理系统中来同时查询性能反而得到了提高这是一个优点但是原始数据的自动化配置也是图数据库无法绕开的步骤。巧妇难为无米之炊如果没有数据再强大的平台也无能为力所以图数据库还需要配合数据自动化配置发现才能实现最佳效果 第二目前市面上基于图数据库的CMDB系统基本上都是在既有的ITSM系统上再次改造而来并没有厂商开发出原生的基于图数据库的CMDB系统。主要原因是图数据库技术还比较新传统CMDB厂商对其了解还不够深入所以现在更多的实践还是在现有CMDB基础之上的改进和补充。目前已经有一些CMDB的开发厂商正在研究如何把图数据库整合到ITSM平台中甚至完全替换掉传统的CMDB技术让我们拭目以待。 关于系统选型和配置建议 从2014年开始到现在图数据库已经在目前所有数据库模型的发展趋势中名列第一如图16所示。目前业界基于图数据库开发出来的开源软件和闭源软件都不少其中开源界最有名的是Neo4j而在闭源的商业软件则有GraphSQL——一个来自美国硅谷的品牌。 图16 db-engines.com网站对全球所有数据库模型发展趋势的评分 无论是Neo4j还是GraphSQL他们都是基于原生图存储和图引擎计算的数据库产品在原理上完全一致。在产品知名度、软件易用性上Neo4j经过多年发展已经更加深入人心但是在大型企业部署上例如高可用、高并发、可扩展性等企业级管理功能上却是GraphSQL明显胜出。 CMDB领域本身的数据量并不大关键是复杂关系的关联分析和管理。一个1000人大型企业的CI项目总计在一起一般不会超过50万个转换成图数据库中的节点和边的数据类型后一般在100万个节点左右甚至以下边的数量在1000万左右。这个数据量对图数据库而言都是小儿科一台普通的X86服务器就可以满足要求。如果出于企业级管理的需要例如高可用、热备等就要考虑部署3台左右的主机甚至异地数据中心的双集群架构。 最后关于本文中提到的技术框架问题、数据模型以及如何做到数据同步、如何实现自动化数据配置发现等问题因篇幅所限无法一一展现欢迎有兴趣的朋友和我们联系。 本文所采用的技术平台由GraphSQL提供支持在此表示感谢。 作者董小珊20年IT从业经验曾供职于HP、F5、Citrix。熟知行业应用对企业级用户的咨询、管理、挖掘有着丰富的经验。2016年作为联合创始人创办深圳安联信息技术有限公司专注于图数据库的咨询与市场。 姚臻大数据分析专家尤其是专注于图数据库领域对GraphSQL、Neo4J、InfiniteGraph等不同的开源技术和闭源产品都有比较深入的研究。 谭通大数据工程架构师多年C/C开发经验现致力于图数据库领域对图建模、业务场景算法有丰富的实践经验。 责编仲培艺关注数据库领域寻求报道或者投稿请致邮zhongpycsdn.net。 本文为《程序员》原创文章未经允许不得转载更多精彩文章请订阅2017年《程序员》
