¿Cómo compartir activos entre múltiples servidores web?

16

Tengo varios servidores web de Linux conectados a un equilibrador de carga, y me gusta compartir activos (como imágenes, videos y otras cosas) entre estos servidores. ¿Cuál es la mejor manera de hacer esto?

Actualmente, he montado en un servidor de archivos a todos los servidores web, pero me preocupa que se caiga bajo un tráfico pesado. ¿Cómo puedo evitar que esto suceda?

Gracias por adelantado.

linux web-server file-sharing

— getmizanur
fuente

Aquí es donde cosas como Cassandra (bases de datos NoSQL) son útiles.

— Alexis Wilke

¿Consideró usar Varnish para mejorar el rendimiento en tráfico pesado? en.wikipedia.org/wiki/Varnish_%28software%29

— Thorbjørn Ravn Andersen

12

Hay varias formas de hacerlo según sus necesidades.

Use un servidor de archivos central montado con fx NFS en los servidores web
Igual que el anterior, pero redundante, por lo que si uno cae, el otro se hace cargo
Use algún tipo de herramienta de sincronización (rsync por ejemplo) y aloje los archivos localmente en los servidores web. Luego configure un cronjob para sincronizar los archivos entre los servidores en un intervalo específico.
Use un CDN como Amazon S3, Akamai, etc.

Los dos primeros son mejores si tiene muchos archivos nuevos por venir. La tercera sería la solución ideal si no agrega o cambia archivos con tanta frecuencia, ya que los usuarios obtendrán 404 en contenido estático que aún no está sincronizado.

La última opción podría ser ideal en muchos sentidos, pero también podría ser la más cara de las 4. También necesitaría reescribir sus sitios web para admitir esto.

— Frederik Nielsen
fuente

El gran problema con rsync es que es probable que obtenga un 404 si carga nuevos datos y el rsync no ocurre muy rápido ... También un sistema como Cassandra (punto 4) es gratuito, aunque por supuesto tener 10 servidores no lo es. gratis ... así que, tal vez debería decir sin cargo adicional (aunque necesita algo de programación para que todo funcione).

— Alexis Wilke

@AlexisWilke: tienes razón sobre rsync, y también lo mencioné en la respuesta. Lo he aclarado en la respuesta ahora.

— Frederik Nielsen

Re: # 3, el 'tiempo muerto' entre el nuevo activo implementado y el nuevo activo sincronizado se puede minimizar si usa un observador del sistema de archivos (como el vigilante de Facebook ) y una herramienta de sincronización rápida (como csync2 ). No, el retraso nunca bajará a cero, pero es muy mínimo y podría ser más fácil de implementar que las otras alternativas.

— pepoluan

2

Otra excelente manera de disminuir la carga en los servidores web y realizar el equilibrio de carga es con squid (es decir, squid3). Configúrelo como un proxy inverso con almacenamiento en caché. Almacenará en caché el contenido estático, como imágenes, etc., ya sea en el HDD (predeterminado) o en la RAM (más rápido y mejor) si lo configura de esa manera. Es capaz de hacer round robin a otros servidores squid también si algún nodo en particular está sobrecargado.

— Aihngel Tech
fuente

1

Creo que ese tipo de almacenamiento en caché falla si quieres un sitio web muy dinámico. Porque con un gran dinamismo, aún necesita acceder al servidor de back-end principal para obtener una gran cantidad de datos. Creo que el usuario está buscando dividir el trabajo de back-end.

— Alexis Wilke

1

Su respuesta es correcta acerca de la reducción potencial de la carga, pero no responde la pregunta sobre compartir archivos de activos entre múltiples servidores.

@AlexisWilke lo hace (falla) si no tiene la configuración de calamar correctamente. Ajuste cómo se almacena en caché (o si se almacena en caché) en la configuración, pero es posible que ninguna página sea completamente dinámica. Siempre hay algo que puede almacenar en caché. También Andre, ayuda mucho compartir recursos como lo describe el título, pero compartir archivos no tanto. La pregunta era cómo evitar que los sitios caigan bajo una carga pesada. El calamar es excelente para hacer esto.

— Aihngel Tech

1

Dado que generalmente la necesidad de más servidores proviene de los recursos necesarios para ejecutar sitios web / aps dinámicos, considere alojar activos estáticos en otro subdominio / dominio. (como static.yourdomain.com)

Luego puede usar otro servidor / servidores para alojarlos. El alojamiento de archivos estáticos no utiliza muchos recursos, por lo que necesitará considerablemente menos servidores para su contenido estático. También liberará algunos recursos en los servidores para su contenido dinámico.

Dependiendo de su balanceador de carga, es posible que también pueda hacer esto en el mismo dominio con el balanceador de carga que decida qué servidor usar para cada solicitud, pero si usa un dominio separado, puede poner sus activos estáticos en un CDN bastante fácil, si la necesidad debe surgir!

— Josef dice reinstalar a Mónica
fuente

1

Una solución a este desafío que he empleado es tener la copia principal de lectura / escritura de los archivos en una unidad NFS compartida, pero también mantener una copia de solo lectura en cada servidor web para que una falla del host NFS ponga acceso a los archivos en modo de solo lectura en lugar de perderlos por completo.

Los archivos viven en el host central, se comparten con los hosts web a través del montaje NFS
rsync se ejecuta cada 15 minutos para mantener actualizada la copia de solo lectura en cada servidor web.
Se check_linkejecuta un script bash cada minuto para asegurarse de que el montaje NFS sigue ahí y, si no, intercambia un enlace simbólico a la copia de solo lectura.

Se encuentran más detalles en este artículo desde la primera vez que configuré este sistema.

Upsides:

Las lecturas de archivos están altamente disponibles
No hay condiciones de carrera para las escrituras de archivos
Los archivos nuevos están disponibles al instante para todos los servidores web.

Desventajas:

Un poco complejo.
el número de copias de solo lectura aumenta con el número de servidores web, lo que podría ser excesivo si tiene muchos más de dos.
Las escrituras de archivos no están altamente disponibles.
Potencial de hasta 1 minuto de tiempo de inactividad antes de cambiar a la copia de solo lectura.

— Adam Franco
fuente

0

Es posible que desee considerar una base de datos NoSQL. Están diseñados para trabajar en clústeres, proporcionan una consistencia eventual. Pero tenga cuidado de que no sean ACID.

Aquí hay una introducción que lo ayudará a decidir qué tipo de base de datos NoSQL desea para su propósito.

Aquí hay una lista de recursos relacionados con NoSQL disponible.

— Azzy
fuente

44

¿Cómo ayuda esta respuesta en el problema de sincronización de archivos?

— titus

@titus En NoSQL, cuando hay una escritura en uno de los nodos, se replicará en otros nodos del clúster. Los niveles de coherencia de escritura de Cassandra podrían ayudar a aclararlo

— Azzy

Entonces, ¿el camino a seguir es almacenar todos los archivos en NoSQL db?

— titus

@titus puede, pero las bases de datos NoSQL pueden hacer mucho más que almacenar archivos. Todo depende de sus necesidades.

— Azzy

2

OP solicitó una solución a un problema específico " varios servidores web Linux conectados a un equilibrador de carga ... comparten activos (como imágenes, videos y otras cosas) entre estos servidores " . Su respuesta es muy genérica, ¿puede sugerir y ¿Explicar herramientas específicas (y preferiblemente configuraciones de las mismas) para abordar el problema?

— kdbanman

0

¿Por qué no prueba una solución DFS? Proporcionan un alto nivel de redundancia y el volumen puede compartirse entre tantos como desee. Gluster es mi favorito y es muy fácil de instalar y configurar en cualquier distribución famosa de Linux

— Arash mo
fuente