Acerca da replicação assíncrona

A replicação assíncrona oferece um objetivo de ponto de recuperação (RPO) baixo e um objetivo de tempo de recuperação (RTO) baixo para a replicação de armazenamento em bloco para a recuperação de desastres (RD) ativa-passiva entre regiões.

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

Pode usar a replicação assíncrona para gerir a replicação de cargas de trabalho do Compute Engine ao nível da infraestrutura, em vez de ao nível da carga de trabalho.

Vista geral

A replicação assíncrona replica dados de um disco associado a uma carga de trabalho em execução, o disco principal, para um disco separado localizado noutra região. O disco que recebe os dados replicados é denominado disco secundário.

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

Qualquer disco que cumpra os requisitos de disco pode ser usado como um disco principal. Depois de ter um disco principal, pode criar um disco secundário que faça referência ao disco principal e iniciar a replicação do disco principal para o disco secundário.

Se parar a replicação do disco principal em qualquer altura e quiser reiniciar a replicação mais tarde, tem de criar um novo disco secundário para reiniciar a replicação.

Grupos de consistência

Os grupos de consistência permitem-lhe realizar testes de DR e DR em vários discos. Um grupo de consistência é uma política de recursos que faz o seguinte:

  • Alinha a replicação nos discos principais e garante que todos os discos contêm dados de replicação a partir de um ponto comum no tempo, que é usado para a recuperação de desastres.
  • Alinha os clones de discos de discos secundários e garante que todos os clones de discos contêm dados de um ponto comum no tempo, que é usado para testes de recuperação de desastres.

Se quiser alinhar o período de replicação em vários discos, adicione discos primários a um grupo de consistência. Se quiser clonar vários discos e garantir que esses clones têm dados de um ponto comum no tempo, 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 para ambos em simultâneo.

Se quiser adicionar discos principais a um grupo de consistência, tem de adicionar discos ao grupo de consistência antes de iniciar a replicação. Pode adicionar discos secundários a um grupo de consistência em qualquer altura.

Comutação por falha e reversão

Em caso de indisponibilidade na região principal, é da sua responsabilidade identificar a indisponibilidade e reiniciar a carga de trabalho através dos discos secundários na região secundária. A replicação assíncrona não oferece monitorização de interrupções. Pode identificar uma indisponibilidade através das métricas de RPO, verificações de estado>, métricas específicas da aplicação e contactando o apoio técnico ao cliente da Google Cloud.

O processo de alternativa envolve as seguintes tarefas:

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

Após a comutação por falha dos discos, é da sua responsabilidade validar e reiniciar a carga de trabalho da aplicação na região secundária, bem como reconfigurar os endereços de rede usados para aceder à aplicação de modo a apontarem para a região secundária.

Após uma comutação por falha da região principal para a região secundária, a região secundária torna-se a região principal em vigor. Após a interrupção ou o desastre ser resolvido, pode iniciar a reposição para iniciar a replicação a partir da região secundária original (a região principal em vigor) para a região principal original. Opcionalmente, pode repetir o processo para mover a carga de trabalho novamente para a região principal original.

O processo de reversão envolve as seguintes tarefas:

  1. Configure a replicação entre a nova região principal e a região principal original.

    • O disco secundário original é agora o novo disco principal e configura-o para replicar para um novo disco secundário na região principal original.
    • Pode criar uma nova política de recursos de grupo de consistência na nova região principal para que os novos discos principais (os discos secundários originais) possam ser replicados de forma consistente para um novo conjunto de discos secundários na região principal original.

  2. (Opcional) Após a replicação inicial, pode repetir o processo de comutação por falha para devolver a carga de trabalho à região principal original.

Encriptação de disco

Os discos primários e secundários não suportam chaves de encriptação fornecidas pelos clientes (CSEK). Em alternativa, use Google-owned and Google-managed encryption keys ou chaves de encriptação geridas pelo cliente (CMEK). Se usar as CMEK no disco principal, também tem de as usar no disco secundário. Pode usar diferentes CMEKs em ambos os discos.

Personalização do disco secundário

Quando cria um disco secundário, o Compute Engine copia as propriedades do disco principal para o disco secundário. Estas propriedades incluem a descrição do disco principal, o tipo de disco e as etiquetas.

Se o disco principal for um disco de arranque, o disco secundário também tem a configuração de arranque do disco principal. A configuração de arranque inclui informações sobre a arquitetura do sistema operativo (SO), as licenças do SO e as respetivas funcionalidades do SO convidado.

Pode alterar determinadas propriedades do disco secundário para que sejam diferentes do disco principal. Por exemplo, o disco principal e o secundário têm de ter o mesmo tamanho e chave de encriptação, mas pode atribuir etiquetas adicionais ao disco secundário.

Para discos de arranque, pode ativar opções de segurança ou de rede adicionais no disco secundário especificando funcionalidades adicionais do SO convidado. No entanto, não pode remover nenhuma das funcionalidades do SO convidado do disco principal. O Compute Engine une as novas funcionalidades especificadas com as funcionalidades do SO convidado existentes do disco principal.

Exemplo

Suponhamos que tem um disco de arranque denominado disk-1, com as seguintes funcionalidades do SO convidado: [GVNIC, UEFI_COMPATIBLE].

Se criar um disco secundário a partir de disk-1, só pode especificar funcionalidades adicionais. Não pode remover as funcionalidades UEFI_COMPATIBLE e GVNIC. Assim, se especificar MULTI_IP_SUBNET quando criar o disco secundário, as funcionalidades do novo disco são unidas às do disco principal. Por isso, as funcionalidades do SO convidado resultantes para o disco secundário são GVNIC, UEFI_COMPATIBLE e MULTI_IP_SUBNET.

Para saber como personalizar um disco secundário, consulte o artigo Crie um disco secundário personalizado.

Replicação assíncrona e discos regionais

Pode usar a replicação assíncrona com discos regionais para alcançar uma elevada disponibilidade (HA) e recuperação de desastres (DR).

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

Quando usa um disco regional como disco principal, a replicação permanece ininterrupta, mesmo que uma das respetivas zonas sofra uma indisponibilidade. O disco principal regional continua a replicar dados da zona em bom estado para o disco secundário. Da mesma forma, quando um disco regional serve como disco secundário, a replicação persiste apesar de uma indisponibilidade numa das respetivas zonas. A utilização de um disco regional como disco secundário prepara a sua carga de trabalho para a alta disponibilidade em várias zonas em caso de uma comutação por falha, em que o disco secundário passa a ser o novo disco principal.

Limitações

  • A replicação assíncrona só é suportada para os seguintes tipos de discos:
    • Disco persistente equilibrado
    • Disco persistente de desempenho (SSD)
    • Hyperdisk Balanced
    • Hiperdisco equilibrado de alta disponibilidade
    • Hyperdisk Extreme
  • Os discos só de leitura não são suportados.
  • Os discos com vários escritores só são suportados para o Hyperdisk Balanced e o Hyperdisk Balanced de alta disponibilidade.
  • As edições que fizer ao tamanho do Hyperdisk são aplicadas automaticamente ao disco secundário. No entanto, as alterações às propriedades do Hyperdisk, incluindo as alterações de IOPS, débito e modo de acesso, não são aplicadas automaticamente ao disco secundário. Tem de editar manualmente estas propriedades no disco secundário.
  • Cada disco pode ter um tamanho máximo de 64 TiB.
  • Tem de parar a replicação antes de poder eliminar um disco principal ou secundário.
  • Se a replicação estiver em curso para o disco de arranque de uma VM, não pode eliminar a VM até parar a replicação.
  • Se um disco principal estiver associado a uma VM como um disco não de arranque e o disco estiver configurado para ser eliminado com a VM, não pode eliminar a VM nem o disco até parar a replicação ou desassociar o disco principal da VM. As tentativas de eliminar a VM vão falhar até parar a replicação.

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

    Por exemplo, um determinado projeto, project-1, pode ter até 1000 pares de discos na região de Iowa-Oregão. project-1 também pode ter até 1000 pares de discos no par de regiões Bélgica-Frankfurt.

Regiões suportadas

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

  • Ásia, exceto Indonésia
  • Europa
  • América do Norte
  • Oceânia

Pode replicar um disco principal numa determinada região para um disco secundário em qualquer região disponível no mesmo continente. Isto significa que pode criar um par de regiões a partir de quaisquer duas regiões no mesmo continente.

Por exemplo, suponha que tem um disco principal em Frankfurt (europe-west3). Pode replicar esse disco para um disco secundário em qualquer lugar da Europa, mas não o pode replicar para uma região na América do Norte.

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

Desempenho

O objetivo de ponto de recuperação (RPO) ou o atraso de tempo para quando os dados estão disponíveis no site secundário depende das taxas de alteração do disco. Normalmente, a replicação assíncrona replica dados com um RPO de destino de um minuto, até 12,5 GB de blocos alterados comprimidos por minuto com blocos de disco replicados com uma granularidade de blocos de 4 KB. Se um determinado bloco for alterado várias vezes entre eventos de replicação, apenas a alteração mais recente é replicada para o disco secundário. Com taxas de alteração do disco mais elevadas, o RPO pode ser superior a um minuto e, normalmente, aumenta à medida que as taxas de alteração do disco crescem. O RPO não é configurável.

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

  • Quando a replicação de disco começa. Durante a replicação inicial, a replicação assíncrona replica todos os blocos usados no disco principal para o disco secundário. A replicação inicial está 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 do disco for superior a 12,5 GB de blocos alterados comprimidos por minuto. Após um pico nas alterações ao disco, o RPO dos ciclos de replicação posteriores pode exceder um minuto enquanto a replicação é atualizada.
  • Se desanexar um disco de uma VM ou reiniciar uma VM enquanto o disco está a ser replicado. Os discos em replicação desassociados de uma VM podem registar um aumento do RPO até cinco minutos durante um curto período.

Para saber como ver o RPO dos seus discos, consulte o artigo Métricas de desempenho da replicação assíncrona.

O objetivo de tempo de recuperação (RTO) durante a transferência de recursos depende do tempo necessário para concluir as várias tarefas envolvidas na transferência de recursos da sua carga de trabalho para uma nova região. As tarefas, como parar a replicação e anexar discos a VMs na região secundária, devem demorar apenas alguns minutos a concluir. Pode acelerar o RTO certificando-se de que tem VMs em execução na região secundária, para que, se ocorrer uma comutação por falha, não tenha de esperar que as VMs sejam iniciadas.

O que se segue?