A Carga de Trabalho Não Está Sendo Distribuída
Estas informações podem ser úteis para diagnosticar o problema se estiver tendo um problema de distribuição de cargas de trabalho.
- Pedidos HTTP não são distribuídos a todos os servidores
- Pedidos de Beans Corporativos Não São Distribuídos a Todos os Servidores
Pedidos de Beans Corporativos Não São Distribuídos Uniformemente
- Um Servidor em Falha Ainda Recebe Pedidos de Bean Corporativo (Failover Não Foi Concluído)
- Servidores parados ou bloqueados não compartilham a carga de trabalho depois de serem restaurados
Um Cluster Não Realiza Failover em Seu Cluster de Backup
Procure os logs da JVM do gerenciador de implementação de problemas e dos servidores de aplicativos:
- Consulte as mensagens de erro, clicando na exibição Referência do centro de informações e expandindo Mensagens na árvore de navegação.
Utilize a ferramenta Log and Trace Analyzer para navegar e analisar o log de serviço (activity.log) do gerenciador de implementação e quaisquer nós que encontrem problemas. Visualize os arquivos activity.log em ambos os registros app_server_root/logs e app_server_root/logs.
Analise o registro de serviço (activity.log) do gerenciador de implementação e dos nós que tiverem problemas. Visualize os arquivos activity.log em profile_root/logs.
Se aparecerem exceções Java™ nos arquivos de log, tente determinar o subcomponente real envolvido diretamente no problema, examinando a pilha de rastreio e procurando uma classe relacionada ao produto próximo da parte superior da pilha (nomes que comecem com com.ibm.websphere ou com com.ibm.ws) que criaram a exceção. Se apropriado, reveja as etapas da resolução de problemas do subcomponente apropriado na seção Resolvendo problemas de aplicativos WebSphere no Centro de informações.
Por exemplo, se a exceção parecer ter sido lançada por uma classe do pacote com.ibm.websphere.naming, revise o tópico Dicas de Resolução de Problemas do Componente de Serviços de Nomenclatura.
Procure os logs da JVM do gerenciador de implementação de problemas e dos servidores de aplicativos:
- Consulte as mensagens de erro, clicando na exibição Referência do centro de informações e expandindo Mensagens na árvore de navegação.
Se aparecerem exceções Java nos arquivos de log, tente determinar o subcomponente real envolvido diretamente no problema, examinando a pilha de rastreio e procurando uma classe relacionada ao produto próximo da parte superior da pilha (nomes que comecem com com.ibm.websphere ou com.ibm.ws) que criaram a exceção. Se apropriado, reveja as etapas da resolução de problemas do subcomponente apropriado na seção Resolvendo Problemas de Aplicativos WebSphere no Centro de Informações.
Por exemplo, se a exceção parecer ter sido lançada por uma classe do pacote com.ibm.websphere.naming, revise o tópico Dicas de Resolução de Problemas do Componente de Serviços de Nomenclatura.
- Certifique-se de que todas as máquinas de sua configuração tenham conectividade TCP/IP entre si, executando o comando
ping:
- De cada servidor físico para o gerenciador de implementação
- Do gerenciador de implementação para cada servidor físico
- Apesar do problema estar ocorrendo em um ambiente em cluster, a causa real pode estar apenas indiretamente relacionada, ou não relacionada, a cluster. Investigue todas as possibilidades relevantes:
- Se um enterprise bean em um ou mais servidores não estiver entregando solicitações, revise Não é possível acessar um enterprise bean a partir de um servlet, JSP, programa independente ou outro cliente e Não é possível consultar um objeto hospedado pelo produto a partir de um servlet, arquivo JSP ou outros tópicos do cliente.
- Se parecer que os problemas surgiram depois da ativação da segurança, reveja o tópico Erros ou problemas de acesso depois de ativar a segurança.
- Se um servidor de aplicativos parar de responder às solicitações, ou espontaneamente ficar inativo (seus processos são fechados), reveja o tópico Módulo da web ou servidor de aplicativos fica inativo ou trava.
- Se as solicitações SOAP não estiverem sendo atendidas por um ou todos os servidores, reveja o tópico Erros retornados ao cliente ao tentar enviar uma solicitação SOAP.
Se você tiver problemas ao instalar ou implementar um aplicativo nos servidores de um ou mais nós, reveja o tópico Resolução de problemas de implementação e instalação de código.
Se sua topologia consistir em um gerenciador de implementação baseado no Windows com servidores de sistemas UNIX suportados, procure nos arquivos .xml e .policy atualizados recentemente nos sistemas baseados em UNIX utilizando o editor vi para assegurar-se de que caracteres Control-M não estejam presentes nos arquivos. Para evitar esse problema no futuro, edite esses arquivos utilizando o editor vi nos sistemas baseados em UNIX suportados para evitar a inserção desses caracteres.
Verifique as dicas de resolução de problemas para o componente de gerenciamento de carga de trabalho.
- Verifique se o problema está identificado e documentado, consultando o suporte on-line disponível (dicas e sugestões, notas técnicas e correções).
Pedidos HTTP não são distribuídos a todos os servidores
- Verifique a lista de Servidores Primários. Os balanços de cargas do plug-in entre todos os servidores definidos na lista Servidores Primários, se a afinidade não tiver sido estabelecida. Se não tiver uma lista de Servidores Primários definida, os balanceamentos de cargas do plug-in entre todos os servidores definidos no cluster, se a afinidade não tiver sido estabelecida. No caso da afinidade ter sido estabelecida, o plug-in deve ir diretamente a um determinado servidor para todos os pedidos da mesma sessão HTTP.
- Se alguns servidores estiverem atendendo pedidos e um ou mais dos outros não estiverem, tente acessar um servidor problemático diretamente para verificar se ele funciona, independente de problemas de gerenciamento de carga de trabalho. Se isso não funcionar:
- Utilize o console administrativo para assegurar-se de que o servidor afetado esteja em execução.
- Para obter mais informações, consulte o tópico Recurso da web não é exibido.
- Para obter informações adicionais, consulte o tópico Dicas de resolução de problemas do componente de plug-in de HTTP.
Verifique as etapas para diagnosticar os problemas de gerenciamento de carga de trabalho no tópico do componente Resolução de problemas do componente do Workload Management.
Pedidos de Beans Corporativos Não São Distribuídos a Todos os Servidores
- Utilize o console administrativo para verificar se o servidor foi iniciado. Tente iniciá-lo ou, se iniciado, pare-o e inicie-o novamente.
- Procure no console administrativo se o nó que executa o servidor problemático aparece. Se não aparecer:
- Reveja as etapas para adicionar um nó em um cluster.
- Examine as etapas na seção Um ou mais nós não são exibidos no console administrativo.
- Se possível, tente acessar o enterprise bean diretamente no servidor problemático para ver se há um problema de conectividade TCP/IP, de funcionamento do servidor de aplicativos ou outro problema não relacionado ao gerenciamento de carga de trabalho. Se isso falhar, revise o tópico Não é possível acessar um enterprise bean a partir de um servlet, um JSP, um programa independente ou outro cliente.
Verifique as etapas para diagnosticar os problemas de gerenciamento de carga de trabalho no tópico do componente Resolução de problemas do componente do Workload Management.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Pedidos de Beans Corporativos Não São Distribuídos Uniformemente
- Configuração imprópria
- Problemas de ambiente, como disponibilidade de servidores ou aplicativos
- Um grande número de pedidos que envolve afinidade transacional ou
- Um pequeno número de clientes
O gerenciamento de carga de trabalho no produto
baseia-se em um esquema proporcional calculado para distribuir pedidos entre os servidores. Isso resulta no equilíbrio ser determinado pelos números de pedidos em vez de por qualquer outra medida. Um problema real de equilíbrio é determinado pela comparação do número de pedidos processados por cada membro do cluster com os pesos que foram definidos para cada um desses membros. Isso
é feito seguindo as etapas no tópico Resolução de problemas do componente Workload Management.
O gerenciamento de carga de trabalho no produto baseia-se em um esquema
round robin de distribuição de pedidos. Isso resulta no equilíbrio ser determinado pelos números de pedidos em vez de por qualquer outra medida. Um problema real de equilíbrio é determinado pela comparação do número de pedidos processados por cada membro do cluster com os pesos que foram definidos para cada um desses membros.
![[z/OS]](../images/ngzos.gif)
- Quando a porcentagem de pedidos que chega para cada membro do cluster for consistente com os pesos, então uma análise mais profunda do aplicativo deverá ser feita para determinar a causa para a carga de trabalho que está sendo desequilibrada mesmo quando o número de pedidos estiver compensado.
- Quando o número de numIncomingNonWLMObjectRequests não está compensado entre os membros do cluster e é grande em relação a numIncomingRequests, então a razão para o desequilíbrio são os componentes não distribuíveis instalados nos membros do cluster. Uma modificação na configuração resultará em um ambiente mais compensado.
- Quando o número de numIncomingStrongAffinityRequests não está compensado entre os membros do cluster e é grande em relação a numIncomingRequests, então a razão para o desequilíbrio são os pedidos que são chamados em uma transação. Eles podem ser reduzidos através da instalação de objetos envolvidos em uma transação no mesmo cluster.
Um Servidor em Falha Ainda Recebe Pedidos de Bean Corporativo (Failover Não Foi Concluído)
O cliente podia estar em uma transação com um bean corporativo no servidor que ficou inativo. Verifique os logs da JVM do servidor de aplicativos que está hospedando a instância do enterprise bean do problema. Se um pedido for retornado com CORBA SystemException COMM_FAILURE org.omg.CORBA.completion_status.COMPLETED_MAYBE, pode estar funcionando conforme projetado. O design é permitir que essa determinada exceção volte ao cliente, já que a transação pode ter sido concluída. Fazer failover desse pedidos para outro servidor pode resultar no pedido ser atendido duas vezes.
O cliente podia estar em uma transação com um bean corporativo no servidor que ficou inativo. Verifique os logs da JVM do servidor de aplicativos que está hospedando a instância do enterprise bean do problema. Se um pedido for retornado com CORBA SystemException COMM_FAILURE org.omg.CORBA.completion_status.COMPLETED_MAYBE, pode estar funcionando conforme projetado. O design é permitir que essa determinada exceção volte ao cliente, já que a transação pode ter sido concluída. Fazer failover desse pedidos para outro servidor pode resultar no pedido ser atendido duas vezes.
Se os pedidos enviados aos servidores voltarem ao cliente com alguma outra exceção de forma consistente, pode ser que nenhum servidor esteja disponível. Nesse caso, siga as etapas de resolução conforme descritas no tópico Resolução de problemas do componente Workload Management.
Se os pedidos enviados aos servidores voltarem ao cliente com alguma outra exceção de forma consistente, pode ser que nenhum servidor esteja disponível.
![[z/OS]](../images/ngzos.gif)
Servidores parados ou bloqueados não compartilham a carga de trabalho depois de serem restaurados
Esse erro ocorre quando os servidores indisponíveis anteriormentes não são reconhecidos pelo componente de gerenciamento de carga de trabalho depois de serem restaurados. Há um intervalo de inutilizável determinado pela propriedade com.ibm.websphere.wlm.unusable.interval durante o qual o gerenciador de carga de trabalho aguarda para enviar a um servidor marcado como inutilizável. Por padrão, são 5 minutos.
Você pode confirmar que esse é o problema, assegurando que os servidores que estavam inativos estejam agora ativos e capazes de atender pedidos. Em seguida, aguarde até o intervalo de inutilizável ter decorrido antes de determinar se ocorre failover.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Um Cluster Não Realiza Failover em Seu Cluster de Backup
[10/11/04 13:11:10:233 CDT] 00000036 SelectionMana A WWLM0061W: um erro foi
encontrado enviando um pedido para o membro do cluster {MEMBERNAME=FlorenceEJBServer1,
NODENAME=fwwsaix1Node01} e esse membro foi marcado como não utilizável por pedidos
futuros no cluster "", devido à exceção: org.omg.CORBA.COMM_FAILURE:
CONNECT_FAILURE_ON_SSL_CLIENT_SOCKET - JSSL0130E: java.io.IOException: Indica
que ocorreu uma exceção de E/S de algum tipo. Razão: Conexão recusada
vmcid: 0x49421000 código secundário: 70 concluído: Não"
- Reveja seu nome do host e porta de auto-inicialização do gerenciador de implementação em cada definição do cluster de backup.
- Examine as portas das camadas da ponte do grupo principal para certificar-se de que o nome do host e a porta DCS (Distribution e Consistency Services) estejam corretos.
- Verifique se o nome de seu cluster principal e de backup correspondem.
- Caso seu aplicativo passe pela segurança para ir para o cluster de backup, reveja sua configuração de segurança. Pode ser necessário utilizar SSO (Single Sign On) e importar as chaves LTPA (Lightweight Third Party Authentication) para a célula de backup.