TiDB (9): テクノロジーインサイダーのスケジュール設定

1 なぜスケジュールを立てるのか

まず、前の TiDB テクノロジーインサイダー - ストレージで説明した情報の一部を思い出してください。TiKV クラスターは、TiDB データベースの分散 KV ストレージエンジンです。データはリージョン単位でレプリケートおよび管理されます。各リージョンには複数のレプリカがあります。これらのレプリカは、は異なる TiKV ノードに分散されます。リーダーは読み取り/書き込みを担当し、フォロワーはリーダーによって送信された raft ログの同期を担当します。この情報を入手して、次の質問について検討してください。

同じリージョンの複数のレプリカが異なるノードに分散されていることを確認するにはどうすればよいですか? さらに一歩進んで、1 台のマシン上で複数の TiKV インスタンスが起動された場合、何が問題になるでしょうか?
ディザスターリカバリーのために TiKV クラスターが複数のコンピュータールームに展開されている場合、Raft グループの複数のレプリカを失わずにコンピュータールームを確実にオフラインにするにはどうすればよいでしょうか?
TiKV クラスターにノードを追加した後、クラスター内の他のノードからデータを移動するにはどうすればよいですか?
ノードがオフラインになるとどうなりますか? クラスター全体は何をする必要があるのでしょうか? ノードが短時間だけオフラインになった場合 (サービスの再起動時) はどうなりますか? ノードが長期間オフラインの場合 (ディスク障害、すべてのデータが失われる)、どうすればよいですか?
クラスターが各 Raft グループに N 個のコピーを持つ必要があると仮定すると、単一の Raft グループの場合、レプリカの数が十分でない可能性があります (たとえば、ノードがオフラインになってコピーが失われる)、または多すぎる可能性があります (たとえば、オフラインノードは通常の状態に戻り、自動的にクラスターに参加します)。では、レプリカの数を調整するにはどうすればよいでしょうか?
読み取り/書き込みはリーダーを通じて実行されますが、リーダーが少数のノードにのみ集中している場合、クラスターにどのような影響がありますか?
すべてのリージョンが頻繁にアクセスされるわけではなく、アクセスホットスポットはいくつかのリージョンにのみ存在する可能性があります。この時点で何をする必要がありますか?
クラスターがロードバランシングを実行しているとき、多くの場合、データの再配置が必要になります。このデータの移行には、多くのネットワーク帯域幅、ディスク IO、CPU が消費されますか? それでオンラインサービスに影響が出るのでしょうか？

これらの問題だけでは簡単な解決策が見つかるかもしれませんが、複数の問題が混在すると、解決するのは簡単ではありません。レプリカの数が十分かどうかに応じてレプリカを追加するかどうかを決定するなど、単一の Raft グループの内部状況を考慮するだけで済む問題もあるようです。しかし実際には、このコピーを追加する場合、グローバルな情報を考慮する必要があります。システム全体も動的に変化しています。領域の分割、ノードの結合、ノードの障害、アクセスホットスポットの変更などが引き続き発生します。スケジューリングシステム全体も、動的状態で最適な状態に向けて動き続ける必要があります。にはグローバルな情報が含まれていますが、グローバルなスケジューリングと構成可能なコンポーネントにより、これらのニーズを満たすことが困難になります。したがって、システム全体のステータスを制御および調整するための中央ノードが必要であるため、PD モジュールが必要になります。

2 スケジュール要件

上記に挙げた問題はたくさんありますが、まずはそれらを分類して整理してみましょう。一般に、問題には次の 2 種類があります。

2.1 分散型高可用性ストレージシステムとして満たさなければならない要件には、次の 4 種類があります。

コピー数は増減できません
レプリカは別のマシンに分散する必要がある
新しいノードが追加された後、他のノード上のコピーを移行できます。
ノードがオフラインになったら、ノードのデータを移行する必要があります

2.2 優れた分散システムとして、最適化する必要がある領域は次のとおりです。

• クラスター全体でリーダーの均等な分布を維持する

• 各ノードのストレージ容量を均一に維持する

• アクセスホットスポットの均等な分散を維持する

• オンラインサービスへの影響を避けるために、Balance の速度を制御します。

• 手動オンライン/オフラインノード、自動オフライン障害ノードなどのノードステータスの管理

最初のタイプの要件を満たした後、システム全体は、マルチコピーのフォールトトレランス、動的拡張/縮小、ノード切断の耐性、および自動エラー回復の機能を備えます。

2 番目のタイプの要件を満たすと、システム全体の負荷をより均一にし、管理しやすくなります。

これらの要件を満たすためには、まず各ノードの状態、各 Raft グループの情報、ビジネスアクセス操作の統計などの十分な情報を収集する必要があります。

次に、いくつかの戦略を設定する必要があり、PD は情報とスケジューリング戦略に基づいて、上記の要件を可能な限り満たすスケジューリング計画を作成し、最終的に、スケジューリング計画を完成させるためにいくつかの基本的な操作が必要になります。

3 スケジュールの基本操作

まず最も簡単な点、つまりスケジューリングの基本操作、つまりスケジューリング戦略を満たすためにどのような機能を使用できるかを紹介します。これが全体のスケジューリングの基本であり、手に持っているハンマーの種類を知って初めて、どのような姿勢で釘を打てばよいのかが分かります。

上記のスケジュール要件は複雑に見えるかもしれませんが、整理して最終的に着地すると、次の 3 つのことに他なりません。

レプリカの追加
レプリカの削除
Raft グループの異なるレプリカ間でリーダーの役割を転送する

Raft プロトコルはたまたまこれら 3 つの要件を満たすことができ、AddReplica、RemoveReplica、および TransferLeader の 3 つのコマンドを通じて、上記の 3 つの基本操作をサポートできます。

4 情報収集

スケジューリングはクラスター全体に関する情報の収集に依存しており、簡単に言えば、各 TiKV ノードのステータスと各リージョンのステータスを知る必要があります。TiKV クラスターは 2 種類のメッセージを PD に報告します。

各 TiKV ノードは定期的にノードの全体的な情報を PD に報告します。

TiKV ノード (ストア) と PD の間にはハートビートパケットがあり、PD はハートビートパケットを使用して各ストアが生きているかどうか、新しいストアがあるかどうかを検出します。ストアのステータス情報も掲載しています。主に次のものが含まれます。

総ディスク容量
空きディスク容量
運ぶリージョンの数
データ書き込み速度
送受信されたスナップショットの数 (スナップショットを介してレプリカ間でデータが同期される場合があります)
過負荷ですか
タグ情報（タグとは階層関係のある一連のタグのこと）

各ラフトグループのリーダーは定期的に情報をPDに報告します。

各 Raft グループのリーダーと PD の間にはハートビートパケットがあり、主に次の情報を含むリージョンのステータスを報告するために使用されます。

リーダーの立場
フォロワーの位置
オフラインレプリカの数
データの書き込み/読み出し速度

PD は、これら 2 種類のハートビートメッセージを通じてクラスター全体の情報を継続的に収集し、この情報を意思決定の基礎として使用します。さらに、PD は管理インターフェイスを通じて追加情報を受け取り、より正確な意思決定を行うこともできます。例えば、あるストアのハートビートパケットが途切れた場合、PDはそのノードが一時的か永続的無効かを判断できず、一定時間(デフォルトは30分)待つことしかできません。ハートビートパケットが無い場合は、ストアが失敗したと見なされます。オフラインにして、ストア上のすべてのリージョンをディスパッチすることを決定します。ただし、運用保守担当者が率先して特定のマシンをオフラインにする場合があります。このとき、ストアが利用できないことを PD の管理インターフェイスを通じて PD に通知すると、PD はすべてのリージョンが利用できないことを即座に判断できます。ストア上で発送する必要があります。

5 スケジュール戦略

PD がこの情報を収集した後、特定のスケジュール計画を策定するためにいくつかの戦略が必要になります。

(1) リージョン内のレプリカの数が正しい

PD は、リージョンリーダーのハートビートパケットを通じて、このリージョン内のレプリカの数が要件を満たしていないことを検出した場合、レプリカの追加/削除操作を通じてレプリカの数を調整する必要があります。この問題が発生する考えられる理由は次のとおりです。

ノードがオフラインになり、ノード上のすべてのデータが失われ、その結果、一部のリージョンでレプリカの数が不十分になります
切断されたノードはサービスを再開し、自動的にクラスターに接続します。そのため、レプリカで補充されたリージョン内のレプリカの数が多すぎるため、特定のレプリカを削除する必要があります。
管理者はレプリカポリシーを調整し、最大レプリカの構成を変更しました

(2) Raft グループ内の複数のレプリカが同じ場所にない

2 番目の点、「Raft グループ内の複数のレプリカは同じ場所にない」に注意してください。ここでは「同じノード」の代わりに「同じ場所」を使用しています。一般に、PD は、単一ノードの障害によって引き起こされる複数のレプリカの損失を回避するために、複数のレプリカが 1 つのノードに存在しないことのみを保証します。実際の展開では、次の要件も発生する可能性があります。

複数のノードが同じ物理マシン上にデプロイされている
TiKV ノードは複数のラックに分散されており、単一ラックの電源がオフになっている場合でもシステムの可用性が保証されることが期待されています。
TiKV ノードは複数の IDC に分散されており、単一のコンピュータ室の電源がオフになっている場合でもシステムを利用できることが期待されています。

これらの要件は、基本的に、特定のノードが最小フォールトトレラントユニットを形成するための共通の場所属性を持っていることです。このユニット内にリージョンの複数のレプリカが存在しないことを望みます。現時点では、PD でロケーションラベルを構成することで、ノードのラベルを構成し、どのラベルがロケーション識別子であるかを指定できます。レプリカが割り当てられるときは、リージョンの複数のレプリカが同じを持つノードが存在しないようにしてください。場所の識別子。

、

(3) ストア間のレプリカの分散は均等に分散されます。

前述したように、各コピーに保存されるデータ容量の上限は固定されているため、各ノードでバランスのとれたコピー数が維持され、全体の負荷がより分散されます。

(4) リーダーの数は店舗間で均等に配分されます

Raft プロトコルはリーダーを介して読み取りと書き込みを行うため、計算負荷は主にリーダーにかかり、PD はリーダーをノード間で可能な限り分散しようとします。

(5) アクセスホットスポットの数は店舗間で均等に分散されます。

情報を報告する際、各ストアおよびリージョンリーダーは、キーの読み取り/書き込み速度など、現在のアクセス負荷に関する情報を伝えます。PD はアクセスホットスポットを検出し、それをノード間で分散します。

(6) 各店舗が占有する保管スペースはほぼ等しい

各ストアの開始時に、ストアのストレージスペースの上限を示す Capacity パラメータが指定され、PD はスケジュール時にノードの残りのストレージスペースを考慮します。

(7) オンラインサービスへの影響を避けるためにスケジューリング速度を制御する

スケジュール操作は CPU、メモリ、ディスク IO、ネットワーク帯域幅を消費するため、オンラインサービスへの過度の影響を避ける必要があります。PD は現在進行中の操作の数を制御します。デフォルトの速度制御は比較的控えめです。スケジューリングを高速化したい場合 (サービスアップグレードの停止、新しいノードの追加、できるだけ早くスケジュールしたい場合など)、 pd-ctl の速度により、スケジューリングを手動で高速化できます。

(8) 手動オフラインノードをサポート

ノードが pd-ctl を通じて手動でオフラインになると、PD は特定のレート制御の下でノードにデータをディスパッチします。スケジューリングが完了すると、ノードはオフラインになります。

6 スケジューリングの実現

上記の情報を理解した後、スケジューリングプロセス全体を見てみましょう。

PD は、Store または Leader のハートビートパケットを通じて継続的に情報を収集し、クラスター全体の詳細なデータを取得し、これらの情報とスケジューリングポリシーに基づいてスケジューリング動作シーケンスを生成します。PD は、Region Leader からハートビートパケットを受信するたびに、For のハートビートパケットがあるかどうかを確認します。このリージョンで実行される操作は、ハートビートパケットの応答メッセージを通じてリージョンリーダーに返され、後続のハートビートパケットで実行結果が監視されます。なお、ここでの操作はリージョンリーダーへの提案であり、実行を保証するものではなく、実行するかどうか、いつ実行するかはリージョンリーダー自身の現状に応じて決定されます。

7 まとめ

ここでは、TiDB のあらゆる設計の背後に考慮事項があることがわかります。分散ストレージシステムのスケジューリング時に考慮する必要があること、戦略と実装を分離する方法、およびより柔軟なサポート戦略の拡張について理解していただければ幸いです。ここでは、TiDB の技術的な内容について説明し、TiDB 全体の基本的な概念と実装原理についてご理解いただければ幸いです｡詳細については、公式 Web サイトの技術記事を参照してください。