Equilibrador de carga de tráfico
Descripción general del equilibrador de carga de tráfico
- Resumen de soporte de equilibrio de carga de tráfico
- Descripción de la aplicación Traffic Load Balancer
- Modos de operación del equilibrador de carga de tráfico
- Funciones del equilibrador de carga de tráfico
- Componentes de la aplicación del equilibrador de carga de tráfico
- Límites de configuración del equilibrador de carga de tráfico
Resumen de soporte de equilibrio de carga de tráfico
En la tabla 1 se proporciona un resumen de la compatibilidad con equilibrio de carga de tráfico en las tarjetas MS-MPC y MS-MIC para Adaptive Services frente a la compatibilidad con la tarjeta de servicios de seguridad MX-SPC3 para Next Gen Services.
MS-MPC |
MX-SPC3 |
||
|---|---|---|---|
Versión de Junos |
< 16.1R6 y 18.2.R1 |
≥ 16.1R6 y 18.2R1 |
19,3R2 |
# máximo de instancias por chasis |
32 |
2.000 / 32 en modo DSR L2 |
2,000 |
# máximo de servicios virtuales por instancia |
32 |
32 |
32 |
# máximo de dirección IP virtual por servicio virtual |
|
1 |
1 |
# máximo de grupos por instancias |
32 |
32 |
32 |
Max # de servicios reales (servidores) por grupo |
255 |
255 |
255 |
# máximo de grupos por servicio virtual |
|
1 |
1 |
# máximo de perfiles de monitor de red por grupo |
|
2 |
2 |
# máximo de HC por servicios de seguridad por PIC/NPU en 5 segundos |
|
4,000 |
1,250 – 19.3R2 10.000 – 20,1R1 |
Protocolos de comprobación de estado admitidos |
ICMP, TCP, UDP, HTTP, SSL, personalizado |
ICMP, TCP, UDP, HTTP, SSL, TLS Hola, personalizado |
|
Descripción de la aplicación Traffic Load Balancer
El Equilibrador de carga de tráfico (TLB) se admite en enrutadores serie MX con el concentrador de puerto modular multiservicios (MS-MPC), la tarjeta de interfaz modular multiservicios (MS-MIC) o la tarjeta de procesamiento de servicios de seguridad MX (MX-SPC3) y junto con las tarjetas de línea del concentrador de puerto modular (MPC) compatibles con los enrutadores de la serie MX, como se describe en la tabla 2.
No puede ejecutar NAT determinista y TLB simultáneamente.
Modo TLB |
Cobertura de la plataforma MX |
|---|---|
Concentrador de puerto modular multiservicios (MS-MPC) |
MX240, MX2480, MX960, MX2008, MX2010, MX2020 |
Tarjeta de procesamiento de servicios de seguridad MX (MX-SPC3) |
MX240, MX480, MX960 |
TLB le permite distribuir el tráfico entre varios servidores.
TLB emplea un plano de control basado en MS-MPC y un plano de datos utilizando el motor de reenvío del enrutador de la serie MX.
TLB utiliza una versión mejorada de multiruta de igual costo (ECMP). El ECMP mejorado facilita la distribución de flujos entre grupos de servidores. Las mejoras al ECMP nativo garantizan que cuando los servidores fallen, solo se vean afectados los flujos asociados con esos servidores, lo que minimiza la rotación general de la red en servicios y sesiones.
TLB proporciona supervisión de estado basada en aplicaciones para hasta 255 servidores por grupo, proporcionando una dirección de tráfico inteligente basada en la comprobación del estado de la información de disponibilidad del servidor. Puede configurar una interfaz de multiservicios agregados (AMS) para proporcionar redundancia uno a uno para MS-MPC o la tarjeta MX-SPC3 de servicios de próxima generación que se usa para supervisar el estado del servidor.
TLB aplica su procesamiento de distribución de flujo al tráfico de entrada.
TLB admite varias instancias de enrutamiento virtual para proporcionar un soporte mejorado para los requisitos de equilibrio de carga a gran escala.
TLB admite la traducción estática de direcciones IP virtuales a direcciones IP reales y la traducción de puertos de destino estáticos durante el equilibrio de carga.
Modos de operación del equilibrador de carga de tráfico
El Equilibrador de carga de tráfico proporciona tres modos de operación para la distribución del tráfico saliente y para controlar el procesamiento del tráfico de retorno.
La Tabla 3 resume la compatibilidad con TLB y en qué tarjetas se admite.
Tarjeta de servicio de seguridad |
MS-MPC |
MX-SPC3 |
|---|---|---|
Traducir |
Sí |
Sí |
Retorno directo transparente del servidor de capa 3 |
Sí |
Sí |
Retorno directo transparente del servidor de capa 2 |
Sí |
No compatible |
- Modo transparente Retorno directo del servidor de capa 2
- Modo traducido
- Modo transparente Retorno directo del servidor de capa 3
Modo transparente Retorno directo del servidor de capa 2
Cuando se utiliza el modo transparente, retorno directo del servidor (DSR) de capa 2:
El PFE procesa datos.
El equilibrio de carga funciona cambiando la MAC de capa 2 de los paquetes.
Un MS-MPC realiza las sondas de supervisión de red.
Los servidores reales deben ser directamente accesibles (capa 2) desde el enrutador de la serie MX.
TLB instala una ruta y todo el tráfico que pasa por esa ruta tiene un equilibrio de carga.
TLB nunca modifica los encabezados de capa 3 y de nivel superior.
La figura 1 muestra la topología TLB para DSR de capa 2 en modo transparente.
transparente
Modo traducido
El modo traducido proporciona una mayor flexibilidad que el modo transparente DSR de capa 2. Cuando elija el modo de traducción:
Un MS-MPC realiza las sondas de supervisión de red.
El PFE realiza el equilibrio de carga sin estado:
El tráfico de datos dirigido a una dirección IP virtual se traduce la dirección IP virtual a una dirección IP de servidor real y traduce el puerto virtual a un puerto de escucha del servidor. El tráfico de retorno se somete a la traducción inversa.
Se traduce el tráfico de cliente a IP virtual; El tráfico se enruta para llegar a su destino.
El tráfico de servidor a cliente se captura mediante filtros implícitos y se dirige a un próximo salto adecuado de equilibrio de carga para el procesamiento inverso. Después de la traducción, el tráfico se enruta de vuelta al cliente.
Hay dos métodos de equilibrio de carga disponibles: aleatorio y hash. El método aleatorio es sólo para el tráfico UDP y proporciona quavms-distribución aleatoria. Aunque no es literalmente aleatorio, este modo proporciona una distribución justa del tráfico a un conjunto disponible de servidores. El método hash proporciona una clave hash basada en cualquier combinación de la dirección IP de origen, la dirección IP de destino y el protocolo.
Nota:El procesamiento en modo traducido solo está disponible para el tráfico de IPv4 a IPv4 e IPv6 a IPv6.
La figura 2 muestra la topología TLB para el modo traducido.
Modo transparente Retorno directo del servidor de capa 3
Modo transparente El equilibrio de carga de DSR de capa 3 distribuye las sesiones a servidores que pueden estar a un salto de la capa 3. El tráfico se devuelve directamente al cliente desde el servidor real.
Funciones del equilibrador de carga de tráfico
TLB proporciona las siguientes funciones:
TLB siempre distribuye las solicitudes para cualquier flujo. Cuando se especifica el modo DSR, la respuesta vuelve directamente al origen. Cuando se especifica el modo de traducción, el tráfico inverso se dirige a través de filtros implícitos en las interfaces orientadas al servidor.
TLB admite el equilibrio de carga basado en hash o el equilibrio de carga aleatorio.
TLB le permite configurar servidores sin conexión para evitar un impacto en el rendimiento que podría ser causado por un refrito para todos los flujos existentes. Puede agregar un servidor en estado inactivo administrativo y utilizarlo posteriormente para la distribución del tráfico deshabilitando el estado inactivo administrativo. La configuración de servidores sin conexión ayuda a evitar que el tráfico afecte a otros servidores.
Cuando la comprobación de estado determina que un servidor está inactivo, solo se repiten los flujos afectados.
Cuando un servidor previamente inactivo se devuelve al servicio, todos los flujos que pertenecen a ese servidor en función del hash vuelven a él, lo que afecta al rendimiento de los flujos devueltos. Por este motivo, puede deshabilitar la reincorporación automática de un servidor a un grupo activo. Puede devolver los servidores al servicio emitiendo el
request services traffic-load-balance real-service rejoincomando operativo.Nota:NAT no se aplica a los flujos distribuidos.
La aplicación de monitoreo de verificación de estado se ejecuta en una MS-MPC/NPU. Esta unidad procesadora de red (NPU) no se utiliza para controlar el tráfico de datos.
TLB admite la traducción estática de direcciones IP virtuales y la traducción de puertos de destino estáticos durante el equilibrio de carga.
TLB proporciona soporte VRF múltiple.
Componentes de la aplicación del equilibrador de carga de tráfico
- Servidores y grupos de servidores
- Supervisión del estado del servidor: comprobación de estado única y comprobación de estado dual
- Servicios virtuales
Servidores y grupos de servidores
TLB permite la configuración de grupos de hasta 255 servidores (denominados en las instrucciones de configuración servicios reales) para usarlos como destinos alternativos para la distribución de sesiones sin estado. Todos los servidores utilizados en grupos de servidores deben configurarse individualmente antes de asignarlos a grupos. El equilibrio de carga utiliza hash o aleatorización para la distribución de la sesión. Los usuarios pueden agregar y eliminar servidores hacia y desde la tabla de distribución de servidores TLB y también pueden cambiar el estado administrativo de un servidor.
TLB utiliza la API del próximo salto de distribución de sesión para actualizar la tabla de distribución del servidor y recuperar estadísticas. Las aplicaciones no tienen control directo sobre la administración de la tabla de distribución del servidor. Solo pueden influir en los cambios indirectamente a través de los servicios de agregar y eliminar de la API de TLB.
Supervisión del estado del servidor: comprobación de estado única y comprobación de estado dual
TLB admite TCP, HTTP, SSL Hello, TLS Hello y sondas de comprobación de estado personalizadas para supervisar el estado de los servidores de un grupo. Puede utilizar un único tipo de sondeo para un grupo de servidores o una configuración de comprobación de estado dual que incluya dos tipos de sondeo. La función de supervisión de estado configurable reside en un MX-SPC3 o en un MS-MPC. De forma predeterminada, las solicitudes de sondeo se envían cada 5 segundos. Además, de forma predeterminada, un servidor real se declara inactivo solo después de cinco fallas consecutivas de la sonda y se declara inactivo solo después de cinco éxitos consecutivos de la sonda.
Utilice un sondeo de comprobación de estado personalizado para especificar lo siguiente:
-
Cadena esperada en la respuesta de la sonda
-
Cadena que se envía con la sonda
-
Estado del servidor que se asignará cuando se agote el tiempo de espera de la sonda (activo o inactivo)
-
Estado del servidor para asignar cuando se recibe la respuesta esperada a la sonda (arriba o abajo)
-
Protocolo: UDP o TCP
TLB proporciona adherencia a la aplicación, lo que significa que las fallas o los cambios en el servidor no afectan los flujos de tráfico a otros servidores activos. Cambiar el estado administrativo de un servidor de arriba a abajo no afecta a ningún flujo activo a los servidores restantes en la tabla de distribución de servidores. Agregar un servidor o eliminar un servidor de un grupo tiene cierto impacto en el tráfico durante un período de tiempo que depende de la configuración de los parámetros de intervalo y reintento en el perfil de supervisión.
TLB proporciona dos niveles de supervisión del estado del servidor:
-
Comprobación de estado única: un tipo de sonda se adjunta a un grupo de servidores mediante la
network-monitoring-profileinstrucción de configuración. -
Comprobación de estado dual TLB (TLB-DHC): dos tipos de sondeo se asocian a un grupo de servidores mediante la
network-monitoring-profileinstrucción de configuración. El estado de un servidor se declara en función del resultado de dos sondeos de comprobación de estado. Los usuarios pueden configurar hasta dos perfiles de comprobación de estado por grupo de servidores. Si un grupo de servidores está configurado para la comprobación de estado dual, un servicio real se declara como UP sólo cuando ambos sondeos de comprobación de estado están simultáneamente UP; de lo contrario, se declara que un servicio real está inactivo.
Se aplican las siguientes restricciones a las interfaces AMS usadas para la supervisión del estado del servidor:
-
Una interfaz AMS configurada en una instancia TLB utiliza sus interfaces miembro configuradas exclusivamente para la comprobación del estado de varios servidores reales configurados.
-
Las interfaces miembro utilizan la unidad 0 para casos VRF individuales, pero pueden usar unidades distintas de 1 para varios casos VRF.
-
TLB utiliza la dirección IP configurada para las interfaces miembro de AMS como dirección IP de origen para las comprobaciones de estado.
-
Las interfaces miembro deben estar en la misma instancia de enrutamiento que la interfaz utilizada para llegar a los servidores reales. Esto es obligatorio para los procedimientos de comprobación del estado del servidor TLB.
A partir de Junos OS versión 24.2R1, cuando TLS y SSL están configurados en el mismo grupo, ahora se utiliza el mecanismo OR en lugar de AND para determinar el estado del servidor real. Es decir, el servidor real se marca como UP si alguna de las sondas está funcionando. Anteriormente, el servidor real se marcaba UP solo si ambas sondas tenían éxito.
Cuando se proporciona la versión de sondeo SSL, sondea con esa versión. Cuando no se especifica la versión de SSL, el comportamiento cambia a Fallback de la versión v3 a la v2. La sonda comienza con SSLv3. Si se produce un error en la sonda SSLv3, el sistema sondea SSLv2. Anteriormente, cuando el atributo version no se proporcionaba explícitamente, el sondeo se realizaba con la versión predeterminada, v3.
Esta mejora del comportamiento de comprobación de estado solo se aplica cuando los sondeos TLS y SSL están configurados en el mismo grupo de comprobación de estado.
Se cambia el resultado de la instancia de estadísticas de equilibrio de carga y tráfico de servicios de mostrar <inst> extensiva.
user@host# show services traffic-load-balance statistics instance <inst-name>
Traffic load balance instance name : <inst-name> Multi services interface name : vms-3/0/0 Interface state : UP Interface type : Multi services Route hold timer : 180 Active real service count : 0 Total real service count : 8 Traffic load balance virtual svc name : vs1 IP address : 60.0.0.1 Virtual service mode : Translate mode Routing instance name : fwd_instance_1 Traffic load balance group name : group1 Traffic load balance group warmup time: 15 Traffic load balance group auto-rejoin: TRUE Health check interface subunit : 0 Traffic load balance group down count : 5 Protocol : tcp Port number : 443 Server Listening Port Number : 443 Route metric : 1 Virtual service down count : 5 Traffic load balance hash method : source Network monitoring profile count : 2 Active real service count : 0 Total real service count : 8 Demux Nexthop index : 673 Nexthop index : 674 Down time : 6d 00:01 Total packet sent count : 361749 Total byte sent count : 55165331 Total packet received count : 542636 Total byte received count : 28940680 Network monitoring profile index : 1 Network monitoring profile name : nm_prof_ssl Probe type : SSL-HELLO Probe interval : 2 Probe failure retry count : 5 Probe recovery retry count : 3 Port number : 443 Network monitoring profile index : 2 Network monitoring profile name : nm_prof_tls Probe type : TLS-HELLO Probe interval : 5 Probe failure retry count : 5 Probe recovery retry count : 5 Port number : 443 Traffic load balance real svc name : rs_1 Routing instance name : server_vrf_1 IP address : 40.1.1.2 Traffic load balance group name : group1 Admin state : UP Oper state : UP Network monitoring probe up count : 1 Network monitoring probe down count : 1 Total rejoin event count : 8 Total up event count : 9 Total down event count : 9 Real Service packet sent count : 69804 Real Service byte sent count : 10644724 Real Service packet received count : 104706 Real Service byte received count : 5584336 Total probe sent : 358307 Total probe success : 76 Total probe fail : 358231 Total probe sent failed : 0 Network monitoring profile index : 1 Network monitoring profile name : nm_prof_sslv3 Probe type : SSL-HELLO Probe state : UP SSL probe version : 3 Probe sent : 255933 Probe success : 255879 Probe fail : 54 Probe sent failed : 0 Probe consecutive success : 254635 Probe consecutive fail : 0 Network monitoring profile index : 2 Network monitoring profile name : nm_prof_tls Probe type : TLS-HELLO Probe state : DOWN TLS probe version : 1.2 Probe sent : 102374 Probe success : 22 Probe fail : 102352 Probe sent failed : 0 Probe consecutive success : 0 Probe consecutive fail : 101854
La versión de la sonda SSL-hello se mueve bajo estadísticas del servidor real desde el servicio virtual cuando la versión SSL no se especifica en el perfil de comprobación de estado.
Servicios virtuales
El servicio virtual proporciona una dirección IP virtual (VIP) que está asociada al grupo de servidores al que se dirige el tráfico, según lo determinado por la distribución de sesiones aleatorias o basada en hash y la supervisión del estado del servidor. En el caso de L2 DSR y L3 DSR, la dirección especial 0.0.0.0 hace que todo el tráfico que fluye a la instancia de reenvío tenga un equilibrio de carga.
La configuración del servicio virtual incluye:
-
Modo: indica cómo se maneja el tráfico (traducido o transparente).
-
Grupo de servidores al que se distribuyen las sesiones.
-
El método de equilibrio de carga.
-
Instancia de enrutamiento y métrica de ruta.
Aunque puede asignar una dirección virtual de 0.0.0.0 para utilizar el enrutamiento predeterminado, se recomienda utilizar una dirección virtual que se pueda asignar a una instancia de enrutamiento configurada específicamente para TLB.
Límites de configuración del equilibrador de carga de tráfico
Los límites de configuración del equilibrador de carga de tráfico se describen en la tabla 4.
Componente de configuración |
Límite de configuración |
|---|---|
Número máximo de instancias |
A partir de Junos OS versión 16.1R6 y Junos OS versión 18.2R1, la aplicación TLB admite 2000 instancias TLB para servicios virtuales que utilizan el retorno directo del servidor o el modo traducido. En versiones anteriores, el número máximo de instancias es 32. Si varios servicios virtuales utilizan el mismo grupo de servidores, todos esos servicios virtuales deben utilizar el mismo método de equilibrio de carga para admitir 2000 instancias TLB. Para los servicios virtuales que utilizan el modo layer2-direct-server-return, TLB solo admite 32 instancias de TLB. Para realizar la misma función que el modo layer2-direct-server-return y tener compatibilidad con 2000 instancias de TLB, puede utilizar el modo direct-server-return y utilizar un filtro de servicio con la acción de omitir. |
Número máximo de servidores por grupo |
255 |
Número máximo de servicios virtuales por PIC de servicios |
32 |
Número máximo de comprobaciones de estado por PIC de servicios en un intervalo de 5 segundos |
Para tarjetas de servicios MS-MPC: 2000 Para el modo Servicios de próxima generación y las tarjetas de servicios MX-SPC3: 1250 |
Número máximo de grupos por servicio virtual |
1 |
Número máximo de direcciones IP virtuales por servicio virtual |
1 |
Protocolos de comprobación de estado admitidos |
ICMP, TCP, HTTP, SSL, TLS-Hello, personalizado
Nota:
La comprobación de estado ICMP solo se admite en tarjetas de servicios MS-MPC. A partir de la versión 22.4R1 de Junos OS, TLB se ha mejorado para admitir el tipo de comprobación de estado TLS-Hello. Para TLS-Hello a través de TCP, se admiten comprobaciones de estado de TLS v1.2 y v1.3. |
Ver también
Configuración de TLB
En los temas siguientes se describe cómo configurar TLB. Para crear una aplicación completa, también debe definir interfaces e información de enrutamiento. Opcionalmente, puede definir filtros de firewall y opciones de políticas para diferenciar el tráfico de TLB.
- Carga del paquete de servicios TLB
- Configuración de un nombre de instancia TLB
- Configuración de la interfaz y la información de enrutamiento
- Configuración de servidores
- Configuración de perfiles de supervisión de red
- Configuración de grupos de servidores
- Configuración de servicios virtuales
- Configuración del seguimiento para la función de supervisión de comprobación de estado
Carga del paquete de servicios TLB
Cargue el paquete de servicio TLB en cada PIC de servicio en el que desee ejecutar TLB.
Para los servicios de próxima generación y la tarjeta de servicios MX-SPC3, no es necesario cargar este paquete.
Para cargar el paquete de servicio TLB en una PIC de servicio:
Cargue el
jservices-traffic-dirdpaquete.[edit chassis fpc slot-number pic pic-number adaptive-services service-package extension-provider] user@host# set package jservices-traffic-dird
Por ejemplo:
[edit chassis fpc 3 pic 0 adaptive-services service-package extension-provider] user@host# set package jservices-traffic-dird
Configuración de un nombre de instancia TLB
system processes sdk-service enable en la jerarquía [edit].
Para configurar un nombre para la instancia de TLB:
-
En el nivel de
[edit services traffic-load-balance]jerarquía, identifique el nombre de la instancia TLB.[edit services traffic-load-balance] user@host# set instance instance-name
Por ejemplo:
[edit services traffic-load-balance] user@host# set instance tlb-instance1
Configuración de la interfaz y la información de enrutamiento
Para configurar la información de interfaz y enrutamiento:
Configuración de servidores
Para configurar servidores para la instancia TLB:
[edit services traffic-load-balance instance instance-name] user@host# set real-service real-service-name address server-ip-address
Por ejemplo:
[edit services traffic-load-balance instance tlb-instance1] user@host# set real-service rs138 address 172.26.99.138 user@host# set real-service rs139 address 172.26.99.139 user@host# set real-service rs140 address 172.26.99.140
Configuración de perfiles de supervisión de red
Un perfil de supervisión de red configura un sondeo de comprobación de estado, que se asigna a un grupo de servidores al que se distribuye el tráfico de sesión.
Para configurar un perfil de supervisión de red:
Configuración de grupos de servidores
Los grupos de servidores están formados por servidores a los que se distribuye el tráfico mediante una distribución de sesión sin estado, basada en hash y supervisión del estado del servidor.
Para configurar un grupo de servidores:
Configuración de servicios virtuales
Un servicio virtual proporciona una dirección que está asociada al grupo de servidores al que se dirige el tráfico, según lo determinado por la distribución de sesiones aleatorias o basada en hash y la supervisión del estado del servidor. Opcionalmente, puede especificar filtros e instancias de enrutamiento para dirigir el tráfico para TLB.
Para configurar un servicio virtual:
Configuración del seguimiento para la función de supervisión de comprobación de estado
Para configurar las opciones de seguimiento de la función de supervisión de comprobación de estado:
Tabla de historial de cambios
La compatibilidad con las funciones viene determinada por la plataforma y la versión que esté utilizando. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.