Disaster Recovery, Parte IV: El diseño detallado (2 de 2)

Para reproducir exactamente nuestra red en el sitio de contingencia se tendría que implementar los siguientes mecanismos:

-          Direccionamiento de la red de contingencia tipo 10.40.0.0/16 (igual a la de producción) con los servidores a instalar

-          Direccionamiento de la red que une los dos lugares tipo 192.168.0.0/24

-          Definición en los servidores DNS de nuestra red interna de nombres “paralelos” de cada servidor de la red de contingencia con una IP ficticia. Por ejemplo, al servidor de nombre SRV001 e IP 10.40.0.31 que tendría ese nombre y esa IP en ambas redes, se le crearía una entrada en el servidor DNS tipo “SERV001-CON 192.168.0.31” para que fuese referenciado desde la red interna como SRV001-CON

-          En el Firewall de la red interna se definiría en la regla de salida hacia la red de contingencia, un NAT tipo 192.168.0.1.

-          En el Firewall de la red de contingencia se definiría unas IP virtuales para cada servidor residente tipo 192.168.0.31 à 10.40.0.31

De esta manera nuestra red principal NO estaría conectada directamente a la red de contingencia sino mediante una red “puente” que estaría constituida por una de las interfaces de cada Firewall en cada localidad.

Para implementar las actualizaciones de datos de los servidores de producción a los de contingencia se podrían usar software de respaldo inteligentes para efectuar sincronizaciones de directorios (para el caso de archivos independientes). En el caso de las Bases de Datos el tema es más complejo porque lo que se desea es enviar los registros modificados, añadidos o eliminados. En nuestro caso se decidió que, para todas las Bases de Datos distintas al sistema central del Banco, se implementaría un esquema simple de envío periódico de toda la Base de Datos (la frecuencia y la modalidad de envío variaría para cada Base de Datos)  la cual NO sería actualizada en el servidor “espejo” sino en caso de activarse la contingencia. En el caso de las Bases de Datos realmente críticas del Banco, que estaban en Oracle, en cambio se implementaría un esquema propio de Oracle para la réplica de los registros cuyo criterio depende del volumen de datos a actualizar, al definirse un tamaño pequeño la pérdida sería realmente pequeña en caso de un desastre mayor (claro que el impacto estaría en la ocupación del enlace de comunicaciones).

Disaster Recovery, Parte IV: El diseño detallado (1 de 2)

Lamentablemente tuvimos que descartar las opciones espectaculares basadas en hardware con las soluciones de software de los fabricantes por razones de costo: nuestra operación no justificaba inversiones de ese calibre, así que tuvimos que ingeniarnos una “casera”.

Sitio para la contingencia

El lugar que seleccionamos para la posible activación de una contingencia al momento de que ocurriese un desastre, fue la instalación de nuestro ISP; resulta que nuestro ISP también se dedica (de hecho es su actividad primordial) a ser un Data Center para “collocation” de servidores, alquiler de espacio, hosting, etc. así que tiene las instalaciones más que adecuadas para estas funciones (de hecho el Data Center como tal está mucho mejor equipado que el nuestro). Otro factor importante que tomamos en cuenta fue que nosotros teníamos con ellos una doble conexión con dos fibras ópticas de dos proveedores distintos, cada una de 2Mbits… de esta manera teníamos la contingencia de comunicaciones asegurada, las conexiones más que probadas y sobre todo la posibilidad de ampliar o reducir los canales de comunicación con mucha rapidez.

Criterios de selección

Evidentemente no se estaría llevando a la instalación de contingencia al 100% de la operación, se establecieron ciertos criterios para reducir el plan a algo cuyo costo fuese razonable:

1)     Se llevarían prácticamente todos los sistemas menos algunos para proyecciones, análisis, etc.

2)     Se llevarían todas las Bases de Datos de producción

3)     No se llevarían los datos históricos

4)     No se llevarían los ambientes de desarrollo

5)     Se llevarían los “Home Folders” de ciertos usuarios seleccionados (en condiciones normales los Home Folders de todos los empleados estaban en un servidor central)

6)     Se llevarían las carpetas compartidas de los distintos departamentos de acuerdo a lo especificado por sus respectivos jefes

7)     Se llevarían los buzones de correo de ciertos usuarios seleccionados (en condiciones normales todos los empleados tenía sus correos en un servidor central mediante IMAP)

Equipamiento para la contingencia

Los servidores necesarios para el plan de contingencia pueden ser divididos en dos categorías: los basados en Windows/Linux y los basados en HPUX.

Servidores Windows/Linux:

Se decidió que los servidores de este tipo serían todos virtualizados (muchos de hecho ya lo eran), de esta manera solo sería cuestión de dimensionar en cuanto a uso de CPU, memoria y espacio en disco, cada uno de ellos para luego dimensionar uno o más servidores anfitriones que los hospedarían. Luego del estudio mencionado, se llegó a la conclusión que ampliando la memoria y el espacio en disco de dos servidores anfitriones que ya se poseían desde hace 5 años, se podrían hospedar a los servidores virtuales necesarios para seguir haciendo funcionar al banco en situación de contingencia (más abajo daré los detalles).

Servidores HPUX:

En verdad el mundo de “los servidores basados en HPUX” se reduce a uno solo: la idea era instalar lo que en producción estaba en dos servidores en uno. No sería una gran proeza ya que al final se traduciría en cantidad de memoria a tener para poder alojar los servicios necesarios.

Los elementos de comunicaciones necesarios para el funcionamiento del banco, tales como Firewall, Switches y Routers serían proveídos por nuestro ISP. Quedaba por verse la solución de respaldos, pero se decidió dejarla para una segunda fase ya que, al momento de un desastre, no hay que ponerse demasiado exigentes.

Inventario de servidores

En cuanto a los servidores se tenía lo siguiente:

- Siete servidores físicos con Windows a virtualizar

- Cuatro servidores Windows ya virtualizados

- Un servidor físico con Solaris (el del correo) a “transformar” en un servidor Linux virtualizado

- Un servidor físico con Linux a virtualizar

- Un servidor Linux ya virtualizado
-  Dos servidores físicos con HPUX a condensar en uno

Al final se tendría un total de once servidores virtuales con Windows y tres servidores virtuales con Linux.

En la próxima entrega la estructura en el sitio de contingencia  y el esquema de refrescamiento de los datos.

Disaster Recovery, Parte III: Ideas iniciales

Comencé a pensar en una configuración externa a nuestras instalaciones que fuese prácticamente igual a la real de producción: la idea era tener servidores menos poderosos pero virtualmente iguales a los otros tanto en nombres, como en URLs, como en direcciones IP… de esta manera las aplicaciones seguirían refiriéndose a los distintos servidores de la misma manera. Obviamente para los usuarios trabajar en el ambiente de contingencia habría sido exactamente igual: se autenticarían de la misma manera, buscarían los sistemas de la misma manera, las áreas compartidas serían las mismas… en fin, una vez que se declarara el desastre y los usuarios tuviesen que ir a nuevas localidades a trabajar, no notarían mayor diferencia con su ambiente normal.

Evidentemente lo primero que pensé para crear un ambiente de este tipo fue en virtualización de servidores, se podrían virtualizar a todos los servidores que hiciese falta (por lo menos los Windows y Linux), meterlos en algunos servidores físicos con amplia capacidad de disco y de memoria e implementar algún esquema que permitiese su actualización periódica.

Para resolver el caso de los servidores con HP-UX era más complicado: aún cuando HP tiene una solución de virtualización que funciona para servidores Integrity y que permite tener máquinas virtuales con HP-UX y/o Windows y/o Linux de RedHat, económicamente el costo era espeluznante tal como mencioné en otra entrada de este blog (Cluster de Servidores Unix: El proyecto). Total que para resolver el problema de los servidores con HP-UX, se me ocurrió el viejo truco de “matar dos pájaros de un tiro”, es decir tener el ambiente de contingencia en un servidor parecido al de producción pero reproduciendo en él el ambiente de prueba (que también necesitaba una mejora) de esta manera se aprovecharía el servidor de dos maneras: 1) Como servidor de desarrollo, y 2) Como servidor de producción de contingencia.

Otro de los puntos importante a analizar en esta etapa, fue el de la réplica de los datos de la SAN. En la San se encontraban los datos más importantes y críticos de la organización: las Bases de datos Oracle, los archivos compartidos entre las distintas áreas de la organización, los archivos de trabajo de cada usuario y otros archivos de sistemas menores; la réplica de estos datos (sobre todo de las Bases de Datos Oracle) era realmente algo crítico en todo el plan de contingencia. Dado que había realizado algunos contactos con proveedores sobre este asunto, uno de ellos me propuso darme una charla sobre una solución a la réplica de los datos para la SAN: tengo que reconocer que la solución que nos proponían era realmente espectacular! Se trataba de tener a una SAN igual en el sitio remoto y luego, instalando un software en ambos lados, la réplica se producía automáticamente con un gasto en ancho de banda mínimo, sin impacto de rendimiento y se basaba en copiar inteligentemente las zonas de los discos que fuesen cambiando. Una vez más el alto coste del hardware y del software no me permitió utilizar esta solución.

En la próxima entrega el diseño detallado de la solución.