¿Cómo encajan los equilibradores de carga en un centro de datos con un rendimiento mucho mayor de lo que pueden manejar?

10

Tiene un centro de datos estandarizado en conexiones 10GE. Con, por ejemplo, Nexus 7000s en el núcleo, Nexus 5000s en la agregación y algunos extensores de tejido para el borde de los servidores (uso el equipo de Cisco como ejemplos porque esto es lo que está en mi laboratorio específico). Hay algunos equilibradores de carga ACE 4710 colgando de su Nexus 5000, pero estos solo tienen interfaces 1GE. Todas sus conexiones de conmutador son 10GE, necesarias para el tráfico masivo este-oeste (VM a VM) en los modernos centros de datos virtualizados.

¿Los equilibradores de carga no se convierten en un cuello de botella en ciertas condiciones de tráfico? Puedo ver cómo parte del tráfico local este-oeste ni siquiera necesita alcanzar el equilibrador de carga, pero hay otras situaciones en las que necesita atravesar el núcleo y posiblemente incluso una interconexión del centro de datos.

Básicamente, sé que los equilibradores de carga se usan en el tráfico cliente-servidor (norte-sur), y cosas como HTTP GET no necesitan 10GE, pero ¿hay situaciones en las que su equilibrador de carga 1GE puede interferir con un resto? 10GE ruta de tráfico y causar problemas para cosas como vMotion (por ejemplo)?

load-balancer

— centinela
fuente

1

El ACE 4710 ha sido EOL / EOS desde 2010. ¿Está vinculado a este equilibrador de carga o está abierto a utilizar un equilibrador de carga moderno que pueda escalar mucho más? (Muchos fabricantes los hacen). No hay ninguna razón para imponer artificialmente límites a su rendimiento de la manera que usted describe. Bueno, no hay ninguna razón fuera del costo, pero realmente si ha comprado la infraestructura que describe, es probable que le quede dinero en efectivo para una configuración real del balanceador de carga.

— Brett Lykins

En realidad, este no es un entorno de producción, sino un escenario real de "laboratorio" que contiene estos dispositivos particulares. En un sentido más general, mi pregunta es, dada la carga de tráfico de un centro de datos típico, ¿cómo se asegura de que el equilibrador de carga no se convierta en un cuello de botella en su diseño? Esto se aplica a su diseño, como por ejemplo, si su centro de datos tiene varios niveles, en qué nivel realiza el equilibrio de carga, etc. En mi ejemplo particular, que no puedo cambiar ya que no es mi diseño, ¿tiene sentido tener estos Dispositivos ACE con un brazo de los Nexus 5000 que son mucho más potentes.

— centinela

6

¿Los equilibradores de carga no se convierten en un cuello de botella en ciertas condiciones de tráfico?

Ciertamente, pero este generalmente no es el caso en una red bien diseñada.

Debería poder diseñar su red de manera que permita la mayor parte de su tráfico interno de servidor a servidor ("este-oeste" como lo dice) incluso si necesita cruzar su núcleo o entre centros de datos.

Si bien a menudo el equilibrador de carga es la puerta de enlace predeterminada para los servidores detrás de él, he visto configuraciones donde se ejecuta un protocolo de enrutamiento (es decir, OSPF o RIP) para permitir que el tráfico "este-oeste" eluda el equilibrador de carga, o en implementaciones más pequeñas donde se usaron rutas estáticas.

Si los equilibradores de carga van a ser un cuello de botella incluso con un buen diseño (es decir, el volumen de tráfico es tan alto), entonces también hay formas de equilibrar la carga en múltiples equilibradores de carga.

— YLearn
fuente

44

En efecto. Si hay un LB en su ruta de vMotion, ha fallado como ingeniero.

— Ricky Beam

"... también hay formas de equilibrar la carga en varios equilibradores de carga", como seleccionar el equilibrador de carga de red del DNS.

— Andrei Rînea

2

De hecho, esto es un cuello de botella y limitará su rendimiento al "eslabón más débil de la cadena", que son sus LB. Sin embargo, puedes evitarlo. Si usa algo conocido como "conmutación hacia atrás" o "retorno directo del servidor", puede hacer flujos de tráfico asíncronos. La forma en que funciona es la siguiente:

a) el cliente realiza una solicitud http a 2.2.2.2

b) LB responde en 2.2.2.2 y pasa la solicitud entrante a un servidor, ya que el LB y el servidor están en la misma LAN, esto se hace en la capa 2.

c) El servidor acepta esta conexión entrante ya que la IP 2.2.2.2 está en una interfaz de bucle invertido con alias (de lo contrario, dejaría caer un paquete que no coincida con una interfaz).

d) El servidor responde directamente al cliente.

La solicitud es de unos pocos bytes. El contenido servido puede ser de cualquier tamaño. El tráfico saliente no pasa por el LB, por lo que puede manejar MUCHO más tráfico.

Salud,

--tc

— Thomas Cannon
fuente

1

Tenga en cuenta que hacerlo solo es apropiado para los clústeres L4. Para los clústeres L7, esto interrumpirá la reescritura de encabezados, la inserción de cookies (persistencia), la terminación de SSL, cualquier tipo de coincidencia de URL y cualquier otra característica más avanzada de muchos equilibrios de carga.

— YLearn