Por que usamos instâncias do servidor de múltiplas aplicações no mesmo servidor?

Eu acho que há uma boa razão, mas eu não entendo porque às vezes colocamos por exemplo 5 instâncias com os mesmos aplicativos web no mesmo servidor físico.

Tem algo a ver com uma otimização para uma arquitetura multi-processador? O limite máximo permitido de RAM para a JVM ou algo mais?

Hmmm … Depois de muito tempo eu estou vendo essa pergunta novamente 🙂

Bem, várias instâncias da JVM em uma única máquina resolvem muitos problemas. Primeiro, vamos encarar isso: Embora o JDK 1.7 esteja entrando em cena, muitos aplicativos legados foram desenvolvidos usando o JDK 1.3 ou 1.4 ou 1.5. E ainda um grande pedaço de JDK é dividido entre eles.

Agora a sua pergunta:

Historicamente, há três problemas principais que os arquitetos de sistemas abordaram implementando várias JVMs em uma única checkbox:

  1. Garbage collection inefficiencies: À medida que os tamanhos de heap aumentam, os ciclos de garbage collection – especialmente para as principais collections – tendem a introduzir atrasos significativos no processamento, graças ao GC de encadeamento único. Várias JVMs combatem isso permitindo tamanhos de heap menores em geral e permitindo alguma medida de simultaneidade durante os ciclos de GC (por exemplo, com quatro nós, quando um entra no GC, você ainda tem outros três processando ativamente).

  2. Resource utilization: JVMs mais antigas não conseguiam escalonar com eficiência além de quatro CPUs ou mais. A resposta? Execute uma JVM separada para cada 2 CPUs na checkbox (a quilometragem pode variar dependendo do aplicativo, é claro).

  3. 64-bit issues: JVMs mais antigas não conseguiam alocar tamanhos de heap além do máximo de 32 bits. Novamente, várias JVMs permitem maximizar a utilização de resources.

  4. Availability: um motivo final pelo qual as pessoas às vezes executam várias JVMs em uma única checkbox é a disponibilidade. Embora seja verdade que essa prática não trata de falhas de hardware, ela corrige uma falha em uma única instância de um servidor de aplicativos.

Extraído de ( http://www.theserverside.com/discussions/thread.tss?thread_id=20044 )

Eu tenho visto principalmente o weblogic. Aqui está um link para mais leitura:

http://download.oracle.com/docs/cd/E13222_01/wls/docs92/perform/WLSTuning.html#wp1104298

Espero que isso ajude você.

Eu acho que você está se referindo ao agrupamento de aplicativos.

AFAIK, JVM gerada com tamanho de heap muito grande tem problemas quando se trata de garbage collection, embora eu tenha certeza, brincando com o algoritmo GC e os parâmetros, você pode reduzir os danos ao mínimo. Além disso, os aplicativos em cluster não possuem um único ponto de falha. Se um nó ficar inativo, os nós restantes poderão continuar atendendo os clientes. Esta é uma das razões pelas quais “arquiteturas baseadas em mensagens” são boas para escalabilidade. Cada solicitação é mapeada para uma mensagem que pode ser capturada por qualquer nó em um cluster.

Outro ponto seria atender várias solicitações simultaneamente, caso seu aplicativo infelizmente use palavras-chave sincronizadas de forma criteriosa. Atualmente, temos um aplicativo legado que possui muito estado compartilhado (infelizmente) e, portanto, o processamento de solicitação simultânea é feito gerando cerca de 20 processos de JVM com uma unidade central de distribuição que faz todo o trabalho de distribuição. 😉

Eu sugiro que você use em torno de menos JVM por região NUMA. Se uma única JVM usa mais de uma região NUMA (geralmente uma única CPU), o desempenho pode diminuir significativamente, devido a um aumento significativo no custo de acessar a memory principal de outra CPU.

Além disso, usar vários servidores pode permitir que você

  • use diferentes versões do java ou do seu servidor de aplicativos.
  • isolar diferentes aplicações que poderiam interferir (elas não deveriam, mas poderiam)
  • limite os tempos de pausa do GC entre os serviços.

EDIT: poderia ser histórico. Pode ter havido vários motivos para ter JVMs separadas no passado, mas como você não sabe quais eram, você não sabe se elas ainda se aplicam e pode ser mais simples deixar as coisas como estão.

Um motivo adicional para usar várias instâncias é a capacidade de manutenção.

Por exemplo, se você tiver vários aplicativos diferentes para vários clientes, ter instâncias separadas do servidor de aplicativos para cada aplicativo pode tornar a vida um pouco mais fácil quando você precisar reiniciar o servidor durante uma liberação.

Suponha que você tenha um host de configuração médio e instale uma única instância do servidor web / de aplicativos. Agora seu aplicativo se torna mais popular e o número de accesss aumenta 2 vezes. O que você faz agora ?

Adicione mais um servidor físico da mesma configuração e instale o aplicativo e equilibre a carga desses dois hosts.

Isso não é fim de vida para o seu aplicativo. Seu aplicativo continuará se tornando mais popular e, portanto, a necessidade de ampliá-lo. Qual vai ser a sua estratégia?

  • continue adicionando mais hosts da mesma configuração
  • compre uma máquina mais potente onde você pode criar mais servidores de aplicativos lógicos

Qual opção você vai longe?

Você fará a análise de custos, que envolverá fatores como o custo real do hardware, o custo de gerenciamento desses servidores (custo de energia, espaço ocupado no data center), etc.

Aparentemente, a decisão não é muito fácil. E, na maioria dos casos, é mais econômico ter uma máquina mais potente.