Consensus Layer Considerations¶

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

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

-etcd- BDR

このセクションでは、サポートされているDCS実装とHARPの相互作用に固有の情報を提供します。

BDRドライバーの互換性¶

bdrネイティブコンセンサスレイヤーは、それぞれBDRバージョンから入手できます。

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

クォーラムの維持¶

任意のアーキテクチャのクラスターは、投票定足数を介してコンセンサスを維持するために少なくともn / 2 + 1ノードを必要とします。したがって、3ノードのクラスターは単一ノードの停止に耐えることができ、5ノードのクラスターは2ノードの停止に耐えることができます。コンセンサスが失われた場合、DCSが特定のロケーション内のどのノードがリードマスターであるかを決定論的に識別することを妨げるため、 HARPは動作不能になります。

その結果、どちらのDCSが選択されても、ノードの半分以上が常に_cluster-wide_で利用可能でなければなりません。これは、2つ以上のデータセンター間でDCSノードを配布するときに重要な要素になる可能性があります。ネットワークパーティションは、多数決を維持できない場所のクォーラムを妨げるため、 HARPは運用を停止します。

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

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

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

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

これを行うには、config.ymlでHARPを設定して、目的の場所ごとに異なるDCS接続ターゲットを使用する必要があります。

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

このデザインには異なるData Centersの間のDCS通信が全くありません、そして、したがって、それらの間のNetwork PartitionはHARPオペレーションにインパクトないでしょう。この結果、 HARPは他のロケーションのノードを完全に認識せず、各ロケーションは本質的に別個のHARPクラスターとして動作します。

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

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

TPAexecとコンセンサス¶

上記の考慮事項もTPAexecに統合されています。 etcdを使用してクラスターをデプロイすると、ロケーションごとに個別のDCSクラスターが自動的にコンストラクト、厳密な整合性を優先して高可用性が促進されます。

したがって、この構成例：

cluster_vars:
   * failover_manager: harp
   * harp_consensus_protocol: etcd

locations:
   * - Name: first
   * - Name: second

firstロケーションに割り当てられたDCSノードをグループ化すると、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オーバーライドは、従来のデータセンターを優先してリージョン内のAvailabilityZonesを優先するAmazonなどのクラウドプロバイダーを使用する場合に、特定のノードグループを優先するためにも必要になる場合があります。

Consensus Layer Considerations¶

BDRドライバーの互換性¶

クォーラムの維持¶

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

TPAexecとコンセンサス¶

前のトピックへ

次のトピックへ

目次