Tempo de troca é a quantia de tempo de atraso de E/S em segundos que o PowerHA SystemMirror causa ao executar uma operação HyperSwap em um grupo de espelhos. O valor de tempo limite de troca é específico para cada grupo de espelhos em um cluster.
Há diferentes valores de tempo limite de troca para HyperSwap planejado e HyperSwap não planejado.
O valor de tempo limite de troca para um HyperSwap planejado é 120 segundos e não pode ser mudado.
O valor de tempo limite de troca para um HyperSwap não planejado é de 0 a 180 segundos.
Para determinar o valor de tempo limite de troca para um HyperSwap não planejado, considere os fatores a seguir sobre seu ambiente:
1. Número de nós em que o aplicativo é hospedado. Quanto maior o número de nós, mais informações estão sendo compartilhadas.
2. Latência de rede e uso de rede do aplicativo.
3. Número de discos que são usados pelo aplicativo.
4. Requisitos de tempo de resposta de E/S para o aplicativo.
HyperSwap for PowerHA SystemMirror planejado
Um HyperSwap planejado ocorre ao iniciar um HyperSwap do subsistema de armazenamento primário para o subsistema de armazenamento auxiliar.
Durante um HyperSwap planejado, a atividade de E/S para um aplicativo para após a coordenação em todo o host no cluster. A E/S do aplicativo é alternada para o subsistema de armazenamento auxiliar e a atividade de E/S do aplicativo continua a funcionar normalmente.
Um HyperSwap planejado é ideal ao executar a manutenção no subsistema de armazenamento primário ou ao migrar de um subsistema de armazenamento antigo para um novo subsistema de armazenamento.
A figura a seguir mostra uma configuração de cluster usando o PowerHA SystemMirror Enterprise Edition for AIX que possui as características a seguir:
v Dois sites chamados Site A e Site B.
v Dois nós para cada site para um total de quatro nós.
v Um aplicativo simultâneo, por exemplo, um aplicativo DB2 que está ativo no Nó 1 e Nó 2.
v Os discos de aplicativo são replicados usando o metroespelhamento do IBM DS8800.
v Todos os quatro nós podem acessar ambas as instâncias dos discos de aplicativo que estão sendo replicados.
A figura a seguir mostra as mudanças em seu ambiente quando uma falha ocorre e seus sites estão configurados para um HyperSwap planejado. O sistema de armazenamento primário no Site A é mudado para o sistema de armazenamento auxiliar porque o aplicativo que está em execução no Nó 1 e Nó 2 pode acessar o sistema de armazenamento no Site B conforme mostrado na figura a seguir. Portanto, o aplicativo que está em execução no Site A agora armazena dados no sistema de armazenamento primário no Site B.
HyperSwap for PowerHA SystemMirror não planejado
Um HyperSwap não planejado ocorre quando um sistema de armazenamento primário falha e o sistema operacional detecta e reage executando um failover. Durante o failover, a E/S do aplicativo no sistema de armazenamento primário é redirecionada transparentemente para um sistema de armazenamento auxiliar e a E/S do aplicativo continua a ser executada.
Durante o processo do HyperSwap, quando os aplicativos estão sendo redirecionados para um sistema de armazenamento auxiliar, a E/S do aplicativo é temporariamente suspensa.
Pulsações
IBM IBM
Sistema de armazenamento
primário
Sistema de armazenamento
auxiliar
ppprc508-2
Site A Site B Site A Site B
Aplicativo
HyperSwap planejado antes HyperSwap planejado após
Nó 1 Nó 2 Nó 3 Nó 4
IBM IBM
Sistema de armazenamento
primário Sistema de
armazenamento auxiliar Aplicativo
Nó 1 Nó 2 Nó 3 Nó 4
Pulsações
Replicação Replicação
Figura 2. Configuração de HyperSwap planejado
Se um HyperSwap não planejado não conclui com êxito, a E/S do aplicativo falha e um evento de fallover do grupo de recursos inicia com base na política de site. Não é possível definir um evento de fallover em uma política de site para grupos de consistências simultâneos.
Há vários cenários em que um HyperSwap não planejado pode ocorrer.
Cenário: Configuração de HyperSwap não planejado para falha de acesso ao nó:
Neste cenário, um nó perde o acesso ao sistema de armazenamento primário e redireciona a E/S do aplicativo para um sistema de armazenamento auxiliar.
A figura a seguir mostra uma configuração de cluster no ambiente do PowerHA SystemMirror Enterprise Edition for AIX com as características a seguir:
v Dois sites chamados Site A e Site B.
v Dois nós para cada site, que equivale a um total de quatro nós. O Nó 1 e Nó 2 possuem acesso a cada sistema de armazenamento no Site A e Site B.
v Um aplicativo simultâneo, por exemplo, um aplicativo DB2 que está ativo no Nó 1 e Nó 2.
v Os discos de aplicativo que são replicados usando o metroespelhamento do IBM DS8800.
Na figura a seguir, o Nó 1 e Nó 2 perdem acesso ao sistema de armazenamento primário no Site A e um HyperSwap não planejado ocorre. Para corrigir esse problema, o PowerHA SystemMirror valida se os nós que hospedam o aplicativo (Nó 1 e Nó 2) podem acessar o sistema de armazenamento auxiliar no Site B.
A função HyperSwap redireciona automaticamente a E/S do aplicativo do Nó 1 e Nó 2 para o sistema de armazenamento no Site B. O sistema de armazenamento no Site B torna-se o sistema de armazenamento primário.
Cenário: Configuração de HyperSwap não planejado para falha de partição de site:
Neste cenário, a conexão de pulsação entre dois sites falha. A replicação entre ambos os sites não ocorre até que a conexão de pulsação seja corrigida e esteja funcionando novamente.
A figura a seguir é para uma configuração de cluster no ambiente do PowerHA SystemMirror Enterprise Edition for AIX com as características a seguir:
v Dois sites chamados Site A e Site B.
v Dois nós para cada site para um total de quatro nós. Todos os nós possuem acesso a cada sistema de armazenamento no Site A e Site B.
v Um aplicativo simultâneo, por exemplo, um aplicativo DB2 que está ativo no Nó 1 e Nó 2.
v Os discos de aplicativo são replicados usando o metroespelhamento do IBM DS8800.
A figura a seguir descreve o efeito de um failover automatizado para aplicativos em uma partição de site.
Os nós para o cluster neste cenário não podem se comunicar um com o outro.
O Nó 1 e Nó 2 podem se comunicar um com o outro, mas não podem se comunicar com o Nó 3 e Nó 4.
Portanto, o Nó 1 e Nó 2 consideram o Nó 3 e Nó 4 como off-line (e vice-versa). O aplicativo em execução no Nó 1 e Nó 2 é configurado para failover automatizado e os nós em cada Site A e Site B tentam colocar o aplicativo on-line. O aplicativo está agora executando independentemente em ambos os sites e pode causar problemas complexos, como distorção de dados entre os dois sites.
Pulsações
IBM IBM
Sistema de armazenamento
primário
Sistema de armazenamento
auxiliar
ppprc509-2
Site A Site B Site A Site B
Aplicativo
Falha de acesso ao nó Solução de acesso ao nó
Nó 1 Nó 2 Nó 3 Nó 4
IBM IBM
Sistema de armazenamento
primário Sistema de
armazenamento auxiliar
Aplicativo
Nó 1 Nó 2 Nó 3 Nó 4
Pulsações
Replicação Replicação
Figura 3. Configuração de HyperSwap não planejado para falha de acesso ao nó
É possível usar as opções de configuração a seguir em seu ambiente para minimizar ou eliminar a falha de site não planejada:
Usar políticas de divisão e mesclagem
Se um fallover ocorrer, é possível especificar o tipo de política que você deseja que o PowerHA SystemMirror implemente. As políticas podem reduzir a partição de site durante um fallover. As políticas que são combinadas com a função HyperSwap podem reduzir a possibilidade de
distorção de dados. Portanto, se o seu cluster usa a função HyperSwap, é necessário configurar as políticas de divisão e mesclagem, para que seja possível recuperar dados automaticamente
durante um fallover. Os tipos de políticas a seguir são suportados pela função HyperSwap:
v Política de divisão v Política de mesclagem
v Política de divisão e mesclagem Ação de recuperação
É possível configurar seu cluster para usar as opções automáticas ou manuais para recuperação de grupo de espelhos durante um fallover.
Iniciando grupos de recursos e grupos de espelhos
Ao usar o PowerHA SystemMirror para iniciar grupos de recursos e grupos de espelhos, deve-se verificar se o grupo de recursos ou espelhos selecionado está no sistema de armazenamento auxiliar. Se você selecionar o sistema de armazenamento auxiliar, o grupo de espelhos ou grupo de recursos não inicia e entra em um estado de erro porque o sistema de armazenamento
Pulsações
IBM IBM
Sistema de armazenamento
primário
Sistema de armazenamento
auxiliar
ppprc510-2
Site A Site B Site A Site B
Falha de partição de site Partição de site após falha
Nó 1 Nó 2 Nó 3 Nó 4
IBM IBM
Sistema de armazenamento
primário
Sistema de armazenamento
auxiliar Aplicativo
Nó 1 Nó 2 Nó 3 Nó 4
Pulsações
Aplicativo Aplicativo
Figura 4. Configuração de HyperSwap não planejado para falha de site
primário não pode ser acessado. A seleção do grupo de recursos e espelhos correto minimiza a distorção de dados se o seu cluster for dividido durante um fallover.
Trocando grupos de recursos e grupos de espelhos
Quando uma falha ocorre no grupo de volumes primário, uma troca automática ocorre. No entanto, a troca não depende de uma divisão de cluster ou uma opção de recuperação. O
processo de troca assegura que os sistemas de armazenamento que contêm os grupos de recursos e grupos de espelhos sejam acessíveis, para que uma troca possa ocorrer.
Processo de fallover para grupos de recursos e grupos de espelhos
Quando o fallover ocorre para um nó ou site que contém grupos de recursos e grupos de espelhos, o PowerHA SystemMirror identifica se outro nó ou site é acessível. Se o nó ou site não for acessível, os grupos de recursos e grupos de espelhos não serão iniciados no sistema de armazenamento auxiliar a menos que o cluster seja configurado com uma política de divisão ou mesclagem.
Cenário: Configuração não planejada do HyperSwap para sistemas de armazenamento suspensos:
Neste cenário, os sistemas de armazenamento em ambos os site não estão sincronizando e a replicação não está ocorrendo.
A figura a seguir é para uma configuração de cluster no ambiente do PowerHA SystemMirror Enterprise Edition for AIX com as características a seguir:
v Dois sites chamados Site A e Site B.
v Dois nós para cada site para um total de quatro nós. Todos os nós possuem acesso a cada sistema de armazenamento no Site A e Site B.
v Os sistemas de armazenamento para ambos os sites estão em um estado suspenso.
v Os discos de aplicativo são replicados usando o metroespelhamento do IBM DS8800.
Na figura a seguir, os sistemas de armazenamento para o Site A e Site B estão em um estado suspenso. O HyperSwap for PowerHA SystemMirror não pode determinar onde os dados mais recentes estão
disponíveis porque os sistemas de armazenamento estão em um estado suspenso. Não há nenhuma solução de recuperação automática para corrigir o problema.
Para corrigir o problema identificado neste cenário, conclua as etapas a seguir:
1. Execute uma operação de recuperação de failback no sistema de armazenamento.
2. Na linha de comandos, insira smit sysmirror.
3. Na interface SMIT, selecione Gerenciamento de sistemas (C-SPOC) > Grupo de recursos e aplicativos> Colocar o grupo de recursos on-line e pressione Enter.