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.

Nota: Esse tópico faz referência a um ou mais arquivos de log do servidor de aplicativos. Como uma recomendação alternativa, é possível configurar o servidor para usar a infraestrutura de log e rastreio do High Performance Extensible Logging (HPEL) em vez de usar os arquivos SystemOut.log , SystemErr.log, trace.log e activity.log em sistemas distribuídos e IBM® i. Também é possível usar HPEL em conjunção com os recursos de criação de log z/OS nativos. Se você estiver usando HPEL, será possível acessar todas as informações de log e rastreio usando a ferramenta de linha de comandos LogViewer a partir do diretório bin do perfil do servidor. Consulte as informações sobre a utilização do HPEL para resolução de problemas dos aplicativos para obter mais informações sobre o uso do HPEL.
Se nenhuma dessas descrições de soluções de problemas corrigir seu problema:
  1. [AIX Solaris HP-UX Linux Windows][IBM i]Procure os logs da JVM do gerenciador de implementação de problemas e dos servidores de aplicativos:
    1. Consulte as mensagens de erro, clicando na exibição Referência do centro de informações e expandindo Mensagens na árvore de navegação.
    2. [AIX Solaris HP-UX Linux Windows][IBM i]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.
    3. [IBM i]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.
    4. 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.

  2. [z/OS]Procure os logs da JVM do gerenciador de implementação de problemas e dos servidores de aplicativos:
    1. Consulte as mensagens de erro, clicando na exibição Referência do centro de informações e expandindo Mensagens na árvore de navegação.
    2. 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.

  3. Certifique-se de que todas as máquinas de sua configuração tenham conectividade TCP/IP entre si, executando o comando ping:
    1. De cada servidor físico para o gerenciador de implementação
    2. Do gerenciador de implementação para cada servidor físico
  4. 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:
    1. 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.
    2. 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.
    3. 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.
    4. 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.
    5. [AIX Solaris HP-UX Linux Windows][IBM i]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.
  5. [AIX Solaris HP-UX Linux Windows][IBM i]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.
  6. [AIX Solaris HP-UX Linux Windows][IBM i]Verifique as dicas de resolução de problemas para o componente de gerenciamento de carga de trabalho.
  7. 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

Se os pedidos HTTP não estiverem sendo 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.
  • [AIX Solaris HP-UX Linux Windows][IBM i]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

Se um cliente não puder alcançar um servidor de um cluster que esperava-se ser alcançado, um servidor pode estar marcado como inutilizável ou estar inativo. Para verificar isso:
  • 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.
  • [AIX Solaris HP-UX Linux Windows][IBM i]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][IBM i]

Pedidos de Beans Corporativos Não São Distribuídos Uniformemente

Há várias razões possíveis para esse comportamento, que geralmente estão em uma ou mais destas categorias:
  • 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

[AIX Solaris HP-UX Linux Windows][IBM i]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.

[z/OS]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]
  • 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)

Algumas das possíveis causas para esse problema são:
  • [AIX Solaris HP-UX Linux Windows][IBM i]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.
  • [z/OS]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.
  • [AIX Solaris HP-UX Linux Windows][IBM i]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.
  • [z/OS]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]

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][IBM i]

Um Cluster Não Realiza Failover em Seu Cluster de Backup

Você pode receber um erro semelhante à amostra a seguir:
[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" 
Execute as etapas a seguir para corrigir sua configuração:
  1. Reveja seu nome do host e porta de auto-inicialização do gerenciador de implementação em cada definição do cluster de backup.
  2. 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.
  3. Verifique se o nome de seu cluster principal e de backup correspondem.
  4. 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.

Ícone que indica o tipo de tópico Tópico de Referência



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_wlmprobs
Nome do arquivo: rtrb_wlmprobs.html