Mostrando entradas con la etiqueta DR. Mostrar todas las entradas
Mostrando entradas con la etiqueta DR. Mostrar todas las entradas

martes, 7 de octubre de 2014

Recuperación de Desastres en el Data Center


Desarrollar un plan de recuperación tiene como objetivo regresar a la operativa del negocio al mismo nivel en el que estaba antes de la catástrofe. Si su negocio es tomar pedidos por medio de una línea telefónica y continuar con la entrega de productos, el esfuerzo de recuperación debería estar dirigido hacia el restablecimiento de la operación telefónica y la conexión del personal a los sistemas de procesamiento informático y telefónico, lo cual permitirá que continúen los envíos.
El plan final podrá incluir una instalación redundante en otro sitio remoto que tenga acceso a los datos obtenidos de las copias de seguridad. Si la operación no es tan crítica o la instalación redundante no ha sido considerada por razones presupuestarias, es imprescindible un buen plan de recuperación.


Un Data Center de respaldo consiste en un sitio de contingencia que reemplazará al de producción solo con las aplicaciones definidas como críticas para el BCP (Business Continuity Plan). A continuación se describen las características de los cuatro tipos de Data Centers que se pueden utilizar para el diseño de un plan de recuperación de desastres:

  • Data Center de contingencia estándar: Consiste en disponer de un espacio físico vacío con la capacidad de contener y soportar las aplicaciones pertenecientes al grupo de DR; preparado con la estructura eléctrica y de refrigeración mínima para cubrir la contingencia de esos equipos. Se debe considerar  con la posibilidad de que los equipos se demoren en conseguir en la zona, por ejemplo, Firewalls (cortafuegos) o algún reemplazo similar. Este método tiene un costo bajo, salvo por el desaprovechamiento del espacio, pero los tiempos de restauración son muy lentos (de días a semanas), ya que se debe conseguir el equipamiento, armar la infraestructura, luego instalar las aplicaciones; y finalmente, restaurar los datos de las cintas.
  • Data Center en la nube: Utiliza los servicios ofrecidos por los proveedores basados en Internet o a través de un enlace punto a punto por medio de un proveedor que ofrezca una conexión privada. Los costos son menores y la velocidad de instalación de los nuevos servidores es muy rápida, están basados en máquinas virtuales, pero lo que demandará más tiempo será la restauración de los datos, porque las cintas de contingencia deben ser enviadas hacia el proveedor, también habrá que restaurar las aplicaciones; y luego, restaurar los datos.
  • Data Center asincrónico (mirror off-line): Consiste en tener otro Data Center duplicado en una ubicación remota en donde se replican todos los servidores críticos de manera asincrónica. Esto puede realizarse en un sitio privado o contratado por a algún proveedor, pero con la salvedad de que los datos de esas aplicaciones críticas se copian al Data Center de contingencia de manera automática fuera del horario de operatoria diaria; por ejemplo, por las noches, mediante diversas herramientas. Tiene un costo alto, ya que todos los servidores están disponibles, pero sólo se utiliza la red dedicada para la transferencia de datos al Data Center de respaldo cuando no afecta las operaciones en horario central; por lo cual, en caso de desastre, el tiempo de recuperación es menor a un día. Generalmente este servicio es empleado por empresas que procesan sus operaciones más importantes en servidores Mainframe, del rubro bancario, por ejemplo, ya que en caso de desastre no pueden quedarse sin operar, y tener un Mainframe de respaldo resulta impráctico debido a su altísimo costo, pudiendo costar varios millones de dólares solo un Mainframe.
  • Data Center sincrónico (mirror on- line): Llamado espejado o (mirroring), es una estrategia donde en el Data Center de respaldo propio o rentado a algún proveedor replica todos los datos de la aplicaciones críticas, tomándolos desde el Data Center de producción, de modo constante en tiempo real, copiando bloque a bloque; de manera tal, que si ocurre un desastre, la recuperación es instantánea, pudiendo tomar tan solo algunos minutos. Es la estrategia más rápida y costosa, ya que requiere tener todos los servidores duplicados y exige tener un gran ancho de banda disponible solo para la copia de los datos en tiempo real. Por lo que los costos en infraestructura de red son altos, además del mantenimiento e la implementación del software encargado de hacer que esa replicación funcione: Softek de IBM, Stream de Oracle, u otras soluciones provistas por los fabricantes de la SAN. Está claro que este tipo de soluciones están reservadas para empresas grandes que manejan presupuestos de infraestructura millonarios y no pueden sufrir interrupciones en la operatoria de sus servicios debido a sus altísimos costos.

Importante: Si se elige una estrategia sincrónica es fundamental que dicho proceso sea monitoreado constantemente a fin de corregir los desvíos, ya que de nada sirve una inversión tan grande para luego tener problemas de inconsistencia de datos por problemas de sincronismo.
Ambas estrategias, asincrónicas o sincrónicas son válidas mientras sean adecuadas entre el balance de costo y tiempo de RTO (Recovery Time Objective), adecuando el tipo de método de replicación elegido, ya sea por SAN, por red o a nivel de servidores o de base de datos, ya que los tiempos de recuperación de datos por medio de las cintas magnéticas son lentos para las necesidades de negocio de muchas empresas.
Los fabricantes de SAN como EMC, IBM, HP, Hitachi o Dell, entre otros ofrecen soluciones de replicación que se ajustan a cualquiera de los dos tipos. También para replicación por red a nivel de sistema operativo o replicación por red con productos que optimizan el tráfico de manera segura y eficiente.

Para decidir cuál va a ser la metodología elegida para el Data Center de contingencia, se deberán analizar los costos por las pérdidas y los costos por la implementación de la solución, además de la variación en horas por cada tipo de solución sobre la base de la complejidad de las aplicaciones que se restaurarán.