Skip to main content
NetApp Solutions
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Automatisierte Oracle HA/DR in AWS FSX ONTAP

Beitragende
PDFs

NetApp Solutions Engineering Team

Zweck

Dieses Toolkit automatisiert die Aufgaben beim Einrichten und Managen einer Umgebung für Hochverfügbarkeit und Disaster Recovery (HR/DR) für Oracle Database, die in der AWS Cloud mit FSX für ONTAP Storage- und EC2 Computing-Instanzen implementiert wird.

Diese Lösung eignet sich für folgende Anwendungsfälle:

  • Richten Sie HA/DR-Ziel-Host ein – Kernel-Konfiguration, Oracle-Konfiguration, die mit dem Quell-Server-Host übereinstimmt.

  • Einrichtung von FSX ONTAP – Einrichtung von Cluster-Peering, vServer-Peering, Einrichtung der Oracle Volumes snapmirror Beziehung von der Quelle zum Ziel.

  • Sichern Sie Oracle-Datenbankdaten per Snapshot - Ausführen von crontab

  • Backup Oracle Datenbank Archiv Protokoll per Snapshot - Ausführen von crontab

  • Failover und Recovery auf HA/DR-Host – testen und validieren der HA/DR-Umgebung

  • Resynchronisierung nach Failover-Test durchführen - Datenbank-Volumes snapmirror-Beziehung wieder im HA-/DR-Modus einrichten

Zielgruppe

Diese Lösung ist für folgende Personen gedacht:

  • Ein DBA, der Oracle-Datenbanken in AWS für Hochverfügbarkeit, Datensicherung und Disaster Recovery eingerichtet hat.

  • Ein Datenbanklösungsarchitekt, der an einer Oracle HA/DR-Lösung auf Storage-Ebene in der AWS-Cloud interessiert ist.

  • Ein Storage-Administrator, der für das Management von AWS FSX ONTAP Storage zur Unterstützung von Oracle-Datenbanken zuständig ist

  • Ein Applikationseigentümer, der Oracle Database für HA/DR in einer AWS FSX/EC2-Umgebung einrichten möchte.

Lizenz

Durch den Zugriff auf, das Herunterladen, die Installation oder die Verwendung der Inhalte in diesem GitHub-Repository stimmen Sie den Bedingungen der in dargelegten Lizenz zu "Lizenzdatei".

Hinweis Es gibt bestimmte Beschränkungen bezüglich der Erstellung und/oder Freigabe von abgeleiteten Arbeiten mit dem Inhalt in diesem GitHub-Repository. Bitte lesen Sie die Lizenzbedingungen, bevor Sie den Inhalt verwenden. Wenn Sie nicht allen Bedingungen zustimmen, dürfen Sie nicht auf den Inhalt dieses Repositorys zugreifen, ihn herunterladen oder verwenden.

Lösungsimplementierung

Voraussetzungen für die Bereitstellung

Details

Die Bereitstellung erfordert die folgenden Voraussetzungen.

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

Toolkit herunterladen

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

Konfiguration globaler Variablen

Details

Die Ansible-Playbooks sind variablengetrieben. Eine globale Beispieldatei fsx_VARs_example.yml ist enthalten, um eine typische Konfiguration zu demonstrieren. Wichtige Überlegungen:

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.

Konfiguration der Host-Variablen

Details

Hostvariablen werden im Verzeichnis Host_VARs mit dem Namen {{ Host_Name }}.yml definiert. Eine Beispiel-Host-Variable Datei Host_Name.yml ist enthalten, um die typische Konfiguration zu demonstrieren. Wichtige Überlegungen:

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.

Konfiguration der Hostdatei des DB-Servers

Details

AWS EC2-Instanz verwenden standardmäßig die IP-Adresse für die Hostbenennung. Wenn Sie einen anderen Namen in der Hostdatei für Ansible verwenden, richten Sie die Auflösung der Hostbenennung in der Datei /etc/Hosts sowohl für Quell- als auch für Zielserver ein. Hier ein Beispiel.

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

Ausführung des Playbooks – in der Reihenfolge ausgeführt

Details

  1. Controller-Prerequsites Ansible installieren

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

  2. Einrichtung der Ziel-EC2 DB-Instanz.

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

  3. FSX ONTAP-snapmirror-Beziehung zwischen Quell- und Ziel-Datenbank-Volumes einrichten

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

  4. Sichern Sie die Datenvolumes der Oracle-Datenbank per Snapshot von 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 von Protokollvolumes der Oracle-Datenbank per Snapshot von 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. Failover und Recovery von Oracle Datenbanken auf EC2 Ziel-DB-Instanz – HA/DR-Konfiguration testen und validieren

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

  7. Resynchronisierung nach Failover-Test durchführen - Datenbank-Volumes snapmirror-Beziehung im Replizierungsmodus wiederherstellen.

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

Wo Sie weitere Informationen finden

Weitere Informationen zur Automatisierung von NetApp Lösungen finden Sie auf der folgenden Website "Automatisierung der NetApp Lösung"