Dimensionamiento de la arquitectura

[jdiazgh]

Hola de nuevo,

el tema de dimensionamiento está muy bien explicado en el pack, pero me ha surgido una duda. Por ejemplo, en el examen de 2008 nos indicaban un número potencial de usuarios concurrentes (3000) y unas consultas de 5kb (a mi me parecen muy pequeñas, pero bueno). Con estas características creo que no vale un único servidor Web (15 Mb de memoria RAM), si además necesitamos alta disponibilidad (24 x 7), he supuesto que necesitaríamos al menos 6 servidores Web con 4 Gb de memoria RAM cada uno en la DMZ balanceados. Supongo que esto no afecta a los servidores de lógica de negocio, si están bien programados, y que con dos servidores en cluster sería suficiente. Lo mismo he pensado de los servidores de BBDD. ¿Estoy en lo cierto?

[vfrades]

No entiendo bien las cuentas que haces para la memoria RAM. Parece que supones que por cada sesión concurrente que atiende el servidor web tiene que cargar de forma permanente 5Kb de información en la RAM. En todo caso sería memoria virtual, no física. Yo creo que en este caso no hay datos suficientes para hacer cálculos de la RAM necesaria.

Quizás la mayor complejidad está en la necesidad de atender 3000 peticiones concurrentes. Un servidor Tomcat por defecto suele tener configurado un número máximo de threads igual a 300. Este valor se puede incrementar, pero llegará un momento en que tengas problemas de memoria o de rendimiento. Habría que hacer pruebas de carga detalladas y determinar el mínimo número de servidores web balanceados que necesitas. Además, los servidores pueden ser físicos o virtuales, pueden estar dedicados a este servicio o compartirlos con otras aplicaciones.

Los datos dados en el enunciado de este examen parecen más adecuados para estimar necesidades de almacenamiento y la capacidad mínima de los enlaces para enviar información de unos sistemas a otros.

[jdiazgh]

Quizás los datos no sean suficientes para estimar el número de servidores, efectivamente, la memoria quizas no sea el enfoque. La cuestión es que, como dices, tendremos un número elevado de usuarios concurrentes. La cuestión es si conociendo este dato se puede planificar el número de servidores dedicados (no compartidos), que serían necesarios. En cuanto si virtualizarlos o no, depende de su número. No podríamos virtualizarlos en unos pocos nodos físicos (uno o dos), ya que correriamos el riesgo de depender demasiado de ellos.

¿El límite entonces estaría en el servidor web o en el de aplicaciones?

[juanopositor]

¿El límite entonces estaría en el servidor web o en el de aplicaciones?

¿Por qué supones que deben ser distintos?
Yo creo que los tendría en el mismo server.

[vfrades]

El límite está siempre en el presupuesto.

En un caso así, en el que parece que tenemos muchas transacciones pero la lógica de negocio es sencilla, parece que hay que poner más medios dedicados a la parte web. Tampoco es necesario poner siempre un servidor de aplicaciones separado del servidor web.

[jdiazgh]

Tienes razón vfrades, en mi administración yo normalmente uso LAMP y la aplicación se ejecuta en el propio servidor web (Apache). Realmente la separación es por motivos de modularidad y rendimiento y creo que para un caso como este separaría uno de otro.

Por otro lado, para este tipo de aplicaciones, el precio de los servidores no suele ser lo más importante. Disponer de líneas de comunicaciones de suficiente capacidad, o de una cabina de almacenamiento SAN es mucho más caro. Por no decir del desarrollo contratado externamente. Y además, no hay más remedio que tener dos o más servidores físicos, para contar con alta disponibilidad.

[jdiazgh]

Creo que para este tema sería muy conveniente disponer de un ejemplo de la arquitectura de una aplicación ya montada en la Administración.

Lo más normal es separar el servidor Web (pongamos Apache) de la lógica de negocio (Tomcat y EJB si hemos escogido Java), más que nada porque el servidor Web debe quedar en una DMZ, para cumplir con los requisitos de seguridad.

Mi idea es que la alta disponibilidad se puede lograr mediante clusters de nodos físicos, y la escalabilidad mediante múltiples instancias de apache y tomcat en estos servidores. También valdría para la base de datos.

El problema viene con las limitaciones, esto es, si suponemos un número muy alto de usuarios concurrentes (supongamos que quiero montar una plataforma de e-learning como la del INAP). Puedo calcular el ancho de banda de las comunicaciones, y parece que es genérico un número máximo de 200 conexiones para un servidor apache o tomcat, pero desconozco las limitaciones de los servidores físicos.