Automatisez la haute disponibilité et la reprise après incident Oracle dans AWS FSX ONTAP
Équipe d'ingénierie des solutions NetApp
Cette solution fournit un kit d'outils d'automatisation basé sur Ansible pour configurer la haute disponibilité et la reprise d'activité (HA/DR) des bases de données Oracle avec AWS FSX ONTAP en tant que stockage de base de données Oracle et les instances EC2 en tant qu'instances de calcul dans AWS.
Objectif
Ce kit automatise les tâches de configuration et de gestion d'un environnement haute disponibilité et de reprise d'activité pour la base de données Oracle déployée dans le cloud AWS avec le stockage FSX ONTAP et les instances de calcul EC2.
Cette solution répond aux cas d'utilisation suivants :
-
Configurez l'hôte cible HA/DR : configuration du noyau, configuration Oracle pour qu'il corresponde à l'hôte du serveur source.
-
Setup FSX ONTAP : peering de cluster, peering de vServers, configuration des relations snapmirror des volumes Oracle de la source à la cible.
-
Sauvegardez les données de la base de données Oracle via snapshot - exécutez-les hors crontab
-
Sauvegarder le journal d'archivage de la base de données Oracle via snapshot - exécuter hors crontab
-
Exécuter le basculement et la restauration sur un hôte HA/DR et tester et valider l'environnement HA/DR
-
Exécutez la resynchronisation après le test de basculement pour rétablir la relation snapmirror des volumes de base de données en mode HA/DR
Public
Cette solution est destinée aux personnes suivantes :
-
Administrateur de bases de données qui a configuré une base de données Oracle dans AWS pour bénéficier de la haute disponibilité, de la protection des données et de la reprise après incident.
-
Architecte de solutions de bases de données et s'intéresse à la solution de haute disponibilité/reprise après incident Oracle au niveau du stockage dans le cloud AWS.
-
Administrateur du stockage qui gère le stockage AWS FSX ONTAP qui prend en charge les bases de données Oracle.
-
Un propriétaire d'applications qui aime créer une base de données Oracle pour la haute disponibilité/reprise dans l'environnement AWS FSX/EC2.
Licence
En accédant au contenu de ce référentiel GitHub, en le téléchargeant, en l'installant ou en l'utilisant, vous acceptez les conditions de la licence énoncées dans "Fichier de licence".
Il existe certaines restrictions concernant la production et/ou le partage de travaux dérivés avec le contenu de ce référentiel GitHub. Assurez-vous de lire les termes de la Licence avant d'utiliser le contenu. Si vous n'acceptez pas toutes les conditions, n'accédez pas au contenu de ce référentiel, ne le téléchargez pas et ne l'utilisez pas. |
Déploiement de la solution
Conditions préalables au déploiement
Details
Le déploiement nécessite les conditions préalables suivantes.
Ansible v.2.10 and higher ONTAP collection 21.19.1 Python 3 Python libraries: netapp-lib xmltodict jmespath
AWS FSx storage as is available
AWS EC2 Instance RHEL 7/8, Oracle Linux 7/8 Network interfaces for NFS, public (internet) and optional management Existing Oracle environment on source, and the equivalent Linux operating system at the target
Téléchargez la boîte à outils
Details
git clone https://github.com/NetApp/na_ora_hadr_failover_resync.git
Configuration des variables globales
Details
Les playbooks Ansible sont basés sur des variables. Un exemple de fichier de variables globales fsx_vars_example.yml est inclus pour démontrer une configuration typique. Principaux éléments à prendre en compte :
ONTAP - retrieve FSx storage parameters using AWS FSx console for both source and target FSx clusters. cluster name: source/destination cluster management IP: source/destination inter-cluster IP: source/destination vserver name: source/destination vserver management IP: source/destination NFS lifs: source/destination cluster credentials: fsxadmin and vsadmin pwd to be updated in roles/ontap_setup/defaults/main.yml file
Oracle database volumes - they should have been created from AWS FSx console, volume naming should follow strictly with following standard: Oracle binary: {{ host_name }}_bin, generally one lun/volume Oracle data: {{ host_name }}_data, can be multiple luns/volume, add additional line for each additional lun/volume in variable such as {{ host_name }}_data_01, {{ host_name }}_data_02 ... Oracle log: {{ host_name }}_log, can be multiple luns/volume, add additional line for each additional lun/volume in variable such as {{ host_name }}_log_01, {{ host_name }}_log_02 ... host_name: as defined in hosts file in root directory, the code is written to be specifically matched up with host name defined in host file.
Linux and DB specific global variables - keep it as is. Enter redhat subscription if you have one, otherwise leave it black.
Configuration des variables hôte
Details
Les variables hôtes sont définies dans le répertoire host_vars nommé {{ host_name }}.yml. Un exemple de fichier de variable hôte nom_hôte.yml est inclus pour démontrer une configuration typique. Principaux éléments à prendre en compte :
Oracle - define host specific variables when deploying Oracle in multiple hosts concurrently ansible_host: IP address of database server host log_archive_mode: enable archive log archiving (true) or not (false) oracle_sid: Oracle instance identifier pdb: Oracle in a container configuration, name pdb_name string and number of pdbs (Oracle allows 3 pdbs free of multitenant license fee) listener_port: Oracle listener port, default 1521 memory_limit: set Oracle SGA size, normally up to 75% RAM host_datastores_nfs: combining of all Oracle volumes (binary, data, and log) as defined in global vars file. If multi luns/volumes, keep exactly the same number of luns/volumes in host_var file
Linux - define host specific variables at Linux level hugepages_nr: set hugepage for large DB with large SGA for performance swap_blocks: add swap space to EC2 instance. If swap exist, it will be ignored.
Configuration du fichier hôte du serveur de BASE DE DONNÉES
Details
Instance AWS EC2 utilise l'adresse IP pour la dénomination des hôtes par défaut. Si vous utilisez un nom différent dans le fichier hosts pour Ansible, configurez la résolution de dénomination des hôtes dans le fichier /etc/hosts pour les serveurs source et cible. Voici un exemple.
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 172.30.15.96 db1 172.30.15.107 db2
Exécution du manuel de vente - exécutée dans l'ordre
Details
-
Installez les versions préalables du contrôleur Ansible.
ansible-playbook -i hosts requirements.yml
ansible-galaxy collection install -r collections/requirements.yml --force
-
Configurez l'instance de base de données EC2 cible.
ansible-playbook -i hosts ora_dr_setup.yml -u ec2-user --private-key db2.pem -e @vars/fsx_vars.yml
-
Configurez la relation ONTAP FSX snapmirror entre les volumes de base de données source et cible.
ansible-playbook -i hosts ontap_setup.yml -u ec2-user --private-key db2.pem -e @vars/fsx_vars.yml
-
Sauvegardez les volumes de données de la base de données Oracle via snapshot à partir de crontab.
10 * * * * cd /home/admin/na_ora_hadr_failover_resync && /usr/bin/ansible-playbook -i hosts ora_replication_cg.yml -u ec2-user --private-key db1.pem -e @vars/fsx_vars.yml >> logs/snap_data_`date +"%Y-%m%d-%H%M%S"`.log 2>&1
-
Sauvegarde des volumes du journal d'archivage de la base de données Oracle via snapshot à partir de crontab.
0,20,30,40,50 * * * * cd /home/admin/na_ora_hadr_failover_resync && /usr/bin/ansible-playbook -i hosts ora_replication_logs.yml -u ec2-user --private-key db1.pem -e @vars/fsx_vars.yml >> logs/snap_log_`date +"%Y-%m%d-%H%M%S"`.log 2>&1
-
Exécutez le basculement et restaurez la base de données Oracle sur l'instance de base de données EC2 cible. Testez et validez la configuration HA/DR.
ansible-playbook -i hosts ora_recovery.yml -u ec2-user --private-key db2.pem -e @vars/fsx_vars.yml
-
Exécuter la resynchronisation après le test de basculement - rétablir la relation snapmirror des volumes de base de données en mode de réplication.
ansible-playbook -i hosts ontap_ora_resync.yml -u ec2-user --private-key db2.pem -e @vars/fsx_vars.yml
Où trouver des informations complémentaires
Pour en savoir plus sur l'automatisation de la solution NetApp, consultez ce site Web "Automatisation des solutions NetApp"