Arquitetar a recuperação de desastres para cargas de trabalho restritas por localidade

Last reviewed 2024-07-20 UTC

Este documento aborda como pode usar o Google Cloud para criar uma arquitetura de recuperação de desastres (RD) de modo a cumprir os requisitos específicos da localização. Para algumas indústrias regulamentadas, as cargas de trabalho têm de cumprir estes requisitos. Neste cenário, aplicam-se um ou mais dos seguintes requisitos:

  • Os dados em repouso têm de ser restritos a uma localização especificada.
  • Os dados têm de ser processados na localização onde residem.
  • As cargas de trabalho só são acessíveis a partir de localizações predefinidas.
  • Os dados têm de ser encriptados através de chaves geridas pelo cliente.
  • Se estiver a usar serviços na nuvem, cada serviço na nuvem tem de fornecer, no mínimo, duas localizações redundantes entre si. Para ver um exemplo dos requisitos de redundância de localização, consulte o Catálogo de critérios de conformidade de computação na nuvem (C5).

A série é composta por estas partes:

Terminologia

Antes de começar a criar a arquitetura para a recuperação de desastres para cargas de trabalho restritas por localidade, é uma boa ideia rever a terminologia de localidade usada no Google Cloud.

Google Cloud presta serviços nas regiões em toda a América, Europa, Médio Oriente e Ásia-Pacífico. Por exemplo, Londres (europe-west2) é uma região na Europa e Oregão (us-west1) é uma região na América do Norte. Alguns Google Cloud produtos agrupam várias regiões numa localização multirregião específica, acessível da mesma forma que usaria uma região.

As regiões estão ainda divididas em zonas onde implementa determinados Google Cloud recursos, como máquinas virtuais, clusters do Kubernetes ou bases de dados do Cloud SQL. Os recursos no Google Cloud são multirregionais, regionais ou zonais. Alguns recursos e produtos que são designados por predefinição como multirregionais também podem ser restritos a uma região. Os diferentes tipos de recursos são explicados da seguinte forma:

  • Os recursos multirregionais são concebidos Google Cloud para serem redundantes e distribuídos dentro e entre regiões. Os recursos multirregionais são resilientes à falha de uma única região.

  • Os recursos regionais são implementados de forma redundante em várias zonas de uma região e são resilientes à falha de uma zona na região.

  • Os recursos zonais operam numa única zona. Se uma zona ficar indisponível, todos os recursos zonais nessa zona ficam indisponíveis até o serviço ser restaurado. Considere uma zona como um domínio de falhas único. Tem de arquitetar as suas aplicações para mitigar os efeitos da indisponibilidade de uma única zona.

Para mais informações, consulte o artigo Geografia e regiões.

Planeamento da recuperação de desastres para cargas de trabalho restritas à localidade

A abordagem que adotar para conceber a sua aplicação depende do tipo de carga de trabalho e dos requisitos de localidade que tem de cumprir. Considere também por que motivo tem de cumprir esses requisitos, uma vez que a sua decisão influencia diretamente a arquitetura de recuperação de desastres.

Comece por ler o Google Cloud guia de planeamento de recuperação de desastres. À medida que considera cargas de trabalho restritas à localidade, concentre-se nos requisitos abordados nesta secção de planeamento.

Defina os requisitos de localidade

Antes de começar o design, defina os requisitos de localidade respondendo a estas perguntas:

  • Onde estão os dados em repouso? A resposta determina os serviços que pode usar e os métodos de alta disponibilidade (HA) e recuperação de desastres (DR) que pode usar para alcançar os seus valores de RTO/RPO. Use a página Localizações na nuvem para determinar que produtos estão no âmbito.
  • Pode usar técnicas de encriptação para mitigar o requisito? Se puder mitigar os requisitos de localidade através da utilização de técnicas de encriptação com o Cloud External Key Manager e o Cloud Key Management Service, pode usar serviços multirregionais e birregionais, e seguir as técnicas padrão de HA/DR descritas em Cenários de recuperação de desastres para dados.

  • Os dados podem ser processados fora da localização onde se encontram? Pode usar produtos como o GKE Enterprise para fornecer um ambiente híbrido que satisfaça os seus requisitos ou implementar controlos específicos do produto, como o equilíbrio de carga de instâncias do Compute Engine em várias zonas numa região. Use a política da organização Restrição de localização de recursos para restringir onde os recursos podem ser implementados .

    Se os dados puderem ser processados fora do local onde têm de estar em repouso, pode criar as partes de "processamento" da sua aplicação seguindo as orientações em Elementos básicos de recuperação de desastres e Cenários de recuperação de desastres para aplicações.

    Configure um perímetro dos VPC Service Controls para controlar quem pode aceder aos dados e restringir os recursos que podem processar os dados.

  • Pode usar mais do que uma região? Se puder usar mais do que uma região, pode usar muitas das técnicas descritas na série de recuperação de desastres. Verifique as restrições de várias regiões e de regiões para Google Cloud produtos.

  • Precisa de restringir quem pode aceder à sua aplicação? OGoogle Cloud tem vários produtos e funcionalidades que ajudam a restringir quem pode aceder às suas aplicações:

    • Identity-Aware Proxy (IAP). Valida a identidade de um utilizador e, em seguida, determina se esse utilizador deve ter permissão para aceder a uma aplicação. A política de organização usa a restrição de partilha restrita ao domínio para definir os IDs permitidos do Cloud ID ou do Google Workspace que são permitidos nas políticas do IAM.
    • Controlos de localidade específicos do produto. Consulte cada produto que quer usar na sua arquitetura para ver as restrições de localidade adequadas. Por exemplo, se estiver a usar o Cloud Storage, crie contentores em regiões especificadas.

Identifique os serviços que pode usar

Identifique que serviços podem ser usados com base na sua localidade e nos requisitos de granularidade regional. A conceção de aplicações sujeitas a restrições de localidade requer a compreensão dos produtos que podem ser restritos a que região e dos controlos que podem ser aplicados para impor os requisitos de restrição de localização.

Identifique o nível de detalhe regional da sua aplicação e dados

Identifique a granularidade regional da sua aplicação e dados respondendo a estas perguntas:

  • Pode usar serviços multirregionais no seu design? Ao usar serviços multirregionais, pode criar arquiteturas resilientes altamente disponíveis.
  • O acesso à sua aplicação tem restrições de localização? Use estes produtos para ajudar a aplicar restrições de acesso às suas aplicações:
  • Os seus dados em repouso estão restritos a uma região específica? Se usar serviços geridos, certifique-se de que os serviços que está a usar podem ser configurados para que os seus dados armazenados no serviço sejam restritos a uma região específica. Por exemplo, use as restrições de localidade do BigQuery para determinar onde os seus conjuntos de dados são armazenados e onde é feita a respetiva cópia de segurança.
  • A que regiões precisa de restringir a sua aplicação? Alguns produtosGoogle Cloud não têm restrições regionais. Use a página Localizações na nuvem e as páginas específicas do produto para validar em que regiões pode usar o produto e que funcionalidades de mitigação, se existirem, estão disponíveis para restringir a sua aplicação a uma região específica.

Cumprir as restrições de localidade com os Google Cloud produtos

Esta secção detalha as funcionalidades e as técnicas de mitigação para usar Google Cloud produtos como parte da sua estratégia de DR para cargas de trabalho com restrições de localidade. Recomendamos que leia esta secção juntamente com os Elementos básicos de recuperação de desastres.

Políticas da organização

O serviço de políticas da organização dá-lhe um controlo centralizado sobre os seus Google Cloud recursos. Com as políticas da organização, pode configurar restrições em toda a sua hierarquia de recursos. Considere as seguintes restrições de políticas ao criar arquiteturas para cargas de trabalho restritas por localidade:

  • Partilha restrita ao domínio: por predefinição, todas as identidades de utilizadores podem ser adicionadas às políticas de IAM. A lista permitida/recusada tem de especificar uma ou mais identidades de clientes do Cloud ID ou do Google Workspace. Se esta restrição estiver ativa, apenas as identidades na lista permitida são elegíveis para serem adicionadas às políticas de IAM.

  • Recursos com restrições de localização: Esta restrição refere-se ao conjunto de localizações onde os recursos Google Cloud baseados na localização podem ser criados. As políticas para esta restrição podem especificar como localizações permitidas ou recusadas qualquer uma das seguintes: multirregiões, como a Ásia e a Europa, regiões, como us-east1 ou europe-west1, ou zonas individuais, como europe-west1-b. Para ver uma lista dos serviços suportados, consulte o artigo Serviços suportados por localizações de recursos.

Encriptação

Se os seus requisitos de localidade de dados se referirem à restrição de quem pode aceder aos dados, a implementação de métodos de encriptação pode ser uma estratégia aplicável. Ao usar sistemas de gestão de chaves externos para gerir chaves que fornece fora do Google Cloud, pode implementar uma arquitetura de várias regiões para cumprir os seus requisitos de localidade. Sem as chaves disponíveis, não é possível desencriptar os dados.

Google Cloud tem dois produtos que lhe permitem usar chaves que gere:

  • Cloud External Key Manager (Cloud EKM): O Cloud EKM permite-lhe encriptar dados no BigQuery e no Compute Engine com chaves de encriptação armazenadas e geridas num sistema de gestão de chaves de terceiros implementado fora da infraestrutura da Google.

  • Chaves de encriptação fornecidas pelo cliente (CSEK): pode usar CSEK com o Cloud Storage e o Compute Engine. A Google usa a sua chave para proteger as chaves geradas pela Google que são usadas para encriptar e desencriptar os seus dados.

    Se fornecer uma chave de encriptação fornecida pelo cliente, a Google não armazena permanentemente a sua chave nos servidores da Google nem gere a sua chave de outra forma. Em alternativa, fornece a sua chave para cada operação, e a chave é eliminada dos servidores da Google após a conclusão da operação.

Quando gere a sua própria infraestrutura de chaves, tem de considerar cuidadosamente os problemas de latência e fiabilidade e garantir que implementa processos de recuperação e HA adequados para o seu gestor de chaves externo. Também tem de compreender os seus requisitos de RTO. As chaves são essenciais para escrever os dados, pelo que o RPO não é a preocupação crítica, uma vez que não é possível escrever dados em segurança sem as chaves. A preocupação real é o RTO, porque sem as suas chaves não pode desencriptar nem escrever dados em segurança.

Armazenamento

Ao arquitetar a DR para cargas de trabalho restritas por localidade, tem de garantir que os dados em repouso estão localizados na região que necessita. Pode configurar Google Cloud serviços de armazenamento de objetos e ficheiros para satisfazer os seus requisitos

Cloud Storage

Pode criar contentores do Cloud Storage que cumpram as restrições de localidade.

Além das funcionalidades abordadas na secção do Cloud Storage do artigo Elementos básicos de recuperação de desastres, quando cria a arquitetura para RD para cargas de trabalho restritas à localidade, considere se a redundância entre regiões é um requisito: os objetos armazenados em várias regiões e duas regiões são armazenados em, pelo menos, duas áreas geograficamente separadas, independentemente da respetiva classe de armazenamento. Esta redundância garante a máxima disponibilidade dos seus dados, mesmo durante interrupções em grande escala, como catástrofes naturais. As regiões duplas alcançam esta redundância através da utilização de um par de regiões à sua escolha. As multirregiões alcançam esta redundância através da utilização de qualquer combinação de centros de dados na multirregião especificada, que pode incluir centros de dados que não estão explicitamente listados como regiões disponíveis.

A sincronização de dados entre os contentores ocorre de forma assíncrona. Se precisar de um elevado grau de confiança de que os dados foram escritos numa região alternativa para cumprir os valores de RTO e RPO, uma estratégia consiste em usar dois contentores de região única. Em seguida, pode escrever o objeto de forma dupla ou escrever num contentor e fazer com que o Cloud Storage o copie para o segundo contentor.

Estratégias de mitigação de região única quando usa o Cloud Storage

Se os seus requisitos restringirem a utilização de uma única região, não pode implementar uma arquitetura redundante em localizações geográficas apenas com o Google Cloud . Neste cenário, considere usar uma ou mais das seguintes técnicas:

  • Adote uma estratégia híbrida ou de várias nuvens. Esta abordagem permite-lhe escolher outra solução na nuvem ou no local na mesma área geográfica que a sua regiãoGoogle Cloud . Pode armazenar cópias dos seus dados em contentores do Cloud Storage no local ou, em alternativa, usar o Cloud Storage como destino dos seus dados de cópia de segurança.

    Para usar esta abordagem, faça o seguinte:

    • Certifique-se de que os requisitos de distância são cumpridos.
    • Se estiver a usar a AWS como o seu outro fornecedor de nuvem, consulte o guia de interoperabilidade do Cloud Storage para saber como configurar o acesso ao Amazon S3 através de Google Cloud ferramentas.
    • Para outras nuvens e soluções no local, considere soluções de código aberto, como o minIO e o Ceph, para fornecer um armazenamento de objetos no local.
    • Considere usar o Cloud Composer com o utilitário de linha de comandos gcloud storage para transferir dados de um local de armazenamento de objetos no local para o Cloud Storage.
    • Use o Serviço de transferência de dados no local para copiar dados armazenados no local para o Cloud Storage.

  • Implementar técnicas de encriptação. Se os seus requisitos de localidade permitirem a utilização de técnicas de encriptação como solução alternativa, pode usar contentores multirregionais ou birregionais.

Filestore

O Filestore oferece armazenamento de ficheiros gerido que pode implementar em regiões e zonas de acordo com os seus requisitos de restrição de localidade.

Bases de dados geridas

Cenários de recuperação de desastres para dados descreve métodos para implementar estratégias de cópia de segurança e recuperação para Google Cloud serviços de base de dados geridos. Além de usar estes métodos, também tem de considerar as restrições de localidade para cada serviço de base de dados gerido que usa na sua arquitetura. Por exemplo:

  • O Bigtable está disponível em localizações zonais numa região. As instâncias de produção têm um mínimo de dois clusters, que têm de estar em zonas únicas na região. A replicação entre clusters numa instância do Bigtable é gerida automaticamente pela Google. O Bigtable sincroniza os seus dados entre os clusters, criando uma cópia separada e independente dos seus dados em cada zona onde a sua instância tem um cluster. A replicação permite que o tráfego recebido mude automaticamente para outro cluster na mesma instância.

  • O BigQuery tem restrições de localidade que determinam onde os seus conjuntos de dados são armazenados. As localizações dos conjuntos de dados podem ser regionais ou multirregionais. Para garantir a resiliência durante um desastre regional, tem de fazer uma cópia de segurança dos dados noutra localização geográfica. No caso das multirregiões do BigQuery, recomendamos que evite fazer cópias de segurança para regiões no âmbito da multirregião. Se selecionar a multirregião da UE, exclui Zurique e Londres da configuração da multirregião. Para orientações sobre a implementação de uma solução de recuperação de desastres para o BigQuery que resolva o evento improvável de uma perda regional física, consulte o artigo Perda da região.

    Para compreender as implicações da adoção de configurações do BigQuery de região única ou multirregião, consulte a documentação do BigQuery.

  • Pode usar o Firestore para armazenar os seus dados do Firestore numa localização multirregional ou numa localização regional. Os dados numa localização multirregional funcionam numa configuração replicada multizonal e multirregional. Selecione uma localização multirregional se os seus requisitos de restrição de localidade o permitirem e quiser maximizar a disponibilidade e a durabilidade da sua base de dados. As localizações multirregionais podem resistir à perda de regiões inteiras e manter a disponibilidade sem perda de dados. Os dados numa localização regional funcionam numa configuração replicada em várias zonas.

  • Pode configurar o Cloud SQL para alta disponibilidade. Uma instância do Cloud SQL configurada para HA também é denominada instância regional e está localizada numa zona primária e secundária na região configurada. Numa instância regional, a configuração é composta por uma instância principal e uma instância de reserva. Certifique-se de que compreende o tempo de comutação por falha típico da instância principal para a instância de reserva.

    Se os seus requisitos o permitirem, pode configurar o Cloud SQL com réplicas entre regiões. Se ocorrer um desastre, a réplica de leitura numa região diferente pode ser promovida. Uma vez que as réplicas de leitura podem ser configuradas para HA antecipadamente, não precisam de passar por alterações adicionais após essa promoção para HA. Também pode configurar réplicas de leitura para terem as suas próprias réplicas entre regiões que podem oferecer proteção imediata contra falhas regionais após a promoção de réplicas.

  • Pode configurar o Spanner como regional ou de várias regiões. Para qualquer configuração regional, o Spanner mantém três réplicas de leitura/escrita, cada uma numa Google Cloud zona nessa região. Cada réplica de leitura/escrita contém uma cópia completa da sua base de dados operacional que consegue processar pedidos de leitura/escrita e só de leitura.

    O Spanner usa réplicas em zonas diferentes para que, se ocorrer uma falha numa única zona, a sua base de dados permaneça disponível. Uma implementação multirregional do Spanner oferece um ambiente consistente em várias regiões, incluindo duas regiões de leitura/escrita e uma região de testemunho que contém uma réplica de testemunho. Tem de validar se as localizações de todas as regiões cumprem os requisitos de restrição de localidade.

Compute Engine

Os recursos do Compute Engine são globais, regionais ou zonais. Os recursos do Compute Engine, como as instâncias de máquinas virtuais ou os discos persistentes zonais, são denominados recursos zonais. Outros recursos, como os endereços IP externos estáticos, são regionais. Os recursos regionais podem ser usados por quaisquer recursos nessa região, independentemente da zona, enquanto os recursos zonais só podem ser usados por outros recursos na mesma zona.

A colocação de recursos em zonas diferentes numa região isola esses recursos da maioria dos tipos de falhas de infraestrutura física e falhas de software de serviços de infraestrutura. Além disso, a colocação de recursos em regiões diferentes oferece um grau ainda maior de independência em caso de falha. Esta abordagem permite-lhe criar sistemas robustos com recursos distribuídos por diferentes domínios de falhas.

Para mais informações, consulte as regiões e as zonas.

Usar as instalações ou outra nuvem como um site de produção

Pode estar a usar uma Google Cloud região que impede a utilização de combinações de regiões duplas ou múltiplas para a sua arquitetura de recuperação de desastres. Para cumprir as restrições de localidade neste caso, considere usar o seu próprio centro de dados ou outra nuvem como o site de produção ou o site de alternativa.

Esta secção aborda os Google Cloud produtos otimizados para cargas de trabalho híbridas. As arquiteturas de DR que usam no local e Google Cloud são abordadas em Cenários de recuperação de desastres para aplicações.

GKE Enterprise

O GKE Enterprise é uma plataforma de aplicações híbrida e multinuvem aberta que ajuda a executar as suas cargas de trabalho baseadas em contentores em qualquer lugar de forma segura. Google Cloud O GKE Enterprise permite a consistência entre ambientes no local e na nuvem, o que lhe permite ter um modelo de funcionamento consistente e uma única vista dos seus clusters do Google Kubernetes Engine (GKE), independentemente de onde os está a executar.

Como parte da sua estratégia de DR, o GKE Enterprise simplifica a configuração e o funcionamento das arquiteturas de HA e de comutação por falha em ambientes diferentes (entre Google Cloud e nas instalações ou noutra nuvem). Pode executar os seus clusters do GKE Enterprise de produção no local e, se ocorrer um desastre, pode fazer a comutação por falha para executar as mesmas cargas de trabalho em clusters do GKE Enterprise noGoogle Cloud.

O GKE Enterprise no Google Cloud tem três tipos de clusters:

  • Cluster de zona única. Um cluster de zona única tem um único plano de controlo em execução numa zona. Este plano de controlo gere cargas de trabalho em nós que estão a ser executados na mesma zona.
  • Cluster multizonal. Um cluster multizonal tem uma única réplica do plano de controlo em execução numa única zona e tem nós em execução em várias zonas
  • Cluster regional. Os clusters regionais replicam os nós primários e os nós do cluster em várias zonas numa única região. Por exemplo, um cluster regional na região us-east1 cria réplicas do painel de controlo e dos nós em três zonas us-east1: us-east1-b, us-east1-c e us-east1-d.

Os clusters regionais são os mais resilientes a interrupções zonais.

Google Cloud VMware Engine

O Google Cloud VMware Engine permite-lhe executar cargas de trabalho do VMware na nuvem. Se as suas cargas de trabalho nas instalações forem baseadas no VMware, pode arquitetar a sua solução de recuperação de desastres para ser executada na mesma solução de virtualização que está a executar nas instalações. Pode selecionar a região que cumpre os requisitos de localidade.

Trabalhar em rede

Quando o seu plano de DR se baseia na movimentação de dados das instalações para a Google Cloud ou de outro fornecedor de nuvem para a Google Cloud, tem de abordar a sua estratégia de rede. Para mais informações, consulte a secção Transferir dados de e para Google Cloud do documento "Elementos básicos de recuperação de desastres".

VPC Service Controls

Ao planear a sua estratégia de recuperação de desastres, tem de garantir que os controlos de segurança que se aplicam ao seu ambiente de produção também se aplicam ao seu ambiente de comutação por falha. Ao usar os VPC Service Controls, pode definir um perímetro de segurança a partir de redes no local para os seus projetos no Google Cloud.

Os VPC Service Controls permitem uma abordagem de acesso sensível ao contexto para controlar os seus recursos na nuvem. Pode criar políticas de controlo de acesso detalhadas Google Cloud com base em atributos como a identidade do utilizador e o endereço IP. Estas políticas ajudam a garantir que os controlos de segurança adequados estão implementados nos seus ambientes no local e na nuvem. Google Cloud

O que se segue?