Las disponibilidad de un sistema o el cómo esto se caiga ¡¡¡¡ es el apocalipsis !!!

Continuo con mis rollos de informática. Para el que no le guste le pondría aquí un enlace al Playboy, a la prensa o una recomendación de libros interesantes pero como en España hay una ley infame que dice que por enlazar hay que pagar a una organización con comportamientos poco edificantes que van a cobrar sean o no socios de ella, pues mira, te vas al buscador que más te guste y buscas algo más ameno.

Rollo al canto ... que no me vea.

Pues nada, vamos a meternos en harina. Para cualquiera que hayas desarrollado o trabajado con un sistema de información le sonará el término disponibilidad o lo que es lo mismo, cuantas horas al día tiene que estar funcionando un sistema y en caso de parada cuánto tiempo puede estar parado sin impactar al negocio de manera significativa. Por lo general la respuesta del usuario es la misma: 

¡¡¡ MI SISTEMA ES LO MÁS IMPORTANTE DEL MUNDO
Y NO SE PUEDE PARAR JAMAS !!!

Lo gracioso es que eso te lo puede decir por ejemplo el encargado del sistema o parte del mismo encargado de pagar los recibos en ventanilla en el banco. Si, ese señor tan joputa simpático que ha decidido que sólo se pueden pagar recibos en ventanilla los martes cuyo día del mes sea par de las semanas bisiestas entre las 08:00AM y las 08:15AM, eso siempre que el día siguiente no sea miércoles e impar. Por supuesto que necesita su sistema arrancado 7x24 y con un SLA (acuerdo de nivel de servicio) de 30 segundos (o menos) Y claro, como el que gestionaba los costes de contabilidad hacía trampas y lo metía todo en el mismo saco, este señor tenía su 7x24 funcionando por todo el morro y sin costarle un euro directamente.

Es curioso que sistemas tan críticos que no se pueden parar nunca resulta que hasta su mecanización o hasta que se modificaron solo iban de 8 a 3 y de lunes a viernes. Y si la cosa se estropeaba, se tiraba de libreta y ya se pasaría cuando se arreglara. Y lo curioso es que no se moría nadie por hacerlo así.

¿Todavía sigue aquí el cansino éste?

Durante mucho tiempo se han gastado ingentes cantidades de dinero en hacer robustos hasta la paranoia sistemas que no lo han necesitado o han tenido alternativas muchísimo más baratas. Se ha abusado de clusters, bases de datos replicadas (la opciones "enterprise" de las bases de datos son sorprendentemente caras) granjas de servidores que estaban al 5% o menos de ocupación de CPU, ...

No voy a decir que se monte un sistema de manera que se pueda caer sin posibilidad de recuperación o que sea sensible a un fallo hardware pero durante mucho tiempo ES QUE SE HA HECHO ASÍ. He visto muchos sistemas que se montaban en discos únicos o servidores únicos con montones SPOF (Single Point of Failure) Lo cierto es que una solución a la que se recurría era el tener un segundo equipo al lado (por ejemplo el viejo) con las mismas aplicaciones y en el que de una manera u otra se hacían volcado de los datos. Esta sistema podía ser de lo más diverso: desde copias de seguridad se recuperaban, volcados de datos, bases de datos replicadas .... todo variaba según el nivel de paranioa y el nivel técnico y económico disponible. No es lo mismo dar HA con software y sistemas de hace 15 años que con una aplicación virtualizada en un cluster, por ejemplo. Para dar alta disponibilidad hoy en día hay infinidad de soluciones pero lo cierto antes de elegir una de ellas hay que hacerse una serie de preguntas:

• Qué disponibilidad necesito en mi aplicación. Esta es la primera pregunta y hay que evitar pensar siempre en "lo más grande que haiga" Si tienes una aplicación de nóminas las lanzarás a final de mes en una determinadas fechas y horas, no te hace falta estar operativo los 30 días de mes (o no toda la aplicación) Si tienes una tienda en Internet estilo Amazon o Aliexpres necesitas estar disponible las 24 horas del día. No conozco las distribuciones horarias de las ventas de estos sitios, pero aparte de servir a todo el mundo (lo que cubre todas las franjas horarias) apostaría un euro a que su actividad principal es los fines de semana y fuera de horas de trabajo. Hablando de fines de semana, no en todo el mundo el fin de semana es el sábado y el domingo.
• Cuánto tiempo puedo estar parado. Time is money como dicen los pérfidos. Si mi aplicación es algo de banca estoy perjudicando a los usuarios si se cae, si es una tienda como las anteriores, dejo de ingresar dinero. Aquí me interesa invertir en tenerla arriba el mayor tiempo posible. Si lo que tengo es la aplicación para pedir las vacaciones, pues si hoy no funciona, ya las pedirán mañana. Esto no es decir que lleno mi sistema de SPOFs (discos, máquinas, comunicaciones) pero tampoco necesito protegerme como si fuera Fort Knox.
• Puedo perder datos o no. Si soy un banco la respuesta es rotunda: No puedo perder ni una sola operación (otra cosa es que si la pierdo me callo como una puta y asumo el coste no sea que de mala imagen) pero si soy Facebook y pierdo las fotos de la última media hora ... pues que las vuelvan a subir.
• Soy o no de verdad crítico. Porque si de verdad soy criticoa lo mejor tengo que irme a un datacenter que me garantice que no voy a tener ningún imponderable (Telefónica se acaba de gastar más de 100 millones en hacerse un TIER IV Gold) o duplicar (mejor triplicar) y distribuir instancias entre diversos sites. Vamos, que será por dinero. Curiosamente según me han contado hay en España algunos sistemas críticos de verdad con menos protecciones ante imprevistos (eso no quiere decir que estén desprotegidos que pueda entrar cualquier hacker) que otros sistemas mucho menos importante.

Al final no hay que obsesionarse con que si mi sistema es la leche o no. Hay que analizar los factores anteriores y conseguir un balance entre coste y disponibilidad. No obstante hay una serie de factores con los que no se debe jugar (otra cosa es que se haga):

• Energía: tus sistemas deben tener algo que les proteja ante fallos eléctricos. Deben estar protegidos ante picos de tensión y disponer de un SAI (sistema de alimentación ininterrumpida) que permita bien el tiempo suficiente para apagar los equipos de manera segura o mejor todavía, aguantar mientras entran equipos auxiliares para producir energía (Ojo, que deben alimentar los ordenadores y la refrigeración) Luego ya te puedes ir a virguerías como equipos duplicados N+1, 2N o incluso, 2N+1, refrigeración redundada, ....  por lo general, casi todos podemos sobrevivir con algo más modesto. Eso sí en invierno, procurad NO CONECTAR RADIADORES Y CALEFACTORES a las tomas alimentadas desde el SAI (no me invento nada)
• Comunicaciones: si lo anterior es importante las comunicaciones son la razón de ser de tu sistema y de tu centro de datos. Hoy en día no creo que nadie trabaje ya con terminales conectados al servidor (aunque de todo hay en la viña del Señor) Mínimo equipos duplicados funcionando en cluster a ser posibles, líneas principales y de backup, 
• Almacenamiento: El perder datos por daño de discos en pleno siglo XXI debería estar penado en el Código Penal con dos años escuchando música de dulzaina y acordeón. Con el precio de los discos y los sistemas existentes para evitar las pérdidas de información (RAID, triple-mirror, hot spare) esto es casi tan importante como lo anterior. Y ya puestos, esto no se mantiene solo. Si se jode un disco y entra el hot-spare, luego hay que cambiarlo (que nos conocemos)

Por supuesto que hay un montón de cosas más que añadir y que se pueden duplicar que van desde servidores, robots de backup, firewalls, .... Pero un fallo en estos elementos se puede intentar paliar pero un fallo en estos sistemas es catastrófico.

Bueno, dentro de unos días más. Seguramente vaya de nubes.

Desde luego, cada vez que habla me entra un sueño más ricooooo