Choosing your architecture ========================== Always Onアーキテクチャは、EDBのTrusted Postgresアーキテクチャを反映しています。これらはプラクティスをカプセル化し、複数の構成で可能な限り最高のサービスの可用性を達成するのに役立ちます。これらの構成は、単一ロケーションのアーキテクチャから、ハードウェア障害やデータセンターの障害から保護する複雑な分散システムにまで及びます。このアーキテクチャは、 EDB Postgres Distributedのマルチマスター機能と、メンテナンス操作中でも99.999%の可用性を達成する機能を活用します。 ここで説明する例を超えたアーキテクチャにEDB Postgres分散を使用できます。ユースケース固有のバリエーションは、実稼働環境に正常に展開されました。ただし、これらのバリエーションは、最初に厳密なアーキテクチャレビューを受ける必要があります。また、 Always Onアーキテクチャ用のEDBの標準展開ツールは、運用環境でサポートされる前に、Trusted Postgres ArchitectTPAを有効にしてバリエーションをサポートする必要があります。 標準のEDB Always Onアーキテクチャ --------------------------------- EDBは、目標復旧ポイントRPOおよび目標復旧時間RTOの要件に応じて、さまざまなレベルの冗長性で単一またはマルチロケーションの展開をサポートするための標準化されたアーキテクチャを特定しました。 Always ONアーキテクチャは、基本的なビルディングブロックとして3つのデータベースノードグループを使用します。冗長性を高めるために5つのノードグループを使用することもできます。 EDB Postgres Distributedは、次の主要なビルディングブロックで構成されています。 - 双方向レプリケーションBDR—マルチマスターメッシュネットワークを作成するPostgres拡張機能 - PGDプロキシ—アプリケーションが適切なデータノードに接続されていることを確認する接続ルーター。 すべてのAlways Onアーキテクチャは、ますます多くの障害状況を保護します。たとえば、2つのデータノードを持つ単一のアクティブなロケーションは、ローカルハードウェア障害から保護しますが、ロケーションデータセンターまたはアベイラビリティーゾーンの障害からの保護は提供しません。別の場所にあるバックアップを使用してそのアーキテクチャを拡張することにより、場所が壊滅的に損失した場合に備えて、ある程度の保護が保証されます。ただし、最初にバックアップからデータベースを復元する必要があるため、RTO要件に違反する可能性があります。マルチマスターメッシュネットワークで接続された2番目のアクティブなロケーションを追加すると、ロケーションがオフラインになってもサービスは利用可能なままです。最後に、3番目の場所これは監視専用の場所にすることができますを追加すると、1つの場所がオフラインになった場合でもグローバルRaft機能が動作できます。グローバルRaftは、主に管理コマンドを実行するために必要です。また、 DDLやシーケンスの割り当てなどの一部の機能は、それなしでは動作しない場合がありますが、DMLレプリケーションは、グローバルRaftなしでも動作し続けます。 データは少なくとも1つのローカルマスターに同期してストリーミングできるため、各アーキテクチャはゼロRPOを提供でき、ローカルハードウェアに障害が発生した場合のデータ損失ゼロを保証します。 可用性保証を強化すると、ハードウェアとライセンス、ネットワーク要件、および操作の複雑性の追加コストが常に増加します。アーキテクチャを選択する前に、可用性とコンプライアンス要件を注意深く検討することが重要です。 アーキテクチャの詳細 -------------------- デフォルトでは、アプリケーショントランザクションはDMLのクラスター全体のコンセンサス選択、挿入、更新、および削除を必要としないため、レイテンシーが低下し、パフォーマンスが向上します。ただし、新しいグローバルシーケンスの生成や分散DDLの実行などの特定の操作の場合、 EDB Postgres Distributedは `Raft `_ ベースのコンセンサスモデルを使用して決定を行うための奇数のノードが必要です。したがって、より単純なアーキテクチャでも、すべてのノードがデータを保存しているわけではない場合でも、常に3つのノードがあります。 アプリケーションは、マルチホスト接続文字列を介して標準のAlways Onアーキテクチャに接続します。各PGDプロキシサーバーは、マルチホスト接続文字列の個別のエントリです。高可用性を保証には、各場所に常に少なくとも2つのプロキシノードが必要です。プロキシをデータベースインスタンスと同じ場所に配置できます。その場合、すべてのデータノードにプロキシを配置することをお勧めします。 他の接続メカニズムは実稼働環境に正常に展開されています。ただし、これらは標準のAlways Onアーキテクチャの一部ではありません。 Always On単一のロケーション ^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. figure:: /images/always_on_1x3_updated.png :alt: Always On 1 Location, 3 Nodes Diagram Always On 1 Location, 3 Nodes Diagram \*データノード1と3間の追加のレプリケーションは表示されていませんが、レプリケーションメッシュの一部として発生します *ローカル障害から迅速に復元するための冗長ハードウェア* 3つのPGDノード *3つのデータノードにすることができます推奨* 2つのデータノードとデータを保持しない1つの監視であることができます 図示されていません *各データノードのPGDプロキシアプリケーションへのアフィニティ* データノードとコロケーションできます推奨 *別のノードに配置できます* データノードの構成とインフラストラクチャの対称性により、再ルーティングされたときにアプリケーションのワークロードを処理するために適切なリソースが利用できるようになります。 *バックアップとリカバリーのBarman不図示* オフサイトはオプションですが推奨 \*マルチプルのPGDクラスターで共有できます *モニタリング用のPostgres Enterprise ManagerPEMは示されていません* マルチプルのPGDクラスターで共有できます Always Onマルチロケーション ^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. figure:: /images/always_on_2x3_aa_updated.png :alt: 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つの監視にすることができます不図示 *へのアフィニティを持つ各データノードのPGD-プロキシアプリケーション* データノードと同じ場所に配置できます推奨 *別のノードに配置できます* データノードと場所の構成とインフラストラクチャの対称性により、再ルーティングされたときにアプリケーションのワークロードを処理するために適切なリソースが利用できることが保証されます *バックアップとリカバリーのBarman図示されていません。* マルチプルのPGDクラスターで共有できます *モニタリングのためのPostgres Enterprise ManagerPEMは示されていません。* マルチプルのPGDクラスターで共有できます *オプションの監視ノードを3番目のリージョンに配置して、ロケーション障害の許容度を高める必要があります。* それ以外の場合、ロケーションに障害が発生すると、新しいノードや分散DDLの追加など、グローバルコンセンサスを必要とするアクションがブロックされます。 アーキテクチャの選択 -------------------- すべてのアーキテクチャは以下を提供します。 \*ハードウェア障害保護 - ゼロダウンタイムのアップグレード \*パブリック/プライベートクラウドでのアベイラビリティーゾーンのサポート これらの基準を使用して、適切なAlways Onアーキテクチャを選択します。 .. csv-table:: :header: "",Single  Data Location,Two  Data  Locations,Two  Data Locations  + Witness,Three or More Data Locations :widths: 8,8,8,8,8 :align: left :class: longtable 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データノードが常に優先されます。