Roteamento de Carga de Trabalho de Recurso

Use esse tópico para aprender sobre como ativar o roteamento de recurso no seu ambiente.

[z/OS]
Em um sistema z/OS, há duas maneiras pelas quais o roteamento de recurso pode ser feito:
  • Configurar um recurso alternativo.
  • Configurar uma notificação de ação.
[AIX Solaris HP-UX Linux Windows]

Em sistemas distribuídos, é possível ativar o roteamento de recurso apenas ao configurar um recurso alternativo.

Configurar um Recurso Alternativo.

Uma origem de dados e um connection factory podem efetuar failover e failback automaticamente quando um valor de limite de falha especificado ou padrão é atingido. Quando o failover ocorre, o aplicativo alterna do uso do recurso principal para o uso de recurso alternativo. O failback ocorre quando o aplicativo alterna novamente do recurso alternativo para o uso do recurso principal.

O recurso alternativo é criado da mesma forma com que outros connection factories ou origens de dados são criadas. A configuração de recurso alternativo deve espelhar a configuração de recurso principal. Por exemplo, a configuração de segurança do recurso alternativo e a configuração do recurso primário, com relação ao aplicativo e aos recursos, devem espelhar uma a outra para que o aplicativo e o banco de dados possam acessar os dados necessários. Depois que o recurso alternativo é criado, é possível alterar os valores de banco de dados que são necessários para a configuração de backend do recurso alternativo. Se o recurso alternativo não for compatível, provavelmente o failover falhará. Se os recursos não forem compatíveis, os seguintes erros poderão ocorrer: tabelas ou campos inexistentes, um registro esperado inexistente e ocorrência de erros de recurso inesperados. Como uma opção de teste, antes que o recurso alternativo seja configurado para a origem de dados principal, é possível testar o aplicativo ao alterar o nome JNDI no aplicativo a partir do nome JNDI principal para o nome JNDI alternativo.

Quando o recurso principal é usado, o recurso alternativo é pausado. Antes que o recurso alternativo seja pausado, o recurso alternativo pode estar disponível antes que o principal seja usado. Usar o alternativo antes que ele seja pausado não é recomendado, a menos que haja uma razão especial para o alternativo precisar ser acessado antes do recurso principal. Um exemplo de uma razão especial é testar a compatibilidade do aplicativo.

Um recurso alternativo não pode ser usado como principal. Quando usar o recurso de failover com adaptadores de recurso não relacionais que possuem backends que também suportam failover, você deve verificar se o failover não está configurado para esses backends. O failover funciona com adaptadores de recursos não relacionais que possuem um objeto ManagedConnection que implementa um método testConnection. O método testConnection é usado para efetuar ping dos recursos alternativo e principal para obter sucesso antes de restabelecer uma conexão com o recurso atualmente disponível. Se o adaptador de recursos não implementar um método testConnection ou o testConnection emitir um erro javax.resource.NotSupportedException, o recurso de failover será desativado.

Para os adaptadores de recursos que não atenderem ao requisito para o testConnection, um failover parcial pode ser usado. Você deve efetuar failback manualmente usando o Mbeans para o recurso principal quando este recurso estiver disponível. Um failover parcial pode ser ativado ao configurar a propriedade enablePartialResourceAdapterFailoverSupport para true.

É recomendado testar a adequação desse recurso com seu ambiente do sistema e os recursos antes de ativar o suporte ao failover.

[z/OS]Para obter mais informações sobre como usar os adaptadores locais otimizados, consulte o tópico sobre ativar o suporte de alta disponibilidade do adaptador local otimizado.

Operações de Mbean

failOverToAlternateResource

Valores: nenhum, suspender ou automatizado; o padrão é suspender sem o failback automatizado.

Descrição: O failover manual para o recurso alternativo. Essa ação é emitida no recurso principal.

failBackToPrimaryResource

Valores: nenhum, suspender ou automatizado; o padrão é automatizado com failover automatizado.

Descrição: Failback manual para o recurso principal. Essa ação é emitida no recurso principal.

Propriedades do Atributo do Mbean

currentActivePool

Valores: Um valor de sequência retornado contendo um nome JNDI.

Descrição: Um nome JNDI primário ou alternativo é retornado, dependendo de qual está sendo usado atualmente.

populateAlternateResource

Valores: booleano

Descrição: False - Desativa o recurso alternativo de preenchimento. True - Ativa o recurso alternativo de preenchimento. Essa ação é emitida no recurso principal.

resourceFailOver

Valores: booleano

Descrição: False - Desativa o failover de recurso. True - Ativa o failover de recurso. Essa ação é emitida no recurso principal.

resourceFailBack

Valores: booleano

Descrição: False - Desativa o failback de recurso. True - Ativa o failback de recurso. Essa ação é emitida no recurso principal.

[z/OS]

Roteamento de Recurso Manual com o Comando modify para Recursos Configurados com um Recurso Alternativo

Na plataforma z/OS, é possível usar alguma funcionalidade do Mbean usando o comando modify. O comando modify é usado para desativar manualmente o suporte de failover de recurso, ativar o suporte de failover de recurso, efetuar failover em um recurso alternativo configurado e efetuar failback no recurso principal configurado. Consulte o tópico Comando Modify, para obter mais detalhes sobre como emitir o comando e aprender sobre os parâmetros de failover.

[z/OS]

Configurar uma Notificação de Ação.

Quando a notificação de ação é configurada para um recurso específico e solicita que o início desse recurso falhe além de um valor do limite especificado ou padrão, o tempo de execução do WebSphere Application Server para z/OS recebe a notificação para executar essa ação específica. A ação é um valor configurável. Os códigos de ação são definidos no conteúdo de propriedade failureNotificationActionCode localizado na seção "Propriedades customizadas" posteriormente neste tópico.

As várias ações de notificação de falha são designadas para ajudar com os ambientes de alta disponibilidade para que, quando uma falha de recurso ocorrer, o trabalho possa ser roteado para outros servidores em um cluster. Os seguintes códigos de ação podem ser usados:
  • Código de Ação 1

    Esse código de ação emite as mensagens BBOJ0130I e BBOJ0131I para o fluxo de criação de logs de cópia impressa no controlador. A mensagem BBOJ0130I é emitida quando o recurso está indisponível, e a BBOJ0131I é emitida quando o recurso é reiniciado e está disponível. O WebSphere Application Server não executa nenhuma ação automatizada adicional.

    Um código de ação 1 é designado para fornecer notificação para os administradores do WebSphere para que as ações de mitigação manuais ou automatizadas possam ser configuradas fora do servidor de aplicativos. O BBOJ0130I contém as seguintes informações:
    • O nome JNDI que identifica o recurso que falhou.
    • O nome do servidor onde o recurso que falhou foi usado.
    • A ação que foi executada. Por exemplo: NONE, PAUSING LISTENERS
    O BBOJ0131I contém as seguintes informações:
    • O nome JNDI que identifica o recurso que foi reiniciado.
    • O nome do servidor no qual o recurso foi reiniciado.
    • A ação que foi executada. Por exemplo: NONE, RESUMING LISTENERS
    • A razão pela qual a ação foi executada: 1: Notificação de disponibilidade da região servidora normal. 2: Disponibilidade de recurso desconhecida.
  • Código de Ação 2

    Este código de ação pausa e continua os listeners no servidor em que o recurso reside para o qual esta ação foi configurada. Os listeners do servidor são pausados quando o recurso estiver realmente indisponível. Os listeners do servidor são continuados quando o recurso estiver realmente disponível. Quando combinado com um roteador frontend que suporta alta disponibilidade, como um servidor proxy ou um roteador on demand, o trabalho desse servidor é roteado para outros servidores no cluster. Como parte desta ação, duas mensagens informativas são emitidas para cópia impressa na regição do controlador. A mensagem BBOJ0130I é emitida quando o recurso está indisponível, e a BBOJ0131I é emitida quando o recurso é reiniciado e está disponível.

  • Código de Ação 3

    Esse código de ação para e inicia todos os aplicativos com módulos instalados localmente que usam esse recurso para o qual essa ação foi configurada. Os aplicativos são parados quando o recurso que esses aplicativos usam estiver realmente indisponível. Os aplicativos são iniciados quando o recurso que esses aplicativos usam estiver realmente disponível.

    Como parte desta ação, duas mensagens informativas são emitidas para cópia impressa na regição do controlador. A mensagem BBOJ0130I é emitida quando o recurso está indisponível, e a BBOJ0131I é emitida quando o recurso é reiniciado e está disponível.
    Atenção: Os únicos aplicativos para os quais uma referência de recurso é definida são parados apenas no servidor onde ocorreu a falha de recurso. Portanto, se o aplicativo estiver instalado em um cluster, o aplicativo permanecerá nos outros servidores no cluster.

    As mensagens BBOJ0130I e BBOJ0131I podem conter as seguintes informações:

    BBOJ0130I:
    • O nome JNDI que identifica o recurso que falhou.
    • O nome do servidor onde o recurso que falhou foi usado.
    • A ação que foi executada, por exemplo: NONE, "PAUSING LISTENERS", "STOPPING APPLICATIONS THAT USE THIS RESOURCE"
    BBOJ0131I:
    • O nome JNDI que identifica o recurso que foi reiniciado.
    • O nome do servidor no qual o recurso foi reiniciado.
    • A ação que foi executada, por exemplo: NONE, "RESUMING LISTENERS", "STARTING APPLICATIONS THAT USE THIS RESOURCE"
    • A razão pela qual a ação foi executada: 1: Notificação de disponibilidade da região servidora normal. 2: Disponibilidade de recurso desconhecido.

Propriedades Personalizadas

Todas as propriedades para esse recurso devem ser criadas como novas propriedades customizadas no conjunto de conexões para uma determinada origem de dados ou connection factory. No console administrativo, navegue para a origem de dados ou connection factory para o qual a notificação deve ser ativada. Clique no link Propriedades do Conjunto de Conexões. No painel Propriedades do Conjunto, clique no link Propriedades customizadas do conjunto de conexões. O painel Propriedades Customizadas para o conjunto de conexões de recursos é exibido. Clique em Novo para criar as propriedades customizadas descritas como a seguir:

[z/OS]failureNotificationActionCode
[z/OS]

Valores: {1,2,3}

Descrição: A propriedade failureNotificationActionCode é usada para ativar o recurso de notificação. Se essa propriedade não estiver configurada para um dos seguintes valores de número inteiro válidos especificado o recurso de notificação será desativado:
  • 1 = Uma mensagem BBOJ0130I é gerada em cópia impressa indicando que esse recurso está indisponível. Quando o recurso estiver disponível, uma mensagem BBOJ0131I será gerada em cópia impressa indicando que o recurso está novamente disponível.
  • 2 = Um comando de pausa de listeners é emitido para o servidor, evitando que o servidor receba novo trabalho recebido. A mensagem BBOJ0130I também é emitida para descrever a ação executada. Quando o recurso estiver disponível, um comando de continuação de listeners é emitido para permitir que o servidor receba novamente o trabalho recebido. A mensagem BBOJ0131I é emitida para descrever a ação executada.
  • 3 = Todos os aplicativos com módulos instalados localmente que usam esse recurso são parados nesse servidor. A mensagem BBOJ0130I também é emitida para descrever a ação executada. Quando o recurso estiver disponível, esses aplicativos são iniciados. A mensagem BBOJ0131I também é emitida para descrever a ação executada.
failureThreshold

Valores: Deve ser um número inteiro e > 0.

Descrição: A propriedade failureThreshold é lida apenas se a propriedade failureNotificationActionCode ou alternateResourceJNDIName estiver configurada para um valor válido. Se a propriedade failureThreshold não estiver configurada ou estiver configurada para um número inválido, o valor padrão 5 será usado. O valor de número inteiro especificado para failureThreshold é o número de exceções de recurso consecutivas que devem ocorrer para um determinado recurso antes que a notificação seja enviada ou o failover ocorra.

A seguir há um exemplo de como esse valor funciona: Se a propriedades failureThreshold for configurada para 5 para a origem de dados B, a origem de dados B deverá obter cinco exceções de recurso consecutivas enquanto tenta estabelecer conexões, sem nenhuma tentativa bem-sucedida entre essas falhas, antes que a notificação seja enviada ou o recurso possa efetuar failover. Uma tentativa de enviar a notificação ou failover é feita após ocorrerem cinco exceções de recurso consecutivas. No entanto, em um ambiente multiencadeado, após o valor do limite de falha ser atingido, a sincronização da notificação ou failover pode ocorrer após exceções do recurso adicional.
Atenção: Os contadores de exceções de recurso não são compartilhados entre os recursos. As exceções de recursos devem ser consecutivas para atingir o limite de falha.
alternateResourceJNDIName

Valores: Valor de sequência contendo um nome JNDI direto.

Descrição: Um recurso de connection factory ou de origem de dados alternativo deve ser tal como o recurso principal. Forneça o nome o JNDI do recurso alternativo para ativar o recurso de failover.

Propriedades de Failover Avançadas

resourceAvailabilityTestRetryInterval

Valores: valor int, o padrão é 10.

Descrição: O intervalo de conexão de teste por padrão é 10 segundos. A cada 10 segundos, o encadeamento de conexão de teste tenta testar o recurso principal. Dependendo dos recursos do sistema, esse valor pode ser alterado de 1 - MAXINIT segundos.

enablePartialResourceAdapterFailoverSupport

Valores: booleano, o padrão é 10.

Descrição: Se esse valor for true, ocorre failover para o recurso alternativo, e o failback para o principal é manual. Essa propriedade poderá ser configurada se o adaptador de recursos que estiver sendo usado não atender aos requisitos para failover de conexão, por exemplo, se não possuir testConnection implementado ou emitir uma exceção não suportada.

disableResourceFailOver

Valores: booleano, o padrão é 10.

Descrição: Se esse valor for true, não ocorre failover automático.

disableResourceFailBack

Valores: booleano, o padrão é 10.

Descrição: Se esse valor for true, não ocorre failback automático.

populateAlternateResource

Valores: booleano, o padrão é 10.

Descrição: Se esse valor for true, o recurso alternativo é preenchido com conexões até o máximo de conexões. Cada tentativa é feita para manter o recurso alternativo no máximo de conexões. Se o banco de dados estiver inativo para o recurso alternativo, as conexões antigas são removidas e o encadeamento de preenchimento preenche o recurso alternativo quando o banco de dados estiver disponível. É possível ativar e desativar dinamicamente o preenchimento do recurso alternativo usando as operações Mbean, disablePopulateAlternateResource e enablePopulateAlternateResource.
Atenção: Pode-se observar ganhos de desempenho durante um failover com o preenchimento do recurso alternativo ativado, porém, é alto o custo para manter o recurso alternativo preenchido. A maior parte do custo está em manter duas vezes o número de conexões normalmente necessárias para uma origem de dados. Como as conexões são objetos grandes, manter as conexões usa recurso de memória adicional no servidor e recurso extra no banco de dados.

Ícone que indica o tipo de tópico Tópico de Conceito



Í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=cdat_dsfailover
Nome do arquivo: cdat_dsfailover.html