Choosing your architecture¶
Always On アーキテクチャは EDB の推奨されるプラクティスを反映しており、マルチプルの構成で可能な限り最高のサービス可用性を達成するのに役立ちます。これらの構成は、単一ロケーションのアーキテクチャから、ハードウェアの障害やデータセンターの障害から保護する複雑な分散システムにまで及びます。このアーキテクチャは、 EDB Postgres Distributedのマルチマスター機能と、メンテナンス操作中でも99.999％の可用性を実現する機能を活用しています。
ここで説明されている例以外のアーキテクチャにもEDB Postgres Distributedを使用できます。ユースケース固有のバリエーションが本番環境に正常にデプロイされました。ただし、これらのバリエーションは、最初に厳密なアーキテクチャレビューを受ける必要があります。また、AlwaysOnアーキテクチャ用のEDBの標準展開ツールであるTPAExecを有効にして、バリエーションを実稼働環境でサポートする必要があります。
標準のEDB Always Onアーキテクチャ¶
EDBは、4つの標準Always Onアーキテクチャを特定しました。
：単一のアクティブな場所（データセンターまたはアベイラビリティーゾーン[AZ]）
：フェールオーバー機能を迅速に復元するための冗長ハードウェアを備えた単一のアクティブな場所とディザスターリカバリー（DR）場所
ホットスタンバイモードの追加の冗長ハードウェアを備えた2つのアクティブロケーション
すべての Always On アーキテクチャは、段階的に堅牢な障害状況を保護します。たとえば、 Always On Bronze はローカルのハードウェア障害から保護しますが、場所 (データセンターまたは AZ) の障害からの保護は提供しません。 Always On Silverは、バックアップが別の場所に保持されるため、場所の壊滅的な損失が発生した場合にある程度の保護を提供します。ただし、データベースを最初にバックアップから復元する必要があるため、目標復旧時間 (RTO) 要件に違反する可能性があります。 Always On Goldは、マルチマスターメッシュネットワークで接続された2つのアクティブなロケーションを提供するため、ロケーションがオフラインになった場合でもサービスを利用できます。最後に、Always On Platinum は両方の場所に冗長なホットスタンバイハードウェアを追加して、ハードウェアに障害が発生した場合にローカルの高可用性を維持します。
各アーキテクチャは、データを少なくとも1つのローカルマスターに同期してストリーミングできるため、ゼロ目標復旧ポイント（RPO）を提供できるため、ローカルハードウェアに障害が発生した場合のデータ損失ゼロが保証されます。
可用性の保証を高めると、ハードウェアとライセンス、ネットワーク要件、および運用の複雑さの追加コストが発生します。アーキテクチャを選択する前に、可用性とコンプライアンスの要件を注意深く検討してください。
アーキテクチャの詳細¶
EDB Postgres Distributedは、 ラフトコンセンサスのモニタリング ベースのコンセンサスアーキテクチャを使用します。通常のデータベース操作（挿入、選択、削除）にはクラスター全体のコンセンサスは必要ありませんが、 EDB Postgres Distributedは、新しいグローバルシーケンスの生成や分散DDL操作など、コンセンサスを必要とする決定を行う際に奇数のBDRノードの恩恵を受けます。より単純なアーキテクチャでも、すべてがデータを保存しているわけではない場合でも、常に3つのBDRノードがあります。 2つのアクティブな場所を使用するAlways On GoldとPlatinumでは、RAFT要件をサポートする監視ノードとして5番目のBDRノードを導入します。
アプリケーションは、マルチホスト接続文字列を介して標準の AlwaysOnアーキテクチャに接続します。ここで、各HAプロキシサーバーはマルチホスト接続文字列の個別のエントリです。他の接続メカニズムは運用環境に正常にデプロイされていますが、標準の Always On アーキテクチャの一部ではありません。
アーキテクチャの選択¶
すべてのアーキテクチャは以下を提供します。
ハードウェア障害保護
*ゼロダウンタイムのアップグレード
パブリック/プライベートクラウドでのアベイラビリティーゾーンのサポート
これらの基準を使用して、適切な Always On アーキテクチャを選択します。
Bronze |
Silver |
Gold |
Platinum |
|
|---|---|---|---|---|
Location failure protection |
No (unless Barman is moved offsite) |
Yes - Recovery from backup |
Yes - instant failover to fully functional site |
Yes - instant failover to fully functional site |
Failover to DR or full DC |
DR (if Barman is located offsite); NA otherwise |
DR (if Barman is located offsite) |
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 data center network traffic |
Backup traffic only (if Barman is located offsite); none otherwise |
Backup traffic only (if Barman is located offsite); none otherwise |
Full replication traffic |
Full replication traffic |
License cost |
2 data nodes |
3 data nodes |
4 data nodes |
4 data nodes <br/>2 logical standbys |
