Cluster Bootstrapping

HARPを使用オーダーには、最小限のメタデータがDCSに存在する必要があります。クラスターを「ブートストラップ」するプロセスとは、本質的に、ノード、場所、およびその他のランタイム構成を一度に、またはリソースごとに初期化することを意味します。

このプロセス全体は、harpctl applyコマンドによって管理されます。詳細については、harpctl docsを確認してください。

このセクションでは、DCSがセットアップされ機能していることを前提としています。

!!! Important * このドキュメントの例は、セクションごとにブートストラップを行う必要があることを示していますが、そうではありません。これらのいずれかまたはすべてを1つのYAMLドキュメントに結合し、一度にすべて適用することができます。説明と簡略化のために、これらのセクションを単純に分割します。

クラスター全体のブートストラップ

一部の設定はクラスタ全体に適用され、ブートストラップ中に指定できます。現在、これはevent_sync_intervalランタイムディレクティブにのみ適用されますが、他のものは後で追加される可能性があります。

このフォーマットは次のとおりです。

cluster:
   * name: mycluster
   * event_sync_interval: 100

ファイルの名前付けがcluster.ymlであると仮定すると、次のように適用します。

harpctl apply cluster.yml

クラスター名前がDCS内でまだ定義されていない場合、これもその値を初期化します。

!!! Important * ここで指定されたクラスター名前パラメータは、config.ymlで指定されたクラスター名前を常にオーバーライドします。前提は、ブートストラップファイルがクラスターまたはその大規模構成の一部をブートストラップするために必要なすべての要素を提供することです。 config.ymlファイルの主な目的は、 HARPマネージャー、 HARPプロキシ、またはharpctlの実行を具体的に制御することです。

場所のブートストラップ

すべてのHARPノードは、最大で1つのロケーションに関連付けられます。このロケーションは、単一のデータセンター、マルチプルの基礎となるサーバーで構成されるグループ化されたリージョン、Amazonアベイラビリティーゾーンなどです。これは、 HARPがノードをグループ化して、その場所のノードをリードマスターとして表すことができるようにする論理構造にすぎません。

したがって、1つ以上の場所を初期化する必要があります。このフォーマットは次のとおりです。

cluster:
   * name: mycluster

locations:
   * - location: dc1
   * - location: dc2

ファイルの名前付けがlocations.ymlであると仮定すると、次のように適用します。

harpctl apply locations.yml

クラスターの操作を実行するときは、名前をプリアンブルとして含めて、変更が適切な場所に送られるようにしてください。

ロケーションがブートストラップされると、簡単な検査で表示されます。

> harpctl get locations

Cluster   Location Leader Previous Leader Target Leader Lease Renewals
-------   -------- ------ --------------- ------------- --------------
mycluster dc1                                           <nil>
mycluster dc2                                           <nil>

ここで見られるように、両方の場所はHARPによって認識され、ノードとプロキシの割り当てに使用できます。

ノードのブートストラップ

HARPノードは名前付けクラスター内に存在し、指定された名前を持つ必要があります。これを超えて、他のすべての設定は動的であり、 HARPがそれらと対話する方法に影響を与える可能性があるため、DCS自分自身内に保持されます。このため、各ノードは、Configurationの文書で説明されている1つ以上のランタイム指示子を使用してブートストラップする必要があります。

ノードのブートストラップ中に、いくつかの必須フィールドがあります。

  • name

  • location

  • dsn

  • pg_data_dir

その他はすべてオプショナルであり、クラスター自分自身に依存する場合があります。一度にマルチプルのノードをブートストラップすることが可能であるため、一般的にこのフォーマットは次の構造に適合します。

cluster:
   * name: mycluster

nodes:
   * - name: node1
   *   location: dc1
   *   dsn: host=node1 dbname=bdrdb user=postgres
   *   pg_data_dir: /db/pgdata
   *   leader_lease_duration: 10
   *   priority: 500

ファイルの名前付けがnode1.ymlであると仮定すると、次のように適用します。

harpctl apply node1.yml

ノードがブートストラップされると、簡単な検査で表示されます。

> harpctl get nodes

Cluster   Name  Ready Role Type Location Fenced Lease Duration
-------   ----  ----- ---- ---- -------- ------ --------------
mycluster node1 true            dc1      false  30

プロキシブートストラップ

ロケーションやノードとは異なり、プロキシは、ロケーション内のすべてのプロキシに適用される構成テンプレートを提供することもできます。これらは、globalの指定でDCSに保存されます。各プロキシには、インスタンスとして存在する名前も必要ですが、特定の設定が必要な場合を除き、さらにカスタマイズする必要はありません。

これは、クラスターのデフォルト構成設定が同じプロキシがマルチプル存在する可能性が高く、これらの値を単一のプロキシで永久に繰り返す必要がないためです。

さらに、プロキシテンプレートをブートストラップする場合、接続の割り当て用に少なくとも1つのデータベースを定義する必要があります。これらの注意事項を念頭に置いて、このフォーマットは次のとおりです。

cluster:
   * name: mycluster

proxies:
   * monitor_interval: 5
   * default_pool_size: 20
   * max_client_connections: 1000
   * database_name: bdrdb
   * instances:
   *   - name: proxy1
   *   - name: proxy2
   *     default_pool_size: 50

これにより、2つのプロキシproxy1とproxy2のHARPが構成され、proxy2のみがカスタムdefault_pool_sizeを持ち、それ以外の場合はグローバル設定を使用します。

ファイルの名前付けがproxy.ymlであると仮定すると、次のように適用します。

harpctl apply proxy.yml

プロキシテンプレートがブートストラップされると、簡単な検査で表示されます。

> harpctl get proxies

Cluster   Name   Pool Mode Auth Type Max Client Conn Default Pool Size
-------   ----   --------- --------- --------------- -----------------
mycluster global session   md5       1000            20
mycluster proxy1 session   md5       1000            20
mycluster proxy2 session   md5       1000            50