Você deve utilizar os clusters do servidor e os membros do cluster
para monitorar e gerenciar as cargas de trabalho de servidores de aplicativos.
Antes de Iniciar
Você deve compreender suas opções para configurar servidores
de aplicativos. Para auxiliá-lo a compreender
como configurar e utilizar clusters para o gerenciamento da carga de trabalho, considere este
cenário. Os pedidos de clientes são distribuídos entre os membros do cluster em uma única
máquina. Um cliente se refere a qualquer
servlet, aplicativo Java™ ou outro programa ou componente que
conecta o usuário final e o servidor de aplicativos que está sendo acessado.
Em cenários de gerenciamento de carga de trabalho mais complexos, é possível distribuir membros do cluster em máquinas remotas.
Em cenários de gerenciamento de carga de trabalho mais complexos, é possível distribuir os membros de cluster no mesmo sysplex.
Sobre Esta Tarefa
Execute as seguintes etapas se você decidir utilizar os clusters para
balancear a sua carga de trabalho.
Procedimento
- Decida qual servidor de aplicativos deseja colocar no cluster.
- Decida se você quer replicar dados. A replicação é um serviço
que transfere dados, objetos ou eventos entre servidores de aplicativos.
É possível criar um domínio de replicação
ao criar um cluster.
- Implemente o aplicativo no servidor de aplicativos.
- Criar um cluster.
Depois de configurar o servidor de aplicativos e os componentes de aplicativo exatamente
como desejado, crie um cluster. A instância original do servidor torna-se um membro do cluster administrado pelo cluster.
- Crie um ou mais membros de cluster.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Configure um cluster de backup.
Evitar Problemas: Se possuir clientes em
execução em um ambiente:
- Isso inclui Java thin
clients,
- Onde a solicitações estão sendo roteadas entre diversas células, ou
- Onde solicitações estão sendo roteadas dentro de uma única célula que inclui
nós de versões anteriores do produto,
eles podem, de repente, encontrar uma situação em que as informações de
porta sobre os membros de cluster do cluster de destino se tornaram obsoletas.
Essa situação ocorre com mais frequência quando todos os membros do cluster possuem portas dinâmicas e são reiniciados durante um período de tempo em que nenhuma solicitação é enviada. O processo do cliente nesse estado
tentará, eventualmente, rotear para o agente de nó para receber os novos dados
de porta dos membros do cluster e, em seguida, usar esses novos dados de porta
para rotear de volta para os membros do cluster.
Se ocorrer qualquer problema que impeça o cliente de se comunicar com
o agente do nó, ou que impeça que os dados da nova porta sejam propagados
entre os membros de cluster e o agente do nó, poderão ocorrer falhas de
solicitação no cliente. Em alguns casos, estas falhas são temporárias. Em outros casos, é necessário reiniciar um
ou mais processos para resolver a falha.
Para contornar os problemas de roteamento do cliente que
possam suscitar nestes casos, é possível configurar portas estáticas nos
membros de cluster. Com portas estáticas, os dados da porta não são alterados
conforme um processo do cliente obtém informações sobre os membros de cluster. Mesmo
se os membros de cluster são reiniciados, ou há problemas de comunicação ou de
propagação de dados entre os processos, os dados da porta que o cliente
retém ainda são válidos. Esta alternativa não resolve necessariamente
os problemas subjacentes de comunicação ou propagação de dados, mas remove
os sintomas de decisões de roteamento do cliente inesperadas ou irregulares.
gotcha
Um
cluster de backup manipulará os pedidos se o cluster principal falhar.
- Inicie o cluster.
Ao iniciar o cluster, todos os servidores de aplicativos que forem membros desse
cluster serão iniciados.
O gerenciamento de carga de trabalho é automaticamente iniciado
depois que os membros de cluster se iniciam.
- Depois que o cluster estiver em execução, será possível executar as seguintes tarefas:
- Pare o cluster.
- Faça upgrade dos aplicativos que estão instalados nos membros do cluster.
- Detecte e manipule os problemas com os clusters do servidor e suas cargas de trabalho.
- Altere com que frequência o estado de gerenciamento
da carga de trabalho do cliente é atualizada.
O
valor de tempo limite padrão para a propriedade JVM
com.ibm.CORBA.RequestTimeout é 0, que indica espera infinita. Esse valor padrão não é uma boa configuração para situações de failover.
Portanto, se seu aplicativo estiver tendo problemas com tempos limites, ou você tiver
configurado seu sistema para situações de failover, utilize a opção -CCD no comando
LaunchClient para definir um valor apropriado diferente de zero para essa propriedade.
Se o estado do gerenciamento de carga de trabalho de um cliente for atualizado muito cedo ou muito tarde, altere a configuração de intervalo da propriedade customizada com.ibm.websphere.wlm.unusable.interval da JVM.
![[IBM i]](../images/iseries.gif)
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
O que Fazer Depois
Para clientes Java independentes, é preciso definir
um host de auto-inicialização. Os clientes Java independentes são clientes localizados em uma máquina diferente do
servidor de aplicativos e não possuem servidor administrativo. Inclua a seguinte linha nos argumentos JVM (Java Virtual Machine) para o cliente:
-Dcom.ibm.CORBA.BootstrapHost=machine_name
em que
machine_name é o nome da máquina na qual o servidor administrativo está em execução.