Skip to main content
NetApp Solutions
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Tr-4956 : déploiement haute disponibilité et reprise après incident PostgreSQL automatisé dans AWS FSX/EC2

Contributeurs

Allen Cao, Niyaz Mohamed, NetApp

Objectif

PostgreSQL est une base de données open-source largement utilisée qui est classée numéro quatre parmi les dix plus populaires moteurs de base de données par "Moteurs DB". D'une part, PostgreSQL tire sa popularité de son modèle open-source sans licence tout en conservant des fonctionnalités sophistiquées. D'autre part, comme les données proviennent de sources ouvertes, il existe un manque de conseils détaillés sur le déploiement de bases de données de production dans les domaines de la haute disponibilité et de la reprise après incident, en particulier dans le cloud public. En général, il peut être difficile de configurer un système haute disponibilité/reprise PostgreSQL classique avec des systèmes de secours et à chaud, de réplication en continu, etc. Tester l'environnement de haute disponibilité/reprise après incident en mettant en avant le site de secours, puis en retournant au site primaire peut interrompre la production. Des problèmes de performances sont documentés sur le site principal lorsque des charges de travail de lecture sont déployées sur le streaming à chaud.

Dans cette documentation, nous vous montrerons comment passer à la solution haute disponibilité et de reprise en continu PostgreSQL au niveau de l'application, et créer une solution haute disponibilité/reprise après incident PostgreSQL basée sur le stockage ONTAP AWS FSX et les instances de calcul EC2 en utilisant la réplication au niveau du stockage. La solution crée un système plus simple et comparable et offre des résultats équivalents lorsque l'on compare la réplication de streaming PostgreSQL classique au niveau applicatif pour la haute disponibilité et la reprise après incident.

Cette solution repose sur la technologie de réplication de stockage NetApp SnapMirror éprouvée et mature, disponible dans le stockage cloud FSX ONTAP natif AWS pour PostgreSQL HA/DR. Il est simple à implémenter grâce à un kit d'automatisation fourni par l'équipe NetApp Solutions. Elles offrent des fonctionnalités similaires, tout en éliminant la complexité et les difficultés liées aux performances sur le site principal grâce à la solution de haute disponibilité/reprise après incident basée sur le streaming au niveau des applications. La solution peut être facilement déployée et testée sans affecter le site principal actif.

Cette solution répond aux cas d'utilisation suivants :

  • Profitez d'un déploiement haute disponibilité/reprise après incident pour PostgreSQL dans le cloud public AWS

  • Test et validation d'une charge de travail PostgreSQL dans le cloud public AWS

  • Test et validation d'une stratégie haute disponibilité/de reprise après incident PostgreSQL basée sur la technologie de réplication NetApp SnapMirror

Public

Cette solution est destinée aux personnes suivantes :

  • L'administrateur de bases de données qui souhaite déployer PostgreSQL avec la haute disponibilité et la reprise d'activité dans le cloud public AWS.

  • L'architecte de solution de base de données qui souhaite tester les workloads PostgreSQL dans le cloud public AWS.

  • L'administrateur du stockage qui souhaite déployer et gérer des instances PostgreSQL déployées sur le stockage AWS FSX.

  • Le propriétaire de l'application qui souhaite mettre en place un environnement PostgreSQL dans AWS FSX/EC2.

Environnement de test et de validation de la solution

Le test et la validation de cette solution ont été réalisés dans un environnement AWS FSX et EC2 qui ne correspond pas à l'environnement de déploiement final. Pour plus d'informations, reportez-vous à la section [Key Factors for Deployment Consideration].

Architecture

Cette image fournit une vue détaillée de l'entreprise de la solution de cloud hybride PostgreSQL

Composants matériels et logiciels

Matériel

Stockage ONTAP FSX

Version actuelle

Deux paires haute disponibilité FSX dans le même VPC et la même zone de disponibilité que les clusters haute disponibilité de secours et primaires

Instance EC2 pour le calcul

t2.XLarge/4 vCPU/16 Gbit/s

Deux instances T2 XLarge d'EC2 en tant qu'instances de calcul principales et de secours

Contrôleur Ansible

CentOS VM/4 vCPU/8 Go sur site

Une machine virtuelle pour héberger le contrôleur d'automatisation Ansible, soit sur site, soit dans le cloud

Logiciel

Red Hat Linux

RHEL-8.6.0_HVM-20220503-x86_64-2-Hourly2-GP2

Déploiement de l'abonnement Red Hat pour les tests

CentOS Linux

CentOS Linux version 8.2.2004 (cœur)

Hébergement du contrôleur Ansible déployé dans un laboratoire sur site

PostgreSQL

Version 14.5

L'automatisation extrait la dernière version disponible de PostgreSQL à partir du postgresql.ora yum repo

Ansible

Version 2.10.3

Conditions requises pour les collections et bibliothèques requises installées avec le PlayBook des besoins

Facteurs clés à prendre en compte lors du déploiement

  • Sauvegarde, restauration et récupération de base de données PostgreSQL. Une base de données PostgreSQL prend en charge plusieurs méthodes de sauvegarde, telles qu'une sauvegarde logique à l'aide de pg_dump, une sauvegarde physique en ligne avec pg_basebackup ou une commande de sauvegarde du système d'exploitation de niveau inférieur, et des instantanés cohérents au niveau du stockage. Cette solution utilise des snapshots de groupes de cohérence NetApp pour les données de base de données PostgreSQL et la sauvegarde, la restauration et la récupération de volumes WAL au site de secours. Les copies Snapshot de volume de groupe de cohérence NetApp séquence les E/S au fur et à mesure de leur écriture sur le stockage et protègent l'intégrité des fichiers de données de base de données.

  • Instances de calcul EC2. dans ces tests et validations, nous avons utilisé le type d'instance AWS EC2 t2.XLarge pour l'instance de calcul de la base de données PostgreSQL. NetApp recommande d'utiliser une instance M5 de type EC2 comme instance de calcul pour PostgreSQL lors du déploiement, car elle est optimisée pour les charges de travail de base de données. L'instance de calcul de secours doit toujours être déployée dans la même zone que le système de fichiers passif (de secours) déployé pour le cluster FSX HA.

  • Clusters HA de stockage FSX déploiement sur une ou plusieurs zones. lors de ces tests et validations, nous avons déployé un cluster HA FSX dans une zone de disponibilité AWS unique. Pour le déploiement de production, NetApp recommande de déployer une paire haute disponibilité FSX dans deux zones de disponibilité différentes. Si une distance spécifique est requise entre le système principal et la veille, une paire haute disponibilité de secours peut être configurée pour assurer la continuité de l'activité dans une autre région. Un cluster FSX HA est provisionné dans une paire haute disponibilité qui est mise en miroir synchrone dans une paire de systèmes de fichiers actifs-passifs afin d'assurer la redondance au niveau du stockage.

  • Données PostgreSQL et placement de journaux. les déploiements PostgreSQL classiques partagent le même répertoire racine ou les mêmes volumes pour les fichiers de données et de journaux. Lors de nos tests et validations, nous avons séparé les données PostgreSQL et les logs en deux volumes distincts pour les performances. Un lien logiciel est utilisé dans le répertoire de données pour pointer vers le répertoire ou le volume du journal qui héberge les journaux PostgreSQL WAL et les journaux WAL archivés.

  • Compteur de délai de démarrage du service PostgreSQL. cette solution utilise des volumes montés sur NFS pour stocker le fichier de base de données PostgreSQL et les fichiers journaux WAL. Lors du redémarrage d'un hôte de base de données, le service PostgreSQL peut essayer de démarrer pendant que le volume n'est pas monté. Cela entraîne un échec de démarrage du service de base de données. Un délai de temporisation de 10 à 15 secondes est nécessaire pour que la base de données PostgreSQL démarre correctement.

  • RPO/RTO pour la continuité de l'activité. la réplication de données FSX du stockage primaire au mode de secours pour la reprise après incident est basée sur ASYNC, ce qui signifie que l'RPO dépend de la fréquence des sauvegardes Snapshot et de la réplication SnapMirror. Par ailleurs, la fréquence plus élevée de la copie Snapshot et de la réplication SnapMirror réduit le RPO. Il existe donc un équilibre entre perte potentielle de données en cas d'incident et coût de stockage incrémentiel. Nous avons déterminé que la copie Snapshot et la réplication SnapMirror peuvent être implémentées dans des intervalles d'à peine 5 minutes pour le RPO et que PostgreSQL peut être restauré sur le site de secours en moins d'une minute pour le RTO.

  • Sauvegarde de la base de données. après l'implémentation ou la migration d'une base de données PostgreSQL vers un système de stockage FSX AWS à partir d'un centre de données On-Prenail, les données sont automatiquement synchronisées en miroir dans la paire HA FSX pour la protection. En outre, les données sont protégées par un site de secours répliqué en cas d'incident. Pour une protection des données ou une conservation des sauvegardes à plus long terme, NetApp recommande d'utiliser l'utilitaire de sauvegarde PostgreSQL pg_basebackup intégré pour exécuter une sauvegarde complète de base de données qui peut être portée vers le stockage d'objets blob S3.

Déploiement de la solution

Le déploiement de cette solution peut être réalisé automatiquement à l'aide du kit d'automatisation basé sur NetApp Ansible, en suivant les instructions détaillées ci-dessous.

  1. Lisez les instructions de la boîte à outils d'automatisation Readme.md "na_postgresql_aws_deploy_hadr".

  2. Regardez la vidéo suivante.

Déploiement et protection PostgreSQL automatisés
  1. Configurez les fichiers de paramètres requis (hosts, host_vars/host_name.yml, fsx_vars.yml) en saisissant des paramètres spécifiques à l'utilisateur dans le modèle dans les sections correspondantes. Utilisez ensuite le bouton Copy pour copier des fichiers vers l'hôte du contrôleur Ansible.

Conditions préalables au déploiement automatisé

Le déploiement nécessite les conditions préalables suivantes.

  1. Un compte AWS a été configuré et les segments de réseau et de VPC nécessaires ont été créés dans votre compte AWS.

  2. À partir de la console AWS EC2, vous devez déployer deux instances Linux EC2, une comme serveur DB PostgreSQL principal au niveau du site principal et une instance du site de reprise en veille. Pour assurer la redondance des ressources de calcul sur les sites de reprise après incident principaux et de secours, déployez deux instances Linux EC2 supplémentaires en tant que serveurs DB PostgreSQL de secours. Pour plus d'informations sur la configuration de l'environnement, reportez-vous au diagramme de l'architecture de la section précédente. Consultez également le "Guide de l'utilisateur pour les instances Linux" pour en savoir plus.

  3. À partir de la console AWS EC2, déployez deux clusters HA du stockage ONTAP FSX pour héberger les volumes de base de données PostgreSQL. Si vous ne connaissez pas le déploiement du stockage FSX, reportez-vous à la documentation "Création de FSX pour les systèmes de fichiers ONTAP" pour obtenir des instructions détaillées.

  4. Créez une machine virtuelle CentOS Linux pour héberger le contrôleur Ansible. Le contrôleur Ansible peut être situé sur site ou dans le cloud AWS. S'il est situé sur site, vous devez disposer d'une connectivité SSH avec les clusters de stockage VPC, EC2 Linux et FSX.

  5. Configurez le contrôleur Ansible comme décrit dans la section « configurez le nœud de contrôle Ansible pour les déploiements CLI sur RHEL/CentOS » à partir de la ressource "Commencer à utiliser l'automatisation des solutions NetApp".

  6. Clonez une copie du kit d'automatisation à partir du site GitHub public de NetApp.

git clone https://github.com/NetApp-Automation/na_postgresql_aws_deploy_hadr.git
  1. À partir du répertoire racine du kit, exécutez les playbooks requis pour installer les collections et les bibliothèques requises pour le contrôleur Ansible.

ansible-playbook -i hosts requirements.yml
ansible-galaxy collection install -r collections/requirements.yml --force --force-with-deps
  1. Récupérez les paramètres d'instance FSX EC2 requis pour le fichier de variables hôte DB host_vars/* et le fichier de variables globales fsx_vars.yml configuration.

Configurez le fichier hosts

Saisissez les noms d'hôtes des instances EC2 et IP de gestion de cluster FSX ONTAP primaires dans le fichier 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

Configurez le fichier host_name.yml dans le dossier Host_var

# 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"

Configurez le fichier global fsx_var.yml dans le dossier rva

########################################################################
######  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

Déploiement PostgreSQL et configuration haute disponibilité/reprise après incident

Les tâches suivantes permettent de déployer le service du serveur de base de données PostgreSQL et d'initialiser la base de données sur le site primaire du serveur de base de données EC2 principal. Un hôte de serveur BDD EC2 principal en veille est ensuite configuré sur le site de secours. Enfin, la réplication du volume de la base de données est configurée depuis le cluster FSX du site principal vers le cluster FSX du site de secours pour la reprise après incident.

  1. Créez des volumes de base de données sur le cluster FSX primaire et configurez postgresql sur l'hôte de l'instance EC2 principale.

    ansible-playbook -i hosts postgresql_deploy.yml -u ec2-user --private-key psql_01p.pem -e @vars/fsx_vars.yml
  2. Configurez l'hôte de l'instance EC2 de reprise après incident de secours.

    ansible-playbook -i hosts postgresql_standby_setup.yml -u ec2-user --private-key psql_01s.pem -e @vars/fsx_vars.yml
  3. Configurer le peering de clusters FSX ONTAP et la réplication du volume de la base de données.

    ansible-playbook -i hosts fsx_replication_setup.yml -e @vars/fsx_vars.yml
  4. Consolider les étapes précédentes en une seule étape du déploiement PostgreSQL et de la configuration de la haute disponibilité et de la reprise après incident.

    ansible-playbook -i hosts postgresql_hadr_setup.yml -u ec2-user -e @vars/fsx_vars.yml
  5. Pour configurer un hôte DB PostgreSQL de secours sur les sites primaire ou de secours, commentez tous les autres serveurs de la section fichier hosts [dr_postgresql], puis exécutez le PlayBook postgresql_standby_setup.yml avec l'hôte cible respectif (tel que psql_01ps ou l'instance de calcul EC2 de secours sur le site primaire). Assurez-vous qu'un fichier de paramètres hôte tel que psql_01ps.yml est configuré sous host_vars répertoire.

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

Sauvegarde et réplication de snapshot de la base de données PostgreSQL vers le site de secours

La sauvegarde et la réplication de snapshot de la base de données PostgreSQL vers le site de secours peuvent être contrôlées et exécutées sur le contrôleur Ansible à l'aide d'un intervalle défini par l'utilisateur. Nous avons vérifié que l'intervalle peut aller jusqu'à 5 minutes. Par conséquent, en cas de défaillance sur le site primaire, il y a 5 minutes de perte de données potentielle en cas de défaillance immédiatement avant la prochaine sauvegarde Snapshot planifiée.

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

Le basculement vers un site de secours pour la reprise après incident

Pour tester le système haute disponibilité/reprise PostgreSQL en tant qu'exercice de reprise après incident, exécutez le basculement et la restauration de base de données PostgreSQL sur l'instance de base de données EC2 principale en attente sur le site en exécutant le manuel de vente suivant. Dans un scénario de reprise d'activité effectivement, exécutez la même opération pour un basculement vers le site de reprise sur incident.

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

Resynchronisation des volumes de bases de données répliqués après le test de basculement

Exécutez la resynchronisation après le test de basculement pour rétablir la réplication SnapMirror volume de bases de données.

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

Le basculement du serveur BDD EC2 principal vers le serveur DB EC2 de secours en raison d'une défaillance de l'instance de calcul EC2

NetApp recommande d'exécuter un basculement manuel ou un logiciel de cluster OS bien établi pouvant nécessiter une licence.