Ciclo de vida automatizado de clones de Oracle en ANF con ASM
Sugerir cambios
PDF
Allen Cao, Niyaz Mohamed, NetApp
La solución proporciona un kit de herramientas de automatización basado en Ansible para configurar, clonar y actualizar bases de datos clonadas de Oracle desde la base de datos física en espera de Oracle Data Guard alojada en la nube de Azure en el almacenamiento de Azure NetApp Files con configuración ASM.
Objetivo
El aprovechamiento de los clones de la base de datos Oracle física en espera en la configuración de Oracle Data Guard para otros casos de uso cumple múltiples propósitos. Proporciona una copia grabable de la base de datos de producción para fines de desarrollo o UAT. De esta forma, se pueden eliminar los costosos costos de licencia de Active Data Guard si se acepta una breve demora (10-15 minutos) en la generación de informes. Ahorra en costes de almacenamiento, especialmente cuando el clon delgado es una opción. Este kit de herramientas de automatización basado en Ansible permite a los usuarios configurar, clonar y actualizar bases de datos Oracle clonadas según los cronogramas del usuario para una gestión optimizada del ciclo de vida. El kit de herramientas se aplica a las bases de datos de Oracle implementadas en la nube pública de Azure mediante el almacenamiento de Azure NetApp Files y la base de datos de Oracle configurada en una configuración de Data Guard.
Esta solución aborda los siguientes casos de uso:
-
Configurar los archivos de configuración de la clonación de la base de datos en espera de Oracle para la automatización de Ansible.
-
Cree o actualice una base de datos Oracle clonada desde el modo en espera de Data Guard usando el libro de jugadas de Ansible según un cronograma definido por el usuario.
Audiencia
Esta solución está destinada a las siguientes personas:
-
Un DBA que administra bases de datos de Oracle en la nube de Azure.
-
Un administrador de almacenamiento que administra el almacenamiento de Azure NetApp Files .
-
Un propietario de una aplicación a quien le gusta clonar bases de datos Oracle desde el modo de espera de Data Guard para otros casos de uso.
Licencia
Al acceder, descargar, instalar o utilizar el contenido de este repositorio de GitHub, usted acepta los términos de la Licencia establecidos en"Archivo de licencia" .
|
Existen ciertas restricciones en torno a la producción y/o intercambio de cualquier trabajo derivado del contenido de este repositorio de GitHub. Asegúrese de leer los términos de la Licencia antes de utilizar el contenido. Si no está de acuerdo con todos los términos, no acceda, descargue ni utilice el contenido de este repositorio. |
Implementación de la solución
Requisitos previos para la implementación
Details
La implementación requiere los siguientes requisitos previos.
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
|
|
Para simplificar, el servidor Oracle de destino clonado debe configurarse de manera idéntica al servidor Oracle en espera, como la pila de software de Oracle y el diseño de directorio para Oracle Home, etc. |
Descargar el kit de herramientas
Details
git clone https://bitbucket.ngage.netapp.com/scm/ns-bb/na_oracle_clone_anf.git|
|
En este momento, solo los usuarios internos de NetApp con acceso a Bitbucket pueden acceder al kit de herramientas. Los usuarios externos interesados deben solicitar acceso a su equipo de cuentas o comunicarse con el equipo de ingeniería de soluciones de NetApp . |
Configuración de archivos de hosts de origen y destino de Ansible
Details
El kit de herramientas incluye un archivo de hosts que define los hosts Oracle de origen y destino en los que se ejecuta el playbook de Ansible. Generalmente, incluye el host de base de datos en espera en la configuración de Data Guard y el host clon de Oracle de destino. A continuación se muestra un archivo de ejemplo. Una entrada de host incluye la dirección IP del host de destino, así como la clave ssh para que el usuario acceda al host para ejecutar el comando de clonación o actualización. El almacenamiento de Azure NetApp Files se configura a través de API. Por lo tanto, la conexión ANF se realiza a través del host local mediante el protocolo HTTP.
[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
Configuración de variables globales
Details
A continuación se muestra un ejemplo de un archivo de variable global típico vars.yml que incluye variables que se aplican a nivel global.
###################################################################### ###### 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"
Configuración de variables del host
Details
Las variables de host se definen en el directorio host_vars llamado {{ host_name }}.yml y se aplica solo al host en particular. Para esta solución, solo se configura el archivo de parámetros del host de la base de datos del clon de destino. Los parámetros de la base de datos en espera de Oracle se configuran en el archivo de variables globales. A continuación se muestra un ejemplo del archivo de variable de host de base de datos clonada de Oracle de destino orac.yml que muestra una configuración típica.
# 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
Configuración del servidor Oracle de destino de clonación adicional
Details
El servidor Oracle de destino clonado debe tener la misma pila de software Oracle que el servidor Oracle de origen instalado y parcheado. El usuario de Oracle .bash_profile tiene $ORACLE_BASE y $ORACLE_HOME configurados. Además, la variable $ORACLE_HOME debe coincidir con la configuración del servidor Oracle de origen. Si la configuración de ORACLE_HOME de destino es diferente de la configuración del servidor Oracle en espera, cree un enlace simbólico para solucionar las diferencias. A continuación se muestra un ejemplo.
# .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'
Ejecución del libro de jugadas
Details
Hay un total de dos libros de estrategias para ejecutar el ciclo de vida de la clonación de la base de datos de Oracle. La clonación o actualización de la base de datos se puede ejecutar a pedido o programar como un trabajo crontab.
-
Instale los requisitos previos del controlador Ansible (solo una vez).
ansible-playbook -i hosts ansible_requirements.yml -
Cree y actualice la base de datos clonada a pedido o periódicamente desde crontab con un script de shell para llamar al clon o actualizar el manual de estrategias.
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
Para clonar bases de datos adicionales, cree un oracle_clone_n_asm_anf.yml y un oracle_clone_n_asm_anf.sh separados. Configure los hosts de destino de Ansible, el archivo vars.yml global y el archivo hostname.yml en el directorio host_vars según corresponda.
|
|
La ejecución del conjunto de herramientas en varias etapas se detiene para permitir que se complete una tarea particular. Por ejemplo, se detiene durante dos minutos para permitir que se complete la clonación de los volúmenes de la base de datos. En general, el valor predeterminado debería ser suficiente, pero es posible que sea necesario ajustar el tiempo para una situación o implementación particular. |
Dónde encontrar información adicional
Para obtener más información sobre la automatización de soluciones de NetApp , consulte el siguiente sitio web"Automatización de soluciones de NetApp "