Alta Disponibilidade Transacional

A alta disponibilidade do serviço de transações permite que qualquer servidor de um cluster recupere o trabalho transacional para qualquer outro servidor no mesmo cluster. Esse recurso faz parte da estratégia (HA) de alta disponibilidade do WebSphere Application Server.

[z/OS]Esse recurso existe, além do suporte para reinicialização e recuperação no mesmo nível, o que permite reiniciar em um sistema de mesmo nível no sysplex.

Como parte vital de fornecimento de recuperação para transações, o serviço de transações registra informações sobre o trabalho transacional ativo no registro de recuperação de transações. O registro de recuperação de transações armazena as informações de forma persistente, o que significa que qualquer trabalho transacional em andamento na hora da falha de um servidor pode ser resolvido quando o servidor for reiniciado. Essa atividade é conhecida como processamento de recuperação da transação. Além de concluir transações pendentes, esse processamento também assegura que quaisquer bloqueios mantidos nos gerenciadores de recursos associados sejam liberados.

Processamento de Recuperação no Mesmo Nível

O processo de recuperação padrão que é executado quando um servidor de aplicativos é reiniciado é para o servidor recuperar e processar as informações de transação do log, recuperar trabalho transacional e concluir transações indeterminadas. A conclusão do trabalho transacional (e, assim, a liberação de quaisquer bloqueios de banco de dados mantidos pelas transações) ocorre após o servidor reiniciar e processar seus registros de transação com êxito. Se o servidor realizar uma recuperação lenta ou exigir intervenção manual, o trabalho transacional não pode ser concluído e o acesso aos bancos de dados associados é interrompido.

Para minimizar tal interrupção do trabalho transacional e dos bancos de dados associados, o WebSphere Application Server fornece uma estratégia de alta disponibilidade conhecida como recuperação peer-to-peer de transação.

A recuperação de período é fornecida em um cluster de servidores. Um servidor no mesmo nível (outro membro do cluster) pode processar os registros de recuperação de um servidor com defeito enquanto o ponto contínua a gerenciar sua própria carga de trabalho transacional. Não é necessário aguardar até que o servidor com defeito reinicie ou inicie um novo servidor de aplicativos especificamente para recuperar o servidor com defeito.

Figura 1. Recuperação de Mesmo Nível
Recuperação de ponto em um cluster de servidores, mostrando o servidor 1 antes e após o início do processamento de recuperação do servidor 2 e do servidor 3 com defeito.

O processo de recuperação de ponto é o equivalente lógico de reiniciar o servidor com defeito, mas não constitui um reinício completo do servidor com defeito dentro do servidor de ponto a ponto. O processo de recuperação da transação fornece uma oportunidade para concluir um trabalho pendente; não pode iniciar um novo trabalho além do processamento de recuperação. Nenhum processamento de redirecionamento é possível para o servidor em falha.

A recuperação de ponto envia os requisitos de alta disponibilidade para longe de servidores individuais, na direção do cluster de servidores. Após tais falhas, o sistema de gerenciamento do cluster despacha novo trabalho para os demais servidores; a única diferença é a eliminação em potencial no rendimento do sistema geral. Se um servidor falhar, é necessário apenas concluir o trabalho que estava ativo no servidor em falha e redirecionar os pedidos para um servidor alternativo.

Por padrão, a recuperação de mesmo nível é desativada até você ativar o failover da recuperação do registro de transações na configuração do cluster e reiniciar os membros do cluster. Depois de ativar a recuperação de log de transações, o WebSphere Application Server suporta dois estilos de inicialização de recuperação peer-to-peer de transação: automatizada e manual. Você determina qual estilo é mais adequado, com base na sua implementação, e especifica esse estilo configurando a política de alta disponibilidade adequada. Essa política de alta disponibilidade é referida em outras partes destes tópicos como a política para serviço de transação.
Recuperação de Mesmo Nível Automatizada
Esse estilo é o padrão para a iniciação de recuperação de mesmo nível. Se um servidor de aplicativos falhar, o WebSphere Application Server automaticamente seleciona um servidor para passar pelo processamento de recuperação peer-to-peer em seu nome, e transmite a recuperação de volta ao servidor que falhou quando ele reiniciar. Para usar esse modelo, ative a recuperação do registro de transação e configure o local do registro de recuperação para cada membro do cluster.
Recuperação de Mesmo Nível Manual
Esse estilo de recuperação de mesmo nível deve ser configurado explicitamente. Se um servidor de aplicativos falhar, você utiliza o console administrativo para selecionar um servidor para executar o processamento de recuperação em seu nome.

Em um ambiente HA, você deve configurar os logs de compensação assim como os logs de transação. Para casa servidor no cluster, use as configurações do serviço de compensação para configurar um local de log de compensação exclusivo, e certifique-se de que todos os membros do cluster podem acessar esses logs de compensação.

Exemplo de Recuperação de Ponto

Os diagramas a seguir ilustram o processo de recuperação de mesmo nível que ocorre se um único servidor falhar. A Figura 2 mostra três servidores estáveis executando em um cluster do WebSphere Application Server. A carga de trabalho é equilibrada entre esses servidores, o que resulta em bloqueios mantidos pelo banco de dados de backend em nome de cada servidor.

Figura 2. O Cluster de Servidores Ativo e em Execução, Antes da Falha do Servidor
Esta figura descreve o cluster de servidor anterior à falha do servidor.

A Figura 3 mostra o estado do sistema após o servidor 1 falhar sem limpar os bloqueios do banco de dados. Os servidores 2 e 3 podem executar suas transações existentes para a conclusão e liberação de bloqueios existentes no banco de dados de backend, mas acesso adicional pode ser obstruído devido aos bloqueios ainda mantidos em nome do servidor 1. Na prática, algum nível de acesso pelos servidores 2 e 3 ainda é possível, assumindo granularidade de bloqueio configurada apropriadamente, mas para este exemplo, suponhamos que os servidores 2 e 3 tentem acessar os registros bloqueados e tornem-se bloqueados.

Figura 3. O servidor 1 falha. Como resultado, os servidores 2 e 3 são bloqueados.
Esta figura mostra os servidores 2 e 3 se tornando bloqueados como resultado da falha do servidor 1.

A Figura 4 mostra um processo de recuperação peer-to-peer para o servidor 1 que é executado dentro do servidor 3. A parte de serviço da transação do processo de recuperação recupera as informações que são armazenadas pelo servidor 1 e usa essas informações para concluir qualquer transação indeterminada. Nessa figura, o processo de recuperação de mesmo nível é parcialmente concluído, já que alguns bloqueios ainda são mantidos pelo banco de dados em nome do servidor 1.

Figura 4. Processo de Recuperação de Mesmo Nível Iniciado no Servidor 3
Esta figura mostra o processo de recuperação peer-to-peer no servidor 3.

A Figura 5 mostra o estado do cluster de servidores quando o processo de recuperação de mesmo nível for concluído. O sistema está em um estado estável com somente dois servidores, entre os quais a carga de trabalho é equilibrada. O servidor 1 pode ser reiniciado e não terá nenhum processamento de recuperação próprio para executar.

Figura 5. Cluster de servidores estável novamente com somente dois servidores: servidor 2 e servidor 3.
Esta figura mostra a estabilidade do cluster de servidor dos servidores 2 e 3.

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