¿La mejor manera de equilibrar la carga en varios servidores de archivos estáticos incluso para una distribución de ancho de banda?


12

En primer lugar, te explicaré mi situación. Estoy ejecutando un sitio web bastante popular como un proyecto paralelo, por lo que realmente no puedo invertir una tonelada de dinero en él. Actualmente tengo solo un servidor con HAProxy en el frente que envía solicitudes normales a Apache, y todas las solicitudes de archivos estáticos a Lighttpd. Esto está funcionando realmente bien porque Apache maneja todas las solicitudes de php y post, mientras que todas las imágenes se envían a Lighttpd más rápido (el sitio es principalmente imágenes, por lo que esto es realmente importante). Sería bueno no tener que configurar un subdominio para servir las imágenes, porque las URL cortas también son muy importantes, por lo tanto, mi razón para usar HAProxy.

He encontrado un proveedor de alojamiento que ofrece un ancho de banda no medido bastante barato que he estado usando, el problema surge cuando empiezo a sacar tanto ancho de banda como puede manejar la tarjeta de red de 100mbs, por lo que necesito un segundo servidor.

He pensado mucho en mis opciones, así que te explicaré cada una. Espero que pueda proporcionar una idea de cuál es la mejor opción para mí, o tal vez haya otra opción que aún no haya pensado.

Requisitos:

  • Incluso la distribución de ancho de banda es imprescindible. Tengo un servidor bastante potente, por lo que ampliar no es una opción. Necesito escalar para ganar más ancho de banda.

  • URL cortas Realmente no suelo configurar un subdominio, como img.example.com, para servir mis imágenes. example.com/image.jpg es cómo es ahora y cómo me gustaría que se quedara. Pero si no hay otra manera, entonces entiendo.

  • El servidor más cercano que maneja la solicitud sería realmente agradable, pero no obligatorio. Algo para tener en cuenta.

HAProxy a equilibrio de carga:

  • Sería muy fácil hacerlo ya que de todos modos ya estoy usando HAProxy. Sin embargo, creo que el problema surge cuando se distribuye el ancho de banda. Podría estar equivocado en esto, pero ¿HAProxy no envía la solicitud a un servidor donde el servidor la procesa y luego la envía de vuelta a través de HAProxy al cliente? Por lo tanto, todo el tráfico vuelve a salir a través del equilibrador de carga, lo que hace que use tanto ancho de banda como todos los servidores combinados.

DNS Round Robin:

  • Esta podría ser mi mejor opción. Simplemente replica el sitio web en varios servidores y haz lo que estoy haciendo ahora. La desventaja es que si un servidor se cae, los clientes aún se envían a él. También necesitaría replicar el sitio en varios servidores. Tenía la esperanza de poder tener un servidor principal que maneje todo excepto los archivos estáticos, y luego tener un par de servidores de archivos estáticos. También leí que esto era una especie de "equilibrio de carga del pobre", y sería bueno tener algo un poco más sofisticado.

Retorno directo del servidor:

  • Parece realmente complicado, pero podría ser una buena opción. ¿Todavía podría enviar ciertas URL a ciertos servidores? Al igual que ahora con HAProxy, cada URL que termina en la extensión de archivo correcta se envía a Lighttpd, mientras que otras extensiones se envían a Apache. Entonces necesitaría algo similar. Al igual, todas las solicitudes de php son manejadas por el mismo servidor que ejecuta el software de equilibrio, mientras que todas las solicitudes de jpg se envían a varios servidores.

Idealmente, si HAProxy admite Direct Server Return, entonces mi problema estaría resuelto. Tampoco quiero usar un CDN, porque son realmente caros, y este es solo un proyecto paralelo después de todo.

¿Entiendes mi problema? Avíseme si no le expliqué algo bien o si necesita más información.


1
Este es Imgur y recientemente recaudó 40 millones de dólares. : O
L1th1um

Respuestas:


3

Haga un dibujo de su ciclo de solicitud / respuesta para la aplicación y aísle el cuello de botella. Tiene razón en que un solo proxy que distribuye la carga a muchos servidores de aplicaciones requerirá el ancho de banda agregado de todos los servidores de aplicaciones. La solución clásica es RR DNS. Google, Yahoo y Amazon usan esta técnica con un TTL corto. Investigué un poco hace un tiempo y documenté mis hallazgos .

Otra solución es utilizar una solución de equilibrio de carga empresarial sofisticada que utilice el direccionamiento IP virtual para equilibrar las solicitudes entre múltiples servidores de aplicaciones con direcciones IP reales. He trabajado con productos Netscaler y Stonesoft. Ambos funcionan bien pero tienen idiosincrasias terribles y son bastante complejos.


Muchas gracias. Los resultados de su encuesta fueron muy útiles. Creo que esta es la solución a la que finalmente llegaré. Sin embargo, "como cualquier buen investigador, no actúo hasta tener suficientes datos". :)
Alan

Gracias por la visión de usted. Desafortunadamente, irónicamente, el enlace a sus hallazgos parece estar inactivo, ¿puede arreglarlo?
TCB13

3

Algunas respuestas:

  • Sí, todo el tráfico pasa a través de HAProxy, ya que funciona como un proxy de nivel HTTP. Esto será lo mismo incluso si HAProxy está instalado en un servidor separado que equilibra la carga de varios servidores de fondo. Por lo tanto, si su proveedor de alojamiento solo proporciona puertos de red de 100 MB y ya está presionando 100 MB, entonces tiene un problema.
  • Con respecto al dominio, lo óptimo sería servir imágenes de un dominio diferente al de su aplicación web, no un subdominio, uno diferente, para que no se envíen cookies en las solicitudes de imágenes. Vea el trabajo original de Steve Souders , o la implementación aquí en Stack Overflow . Si las URL cortas son muy importantes para usted, ¿tal vez lo mejor sería mover la aplicación web fuera de la URL principal, es decir, mover la aplicación de administración de archivos a login.sitename.com?

¿Necesita autenticación en las solicitudes de imagen? Si no, ¿qué tal usar algo como Amazon S3? Es masivamente escalable, y el costo de transferencia de datos es bastante barato. En este caso, usaría algo como i.sitename.com como CNAME DNS para el nombre de host del cubo de Amazon S3, consulte los documentos de Amazons . AFAIK no puede tener el nombre de dominio raíz (sitename.com) como CNAME, por lo que debe usar un subdominio como i.sitename.com para esto.

También puede hacer hash de sus imágenes en varios servidores. Es decir, crea una estructura DNS como login.sitename.com y a.sitename.com; b.sitename.com; c.sitename.com et etcétera. La A." y B." los servidores etc. simplemente contienen un sistema de archivos con imágenes y un servidor HTTP liviano (ya está utilizando Lighttpd, así que continúe usándolo. Para un proyecto futuro, propondría considerar nginx como un mejor reemplazo). Cuando un usuario carga una imagen, crea un hash de un identificador único, tal vez su nombre de usuario, tal vez el nombre del archivo o una combinación de identificadores múltiples . A partir de este hash, usted determina en qué servidor almacenar la imagen.

Editar Debería haber visto que el hashing ya se discutió. Esencialmente, lo que propongo aquí es usar también el hashing en el nombre de host, para distribuir el tráfico de red de manera uniforme en varios hosts.

No sé qué tan barato necesitas que sea , pero cuando estás empujando 100 MBit de tráfico de red, entonces "barato y bueno" rápidamente se convierte en una ilusión. ¿Quizás debería buscar primero obtener un buen modelo de negocio, algo que proporcione ingresos recurrentes, y luego implementar la tecnología adecuada después?


1

¿Asumo que HAProxy está en el mismo servidor que sus otras aplicaciones? Puede dividir HAProxy en otro sistema para ejecutar las solicitudes y hacer que envíe solicitudes normales a un servidor y solicitudes de imágenes a otro servidor. El problema es que todas las solicitudes siguen yendo a un cuadro, y si está saturando su ancho de banda, eso puede no serle de gran ayuda.

Dices que las URL cortas son importantes. ¿Por qué? ¿Es realmente tan importante cambiar las imágenes de "example.com" a "i.example.com"? Puede configurar "i" en su propia IP en su propio servidor con Lighttpd y omitir HAProxy por completo, resolviendo su problema de rendimiento. También obtendría el beneficio del navegador web que permite que se abran más solicitudes a la vez, ya que consideraría que son nombres de dominio diferentes y podría abrir más conexiones concurrentes. Si el único servidor "i" se saturó, podría emplear DNS round-robin para agregar otro. Esperemos que para ese momento esté generando suficientes ingresos para implementar una mejor solución.


Sí, HAProxy está en el mismo servidor, solo tengo uno hasta ahora. Incluso si lo dividí en otro servidor, ¿no seguirían viajando todos los datos a través del servidor con HAProxy, como he explicado anteriormente? Las URL cortas son importantes porque ese es el propósito del sitio. Es un cruce entre ImageShack y TinyPic. Cuanto más larga sea la URL, menos punto tendrá mi sitio. Pero como dije, si la única opción viable es configurar un subdominio, entonces solo tendría que hacerlo. Aunque realmente preferiría no hacerlo.
Alan

1

¿Su proveedor de alojamiento ofrece servicios de equilibrio de carga? Creo que es la mejor solución.

Otra forma de hacerlo, pero debe probarse, es reescribir (en light o apache) las solicitudes. Por ejemplo: example.com/file.html permanece en apache y example.com/image.jpg redirige a i.example.com/image.jpg. Todas las solicitudes se gestionarán a través de apache, pero las respuestas (ancho de banda ascendente) se enviarán al servidor lighttpd. El dominio es transparente para el usuario. Aún así, debe probar si apache puede manejar todas las solicitudes o tal vez dejar que lighttpd haga este trabajo.

Tienes razón, todos los datos pasan a través de HAProxy, por lo que no puedes (por lo que sé) hacer un retorno directo del servidor con él.

ACTUALIZAR

En la documentación de HAproxy encontré el parámetro "redir". No sé si puede funcionar como apache rewrite pero puede ser útil. La documentación dice:

El uso principal consiste en aumentar el ancho de banda para los servidores estáticos al hacer que los clientes se conecten directamente a ellos.

Quizás funcione para su caso.


Hola, gracias por la respuesta. De hecho, ya he probado esto, y no funciona tan bien en la práctica como en teoría. La razón es que Apache maneja todas las solicitudes, por lo que cada vez que un usuario golpea una imagen, Apache se genera, mira la URL y luego se la envía a la ligera. Lo cual no es diferente, entonces solo hacer que Apache maneje la imagen en primer lugar. Estoy de acuerdo en que un equilibrador de carga proporcionado por mi host es la mejor opción, pero también es una de las más caras. Cobran por conexión concurrente, y obtengo cientos de ellos.
Alan

Es diferente en la forma en que el servidor ligero enviará la respuesta directamente al cliente que consume su propio ancho de banda. El problema es que el servidor Apache manejará muchas solicitudes. Verifique la actualización de mi respuesta, encontré otra solución.
hdanniel

1

Supongo que con cualquier conjunto considerable de imágenes no está almacenando las imágenes en función de su nombre de archivo original, ya que se encontraría con conflictos de nombres con bastante rapidez.

Muchas aplicaciones que se ocupan de este tipo de problemas utilizan el hash del archivo y una estructura de directorio basada en ese hash. La estructura del directorio tiene el siguiente aspecto, donde la ruta del directorio son los dos primeros caracteres del hash, luego el directorio de segundo nivel son los siguientes dos caracteres del hash.

/image root/AA/AA/images  
/image root/AA/AB/images

El beneficio aquí es que los hash mantienen la distribución de archivos bastante uniforme y le proporciona un espacio de nombres que es fácil de dividir en varios servidores. Básicamente, sirve porciones del espacio hash desde diferentes servidores y, a medida que escala, puede subdividir esto más según sea necesario.

La desventaja es que los hash no son perfectos y puede haber colisiones. No estoy seguro de cómo se trata esto. Entonces eso puede requerir un poco de investigación de su parte. Me imagino que una regla de reescritura en el proxy debería poder tomar un hash como A3A8BBC83261.jpg y reescribirlo en http://img3.domain.com/A3/A8/BBC83261.jpg . Sin embargo, es posible que no consideres que es una URL corta.


Sí, así es exactamente como estoy almacenando las imágenes. Sin embargo, el problema no es con el almacenamiento, sino con la distribución del ancho de banda.
Alan

Pero si almacena AA a través de 33 en un servidor y 34 a 99 en otro servidor, no solo equilibrará el problema de almacenamiento sino también la distribución del ancho de banda.
3dinfluence

0

En su publicación mencionó que sentía que DNS round robbin podría ser su mejor opción, pero le preocupaba que un solo servidor fallara ...

Si ese es el caso, eche un vistazo a Simple Failover de JH Software. Lo he usado en el pasado y funciona muy bien.

http://www.simplefailover.com

Básicamente, monitorea sus servidores y cuando ve que uno se cae, reescribe rápidamente el DNS para sacar el servidor muerto de la rotación.

Aquí hay un fragmento de su sitio web:

Simple Failover monitorea continuamente sus servidores para descubrir cuáles están activos y cuáles están inactivos, y luego actualiza dinámicamente sus registros DNS en consecuencia para que su nombre de dominio siempre apunte a un servidor funcional.

Funciona con servidores web (HTTP), servidores de correo (SMTP, IMAP, POP3), servidores FTP y prácticamente cualquier otro tipo de servidor basado en TCP / IP.

Como se mencionó anteriormente, lo he usado en el pasado para sitios web y servidores de correo. Funcionó bastante bien. La conmutación por error fue bastante rápida en la mayoría de los casos (suponiendo 2-5min) y diría que casi todos fallaron en menos de 15 minutos.

No necesariamente PERFECTO ... pero definitivamente rápido y fácil.

NOTA: Este es un producto de Windows. No estoy seguro de si tienen una versión de Linux o no, pero puede fallar en cualquier servidor que desee ya que está basado en DNS.

En nuestro caso, simplemente lo lanzamos en una máquina XP, le dijimos a la máquina que se reiniciara una vez por noche y funcionó bien durante años.

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.