Replique o grupo, não o disco, consistência na replicação entre arrays

A replicação entre arrays soa ao tipo mais simples de disaster recovery: o array copia os seus discos para outro array noutro datacenter, e nada dentro dos seus servidores tem de mudar. É mesmo assim tão simples, desde que replique as coisas certas em conjunto. Replique cada volume por si só e pode acabar com uma cópia perfeita de cada disco e uma base de dados que se recusa a arrancar.

Uma cópia de cada disco não é uma cópia da aplicação

A maioria das aplicações sérias escreve em mais do que um volume. Uma base de dados guarda os ficheiros de dados num disco e o transaction log noutro. Um servidor de correio separa o message store dos seus logs. Uma máquina virtual pode ter um disco de sistema e um disco de dados que só fazem sentido juntos.

Estas aplicações dependem da ordem das escritas. A base de dados escreve primeiro o registo no log e depois a página de dados, e na recuperação reproduz o log para levar os ficheiros de dados a um ponto consistente. Se a cópia do volume de log no site remoto for alguns segundos mais antiga do que a cópia do volume de dados, o site remoto guarda páginas de dados que se referem a registos de log que ali não existem. A base de dados vê um estado impossível. Na melhor das hipóteses recupera com trabalho; na pior não abre.

Quando cada volume replica de forma independente, cada cópia avança ao seu próprio ritmo, pelo que os discos remotos quase nunca estão no mesmo instante no tempo. A resposta é um consistency group: um conjunto de volumes que o array replica como uma só unidade, preservando a ordem das escritas em todos eles. Nos HPE 3PAR isto é um Remote Copy group. Outros arrays têm o seu próprio nome para a mesma ideia. Chame-se o que se chamar, a regra é a mesma. Tudo o que uma aplicação precisa para arrancar entra num só grupo.

Escolher o que entra num grupo

Comece pela aplicação, não pela lista de volumes:

• Liste todos os volumes em que a aplicação escreve, incluindo os que são fáceis de esquecer: o volume que guarda o arquivo do binary log ou do write-ahead log, um tablespace temporário separado, um disco de configuração.
• Coloque-os todos num só grupo.
• Mantenha aplicações sem relação entre si em grupos separados, para que uma possa fazer failover, ser testada ou pausada sem tocar na outra.

Depois decida quão de perto a cópia segue o original.

Quão próxima deve estar a cópia?

Há duas grandes famílias de modos de replicação, e a escolha é tanto uma questão de física como de preferência.

O síncrono mantém a cópia atual à custa de uma ida e volta em cada escrita, que é pequena a distância metropolitana e mensurável entre países. O assíncrono corre à velocidade local e o atraso é o seu recovery point.

Nenhum está certo em geral. Um sistema transacional cujo último minuto de encomendas tem valor pode justificar a latência de escrita; uma plataforma de conteúdos que pode perder alguns minutos de edições normalmente não. A resposta correta vem de perguntar o que custaria ao negócio perder essa diferença, e depois medir se a aplicação tolera a latência do modo mais estrito.

Mantenha a replicação fora do caminho da produção

O tráfego de replicação compete com o I/O dos hosts se o deixar. Dê-lhe portas dedicadas no array, mantenha essas portas separadas das portas que os hosts usam, e mantenha cada ligação de replicação com um único parceiro. Vigie o atraso da replicação, não apenas o estado da ligação. Uma ligação que está up enquanto a cópia fica cada hora mais para trás é o modo de falha que transforma um plano de disaster recovery numa surpresa.

Teste a réplica sem a estragar

Uma réplica que nunca foi arrancada é uma esperança. A boa notícia é que pode testá-la sem interromper a replicação:

1. Tire um snapshot point-in-time dos volumes secundários do grupo no array remoto. Faça o snapshot de todo o grupo de uma vez, para que a cópia de teste seja tão consistente como a réplica.
2. Apresente os snapshots a um host de teste isolado no site remoto. Mantenha esse host fora da rede de produção, para que a cópia não possa responder a tráfego real, enviar e-mails reais ou correr tarefas agendadas contra sistemas reais.
3. Arranque a aplicação exatamente como faria num desastre, usando o seu runbook escrito e nada mais.
4. Verifique-a ao nível da aplicação: a base de dados abre e passa a sua própria verificação de consistência, as contagens de linhas e os registos mais recentes estão onde o recovery point diz que deviam estar, e um login na aplicação funciona.
5. Cronometre, desde a decisão de fazer failover até à primeira transação bem-sucedida. Esse número é o seu tempo de recuperação real, diga o plano o que disser.
6. Remova os snapshots e registe o resultado, incluindo tudo o que o surpreendeu.

Faça o teste depois de qualquer alteração ao grupo, e num calendário regular mesmo quando nada mudou, porque as aplicações acrescentam volumes em silêncio.

Replicação não é backup

A replicação copia as alterações fielmente, e isso inclui uma tabela apagada, uma encriptação por ransomware e um deployment mau. Em segundos ou minutos o erro está nos dois lados. Uma réplica protege-o de perder um site; backups com histórico protegem-no dos seus próprios dados. Precisa de ambos, e os backups devem ser puxados por um sistema a que o lado da produção não consegue chegar.

Como o fazemos

Entre os nossos datacenters de Atenas e Amesterdão, os volumes dos clientes podem replicar de array para array em HPE 3PAR, com os volumes relacionados colocados no mesmo Remote Copy group para se manterem consistentes entre si. O modo de replicação é acordado por serviço, a replicação corre em portas dedicadas, um parceiro por par de portas, sobre a nossa própria interligação privada entre os sites, e as réplicas de dados alojados na UE ficam dentro da nossa infraestrutura na UE. Dentro de cada site os arrays estão em federation, pelo que os volumes também se movem entre arrays online. Os backups ficam ao lado, separados e pull-only.

Se não tem a certeza de que a sua cópia remota arrancaria no dia em que precisar dela, vale a pena descobri-lo num dia sossegado. Teremos todo o gosto em ajudar a desenhar os grupos e o teste.

cta: Fale com um engenheiro

Related

• /what-we-do/storage-compute/storage-replication-federation/
• /what-we-do/storage-compute/disaster-recovery/
• /what-we-do/storage-compute/enterprise-san-storage/