Implantación de la replicación del sistema de archivos (DBFS) de Oracle Database

Esta implantación consiste en copiar el contenido de la capa media en una carpeta de DBFS y confiar en Oracle Data Guard para replicarlo en el sitio secundario. El contenido de la capa media no reside directamente en DBFS, porque eso haría que la capa media dependiera de la infraestructura de DBFS (base de datos, bibliotecas FUSE, puntos de montaje, etc.). El montaje DBFS es solo una carpeta intermedia de almacenamiento provisional para almacenar una copia del contenido.

Cualquier replicación en espera implica dos pasos en este modelo: desde la carpeta de origen de la base de datos primaria hasta el montaje de DBFS intermedio y, a continuación, en la ubicación secundaria, desde el montaje de DBFS hasta la carpeta de destino de la base de datos en espera. Las copias intermedias se realizan mediante rsync. Como se trata de una copia rsync local y de baja latencia, algunos de los problemas que surgen en una operación de copia rsync remota se evitan con este modelo.

Note:

Este método no está soportado con Oracle Autonomous Database, que no permite conexiones DBFS.

Descripción de replica-mid-tier-dbfs.png a continuación

Descripción de la ilustración replica-mid-tier-dbfs.png

réplica-mid-tier-dbfs-oracle.zip

Las ventajas de implementar la réplica de nivel medio con DBFS son:

Este método aprovecha la solidez de la réplica de Oracle Data Guard.
El almacenamiento de nivel medio real puede permanecer montado en los nodos secundarios. No hay pasos adicionales para conectar o montar el almacenamiento en el secundario en cada operación de switchover o failover.

Las siguientes son consideraciones para implementar la réplica de nivel medio con DBFS:

Este método requiere Oracle Database con Oracle Data Guard.
Los hosts de nivel medio necesitan el cliente de Oracle Database para montar el DBFS.
El uso de DBFS para la replicación tiene implicaciones desde la perspectiva de la configuración, el almacenamiento de la base de datos y el ciclo de vida. Requiere una instalación del cliente de Oracle Database en los hosts de nivel medio, cierto mantenimiento de la base de datos (para limpiar, comprimir y reducir el almacenamiento de tablas) y un buen conocimiento del comportamiento de los puntos de montaje DBFS.
Los directorios DBFS solo se pueden montar si la base de datos está abierta. Cuando Oracle Data Guard no es un Active Data Guard, la base de datos en espera está en estado de montaje. Por lo tanto, para acceder al montaje de DBFS en la ubicación secundaria, debe convertir la base de datos en una instantánea en espera. Cuando se utiliza Active Data Guard, el sistema de archivos se puede montar para lecturas y no es necesario realizar la transición a una instantánea.
No se recomienda utilizar DBFS como solución de uso general para replicar todos los artefactos (especialmente los archivos de tiempo de ejecución) en la base de datos en espera. El uso de DBFS para replicar los binarios es excesivo. Sin embargo, este enfoque es adecuado para replicar algunos artefactos, como la configuración, cuando otros métodos, como la replicación de almacenamiento o rsync, no se ajustan a las necesidades del sistema.
Es responsabilidad del usuario crear los scripts personalizados para cada entorno y ejecutarlos periódicamente.
Es responsabilidad del usuario implementar una forma de revertir la dirección de la réplica.

Configurar replicación para sistema de archivos de base de datos

Esta implantación utiliza la tecnología rsync y sigue el modelo de peer a peer. En este modelo, la copia se realiza directamente entre los hosts pares de capa media. Cada nodo tiene conectividad SSH con su par y utiliza comandos rsync a través de SSH para replicar los artefactos de archivo de nivel medio principales.

Se necesita lo siguiente para implementar la réplica de nivel medio con DBFS:

Instalación de un cliente de Oracle Database en los hosts de nivel medio que realizan la copia, tanto en el principal como en el secundario.
Un sistema de archivos DBFS creado en la base de datos.
Un montaje de DBFS en los hosts de capa media que realizan las copias, tanto en el primario como en el secundario. Esto monta el sistema de archivos DBFS de la base de datos. Este sistema de archivos se puede montar en más de un host, ya que DBFS es un sistema de archivos que se puede compartir.
Scripts que copian los artefactos de archivo de nivel medio en el montaje de DBFS en el sitio principal.
Scripts que copian los artefactos de archivo de nivel medio del montaje de DBFS en las carpetas del sitio secundario. Según la implementación, este método puede requerir conectividad SQL*net entre los hosts de capa media y la base de datos remota para operaciones de base de datos, como conversiones de roles.
Una forma de gestionar la información específica del sitio, ya sea excluyendo esa información de la copia o actualizándola con la información adecuada después de la réplica.
Programe estos scripts para que se ejecuten de forma continua.
Un mecanismo para cambiar la dirección de la réplica después de una operación de switchover o failover.

Ejemplo 1: Uso de DBFS para replicar el dominio de Oracle WebLogic

Note:

El siguiente ejemplo se aplica a los Sistemas Oracle WebLogic. Puede utilizarlo como referencia para copiar otras carpetas del sistema de nivel medio mediante DBFS, pero en este ejemplo concreto se utiliza un script que replica la carpeta de dominio del administrador WebLogic en la secundaria mediante DBFS.

En este ejemplo se muestra cómo replicar la carpeta de dominio del host de administración WebLogic mediante DBFS. El contenido ubicado fuera de la carpeta de dominio, así como el contenido de otros hosts, no se incluye en este ejemplo. La carpeta de dominio no reside directamente en DBFS; el montaje de DBFS es solo una carpeta temporal intermedia para almacenar una copia de la carpeta de dominio.

En este ejemplo, se proporciona un script para realizar estas acciones, que se deben ejecutar periódicamente en las ubicaciones principal y en espera. Este script copia la carpeta de dominio de administración WebLogic, omitiendo algunos elementos como los archivos tmp, .lck, .state y tnsnames.ora. El procedimiento consiste en lo siguiente:

Cuando el script se ejecuta en el host de administración WebLogic del sitio principal, el script copia la carpeta de dominio WebLogic en la carpeta DBFS.
Los archivos copiados en el DBFS, a medida que se almacenan en la base de datos, se transfieren automáticamente a la base de datos en espera mediante Oracle Data Guard.
Cuando la secuencia de comandos se ejecuta en el host de administración WebLogic del sitio secundario:
- La secuencia de comandos convierte la base de datos en espera en una instantánea en espera.
- A continuación, monta el sistema de archivos DBFS desde la base de datos en espera.
- La carpeta de dominio replicado ahora está disponible en esta carpeta DBFS. El script lo copia desde el montaje DBFS a la carpeta de dominio real.
- Por último, la secuencia de comandos vuelve a convertir la base de datos en espera en una base de datos física en espera.
En caso de un cambio de rol, la secuencia de comandos adapta automáticamente la ejecución al nuevo rol. Recopila el rol real del sitio comprobando el rol de la base de datos.

Esta secuencia de comandos solo replica la carpeta de dominio del host de administración WebLogic. El contenido de la carpeta DOMAIN_HOME/config se copia automáticamente en todos los demás nodos que forman parte del dominio WebLogic cuando se inician los servidores gestionados. Los archivos fuera de esta carpeta y los archivos ubicados en otros hosts no se replican y se deben sincronizar por separado.

Para las operaciones de despliegue de la aplicación, utilice la opción de despliegue Cargar archivos en la consola de administración WebLogic. De esta forma, los archivos desplegados se colocan en el directorio de carga del servidor de administración ($DOMAIN_HOME/servers/admin_server_name/upload) y el script de réplica de configuración los sincroniza con la ubicación en espera.

En este ejemplo, se proporciona otra secuencia de comandos para instalar el cliente de base de datos y configurar un montaje de DBFS en los hosts de capa media. La imagen es un ejemplo de un sistema Oracle WebLogic Server for OCI con replicación de DBFS.

A continuación se describe wls-dbfs-replication.png

Descripción de la ilustración wls-dbfs-replication.png

wls-dbfs-replication-oracle.zip

Realice lo siguiente para utilizar el método DBFS para replicar el dominio WebLogic:

Permitir la conectividad SQL*net entre los hosts de administración y las bases de datos remotas.
Oracle recomienda utilizar el intercambio de tráfico remoto con el gateway de direccionamiento dinámico. El script necesita esta conectividad para realizar operaciones de base de datos, como conversiones de roles. Cuando el script se ejecuta en la ubicación con rol en espera, convierte la base de datos en espera en una base de datos de instantánea en espera para montar el montaje de DBFS.
Descargue los scripts.
En este documento, se proporcionan scripts para configurar el montaje de DBFS y automatizar la replicación.
1. Vaya al repositorio de Oracle MAA en GitHub. Consulte la sección Explorar más de este manual.
2. Descargue todos los scripts en el directorio app_dr_common.
3. Descargue todos los scripts en el directorio wls_mp_dr.
4. Copiarlos en los hosts de administración principal y secundario, en una ubicación que no se replica.
5. Los scripts realizan llamadas entre sí. Copie los scripts de ambos directorios y colóquelos en la misma carpeta. Asegúrese de que el usuario oracle tiene permiso de ejecución.

Configure el montaje de DBFS en hosts de administración principales y secundarios.

Note:

Si ya tiene un montaje de DBFS, puede omitir este paso. Por ejemplo, algunas pilas de SOA Marketplace incluyen un montaje de DBFS listo para usar.

Configure el montaje de DBFS en los hosts de administración WebLogic principales y secundarios. Necesita el cliente de base de datos y algunos paquetes del sistema operativo en el host de administración WebLogic. Siga estos pasos en cada host de administración:

Descargue el cliente de base de datos desde la entrega electrónica y cárguelo en el host de nivel medio (no lo instale aún). Busque Cliente de Oracle Database y seleccione solo el cliente de base de datos. Haga clic en Continuar y, a continuación, seleccione la versión del instalador (no la imagen principal).

Note:
Asegúrese de descargar la versión del instalador, no la instalación basada en imágenes. Se recomienda utilizar la versión más reciente.

Por ejemplo, descargue el archivo 982064-01.zip para el cliente de Oracle Database 19.3.0.0.0 para Linux x86-64, 1.1 GB y cárguelo en /u01/install/V982064-01.zip en todos los hosts de capa media.
No lo instale todavía.
Busque el script dbfs_dr_setup_root.sh en la carpeta app_dr_common.
Este script realiza las tareas necesarias para que el montaje DBFS esté listo en el host. Instala el cliente de base de datos y los paquetes del sistema operativo necesarios, configura el usuario y el esquema de DBFS en la base de datos, monta el sistema de archivos DBFS y crea un cron, por lo que el sistema de archivos DBFS se monta en el inicio del host.

Ejecute el script como usuario root.

La sintaxis es la siguiente:

./dbfs_dr_setup_root.sh  local_db_scan_name db_port  local_PDB_service pdb_sys_password path_to_dbclient_installer

Como parámetros de entrada, proporcione los datos de conexión utilizados para conectarse a la base de datos local utilizada por WLS: proporcione los datos de conexión de PDB primaria cuando los ejecute en el host de administración de la ubicación primaria y proporcione los datos de conexión de PDB secundaria cuando los ejecute en el host de administración secundario.

Note:

La base de datos en espera debe estar en modo de instantánea en espera para ejecutar este script en el host de administración secundario.

En el siguiente ejemplo, se ejecuta el host de administración principal de nivel medio. Debe ser una sola línea y debe proporcionar los valores de PDB principales y la contraseña:

./dbfs_dr_setup_root.sh  drdba-scan.wlsdrvcnlon1ad2.wlsdrvcnlon1.oraclevcn.com 1521 mypdbservice.example.com  mypassword   /u01/install/V982064-01.zip

En el siguiente ejemplo, se ejecuta el host de administración de nivel medio secundario. Debe ser una sola línea y debe proporcionar los valores de PDB principales y la contraseña:

./dbfs_dr_setup_root.sh  drdbb-scan.wlsdrvcnfra1ad2.wlsdrvcnfra1.oraclevcn.com 1521 mypdbservice.example.com  mypassword   /u01/install/V982064-01.zip

Como resultado de la ejecución de este script, obtendrá lo siguiente:

Artefacto	Valor	Descripción
Directorio raíz de cliente de base de datos	`/u01/app/oracle/client`	La secuencia de comandos instala el software del cliente de base de datos en el host. También utiliza `yum` para instalar los paquetes necesarios.
Usuario de Base de Datos	Nombre: `dbfsuser` Contraseña: igual que `sys`	Usuario de la base de datos PDB para DBFS.
Tablespace DBFS	`tbsdbfs`	Tablespace en la PDB para el montaje de DBFS.
Carpeta DBFS	`dbfsdir`	La carpeta DBFS del tablespace.
Una carpeta en el host de capa media	`DOMAIN_HOME/dbfs`	Contiene la cartera que almacena el usuario, la contraseña y otros artefactos (`tnsnames.ora`, `sqlnet.ora`) necesarios para que el cliente de base de datos monte el DBFS en el host.
Script en el host de nivel medio	`DOMAIN_HOME/dbfs/dbfsMount.sh`	Script para montar el sistema de archivos DBFS en el host. Esta secuencia de comandos se agrega a `cron` al reiniciar, por lo que se ejecuta cuando se reinicia la máquina.
Punto de montaje en el host de capa media	`/u02/data/dbfs_root`	El sistema de archivos DBFS se monta en el punto de montaje `/u02/data/dbfs_root` como carpeta `dbfsdir`.

Puede volver a ejecutar el archivo de comandos, pero recibirá advertencias porque ya se han creado algunas cosas (usuario de base de datos, tablespace, etc.). Puede ignorar estos mensajes.

Verifique que el montaje DBFS esté presente en el host de administración de nivel medio.
```
[root@ prefix-wls-1]# df -h | grep dbfs
dbfs-@PDB1:/     32G  248K   32G   1% /u02/data/dbfs_root
[root@ prefix-wls-1]# ls /u02/data/dbfs_root
dbfsdir
```
Este sistema de archivos DBFS se utiliza como un sistema de archivos de asistencia para almacenar una copia de la configuración de dominio del sitio principal.

Prepare el script de réplica.
En este documento se proporciona un script de referencia para esta implementación, el script config_replica.sh.
1. En el host de administración de Oracle WebLogic principal, abra el script config_replica.sh. Edite las secciones de parámetros personalizables.
  Asegúrese de proporcionar las variables adecuadas para la principal. En la propiedad DR_METHOD, utilice DBFS.
2. Haga lo mismo en el host secundario de administración de Oracle WebLogic. Asegúrese de proporcionar las variables adecuadas para el secundario.
Ejecute el script de replicación.
1. Como usuario oracle, ejecute el script config_replica.sh en el host de administración de Oracle WebLogic principal.
  El script verificará el rol de sitio actual y copiará la configuración de dominio del dominio principal de Oracle WebLogic Server en el montaje de DBFS.
2. Supervise la ejecución y compruebe si hay errores.
3. Una vez finalizado, ejecute la secuencia de comandos config_replica.sh en el host Oracle WebLogic Administration Server del sitio secundario.
  Asegúrese de utilizar los valores adecuados en los parámetros personalizados. El script verificará el rol de base de datos. Puesto que es la base de datos en espera, copiará la configuración del dominio del sistema de archivos temporal secundario en el dominio secundario de Oracle WebLogic Server.
Note:
Este script siempre se debe ejecutar tanto en la base de datos principal como en la base de datos en espera para realizar una replicación completa: primero en la base de datos principal para copiar el dominio en la carpeta DBFS y, a continuación, en la base de datos en espera para copiar el dominio de DBFS en la carpeta de dominio. La frecuencia depende de la frecuencia con la que se realizan los cambios de configuración en el dominio de Oracle WebLogic Server.

Validar replicación para sistema de archivos de base de datos

En una operación de switchover o failover, la información replicada debe estar disponible y utilizarse en la ubicación en espera antes de que se inicien los procesos. Esto también es necesario al validar el sistema secundario (abriendo la base de datos en espera en modo de instantánea).

En esta implantación, el almacenamiento siempre está disponible en la base de datos en espera; no es necesario asociar ni montar ningún volumen. La única acción que necesita es asegurarse de que contiene la última versión del contenido.

Realice lo siguiente para utilizar el contenido replicado en espera:

Ejecute una replicación.
Ejecute los scripts de réplica para que el contenido más reciente esté disponible en el sistema secundario.
Desactive las replicaciones programadas.
Cuando termine la última réplica, desactive cualquier secuencia de comandos de réplica. De lo contrario, puede interferir con el procedimiento de switchover, failover o validación. Lo volverá a activar después de la operación, en la dirección adecuada.

Replicación continua para el sistema de archivos de base de datos

Ejecute el script de replicación periódicamente para mantener el dominio secundario sincronizado con el principal.

Siga estas recomendaciones al utilizar rsync desde los hosts de nivel medio:

Utilice crontab del sistema operativo u otra herramienta de programación para programar replicación. Debe permitir que las secuencias de comandos completen la replicación. De lo contrario, los trabajos posteriores pueden superponerse.
Mantenga los procesos de nivel medio detenidos en la ubicación en espera. Si los servidores están activos en la ubicación en espera mientras se replican los cambios, estos se aplicarán la próxima vez que se inicien. Inícelos solo al validar la ubicación en espera o durante el procedimiento de switchover o failover.
Mantenga la información específica de cada sitio y manténgala actualizada. Por ejemplo, omita tnsnames.ora de la copia para que cada sistema tenga sus detalles de conectividad. Si realiza un cambio en tnsnames.ora en el nodo principal (por ejemplo, agregando un nuevo alias), actualice manualmente tnsnames.ora en el secundario según corresponda.
Después de una operación de switchover o failover, invierta la dirección de la réplica. Esto depende de la implementación específica. Los scripts pueden utilizar una comprobación dinámica para identificar quién es el sitio activo o puede realizar un cambio manual después de una operación de switchover o failover (por ejemplo, desactivar y activar los scripts adecuados). En el ejemplo proporcionado, el script config_replica.sh adapta automáticamente la ejecución al rol real del sitio comprobando el rol de la base de datos local.