Planejar a recuperação de desastres

Esta página contém informações que podem ser usadas para planejar a recuperação de desastres das cargas de trabalho executadas no ambiente da Solução Bare Metal.

A Solução Bare Metal é entregue em uma extensão de região. Desde fevereiro de 2024, todas as regiões da Solução Bare Metal são hospedadas fisicamente em instalações que não são do Google. Devido ao modelo de extensão de região, a Solução Bare Metal não segue as o modelo de separação zonal convencional usado por outros serviços do Google Cloud, como o Compute Engine. cada implantação da Solução Bare Metal em uma região é conhecida como pod. Em algumas regiões, os recursos da Solução Bare Metal são e disponibilizados por vários pods, mas não é obrigatório ou esperado que os pods estão geograficamente separados.

Se você executa cargas de trabalho críticas, recomendamos para recuperação de desastres.

Recursos recomendados para o planejamento de recuperação de desastres

Recomendamos que você consulte os seguintes recursos para planejar recuperação de desastres:

Conectividade entre pods

As extensões de região e pods não têm conectividade direta. Todo o tráfego (de entrada e saída) da implantação da Solução Bare Metal transita por uma interconexão e pelo backbone do Google Cloud. Não há um caminho de dados compatível para a replicação no nível do armazenamento. Isso elimina as opções de recuperação de desastres as tecnologias de armazenamento, como replicação de armazenamento no nível de bloco ou replicação de snapshots.

Planejamento de região de recuperação de desastres

Normalmente, é possível selecionar uma região da Solução Bare Metal com base em outros serviços do Google Cloud que você está usando. No entanto, a recuperação de desastres para bancos de dados geralmente está alinhada com as regiões usadas para os aplicativos correspondentes e as integrações deles. Portanto, considere a latência de rede regiões ao planejar quais usar na recuperação de desastres.

Dependendo do seu setor, pode haver requisitos regulatórios sobre dados localidade que determinam onde é possível replicar os dados. Cada aplicativo tem a própria portanto, a seleção da região de recuperação de desastres fica a seu critério.

Considerações sobre a rede

Como isolar o tráfego para a interconexão

Em muitos casos, é recomendável isolar o tráfego de replicação das sessões do aplicativo.

O isolamento de tráfego pode ser alcançado com provisionamento Interconexões por parceiro em cada região que terminam em um VPC de trânsito usada para replicação. O diagrama a seguir mostra esse tipo de configuração do Terraform.

Isolamento de tráfego usando interconexões separadas.

No diagrama, os servidores da Solução Bare Metal na região us-west2 usam o A rede 10.10.10.0/24 e os servidores da Solução Bare Metal no us-east4 use a rede 10.20.20.0/24. O projeto do usuário contém VPCs separadas para o tráfego de aplicativo e replicação, chamado Application VPC e Replication VPC, respectivamente. As divulgações do BGP são configuradas cada Cloud Router na Replication VPC divulga uma rota para o rede da Solução Bare Metal entre regiões, forçando o fluxo de tráfego entre regiões durante Replication VPC. Os Cloud Routers no Application VPC anunciar uma rota genérica 0.0.0.0/0 ou rotas para blocos CIDR específicos que com que os servidores da Solução Bare Metal precisam se comunicar. Neste exemplo, 0.0.0.0/0 é usado para indicar uma rota que envia tráfego para qualquer outro destino.

Os servidores de aplicativos e outros serviços que se conectam no local e os data centers se conectam pela Application VPC. As instâncias no Application VPC ainda podem se comunicar com bancos de dados executados em qualquer extensão regional da Solução Bare Metal.

As interconexões que terminam na VPC de trânsito também podem ser usadas para acessar serviços do Google Cloud, como o Cloud Storage, o Filestore ou o Backup e DR. Isso pode ser feito criando a instância do Filestore na VPC de trânsito ou usando endpoints do Private Service Connect que residem na VPC de trânsito.