Con una mayor demanda de infraestructuras confiables y de alto rendimiento diseñadas para servir a sistemas críticos, los términos escalabilidad y alta disponibilidad no podrían ser más populares. Si bien manejar una mayor carga del sistema es una preocupación común, la disminución del tiempo de inactividad y la eliminación de puntos únicos de falla son igual de importantes.
La alta disponibilidad es una calidad de diseño de infraestructura a escala que aborda estas últimas consideraciones.
En esta guía, discutiremos qué significa exactamente alta disponibilidad y cómo puede mejorar la confiabilidad de su infraestructura.
Indice
¿Qué es la alta disponibilidad?
En informática, el término disponibilidad se utiliza para describir el período de tiempo en que un servicio está disponible, así como el tiempo requerido por un sistema para responder a una solicitud realizada por un usuario.
La alta disponibilidad es la calidad de un sistema o componente que asegura un alto nivel de rendimiento operativo durante un período de tiempo determinado.
Disponibilidad de medición
La disponibilidad a menudo se expresa como un porcentaje que indica cuánto tiempo de actividad se espera de un sistema o componente en particular en un período de tiempo determinado, donde un valor del 100% indicaría que el sistema nunca falla.
Por ejemplo, un sistema que garantiza el 99% de disponibilidad en un período de un año puede tener hasta 3.65 días de tiempo de inactividad (1%).
Estos valores se calculan en función de varios factores, incluidos los períodos de mantenimiento programados y no programados, así como el tiempo para recuperarse de una posible falla del sistema.
¿Cómo funciona la alta disponibilidad?
La alta disponibilidad funciona como un mecanismo de respuesta a fallas para la infraestructura. La forma en que funciona es bastante simple conceptualmente, pero generalmente requiere un software y configuración especializados.
¿Cuándo es importante la alta disponibilidad?
Al configurar sistemas de producción robustos, minimizar el tiempo de inactividad y las interrupciones del servicio a menudo es una alta prioridad.
Independientemente de cómo tus sistemas y software son confiables, pueden ocurrir problemas que pueden derribar tus aplicaciones o tus servidores. La implementación de alta disponibilidad de la infraestructura es una estrategia útil para reducir el impacto de este tipo de eventos.
Los sistemas de alta disponibilidad pueden recuperarse de la falla del servidor o componente automáticamente.
Elementos de alta disponibilidad
En esta sección, repasaremos la función de cada componente de la configuración de alta disponibilidad y explicaremos cómo funcionan las piezas juntas. Hay una serie de combinaciones de software para realizar cada tarea en una configuración de alta disponibilidad, y el software mencionado en esta sección sirve como solo una posible solución para crear un sitio o aplicación altamente disponible.
Sistema de archivos
Para almacenar cargas y complementos, tu sitio necesitará un sistema de archivos en red.
En una configuración de alta disponibilidad, se utiliza un volumen replicado distribuido para almacenar archivos. Puedes pensar en el volumen como todo el sistema de archivos compartidos en todos los servidores. El volumen está compuesto de ladrillos, que son los directorios de archivos compartidos en cualquier servidor.
Una de las ventajas de usar GlusterFS para el clúster del sistema de archivos es que maneja la monitorización y la conmutación por error de forma predeterminada, lo que lo convierte en una excelente opción al construir un sistema altamente disponible.
Base de datos
La base de datos almacena el contenido y las credenciales de usuario para tu sitio. Podemos usar Percona XtraDB , pero otros sistemas de administración de bases de datos funcionan de manera similar.
Una base de datos es particularmente importante cuando se usa un CMS como WordPress, ya que almacena la información que compone sus páginas y publicaciones.
En nuestra configuración, los nodos de la base de datos son un grupo de servidores XtraDB de Percona, que utilizan Galera para la replicación. Galera ofrece replicación sincrónica , lo que significa que los datos se escriben en los nodos de la base de datos secundaria al mismo tiempo que se escriben en el primario. Este método de replicación proporciona una excelente redundancia al clúster de la base de datos porque evita períodos de tiempo en los que los nodos de la base de datos no se encuentran en estados coincidentes. Galera también proporciona replicación multimaestro , lo que significa que cualquiera de los nodos de la base de datos puede responder a las consultas de los clientes.
Nuestra configuración también utiliza XtraBackup , un método eficiente de transferencia de instantáneas de estado . Esto significa que cuando un nuevo nodo se une al clúster, el nodo desde el cual está sincronizando datos (el donante) todavía está disponible para manejar consultas. Esto no solo ayuda con la eficiencia en la configuración inicial, sino que también permite un escalado horizontal casi perfecto a medida que crecen sus necesidades.
Servidor web
Los servidores web supervisan las solicitudes de contenido web y las atienden en consecuencia. Nuestra guía utiliza Apache HTTPD , pero otros servidores web como NGINX y lighttpd también cumplirán esta función.
En la mayoría de las configuraciones, el servidor web leerá desde una base de datos para generar su contenido y escribirá en una base de datos si se completa un formulario. En un sitio web o aplicación dinámica, la base de datos es crucial para cumplir con las solicitudes web. El servidor web también almacena software, como WordPress, y complementos dentro del sistema de archivos.
El servidor Apache en nuestra configuración especifica la raíz del documento , o la ubicación desde la que sirve el contenido, como punto de montaje para nuestro clúster del sistema de archivos Gluster. Al hacer esto, Apache sirve ciertos archivos (como imágenes y activos CMS) no desde el servidor en el que se está ejecutando, sino desde un clúster de nodos altamente disponible. Cada nodo de Apache funciona de la misma manera, por lo que hay tres servidores web disponibles que pueden leer desde cualquiera de los tres servidores de archivos replicados.
La comunicación de Apache con los nodos de la base de datos funciona de manera similar. Debido a que el clúster de la base de datos tiene múltiples maestros, cualquiera de las bases de datos puede responder a las consultas de Apache. Debido a su replicación sincrónica, cuando Apache escribe en una base de datos, las demás se actualizan en tiempo real para atender solicitudes de cualquiera de los otros servidores de Apache.
Conmutación por error
La conmutación por error es el proceso por el cual un nodo se hace cargo del trabajo de otro en caso de que uno se deshabilite. Esto viene como resultado de la supervisión de fallas por parte del sistema.
Si bien GlusterFS maneja el monitoreo y la conmutación por error, se necesita un servicio separado para el clúster de la base de datos. Para esto, utilizamos Keepalived con una dirección IP de conmutación por error . La dirección IP de conmutación por error es simplemente una dirección IP privada que se puede reasignar entre nodos según sea necesario cuando uno falla.
Keepalived utiliza el protocolo de redundancia de enrutador virtual , o VRRP, para asignar automáticamente la dirección IP de conmutación por error a cualquiera de los nodos de la base de datos. El servicio keepalived utiliza reglas definidas por el usuario para monitorear un cierto número de fallas por parte de un nodo de la base de datos. Cuando se alcanza ese umbral de falla, keepalived asigna la dirección IP de conmutación por error a un nodo diferente para que no se interrumpa el cumplimiento de las solicitudes mientras el primer nodo espera a ser reparado.
Balanceo de carga
El componente de equilibrio de carga de un sistema de alta disponibilidad es uno de sus componentes más importantes, ya que actúa como la primera barrera para manejar el tráfico de los usuarios a los servidores de aplicaciones. Sin un equilibrador de carga, su sitio estaría alojado en tres servidores de aplicaciones que no tienen forma de asignar prioridad entre ellos.
Nuestra solución para el equilibrio de carga es NodeBalancer , un componente altamente disponible que distribuirá uniformemente el tráfico entrante a uno de los tres servidores de aplicaciones, asegurando que ningún servidor experimente una carga mucho más pesada que los demás.
El NodeBalancer es crítico porque proporciona un único punto de acceso sin un solo punto de falla. Ofrece monitoreo de back-end y conmutación por error en el nivel superior del sistema altamente disponible (el nivel inferior es manejado por Gluster FS y Keepalived).
¿Qué hace que un sistema esté altamente disponible?
Uno de los objetivos de alta disponibilidad es eliminar puntos únicos de fallo en tu infraestructura. Un único punto de fallo es un componente de tu pila de tecnología que causaría una interrupción del servicio si no estuviera disponible.
Como tal, cualquier componente que es un requisito para el funcionamiento correcto de la aplicación que no tiene la redundancia es considerado como un único punto de fallo.
Para eliminar puntos únicos de fallo, cada capa de yu pila debe estar preparada para la redundancia.
Por ejemplo, imagina que tienes una infraestructura que consta de dos servidores web idénticos y redundantes detrás de un equilibrador de carga. El tráfico proveniente de los clientes se distribuirá por igual entre los servidores web, pero si uno de los servidores se cae, el equilibrador de carga redirigirá todo el tráfico al servidor en línea restante.
La capa del servidor web en este escenario no es un único punto de fallo porque:
- componentes redundantes para la misma tarea están en su lugar
- el mecanismo en la parte superior de esta capa (el equilibrador de carga) puede detectar fallos en los componentes y adaptar su comportamiento para una recuperación oportuna
Pero, ¿qué sucede si el equilibrador de carga se desconecta?
Con el escenario descrito, que no es raro en la vida real, la capa de equilibrio de carga en sí misma sigue siendo un punto único de fallo. Sin embargo, eliminar este único punto de fallo restante puede ser un desafío. Aunque puedes configurar fácilmente un equilibrador de carga adicional para lograr la redundancia, no hay un punto obvio por encima de los equilibradores de carga para implementar la detección y recuperación de fallos.
La redundancia por sí sola no puede garantizar una alta disponibilidad. Debe existir un mecanismo para detectar fallos y tomar medidas cuando uno de los componentes de su pila no esté disponible.
La detección y recuperación de fallos para sistemas redundantes se puede implementar utilizando un enfoque de arriba a abajo: la capa superior se hace responsable de monitorizar la capa inmediatamente debajo de ella para detectar fallos.
En nuestro escenario de ejemplo anterior, el equilibrador de carga es la capa superior. Si uno de los servidores web (capa inferior) no está disponible, el equilibrador de carga dejará de redirigir las solicitudes para ese servidor específico.
Este enfoque tiende a ser más simple, pero tiene limitaciones: habrá un punto en su infraestructura donde una capa superior no existe o está fuera de alcance, como es el caso de la capa de balanceador de carga. Crear un servicio de detección de fallos para el equilibrador de carga en un servidor externo simplemente crearía un nuevo punto único de fallo.
Con tal escenario, es necesario un enfoque distribuido. Se deben conectar varios nodos redundantes como un clúster donde cada nodo debe ser igualmente capaz de detectar y recuperar fallos.
Sin embargo, para el caso del equilibrador de carga, hay una complicación adicional, debido a la forma en que funcionan los servidores de nombres. La recuperación de una falo del equilibrador de carga generalmente significa una conmutación por error a un equilibrador de carga redundante, lo que implica que se debe realizar un cambio de DNS para apuntar un nombre de dominio a la dirección IP del equilibrador de carga redundante.
Un cambio como este puede llevar una cantidad considerable de tiempo para propagarse en Internet, lo que causaría un tiempo de inactividad grave en este sistema.
Una posible solución es utilizar el equilibrio de carga de round-robin de DNS. Sin embargo, este enfoque no es confiable, ya que deja la conmutación por error de la aplicación del lado del cliente.
Una solución más robusta y confiable es utilizar sistemas que permitan una reasignación flexible de direcciones IP, como IP flotantes.
La reasignación de direcciones IP bajo demanda elimina los problemas de propagación y almacenamiento en caché inherentes a los cambios de DNS al proporcionar una dirección IP estática que se puede reasignar fácilmente cuando sea necesario. El nombre de dominio puede permanecer asociado con la misma dirección IP, mientras que la propia dirección IP se mueve entre servidores.
¿Qué componentes del sistema se requieren para alta disponibilidad?
Hay varios componentes que deben tenerse en cuenta cuidadosamente para implementar la alta disponibilidad en la práctica.
Mucho más que una implementación de software, la alta disponibilidad depende de factores como:
- Medio ambiente: si todos tus servidores están ubicados en la misma área geográfica, una condición ambiental como un terremoto o una inundación podría destruir todo el sistema. Tener servidores redundantes en diferentes centros de datos y áreas geográficas aumentará la confiabilidad.
- Hardware: los servidores de alta disponibilidad deben ser resistentes a los cortes de energía y fallos de hardware, incluidos los discos duros y las interfaces de red.
- Software: toda la pila de software, incluido el sistema operativo y la propia aplicación, debe estar preparada para manejar fallos inesperados que podrían requerir un reinicio del sistema, por ejemplo.
- Datos: la pérdida de datos y la inconsistencia pueden ser causadas por varios factores, y no se limita a fallos en el disco duro. Los sistemas de alta disponibilidad deben tener en cuenta la seguridad de los datos en caso de fallo.
- Red: las interrupciones de red no planificadas representan otro posible punto de fallo para los sistemas de alta disponibilidad. Es importante que exista una estrategia de red redundante para posibles fallos.
¿Qué software se puede usar para configurar la alta disponibilidad?
Cada capa de un sistema altamente disponible tendrá diferentes necesidades en términos de software y configuración. Sin embargo, a nivel de aplicación, los equilibradores de carga representan una pieza esencial de software para crear cualquier configuración de alta disponibilidad.
HAProxy (proxy de alta disponibilidad) es una opción común para el equilibrio de carga, ya que puede manejar el equilibrio de carga en varias capas y para diferentes tipos de servidores, incluidos los servidores de bases de datos .
Al avanzar en la pila del sistema, es importante implementar una solución redundante confiable para el punto de entrada de su aplicación, normalmente el equilibrador de carga. Para eliminar este único punto de falla, como se mencionó anteriormente, necesitamos implementar un grupo de equilibradores de carga detrás de una IP flotante. Corosync y Pacemaker son opciones populares para crear dicha configuración, tanto en servidores Ubuntu como CentOS.
¿Cuál es la diferencia entre alta disponibilidad y redundancia?
La redundancia por sí sola no puede garantizar una alta disponibilidad. Un sistema también necesita mecanismos de detección de fallos.
También es esencial la capacidad de realizar pruebas de alta disponibilidad y la capacidad de tomar medidas correctivas cada vez que uno de los componentes de la pila no está disponible.
Los enfoques de arriba a abajo o distribuidos de alta disponibilidad pueden tener éxito, y las técnicas basadas en hardware o software para reducir el tiempo de inactividad también son efectivas.
La redundancia es un enfoque basado en hardware. Por otro lado, la implementación de estrategias de alta disponibilidad casi siempre involucra software.
Alta disponibilidad frente a tolerancia a fallos
La alta disponibilidad y la tolerancia a fallos se refieren a técnicas para brindar altos niveles de tiempo de actividad. Sin embargo, las estrategias de alta disponibilidad frente a fallos logran ese objetivo de manera diferente.
La informática tolerante a fallos exige redundancia completa en el hardware. Múltiples sistemas operan en conjunto para lograr tolerancia a fallos, duplicando aplicaciones idénticamente y ejecutando instrucciones juntas. Cuando el sistema principal falla, otro sistema debería hacerse cargo sin pérdida de tiempo de actividad.
Para lograr una informática tolerante a fallos, necesitas hardware especializado. Debe ser capaz de detectar inmediatamente fallos en los componentes y permitir que los múltiples sistemas se ejecuten en conjunto.
Este tipo de sistema retiene la memoria y los datos de los programas, lo cual es un gran beneficio. Sin embargo, puede llevar más tiempo adaptarse a fallos en redes y sistemas que son más complejos. Además, los problemas de software que hacen que los sistemas se bloqueen a veces pueden hacer que los sistemas redundantes que funcionan en tándem fallen de manera similar, causando un bloqueo en todo el sistema.
Por el contrario, una solución de alta disponibilidad adopta un enfoque basado en software en lugar de hardware para reducir el tiempo de inactividad del servidor. En lugar de utilizar hardware físico para lograr una redundancia total, un clúster de alta disponibilidad localiza un conjunto de servidores juntos.
Estos servidores de alta disponibilidad poseen capacidades de conmutación por error y se monitorizan entre sí. Si el servidor primario tiene problemas, solo uno de los servidores de respaldo necesita detectarlos. Luego puede reiniciar la aplicación problemática que disparó el servidor bloqueado.
Los sistemas de alta disponibilidad se recuperan rápidamente, pero también abren riesgos en el tiempo que tarda el sistema en reiniciarse. Los sistemas tolerantes a fallos protegen tu negocio contra equipos defectuosos, pero son muy caros y no protegen contra fallos de software.
Esto significa que en la mayoría de las verticales, especialmente los servicios basados en software, una arquitectura de alta disponibilidad tiene mucho sentido. Es altamente rentable en comparación con una solución tolerante a fallos, que no puede manejar los problemas de software de la misma manera.
Alta disponibilidad frente a recuperación ante desastres
Del mismo modo, es importante mencionar la diferencia entre alta disponibilidad y recuperación ante desastres aquí. La recuperación ante desastres (DR), tal como suena, es un plan integral para la recuperación de operaciones y sistemas críticos después de eventos catastróficos.
Sin embargo, si ha implementado un sistema de alta disponibilidad y tolerante a fallas, por ejemplo, ¿por qué participar en este tipo de planificación?
DR generalmente se enfoca en volver a estar en línea y funcionar después de un evento catastrófico. La alta disponibilidad se centra en fallas graves pero más típicas, como un componente o servidor con fallas. Un plan de recuperación de desastres puede hacer frente a la pérdida de una región entera, por ejemplo, aunque ambos están relacionados.
Implementar Arquitectura de Alta Disponibilidad
No importa el tamaño y el tipo de negocio, cualquier tipo de tiempo de inactividad del servicio puede ser costoso sin una solución de recuperación ante desastres en la nube.
Peor aún, puede causar daños permanentes a tu reputación. Al aplicar una serie de mejores prácticas enumeradas anteriormente, puedes reducir el riesgo de perder tus datos. También minimiza las posibilidades de tener problemas en el entorno de producción.
tus posibilidades de estar desconectado son mayores sin un sistema de alta disponibilidad.
Desde esa perspectiva, el coste del tiempo de inactividad supera dramáticamente los costes de una infraestructura de TI bien diseñada. En los últimos años, las soluciones de informática alojada y en la nube se han vuelto más populares que el soporte interno de soluciones. La razón principal de esto es el hecho de que reduce los costes de TI y agrega más flexibilidad.
No importa qué solución elijas, los beneficios de un sistema de alta disponibilidad son numerosos:
- Ahorra dinero y tiempo, ya que no es necesario reconstruir los datos perdidos debido al almacenamiento u otros fallos del sistema. En algunos casos, es imposible recuperar tus datos después de una interrupción. Eso puede tener un impacto desastroso en tu negocio.
- Menos tiempo de inactividad significa menos impacto en los usuarios y clientes. Esto conduce a una mejor productividad de tus empleados y garantiza la satisfacción del cliente.
- Se mejorará el rendimiento de tus aplicaciones y servicios.
- Evitará multas y sanciones si no cumples con los SLA del contrato debido a un problema del servidor.
A primera vista, la implementación puede parecer bastante compleja; sin embargo, puede traer enormes beneficios para los sistemas que requieren una mayor confiabilidad.