Alta disponibilidad Oracle para Bases de Datos

Alta disponibilidad Oracle para Bases de Datos

Neuronet implementa todas las arquitecturas de alta disponibilidad Oracle, denominada  MAA (Maximum Availability Architecture),  proveyendo de esta forma de una protección superior y disponibilidad minimizando o eliminando los downtime’s planeados y no planeados.

racRAC (Real Application Clusters)

Oracle RAC es una opción que en Oracle Standard Edition viene incluida en el licenciamiento básico y que le permite a varios servidores  trabajar  en forma concurrente sobre una misma base de datos (que se encuentra en un Storage), incrementando escabilidad, rendimiento y tolerancia a las fallas (alta disponibilidad). Esto permite bajar los costos de operación : RAC le permite utilizar un cluster de servidores de bajo costo (por ejemplo equipos con procesadores INTEL y sistema operativo Linux) en vez de un equipo con procesadores de Multi Procesamiento Simétrico (SMP) y sistema operativo propietario que son de mucho mayor costo. Incluso se puede armar un RAC con 3 máquinas de bajo costos donde dos máquinas juegan el rol de nodos del RAC y la tercera juega el rol de Storage accesado con protocolo iSCSI. NEURONET mostró en el último Oracle Day en forma exitosa la operación de esta última configuración, derribando el mito de que RAC es una arquitectura cara y para empresas muy grandes. RAC es una opción real que tiene cualquier empresa que maneje información de misión crítica para su negocio.

NEURONET posee experiencia en la implementación de configuraciones más sofistacada que utilizan RAC como es el caso de RAC extendido donde parte de los nodos del RAC se encuentran en un sitio y el resto se encuentra en un segundo sitio. En este caso los storage están distribuidos en los dos site, normalmente unidos por fibra oscura, canal que permite una alta tasa de transferencia (> 10 Gbps) entre los sitios para la replicación de la información  a nivel de los discos.

 

Alta disponibilidad: Arquitecura de replicación Oracle con Oracle RAC. Cluster Activo-Activo

 Base de Datos Standby (manual)

Una base de datos Standby es una configuración de alta disponibilidad y contingencia relativa que respalda el nodo de producción primario de una instalación Oracle. En el caso de Bases de Datos Standard Edition este proceso se realiza manualmente mediante el modo de recuperación manual (manual recovery mode) , ya que la versión de Oracle Estándar no soporta modo de recuperación administrado (managed recovery mode), la cual realiza todo el proceso automáticamente a través de Oracle Net.

Este proceso, manual recovery mode, se puede resumir en la siguiente figura:

standby_database
Alta disponibilidad Oracle: Arquitecura de replicación Oracle con Standby Database

En la figura se aprecia lo siguiente:
1.- Las transacciones en el nodo primario son registradas en los archivos de redolog online de la base de datos primaria (Nodo primario).
2.- El proceso de archive en el nodo primario copia cada archive redolog que se llene a un directorio en que se acumulan los archivos de archive redolog  históricos.
3.- Los archivos de archive redo log  históricos son copiados mediante procedimientos programados externamente (en principio manuales) hacia el directorio apropiado en el nodo Standby. Este proceso se denomina Log Shipping.
4.- Mediante un procedimiento manual estos archivos de archive redo log son aplicados en la base de datos Standby (Manual Standby Recovery). Con esto termina el ciclo de reproducción de las transacciones entre el nodo de producción y el nodo de respaldo. Este proceso se repite continuamente hasta que suceda una contingencia que obligue a activar la base de datos Standby para dejarla disponible como una alternativa de servicio.

El diagrama anterior muestra el proceso en régimen permanente, para que este proceso se eche a andar es necesario realizar una primera recuperación de la base de datos del nodo primario con un respaldo consistente. Una vez realizada esta tarea la recuperación de datos se realiza de manera incremental con los archivo de archive redolog históricos traspasados en el proceso de Log Shipping.

Una base de datos Standby tiene como propósitos principales los siguientes:

•    Protección ante desastres.
•    Protección en caso de corrupción de los datos.
•    Eventualmente como una base de datos de consulta (no  en este caso, solo con Oracle Dataguard)
Si bien esta alternativa es económica, se corre el riesgo de pérdida de datos en el caso de que una falla no permita acceder a las transacciones que en el nodo primario se encuentran en los online redolog y que no alcanzaron a ser archivadas en un archived redolog y luego transmitida al nodo standby. Cuando esta última situación no es tolerable por los SLA de la organziación, entonces se debe recurrir a Oracle Dataguard.


data_guard Oracle Data Guard

Oracle Data Guard es una facilidad de Alta Disponibilidad que se encuentra disponible en la versión Oracle Database Enterprise Edition y que pemite configurar uno o más ambientes de replicación que sirvan como contingencia en caso que el servidor de producción (servidor primario) de la configuración pierda su capacidad de servicio. La configuración de Oracle Dataguard se puede hacer de acuerdo a los objetivos que se tengan: MAXIMA DISPONIBILIDAD, MAXIMA PROTECCION, MAXIMO DESEMPEÑO. Cada una de estas opciones tiene ventajas y desventajas que deben ser pesadas a la hora de seleccionar la configuración más adecuada para un negocio específico. Oracle dataguard se puede administrar desde la consola Grid Control de Oracle o también desde las consolas de sqlplus o el Oracle Dataguard Broker.

data_guard_explanation
Alta disponibilidad Oracle: Arquitecura de replicación Oracle con Oracle RAC. Oracle Dataguard

La figura muestra la arquitectura de la solución Oracle Dataguard. En ella se observan dos servidores de base de datos: un servidor primario o de producción y un servidor standby o de contingencia. Basicamente Oracle Dataguard posee una serie de procesos que se encargan de trasladar cada uno de las transacciones que ocurre en el servidor primario para que se replique (redo apply) en el servidor standby. Como las transacciones se van registrando en los archivos de redolog, las entradas de estos archivos de bitácora de transacciones se van transportando y reaplicando en los archivos de redolog standby y estos a su vez se aplican a la base de datos standby por medio de un proceso especial para este fin.

Lo interesante que Oracle Dataguard permite invertir los roles de las base de datos, (switchover) esto es, la base de datos standby puede quedar como productiva y la productiva como standby,  y luego repetir nuevamente el cambio de roles para llegar a la configuración original y todo esto con un mínimo tiempo de pérdida de servicio. Esto es muy útil cuando se requiere hacer mantenciones preventivas de la infraestructura de servidores, parchado de software, o cualquier otra mantención al sitio. Oracle dataguard permite administrar los roles anteriormente descritos. Existens dos tipos de roles de transición: SWITCHOVER y FAILOVER. El rol de SWITCHOVER que fue mencionado permite la inversión de roles primary –> standby y viceversa. La gracia es que a diferencia de una base de datos standby que tambien permite hacer en forma manual un switchover esto se hace sin la necesidad de recrear las bases de datos, por lo tanto es mucho más rápida la operación. El otro rol  de transición es el rol de FAILOVER que se puede ejecutar en forma manual o automática. En un FAILOVER la base de datos standby queda como primaria cuando se ha perdido la base de datos primaria (imaginemos una pérdida de disco que no permite seguir operando la base de datos). Una vez que se ha corregido el problema la base de datos primaria que falló rapidamente se puede dejar como una base de datos standby  de la nueva base de datos primaria, usando la capacidad de FLASHBACK DATABASE que tiene oracle. Esto último reduce dramaticamente el esfuerzo de recrear la configuración de protección de Oracle Dataguard.

Felipe Manríquez  –  Ingeniero Consultor – [email protected]

Referencias:

Blog de Kai Yu

RAC: Frequently Asked Questions (Doc ID 220970.1)

https://davidburnham.wordpress.com/2010/10/19/extended-distance-rac-test-cluster/

Oracle RAC and Oracle RAC One Node on Extended Distance (Stretched) Clusters