High Availability Patterns for PEM Deployment#
PEM展開の高可用性が必要な場合は、高可用性HAトポロジでPEMバックエンドデータベースとフロントエンドWebアプリケーションの複数のインスタンスを展開できます。このページでは、このようなトポロジの基本的な要件について詳しく説明します。
いくつかの一般的な構成の詳細なインストール手順は Installing Postgres Enterprise Manager in HA Patterns で見つけることができます。
PEMバックエンドデータベースの複数のインスタンスの実行#
高可用性PEMバックエンドデータベースは、他の標準のHA Postgresクラスターと同様に機能します。バックエンドの主要な要件は次のとおりです。
プライマリ#
任意の時点で、PEMバックエンドデータベースの1つのインスタンスのみが書き込み接続を受け入れる必要があります。このインスタンスは、primary PEM backend database
または単にprimary と呼ばれます。
他のすべてのインスタンスは、プライマリのレプリカとして機能する必要があります。プライマリ障害が発生した場合にレプリカを昇格させるための信頼できる方法を実装する必要があります。これには通常、サポートされているフェールオーバーマネージャーの使用が含まれます。
PEMは、次のフェイルオーバーソリューションをサポートしています。
EDB フェールオーバーマネージャーEFM
パトローニ
注釈
EDB Postgres Distributedは、PEMバックエンドとしてサポートされていません。
接続はプライマリに移動する必要があります#
アクティブなPEM Webアプリケーションインスタンスと実行中のPEMエージェントからのすべての接続は、プライマリPEMバックエンドデータベースに接続する必要があります。
これを保証には2つの一般的なアプローチがあります。
常にプライマリにルーティングする C1:単一のエンドポイントとコロケーション を使用します。これは、仮想IPVIP、ネットワークロードバランサー、トラフィックを現在のプライマリに自動的にルーティングするプロキシなど、さまざまな方法を使用して実装できます。
プライマリが変更されたときにエンドポイントをスイッチするようにクライアントを構成します。これは通常、[マルチホスト接続文字列]を使用して実行され、プライマリが到達不能な場合、クライアントは代替ホストに対して再試行できます。
詳細については、 ロードバランサー、プロキシ、VIP および リファレンスアーキテクチャ を参照してください。
複数のPEM Webアプリケーションインスタンスの実行#
PEM Webアプリケーションの高可用性は、Webアプリケーションの複数のインスタンスを実行することにより実現されます。前述のように、すべてはプライマリPEMバックエンドに接続されます。バックエンドとは異なり、複数のフロントエンドインスタンスは問題なく同時に実行できます。
すべてのインスタンスで一貫性を保証するには
ユーザー設定をローカルではなくPEMバックエンドデータベースに保存するようにすべてのインスタンスを構成します。
ファイルを生成または保存する機能の場合 例ダンプ/リストア、すべてのWebインスタンスにアクセスできる共有ファイルシステムを使用します。
HA PEM展開のアップグレード#
高可用性HA構成でPEMを実行する場合、明確に定義されテストされたアップグレード手順を使用することが重要です。これにより、ダウンタイムが最小限に抑えられ、アップグレードプロセス中にバックエンドデータベースとWebアプリケーションの両方の整合性が維持されます。
ロードバランサー、プロキシ、VIP#
以下のリファレンスアーキテクチャでは、インバウンド接続の単一のエンドポイントを提示し、トラフィックを現在のプライマリにルーティングするコンポーネントを参照するために「プロキシ/VIP」という用語を使用しています。これは、さまざまなツールとテクニックを使用して実装できます。以下にその概要を示します。
フェールオーバーマネージャーによって管理される仮想IPVIPを使用する#
仮想IPVIPは、特定の物理ネットワークインターフェイスに関連付けられないIPアドレスであり、サブネット内のノード間を移動できます。 VIPはOSネットワークスタックによって管理されるため、追加のハードウェアまたはサードパーティソフトウェアは必要ありません。
VIPを使用してトラフィックをプライマリにルーティングするには、フェールオーバー中にVIPを新しいプライマリに割り当てるようにフェールオーバーマネージャーを構成します。
EDB Failover ManagerEFMは、VIPをネイティブにサポートしており、この方法を選択する場合にお勧めします。
制限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#