En el mundo real, puede haber situaciones en las que una caída en el rendimiento de sus servidores puede ocurrir por eventos que van desde un repentino pico de tráfico puede llevar a un repentino corte de energía. Puede ser mucho peor y sus servidores pueden quedar paralizados, independientemente de si sus aplicaciones están alojadas en la nube o en una máquina física. Estas situaciones son inevitables. Sin embargo, en lugar de esperar que no ocurra, lo que debe hacer es prepararse para que sus sistemas no sufran fallos.
La respuesta al problema es el uso de una configuración o arquitectura de alta disponibilidad (HA). La arquitectura de alta disponibilidad es un enfoque de definición de los componentes, módulos o implementación de servicios de un sistema que garantiza un rendimiento operativo óptimo, incluso en momentos de altas cargas. Aunque no hay reglas fijas para la implementación de sistemas de alta disponibilidad, en general hay algunas buenas prácticas que se deben seguir para sacar el máximo provecho de los mínimos recursos.
¿Por qué lo necesita?
Definamos el tiempo de inactividad antes de seguir adelante. El tiempo de inactividad es el período de tiempo en el que su sistema (o red) no está disponible para su uso, o no responde. El tiempo de inactividad puede causar enormes pérdidas a una empresa, ya que todos sus servicios quedan en suspenso cuando sus sistemas están fuera de servicio. En agosto de 2013, Amazon se cayó durante 15 minutos (tanto los servicios web como los móviles), y acabó perdiendo más de 66.000 dólares por minuto. Son cifras enormes, incluso para una empresa del tamaño de Amazon.
Hay dos tipos de paradas: programadas y no programadas. Un tiempo de inactividad programado es el resultado del mantenimiento, que es inevitable. Esto incluye la aplicación de parches, la actualización de software o incluso cambios en el esquema de la base de datos. Un tiempo de inactividad no programado es, sin embargo, causado por algún evento imprevisto, como un fallo de hardware o software. Esto puede ocurrir debido a cortes de energía o al fallo de un componente. Los tiempos de inactividad programados generalmente se excluyen de los cálculos de rendimiento.
El objetivo principal de la implementación de la arquitectura de Alta Disponibilidad es asegurarse de que su sistema o aplicación está configurada para manejar diferentes cargas y diferentes fallos con un mínimo o ningún tiempo de inactividad. Hay varios componentes que ayudan a conseguirlo, y los discutiremos brevemente.
¿Cómo se mide la disponibilidad?
Las organizaciones que planean utilizar completamente una infraestructura en la nube también deben ser capaces de satisfacer las demandas de disponibilidad 24/7. La disponibilidad puede medirse como el porcentaje de tiempo que los sistemas están disponibles.
x = (n – y) * 100/n
Donde n es el número total de minutos en un mes natural e y es el número total de minutos que el servicio no está disponible en el mes natural dado. La alta disponibilidad se refiere simplemente a un componente o sistema que está continuamente operativo durante un periodo de tiempo deseablemente largo. El estándar de disponibilidad de un producto o sistema, muy extendido pero casi imposible de alcanzar, se denomina «disponibilidad de cinco nueves» (99,999%). La alta disponibilidad es un requisito para cualquier empresa que espere proteger su negocio contra los riesgos que conlleva una interrupción del sistema. Estos riesgos pueden suponer una pérdida de millones de dólares en ingresos.
¿Vale realmente la pena el dinero?
El hecho de que optar por una arquitectura de alta disponibilidad le proporcione un mayor rendimiento está bien, pero también tiene un gran coste. Debe preguntarse si cree que la decisión está justificada desde el punto de vista de las finanzas.
Hay que decidir si el tiempo de actividad adicional merece realmente la pena por la cantidad de dinero que hay que invertir. Debe preguntarse hasta qué punto los posibles tiempos de inactividad pueden ser perjudiciales para su empresa y hasta qué punto sus servicios son importantes para el funcionamiento de su negocio.
¿Cómo lo conseguimos?
Ahora que se ha decidido por ello, hablemos de las formas de implementarlo. De forma no intuitiva, añadir más componentes a un sistema no ayuda a hacerlo más estable y a conseguir una alta disponibilidad. De hecho, puede provocar lo contrario, ya que un mayor número de componentes aumenta la probabilidad de fallos. Los diseños modernos permiten distribuir las cargas de trabajo entre múltiples instancias, como una red o un clúster, lo que ayuda a optimizar el uso de los recursos, maximizar el rendimiento, minimizar los tiempos de respuesta y evitar la sobrecarga de cualquier sistema en el proceso conocido como equilibrio de carga. También implica el cambio a un recurso de reserva como un servidor, componente o red en caso de fallo de uno activo, lo que se conoce como sistemas de conmutación por error.
Uso de múltiples servidores de aplicaciones:
Imagina que tienes un único servidor para prestar tus servicios y un pico repentino de tráfico provoca su fallo (o lo colapsa). En tal situación, hasta que su servidor se reinicie, no se pueden servir más peticiones, lo que conduce a un tiempo de inactividad.
La solución obvia en este caso es desplegar su aplicación en múltiples servidores. Necesitas distribuir la carga entre todos ellos, para que ninguno esté sobrecargado y el rendimiento sea óptimo. También puedes desplegar partes de tu aplicación en diferentes servidores. Por ejemplo, podría haber un servidor separado para manejar los correos o uno separado para procesar archivos estáticos como imágenes (como una Red de Entrega de Contenido).
Escalado de Bases de Datos:
Las bases de datos son las más populares y quizás una de las formas más simples conceptualmente para guardar los datos de los usuarios. Hay que recordar que las bases de datos son tan importantes para sus servicios como sus servidores de aplicaciones. Las bases de datos se ejecutan en servidores separados (como el RDS de Amazon) y son propensos a caídas también. Lo que es peor es que las caídas de las bases de datos pueden conducir a una pérdida de datos de los usuarios, lo que puede resultar costoso.
La redundancia es un proceso que crea sistemas con altos niveles de disponibilidad al lograr la detectabilidad de fallos y evitar los fallos de causa común. Esto puede lograrse manteniendo esclavos, que pueden intervenir si el servidor principal falla. Otro concepto interesante de escalado de bases de datos es la fragmentación. Un shard es una partición horizontal en una base de datos, donde las filas de la misma tabla que se ejecuta en un servidor separado.
Localizaciones geográficas diversificadas:
Escalar sus aplicaciones y luego sus bases de datos es un gran paso adelante, pero ¿qué pasa si todos los servidores están en la misma ubicación física y algo terrible como un desastre natural afecta al centro de datos en el que se encuentran sus servidores? Esto puede conducir a tiempos de inactividad potencialmente enormes.
Es, por tanto, imperativo que mantenga sus servidores en diferentes ubicaciones. La mayoría de los servicios web modernos le permiten seleccionar la ubicación geográfica de sus servidores. Debes elegir sabiamente para asegurarte de que tus servidores están distribuidos por todo el mundo y no localizados en una zona.
Dentro de este post, he tratado de tocar las ideas básicas que forman la idea de la arquitectura de alta disponibilidad. En definitiva, es evidente que ningún sistema puede resolver todos los problemas. Por lo tanto, hay que evaluar la situación con cuidado y decidir qué opciones son las más adecuadas. Esperamos que esto le haya introducido en el mundo de la arquitectura de alta disponibilidad y le haya ayudado a decidir cómo conseguirla por sí mismo.
¿Cuáles son las mejores prácticas?
Para frenar los fallos del sistema y mantener a raya los tiempos de inactividad tanto planificados como no planificados, el uso de una arquitectura de alta disponibilidad (HA) es muy recomendable, especialmente para las aplicaciones de misión crítica. Los expertos en disponibilidad insisten en que para que cualquier sistema tenga alta disponibilidad, sus partes deben estar bien diseñadas y rigurosamente probadas. El diseño y la posterior implementación de una arquitectura de alta disponibilidad pueden ser difíciles, dada la amplia gama de opciones de software, hardware y despliegue. Sin embargo, un esfuerzo exitoso suele comenzar con requisitos empresariales claramente definidos y comprendidos en su totalidad. La arquitectura elegida debe ser capaz de cumplir con los niveles deseados de seguridad, escalabilidad, rendimiento y disponibilidad.
La única manera de garantizar que los entornos informáticos tengan un nivel deseable de continuidad operativa durante las horas de producción es diseñándolos con alta disponibilidad. Además de diseñar adecuadamente la arquitectura, las empresas pueden mantener las aplicaciones cruciales en línea observando las mejores prácticas recomendadas para la alta disponibilidad.
- Copias de seguridad, recuperación y replicación de datos
El sello de un buen plan de protección de datos que proteja contra los fallos del sistema es una sólida estrategia de copia de seguridad y recuperación. Los datos valiosos nunca deben ser almacenados sin copias de seguridad adecuadas, replicación o la capacidad de recrear los datos. Todo centro de datos debe planificar por adelantado la pérdida o corrupción de datos. Los errores en los datos pueden crear problemas de autentificación de los clientes, dañar las cuentas financieras y, posteriormente, la credibilidad de la comunidad empresarial. La estrategia recomendada para mantener la integridad de los datos consiste en crear una copia de seguridad completa de la base de datos primaria y, a continuación, probar de forma incremental el servidor de origen para detectar corrupciones de datos. La creación de copias de seguridad completas está a la vanguardia de la recuperación de un fallo catastrófico del sistema.
- Clustering
Incluso con la más alta calidad de ingeniería de software, todos los servicios de aplicación están destinados a fallar en algún momento. La alta disponibilidad consiste en ofrecer servicios de aplicación independientemente de los fallos. Los clústeres pueden proporcionar servicios de aplicación de conmutación por error instantánea en caso de fallo. Un servicio de aplicación que es «consciente de los clústeres» es capaz de llamar a los recursos de múltiples servidores; vuelve a un servidor secundario si el servidor principal se desconecta. Un clúster de alta disponibilidad incluye varios nodos que comparten información a través de redes de memoria de datos compartidas. Esto significa que cualquier nodo puede desconectarse o apagarse de la red y el resto del clúster seguirá funcionando con normalidad, siempre que al menos un nodo sea totalmente funcional. Cada nodo puede actualizarse individualmente y volver a unirse mientras el clúster funciona. El alto coste de la compra de hardware adicional para implementar un clúster puede mitigarse configurando un clúster virtualizado que utilice los recursos de hardware disponibles.
- Equilibrio de la carga de la red
El equilibrio de la carga es una forma eficaz de aumentar la disponibilidad de las aplicaciones críticas basadas en la web. Cuando se detectan instancias de fallo del servidor, se sustituyen sin problemas al redistribuir automáticamente el tráfico a los servidores que siguen funcionando. El balanceo de carga no sólo conduce a una alta disponibilidad, sino que también facilita la escalabilidad incremental. El equilibrio de la carga de la red puede llevarse a cabo mediante un modelo «pull» o «push». Facilita niveles más altos de tolerancia a fallos dentro de las aplicaciones de servicio.
- Soluciones de conmutación por error
La arquitectura de alta disponibilidad consiste tradicionalmente en un conjunto de servidores débilmente acoplados que tienen capacidades de conmutación por error. La conmutación por error es básicamente un modo operativo de reserva en el que las funciones de un componente del sistema son asumidas por un sistema secundario en caso de que el primario se desconecte, ya sea por un fallo o por un tiempo de inactividad planificado. Una «conmutación por error en frío» se produce cuando el servidor secundario sólo se pone en marcha después de que el primario se haya apagado por completo. Una «conmutación por error en caliente» se produce cuando todos los servidores están funcionando simultáneamente, y la carga se dirige por completo hacia un único servidor en un momento dado. En ambos casos, las tareas se descargan automáticamente en un componente del sistema en espera para que el proceso sea lo más fluido posible para el usuario final. La conmutación por error puede gestionarse a través de DNS, en un entorno bien controlado.
- Redundancia geográfica
La georredundancia es la única línea de defensa cuando se trata de evitar el fallo del servicio ante eventos catastróficos como los desastres naturales que provocan cortes del sistema. Como en el caso de la georreplicación, se despliegan múltiples servidores en lugares geográficamente distintos. Las ubicaciones deben estar distribuidas globalmente y no localizadas en un área específica. Es crucial ejecutar pilas de aplicaciones independientes en cada una de las ubicaciones, para que en caso de que haya un fallo en una de ellas, la otra pueda seguir funcionando. Lo ideal es que estas ubicaciones sean completamente independientes entre sí.
- Planificar para el fracaso
A pesar de que aplicar las mejores prácticas para la alta disponibilidad es esencialmente planificar para el fracaso; hay otras acciones que una organización puede tomar para aumentar su preparación en caso de que un fallo del sistema provoque un tiempo de inactividad. Las organizaciones deben mantener datos de fallos o de consumo de recursos que puedan utilizarse para aislar los problemas y analizar las tendencias. Estos datos sólo pueden obtenerse mediante la supervisión continua de la carga de trabajo operativa. Se puede poner en marcha un servicio de ayuda a la recuperación para recopilar información sobre los problemas, establecer un historial de problemas y comenzar a resolverlos inmediatamente. Un plan de recuperación no sólo debe estar bien documentado, sino que debe probarse periódicamente para garantizar su viabilidad cuando se produzcan interrupciones imprevistas. La formación del personal en ingeniería de la disponibilidad mejorará sus habilidades para diseñar, desplegar y mantener arquitecturas de alta disponibilidad. También deben establecerse políticas de seguridad para frenar las incidencias de las interrupciones del sistema debidas a fallos de seguridad.
Ejemplo: Arquitectura de Alta Disponibilidad de FileCloud
El siguiente diagrama explica cómo los servidores de FileCloud pueden configurarse para Alta Disponibilidad para mejorar la fiabilidad del servicio y reducir el tiempo de inactividad. Haga clic aquí para obtener más detalles.