High availability patterns for PEM deployment#
PEM展開の可用性を高くする必要がある場合は、高可用性HAトポロジでPEMバックエンドデータベースとフロントエンドWebアプリケーションの複数のインスタンスを展開できます。
一部の一般的な構成のインストール手順の詳細については、 Installing Postgres Enterprise Manager in HA Patterns を参照してください。
PEMバックエンドデータベースの複数のインスタンスの実行#
高可用性PEMバックエンドデータベースは、他の標準のHA Postgresクラスターと同様に機能します。バックエンドの主要な要件は次のとおりです。
プライマリ#
任意の時点で、PEMバックエンドデータベースの1つのインスタンスのみが書き込み接続を受け入れることができます。このインスタンスは、 プライマリPEMバックエンドデータベース 、または単に プライマリ と呼ばれます。
他のすべてのインスタンスは、プライマリのレプリカとして機能する必要があります。プライマリ障害が発生した場合にレプリカを昇格させるための信頼できる方法を実装する必要があります。これには通常、サポートされているフェールオーバーマネージャーの使用が含まれます。
PEMは、次のフェイルオーバーソリューションをサポートしています。
EDB フェールオーバーマネージャーEFM
パトローニ
注釈
EDB Postgres Distributedは、PEMバックエンドとしてサポートされていません。
接続はプライマリに移動する必要があります#
アクティブなPEM Webアプリケーションインスタンスと実行中のPEMエージェントからのすべての接続は、プライマリPEMバックエンドデータベースに接続する必要があります。
これを保証には2つの一般的なアプローチがあります。
常にプライマリにルーティングする C1:単一のエンドポイントとコロケーション を使用します。これは、仮想IPVIP、ネットワークロードバランサー、または現在のプライマリにトラフィックをルーティングするプロキシなどの方法を使用して実装できます。
プライマリが変更されたときにエンドポイントをスイッチするようにクライアントを構成します。これは一般的にマルチホスト接続文字列を使用して実行され、プライマリが到達不能な場合にクライアントは代替ホストに対して再試行できます。
詳細については、 ロードバランサー、プロキシ、およびVIP および リファレンスアーキテクチャ を参照してください。
複数のPEM Webアプリケーションインスタンスの実行#
前述のように、Webアプリケーションの複数のインスタンスを実行し、すべてプライマリPEMバックエンドに接続することにより、PEM Webアプリケーションの高可用性を実現できます。バックエンドとは異なり、複数のフロントエンドインスタンスは問題なく同時に実行できます。
すべてのインスタンスで一貫した動作を保証するには
ユーザー設定をローカルではなくPEMバックエンドデータベースに保存するようにすべてのインスタンスを構成します。
ダンプ/リストアなどのファイルを生成または保存する機能の場合、すべてのWebインスタンスにアクセスできる共有ファイルシステムを使用します。
HA PEM展開のアップグレード#
HA構成でPEMを実行する場合、明確に定義されテストされたアップグレード手順を行うことが重要です。これにより、ダウンタイムが最小限に抑えられ、アップグレードプロセス中にバックエンドデータベースとWebアプリケーションの両方の整合性が維持されます。 HA PEMをアップグレードする手順については、 Upgrading an HA PEM installation を参照してください。特定の環境でこれらの手順を検証します。
ロードバランサー、プロキシ、およびVIP#
リファレンスアーキテクチャ では、プロキシ/VIPという用語は、インバウンド接続の単一のエンドポイントを提示し、トラフィックを現在のプライマリにルーティングするコンポーネントを指します。これは、さまざまなツールとテクニックを使用して実装できます。ここで概要を説明します。
フェールオーバーマネージャーによって管理される仮想IPVIPを使用する#
仮想IPVIPは、特定の物理ネットワークインターフェイスに関連付けられないIPアドレスであり、サブネット内のノード間を移動できます。 VIPはOSネットワークスタックによって管理されるため、追加のハードウェアまたはサードパーティソフトウェアは必要ありません。
VIPを使用してトラフィックをプライマリにルーティングするには、フェールオーバー中にVIPを新しいプライマリに割り当てるようにフェールオーバーマネージャーを構成します。
EDB Failover ManagerEFMは、VIPをネイティブにサポートします。この方法を選択する場合、EFMの使用をお勧めします。
制限VIPは、マルチリージョンまたはマルチサブネットのクラウド環境には適していません。
ロードバランサーの使用#
ご使用の環境がロードバランサーたとえば、AWS Elastic Load Balancer、オンプレミスF5などをサポートしている場合、それらを使用してトラフィックを現在のプライマリにルーティングできます。一般的なパターンは2つあります。
フェールオーバー中にロードバランサーを再構成するフェールオーバーマネージャーを使用して、インバウンド接続を新しいプライマリにルーティングします。
ロードバランサーがHTTPエンドポイントを介して各ノードをポーリングし、現在のプライマリが判断するフェールオーバーマネージャーを使用します。プライマリのみが肯定的な応答たとえば、HTTPコード200、ロードバランサーが1つのポーリング間隔以内にすべてのトラフィックをプライマリにスイッチすることを意味します。これは、たとえば、Patroniの
/primaryまたは/read-writeエンドポイントを介して実現できます。
2番目のパターンは、ロードバランサーが動作するように設計されており、フェールオーバー中にロードバランサーの構成を変更するための管理アクセスを必要としないため、一般的に好まれます。
注釈
「ご使用の環境がロードバランサーを提供する場合」と言う理由は、このソリューションを適切に実装して、単一障害点になることを回避する必要があるためです。 ロードバランサーは可用性が高い必要があります。これには、通常、DNSフェールオーバー、Elastic IP、またはその他のインフラストラクチャレベルのソリューションを使用して、単一障害点になることを回避することが含まれます。
データベースの前にHAProxyまたはpgBouncerのスタンドアロンインスタンスを追加するだけでは十分ではありません。 EDBサポートは、カスタムロードバランサー設定の設計または管理を支援することはできません。ソリューションは、組織のインフラストラクチャまたは運用チームによって精査、サポート、および維持される必要があります。
PEM 10.1から、PEMエージェントとPEM Webアプリケーションの両方が、バックエンドデータベースに接続するためのマルチホスト接続文字列をサポートしています。マルチホスト接続文字列の場合 - クライアントPEMエージェントまたはWebアプリケーションは、書き込み接続を受け入れるまで、リストされた各ホストを試行します。 - フェールオーバー時に、接続がドロップされ、クライアントは再び検索を開始します。 - 文字列の最初のホストがプライマリでない場合、接続試行は失敗します。この障害により、プライマリへの接続を確立するまでにかかる時間が増加し、監視対象サーバーとPEMバックエンドサーバーでのリソースの使用量が増加します。
リファレンスアーキテクチャ#
以下のすべてのアーキテクチャは、PEMバックエンドデータベースを備えた3つのノードを示しています。ただし、フェールオーバーマネージャーが偶数のノード番号を使用できる場合、このアプローチは2つのノードのみで動作します。そうでない場合は、完全な3番目のノードの代わりに監視ノードを使用できます。 3つを超えるノードも正常に動作しますが、その構成は、ほとんどの展開で大きな利点が得られない場合があります。
C1:単一のエンドポイントとコロケーション#
PEM Webアプリケーションとバックエンドデータベースの両方が同じホストで実行される最小限のセットアップ。
長所
Webアプリケーションユーザーとモニタリングエージェントの両方の同じエンドポイントへの透過的な接続。
すべてのインスタンスがループバックインターフェイスに接続するため、Webアプリケーションの構成とアップグレードが簡素化されます。
小規模な展開に適しています。
短所
共有リソースがボトルネックになる可能性があります。
Webアプリケーションの障害に対する回復力がありません。フェールオーバー条件をカスタマイズしない限り、データベースに障害が発生するとフェールオーバーが発生します。
Webアプリケーションは書き込み不可のPostgresサーバーへの接続を拒否するため、レプリカで実行されているWebアプリケーションは使用できません。
reference arch#
S1 データベースの単一のエンドポイントで分離#
PEM Webアプリケーションとバックエンドデータベースの両方が別のホストで実行されるセットアップ。
長所
モニタリングエージェントは常に同じエンドポイントに接続するため、透過的な接続。
Webアプリケーションとデータベースコンポーネントは、独立してスケーラブルで冗長です。
大規模な展開に適しています。
短所
フロントエンドロードバランサーを使用しない限り、ユーザーはWebアプリケーションインスタンスを手動で選択する必要があります。
reference arch#
CM マルチホスト接続文字列とのコロケーション#
シングルエンドポイント設定は、マルチホスト接続文字列を使用するクライアントに置き換えられ、トラフィックがプライマリにルーティングされるようにします。 Webアプリケーションとバックエンドデータベースは同じ場所にあります。
長所
データベースサーバーのロードバランサーまたはVIPを管理する必要はありません。
冗長Webアプリケーション。
S1およびSMよりも小さいフットプリント。
短所
すべてのモニタリングエージェントとWebアプリケーションを、すべてのバックエンドデータベースの接続の詳細で構成する必要があるため、再構成が困難。
Webアプリケーションの複数のインスタンスを実行すると、混乱を招く場合があります。フロントエンドロードバランサーを使用しない限り、ユーザーはWebアプリケーションインスタンスを手動で選択する必要があります。
マルチホスト接続は、単一のエンドポイントを介したルーティングよりも効率が低くなります。
reference arch#
SM マルチホスト接続文字列で区切られる#
この設定では、単一のエンドポイントを削除しますが、Webアプリケーションとバックエンドデータベースを分離して、スケーラビリティを向上させます。
長所
データベースサーバーのロードバランサーまたはVIPを管理する必要はありません。
冗長Webアプリケーションとバックエンドデータベースコンポーネント。
スケーラビリティを向上させるための大規模な展開に適しています。
短所
すべてのモニタリングエージェントとWebアプリケーションを、すべてのバックエンドデータベースの接続の詳細で構成する必要があるため、再構成が困難。
Webアプリケーションの複数のインスタンスを実行すると、混乱を招く場合があります。フロントエンドロードバランサーを使用している場合を除き、ユーザーはWebアプリケーションインスタンスを手動で選択する必要があります。
マルチホスト接続は、単一のエンドポイントを介したルーティングよりも効率が低くなります
reference arch#