Equilibrio de carga de red

Aspectos Esenciales de NLB

Al trabajar con equilibradores de carga de red (NLB), es importante comprender los bloques de creación y la terminología clave relacionada.

Servidor de backend

Un NLB tiene un juego de servidores backend para enrutar el tráfico entrante a los destinos al equilibrar la carga colocada en cada servidor individual del juego.

Un servidor de backend es un servidor de aplicaciones responsable de generar contenido como respuesta al tráfico de cliente entrante. Los servidores de aplicaciones se suelen identificar con una combinación única de dirección y número de puerto IPv4 de superposición (privada). Por ejemplo, 10.10.10.1:8080 y 10.10.10.2:8080.

Nota

El servidor de backend no puede funcionar como cliente y como backend simultáneamente, ya que no puede ser un origen de tráfico para la IP virtual (VIP) del NLB.

Juego de backends

El juego de backends es una entidad lógica que incluye:

• Lista de servidores backend (instancias informáticas) que aceptan tráfico del NLB.

• Una política de equilibrio de carga a nivel de red para distribuir el tráfico a los servidores backend de una manera consistente.

• Una política de comprobación del sistema para decidir si los servidores backend están funcionando y pueden aceptar tráfico de los NLB.

Política de Equilibrio de Carga de Red

Una política de equilibrio de carga de red indica al NLB cómo distribuir el tráfico entrante entre los servidores backend del juego de backends.

Un NLB utiliza un hash de IP asignado desde una n-tuple, que es una lista ordenada y finita de elementos. Estos elementos se extraen normalmente de los campos de un encabezado de paquete o de elementos de la cuadrícula de una base de datos relacional. La n indica cuántos campos contiene la tupla.

Las políticas de NLB permitidas para el hash de IP incluyen:

• Un hash en 5 campos del encabezado TCP/IP (llamado "Hash de 5 tuplas")
• Un hash en 3 campos del encabezado TCP/IP (llamado "Hash de 3 tuplas")
• Un hash en 2 campos en el encabezado TCP/IP (llamado "Hash de 2 tuplas"

Nota

Las políticas de NLB son diferentes de las políticas de LBaaS. Las políticas de NLB no manejan direcciones IP ni números de puerto directamente. El hashing es una manera de manipular estos y otros campos de encabezado de paquete para proporcionar un número que el NLB puede usar sin procesar el encabezado de paquete completo. Cuantas más tuplas se utilicen para la política de equilibrio de carga, mayor será el procesamiento necesario para cada paquete con equilibrio de carga, pero más amplio será el rango de valores que puede utilizar el NLB para distribuir el tráfico.

Comprobación del Sistema

Una comprobación del sistema es una prueba para confirmar la disponibilidad de los servidores de backend. Una comprobación del sistema puede ser una solicitud o un intento de conexión. En función del intervalo de tiempo especificado, el NLB aplica la política de comprobación del sistema para supervisar continuamente los servidores backend. Si un servidor no supera la comprobación del sistema, el NLB saca temporalmente al servidor de la rotación. Si el servidor supera posteriormente la comprobación del sistema, el NLB lo devuelve a la rotación.

La política de comprobación del sistema se configura al crear un juego de backends. Las comprobaciones del sistema a nivel de TCP intentan realizar una conexión TCP con los servidores backend y validar la respuesta en función del estado de conexión

Los resultados de la comprobación del sistema actualizan el estado del NLB. El estado de salud es un indicador que informa el estado general de los NLB y sus componentes.

Listener

Una entidad lógica que busca el tráfico entrante en la dirección IP del NLB. El número de puerto de un listener se configura con varios valores opcionales. Al crear un listener, las reglas de seguridad de VCN deben permitir que el listener acepte tráfico.

Solicitud de trabajo

Objeto que informa del estado actual de una solicitud de NLB. Algunas tareas de configuración del NLB pueden tardar mucho más en completarse que otras. Las solicitudes de trabajo permiten a los NLB gestionar los pasos de configuración de forma asíncrona y formar una cola. Esto permite al usuario emitir más comandos de configuración sin esperar a que finalice una directiva de configuración anterior.