Unidad 3.4: Equilibrio de carga - Capa 4 (Red)

Introducción

La Unidad 3.3 terminó TLS en un equilibrador de carga de capa 7 público porque el borde necesitaba leer HTTP y enrutar el contenido. El nivel de datos tiene el requisito opuesto. Habla con bases de datos y otros protocolos no HTTP, y la postura GDPR/BSI de FinCorp quiere que la carga esté cifrada desde el nivel de aplicación hasta la base de datos, sin intermediarios que puedan leerla. Un equilibrador de carga que tenga conocimiento del contenido no puede servir a ese nivel, y no debe intentarlo.

Esta unidad cubre el Managed Network Load Balancer (NLB), el equilibrador de carga TCP de capa 4 de la plataforma, y termina construyendo un NLB privado frente al nivel de datos de FinCorp dentro del centro de datos virtual que creó en la Unidad 3.1. La decisión de diseño es deliberadamente estrecha: distribuir conexiones TCP entre objetivos saludables sin descifrarlos ni inspeccionarlos nunca.

1. Paso de TCP de capa 4 y cuándo es la mejor opción

El Managed Network Load Balancer opera en la capa 4 del modelo OSI, en TCP/IP, y proporciona equilibrio de carga basado en conexiones. Es un elemento de VDC preconfigurado, completamente gestionado, desplegado en una configuración de alta disponibilidad y integrado en la red definida por software de la plataforma. Sirve como un único punto de entrada y salida para el tráfico del cliente: el listener acepta conexiones y las reglas de reenvío distribuyen las sesiones en varios objetivos de procesamiento para el procesamiento paralelo.

La propiedad definitoria es lo que el NLB no hace. Distribuye cualquier tráfico basado en TCP, incluyendo protocolos de capas superiores como HTTP y HTTPS, pero sus reglas de reenvío y comprobaciones de salud son estrictamente TCP. No se admiten decisiones de enrutamiento basadas en una URL o encabezado HTTP. El NLB nunca descifra la conexión, por lo que nunca termina TLS. Cuando un cliente abre una conexión cifrada, la sesión TLS se establece con el objetivo de backend, y el certificado y la clave privada viven en ese objetivo de backend, no en el equilibrador. Este es exactamente el comportamiento que quiere el nivel de datos.

Dos situaciones hacen que la capa 4 sea la elección obligatoria en lugar de una preferencia:

• Cifrado de extremo a extremo. Cuando el modelo de seguridad requiere que la carga útil permanezca cifrada desde el cliente (o el nivel de arriba) hasta el backend sin un salto de descifrado en el medio, un equilibrador de capa 7 es descalificado porque terminar TLS significa descifrar. El NLB pasa el flujo TCP cifrado sin tocarlo, por lo que el backend mantiene el certificado y sigue siendo el único lugar donde existe el texto plano. Para el camino de datos regulado de FinCorp, esto elimina al equilibrador del conjunto de componentes que manejan datos de cliente en texto plano, lo que simplifica la evaluación de protección de datos.
• Tráfico no HTTP. Los protocolos de base de datos (PostgreSQL, protocolos de cable MariaDB), corredores de mensajes y otros servicios TCP no son HTTP, por lo que no hay nada para que un equilibrador de capa 7 se base en ello. La capa 4 es el único nivel que encaja.

Dado que el NLB no puede leer el contenido de la aplicación, tampoco puede hacer nada que dependa del contenido: no hay reglas de ruta, no hay enrutamiento de host, no hay comprobaciones de salud HTTP-conscientes. Si necesita esas características, está en el nivel equivocado y la Unidad 3.3 es la respuesta. La presentación honesta es que las capas 4 y 7 no están clasificadas; se encuentran en diferentes puntos de la arquitectura y resuelven diferentes problemas.

1.1 Traducción de direcciones y modelo de conexión

Entender cómo fluye el tráfico a través del NLB explica varias de sus limitaciones. El NLB realiza una traducción de destino NAT (DNAT): las conexiones del cliente terminan en el Load Balancer, y el equilibrador luego inicia una conexión separada y dedicada al objetivo de backend elegido. No se admite la traducción de origen NAT (SNAT), lo que significa que los objetivos no pueden iniciar conexiones salientes a través del Load Balancer. El NLB es un dispositivo de distribución de entrada, no una ruta de salida. Cuando las cargas de trabajo privadas necesitan acceso a Internet, ese es el trabajo de la puerta de enlace NAT (SNAT solo, cubierto en la Unidad 3.6), y los dos productos son complementarios en lugar de intercambiables.

Dado que el equilibrador abre su propia conexión al objetivo, el backend ve por defecto la dirección del equilibrador en lugar de la del cliente original. Donde el backend necesita la dirección IP real del cliente (para registro, lógica geográfica o limitación de velocidad), habilite el protocolo Proxy en el objetivo para que se preserve y se reenvíe la información de la conexión original. El servicio de backend (por ejemplo, Apache, NGINX o un controlador de entrada en Cluster) debe estar configurado para esperar y analizar el encabezado del protocolo Proxy, o las conexiones fallarán.

1.2 Algoritmos de distribución y ponderación de canario

Una regla de reenvío lleva un algoritmo de distribución. El NLB ofrece cuatro:

• Round Robin: distribuye las conexiones en los objetivos en un orden circular y secuencial, honrando el peso de cada objetivo.
• Menos conexiones: envía la siguiente conexión al objetivo con la menor cantidad de conexiones activas, lo que es adecuado para sesiones de larga duración o sesiones desiguales.
• Aleatorio: distribuye las conexiones de forma aleatoria en los objetivos.
• Dirección IP de origen: asigna un cliente de forma coherente al mismo objetivo en función de su dirección de origen.

De forma independiente del algoritmo, el NLB mantiene las sesiones activas asignadas al mismo objetivo a través de la afinidad de dirección IP de origen (sesiones pegajosas) durante todo el tiempo que las sesiones TCP subyacentes permanecen activas. La afinidad de dirección IP de origen es lo que mantiene una conexión en un backend; seleccionar el algoritmo de dirección IP de origen extiende esa pegajosidad para mantener a un cliente determinado en el mismo servidor en todas las conexiones, lo que importa cuando los backends no comparten el estado TLS y desea evitar la renegociación contra un Node diferente.

Cada objetivo lleva un peso de 1 a 256, que predeterminadamente es 1, y el tráfico se distribuye en proporción al peso de un objetivo en relación con el peso combinado de todos los objetivos. Este es el mecanismo para un canario controlado. Para enviar aproximadamente el diez por ciento de las nuevas conexiones a una versión de candidato, registre el objetivo de canario con un peso bajo en comparación con los objetivos estables con mayor peso (por ejemplo, peso 1 en el canario contra peso 9 en el titular) y observe su salud y métricas antes de aumentar el peso. La ponderación dirige las nuevas conexiones solo; las sesiones ya asignadas por la afinidad de dirección IP de origen permanecen donde están hasta que se cierran, por lo que un cambio de peso se drena gradualmente en lugar de instantáneamente. Para FinCorp, la ponderación de canario permite que un nuevo servicio de acceso a datos tome una pequeña parte observable del tráfico real sin un corte de bandera.

2. Componiendo la capa pública 7 con la capa privada 4

La forma canónica en capas de la Unidad 1.2 coloca un equilibrador de carga de capa 7 público en el borde y un equilibrador de carga de capa 4 privado frente a la capa de datos. Los dos no son redundantes; cada uno hace lo que el otro no puede.

El equilibrador de carga de capa 7 público (Unidad 3.3) se encuentra en el borde público, termina TLS, y enruta HTTP por contenido a la capa de aplicación sin estado. El equilibrador de carga privado NLB se encuentra completamente en una red privada: su oyente se expone solo al tráfico interno, por lo que maneja conexiones de este a oeste dentro del centro de datos en lugar de tráfico de internet de norte a sur. La capa de aplicación abre conexiones TCP cifradas al oyente privado del NLB, el NLB las distribuye entre los objetivos de la capa de datos, y TLS se termina en esos objetivos. Ningún IP público toca la capa de datos, y ningún componente entre la aplicación y la base de datos puede leer la carga.

Esta composición también clarifica un límite de seguridad que atrapa a las personas. Los firewalls de NIC y Network Security Groups se unen a las NIC de los servidores solo; no se aplican a la solución de Load Balancer gestionada (Unidad 3.2). El NLB lleva reglas básicas de Firewall que se aplican automáticamente desde sus reglas de reenvío y no se pueden editar, pero no se puede adjuntar un NSG a él y no hay una lista de permitidos de IP en el equilibrador en sí. El control de acceso para la capa de datos, por lo tanto, pertenece a los firewalls de NIC de los objetivos y a la topología: el almacenamiento de datos LAN permanece privado, y lo único que debería llegar a él es la capa de aplicación a través del NLB. Mantener el NLB privado es en sí mismo un control principal, porque un oyente privado es inaccesible desde internet por construcción.

Una nota práctica sobre la colocación: en el Data Center Designer, el elemento NLB tiene dos interfaces. La interfaz norte es el oyente y se conecta hacia los clientes (un elemento de acceso a internet para un NLB público, o un almacenamiento de datos LAN privado para uno privado); la interfaz sur es el backend y se conecta al almacenamiento de datos LAN privado que contiene los objetivos. Para la capa de datos de FinCorp, tanto el lado del oyente como el lado del backend se quedan en LANs privadas.

DCD Implementación paso a paso

Construirá un equilibrador de carga de capa 4 privado frente al nivel de datos de FinCorp, reutilizando el VDC y la topología de tres LAN de la Unidad 3.1. El objetivo es un NLB privado cuyo oyente se enfrenta a la aplicación LAN y cuyo backend se enfrenta a los datos privados LAN, distribuyendo conexiones TCP cifradas entre los objetivos del nivel de datos sin terminar TLS. El requisito previo es que los objetivos (los servidores del nivel de datos) ya estén provisionados en una LAN privada; el NLB necesita objetivos existentes para distribuir sesiones.

Objetivo de la construcción: Construir un equilibrador de carga de capa 4 privado frente al nivel de datos.

Pasos (en el Data Center Designer):

1. Abra el VDC de FinCorp de la Unidad 3.1 en el Data Center Designer.
2. Arrastre el elemento de red Load Balancer al espacio de trabajo.
3. Conecte las dos interfaces del NLB. Conecte la interfaz norte (el oyente) a la aplicación LAN privada, para que el equilibrador se enfrente a los clientes internos en lugar de a Internet. Conecte la interfaz sur (el backend) a la LAN privada que contiene los objetivos del nivel de datos. Mantener ambos lados en LANs privadas es lo que hace que este sea un equilibrador de carga privado, de este a oeste.
4. En el Inspector, abra la pestaña de configuración y configure el oyente IP. Un NLB privado toma una IP privada; asígnela desde la aplicación LAN para que el nivel de la aplicación tenga una dirección estable a la que conectarse.
5. Abra la pestaña de reglas de reenvío y seleccione Agregar regla de reenvío. Asigne un nombre a la regla, elija el algoritmo de distribución (por ejemplo, Conexiones mínimas para conexiones de base de datos, o Origen IP donde necesite un cliente conectado a un Node), y confirme el campo de protocolo, que está preestablecido en TCP. Establezca la IP del oyente y el puerto del oyente que el equilibrador aceptará conexiones (por ejemplo, el puerto de la base de datos).
6. Dentro de la regla, seleccione Agregar objetivo para cada servidor del nivel de datos. Proporcione la IP del objetivo y el puerto del objetivo, y establezca el peso (1 a 256, predeterminado 1); utilice pesos desiguales para implementar un canario. Active el protocolo de proxy en el objetivo si el backend necesita la IP del cliente original, y configure el backend para analizarlo.
7. Configure la configuración de comprobación de salud para la regla de reenvío. Las comprobaciones son basadas en TCP. Los valores predeterminados son un tiempo de espera del cliente de 50000 ms, un tiempo de espera de conexión de 5000 ms y un tiempo de espera de objetivo de 50000 ms; ajuste el tiempo de espera de conexión para determinar con qué rapidez desea que un objetivo no respondiente sea marcado como no saludable y eliminado de la rotación.
8. Proporcione los cambios. El equilibrador se activa según la configuración, enrutando solo a los objetivos que superan la comprobación de salud.

Errores comunes:

• Esperar que el NLB termine TLS. No lo hace. El certificado y la clave privada se quedan en los objetivos del backend; no planee un diseño de certificado en el equilibrador en la capa 4.
• Intentar enrutrar en función de la URL o del camino HTTP. Las reglas de reenvío y las comprobaciones de salud son estrictamente TCP; el enrutamiento de contenido es un trabajo de la capa 7 (Unidad 3.3).
• Intentar adjuntar un grupo de seguridad de red o una lista de permitidos IP al NLB. No hay ninguno. Las reglas Firewall generadas automáticamente del NLB no se pueden editar; coloque el filtrado en los firewalls de la NIC de los objetivos y mantenga el oyente privado.
• Suponer que el NLB da a los objetivos salida a Internet. Solo es DNAT de entrada; no se admite SNAT. Proporcione una puerta de enlace NAT (Unidad 3.6) para la salida privada.
• Olvidar que el backend ve la dirección del equilibrador. Si la aplicación necesita la IP del cliente real, active el protocolo de proxy en el objetivo y configure el backend para esperarlo, o las conexiones se interrumpirán.
• Señalar el NLB a objetivos que no existen aún. Los objetivos deben estar provisionados en su LAN privada antes de que el equilibrador tenga algo a lo que distribuir.

Resumen

El Managed Network Load Balancer es el equilibrador de carga de capa 4 TCP de la plataforma: distribuye las conexiones entre objetivos saludables utilizando Round Robin, Menos Conexiones, Aleatorio o Fuente IP, asigna pesos a los objetivos desde 1 hasta 256 para el control de canario, y realiza DNAT para que las conexiones del cliente finalicen en el equilibrador y se abra una nueva conexión al objetivo. Nunca descifra el tráfico, por lo que nunca termina TLS, lo que es precisamente por qué se adapta a protocolos no HTTP y a caminos de datos cifrados de extremo a extremo donde el certificado debe permanecer en el backend. Colocado privadamente frente al nivel de datos de FinCorp, detrás del borde público de capa 7, completa la forma en capas de la Unidad 1.2 sin exposición pública y sin salto legible entre la aplicación y la base de datos.

Puntos clave:

• La capa 4 es paso de TCP: cualquier tráfico TCP se distribuye, pero las reglas y las comprobaciones de salud son estrictamente TCP, por lo que no hay enrutamiento de contenido.
• El NLB no termina TLS; el backend mantiene el certificado, lo que es lo que hace que la cifrado de extremo a extremo y el tráfico no HTTP sean factibles.
• Los algoritmos son Round Robin, Menos Conexiones, Aleatorio y Fuente IP; las sesiones pegajosas son afinidad de fuente-IP mantenida mientras las sesiones TCP permanecen activas.
• Los pesos de los objetivos (1 a 256, predeterminado 1) distribuyen el tráfico proporcionalmente y son el mecanismo de canario; el pesaje dirige nuevas conexiones solo.
• DNAT de entrada solo, no SNAT; el NLB no proporciona salida (use una NAT Gateway). No hay NSG o IP que permita unir la lista de permitidos al equilibrador administrado, por lo que el filtrado pertenece a los objetivos.
• Componga un borde público de capa 7 con un equilibrador de carga privado de capa 4 frente a un nivel de datos privado solo.