SNAT vs PBR para el equilibrio de carga del servidor


8

En una configuración SLB de un solo brazo, SNAT se usa para forzar que el tráfico de retorno pase a través del SLB. Esto tiene un aspecto negativo: simplemente que los registros web no pueden capturar la verdadera IP del cliente a menos que se pase en el encabezado XFF (X-Fordered-For) y el servidor web pueda iniciar sesión.

Una alternativa es utilizar PBR (enrutamiento basado en políticas) para devolver el tráfico de retorno al SLB, pero trato de evitar el PBR a menos que no haya otra / mejor solución en la plataforma 6500E con SUP720 / PFC3B, y sé lo particular La versión de IOS también puede ser un factor: ¿PBR agrega alguna latencia sobre SNAT, suponiendo que PBR se haga todo en hardware? Si PBR se realiza en hardware utilizando solo los comandos que admite hoy en día, ¿es posible que la actualización de IOS en el futuro pueda cambiar PBR para que se realice en software / proceso conmutado?

Hoy en día, nuestros equilibradores de carga tienen la mayoría de las VLAN del servidor web directamente detrás de ellas (g / w predeterminada que apunta a SLB) y otros servidores como SQL en las VLAN que no son SLB. Sin embargo, este tráfico web-sql transita el SLB. Nuestro objetivo sería evitar cruzar el SLB y mantener el tráfico SQL por separado, y aún retener al verdadero cliente en los registros web. Prefiero no introducir la complejidad de solución de problemas con PBR y posiblemente tener este cambio de hardware a software procesado en el futuro. Además de XFF y SNAT mencionados anteriormente, ¿es PBR la única opción aquí y cuál es la mejor manera de mantener PBR bien configurado?


No estoy 100% seguro de entender la topología, ¿su servidor tiene dos interfaces y necesita SNAT para que ese servidor pueda tener una única ruta estática para devolver el tráfico de 'producción' a la interfaz orientada a SLB? Pero SNAT en la configuración 1: N implica estados, que siempre deben evitarse, PBR no tiene estado, por lo que se escala mucho mejor.
ytti

3
Normalmente, desaconsejo el diseño de equilibrador de carga de un solo brazo (o podría llamarlo equilibrador de carga en un dispositivo), y opto por una subred frontal para VIPs con equilibrio de carga y una subred posterior para el servidor quinielas. Los servidores predeterminan a través de la interfaz posterior en el equilibrador de carga. Esto elimina por completo la necesidad de SNAT o PBR.
Mike Pennington

Aparte de mi comentario sobre las topologías de equilibrador de carga ... ¿podría agregar algunos diagramas para referencia, porque algunas de las preguntas no están claras cuando no está seguro de cómo se ve la imagen más grande?
Mike Pennington

@ytti, la topología actual tiene SLB en línea con los g / w predeterminados de los servidores que apuntan a SLB: NIC / servidor único. Esencialmente, tenemos lo que Mike describió con las VLAN del lado del cliente y del servidor en dos interfaces del SLB ahora, pero esta es una pregunta acerca de pasar a una topología diferente como un brazo para que el tráfico del servidor al SQL no tenga que atravesar SLB y preferimos no agregar ninguna complejidad a los servidores, como NIC duales con rutas estáticas del servidor, etc. Comprender la latencia de SNAT frente a PBR es clave, así como otros diseños que me perdí (como el retorno directo del servidor descrito en una respuesta )
generalnetworkerror

¿Qué servidores son? En Linux (o * BSD) es fácil de configurar para que el paquete regrese a la interfaz donde vino, lo cual es útil en las configuraciones de SLB (lo usamos para conectar servidores de forma redundante a dos cajas SLB desconectadas, los VIP son ECMPd por lo que ambos están calientes, pero podría ser incluso de un proveedor diferente, ya que no se conocen entre sí).
ytti

Respuestas:


6

¿PBR agrega alguna latencia sobre SNAT asumiendo que PBR se hace todo en hardware?

Sup720 admite PBR en HW , la latencia adicional (si la hay) es insignificante porque PBR no agrega más colas de interfaz. Creo que PBR haría las cosas más difíciles de lo que deberían ser (y aún no estoy seguro de si funcionaría ... los detalles de esa opción no están totalmente claros)

Además de XFF y SNAT mencionados anteriormente, ¿es PBR la única opción aquí y cuál es la mejor manera de mantener PBR bien configurado?

PBR no es la única opción. Su opción propuesta es un poco confusa, pero PBR normalmente se reduce a nada más que una forma más elegante de enrutamiento estático.

Por lo general, esta es la mejor topología para servicios de carga equilibrada que requieren consultas SQL ...

  • Coloque sus VIP en una subred frontal ... 172.16.1.0/24 en el diagrama
  • Coloque sus agrupaciones de servidores en una subred posterior ... 172.16.2.0/24 en el diagrama
  • Coloque sus consultas SQL en otra interfaz ... 172.16.3.0/24 en el diagrama. Agregue una segunda interfaz a todos los servidores que requieren consultas SQL. Realice todas sus consultas SQL a las direcciones en esta subred. Esta topología funciona tanto para Unix como para Windows, ya que solo depende de ARP o rutas de host (según su preferencia) para la conectividad SQL.

Diagrama:

LB w red de consulta SQL

Esta topología tiene beneficios adicionales:

  • Separa las interfaces SQL del tráfico web, ya que las consultas SQL son explosivas y pueden terminar congestionando el tráfico web.
  • Proporciona diferentes MTU para sus servicios de equilibrio de carga (que generalmente necesitan permanecer en 1500 o menos, si transitan por Internet) y sus servicios SQL (que favorecen las tramas gigantes).

Cualquier topología de equilibrador de carga con un solo brazo es una opción menos deseable ya que termina reduciendo su rendimiento máximo a la mitad debido a la topología de un solo brazo.

EDITAR para preguntas sobre el cambio de HW vs SW en Sup720

Este es un tema profundo, pero daré la versión de resumen ... Sup720 aplica una ACL en cada dirección (entrada / salida) y la ACL debe encajar en TCAM en función del algoritmo de fusión que la plataforma haya elegido. El Administrador de funciones de Sup720 (es decir, fm) es responsable de mediar las funciones en TCAM e informar si tiene una adyacencia de despeje (es decir, conmutación de SW) o si la combinación de protocolo y dirección se cambia en HW. Para aislar si

  1. Primero, identifique todas las interfaces de capa 3 de entrada y salida que el tráfico PBR podría transitar.
  2. Luego, examine la salida de show fm fie int <L3_intf_name> | i ^Interf|Result|Flow|Config(debe mirar las direcciones de entrada y salida para todas las interfaces en el Paso 1 ). Su tráfico cambiará HW si los valores en MAYÚSCULAS coinciden con los valores que ve a continuación ... tenga en cuenta que la salida del comando que estoy usando es muy similar a lo que ve en show fm fie summary...

Tx.Core01#sh fm fie int Vl220 | i ^Interf|Result|Flow|Config
Interface Vl220:
 Flowmask conflict status for protocol IP : FIE_FLOWMASK_STATUS_SUCCESS      <--- in HW
 Flowmask conflict status for protocol OTHER : FIE_FLOWMASK_STATUS_SUCCESS   <--- in HW
 Flowmask conflict status for protocol IPV6 : FIE_FLOWMASK_STATUS_SUCCESS    <--- in HW
Interface Vl220 [Ingress]:
 FIE Result for protocol IP : FIE_SUCCESS_NO_CONFLICT                        <--- in HW
 Features Configured : V4_DEF   - Protocol : IP
 FIE Result for protocol OTHER : FIE_SUCCESS_NO_CONFLICT                     <--- in HW
 Features Configured : OTH_DEF   - Protocol : OTHER
 FIE Result for protocol IPV6 : FIE_SUCCESS_NO_CONFLICT                      <--- in HW
 Features Configured : V6_DEF   - Protocol : IPV6
Interface Vl220 [Egress]:
 No Features Configured
No IP Guardian Feature Configured
No IPv6 Guardian Feature Configured
No QoS Feature Configured
Tx.Core01#

La interfaz anterior no muestra salida de salida, pero eso es irrelevante ... la salida es similar a la dirección de entrada. Ricky Micky escribió una explicación sobresaliente de 'sh fm fie interface' si desea obtener más detalles sobre la dinámica de los bancos TCAM / resultados de fusión.


Ya había eliminado esta opción de diseño, ya que requiere adyacencia L2 entre el nivel de front-end y el nivel de back-end, así como no escalar bien para nuestras múltiples VLAN de back-end y debido a la posible necesidad de colocar un firewall (no transparente ) entre niveles. Sin embargo, sigue siendo una excelente opción para aquellos que no tienen estas preocupaciones. Buen punto sobre las MTU.
generalnetworkerror

A falta de consultar la documentación de PBR para versiones específicas de IOS para saber si una característica de PBR determinada desencadena la necesidad de que se haga en software, ¿se puede determinar esto dentro de IOS? Esto es lo que quise decir con "estrictamente configurado" para que PBR lo mantenga funcionando dentro del hardware.
generalnetworkerror

@generalnetworkerror, ¿en qué hardware quieres hacer PBR? Si Sup720 / Sup2T, no es tan difícil identificar si está cambiando en HW vs SW ... necesitamos más detalles para ayudar. De hecho, si no le importa un diagrama de cómo funciona este concepto de PBR sería realmente útil
Mike Pennington

SUP720 / PFC3B ... buscando ver cómo puede determinar a partir de CLI si una característica PBR dada forzó esto a cambiar de s / w
generalnetworkerror

@generalnetworkerror, sh fm fie summary... o lea mi respuesta para obtener más información ...
Mike Pennington

1

Si su equilibrador de carga lo admite, Direct Server Return también haría lo que desea. Debe ser compatible con su equilibrador de carga y existen algunas preocupaciones sobre el sistema operativo. Implica poner interfaces 'loopback' en cada servidor que tienen la dirección IP del VIP, el balanceador de carga mientras que las direcciones del servidor real solo usan la dirección MAC del servidor real para reenviar el paquete, ya que el servidor tiene la interfaz loopback con El VIP en él, el servidor acepta el paquete.

Debe consultar el documento del proveedor de LB específico y sus equipos de servidores deben poder administrar el adaptador virtual (no utilizamos esta función porque no pensamos que nuestro aprovisionamiento de servidor automatizado pueda administrar un adaptador de bucle invertido de MS).

Pero esto no usa NAT en el LB y no tiene que hacer PBR.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.