Clusters e Gerenciamento de Carga de Trabalho
Clusters são conjuntos de servidores que são gerenciados juntos e participam no gerenciamento da carga de trabalho. Os clusters permitem que os aplicativos corporativos façam um escalonamento além da quantidade de rendimento de processamento capaz de ser alcançada com um único servidor de aplicativos. Eles também permitem que os aplicativos corporativos estejam altamente disponíveis porque os pedidos são roteados automaticamente para os servidores em execução no caso de falha. Os servidores que são membros de um cluster podem estar em máquinas host diferentes. Por outro lado, os servidores que fazem parte do mesmo nó devem estar localizados na mesma máquina host. Uma célula pode não incluir clusters, ter um, ou vários clusters.
Os servidores que pertencem a um cluster são membros desse conjunto de clusters e todos devem ter componentes de aplicativo idênticos implementados neles. Além dos aplicativos configurados para serem executados neles, os membros do cluster não precisam compartilhar outros dados de configuração. Um membro de cluster pode estar em execução em um grande sistema de servidor corporativo com multi-processador enquanto outro membro desse mesmo cluster pode estar em execução em um sistema menor. As definições de configuração do servidor para cada um desses dois membros do cluster são muito diferentes, exceto na área de componentes aplicativos atribuídos a eles. Nessa área de configuração, eles são idênticos. Isso permite que o trabalho do cliente seja distribuído entre todos os membros de um cluster em vez de toda a carga de trabalho ser tratada por um único servidor de aplicativos.
Ao criar um cluster, você faz cópias de um modelo de servidor de aplicativos existente. O modelo é mais provavelmente um servidor de aplicativos que você configurou anteriormente. Você tem a opção de tornar esse servidor um membro do cluster. No entanto, recomenda-se manter o servidor disponível apenas como um modelo, porque a única forma de remover um membro de cluster é excluindo o servidor de aplicativos. Ao excluir um cluster, você também exclui quaisquer servidores de aplicativos que eram membros do cluster. Não há como preservar qualquer membro de um cluster. Manter o modelo original intacto permite a você reutilizar o modelo se você precisar reconstruir a configuração.
Um cluster vertical possui membros de cluster no mesmo nó ou máquina física. Um cluster horizontal possui membros de cluster em diversos nós em muitas máquinas em uma célula. É possível configurar qualquer tipo de cluster ou ter uma combinação de clusters verticais e horizontais.
O armazenamento em cluster de servidores de aplicativos que hospedam contêineres da Web automaticamente permite o gerenciamento de carga de trabalho do plug-in para os servidores de aplicativos e os servlets que eles hospedam. O roteamento de solicitações do servlet ocorre entre o plug-in de servidor da Web e os servidores de aplicativos armazenados em cluster que usam transportes HTTP ou canais de transporte HTTP.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)

Essa rota é baseada em pesos associados
a membros de cluster. Se todos os membros de cluster tiverem pesos idênticos,
o plug-in enviará pedidos iguais para todos os membros do cluster, supondo
que não existem fortes configurações de afinidade. Se os pesos forem escalados
no intervalo de zero a vinte, o plug-in geralmente roteará pedidos para os
membros de cluster com os valores de pesos mais altos.
É possível utilizar o console administrativo para especificar um peso para um membro de cluster. O peso designado a um membro de cluster deve ser baseado em sua capacidade aproximada, proporcional de realizar trabalho. O valor do peso especificado para um membro específico é significativo somente no contexto dos pesos especificados para os outros membros de um cluster. Os valores do peso não indicam capacidade absoluta. Se um membro de cluster estiver indisponível, o plug-in de servidor da Web roteia temporariamente os pedidos ao redor desse membro de cluster.
Por exemplo, se tiver um cluster que consiste em dois membros, designar pesos 1 e 2 faz com que o primeiro membro obtenha aproximadamente 1/3 da carga de trabalho e o segundo membro obtenha aproximadamente 2/3 da carga de trabalho. No entanto, se você incluir um terceiro membro no cluster, e designar ao novo membro um peso 1, aproximadamente 1/4 da carga de trabalho agora irá para o primeiro membro, aproximadamente 1/2 da carga de trabalho irá para o segundo membro e aproximadamente 1/4 da carga de trabalho irá para o terceiro membro. Se o primeiro membro do cluster ficar indisponível, o segundo membro fica com aproximadamente 2/3 da carga de trabalho e o terceiro membro com aproximadamente 1/3 da carga de trabalho.
Os valores do peso somente aproximam seus objetivos de equilíbrio de carga. Há outras dependências de aplicativos, como simultaneidade de encadeamento, preferências de configuração local, afinidade e disponibilidade de recursos que também são fatores para determinar para onde um pedido específico é enviado. Portanto, não utilize o padrão exato de pedidos para determinar a designação de peso para membros específicos do cluster.
O gerenciamento de carga de trabalho para contêineres EJB pode ser executado configurando o contêiner da Web e os contêineres EJB em servidores de aplicativos separados. Vários servidores de aplicativos podem ser armazenados em cluster com os contêineres EJB, permitindo a distribuição de pedidos do enterprise bean entre contêineres EJB em diferentes servidores de aplicativos.

Nesta configuração, os pedidos do cliente EJB são roteados para contêineres EJB disponíveis em forma de rodízio, com base em pesos do servidor designados. Os clientes EJB podem ser servlets que operam em um contêiner da Web, programas Java™ independentes que usam RMI/IIOP ou outros EJBs.
A política de rota de rodízio pesada pelo servidor assegura uma distribuição de rota compensada com base no conjunto de pesos do servidor que foram designados aos membros de um cluster. Por exemplo, se todos os servidores no cluster tiverem o mesmo peso, a distribuição esperada para o cluster é que todos os servidores recebam o mesmo número de pedidos. Se os pesos para os servidores não forem iguais, o mecanismo de distribuição enviará mais pedidos para o servidor com valor de peso maior do que para os servidores com valor de peso menor. A política assegura a distribuição que você deseja, baseada nos pesos que são designados aos membros do cluster.
Você pode configurar o gerenciamento de carga de trabalho para equilibrar
as tarefas entre diferentes clusters.
É possível optar para que os pedidos sejam enviados para o nó no qual o cliente reside como a rota preferencial. Neste caso, apenas os membros de cluster nesse nó serão escolhidos (utilizando o método de peso de rodízio). Os membros de cluster em nós remotos serão escolhidos apenas se um servidor local não estiver disponível.
Vários servidores que podem atender o mesmo pedido do cliente formam a base para suporte de failover. Se um servidor falhar durante o processamento de um pedido de cliente, o pedido que falhou poderá ser roteado novamente a qualquer um dos demais membros do cluster. Mesmo que vários servidores falhem, desde que pelo menos um membro de cluster esteja em execução, os pedidos do cliente continuam a ser atendidos.
O cluster de backup ainda
funcionará mesmo que todos os membros do cluster principal não estejam disponíveis.