HARP Functionality Overview¶

HARPは、 BDRクラスターの高可用性への新しいアプローチです。コンセンサス主導のクォーラムを活用して、半排他的な方法で正しい接続エンドポイントを決定し、アプリケーションからの意図しないマルチノード書き込みを防ぎます。

クォーラムの重要性¶

HARPの主な目的は、管理するPostgresクラスターにフルクォーラムを適用することです。定足数は、一般的に投票機関に適用される用語であり、特定の最小限の出席者が決定をmakeことを義務付けています。または、おそらくもっと簡単に：マジョリティルール。

投票が同オーダー以外の結果で終わるためには、奇数個のノードが完全なクラスターメンバーシップを構成する必要があります。ただし、定足数はこの制約を厳密に要求しません。シンプル過半数で十分です。これは、Nノードのクラスターでは、クォーラムが意味のある投票を行うために最低N / 2 + 1ノードを必要とすることを意味します。

このすべてにより、クラスターがどのノードを「担当」するかに関して常に合意することが保証されます。マルチプルのノードで構成されるBDRクラスターの場合、これにより、どのノードがプライマリ書き込みターゲットであるかが決まります。 HARPは、このノードをリードマスターとして指定します。

書き込みターゲットの削減¶

クォーラムの概念を無視するか、それを不十分に適用すると、「正しい」書き込みターゲットがあいまいまたは不明なスプリットブレインシナリオが発生する可能性があります。標準のPostgresクラスターでは、1つのノードのみが書き込み可能で、残りのノードにレプリケーショントラフィックを送信することが重要です。

BDRなどのマルチマスター対応のアプローチでも、必要な競合管理の量を減らして、クラスター全体で同一のデータを取得することは有益です。物理的場所または地域ごとにマルチプルのBDRノードで構成されるクラスターでは、これは通常、単一のBDRノードが「リーダー」として機能し、残りのノードが「シャドウ」であることを意味します。これらのShadowノードは引き続き書き込み可能ですが、どうしても必要な場合を除き、書き込みはお勧めできません。

Quorumを活用することで、すべてのノードがどのPostgresノードがクラスター全体またはローカルBDRリージョンを表すかを正確に一致させることができます。定義、クォーラムの残りの部分との接続を失ったノード、またはそれによって無効にされたノードは、クラスターリーダーになることはできません。

これにより、書き込みが意図せずに2つのPostgresノードに到達するスプリットブレインの状況を防ぎます。 VPN、プロキシ、ロード、DNSなどのテクノロジとは異なり、構成の誤りやネットワークパーティションによって定足数から派生したコンセンサスを回避することはできません。コンセンサスレイヤーに連絡してHARPによって維持されるクォーラムの状態を判断できる限り、有効なターゲットは1つだけです。

基本アーキテクチャ¶

HARPのデザインは、基本的にマネージャーとプロキシからなる2つの部分で構成されています。次の図は、これらが単一のPostgresインスタンスとどのように相互作用するかを説明しています。

コンセンサスレイヤーは、Harp Managerが割り当てられたPostgresノードについて学習した情報を維持する外部エンティティであり、 HARPプロキシはこの情報を有効なPostgresノードターゲットに変換します。プロキシはコンセンサスレイヤーからノードターゲットを取得するため、このようなインスタンスがいくつか独立して存在する場合があります。

BDR自分自身をコンセンサスレイヤーとして使用している間、各サーバーノードは代わりにこのバリアントに似ています。

いずれの場合も、各ユニットは次の要素で構成されます。

PostgresまたはEDBインスタンス
Postgresのさまざまな属性を追跡するためのコンセンサスレイヤーリソースインスタンス
Postgresノードの状態を伝えるHARP Managerプロセスコンセンサスレイヤー *トラフィックを適切なリードマスターノードに転送するHARPプロキシサービスコンセンサスレイヤーから派生

すべてのアプリケーションスタックがプロキシコンポーネント専用の追加ノードリソースにアクセスできるわけではないため、アプリケーションサーバーと組み合わせてスタック自分自身を簡素化できます。

これは、リードマスター/シャドウマスター構成で編成された単一のデータセンターで2つのBDRノードを使用する一般的なデザインです。

BDR自分自身をHARPコンセンサスレイヤーとして使用する場合、クォーラムマジョリティを保証には、少なくとも3つの完全修飾BDRノードが存在する必要があることに注意してください。

（上の図には、 BDRノード間の接続は示されていません。）

仕組み¶

BDRクラスターを管理する場合、 HARPは定義されたロケーションごとに最大1つの「リーダー」ノードを維持します。正式には、これはリードマスターと呼ばれます。この位置を取るのに適格な他のBDRノードは、それらがリーダーのロールを引き受けるときまでシャドウマスター状態です。

アプリケーションは、プロキシサービスを介してのみ現在のリーダーに連絡できます。コンセンサスレイヤーはリーダーの状態を伝える前にクォーラム契約を必要とするため、すべてのプロキシサービスがトラフィックをそのノードに転送します。

高レベルでは、これが最終的にマルチプルのノードとのアプリケーションの相互作用を同時に妨げるものです。

リーダーの決定¶

例として、単一のデータセンター内に存在する可能性がある、ローカルに細分化されたBDR Always-Onグループ内のリードマスターのロールを検討します。 PostgresまたはManagerリソースが開始され、構成可能なリフレッシュインターバルの後、以下が発生する必要があります。

Managerは、割り当てられたPostgresリソースのステータスを確認します。 Postgresが実行されていない場合は、設定可能なタイムアウト後に再試行してください。 Postgresが実行されている場合、続行します。 2. Managerは、コンセンサスレイヤーでリーダーリースのステータスを確認します。 -リースが請求されていない場合、リースを取得し、このManagerに割り当てられたPostgresインスタンスのIDを割り当てます。このリース期間は設定可能ですが、長すぎると予期しないリーダーシップの移行が発生する可能性があります。 -リースが既に請求されている場合は、リースTTLを更新します。 -それ以外の場合は何もしません。

ここでは明らかにもっと多くのことが起こりますが、この単純化されたバージョンは何が起こっているのかを説明するはずです。リーダーリースは1つのノードでのみ保持でき、他の場所で保持されている場合、 HARPマネージャーはあきらめて後で再試行します。

注釈

選択したコンセンサスレイヤーに応じて、リーダーリースのステータスを確認するために繰り返しループするのではなく、 HARPは代わりに通知をサブスクライブします。この場合、ポーリングではなく、リースの状態が変わるとすぐに応答できます。現在、この機能はetcdコンセンサスレイヤーに制限されています。

これは、 HARP自分自身が選挙を行わず、クォーラムを管理しないことを意味します。これはコンセンサスレイヤーに委任されます。リースを取得する行為は、コンセンサスレイヤーのクォーラムによって承認される必要があるため、要求が成功した場合、そのノードはそのロケーションのクラスターをリードします。

接続ルーティング¶

リードマスターのロールが確立されると、 HARPプロキシに反映されるのと同様の確定的な結果で接続が処理されます。 HARPプロキシが特定のバックエンドリソースの接続ターゲットを決定するニーズがある場合を考えます。

HARPプロキシは、構成された場所にある現在のリードマスターのコンセンサスレイヤーに問い合わせます。 2.これが未設定または移行中の場合; Postgresへの新しいクライアント接続は禁止されていますが、クライアントは蓄積され、リードマスターが表示されるまで一時停止状態になります。 -既存のクライアント接続は現在のトランザクションを完了することができ、新しい接続と同様の保留状態に戻ります。 3.クライアント接続がリードマスターに転送されます。

この場合に示される相互作用は、 HARP ManagerまたはPostgresとの相互作用を必要としないことに注意してください。コンセンサスレイヤー自分自身は、プロキシの観点からのすべての真実のソースです。

コロケーション¶

ワークユニットの配置は、組織がこれらの原則に従うことを要求されるようなものです。

ManagerとPostgresユニットは、同じノード内に同時に存在する必要があります。 2.コンセンサスレイヤーの内容は、すべての運用ワークユニットの規範ロールを決定します。

これにより、クラスタークォーラムの責任がコンセンサスレイヤー自分自身に委任されますが、 HARPは重要なロールの割り当てとキー/値のストレージにそれを活用します。コンセンサスレイヤーが動作不能または到達不能である場合、ストレージも取得も成功せず、したがって、不正なPostgresノードが接続を受け入れることを防ぎます。

その結果、コンセンサスレイヤーは、安全性を最大限に高めるために、一般にHARPまたはHARP管理対象ノードの外部に存在する必要があります。リファレンス図は、このような分離を促進オーダーにこれを反映していますが、必須ではありません。

注釈

クラスター状態を操作および管理するオーダーに、 BDRにはRaft Consensusモデルの独自の実装が含まれています。 HARPは、この同じレイヤーを活用して外部依存への依存を減らし、サーバーリソースを保持するように構成できます。ただし、このアプローチには特定の欠点があり、コンセンサスレイヤーのセクションでさらに詳しく説明します。

推奨されるアーキテクチャと使用¶

HARPは、主に2つ（またはそれ以上）のデータセンター内にあり、少なくとも5つのBDRノードで構成されるBDR Always-Onアーキテクチャを表すように設計されました。これは、ロジカルスタンバイノードをカウントしません。

これの現在および標準の表現形式は、次の図で見ることができます。

この図では、 HARP ManagerはBDRノード1〜4に存在します。クラスターの初期状態は、 BDRノード1がDC Aのリードマスタであり、 BDRノード3がDC Bのリードマスターであるということです。

これにより、DC AのHARPプロキシリソースがBDRノード1に接続され、同様にDC BのHARPプロキシリソースがBDRノード3に接続されます。

注釈

この図はDCごとに1つのHARPプロキシのみを示していますが、これは単なる例示であり、単一障害点と見なされるべきではありません。任意の数のHARPプロキシノードが存在する場合があり、それらはすべてアプリケーショントラフィックを同じノードに向けます。

ロケーション設定¶

マルチプルのBDRノードがロケーションでリードマスターロックを取得できるようにオーダーには、config.yml構成ファイル内でロケーションを定義する必要があります。

上記の図を再現するには、 BDRノード1および2のconfig.yml構成に次の行を追加します。

location: dca

BDRノード3および4の場合：

location: dcb

これは、それぞれのデータセンターで指定されているHARPプロキシノードにも適用されます。

BDR 3.7互換性¶

BDR 3.7以降では、 BDRノード自分自身にロケーションを割り当てることにより、より直接的なロケーション定義を提供します。これは、 BDRノードに接続しているときに次のSQL APIファンクションを呼び出すことで実行されます。したがって、 BDRノード1および2の場合、次のようにします。

SELECT bdr.set_node_location(dca);