Cuando escucha el término "alta disponibilidad", puede pensar en entornos grandes y complejos con tecnologías arcanas 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 mediante Keepalived. . Lo guiaré a través de situaciones de conmutación por error simples, así como una configuración más compleja que se utiliza para responder a eventos externos y desencadenar la conmutación 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 alta disponibilidad de Linux.
Conceptos básicos de Keepalived y VRRP
Símbolos de red en los diagramas disponibles a través de VRT Network Equipment Extension, CC BY-SA 3.0.
Si ha leído algunos de los artículos sobre Habilitar redes de Sysadmin, entonces sabe que todos los administradores de sistemas pueden beneficiarse de una sólida comprensión de los fundamentos de la red. 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 sonar extraño que estemos usando un protocolo creado para enrutadores en nuestros servidores. Resulta que la misma tecnología de red utilizada para brindar redundancia a los equipos de red también puede brindar redundancia en entornos de servidor. Los enrutadores a menudo se implementan en pares, donde un enrutador está activo y otro en espera, listo para funcionar en caso de que falle el enrutador activo. Estos mismos conceptos pueden aplicarse a los servidores.
VRRP utiliza el concepto de una dirección IP virtual (VIP). Uno o más hosts (enrutadores, servidores, etc.) participan en una elección para determinar el host que controlará ese VIP. Solo un host (el maestro) controla el VIP a la vez. Si el maestro falla, VRRP proporciona mecanismos para detectar esa falla y conmutar rápidamente a un host en espera. 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 falla, el servidor 2 se hace cargo de esta IP.
También vale la pena tener en cuenta que Keepalived proporciona más que un simple VRRP implementación. Keepalived también tiene la capacidad de configurar servidores virtuales Linux IP para el equilibrio de carga. La configuración de 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.
Operación del protocolo VRRP
VRRP El 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. Si bien revisar el RFC es la mejor manera de comprender completamente el comportamiento del protocolo, no es necesario ser un experto para comenzar a usar Keepalived La implementación de en su entorno. Sin embargo, conocimientos básicos de VRRP El comportamiento de lo posicionará mejor para operarlo y solucionar problemas en su entorno.
El primer paso en VRRP La operación de es la elección de un maestro para determinar qué servidor (o enrutador, en la especificación del protocolo) mantendrá la dirección IP compartida. VRRP los servidores están configurados con un valor de prioridad, que puede considerarse como un peso. El servidor con mayor prioridad será el propietario de un VRRP dirección. La especificación indica que la prioridad del maestro debe ser 255 , con cualquier servidor de copia de seguridad que tenga un valor inferior a 255 . En la práctica, una prioridad de 255 no es estrictamente necesario ya que el protocolo seleccionará el servidor con la prioridad más alta, incluso si no es 255.
Una vez que se establece un maestro, todos los demás servidores escuchan 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 alguna razón, el servidor de respaldo con la prioridad más alta se hará cargo. Del mismo modo, una característica llamada preferencia puede permitir que cualquier servidor que tenga una prioridad más alta se convierta en maestro automáticamente cuando se conecte.
Cuando un maestro se conecta por primera vez y se hace cargo 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 su tráfico correctamente en la Capa 2. También hace que la conmutación por error de VIP sea más rápida:los hosts no tienen que esperar a que expiren sus temporizadores ARP y pueden simplemente actualice 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 del funcionamiento de un protocolo puede ser un poco aburrido, pero es fundamental para comprender cómo funciona una tecnología (y para solucionar los problemas cuando falla). Si observa la estructura del paquete de un VRRP publicidad usando Wireshark, algunas cosas se vuelven más claras.
Primero, notará que las direcciones de destino de Ethernet e IP son multicast direcciones. El tráfico de multidifusión, como su nombre lo indica, se envía a múltiples hosts en una red que están "escuchando" 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 servidor de seguridad de su host para permitir este tráfico desde el VRRP. servidores en su entorno.
Una vez que empieces a mirar el VRRP sección del paquete, notará que contiene toda la información necesaria para elegir un maestro e informar a otros servidores del maestro actual:
- Identificación de enrutador virtual (VRID) es un identificador único para un
VRRPinstancia y sus direcciones IP (puede haber más de una) en una red. Debe evitar reutilizar los VRID en la misma LAN, pero se pueden reutilizar de manera segura en diferentes redes de capa 2. - Prioridad es la prioridad para el host que envía el anuncio. Una vez que se elige un maestro, esta es cualquiera que sea la prioridad definida por el maestro. El cumplimiento estricto de la especificación debe usar
255para la prioridad del maestro, pero muchas configuraciones eligen un valor diferente. - El tipo de autenticación y la cadena de autenticación contienen una contraseña de texto simple para autenticar a los miembros del
VRRPagruparse entre sí. - El intervalo de anuncios indica la frecuencia con la que el maestro enviará los 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. Si bien esta serie solo cubrirá la conmutación por error de una sola dirección IP, es posible tener
VRRPadministrar varias direcciones IP.
Conclusión
Este artículo lo guió a través del protocolo básico que sustenta a Keepalived , una implementación de software de VRRP en Linux. Si bien la revisión de las especificaciones de los protocolos puede parecer aburrida, es crucial comprender los protocolos de red que operan en su entorno para que pueda configurarlos y solucionar los problemas de manera efectiva. En el próximo artículo, aprenderá cómo instalar y configurar Keepalived .
[ ¿Necesita aprender más sobre la administración del sistema Linux? Considere tomar un curso de administración de sistemas de Red Hat. ]