showcase example ejemplo descargar java java-ee jvm appserver

java - example - struts showcase



Múltiples JVMs vs servidor de una sola aplicación (4)

Comprobación de JVM ''multi-tenant''.

El JRE de IBM ya lo tiene: http://www.ibm.com/developerworks/library/j-multitenant-java/

Waratek lo ha implementado sobre el JRE de Oracle y crearon ElastiCat, una bifurcación de Tomcat que aísla diferentes aplicaciones en el mismo contenedor: http://www.elasticat.com/faq/

Se rumorea que la tenencia múltiple también aparecerá en la JVM oficial de Java 9.

================================================== =====

Actualización: Java 9 está disponible, pero no hay información de Oracle sobre la tenencia múltiple. Parece que prefieren tener múltiples JVM en estos días, incluso varios Contenedores (por ejemplo, docker).

Estoy tratando con un sistema que ejecuta una aplicación Java por cliente en su propia JVM. Tenemos alrededor de media docena de servidores dedicados que ejecutan cerca de 100 JVM en total ahora y conjuntos de scripts personalizados para administrar estas JVM. En este punto, esta configuración realmente muestra su edad: gestionar que muchas JVM se está convirtiendo en una pesadilla de monitoreo / administración y estamos constantemente lidiando con problemas de tamaño de pila. Nos gustaría pasar a un enfoque más moderno y simplemente ejecutar un grupo de aplicaciones en un solo servidor de aplicaciones por máquina física. Sin embargo, mantener las aplicaciones separadas tiene distintas ventajas en términos de aislamiento (por ejemplo, los errores de falta de memoria solo afectan a un cliente). La pila de software de cada cliente tiene requisitos de memoria que varían ampliamente.

Mi pregunta: ¿hay una manera de tener lo mejor de ambos mundos aquí y ejecutar varias aplicaciones en una JVM (servidor de aplicaciones) y aún mantener un cierto nivel de aislamiento? ¿O es solo un hecho moderno de la vida que necesita administrar los requisitos de memoria de un conjunto de aplicaciones en estos días? ¿Hay otras soluciones aquí además de un servidor de aplicaciones o un contenedor Java EE (por ejemplo, Wildfly o Spring) que me estoy perdiendo aquí? ¡Parece que este sistema es una retención de otra era!

Hay ventajas y desventajas de cualquier enfoque:

JVM compartida

  • Gastos indirectos más bajos: la huella de memoria de JVM (bibliotecas del núcleo, etc.) solo necesita cargarse una vez.
  • Mejor uso de la memoria. Los procesos de Java consumirán la memoria del sistema operativo para el espacio de almacenamiento dinámico que puede no estar actualmente en uso.

JVM separada

  • Aislamiento de aplicaciones ''codiciosas'' o ''fugas''.
  • Mejor seguridad frente a códigos maliciosos.
  • Actualizaciones más fáciles, actualizando una aplicación sin derribar la otra.

En general, no establecería una política general. Busque aplicaciones pequeñas / microservicios u otras aplicaciones de bajo uso que puedan ser buenas candidatas para compartir primero y expandirse desde allí.

Otra razón importante para tener múltiples JVM en lugar de uno es cuando se enfrentan a numerosos grupos. No puede distribuir sus subprocesos dentro de una JVM adecuada en numerosos grupos, ya que puede hacerlo con múltiples procesos jvm. Al menos nunca encontré la forma de hacerlo.

Aquí tenemos máquinas con dos cpu, cada una con 18 núcleos. Esto da dos grupos numa y no podemos hacer que 34 subprocesos se distribuyan en ambos cpu si solo se utiliza una JVM. Esto es obviamente porque asume que todos los subprocesos del mismo proceso JVM necesitan tener un acceso rápido a la misma memoria, lo que no es el caso.

Teniendo 34 procesos, el sistema asume que no necesita memoria compartida y, por lo tanto, los distribuye en ambos CPU.

Si alguien sabe una mejor manera de hacerlo, me encantaría escucharlo.