Para tener un
ambiente altamente disponible debemos considerar la construcción de un DRS
(Disaster Recovery Site) el cual nos proporciona ventajas como, preservar cada
una de las transacciones que se realizan en nuestro ambiente de producción, protegiéndonos
ante desastres naturales, virus, fallas de hardware, errores de software, o
errores de usuarios; facilidad al realizar una recuperación desde el sitio de
producción o desde el sitio de contingencia; facilidad para realizar
mantenimientos de ambientes completos con ayuda de un switchover.
Idealmente el
sitio de contingencia debe ser construido geográficamente muy lejos, otro país.
Para poder
crear un DRS para un ambiente SOA, debemos considerar los siguientes puntos:
- El punto de acceso de los clientes a nuestro ambiente SOA.
- Estructura de Directorios idénticos entre el sitio de producción (SITE-1) y el sitio de continencia (SITE-2), puntos de montaje, tamaño de discos, permisos, hostname, misma versión de sistema operativo, misma version de software de Middleware, etc.
- Replicación de Archivos binarios y archivos de configuración del Middleware.
- Replicación de la data transaccional de nuestra base de datos.
El acceso a los clientes hacia nuestro ambiente SOA debe ser lo más transparente posible ante un desastre, es decir, inicialmente los clientes van a estar conectándose a nuestro ambiente de producción (SITE-1) pero cuando ocurra un desastre se deberán conectar a nuestro ambiente de contingencia (SITE-2), este cambio debe ser lo más rápido y transparente.
A
continuación se muestra una imagen en la que se ve como estaría la configuración en un inicio.
- Los clientes se conectan al sitio de producción (SITE-1).
- La base de datos está replicando la data al sitio de contingencia (SITE-2).
- Los binarios y los archivos de configuración del Middleware se están replicando hacia el sitio de contingencia (SITE-2).
Es necesario
dejar claro que la replicación de los binarios y archivos de configuración es a
través de mirroring entre los discos que utiliza el Middleware, mientras que la
replicación de la data de nuestra base de datos es por medio de los
"archived logs" generados por la base de datos de producción,
enviados a la base de datos de contingencia y luego aplicados a esta última. La
replicación de la base de datos se hace por medio de "Data Guard" y
la configuración es llamada "Physical Standby", para saber cómo crear
una configuración de éste tipo pueden visitar el siguiente enlace:
http://docs.oracle.com/cd/B19306_01/server.102/b14239/create_ps.htm#i63561
Cuando ocurra un desastre (Failover) o se necesite realizar un mantenimiento planificado (Switchover), se deberá cortar la sincronización SITE-1->SITE-2 tanto de los binarios y archivos de configuración del middleware, como la sincronización de nuestra base de datos. Se deberá cortar la conexión de los usuarios hacia el sitio de producción (SITE-1) y redireccionarlos hacia el sitio de continencia (SITE-2) tal como se ve en la siguiente imagen:
Cuando ocurra un desastre (Failover) o se necesite realizar un mantenimiento planificado (Switchover), se deberá cortar la sincronización SITE-1->SITE-2 tanto de los binarios y archivos de configuración del middleware, como la sincronización de nuestra base de datos. Se deberá cortar la conexión de los usuarios hacia el sitio de producción (SITE-1) y redireccionarlos hacia el sitio de continencia (SITE-2) tal como se ve en la siguiente imagen:
Una vez el sitio de
contingencia ya esté activado y los clientes estén debidamente redireccionados
a éste nuevo sitio, la configuración quedaría de la siguiente manera para un Switchover (Mantenimiento planificado):
El SITE-2 será el ambiente de
producción y el SITE-1 pasará a ser el ambiente de contingencia, la replicación
seguirá realizándose, solamente que ahora en dirección inversa: desde el
SITE-2->SITE-1. Por lo tanto todos los cambios que se estén realizando en el
nuevo ambiente (SITE-2) no se estarían perdiendo, pues el SITE-1 se estaría
sincronizando.
La siguiente imagen demuestra como quedaría la configuración:
Si se tratara de un Failover, se estaría asumiendo que el SITE-1 estaría
completamente perdido. Los clientes estarían conectándose al SITE-2 y ya no habría
replicación de binarios y archivos de configuración del Middleware, tampoco de
la data de nuestra BD.
La configuración después de un failover quedaría como muestra la siguiente imagen:
La configuración después de un failover quedaría como muestra la siguiente imagen:
http://docs.oracle.com/cd/E23943_01/doc.1111/e15250/toc.htm
No hay comentarios:
Publicar un comentario