关于运维:如何运维多集群数据库58-同城-NebulaGraph-Database-运维实践

5次阅读

共计 7060 个字符，预计需要花费 18 分钟才能阅读完成。

在公司各个业务线中，有不少部门都有着关系剖析等图摸索场景，随着业务倒退，相干的需要越来越多。大量需要应用多模数据库来实现，开发成本和治理老本绝对较高。

随着图数据库的倒退，相干零碎利用越来越成熟，于是引入业余图数据库来满足这部分业务需要的事务也提上日程。接下来要思考的问题就是图数据库选型了。

首先，NebulaGraph 有大量互联网大厂利用案例，阐明 NebulaGraph 能够应答海量数据的图摸索场景。另外，目前 NebulaGraph 在 DB-Engines 在图数据库畛域排名 14，而且增长势头强劲。排名靠前的图数据库，局部不开源或者单机版开源，场景受限。

在导入性能上，数据量小的时候 NebulaGraph 的导入效率稍慢于 neo4j，但在大数据量的时候 NebulaGraph 的导入显著优于其余两款图数据库。在 3 种查问场景下，NebulaGraph 的效率都显著高于 neo4j，与 HugeGraph 相比也有肯定的劣势。

公司有多种线上业务，工程复杂度和架构复杂度都较高，各个业务部门都须要专门的图数据库来实现对实体关系数据的解决和摸索。

通过图数据库实现对工作依赖的运行工夫进行监控，及时获取提早工作、销售激励平台工作血缘关系解决、剖析利用外部的类 / 办法级调用关系、业务危险数据分析、记录企业高管、法人、股东关系，用于签单业务等场景。

为了更好的治理和保护，图数据库在运维部门集中运维治理。用户按需在工单平台中提交申请即可，工单中填写具体的资源需要数据和性能需求指标，由运维同学对立审核交付集群资源。

公司目前服务器环境是自建机房，采纳高配物理机，单机多实例混部数据库服务。为了实现规模化治理和保护，须要提前制订好实例规范和规定。

得益于 NebulaGraph 良好的图计算能力，咱们曾经继续交付集群靠近 20 套，目前还有业务部门在继续申请相干集群服务资源。

因为须要满足大量业务需要，将来会有大量的集群须要交付和保护。为了高效治理和运维规模化的集群，须要提前布局和制订标准。

目前应用版本为 2.0.1

程序门路为 /opt/soft/nebula201，该门路下有 bin、scripts、share 等，作为公共的服务依赖门路，从服务门路中抽离进去

同样，降级为 3.X 版本，只须要将程序门路抽离进去作为公共的服务依赖门路即可。

服务门路为 /work/nebulagraph+graph 端口 ，该门路下有 data、etc、logs、pids

集群之间端口递增 5，因为 storage 正本须要端口通信，通常是 storage 端口 -1，例如两套集群 graph 端口别离是 60000 和 60005;
每种服务端口和 http、http2 端口之间步长为 10000，例如 graph 端口是 60000，ws_http_port 就是 50000，ws_h2_port 就是 40000；
三种服务端口之间相差 1000，例如 graph 端口是 60000，meta 端口就是 61000，storage 端口就是 62000；
- 60000 graph 端口；50000 ws_http_port；40000 ws_h2_port
- 61000 meta 端口；51000 ws_http_port；41000 ws_h2_port
- 62000 storage 端口；52000 ws_http_port；42000 ws_h2_port

第一，创立 space 需用 ngdb_ 左前缀，分片默认是节点数的 2 倍，正本数默认为 2，参考 CREATE SPACE ngdb_demo (partition_num=6,replica_factor=2,charset=utf8,collate=utf8_bin,vid_type=FIXED_STRING(128),atomic_edge=false) ON default;
第二，授予业务账号 DBA 角色：GRANT ROLE DBA ON ngdb_demo TO demo_wr;
第三，搭建一套 NebulaGraph 集群后，将内置账号 root 的明码重置，之后将 /work/nebulagraph+graph 端口 门路打包生成 rpm，作为规范安装包

服务申请间接通过 DNS 和网关服务到 Graph，不便计算和存储服务间接交互，因为是通过 DNS 拜访，不对外裸露 Meta 节点信息，能够更灵便的运维，较少服务绑定 Meta 节点 ip 带来的运维代价。

这种架构限度了 Java 等驱动的拜访，须要用其余驱动代替。

第四，根底集群套餐是 3 个 Graph 节点、3 个 Meta 节点、3 个 Storage 节点，在保障高可用的同时也能保障足够的解决能力。

根底集群散布在 3 台物理机上，存储和计算不须要过多的网络交互。

为了可能一键部署服务，集中式治理服务，咱们须要借助远程管理工具 Ansible，能帮咱们做到疾速部署。根据三种角色服务的端口标准，生成 Ansible 的配置文件。

因为将版本信息写到了配置文件中，在兼容多版本场景下，只须要在 bootstrap.yml 文件中减少相应判断即可，主程序兼容多版本老本十分无限。

部署实例时，依据 graph 角色散发文件，也能够每个节点独自散发文件。

根据三种角色，别离散发配置文件到目标门路下，并且依照文件命名规定生成最终配置文件。

more bootstrap.yml
- hosts: graph
  become: yes
  remote_user: root
  tasks:
    - name: init elasticsearch file on data
      command: cp -r /opt/soft/nebulagraph201 {{nebula_home}}
- hosts: graph
  become: yes
  remote_user: root
  tasks:
    - name: init config graphfile on master {{version}}
      template: src=/opt/soft/ngdeploy/conf/templates/201graph dest="{{nebula_etc}}nggraphd.conf" owner=root group=root mode=0755
- hosts: meta
  become: yes
  remote_user: root
  tasks:
    - name: init config metafile on master {{version}}
      template: src=/opt/soft/ngdeploy/conf/templates/201meta dest="{{nebula_etc}}ngmetad.conf" owner=root group=root mode=0755
- hosts: storage
  become: yes
  remote_user: root
  tasks:
    - name: init config storagefile on master {{version}}
      template: src=/opt/soft/ngdeploy/conf/templates/201storage dest="{{nebula_etc}}ngstoraged.conf" owner=root group=root mode=0755

配置文件的散发最为要害，有较多变量须要解决，这些变量须要提前在 Ansible 的配置文件中定义，nebulagraphd 门路标准和服务端口须要应用 graphport、meta_server_addrs 须要用到 for 循环语法实现。

more templates/201graph 
########## basics ##########
--daemonize=true
--pid_file=/work/nebulagraph{{graphport}}/pids/nebula-graphd.pid
--enable_optimizer=true
########## logging ##########
--log_dir=/work/nebulagraph{{graphport}}/logs
--minloglevel=0
--v=0
--logbufsecs=0
--redirect_stdout=true
--stdout_log_file=graphd-stdout.log
--stderr_log_file=graphd-stderr.log
--stderrthreshold=2

########## query ##########
--accept_partial_success=false

########## networking ##########
--meta_server_addrs={% for host in groups.graph%}{%if loop.last%}{{hostvars[host].inventory_hostname }}:{{hostvars[host].metaport }}{%else%}{{hostvars[host].inventory_hostname }}:{{hostvars[host].metaport}}
,{%endif%}{% endfor %}

--local_ip={{inventory_hostname}}
--listen_netdev=any
--port={{graphport}}
--reuse_port=false
--listen_backlog=1024
--client_idle_timeout_secs=0
--session_idle_timeout_secs=0
--num_accept_threads=1
--num_netio_threads=0
--num_worker_threads=0
--ws_ip={{inventory_hostname}}
--ws_http_port={{graph_h1_port}}
--ws_h2_port={{graph_h2_port}}
--default_charset=utf8
--default_collate=utf8_bin

########## authorization ##########
--enable_authorize=true

########## Authentication ##########
--auth_type=password

同样，nebulametad 服务配置文件门路标准和服务端口须要应用 metahport、meta_server_addrs 须要用到 for 循环语法实现。

more templates/201meta 
########## basics ##########
--daemonize=true
--pid_file=/work/nebulagraph{{graphport}}/pids/nebula-metad.pid
########## logging ##########
--log_dir=/work/nebulagraph{{graphport}}/logs
--minloglevel=0
--v=0
--logbufsecs=0
--redirect_stdout=true
--stdout_log_file=metad-stdout.log
--stderr_log_file=metad-stderr.log
--stderrthreshold=2

########## networking ##########
--meta_server_addrs={% for host in groups.graph%}{%if loop.last%}{{hostvars[host].inventory_hostname }}:{{hostvars[host].metaport }}{%else%}{{hostvars[host].inventory_hostname }}:{{hostvars[host].metaport}}
,{%endif%}{% endfor %}

--local_ip={{inventory_hostname}}
--port={{metaport}}
--ws_ip={{inventory_hostname}}
--ws_http_port={{meta_h1_port}}
--ws_h2_port={{meta_h2_port}}
########## storage ##########
--data_path=/work/nebulagraph{{graphport}}/data/meta

########## Misc #########
--default_parts_num=100
--default_replica_factor=1
--heartbeat_interval_secs=10
--timezone_name=CST-8

同样，nebulastoraged 服务配置文件门路标准和服务端口须要应用 storageport、meta_server_addrs 须要用到 for 循环语法实现。

more templates/201graph 
########## basics ##########
--daemonize=true
--pid_file=/work/nebulagraph{{graphport}}/pids/nebula-graphd.pid
--enable_optimizer=true
########## logging ##########
--log_dir=/work/nebulagraph{{graphport}}/logs
--minloglevel=0
--v=0
--logbufsecs=0
--redirect_stdout=true
--stdout_log_file=graphd-stdout.log
--stderr_log_file=graphd-stderr.log
--stderrthreshold=2

########## query ##########
--accept_partial_success=false

########## networking ##########
--meta_server_addrs={% for host in groups.graph%}{%if loop.last%}{{hostvars[host].inventory_hostname }}:{{hostvars[host].metaport }}{%else%}{{hostvars[host].inventory_hostname }}:{{hostvars[host].metaport}}
,{%endif%}{% endfor %}

--local_ip={{inventory_hostname}}
--listen_netdev=any
--port={{graphport}}
--reuse_port=false
--listen_backlog=1024
--client_idle_timeout_secs=0
--session_idle_timeout_secs=0
--num_accept_threads=1
--num_netio_threads=0
--num_worker_threads=0
--ws_ip={{inventory_hostname}}
--ws_http_port={{graph_h1_port}}
--ws_h2_port={{graph_h2_port}}
--default_charset=utf8
--default_collate=utf8_bin

########## authorization ##########
--enable_authorize=true

########## Authentication ##########
--auth_type=password

须要部署新集群时，须要依照规定和目标服务器信息生成 Ansible 的配置文件，而后调用 ansible-playbook，依照 bootstrap.yml 定义的行为执行即可。

部署结束之后，须要依照服务角色顺次启动 start.yml 的脚本文件提前定义好三种服务的启动命令和配置文件。

调用 ansible-playbook，依据 start.yml 的脚本文件顺次执行三种服务的启动命令即可。

有赖于将指标 host 前置于 Web 平台的设置，咱们只须要对多个我的项目的开发提供一套公共的 Web 平台即可，缩小了 NebulaGraph 集群的组件数量，有别于 ELK 的规范架构。

开发能够通过 NebulaGraph Studio 实现可视化治理数据，轻松实现数据导入和导出，便于用户摸索数据关系。间接出现出点边关系，使摸索图数据之间的关系更为直观。

以上是咱们在规模化治理保护 NebulaGraph 集群过程中的一些教训，心愿对大家有些帮忙。

交换图数据库技术？退出 NebulaGraph 交换群请先填写下你的 NebulaGraph 名片，NebulaGraph 小助手会拉你进群~~

NebulaGraph 的开源地址：https://github.com/vesoft-inc/nebula 如果你感觉应用体验还不错的话，给咱们的 GitHub 点个 ❤️ 激励下开源路上的咱们呢~

正文完

运维

发表至：运维

2023-02-15

0

关于运维:IT运维软件的费用是多少

关于运维:高效实践｜运维指标体系在银行业务的应用实践

关于运维:业界首个机密计算容器运行时Inclavare-Containers正式进入CNCF

关于运维:全链路业务追踪落地实践方案

关于安全:顶象业务安全大讲堂全新升级挖洞大佬喊你来get-挖洞秘籍啦

关于运维:如何运维多集群数据库58-同城-NebulaGraph-Database-运维实践

图计算业务背景介绍

咱们为什么抉择 NebulaGraph？

NebulaGraph 理论测试体现如何

实用场景有哪些

资源申请和集群治理形式

集群规模

NebulaGraph 标准和架构设计

版本标准

门路标准

端口标准

运维标准

集群部署自动化实现

可视化图摸索平台

站内搜索