Alta disponibilidad y redundancia
Se dice que un sistema de computación tiene alta disponibilidad cuando está diseñado para funcionar de manera continua sin interrupciones.
Dado que todo elemento físico está sujeto a errores y desgastes, la única manera de garantizar esto es mediante la redundancia.
La redundancia, simplemente, es contar con un elemento de backup que se activará automáticamente en caso de que el elemento principal falle.
En detalle
Visto lo de arriba, un sistema ideal de alta disponibilidad tendría que tener todos sus elementos redundados.
Claro, «algo» tiene que gobernar el funcionamiento de los elementos y decidir pasar el manejo al sistema de backup. A eso se le llama «failover» o conmutación por fallo.
A pesar de que a estas altura no parece sencillo lo explicado arriba, es todavía más complejo. Ese «failover» no solo pasa la actividad al sistema de backup sino que controlará el estado de los sistemas, recuperará las transacciones que fallaron o se perdieron y, en definitiva, restaurará el sistema a su estado óptimo en microsegundos. Al fin y al cabo se trata de que todo este desastre sea imperceptible para el usuario final.
Medir la disponibilidad
La disponibilidad suele medirse como un valor porcentual en que el 100% representa el ideal de que un sistema nunca cae.
Un 99%, que parece un muy buen valor, supondría que el sistema estará fuera de servicio 3,65 días en un año. Si lo piensas de esa forma, tres días y medio sin servicio, es inaceptable para según qué servicios.
Los tiempos de falta de servicio no tienen por qué ser únicamente fallos, también puede haber desconexiones controladas por mantenimiento, por ejemplo.
En cualquier caso, lo habitual es ofrecer disponibilidades del 99,999% (los cinco nueves) a nivel contractual (SLA). Aquí hablaríamos de algo más de 5 minutos de falta de servicio por año.
La importancia de la redundancia
Antes hemos explicado que la redundancia es la forma en que, en la práctica, conseguimos una alta disponibilidad. Cada sistema que sea crítico para nosotros debería de tener su contraparte redundante.
Un backup es una forma de respaldo importante. Conservar una copia de datos en una ubicación distinta a la original nos salvaguarda de que el disco en que los datos se almacenan se dañe y podamos perder dicha información.
Los servidores suelen tener más de un disco duro y suelen estar conectados mediante un RAID. Eso garantiza que si uno de los discos falla, el otro puede retomar el trabajo del primero.
La fuente de alimentación también es algo que requiere redundancia. Si una fuente da error el sistema tiene que poder recibir alimentación por la fuente redundante para seguir funcionando.
Incluso la conectividad puede ser redundante. Podemos tener dos proveedores de internet para dar conectividad a una red de servidores. Si uno de los proveedores falla, podremos seguir conectados a través del otro proveedor.
Por último, podemos hablar de georedundancia. Con ella evitamos una posible caída de parte o la totalidad de un datacenter. Y sí, puede pasar, ha pasado no hace mucho en Francia. ¿Cómo hacer? Teniendo sistemas redundados en distintos centros de datos.
Failover
Decíamos antes que es el mecanismo por el cual, ante un fallo de toda o una parte de un sistema, se activa el backup y los elementos de respaldo retoman el trabajo asegurando que el servicio no se ve afectado.
La caída de servicio puede ser fortuita o programada. En este último caso hablamos de «switchover«, dado que es un cambio manual.
Ambos acaban con lo que lamamos «failback«, que sería la vuelta a la normalidad.
Y, por último, para controlar el estado de los sistemas y poder activar el failover de manera automática, necesitamos algo llamado «heartbeat«. Es un método de conexión entre sistemas que lanza regularmente un saludo al que espera una respuesta. Cuando no hay respuesta al saludo, no hay conectividad, y se activa todo lo descrito arriba.
Y esto, ¿por cuánto me va a salir?
Obviamente, replicar toda a parte de una red tiene un coste añadido.
En cada caso el coste puede ser muy diferente, aunque básicamente depende del hardware.
En Kolmisoft, por ejemplo, sí que añadimos fees de instalación/configuración y un pequeño extra al valor mensual cuando existe redundancia.
Al final esto es como todo en la vida, poner en un lado de la balanza cuánto nos cuesta salvaguardarnos de posibles caídas y cuánto nos cuánto nos cuestan dichas caídas. Esto último es difícil de calcular porque no es el tiempo sin servicio sino el riesgo de perder un cliente que costó mucho tiempo y dinero captar.
Lo razonable, de hecho, es ir paso a paso, añadiendo la seguridad más crítica que sabemos que podemos compensar con ingresos y que nos permite ofrecer mayores garantías a nuestros clientes.