HARP Functionality Overview¶

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

クォーラムの重要性¶

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

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

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

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

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

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

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

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

基本アーキテクチャ¶

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

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

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

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

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

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

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

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

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

仕組み¶

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

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

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

リーダーの決定¶

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

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

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

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

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

接続ルーティング¶

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

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

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

コロケーション¶

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

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

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

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

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

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

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に接続されます。

!!! Note * この図は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以上では、aLocationをBDRノード自分自身に割り当てることにより、より直接的なロケーション定義を提供します。これは、 BDRノードに接続している間に次のSQLAPIファンクションを呼び出すことで実行されます。したがって、 BDRノード1および2の場合、これを行うことができます。

SELECT bdr.set_node_location('dca');