Failover Manager with EDB Pgpool-II#
Pgpool-IIは、読み取り専用のトラフィックロードバランシング、接続プーリング、クラスター化プロキシとしての実行など、多くの機能を提供できる人気の接続プーラーです。可用性を管理するフェールオーバーマネージャーと、正しいプライマリにプロキシへのEDB Pgpool-IIを再構成すると、セットアップはオンプレミスのセットアップとクラウドセットアップで高可用性を提供できます。
オンプレミスのEDB Pgpool-IIを使用したフェールオーバーマネージャー#
オンプレミスセットアップの場合、VIPを使用してトラフィックを利用可能なEDB Pgpool-IIインスタンスにルーティングできます。この設定では、EDB Pgpool-IIの自動フェイルオーバーが無効になり、フェールオーバーマネージャーはEDB Pgpool-IIを管理するように構成されます。
Failover Manager with Pgpool on-premises#
クラウドでのEDB Pgpool-IIを使用したフェールオーバーマネージャー#
ネットワークロードバランサーのある環境クラウド環境などの場合、ネットワークロードバランサーNLBを使用して、VIPを必要とせずに使用可能なすべてのEDB Pgpool-IIインスタンスでトラフィックを分散できます。
Failover Manager with Pgpool in cloud#
EDB Pgpool-IIでのフェールオーバーマネージャーの使用#
インストール#
次のとおりに、 Advanced Serverデータベース、フェールオーバーマネージャー、およびEDB Pgpool-IIをインストールおよび構成します。
Systems |
Components |
|---|---|
PgDB server 1, server2, and server 3 |
Primary / standby node running Advanced Server and Failover Manager |
EDB Pgpool-II |
Pgpool node running EDB Pgpool-II 4.2 in a watchdog configuration. Register these three nodes as targets in the target group. Three is the minimum and is sufficient for most cases. |
EDBは、次の理由から、EDB Pgpool-IIと同じマシンで実行されているFailover Manager / PostgreSQLでのこのアーキテクチャをサポートしていません。
クラウドネットワークロードバランサーの制限は、ソースと宛先が同じマシンにある場合、トラフィックを適切にルーティングしません。
混合アーキテクチャでは、PgpoolとPostgres間のトラフィックがアンバランスになる場合があります。
PgpoolとPostgreSQLはリソースをめぐって競合する可能性があります。
フェールオーバーマネージャーの構成#
フェールオーバーマネージャーは、障害が発生したデータベースノードをEDB Pgpool-IIロードバランシングから削除できます。フェールオーバーマネージャークラスターに戻ったときに、ノードをEDB Pgpool-IIに再接続することもできます。 EDB Pgpool-IIを使用して高可用性を備えたフェールオーバーマネージャーを構成するには、クラスタープロパティファイルで次のプロパティを設定する必要があります。
pgpool.enable = true
pcp.user = User invoking PCP commands
pcp.host = Virtual IP of EDB Pgpool-II or IP of NLB
pcp.port = 9898
pcp.pass.file = Absolute path of PCPPASSFILE
pgpool.bin = Absolute path of pgpool bin directory
EDB Pgpool-IIの構成#
pgpool.conf ファイルでいくつかの重要なパラメーターを構成して、EDB
Pgpool-IIとFailover Managerを統合できます。
バックエンドノード設定#
3つのPostgreSQLバックエンドノードがあります。1つのプライマリノードと2つのスタンバイノード。
pgpool.conf
のbackend_*構成パラメーターを使用して構成し、すべてのノードに等しいバックエンドの重みを使用します。これにより、読み取りクエリがすべてのノードに等しく分散されます。
backend_hostname0 = server1_IP
backend_port0 = 5444
backend_weight0 = 1
backend_flag0 = ALLOW_TO_FAILOVER
backend_hostname1 = server2_IP
backend_port1 = 5444
backend_weight1 = 1
backend_flag1 = ALLOW_TO_FAILOVER
backend_hostname2 = server3_IP
backend_port2 = 5444
backend_weight2 = 1
backend_flag2 = ALLOW_TO_FAILOVER
ロードバランシングとストリーミングレプリケーションモードの有効化#
pgpool.conf
ファイルで次の構成パラメーターを設定して、ロードバランシングとストリーミングレプリケーションモードを有効にします。
EDB Pgpool-IIバージョン4.2の場合
backend_clustering_mode = streaming_replication
load_balance_mode = on
EDB Pgpool-IIバージョン4.2より前のバージョンの場合
master_slave_mode = on
master_slave_sub_mode = stream
load_balance_mode = on
ヘルスチェックとフェイルオーバーの無効化#
ヘルスチェックとフェイルオーバーはフェールオーバーマネージャーによって処理されるため、EDB Pgpool-II側でそれらを無効にします。 EDB Pgpool-II側でヘルスチェックとフェールオーバーを無効にするには、次の値を割り当てます。
health_check_period = 0
failover_on_backend_error = off
failover_if_affected_tuples_mismatch = off
failover_command =
failback_command =
pgpool.confファイルの値を設定するときに以下を確認します。
pgpool.confのwd_priorityの値をノードごとに異なるままにします。最も高い値を持つノードが最も高い優先順位を取得します。プロパティ
backend_hostname0、backend_hostname1、backend_hostname2などは共有プロパティフェールオーバーマネージャー用語であり、すべてのEDB Pgpool-IIノードのpgpool.confファイルに同じ値を保持する必要があります。pgpool.confファイルのif_ *およびarpingcmd小道具の正しいインターフェイス値を更新します。すべてのノードの
pgpool.confファイルに、ノードの数に応じて、プロパティheartbeat_destination0、heartbeat_destination1、heartbeat_destination2などを追加します。ここでは、heartbeat_destination0をローカルノードのIPアドレスまたはホスト名に設定します。
PCPのセットアップ#
スクリプトはPCPインターフェイスを使用するため、 PCPおよび.PCPPASS
ファイルを設定して、パスワードプロンプトなしでPCP接続を許可する必要があります。
PCPを設定するには、 Configuring pcp.conf を参照してください。
PCPPASSを設定するには、 PCP commands を参照してください。
ロードバランシングがオンになって、スタンバイノード全体に読み取りトラフィックを分散することにより、読み取りのスケーラビリティを保証します。
フェールオーバーマネージャーがヘルスチェックを実行し、フェールオーバーをトリガーするため、ヘルスチェックとエラートリガーのバックエンドフェールオーバーはオフになっています。この場合、フェールオーバーマネージャーとの競合、または時期尚早に実行されるフェールオーバーを回避するために、EDB Pgpool-IIを使用してヘルスチェックを実行することはお勧めしません。
最後に、 search_primary_node_timeout
は低い値に設定されて、フェールオーバーマネージャーがトリガーしたフェールオーバーが発生したときにEDB
Pgpool-IIサービスの迅速なリカバリーを保証します。
仮想IPアドレスの使用#
EDB Pgpool-IIとFailover Managerは、両方ともシームレスなフェイルオーバーのために仮想IPを使用する機能を提供します。どちらもこの機能を提供しますが、EDB Pgpool-IIリーダーは、仮想IPを介してアプリケーション接続を受信するプロセスです。このデザインと同様に、このような仮想IP管理は、EDB Pgpool-IIウォッチドッグシステムによって実行されます。 Failover Manager VIPはこのデザインでは役に立たないため、無効にします。
EDB Pgpool-IIのアクティブインスタンスサンプルアーキテクチャのプライマリEDB Pgpool-IIサーバーに障害が発生すると、次の利用可能なスタンバイEDB Pgpool-IIインスタンスウォッチドッグ優先度に従ってがアクティブ化され、リーダーとして担当しますEDB Pgpool-IIインスタンス。
ネットワークロードバランサーの構成#
AWSまたはAzureのネットワークロードバランサーを使用したフェールオーバーマネージャー/EDB Pgpool-II統合の場合、いくつかの追加手順を実行する必要があります。
EDB Pgpool-IIインスタンスが使用するセキュリティグループに次のルールを追加します。
EDB Pgpool-IIインスタンスSG Pgpoolが使用するセキュリティグループのルール。
タイプ |プロトコル | ポートレンジ | ソース | 説明 ————|—————|—————-|— ————-|——————- カスタムTCP | TCP | 9000 | サブネット全体 | ウォッチドッグカスタムTCP | TCP | 9694 | サブネット全体 | ハートビートカスタムTCP | TCP | 9898 | サブネット全体 | pcpカスタムTCP | TCP | 9999 | サブネット全体 | Pgpool
これらのルールに加えて、要件に応じてSSHとPingのルールを追加します。
データベースインスタンスSG DBが使用するセキュリティグループのルール
タイプ |プロトコル | ポートレンジ | ソース | 説明 ————|—————|—————-|— ————-|——————- カスタムTCP | TCP | 7800 |サブネット全体 |フェールオーバーマネージャーカスタムTCP | TCP | 5444 |サブネット全体|Postgres
これらのルールを設定すると、データベース、フェールオーバーマネージャー、およびEDB Pgpool-IIを実行するために必要なポートが、トラフィックルーティングとヘルスモニタリングのためのノードとロードバランサー間の通信のためにオープンされるようになります。
これらのルールに加えて、要件に応じてSSHとPingのルールを追加します。
AzureでのNLBの構成#
AWSを使用する場合、 AWSでのNLBの構成 を参照してください。
ネットワークロードバランサーの構成 で説明されているセキュリティグループルールを構成した後、Azureのドキュメントに従って、次のことを行います。
EDB Pgpool-IIインスタンスを実行しているすべての仮想マシンで構成されるバックエンドプールを作成します。仮想マシンのプライベートIPを使用して、バックエンドプールを作成します。
正常性プローブを追加して、EDB Pgpool-IIインスタンスが仮想マシンで利用できるかどうかを確認します。プロトコルを
TCPに、ポートを9999に設定します。2つのロードバランシングルールを追加します。ポート
9898およびポート9999に1つずつです。これらのルールにより、そのポートに着信するネットワークトラフィックが、バックエンドプールに存在するすべての仮想マシンに均等に分散されます。タイプをPublicロードバランサーまたはInternalロードバランサーに設定します。
これらの構成を完了すると、ポート9999でネットワークロードバランサーのIPアドレスでデータベースに接続できます。プライマリデータベースサーバーで障害が発生すると、フェールオーバーマネージャーは新しいプライマリをプロモートし、トラフィックを再分散するようにEDB
Pgpool-IIを再構成します。トラフィックを受け入れることができないEDB
Pgpool-IIプロセスがある場合、ネットワークロードバランサーはすべてのトラフィックを残りの2つのEDB
Pgpool-IIプロセスに再分散します。フェイルオーバーが発生した場合に備えて、接続数の増加を補償するようにlisten_backlog_multiplier
パラメーターが調整されていることを確認します。
AWSでのNLBの構成#
サンプル構成では、次の仮定が採用されています。
すべてのEC2インスタンスとロードバランサーは同じサブネットに展開されます。必要に応じて、データベースノードを別のサブネットに追加できますが、これにはより複雑な構成が必要で、パフォーマンスに影響を与える可能性があります。
EDB Pgpool-IIのセキュリティグループとデータベースインスタンスのセキュリティグループがあります。
ネットワークロードバランサーの構成 で説明しているセキュリティグループルールを構成した後、AWSドキュメントに従って、次のことを行います。
次の詳細を使用して2つのターゲットグループを作成します。
名前 |タイプ |プロトコル | ポート | VPC —————|————–|————– |—————-|—————————- ——————— pcp |インスタンス | TCP | 9898 | インスタンスが接続されているVPCを選択します。 pgpool |インスタンス | TCP | 9999 | インスタンスが接続されているVPCを選択します。残りの設定 ヘルスチェックTCP および Advanced health check 設定)はデフォルトのままにします。
作成したターゲットグループをPgBouncerを実行しているインスタンスに登録します。
次の詳細を使用してロードバランサーを作成します。
タイプ | VPC |リスナー | ————————————————– ———————|—————————-
——————-|—————————- ————————————————– ————————————————– —————————————|
Public またはInternal 。
EDBは、内部ロードバランサーを使用することをお勧めします。|
VPCを選択し、目的のゾーンにマッピングします。 | TCP を9898
に設定してリスナーを作成し、ターゲットグループpcpに転送します。 TCP
を9999
に設定して別のリスナーを作成し、ターゲットグループpgpoolに転送します。
構成が完了したら、ポート9999でネットワークロードバランサーのIPアドレスでデータベースに接続できます。プライマリデータベースサーバーで障害が発生すると、フェールオーバーマネージャーは新しいプライマリをプロモートし、EDB
Pgpool-IIを再構成してトラフィックを再分散します。トラフィックを受け入れることができないEDB
Pgpool-IIプロセスがある場合、ネットワークロードバランサーはすべてのトラフィックを残りの2つのEDB
Pgpool-IIプロセスに再分散します。フェイルオーバーが発生した場合に備えて、接続数の増加を補うようにlisten_backlog_multiplier
が調整されていることを確認します。