Skip to main content
NetApp Solutions

Automated Oracle HA/DR in AWS FSx ONTAP

Contributors kevin-hoke acao8888
PDFs

NetApp Solutions Engineering Team

This solution provides an Ansible based automation toolkit for configuring Oracle database High Availability and Disaster Recovery (HA/DR) with AWS FSx ONTAP as Oracle database storage and EC2 instances as the compute instances in AWS.

Purpose

This toolkit automates the tasks of setting up and managing a High Availability and Disaster Recovery (HR/DR) environment for Oracle database deployed in AWS cloud with FSx ONTAP storage and EC2 compute instances.

This solution addresses the following use cases:

  • Setup HA/DR target host - kernel configuration, Oracle configuration to match up with source server host.

  • Setup FSx ONTAP - cluster peering, vserver peering, Oracle volumes snapmirror relationship setup from source to target.

  • Backup Oracle database data via snapshot - execute off crontab

  • Backup Oracle database archive log via snapshot - execute off crontab

  • Run failover and recovery on HA/DR host - test and validate HA/DR environment

  • Run resync after failover test - re-establish database volumes snapmirror relationship in HA/DR mode

Audience

This solution is intended for the following people:

  • A DBA who set up Oracle database in AWS for high availability, data protection, and disaster recovery.

  • A database solution architect who is interested in storage level Oracle HA/DR solution in the AWS cloud.

  • A storage administrator who manages AWS FSx ONTAP storage that supports Oracle databases.

  • An application owner who like to stand up Oracle database for HA/DR in AWS FSx/EC2 environment.

License

By accessing, downloading, installing or using the content in this GitHub repository, you agree the terms of the License laid out in License file.

Note There are certain restrictions around producing and/or sharing any derivative works with the content in this GitHub repository. Please make sure you read the terms of the License before using the content. If you do not agree to all of the terms, do not access, download or use the content in this repository.

Solution deployment

Prerequisites for deployment

Details

Deployment requires the following prerequisites.

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

Download the toolkit

Details 
git clone https://github.com/NetApp/na_ora_hadr_failover_resync.git

Global variables configuration

Details

The Ansible playbooks are variable driven. An example global variable file fsx_vars_example.yml is included to demonstrate typical configuration. Following are key considerations:

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.

Host variables configuration

Details

Host variables are defined in host_vars directory named as {{ host_name }}.yml. An example host variable file host_name.yml is included to demonstrate typical configuration. Following are key considerations:

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.

DB server host file configuration

Details

AWS EC2 instance use IP address for host naming by default. If you use different name in hosts file for Ansible, setup host naming resolution in /etc/hosts file for both source and target servers. Following is an example.

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

Playbook execution - executed in sequence

Details

  1. Install Ansible controller prerequsites.

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

  2. Setup target EC2 DB instance.

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

  3. Setup FSx ONTAP snapmirror relationship between source and target database volumes.

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

  4. Backup Oracle database data volumes via snapshot from 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. Backup Oracle database archive log volumes via snapshot from 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. Run failover and recover Oracle database on target EC2 DB instance - test and validate HA/DR configuration.

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

  7. Run resync after failover test - re-establish database volumes snapmirror relationship in replication mode.

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

Where to find additional information

To learn more about the NetApp solution automation, review the following website NetApp Solution Automation