Disaster Recovery, Parte II: Las nuevas premisas

Como mencioné en la primera entrega, se contrataron los servicios de una empresa para que hiciera el trabajo teórico del Plan de Continuidad del negocio; finalmente llega el día de la entrega del informe y me pongo a analizarlo… no lo podía creer… el sistema que resultó ser más prioritario para la organización, el sistema que, según los usuarios, no podía dejar de funcionar porque el impacto hubiese sido tremendo, era PhotoShop! Este diagnóstico se produjo porque los sistemas no quedaron priorizados en la organización, por lo tanto, para el personal de mercadeo, si no tenían PhotoShop, todo se acababa puesto que ellos no podrían hacer nada! La persona a cargo del proyecto me dijo que ahora pasaríamos a la etapa donde la organización pondrían las criticidades de los sistemas y de esta manera se corregirían esos diagnósticos errados… ok… había que esperar unos meses más… en ese momento me dije: “Yo se perfectamente como va a quedar esa lista de los sistemas críticos, puesto que se como funciona la organización y que le hace falta a cada momento, así que voy a tomar la iniciativa”.

De esta manera fue que apelé al menos común de los sentidos y fui elaborando una matriz con la lista de los servicios que prestábamos (en orden decreciente de criticidad) con los elementos tecnológicos necesarios para que funcionaran en términos de servidores, software y enlaces. Organicé la matriz para que los directivos de la organización fácilmente pudiesen escoger lo que querían mantener y lo que no (el Sistema central, los ATM, los POS, los sistemas administrativos, etc.) y también puse los servicios tecnológicos internos para que también pudiesen ser discriminados (Directorio Activo, Distribución de huellas del antivirus, Monitoreo, Respaldos, etc.).

Otra decisión que tomé fue la de NO tomar la filosofía de suponer que, al estar todo destruido, se tendría que volver a levantar la operación desde cero sino que se mantendría una operación paralela funcionando en un lugar a prueba de fallas, esperando por el momento que habría que activarla por la ocurrencia de un desastre.

En la próxima entrega ya comentaré sobre el diseño de la solución.

Disaster Recovery, Parte I: Los preliminares

Se habla mucho de la recuperación de la empresa luego de un desastre, más a partir del 11 de septiembre del 2011 cuando varias empresas fueron literalmente borradas del mapa (instalaciones, equipamiento, respaldos, personal, documentación, etc.), si se le pregunta a la directiva de cualquier empresa al respecto seguramente su respuesta será “Hay que estar preparados! La empresa tiene que estar funcionando 7x24, no importa lo que ocurra! Este proyecto tiene prioridad 1!”, el problema es cuando se le presentan los números a ese mismo directivo y ve como se volatilizan las utilidades de esa empresa para un año o más simplemente para “estar preparados para lo peor”, en ese momento la prioridad del proyecto baja en picada.

En el banco en el cual trabajé el ente regulatorio nos obligó a tener nuestro plan de continuidad del negocio, por lo tanto tuvimos que emprender la tarea completa. Se comenzó contratando a una empresa que, mediante entrevistas al personal, llenando formularios y alimentando a un sistema se detectaría la criticidad de cada aplicación. También, al preguntarle a cada ejecutivo sobre la importancia de los sistemas que usaba, se detectaría la cantidad de tiempo que el negocio podría “soportar” sin la presencia de un sistema determinado.

El trabajo con la empresa contratada duró algunos meses. En mi caso me preguntaron los tiempos que nos tomaría crear la plataforma de servidores necesaria para cada aplicación suponiendo que, llegado el momento del desastre, tuviésemos que recrearla a partir de servidores nuevos que “alguien” nos habría conseguido oportunamente. De nada sirvió que le explicara al analista que me encuestaba que no veía factible en Venezuela que, al momento de un terremoto o de un incendio, fuese realista que “alguien” (reitero esto de “alguien” ya que en la práctica quién llevaba las negociaciones con los proveedores de hardware y de software era yo mismo) llamara a un proveedor de confianza, le pidiera los equipos necesarios y éste nos los suministrara en un corto tiempo (los tiempos normales en Venezuela para la obtención de equipamiento tecnológico NO de consumo masivo como lo pueden ser servidores Unix, una SAN o una unidad de respaldo corporativa son de no menos de 4 semanas) para que entonces nosotros comenzáramos a instalar Oracle, Oracle AS, Flexcube, clientes de respaldos, servicios DNS, DHCP, etc. etc.

Para la reconstrucción de los servidores Unix, luego que el proveedor hubiese entregado en nuestras instalaciones el montón de cajas, cajitas y afines (hay cajas que contienen un cable o un manual!) se tendría que apersonar el analista que los instalaría físicamente (un par de días) y luego el que efectuaría la instalación del software básico  ya que muchas veces vienen con Unix pre instalado, pero hay que parametrizar muchos valores (otro par de días sin ponernos exquisitos instalando el Cluster), entonces vendríamos nosotros a instalar el software mencionado antes (otros 3 o 4 días). En conclusión: suponiendo que se hubiese presentado un terremoto durante un fin de semana o de noche (para que no nos matara el personal!) lo suficientemente fuerte para derrumbar nuestro edificio pero no muchos más (porque si hubiese sido un desastre parecido al de Haití o al tsunami de Japón en Caracas, podemos olvidarnos de contar con equipamiento tecnológico nuevo por meses), suponiendo que gracias a nuestro espectacular plan de contingencia tendríamos en otras instalaciones SEGURAS Y A PRUEBA DE TODO RIESGO respaldos actualizados, el software a instalar, los instructivos, etc. en el mejor de los casos nos tardaríamos unas 6 semanas en volver a tener los servicios tecnológicos funcionando. En la práctica con un desastre real no nos hubiésemos recuperado nunca.

En la próxima entrega seguiré contando sobre los resultados del estudio del Plan de Continuidad del negocio.

Software Bancario, Parte III: Configuraciones

Ya he comentado suficientemente sobre  nuestra instalación de Flexcube – Oracle en el cluster de servidores HP con Service Guard, sin embargo me quedé con las ganas de implementar una solución mucho más “atrevida”, veamos de que se trata…

Requerimientos

Toda instalación de una plataforma tecnológica importante tiene que responder una serie de preguntas en cuanto a:

1)     ¿Los servicios tienen que estar funcionando 7x24?

2)     ¿Los servicios son críticos para el negocio? Es decir ¿si se para la operación se deja de ganar o se pierde dinero?

3)     ¿Los tiempos de respuestas son realmente críticos?

4)     ¿El negocio es tan bueno como para justificar prácticamente cualquier inversión en tecnología?

En nuestro caso las respuestas a esas preguntas eran: Si, No mucho, No mucho y No.

Bajo estas premisas para el departamento de tecnología era muy importante tener algún tipo de Cluster que garantizara el funcionamiento 7x24, por otro lado para estar preparados a una eventual explosión del negocio que volviese las respuestas “No mucho” en “Si”, queríamos tener algo que permitiese mejorara los tiempos de respuesta con relativa facilidad.

La configuración que se me ocurrió fue la de estructurar un cluster de servidores Intel con Linux, compartiendo una SAN y manejados por RAC de Oracle. ¿Cuáles serían los beneficios de una plataforma de este tipo?

1)     RAC de Oracle nos ofrecería:

a.       Implementación de un esquema Activo – Activo entre todos los servidores: se obtiene una distribución de la carga más o menos uniforme entre todos los miembros del cluster

b.       Incorporación o remoción de un servidor sin traumas: excelente para efectuar trabajos de manutención hardware y/o software así como incrementar el poder de cómputo en tiempo real

c.       Estadísticas de uso, picos, etc.: muy cómodo para hacer estudios de capacidad, detección de cuellos de botella, mal funcionamientos, etc.

2)     Linux nos ofrecería:

a.       Disminución del TCO de los servidores  ya que nos libraríamos del costo del licenciamiento del software operativo propiamente pero no así del soporte ya que es casi obligante para este tipo de instalaciones poseer algún tipo de contrato

b.       Tener en servidores de bajo costo un Unix que está prácticamente a la misma altura que HPUX, Solaris o AIX (los servidores que se necesitan para este tipo sistemas operativos son mucho más costosos que los Intel)

Para protegernos las espaldas se habrían podido adquirir servidores de una buena marca reconocida: IBM, HP, Dell con su respectiva solución SAN, todo certificado por Oracle. Una configuración relativamente económica para el año 2007 podría haber sido teniendo servidores DL380 de HP, procesador Xeón, 8GBytes de memoria RAM, dos discos SCSI de 146GBytes en RAID-1 (solo contentivos del sistema operativo), 4 tarjetas de red 10/100/1000 y la tarjeta de Fibra para la conexión a la SAN. La SAN podría haber sido la EVA 4100 que tuvimos luego. ¿Con cuanto servidores se podría comenzar? Yo diría que tres, para que al momento de remover uno para mantenimiento, todavía quedaran dos dando alta disponibilidad.

Expansibilidad

El crecimiento de esta plataforma para Oracle sería de dos tipos Vertical y Horizontal:

Vertical: Se trata de mejorar el hardware de los servidores existentes, para el ejemplo citado los DL380 de HP pueden crecer fácilmente en memoria hasta 96GBytes. Digamos que una configuración razonable para nuestro caso (sobre todo al pasar de Oracle 9i a Oracle 10g) habría sido de 16GBytes. También se puede instalar un segundo CPU para incrementar el poder de cómputo. Adicionalmente, en cuanto al espacio en disco, la SAN de HP crece fácilmente añadiendo más discos y/o más gabinetes para poder añadir discos.

Horizontal: Simplemente añadir más servidores! Esto es lo hermoso de esta solución, se añaden más servidores, se configura RAC para enterarlo de la nueva situación y de inmediato la carga se reparte con los nuevos elementos.

Desventajas

La única desventaja que le veo a este esquema es el del costo, veamos una tabla comparativa (en cuanto a las configuraciones de hardware y software) entre el esquema Activo – Pasivo y el Activo – Activo:

No tengo los números, pero estoy seguro que en cuanto a la inversión a realizar en software, sería sensiblemente más oneroso el esquema Activo – Activo. En cuanto al hardware si me parece que sería más costosa la solución basada en servidores Itanium.

	Activo – Pasivo	Activo – Activo
Cantidad de Servidores	2	3
SAN	HP EVA 4100	HP EVA 4100
Tipo de Servidores	2 x HP rx3600 -       1 x CPU Itanium -       4 x 146GB de HD -       8 x GB de RAM -       4 x 10/100/1000 de red -       2 x Tarjetas FC	3 x HP DL380G5 -       1 x CPU Xeón -       2 x 146GB de HD -       8 x GB de RAM -       4 x 10/100/1000 de red -       2 x Tarjetas FC
Sistema Operativo	HP UX	Linux Red Hat
Software de Cluster	2 x HP Service Guard	3 x Oracle RAC
Bases de Datos	1 x Oracle 10g	3 x Oracle 10g