图数据库设计实践 | 存储服务的负载均衡和数据迁移
在文章《Nebula 架构剖析系列(一)图数据库的存储设计》中,我们提过分布式图存储的管理由 Meta Service 来统一调度,它记录了所有 partition 的分布情况,以及当前机器的状态。当 DBA 增减机器时,只需要通过 console 输入相应的指令,Meta Service 便能够生成整个 Balance 计划并执行。而之所以没有采用完全自动 Balance 的方式,主要是为了减少数据搬迁对于线上服务的影响,Balance 的时机由用户自己控制。
在本文中我们将着重讲解在存储层如何实现数据和服务的负载平衡。
简单回顾一下,Nebula Graph 的服务可分为 graph,storage,meta。本文主要描述对于存储层(storage)的数据和服务的 balance。这些都是通过 Balance 命令来实现的:Balance 命令有两种,一种需要迁移数据,命令为 BALANCE DATA
;另一种不需要迁移数据,只改变 partition 的 raft-leader 分布(负载均衡),命令为 BALANCE LEADER
。
本文目录
- Balance 机制浅析
- 集群数据迁移
- Step 1:准备工作
- Step 1.1 查看现有集群状态
- Step 1.2 创建图空间
- Step 2 加入新实例
- Step 3 迁移数据
- Step 4 假如要中途停止 balance data
- Step 5 查看数据迁移结果
- Step 6 Balance leader
- Step 1:准备工作
- 批量缩容
- 示例数据迁移
Balance 机制浅析
在图数据库 Nebula Graph 中, Balance 主要用来 balance leader 和 partition,只涉及 leader 和 partition 在机器之间转移,不会增加或者减少 leader 和 partition 的数量。
上线新机器并启动相应的 Nebula 服务后,storage 会自动向 meta 注册。Meta 会计算出一个新的 partition 分布,然后通过 remove partition和 add partition 逐步将数据从老机器搬迁到新的机器上。这个过程所对应的命令是 BALANCE DATA
,通常数据搬迁是个比较漫长的过程。
但 BALANCE DATA 仅改变了数据和副本在机器之间的均衡分布,leader(和对应的负载) 是不会改变的,因此还需要通过命令BALANCE LEADER
来实现负载的均衡。这个过程也是通过 meta 实现的。
集群数据迁移
以下举例说明 BALANCE DATA
的使用方式。本例将从 3 个实例(进程)扩展到 8 个实例(进程):
Step 1:准备工作
部署一个 3 副本的集群,1个 graphd,1个 metad,3 个 storaged(具体部署方式请参考集群部署文:https://zhuanlan.zhihu.com/p/80335605),通过 SHOW HOSTS
命令可以看到集群的状态信息:
Step 1.1 查看现有集群状态
按照集群部署文档部署好 3 副本集群之后,用 SHOW HOSTS
命令查看下现在集群情况:
nebula> SHOW HOSTS ================================================================================================ | Ip | Port | Status | Leader count | Leader distribution | Partition distribution | ================================================================================================ | 192.168.8.210 | 34600 | online | 0 | No valid partition | No valid partition | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34700 | online | 0 | No valid partition | No valid partition | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34500 | online | 0 | No valid partition | No valid partition | ------------------------------------------------------------------------------------------------ Got 3 rows (Time spent: 5886/6835 us)
SHOW HOSTS
返回结果解释:
- IP,Port 表示当前的 storage 实例。这个集群启动了 3 个 storaged 服务,并且还没有任何数据。(192.168.8.210:34600,192.168.8.210:34700,192.168.8.210:34500)
- Status 表示当前实例的状态,目前有 online/offline 两种。当机器下线以后(metad 在一段间隔内收不到其心跳),将把其更改为 offline。 这个时间间隔可以在启动 metad 的时候通过设置
expired_threshold_sec
来修改,当前默认值是 10 分钟。 - Leader count:表示当前实例 Raft leader 数目。
- Leader distribution:表示当前 leader 在每个 space 上的分布,目前尚未创建任何 space。( space 可以理解为一个独立的数据空间,类似 MySQL 的 Database)
- Partition distribution:不同 space 中 partition 的数目。
可以看到 Leader distribution 和 Partition distribution 暂时都没有数据。
Step 1.2 创建图空间
创建一个名为 test 的图空间,包含 100 个 partition,每个 partition 有 3 个副本。
nebula> CREATE SPACE test (PARTITION_NUM=100, REPLICA_FACTOR=3)
片刻后,使用 SHOW HOSTS
命令显示集群的分布。
nebula> SHOW HOSTS ================================================================================================ | Ip | Port | Status | Leader count | Leader distribution | Partition distribution | ================================================================================================ | 192.168.8.210 | 34600 | online | 0 | test: 0 | test: 100 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34700 | online | 52 | test: 52 | test: 100 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34500 | online | 48 | test: 48 | test: 100 | ------------------------------------------------------------------------------------------------
如上,创建包含 100 个 partitio_n 和 3 个 replica 图空间之后,3 个实例的_Leader distribution 和 _Partition distribution _有了对应的数值,对应的 _Partition distribution_都为 100。当然,这样的 learder 分布还不均匀。
Step 2 加入新实例
启动 5 个新 storaged 实例进行扩容。启动完毕后,使用 SHOW HOSTS
命令查看新的状态:
nebula> SHOW HOSTS ================================================================================================ | Ip | Port | Status | Leader count | Leader distribution | Partition distribution | ================================================================================================ | 192.168.8.210 | 34600 | online | 0 | test: 0 | test: 100 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34900 | online | 0 | No valid partition | No valid partition | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 35940 | online | 0 | No valid partition | No valid partition | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34920 | online | 0 | No valid partition | No valid partition | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 44920 | online | 0 | No valid partition | No valid partition | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34700 | online | 52 | test: 52 | test: 100 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34500 | online | 48 | test: 48 | test: 100 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34800 | online | 0 | No valid partition | No valid partition | ------------------------------------------------------------------------------------------------
上新实例之后,集群由原来 3 个实例变成了 8 个实例。上图数据库 icon 为蓝色的图示为新增的 5 个实例,此时由于仅仅加入了集群,新实例的状态为 Online,但此时_Leader distribution_ 和 Partition distribution 并没有数值,说明还不会参与服务。
Step 3 迁移数据
运行 BALANCE DATA
命令。
nebula> BALANCE DATA ============== | ID | ============== | 1570761786 | --------------
如果当前集群有新机器加入,则会生成一个新的计划 ID。对于已经平衡的集群,重复运行 BALANCE DATA
不会有任何新操作。如果当前有正在执行的计划,那会显示当前计划的 ID。
也可通过 BALANCE DATA $id
查看这个 balance 的具体执行进度。
nebula> BALANCE DATA 1570761786 =============================================================================== | balanceId, spaceId:partId, src->dst | status | =============================================================================== | [1570761786, 1:1, 192.168.8.210:34600->192.168.8.210:44920] | succeeded | ------------------------------------------------------------------------------- | [1570761786, 1:1, 192.168.8.210:34700->192.168.8.210:34920] | succeeded | ------------------------------------------------------------------------------- | [1570761786, 1:1, 192.168.8.210:34500->192.168.8.210:34800] | succeeded | ------------------------------------------------------------------------------- ...//这里省略一些。以下一行为例 ------------------------------------------------------------------------------- | [1570761786, 1:88, 192.168.8.210:34700->192.168.8.210:35940] | succeeded | ------------------------------------------------------------------------------- | Total:189, Succeeded:170, Failed:0, In Progress:19, Invalid:0 | 89.947090% | ------------------------------------------------------------------------------- Got 190 rows (Time spent: 5454/11095 us)
BALANCE DATA $id
返回结果说明:
- 第一列 balanceId,spaceId:partId,src->dst 表示一个具体的 balance task。<br /> 以
1570761786, 1:88, 192.168.8.210:34700->192.168.8.210:35940
为例:- 1570761786 为 balance ID
- 1:88,1 表示当前的 spaceId(也就是 space test 的 ID),88 表示迁移的 partitionId
- 192.168.8.210:34700->192.168.8.210:35940,表示数据从 192.168.8.210:34700 搬迁至_192.168.8.210:35940_。而原先 192.168.8.210:34700 中的数据将会在迁移完成后再 GC 删除
- 第二列表示当前 task 的运行状态,有 4 种状态
- Succeeded:运行成功
- Failed:运行失败
- In progress:运行中
- Invalid:无效的 task
最后对所有 task 运行状态的统计,部分 partition 尚未完成迁移。
Step 4 假如要中途停止 balance data
BALANCE DATA STOP
命令用于停止已经开始执行的 balance data 计划。如果没有正在运行的 balance 计划,则会返回错误提示。如果有正在运行的 balance 计划,则会返回计划对应的 ID。
由于每个 balance 计划对应若干个 balance task,
BALANCE DATA STOP
不会停止已经开始执行的 balance task,只会取消后续的 task,已经开始的 task 将继续执行直至完成。
用户可以在 BALANCE DATA STOP
之后输入 BALANCE DATA $id
来查看已经停止的 balance 计划状态。
所有已经开始执行的 task 完成后,可以再次执行 BALANCE DATA
,重新开始 balance。如果之前停止的计划中有失败的 task,则会继续执行之前的计划,如果之前停止的计划中所有 task 都成功了,则会新建一个 balance 计划并开始执行。
Step 5 查看数据迁移结果
大多数情况下,搬迁数据是个比较漫长的过程。但是搬迁过程不会影响已有服务。现在可以通过 SHOW HOSTS
查看运行后的 partition 分布。
nebula> SHOW HOSTS ================================================================================================ | Ip | Port | Status | Leader count | Leader distribution | Partition distribution | ================================================================================================ | 192.168.8.210 | 34600 | online | 3 | test: 3 | test: 37 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34900 | online | 0 | test: 0 | test: 38 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 35940 | online | 0 | test: 0 | test: 37 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34920 | online | 0 | test: 0 | test: 38 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 44920 | online | 0 | test: 0 | test: 38 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34700 | online | 35 | test: 35 | test: 37 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34500 | online | 24 | test: 24 | test: 37 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34800 | online | 38 | test: 38 | test: 38 | ------------------------------------------------------------------------------------------------ Got 8 rows (Time spent: 5074/6488 us)
_Partition distribution_相近,partition 总数 300 不变且 partition 已均衡的分布至各个实例。
如果有运行失败的 task,可再次运行 BALANCE DATA
命令进行修复。如果多次运行仍无法修复,请与社区联系 GitHub。
Step 6 Balance leader
BALANCE DATA
仅能 balance partition,但是 leader 分布仍然不均衡,这意味着旧实例的服务较重,而新实例的服务能力未得到充分使用。运行 BALANCE LEADER
重新分布 Raft leader:
nebula> BALANCE LEADER
片刻后,使用 SHOW HOSTS
命令查看,此时 Raft leader 已均匀分布至所有的实例。
nebula> SHOW HOSTS ================================================================================================ | Ip | Port | Status | Leader count | Leader distribution | Partition distribution | ================================================================================================ | 192.168.8.210 | 34600 | online | 13 | test: 13 | test: 37 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34900 | online | 12 | test: 12 | test: 38 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 35940 | online | 12 | test: 12 | test: 37 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34920 | online | 12 | test: 12 | test: 38 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 44920 | online | 13 | test: 13 | test: 38 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34700 | online | 12 | test: 12 | test: 37 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34500 | online | 13 | test: 13 | test: 37 | ------------------------------------------------------------------------------------------------ | 192.168.8.210 | 34800 | online | 13 | test: 13 | test: 38 | ------------------------------------------------------------------------------------------------ Got 8 rows (Time spent: 5039/6346 us)
如上, BALANCE LEADER
成功执行后,新增的实例和原来的实例(对应上图 icon 蓝色和黑色图示)的 _Leader distribution_相近, 所有实例已均衡,此外,也可以看到 Balance 命令只涉及 leader 和 partition 在物理机器上的转移,并没有增加或者减少 leader 和 partition。
批量缩容
Nebula Graph 支持指定需要下线的机器进行批量缩容。语法为 BALANCE DATA REMOVE $host_list
,例如:BALANCE DATA REMOVE 192.168.0.1:50000,192.168.0.2:50000
,将指定移除 192.168.0.1:50000,192.168.0.2:50000 两台机器。
如果移除指定机器后,不满足副本数要求(例如剩余机器数小于副本数),Nebula Graph 将拒绝本次 balance 请求,并返回相关错误码。
示例数据迁移
上面讲了如何从 3 个实例变成 8个实例的集群,如果你对上文有疑问,记得在本文的评论区留言哈。我们现在看看上面迁移的过程,192.168.8.210:34600 这个实例的状态变化。
说明:有颜色为红色说明对应的数值发生变化,如果数值不变,则为黑色。
附录
最后是 Nebula 的 GitHub 地址,欢迎大家试用,有什么问题可以向我们提 issue。GitHub 地址:https://github.com/vesoft-inc/nebula
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
阿里云自研神龙架构,如何解决云计算行业难题?
“神龙X-Dragon架构”是阿里云自研的软硬件一体化计算架构,包含“X-Dragon虚拟化芯片”、“X-Dragon Hypervisor系统软件”、以及“X-Dragon服务器硬件架构”,深度融合了物理机和虚拟机特性,可兼顾虚拟机的弹性资源、分钟级交付、全自动运维和物理机的性能优势、完整特性和硬件级隔离,为用户了提供一种新型的计算资源交付方式。 2016年,阿里云启动了“神龙X-Dragon架构”新一代IaaS计算平台项目,其采用了软硬件协同设计方法,从云计算IaaS领域重新去审视芯片、硬件和软件的定义与协同创新。 2017年10月,阿里云在杭州云栖大会上首次公布了基于神龙X-Dragon架构的裸金属服务器。 2019年9月,阿里云正式发布第三代自研神龙架构,贯穿整个弹性计算平台,全面支持ECS虚拟机、云原生容器等,并在IOPS、PPS等方面提升5倍性能,用户能在云上获得超越传统物理机100%的计算能力。 背景:云计算的历史性难题 从计算机诞生到90年代,计算资源都是作为“可计划性”的资源来使用。然而,互联网时代的到来,一个爆发性事件,就有可能让已有的计算资源招架不住。 云计算的优...
- 下一篇
自建 Hadoop 数据迁移到阿里云EMR集群
场景描述 客户在 IDC 或者公有云环境自建 Hadoop 集群,数据集中保存在 HDFS文件系统用于数据分析任务。客户在决定上云之后,会将自建 Hadoop 集群的数据迁移到阿里云自建 Hadoop 集群或者 EMR 集群。本实践方案提供安全和低成本的 HDFS 数据迁移方案。 解决问题 客户自建 Hadoop 迁移到阿里云 EMR 集群的技术方案 基于 IPSec VPN 隧道构建安全和低成本数据传输链路 产品列表 专有网络 VPC 云服务器 ECS 对象存储 OSS E-MapReduce VPN 网关 直达最佳实践 》》
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- Mario游戏-低调大师作品
- CentOS6,CentOS7官方镜像安装Oracle11G
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Windows10,CentOS7,CentOS8安装Nodejs环境
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS8编译安装MySQL8.0.19
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS8安装Docker,最新的服务器搭配容器使用