it-swarm-es.com

¿Qué problemas potenciales debo tener en cuenta en un entorno multiservidor / en clúster?

He estado trabajando en un sitio web con un cliente durante algún tiempo y el sitio en sí ha crecido enormemente en popularidad. Ahora estamos en la etapa en la que la única máquina que tenemos alojando el sitio está luchando por mantener las solicitudes y hemos optimizado el sitio en la medida de lo posible (almacenamiento en caché, etc.).

Ahora estamos en la etapa en la que necesitamos agregar otro servidor para soportar la tensión adicional que lleva a mi pregunta: ¿qué posibles peligros y advertencias debo tener en cuenta o probar el sitio cuando me traslade a una granja web o alojamiento en clúster? ¿ambiente?

3
Wolfwyrd

Hay varias advertencias posibles:

Sesiones

Si las sesiones se almacenan del lado del servidor, (es decir, PHP), ambos servidores necesitarán acceso a una ruta de almacenamiento de sesión compartida. De lo contrario, perderá sesiones ya que el equilibrador de carga envía solicitudes de un servidor a otro, o posiblemente (jadeo) tenga un usuario con dos sesiones únicas. Esto puede ser particularmente frustrante con AJAX. Las sesiones 'fijas' también pueden ser posibles, dependiendo de su balanceador de carga.

Archivos temporales

Ambos servidores deben compartir el mismo directorio/tmp, si de hecho utiliza algún tipo de archivo temporal mientras trabaja para atender solicitudes. Esto podría ser un archivo temporal que se comprime para una descarga, una base de datos de archivo plano que realiza un seguimiento de algo, lo que sea.

Bloqueo SQLite

Si usa SQLite3, puede notar algunas peculiaridades que nunca surgieron antes, especialmente si está usando algo como NFS para compartir los archivos de la base de datos entre los servidores. NFS es lento con esto, por lo que recomiendo usar algo más. Los sistemas de archivos distribuidos como Lustre son fáciles de configurar, o puede usar GFS/OCFS2.

SSL

Probablemente desee que el equilibrador de carga sea el que maneje el protocolo de enlace SSL, que luego realiza la solicitud a los servidores de back-end utilizando cualquier certificado antiguo autofirmado.

Algunas notas generales:

  • Como se señaló, use un sistema de archivos de alto rendimiento para compartir directorios. Todos los archivos compartidos deben vivir en el almacenamiento de red, no en uno de los servidores web. De lo contrario, si uno cae, ambos son inútiles, de alguna manera frustra el propósito.

  • Si el sitio usa un RDBMS, tiene dos opciones. Ejecútelo en ambos nodos y use una sincronización maestro-maestro, o coloque el servidor DB en su propio hogar. Recomiendo el segundo porque eso le da a sus servidores web mucho más espacio para operar.

  • Los equilibradores de carga también necesitan redundancia.

En la mayoría de los casos, puede pasar de un único servidor a una granja de servidores con carga equilibrada, con pocos cambios o sin cambios en el sitio/aplicación en sí, pero deberá asegurarse de que todos los nodos puedan leer y escribir en los mismos archivos. Esto puede requerir que agregue algo de lógica para bloquear la aplicación en sí.

1
Tim Post

El estado de la sesión (si eso es un problema) es un problema potencial. La mayoría de los dispositivos de equilibrio de carga pueden usar sesiones fijas, lo que significa que un usuario que termina en SERVER1 para comenzar permanecerá en SERVER1, generalmente mediante el uso de una cookie almacenada en la memoria del navegador. La única advertencia con esto es que cuando SERVER1 se desconecta por cualquier motivo, ese usuario tendrá que iniciar sesión nuevamente en otro servidor.

Comencé a pasar esto por alto en mis aplicaciones (son aplicaciones CF) compartiendo sesiones en la granja de servidores. Por lo tanto, una máquina que no funciona no afectará la experiencia del usuario.

El único otro desafío que he enfrentado para replicar el contenido correctamente a todos los servidores de la granja. Hay un software para hacer esto (robocopy, Fling del software NCH son dos que he usado), pero todavía he tenido casos en los que la sincronización no funcionó el 100% del tiempo.

0
Milner

¿Su aplicación se preocupa por el estado? Si un usuario tiene una solicitud atendida por una máquina y luego otra atendida por otra, ¿importa? Si necesita persistir alguna forma de estado entre solicitudes, entonces todo es más complicado y hay varias formas de abordar el problema.

Si no necesita preocuparse por el estado, entonces es un buen trabajo construir su sitio, y sus cosas deberían estar relativamente bien con un proxy y algunos servidores de back-end.

Si necesita mantener el estado, hay varias formas de crear una sesión fija a través del proxy para que el mismo servidor de fondo maneje todas las solicitudes de un solo usuario, pero también hay muchas cosas que hacen que esas sesiones sean difíciles de mantener. .

También puede mantener el estado en un medio común en el back-end, por lo que cada servidor cargará el mismo estado para el mismo usuario. Puede hacer esto con una base de datos (quizás demasiado lenta) o algo así como memcached .

¿También está aumentando la cantidad de servidores de bases de datos? Eso traerá otros problemas por los que preocuparse.

Algunos de los problemas de la sesión se analizan en el Podcast de desbordamiento de pila Número 6

Para las pruebas, asegúrese de golpear con fuerza un clúster de prueba similar para que pueda ver cómo funcionan sus solicitudes cuando se dirigen a través de muchos servidores, porque es probable que tenga problemas con muchas solicitudes del mismo cliente a diferentes servidores. algo en su plan de prueba hace que eso ocurra.

También es posible que desee leer sobre Stack Overflow's config de red

0
danivovich