Configurando Propriedades de Transações para Recuperação no Mesmo Nível

A recuperação de mesmo nível para o serviço de transação permite que os servidores de um cluster concluam trabalho pendente para um membro de cluster em falha. Siga as etapas deste tópico para configurar as propriedades de transação que são requeridas para recuperação de mesmo nível de servidores de aplicativos em falha em um cluster.

Antes de Iniciar

Para ativar a recuperação de peer de transação entre servidores, é necessário ter uma configuração comum dos provedores de recursos entre os membros do servidor participantes. Isso significa que o processamento da recuperação no mesmo nível pode ocorrer apenas entre membros do mesmo cluster de servidores. Embora um cluster contenha servidores que estão em versões diferentes do WebSphere Application Server, você deverá ativar e configurar a alta disponibilidade apenas se todos os servidores do cluster estiverem na Versão 6 ou posterior.

Sobre Esta Tarefa

[z/OS]A recuperação no mesmo nível das transações é adicional ao suporte para Reinicialização e Recuperação no Mesmo Nível, que permite reiniciar em um sistema de mesmo nível no sysplex. Para obter informações adicionais sobre como configurar reinicialização e recuperação no mesmo nível, consulte Configurando Reinicialização e Recuperação no Mesmo Nível.

A configuração das propriedades da transação que são requeridas para recuperação de mesmo nível faz parte da tarefa geral para configuração de um cluster para utilizar suporte de alta disponibilidade.

Procedimento

  1. [z/OS]Nas plataformas z/OS, configure oRACF (Resource Access Control Facility) para permitir que os servidores de aplicativos chamem a macro ATRSRV.

    A macro ATRSRV permite que um servidor confirme e restaure transações para outros servidores. Este processo difere do suporte de reinicialização e recuperação no mesmo nível, em que o outro servidor é iniciado em um outro sistema. A macro ATRSRV é fornecida pelo RRS (Resource Recovery Services) do MVS.

    O ID do usuário com o qual a região do controlador do servidor de aplicativos é executada deve ter acesso ALTER para o recurso MVSADMIN.RRS.COMMANDS.gname.sysname na classe FACILITY, em que gname é o grupo de criação de log RRS (geralmente o nome SYSPLEX) e sysname é o nome do sistema. Para permitir o acesso a todos os grupos e sistemas de log, use caracteres curinga no nome do recursos, por exemplo MVSADMIN.RRS.COMMANDS.*.
    Nota: Como a região do controlador é executada como um espaço de endereços autorizado, implicitamente ele possui o acesso ALTER a essa classe de recurso, a menos que a configuração de RACF restrinja explicitamente o acesso. Permitindo explicitamente o acesso a esse recurso, você não depende do estado autorizado da região do controlador.

    Para obter mais informações sobre a macro ATRSRV e sobre como configurar as permissões de RACF apropriadas, consulte o Capítulo 8 de MVS Programming: Resource Recovery, SA22-7616-02.

  2. Configure a definição do diretório do registro de transações de cada servidor no cluster. Você pode configurar o local do diretório de log de transações usando o console administrativo ou comandos. A configuração é armazenada no arquivo de configuração no nível do nó serverindex.xml.

    Cada servidor do cluster deve ser capaz de acessar os diretórios de registro de outros servidores no mesmo cluster. Por essa razão, não deixe essa configuração sem definição. Se você não configurar um diretório, o servidor de aplicativos assume um local padrão no diretório de perfil apropriado, que pode não estar acessível para outros servidores no cluster.

    Cada servidor do cluster também deve ter um diretório de log de transações exclusivo para evitar tentativas por vários servidores de acessar o mesmo arquivo de log. Por exemplo, você poderia utilizar o nome de cada servidor como parte do nome do diretório do log para o servidor.

    [AIX Solaris HP-UX Linux Windows][z/OS]O mecanismo de armazenamento utilizado para hospedar arquivos de log de recuperação (por exemplo, você pode utilizar o IBM® NAS (Network attached storage) e unidades SCSI compartilhadas, mas não compartilhamento de rede simples) e acessar esse mecanismo (por exemplo, através de uma LAN (rede local)) deverá suportar a operação force baseada em arquivo, que é utilizada pelo serviço de log de recuperação para forçar dados para o disco.

    [IBM i]O mecanismo de armazenamento que é utilizado para hospedar arquivos de log de recuperação e o acesso a esse mecanismo (por exemplo, você pode armazenar os logs em outro servidor IBM i utilizando o sistema de arquivos NetClient (QNTC), que fornece acesso a dados em um sistema remoto utilizando o protocolo Server Message Block (SMB)) deve suportar a operação forçar baseado em arquivo que é utilizada pelo serviço de log de recuperação para forçar os dados para o disco.

    Além disso, configure o mecanismo pelo qual os arquivos de registro remotos são acessados para explorar qualquer tolerância a falhas no sistema de arquivos subjacente. Por exemplo, usando o Network File System (NFS) e a montagem física do diretório remoto que contém os arquivos de registro (usando a opção hard -o do comando de montagem NFS), o cliente NFS tentará novamente com uma operação com falha até que o servidor NFS fique disponível novamente.

    Para obter mais informações sobre como configurar diretórios de log de transações, consulte Configurando propriedades de transação para um servidor de aplicativos.

    Nota: Se tiver migrado de uma versão anterior do WebSphere Application Server, esteja ciente de que versões anteriores armazenavam a configuração do log de recuperação no arquivo de configuração no nível do servidor server.xml. Se você executar um script existente que define as configurações originais do log de recuperação, ou migrar os servidores de aplicativos da Versão 5 para uma versão posterior do WebSphere Application Server, a configuração original do diretório de log de transação no arquivo server.xml será atualizada. O console administrativo detecta essa condição e solicita que você salve a configuração quando visualizar o painel de serviço de transação. Essa operação de salvamento salva a configuração alterada no arquivo serverindex.xml e redefine os campos mais antigos para nulo. Altere, assim que possível, seus scripts existentes para ter como destino o arquivo serverindex.xml. Os novos sripts também devem ter como destino o arquivo serverindex.xml.
  3. Ative a função de alta disponibilidade para o cluster, executando as seguintes etapas no painel de configuração do cluster do console administrativo do WebSphere Application Server:
    1. No console administrativo, clique em Servidores > Clusters > Clusters do WebSphere Application Server > cluster_name.
    2. Selecione a opção Ativar Failover da Recuperação do Registro de Transação.
    3. Clique em OK.
    Para obter informações adicionais sobre como ativar a função de alta disponibilidade para um cluster, consulte Configurações do Cluster de Servidores.
  4. Decida qual tipo de recuperação de mesmo nível de transação utilizar referindo-se a Como Escolher entre as Recuperações Automatizada e Manual do Período de Transação.
  5. Conclua uma das seguintes ações, dependendo da configuração necessária.

O que Fazer Depois

Também é necessário configurar o local do log de compensação. Cada servidor deve ter um diretório de log de compensação exclusivo e os logs de compensação devem estar acessíveis, de forma semelhante aos logs de transações.

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