Architecture

典型的なEFMおよびPgpool構成

サンプルのアーキテクチャー図には、次の表で説明する4つのノードが示されています。

Systems	Components
プライマリPgpool/EFM監視ノード	プライマリPgpoolノードは、PgpoolとEFMwitnessのみを実行します。そのため、Pgpoolで利用可能なリソースをできるだけ多く残します。通常の実行モード（Pgpoolフェイルオーバーなし）では、プライマリPgpoolノードが仮想IPアドレスを接続し、すべてのアプリケーションが仮想IPアドレスを介してPgpoolに接続します。Pgpoolはすべての書き込みトラフィックをプライマリデータベースノードに転送し、すべてのスタンバイノード間ですべての読み取りのバランスをとります。プライマリPgpoolノードでは、EFM監視プロセスにより、データベースノードの1つでも3つのEFMエージェントの最小クォータが利用可能になります。失敗します。いくつかの例は、メンテナンスまたは障害のためにノードがすでに使用不可であり、別の障害が発生した場合です。
プライマリデータベースノード	プライマリデータベースノードは、Postgres（プライマリ）とEFMのみを実行し、すべてのリソースをPostgresに残します。読み取り/書き込みトラフィック（つまり、INSERT、UPDATE、DELETE）は、プライマリPgpoolノードによってこのノードに転送されます。
スタンバイノード	スタンバイノードは、Postgres（スタンバイ）、EFM、および非アクティブなPgpoolプロセスを実行しています。プライマリデータベースに障害が発生した場合、EFMはこれらのスタンバイノードのいずれかでPostgresを昇格させ、読み書きトラフィックを処理します。プライマリPgpoolに障害が発生した場合、Pgpoolウォッチドッグは、VIPを接続するスタンバイノードの1つでPgpoolをアクティブにし、データベースノードへのアプリケーション接続の転送を処理します。二重障害状態（プライマリPgpoolノードとプライマリデータベースノードの両方に障害が発生している）では、これらのプライマリプロセスの両方が同じノードで終了する可能性があることに注意してください。

このアーキテクチャ:

• プライマリPostgresノードに障害が発生した場合に昇格できる2つのスタンバイを提供することにより、高可用性を実現します。

• ウォッチドッグ構成で少なくとも3つのPgpoolプロセスを提供することにより、高可用性を実現します。

• 負荷分散のための複数のスタンバイで読み取りスケーラビリティを向上させることにより、混合および読み取り集中型のワークロードでパフォーマンスが向上します。

• 読み取り専用トラフィックをプライマリpgpoolノードにリダイレクトすることにより、プライマリデータベースノードの負荷を軽減します。

• プライマリデータベースノード上のPgpoolとPostgres間のリソースの競合を防ぎます。プライマリデータベースノードでPgpoolを実行しないことにより、プライマリPostgresプロセスはできるだけ多くのリソースを利用できます。

• プライマリPgpoolノード上のpgpoolとPostgres間のリソースの競合を防ぎます。プライマリPgpoolノードでスタンバイデータベースを実行しないことにより、Pgpoolはできるだけ多くのリソースを利用できます。

• オプションで、同期イベントを設定して、障害発生時にほぼゼロのデータ損失を実現できます。

注釈

このアーキテクチャにより、Postgresを実行している3つの仮想マシンとPgpoolを実行している3つの仮想マシンを完全に分離することもできます。この種類のセットアップには2つの追加の仮想マシンが必要ですが、フェールオーバーシナリオでPgpoolとPostgresの間のリソースの競合を防ぎたい場合は、より良い選択です。このセットアップでは、EFMWitnessProcessを実行する追加の7番目のノードなしでアーキテクチャを実行できます。障害の解決を向上させるために、efmwitnessエージェントをPgpoolサーバーに展開できます。

個別の仮想マシンへのEFMとPgpoolの展開