EDB Postgres HA 構築のベストプラクティス（EDB技術本部長高鶴勝治）

EPASにおけるHA構成パターン

EDB Postgres Advanced Server（EPAS）では、下記の５つのHA（高可用性）構成パターンが可能です。

① Pgpool-II による Master – Slave 構成
② EFM による Master – Slave 構成
③ Pgpool-II & EFM による Master – Slave 構成
④ EDB Replication Server による　Active –Active 構成
⑤ クラスタ・ソフトによる Active – Passive 構成

EDBは、EDB Postgres on Kubernetes やCDSを提供していますが、これらは、全て、Master-slave 構成となります。EDBでは、Master-slave 構成が、EDB Postgres に適したHA構成と考えております。

pgpool-II について

EDBは、pgpool-IIもサポートしており、EPASインストール時、pgpool-IIもインストールされます。
但し、サポートされる機能は以下の通りです。

ロード・バランシング
コネクション・プーリング
Pgpool-II自体の可用性のための使用、WatchdogプロセスとMaster-Slaveモード

pgpool-IIの「レプリケーション機能」と「パラレル・クエリ機能」はサポート対象外です。

EDBが推奨するHA構成のベストプラクティス

EDBが推奨するHA構成のベストプラクティスは、下記のとおりです。

EPASにおけるHA構成パターン②とパターン③に対応します。どちらの構成も、データベースの可用性確保は、EFMによって行われます。

スケール・アウトや大規模コネクションに対応する必要がある場合は、pgppolの導入した、パターン③の構成となります。

HA構成ベストプラクティスのレベル分け

HA構成のベストプラクティスは、バックアップ、ローカルサイトの可用性レベル、DR（ディザスタリカバリ）有無の要件によって、ブロンズ、シルバー、ゴールド、プラチナの4つのレベルに分類できます。

バックアップは、データ保全という観点から、どのようなケースでも必要と考えています。ローカルサイトの可用性レベルは、サーバ障害許容台数をどの程度考えるかという点がポイントとなります。

次に、それぞれのレベルについて、解説いたします。

ブロンズ

ブロンズはバックアップのみのHA構成で、最低限の可用性を担保します。

データベースサーバの高可用性は、EDB製品等は使用せずにvSphereHAなどで対応
２世代以上の保持ポリシーで、BARTを用いたデータベースのバックアップを、定期的に取得
データベース部分の障害が発生した場合は、バッアップを用いてリカバリ cz-lekarna.com
リストア中は、サービスを停止する必要がある

ブロンズ構成では、データ保全性の観点から、バックアップのみを行いますが、データベース・レイヤでの可用性確保のための構成はとっていません。

サーバ障害には、VM機能、例えば、vSphereHAなどで対応される、といった場合に、とられる構成と考えます。言い換えれば、ベアメタル環境では、あまり採用されない構成とも言えます。

データベース・サーバとは、別にBARTサーバを設けますが、これは全ての構成に共通です。データ保全という観点から、どのようなケースでもバックアップが必要となるからです。

シルバー

シルバー構成は、マスタ・スレーブ構成による、データベース・レイヤで、可用性を確保した構成です。DRは考慮されていません。

マスター・スレーブ型アーキテクチャ
１台のDB障害に対して、サービス継続が可能
Pgpool-ll との併用により、以下が可能
- コネクション・プーリングによる大規模コネクション対応
- ロード・バランシング機能によるREAD型のスケール・アウト対応
コネクション・プーリングによる大規模コネクション対応
バック・アップをスレーブから取得することで、マスター側の負荷を軽減
パターン１
- 非同期レプリケーションによる２ノード構成
- マスターが障害の場合、スレーブ(非同期)が昇格
- データ・ロスの可能性はあるが、レプリケーションによるマスター側のオーバヘッドは軽微
パターン２
- 同期レプリケーションによる３ノード構成
- マスターが障害の場合、スレーブ(同期)が昇格
- データ・ロスはないが、レプリケーションによるマスタ側のオーバヘッドを考慮する必要がある

１台までのサーバ障害に対して、サービス継続が可能です。

パターン１は、非同期レプリケーションで、この要件を満たすには、２台のサーバで可能です。マスターが障害時は、スレーブが昇格、スレーブダウン時は、マスターは影響を受けずサービス継続が可能です。

パターン２は、同期レプリケーションで、この要件を満たすには、３台のサーバで可能となります。マスタ障害時は、同期スレーブが昇格、非同期スレーブが、同期スレーブに昇格します。同期スレーブがダウン時は、非同期スレーブが同期スレーブに昇格します。同期レプリケーションではオーバヘッドがある点に注意してください。

ゴールド

ゴールド構成は、２台までの、サーバ障害に対して、サービス継続が可能となる構成です。

マスター・スレーブ型アーキテクチャ
２台までのDB障害に対して、サービス継続が可能
Pgpool-ll との併用により、以下が可能
- ロード・バランシング機能によるREAD型のスケール・アウト対応
- コネクション・プーリングによる大規模コネクション対応
バック・アップをスレーブから取得することで、マスター側の負荷を軽減
パターン１
- 非同期レプリケーションによる３ノード構成
- マスターが障害の場合、スレーブ(非同期)が昇格
- データ・ロスの可能性はあるが、レプリケーションによるマスター側のオーバヘッドは軽微
パターン２
- 同期レプリケーションによる４ノード構成
- マスターが障害の場合、スレーブ(同期)が昇格
- データ・ロスはないが、レプリケーションによるマスタ側のオーバヘッドを考慮する必要がある