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.
No hay comentarios:
Publicar un comentario