Skip to main content
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

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環境で実行しました。詳細については、を参照してください 導入にあたって考慮すべき主な要因

アーキテクチャ

この図は、オンプレミス側やAWSサイトなど、PostgreSQLハイブリッドクラウド解決策 の構成の詳細を示しています。

ハードウェアおよびソフトウェアコンポーネント

* ハードウェア *

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ベースの自動化ツールキットを使用して自動的に完了できます。

  1. オートメーションツールキットのreadme.mdの説明をお読みください"na_postgresql_AWS_DEプロイ_hadr"

  2. 次のビデオを見ていきましょう。

PostgreSQLの自動導入と保護
  1. (hosts host_vars/host_name.yml `fsx_vars.yml`関連するセクションのテンプレートにユーザ固有のパラメータを入力して、必要なパラメータファイルを設定します。次に、コピーボタンを使用してAnsibleコントローラホストにファイルをコピーします。

導入を自動化するための前提条件

導入には、次の前提条件が必要です。

  1. AWSアカウントが設定され、必要なVPCとネットワークセグメントがAWSアカウント内に作成されている。

  2. AWS EC2コンソールでは、2つのEC2 Linuxインスタンスを導入する必要があります。1つはプライマリのPostgreSQL DBサーバ、もう1つはスタンバイのDRサイトです。プライマリおよびスタンバイDRサイトでのコンピューティングの冗長性を確保するために、2つの追加EC2 LinuxインスタンスをスタンバイPostgreSQL DBサーバとして配置します。環境セットアップの詳細については、前のセクションのアーキテクチャ図を参照してください。詳細については、も参照して"Linuxインスタンスのユーザーガイド"ください。

  3. AWS EC2コンソールから、FSX ONTAP ストレージHAクラスタを2つ導入して、PostgreSQLデータベースボリュームをホストします。FSxストレージの導入に慣れていない場合は、ステップバイステップの手順についてドキュメントを参照してください"FSx ONTAPファイルシステムの作成"

  4. AnsibleコントローラをホストするCentOS Linux VMを構築します。Ansibleコントローラは、オンプレミスとAWSクラウドのどちらにも配置できます。オンプレミスにある場合は、VPC、EC2 Linuxインスタンス、およびFSXストレージクラスタへのSSH接続が必要です。

  5. リソースから「RHEL / CentOSでのCLI導入用のAnsibleコントロールノードのセットアップ」セクションの説明に従って、Ansibleコントローラを"NetApp解決策 自動化の導入"セットアップします。

  6. パブリックのNetApp GitHubサイトから、自動化ツールキットのコピーをクローニングします。

git clone https://github.com/NetApp-Automation/na_postgresql_aws_deploy_hadr.git
Cli
  1. ツールキットのルートディレクトリで、必要なプレイブックを実行して、Ansibleコントローラに必要なコレクションとライブラリをインストールします。

ansible-playbook -i hosts requirements.yml
Cli
ansible-galaxy collection install -r collections/requirements.yml --force --force-with-deps
Cli
  1. 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ファイルを設定します

# Add your AWS EC2 instance IP address for the respective PostgreSQL server host
ansible_host: "10.61.180.15"

# "{{groups.postgresql[0]}}" represents first PostgreSQL DB server as defined in PostgreSQL hosts group [postgresql]. For concurrent multiple PostgreSQL DB servers deployment, [0] will be incremented for each additional DB server. For example,  "{{groups.posgresql[1]}}" represents DB server 2, "{{groups.posgresql[2]}}" represents DB server 3 ... As a good practice and the default, two volumes are allocated to a PostgreSQL DB server with corresponding /pgdata, /pglogs mount points, which store PostgreSQL data, and PostgreSQL log files respectively. The number and naming of DB volumes allocated to a DB server must match with what is defined in global fsx_vars.yml file by src_db_vols, src_archivelog_vols parameters, which dictates how many volumes are to be created for each DB server. aggr_name is aggr1 by default. Do not change. lif address is the NFS IP address for the SVM where PostgreSQL server is expected to mount its database volumes. Primary site servers from primary SVM and standby servers from standby SVM.
host_datastores_nfs:
  - {vol_name: "{{groups.postgresql[0]}}_pgdata", aggr_name: "aggr1", lif: "172.21.94.200", size: "100"}
  - {vol_name: "{{groups.postgresql[0]}}_pglogs", aggr_name: "aggr1", lif: "172.21.94.200", size: "100"}

# Add swap space to EC2 instance, that is equal to size of RAM up to 16G max. Determine the number of blocks by dividing swap size in MB by 128.
swap_blocks: "128"

# Postgresql user configurable parameters
psql_port: "5432"
buffer_cache: "8192MB"
archive_mode: "on"
max_wal_size: "5GB"
client_address: "172.30.15.0/24"
Bash

グローバルFSX_vars.ymlファイルをvarsフォルダに設定します

########################################################################
######  PostgreSQL HADR global user configuration variables       ######
######  Consolidate all variables from FSx, Linux, and postgresql ######
########################################################################

###########################################
### Ontap env specific config variables ###
###########################################

####################################################################################################
# Variables for SnapMirror Peering
####################################################################################################

#Passphrase for cluster peering authentication
passphrase: "xxxxxxx"

#Please enter destination or standby FSx cluster name
dst_cluster_name: "FsxId0cf8e0bccb14805e8"

#Please enter destination or standby FSx cluster management IP
dst_cluster_ip: "172.30.15.90"

#Please enter destination or standby FSx cluster inter-cluster IP
dst_inter_ip: "172.30.15.13"

#Please enter destination or standby SVM name to create mirror relationship
dst_vserver: "dr"

#Please enter destination or standby SVM management IP
dst_vserver_mgmt_lif: "172.30.15.88"

#Please enter destination or standby SVM NFS lif
dst_nfs_lif: "172.30.15.88"

#Please enter source or primary FSx cluster name
src_cluster_name: "FsxId0cf8e0bccb14805e8"

#Please enter source or primary FSx cluster management IP
src_cluster_ip: "172.30.15.20"

#Please enter source or primary FSx cluster inter-cluster IP
src_inter_ip: "172.30.15.5"

#Please enter source or primary SVM name to create mirror relationship
src_vserver: "prod"

#Please enter source or primary SVM management IP
src_vserver_mgmt_lif: "172.30.15.115"

#####################################################################################################
# Variable for PostgreSQL Volumes, lif - source or primary FSx NFS lif address
#####################################################################################################

src_db_vols:
  - {vol_name: "{{groups.postgresql[0]}}_pgdata", aggr_name: "aggr1", lif: "172.21.94.200", size: "100"}

src_archivelog_vols:
  - {vol_name: "{{groups.postgresql[0]}}_pglogs", aggr_name: "aggr1", lif: "172.21.94.200", size: "100"}

#Names of the Nodes in the ONTAP Cluster
nfs_export_policy: "default"

#####################################################################################################
### Linux env specific config variables ###
#####################################################################################################

#NFS Mount points for PostgreSQL DB volumes
mount_points:
  - "/pgdata"
  - "/pglogs"

#RedHat subscription username and password
redhat_sub_username: "xxxxx"
redhat_sub_password: "xxxxx"

####################################################
### DB env specific install and config variables ###
####################################################
#The latest version of PostgreSQL RPM is pulled/installed and config file is deployed from a preconfigured template
#Recovery type and point: default as all logs and promote and leave all PITR parameters blank
Bash

PostgreSQLの導入とHA/DRのセットアップ

次のタスクでは、PostgreSQL DBサーバサービスを展開し、プライマリEC2 DBサーバホストのプライマリサイトでデータベースを初期化します。スタンバイプライマリEC2 DBサーバホストは、スタンバイサイトで設定されます。最後に、DBボリュームのレプリケーションは、ディザスタリカバリ用にプライマリサイトのFSXクラスタからスタンバイサイトのFSXクラスタにセットアップされます。

  1. プライマリFSXクラスタにDBボリュームを作成し、プライマリEC2インスタンスホストにPostgreSQLをセットアップします。

    ansible-playbook -i hosts postgresql_deploy.yml -u ec2-user --private-key psql_01p.pem -e @vars/fsx_vars.yml
    Cli
  2. スタンバイDR EC2インスタンスホストを設定します。

    ansible-playbook -i hosts postgresql_standby_setup.yml -u ec2-user --private-key psql_01s.pem -e @vars/fsx_vars.yml
    Cli
  3. FSX ONTAP クラスタピアリングとデータベースボリュームレプリケーションをセットアップします。

    ansible-playbook -i hosts fsx_replication_setup.yml -e @vars/fsx_vars.yml
    Cli
  4. 前の手順を1ステップのPostgreSQL展開とHA/DRセットアップに統合します。

    ansible-playbook -i hosts postgresql_hadr_setup.yml -u ec2-user -e @vars/fsx_vars.yml
    Cli
  5. プライマリサイトまたはスタンバイサイトのいずれかでスタンバイPostgreSQL DBホストを設定するには、hostsファイル[dr_gresql]セクションの他のすべてのサーバをコメントアウトし、それぞれのターゲットホスト(プライマリサイトのpsql_01psまたはスタンバイEC2コンピューティングインスタンスなど)でpostgresql_standby_setup.ymlプレイブックを実行します。ディレクトリの下に、などのホストパラメータファイルが設定されている `host_vars`ことを確認し `psql_01ps.yml`ます。

    [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
    Cli
ansible-playbook -i hosts postgresql_standby_setup.yml -u ec2-user --private-key psql_01ps.pem -e @vars/fsx_vars.yml
Cli

PostgreSQLデータベーススナップショットのバックアップとスタンバイサイトへのレプリケーション

PostgreSQLデータベーススナップショットのバックアップとスタンバイサイトへのレプリケーションは、ユーザー定義の間隔でAnsibleコントローラで制御および実行できます。間隔は5分程度に短くなることが確認されました。したがって、プライマリサイトで障害が発生した場合、スケジュールされている次のSnapshotバックアップの直前に障害が発生した場合、データ損失が5分間発生する可能性があります。

*/15 * * * * /home/admin/na_postgresql_aws_deploy_hadr/data_log_snap.sh
Cli

DRのスタンバイサイトにフェイルオーバーします

PostgreSQLのHA / DRシステムをDR用にテストするには、次のプレイブックを実行して、スタンバイサイトのプライマリスタンバイEC2 DBインスタンスでフェイルオーバーとPostgreSQLデータベースリカバリを実行します。実際のDRシナリオでは、同じ手順を実行してDRサイトへの実際のフェイルオーバーを行います。

ansible-playbook -i hosts postgresql_failover.yml -u ec2-user --private-key psql_01s.pem -e @vars/fsx_vars.yml
Cli

フェイルオーバーテスト後にレプリケートされたDBボリュームを再同期

フェイルオーバーテスト後にresyncを実行して、データベースとボリュームのSnapMirrorレプリケーションを再確立します。

ansible-playbook -i hosts postgresql_standby_resync.yml -u ec2-user --private-key psql_01s.pem -e @vars/fsx_vars.yml
Cli

EC2コンピューティングインスタンス障害のため、プライマリEC2 DBサーバからスタンバイEC2 DBサーバへのフェイルオーバーを実行します

手動フェイルオーバーを実行するか、ライセンスが必要なOSクラスタウェアを十分に確立して使用することを推奨します。

詳細情報の入手方法

Looking for answers?
Try Doc, our Gen AI Assistant.