Architecture#

KubernetesでEDB Postgres分散を展開するときは、これらの主なアーキテクチャの側面を考慮してください。

EDB CloudNativePGグローバルクラスターは Kubernetes operator

プライベート、パブリック、ハイブリッド、またはマルチクラウド環境で実行されるEDB Postgres分散クラスターを展開および管理するように設計されています。

EDB Postgres Distributedとの関係#

は、高いパフォーマンスと可用性を実現するように設計されたPostgresのマルチマスター実装です。 PGDは通常、 Trusted Postgres Architect (TPA) を使用した展開が必要です。このツールは、 Ansible を使用してPGDクラスターをプロビジョニングおよび展開するツールです。

EDB CloudNativePG Global Clusterは、コンテナとKubernetesを活用して、PGDクラスターを展開する別の方法を提供します。利点は、結果のアーキテクチャが次のことです。

自己修復性と堅牢性があります。
宣言的構成を介して管理されます。
広大で成長を続けるKubernetesエコシステムを利用します。

EDB CloudNativePGクラスターとの関係#

PGDクラスターは、1つ以上の_PGDグループ_で構成され、それぞれが1つ以上の_PGDノード_があります。 PGDノードはPostgresデータベースです。 EDB CloudNativePGグローバルクラスターは、KubernetesのEDB Postgresで定義されたCluster リソース、特に単一のインスタンスつまりレプリカなしのクラスターを使用して各PGDノードを内部管理します。

.spec.cnp の各Cluster によって作成された単一のPostgreSQLインスタンスを構成できます。

PGDグループ仕様の

EDB CloudNativePGグローバルクラスターでは、 EDB CloudNativePGクラスターと同様に、基になるデータベース実装がデータレプリケーションを担当します。ただし、フェイルオーバーとスイッチオーバーの動作が異なり、Raft選挙と新しい書き込みリーダーの指名が必要になることに注意することが重要です。 EDB CloudNativePGクラスターは、データノードの展開と修復のみを処理します。

EDB CloudNativePGグローバルクラスターを使用したPGDの管理#

EDB CloudNativePG Global Clusterオペレーターは、PGDクラスターの完全なライフサイクルを管理できます。そのため、 PGDノード単一インスタンスClusters として表されるに加えて、PGDに関連付けられている他のオブジェクトを管理する必要があります。

PGDは、分散コンセンサスのためのRaftアルゴリズムに依存して、ノードのメタデータ、特に_write leader_に関する契約を管理します。データノード間のコンセンサスは、新しいグローバルシーケンスの生成や分散DDLの実行などの操作にも必要です。

これらの考慮事項により、データベースノードの上のPGDに追加のアクターが強制されます。

EDB CloudNativePGグローバルクラスターは以下を管理します。

データノード。ノードはデータベースであり、EDB CloudNativePGクラスターによって管理され、単一のインスタンスでCluster を作成します。
Witness nodes

は、データレプリケーションに参加しない基本的なデータベースインスタンスです。彼らの機能は、偶数のデータノードを持つグループ、またはネットワーク分割後のコンセンサスが可能であることを保証することです。 Witnessノードは、単一インスタンスのCluster リソースを使用して管理されます。

PGD proxies

書き込みリーダーの情報を使用してPostgresプロキシとして機能します。 PGDプロキシは、書き込みを現在の書き込みリーダーにルーティングするためにRaftからの情報を必要とします。

プロキシとルーティング#

PGDグループは、 PGDノードのフルメッシュ接続を想定しています。各ノードは、適切な接続文字列libpq スタイルのDSNを使用して他のすべてのノードに接続できる必要があります。書き込み操作はすべてのノードに送信される必要はありません。 PGDは、1つのノードにコミットされた後、データの複製を担当します。

パフォーマンスを向上させるために、書き込み操作のほとんどを単一のノード_write leader_に送信することをお勧めします。 Raftは、どのノードが書き込みリーダーであるかを識別し、PGDノードに関するメタデータを保持するために使用されます。 PGDプロキシは、書き込みを書き込みリーダーに透過的にルーティングし、スイッチオーバーまたはフェイルオーバーが発生した場合に新しい書き込みリーダーにすばやくピボットするために使用されます。

_Raft subgroups_を構成することが可能であり、それぞれが別個の書き込みリーダーを維持できます。 EDB CloudNativePGグローバルクラスターでは、 PGDプロキシを含むPGDグループはRaftサブグループを構成します。

PGDプロキシでは2種類のルーティングが使用できます。

グローバルルーティングは、トップレベルのRaftグループを使用し、1つのグローバル書き込みリーダーを維持します。
ローカルルーティングは、サブグループを使用して個別の書き込みリーダーを維持します。ローカルルーティングは、書き込みの地理的な分離を実現するために使用されることがよくあります。

EDB CloudNativePGグローバルクラスターでは、デフォルトでローカルルーティングが使用され、グローバルルーティングを選択する構成オプションを使用できます。

Raftを使用したルーティングの詳細については、PGDドキュメントの Proxies, Raft, and Raft subgroups を参照してください。

PGDアーキテクチャと高可用性#

EDBは、 PGDの分散マルチマスター機能を有効に活用し、高可用性を提供するために、いくつかの推奨アーキテクチャを提案しています。

Always Onアーキテクチャは、1つの場所にある1つのグループ、または2つの別の場所にある2つのグループから構築されます。詳細については、PGDドキュメントの Choosing your architecture を参照してください。

KubernetesでのPGDの展開#

EDB CloudNativePG Global Clusterは、Kubernetesを活用してPGDクラスターを展開および管理します。そのため、 PGDをKubernetesエコシステムに変換するには、いくつかの適応が必要です。

イメージとオペランド#

3つのPostgresディストリビューションのいずれかを実行するようにPGDを構成できます。 PGD documentation を参照してください

各ディストリビューションの特徴を理解するため。

Kubernetesで機能するには、Postgresディストリビューションごとにコンテナが提供されます。これらは_operands_です。さらに、オペレーターイメージはこれらと同じリポジトリに保持されます。

EDB's private container registries を参照

画像へのアクセスの詳細については、

Kubernetesアーキテクチャ#

PG4K document on Kubernetes architecture のポイントの一部

はここに再現されています。詳細については、 PG4Kドキュメントを参照してください。

Kubernetesは、別の物理的な場所にまたがる可能性をネイティブに提供します。これらの物理的な場所は、データセンター、障害ゾーン、またはより多くの場合、_アベイラビリティーゾーン_としても知られます。これらは、冗長、低遅延、プライベートネットワーク接続を介して相互に接続されます。

分散システムであるため、_Kubernetesクラスター_の推奨される最小数は3です。この最小値により、コントロールプレーンは単一ゾーンの障害に対する回復力があります。これは、各データセンターがいつでもアクティブで、ワークロードを同時に実行できることを意味します。

EDB CloudNativePGグローバルクラスターは単一のKubernetesクラスターにインストールできます

または複数のKubernetesクラスター全体にわたって。

単一のKubernetesクラスター#

マルチアベイラビリティーゾーンのKubernetesアーキテクチャは、クラウドプロバイダーが管理するKubernetesサービスの一般的なものです。このようなアーキテクチャにより、EDB CloudNativePGグローバルクラスターとEDB CloudNativePGクラスターオペレーターは、すべてのゾーンがアクティブであることを考慮して、アベイラビリティーゾーンにわたってワークロードとノードをスケジュールできます。

Kubernetes cluster spanning over 3 independent data centers#

PGDクラスターは、単一のKubernetesクラスターに展開でき、Kubernetes可用性ゾーンを利用して、 Always On推奨アーキテクチャを含む高可用性アーキテクチャを有効にすることができます。

PGDドキュメントの Choosing your architecture に示されている_Always On Single Location_アーキテクチャは、3つのアベイラビリティーゾーンを持つ単一のKubernetesクラスターで実現できます。

EDB CloudNativePGグローバルクラスターオペレーターは、EDB CloudNativePG クラスターの場合と同様に、アフィニティ、トレランス、およびノードセレクターを使用して、ポッドのスケジュールつまり、どのポッドがどのデータセンターに移動するかを制御できます。個々のスケジューリング制御は、ノードだけでなくプロキシでも利用できます。

詳細については、EDB CloudNativePGクラスタードキュメントの Kubernetes documentation on scheduling および Scheduling を参照してください。

複数のKubernetesクラスター#

PGDクラスターは、相互に確実に通信できる複数のKubernetesクラスターに展開することもできます。

Always On multi-location PGD architectures

接続要件を満たす複数のKubernetesクラスターで実現できます。

詳細については、 Connectivity を参照してください。

Architecture

目次