Unidad 3.5: Alta disponibilidad en el borde de la red
Introducción
Un punto de acceso público solo es tan disponible como la única interfaz de red que actualmente responde por él. Si esa interfaz pertenece a un servidor y dicho servidor se pierde, la dirección deja de responder y todos los clientes que la hayan almacenado en caché quedan desasistidos hasta que algo mueva la dirección a otro lugar. La pregunta arquitectónica en el borde de la red, por lo tanto, no es "cómo hago que un servidor sea confiable", sino "cómo mantengo una dirección pública estable respondiendo cuando lo que hay detrás de ella cambia". IONOS CLOUD le ofrece un primitiva específica para esto, IP failover, con un alcance preciso y acotado. Esta unidad aborda la HA en el borde como una decisión de diseño: lo que IP failover garantiza, lo que deliberadamente no garantiza y cómo se integra en el panorama más amplio de resiliencia que el Módulo 7 completa.
1. IP Failover: una dirección compartida entre NICs redundantes
IP failover es el mecanismo de la plataforma para un borde activo-pasivo. La función Cloud IP-Failover aprovisiona la misma dirección IP a múltiples interfaces de red que pertenecen a diferentes servidores virtuales en la misma LAN. Una NIC se designa como maestra y mantiene la dirección como su IP primaria; las otras NICs del grupo son réplicas que están listas para asumir la misma dirección. Cuando el servidor maestro falla, la dirección puede moverse a una NIC réplica, de modo que el punto de acceso público siga respondiendo sin que el cliente tenga que conocer una nueva dirección.
Lo que hace que esto funcione como un punto de acceso estable es que la dirección debe ser una IP pública reservada. Las direcciones generadas por DHCP no pueden utilizarse en un grupo de failover. Esta es la misma disciplina de reserva que aplicó al construir la topología de tres LANs en la Unidad 3.1: la dirección IPv4 reservada está vinculada a la región y persiste de forma independiente de cualquier servidor individual, que es exactamente la propiedad que un punto de acceso de alta disponibilidad necesita. El grupo de failover simplemente vincula esa dirección persistente a un conjunto de NICs candidatas y rastrea cuál de ellas la posee actualmente.
La propiedad más importante que debe internalizar es el límite de la garantía. IP failover proporciona el aprovisionamiento de la misma IP a múltiples interfaces. No monitorea la disponibilidad del servicio al que se accede a través de esa IP. La plataforma mueve una dirección entre NICs; no ejecuta una sonda de salud contra su aplicación, no decide que su servidor web está devolviendo errores y no activa un cambio en su nombre. La lógica de detección y decisión que promueve una réplica a maestra reside en su sistema operativo invitado. El patrón establecido es una capa de HA de software que se ejecuta en los propios servidores, por ejemplo keepalived que controla VRRP, o el propio mecanismo de HA de un dispositivo de un proveedor, que decide cuándo reclamar la dirección compartida y luego ejecuta el cambio. La plataforma proporciona el primitivo de dirección compartida; usted proporciona la lógica que decide cuándo realizar el failover. Esta es la división de trabajo recurrente que la plataforma establece entre el nivel de infraestructura y el nivel de aplicación, y en el borde es inusualmente marcada.
Dos restricciones adicionales dan forma a cada diseño que utiliza IP failover:
- La LAN debe ser pública (conectada a internet) y no debe contener un balanceador de carga. IP failover y un balanceador de carga gestionado son patrones de borde alternativos, no superpuestos: si un Managed Application Load Balancer o un Network Load Balancer ya está en la parte frontal de la capa, ese balanceador es la estructura de disponibilidad y IP failover no se aplica en la misma LAN.
- No se admiten direcciones MAC virtuales. Un diseño de failover no puede suponer una identidad de capa 2 portátil que viaje con la dirección; el cambio se produce en la capa IP, y la réplica responde con su propia MAC una vez que posee la dirección. Planifique el comportamiento de ARP/vecino y cualquier expectativa de ARP gratuito en consecuencia, ya que el software de HA del invitado es el que anuncia el cambio.
IP failover debe configurarse para todos los montajes de HA de este tipo; es la estructura nativa para un par activo-pasivo autogestionado detrás de una sola dirección pública, y la plataforma no documenta ninguna alternativa para esa forma específica.
2. Cuándo el conmutación de IP en el borde es la herramienta adecuada
La conmutación de IP ocupa un lugar en un conjunto limitado de diseños, y reconocer ese conjunto le impide aplicarla de manera incorrecta. La siguiente tabla contrasta las opciones de disponibilidad en el borde que tiene actualmente en este módulo.
| Constructo del borde | Lo que hace altamente disponible | Conciencia del estado de salud | Dónde se une | Ideal para |
|---|---|---|---|---|
| Conmutación de IP | Una IP pública reservada a través de NIC redundantes | Ninguna en el lado de la plataforma; el software de HA del invitado decide | Una LAN pública sin un equilibrador de carga administrado | Un par activo-pasivo autogestionado (firewall/NVA, un dispositivo en clúster) que posee su propia lógica de conmutación |
| Managed Application Load Balancer (L7) | Un punto de servicio público a través de muchos backends | Destinos con verificación de estado de salud, exclusión automática | Su propio front-end administrado (Unidad 3.3) | Capas HTTP/S sin estado que necesitan enrutamiento de contenido y terminación TLS |
| Managed Network Load Balancer (L4) | Un punto de servicio a través de muchos backends | Destinos con verificación de estado de salud | Su propio front-end administrado (Unidad 3.4) | Capas TCP/UDP y cifradas de extremo a extremo, generalmente orientadas a redes privadas |
| Conmutación de DNS (Unidad 3.7) | Un nombre a través de puntos de servicio en zonas o sitios diferentes | Su propia verificación de estado de salud externa (o el estado de salud del LB) reorienta el registro a través de la API; Cloud DNS no tiene conciencia del estado de salud | La ruta de resolución de DNS, no la ruta de datos | Conmutación entre zonas y entre sitios donde una sola IP no puede abarcar el dominio de falla |
La pregunta decisiva es si lo que está protegiendo gestiona su propia disponibilidad y necesita una dirección pública única y persistente, o si es una capa escalable horizontalmente sobre la cual un equilibrador administrado debería distribuir el tráfico. Un dispositivo virtual de red autogestionado, un firewall de software, o un servicio en clúster que espera poseer un VIP flotante es el candidato clásico para la conmutación de IP: ya ejecuta keepalived o un equivalente, y solo necesita que la plataforma permita que dos de sus NIC compartan una dirección reservada. Una capa web o API sin estado no lo es; esa pertenece detrás de un equilibrador de carga administrado, donde la verificación del estado de salud y la distribución de backends se manejan por usted.
La conmutación de IP también está limitada por el dominio de falla. Dado que el grupo de conmutación reside en una sola LAN, protege contra la pérdida de un servidor, no contra la pérdida de una zona de disponibilidad o una región. Ese es el punto donde los dos mecanismos siguientes toman el relevo.
3. Composición de HA en el borde con colocación multi-zona y conmutación por error de DNS
Ninguna construcción individual proporciona resiliencia de extremo a extremo, y diseñar como si lo hiciera es el error más común en el borde. La postura robusta es por capas, donde cada mecanismo cubre el dominio de fallo que el mecanismo inferior no puede cubrir.
En la base, la colocación multi-zona distribuye los miembros redundantes de cualquier par entre zonas de disponibilidad para que un fallo a nivel de zona no elimine ambas mitades a la vez. Esta es una decisión de colocación que se toma en el momento de la aprovisionamiento, e interactúa directamente con la HA en el borde: un par de conmutación por error de IP cuyo maestro y réplica se encuentran en la misma zona no obtiene ninguna ventaja cuando se pierde esa zona. Coloque los miembros en zonas diferentes y hágalo de manera deliberada, en lugar de aceptar una colocación automática que podría ubicarlos juntos. (Compute expone las zonas 1, 2 y Auto; "Auto" es conveniente, pero es exactamente la configuración que puede colocar silenciosamente un par redundante en la misma zona, por lo que debe especificar las zonas explícitamente para cualquier par de HA. El Módulo 7 retoma esta trampa de zona automática en el contexto de resiliencia.)
Por encima de la colocación, la conmutación por error de DNS cubre los dominios de fallo que una sola IP no puede abarcar. Una IP reservada y su grupo de conmutación por error están anclados a una región y una LAN; no pueden mover un punto de acceso a un segundo sitio o a una segunda región. Cuando el dominio de fallo que debe sobrevivir es mayor que una LAN, la dirección se eleva al nombre. Como se desarrolla en la Unidad 3.7, este es un patrón construido por el cliente, no un producto nativo: su propia comprobación de estado (un monitor externo, o una señal de la salud de los objetivos de un equilibrador de carga) detecta un punto de acceso inactivo y llama a la API de Cloud DNS para redirigir un registro con TTL bajo hacia uno saludable. Cloud DNS en sí mismo no es consciente del estado de salud; sirve el registro que usted configure y nunca cambia una respuesta por su cuenta. Esta es la forma de obtener conmutación por error automatizada entre zonas y sitios, dado que no existe un producto de conmutación por error gestionado. La conmutación por error de DNS solo dirige nuevas conexiones, por lo que las capas que se encuentran detrás deben ser sin estado para que el patrón sea seguro.
Leídas juntas, las tres capas forman una jerarquía clara: la conmutación por error de IP mantiene una única dirección pública respondiendo cuando un servidor muere en una LAN; la colocación multi-zona asegura que los miembros redundantes no compartan un destino a nivel de zona; y la conmutación por error de DNS redirige a los clientes cuando un punto de acceso, zona o sitio completo ha desaparecido. Cada una es necesaria, ninguna es suficiente por sí sola, y el diseño del borde consiste en elegir qué capas necesita realmente un punto de acceso dado.
FinCorp en el borde
Las cargas de trabajo reguladas de FinCorp se encuentran detrás de un dispositivo de cortafuegos de red autogestionado que el equipo de seguridad insiste en operar por sí mismo, por razones de política y auditoría. Ese dispositivo es el caso de libro de texto de conmutación por error de IP: dos instancias de cortafuegos en la LAN pública, maestro y réplica, compartiendo una única dirección IPv4 pública reservada, con el propio proceso de HA de los dispositivos decidiendo cuándo la réplica reclama la dirección. FinCorp coloca las dos instancias de cortafuegos en zonas de disponibilidad diferentes para que un fallo de zona no elimine ambas, y acepta que la plataforma no realizará comprobaciones de estado del servicio de cortafuegos por ellos; esa monitorización es responsabilidad del dispositivo. Para la capa web sin estado orientada al público que se encuentra detrás de ese cortafuegos, FinCorp no utiliza la conmutación por error de IP en absoluto; utiliza el Managed Application Load Balancer de la Unidad 3.3, porque esa capa escala horizontalmente y se beneficia de una distribución con comprobación de estado. La pregunta de entre sitios, sobrevivir a la pérdida de la región principal por completo, se pospone al diseño de conmutación por error de DNS de la Unidad 3.7 y al plan de continuidad del Módulo 7, porque ninguna IP de borde puede responder a ese requisito. La decisión se acumula: una IP reservada y un par de conmutación por error de IP para el dispositivo autogestionado, equilibrio de carga gestionado para las capas elásticas, y DNS como la capa de dirección entre dominios de fallo.
Resumen de la decisión
| Requisito | Elección | Restricciones estrictas | Notas |
|---|---|---|---|
| Mantener una IP pública única que responda en una pareja activa-pasiva autogestionada | Grupo de conmutación por error de IP | Solo IP pública reservada (sin DHCP); LAN pública sin Load Balancer; sin MAC virtual; usted ejecuta la lógica de HA dentro del invitado | La plataforma mueve la dirección; no realiza comprobaciones de estado de su servicio |
| Capa HTTP/S sin estado de alta disponibilidad en el borde | Managed Application Load Balancer (3.3) | Tiene su propio front-end; no puede compartir una LAN con un grupo de conmutación por error de IP | Con comprobaciones de estado y terminación de TLS |
| Capa TCP/UDP o cifrada de alta disponibilidad | Managed Network Load Balancer (3.4) | Tiene su propio front-end | Sin terminación de TLS; generalmente orientada a redes privadas |
| Sobrevivir a la pérdida de una zona | Colocación multizona de la pareja redundante | Establezca las zonas de forma explícita; no use Auto para una pareja de HA | Se compone bajo cualquiera de las opciones anteriores |
| Sobrevivir a la pérdida de un punto de extremo, zona o sitio completo | Conmutación por error de DNS orquestada por el cliente (3.7) | Las capas frontales deben ser sin estado; el RTO está acotado por el TTL; usted ejecuta la comprobación de estado, Cloud DNS no es consciente del estado | El sustituto construido por el cliente para un producto de conmutación por error gestionado |
La regla de selección: proteja una pareja autogestionada de dirección única con conmutación por error de IP; proteja una capa elástica con un Load Balancer gestionado; proteja contra la pérdida de una zona con colocación multizona explícita; y proteja contra la pérdida de un punto de extremo o sitio completo con conmutación por error de DNS. Los mecanismos se apilan; no se sustituyen entre sí.
Resumen
La alta disponibilidad en el borde de red de IONOS CLOUD se construye mediante composición, no a través de una única función. El failover de IP proporciona a un par activo-pasivo autogestionado una IP pública reservada estable que puede moverse entre NICs redundantes en la misma LAN pública, pero se detiene deliberadamente en la asignación de la dirección compartida: la detección de estado de salud y la decisión de ejecutar el failover residen en su invitado, y esta estructura no puede abarcar una LAN equilibrada de carga, utilizar una dirección DHCP ni depender de una MAC virtual. Alrededor de esta primitiva se superponen la colocación explícita en múltiples zonas para contrarrestar fallos a nivel de zona y el failover de DNS para redirigir a los clientes cuando un extremo o sitio completo ha desaparecido, lo cual es la respuesta de la plataforma a la ausencia de un producto de failover gestionado.
Puntos clave:
- El failover de IP asigna una IP pública reservada a través de múltiples NICs en diferentes servidores en la misma LAN pública; el maestro la mantiene, y las réplicas pueden asumirla.
- La plataforma no supervisa el estado de salud del servicio para el failover. La detección y la promoción son responsabilidad del cliente, generalmente una capa de HA del invitado como keepalived/VRRP o el propio HA de un dispositivo de un proveedor.
- El failover de IP requiere una IP pública reservada (sin DHCP), una LAN pública sin equilibrador de carga y no admite direcciones MAC virtuales.
- El failover de IP está destinado a pares de dirección única autogestionados; las capas sin estado elásticas deben colocarse detrás de un equilibrador de carga gestionado en su lugar.
- La HA del borde se compone con la colocación en múltiples zonas (para contrarrestar fallos de zona; establezca las zonas explícitamente, nunca Auto para un par redundante) y el failover de DNS (para contrarrestar la pérdida de extremo/zona/sitio), cada uno cubriendo un dominio de fallo que el otro no puede cubrir.
Terminología importante:
- Grupo de failover de IP: Un conjunto de NICs en diferentes servidores en una LAN pública que comparten una única IP pública reservada, con un maestro designado, que permite el failover activo-pasivo de la dirección.
- NIC maestro / réplica: Dentro de un grupo de failover, el maestro posee actualmente la dirección compartida como su IP principal; las réplicas están habilitadas para asumirla.
- HA activo-pasivo: Un modelo de redundancia en el que un nodo atiende el tráfico y un nodo en espera asume el control en caso de fallo, a diferencia del equilibrio de carga activo-activo.
Lectura adicional
- Unidad 3.3, Equilibrio de carga - Capa 7 (Aplicación), y Unidad 3.4, Equilibrio de carga - Capa 4 (Red), para la alternativa de borde del equilibrador de carga administrado.
- Unidad 3.7, DNS y enrutamiento de conmutación por error, para la dirección de conmutación por error entre zonas y entre sitios.
- Módulo 7, Operaciones, resiliencia y rendimiento, para la colocación en varias zonas, la trampa de zona automática y la imagen completa de continuidad del negocio.