Choosing your architecture¶
Always Onアーキテクチャは、EDBのTrusted Postgresアーキテクチャを反映しています。これらはプラクティスをカプセル化し、複数の構成で可能な限り最高のサービス可用性を達成するのに役立ちます。これらの構成は、単一ロケーションアーキテクチャから、ハードウェア障害やデータセンター障害から保護する複雑な分散システムにまで及びます。このアーキテクチャは、 EDB Postgres Distributedのマルチマスター機能と、メンテナンス操作中でも99.999％の可用性を達成するその機能を活用しています。
ここで説明されている例以外のアーキテクチャにも、 EDB Postgres Distributedを使用できます。ユースケース固有のバリエーションが本番環境に正常にデプロイされました。ただし、これらのバリエーションは、最初に厳密なアーキテクチャレビューを受ける必要があります。また、 Always Onアーキテクチャ用のEDBの標準デプロイツールでは、Trusted Postgres Architect（TPA）を有効にしてバリエーションをサポートしてからでないと、運用環境でサポートできません。
標準EDB Always Onアーキテクチャ¶
EDBは、目標復旧時点（RPO）と目標復旧時間（RTO）の要件に応じて、さまざまなレベルの冗長性を備えた単一または複数の場所の展開をサポートするための一連の標準化されたアーキテクチャを特定しました。
Always ONアーキテクチャは、基本的なビルディングブロックとして3つのデータベースノードグループを使用します。余分な冗長性のために5ノードグループを使用することもできます。
EDB Postgres Distributedは、次の主要なビルディングブロックで構成されています。
双方向レプリケーション（BDR） -マルチマスターメッシュネットワークを作成するPostgres拡張機能
PGDプロキシ -アプリケーションが適切なデータノードに接続されていることを確認する接続ルーター。
Always Onアーキテクチャはすべて、ますます多様化する障害状況を保護します。たとえば、2つのデータノードを持つ1つのアクティブな場所は、ローカルのハードウェア障害から保護しますが、場所（データセンターまたはアベイラビリティーゾーン）の障害からの保護は提供しません。別の場所にあるバックアップでそのアーキテクチャを拡張すると、場所の壊滅的な損失が発生した場合に備えて、ある程度の保護が保証されます。ただし、最初にバックアップからデータベースを復元する必要があります。これは、RTO要件に違反する可能性があります。マルチマスターメッシュネットワークに接続された2番目のアクティブロケーションを追加すると、ロケーションがオフラインになった場合でもサービスが利用可能なままになります。最後に、3番目の場所（これはwitness専用の場所にすることができます）を追加すると、1つの場所がオフラインになった場合でも、グローバルRaft機能が機能できます。グローバルRaftは、主に管理コマンドを実行するために必要です。また、 DDLやシーケンス割り当てなどの一部の機能は、それなしでは動作しない場合がありますが、DMLレプリケーションはグローバルRaftがなくても引き続き動作します。
データを少なくとも1つのローカルマスターに同期的にストリーミングできるため、各アーキテクチャはゼロRPOを提供でき、ローカルハードウェアに障害が発生した場合のデータ損失ゼロを保証します。
可用性の保証を高めると、常にハードウェアとライセンス、ネットワーク要件、運用の複雑さのコストが増加します。アーキテクチャを選択する前に、可用性とコンプライアンスの要件を慎重に検討することが重要です。
アーキテクチャの詳細¶
デフォルトでは、アプリケーショントランザクションはDML（選択、挿入、更新、および削除）のクラスター全体のコンセンサスを必要としないため、レイテンシーが低下し、パフォーマンスが向上します。ただし、新しいグローバルシーケンスの生成や分散DDLの実行などの特定の操作では、 EDB Postgres Distributedは Raft ベースのコンセンサスモデルを使用して決定を行うために奇数のノードを必要とします。したがって、より単純なアーキテクチャでも、すべてがデータを格納しているわけではない場合でも、常に3つのノードがあります。
アプリケーションは、マルチホスト接続文字列を介して標準のAlways Onアーキテクチャに接続します。各PGDプロキシサーバーは、マルチホスト接続文字列内の個別のエントリです。高可用性を確保するには、各場所に常に少なくとも2つのプロキシノードが必要です。プロキシをデータベースインスタンスと同じ場所に配置できます。その場合、すべてのデータノードにプロキシを配置することをお勧めします。
他の接続メカニズムは、本番環境に正常に展開されています。ただし、これらは標準のAlways Onアーキテクチャの一部ではありません。
Always On 1つの場所¶
Always On 1 Location, 3 Nodes Diagram¶
*データノード1と3間の追加のレプリケーションは表示されませんが、レプリケーションメッシュの一部として発生します
ローカル障害から迅速に復元する冗長ハードウェア 3つのPGDノード 3つのデータノードにすることができます（推奨） 2つのデータノードとデータを保持しない1つのウィットネスにすることができます（図示せず） アプリケーションへの親和性 データノードと併置可能
バックアップとリカバリのBarman（図示されていません） オフサイトはオプションですが、推奨 *複数のクラスターで共有できます
モニタリング用のPostgresEnterpriseManager（PEM）（図示せず） 複数のクラスターで共有可能
Always Onマルチロケーション¶
*アプリケーションは、各場所でアクティブ/アクティブにするか、1つの場所のみが書き込みを行うアクティブ/パッシブまたはアクティブDRにすることができます。
*データノード1と3間の追加のレプリケーションは表示されませんが、レプリケーションメッシュの一部として発生します。
ローカル障害から迅速に復元する冗長ハードウェア。 合計6つのPGDノード、各場所に3つ 3つのデータノードにすることができます（推奨） 2つのデータノードとデータを保持しない1つのwitnessにできます（図示されていません）アプリケーション *データノードと同じ場所に配置できます
バックアップとリカバリのBarman（図示せず）。 複数のクラスターで共有できます
監視用のPostgresEnterpriseManager（PEM）（図示せず）。 複数のクラスターで共有できます
ロケーション障害の耐性を高めるには、オプションの監視ノードを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 Distributedにはさまざまな競合処理アプローチが利用できますが、地理的に異なる場所からの書き込みアクティビティを許可する場合は、予想される衝突の数を最小限に抑えるように注意してください。
2種類のノードを追加して、標準アーキテクチャを拡張することもできます。
サブスクライバー専用ノード 。これを使用すると、読み取りのスケーラビリティが向上し、アプリケーションのワークロードの大部分が読み取り集中型で書き込み頻度が低い場合に、データをユーザーの近くに配置できます。また、それらを活用して、レポート、アーカイブ、および分析のニーズに合わせてデータのサブセットを公開することもできます。
論理スタンバイ 。 PGDクラスター内の別のノードから複製されたデータを受信しますが、レプリケーションメッシュまたはコンセンサスには参加しません。これらには、他のPGDデータノードと同じデータがすべて含まれており、データノードの1つがクラスターをフルキャパシティー/コンセンサスに戻せない場合、すぐにマスターに昇格できます。データセンター間のネットワークトラフィックが懸念される環境で使用できます。それ以外の場合、場所ごとに3つのPGDデータノードが常に優先されます。
