图数据库驱动的基础设施运维示例

- 尝试情况搭建

- 布景常识

- 情况预备搭建

- NebulaGraph 集群

- OpenStack 集群

- 图谱建模

- 根底设备图 ETL

- push 形式

- pull 形式

- 加载数据到 NebulaGraph

- 基于图谱的根底设备运维示例

- 告警、形态的推理与传导

- 收集可达检测

- 镜像、云盘、快照的血缘

- 高相关性虚机预警

- 子图快速验证：阅读器内算法

- 全图消费利用

- 平安相关场景

- 秘钥泄露风控阐发

- 镜像、云盘破绽范畴阐发

- 潜在宿主机逃离影响范畴阐发

- 重点存眷资本检测

- 总结

- 参考文献

本文系图手艺在大型、复杂根底设备之中 SRE / DevOps 的理论参考，并以 OpenStack 系统之上的图数据库加强的运维案例为例，显示图数据库、图算法在智能运维上的利用。本文所有示例代码开源。

比来，有些尚未利用过图手艺、DevOps / Infra 范畴的工程师在 NebulaGraph 社区询问能否有「图手艺在运维的利用」相关案例参考。于是，我又能够“借题发扬”来理论下若何操纵图的才能与优势往搀扶帮助运维工程师们基于复杂根底设备上构建辅助运维系统。假设你对本文有任何观点，欢送评论区或者来论坛 /交换，十分感激。

凡是，我们说的复杂的根底设备运维情况指的是资本（manifest）繁多且散布在差别层面的系统。为了让理论愈加实在、切近现实的运维情状，让运维问题复杂又可控，那里我抉择了用一个根底设备平台：OpenStack。在 OpenStack 系统上，我别离操纵 Push 和 Pull 两种形式将资本在图模子中对应点、边信息加载到 NebulaGraph 的 Graph ETL 管道的途径中。

在我们基于运维资本构建的图谱，会做如下用例图摸索：

告警、形态的推理与传导；

收集曲连与互联关系；

镜像、云盘、快照血缘治理；

高相关性虚机预警；

秘钥泄露的图优势控阐发；

镜像、云盘破绽范畴阐发；

宿主机逃离影响范畴阐发；

懦弱依靠资本检测；

尝试情况搭建

布景常识

01

OpenStack 是一个开源的云计算平台，供给了类似于 AWS 的云办事。它供给了一组可插拔的模块，包罗了计算，存储和收集等功用，能够搀扶帮助用户构建和治理云情况。OpenStack 摘用散布式架构，撑持多种操做系统和硬件平台，能够在企业级和办事供给企业级情况中利用。

最后，OpenStack 是由 NASA 和 Rackspace Inc. 倡议的 Nova（虚拟化计算项目）和 Swift（兼容 S3 的对象存储）项目构成。跟着项目标开展，OpenStack 如今已经有十分多差别的子项目：

本次理论中涉及到 OpenStack 的次要项目有：

Nova 是 OpenStack 的计算办事，用于治理虚拟机；

Cinder 是 OpenStack 的块存储办事，用于治理云存储；

Neutron 是 OpenStack 的收集办事，用于治理云收集；

Glance 是 OpenStack 的镜像办事，用于治理云镜像；

Horizon 是 OpenStack 的可视化掌握台办事。

除此之外，我还引进了 Vitrage 项目辅助我们搜集部门资本数据：

Vitrage 是 OpenStack 的一个高级阐发和可视化东西，用于阐发和可视化 OpenStack 情况中的资本和事务。它能够搜集来自 OpenStack 各个办事的数据，并以可视化的体例闪现。Vitrage 能发现和诊断问题，进步 OpenStack 情况的可用性和可庇护性。

得益于 OpenStack Decouple 的设想理念，Vitrage 能够很随便、无侵略式（只用修改要搜集的办事的两行设置装备摆设）就能够在 OpenStack 的动静队列中订阅资本信息的 Push 动静。

不外，介于 Vitrage 许久没有大更新，且庇护维艰，好比：在 zed 里 Vitrage Dashboard 做为 Horizon 插件已经无法一般工做了。所以，本理论只操纵它的资本搜集才能。

情况预备搭建

02

NebulaGraph 集群

快速试玩 NebulaGraph 的话，安拆有那么几个选项：

30 天免费试用的阿里云上的 NebulaGraph 企业版，含有配套的可视化周边东西。复造链接开启试用👉：

有 Docker 情况，Nebula-Up 一键安拆：

RPM、TAR 包、源码编译等安拆体例，可参考文档：

/

OpenStack 集群

本文需要的 OpenStack 集群是一个多机的情况，因而我在 Linux Server 上用 Libvirt 和 Linux Bridge 搭建了多个虚拟机来模仿 OpenStack 的物理机。得益于 CPU 的嵌套虚拟化和 QEMU，我们完全能够在虚拟机搭建的尝试情况中模仿可一般工做的 OpenStack Nova instance 虚机。

虚拟机搭建完成后，还需要模仿实在的多资本 Infra 情况。那边略往详细的操做步调，感兴致的小伙伴能够阅读本文的参考文献，傍边有详尽的理论过程。

完成 OpenStack 情况的搭建后，我们通过 Horizon Dashboard 查看集群和资本：

虚拟机情状：

网盘情状，此中四个挂载在差别的虚拟机上

集群租户的收集拓扑：

通过 OpenStack Vitrage 的 API/CLI 可获得部门次要资本的拓扑：

sourceopenrc admin admin

vitrage topology show --all-tenants

那个成果是一个 JSON，数据已经是边（links）和点（nodes）的序列化图构造了。

"directed": true,

"graph": {},

"links": [

"vitrage_is_deleted": false,

"relationship_type": "contains",

"source": 0,

"target": 11,

"key": "contains"

"vitrage_is_deleted": false,

"relationship_type": "contains",

"source": 0,

"target": 13,

"key": "contains"

"vitrage_is_deleted": false,

"relationship_type": "attached",

"source": 27,

"target": 28,

"key": "attached"

"multigraph": true,

"nodes": [

"id": "node0",

"vitrage_type": "nova.host",

"vitrage_category": "RESOURCE",

"vitrage_is_deleted": false,

"update_timestamp": "2023-01-13T08:06:48Z",

"vitrage_sample_timestamp": "2023-01-13T08:06:49Z",

"vitrage_is_placeholder": false,

"vitrage_id": "630b4c2c-5347-4073-91a3-255ec18dadfc",

"name": "node0",

"vitrage_cached_id": "d043d278a6a712909e30e50ca8ec2364",

"is_real_vitrage_id": true,

"vitrage_aggregated_state": "AVAILABLE",

"vitrage_operational_state": "OK",

"vitrage_datasource_name": "nova.host",

"state": "available",

"graph_index": 0

"id": "nova",

"vitrage_type": "nova.zone",

"vitrage_category": "RESOURCE",

"vitrage_is_deleted": false,

"vitrage_sample_timestamp": "2023-01-12T03:06:48Z",

"vitrage_is_placeholder": false,

"vitrage_id": "a1e9c808-dac8-4b59-8f80-f21a90e9869d",

"vitrage_cached_id": "125f1d8c4451a6385cc2cfa2b0ba45be",

"is_real_vitrage_id": true,

"vitrage_aggregated_state": "AVAILABLE",

"vitrage_operational_state": "OK",

"state": "available",

"update_timestamp": "2023-01-12T03:06:48Z",

"name": "nova",

"vitrage_datasource_name": "nova.zone",

"graph_index": 1

"raw": true

图谱建模

将资本映射成图谱：

nova instance 是 Nova 办事中的虚拟机实例，每个 nova instance 都有本身的设置装备摆设信息（如 CPU、内存、磁盘等），有时候我们就喊它 server 或者 VM、虚机。

nova host 是 Nova 办事中的物理主机，是 nova instance 运行的物理情况。nova host 上面会运行 nova-compute 办事，那个办事负责治理和调度 nova instance。nova host 上面还可能运行其他办事，如收集办事等。

nova keypair 是 Nova 办事中的密钥对，用于拜候 nova instance。

cinder volume 是 Cinder 办事中的云存储卷，能够 attach 到 nova instance 上做为硬盘。

cinder snapshot 是 Cinder 办事中的云存储快照，能够在 cinder volume 上做快照。

glance image 是 Glance 办事中的镜像，能够做为创建 nova instance 时候的启动硬盘。

neutron network 是 Neutron 办事中的收集，能够用于设置装备摆设 nova instance 的收集毗连。

neutron port 是 Neutron 办事中的端口，用来毗连 nova instance 和 neutron network 之间。在 nova instance 虚拟机上，假设不是 trunk port 的话，一个 port 经常对应一个网卡。

它们之间的关系如下：

根底设备图 ETL

接下来我们处理从根底设备中抽取资本元数据的问题：

push 形式

01

那里的 push 指的是以根底设备为起点，通过事务驱动主动地发出资本变更的信息。它的益处是实时掌握资本情状，害处是过于依靠根底设备，良多十分瘦的、软件定义 / 可编程水平不高的组件、某些硬件设备是没有 push 机造的。好比：有些年份的软件系统纷歧定能存在 push 的接口，革新起来有侵略性。

前面提及过，OpenStack 本身是存在 Push Hook 机造的，它的子项目 vitrage 就操纵那个机造很文雅地搜集系统资本、告警等信息进进图中，类似的机造在其他平台中也是能够实现的。

本尝试中我们就操纵 vitrage 的机造往搜集一部门图谱中的资本信息，如下图，能够看到 vitrage 会在 OpenStack message bus 中订阅 nova / cinder / neutron 等办事中的资本时间，把事务传进 Entity Queue，颠末处置，存储到 Entity Graph 中。

在此之上，我们能够通过 vitrage API 获取图谱的拓扑，来消费它。

重视：现实上 Vitrage 办事还供给了推理告警、推理形态、定义决策事务的才能，那里我们并没有摘用，后边我们在图上做的一些工作以至还和它的才能有一些堆叠。

那里我只是用它来展现 push 形式的工做机造，假设没有 Virtrage 那个项目存在，我们也能够比力随便通过 OpenStack 的 oslo.messaging 那个库很随便写出在 Message Bus（可能是 Kafka, RabbitMQ 等差别底层实现）上订阅资本时间的利用，然后把事务通过 Flink / Kafka / Pulsar 等体例接驳 NebulaGraph。

因为 Vitrage 的存在，我就偷懒不消往实现那部门逻辑，只消写一小部门代码挪用 Vitrage API 取那个数据就能够了，挖苦的是，从那个角度来看，那其实是一种 pull 的形式了，不消拘泥它素质上算是哪一种体例，至少在资本倡议测，我们把它当做 push 形式的例子对待吧。

那部门从 Vitrage 挠取的代码我放在 客户端的情况中，施行它就能够了，好比：

# 连到 node0 上

ssh stack@node0_ip

# 进进 devstack 目次

cddevstack

# 下载 vitrage 中图数据，解析为 NeublaGraph DML/DQL 的东西

wget

# 施行它

python3 vitrage_to_graph.py

施行之后，会生成如下文件：

schema.ngql

图数据的 Schema 定义

vertices/

点数据的文件夹

edges/

边数据的文件夹

pull 形式

02

反过来，pull 形式是从资本外部按期或者事务驱动地拉取资本，存进图谱的体例。刚好，本尝试中 Vitrage 挠取的资本是有限，部门额外的资本零丁写了 Python 的代码来主动全量挠取。pull 形式的益处是对资本方没有任何侵略性，只需要挪用它的接口获取信息就能够，害处则是有的系统不太随便获得增量改变，可能只能全量往取。

那部门我挠取的关系如下：

glance_used_by：

image -[:used_by]- instance (get from instance)

glance_created_from：

image -[:created_from]- volume (get from image)

nova_keypair_used_by：

keypair -[:used_by]- instance (get from instance)

cinder_snapshot_created_from：

volume snapshot -[:created_from]- volume (get from snapshot)

cinder_volume_created_from：

volume -[:created_from]- volume snapshot (get from volume)

cinder_volume_created_from：

volume -[:created_from]- image (get from volume)

代码在 等体例按期施行它。

手动施行的体例也很简单：

# 连到 node0 上

ssh stack@node0_ip

# 进进 devstack 目次

cddevstack

# 下载挠取 OpenStack 资本，生成 NeublaGraph DML/DQL 的东西

wget

# 施行它

python3 pull_resources_to_graph.py

施行之后，会生成点、边的 nGQL 语句在两个文件夹下：

vertices/

点数据的文件夹

edges/

边数据的文件夹

加载数据到 NebulaGraph

03

加载数据到 NebulaGraph

我们只需要在 NebulaGraph Studio Console，Explorer Console 或者 NebulaGraph 号令行 Console 中施行上边生成的 .ngql文件就好了：

# DDL from vitrage

cat schema.ngql

# DDL and DML for both push and pull mode data

cat edges/*.ngql

cat vertices/*.ngql

之后，在 NebulaGraph 中我们会有一个喊做 openstack 的图空间，用那个查询能够查到所有数据：

MATCH (n) WITH n LIMIT 1000

OPTIONAL MATCH p=(n)--

RETURN p, n

在 NebulaGraph Explorer 中衬着，手动设置一下数据的图标，就能够看到 OpenStack 集群里的所有租户的资本图了：

接下来，我们末于能够在图上看看有意思的洞察了！

基于图谱的根底设备运维示例

做为非 SRE、DevOps 人员，我测验考试藉由本身在 OpenStack 和图手艺的理解模仿出以下实例，期看对你有所搀扶帮助。

告警、形态的推理与传导

01

受启发于 Vitrage 项目，我们能够借助资本图谱实时图查询、图计算以至图可视化才能，在图上推理、传导信息，把重要的事务藉由图上组织好的常识分发给需要收到通知的人、组织、系统。

一个简单的例子，我们在 nova host（虚拟机的宿主机、Hypervisor 机器，以下简称宿主机）中获得了一个告警、事务的时候，可能是网卡失败、物理硬盘预警、CPU 占用过高之类的告警。借助图谱查询获得所有相联系关系的虚机后，再把 WARN 级此外告警发出往或者设置它们为亚安康 unhealthy 形态。

获得通知的对象，往往是一些用户系统，它们能够根据预先定义好的战略做些主动化运维，或者通知 Hook：

收到“宿主机 CPU 过高”的告警情状，根据用户本身设定的差别战略把虚机迁徙走，或者摘用更高级、复杂的撤离体例，像是起头不承受新流量，创建新的替代 workload，再文雅地封闭那个 workload；

“掌握面收集毛病”告警情状，那时候往往无法胜利停止主机的撤离、迁徙，故能够考虑触发备份主机、启动新 workload、关机；

其他“亚安康形态”，能够做为负载层面出问题的根因阐发 RCA 根据。

那里给出一个在图谱长进行告警、形态传递的查询例子。假设 vid 为 node0的宿主机呈现了高 CPU 告警，下面那个查询能够得到所有该宿主机上的虚机，获得时间、告警通知列表：

MATCH (vm:nova_instance)-[:`contains`]-(host_CPU_high:nova_host)

WHERE id(host_CPU_high) == "node0"

RETURN vm.nova_instance.name AS VM_to_raise_CPU_alarms

那条语句的查询图形式是从 host_CPU_high那个 nova_host向外经由 contains那个关系指向 vm那个 nova_instance的。

(vm:nova_instance)-[:`contains`]-(host_CPU_high:nova_host)

它的成果是：

VM_to_raise_CPU_alarms

server-4

server-3

server-1

server-0

假设我们把查询改动一下，抉择输出全途径，则能够看到那个信息传递的标的目的：

MATCH p=(vm:nova_instance)-[:`contains`]-(host_CPU_high:nova_host)

WHERE id(host_CPU_high) == "node0"

RETURN p

我们在 Explorer 中衬着下，点击 N 跳检测：

那个例子比力简单，以至用不到图才能。因为一跳查询在表构造中也能很轻松地用一、两个 nova API call 搞定。现实上，图上是能够做良多更 Graphy（具有图属性的）、复杂、特殊的工做的，我们渐渐来看：

收集可达检测

02

考虑下如许的场景，在 OpenStack 中，差别的主机能够毗连到不异的子网 VPC，主机也能够毗连到多个子网之中。如许，主机之间的收集连通性信息、与收集联通相关的推理、传导都能够在图长进行。

在实在世界中，那里可能还要考虑 Security Group、Router、Switch 等因素。本示例中我们用到的 OpenStack 是比力简化的 L2 only Setup。

我们要获得与虚机 server_a统一 VPC 的所有其他虚机很随便表达：

MATCH (server_a)--(:neutron_port)--(:neutron_network)--(:neutron_port)--(server_b:`nova_instance`)

WHERE id(server_a) == "server-0"

RETURN server_b.nova_instance.name AS L2_connected_server

成果如下：

L2_connected_server

server-1

看起来很初级，接下来我们再查询与虚机 server_a统一 VPC、有可能通过跨收集虚机而互联的主机的所有其他虚机。那时候，我们除了共享 neutron network(VPC) 的情状，还要查询所有二层曲连的虚机可能通过其他 VPC 连出往的的虚机。下面的例子，我们用到了 OPTIONAL MATCH的表达，表达可能婚配到的形式：

MATCH (server_a)--(:neutron_port)--(net:neutron_network)--(:neutron_port)--(server_b:`nova_instance`)

WHERE id(server_a) == "server-0"

OPTIONAL MATCH (server_b)----(other_net:neutron_network)--(:neutron_port)--(server_c:`nova_instance`)

WITH server_a, server_b AS same_subnet_machines, server_c AS routeable_machines WHERE routeable_machines != server_a

RETURN same_subnet_machines.nova_instance.name AS L2_connected_server,

routeable_machines.nova_instance.name AS cross_vpc_server

能够看到成果里，跨收集潜在的相连主机还有 server-3：

L2_connected_server

cross_vpc_server

server-1

server-3

可视化下，同样，我们修改输出为途径 p和 p1。

MATCH p=(server_a)--(:neutron_port)--(net:neutron_network)--(:neutron_port)--(server_b:`nova_instance`)

WHERE id(server_a) == "server-0"

OPTIONAL MATCH p1=(server_b)----(other_net:neutron_network)--(:neutron_port)--(server_c:`nova_instance`)

RETURN p, p1

它可能的毗连途径一目了然了：

有了获得那些信息的才能，我们能够可编程地毗连告警、形态、平安风控、收集等方方面面系统。当然那不是本文的重点，就不加以赘述了，你有相关的理论想要分享的话，记得来 NebulaGraph 社区。

下面，我们来看看存储相关的例子。

镜像、云盘、快照的血缘

03

在根底设备中，云盘（iSCSI、Ceph、NFS）、镜像、快照之间有多反复杂的关系，好比：

一个系统镜像可能从某一个虚拟机挂载的云盘或者一个快照创建

一个云盘可能是从一个系统镜像、一个快照或者另一个云盘创建

一个快照是从一个云盘创建的

那种血缘信息的识别和治理是很有需要的。下面的查询能够获得指定虚机 server-0的所有存储血缘：

MATCH p=(server_a)-[:`attached`|created_from|used_by]-(step1)

WHERE id(server_a) == "server-0"

OPTIONAL MATCH p1=(step1)-[:created_from*1..5]-(step2)

RETURN p, p1

我们能够看到成果中：

server-0

的启动镜像（那里它是从当地盘启动的，没有挂载云盘）是从 volume-1 创建的；

volume-1

是从

cirros-0.5.2-x86_64-disk

那个镜像创建的；

此外，还有其他有分叉关系的存储资本和它们也息息相关：

下面，我们不但考虑存储资本，看下涉及云盘 cinder_volume 挂载 attached 那层关系下的血缘关系：

MATCH p=(server_a)-[:`attached`|created_from|used_by]-(step1)

WHERE id(server_a) == "server-4"

OPTIONAL MATCH p1=(step1)-[:created_from|attached*1..5]-(step2)

RETURN p, p1

我们能够从衬着图中读出如许的洞察：

server-4

的启动镜像（那里它是从当地盘启动的）是从

volume-1

创建的

而

volume-1

如今挂载在

server-6

上

volume-1

是从

cirros-0.5.2-x86_64-disk

那个镜像创建的

同样

cirros-0.5.2-x86_64-disk

镜像被良多其他虚机在摘用

server-4

同时挂载了数据盘

volume-2

而

volume-2

是一个多挂载的盘，它同时挂载在

server-3

之上

server-3

的系统启动盘是从快照

snapshot-202301111800-volume-1

克隆创建的

快照

snapshot-202301111800-volume-1

是曾经从

volume-1

创建的

volume-1

如今挂载在

server-6

上，快照纷歧定是从

server-6

而来，因为镜像可能被从头挂载过。而那些血缘信息能够被用在资本生命周期治理、根因阐发、平安告警、形态传递上，那里不加以赘述。

高相关性虚机预警

04

下面那个例子，会给出一个节点类似度的利用。在全图或者子图上，操纵图算法找到与指定虚机图拓扑构造最类似的其他虚机，并在那种相关性根底上增加新的关系，做风险事务预警。

本次理论，我们会根据一个典型的从「快速子图验证」到「全图消费利用」的工做流。

子图快速验证：阅读器内算法

从 server-0的三度子图上做算法的验证：

GET SUBGRAPH 3 STEPS FROM "server-0"

YIELD VERTICES AS nodes, EDGES AS relationships;

将成果衬着在画布上，我们能够看到子图中包罗了其他几个虚机：

我们操纵 Explorer 中的阅读器内图算法，能够十分便利地验证我们的设法。那里，我们利用 Jaccard Similarity 类似性算法，让 server-0与 server-1,server-3,server-4,server-6迭代别离得到类似性：

能够看出，在 3 步子图内，和 server-0比来接的虚机是 server-4。进一步，我们能够简单在子图上看看两者之间的途径做为类似性的阐明：

在那个可阐明成果中，我们晓得 server-0与 server-4类似的原因可能是：

坐落在统一个宿主机：node-0

利用统一个镜像：cirros_mod_from_volume-1

因而，我们最末落地的预警机造可能是，当 server-0呈现某一问题、告警时候，给类似的 server-4也设定预警，预警理由就是它们在同样主机、同样镜像。

全图消费利用

有了上面的快速尝试，借助 Workflow + NebulaGraph Analytics 把它落地为全图上的算法，操纵 Analytics 散布式才能往施行。

在消费上，我们操纵 Workflow 的 DAG 编排才能，创建两个前后相连的使命：

取临近虚机

全图算类似度

第一个使命如下，实时从指定虚机动身给出其他虚机 vid。那里查询语句写死了 server-0，但是在 Workflow 里能够参数化，并封拆使命为可被 API 触发的异步办事：

MATCH (n)-[*1..5]-(m:`nova_instance`)

WHERE id(n) == "server-0" AND n != m

RETURN distinct id(m)

而在 Jaccard Similarity Job 中，我们抉择 ids1 为 server-0，ids2 从上游（上面的 Query Job）取，抉择在 OpenStack 全图扫描所有边类型。

保留、运行。成果如下，此次它运算了更多的目标虚机，而且迭代感化范畴是全图而非一个子图。能够看到同前次的成果是一样，因为子图上联系关系度大的点和附近的边在 Jaccard 算法里起到了更次要的感化。

平安相关场景

05

根底设备资本中的联系关系关系和金融、内容系统、电商范畴的风控场景有类似的处所，良多场景素质上操纵到了图谱关系中的常识，在图库上实时获取那些复杂但又天然可阐明的平安洞察。

秘钥泄露风控阐发

先看一个秘钥泄露的场景：假设 key-0被平安部分确定被泄露了，我们能够在毫秒内获得如下查询：

间接利用该密钥的虚机

与利用该秘钥的虚机收集曲连的机器

与利用该秘钥的虚机跨收集相连的机器

MATCH (key_leaked)-[:`used_by`]-(involved_server:nova_instance)--(:neutron_port)--(net:neutron_network)--(:neutron_port)--(server_b:nova_instance)

WHERE id(key_leaked) == "key-0"

OPTIONAL MATCH (server_b)----(other_net:neutron_network)--(:neutron_port)--(server_c:nova_instance)

WITH involved_server, server_b AS same_subnet_machines, server_c AS cross_net_machines

WHERE cross_net_machines != involved_server

RETURN involved_server.nova_instance.name AS with_key,

same_subnet_machines.nova_instance.name AS l2_vms,

cross_net_machines.nova_instance.name AS cross_vpc_vms

贴一下部门成果，我们晓得 server-4 摘用了那个 keypair，而且 server-6 和它在统一个收集。同时，有必然几率通过 server-6、server-1、server-2、server-0、server-5 也遭到了影响。针对那种情状，相关的机器能够设置差别告警级别来降低平安变乱的影响。

with_key

l2_vms

cross_vpc_vms

server-4

server-6

server-1

server-4

server-6

server-2

server-4

server-6

server-0

server-4

server-6

server-5

那个查询革新为可视化成果：

MATCH p=(key_leaked)-[:`used_by`]-(involved_server:nova_instance)--(:neutron_port)--(net:neutron_network)--(:neutron_port)--(server_b:nova_instance)

WHERE id(key_leaked) == "key-0"

OPTIONAL MATCH p1=(server_b)----(other_net:neutron_network)--(:neutron_port)--(server_c:nova_instance)

RETURN p,p1

在 Explorer 中利用 Dagre-LR 的规划，相关的联系关系关系能够很清晰地被展现出来。介于可视化展现的曲看性，我们能够考虑把那个图放进平安陈述，伴同其他平安信息一同分发给虚机租户。

镜像、云盘破绽范畴阐发

类似的，一个镜像被扫露马脚，我们能够霎时查到涉及的资本，并做出响应应对之策。

镜像文件有破绽：

MATCH p=(image_risky)-[:`created_from`]-(step1)

WHERE id(image_risky) == "cirros-0.5.2-x86_64-disk"

OPTIONAL MATCH p1=(step1)-[:created_from*1..5]-(step2)

RETURN p, p1

某个云盘有破绽：

MATCH p=(volume_risky)-[:`created_from`]-(step1)

WHERE id(volume_risky) == "volume-1"

OPTIONAL MATCH p1=(step1)-[:created_from*1..5]-(step2)

RETURN p, p1

潜在宿主机逃离影响范畴阐发

最初，我们讨论一个严峻的平安问题：宿主机逃离。

在极端的情状下，server-0发作了有可能影响宿主机的平安事务，此时仅仅封闭那个宿主机是不敷的，因为受影响的范畴可能已经扩展。但我们又不克不及因为如许不知影响范畴多广的平安事务来封闭整个机房。所以，操纵图谱辅助找出受影响范畴就十分有用了。

下面的查询形式是：

找出可能被影响的子网（VPC），标识表记标帜更高级别风险子网为后续定位做预备

找到可能被掌握了的宿主机

从宿主机触发，找出同主机的其他虚机

从其他虚机触发，找到它们的子网（VPC）

从其他虚机触发，找到可能已经被影响的网盘。那是为了避免被挂载到其他机器，那会扩展影响。

MATCH (server_escaping_hypervisor)-[:`contains`]-(hypervisor_compromised:nova_host)

WHERE id(server_escaping_hypervisor) == "server-0"

OPTIONAL MATCH (server_escaping_hypervisor)-[:attached]-(:neutron_port)-[:contains]-(impacted_subnet_high:neutron_network)

OPTIONAL MATCH (hypervisor_compromised)-[:`contains`]-(server_same_host:nova_instance)

OPTIONAL MATCH (server_same_host)-[:attached]-(:neutron_port)-[:contains]-(impacted_subnet:neutron_network)

OPTIONAL MATCH (server_same_host)-[:attached]-(impacted_volume:cinder_volume)

RETURN impacted_subnet_high.neutron_network.name AS impacted_subnet_high,

hypervisor_compromised.nova_host.name AS hypervisor_compromised,

impacted_subnet.neutron_network.name AS impacted_subnet,

[server_same_host.nova_instance.name, server_same_host.nova_instance.instance_name] AS server_same_host,

impacted_volume.cinder_volume.name AS impacted_volume

下面的成果集中，列出了 server-0 被掌握之后，考虑宿主机逃离的情状下可能受影响的扩散范畴。

impacted_subnet_high

hypervisor_compromised

impacted_subnet

server_same_host

impacted_volume

shared

node0

shared

["server-0", "instance-00000001"]

Empty

shared

node0

shared

["server-1", "instance-00000002"]

ffaeb199-47f4-4d95-89b2-97fba3c1bcfe

shared

node0

private

["server-1", "instance-00000002"]

ffaeb199-47f4-4d95-89b2-97fba3c1bcfe

shared

node0

private

["server-3", "instance-00000005"]

c9db7c2e-c712-49d6-8019-14b82de8542d

shared

node0

private

["server-3", "instance-00000005"]

volume-2

shared

node0

public

["server-4", "instance-00000006"]

volume-2

咱们再看看它的可视化成果。

MATCH p=(server_escaping_hypervisor)-[:`contains`]-(hypervisor_compromised:nova_host)

WHERE id(server_escaping_hypervisor) == "server-0"

OPTIONAL MATCH p0=(server_escaping_hypervisor)-[:attached]-(:neutron_port)-[:contains]-(impacted_subnet_high:neutron_network)

OPTIONAL MATCH p1=(hypervisor_compromised)-[:`contains`]-(server_same_host:nova_instance)

OPTIONAL MATCH p2=(server_same_host)-[:attached]-(:neutron_port)-[:contains]-(impacted_subnet:neutron_network)

OPTIONAL MATCH p3=(server_same_host)-[:attached]-(impacted_volume:cinder_volume)

RETURN p,p0,p1,p2,p3

仍是和之前一样，我们在可视化图摸索东西 Explorer 中抉择 Dagre 规划，它能比力清晰看出影响资本的范畴。从那些可能受影响的虚机、收集、网盘动身，能够进一步摘取需要的平安办法了。

重点存眷资本检测

06

最初，操纵 Betweenness Centrality 算法，我们能够获得根底设备中影响面大的那些”懦弱环节“。那些资本纷歧定实的处在求助紧急的形态，只是说，它们处在了比力重要的资本之间的交汇处，一旦它们出问题，出问题的代价可能会十分大。

因而，识别关键资本后，我们能够考虑下面的平安机造：

有针对性摘用更激进、高贵的安康查抄战略；

设定更高的撑持、存眷级别；

主动迁徙相联系关系的资本，以降低”懦弱环节“对整体根底设备可用性的影响范畴；

在那里，我们只在阅读器内部的子图上做算法流程验证。机智的你，能够本身试着操纵开源的 NebulaGraph Algorithm或者付费的 NebulaGraph Workflow + Analytics 做全图上的等价操做。

起首，我们用之前的体例往扫描图上 1,000 个点，而且从它们动身，跳一跳，获得一个比力随机的子图。现实上，因为我们的数据集并非很大，那个操做是捞取了全图的数据：

OPTIONAL MATCH p=(n)--

RETURN p, n

随机子图搞定之后，我们运行 Betweenness Centrality 算法，得到 node0 是分值更大的“懦弱一环”。确实，它是我们当前尝试中负载更大的宿主机，能够想象它确实是毛病之后全局影响更大的一个资本。

总结

在海量数据、企业云、混合云的复杂根底设备运维场景下，操纵图数据库图算法的才能做高效的辅助运维工做是一个非常值得的测验考试与手艺投资。

NebulaGraph 做为高性能、开源、散布式的新一代云原生图数据库，是一个很值得考虑的图根底设备选型目标。

欢送各人在文末留言讨论，本文的可复现情况和示例的 ETL 管道的代码、示例数据全都在 /开源，欢送各人来一路完美。

本文用到的可视化图摸索东西为 NebulaGraph Explorer，目前能够免费试用 30 天，复造链接开启试用：

此外，我把本尝试中的图谱放在了 NebulaGraph Studio/Explorer 的示例数据集中，各人也能够在里边下载试玩。

🌟 参考文献

OpenStack 情况搭建：

Infra 资本创建：

Vitrage 示例文档：

闻名开源奉献者Hax在GitHub公开与360的劳动争议诉讼

我们为何等待Rust 2.0？ 微软开源“傻瓜式”类ChatGPT模子操练东西，提速省钱15倍

🌟 活动选举

2023 年 5 月 27-28 日，GOTC 2023 全球开源手艺峰会将在上海张 江科学礼堂慎重举行。

为期 2 天的开源行业盛会，将以行业展览、主题发言、特殊论坛、分论坛、快闪演讲的形式来诠释此次大会主题 ——“Open Source, Into the Future”。 与会者将一路切磋元宇宙、3D 与游戏、eBPF、Web3.0、区块链等热门手艺主题，以及 OSPO、汽车软件、AIGC、开源教导培训、云原生、信创等热门话题，切磋开源将来，助力开源开展。