Always-On Architecture

Always-On Architecture#

PGDのアーキテクチャは、組織のニーズを満たすために時間の経過とともに進化してきました。その中核は、Postgresデータベースの高可用性とディザスターリカバリーを提供するように設計されたAlways-onアーキテクチャです。 PGD 4および5で定義されたAlways-onアーキテクチャは、PGD 6の新しい機能と機能をサポートするように進化しました。

Always-onアーキテクチャは、EDBのTrused Postgresアーキテクチャを反映しています。これらはプラクティスをカプセル化し、複数の構成で可能な限り最高のサービスの可用性を達成するのに役立ちます。これらの構成は、単一ロケーションのアーキテクチャから、ハードウェア障害やデータセンターの障害から保護する複雑な分散システムにまで及びます。このアーキテクチャは、 EDB Postgres Distributedのマルチマスター機能と、メンテナンス操作中でも99.999%の可用性を達成する機能を活用します。

ここで説明する例を超えたアーキテクチャにEDB Postgres分散を使用できます。ユースケース固有のバリエーションは、実稼働環境に正常に展開されました。ただし、これらのバリエーションは、最初に厳密なアーキテクチャレビューを受ける必要があります。

標準EDB Always-onアーキテクチャ#

EDBは、目標復旧ポイントRPOおよび目標復旧時間RTOの要件に応じて、さまざまなレベルの冗長性で単一またはマルチロケーションの展開をサポートするための標準化されたアーキテクチャを特定しました。

Always-onアーキテクチャは、基本的なビルディングブロックとして3つのデータベースノードグループを使用します。冗長性を高めるために5つのノードグループを使用することもできます。

EDB Postgres Distributedは、次の主要なビルディングブロックで構成されています。

  • 双方向レプリケーションBDR—マルチマスターメッシュネットワークを作成するPostgres拡張機能

  • 接続マネージャー —アプリケーションが適切なデータノードに接続されていることを確認する接続ルーター。

すべてのAlways-onアーキテクチャは、増加する範囲の障害状況を保護します。たとえば、2つのデータノードを持つ単一のアクティブなロケーションは、ローカルハードウェア障害から保護しますが、ロケーションデータセンターまたはアベイラビリティーゾーンの障害からの保護は提供しません。別の場所にあるバックアップを使用してそのアーキテクチャを拡張することにより、場所が壊滅的に損失した場合に備えて、ある程度の保護が保証されます。ただし、最初にバックアップからデータベースを復元する必要があるため、RTO要件に違反する可能性があります。マルチマスターメッシュネットワークで接続された2番目のアクティブなロケーションを追加すると、ロケーションがオフラインになってもサービスは利用可能なままです。最後に、3番目の場所これは監視専用の場所にすることができますを追加すると、1つの場所がオフラインになった場合でもグローバルRaft機能が動作できます。グローバルRaftは、主に管理コマンドを実行するために必要です。また、 DDLやシーケンスの割り当てなどの一部の機能は、それなしでは動作しない場合がありますが、DMLレプリケーションは、グローバルRaftなしでも動作し続けます。

データは少なくとも1つのローカルマスターに同期してストリーミングできるため、各アーキテクチャはゼロRPOを提供でき、ローカルハードウェアに障害が発生した場合のデータ損失ゼロを保証します。

可用性保証を強化すると、ハードウェアとライセンス、ネットワーク要件、および操作の複雑性の追加コストが常に増加します。アーキテクチャを選択する前に、可用性とコンプライアンス要件を注意深く検討することが重要です。

アーキテクチャの詳細#

デフォルトでは、アプリケーショントランザクションはDMLのクラスター全体のコンセンサス選択、挿入、更新、および削除を必要としないため、レイテンシーが低下し、パフォーマンスが向上します。ただし、新しいグローバルシーケンスの生成や分散DDLの実行などの特定の操作の場合、 EDB Postgres Distributedは Raft ベースのコンセンサスモデルを使用して決定を行うための奇数のノードが必要です。したがって、より単純なアーキテクチャでも、すべてのノードがデータを保存しているわけではない場合でも、常に3つのノードがあります。

アプリケーションは、マルチホスト接続文字列を介して標準のAlways-onアーキテクチャに接続します。各接続マネージャーは、マルチホスト接続文字列の個別のエントリです。

他の接続メカニズムは実稼働環境に正常に展開されています。ただし、これらは標準のAlways-onアーキテクチャの一部ではありません。

常時接続の単一ロケーション#

Always-on 1 Location, 3 Nodes Diagram

Always-on 1 Location, 3 Nodes Diagram#

  • データノード1と3間の追加のレプリケーションは表示されていませんが、レプリケーションメッシュの一部として発生します

  • ローカル障害から迅速に復元するための冗長ハードウェア 3 PGDノード 3つのデータノードにすることができます推奨 2つのデータノードと、データを保持しない1つの監視であることができます 図示されていません データノードの構成とインフラストラクチャの対称性は再ルーティングされたときにアプリケーションのワークロードを処理するために適切なリソースが利用できることを保証することが期待されます

  • バックアップとリカバリーのためのBarman不図示 オフサイトはオプションですが推奨 マルチプルのPGDクラスターで共有できます

  • モニタリング用のPostgres Enterprise ManagerPEM（図示されていません） *マルチプルのPGDクラスターで共有できます

常時接続のマルチロケーション#

Always-on 2 Locations, 3 Nodes Per Location, Active/Active Diagram

Always-on 2 Locations, 3 Nodes Per Location, Active/Active Diagram#

  • アプリケーションは、各場所でアクティブ/アクティブにするか、アクティブ/パッシブまたは書き込みを行う1つの場所のみを使用するアクティブDRにすることができます。

  • データノード1と3間の追加のレプリケーションは表示されていませんが、レプリケーションメッシュの一部として発生します。

  • ローカル障害から迅速に復元するための冗長ハードウェア。 合計6つのPGDノード、各ロケーションに3つ 3つのデータノードにすることができます推奨 2つのデータノードと、データを保持しない1つの監視にすることができます不図示 データノードと場所の構成とインフラストラクチャの対称性は、次のとおりであると予想されます。再ルーティングされたときにアプリケーションのワークロードを処理するために適切なリソースが利用できることを確認

  • バックアップとリカバリーのBarman図示されていません。 *マルチプルのPGDクラスターで共有できます

  • モニタリングのためのPostgres Enterprise ManagerPEMは示されていません。 *マルチプルのPGDクラスターで共有できます

  • オプションの監視ノードを3番目のリージョンに配置して、ロケーション障害の許容度を高める必要があります。 *それ以外の場合、ロケーションに障害が発生すると、新しいノードや分散DDLの追加など、グローバルコンセンサスを必要とするアクションがブロックされます。

アーキテクチャの選択#

すべてのアーキテクチャは以下を提供します。

  • ハードウェア障害保護

  • ゼロダウンタイムのアップグレード

  • パブリック/プライベートクラウドでのアベイラビリティーゾーンのサポート

これらの基準を使用して、適切なAlways-onアーキテクチャを選択します。

Single-data location

Two data locations

Two data locations + witness

Three or more data locations

Locations needed

1

2

3

3

Fast restoration of local HA after data node failure

Yes - if 3 PGD data nodes No - if 2 PGD data nodes

Yes - if 3 PGD data nodes No - if 2 PGD data nodes

Yes - if 3 PGD data nodes No - if 2 PGD data nodes

Yes - if 3 PGD data nodes No - if 2 PGD data nodes

Data protection in case of location failure

No (unless offsite backup)

Yes

Yes

Yes

Global consensus in case of location failure

N/A

No

Yes

Yes

Data restore required after location failure

Yes

No

No

No

Immediate failover in case of location failure

No - requires data restore from backup

Yes - alternate Location

Yes - alternate Location

Yes - alternate Location

Cross-location network traffic

Only if backup is offsite

Full replication traffic

Full replication traffic

Full replication traffic

License cost

2 or 3 PGD data nodes

4 or 6  PGD data nodes

4 or 6 PGD data nodes

6+ PGD data nodes

標準アーキテクチャに柔軟性を追加する#

必要なデータの復元力と、アプリケーションとデータを維持するユーザーへの近接性を提供するために、単一ロケーションアーキテクチャを必要なだけ多くの場所に展開できます。 EDB Postgres分散には、さまざまな競合処理アプローチが利用できますが、地理的に異なる場所からの書き込みアクティビティを許可する場合、予想される衝突数を最小限に抑えるように注意してください。

2つの追加タイプのノードを使用して標準アーキテクチャを拡張することもできます。

  • サブスクライバー専用ノード アプリケーションのワークロードの大部分が読み取り集中であり、書き込みが低い場合に、追加の読み取りスケーラビリティを実現し、データをユーザーの近くに配置するために使用できます。それらを活用して、レポート、アーカイブ、分析ニーズに合わせてデータのサブセットを公開することもできます。

  • 論理スタンバイ PGDクラスター内の別のノードからレプリケートデータを受信しますが、レプリケーションメッシュまたはコンセンサスに参加しません。これらには、他のPGDデータノードとすべて同じデータが含まれており、データノードの1つがクラスターをフルキャパシティ/コンセンサスに戻すことができなかった場合、すぐにマスターに昇格できます。データセンター間のネットワークトラフィックが懸念される環境で使用できます。それ以外の場合、ロケーションごとに3つのPGDデータノードが常に優先されます。

目次