Consensus layer considerations¶

HARPは、分散制御システム（DCS）としても知られるコンセンサスレイヤーのさまざまな実装で動作できるように設計されています。

現在、次のDCS実装がサポートされています。

etcd - BDR

この情報は、サポートされているDCS実装とHARPの相互作用に固有です。

BDRドライバーの互換性¶

bdr ネイティブコンセンサスレイヤーは、 BDRバージョン 3.6.21 および 3.7.3 から利用できます。

投票クォーラムを維持するために、 BDR論理スタンバイノードはEDB Postgres分散クラスターでのコンセンサス通信に参加しません。 DCSクォーラム要件を満たすために、これらを合計ノードリストでカウントしないでください。

クォーラムの維持¶

どのアーキテクチャのクラスターでも、投票クォーラムを介してコンセンサスを維持するには、少なくともn/2 + 1個のノードが必要です。したがって、3ノードのクラスターは単一ノードの停止を許容でき、5ノードのクラスターは2ノードの停止を許容できます。コンセンサスが失われると、DCSが特定の場所のリードマスターであるノードを決定的に識別できないため、 HARPは動作不能になります。

その結果、どちらのDCSを選択しても、ノードの半分以上が常に_クラスター全体で_使用可能である必要があります。これは、DCSノードを2つ以上のデータセンターに分散する場合、重要な要素になる可能性があります。ネットワークパーティションは、投票過半数を維持できない場所でクォーラムを防止するため、 HARPが動作を停止します。

したがって、コンセンサスレイヤーを構築するときは、奇数のノード（最低3つ）が重要です。理想的なケースは、ノードを少なくとも3つの独立した場所に分散して、単一のネットワークパーティションがコンセンサスを混乱させないようにすることです。

1つの構成例は、2つのデータセンターにプライマリBDRノードと一致する2つのDCSノードを指定し、他の場所に5番目のDCSノード（ BDRなど）を指定することです。このような設計を使用すると、2つのBDRデータセンター間のネットワークパーティションは、独立して配置されたノードのおかげでコンセンサスを混乱させません。

マルチコンセンサスバリアント¶

HARPは、設定されたロケーションごとに1つのリードマスターを想定しています。通常、各場所は location 構成設定を使用してHARPで指定されます。ロケーションごとに個別のDCSクラスターを作成することにより、 HARPとは無関係にこの動作をエミュレートできます。

これを行うには、目的の場所ごとに異なるDCS接続ターゲットを使用するようにconfig.yml でHARPを構成します。

DC-AのHARPノードは次のようなものを使用します。

location: dca
dcs:
  driver: etcd
  endpoints:
    - dcs-a1:2379
    - dcs-a2:2379
    - dcs-a3:2379

DC-Bは、正規の場所にあるノードに対応する異なるホスト名を使用しますが：

location: dcb
dcs:
  driver: etcd
  endpoints:
    - dcs-a1:2379
    - dcs-a2:2379
    - dcs-a3:2379

このデザインには異なるデータセンター間のDCS通信がないため、それらの間のネットワークパーティションはHARPオペレーションに影響しません。この結果、 HARPは他の場所のノードを完全に認識せず、各場所は本質的に別個のHARPクラスターとして動作します。

BDRをDCSとして使用する場合、 BDRはすべての参加者ノードにわたってコンセンサスレイヤーを維持するため、これは不可能です。

このアプローチの潜在的な欠点は、 harpctl が現在の場所の外部のノードと対話できないことです。ノード情報の取得、リードマスターの取得または設定、または他の場所をターゲットとするその他の操作を実行することはできません。基本的に、この組織はharpctl への--location パラメーターを使用不可にします。

TPAexecとコンセンサス¶

これらの考慮事項もTPAexecに統合されています。 etcdを使用してクラスターをデプロイすると、ロケーションごとに個別のDCSクラスターが構築され、厳密な一貫性を維持しながら高可用性が促進されます。

したがって、この構成例では、 first の場所に割り当てられたDCSノードをグループ化し、 second の場所は別のクラスターです。

cluster_vars:
  failover_manager: harp
  harp_consensus_protocol: etcd

locations:
  - Name: first
  - Name: second

この動作をオーバーライドするには、特定のグループ化を強制するようにharp_location を暗黙的に構成します。

したがって、この例では、すべてのetcdノードを単一の凝集DCSレイヤーに返します。

cluster_vars:
  failover_manager: harp
  harp_consensus_protocol: etcd

locations:
  - Name: first
  - Name: second
  - Name: all_dcs

instance_defaults:
  vars:
    harp_location: all_dcs

harp_location オーバーライドは、従来のデータセンターよりもリージョンのアベイラビリティーゾーンを優先するAmazonなどのクラウドプロバイダーを使用する場合、特定のノードグループを優先するためにも必要になる場合があります。

Consensus layer considerations¶

BDRドライバーの互換性¶

クォーラムの維持¶

マルチコンセンサスバリアント¶

TPAexecとコンセンサス¶

前のトピックへ

次のトピックへ

目次