TR-4956:『Automated PostgreSQL High Availability Deployment and Disaster Recovery in AWS FSX/EC2』
ネットアップ、Niyaz Mohamed、Allen Cao氏
この解決策では、FSx ONTAPストレージ製品とAWSのNetApp Ansible自動化ツールキットに組み込まれたNetApp SnapMirrorテクノロジに基づくPostgreSQLデータベースの導入とHA / DRのセットアップ、フェイルオーバー、再同期の概要と詳細について説明します。
目的
PostgreSQLは、広く使用されているオープンソースデータベースで、で最も人気のあるデータベースエンジントップ10の4位にランクされてい"DB-Engines(DBエンジン)"ます。一方、PostgreSQLは、まだ高度な機能を持っている一方で、ライセンスフリーのオープンソースモデルから人気を得ています。一方、オープンソースのため、高可用性とディザスタリカバリ(HA/DR)分野では、本番環境レベルのデータベース導入に関する詳細なガイダンスが不足しており、特にパブリッククラウドでは不足しています。一般的に、ホットスタンバイやウォームスタンバイ、ストリーミングレプリケーションなどを使用した一般的なPostgreSQL HA/DRシステムのセットアップは困難です。スタンバイサイトを昇格させてからプライマリに戻すことで、HA / DR環境をテストすると、本番環境が停止する可能性があります。ストリーミングホットスタンバイに読み取りワークロードが導入されている場合、プライマリにはパフォーマンスの問題が詳しく文書化されています。
このドキュメントでは、アプリケーションレベルのPostgreSQLストリーミングHA / DR解決策 を使用して、ストレージレベルのレプリケーションを使用してAWS FSX ONTAP ストレージとEC2コンピューティングインスタンスに基づいてPostgreSQL HA / DR解決策 を構築する方法を説明します。解決策 は、シンプルで同等のシステムを構築し、従来のPostgreSQLアプリケーションレベルのHA/DRストリーミングレプリケーションと比較して同等の結果を提供します。
この解決策 は、実績のある成熟したネットアップのSnapMirrorストレージレベルのレプリケーションテクノロジを基盤としており、PostgreSQLのHA / DR用にAWSネイティブのFSX ONTAP クラウドストレージで利用できます。実装には、ネットアップのソリューションチームが提供する自動化ツールキットが必要同様の機能を提供すると同時に、アプリケーションレベルのストリーミングベースのHA / DR解決策 によって、プライマリサイトにおける複雑さやパフォーマンスの低下を解消します。解決策 は、アクティブなプライマリサイトに影響を与えることなく、簡単に導入してテストできます。
この解決策 は、次のユースケースに対応します。
-
パブリックAWSクラウドにPostgreSQL向けの本番グレードのHA/DRを導入します
-
パブリックAWSクラウドでのPostgreSQLワークロードのテストと検証
-
NetApp SnapMirrorレプリケーションテクノロジをベースにしたPostgreSQLのHA / DR戦略をテストし検証しています
対象読者
この解決策 は、次のユーザーを対象としています。
-
パブリックAWSクラウドにHA/DRでPostgreSQLを導入することに関心をお持ちのDBA。
-
パブリックAWSクラウドでのPostgreSQLワークロードのテストに関心をお持ちのデータベース解決策 アーキテクト。
-
AWS FSXストレージに導入されたPostgreSQLインスタンスの導入と管理に関心をお持ちのストレージ管理者。
-
AWS FSX/EC2でPostgreSQL環境の立ち上げに関心があるアプリケーション所有者。
解決策 のテストおよび検証環境
この解決策 のテストと検証は、最終的な導入環境と一致しないAWS FSXおよびEC2環境で実行しました。詳細については、を参照してください 導入にあたって考慮すべき主な要因。
アーキテクチャ
ハードウェアおよびソフトウェアコンポーネント
* ハードウェア * |
||
FSX ONTAP ストレージ |
現在のバージョン |
プライマリおよびスタンバイのHAクラスタと同じVPCおよびアベイラビリティゾーンに2つのFSX HAペア |
コンピューティングのEC2インスタンス |
t2.xlarge / 4vCPU / 16G |
2つのEC2 T2 xlargeをプライマリおよびスタンバイコンピューティングインスタンスとして使用できます |
Ansibleコントローラ |
オンプレミスCentOS VM / 4vCPU / 8G |
オンプレミスまたはクラウドでAnsible自動化コントローラをホストするVM |
ソフトウェア |
||
Red Hat Linux |
RHEL-8.6.0_HVM-20220503-x86_64-2- Hourly2-gp2の場合 |
テスト用にRedHatサブスクリプションを導入 |
CentOS Linuxの場合 |
CentOS Linuxリリース8.2.2004(コア) |
オンプレミスのラボに導入されたAnsibleコントローラをホストする |
PostgreSQL |
バージョン14.5 |
Automationは、PostgreSQLの.ora yum repoから最新バージョンのPostgreSQLを取得します |
Ansible |
バージョン2.10.3 |
要件Playbookがインストールされた必須のコレクションとライブラリの前提条件 |
導入にあたって考慮すべき主な要因
-
* PostgreSQLデータベースのバックアップ、リストア、リカバリ*PostgreSQLデータベースは、pg_dumpを使用した論理バックアップ、pg_basebackまたは下位レベルのOSバックアップコマンドを使用した物理オンラインバックアップ、ストレージレベルで整合性のあるSnapshotなど、さまざまなバックアップ方法をサポートしています。この解決策 は、PostgreSQLデータベースデータおよびスタンバイサイトでのWALボリュームのバックアップ、リストア、およびリカバリに、ネットアップの整合グループスナップショットを使用します。ネットアップの整合性グループボリュームのSnapshotは、ストレージに書き込まれる時点でのI/Oシーケンスを検証し、データベースデータファイルの整合性を保護します。
-
* EC2コンピューティングインスタンス*これらのテストと検証では、PostgreSQLデータベースコンピューティングインスタンスにAWS EC2 T2.xlargeインスタンスタイプを使用しました。データベースワークロード向けに最適化されているため、導入環境ではPostgreSQLのコンピューティングインスタンスとしてM5タイプEC2インスタンスを使用することを推奨します。スタンバイコンピューティングインスタンスは、FSX HAクラスタ用に展開されたパッシブ(スタンバイ)ファイルシステムと同じゾーンに常に配置する必要があります。
-
* FSxストレージHAクラスタのシングルゾーンまたはマルチゾーン導入*今回のテストと検証では、1つのAWSアベイラビリティゾーンにFSx HAクラスタを導入しました。本番環境では、FSX HAペアを2つの異なるアベイラビリティゾーンに導入することを推奨します。ビジネス継続性のためのディザスタリカバリスタンバイHAペアは、プライマリとスタンバイの間に特定の距離が必要な場合、別のリージョンに設定できます。FSX HAクラスタは、アクティブ/パッシブファイルシステムのペアで同期ミラーされるHAペアで、ストレージレベルの冗長性を提供するために割り当てられます。
-
* PostgreSQLのデータとログの配置*一般的なPostgreSQL環境では、データファイルとログファイル用に同じルートディレクトリまたはボリュームを共有します。テストと検証では、PostgreSQLのデータを分離し、パフォーマンスのために2つのボリュームにログを作成しました。データディレクトリ内のソフトリンクは、PostgreSQL WALログとアーカイブされたWALログをホストするログディレクトリまたはボリュームを指すために使用されます。
-
* PostgreSQLサービス起動遅延タイマー*このソリューションでは、NFSマウントボリュームを使用してPostgreSQLデータベースファイルとWALログファイルを格納します。データベース・ホストの再起動中に、ボリュームがマウントされていない状態でPostgreSQLサービスが起動を試みることがあります。その結果、データベースサービスの起動に失敗します。PostgreSQLデータベースを正しく起動するには、10~15秒のタイマー遅延が必要です。
-
*ビジネス継続性のためのRPO / RTO。*DR用のプライマリからスタンバイへのFSxデータレプリケーションは非同期に基づいています。つまり、RPOはSnapshotバックアップとSnapMirrorレプリケーションの頻度によって異なります。SnapshotコピーとSnapMirrorレプリケーションの頻度を高くすると、RPOが短縮されます。そのため、災害時のデータ損失と、ストレージコストの増加というバランスを取ることができます。これまでのところ、RPOではSnapshotコピーとSnapMirrorレプリケーションをわずか5分間隔で実装できると判断しており、一般にRTOでは、DRスタンバイサイトでPostgreSQLを1分以内にリカバリできます。
-
*データベースのバックアップ。*PostgreSQLデータベースをオンプレミスのデータセンターからAWS FSxストレージに実装または移行すると、データはFSx HAペアで自動同期ミラーリングされて保護されます。災害発生時に、複製されたスタンバイサイトによってデータがさらに保護されます。長期のバックアップ保持やデータ保護を実現するために、組み込みのPostgreSQL pg_basbackupユーティリティを使用して、S3 BLOBストレージに移植可能なフルデータベースバックアップを実行することを推奨します。
解決策 の導入
この解決策 の導入は、以下に示す詳細な手順に従って、NetApp Ansibleベースの自動化ツールキットを使用して自動的に完了できます。
-
オートメーションツールキットのreadme.mdの説明をお読みください"na_postgresql_AWS_DEプロイ_hadr"。
-
次のビデオを見ていきましょう。
-
(
hosts
host_vars/host_name.yml
`fsx_vars.yml`関連するセクションのテンプレートにユーザ固有のパラメータを入力して、必要なパラメータファイルを設定します。次に、コピーボタンを使用してAnsibleコントローラホストにファイルをコピーします。
導入を自動化するための前提条件
導入には、次の前提条件が必要です。
-
AWSアカウントが設定され、必要なVPCとネットワークセグメントがAWSアカウント内に作成されている。
-
AWS EC2コンソールでは、2つのEC2 Linuxインスタンスを導入する必要があります。1つはプライマリのPostgreSQL DBサーバ、もう1つはスタンバイのDRサイトです。プライマリおよびスタンバイDRサイトでのコンピューティングの冗長性を確保するために、2つの追加EC2 LinuxインスタンスをスタンバイPostgreSQL DBサーバとして配置します。環境セットアップの詳細については、前のセクションのアーキテクチャ図を参照してください。詳細については、も参照して"Linuxインスタンスのユーザーガイド"ください。
-
AWS EC2コンソールから、FSX ONTAP ストレージHAクラスタを2つ導入して、PostgreSQLデータベースボリュームをホストします。FSxストレージの導入に慣れていない場合は、ステップバイステップの手順についてドキュメントを参照してください"FSx ONTAPファイルシステムの作成"。
-
AnsibleコントローラをホストするCentOS Linux VMを構築します。Ansibleコントローラは、オンプレミスとAWSクラウドのどちらにも配置できます。オンプレミスにある場合は、VPC、EC2 Linuxインスタンス、およびFSXストレージクラスタへのSSH接続が必要です。
-
リソースから「RHEL / CentOSでのCLI導入用のAnsibleコントロールノードのセットアップ」セクションの説明に従って、Ansibleコントローラを"NetApp解決策 自動化の導入"セットアップします。
-
パブリックのNetApp GitHubサイトから、自動化ツールキットのコピーをクローニングします。
-
ツールキットのルートディレクトリで、必要なプレイブックを実行して、Ansibleコントローラに必要なコレクションとライブラリをインストールします。
-
DBホスト変数ファイルとグローバル変数 `fsx_vars.yml`ファイル構成に必要なEC2 FSxインスタンスパラメータを取得し `host_vars/*`ます。
hostsファイルを設定します
プライマリFSX ONTAP クラスタ管理IPとEC2インスタンスがhostsファイルに名前を入力します。
# Primary FSx cluster management IP address [fsx_ontap] 172.30.15.33
# Primary PostgreSQL DB server at primary site where database is initialized at deployment time [postgresql] psql_01p ansible_ssh_private_key_file=psql_01p.pem
# Primary PostgreSQL DB server at standby site where postgresql service is installed but disabled at deployment # Standby DB server at primary site, to setup this server comment out other servers in [dr_postgresql] # Standby DB server at standby site, to setup this server comment out other servers in [dr_postgresql] [dr_postgresql] -- psql_01s ansible_ssh_private_key_file=psql_01s.pem #psql_01ps ansible_ssh_private_key_file=psql_01ps.pem #psql_01ss ansible_ssh_private_key_file=psql_01ss.pem
host_varsフォルダでhost_name.ymlファイルを設定します
グローバルFSX_vars.ymlファイルをvarsフォルダに設定します
PostgreSQLの導入とHA/DRのセットアップ
次のタスクでは、PostgreSQL DBサーバサービスを展開し、プライマリEC2 DBサーバホストのプライマリサイトでデータベースを初期化します。スタンバイプライマリEC2 DBサーバホストは、スタンバイサイトで設定されます。最後に、DBボリュームのレプリケーションは、ディザスタリカバリ用にプライマリサイトのFSXクラスタからスタンバイサイトのFSXクラスタにセットアップされます。
-
プライマリFSXクラスタにDBボリュームを作成し、プライマリEC2インスタンスホストにPostgreSQLをセットアップします。
-
スタンバイDR EC2インスタンスホストを設定します。
-
FSX ONTAP クラスタピアリングとデータベースボリュームレプリケーションをセットアップします。
-
前の手順を1ステップのPostgreSQL展開とHA/DRセットアップに統合します。
-
プライマリサイトまたはスタンバイサイトのいずれかでスタンバイPostgreSQL DBホストを設定するには、hostsファイル[dr_gresql]セクションの他のすべてのサーバをコメントアウトし、それぞれのターゲットホスト(プライマリサイトのpsql_01psまたはスタンバイEC2コンピューティングインスタンスなど)でpostgresql_standby_setup.ymlプレイブックを実行します。ディレクトリの下に、などのホストパラメータファイルが設定されている `host_vars`ことを確認し `psql_01ps.yml`ます。
PostgreSQLデータベーススナップショットのバックアップとスタンバイサイトへのレプリケーション
PostgreSQLデータベーススナップショットのバックアップとスタンバイサイトへのレプリケーションは、ユーザー定義の間隔でAnsibleコントローラで制御および実行できます。間隔は5分程度に短くなることが確認されました。したがって、プライマリサイトで障害が発生した場合、スケジュールされている次のSnapshotバックアップの直前に障害が発生した場合、データ損失が5分間発生する可能性があります。
DRのスタンバイサイトにフェイルオーバーします
PostgreSQLのHA / DRシステムをDR用にテストするには、次のプレイブックを実行して、スタンバイサイトのプライマリスタンバイEC2 DBインスタンスでフェイルオーバーとPostgreSQLデータベースリカバリを実行します。実際のDRシナリオでは、同じ手順を実行してDRサイトへの実際のフェイルオーバーを行います。
フェイルオーバーテスト後にレプリケートされたDBボリュームを再同期
フェイルオーバーテスト後にresyncを実行して、データベースとボリュームのSnapMirrorレプリケーションを再確立します。
EC2コンピューティングインスタンス障害のため、プライマリEC2 DBサーバからスタンバイEC2 DBサーバへのフェイルオーバーを実行します
手動フェイルオーバーを実行するか、ライセンスが必要なOSクラスタウェアを十分に確立して使用することを推奨します。
詳細情報の入手方法
このドキュメントに記載されている情報の詳細については、以下のドキュメントや Web サイトを参照してください。
-
Amazon FSx ONTAP
-
Amazon EC2
-
NetApp 解決策の自動化