Como arquitetar a recuperação de desastres para cargas de trabalho com restrição de localidade

Last reviewed 2022-06-10 UTC

Este documento discute como você pode usar o Google Cloud para arquitetar a recuperação de desastres (DR, na sigla em inglês) e atender aos requisitos específicos do local. Para alguns setores regulamentados, as cargas de trabalho precisam atender a esses requisitos. Nesse cenário, um ou mais dos seguintes requisitos se aplicam:

  • Os dados em repouso precisam ser restritos a um país especificado.
  • Os dados precisam ser processados no país em que residem.
  • As cargas de trabalho só podem ser acessadas em locais predefinidos.
  • Os dados precisam ser criptografados usando chaves que o cliente gerencia.
  • Se você estiver usando serviços de nuvem, cada serviço deverá fornecer no mínimo dois locais que sejam mutuamente redundantes. Para ver um exemplo de requisitos de redundância de local, consulte o Catálogo de critérios de conformidade de computação em nuvem (C5).

Este artigo é a última parte de uma série que discute a recuperação de desastres no Google Cloud. Nesta parte, apresentamos uma visão geral do processo de planejamento de DR: o que é necessário saber para projetar e implantar um plano de DR.

A série contém estas partes:

Terminologia

Antes de começar a arquitetar a DR para cargas de trabalho restritas por localidade, convém analisar a terminologia de localidade usada no Google Cloud.

O Google Cloud oferece serviços em regiões nas Américas, Europa, Oriente Médio e Ásia-Pacífico. Por exemplo, Londres (europe-west2) é uma região na Europa, e Oregon (us-west1) é uma região na América do Norte. Alguns grupos de produtos do Google Cloud agrupam várias regiões em um local multirregional acessível da mesma forma que você usaria uma região.

As regiões são divididas em zonas, em que você implanta determinados recursos do Google Cloud, como máquinas virtuais, clusters do Kubernetes ou bancos de dados Cloud SQL. Os recursos no Google Cloud são multirregionais, regionais ou zonais. Alguns recursos e produtos designados por padrão como multirregionais também podem ser restritos a uma região. Os diferentes tipos de recursos são explicados da seguinte maneira:

  • Os recursos multirregionais são projetados pelo Google Cloud para serem redundantes e distribuídos dentro e entre as regiões. Os recursos multirregional são resilientes à falha de uma única região.
  • Os recursos regionais são implantados de maneira redundante em várias zonas de uma região e são resilientes à falha de uma zona na região.
  • Os recursos zonais operam em uma única zona. Se uma zona estiver indisponível, todos os recursos zonais nela permanecerão indisponíveis até o serviço ser restaurado. Considere uma zona como um domínio de falha única. Você precisa arquitetar seus aplicativos para reduzir os efeitos de uma única zona se tornar indisponível.

A tabela a seguir mostra a relação atual entre regiões, zonas e locais na Europa.

Region Zonas Local
europe-north1 a, b, c Hamina, Finlândia
europe-west1 b, c, d St. Ghislain, Bélgica
europe-west2 a, b, c Londres, Inglaterra, Reino Unido
europe-west3 a, b, c Frankfurt, Alemanha
europe-west4 a, b, c Eemshaven, Holanda
europe-west6 a, b, c Zurique, Suíça

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

Como planejar a DR para cargas de trabalho com restrição de localidade

A abordagem que você adota para projetar seu aplicativo depende do tipo de carga de trabalho e dos requisitos de localidade que é preciso atender. Considere também por que você precisa atender a esses requisitos, já que o que você decide influencia diretamente sua arquitetura de DR.

Leia o Guia de planejamento de recuperação de desastres do Google Cloud. E ao considerar as cargas de trabalho com restrição de localidade, concentre-se nos requisitos discutidos nesta seção de planejamento.

Definir seus requisitos de localidade

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

  • Onde estão os dados em repouso? A resposta determina quais serviços você pode usar e os métodos de alta disponibilidade (HA, na sigla em inglês) e DR que podem ser usados para atingir os valores de RTO/RPO. Use a página Locais na nuvem para determinar quais produtos estão no escopo.
  • É possível usar técnicas de criptografia para reduzir o requisito? Se você puder reduzir os requisitos de localidade usando técnicas de criptografia por meio do Cloud External Key Manager e do Cloud Key Management Service, utilize os serviços multirregionais e birregionais e siga 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 de onde residem? Use produtos como o GKE Enterprise para fornecer um ambiente híbrido que atenda suas necessidades ou implementar controles específicos do produto, como o balanceamento de carga de instâncias do Compute Engine. em várias zonas em uma região. Use a restrição de local de recursos da política da organização para restringir onde os recursos podem ser implantados.

    Se os dados puderem ser processados fora de onde precisam estar em repouso, você poderá projetar as partes de "processamento" do aplicativo seguindo as orientações em Elementos básicos de recuperação de desastres e Cenários de recuperação de desastres para aplicativos.

    Configure um perímetro de VPC Security Controls para controlar quem pode acessar os dados e restringir os recursos que podem processá-los.

  • É possível usar mais de uma região? Se você puder usar mais de uma região, poderá usar muitas das técnicas descritas na série Recuperação de desastres. Verifique as restrições de multirregião e região para produtos do Google Cloud.

  • Você precisa restringir quem pode acessar seu aplicativo? O Google Cloud tem vários produtos e recursos que ajudam a restringir quem pode acessar seus aplicativos:

    • Identity-Aware Proxy (IAP). Verifica a identidade de um usuário e determina se ele tem permissão para acessar um aplicativo. A política da organização usa a restrição de compartilhamento restrito de domínio para definir os IDs permitidos do Cloud Identity ou do Google Workspace que são permitidos nas políticas do IAM.
    • Controles de localidade específicos do produto. Consulte cada produto que você quer usar na sua arquitetura para saber as restrições de localidade apropriadas. Por exemplo, use o gerenciador de configuração do GKE Enterprise para aplicar políticas específicas da região aos clusters do GKE gerenciados pelo GKE Enterprise. Se você estiver usando o Cloud Storage, crie buckets em regiões especificadas.

Identificar os serviços que você pode usar

Identifique quais serviços podem ser usados com base nos seus requisitos de localidade e granularidade. Projetar aplicativos sujeitos a restrições de localidade requer a compreensão de quais produtos podem ser restritos a qual região e quais controles podem ser aplicados para impor requisitos de restrição de local.

Identificar a granularidade regional do aplicativo e dos dados

Identifique a granularidade regional para seu aplicativo e seus dados respondendo a estas perguntas:

  • É possível usar serviços multirregionais no seu design? Usando serviços multirregionais, é possível criar arquiteturas resilientes altamente disponíveis.
  • O acesso ao seu aplicativo tem restrições de local? Use estes produtos do Google Cloud para ajudar a impor de onde seus aplicativos podem ser acessados:
  • Seus dados em repouso estão restritos a uma região específica? Se você usa serviços gerenciados, verifique se os serviços que você está usando podem ser configurados para que os 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 conjuntos de dados são armazenados e armazenados em backup.
  • A quais regiões você precisa restringir seu aplicativo? Alguns produtos do Google Cloud não têm restrições regionais. Use a página Locais do Cloud e as páginas específicas do produto para validar em quais regiões é possível usar o produto e quais recursos de mitigação, se houver, estão disponíveis para restringir seu aplicativo a uma região específica.

Como atender às restrições de localidade usando os produtos do Google Cloud

Nesta seção, detalhamos os recursos e as técnicas de mitigação para usar os produtos do Google Cloud como parte da estratégia de DR para cargas de trabalho com restrição de localidade. Recomendamos que você leia esta seção junto com os Elementos básicos da recuperação de desastres.

Políticas da organização

O serviço Política da organização oferece controle centralizado sobre seus recursos do Google Cloud. Com as políticas da organização, é possível configurar restrições em toda a hierarquia de recursos. Considere as seguintes restrições de política ao arquitetar as cargas de trabalho restritas por localidade:

  • Compartilhamento restrito ao domínio: por padrão, todas as identidades de usuário podem ser adicionadas às políticas do IAM. A lista de permitidos/negados precisa especificar uma ou mais identidades de clientes do Cloud Identity ou do Google Workspace. Se essa restrição estiver ativa, somente as identidades na lista de permitidos estarão qualificadas para inclusão nas políticas do IAM.

  • Recursos com restrição de local: essa restrição se refere ao conjunto de locais em que os recursos do Google Cloud baseados em local podem ser criados. As políticas dessa restrição podem especificar como locais permitidos ou negados qualquer uma das seguintes opções: multirregiões, como Ásia e Europa, regiões, como us-east1 ou europe-west1, ou zonas individuais, como europe-west1-b. Para ver uma lista de serviços compatíveis, consulte Serviços compatíveis com locais de recursos.

Encryption

Se seus requisitos de localidade de dados estiverem relacionados à restrição de quem pode acessar os dados, a implementação de métodos de criptografia poderá ser uma estratégia aplicável. Ao usar sistemas de gerenciamento de chaves externos para gerenciar as chaves fornecidas fora do Google Cloud, é possível implantar uma arquitetura multirregional para atender aos seus requisitos de localidade. Sem as chaves disponíveis, os dados não podem ser descriptografados.

O Google Cloud tem dois produtos que permitem o uso de chaves que você gerencia:

  • Cloud External Key Manager (Cloud EKM): o Cloud EKM permite criptografar dados no BigQuery e no Compute Engine com chaves de criptografia armazenadas e gerenciadas em um sistema de gerenciamento de chaves de terceiros implantado fora da infraestrutura do Google.

  • Chaves de criptografia fornecidas pelo cliente (CSEK): use a CSEK com o Cloud Storage e o Compute Engine. O Google usa sua chave para proteger as chaves geradas pelo Google que são usadas para criptografar e descriptografar seus dados.

    Se você fornecer uma chave de criptografia fornecida pelo cliente, o Google não armazenará permanentemente sua chave nos servidores do Google nem gerará sua chave. Em vez disso, forneça sua chave para cada operação. Ela será removida dos servidores do Google após a conclusão da operação.

Ao gerenciar sua própria infraestrutura de chaves, considere cuidadosamente os problemas de latência e confiabilidade e implemente os processos apropriados de alta disponibilidade e recuperação para seu gerenciador de chaves externo. Também é preciso entender os requisitos de RTO. As chaves são essenciais para gravar os dados. Portanto, o RPO não é a preocupação crítica porque nenhum dado pode ser gravado sem as chaves. A preocupação real é o RTO porque sem suas chaves, não é possível criptografar ou gravar dados com segurança.

Storage

Ao arquitetar a DR para cargas de trabalho restritas por localidade, você precisa garantir que os dados em repouso estejam localizados na região de que você precisa. Configurar os serviços de armazenamento de objetos e arquivos do Google Cloud para atender aos seus requisitos

Cloud Storage

É possível criar buckets do Cloud Storage que atendam às restrições de localidade.

Além dos recursos discutidos na seção do Cloud Storage do artigo Elementos básicos da recuperação de desastres, ao arquitetar para DR para cargas de trabalho com restrição de localidade, considere se redundância entre regiões é um requisito: objetos armazenados em multirregiões ebirregionais são armazenados em pelo menos duas áreas geograficamente separadas, independentemente da classe de armazenamento. Essa redundância garante a máxima disponibilidade dos seus dados, mesmo durante interrupções em grande escala, como desastres naturais. As regiões birregionais alcançam essa redundância usando um par de regiões escolhidas. Multirregiões conseguem redundância geográfica usando qualquer combinação de data centers na multirregião especificada, o que pode incluir data centers que não estão explicitamente listados como regiões disponíveis.

A sincronização de dados entre os buckets ocorre de forma assíncrona. Se você precisa de um alto grau de confiança de que os dados foram gravados em uma região alternativa para atender aos valores de RTO e RPO, uma estratégia é usar dois buckets de região única. Em seguida, grave duas vezes o objeto ou grave-o em um bucket e faça com que o Cloud Storage copie (rewriteTo) o segundo bucket.

Estratégias de mitigação de região única ao usar o Cloud Storage

Se os requisitos restringirem o uso de uma única região (por exemplo, Londres ou Zurique), você estará restrito a essa região e não poderá implementar uma arquitetura redundante em diferentes locais geográficos usando apenas o Google Cloud. Nesse cenário, use uma ou mais das seguintes técnicas:

  • Adote uma estratégia híbrida ou de várias nuvens. Essa abordagem permite escolher outra solução de nuvem ou local na mesma área geográfica da sua região do Google Cloud. É possível armazenar cópias dos dados nos buckets do Cloud Storage no local ou usar o Cloud Storage como destino para os dados de backup.

    Para usar essa abordagem, faça o seguinte:

    • Verifique se os requisitos de distância foram atendidos.
    • Se você estiver usando a AWS como seu outro provedor de nuvem, consulte o guia de interoperabilidade do Cloud Storage para saber como configurar o acesso ao Amazon S3 usando as ferramentas do Google Cloud.
    • Para outras soluções de nuvens e locais, considere soluções de código aberto, como minIO e Ceph, para fornecer um armazenamento de objetos no local.
    • Considere o uso de soluções de parceiros para fornecer um armazenamento de objetos no local.
    • Considere usar uma solução de parceiros para implementar fluxos de trabalho que permitem gravar dados no Cloud Storage e em um serviço de armazenamento de objetos alternativo de nuvem.
    • Considere usar o Cloud Composer com o utilitário de linha de comando gsutil para transferir dados de um armazenamento de objetos local para o Cloud Storage.
    • Use o Serviço de transferência de dados locais para copiar os dados armazenados no local para o Cloud Storage.

  • Implemente técnicas de criptografia. Se os requisitos de localidade permitirem o uso de técnicas de criptografia como solução alternativa, será possível usar buckets de várias regiões ou de região dupla.

Filestore

O Filestore fornece armazenamento de arquivos gerenciados que você pode implantar em regiões e zonas de acordo com seus requisitos de restrição de localidade.

Bancos de dados gerenciados

Cenários de recuperação de desastres para dados descreve métodos para implementar estratégias de backup e recuperação para serviços de bancos de dados gerenciados do Google Cloud. Além de usar esses métodos, considere as restrições de localidade para cada serviço de banco de dados gerenciado usado na arquitetura, por exemplo:

  • O Cloud Bigtable está disponível em locais por zona em uma região. As instâncias de produção têm no mínimo dois clusters, que precisam estar em zonas exclusivas na região. A replicação entre clusters em uma instância do Bigtable é gerenciada automaticamente pelo Google. O Bigtable sincroniza os dados entre os clusters, criando uma cópia separada e independente dos dados em cada zona em que a instância tem um cluster. A replicação possibilita que o tráfego de entrada faça o failover para outro cluster na mesma instância.

  • O BigQuery tem restrições de localidade que determinam onde os conjuntos de dados são armazenados. Os locais de conjuntos de dados podem ser regionais ou multirregionais. Para oferecer resiliência durante um desastre regional, é necessário fazer backup dos dados para outro local geográfico. No caso das multirregiões do BigQuery, recomendamos evitar o backup em regiões no escopo da multirregião. Se você selecionar a multirregião UE, excluirá a cidade de Zurique e de Londres da configuração multirregional. Para receber orientações sobre como implementar uma solução de DR para o BigQuery que aborda o evento improvável de uma perda regional física, consulte Perda da região.

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

  • Use o Firestore para armazenar dados do Firestore em um local multirregional ou regional. Os dados em um local multirregional operam em uma configuração replicada com várias zonas e regiões. Selecione um local multirregional se os requisitos de restrição de localidade permitirem e você quiser maximizar a disponibilidade e a durabilidade do seu banco de dados. Locais multirregionais podem suportar a perda de regiões inteiras e manter a disponibilidade sem perda de dados. Os dados em um local regional operam em uma configuração replicada com várias zonas.

  • Você pode configurar o Cloud SQL para alta disponibilidade. Uma instância do Cloud SQL configurada para alta disponibilidade também é chamada de instância regional e está localizada em uma zona primária e secundária na região configurada. Em uma instância regional, a configuração é composta por uma instância principal e uma instância de espera. Entenda o tempo de failover típico da instância principal para a instância de espera.

    Se seus requisitos permitirem, você poderá configurar o Cloud SQL com réplicas entre regiões. Se ocorrer um desastre, a réplica de leitura em uma região diferente poderá ser promovida. Como as réplicas de leitura podem ser configuradas para alta disponibilidade com antecedência, elas não precisam passar por mais alterações após essa promoção para alta disponibilidade. Também é possível configurar réplicas de leitura para ter as próprias réplicas entre regiões que podem oferecer proteção imediata contra falhas regionais após a promoção da réplica.

  • É possível configurar o Spanner como regional ou multirregional. Para qualquer configuração regional, o Spanner mantém três réplicas de leitura e gravação, cada uma em uma zona diferente do Google Cloud nessa região. Cada réplica de leitura e gravação contém uma cópia completa do seu banco de dados operacional que pode atender a solicitações de leitura/gravação e somente leitura.

    O Spanner usa réplicas em diferentes zonas para que, caso ocorra uma falha em uma única zona, o banco de dados permaneça disponível. Uma implantação multirregional do Spanner fornece um ambiente consistente em várias regiões, incluindo duas regiões de leitura e gravação e uma região testemunha contendo uma réplica testemunha. Você precisa validar se os locais de todas as regiões atendem aos seus 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 instâncias de máquina virtual ou discos permanentes zonais, são chamados de recursos zonais. Outros recursos, como endereços IP externos estáticos, são regionais. Os recursos regionais podem ser usados por quaisquer recursos nessa região, independentemente da zona, e os recursos zonais só podem ser usados por recursos na mesma zona.

Colocar recursos em diferentes zonas de uma região isola esses recursos da maioria dos tipos de falha de infraestrutura física e falhas de serviço de software da infraestrutura. Além disso, colocar recursos em regiões diferentes fornece um grau ainda mais elevado de independência em relação a falhas. Essa abordagem permite projetar sistemas robustos com recursos espalhados por diferentes domínios de falha.

Para mais informações, consulte Regiões e zonas.

Como usar o local ou outra nuvem como um site de produção

É possível usar uma região do Google Cloud que impeça o uso de combinações birregionais ou multirregionais em sua arquitetura de DR. Para atender às restrições de localidade, nesse caso, use seu próprio data center ou outra nuvem como o local de produção ou como o local de failover.

Nesta seção, discutiremos os produtos do Google Cloud otimizados para cargas de trabalho híbridas. As arquiteturas de DR que usam o local e o Google Cloud são discutidas nos cenários de recuperação de desastres para aplicativos.

GKE Enterprise

O GKE Enterprise é a plataforma aberta de aplicativos híbrida e de várias nuvens do Google Cloud que ajuda a executar com segurança suas cargas de trabalho baseadas em contêiner em qualquer lugar. O GKE Enterprise permite consistência entre ambientes locais e de nuvem, permitindo que você tenha um modelo operacional consistente e uma única visualização dos clusters do Google Kubernetes Engine (GKE), não importa onde você os esteja executando.

Como parte da estratégia de DR, o GKE Enterprise simplifica a configuração e a operação das arquiteturas de alta disponibilidade e failover em ambientes diferentes (entre o Google Cloud e o local ou outra nuvem). É possível executar os clusters de produção do GKE Enterprise no local e, se ocorrer um desastre, é possível fazer o failover para executar as mesmas cargas de trabalho nos clusters do GKE Enterprise no Google 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 controle em execução em uma zona. Esse plano de controle gerencia as cargas de trabalho em nós que estão em execução na mesma zona.
  • Cluster de várias zonas. Um cluster de várias zonas tem uma única réplica do plano de controle em execução em uma única zona e tem nós em execução em várias zonas.
  • Cluster regional. Os clusters regionais replicam as primárias e os nós do cluster em várias zonas em uma única região. Por exemplo, um cluster regional na região us-east1 cria réplicas do plano de controle e nós em três zonas de us-east1: us-east1-b, us-east1-c e us-east1-d.

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

Google Cloud VMware Engine

O Google Cloud VMware Engine permite executar cargas de trabalho VMware na nuvem. Se as cargas de trabalho locais forem baseadas em VMware, você poderá arquitetar a solução de DR para executar na mesma solução de virtualização executada no local. Você pode selecionar a região que atende aos seus requisitos de localidade.

Rede

Quando seu plano de DR é baseado na movimentação de dados do local para o Google Cloud ou de outro provedor de nuvem para o Google Cloud, é necessário resolver sua estratégia de rede. Para mais informações, consulte a seção Transferência de dados para o Google Cloud do documento "Elementos básicos da recuperação de desastres".

VPC Service Controls

Ao planejar sua estratégia de DR, você precisa garantir que os controles de segurança que se aplicam ao ambiente de produção também se estendam ao seu ambiente de failover. Ao usar o VPC Service Controls, você pode definir um perímetro de segurança de redes locais para seus projetos no Google Cloud.

O VPC Service Controls permite uma abordagem de acesso baseado no contexto para controlar seus recursos de nuvem. Você pode criar políticas de controle de acesso granulares no Google Cloud com base em atributos como identidade do usuário e endereço IP. Essas políticas ajudam a garantir que os controles de segurança apropriados estejam implantados nos seus ambientes locais e do Google Cloud.

A seguir