Recomendação de configuração de cluster para um aplicativo Java-WebSphere-SQL Server

Question

Atualmente, temos um aplicativo da Web baseado em Java que é executado no WebSphere e acessa o SQL Server 2008.

O aplicativo requer alterações freqüentes de código e arquivo e, portanto, atualizamos os arquivos EAR no WebSphere pelo menos uma vez em um mês, mas geralmente com mais frequência. É um aplicativo intensivo de banco de dados.

O tempo de inatividade é extremamente caro para nós e, no momento, tentamos fazê-lo durante os períodos de menor carga (por volta das 3h da manhã nos dias úteis). De agora em diante, parece que isso não será uma opção (especialmente considerando as freqüentes atualizações do nosso aplicativo) e estamos procurando por uma melhor configuração de hospedagem, como um cluster. Esperamos resolver alguns dos nossos outros problemas também através da nova configuração (para a qual, até agora, estamos recorrendo a soluções alternativas).

Temos um cluster de vários nós em mente. Meu entendimento dos clusters é primitivo, então se qualquer suposição abaixo estiver errada, por favor me avise.

Os seguintes são nossos novos requisitos:

• Devemos ser capazes de implantar novas versões do aplicativo sem nenhum tempo de inatividade (ou apenas alguns segundos).
• Balanceamento de carga de solicitações da web.
• Capaz de lidar com um failover.

Aqui estão algumas perguntas que tenho:

1. Que tipo de configuração de servidor você recomendaria?
2. Considerando que temos um banco de dados, é realmente possível garantir quase zero tempo de inatividade, a menos que tenhamos dois clusters - um para o banco de dados e outro para a camada da web do aplicativo?
3. Se tivéssemos apenas um cluster para a camada da web (e o banco de dados em um servidor dedicado), isso nos permitiria implementar novas versões do aplicativo sem interrupções no WebSphere?
4. Nosso aplicativo Java foi escrito para ser executado em uma única JVM. Se implementarmos no WebSphere, o WS faria automaticamente o aplicativo ser executado em um cluster? Ou teríamos que fazer uso de uma JVM com reconhecimento de cluster como Terracota?

Answer 1

Parece que você precisa de dois clusters. Você precisa de um cluster de balanceamento de carga para o aplicativo da web com um balanceador de carga na frente dos servidores da web para balancear o tráfego da web para que, se um servidor ficar inativo, o outro manipule a carga. Dessa forma, você pode tirar uma máquina do cluster, atualizá-la para fazer as alterações no banco de dados, depois remover a máquina com a versão antiga e colocar na máquina com a nova versão.

No lado do banco de dados, você desejará um cluster Ativo / Passivo. Isso permitirá que o serviço seja reiniciado em segundos, no caso de uma falha de hardware na nota que está executando a instância do SQL. Isso não fará nada para evitar interrupções no caso de uma liberação incorreta ou se o processo de liberação do banco de dados bloquear objetos de banco de dados. Isso também não escalará a carga do banco de dados entre os dois (ou mais) nós do cluster. Os clusters SQL executam a instância do SQL em um único nó físico a qualquer momento.

    

Answer 2

Isso provavelmente é desnecessário, mas não se esqueça de que tudo o que você confia na sincronização da JVM ou nos dados singleton / global não estará mais seguro nos servidores WebSphere em cluster.

Não posso abordar nada sobre o uso de uma JVM com reconhecimento de cluster com o WebSphere. Eu sei que o WebSphere geralmente não suporta execução em qualquer JVM diferente da sua, mas o Google indica que algumas pessoas estão combinando esses produtos.

Com o WebSphere, você também quer pensar sobre o que tem na frente do Application Server para manter a afinidade de Sessão para um membro de cluster específico e para suportar o failover quando um membro de cluster estiver inativo. Isso normalmente é tratado pelo WebSphere Plugin para um determinado Web Server, como o IBM HTTP Server ou Microsoft IIS.

No entanto, nossa experiência tem sido que, mesmo quando você deliberadamente desce um membro do cluster, ainda é não instantâneo que os pedidos começam a ser encaminhados para o (s) outro (s) .

E se você precisar de failover de sessão (IMO, não necessariamente obrigatório), configure também o Session Manager para sessões distribuídas (por meio do armazenamento do banco de dados ou via replicação de sessão memória a memória). O que também traz restrições adicionais sobre o que você armazena na sessão, já que seu conteúdo agora terá que ser serializável. E você terá que selecionar uma das estratégias disponíveis para decidir quando armazenar ou replicar os dados da memória para o local distribuído.