58 同一都市でのワンクリック展開運用保守アーキテクチャの実践 - クラスタ コロケーション管理プラットフォーム マルチシナリオ コスト削減と効率向上

> > > > グラフコンピューティング事業の背景紹介

 

NebulaGraph を選んだ理由

会社の各ビジネスラインでは、多くの部門が関係分析などのグラフ探索シナリオを持っており、ビジネスの発展に伴い、関連するニーズがますます増えています。マルチモーダルデータベースを使用して多数の要件が実装されており、開発コストと管理コストが比較的高くなります。

グラフ データベースの開発に伴い、関連するシステム アプリケーションがますます成熟しているため、ビジネスのこの部分のニーズを満たすための専門的なグラフ データベースの導入も議題になっています。次に考慮すべき問題は、グラフ データベースの選択です。

まず、NebulaGraph には大手インターネット企業の多数の適用事例があり、NebulaGraph が膨大なデータを扱うグラフ探索シナリオに対応できることを効果的に検証しています。また、NebulaGraph は DB-Engines のグラフデータベース分野で現在 14 位にランクされており、成長モメンタムは強い。上位にランクされたグラフ データベースの一部は、オープン ソースまたはスタンドアロンのオープン ソースではなく、シナリオが限られています。

 

NebulaGraph は実際のテストでどのように機能しますか?

インポートのパフォーマンスに関しては、データ量が少ない場合、NebulaGraph のインポート効率は neo4j よりもわずかに遅くなりますが、データ量が多い場合、NebulaGraph のインポートは他の 2 つのグラフ データベースよりも大幅に優れています。3 次クエリのシナリオでは、NebulaGraph の効率は neo4j の効率よりも大幅に高く、HugeGraph と比較して特定の利点もあります。

 

該当するシナリオは何ですか

同社は、エンジニアリングとアーキテクチャの複雑さが高いさまざまなオンライン ビジネスを展開しており、各ビジネス部門には、エンティティ関係データを処理および調査するための専用のグラフ データベースが必要です。

グラフ データベースによるタスクの依存関係の実行時間の監視、時間内に遅延したタスクの取得、売上インセンティブ プラットフォームでのタスクの血縁関係の処理、アプリケーション内のクラス/メソッド レベルの呼び出し関係の分析、ビジネス リスク データの分析、および記録企業の経営者、法人、および株主の関係であり、ビジネスの署名など​​のシナリオで使用されます。

 

リソース アプリケーションとクラスタ管理

グラフデータベースは運用保守部門で一元的に運用・管理されており、よりよい管理・保守が可能です。ユーザーは、必要に応じてワーク オーダー プラットフォームでアプリケーションを送信できます. 詳細なリソース需要データとパフォーマンス デマンド インジケーターがワーク オーダーに記入されます. 運用と保守の学生は、クラスタ リソースを一律にレビューして提供します.

同社の現在のサーバー環境は自作のコンピューター ルームであり、注目度の高い物理マシンと単一マシンの複数インスタンスの混合データベース サービスを使用しています。大規模な管理・保守を実現するためには、インスタンスの基準やルールを事前に策定する必要があります。

 

クラスターサイズ

NebulaGraph の優れたグラフ コンピューティング機能のおかげで、これまでに 20 近くのクラスターを提供してきました。ビジネス部門は、関連するクラスター サービス リソースの申請を続けています。

 

> > > >  NebulaGraph 仕様とアーキテクチャ設計

満たす必要のあるビジネス要件が多数あるため、将来、多数のクラスターを提供および維持する必要があります。大規模なクラスタを効率的に管理・運用するためには、事前に仕様を計画・策定する必要があります。

 

バージョン仕様

現在のバージョンは 2.0.1 です

 

パス指定

1) プログラムのパスは /opt/soft/nebula201 で、このパスの下に bin、scripts、share などがあり、パブリック サービスの依存パスとして、サービス パスから抽出されます。

同様に、バージョン 3.x にアップグレードするには、プログラム パスをパブリック サービス依存パスとして抽出するだけです。

2) サービス パスは /work/nebulagraph+graph ポートで、このパスにはデータなど、ログ、pid があります。

 

ポート仕様

1) クラスター間のポートは 5 ずつ増加します。これは、ストレージ コピーがポート通信 (通常はストレージ ポート -1) を必要とするためです。たとえば、クラスター グラフ ポートの 2 つのセットは 60000 と 60005 です。

2) 各サービス ポートと http および http2 ポートの間のステップ サイズは 10000 です。たとえば、グラフ ポートは 60000、ws_http_port は 50000、ws_h2_port は 40000 です。

3) 3 つのサービス ポートの差は 1000 です。たとえば、グラフ ポートは 60000、メタ ポートは 61000、ストレージ ポートは 62000 です。

60000 グラフ ポート、50000 ws_http_port、40000 ws_h2_port

61000 メタ ポート; 51000 ws_http_port; 41000 ws_h2_port

62000 ストレージ ポート; 52000 ws_http_port; 42000 ws_h2_port

 

運用保守仕様

1) スペースを作成するには ngdb_ の左側のプレフィックスが必要です。デフォルトのシャード数はノード数の 2 倍、レプリカのデフォルト数は 2 です 。CREATE SPACE `ngdb_demo` (partition_num=6,replica_factor= ) を参照してください。 2,charset=utf8,collat​​e=utf8_bin,vid_type =FIXED_STRING(128),atomic_edge=false) オン デフォルト;

2) ビジネス アカウントに DBA ロールを付与します。GRANT ROLE DBA ON ngdb_demo TO demo_wr ;

3) NebulaGraph クラスターを構築したら、ビルトイン アカウント root のパスワードをリセットし、/work/nebulagraph+graph ポート パスをパッケージ化して、標準インストール パッケージとして rpm を生成します。

サービス要求は、DNS およびゲートウェイ サービスを介して Graph に直接送信されます, これにより、コンピューティング サービスとストレージ サービスの間の直接的なやり取りが容易になります. DNS を介してアクセスされ、メタ ノード情報が外部に公開されないため、より柔軟な運用と保守を実現できます。メタノード IP によってバインドされるサービスが少なくなります。運用コスト。

このアーキテクチャは、Java などのドライバーのアクセスを制限するため、他のドライバーに置き換える必要があります。

4) 基本クラスタパッケージはグラフノード3台、メタノード3台、ストレージノード3台で、高可用性を確保しながら十分な処理能力を確保できます。

基本クラスターは 3 台の物理マシンに分散されており、ストレージとコンピューティングにはネットワークのやり取りがあまり必要ありません。

 

クラスター展開の自動化の実装

ワンクリックでサービスを展開し、サービスを一元管理するには、リモート管理ツール Ansible を使用する必要があります。これにより、迅速な展開が可能になります。3 つの役割サービスのポート仕様に従って ansible 構成ファイルを生成します。

• 設定ファイルにバージョン情報が書かれているので、複数バージョン対応の場合は、対応する判定をbootstrap.ymlファイルに追加するだけでよく、メインプログラムを複数バージョン対応にするためのコストは非常に限定的です.

インスタンスのデプロイ時に、グラフの役割に応じてファイルを配布するか、各ノードが個別にファイルを配布することができます。

• 3 つの役割に従って、構成ファイルはそれぞれ宛先パスに配布され、最終的な構成ファイルはファイル命名規則に従って生成されます。

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 loop 構文を使用する必要があります。

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

同様に、nebulastored サービス構成ファイルのパス指定とサービス ポートは 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 のスクリプト ファイルを順番に起動し、3 つのサービスの起動コマンドと構成ファイルを事前に定義する必要があります。

ansible-playbook を呼び出し、start.yml のスクリプト ファイルに従って、3 つのサービスの開始コマンドを順番に実行します。

 

> > > > ビジュアル グラフ ディスカバリー プラットフォーム

ターゲット ホストを Web プラットフォームに配置する設定によっては、ELK の標準アーキテクチャとは異なり、複数のプロジェクトの開発に共通の Web プラットフォームを提供するだけで済み、NebulaGraph クラスター内のコンポーネントの数を減らすことができます。 .

開発者は、NebulaGraph Studio を使用してデータを視覚的に管理し、データのインポートとエクスポートを簡単に実装して、ユーザーがデータの関係を探索しやすくすることができます。ポイントとエッジの関係が直接表示されるため、グラフ データ間の関係をより直感的に調べることができます。

上記は、NebulaGraph クラスターの大規模な管理と保守のプロセスにおける私たちの経験の一部であり、少しでもお役に立てれば幸いです。

交換グラフデータベース技術? NebulaGraph 交換グループに参加するには、まず NebulaGraph 名刺を 記入してください。Nebula アシスタントがあなたをグループに引き込みます~~

 

公式サイト：https ://nebula-graph.com.cn

GitHub：https://github.com/vesoft-inc/nebula

無料でオープンソース、右上隅のStar(8K)をクリックしてサポート/お気に入りにできます〜

{{o.name}}

{{m.name}}