Inicio > Seguridad > Recuperación ante desastres con Oracle, del Active Dataguard a la Standby Manual

Recuperación ante desastres con Oracle, del Active Dataguard a la Standby Manual

En la mayoría de empresas se han ido implantando durante los últimos años planes de recuperación ante desastres o DR (Disaster Recovery). Estos planes comprenden un conjunto de recursos hardware, software y procedimientos que deben permitir a una empresa continuar ofreciendo sus servicios (o los considerados mínimos) en caso de que ocurran problemas graves en los sistemas informáticos de ésta.

Ejemplos típicos de estos problemas pueden ser incendios, inundaciones, terremotos, pérdidas prolongadas de suministro eléctrico/comunicaciones o errores humanos que dejen fuera de servicio los sistemas informáticos principales de la empresa.

En el caso de los productos Oracle y para intentar minimizar este tipo de problemas, existen configuraciones de DR que nos permiten mantener en ubicaciones físicamente separadas (a decenas, centenares o miles de kilómetros) sistemas de contingencia que podrán seguir dando servicio en caso de caída de los sistemas principales.

No deberemos confundir el DR destinado a sobreponer a la empresa ante errores graves o de gran magnitud con la alta disponibilidad o HA (High Availability). La HA está encaminada a evitar cortes de servicio en caso de fallo en alguno de los componentes de nuestros sistemas informáticos. De hecho ambos tipos de soluciones se pueden combinar en los sistemas informáticos más críticos. Por ejemplo disponer de discos, o tarjetas de red duplicados en un servidor es una solución de alta disponibilidad (HA), disponer de un segundo servidor en otra ciudad replicado con el primero es protección ante desastres (DR).

Hoy nos centramos solo en el DR, y específicamente en DR para las BBDD Oracle, dejando para próximas entradas soluciones de HA para BBDD y HA/DR para servidores de aplicaciones Oracle.

Disaster Recovery para BBDD Oracle

Si queremos plantearnos una solución de DR, lo primero que deberemos decidir es el nivel de servicio que queremos/necesitamos/nos podemos permitir en caso de problemas en nuestro centro principal.

¿Nos basta con restablecer una parte del servició o requerimos servicio al 100%?

¿Tenemos que volver a dar servicio en menos de “x” horas o “x” minutos?

¿Podemos permitirnos perder algunos datos o ninguno?

¿Qué tipo de líneas de comunicación y de qué capacidad disponemos para comunicar con el site remoto?


Podemos pedir prácticamente lo que queramos: desde disponer del sistema en unos segundos tras el desastre sin tener que reconfigurar nada en los clientes y sin perder ningún dato, a tenerlo un día tras el desastre, a un 50% del servicio original y perdiendo unas horas de trabajo.

Si preguntamos a los usuarios siempre pedirán el máximo posible, pero como os podéis imaginar todo tiene un coste…

Tendremos que evaluar el coste de puesta en marcha del sistema de DR, el coste de su mantenimiento y la posible sobrecarga que cause en el sistema principal, frente a las pérdidas que ocasionaría la caída del sistema principal. A partir del punto en que el sistema de DR es más costoso que la propia caída del principal no estaremos haciendo “buen negocio”.

Llegados a este punto espero que tengáis alguna idea de qué puede aportar el DR y sobretodo muchas dudas. Vamos a entrar un poco mas en detalle en algunas soluciones de DR y de esta manera intentar aclarar algunas de estas dudas.

De todos modos las soluciones de DR son muy flexibles y se pueden (y deben) adaptar a cada situación.

Soluciones de terceros

Empecemos por “abajo”. Si buscamos un poco, en el mercado existen opciones para replicar centros de datos a nivel de cabina. Acostumbran a ser “generalistas”, replicando a nivel de byte los volúmenes (realmente desconocen los datos o aplicaciones que replican).

Normalmente son soluciones propietarias de las empresas que fabrican las propias cabinas y si bien algunas “reconocen” los datos Oracle y saben tratarlos como tales, acostumbran a ser caras y a requerir mucho ancho de banda para replicar los datos. Finalmente, dan poca “sensación de seguridad” ya que no podemos saber si la réplica funcionara correctamente hasta el momento que tengamos que usarla.

A nivel un poco más alto existen programas que “capturan” los datos que las aplicaciones escriben en disco y los replican en ubicaciones remotas. Estos no acostumbran a llevarse bien con Oracle (que siempre trata de escribir a disco directamente y sin intermediarios). Estos programas tienen los mismos puntos negros que las soluciones de replica a nivel de cabina, además de presentar una sobrecarga en el rendimiento del gestor al monitorizar todas las escrituras a disco; por contra, acostumbran a ser un poco más económicas que las anteriores.

Standby y Dataguard de Oracle

Finalmente existen las soluciones que nos aporta Oracle: las BBDD Standby y el producto DataGuard (que ya viene integrado en las BBDD EE).

Una BBDD Standby física (existen Standby “lógicas” de las que hablaremos en otra ocasión) es una copia “bit a bit” de nuestra BBDD productiva, separada de ésta varias decenas, centenares o miles de kilómetros. Los cambios se trasmiten de la principal a la Standby y se aplican posteriormente en ésta.

Las trasmisiones de datos se realizan de manera comprimida y optimizada ocupando un mínimo de ancho de banda, y los datos pueden aplicarse en la standby “al momento” o con un cierto retardo, de manera que en caso de errores lógicos (modificación o borrado por error de gran cantidad de datos en la principal) se pueda ir a consultar los datos “del pasado” en la standby.

En caso de usar la funcionalidad de Active Data Guard es posible consultar la BBDD Standby al mismo tiempo que se aplican los cambios.  En consecuencia, es posible descargar parte de las consultas contra la BBDD Standby, y con las versiones mas actuales del gestor es posible lanzar selects contra la Standby pidiendo que si la “frescura” de los datos es menor de un cierto límite, la select acabe lanzándose en la principal (todo de manera trasparente a la aplicación). En estas BBDD Standby también podremos realizar el reporting y los backups.

Incluso podemos usar la BBDD Standby como banco de pruebas, ya que con la función de Flashback Database podremos abrir la BBDD Standby en modo lectura-escritura, realizar los cambios y pruebas que queramos, y una vez finalizadas volver al estado anterior “rebobinando” la BBDD sin que pierda su función DR.

Podemos cambiar los roles de las BBDD en menos de 5 minutos y, con solo unos clicks de ratón o una orden de línea de comandos, pasar la BBDD principal a Standby y la Standby a principal. Esto nos facilitara mucho la vida si, por ejemplo, queremos realizar tareas de mantenimiento en el servidor principal: solo tenemos que cambiar los roles, realizar las modificaciones y volver a cambiar los roles una vez finalizadas (todo ello con un mínimo corte de servicio y sin perder datos). Esta opción tambien permite intercambiar los roles cada cierto tiempo para “asegurar” que nuestra solución DR funciona correctamente.

Cabe destacar que podemos mantener diferentes niveles de seguridad/prestaciones en una Standby y cambian de uno a otro nivel bajo demanda. Desde un modo en que se favorezca la BBDD principal, enviando los cambios de manera asíncrona a la Standby evitando que se penalice su rendimiento en lo mas mínimo, hasta un modo en que prime la seguridad, no devolviendo el “commit completed” al usuario hasta que el cambio se haya almacenado tanto en la principal como en la Standby.

Finalmente, comentar que todo esto lo podemos configurar desde Oracle Grid Control o por línea de comandos mediante la utilidad DGMGRL, el propio software de BBDD incorpora el llamado Data Guard Broker que vigilará y mantendrá la BBDD Standby por nosotros en todo momento.

Todas estas funcionalidades están al alcance de los usuarios de BBDD Oracle en versión Enterprise Edition y, exceptuando la opción de Active Dataguard, son gratuitas.

Eso sí, se requiere el correcto licenciamiento de las dos maquinas que intervienen (primaria y Standby). En caso de usar licencias por usuario nominal esto no acostumbra a ser un sobrecoste (dependerá del numero de CPU’s por tema de mínimos de usuario nominal x CPU), en caso de usar licenciamiento por CPU  implica el sobrecoste de las CPU’s de la Stanby.

Para los que queráis entrar más en detalle, podéis enviarnos vuestros comentarios o dar un vistazo a este link en el que  encontraréis mucha mas información sobre Data Guard:

http://www.oracle.com/technology/deploy/availability/htdocs/DataGuardOverview.html

Standby Manual

Llegados a este punto, los usuarios de BBDD Standard Edition se deben preguntar qué pueden hacer ellos para preparar un entorno DR. Pues bien, en este caso no está permitido usar las funcionalidades anteriormente mencionadas, pero podemos montar un sistema de DR “manual”.

Podemos crear una BBDD Standby, preparar un sistema de scripts que envíe los redo logs archivados de la primaria a la Standby, y finalmente otro que los aplique. En el fondo lo que haremos será una especie de “recover” continuado de la BBDD.

De nuestra pericia con los scripts dependerá el grado de automatización y funcionalidades que lleguemos a tener (hemos realizado algunas instalaciones de este tipo en las que se ha llegado a simular el “aplicado retardado” que nos ofrece Data Guard por ejemplo).  No podremos abrir en lectura-escritura al no disponer de Flashback Database (solo disponible con Enterprise Edition), pero si podremos abrir la Standby en solo lectura, realizar consultas y volverla a activar posteriormente (todo ello mediante comandos SQL).

Otro inconveniente es que no disponemos del “Real Time Apply”  traspaso síncrono de cambios de manera que en caso de problemas es probable que perdamos algunos datos (pero la cantidad de datos perdidos es controlable por la frecuencia de enviado de redos que decidamos configurar).

A nivel de licenciamiento rigen las mismas consideraciones que ya hemos comentado en el punto anterior, se deberá disponer de licencias para ambos gestores.

No tendremos todas las ventajas de una Standby “real” pero, dependiendo del caso, puede cubrir nuestras necesidades de DR, y todo ello con BBDD Standard Edition.

En definitiva, no por tener una BBDD Standard Edition deberíamos renunciar a disponer de un entorno de DR.

Categorías:Seguridad Etiquetas: , ,
  1. Francis Pérez Mateu
    octubre 2, 2012 en 13:48

    Muy interesante y útil tu post. SImplemente aclarar un punto. Lo que marca la posible perdida de datos ante una catástrofe no es el Real Time Apply ( éste minimiza el tiempo de activar la standby) sino el modo síncrono o asíncrono en el transporte. En una Standard el transporte siempre será asíncrono, por medio de nuestros scripts, y aquí puede haber pérdida de datos.

    Otra opción interesante es el producto Golden Gate, de Oracle, que creo sí es licenciable en una Standard

    • Rafael Planella
      octubre 3, 2012 en 08:31

      Hola totalmente correcto, comentario actualizado 😉

      En cuanto a GoldenGate, efectivamente se puede licenciar en una Standard y en multitud de otras BBDD de otros fabricantes, en alguna presentación lo he definido como:

      Una herramienta capaz de capturar, enrutar, transformar, y enviar datos transaccionales entre entornos heterogéneos en tiempo real.

      Una de las ventajas frente a otros sistema de replica hetereogeneos es que trabaja a partir de los ficheros de “journaling” de la BBDD (los redo logs online/archivados en caso de Oracle) por lo que tiene un impacto muy bajo en el sistema origen.

  1. enero 3, 2011 en 13:07
  2. enero 2, 2012 en 10:38
  3. enero 2, 2013 en 09:41

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: