Replicación de Filesystems ACFS con Infraestructura Grid 12c

Por Francisco Riccio
Publicado en Mayo 2015

Introducción
Hoy en día disponemos de un gran número de soluciones que nos permiten diseñar esquemas de contingencia para nuestras soluciones de negocio. Una alternativa actual e interesante es la que nos ofrece Oracle Infraestructura Grid, permitiéndonos replicar nuestros filesystems desde un servidor a otro (principal/secundario), donde cada filesystem del servidor principal almacena distintos archivos críticos que son parte de nuestras aplicaciones y requerimos incluirlas dentro una solución de contingencia en un marco integral.

Asimismo es posible replicar ciertos archivos de un filesystem donde se les ha asignado un atributo personalizado para dar un mayor control de lo que se desea proteger ante una incidencia.

Esta nueva tecnología reemplazaría soluciones antiguas que antes realizábamos vía comandos de sistema operativo tales como: SCP para ambientes Unix/Linux y Robocopy para ambientes Windows de una manera más consistente, robusta y con mayores opciones de administración como veremos más adelante.

Esta nueva opción se encuentra disponible para los siguientes sistemas operativos:

Tabla 1

Adicionalmente Infraestructura Grid 12.1 nos permite configurar auditoria, seguridad y encriptación sobre filesystems que han sido configurados con la opción de replicación, dando mejores opciones que teníamos sobre la versión 11.2.0.2.

Implementación
En esta implementación se indicarán todos los pasos requeridos para configurar una replicación de un filesystem ACFS.
El ambiente a implementar está configurado sobre 2 servidores con sistema operativo Oracle Linux 5 Update 10 x64 bits y Oracle Infraestructura Grid 12.1.0.2.
Inventario

Tabla 2

Requisitos:

• Ambos servidores deben mantener la misma arquitectura de hardware y versión de sistema operativo. Adicionalmente deben tener instalado el componente de Clusterware y no Oracle Restart.
• El ORACLE_HOME de la Infraestructura Grid debe ambos servidores deben contar con un password file.
• El servidor que llevará el filesystem ACFS con rol secundario deberá montarlo en un solo nodo en caso de tener múltiples nodos en el clúster.
• Los filesystem ACFS a replicar deberán contar con un mínimo 4 GB de espacio libre adicionalmente el filesystem ACFS secundario debe estar vacío.
• El diskgroup que monta el volumen ADVM, debe estar configurado con la compatibilidad de asm y advm en las versiones indicadas en la Tabla 1.

Se adjunta un ejemplo de como realizar la validación de este punto basado en el entorno presentado:

Figura 1

Paso 1
En esta configuración se creará un usuario en ambas instancias +ASM el cual será utilizado para la replicación. El usuario que será creado deberá tener los privilegios: SYSASM y SYSDBA.

Figura 2

La creación del usuario debe realizarse en ambas instancias ASM.

Paso 2
Debemos crear un nuevo servicio en ambos servidores para conectarnos a las instancias +ASM de manera remota.
Por cada filesystem ACFS a replica debe existir un único servicio y el nombre debe ser diferente a +ASM.

Servidor: srvig1.riccio.com Figura 3

Servidor: srvig2.riccio.com

Paso 3
En cada servidor se deberá crear una entrada en el archivo tnsnames.ora del ORACLE HOME de Infraestructura Grid. Esta entrada deberá permitir generar conexiones remotas a las instancias +ASM utilizando los servicios creados del paso 2.

Servidor: srvig1.riccio.com Figura 4

Servidor: srvig2.riccio.com Figura 5

Paso 4
Se procederá a configurar la replicación primero en el servidor que tendrá el filesystem ACFS de rol secundario, en nuestro caso es el servidor srvig2.riccio.com.

Se presenta la sintaxis del comando que debe ser ejecutado con el usuario root:
/sbin/acfsutil repl init standby -p <user>/<password>@<ALIAS_CONEXION_ROL_PRINCIPAL_TNSNAMES> -c <SERVICIO_ROL_SECUNDARIO> <NOMBRE_FS>

Figura 6

Nota: Si el comando falla, el filesystem ACFS debe ser recreado y montado antes de volver a ejecutarse el comando.
Validamos si todo está conforme con el comando: /sbin/acfsutil repl info -c <NOMBRE_FS>

Figura 7

También podemos validar los background process responsables de la replicación en el filesystem ACFS.

Figura 8

Paso 5
Configuramos la replicación ahora en el filesystem ACFS con rol primario, en nuestro caso en el servidor srvig1.riccio.com.

Se presenta la sintaxis del comando que debe ser ejecutado con el usuario root:
/sbin/acfsutil repl init primary -s <user>/<password>@<ALIAS_CONEXION_ROL_SECUNDARIO_TNSNAMES> -c <SERVICIO_ROL_PRINCIPAL> <NOMBRE_FS>

Figura 9

Nota: El comando previamente mencionado acepta el parámetro -m que nos permite indicar el nombre del filesystem ACFS con rol secundario en caso se llame diferente al del primario. También nos permite comprimir los cambios registrados con la opción -z on.

Validamos si todo fue correcto con el comando: /sbin/acfsutil repl info -c  -v <NOMBRE_FS>

Figura 10

También podemos validar los background process responsables de la replicación en el filesystem ACFS principal.

Figura 11

Asimismo validamos que la información de ambos filesystems ACFS están iguales después de la inicialización.

Figura 12

El filesystem ACFS secundario no aceptará modificaciones mientras esté replicando como podemos apreciar en el siguiente ejemplo:

Figura 13

Es importante mencionar que la replicación se realizará en 2 partes:

• Primero inicia una copia de la estructura de todas las carpetas y sub-carpetas del filesystem ACFS principal al destino.
• Segundo inicia la copia de archivos del filesystem ACFS principal al destino y mientras se realiza la copia no se ejecutarán cambios en el origen. Terminado la copia de los archivos se procederá a llevar un control de los futuros cambios a través de los archivos rlogs los cuales son similar a los archivos archived logs en un Oracle Standby Database.

Los archivos rlogs se almacenan en el directorio .ACFS/repl y son eliminados automáticamente cuando son replicados en el destino. Estos archivos aparecerán en el origen y en el destino.

Figura 14

La carpeta ready tendrá los archivos rlogs que aún no han sido procesados en el filesystem ACFS secundario.

Paso 6
Si deseamos detener la réplica, podemos ejecutar el siguiente comando:
/sbin/acfsutil repl pause <NOMBRE_FS>

Si el comando es ejecutado en el filesystem ACFS con rol:

• Secundario, recibirá los archivos rlogs generados en el origen pero no los aplicará ni tampoco permitirá que un usuario pueda crear archivos o directorios manualmente.
• Principal, generará los rlogs pero no los propagará al filesystem ACFS secundario.

Asimismo podemos reactivar la réplica utilizando el comando: /sbin/acfsutil repl resume <NOMBRE_FS>

Figura 15

Si deseamos terminar la replicación debemos ejecutar el siguiente comando:
/sbin/acfsutil repl terminate primary|standby <NOMBRE_FS>

Primero debe ser ejecutado en el filesystem ACFS principal y luego en el secundario como recomendación.

Servidor: srvig1.riccio.com Figura 16

Servidor: srvig2.riccio.com Figura 17

En caso necesitemos hacer una re sincronización de todo el filesystem ACFS podemos ejecutar el siguiente comando:
/sbin/acfsutil repl sync apply <NOMBRE_FS>

Figura 18

Este comando no permitirá nuevos cambios en el filesystem ACFS principal mientras realiza la sincronización.

Paso 7
La opción de replicación también nos permite replicar ciertos directorios o archivos y no todo el filesystem.

Para  implementarlo debemos ejecutar el siguiente comando:
/sbin/acfsutil tag set <nombre_tag> <NOMBRE_FS>

Figura 19

La opción -r indica una operación recursiva sobre el directorio.
Posterior a este comando debemos iniciar la réplica en el filesystem ACFS secundario y luego en el principal indicando los tags que se tomarán en cuenta para la replicación.

Ejemplo:

Figura 20

En este caso hemos configurado para que la réplica considere al tag reporte previamente creado.

Nota : Basado en esta configuración, si existen nuevos archivos en el directorio /data/rep y la extensión es txt no serán replicados porque los nuevos archivos no heredarán el tag reporte, pero manualmente podemos configurarlos en línea y automáticamente también serán replicados.

Figura 21

En el caso el tag hubiera sido definido de la siguiente manera:
/sbin/acfsutil tag set reporte -r /data/rep

Nuevos archivos o directorios si hubieran sido replicados de manera automática.

En ambos casos todos los archivos del filesystem ya no serán replicados, sino se regirá por los filtros realizados con el parámetro tag, pero si es importante hacer notar que todos los directorios que se creen dentro del filesystem y están excluidos de los filtros serán replicados pero sin ningún archivo.

Para remover un tag utilizamos el siguiente archivo: /sbin/acfsutil tag unset <nombre_tag> -r <filtro>

Ejemplo:

Figura 22

Paso 8
Si deseamos obtener estadísticas del volumen de datos generados podemos ejecutar el siguiente comando:
/sbin/acfsutil info fs -s <NOMBRE_FS>

Figura 23

En este ejemplo, el número 5 indica que la información se desea visualizar en intervalos de 5 segundos.

Paso 9
En caso de errores durante la etapa de configuración u operación podemos revisar los logs que se encuentran en el directorio:
$ORACLE_HOME/log/<hostname>/acfs

Figura 24

También si deseamos activar un mayor nivel de trace sobre la replicación ejecutamos el siguiente comando:
/sbin/acfsutil repl trace # <NOMBRE_FS>

El nivel de trace por defecto es 2 y sus valores van de 0 a 6.

Conclusión
En este material hemos realizado satisfactoriamente una implementación de replicación de Filesystem ACFS, pero es importante resaltar algunas consideraciones que siempre debemos tener presente para asegurar el éxito en la operación.

• Mantener siempre 4 GB libres en cada filesystem replicado tanto en el servidor principal como en el secundario. Si el filesystem logra tener menos de 2 GB, Infraestructura Grid intentará  terminar la replicación.
• La réplica de filesystem se realiza utilizando la red LAN, por lo cual es importante que la red no mantenga una latencia elevada.

Asimismo es importante tener presente que un servidor puede tener configurado un filesystem ACFS con el rol principal pero además podría  tener otro con el rol secundario, es decir, un servidor no necesariamente debe tener todos sus filesystems ACFS con el rol principal o secundario de manera exclusiva.

Teniendo en cuenta las consideraciones previamente mencionadas, podríamos sentirnos seguros que la replicación siempre funcionará y nos ayudaría a complementar nuestra estrategia de continuidad de negocio.

Publicado por Ing. Francisco Riccio. Es un IT Architect en IBM Perú e instructor de cursos oficiales de certificación Oracle. Está reconocido por Oracle como un Oracle ACE y certificado en productos de Oracle Application & Base de Datos.

Este artículo ha sido revisado por el equipo de productos Oracle y se encuentra en cumplimiento de las normas y prácticas para el uso de los productos Oracle.