图数据库驱动的基础设施运维实操

　　本文系图技术在大型、复杂基础设施之中SREDevOps的实践参考，并以OpenStack系统之上的图数据库增强的运维案例为例，揭示图数据库、图算法在智能运维上的应用。本文所有示例代码开源。
　　最近，有些尚未使用过图技术、DevOpsInfra领域的工程师在NebulaGraph社区询问是否有图技术在运维的应用相关案例参考。于是，我又可以借题发挥来实践下如何利用图的能力与优势去帮助运维工程师们基于复杂基础设施上构建辅助运维系统。如果你对本文有任何看法，欢迎评论区或者来论坛和我交流下，非常感谢。
　　通常，我们说的复杂的基础设施运维环境指的是资源（manifest）繁多且分布在不同层面的系统。为了让实践更加真实、贴近实际的运维情况，让运维问题复杂又可控，这里我选择了用一个基础设施平台：OpenStack。在OpenStack系统上，我分别利用Push和Pull两种模式将资源在图模型中对应点、边信息加载到NebulaGraph的GraphETL管道的路径中。
　　在我们基于运维资源构建的图谱，会做如下用例图探索：告警、状态的推理与传导；网络直连与互联关系；镜像、云盘、快照血缘管理；高相关性虚机预警；秘钥泄漏的图上风控分析；镜像、云盘漏洞范围分析；宿主机逃离影响范围分析；脆弱依赖资源检测；实验环境搭建背景知识
　　OpenStack是一个开源的云计算平台，提供了类似于AWS的云服务。它提供了一组可插拔的模块，包括了计算，存储和网络等功能，可以帮助用户构建和管理云环境。OpenStack采用分布式架构，支持多种操作系统和硬件平台，可以在企业级和服务提供企业级环境中使用。
　　最初，OpenStack是由NASA和RackspaceInc。发起的Nova（虚拟化计算项目）和Swift（兼容S3的对象存储）项目组成。随着项目的发展，OpenStack现在已经有非常多不同的子项目：
　　本次实践中涉及到OpenStack的主要项目有：Nova是OpenStack的计算服务，用于管理虚拟机；Cinder是OpenStack的块存储服务，用于管理云存储；Neutron是OpenStack的网络服务，用于管理云网络；Glance是OpenStack的镜像服务，用于管理云镜像；Horizon是OpenStack的可视化控制台服务。
　　除此之外，我还引入了Vitrage项目辅助我们收集部分资源数据：Vitrage是OpenStack的一个高级分析和可视化工具，用于分析和可视化OpenStack环境中的资源和事件。它可以汇集来自OpenStack各个服务的数据，并以可视化的方式呈现。Vitrage能发现和诊断问题，提高OpenStack环境的可用性和可维护性。
　　得益于OpenStackDecouple的设计理念，Vitrage可以很容易、无侵入式（只用修改要收集的服务的两行配置）就可以在OpenStack的消息队列中订阅资源信息的Push消息。
　　不过，介于Vitrage许久没有大更新，且维护维艰，比如：在zed里VitrageDashboard作为Horizon插件已经无法正常工作了。所以，本实践只利用它的资源收集能力。环境准备搭建NebulaGraph集群
　　快速试玩NebulaGraph的话，安装有这么几个选项：30天免费试用的阿里云上的NebulaGraph企业版，含有配套的可视化周边工具。点击使用https：market。aliyun。comisvnebulagraph有Docker环境，NebulaUp一键安装：https：github。comweygunebulaupRPM、TAR包、源码编译等安装方式，可参考文档：https：docs。nebulagraph。com。cnOpenStack集群
　　本文需要的OpenStack集群是一个多机的环境，因此我在LinuxServer上用Libvirt和LinuxBridge搭建了多个虚拟机来模拟OpenStack的物理机。得益于CPU的嵌套虚拟化和QEMU，我们完全可以在虚拟机搭建的实验环境中模拟可正常工作的OpenStackNovainstance虚机。
　　虚拟机搭建完成后，还需要模拟真实的多资源Infra环境。这边略去具体的操作步骤，感兴趣的小伙伴可以阅读本文的参考文献，当中有详细的实践过程。
　　完成OpenStack环境的搭建后，我们通过HorizonDashboard查看集群和资源：
　　虚拟机情况：
　　网盘情况，其中四个挂载在不同的虚拟机上
　　集群租户的网络拓扑：
　　通过OpenStackVitrage的APICLI可获得部分主要资源的拓扑：sourceopenrcadminadminvitragetopologyshowalltenants
　　这个结果是一个JSON，数据已经是边（links）和点（nodes）的序列化图结构了。｛directed：true，graph：｛｝，links：〔｛vitrageisdeleted：false，relationshiptype：contains，source：0，target：11，key：contains｝，｛vitrageisdeleted：false，relationshiptype：contains，source：0，target：13，key：contains｝，。。。｛vitrageisdeleted：false，relationshiptype：attached，source：27，target：28，key：attached｝〕，multigraph：true，nodes：〔｛id：node0，vitragetype：nova。host，vitragecategory：RESOURCE，vitrageisdeleted：false，updatetimestamp：20230113T08：06：48Z，vitragesampletimestamp：20230113T08：06：49Z，vitrageisplaceholder：false，vitrageid：630b4c2c5347407391a3255ec18dadfc，name：node0，vitragecachedid：d043d278a6a712909e30e50ca8ec2364，isrealvitrageid：true，vitrageaggregatedstate：AVAILABLE，vitrageoperationalstate：OK，vitragedatasourcename：nova。host，state：available，graphindex：0｝，｛id：nova，vitragetype：nova。zone，vitragecategory：RESOURCE，vitrageisdeleted：false，vitragesampletimestamp：20230112T03：06：48Z，vitrageisplaceholder：false，vitrageid：a1e9c808dac84b598f80f21a90e9869d，vitragecachedid：125f1d8c4451a6385cc2cfa2b0ba45be，isrealvitrageid：true，vitrageaggregatedstate：AVAILABLE，vitrageoperationalstate：OK，state：available，updatetimestamp：20230112T03：06：48Z，name：nova，vitragedatasourcename：nova。zone，graphindex：1｝，。。。raw：true｝图谱建模
　　将资源映射成图谱：novainstance是Nova服务中的虚拟机实例，每个novainstance都有自己的配置信息（如CPU、内存、磁盘等），有时候我们就叫它server或者VM、虚机。novahost是Nova服务中的物理主机，是novainstance运行的物理环境。novahost上面会运行novacompute服务，这个服务负责管理和调度novainstance。novahost上面还可能运行其他服务，如网络服务等。novakeypair是Nova服务中的密钥对，用于访问novainstance。cindervolume是Cinder服务中的云存储卷，可以attach到novainstance上做为硬盘。cindersnapshot是Cinder服务中的云存储快照，可以在cindervolume上做快照。glanceimage是Glance服务中的镜像，可以作为创建novainstance时候的启动硬盘。neutronnetwork是Neutron服务中的网络，可以用于配置novainstance的网络连接。neutronport是Neutron服务中的端口，用来连接novainstance和neutronnetwork之间。在novainstance虚拟机上，如果不是trunkport的话，一个port常常对应一个网卡。
　　它们之间的关系如下：
　　基础设施图ETL
　　接下来我们解决从基础设施中抽取资源元数据的问题：push模式
　　这里的push指的是以基础设施为出发点，通过事件驱动主动地发出资源变动的信息。它的好处是实时掌握资源情况，坏处是过于依赖基础设施，很多非常瘦的、软件定义可编程程度不高的组件、某些硬件设备是没有push机制的。比如：有些年份的软件系统不一定能存在push的接口，改造起来有侵入性。
　　前面提及过，OpenStack自身是存在PushHook机制的，它的子项目vitrage就利用这个机制很优雅地收集系统资源、告警等信息进入图中，类似的机制在其他平台中也是可以实现的。
　　本实验中我们就利用vitrage的机制去收集一部分图谱中的资源信息，如下图，可以看到vitrage会在OpenStackmessagebus中订阅novacinderneutron等服务中的资源时间，把事件传入EntityQueue，经过处理，存储到EntityGraph中。
　　在此之上，我们可以通过vitrageAPI获取图谱的拓扑，来消费它。
　　注意：实际上Vitrage服务还提供了推理告警、推理状态、定义决策事件的能力，这里我们并没有采用，后边我们在图上做的一些事情甚至还和它的能力有一些重叠。
　　这里我只是用它来展示push模式的工作机制，如果没有Virtrage这个项目存在，我们也可以比较容易通过OpenStack的oslo。messaging这个库很容易写出在MessageBus（可能是Kafka，RabbitMQ等不同底层实现）上订阅资源时间的应用，然后把事件通过FlinkKafkaPulsar等方式接驳NebulaGraph。
　　因为Vitrage的存在，我就偷懒不用去实现这部分逻辑，只消写一小部分代码调用VitrageAPI取这个数据就可以了，讽刺的是，从这个角度来看，这其实是一种pull的模式了，不用拘泥它本质上算是哪一种方式，至少在资源发起测，我们把它当做push模式的例子看待吧。
　　这部分从Vitrage抓取的代码我放在https：github。comweyguopenstackgraphblobmainutilsvitragetograph。py了，调用方式很简单，在有OpenStack客户端的环境中，执行它就可以了，比如：连到node0上sshstacknode0ip进入devstack目录cddevstack下载vitrage中图数据，解析为NeublaGraphDMLDQL的工具wgethttps：raw。githubusercontent。comweyguopenstackgraphmainutilsvitragetograph。py执行它python3vitragetograph。py
　　执行之后，会生成如下文件：schema。ngql图数据的Schema定义vertices点数据的文件夹edges边数据的文件夹pull模式
　　反过来，pull模式是从资源外部定期或者事件驱动地拉取资源，存入图谱的方式。刚好，本实验中Vitrage抓取的资源是有限，部分额外的资源单独写了Python的代码来主动全量抓取。pull模式的好处是对资源方没有任何侵入性，只需要调用它的接口获取信息就可以，坏处则是有的系统不太容易获得增量变化，可能只能全量去取。
　　这部分我抓取的关系如下：glanceusedby：image〔：usedby〕instance（getfrominstance）glancecreatedfrom：image〔：createdfrom〕volume（getfromimage）novakeypairusedby：keypair〔：usedby〕instance（getfrominstance）cindersnapshotcreatedfrom：volumesnapshot〔：createdfrom〕volume（getfromsnapshot）cindervolumecreatedfrom：volume〔：createdfrom〕volumesnapshot（getfromvolume）cindervolumecreatedfrom：volume〔：createdfrom〕image（getfromvolume）
　　代码在https：github。comweyguopenstackgraphblobmainutilspullresourcestograph。py。在真实场景下，我们可能会用ApacheAirflow、Dagster甚至是CronJob等方式定期执行它。
　　手动执行的方式也很简单：连到node0上sshstacknode0ip进入devstack目录cddevstack下载抓取OpenStack资源，生成NeublaGraphDMLDQL的工具wgethttps：raw。githubusercontent。comweyguopenstackgraphmainutilspullresourcestograph。py。py执行它python3pullresourcestograph。py
　　执行之后，会生成点、边的nGQL语句在两个文件夹下：vertices点数据的文件夹edges边数据的文件夹加载数据到NebulaGraph
　　我们只需要在NebulaGraphStudioConsole，ExplorerConsole或者NebulaGraph命令行Console中执行上边生成的。ngql文件就好了：DDLfromvitragecatschema。ngqlDDLandDMLforbothpushandpullmodedatacatedges。ngqlcatvertices。ngql
　　之后，在NebulaGraph中我们会有一个叫做openstack的图空间，用这个查询可以查到所有数据：MATCH（n）WITHnLIMIT1000OPTIONALMATCHp（n）（）RETURNp，n
　　在NebulaGraphExplorer中渲染，手动设置一下数据的图标，就可以看到OpenStack集群里的所有租户的资源图了：
　　接下来，我们终于可以在图上看看有意思的洞察了！基于图谱的基础设施运维示例
　　作为非SRE、DevOps人员，我尝试藉由自己在OpenStack和图技术的理解模拟出以下实例，希望对你有所帮助。告警、状态的推理与传导
　　受启发于Vitrage项目，我们可以借助资源图谱实时图查询、图计算甚至图可视化能力，在图上推理、传导信息，把重要的事件藉由图上组织好的知识分发给需要收到通知的人、组织、系统。
　　一个简单的例子，我们在novahost（虚拟机的宿主机、Hypervisor机器，以下简称宿主机）中获得了一个告警、事件的时候，可能是网卡失败、物理硬盘预警、CPU占用过高之类的告警。借助图谱查询获得所有相关联的虚机后，再把WARN级别的告警发出去或者设置它们为亚健康unhealthy状态。
　　获得通知的对象，往往是一些用户系统，它们可以根据预先定义好的策略做些自动化运维，或者通知Hook：收到宿主机CPU过高的告警情况，根据用户自己设定的不同策略把虚机迁移走，或者采用更高级、复杂的撤离方式，像是开始不接受新流量，创建新的替代workload，再优雅地关闭这个workload；控制面网络故障告警情况，这时候往往无法成功进行主机的撤离、迁移，故可以考虑触发备份主机、启动新workload、关机；其他亚健康状态，可以作为负载层面出问题的根因分析RCA依据。
　　这里给出一个在图谱上进行告警、状态传递的查询例子。假设vid为node0的宿主机出现了高CPU告警，下面这个查询可以得到所有该宿主机上的虚机，获得时间、告警通知列表：MATCH（vm：novainstance）〔：contains〕（hostCPUhigh：novahost）WHEREid（hostCPUhigh）node0RETURNvm。novainstance。nameASVMtoraiseCPUalarms
　　这条语句的查询图模式是从hostCPUhigh这个novahost向外经由contains这个关系指向vm这个novainstance的。（vm：novainstance）〔：contains〕（hostCPUhigh：novahost）
　　它的结果是：
　　VMtoraiseCPUalarms
　　server4
　　server3
　　server1
　　server0
　　如果我们把查询改动一下，选择输出全路径，则可以看到这个信息传递的方向：MATCHp（vm：novainstance）〔：contains〕（hostCPUhigh：novahost）WHEREid（hostCPUhigh）node0RETURNp
　　我们在Explorer中渲染下，点击N跳检测：
　　这个例子比较简单，甚至用不到图能力。因为一跳查询在表结构中也能很轻松地用一、两个novaAPIcall搞定。实际上，图上是可以做很多更Graphy（具有图属性的）、复杂、独特的工作的，我们慢慢来看：网络可达检测
　　考虑下这样的场景，在OpenStack中，不同的主机可以连接到相同的子网VPC，主机也可以连接到多个子网之中。这样，主机之间的网络连通性信息、与网络联通相关的推理、传导都可以在图上进行。
　　在真实世界中，这里可能还要考虑SecurityGroup、Router、Switch等因素。本示例中我们用到的OpenStack是比较简化的L2onlySetup。
　　我们要获得与虚机servera同一VPC的所有其他虚机很容易表达：MATCH（servera）（：neutronport）（：neutronnetwork）（：neutronport）（serverb：novainstance）WHEREid（servera）server0RETURNserverb。novainstance。nameASL2connectedserver
　　结果如下：
　　L2connectedserver
　　server1
　　看起来很初级，接下来我们再查询与虚机servera同一VPC、有可能通过跨网络虚机而互联的主机的所有其他虚机。这时候，我们除了共享neutronnetwork（VPC）的情况，还要查询所有二层直连的虚机可能通过其他VPC连出去的的虚机。下面的例子，我们用到了OPTIONALMATCH的表达，表示可能匹配到的模式：MATCH（servera）（：neutronport）（net：neutronnetwork）（：neutronport）（serverb：novainstance）WHEREid（servera）server0OPTIONALMATCH（serverb）（）（othernet：neutronnetwork）（：neutronport）（serverc：novainstance）WITHservera，serverbASsamesubnetmachines，servercASrouteablemachinesWHERErouteablemachines！serveraRETURNsamesubnetmachines。novainstance。nameASL2connectedserver，routeablemachines。novainstance。nameAScrossvpcserver
　　可以看到结果里，跨网络潜在的相连主机还有server3：
　　L2connectedserver
　　crossvpcserver
　　server1
　　server3
　　可视化下，同样，我们修改输出为路径p和p1。MATCHp（servera）（：neutronport）（net：neutronnetwork）（：neutronport）（serverb：novainstance）WHEREid（servera）server0OPTIONALMATCHp1（serverb）（）（othernet：neutronnetwork）（：neutronport）（serverc：novainstance）RETURNp，p1
　　它可能的连接路径一目了然了：
　　有了获得这些信息的能力，我们可以可编程地连接告警、状态、安全风控、网络等方方面面系统。当然这不是本文的重点，就不加以赘述了，你有相关的实践想要分享的话，记得来NebulaGraph社区。
　　下面，我们来看看存储相关的例子。镜像、云盘、快照的血缘
　　在基础设施中，云盘（iSCSI、Ceph、NFS）、镜像、快照之间有多重复杂的关系，比如：一个系统镜像可能从某一个虚拟机挂载的云盘或者一个快照创建一个云盘可能是从一个系统镜像、一个快照或者另一个云盘创建一个快照是从一个云盘创建的
　　这种血缘信息的识别和管理是很有必要的。下面的查询可以获得指定虚机server0的所有存储血缘：MATCHp（servera）〔：attachedcreatedfromusedby〕（step1）WHEREid（servera）server0OPTIONALMATCHp1（step1）〔：createdfrom1。。5〕（step2）RETURNp，p1
　　我们可以看到结果中：server0的启动镜像（这里它是从本地盘启动的，没有挂载云盘）是从volume1创建的；volume1是从cirros0。5。2x8664disk这个镜像创建的；
　　此外，还有其他有分叉关系的存储资源和它们也息息相关：
　　下面，我们不只考虑存储资源，看下涉及云盘cindervolume挂载attached这层关系下的血缘关系：MATCHp（servera）〔：attachedcreatedfromusedby〕（step1）WHEREid（servera）server4OPTIONALMATCHp1（step1）〔：createdfromattached1。。5〕（step2）RETURNp，p1
　　我们可以从渲染图中读出这样的洞察：server4的启动镜像（这里它是从本地盘启动的）是从volume1创建的而volume1现在挂载在server6上volume1是从cirros0。5。2x8664disk这个镜像创建的同样cirros0。5。2x8664disk镜像被很多其他虚机在采用server4同时挂载了数据盘volume2而volume2是一个多挂载的盘，它同时挂载在server3之上server3的系统启动盘是从快照snapshot202301111800volume1克隆创建的快照snapshot202301111800volume1是曾经从volume1创建的volume1现在挂载在server6上，快照不一定是从server6而来，因为镜像可能被重新挂载过。而这些血缘信息可以被用在资源生命周期管理、根因分析、安全告警、状态传递上，这里不加以赘述。高相关性虚机预警
　　下面这个例子，会给出一个节点相似度的应用。在全图或者子图上，利用图算法找到与指定虚机图拓扑结构最相似的其他虚机，并在这种相关性基础上增加新的关系，做风险事件预警。
　　本次实践，我们会按照一个典型的从快速子图验证到全图生产应用的工作流。子图快速验证：浏览器内算法
　　从server0的三度子图上做算法的验证：GETSUBGRAPH3STEPSFROMserver0YIELDVERTICESASnodes，EDGESASrelationships；
　　将结果渲染在画布上，我们可以看到子图中包含了其他几个虚机：
　　我们利用Explorer中的浏览器内图算法，可以非常方便地验证我们的想法。这里，我们使用JaccardSimilarity相似性算法，让server0与server1，server3，server4，server6迭代分别得到相似性：
　　可以看出，在3步子图内，和server0最近接的虚机是server4。进一步，我们可以简单在子图上看看两者之间的路径作为相似性的解释：
　　在这个可解释结果中，我们知道server0与server4相似的原因可能是：坐落在同一个宿主机：node0使用同一个镜像：cirrosmodfromvolume1
　　因此，我们最终落地的预警机制可能是，当server0出现某一问题、告警时候，给相似的server4也设定预警，预警理由就是它们在同样主机、同样镜像。全图生产应用
　　有了上面的快速实验，借助WorkflowNebulaGraphAnalytics把它落地为全图上的算法，利用Analytics分布式能力去执行。
　　在生产上，我们利用Workflow的DAG编排能力，创建两个前后相连的任务：取临近虚机全图算相似度
　　第一个任务如下，实时从指定虚机出发给出其他虚机vid。这里查询语句写死了server0，但是在Workflow里可以参数化，并封装任务为可被API触发的异步服务：MATCH（n）〔1。。5〕（m：novainstance）WHEREid（n）server0ANDn！mRETURNdistinctid（m）
　　而在JaccardSimilarityJob中，我们选择ids1为server0，ids2从上游（上面的QueryJob）取，选择在OpenStack全图扫描所有边类型。
　　保存、运行。结果如下，这次它运算了更多的目标虚机，并且迭代作用范围是全图而非一个子图。可以看到同上次的结果是一样，因为子图上关联度大的点和相近的边在Jaccard算法里起到了更主要的作用。
　　安全相关场景
　　基础设施资源中的关联关系和金融、内容系统、电商领域的风控场景有相似的地方，很多场景本质上利用到了图谱关系中的知识，在图库上实时获取这些复杂但又天然可解释的安全洞察。秘钥泄漏风控分析
　　先看一个秘钥泄漏的场景：假设key0被安全部门确定被泄漏了，我们可以在毫秒内获得如下查询：直接使用该密钥的虚机与使用该秘钥的虚机网络直连的机器与使用该秘钥的虚机跨网络相连的机器MATCH（keyleaked）〔：usedby〕（involvedserver：novainstance）（：neutronport）（net：neutronnetwork）（：neutronport）（serverb：novainstance）WHEREid（keyleaked）key0OPTIONALMATCH（serverb）（）（othernet：neutronnetwork）（：neutronport）（serverc：novainstance）WITHinvolvedserver，serverbASsamesubnetmachines，servercAScrossnetmachinesWHEREcrossnetmachines！involvedserverRETURNinvolvedserver。novainstance。nameASwithkey，samesubnetmachines。novainstance。nameASl2vms，crossnetmachines。novainstance。nameAScrossvpcvms
　　贴一下部分结果，我们知道server4采用了这个keypair，并且server6和它在同一个网络。同时，有一定几率通过server6、server1、server2、server0、server5也受到了影响。针对这种情况，相关的机器可以设置不同告警级别来降低安全事故的影响。
　　withkey
　　l2vms
　　crossvpcvms
　　server4
　　server6
　　server1
　　server4
　　server6
　　server2
　　server4
　　server6
　　server0
　　server4
　　server6
　　server5
　　这个查询改造为可视化结果：MATCHp（keyleaked）〔：usedby〕（involvedserver：novainstance）（：neutronport）（net：neutronnetwork）（：neutronport）（serverb：novainstance）WHEREid（keyleaked）key0OPTIONALMATCHp1（serverb）（）（othernet：neutronnetwork）（：neutronport）（serverc：novainstance）RETURNp，p1
　　在Explorer中应用DagreLR的布局，相关的关联关系可以很清晰地被展示出来。介于可视化展示的直观性，我们可以考虑把这个图放入安全报告，随同其他安全信息一同分发给虚机租户。
　　镜像、云盘漏洞范围分析
　　类似的，一个镜像被扫出漏洞，我们可以瞬间查到波及的资源，并做出相应应对之策。
　　镜像文件有漏洞：MATCHp（imagerisky）〔：createdfrom〕（step1）WHEREid（imagerisky）cirros0。5。2x8664diskOPTIONALMATCHp1（step1）〔：createdfrom1。。5〕（step2）RETURNp，p1
　　某个云盘有漏洞：MATCHp（volumerisky）〔：createdfrom〕（step1）WHEREid（volumerisky）volume1OPTIONALMATCHp1（step1）〔：createdfrom1。。5〕（step2）RETURNp，p1
　　潜在宿主机逃离影响范围分析
　　最后，我们讨论一个严重的安全问题：宿主机逃离。
　　在极端的情况下，server0发生了有可能影响宿主机的安全事件，此时仅仅关闭这个宿主机是不够的，因为受影响的范围可能已经扩大。但我们又不能因为这样不知影响范围多广的安全事件来关闭整个机房。所以，利用图谱辅助找出受影响范围就非常有用了。
　　下面的查询模式是：找出可能被影响的子网（VPC），标记最高级别风险子网为后续定位做准备找到可能被控制了的宿主机从宿主机触发，找出同主机的其他虚机从其他虚机触发，找到它们的子网（VPC）从其他虚机触发，找到可能已经被影响的网盘。这是为了防止被挂载到其他机器，这会扩大影响。MATCH（serverescapinghypervisor）〔：contains〕（hypervisorcompromised：novahost）WHEREid（serverescapinghypervisor）server0OPTIONALMATCH（serverescapinghypervisor）〔：attached〕（：neutronport）〔：contains〕（impactedsubnethigh：neutronnetwork）OPTIONALMATCH（hypervisorcompromised）〔：contains〕（serversamehost：novainstance）OPTIONALMATCH（serversamehost）〔：attached〕（：neutronport）〔：contains〕（impactedsubnet：neutronnetwork）OPTIONALMATCH（serversamehost）〔：attached〕（impactedvolume：cindervolume）RETURNimpactedsubnethigh。neutronnetwork。nameASimpactedsubnethigh，hypervisorcompromised。novahost。nameAShypervisorcompromised，impactedsubnet。neutronnetwork。nameASimpactedsubnet，〔serversamehost。novainstance。name，serversamehost。novainstance。instancename〕ASserversamehost，impactedvolume。cindervolume。nameASimpactedvolume
　　下面的结果集中，列出了server0被控制之后，考虑宿主机逃离的情况下可能受影响的扩散范围。
　　impactedsubnethigh
　　hypervisorcompromised
　　impactedsubnet
　　serversamehost
　　impactedvolume
　　shared
　　node0
　　shared
　　〔server0，instance00000001〕
　　Empty
　　shared
　　node0
　　shared
　　〔server1，instance00000002〕
　　ffaeb19947f44d9589b297fba3c1bcfe
　　shared
　　node0
　　private
　　〔server1，instance00000002〕
　　ffaeb19947f44d9589b297fba3c1bcfe
　　shared
　　node0
　　private
　　〔server3，instance00000005〕
　　c9db7c2ec71249d6801914b82de8542d
　　shared
　　node0
　　private
　　〔server3，instance00000005〕
　　volume2
　　shared
　　node0
　　public
　　〔server4，instance00000006〕
　　volume2
　　咱们再看看它的可视化结果。MATCHp（serverescapinghypervisor）〔：contains〕（hypervisorcompromised：novahost）WHEREid（serverescapinghypervisor）server0OPTIONALMATCHp0（serverescapinghypervisor）〔：attached〕（：neutronport）〔：contains〕（impactedsubnethigh：neutronnetwork）OPTIONALMATCHp1（hypervisorcompromised）〔：contains〕（serversamehost：novainstance）OPTIONALMATCHp2（serversamehost）〔：attached〕（：neutronport）〔：contains〕（impactedsubnet：neutronnetwork）OPTIONALMATCHp3（serversamehost）〔：attached〕（impactedvolume：cindervolume）RETURNp，p0，p1，p2，p3
　　还是和之前一样，我们在可视化图探索工具Explorer中选择Dagre布局，它能比较清晰看出影响资源的范围。从这些可能受影响的虚机、网络、网盘出发，可以进一步采取需要的安全措施了。
　　重点关注资源检测
　　最后，利用BetweennessCentrality算法，我们可以获得基础设施中影响面大的那些脆弱环节。这些资源不一定真的处在危险的状态，只是说，它们处在了比较重要的资源之间的交汇处，一旦它们出问题，出问题的代价可能会非常大。
　　因此，识别关键资源后，我们可以考虑下面的安全机制：有针对性采用更激进、昂贵的健康检查策略；设定更高的支持、关注级别；主动迁移相关联的资源，以降低脆弱环节对整体基础设施可用性的影响范围；
　　在这里，我们只在浏览器内部的子图上做算法流程验证。机智的你，可以自己试着利用开源的NebulaGraphAlgorithm或者付费的NebulaGraphWorkflowAnalytics做全图上的等价操作。
　　首先，我们用之前的方式去扫描图上1，000个点，并且从它们出发，跳一跳，获得一个比较随机的子图。实际上，由于我们的数据集并不是很大，这个操作是捞取了全图的数据：OPTIONALMATCHp（n）（）RETURNp，n
　　随机子图搞定之后，我们运行BetweennessCentrality算法，得到node0是分值最大的脆弱一环。的确，它是我们当前实验中负载最大的宿主机，可以想象它确实是故障之后全局影响最大的一个资源。
　　总结
　　在海量数据、企业云、混合云的复杂基础设施运维场景下，利用图数据库图算法的能力做高效的辅助运维工作是一个十分值得的尝试与技术投资。
　　NebulaGraph作为高性能、开源、分布式的新一代云原生图数据库，是一个很值得考虑的图基础设施选型目标。
　　欢迎大家在文末留言讨论，本文的可复现环境和示例的ETL管道的代码、示例数据全都在https：github。comweyguopenstackgraph开源，欢迎大家来一起完善。
　　本文用到的可视化图探索工具为NebulaGraphExplorer，目前可以免费试用30天。
　　此外，我把本实验中的图谱放在了NebulaGraphStudioExplorer的示例数据集中，大家也可以在里边下载试玩。参考文献OpenStack环境搭建：https：github。comweyguopenstackgraphenvironmentsetupInfra资源创建：https：github。comweyguopenstackgraphcreateresourcesonopenstackVitrage示例文档：https：github。comopenstackvitrageblobmasterdocsourcecontributorvitragetemplates。rst
　　谢谢你读完本文（）
　　NebulaGraphDesktop，Windows和macOS用户安装图数据库的绿色通道，10s拉起搞定海量数据的图服务。通道传送门：http：c。nxw。so7CcNV
　　想看源码的小伙伴可以前往GitHub阅读、使用、（）star它