Automatisierter Oracle-Klon-Lebenszyklus auf ANF mit ASM
Änderungen vorschlagen
PDFs
Allen Cao, Niyaz Mohamed, NetApp
Die Lösung bietet ein auf Ansible basierendes Automatisierungs-Toolkit zum Einrichten, Klonen und Aktualisieren von Oracle-Klondatenbanken aus der physischen Standby-Datenbank von Oracle Data Guard, die in der Azure-Cloud auf Azure NetApp Files Speicher mit ASM-Konfiguration gehostet wird.
Zweck
Die Nutzung der Klone der physischen Standby-Oracle-Datenbank in der Oracle Data Guard-Konfiguration für andere Anwendungsfälle dient mehreren Zwecken. Es stellt eine beschreibbare Kopie der Produktionsdatenbank für Entwicklungs- oder UAT-Zwecke bereit. Auf diese Weise können teure Lizenzkosten für Active Data Guard vermieden werden, wenn eine kurze Verzögerung (10–15 Minuten) bei der Berichterstattung akzeptabel ist. Dies spart Speicherkosten, insbesondere wenn der Thin Clone eine Option ist. Mit diesem auf Ansible basierenden Automatisierungs-Toolkit können Benutzer geklonte Oracle-Datenbanken nach Benutzerzeitplänen einrichten, klonen und aktualisieren, um das Lebenszyklusmanagement zu optimieren. Das Toolkit gilt für Oracle-Datenbanken, die in der öffentlichen Azure-Cloud mithilfe von Azure NetApp Files Speicher und einer in einer Data Guard-Konfiguration konfigurierten Oracle-Datenbank bereitgestellt werden.
Diese Lösung ist für die folgenden Anwendungsfälle geeignet:
-
Richten Sie die Konfigurationsdateien für den Oracle-Standby-Datenbankklon für die Ansible-Automatisierung ein.
-
Erstellen oder aktualisieren Sie eine geklonte Oracle-Datenbank aus dem Data Guard-Standby mithilfe des Ansible-Playbooks nach einem benutzerdefinierten Zeitplan.
Publikum
Diese Lösung ist für folgende Personen gedacht:
-
Ein DBA, der Oracle-Datenbanken in der Azure-Cloud verwaltet.
-
Ein Speicheradministrator, der den Azure NetApp Files Speicher verwaltet.
-
Ein Anwendungsbesitzer, der Oracle-Datenbanken aus dem Data Guard-Standby für andere Anwendungsfälle klonen 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" .
|
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 controller:
Ansible v.2.10 and higher
ONTAP collection 21.19.1
Python 3
Python libraries:
netapp-lib
xmltodict
jmespath
Oracle servers: Physical standby Oracle servers in Data Guard configuration Clone target Oracle servers with ASM configuration
|
|
Der Einfachheit halber sollte der Oracle-Zielserver für den Klon identisch zum Standby-Oracle-Server konfiguriert sein, beispielsweise hinsichtlich des Oracle-Software-Stacks und des Verzeichnislayouts für Oracle Home usw. |
Laden Sie das Toolkit herunter
Details
git clone https://bitbucket.ngage.netapp.com/scm/ns-bb/na_oracle_clone_anf.git|
|
Auf das Toolkit kann derzeit nur von internen NetApp Benutzern mit Bitbucket-Zugriff zugegriffen werden. Interessierte externe Benutzer fordern den Zugriff bitte bei ihrem Account-Team an oder wenden sich an das NetApp Solutions Engineering-Team. |
Konfiguration der Ansible-Quell- und Zielhostdateien
Details
Das Toolkit enthält eine Hosts-Datei, die die Quell- und Ziel-Oracle-Hosts definiert, auf denen das Ansible-Playbook ausgeführt wird. Normalerweise umfasst es den Standby-DB-Host im Data Guard-Setup und den Ziel-Oracle-Klonhost. Es folgt eine Beispieldatei. Ein Hosteintrag enthält die IP-Adresse des Zielhosts sowie den SSH-Schlüssel für den Benutzerzugriff auf den Host, um den Klon- oder Aktualisierungsbefehl auszuführen. Der Azure NetApp Files Speicher wird über die API konfiguriert. Daher erfolgt die ANF-Verbindung über den lokalen Host per HTTP-Protokoll.
[ora_stdby] oras ansible_host=172.179.119.75 ansible_ssh_private_key_file=oras.pem
[ora_clone] orac ansible_host=52.148.142.212 ansible_ssh_private_key_file=orac.pem
[azure] localhost ansible_connection=local
Konfiguration globaler Variablen
Details
Unten sehen Sie ein Beispiel für eine typische globale Variablendatei vars.yml, die Variablen enthält, die auf globaler Ebene anwendbar sind.
###################################################################### ###### Oracle DB clone on ANF user configuration variables ###### ###### Consolidate all variables from ANF, linux and oracle ###### ######################################################################
########################################### ### ONTAP/ANF specific config variables ### ###########################################
# ANF credential subscription: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" client: "xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" secret: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" tenant: "xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"
# Cloned DB volumes from standby DB
resource_group: ANFAVSRG
storage_account: ANFOraWest
anf_pool: database2
data_vols:
- "{{ groups.ora_stdby[0] }}-u02"
- "{{ groups.ora_stdby[0] }}-u04"
- "{{ groups.ora_stdby[0] }}-u05"
- "{{ groups.ora_stdby[0] }}-u06"
- "{{ groups.ora_stdby[0] }}-u03"
nfs_lifs: - 10.0.3.36 - 10.0.3.36 - 10.0.3.36 - 10.0.3.36 - 10.0.3.36
########################################### ### Linux env specific config variables ### ###########################################
#################################################### ### DB env specific install and config variables ### ####################################################
# Standby DB configuration
oracle_user: oracle
oracle_base: /u01/app/oracle
oracle_sid: NTAP
db_unique_name: NTAP_LA
oracle_home: '{{ oracle_base }}/product/19.0.0/{{ oracle_sid }}'
spfile: '+DATA/{{ db_unique_name }}/PARAMETERFILE/spfile.289.1190302433'
adump: '{{ oracle_base }}/admin/{{ db_unique_name }}/adump'
grid_home: /u01/app/oracle/product/19.0.0/grid
asm_disk_groups:
- DATA
- LOGS
# Clond DB configuration clone_sid: NTAPDEV sys_pwd: "xxxxxxxx"
Konfiguration der Hostvariablen
Details
Hostvariablen werden im Verzeichnis host_vars mit dem Namen {{ host_name }}.yml definiert, das nur für den jeweiligen Host gilt. Für diese Lösung wird nur die Ziel-Klon-DB-Host-Parameterdatei konfiguriert. Die Parameter der Oracle-Standby-DB werden in der Datei „Globale Variablen“ konfiguriert. Unten sehen Sie ein Beispiel für die Hostvariablendatei orac.yml des Ziel-Oracle-Klon-DB, die eine typische Konfiguration zeigt.
# User configurable Oracle clone host specific parameters
# Database SID - clone DB SID
oracle_base: /u01/app/oracle
oracle_user: oracle
clone_sid: NTAPDEV
oracle_home: '{{ oracle_base }}/product/19.0.0/{{ oracle_sid }}'
clone_adump: '{{ oracle_base }}/admin/{{ clone_sid }}/adump'
grid_user: oracle
grid_home: '{{ oracle_base }}/product/19.0.0/grid'
asm_sid: +ASM
Zusätzliche Oracle-Serverkonfiguration für Klonziele
Details
Auf dem geklonten Oracle-Zielserver sollte derselbe Oracle-Software-Stack installiert und gepatcht sein wie auf dem Oracle-Quellserver. Für den Oracle-Benutzer .bash_profile sind $ORACLE_BASE und $ORACLE_HOME konfiguriert. Außerdem sollte die Variable $ORACLE_HOME mit der Einstellung des Quell-Oracle-Servers übereinstimmen. Wenn sich die Zieleinstellung ORACLE_HOME von der Konfiguration des Standby-Oracle-Servers unterscheidet, erstellen Sie einen symbolischen Link, um die Unterschiede zu umgehen. Es folgt ein Beispiel.
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
export ORACLE_BASE=/u01/app/oracle export GRID_HOME=/u01/app/oracle/product/19.0.0/grid export ORACLE_HOME=/u01/app/oracle/product/19.0.0/NTAP alias asm='export ORACLE_HOME=$GRID_HOME;export PATH=$PATH:$GRID_HOME/bin;export ORACLE_SID=+ASM'
Playbook-Ausführung
Details
Es gibt insgesamt zwei Playbooks zur Ausführung des Lebenszyklus des Oracle-Datenbankklons. Das Klonen oder Aktualisieren der Datenbank kann bei Bedarf ausgeführt oder als Crontab-Job geplant werden.
-
Installieren Sie die Voraussetzungen für den Ansible-Controller – nur einmal.
ansible-playbook -i hosts ansible_requirements.yml -
Erstellen und aktualisieren Sie die Klondatenbank bei Bedarf oder regelmäßig über Crontab mit einem Shell-Skript, um das Klon- oder Aktualisierungs-Playbook aufzurufen.
ansible-playbook -i oracle_clone_asm_anf.yml -u azureuser -e @vars/vars.yml0 */2 * * * /home/admin/na_oracle_clone_anf/oracle_clone_asm_anf.sh
Um zusätzliche Datenbanken zu klonen, erstellen Sie eine separate Datei „oracle_clone_n_asm_anf.yml“ und „oracle_clone_n_asm_anf.sh“. Konfigurieren Sie die Ansible-Zielhosts, die globale Datei vars.yml und die Datei hostname.yml im Verzeichnis host_vars entsprechend.
|
|
Die Ausführung des Toolkits wird in verschiedenen Phasen angehalten, um die Fertigstellung einer bestimmten Aufgabe zu ermöglichen. Beispielsweise wird eine zweiminütige Pause eingelegt, damit das Klonen der DB-Volumes abgeschlossen werden kann. Im Allgemeinen sollte die Standardeinstellung ausreichend sein, der Zeitpunkt muss jedoch möglicherweise an die jeweilige Situation oder Implementierung angepasst werden. |
Wo Sie weitere Informationen finden
Weitere Informationen zur Automatisierung der NetApp -Lösung finden Sie auf der folgenden Website"Automatisierung der NetApp -Lösung"