Introducción a la informática de alta disponibilidad: conceptos y teoría

Centrémonos más en algunos de los principios arquitectónicos más amplios de la gestión de clústeres que en una única solución tecnológica.

Podemos ver algunas implementaciones reales más adelante en el libro, y puede aprender mucho sobre cómo funciona esto en AWS de Amazon en mi libro Aprenda los servicios web de Amazon en un mes de almuerzos de Manning. Pero por ahora, primero asegurémonos de que estamos cómodos con lo básico.

La ejecución de operaciones de servidor mediante clústeres de computadoras físicas o virtuales se trata de mejorar tanto la confiabilidad como el rendimiento por encima de lo que podría esperar de un solo servidor de alta potencia. Usted agrega confiabilidad al evitar colgar toda su infraestructura en un solo punto de falla (es decir, un solo servidor). Y puede aumentar el rendimiento a través de la capacidad de agregar muy rápidamente potencia y capacidad de cómputo al escalar hacia arriba y hacia afuera.

Esto puede suceder mediante la distribución inteligente de sus cargas de trabajo entre diversos entornos geográficos y de demanda (equilibrio de carga), proporcionando

Servidores de respaldo que pueden ponerse en servicio rápidamente en caso de que falle un nodo en funcionamiento (conmutación por error), optimizando la forma en que se implementa su nivel de datos o permitiendo tolerancia a fallas a través de arquitecturas poco acopladas.

Llegaremos a todo eso. Primero, sin embargo, aquí hay algunas definiciones básicas:

Nodo : una sola máquina (ya sea física o virtual) que ejecuta las operaciones del servidor de forma independiente en su propio sistema operativo. Dado que cualquier nodo puede fallar, cumplir los objetivos de disponibilidad requiere que varios nodos funcionen como parte de un clúster.

Clúster : dos o más nodos de servidor que se ejecutan en coordinación entre sí para completar tareas individuales como parte de un servicio más grande, donde la conciencia mutua permite que uno o más nodos compensen la pérdida de otro.

Fallo del servidor : la incapacidad de un nodo de servidor para responder adecuadamente a las solicitudes de los clientes. Esto podría deberse a un bloqueo total, problemas de conectividad o porque se ha visto abrumado por una gran demanda.

Conmutación por error : la forma en que un clúster intenta adaptarse a las necesidades de los clientes huérfanos por la falla de un solo nodo de servidor mediante el lanzamiento o la redirección de otros nodos para llenar un vacío de servicio.

Conmutación por recuperación : restauración de responsabilidades en un nodo del servidor a medida que se recupera de una falla.

Replicación : la creación de copias de almacenes de datos críticos para permitir un acceso sincrónico confiable desde múltiples nodos de servidor o clientes y para asegurar que sobrevivirán a desastres. La replicación también se usa para permitir un equilibrio de carga confiable.

Redundancia : El aprovisionamiento de múltiples nodos de servidor virtuales o físicos idénticos de los cuales cualquiera puede adoptar los clientes huérfanos de otro que falla.

Cerebro dividido : un estado de error en el que la comunicación de red entre los nodos o el almacenamiento compartido se ha roto de alguna manera y varios nodos individuales, cada uno de los cuales cree que es el único nodo que sigue activo, continúan accediendo y actualizando una fuente de datos común. Si bien esto no afecta los diseños de nada compartido, puede provocar errores en el cliente y corrupción de datos dentro de los clústeres compartidos.

Cercado : para evitar la división del cerebro, el demonio stonithd se puede configurar para cerrar automáticamente un nodo que funciona mal o para imponer una cerca virtual entre él y los recursos de datos del resto de un clúster. Siempre que exista la posibilidad de que el nodo todavía esté activo, pero no se coordine correctamente con el resto del clúster, permanecerá detrás de la valla. Stonith significa "Dispara al otro nodo en la cabeza". De Verdad.

Quórum : puede configurar el cercado (o apagado forzado) para que se imponga en los nodos que han perdido contacto entre sí o con algún recurso compartido. A menudo, el quórum se define como más de la mitad de todos los nodos del clúster total. Al usar estas configuraciones definidas, evita tener dos subgrupos de nodos, cada uno de los cuales cree que el otro no funciona correctamente, intentando eliminar al otro.

Recuperación ante desastres : Su infraestructura difícilmente puede considerarse de alta disponibilidad si no cuenta con un sistema de respaldo automatizado junto con un plan de recuperación ante desastres integrado y probado. Su plan deberá tener en cuenta la redistribución de cada uno de los servidores de su clúster.

Clúster activo / pasivo

La idea detrás de la conmutación por error del servicio es que la pérdida repentina de cualquier nodo en un clúster de servicios se compensaría rápidamente con otro nodo que ocuparía su lugar. Para que esto funcione, la dirección IP se mueve automáticamente al nodo en espera en caso de una conmutación por error. Alternativamente, las herramientas de enrutamiento de red como los equilibradores de carga se pueden utilizar para redirigir el tráfico lejos de los nodos fallidos. La forma precisa en que ocurre la conmutación por error depende de la forma en que haya configurado sus nodos.

Solo se configurará inicialmente un nodo para atender a los clientes y continuará haciéndolo solo hasta que falle de alguna manera. La responsabilidad de los clientes nuevos y existentes se trasladará (es decir, "conmutación por error") al nodo pasivo, o de respaldo, que hasta ahora se ha mantenido pasivamente en reserva. Al aplicar el modelo a varios servidores o componentes de la sala de servidores (como fuentes de alimentación), la redundancia n + 1 proporciona los recursos suficientes para la demanda actual más una unidad más para cubrir una falla.

Clúster activo / activo

Un clúster que utiliza un diseño activo / activo tendrá dos o más nodos configurados de forma idéntica que atienden a los clientes de forma independiente.

Si un nodo falla, sus clientes se conectarán automáticamente con el segundo nodo y, en la medida en que los recursos lo permitan, recibirán acceso completo a los recursos.

Una vez que el primer nodo se recupera o se reemplaza, los clientes se dividirán nuevamente entre ambos nodos del servidor.

La principal ventaja de ejecutar clústeres activos / activos radica en la capacidad de equilibrar de manera eficiente una carga de trabajo entre nodos e incluso redes. El equilibrador de carga, que dirige todas las solicitudes de los clientes a los servidores disponibles, está configurado para monitorear la actividad de los nodos y de la red y utilizar algún algoritmo predeterminado para enrutar el tráfico a los nodos que mejor pueden manejarlo. Las políticas de enrutamiento pueden seguir un patrón de operación por turnos, donde las solicitudes de los clientes simplemente se alternan entre los nodos disponibles, o por un peso preestablecido en el que un nodo se ve favorecido sobre otro por alguna proporción.

Tener un nodo pasivo que actúa como un reemplazo de reserva para su socio en una configuración de clúster activo / pasivo proporciona una redundancia incorporada significativa. Si su operación requiere absolutamente un servicio ininterrumpido y transiciones de conmutación por error sin problemas, entonces su objetivo debe ser alguna variación de una arquitectura activa / pasiva.

Clústeres de disco compartido y nada compartido

Uno de los principios rectores de la computación distribuida es evitar que su operación dependa de un solo punto de falla. Es decir, todos los recursos deben ser replicados de forma activa (redundantes) o reemplazables de forma independiente (conmutación por error), y no debe haber un solo elemento cuya falla pueda hacer caer todo el servicio.

Ahora, imagine que está ejecutando unas pocas docenas de nodos que dependen de un solo servidor de base de datos para su función. Aunque la falla de cualquier número de nodos no afectará la salud continua de los nodos que quedan, si la base de datos deja de funcionar, todo el clúster se volverá inútil. Sin embargo, los nodos en un clúster de nada compartido mantendrán (generalmente) sus propias bases de datos de modo que, suponiendo que estén sincronizados y configurados correctamente para la seguridad de las transacciones en curso, ninguna falla externa los afectará.

Esto tendrá un impacto más significativo en un clúster con equilibrio de carga, ya que cada nodo con equilibrio de carga tiene una necesidad constante y crítica de acceso simultáneo a los datos. Sin embargo, el nodo pasivo en un sistema de conmutación por error simple podría sobrevivir algún tiempo sin acceso.

Si bien tal configuración podría ralentizar la forma en que el clúster responde a algunas solicitudes, en parte porque los temores de fallas de cerebro dividido pueden requerir un cercado periódico a través de stonith, la compensación puede justificarse para implementaciones de misión crítica donde la confiabilidad es la consideración principal.

Disponibilidad

Al diseñar su clúster, deberá tener una idea bastante clara de cuán tolerante puede ser con las fallas. O, en otras palabras, dadas las necesidades de las personas o máquinas que consumen sus servicios, ¿cuánto tiempo puede durar una interrupción del servicio antes de que la turba entre por sus puertas delanteras con horquillas y antorchas encendidas? Es importante saber esto, porque la cantidad de redundancia que incorpore en su diseño tendrá un impacto enorme en los tiempos de inactividad que eventualmente enfrentará.

Obviamente, el sistema que construya para un servicio que puede dejar de funcionar durante un fin de semana sin que nadie se dé cuenta será muy diferente de un sitio de comercio electrónico cuyos clientes esperan acceso las 24 horas, los 7 días de la semana. Como mínimo, generalmente debe aspirar a un promedio de disponibilidad de al menos el 99%, y algunas operaciones requieren resultados del mundo real significativamente más altos. El 99% del tiempo de actividad se traduciría en una pérdida de menos de un total de cuatro días por año.

Existe una fórmula relativamente simple que puede utilizar para generar una estimación útil de Disponibilidad (A). La idea es dividir el tiempo medio antes de la falla por el tiempo medio antes de la falla más el tiempo medio de reparación.

A = MTBF / (MTBF + MTTR)

Cuanto más se acerque el valor de A a 1, mayor será la disponibilidad de su clúster. Para obtener un valor realista de MTBF, probablemente necesitará dedicar tiempo a exponer un sistema real a un castigo serio y observarlo cuidadosamente para detectar fallas de software, hardware y redes. Supongo que también puede consultar las métricas publicadas del ciclo de vida de los proveedores de hardware o consumidores a gran escala como Backblaze para tener una idea de cuánto tiempo se puede esperar que dure el hardware muy usado.

El MTTR será producto del tiempo que le toma a su clúster reemplazar la funcionalidad de un nodo de servidor que ha fallado (un proceso que es similar, aunque no idéntico, a la recuperación de desastres, que se enfoca en reemplazar rápidamente el hardware y la conectividad fallados). Idealmente, ese sería un valor lo más cercano a cero segundos como sea posible.

El problema es que, en el mundo real, generalmente hay demasiadas variables desconocidas para que esta fórmula sea realmente precisa, ya que los nodos que ejecutan diferentes configuraciones de software y construidos con hardware de diferentes perfiles y edades tendrán una amplia gama de expectativas de vida. Sin embargo, puede ser una buena herramienta para ayudarlo a identificar el diseño de clúster más adecuado para su proyecto.

Con esa información, puede generar fácilmente una estimación del tiempo total de inactividad que probablemente tendrá su servicio en el transcurso de un año completo.

Una consideración relacionada, si está implementando sus recursos en un proveedor de plataforma de terceros como VMWare o Amazon Web Services, es el Acuerdo de nivel de servicio (SLA) del proveedor. El EC2 de Amazon, por ejemplo, garantiza que sus instancias de cómputo y dispositivos de almacenamiento de almacenamiento en bloque entregarán un porcentaje de tiempo de actividad mensual de al menos 99,95%, que es menos de cinco horas de tiempo de inactividad por año. AWS emitirá créditos para los meses en los que no cumplieron sus objetivos, aunque no lo suficiente para compensar los costos comerciales totales de su tiempo de inactividad. Con esa información, puede organizar un nivel de redundancia de servicio que se adapte a sus necesidades específicas.

Naturalmente, como proveedor de servicios para sus propios clientes, es posible que deba publicar su propio SLA en función de sus estimaciones de MTBF y MTTR.

Manejo de sesiones

Para cualquier relación servidor-cliente, los datos generados por las sesiones HTTP con estado deben guardarse de manera que estén disponibles para interacciones futuras. Las arquitecturas de clúster pueden introducir una gran complejidad en estas relaciones, ya que el servidor específico con el que interactúa un cliente o usuario puede cambiar entre un paso y el siguiente.

Para ilustrarlo, imagine que está conectado a Amazon.com, hojeando sus libros sobre capacitación LPIC y agregando periódicamente un artículo a su carrito (con suerte, más copias de este libro). Sin embargo, cuando esté listo para ingresar su información de pago y realizar el pago, es posible que el servidor que utilizó para navegar ya no exista. ¿Cómo sabrá su servidor actual qué libros decidió comprar?

No sé exactamente cómo Amazon maneja esto, pero el problema a menudo se resuelve a través de una herramienta de replicación de datos como memcached que se ejecuta en un

nodo externo (o nodos). El objetivo es brindar acceso constante a una fuente de datos confiable y consistente para cualquier nodo que pueda necesitarla.

Este artículo está adaptado de " Aprenda usted mismo la virtualización de Linux y la alta disponibilidad: prepárese para el examen de certificación LPIC-3 304 ". Consulte mis otros libros sobre administración de AWS y Linux , incluidos Linux en acción y Linux en movimiento  , un curso híbrido compuesto por más de dos horas de video y alrededor del 40% del texto de Linux en acción.