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

Automatisiertes Oracle HA/DR in AWS FSx ONTAP

Beitragende kevin-hoke
PDFs

NetApp Solutions Engineering Team

Diese Lösung bietet ein auf Ansible basierendes Automatisierungs-Toolkit zum Konfigurieren der Hochverfügbarkeit und Notfallwiederherstellung (HA/DR) von Oracle-Datenbanken mit AWS FSx ONTAP als Oracle-Datenbankspeicher und EC2-Instanzen als Compute-Instanzen in AWS.

Zweck

Dieses Toolkit automatisiert die Aufgaben zum Einrichten und Verwalten einer Hochverfügbarkeits- und Notfallwiederherstellungsumgebung (HR/DR) für Oracle-Datenbanken, die in der AWS-Cloud mit FSx ONTAP -Speicher und EC2-Recheninstanzen bereitgestellt werden.

Diese Lösung ist für die folgenden Anwendungsfälle geeignet:

  • Richten Sie den HA/DR-Zielhost ein – Kernelkonfiguration, Oracle-Konfiguration zur Übereinstimmung mit dem Quellserverhost.

  • FSx ONTAP einrichten – Cluster-Peering, VServer-Peering, Einrichtung der Snapmirror-Beziehung zwischen Oracle-Volumes und Ziel.

  • Oracle-Datenbankdaten per Snapshot sichern – Ausführung über Crontab

  • Sichern Sie das Oracle-Datenbankarchivprotokoll per Snapshot – Ausführung über Crontab

  • Führen Sie Failover und Wiederherstellung auf dem HA/DR-Host aus – testen und validieren Sie die HA/DR-Umgebung

  • Führen Sie nach dem Failover-Test eine erneute Synchronisierung durch – stellen Sie die Snapmirror-Beziehung der Datenbankvolumes im HA/DR-Modus wieder her

Publikum

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

  • Ein DBA, der eine Oracle-Datenbank in AWS für hohe Verfügbarkeit, Datenschutz und Notfallwiederherstellung eingerichtet hat.

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

  • Ein Speicheradministrator, der AWS FSx ONTAP Speicher verwaltet, der Oracle-Datenbanken unterstützt.

  • Ein Anwendungsbesitzer, der eine Oracle-Datenbank für HA/DR in einer AWS FSx/EC2-Umgebung einrichten möchte.

Lizenz

Indem Sie auf den Inhalt dieses GitHub-Repositorys zugreifen, ihn herunterladen, installieren oder verwenden, stimmen Sie den Bedingungen der Lizenz zu, die in"Lizenzdatei" .

Hinweis Es gelten bestimmte Einschränkungen hinsichtlich der Erstellung und/oder Weitergabe abgeleiteter Werke mit den Inhalten 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 die Inhalte in diesem Repository zugreifen, sie nicht herunterladen oder verwenden.

Lösungsbereitstellung

Voraussetzungen für die Bereitstellung

Details

Für die Bereitstellung sind die folgenden Voraussetzungen erforderlich.

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

Laden Sie das Toolkit herunter

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

Konfiguration globaler Variablen

Details

Die Ansible-Playbooks sind variablengesteuert. Zur Veranschaulichung einer typischen Konfiguration ist eine Beispieldatei mit globalen Variablen (fsx_vars_example.yml) enthalten. Im Folgenden sind die wichtigsten Überlegungen aufgeführt:

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 Hostvariablen

Details

Hostvariablen werden im Verzeichnis host_vars mit dem Namen {{ host_name }}.yml definiert. Zur Veranschaulichung einer typischen Konfiguration ist eine Beispieldatei mit Hostvariablen host_name.yml enthalten. Im Folgenden sind die wichtigsten Überlegungen aufgeführt:

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 DB-Server-Hostdatei

Details

AWS EC2-Instanzen verwenden standardmäßig die IP-Adresse zur Hostbenennung. Wenn Sie in der Hosts-Datei für Ansible einen anderen Namen verwenden, richten Sie die Host-Namensauflösung in der Datei /etc/hosts für Quell- und Zielserver ein. Es folgt 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

Playbook-Ausführung – nacheinander ausgeführt

Details

  1. Installieren Sie die Voraussetzungen für den Ansible-Controller.

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

  2. Richten Sie die Ziel-EC2-DB-Instance ein.

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

  3. Richten Sie die FSx ONTAP Snapmirror-Beziehung zwischen Quell- und Zieldatenbank-Volumes ein.

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

  4. Sichern Sie Oracle-Datenbankdatenvolumes per Snapshot aus 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. Sichern Sie die Protokollvolumes des Oracle-Datenbankarchivs per Snapshot aus 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. Führen Sie ein Failover durch und stellen Sie die Oracle-Datenbank auf der EC2-Ziel-DB-Instance wieder her – testen und validieren Sie die HA/DR-Konfiguration.

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

  7. Führen Sie nach dem Failover-Test eine erneute Synchronisierung aus – stellen Sie die Snapmirror-Beziehung der Datenbankvolumes im Replikationsmodus wieder her.

    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 der NetApp -Lösung finden Sie auf der folgenden Website"Automatisierung der NetApp -Lösung"