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

Oracle HA/DR automatisé dans AWS FSx ONTAP

Contributeurs kevin-hoke
PDF

Équipe d'ingénierie des solutions NetApp

Cette solution fournit une boîte à outils d'automatisation basée sur Ansible pour configurer la haute disponibilité et la reprise après sinistre (HA/DR) de la base de données Oracle avec AWS FSx ONTAP comme stockage de base de données Oracle et les instances EC2 comme instances de calcul dans AWS.

But

Cette boîte à outils automatise les tâches de configuration et de gestion d'un environnement de haute disponibilité et de reprise après sinistre (HR/DR) pour la base de données Oracle déployée dans le cloud AWS avec stockage FSx ONTAP et instances de calcul EC2.

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

  • Configuration de l'hôte cible HA/DR - configuration du noyau, configuration Oracle pour correspondre à l'hôte du serveur source.

  • Configuration de FSx ONTAP - peering de cluster, peering de vserver, configuration de la relation snapmirror des volumes Oracle de la source à la cible.

  • Sauvegarder les données de la base de données Oracle via un instantané - exécuter hors crontab

  • Sauvegarde du journal d'archive de la base de données Oracle via un instantané - exécution hors crontab

  • Exécuter le basculement et la récupération sur l'hôte HA/DR - tester et valider l'environnement HA/DR

  • Exécuter la resynchronisation après le test de basculement - 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 :

  • Un administrateur de base de données qui a configuré une base de données Oracle dans AWS pour une haute disponibilité, une protection des données et une reprise après sinistre.

  • Un architecte de solutions de base de données intéressé par une solution Oracle HA/DR au niveau du stockage dans le cloud AWS.

  • Un administrateur de stockage qui gère le stockage AWS FSx ONTAP prenant en charge les bases de données Oracle.

  • Un propriétaire d'application qui souhaite mettre en place une base de données Oracle pour HA/DR dans un environnement AWS FSx/EC2.

Licence

En accédant, en téléchargeant, en installant ou en utilisant le contenu de ce référentiel GitHub, vous acceptez les termes de la licence énoncés dans"Fichier de licence" .

Remarque Il existe certaines restrictions concernant la production et/ou le partage d'œuvres dérivées du contenu de ce référentiel GitHub. Veuillez vous assurer de lire les termes de la licence avant d'utiliser le contenu. Si vous n'acceptez pas toutes les conditions, n'accédez pas, ne téléchargez pas et n'utilisez pas le contenu de ce référentiel.

Déploiement de la solution

Prérequis pour le déploiement

Details

Le déploiement nécessite les prérequis suivants.

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 pilotés par des variables. Un exemple de fichier de variable globale fsx_vars_example.yml est inclus pour illustrer une configuration typique. Voici quelques considérations clés :

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 de l'hôte

Details

Les variables d'hôte sont définies dans le répertoire host_vars nommé {{ host_name }}.yml. Un exemple de fichier de variable hôte host_name.yml est inclus pour illustrer une configuration typique. Voici quelques considérations clés :

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

L'instance AWS EC2 utilise l'adresse IP pour la dénomination de l'hôte par défaut. Si vous utilisez un nom différent dans le fichier hosts pour Ansible, configurez la résolution de nommage d'hôte 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 playbook - exécutée en séquence

Details

  1. Installez les prérequis du contrôleur Ansible.

    ansible-playbook -i hosts requirements.yml
    ansible-galaxy collection install -r collections/requirements.yml --force

  2. Configurer l'instance cible de la base de données EC2.

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

  3. Configurer la relation snapmirror FSx ONTAP 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

  4. Sauvegardez les volumes de données de la base de données Oracle via un instantané à 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

  5. Sauvegardez les volumes de journaux d'archives de la base de données Oracle via un instantané à 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

  6. Exécutez le basculement et récupérez 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

  7. Exécutez la resynchronisation après le test de basculement - rétablissez 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 supplémentaires

Pour en savoir plus sur l'automatisation des solutions NetApp , consultez le site Web suivant"Automatisation des solutions NetApp "