Obtuvimos esta aplicación web JavaEE (JSP+Struts+Hibernate+MySQL) que actualmente se ejecuta en un único servidor. Debido al crecimiento del sitio web y a los problemas de rendimiento, hemos decidido agrupar el proyecto en algunas máquinas. El sitio web debería tolerar unas 5000 solicitudes por segundo. Después de buscar en Google y leer cosas, encontré algunas estrategias para hacer esto:
- Usando Apache como balanceador de carga front-end y proxy inverso, algunas instancias de Tomcat, cada una en una máquina separada, y finalmente un servidor de base de datos que ejecuta MySQL. Las instancias de Tomcat pueden escalar en el momento de necesidad.
- Usandonginxcomo balanceador de carga front-end y proxy inverso. El resto sería igual que el anterior.
- UsandoHAProxycomo balanceador de carga front-end y proxy inverso. El resto sería igual que el anterior.
Supongo que en los enfoques antes mencionados todo el tráfico debería pasar a través del equilibrador de carga frontal (Apache, Nginx o HAProxy Server). esto convierte al servidor front-end en un cuello de botella y también en un SPOF. ¿Está bien? ¿Puede un único servidor front-end tolerar todo el tráfico de una gran aplicación web?
Para solucionar este problema, se me ocurrió una estrategia algo artesanal:
- Colocar la página de inicio de sesión y autenticar las acciones en un servidor front-end (por ejemplo, será accesible desde myapp.com). cuando un usuario inicia sesión correctamente, se le redirige a uno de los servidores backend (como srv1.myapp.com) y continúa su actividad allí.
Entonces, ¿estoy en el camino correcto?
Déjame saber tus opiniones sobre estos enfoques y si estás pensando en uno mejor, menciónalo aquí.
Respuesta1
Poner la página de inicio de sesión en un servidor frontend y redirigirla al backend es una mala idea. Los usuarios pueden marcar sus servidores backend, usted puede terminar con una distribución desigual y cuando un servidor falla, los usuarios seguirán intentando acceder a él si están en la misma sesión.
Lo que necesitas es un activo/pasivo (Latido del corazón/Marcapasos/Conmutación por error de IP/Conmutación por error de DNS) o activo/activo (Operación por turnos de DNS/equilibrio de carga de red) servidores front-end.
Con activo/pasivo, todo su tráfico sería redirigido a un servidor frontend, con un segundo en espera (modo de espera activo). Cuando el primero fallaba, de alguna manera realizarías una conmutación por error (Ether reasignando la dirección IP o modificando el DNS*) para apuntar al segundo servidor.
Con activo/activo tendrías dos (o más) servidores constantemente activos, usando etherOperación por turnos de DNSoEquilibrio de carga de IP/redpara distribuir la carga (aproximadamente) uniformemente entre los dos. Luego, los dos servidores volverían a distribuir la carga a sus servidores backend.
activo/activo es el método utilizado por la mayoría de las aplicaciones web grandes (mire los registros DNS de Youtube/Google/Twitter/Wordpress.com/Tumblr y tendrán múltiples IP para los servidores para el round robin de DNS.
Una vez que haya tomado esa decisión y la haya implementado, todo lo que le queda es elegir entre soluciones. Personalmente sugeriríaNGINXpero cada uno tiene su preferencia (HAProxy,Calamar,Cherokee,Velocidad de la luz,F5(hardware),cisco(hardware) y muchos otros).
Desafortunadamente, para este tipo de preguntas no podemos simplemente decir "haz esto" porque realmente depende de cuáles sean tus requisitos. Investigue algunas de las palabras clave anteriores y, si tiene alguna pregunta específica, no dude en preguntar.
* Si es posible, probablemente se debería evitar la conmutación por error basada en DNS; algunos clientes almacenarán en caché el DNS más allá de su TTL, por lo que no es lo ideal.
Respuesta2
No sé acerca de nginx, pero puedes emparejar un par de balanceadores de carga haproxy en una configuración activa/pasiva para evitar que haproxy se convierta en ese único punto de falla.
También existen soluciones comerciales, pero por alguna razón no parecen recibir tanta "tinta" en caso de error del servidor.