Espelhamento assíncrono

Largura da banda da rede

Quando o espelhamento síncrono é usado, é necessário fornecer largura da banda da rede suficiente para manipular a carga de trabalho de espelhamento de dados em seu pico, para assegurar um tempo de resposta aceitável. No entanto, quando o espelhamento assíncrono é usado, pode ser necessário fornecer largura da banda da rede suficiente para um pouco mais do que a quantidade média da carga de trabalho de espelhamento de dados. Realmente depende do quanto o pico se difere da média e se o cache do site de produção é grande o suficiente para conter o excesso de solicitações de gravação durante os períodos de pico. Na maioria dos casos, o espelhamento assíncrono requer uma rede de largura de banda menos dispendiosa do que o espelhamento síncrono. Por exemplo, se uma solução síncrona requer uma rede que esteja apenas 10 utilizando a maior parte do tempo, mas a mesma carga de trabalho pode ser espelhada de forma assíncrona sobre uma rede de largura de banda baixa que é 75% utilizada na maior parte do tempo, então o espelhamento assíncrono pode ser uma escolha melhor do que o espelhamento síncrono.

Latência de rede

O espelhamento assíncrono permite que o espelhamento de dados no site de recuperação de desastre fique atrás de gravações do aplicativo que ocorrem no site de produção. Isso pode melhorar muito o tempo de resposta do aplicativo por ter AIX® LVM dizer ao aplicativo que sua gravação foi concluída após os dados terem sido gravados nos discos locais, mas sem ter que esperar que os dados sejam gravados nos discos remotos. As solicitações de gravação de volumes físicos remotos são armazenadas em cache no site de produção e espelhadas no site de recuperação de desastre por um período de tempo mais longo, removendo efetivamente os efeitos da latência de rede que, por sua vez, permite que os sites fiquem ainda mais distantes, sem impactar o tempo de resposta do aplicativo.

Se o espelhamento de dados remoto puder manter uma demanda suficiente para evitar que o cache fique cheio, pode não haver um atraso perceptível no tempo de resposta do aplicativo. No entanto, quando o limite de armazenamento em cache for atingido, as gravações do aplicativo terão que aguardar até que haja espaço no cache. Em uma carga de trabalho do aplicativo de gravação intensiva, o espelhamento remoto atingiria mais rapidamente o limite do cache e o tempo de resposta do aplicativo diminuiria. Em um ambiente como esse, o espelhamento assíncrono não oferece nenhuma melhoria com relação ao espelhamento síncrono e, devido ao risco de perda de dados, não é a melhor opção para espelhamento.

Evitando a perda de dados

O espelhamento assíncrono cria a possibilidade de alguma quantidade de perda de dados de um desastre do site de produção. Se o espelhamento de site remoto ficar atrás do site local, você corre o risco de perder os dados em cache no caso de um desastre. É necessário determinar a quantidade de dados que você está disposto a correr o risco de perder.

As solicitações de gravação de volumes físicos remotos são armazenadas em cache em armazenamento permanente no site de produção, até que sejam gravadas em disco no site de recuperação de desastre. Após um travamento do nó, é possível recuperar essas solicitações de gravação. Por exemplo, suponha que um nó trave enquanto o grupo de volumes muda para online. Você pode recuperar o nó acidado, trazer o grupo de volume de volta online, e ter o espelhamento assíncrono captar onde parou, sem mais perda de dados do que quando utilizar grupos de volume ordinário.

Se você parar a carga de trabalho do aplicativo e mudar um grupo de volumes para offline, todas as gravações pendentes de volumes físicos remotos serão gravadas em disco no site remoto. Por exemplo, se desativar o site de produção para manutenção planejada, você não desejará que o grupo de volumes seja mudado para online no site de recuperação de desastre enquanto ainda houver gravações pendentes no cache no site de produção. Ao forçar o site remoto a ser atualizado no momento em que o grupo de volumes é mudado para offline, a carga de trabalho do aplicativo evita acessar dados com versão anterior acidentalmente. Além disso, o failover gracioso PowerHA® SystemMirror® de grupos de volumes espelhados geograficamente de forma assíncrona do site de produção para o site de recuperação de desastres pode ocorrer sem nenhuma perda de dados. O drawback dessa abordagem é que demorará mais para que o grupo de volumes seja mudado para offline, quando o cache contiver uma lista não processada de solicitações de gravação de volumes físicos remotos. Dependendo do tamanho da lista não processada, pode demorar muito para que todas as gravações no cache sejam gravadas nos discos no site remoto. E isso, por sua vez, pode causar uma grande demora de todos os tipos de failovers sem erros, independentemente de serem failovers de peer ou de site local.

A única vez que a perda de dados pode ocorrer ao usar o espelhamento assíncrono, além do que pode ser esperado ao usar grupos de volumes ordinários, é quando todo o site de produção falha repentinamente, antes de o espelhamento no site de recuperação de desastre ter tido a chance de capturar. Se os dados serão realmente perdidos ou não depende das circunstâncias da falha e, em alguns casos, de como você deseja lidar com essas circunstâncias. Por exemplo, uma inundação ou incêndio pode destruir todo o hardware no site de produção. Nesse cenário, a perda de dados quase certamente ocorrerá. Os dados perdidos consistiriam em todas as gravações de volumes físicos remotos não espelhados que estavam no cache no site de produção no momento da falha. Em outra situação, uma indisponibilidade de energia pode desativar todo o site de produção, sem destruir nenhum hardware. Nesse cenário, os dados ainda estão lá, mas não poderão ser acessados até que a energia seja restaurada e o sistema seja mudado para online novamente. É possível optar por aguardar a recuperação do site de produção, de modo que é possível evitar a perda de dados não espelhados ou mover a carga de trabalho do aplicativo para o site de recuperação de desastre, com alguma quantidade de perda de dados.

Divergência de dados

Divergência de dados é um estado em que os discos de cada site contêm atualizações de dados que não foram espelhadas para o outro site. Por exemplo, se um desastre destruir os discos no site de produção, a única cópia dos dados existirá no site de recuperação de desastre. Usando o espelhamento assíncrono, existe a possibilidade de os dados serem de uma versão anterior, devido ao armazenamento em cache de dados. No entanto, é possível que o site de produção falhe sem dano ao hardware. Nesse caso, os dados ainda estão lá, mas não poderão ser acessados até que o site de produção possa ser colocado online novamente. Nesse caso, é possível aguardar que o site de produção seja colocado online novamente ou mover a carga de trabalho do aplicativo para o site de recuperação de desastre. Se você mover a carga de trabalho do aplicativo para o site de recuperação de desastre, arriscará a divergência de dados conforme o aplicativo começa a usar os dados de versão anterior nos discos do site de recuperação de desastre. Você precisará determinar qual ação o site PowerHA SystemMirror deverá tomar caso o site de produção fique inativo enquanto o site de recuperação de desastres contiver dados de back-level.

Quando ocorrer a divergência de dados, será necessário decidir como deseja que seja feita a recuperação. Se forem feitas poucas ou nenhuma transação no site de recuperação de desastre, é necessário poder voltar ao site de produção com algumas complicações. No entanto, se seu site de recuperação de desastre tiver executado aplicativos por um longo período, não será possível apenas voltar ao site de produção sem arriscar alguns dos dados.