High Availability & Scalability Guide 4.2

EnterpriseDB

High Availability & Scalability Guide

高可用性と読み取りスケーラビリティはEDB Postgres Advanced Serverのコア機能セットのパートではないため、 Advanced Serverはこの機能を提供する外部ツールに依存しています。このドキュメントでは、 EDB Failover ManagerとPgpool-IIが提供する機能に焦点を当て、これらのツールを中心に形成された高可用性アーキテクチャの意味について説明します。

序文アーキテクチャcomponents_ha_pgpool appendix_a appendix_b結論

</ div>

Architecture Overview

このガイドでは、Failover ManagerとPgpoolを構成してAdvanced Serverに提供する利点を最大限に活用する方法を説明します。アーキテクチャのセクションで説明したリファレンス・アーキテクチャを使用すると、（フェイルオーバーマネージャーとの）自動フェイルオーバーメカニズムを実装することにより、高可用性を実現する方法を学ぶことができます大規模なワークロードのためのシステムおよび読み取り中心または混在ワークロードとの同時クライアント数の増加をスケーリングしながら、 （Pgpoolを使用して）水平スケーリング/読み取りスケーリングを実現します。

このドキュメントで説明されているアーキテクチャは、EFM 4.2、 EDB pgPool 4.2、およびAdvanced Server 13向けに開発およびテストされています。

Advanced ServerおよびFailover Managerのドキュメントは、 EnterpriseDBから入手できます。

https://www.enterprisedb.com/docs/

pgPool-IIのドキュメントは次の場所にあります。

http://www.pgpool.net/docs/latest/en/html

フェイルオーバーマネージャーの概要

フェールオーバーマネージャーは、 Postgresストリーミングレプリケーションクラスターの状態を監視し、障害を迅速に検証する高可用性モジュールです。データベース障害が発生すると、フェールオーバーマネージャーはストリーミングレプリケーションスタンバイノードを書き込み可能なプライマリノードに自動的にプロモートさせ、継続的なパフォーマンスを保証し、最小限のサービス中断でデータロスを防ぎます。

基本的なEFMアーキテクチャの用語

フェールオーバーマネージャークラスターは、ネットワーク上の次のホストに存在するEFMプロセスで構成されます。

  • プライマリノードは、データベースクライアントにサービスを提供しているプライマリデータベースサーバです。
  • 1つ以上のスタンバイノードは、プライマリノードに関連付けられたストリーミングレプリケーションサーバーです。
  • ウィットネスノードは、フェイルオーバーシナリオでプライマリまたはスタンバイのアサーションを確認します。障害が発生したシチュエーションで、プライマリが半分以上のノードを持つパーティションで検出さ自分自身と、プライマリのままになります。そのため、EFMは、偶数のエージェントを含むクラスターでの実行をサポートしています。

Pgpool-IIの概要

Pgpool-II（Pgpool）は、EPASおよびコミュニティPostgresクラスターのマルチプルのスタンバイでのSELECTクエリの水平スケーラビリティのためのコネクションプーリングと負荷分散を提供するオープンソースアプリケーションです。すべてのバックエンドについて、backend_weightパラメータは、読み取りトラフィックの比率をバックエンドノードに向けるように設定できます。プライマリノードでの読み取りトラフィックを防ぐために、backend_weightパラメータを0に設定できます。そのような場合、データ変更言語（DML）クエリ（つまり、INSERT、UPDATE、DELETE）は、読み取り中にプライマリノードに送信されます。クエリはスタンバイに対して負荷分散されるため、読み取り集中型のワークロードが混在するスケーラビリティを提供します。

EnterpriseDBは、次のPgpool機能をサポートしています。

  • 負荷分散
  • 接続プーリング
  • 高可用性
  • 接続制限

PCPの概要

Pgpoolは、Pgpoolのステータスの取得やPgpoolプロセスのリモート終了などの管理操作を実行する管理者向けのPCPと呼ばれるインタフェースを提供します。 PCPコマンドは、ネットワーク経由でPgpoolを操作するUNIXコマンドです。

Pgpool Watchdog

watchdogは、高可用性機能を提供するPgpoolのオプショナルのサブプロセスです。 watchdogによって追加された機能は次のとおりです。

  • pgpoolサービスのヘルスチェック
  • 他のウォッチドッグプロセスの相互モニタリング
  • 特定の障害が検出された場合のリーダー/スタンバイ状態の変更
  • サーバーの切り替えに同期的した自動仮想IPアドレスの割り当て
  • リカバリ中のサーバーのスタンバイとしての自動登録

Pgpool watchdogコンポーネントの詳細については、次を参照してください。

http://www.pgpool.net/docs/latest/en/html/tutorial-watchdog.html

Architecture

A typical EFM and Pgpool configuration

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

Systems Components
Primary Pgpool/EFM witness node プライマリPgpoolノードは、PgpoolとEFM witnessのみを実行します。そのため、できるだけ多くのリソースをPgpoolで使用できます。通常の実行モード（Pgpoolフェイルオーバーなし）では、プライマリPgpoolノードが仮想IPアドレスを接続し、すべてのアプリケーションが仮想IPアドレスを介してPgpoolに接続します。 Pgpoolは、すべての書き込みトラフィックをプライマリデータベースノード、すべてのスタンバイノード間ですべての読み取りのバランスをとります。プライマリPgpoolノードでは、EFM監視プロセスにより、データベースノードの1つでも3つのEFMエージェントの最小クォータが利用可能になります。失敗します。いくつかの例は、メンテナンスまたは障害のためにノードがすでに使用不可であり、別の障害が発生した場合です。
Primary Database node プライマリデータベースノードは、 Postgres （プライマリ）とEFMのみを実行し、すべてのリソースをPostgresに残します。読み取り/書き込みトラフィック（つまり、INSERT、UPDATE、DELETE）は、プライマリPgpoolノードによってこのノードに転送されます。
Standby nodes スタンバイノードは、 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はできるだけ多くのリソースを利用できます。
  • 必要に応じて、同期レプリケーションイベントをセットアップして、障害発生時にほぼゼロのデータロスを実現できます。

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

Deployment of EFM and Pgpool on separate virtual machines

Implementing High Availability with Pgpool

フェールオーバーマネージャーは、 Postgresノードの状態を監視します。データベースに障害が発生しイベントに、フェイルオーバーマネージャーはスタンバイ・ノードへの自動フェイルオーバーを行います。 Pgpoolはバックエンドノードの状態をモニタせず、スタンバイノードへのフェイルオーバーを実行しないことに注意してください。

フェイルオーバーマネージャーの設定

フェールオーバーマネージャーは、障害が発生したデータベースノードをPgpool負荷分散から削除する機能を提供します。また、フェールオーバーマネージャークラスターに戻ったときにノードをPgpoolに再接続することもできます。 Pgpoolを使用してEFMを高可用性用に構成するには、クラスタープロパティファイルで次のプロパティを設定する必要があります。

pgpool.enable = true/false

pcp.user = User that would be invoking PCP commands

pcp.host = Virtual IP that would be used by pgpool. Same as pgpool parameter 'delegate_IP’

pcp.port = The port on which pgpool listens for pcp commands

pcp.pass.file = Absolute path of PCPPASSFILE

pgpool.bin = Absolute path of pgpool bin directory

Pgpoolの構成

このセクションでは、edg_tran_1ファイル内のいくつかの重要なパラメーターの構成をリストして、Pgpool-IIをEFMと統合します。

バックエンドノードの設定

3つのPostgreSQLバックエンドノード、1つのプライマリノードと2つのスタンバイノードがあります。 pgpool.confのbackend_*構成パラメーターを使用して構成し、すべてのノードに等しいバックエンドの重みを使用します。これmake、読み取りクエリがすべてのノードに均等に分散されます。

backend_hostname0 = ‘server1_IP'
backend_port0 = 5444
backend_weight0 = 1
backend_flag0 = 'DISALLOW_TO_FAILOVER'

backend_hostname1 = ‘server2_IP'
backend_port1 = 5444
backend_weight1 = 1
backend_flag1 = 'DISALLOW_TO_FAILOVER'

backend_hostname2 = ‘server3_IP'
backend_port2 = 5444
backend_weight2 = 1
backend_flag2 = 'DISALLOW_TO_FAILOVER'

負荷分散およびストリーミングレプリケーションモードを有効化

pgpool.confファイルで次の設定パラメータして、負荷分散とストリーミングレプリケーションモードを有効にしモード。

master_slave_mode = on
master_slave_sub_mode = 'stream'
load_balance_mode = on

ヘルスチェックとフェイルオーバーを無効にします

ヘルスチェックとフェイルオーバーはEFMで処理する必要があるため、Pgpool-II側でこれらを無効にする必要があります。 pgpool-II側でヘルスチェックとフェイルオーバーを無効にするには、次の値を割り当てます。

health_check_period = 0
fail_over_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などは（EFM用語では）共有プロパティであり、pgpool.confファイル内のすべてのノードに対して同じ値を保持する必要があります。
    • if  _ *  *の正しいインタフェース値を更新し、pgpool.confファイルのcmd propsをarpingします。
  • 各ノードのpgpool.confファイルのノード数に応じて、プロパティheartbeat_destination0、heartbeat_destination1、heartbeat_destination2などを追加します。ここで、heartbeat_destination0はローカルノードのip / hostnameである必要があります。

** PCPのセットアップ**

スクリプトはPCPインタフェースを使用するため、パスワードプロンプトなしでPCP接続を許可するには、PCPおよび.PCPPASSファイルを設定する必要があります。

セットアップPCP：http://www.pgpool.net/docs/latest/en/html/configuring-pcp-conf.html

PCPPASSのセットアップ：https://www.pgpool.net/docs/latest/en/html/pcp-commands.html

スタンバイノードに読み取りトラフィックを分散することで読み取りのスケーラビリティを保証に、負荷分散がオンになっていることに注意してください。

フェールオーバーマネージャーは、ヘルスチェックの実行とフェイルオーバーのトリガーを担当するため、ヘルスチェックとエラーによってトリガーされるバックエンドフェイルオーバーはオフになっています。この場合、Pgpoolがヘルスチェックを実行することはお勧めできません。これにより、Failover Managerとの競合が発生したり、早期にフェイルオーバーが実行されたりすることはありません。

最後に、search_primary_node_timeoutは、フェイルオーバーマネージャー・トリガ・フェイルオーバー時にはpgpoolサービスのプロンプトリカバリを確実にする保証に低い値に設定されています。

仮想IPアドレス

Pgpool-IIとFailover Managerの両方が、シームレスなフェイルオーバーのために仮想IPを使用する機能を提供します。両方ともこの機能を提供しますが、pgpool-IIリーダーは仮想IPを介してアプリケーション接続を受け取るプロセスです。このデザインのように、このような仮想IP管理はPgpool-IIウォッチドッグシステムによって実行されます。 EFM VIPはこのデザインには有益な効果がなく、無効にする必要があります。

Pgpoolのアクティブなインスタンス（サンプルアーキテクチャのプライマリPgpoolサーバー）の障害シチュエーションでは、次に使用可能なスタンバイPgpoolインスタンス（ウォッチドッグの優先順位に従って）がアクティブ化され、リーダーPgpoolインスタンスとして機能します。

Pgpool-II Watchdogの設定

Watchdogは、Pgpool-IIノードの高可用性を提供します。このセクションでは、各Pgpool-IIノードでウォッチドッグに必要な構成をリストします。

すべてのPgpoolノードでの一般的なウォッチドッグ構成

以下の構成パラメーターは、ウォッチドッグを有効にして構成します。インターバルとリトライの値は、要件とテスト結果に応じて調整できます。

use_watchdog = on # enable watchdog
wd_port = 9000 # watchdog port, can be changed
delegate_IP = ‘Virtual IP address’
wd_lifecheck_method = 'heartbeat'
wd_interval = 10 # we can lower this value for quick detection
wd_life_point = 3
#  virtual IP control
ifconfig_path = '/sbin' # ifconfig command path
if_up_cmd = 'ifconfig eth0:0 inet $_IP_$ netmask 255.255.255.0'
   *                                    # startup delegate IP command
if_down_cmd = 'ifconfig eth0:0 down' # shutdown delegate IP command
arping_path = '/usr/sbin'            # arping command path

Note * eth0の値をシステムのネットワークインタフェースに置き換えます。接続数のチューニング、およびプール構成については、Chapter 5を参照してください。

サーバー2のウォッチドッグ構成

other_pgpool_hostname0 = 'server 3 IP/hostname'
other_pgpool_port0 = 9999
other_wd_port0 = 9000
other_pgpool_hostname1 = 'server 4 IP/hostname'
other_pgpool_port1 = 9999
other_wd_port1 = 9000
wd_priority = 1

サーバー3のウォッチドッグ構成

other_pgpool_hostname0 = 'server 2 IP/hostname'
other_pgpool_port0 = 9999
other_wd_port0 = 9000
other_pgpool_hostname1 = 'server 4 IP/hostname'
other_pgpool_port1 = 9999
other_wd_port1 = 9000
wd_priority = 3

サーバー4のウォッチドッグ構成

other_pgpool_hostname0 = 'server 2 IP/hostname'
other_pgpool_port0 = 9999
other_wd_port0 = 9000
other_pgpool_hostname1 = 'server 3 IP/hostname'
other_pgpool_port1 = 9999
other_wd_port1 = 9000
wd_priority = 5 # use high watchdog priority on server 4

EFM Pgpool Integration Using Azure Network Load Balancer