Alta disponibilidad: ¿Cuánto cuesta que el sistema no se caiga?

Ayer se nos rompió uno de los discos duros que lleva parte del sistema de facturación de nuestro sistema de voz sobre IP. Sin embargo no pasó nada ya que el equipo estaba con una configuración de alta disponibilidad (RAID10  para ser exactos), con cuatro discos similares. A la hora de escribir este post el equipo ya está al 100% de nuevo.

Esto que es algo bastante habitual (aquí podéis leer el reporte del primer trimestre de 2017 sobre fallos de discos de Backblaze) en nuestro día a día puede resultar en una tragedia si no se tiene una buena estrategia de alta disponibilidad. La última noticia que ha llegado a la opinión pública ha sido el fallo de British Airways, atribuido a un ingeniero que no siguió el procedimiento de forma correcta.

¿Qué es la alta disponibilidad?

 
Mucha gente confunde los términos alta disponibilidad (High Availability)  y balanceo de carga (Load Balancing) y aunque a simple vista pueden parecer similares, las diferencias son enormes, tanto en el objetivo como en la forma de implementar las soluciones.

Balanceo de carga significa identificar dónde están los cuellos de botella de una plataforma (web, red, humanos, etc.) y disponer de recursos suficientes para poder distribuir el trabajo en distintos equipos para que esos cuellos de botella se reduzcan. Por ejemplo, tener dos servidores web para una página, dos salidas a Internet, etc. Esto es relativamente sencillo de implementar y hay múltiples soluciones, tanto de software como de hardware para conseguirlo: si tenemos dos servidores web podemos poner un balanceador por delante que pase las peticiones de forma equitativa a ambos servidores.

Si embargo una solución de alta disponibilidad busca dar continuidad ininterrumpida a un servicio. Para eso tenemos que ver los posibles puntos únicos de fallo y duplicarlos:

• ¿Sólo tenemos un servidor? ¿Cuántos discos tiene? ¿Cuantas fuentes de alimentación tiene? ¿Y si falla?
• ¿Tenemos todo alojado en un único centro de datos? ¿Y si falla?
• ¿Tenemos la conexión con un único proveedor? ¿Y las Redes Privadas Virtuales (VPN)? ¿Y si se corta la línea?
• ¿Cuántas personas conocen el sistema? ¿Y si están de vacaciones? ¿Y por la noche?

Podemos ver que no sólo se trata de poner elementos y «hierro» si no que una alta disponibilidad necesita además de procedimientos y personas, y aquí es donde empieza a «irse» el dinero.

Nueve es el número mágico

 
La forma clásica de medir la disponibilidad de un servicio es por porcentaje y se usa el sistema de 99%: partiendo de la base de que una disponibilidad del 100% es técnicamente imposible, 99% significa que un sistema está caído 7,20 horas al mes; pasar a 99,9% ya son 43 minutos de caída y 99,99% no llega a 5 minutos de caída, etc. por lo que añadir un 9 más al final puede suponer un desembolso millonario.

Vamos a verlo por partes con un ejemplo práctico: una web online que ahora mismo está alojada en un único servidor en un CPD.
 

1.- Hardware

 
Partiendo de un único servidor, su componente más débil es el disco duro, por lo que tendremos que comprar 2 similares para tener un mínimo de RAID1 y que en caso de fallo de un disco el servidor siga funcionando. Si estamos usando discos SSD en el que un disco cuesta por ejemplo 100€ pasaríamos a tener que gastar 200€ y esto no nos haría incrementar la capacidad del servidor, es como la rueda de repuesto, cuesta lo mismo que las normales pero la compramos para no usarla.

Por supuesto que el servidor tiene que tener doble fuente de alimentación, ya que otro de los puntos de fallo suele ser este (la conversión de corriente alterna a corriente continua para que funcione el servidor produce mucho calor), y además podría ocurrir un fallo en el CPD.

Y… ¿sólo un servidor? ¿y si se rompe otra cosa? Pues nada, ya necesitaríamos como mínimo dos servidores similares, si la web no es muy pequeña se puede sincronizar el contenido de uno a otro, si ya tiene un tamaño considerable necesitaríamos un almacenamiento externo y cambiaríamos a un esquema de «frontal + backend«, que por supuesto también tendría que estar por duplicado.

A esto le añadimos un dos balanceadores para que en caso de fallo de un servidor, se pasen las peticiones a otro. Ya con esto, ¡hemos pasado de 1 servidor a 6! Cada uno cargado hasta los dientes de fuentes, discos duros, pero tenemos ya nuestros 100KG de hierro para servir nuestra web, ¿o no?
 

2.- Software

 
Si hemos empezado a desarrollar la web en nuestro ordenador posiblemente que sea un desarrollo muy simple, ahora hemos escalado y tenemos varios servidores: ¿Está nuestro software preparado para ello? Tenemos que investigar en sistemas de caché compartida como Memcached o Redis. Además la base de datos tiene que estar también replicada y ya se empieza a escuchar por la oficina la pregunta de, «¿alguien sabe cuánto vale una licencia de SQL Server con replicación?».

¿Qué pasa si una petición cae en un servidor y este falla? ¿Y para pasar a producción nuevo software? Eso también es algo que se complica según crecen las plataformas.

3.- Alojamiento y conectividad

 
Tenemos nuestra web ya adaptada a varios servidores (da igual que sean físicos o en Cloud con sistemas tipo AWS, el Cloud no deja de ser el ordenador de otra persona) y ahora la tenemos que alojar en un CPD. ¿Y si ese CPD falla? Habrá que duplicarlo todo en otro CPD. ¿Y las IPs? ¿Mi proveedor tiene IPs anycast o sistemas que me permitan actualizar DNS en tiempo real?

Con esto ya acabamos de duplicar todo el coste del servicio anterior, no está mal para haber empezado con una web alojada en un servidor.

4.- Personal y procedimientos

 
Ahora que ya tenemos nuestra web en dos CPDs y 10, 20 o 30 servidores distribuidos por el globo necesitamos gente que la mantenga 24×7. Esto significa que haya como mínimo 3 personas trabajando 8 horas seguidas y que todas ellas sepan solucionar los problemas (horas de formación, escribir procedimientos, etc.). Pero claro, si se cogen vacaciones o están de baja… suma y sigue. Además aquí ya nos encontramos con problemas que se escapan del campo de TI, es mejor tratar de arreglar problemas de la capa 8 del modelo OSI de forma técnica 😉

Hay que probar que funcionen bien los sistemas que hemos montado, por ejemplo en Netflix tiene un ejército de monos que desconectan desde servicios de un servidor, pasando por un servidor completo y llegando a tumbar CPDs enteros para probar la resilencia de sus sistemas. Otros igual no tenemos de eso pero podemos tener al personal de limpieza apagando un router al pasar la aspiradora (si me diesen un euro cada vez que le ha ocurrido eso a un cliente…) o un cable de red que no hace bien click al conectarlo y se ha soltado al pasar por delante.

Encontrar el equilibrio

 
Como vemos, el «desde dirección me piden un 100% de disponibilidad, no puede estar ni un minuto caído el sistema» es algo imposible de conseguir, y acercarse supone un desembolso enorme para algo que posiblemente ni notemos. Que algo pueda estar caído 7 horas al mes (99% de disponibilidad) no significa ni mucho menos que vaya a ser seguido

¿Podemos vivir con 5 minutos de caída para aplicar unos parches de seguridad?

Si somos Amazon o British Airways quizá no, pero aunque estos gigantes tienen recursos suficientes, podemos ver con el problema de hace poco de British Airways, o el último fallo de S3 de Amazon, que siempre puede ocurrir un imprevisto y tenemos que estar preparado para ello (aunque ya lo revisaremos en otro post) ya que como dijo Mat Cauthon en «La Rueda del Tiempo», «Todo cambia, el mejor plan aguanta hasta que la primera flecha sale del arco».

Contacta ahora con Sarenet

Créditos de las imágenes:
Foto servidores: Torkild Retvedt – CC BY-SA 2.0.
Foto cabecera: Sarenet 🙂