[z/OS]

Configurando a Reinicialização e Recuperação no Mesmo Nível

Para permitir que o produto seja reiniciado em um sistema alternativo, os pré-requisitos a seguir devem estar instalados em todos os sistemas (seu sistema original, assim como quaisquer sistemas destinados para recuperação) antes de reconfigurar as políticas de ARM para ativar a reinicialização e recuperação no mesmo nível.

Antes de Iniciar

Recurso Reprovado Recurso Reprovado: A funcionalidade PRR (Peer Restart and Recovery) tornou-se obsoleta. Para a recuperação de transações, em vez dessa funcionalidade PRR, utilize o suporte integrado de alta disponibilidade para o subcomponente do serviço de transações. Consulte o tópico Suporte a transações no WebSphere Application Server para obter informações adicionais sobre o suporte de alta disponibilidade integrado para o subcomponente de serviço de transações e como configurá-lo para recuperação peer-to-peer de transações sendo processadas em um servidor de aplicativos que falha.depfeat

É necessário certificar-se também que todos os sistemas, nos quais é possível ser necessário executar o reinício, são parte do mesmo grupo de log do RRS.

  • z/OS Versão 1.2 ou superior
  • BCP APAR OA01584
  • RRS APARs OA02556 e OA2556
  • WebSphere Application Server Versão 5 ou superior

A instalação das atualizações de serviço dos pré-requisitos em todos esses sistemas não impedirá seu ambiente atualmente em execução, se você desejar continuar a iniciar novamente no local somente. No entanto, se esse serviço não for instalado, há uma possibilidade do controlador não estar apto a mover de volta. O OTS tentará iniciar novamente no sistema alternativo e falhará. Se houverem URs não resolvidas com o RRS antes disso ocorrer, o controlador não poderá iniciar novamente no sistema inicial até que o RRS seja cancelado no sistema alternativo. Para obter mais informações sobre OTS e RRS, consulte z/OS MVS Programming: Resource Recovery.

Se você não pretende utilizar a reinicialização e recuperação no mesmo nível, não é necessário agir de acordo com esses pré-requisitos funcionais. Seu sistema, em vez disso, utilizará a função iniciar-novamente-no-local.

Os produtos a seguir suportam o RRS. Individualmente, eles também suportam a reinicialização e recuperação no mesmo nível, desde que que os pré-requisitos anteriormente listados sejam todos corretamente instalados:
  • DB2 Versão 7 ou superior
  • IMS Versão 8 ou superior
  • CICS Versão 1.3 ou superior
  • MQSeries Versão 5.2 ou superior

Além dos produtos anteriores, vários JTA XAResource Managers podem ser utilizados para ajudar em uma reinicialização e recuperação no mesmo nível do produto. Consulte a documentação do JTA XAResource Manager para determinar se ele suporta iniciar novamente em um sistema alternativo.

Evitar Problemas Evitar Problemas: Ao configurar a política ARM para um sysplex, certifique-se de que ambos os sistemas possuem o mesmo nível do Servidor de Aplicativos instalado. Por exemplo, não é possível utilizar um servidor de aplicativos que esteja executando WebSphere Application Server Versão 5.1 para executar reinicialização e recuperação no mesmo nível para um servidor de aplicativos que estiver executando WebSphere Application Server Versão 6.0.1.gotcha
Antes de utilizar a reinicialização e recuperação no mesmo nível:
  • É necessário assegurar-se de que o Daemon do serviço de localização e o agente do nó já estão em execução em todos os sistemas que possam ser utilizados para recuperação. Caso contrário, o sistema de recuperação pode tentar recuperar em um sistema que não esteja executando o Daemon do serviço de localização e o agente do nó. Se isso ocorrer, o servidor falhará ao iniciar e a recuperação falhará.

Os clientes notarão um impacto no desempenho, se os sistemas estiverem em execução no limite da capacidade. Em uma tentativa de minimizar o impacto na memória e na CPU no sistema alternativo, o enterprise bean e os contêineres da Web não são reiniciados para servidores executando em modo de reinicialização no mesmo nível. Isso significa que os servidores de aplicativos que estão in no estado de recuperação não poderão aceitar nenhum trabalho de entrada.

Sobre Esta Tarefa

Após a instalação dos pré-requisitos, a inicialização de um servidor em um sistema para o qual ele não foi implicitamente configurado irá colocá-lo no modo de reinicialização e recuperação no mesmo nível. Se você configurou seu log de Parceiro XA para gravar em um HFS não compartilhado ou se estiver utilizando um JTA XA Resource Manager, será necessário executar as etapas a seguir antes de iniciar um servidor:

Procedimento

  1. (Requerido apenas se estiver utilizando um HFS não-compartilhado). Ativar o suporta a HFS não compartilhado. Ao utilizar um HFS não compartilhado, as definições de configuração devem ser replicadas em diferentes sistemas no sysplex. Isso é feito automaticamente pelo gerenciador de implementação e pelo agente do nó. Para ativar esse suporte, cada agente do nó em sua configuração deve ser definido como um nó de recuperação. Essa alteração é feita no Administrative Console:
    1. Na navegação do console administrativo, selecione Administração do sistema > Agentes do nó.
    2. Selecione um agente de nó da lista.
    3. Na seção Propriedades Adicionais, selecione Serviço de Sincronização de Arquivos.
    4. Na seção Propriedades Adicionais, selecione Propriedades Customizadas.
    5. Selecione Novo.
    6. Insira recoveryNode para Nome e true para Valor. O campo Descrição pode permanecer em branco.
    7. Repita as etapas 3-7 para cada agente do nó em sua configuração.
    8. Salve a configuração.
  2. (Requerido apenas se estiver utilizando JTA XAResource Managers). Disponibilizar os logs e classes apropriados no sistema alternativo Se você planejar utilizar a reinicialização e recuperação no mesmo nível, e seus aplicativos acessarem JTA XAResource Managers, assegure-se de que os logs e classes apropriados esteja disponíveis no sistema alternativo.
    1. Aponte a variável do produto TRANLOG_ROOT para um HFS compartilhado. A variável TRANLOG_ROOT deve apontar para um HFS compartilhado, no qual todos os sistemas na célula podem gravar. O log parceiro do XA é armazenado aqui e o sistema alternativo deve estar apto a ler e atualizar esse log.
      1. No console administrativo, clique em Servidores > Tipos de Servidor > WebSphere Application Servers > server_name.
      2. Sob Serviços do Contêiner, clique em Serviço de Transações.
      3. Insira o diretório do HFS compartilhado no campo de Diretório de log de transações.
    2. Armazene o driver (isto é, JDBC Driver, JMS Provider ou JCA Resource Adapter, etc.) para cada JTA XAResource Manager em um HFS que seja legível por todos os sistemas na célula. Por exemplo, se seu conector for um driver JDBC para um banco de dados, é provável que o driver seja armazenado em um HFS de somente leitura, acessível a todos os sistemas no sysplex. Isso permite que o sistema alternativo leia o caminho de classe salvo para o recurso e reconstrua-o ao reiniciar.

      Se o conector utilizado para acessar um JTA XAResource Manager não for armazenado em um HFS legível a todos os sistemas que possam ser utilizados para recuperação, ao iniciar novamente o servidor de aplicativos em um sistema alternativo, aparecerá que não há trabalho de recuperação de XA a ser feito ou será impossível carregar as classes necessárias para comunicar-se com o JTA XAResource Manager

  3. Resolver unidades InDoubt.

    Durante uma recuperação, haverá instâncias ao requerer a intervenção manual para resolver as unidades InDoubt. Será necessário utilizar os painéis do RRS para essa intervenção manual.


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



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