Sobre a replicação assíncrona do disco permanente

A replicação assíncrona do disco permanente (replicação assíncrona do DP) oferece um objetivo de ponto de recuperação baixo (RPO) e um objetivo de tempo de recuperação baixo (RTO ), bloquear a replicação de armazenamento para recuperação de desastres (DR) ativa e passiva entre regiões.

A replicação assíncrona de DPs é uma opção de armazenamento que oferece replicação assíncrona de dados entre duas regiões. No caso improvável de uma falha temporária regional, a replicação assíncrona de DPs permite fazer failover dos dados para uma região secundária e reiniciar a carga de trabalho nessa região.

Use a replicação assíncrona de DP para gerenciar a replicação das cargas de trabalho do Compute Engine no nível da infraestrutura, em vez do nível da carga de trabalho.

Visão geral

A replicação assíncrona do disco permanente replica os dados de um disco anexado a uma carga de trabalho em execução, o disco primário, para um disco separado localizado em outra região. O disco que recebe os dados replicados é chamado de disco secundário.

A região em que o disco principal está localizado é chamada de região primária e a região em que o disco secundário está localizado é chamada de região secundária. As regiões primária e secundária são chamadas de par de regiões.

Qualquer disco que atenda aos requisitos de disco pode ser usado como um disco principal. Depois de criar um disco principal, é possível criar um disco secundário que faça referência ao disco principal e inicie a replicação dele para o disco secundário.

Se você interromper a replicação do disco principal a qualquer momento e quiser reiniciá-la mais tarde, será necessário criar um novo disco secundário para reiniciar a replicação.

Grupos de consistência

Os grupos de consistência permitem realizar recuperação de desastres (DR) e testes de DR em vários discos. Um grupo de consistência é uma política de recursos que faz o seguinte:

  • Alinha a replicação entre os discos principais e garante que todos os discos contenham dados de replicação de um ponto comum no tempo, que é usado para DR.
  • Alinha os clones de disco dos discos secundários e garante que todos os clones de disco contenham dados de um ponto comum no tempo, usado para treinamentos de DR.

Se você quiser alinhar o período de replicação em vários discos, adicione discos principais a um grupo de consistência. Se você quiser clonar vários discos e garantir que esses clones tenham dados de um momento comum, adicione discos secundários a um grupo de consistência. Um grupo de consistência pode ser usado para replicação ou clonagem, mas não ambos simultaneamente.

Se você quiser adicionar discos principais a um grupo de consistência, adicione discos ao grupo de consistência antes de iniciar a replicação. É possível adicionar discos secundários a um grupo de consistência a qualquer momento.

Failover e failback

No caso de uma interrupção na região primária, é sua responsabilidade identificar a falha e reiniciar a carga de trabalho usando os discos secundários, na região secundária. A replicação assíncrona de DPs não oferece monitoramento de falhas. É possível identificar uma falha temporária usando métricas do RPO, verificações de integridade, métricas específicas do aplicativo e entrando em contato com o Cloud Customer Care.

O processo de failover envolve as seguintes tarefas:

  1. Interrompe a replicação.
  2. Anexe os discos secundários às VMs na região secundária.

Depois de realizar o failover dos discos, é sua responsabilidade validar e reiniciar a carga de trabalho do seu aplicativo na região secundária e reconfigurar os endereços de rede usados para acessar o aplicativo e apontar para a região secundária.

Após um failover da região principal para a região secundária, a região secundária se torna a região primária de atuação. Depois que a falha ou o desastre for resolvido, inicie o failover para iniciar a replicação da região secundária original (a região primária de ação) para a região primária original. Se quiser, repita o processo para mover a carga de trabalho de volta à região principal original.

O processo de failback envolve as seguintes tarefas:

  1. Configure a replicação entre a nova região primária e a original.

    • O disco secundário original agora é o novo disco primário. Você o configura para ser replicado em um novo disco secundário na região principal original.
    • É possível criar uma nova política de recursos de grupos de consistência na nova região primária para que os novos discos principais (os discos secundários originais) possam ser replicados de forma consistente em um novo conjunto de discos secundários na região primária original. (em inglês).

  2. (Opcional) Depois que a replicação inicial ocorrer, repita o processo de failover para retornar a carga de trabalho à região principal original.

Criptografia de disco

Os discos primários e secundários não oferecem suporte a chaves de criptografia fornecidas pelo cliente (CSEK). Use chaves de propriedade e gerenciadas pelo Google ou chaves de criptografia gerenciadas pelo cliente (CMEK). Se você usa CMEK no disco principal, use também CMEK no disco secundário. É possível usar CMEKs diferentes nos dois discos.

Personalização do disco secundário

Quando você cria um disco secundário, o Compute Engine copia as propriedades do disco principal para o secundário. Essas propriedades incluem a descrição, o tipo e os rótulos do disco principal.

Se o disco principal for de inicialização, o disco secundário também terá a configuração de inicialização do disco principal. A configuração de inicialização inclui informações sobre a arquitetura do sistema operacional (SO), as licenças do SO e os recursos do SO convidado.

É possível alterar determinadas propriedades do disco secundário para que elas sejam diferentes do disco principal. Por exemplo, o disco principal e o secundário precisam ter o mesmo tamanho e a mesma chave de criptografia, mas é possível atribuir mais rótulos ao disco secundário.

Para discos de inicialização, é possível ativar outras opções de segurança ou de rede no disco secundário ao especificar outros recursos do SO convidado. No entanto, não é possível remover nenhum dos recursos do SO convidado do disco principal. O Compute Engine mescla os novos recursos especificados com os recursos atuais do SO convidado do disco principal.

Exemplo

Suponha que você tenha um disco de inicialização chamado disk-1, com os seguintes recursos do SO convidado: [GVNIC, UEFI_COMPATIBLE].

Se você criar um disco secundário usando disk-1, será possível especificar apenas recursos adicionais. Não é possível remover os recursos UEFI_COMPATIBLE e GVNIC. Dessa forma, se você especificar MULTI_IP_SUBNET ao criar o disco secundário, o novo recurso será mesclado com os do disco principal. Os recursos resultantes do SO convidado para o disco secundário serão GVNIC. UEFI_COMPATIBLE e MULTI_IP_SUBNET.

Para saber como personalizar um disco secundário, consulte Criar um disco secundário personalizado.

Replicação assíncrona de DP e discos permanentes regionais

É possível usar a replicação assíncrona de DP com discos permanentes regionais para ter alta disponibilidade (HA, na sigla em inglês) e recuperação de desastres (DR).

Os discos permanentes regionais podem ser usados como disco principal ou secundário em um par de discos de replicação assíncrona do DP. Um par de discos é um disco principal que é replicado para um disco secundário.

Ao usar um disco regional como disco principal, a replicação permanece ininterrupta, mesmo se uma das zonas sofrer uma interrupção do serviço. O disco principal regional continua a replicar dados da zona íntegra para o disco secundário. Da mesma forma, quando um disco regional serve como disco secundário, a replicação persiste apesar de uma interrupção em uma das zonas. Usar um disco regional como disco secundário prepara a carga de trabalho para alta disponibilidade entre zonas em caso de failover, em que o disco secundário transiciona para se tornar o novo disco principal.

Limitações

  • Só há suporte para a replicação assíncrona do DP no Persistent Disk balanceado e de desempenho (SSD).
  • Discos somente leitura e discos de vários gravadores não são suportados.
  • Cada disco pode ter um tamanho máximo de 32 TiB.
  • É necessário interromper a replicação antes de excluir um disco principal ou secundário.
  • Se a replicação estiver em andamento para o disco de inicialização de uma VM, não será possível excluir a VM até que a replicação seja interrompida.
  • Se um disco principal for anexado a uma VM como um disco que não é de inicialização e estiver configurado para ser excluído com a VM, não será possível excluir a VM ou o disco até que você pare a replicação ou remova o disco principal da VM. As tentativas de excluir a VM vão falhar até que você pare a replicação.

  • Cada projeto pode ter no máximo 1.000 pares de discos em cada par de regiões.

    Por exemplo, um determinado projeto, project-1 pode ter até 100 pares de discos no par de regiões de Iowa e Oregon. project-1 também pode ter até 1.000 pares de discos no par de regiões Bélgica-Frankfurt.

Regiões aceitas

A replicação assíncrona de DP está disponível em todas as regiões dos seguintes continentes:

  • Ásia, exceto Indonésia
  • Europa
  • América do Norte
  • Oceania

É possível replicar um disco principal em uma determinada região para um disco secundário em qualquer região disponível no mesmo continente. Isso significa que é possível criar um par de regiões em qualquer duas regiões no mesmo continente.

Por exemplo, suponha que você tenha um disco principal em Frankfurt (europe-west3). É possível replicá-lo em um disco secundário em qualquer lugar da Europa, mas não replicá-lo para uma região na América do Norte.

Para ver uma lista completa de todas as regiões no Compute Engine, consulte Zonas e regiões disponíveis.

Desempenho

O objetivo do ponto de recuperação (RPO) ou o atraso de quando os dados estão disponíveis no local secundário depende das taxas de alteração do disco. A replicação assíncrona do DP normalmente replica dados com um RPO de destino de um minuto, para até 12,5 GB de blocos alterados compactados por minuto, com blocos de discos replicados com granularidade de blocos de 4 KB. Se um determinado bloco for alterado várias vezes entre eventos de replicação, somente a alteração mais recente será replicada no disco secundário. Em taxas de alteração de disco mais altas, o RPO pode ser maior que um minuto e geralmente aumenta conforme as taxas de alteração de disco aumentam. O RPO não é configurável.

O RPO pode exceder um minuto nos seguintes cenários:

  • Quando a replicação do disco é iniciada. Durante a replicação inicial, a replicação assíncrona de DPs replica todos os blocos usados no disco principal para o disco secundário. A replicação inicial é concluída quando a métrica disk/async_replication/time_since_last_replication está disponível no Cloud Monitoring.
  • Se a taxa de alteração de disco for maior que 12,5 GB de blocos alterados compactados por minuto. Após um aumento no disco, o RPO para ciclos de replicação posteriores pode exceder um minuto enquanto a replicação alcança.
  • Se você desanexar um disco de uma VM ou reiniciar uma VM enquanto o disco estiver sendo replicado. Os discos em replicação que são desanexados de uma VM podem ver o RPO aumentar por até cinco minutos por um curto período.

Para saber como visualizar o RPO dos discos, consulte Métricas de desempenho da replicação assíncrona do disco permanente.

O objetivo do tempo de recuperação (RTO) durante o failover depende do tempo necessário para concluir as várias tarefas envolvidas no failover sua carga de trabalho para uma nova região. Tarefas como a interrupção da replicação e a anexação de discos às VMs na região secundária precisam levar apenas alguns minutos para ser concluídas. É possível acelerar o RTO garantindo que você tenha VMs em execução na região secundária. Assim, se ocorrer um failover, não será preciso esperar a inicialização das VMs.

A seguir