Uso de Keepalived para administrar la conmutación por error simple en clústeres

Cuando escucha el término "alta disponibilidad", puede pensar en entornos grandes y complejos con tecnologías oscuras que están fuera del alcance del administrador de sistemas promedio. Pero la alta disponibilidad básica no tiene por qué ser complicada: en esta serie, aprenderá a implementar servicios básicos de alta disponibilidad utilizando Keepalived. Lo guiaré a través de situaciones de conmutación por error simples, así como una configuración más compleja que se usa para responder a eventos externos y desencadenar conmutaciones por error. Primero, comenzaremos con los fundamentos de Keepalived y el Virtual Router Redundancy Protocol (VRRP).

Este artículo es el primero de una serie de tres artículos que cubren todo, desde la configuración básica hasta los conceptos avanzados de HA de Linux.

Índice

Keepalived y los conceptos básicos de VRRP

Si ha leído algunos de los artículos de redes Habilitar Sysadmin, sabe que todos los administradores de sistemas pueden beneficiarse de una sólida comprensión de los fundamentos de las redes. el conocimiento de Keepalived no es diferente El protocolo que respalda la conmutación por error de alta disponibilidad es el Virtual Router Redundancy Protocol (VRRP), y Keepalived proporciona una implementación de la versión 2 y la versión 3 de este protocolo.

Puede parecer extraño que usemos un protocolo diseñado para enrutadores en nuestros servidores. Resulta que la misma tecnología de red utilizada para proporcionar redundancia en equipos de red también puede proporcionar redundancia en entornos de servidor. Los enrutadores a menudo se implementan en pares, donde un enrutador está activo y otro en espera, listo para operar si falla el enrutador activo. Estos mismos conceptos se pueden aplicar a los servidores.

VRRP utiliza el concepto de dirección IP virtual (VIP). Uno o más hosts (enrutadores, servidores, etc.) participan en una elección para determinar qué host controlará este VIP. Solo un host (el maestro) controla el VIP a la vez. Si el maestro falla, VRRP proporciona mecanismos para detectar esta falla y conmutar rápidamente a un host de respaldo. En la topología anterior, server1 es el maestro y es responsable de la dirección IP 192.168.122.200. Si el servidor 1 se cae, el servidor 2 se hace cargo de esta IP.

También vale la pena ser consciente de que Keepalived proporciona más que solo VRRP Implementación. Keepalived también tiene la capacidad de configurar Servidores Virtuales IP Linux para balanceo de carga. Configurar IPVS está fuera del alcance de esta serie, pero es bueno saber que puede usar Keepalived para configurar un equilibrador de carga redundante todo en uno para su entorno.

Cómo funciona VRRP

VRRPel comportamiento de está especificado por RFC 3768 (versión 2) y RFC 5798 (Versión 3). Usaré la versión 2 en esta serie de artículos. Aunque revisar el RFC es la mejor manera de comprender completamente el comportamiento del protocolo, no necesita ser un experto para comenzar a usar Keepaliveden tu entorno Sin embargo, los conocimientos básicos sobre VRRPSu comportamiento lo posicionará mejor para usarlo y solucionar problemas en su entorno.

El primer paso en VRRPes la elección de un maestro para determinar qué servidor (o enrutador, en la especificación del protocolo) tendrá la dirección IP compartida. VRRP los servidores están configurados con un valor de prioridad, que se puede considerar como un peso. El servidor con mayor prioridad será el propietario de un VRRP habla a. La especificación indica que la prioridad del maestro debe ser 255, con todos los servidores de copia de seguridad con un valor inferior a 255. En la práctica, una prioridad de 255 no es estrictamente necesario porque el protocolo seleccionará el servidor con la prioridad más alta, incluso si no lo es 255.

Una vez que se establece un maestro, todos los demás servidores escuchan los mensajes periódicos enviados por el maestro para indicar que todavía está activo. El maestro envía estos anuncios a intervalos regulares. Mientras el maestro esté vivo, atenderá el tráfico para el VIP y enviará anuncios. Si el maestro se desconecta por algún motivo, el servidor de respaldo con la prioridad más alta se hará cargo. De manera similar, una característica llamada preferencia puede permitir que cualquier servidor con una prioridad más alta se convierta automáticamente en maestro cuando se conecte.

Cuando un maestro se conecta por primera vez y toma el control de una dirección IP, transmite un ARP gratuito. Este mensaje informa a otros servidores en la red de la dirección MAC asociada con el VIP para que puedan dirigir correctamente su tráfico en la Capa 2. También acelera la conmutación por error de VIP: los hosts no tienen que esperar a que caduquen sus temporizadores ARP y simplemente pueden actualizar sus tablas ARP con la dirección MAC correcta para el host que posee el VIP.

formato de paquete

Profundizar en los aspectos teóricos de cómo funciona un protocolo puede ser un poco aburrido, pero es esencial para comprender cómo funciona una tecnología (y solucionar los problemas cuando falla). Si echa un vistazo a la estructura del paquete de un VRRP publicidad usando Tiburón alambre, algunas cosas se vuelven más claras.

Primero, notará que las direcciones de destino IP y Ethernet están multicast direcciones. El tráfico de multidifusión, como sugiere el nombre, se envía a múltiples hosts en una red que "escucha" esa dirección de multidifusión. La mayoría de las redes evitan la configuración compleja de multidifusión, por lo que el tráfico de multidifusión para VRRP se convertirá en tráfico de difusión en el segmento de la red local y se dirigirá a todos los hosts.

También puedes ver que VRRP no es ni TCP ni UDP. VRRP utiliza el protocolo IP número 112 para su funcionamiento. Conocer este número de protocolo puede ser importante, ya que es posible que deba configurar el firewall de su host para permitir este tráfico desde el VRRP servidores de su entorno.

Una vez que empiezas a ver el VRRP sección del paquete, notará que contiene toda la información necesaria para elegir un maestro y notificar a otros servidores del maestro actual:

  • ID de enrutador virtual (VRID) es un identificador único para un VRRP instancia y sus direcciones IP (puede haber varias) en una red. Debe evitar reutilizar los VRID en la misma red local, pero se pueden reutilizar de manera segura en diferentes redes de capa 2.
  • La prioridad es la prioridad del host que envía el anuncio. Una vez que se elige un maestro, es independientemente de la prioridad establecida del maestro. El estricto cumplimiento de la especificación debe utilizar 255 para la prioridad maestra, pero muchas configuraciones eligen un valor diferente.
  • El tipo de autenticación y la cadena de autenticación contienen una contraseña de texto sin formato para autenticar a los miembros del VRRP agruparse unos con otros.
  • El intervalo de anuncios indica la frecuencia con la que el maestro enviará anuncios. En este caso, el maestro enviará un anuncio cada segundo.
  • La dirección IP contiene una o más direcciones IP de las que es responsable el maestro. Aunque esta serie solo cubre la conmutación por error de una sola dirección IP, es posible tener VRRP gestionar varias direcciones IP.

Conclusión

Este artículo le ha presentado el protocolo básico detrás Keepalived, una implementación de software de VRRP en Linux. Si bien mirar los detalles de los protocolos puede parecer aburrido, es esencial comprender los protocolos de red que operan en su entorno para que pueda configurarlos y solucionarlos de manera efectiva. En el próximo artículo aprenderá a instalar y configurar Keepalived.

Artículos de interés

Subir