[AIX Solaris HP-UX Linux Windows][IBM i]

Configurando aspectos de transação de servidores para otimizar a disponibilidade

É possível configurar aspectos relacionados a transações de servidores de aplicativos para otimizar a disponibilidade desses servidores. Isso ajuda as transações a serem concluídas ou recuperadas mais rapidamente. Após alterar propriedades relacionadas a transações de um servidor de aplicativos, você deve reiniciar o servidor.

Sobre Esta Tarefa

Para configurar os aspectos relacionados às transações dos servidores de aplicativos para uma melhor disponibilidade, execute as etapas a seguir:

Procedimento

  1. Armazene os arquivos de log de transações em um disco rápido em um sistema de arquivos de alta disponibilidade, como um dispositivo RAID. O log de transações pode precisar ser acessado por cada transação global e ser usado para recuperação de transações após um travamento. Portanto, o disco no qual os arquivos de log estão sendo gravados deve estar em um sistema de arquivos de alta disponibilidade, como um dispositivo RAID.

    O desempenho do disco também afeta diretamente o desempenho das transações. Em geral, uma transação global faz duas gravações em disco, uma após a fase de preparação quando o resultado da transação é conhecido (essas informações são forçadas no disco) e mais uma gravação em disco na conclusão da transação. Portanto, os logs da transação devem ser colocados nos discos mais rápidos disponíveis.

    Para que o failover automático da recuperação de log de transação funcione em uma topologia de cluster do WebSphere Application Server, os dispositivos montados da rede devem ser usados para os logs de transação, em um disco rápido e em um sistema de arquivos altamente disponível, como um dispositivo RAID, que cada membro de cluster pode acessar.

  2. Espelhe os arquivos de log de transações, utilizando espelhamento de disco de hardware ou discos com duas portas. Se os arquivos de log tiverem sido espelhados ou puderem ser recuperados, estes arquivos de log poderão ser usados ao reiniciar um servidor com falha, poderão ser movidos para outra máquina e outro servidor poderá ser iniciado para fazer a recuperação.

    É possível configurar espelho de disco de hardware ou discos de duas portas utilizando o console administrativo para especificar o diretório de sistema de arquivos apropriado para os logs de transações.

  3. Especifique a localização otimizada do diretório de logs de transações para servidores de aplicativos.

    Por padrão, um servidor de aplicativos coloca arquivos de log de transação em um subdiretório do WebSphere Application Server instalado, no qual o nome do subdiretório é igual ao nome do servidor.

    [AIX Solaris HP-UX Linux Windows]Por exemplo, o diretório padrão para um servidor de aplicativos denominado server1 é

    /IBM/WebSphere/AppServer/profiles/profile_name/tranlog/server1

    [IBM i]Por exemplo, o diretório padrão para um servidor de aplicativos denominado server1 é

    /QIBM/UserData/WebSphere/AppServer/was_version/ND/profiles/profile_name/tranlog/server1

    em que was_version indica o número da versão para essa instalação do IBM® WebSphere Application Server. Por exemplo, V6 para WebSphere Application Server Versão 6.
    [z/OS]Por exemplo, o diretório padrão para um servidor de aplicativos denominado server1 é

    /IBM/WebSphere/was_version/AppServer/profiles/profile_name/tranlog/server1

    em que was_version indica a versão, release e número de modificação para essa instalação doIBM WebSphere Application Server. Por exemplo, V6R0M2 para WebSphere Application Server Versão 6.0.2.

    É possível definir uma localização específica para o diretório do log de transações para um servidor de aplicativos, definindo a propriedade Diretório do Log de Transações para o servidor. Se o diretório para os logs de transações não tiver sido criado na inicialização do servidor de aplicativos, a estrutura de diretório é criada para você.

    Nota: Se você alterar o diretório do log de transações, aplique a alteração e reinicie o servidor de aplicativos assim que possível, para minimizar o risco de ocorrem problemas antes de o servidor de aplicativos ser reiniciado. Por exemplo, se um problema causar falha do servidor (com transações em andamento), o servidor será iniciado na próxima vez com o novo diretório de log e não poderá resolver automaticamente transações em andamento que foram registradas no antigo diretório de log.
  4. Nunca permita que mais de um servidor de aplicativos utilize simultaneamente o mesmo conjunto de arquivos de log. Como os logs de transações registram o estado das transações globais em um servidor, se os logs forem perdidos ou corrompidos, então, as transações que se encontram no estado preparado antes da falha podem deixar recursos em um estado duvidoso e impedir outras atualizações ou acesso aos recursos por outros usuários ou servidores. Estas transações podem precisar ser resolvidas manualmente, executando commit ou retrocedendo as transações nos gerenciadores de recursos afetados. O servidor em falha poderá ser iniciado do zero, o que cria novos logs de transações vazios.

    Se os arquivos de log tiverem sido espelhados ou puderem ser recuperados, estes arquivos de log poderão ser usados ao reiniciar um servidor com falha, ou poderão ser movidos para outra máquina e outro servidor poderá ser iniciado para fazer a recuperação, conforme descrito nas tarefas relacionadas.

    Nunca permita que mais de um servidor de aplicativos utilize simultaneamente o mesmo conjunto de arquivos de log, porque cada servidor destruirá as informações registradas pelo outro, resultando em arquivos de log corrompidos que não podem ser utilizados para finalidades de recuperações futuras.

  5. Configure os servidores de aplicativos para sempre utilizar o mesmo endereço de porta listening a cada inicialização. Se estiver executando transações distribuídas entre vários servidores de aplicativos, as referências do objeto remoto salvas no log de transações precisarão ser redirecionadas para o servidor de origem na recuperação.

    No WebSphere Application Server, Network Deployment, os agentes do nós automaticamente redirecionam essas referências do objeto remoto para os servidores de aplicativos apropriados na recuperação. Porém, se a transação distribuída estiver entre servidores de aplicativos que não estão no WebSphere Application Server, Network Deployment, você deve tratar do redirecionamento de referências do objeto remoto para que a recuperação da transação possa ser concluída. Por exemplo, você deve fazer isso se um servidor de aplicativos é implementado no WebSphere Application Server, Network Deployment e executa transações distribuídas com servidores EJB ou Corba não WebSphere.

    Em particular, a ação de reinicialização padrão de um servidor de aplicativos que não está no Application Server WebSphere Application Server, Network Deployment é usar um endereço de porta de atendimento diferente para a porta quando o servidor encerra. Isso impede que a recuperação da transação obtenha êxito. Para superar isso, é necessário sempre configurar servidores de aplicativos para sempre usarem o mesmo endereço de porta de atendimento em cada inicialização (consulte a propriedade ORB com.ibm.CORBA.ListenerPort no tópico sobre propriedades customizadas do Object Request Broker). Pode ser necessário fazer alterações na configuração semelhantes às alterações na configuração em outros servidores de aplicativos envolvidos em transações, para que seja possível acessar esses servidores durante a recuperação.


Í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_optsrv
Nome do arquivo: tjta_optsrv.html