30 votos

¿Qué es un método típico para ampliar un equilibrador de carga de software?

A menudo veo en la web de la aplicación de arquitecturas con un SLB / proxy inverso en frente de un montón de servidores de aplicaciones.

¿Qué sucede cuando el número de conexiones a la SLB requiere demasiados recursos para una sola SLB para manejar de manera efectiva? Para un hormigón sin embargo, más de-the-top ejemplo, considere la posibilidad de 2 millones de conexiones HTTP persistentes. Claramente una sola SLB no puede manejar esto.

¿Cuál es la configuración recomendada para el escalado a cabo un SLB?

Es típico para crear un grupo de clúster o de Libras? Si es así, ¿cómo es la carga de clientes repartidos entre el grupo de Libras?

25voto

Zameer Manji Puntos 1213

OK, no es ya aceptado la respuesta, pero hay algo que añadir.. El más común de los 'clásicos' formas de escalar el equilibrador de carga de nivel son (sin ningún orden en particular):

  • DNS Round Robin para dar a conocer varias direcciones IP para el dominio. Para cada dirección IP, implementar una alta disponibilidad del servidor de par (2 servidores de cooperar en el mantenimiento de una dirección IP de trabajo en todo momento.) Cada IP corresponde a un equilibrador de carga de clúster, ya sea mediante dispositivos o servidores con equilibrio de carga de software. Escala horizontal por adición de equilibrador de carga de pares como sea necesario.

  • Enrutamiento o ajustes de firewall para distribuir la carga a varios de los equilibradores de carga. Tiene la parte frontal del router o firewall frontal difundir las conexiones de entrada de varias direcciones IP (cada uno representando a un equilibrador de carga de par) por el hash de la dirección IP de origen, tener múltiples de igual coste rutas a los equilibradores de carga, o similar.

  • Una capa de IP de nivel de equilibradores de carga en frente de una capa de HTTP a nivel de los equilibradores de carga. IP de la capa de equilibrio de carga puede ser implementado en ASICs / silicio, y puede ser malo rápida para algunas cosas. Así, una única dirección IP del equilibrador de carga de par puede a menudo 'mantener' con HTTP/HTTPS nivel de equilibradores de carga, y proporcionar multi-gigabit de los niveles de rendimiento, manteniendo la arquitectura agradable y simple.

Va completamente en profundidad sobre las diferentes maneras de hacer lo anterior requeriría una respuesta larga. Pero en general, no es tan difícil de escalar el equilibrador de carga de nivel, es mucho más difícil de escalar el nivel de servidor de aplicaciones y, especialmente, el nivel de base de datos.

Ya sea que usted elija un dispositivo factor de forma (F5, Cisco, A10) o un servidor genérico (Windows / Linux + software) que importa menos. Las principales consideraciones a la hora de escalar el equilibrador de carga de la capa son:

  • El estado completo versus apátridas. ¿Es absolutamente necesario sticky sessions, o puedes vivir sin él? No mantiene el estado hace todo más fácil.
  • 'Hardware' (ASICs) frente a 'software' (de propósito general, servidores) para el equilibrio de carga. Cada uno tiene sus pros y sus contras, ver el HAProxy visión general de la documentación vinculada anteriormente.
  • L3/4 (IP / TCP/IP) balanceo de carga versus L7 (HTTP) de equilibrio de carga. De nuevo, pros y contras, el HAProxy doc proporciona una buena visión general.
  • La terminación SSL, donde, en el webnodes o en el equilibrador de carga.

Por lo general, usted no necesita preocuparse acerca de esto antes de que su sitio web recibe muy grandes-una sola moderna servidor con fx nginx manejar decenas de miles de llanura peticiones HTTP por segundo. Así que no hagas prematuro de optimización, no tiene que lidiar con esto antes de que usted tiene que.

15voto

Hyppy Puntos 11996

Equilibradores de carga no pueden escalarse fácilmente por otros balanceadores de carga ya que inherentemente habrá un equilibrador de carga individual de la cadena en algún lugar mantener las conexiones. Dicho esto, balanceadores LVS como HAProxy tienen capacidad absurda en la gama Gbps. Una vez que tengas más allá de las capacidades de un equilibrador de carga única (software, hardware, lo que sea), entonces usted necesitará pasar a otras técnicas como round robin DNS.

9voto

siddhadev Puntos 6083

La clave de la escala HTTP equilibrio de carga de capa para añadir otra capa de nivel inferior (IP o TCP) de equilibrio de carga de primera. Esta capa puede ser construido enteramente con software de código abierto, a pesar de que obtendrá mejores resultados si usted tiene routers modernos.

Los flujos de sesiones TCP) debe ser hash utilizando encabezados tales como IP de origen/destino y los puertos TCP, para decidir qué interfaz a la que asistan. También se necesita un mecanismo para asegurarse de que cuando un frontend muere, deja de acostumbrarse.

Existen varias estrategias, voy a esbozar un par que he utilizado en la producción en los sitios de servir a millones de usuarios, así que te puedes hacer una idea. Sería demasiado largo explicar todo en detalle, pero espero que esta respuesta le dará suficiente información y sugerencias para empezar. Con el fin de implementar estas soluciones vas a necesitar a alguien que está realmente bien informado acerca de las redes.

Es cierto que lo que estoy describiendo aquí es mucho más difícil de implementar de lo que se describe en otras respuestas, pero este es realmente el estado-of-the-art si usted tiene un alto tráfico del sitio web con grandes problemas de escalabilidad y requisitos de disponibilidad del 99.9%. A condición de que usted ya tiene un ingeniero de la red de la clase de hombre a bordo, menores costes de instalación y ejecución (tanto en capex y opex) de equilibrador de carga de los aparatos, y se puede ampliar aún más en casi ningún costo adicional (frente a la compra de una nueva, aún más costoso aparato cuando superas tu modelo actual).

Primera estrategia: con un firewall

Es de suponer que usted tiene un par de routers en las que el ISP uplinks están conectados. Su ISP le proporciona 2 enlaces (activo/pasivo, el uso de VRRP). En sus routers, también el uso de VRRP, y enrutar el tráfico que se va a la red pública a un servidor de seguridad. Los firewalls (FW 1 y FW 2 por debajo) y también están activo/pasivo y filtrar el tráfico y enviar a cada flujo para una vida saludable interfaz de servidor (HTTP balanceadores de carga, FE 1 y FE 2 por debajo).

 +--------------+ +--------------+
 | Router ISP | | ISP router B |
 +--------------+ +--------------+
 | |
 ==#======================#== (red pública)
 | |
 +---------------+ +---------------+
 | Su enrutador | | Tu router B |
 +---------------+ +---------------+
 | |
 ==#=====#==========#=====#== (RFC 1918 red privada)
 | | | |
 +------+ +------+ +------+ +------+
 | FW 1 | | FE 1 | | FE 2 | | FW 2 |
 +------+ +------+ +------+ +------+

El objetivo es tener un flujo de tener este aspecto:

  1. ISP rutas de tráfico que se va a su IPs para su activo router.
  2. Los enrutadores enrutar el tráfico a un VIP que utiliza un RFC 1918 dirección. Este VIP es propiedad del firewall activo, tanto como VRRP. Si usted usa OpenBSD para su firewall necesidades, entonces usted puede utilizar la CARPA, de patente, una alternativa gratuita a VRRP/HSRP.
  3. El firewall se aplica el filtro (por ejemplo, "permitir sólo 80/tcp y 443/tcp ir a esta dirección IP en particular").
  4. El firewall también actúa como un router y reenvía los paquetes a una saludable frontend.
  5. Su interfaz termina la conexión TCP.

Ahora la magia sucede en los pasos 4 y 5, así que vamos a ver en más detalles de lo que hacen.

El firewall sabe la lista de interfaces (FE 1 y FE 2), y se tomará uno de ellos basado en un aspecto particular del flujo (por ejemplo, por la mezcla de la IP de origen y el puerto, entre otras cabeceras). Pero también es necesario para asegurarse de que el reenvío de tráfico a un saludable frontend, de lo contrario se blackhole tráfico. Si usted usa OpenBSD, por ejemplo, puede utilizar relayd. Lo relayd que hace es simple: controles de salud todas sus interfaces (por ejemplo, mediante el envío de una sonda de solicitud HTTP), y cada vez que un frontend es saludable que se agrega a una tabla que utiliza el firewall para seleccionar el siguiente salto de los paquetes de un flujo. Si un frontend falla en los controles de salud, se elimina de la tabla y no los paquetes son enviados a ella más. Cuando el reenvío de paquetes a un frontend, todos los firewall es el intercambio de la dirección MAC de destino de los paquetes de la interfaz de usuario elegido.

En el paso 5, los paquetes del usuario son recibidos por el equilibrador de carga (Barniz, nginx, o lo que sea). En este punto, el paquete sigue siendo destinados a su dirección IP pública, por lo que necesita para su alias VIP(s) en la interfaz de loopback. Esto se llama DSR (Directo del Servidor de Retorno), debido a que su interfases terminar la conexión TCP y el firewall de entre sólo ve simplex de tráfico (sólo los paquetes entrantes). El router enviará los paquetes salientes directamente a los ISP de los routers. Esto es especialmente bueno para el tráfico HTTP, porque las solicitudes que tienden a ser más pequeñas que las respuestas, a veces de manera significativa. Para que quede claro: esto no es un OpenBSD cosa específica y es ampliamente utilizado en la alta víctimas de la trata de sitios web.

Trampas:

  • Los usuarios finales se conectan directamente a la interfaz de los servidores debido a que el uso de DSR. Tal vez ya era el caso, pero si no es así, usted necesita para asegurarse de que está debidamente protegida.
  • Si usted usa OpenBSD, ten en cuenta que el núcleo es de un solo subproceso por lo que el rendimiento de un solo núcleo de la CPU va a limitar el rendimiento de un servidor de seguridad. Podría ser un problema dependiendo de su tipo de NIC y la velocidad de paquete que usted está viendo. Hay maneras de resolver este problema (más sobre esto más adelante).

Segunda estrategia: sin un firewall

Esta estrategia es más eficiente, pero más difícil de la instalación debido a que se depende más de las características específicas de los routers que tienen. La idea es evitar el firewall de arriba y tienen los routers de hacer todo el trabajo de los firewalls que estaban haciendo.

Usted necesitará los routers que soportan por puerto L3/L4 Acl, BGP y ECMP, y la Política de Enrutamiento Basado en (PBR). Sólo de gama alta de los routers compatibles con estas características, y que a menudo tienen extra de las licencias para el uso de BGP. Normalmente esto es aún más barato que equilibradores de carga de hardware, y también es mucho más fácil de escalar. La cosa buena acerca de estos routers es que tienden a ser de la velocidad de línea (por ejemplo, siempre se puede máximo fuera de el vínculo, incluso en 10 gbe de interfaces, ya que todas las decisiones que se toman se hacen en hardware por ASICs).

En los puertos en los que tienes tu ISP uplinks, aplicar la ACL que solía ser en el servidor de seguridad (por ejemplo, "permitir sólo 80/tcp y 443/tcp ir a esta dirección IP en particular"). Luego que cada uno de sus interfaces mantener una sesión BGP con su router. Usted puede utilizar el excelente OpenBGPD (si su interfases están en OpenBSD) o Quagga. El router se ECMP el tráfico de las interfaces que están sanos (porque son el mantenimiento de sus sesiones BGP). El router también enrutar el tráfico a cabo adecuadamente el uso de los derechos de OBTENTOR.

Refinamientos

  • Con el firewall de solución de par, es bueno si se puede sincronizar el TCP estados a través del cortafuegos, de modo que cuando uno de los firewall de falla, todo falla por encima sin problemas a la otra. Usted puede lograr esto con pfsync.
    • Tenga en cuenta que pfsync normalmente el doble de la velocidad de paquetes en el firewall.
    • HTTP es un protocolo sin estado, por lo que no es el fin del mundo si restablece todas las conexiones durante un firewall de conmutación por error porque no uso pfsync.
  • Si superan un único firewall, puede utilizar ECMP en el router para enrutar el tráfico a más de un par de firewall.
  • Si utiliza más de un par de cortafuegos, así podría hacer de todos ellos activo/activo. Usted puede lograr esto a través de los firewalls mantener una sesión BGP con los routers, como las interfaces necesidad de mantener uno en la 2ª diseño sin cortafuegos.

Ejemplo relayd config

Ver también CÓMO en https://calomel.org/relayd.html

vip="1.2.3.4" # Su dirección IP pública
 # (puede haber más de uno, pero no es necesario)
fe1="10.1.2.101"
fe2="10.1.2.102"
fe3="10.1.2.103"
fe4="10.1.2.104" # Usted puede tener cualquier número de interfaces.
int_if="em0"
la tabla <fe> { $fe1 reintentar 2, $fe2 reintentar 2, $fe3 reintentar 2, $fe4 reintentar 2 }
la tabla <retroceso> { 127.0.0.1 }

redirigir webtraffic {
 escuchar en $vip puerto 80
 tiempo de espera de sesión de 60
 ruta a <fe> http "/healthcheck.html" digest "(el sha1sum de healthcheck.html)" de la interfaz de $int_if
}

2voto

Some French Guy Puntos 96

Personalmente voy a más simple, menos equilibradores de carga de hardware configurable en ese momento - las cosas como ACE/ASAs de Cisco, fundición de ServerIrons, tal vez incluso Zeus ZXTMs (libras SW diseñado cargas muy pesadas fro).

1voto

Mxx Puntos 1135

¿Tal vez en lugar de mantener constantemente tantas conexiones abiertas para enviar respuestas, el código de la aplicación de tal manera para que los clientes sondean periódicamente sus servidores tantas veces como sea necesario?

¿Es lo que estás haciendo en realidad requiere una respuesta este mismo milisegundo o puede un cliente espere 15/20 segundos hasta el próximo período electoral?

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: