Unidad 3.5: Alta disponibilidad en el borde de la red

Introducción

Un punto de conexión público es tan disponible como la única interfaz de red que actualmente responde por él. Si esa interfaz pertenece a un servidor y el servidor se pierde, la dirección deja de responder, y cada cliente que la ha almacenado en caché queda varado hasta que algo mueve la dirección a otro lugar. La pregunta arquitectónica en el borde de la red es, por lo tanto, no "¿cómo hago que un servidor sea confiable" sino "¿cómo mantengo una dirección pública estable que responda cuando lo que hay detrás de ella cambia". IONOS le proporciona un primitivo específico para esto, IP failover, con un alcance preciso y estrecho. Esta unidad trata la alta disponibilidad en el borde como una decisión de diseño: qué garantiza IP failover, qué deliberadamente no hace, y cómo se ajusta a la imagen más amplia de resiliencia que completa el Módulo 7.

1. IP Failover: Una dirección compartida en NICs redundantes

El failover de IP es el mecanismo de la plataforma para un borde activo-pasivo. La función de Cloud IP-Failover proporciona 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 dirección IP principal; las otras NIC en el grupo son réplicas que están listas para llevar la misma dirección. Cuando el servidor maestro falla, la dirección puede moverse a una NIC réplica, por lo que el punto de conexión público sigue respondiendo sin que el cliente tenga que aprender una nueva dirección.

Lo que hace que esto funcione como un punto de conexión estable es que la dirección debe ser una dirección pública IP reservada. Las direcciones generadas por DHCP no se pueden utilizar en un grupo de failover. Esta es la misma disciplina de reserva que aplicó al construir la topología de tres LAN 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, lo que es exactamente la propiedad que necesita un punto de conexión de alta disponibilidad. El grupo de failover simplemente vincula esa dirección persistente a un conjunto de NIC candidatas y rastrea cuál es la que actualmente la posee.

La propiedad más importante que debe internalizar es el límite de la garantía. El failover de IP proporciona la provisión de la misma dirección IP a múltiples interfaces. No supervisa la disponibilidad del servicio al que se accede a través de esa dirección IP. La plataforma mueve una dirección entre NIC; no ejecuta una sonda de salud contra su aplicación, decide que su servidor web está devolviendo errores y activa un conmutador en su nombre. La lógica de detección y decisión que promueve a una réplica a maestra vive en su sistema operativo invitado. El patrón establecido es una capa de alta disponibilidad de software que se ejecuta en los servidores mismos, por ejemplo, keepalived que impulsa VRRP, o el mecanismo de alta disponibilidad de un dispositivo de un proveedor, que decide cuándo reclamar la dirección compartida y luego impulsa el movimiento. La plataforma suministra el primitivo de dirección compartida; usted suministra los "cerebros" que deciden cuándo conmutar. Esta es la división recurrente de trabajo que la plataforma dibuja en el nivel de infraestructura versus el nivel de aplicación, y en el borde es inusualmente aguda.

Dos limitaciones adicionales dan forma a cada diseño que utiliza el failover de IP:

• La LAN debe ser pública (conectada a Internet) y no debe contener un Load Balancer. El failover de IP y un Load Balancer gestionado son patrones de borde alternativos, no superpuestos: donde un Managed Application Load Balancer o un equilibrador de carga de red Load Balancer ya se encuentra en el nivel, ese equilibrador es la construcción de disponibilidad y el failover de IP no se aplica en la misma LAN.
• No se admiten direcciones MAC virtuales. Un diseño de failover no puede asumir una identidad de capa 2 portátil que viaja con la dirección; el movimiento 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 ARP/vecino y cualquier expectativa de ARP gratuito según sea necesario, ya que el software de alta disponibilidad del invitado es lo que anuncia el movimiento.

El failover de IP debe configurarse para todos los conjuntos de alta disponibilidad; es la construcción nativa para un par activo-pasivo autoadministrado detrás de una dirección pública, y la plataforma no documenta ninguna alternativa para esa forma específica.

2. Cuando el failover de Edge IP es la herramienta adecuada

El failover de IP tiene su lugar en una banda estrecha de diseños, y reconocer esa banda evita que lo aplique incorrectamente. La siguiente tabla contrasta las opciones de disponibilidad de edge que ahora tiene a lo largo de este módulo.

La pregunta decisiva es si la cosa que está protegiendo administra su propia disponibilidad y necesita una dirección pública única, o si es una capa escalable horizontalmente que un equilibrador gestionado debe distribuir el tráfico. Un appliance de red virtual autoadministrado, un software Firewall, o un servicio agrupado que espera poseer una VIP flotante es el candidato clásico para el failover de IP: ya ejecuta keepalived o equivalente, y solo necesita que la plataforma permita que dos de sus NICs compartan una dirección reservada. Una capa web estatal o API no lo es; eso pertenece detrás de un Load Balancer gestionado, donde la comprobación de salud y la distribución de backend se manejan para usted.

El failover de IP también está limitado por el dominio de fallas. Debido a que el grupo de failover vive en un solo LAN, protege contra la pérdida de un servidor, no contra la pérdida de una zona de disponibilidad o una región. Esa es la costura donde los dos mecanismos siguientes toman el control.

3. Componiendo Edge HA con colocación multi-zona y conmutación por error de DNS

No hay un solo constructo que proporcione resistencia de extremo a extremo, y diseñar como si uno lo hiciera es el error de borde más común. La postura robusta es en capas, con cada mecanismo cubriendo el dominio de fallas que el de abajo no puede.

En la parte inferior, la colocación multi-zona dispersa los miembros redundantes de cualquier par a través de zonas de disponibilidad para que una falla a nivel de zona no afecte a ambas mitades al mismo tiempo. Esta es una decisión de colocación que se toma en el momento de la provisión, y que interactúa directamente con la alta disponibilidad de borde: un par de conmutación por error de IP cuyo maestro y réplica se encuentran en la misma zona no gana nada cuando se pierde esa zona. Coloque los miembros en diferentes zonas y sea deliberado al respecto, en lugar de aceptar una colocación automática que pueda colocarlos juntos. (Compute expone las zonas 1, 2 y Auto; "Auto" es conveniente, pero es exactamente la configuración que puede silenciosamente poner un par redundante juntos, así que nombre las zonas explícitamente para cualquier par de alta disponibilidad. El Módulo 7 vuelve a esta trampa de zona automática en el contexto de resistencia.)

Por encima de la colocación, la conmutación por error de DNS cubre los dominios de fallas que ningún solo IP puede abarcar. Un IP reservado y su grupo de conmutación por error están anclados a una región y un LAN; no pueden mover un punto de conexión a un segundo sitio o a una segunda región. Cuando el dominio de fallas que debe sobrevivir es más grande que un LAN, la dirección se mueve hacia arriba hacia el nombre. Como se desarrolla en la Unidad 3.7, este es un patrón construido por el cliente, en lugar de un producto nativo: su propia comprobación de salud (un monitor externo o una señal de la salud objetivo de un Load Balancer) detecta un punto de conexión muerto y llama al Cloud DNS API para reenviar un registro de baja TTL a uno saludable. Cloud DNS en sí mismo no es consciente de la salud; sirve cualquier registro que se configure y nunca cambia una respuesta por su cuenta. Esta es la forma de obtener conmutación por error automatizada a través de zonas y sitios, dado que no hay un producto de conmutación por error administrado. La conmutación por error de DNS solo dirige nuevas conexiones, por lo que los niveles que anteceden deben ser sin estado para que el patrón sea seguro.

Leídos juntos, los tres niveles forman una jerarquía clara: la conmutación por error de IP mantiene una sola dirección pública que responde cuando un servidor muere en un LAN; la colocación multi-zona garantiza 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 todo un punto de conexión, zona o sitio desaparece. Cada uno es necesario, ninguno es suficiente por sí solo, y el diseño de borde es el acto de elegir qué niveles realmente necesita un punto de conexión determinado.

FinCorp en el borde

Las cargas de trabajo reguladas de FinCorp se encuentran detrás de un dispositivo de red Firewall autoadministrado que el equipo de seguridad insiste en operar ellos mismos, por razones de política y auditoría. Ese dispositivo es el caso de conmutación por error de IP de libro de texto: dos instancias de Firewall en la red pública LAN, maestro y réplica, que comparten una dirección pública reservada, con el propio proceso de alta disponibilidad de los dispositivos decidiendo cuándo la réplica reclama la dirección. FinCorp coloca las dos instancias de Firewall en diferentes zonas de disponibilidad para que una falla de zona no pueda eliminar ambas, y acepta que la plataforma no realizará comprobaciones de salud del servicio Firewall para ellos; esa monitorización es el trabajo del dispositivo. Para el nivel web estatal sin estado que se encuentra detrás de ese Firewall, FinCorp no utiliza la conmutación por error de IP en absoluto; utiliza el Managed Application Load Balancer de la Unidad 3.3, porque ese nivel se escala horizontalmente y se beneficia de la distribución con comprobación de salud. La pregunta de sitio cruzado, sobreviviendo a la pérdida de la región principal en su totalidad, se difiere al diseño de conmutación por error de DNS en la Unidad 3.7 y al plan de continuidad en el Módulo 7, porque ningún IP de borde puede responder a ese requisito. La decisión se acumula: un IP reservado y un par de conmutación por error de IP para el dispositivo autoadministrado, equilibrio de carga administrado para los niveles elásticos, y DNS como la capa de dirección de fallas cruzadas.

Resumen de la decisión

La regla de selección: proteger un par de dirección única autoadministrado con conmutación por error IP; proteger una capa elástica con un Load Balancer administrado; proteger contra la pérdida de zona con colocación multi-zona explícita; y proteger contra la pérdida de un punto de conexión o sitio completo con conmutación por error DNS. Los mecanismos se superponen; no sustituyen uno por otro.

Resumen

La alta disponibilidad en el borde de la red de IONOS se construye por composición, no por una sola característica. El failover de IP da a un par activo-pasivo autoadministrado una dirección pública reservada estable de IP que puede moverse entre NICs redundantes en el mismo LAN público, pero deliberadamente se detiene en la provisión de la dirección compartida: la detección de salud y la decisión de conmutar por error viven en su invitado, y el constructo no puede abarcar un LAN con equilibrio de carga, utilizar una dirección DHCP o confiar en una MAC virtual. Alrededor de ese primitivo, se capa el posicionamiento multi-zona explícito para derrotar a los fallos a nivel de zona y el failover de DNS para redirigir a los clientes cuando todo un punto de conexión o sitio desaparece, lo que es la respuesta de la plataforma a no tener un producto de conmutación por error administrado.

Puntos clave:

• El failover de IP proporciona una dirección pública reservada de IP en múltiples NICs en diferentes servidores en el mismo LAN público; el maestro la mantiene, las réplicas pueden asumirla.
• La plataforma no supervisa la salud del servicio para el failover. La detección y promoción son responsabilidad del cliente, típicamente una capa de alta disponibilidad del invitado como keepalived/VRRP o la propia capa de alta disponibilidad de un dispositivo de un proveedor.
• El failover de IP requiere una dirección pública reservada de IP (no DHCP), un LAN público con ningún Load Balancer, y no admite direcciones MAC virtuales.
• El failover de IP es para pares de direcciones autoadministrados de una sola dirección; los niveles estatales elásticos pertenecen detrás de un Load Balancer administrado en su lugar.
• La alta disponibilidad en el borde se compone con el posicionamiento multi-zona (derrotar a los fallos de zona; establecer zonas explícitamente, nunca Auto para un par redundante) y el failover de DNS (derrotar la pérdida de punto de conexión/zona/sitio), cada uno cubriendo un dominio de fallo que el otro no puede.

Terminología importante:

• Grupo de failover de IP: Un conjunto de NICs en diferentes servidores en un LAN público que comparten una sola dirección pública reservada de IP, 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 actualmente posee la dirección compartida como su dirección principal de IP; las réplicas son elegibles para asumirla.
• Alta disponibilidad activo-pasiva: Un modelo de redundancia donde un Node sirve tráfico y un dispositivo de respaldo asume el control en caso de fallo, en oposición al 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 gestionado.
• Unidad 3.7, DNS y enrutamiento de conmutación por error, para la dirección de conmutación por error entre zonas y 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 empresarial.