14 min de lectura

Objetivos de aprendizaje

Al final de este módulo, podrás:

  • Decidir cuándo la passthrough TCP de la capa 4 es el nivel de equilibrio de carga correcto en lugar de la enrutación de contenido de la capa 7
  • Elegir un algoritmo de distribución para un Managed Network Load Balancer y usar el ponderado de objetivos para un canary controlado
  • Explicar por qué el cifrado de extremo a extremo y el tráfico no HTTP mantienen el certificado en el backend y descartan la terminación TLS en el balancero
  • Componer un borde público de la capa 7 con un balancero privado de la capa 4 frente a la capa de datos
  • Crear un balancero privado de la capa 4 en el Data Center Designer

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

Introducción

La Unidad 3.3 terminaba TLS en un balancificador de carga público de la capa 7, porque el borde necesitaba leer HTTP y enrutar según el contenido. La capa de datos tiene el requisito opuesto. Habla el protocolo de base de datos y otros protocolos que no son HTTP, y la postura de RGPD/BSI de FinCorp exige que la carga útil esté cifrada desde la capa de aplicación hasta la base de datos, sin ningún intermediario que pueda leerla. Un balancificador de carga consciente del contenido no puede servir a esa capa, y no debería intentarlo.

Esta unidad aborda el Managed Network Load Balancer (NLB), el balancificador de carga TCP de la capa 4 de la plataforma, y concluye construyendo un NLB privado delante de la capa de datos de FinCorp dentro del VDC que creó en la Unidad 3.1. La decisión de diseño es deliberadamente estrecha: distribuir las conexiones TCP entre objetivos sanos sin cifrarlos ni inspeccionarlos nunca.

1. Passthrough TCP de la capa 4 y cuándo es la opción ganadora

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

La propiedad definitoria es lo que el NLB no hace. Distribuye cualquier tráfico basado en TCP, incluidos protocolos de capas superiores como HTTP y HTTPS, pero sus reglas de reenvío y comprobaciones de estado de salud son estrictamente de TCP. No se admiten decisiones de enrutamiento basadas en una URL o en un encabezado HTTP. El NLB nunca descifra la conexión, por lo que nunca termina la sesión 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 residen en ese backend, no en el equilibrador de carga. Este es exactamente el comportamiento que la capa de datos desea.

Dos situaciones hacen que la capa 4 sea una 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 la capa superior) hasta el backend, sin un salto de descifrado intermedio, un equilibrador de carga de capa 7 queda descalificado, ya que terminar TLS implica descifrar. El NLB deja pasar el flujo TCP cifrado sin alterarlo, de modo que el backend conserva el certificado y sigue siendo el único lugar donde existe el texto plano. Para la ruta de datos regulada de FinCorp, esto excluye al equilibrador de carga del conjunto de componentes que manejan datos de clientes en texto plano, lo que simplifica la evaluación de protección de datos.
  • Tráfico no HTTP. Los protocolos de base de datos (protocolos de cable de PostgreSQL y MariaDB), los intermediarios de mensajes y otros servicios TCP no son HTTP, por lo que no hay nada sobre lo que un equilibrador de carga de capa 7 pueda enrutar. La capa 4 es la única capa que encaja.

Dado que el NLB no puede leer el contenido de la aplicación, tampoco puede realizar nada consciente del contenido: no hay reglas de ruta, no hay enrutamiento por host y no hay sondeo de estado de salud consciente de HTTP. Si necesita esas funciones, se encuentra en la capa equivocada y la Unidad 3.3 es la respuesta. La formulación honesta es que la capa 4 y la capa 7 no están jerarquizadas; ocupan puntos diferentes en la arquitectura y resuelven problemas diferentes.

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

Comprender cómo fluye realmente el tráfico a través del NLB explica varias de sus restricciones. El NLB realiza NAT de destino (DNAT): las conexiones de los clientes terminan en el equilibrador de carga, y este inicia a continuación una conexión separada y dedicada al objetivo de backend elegido. No se admite NAT de origen (SNAT), lo que significa que los objetivos no pueden iniciar conexiones salientes a través del equilibrador de carga. El NLB es un dispositivo de distribución de tráfico entrante, no una ruta de salida. Cuando las cargas de trabajo privadas necesitan acceso a Internet saliente, esa es la función de la NAT Gateway (solo SNAT, cubierta en la Unidad 3.6), y los dos productos son complementarios en lugar de intercambiables.

Dado que el equilibrador de carga abre su propia conexión al objetivo, el backend ve por defecto la dirección del equilibrador de carga en lugar de la del cliente original. Cuando el backend necesita la IP del cliente real (para registros, lógica geográfica o limitación de velocidad), habilite Proxy Protocol en el objetivo para que la información de la conexión original se preserve y se reenvíe. El servicio de backend (por ejemplo, Apache, NGINX o un controlador de entrada dentro del clúster) debe configurarse para esperar y analizar el encabezado de Proxy Protocol, o de lo contrario las conexiones fallarán.

1.2 Algoritmos de distribución y ponderación canary

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

  • Round Robin: distribuye las conexiones entre los objetivos en un orden circular y secuencial, respetando el peso de cada objetivo.
  • Least Connections: envía la siguiente conexión al objetivo con menos conexiones activas, lo cual es adecuado para sesiones de larga duración o irregulares.
  • Random: distribuye las conexiones aleatoriamente entre los objetivos.
  • Source IP: asigna de forma consistente a un cliente al mismo objetivo basándose en su dirección de origen.

Independientemente del algoritmo, el NLB mantiene las sesiones activas mapeadas al mismo objetivo a través de la afinidad por IP de origen (sesiones pegajosas) durante todo el tiempo que las sesiones TCP subyacentes permanezcan activas. La afinidad por IP de origen es lo que mantiene una conexión en un solo backend; seleccionar el algoritmo Source IP extiende esa pegajosidad para mantener a un cliente dado en el mismo servidor entre conexiones, lo cual es importante cuando los backends no comparten el estado TLS y se desea evitar la renegociación con un nodo diferente.

Cada objetivo tiene un peso de 1 a 256, con un valor predeterminado de 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 canary controlado. Para enviar aproximadamente el diez por ciento de las nuevas conexiones a una compilación candidata, registre el objetivo canary con un peso bajo frente a objetivos estables de mayor peso (por ejemplo, peso 1 en el canary frente a peso 9 en el estable) y observe su estado de salud y métricas antes de aumentar el peso. La ponderación dirige solo las nuevas conexiones; las sesiones ya fijadas por afinidad de IP de origen permanecen donde están hasta que se cierren, por lo que un cambio de peso se drena gradualmente en lugar de de forma instantánea. Para FinCorp, la ponderación canary permite que un nuevo servicio de acceso a datos asuma una pequeña parte observable del tráfico real sin un cambio de fecha límite.

2. Composición de la capa 7 pública con la capa 4 privada

La forma por capas canónica de la Unidad 1.2 coloca un balanceador de carga de la capa 7 pública en el borde y un balanceador de carga de la capa 4 privada delante de la capa de datos. Estos dos componentes no son redundantes; cada uno realiza lo que el otro no puede.

El balanceador de carga de la capa 7 pública (Unidad 3.3) se encuentra en el borde público, termina TLS y enruta HTTP según el contenido hacia la capa de aplicaciones sin estado. El NLB privado reside por completo en una red privada: su oyente solo está expuesto al tráfico interno, por lo que gestiona conexiones de este a oeste dentro del centro de datos, en lugar de tráfico de internet de norte a sur. La capa de aplicaciones abre conexiones TCP cifradas hacia el oyente privado del NLB, el NLB las distribuye entre las metas de la capa de datos, y TLS se termina en esas metas. Ninguna IP pública toca la capa de datos, y ningún componente entre la aplicación y la base de datos puede leer la carga útil.

Esta composición también aclara un límite de seguridad que suele pasar por alto. Los firewalls de NIC y los Network Security Groups se vinculan únicamente a las NIC de los servidores; no se aplican al balanceador de carga administrado (Unidad 3.2). El NLB sí incluye reglas básicas de firewall que se aplican automáticamente desde sus reglas de reenvío y no pueden editarse, pero no se puede adjuntar un NSG a él y no existe una lista de permisos de IP en el propio balanceador. Por lo tanto, el control de acceso para la capa de datos debe estar en los firewalls de NIC de las propias metas y en la topología: la LAN de datos permanece privada, y lo único que debe alcanzarla es la capa de aplicaciones a través del NLB. Mantener el NLB privado es en sí mismo un control primario, porque un oyente privado es inalcanzable desde internet por diseño.

Una nota práctica sobre la colocación: en Data Center Designer, el elemento NLB tiene dos interfaces. La interface Northern es el oyente y se conecta hacia los clientes (un elemento de acceso a internet para un NLB público, o una LAN privada para uno privado); la interface Southern es el backend y se conecta a la LAN privada que contiene las metas. Para la capa de datos de FinCorp, tanto el lado del oyente como el lado del backend permanecen en LAN privadas.

Recorrido de implementación de DCD

Construirá un balancificador privado de capa 4 frente a la capa 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 listener se orienta hacia la LAN de aplicaciones y cuya parte posterior se orienta hacia la LAN privada de datos, distribuyendo conexiones TCP cifradas entre los objetivos de la capa de datos sin terminar TLS. El requisito previo es que los objetivos (los servidores de la capa de datos) ya estén aprovisionados en una LAN privada; el NLB necesita objetivos existentes a los que distribuir sesiones.

Objetivo de construcción: Construir un balancificador privado de capa 4 frente a la capa de datos.

Pasos (en Data Center Designer):

  1. Abra el VDC de FinCorp de la Unidad 3.1 en Data Center Designer.
  2. Arrastre el elemento Network Load Balancer al área de trabajo.
  3. Conecte las dos interfaces del NLB. Enlace la interfaz Northern (el listener) a la LAN privada de aplicaciones, de modo que el balancificador se oriente hacia clientes internos en lugar de hacia internet. Enlace la interfaz Southern (la parte posterior) a la LAN privada que contiene los objetivos de la capa de datos. Mantener ambos lados en LAN privadas es lo que convierte esto en un balancificador privado de este a oeste.
  4. En el Inspector, abra la pestaña Settings y configure la IP del listener. Un NLB privado toma una IP privada; asígnela desde la LAN de aplicaciones para que la capa de aplicaciones tenga una dirección estable a la que conectarse.
  5. Abra la pestaña Forwarding rules y seleccione Add forwarding rule. Nombre la regla, elija el algoritmo de distribución (por ejemplo, Least Connections para conexiones de base de datos, o Source IP cuando necesite fijar un cliente a un nodo) y confirme el campo Protocol, que está preestablecido en TCP. Establezca la Listener IP y el Listener Port en los que el balancificador aceptará conexiones (por ejemplo, el puerto de la base de datos).
  6. Dentro de la regla, seleccione Add target para cada servidor de la capa de datos. Proporcione la Target IP y el Target port, y establezca el Weight (de 1 a 256, valor predeterminado 1); use pesos desiguales para implementar un canary. Active Proxy Protocol en el objetivo si la parte posterior necesita la IP del cliente original, y configure la parte posterior para analizarla.
  7. Configure las configuraciones de Health Check para la regla de reenvío. Las comprobaciones son basadas en TCP. Los valores predeterminados son un tiempo de espera de 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 según lo rápido que desee que un objetivo no receptivo se marque como no saludable y se retire de la rotación.
  8. Aproveche los cambios. El balancificador se activa según las configuraciones, dirigiendo el tráfico solo a 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 permanecen en los objetivos de la parte posterior; no planifique un diseño con certificado en el balancificador en la capa 4.
  • Intentar enrutar por URL o ruta HTTP. Las reglas de reenvío y las comprobaciones de salud son estrictamente TCP; el enrutamiento por contenido es una tarea de capa 7 (Unidad 3.3).
  • Intentar adjuntar un Network Security Group o una lista de permisos de IP al NLB. No existe ninguno. Las reglas de firewall generadas automáticamente del NLB no se pueden editar; coloque el filtrado en los firewalls de NIC de los objetivos y mantenga el listener privado.
  • Suponer que el NLB da a los objetivos salida a internet. Es solo DNAT entrante; no se admite SNAT. Aproveche un NAT Gateway (Unidad 3.6) para la salida privada.
  • Olvidar que la parte posterior ve la dirección del balancificador. Si la aplicación necesita la IP real del cliente, active Proxy Protocol en el objetivo y configure la parte posterior para esperarlo, o las conexiones se romperán.
  • Apuntar el NLB a objetivos que aún no existen. Los objetivos deben estar aprovisionados en su LAN privada antes de que el balancificador tenga algo a lo que distribuir.

Resumen

El Managed Network Load Balancer es el equilibrador TCP de capa 4 de la plataforma: distribuye conexiones entre objetivos sanos mediante Round Robin, Least Connections, Random o Source IP, asigna pesos a los objetivos de 1 a 256 para el control de canary y realiza DNAT, de modo que las conexiones del cliente terminan en el equilibrador y se abre una conexión nueva hacia el objetivo. Nunca descifra el tráfico, por lo que nunca termina TLS, lo cual es precisamente la razón por la que es adecuado para protocolos no HTTP y rutas de datos cifradas de extremo a extremo donde el certificado debe permanecer en el backend. Colocado de forma privada frente a la capa de datos de FinCorp, detrás del borde de capa 7 público, completa la estructura por capas de la Unidad 1.2 sin exposición pública y sin un salto legible entre la aplicación y la base de datos.

Puntos clave:

  • La capa 4 es passthrough de TCP: cualquier tráfico TCP se distribuye, pero las reglas y las comprobaciones de estado son estrictamente de TCP, por lo que no hay enrutamiento por contenido.
  • El NLB no termina TLS; el backend conserva el certificado, lo que hace posible el cifrado de extremo a extremo y el tráfico no HTTP.
  • Los algoritmos son Round Robin, Least Connections, Random y Source IP; las sesiones persistentes son afinidad por IP de origen mantenida mientras las sesiones TCP permanecen activas.
  • Los pesos de los objetivos (de 1 a 256, valor predeterminado 1) distribuyen el tráfico de forma proporcional y constituyen el mecanismo de canary; la ponderación solo dirige las nuevas conexiones.
  • DNAT solo de entrada, sin SNAT; el NLB no proporciona salida (use una NAT Gateway). Ninguna NSG ni lista de autorización de IP se asocia al equilibrador administrado, por lo que el filtrado debe aplicarse en los objetivos.
  • Combine un borde de capa 7 público con un equilibrador de capa 4 privado frente a una capa de datos de solo acceso privado.