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.
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]](../images/dist.gif)
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.
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.