TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

2 つのリージョンの展開で 3 つのアベイラビリティー ゾーン

このドキュメントでは、2 つのリージョンのデプロイにおける 3 つのアベイラビリティ ゾーン (AZ) のアーキテクチャと構成を紹介します。

このドキュメントの「地域」という用語は地理的な領域を指し、大文字の「リージョン」は TiKV のデータstorageの基本単位を指します。 「AZ」はリージョン内の孤立した場所を指し、各リージョンには複数の AZ があります。このドキュメントで説明するソリューションは、1 つの都市に複数のデータ センターが配置されているシナリオにも適用されます。

概要

2 つのリージョンにある 3 つの AZ のアーキテクチャは、本番データ AZ、同じリージョン内のディザスター リカバリー AZ、および別のリージョン内のディザスター リカバリー AZ を提供する、可用性が高く災害に強いデプロイ ソリューションです。このモードでは、2 つのリージョンの 3 つの AZ が相互接続されます。 1 つの AZ で障害が発生したり、障害が発生したりした場合でも、他の AZ は引き続き正常に動作し、主要なアプリケーションまたはすべてのアプリケーションを引き継ぐことができます。 1 つのリージョンでのマルチ AZ 配置と比較して、このソリューションには、リージョン間の高可用性という利点があり、リージョン レベルの自然災害に耐えることができます。

分散データベース TiDB は、 Raftアルゴリズムを使用して 2 リージョン内の 3 AZアーキテクチャをネイティブにサポートし、データベース クラスター内のデータの一貫性と高可用性を保証します。同じリージョン内の AZ 間のネットワークレイテンシーは比較的低いため、アプリケーション トラフィックは同じリージョン内の 2 つの AZ にディスパッチでき、TiKVリージョンリーダーと PD リーダーの分散を制御することで、トラフィック負荷をこれら 2 つの AZ で共有できます。 .

導入アーキテクチャ

このセクションでは、シアトルとサンフランシスコの例を取り上げて、TiDB の分散データベースの 2 つのリージョンに 3 つの AZ を配置するモードについて説明します。

この例では、2 つの AZ (AZ1 と AZ2) がシアトルにあり、別の AZ (AZ3) がサンフランシスコにあります。 AZ1 と AZ2 の間のネットワークレイテンシーは3 ミリ秒未満です。シアトルの AZ3 と AZ1/AZ2 間のネットワークレイテンシーは約 20 ミリ秒です (ISP 専用ネットワークを使用)。

クラスタ展開のアーキテクチャは次のとおりです。

  • TiDB クラスターは、シアトルの AZ1、シアトルの AZ2、サンフランシスコの AZ3 の 2 つのリージョンにある 3 つの AZ にデプロイされます。
  • クラスターには 5 つのレプリカがあり、AZ1 に 2 つ、AZ2 に 2 つ、AZ3 に 1 つです。 TiKVコンポーネントの場合、各ラックにはラベルがあり、これは各ラックにレプリカがあることを意味します。
  • Raftプロトコルは、データの一貫性と高可用性を確保するために採用されており、ユーザーに対して透過的です。

3-AZ-in-2-region architecture

このアーキテクチャは可用性が高いです。リージョンリーダーの配布は、同じリージョン (シアトル) にある 2 つの AZ (AZ1 と AZ2) に制限されています。リージョンリーダーの配布が制限されていない 3 AZ ソリューションと比較して、このアーキテクチャには次の利点と欠点があります。

  • 利点

    • リージョンリーダーは同じリージョンの低レイテンシーの AZ にあるため、書き込みはより高速です。
    • 2 つの AZ が同時にサービスを提供できるため、リソースの使用率が高くなります。
    • 1 つの AZ に障害が発生した場合でも、サービスは引き続き利用可能で、データの安全性が確保されます。

  • 短所

    • データの一貫性はRaftアルゴリズムによって達成されるため、同じリージョン内の 2 つの AZ が同時に失敗した場合、生き残ったレプリカは 1 つだけが別のリージョン (サンフランシスコ) のディザスター リカバリー AZ に残ります。これは、ほとんどのレプリカが存続するRaftアルゴリズムの要件を満たすことができません。その結果、クラスターが一時的に使用できなくなる可能性があります。メンテナンス スタッフは、生き残った 1 つのレプリカからクラスターを回復する必要があり、複製されていない少量のホット データが失われます。しかし、このケースはまれなケースです。
    • ISP専用ネットワークを利用するため、このアーキテクチャのネットワークインフラはコストが高くなります。
    • 2 つのリージョンの 3 つの AZ に 5 つのレプリカが構成されているため、データの冗長性が増し、storageコストが高くなります。

導入の詳細

2 つのリージョン (シアトルとサンフランシスコ) の展開計画における 3 つの AZ の構成は、次のように示されています。

3-AZ-2-region

前の図から、シアトルには AZ1 と AZ2 の 2 つの AZ があることがわかります。 AZ1 には、rac1、rac2、および rac3 の 3 セットのラックがあります。 AZ2 には、rac4 と rac5 の 2 つのラックがあります。サンフランシスコの AZ3 には rac6 ラックがあります。

AZ1 の rac1 では、1 つのサーバーがTiDB および PD サービスで展開され、他の 2 つのサーバーは TiKV サービスで展開されます。各 TiKVサーバーには、2 つの TiKV インスタンス (tikv-server) がデプロイされます。これは、rac2、rac4、rac5、および rac6 に似ています。

TiDBサーバー、制御マシン、および監視サーバーはrac3 上にあります。 TiDBサーバーは、定期的なメンテナンスとバックアップのためにデプロイされます。 Prometheus、Grafana、および復元ツールは、制御マシンと監視マシンにデプロイされます。

Drainerをデプロイするために、別のバックアップサーバーを追加できます。 Drainer は、増分バックアップを実現するために、ファイルを出力することによってbinlogデータを指定された場所に保存します。

コンフィグレーション

例

たとえば、次のtiup topology.yaml yaml ファイルを参照してください。

# # Global variables are applied to all deployments and used as the default value of
# # the deployments if a specific deployment value is missing.
global:
  user: "tidb"
  ssh_port: 22
  deploy_dir: "/data/tidb_cluster/tidb-deploy"
  data_dir: "/data/tidb_cluster/tidb-data"

server_configs:
  tikv:
    server.grpc-compression-type: gzip
  pd:
    replication.location-labels: ["az","replication zone","rack","host"]

pd_servers:
  - host: 10.63.10.10
    name: "pd-10"
  - host: 10.63.10.11
    name: "pd-11"
  - host: 10.63.10.12
    name: "pd-12"
  - host: 10.63.10.13
    name: "pd-13"
  - host: 10.63.10.14
    name: "pd-14"

tidb_servers:
  - host: 10.63.10.10
  - host: 10.63.10.11
  - host: 10.63.10.12
  - host: 10.63.10.13
  - host: 10.63.10.14

tikv_servers:
  - host: 10.63.10.30
    config:
      server.labels: { az: "1", replication zone: "1", rack: "1", host: "30" }
  - host: 10.63.10.31
    config:
      server.labels: { az: "1", replication zone: "2", rack: "2", host: "31" }
  - host: 10.63.10.32
    config:
      server.labels: { az: "2", replication zone: "3", rack: "3", host: "32" }
  - host: 10.63.10.33
    config:
      server.labels: { az: "2", replication zone: "4", rack: "4", host: "33" }
  - host: 10.63.10.34
    config:
      server.labels: { az: "3", replication zone: "5", rack: "5", host: "34" }
      raftstore.raft-min-election-timeout-ticks: 1000
      raftstore.raft-max-election-timeout-ticks: 1200

monitoring_servers:
  - host: 10.63.10.60

grafana_servers:
  - host: 10.63.10.60

alertmanager_servers:
  - host: 10.63.10.60

ラベルデザイン

2 つのリージョンに 3 つの AZ をデプロイする場合、ラベルの設計では、可用性と災害復旧を考慮する必要があります。デプロイメントの物理構造に基づいて、4 つのレベル ( az 、 replication zone 、 rack 、およびhost ) を定義することをお勧めします。

Label logical definition

PD 構成で、TiKV ラベルのレベル情報を追加します。

server_configs:
  pd:
    replication.location-labels: ["az","replication zone","rack","host"]

tikv_serversの構成は、TiKV の実際の物理的な展開場所のラベル情報に基づいているため、PD はグローバルな管理とスケジューリングを実行しやすくなります。

tikv_servers:
  - host: 10.63.10.30
    config:
      server.labels: { az: "1", replication zone: "1", rack: "1", host: "30" }
  - host: 10.63.10.31
    config:
      server.labels: { az: "1", replication zone: "2", rack: "2", host: "31" }
  - host: 10.63.10.32
    config:
      server.labels: { az: "2", replication zone: "3", rack: "3", host: "32" }
  - host: 10.63.10.33
    config:
      server.labels: { az: "2", replication zone: "4", rack: "4", host: "33" }
  - host: 10.63.10.34
    config:
      server.labels: { az: "3", replication zone: "5", rack: "5", host: "34" }

パラメータ構成の最適化

2 つのリージョンに 3 つの AZ をデプロイする場合、パフォーマンスを最適化するには、通常のパラメーターを構成するだけでなく、コンポーネントのパラメーターも調整する必要があります。

  • TiKV で gRPC メッセージ圧縮を有効にします。クラスターのデータはネットワークで送信されるため、gRPC メッセージ圧縮を有効にしてネットワーク トラフィックを下げることができます。

    server.grpc-compression-type: gzip

  • 別のリージョン (サンフランシスコ) で TiKV ノードのネットワーク構成を最適化します。サンフランシスコの AZ3 の次の TiKV パラメータを変更し、この TiKV ノードのレプリカがRaft選択に参加しないようにしてください。

    raftstore.raft-min-election-timeout-ticks: 1000
raftstore.raft-max-election-timeout-ticks: 1200

  • スケジューリングを構成します。クラスターが有効になったら、 tiup ctl:v<CLUSTER_VERSION> pdツールを使用してスケジューリング ポリシーを変更します。 TiKV Raftレプリカの数を変更します。この数を計画どおりに構成します。この例では、レプリカの数は 5 です。

    config set max-replicas 5

  • Raftリーダーを AZ3 にスケジューリングすることを禁止します。 Raftリーダーを別のリージョン (AZ3) にスケジュールすると、シアトルの AZ1/AZ2 とサンフランシスコの AZ3 の間に不要なネットワーク オーバーヘッドが発生します。ネットワーク帯域幅とレイテンシーも、TiDB クラスターのパフォーマンスに影響します。

    config set label-property reject-leader dc 3

    ノート：

    TiDB v5.2 以降、 label-property構成はデフォルトでサポートされていません。レプリカ ポリシーを設定するには、 配置ルールを使用します。

  • PD の優先度を設定します。 PD リーダーが別の地域 (AZ3) にいる状況を回避するには、ローカル PD の優先度を上げ (シアトル)、別の地域 (サンフランシスコ) にある PD の優先度を下げることができます。数値が大きいほど優先度が高くなります。

    member leader_priority PD-10 5
member leader_priority PD-11 5
member leader_priority PD-12 5
member leader_priority PD-13 5
member leader_priority PD-14 1

このページは役に立ちましたか？