Choosing your architecture¶
Always Onアーキテクチャは、プラクティスをカプセル化し、マルチプルの構成で可能な限り最高のサービス可用性を達成するのに役立つEDBのTrusted Postgresアーキテクチャを反映しています。これらの構成は、単一ロケーションのアーキテクチャから、ハードウェアの障害やデータセンターの障害から保護する複雑な分散システムにまで及びます。このアーキテクチャは、 EDB Postgres Distributedのマルチマスター機能と、メンテナンス操作中でも99.999％の可用性を実現する機能を活用しています。
ここで説明されている例以外のアーキテクチャにもEDB Postgres Distributedを使用できます。ユースケース固有のバリエーションが本番環境に正常にデプロイされました。ただし、これらのバリエーションは、最初に厳密なアーキテクチャレビューを受ける必要があります。また、 Always Onアーキテクチャ用のEDBの標準デプロイツールであるTPAExecを有効にして、バリエーションを実稼働環境でサポートする必要があります。
標準のEDB Always Onアーキテクチャ¶
EDBは、4つの標準Always Onアーキテクチャを特定しました。
：2つのデータノード、監視ノード、およびローカルバックアップがある単一の場所
：3つのデータノードを持つ単一の場所とオフサイトバックアップを持つ2番目の場所
：それぞれ2つのデータノードを持つ2つの場所とwitnessを持つ3番目の場所
：それぞれ3つのデータノードを持つ2つの場所（2つのマスターとホットスタンバイモードの追加の冗長ハードウェア）
各アーキテクチャは、データを少なくとも1つのローカルマスターに同期してストリーミングできるため、ゼロ復旧ポイント（RPO）を提供できるため、ローカルハードウェアに障害が発生した場合のデータ損失がゼロになります。ただし、いずれかのデータノードに障害が発生するとRPOが延長されるため、Bronzeアーキテクチャでは同期レプリケーションはお勧めしません。
可用性の保証を高めると、ハードウェアとライセンス、ネットワーク要件、および運用の複雑さに関する追加のコストが発生します。アーキテクチャを選択する前に、可用性とコンプライアンスの要件を注意深く検討してください。
アーキテクチャの詳細¶
EDB Postgres Distributedは、 show-raft ベースのコンセンサスアーキテクチャを使用します。通常のデータベース操作（挿入、選択、削除）にはクラスター全体のコンセンサスは必要ありませんが、 EDB Postgres Distributedは、新しいグローバルシーケンスの生成や分散DDL操作など、コンセンサスを必要とする決定を行う際に奇数のノードの恩恵を受けます。より単純なアーキテクチャでも、すべてがデータを保存しているわけではない場合でも、1つの場所内に常に3つのノードがあります。 2つのロケーションを使用するAlways On GoldとPlatinumでは、RAFT要件をサポートするための監視ノードとして5番目のノードが導入されています。
アプリケーションは、マルチホスト接続文字列を介して標準のAlways Onアーキテクチャに接続します。各HARPプロキシサーバーは、マルチホスト接続文字列内の個別のエントリです。他の接続メカニズムは運用環境に正常にデプロイされていますが、標準のAlways Onアーキテクチャの一部ではありません。
アーキテクチャの選択¶
すべてのアーキテクチャは以下を提供します。
ハードウェア障害保護
*ゼロダウンタイムのアップグレード
パブリック/プライベートクラウドでのアベイラビリティーゾーンのサポート
これらの基準を使用して、適切なAlways Onアーキテクチャを選択します。
Bronze |
Silver |
Gold |
Platinum |
|
|---|---|---|---|---|
Minimum Locations Needed |
1 |
2 |
3 |
2 |
Location failure protection |
No - unless offsite backup |
Yes - Recovery from backup |
Yes - instant failover to fully functional site |
Yes - instant failover to fully functional site |
Failover to DR or full DC |
NA (DR only if offsite backup) |
DR using offsite backup |
Full DC |
Full DC |
Fast local restoration of high availability after device failure |
No; time to restore HA: (1) VM prov + (2) approx 60 min/500GB |
Yes; three local data nodes allow to maintain HA after device failure |
No; time to restore HA: (1) VM prov + (2) approx 60 min/500GB |
Yes; logical standbys can quickly be promoted to master data nodes |
Cross location network traffic |
None (unless offsite backup then backup traffic only) |
Backup traffic only |
Full replication traffic |
Full replication traffic |
License cost |
2 data nodes |
3 data nodes |
4 data nodes |
4 data nodes <br/>2 logical standbys |
