Migre entre regiões da Google Cloud: crie ambientes resilientes de região única na Google Cloud

Last reviewed 2024-12-08 UTC

Este documento ajuda a criar ambientes resilientes de região única no Google Cloud. Este documento é útil se estiver a planear migrar um ambiente de região única ou se estiver a avaliar a oportunidade de o fazer no futuro e quiser explorar como poderá ser.

Este documento faz parte de uma série:

Este documento tem como objetivo fornecer orientações sobre como conceber ambientes resilientes de região única no Google Cloude foca-se nos seguintes componentes de arquitetura:

As orientações neste documento pressupõem que está a conceber e implementar ambientes de região única. Se usar um ambiente de região única agora, no futuro, pode migrar para um ambiente de várias regiões. Se estiver a considerar uma migração e uma evolução futuras dos seus ambientes zonais e de região única para ambientes de várias regiões, consulte o artigo Migrar entre Google Cloud regiões: introdução.

Propriedades de diferentes arquétipos de implementação

Google Cloud Os produtos são fornecidos em muitas regiões e zonas.

Quando cria o seu Google Cloud ambiente, pode escolher entre os seguintes arquétipos de implementação, apresentados por ordem crescente de fiabilidade e sobrecarga operacional:

  • Zonal: aprovisiona Google Cloud recursos numa única zona numa região e usa serviços zonais onde estão disponíveis. Se os serviços zonais não estiverem disponíveis, usa os serviços regionais.
  • Regional: aprovisiona Google Cloud recursos em várias zonas numa região e usa serviços regionais sempre que possível.
  • Multirregional: aprovisiona Google Cloud recursos em várias zonas em diferentes regiões. Os recursos zonais são aprovisionados numa ou mais zonas em cada região.
  • Global: aprovisiona Google Cloud recursos em várias zonas em diferentes regiões em todo o mundo. Os recursos zonais são aprovisionados numa ou mais zonas em cada região.

Os arquétipos de implementação anteriores têm propriedades de fiabilidade diferentes e pode usá-los para fornecer as garantias de fiabilidade de que o seu ambiente precisa. Por exemplo, é mais provável que um ambiente multirregional sobreviva a uma interrupção regional em comparação com um ambiente zonal ou de região única. Para mais informações sobre as propriedades de fiabilidade de cada arquétipo de implementação, consulte o artigo Como tirar partido das zonas e das regiões para alcançar a fiabilidade e o Google Cloud guia de fiabilidade da infraestrutura.

A conceção, a implementação e a operação de um ambiente com base nestes arquétipos de implementação requerem diferentes níveis de esforço devido às propriedades de custo e complexidade de cada arquétipo de implementação. Por exemplo, um ambiente zonal pode ser mais barato e fácil de conceber, implementar e operar em comparação com um ambiente regional ou multirregional. O esforço e o custo potencialmente inferiores do ambiente zonal devem-se à sobrecarga adicional que tem de gerir para coordenar cargas de trabalho, dados e processos que residem em regiões diferentes.

A tabela seguinte resume a distribuição de recursos, as propriedades de fiabilidade e a complexidade de cada arquétipo de implementação. Também descreve o esforço necessário para conceber e implementar um ambiente com base em cada uma delas.

Nome do arquétipo de implementação Distribuição de recursos Ajuda a resistir Complexidade do design
Ambiente zonal Numa única zona Falhas de recursos Requer coordenação dentro de uma única zona
Ambiente de região única Em várias zonas, numa única região Falhas de recursos, interrupções zonais Requer coordenação em várias zonas numa única região
Ambiente multirregional Em várias zonas, em várias regiões Falhas de recursos, interrupções zonais, interrupções regionais, interrupções multirregionais Requer coordenação em várias zonas e em várias regiões
Ambiente global Em várias zonas e regiões a nível global Falhas de recursos, interrupções zonais, interrupções regionais, interrupções multirregionais Requer coordenação em várias zonas e em várias regiões

Para mais informações acerca destes e de outros arquétipos de implementação, consulte os Google Cloud arquétipos de implementação.

Escolha arquétipos de implementação para os seus ambientes

Para escolher o arquétipo de implementação que melhor se adapta às suas necessidades, faça o seguinte:

  1. Defina os modelos de falhas contra os quais quer proteger-se.
  2. Avalie os arquétipos de implementação para determinar o que melhor se adequa às suas necessidades.

Defina modelos de falhas

Para definir modelos de falhas, considere as seguintes perguntas:

  • Que componentes do seu ambiente precisam de modelos de falhas? Os modelos de falhas podem aplicar-se a tudo o que aprovisionar ou implementar no Google Cloud. Um modelo de falha pode aplicar-se a um indivíduo ou pode aplicar um modelo de falha a todos os recursos numa zona ou região inteira. Recomendamos que aplique um modelo de falhas a tudo o que lhe oferece valor, como cargas de trabalho, dados, processos e qualquer recurso. Google Cloud
  • Quais são os seus requisitos de alta disponibilidade, continuidade de negócios e recuperação de desastres para estes componentes? Cada componente do seu ambiente pode ter os seus próprios objetivos do nível de serviço (SLOs) que definem os níveis de serviço aceitáveis para esse componente e os seus próprios requisitos de recuperação de desastres. Por exemplo, o SLA do Compute Engine indica que, se precisar de alcançar mais de 99,5% de tempo de atividade mensal, tem de aprovisionar instâncias em várias zonas numa única região. Para mais informações, consulte o Guia de planeamento de recuperação de desastres.
  • Quantos modelos de falhas precisa de definir? Num ambiente típico, nem todos os componentes têm de oferecer as mesmas garantias de fiabilidade. Se oferecer garantias de maior tempo de atividade e resiliência mais forte, normalmente, tem de despender mais esforço e recursos. Quando define os seus modelos de falhas, recomendamos que considere uma abordagem em que define vários modelos de falhas para cada componente e não apenas um para todos os seus componentes. Por exemplo, as cargas de trabalho críticas para a empresa precisam normalmente de oferecer uma fiabilidade mais elevada, embora possa ser aceitável oferecer garantias de fiabilidade inferiores para outras cargas de trabalho menos críticas.
  • De quantos recursos precisam os modelos de falhas para se protegerem contra falhas? Para se proteger contra os modelos de falhas que definiu, gasta recursos, como o tempo e o custo necessários para as pessoas conceberem, aprovisionarem e configurarem mecanismos de proteção e processos automáticos. Recomendamos que avalie quantos recursos precisa para se proteger contra cada modelo de falha que definir.
  • Como vai detetar que está a ocorrer uma falha? A capacidade de detetar que está a ocorrer ou vai ocorrer uma falha é fundamental para que possa iniciar processos de mitigação, recuperação e conciliação. Por exemplo, pode configurar o Google Cloud Observability para receber alertas sobre o desempenho degradado.
  • Como pode testar os modelos de falhas que está a definir? Quando define modelos de falhas, recomendamos que pense em como testar continuamente cada modelo para verificar se protege eficazmente contra as falhas a que os modelos se destinam. Por exemplo, pode injetar falhas nos seus ambientes ou, para avaliar a capacidade dos seus ambientes de tolerar falhas, pode adotar a engenharia do caos.
  • Qual o impacto esperado se ocorrer um modelo de falha específico? Para compreender o impacto que uma falha pode ter na sua empresa, recomendamos que, para cada modelo de falha, estime as consequências de cada falha para a qual o modelo foi concebido. Esta compreensão é útil para estabelecer prioridades e ordens de recuperação, para que os seus processos e a sua equipa lidem primeiro com os componentes mais críticos.
  • Quanto tempo espera que as falhas durem nos modelos de falhas que está a definir? A duração de uma falha pode afetar significativamente os planos de mitigação e recuperação. Por isso, quando define modelos de falhas, recomendamos que tenha em conta quanto tempo uma falha pode durar. Quando considerar quanto tempo uma falha pode durar, considere também quanto tempo demora a: identificar uma falha, conciliar a falha e restaurar os recursos que falharam.

Para mais considerações sobre modelos de falhas e como criar um plano de recuperação de desastres fiável, consulte o artigo Arquitetar a recuperação de desastres para interrupções da infraestrutura na nuvem.

Avalie os arquétipos de implementação

Depois de definir os modelos de falhas contra os quais quer proteger-se, deve avaliar os arquétipos de implementação para determinar o que melhor se adequa às suas necessidades. Quando avaliar os arquétipos de implementação, considere as seguintes perguntas:

  • De quantos arquétipos de implementação precisa? Não tem de escolher apenas um arquétipo de implementação para se adequar a todos os seus ambientes. Em alternativa, pode implementar uma abordagem híbrida em que escolhe vários arquétipos de implementação de acordo com as garantias de fiabilidade de que precisa para se proteger contra os modelos de falhas que definiu. Por exemplo, se tiver definido dois modelos de falhas, um que requer um ambiente zonal e outro que requer um ambiente regional, pode optar por arquétipos de implementação separados para se proteger contra cada modelo de falhas. Se escolher vários arquétipos de implementação, recomendamos que avalie a complexidade potencialmente crescente da conceção, implementação e funcionamento de vários ambientes.
  • De quantos recursos precisa para conceber e implementar ambientes com base nos arquétipos de implementação? Conceber e implementar qualquer tipo de ambiente requer recursos e esforço. Recomendamos que avalie quantos recursos considera que vai precisar para conceber e implementar cada ambiente com base no arquétipo que escolher. Quando tem uma compreensão completa do número de recursos de que precisa, pode equilibrar os compromissos entre as garantias de fiabilidade que cada arquétipo de implementação oferece e o custo e a complexidade da criação, implementação e operação de ambientes com base nesses arquétipos.
  • Espera migrar um ambiente baseado num arquétipo de implementação para um ambiente baseado num arquétipo diferente? No futuro, pode migrar cargas de trabalho, dados e processos de um Google Cloud ambiente para um ambiente diferente Google Cloud. Por exemplo, pode migrar de um ambiente zonal para um ambiente regional.
  • Qual a importância crítica para a empresa dos ambientes que está a conceber e implementar? Os ambientes essenciais para a empresa precisam provavelmente de mais garantias de fiabilidade. Por exemplo, pode optar por conceber e implementar um ambiente de várias regiões para cargas de trabalho, dados e processos essenciais para a empresa, e conceber um ambiente zonal ou regional para cargas de trabalho, dados e processos menos críticos.
  • Precisa das funcionalidades oferecidas por determinados arquétipos de implementação para determinados ambientes? Além das garantias de fiabilidade que cada arquétipo de implementação oferece, os arquétipos também oferecem diferentes garantias de escalabilidade, proximidade geográfica, latência e localidade dos dados. Recomendamos que tenha em consideração essas garantias quando escolher os arquétipos de implementação para os seus ambientes.

Juntamente com os aspetos técnicos dos modos de falha que definiu seguindo as orientações anteriores, recomendamos que considere quaisquer requisitos não funcionais, como requisitos regulamentares, de localidade e de soberania. Esses requisitos podem restringir as opções disponíveis para si. Por exemplo, se precisar de cumprir requisitos regulamentares que exijam a utilização de uma região específica, tem de conceber e implementar um ambiente de região única ou um ambiente zonal nessa região.

Escolha uma Google Cloud região para o seu ambiente

Quando começar a criar os seus ambientes de região única, tem de determinar a região que melhor se adapta aos requisitos de cada ambiente. As secções seguintes descrevem estas duas categorias de critérios de seleção:

  • Critérios funcionais. Estes critérios referem-se aos Google Cloud produtos que uma determinada região oferece e se uma determinada região cumpre os seus requisitos de latência e proximidade geográfica dos utilizadores e outros ambientes externos Google Cloud. Por exemplo, se as suas cargas de trabalho e dados tiverem requisitos de latência para os seus utilizadores ou outros ambientes fora Google Cloud, pode ter de escolher a região mais próxima dos seus utilizadores ou outros ambientes para minimizar essa latência.
  • Critérios não funcionais. Estes critérios referem-se aos preços dos produtos associados a regiões específicas, aos requisitos de pegada de carbono e aos requisitos e regulamentos obrigatórios em vigor para a sua empresa. Por exemplo, os mercados altamente regulamentados, como o setor bancário e o setor público, têm requisitos muito rigorosos e específicos sobre a localização dos dados e das cargas de trabalho, e sobre a forma como partilham a infraestrutura do fornecedor de nuvem com outros clientes.

Se escolher uma Google Cloud região específica agora, no futuro pode migrar para diferentes regiões ou para um ambiente de várias regiões. Se estiver a considerar uma migração futura para outras regiões, consulte o artigo Migrar entre Google Cloud regiões: introdução.

Avalie os critérios funcionais

Para avaliar os critérios funcionais, considere as seguintes perguntas:

  • Quais são os seus requisitos de proximidade geográfica? Quando escolhe uma Google Cloud região, pode ter de colocar as suas cargas de trabalho, dados e processos perto dos seus utilizadores ou dos seus ambientes fora do Google CloudGoogle Cloud, como os seus ambientes no local. Por exemplo, se estiver a segmentar uma base de utilizadores concentrada numa área geográfica específica, recomendamos que escolha uma região mais próxima dessa área geográfica. Google Cloud Escolher uma Google Cloud região que se ajuste melhor aos seus requisitos de proximidade geográfica permite que os seus ambientes garantam uma latência mais baixa e tempos de reação mais baixos aos pedidos dos seus utilizadores e dos seus ambientes externos Google Cloud. As ferramentas como o Google Cloud painel de controlo de latência, e as ferramentas não oficiais, como o GCPing e o Google Cloud Region Picker podem dar-lhe uma ideia geral das caraterísticas de latência das Google Cloud regiões. No entanto, recomendamos que faça uma avaliação abrangente para determinar se as propriedades de latência se adequam aos seus requisitos, cargas de trabalho, dados e processos.
  • Quais das regiões que quer usar oferecem os produtos de que precisa? Recomendamos que avalie os produtos disponíveis em cada região e que regiões oferecem os serviços de que precisa para conceber e implementar os seus ambientes. Google Cloud Para mais informações sobre os produtos disponíveis em cada região e os respetivos prazos de disponibilidade, consulte Localizações da nuvem. Além disso, alguns produtos podem não oferecer todas as respetivas funcionalidades em todas as regiões onde estão disponíveis. Por exemplo, as regiões e zonas disponíveis para o Compute Engine oferecem tipos de máquinas específicos em Google Cloud regiões específicas. Para mais informações sobre as funcionalidades que cada produto oferece em cada região, consulte a documentação do produto.
  • Os recursos de que precisa em cada Google Cloud região estão dentro dos limites de quota por região? Google Cloud usa quotas para restringir a quantidade de um recurso Google Cloud partilhado que pode usar. Algumas quotas são globais e aplicam-se à sua utilização do recurso em qualquer parte do Google Cloud, enquanto outras são regionais ou zonais e aplicam-se à sua utilização do recurso numa região Google Cloud específica. Por exemplo, a maioria das quotas de utilização de recursos do Compute Engine, como o número de máquinas virtuais que pode criar, são regionais. Para mais informações sobre quotas e como ajustá-las, consulte a documentação das quotas do Google Cloud.

Avalie critérios não funcionais

Para avaliar os critérios não funcionais, considere as seguintes perguntas:

  • Prefere uma pegada de carbono baixa? Google Cloud investe continuamente na sustentabilidade e em energia sem carbono para Google Cloud regiões, e está empenhada em energia sem carbono para todas as regiões da nuvem. AsGoogle Cloud regiões têm pegadas de carbono diferentes. Para ver informações sobre a pegada de carbono de cada Google Cloud região Google Cloud e como incorporar energia sem carbono na sua estratégia de localização, consulte o artigo Energia sem carbono para Google Cloud regiões.
  • Os seus ambientes têm de cumprir regulamentos específicos? Os governos e as entidades nacionais e supranacionais regulamentam frequentemente de forma rigorosa determinados mercados e áreas empresariais, como a banca e o setor público. Estes regulamentos podem exigir que as cargas de trabalho, os dados e os processos residam apenas em determinadas regiões geográficas. Por exemplo, os seus ambientes podem ter de estar em conformidade com os requisitos de soberania de dados, operacionais e de software para garantir determinados níveis de controlo e transparência para dados confidenciais e cargas de trabalho em execução na nuvem. Recomendamos que avalie os requisitos regulamentares atuais e futuros ao escolher asGoogle Cloud regiões para os seus ambientes e selecione asGoogle Cloud regiões que melhor se adequam aos seus requisitos regulamentares.

Conceba e crie os seus ambientes de região única

Para conceber um ambiente de região única, faça o seguinte:

  1. Construa a sua base no Google Cloud.
  2. Aprovisionar e configurar recursos de computação.
  3. Aprovisione e configure recursos de armazenamento de dados.
  4. Aprovisionar e configurar recursos de estatísticas de dados.

Quando criar o seu ambiente, considere os seguintes princípios gerais de criação:

  • Disponibilizar recursos regionais. Muitos Google Cloud produtos suportam o aprovisionamento de recursos em várias zonas numa região. Recomendamos que aprovisione recursos regionais em vez de recursos zonais sempre que possível. Teoricamente, pode aprovisionar recursos zonais em várias zonas numa região e geri-los autonomamente para alcançar uma maior fiabilidade. No entanto, essa configuração não tiraria totalmente partido de todas as funcionalidades de fiabilidade da infraestrutura da Google que suportam Google Cloud os serviços.
  • Verifique se os ambientes funcionam como esperado com as pressuposições do modelo de falhas. Quando concebe e implementa os seus ambientes de região única, recomendamos que verifique se esses ambientes cumprem os requisitos para se proteger contra os modelos de falhas que está a considerar, antes de promover esses ambientes como parte do seu ambiente de produção. Por exemplo, pode simular falhas zonais para verificar se os seus ambientes de região única podem sobreviver com uma interrupção mínima.

Para ver princípios de design mais gerais para criar ambientes de região única e multirregião fiáveis, e para ver informações sobre como a Google alcança uma melhor fiabilidade com serviços regionais e multirregionais, consulte o artigo Criar uma arquitetura de recuperação de desastres para interrupções da infraestrutura na nuvem: temas comuns.

Construa a sua base em Google Cloud

Para criar a base dos seus ambientes de região única, consulte o artigo Migrar para Google Cloud: planeie e crie a sua base. As orientações nesse documento destinam-se a criar uma base para migrar cargas de trabalho, dados e processos para o Google Cloud, mas também são aplicáveis para criar a base para os seus ambientes de região única. Depois de ler esse documento, continue a ler este documento.

Depois de criar a base no Google Cloud, concebe e implementa controlos e limites de segurança. Essas medidas de segurança ajudam a garantir que as suas cargas de trabalho, dados e processos permanecem nas respetivas regiões. As medidas de segurança também ajudam a garantir que os seus recursos não divulgam nada a outras regiões devido a erros, configurações incorretas ou ataques maliciosos.

Aprovisione e configure recursos de computação

Depois de criar a base dos seus ambientes de região única, pode aprovisionar e configurar recursos de computação. As secções seguintes descrevem os Google Cloud produtos de computação que suportam implementações regionais.

Compute Engine

O Compute Engine é uma infraestrutura como serviço (IaaS). Google CloudUtiliza a infraestrutura mundial da Google para oferecer máquinas virtuais e serviços relacionados aos clientes.

Os recursos do Compute Engine são zonais, como as máquinas virtuais ou o Persistent Disk zonal; regionais, como os endereços IP externos estáticos; ou globais, como os instantâneos do Persistent Disk. Para mais informações sobre os recursos zonais, regionais e globais que o Compute Engine suporta, consulte o artigo Recursos globais, regionais e zonais.

Para permitir uma melhor flexibilidade e gestão de recursos físicos, o Compute Engine desvincula as zonas dos respetivos recursos físicos. Para mais informações sobre esta abstração e o que pode implicar para si, consulte Zonas e clusters.

Para aumentar a fiabilidade dos seus ambientes que usam o Compute Engine, considere o seguinte:

  • Grupos de instâncias geridas (MIGs) regionais. As máquinas virtuais do Compute Engine são recursos zonais e, por isso, ficam indisponíveis em caso de uma interrupção zonal. Para mitigar este problema, o Compute Engine permite-lhe criar GIGs regionais que aprovisionam máquinas virtuais em várias zonas numa região automaticamente, de acordo com a procura e a disponibilidade regional.

    Se as suas cargas de trabalho forem com estado, também pode criar MIGs com estado regionais para preservar os dados e as configurações com estado. Os MIGs regionais suportam a simulação de falhas zonais. Para ver informações sobre como simular uma falha zonal quando usa um MIG regional, consulte o artigo Simule uma indisponibilidade de zona para um MIG regional. Para informações sobre a comparação dos MIGs regionais com outras opções de implementação, consulte o artigo Escolha uma estratégia de implementação do Compute Engine para a sua carga de trabalho.

  • Forma de distribuição alvo. Os GIGs regionais distribuem máquinas virtuais de acordo com a forma de distribuição de destino. Para garantir que a distribuição de máquinas virtuais não difere em mais de uma unidade entre duas zonas numa região, recomendamos que escolha o formato de distribuição EVEN quando criar MIGs regionais. Para obter informações sobre as diferenças entre as formas de distribuição de destino, consulte o artigo Comparação de formas.

  • Modelos de instâncias. Para definir as máquinas virtuais a aprovisionar, os MIGs usam um tipo de recurso global denominado modelos de instâncias. Embora os modelos de instâncias sejam recursos globais, podem referenciar recursos zonais ou regionais. Quando criar modelos de instâncias, recomendamos que faça referência a recursos regionais em vez de recursos zonais, sempre que possível. Se usar recursos zonais, recomendamos que avalie o impacto da respetiva utilização. Por exemplo, se criar um modelo de instância que faça referência a um volume de disco persistente que só esteja disponível numa determinada zona, não pode usar esse modelo noutras zonas porque o volume de disco persistente não está disponível nessas outras zonas.

  • Configure o balanceamento de carga e o escalonamento. O Compute Engine suporta o balanceamento de carga do tráfego entre instâncias do Compute Engine e suporta a escala automática para adicionar ou remover automaticamente máquinas virtuais de GIGs, de acordo com a procura. Para aumentar a fiabilidade e a flexibilidade dos seus ambientes, e para evitar o encargo de gestão das soluções autogeridas, recomendamos que configure o equilíbrio de carga e o dimensionamento automático. Para mais informações sobre a configuração do equilíbrio de carga e do dimensionamento do Compute Engine, consulte o artigo Equilíbrio de carga e dimensionamento.

  • Configure as reservas de recursos. Para garantir que os seus ambientes têm os recursos necessários quando precisa deles, recomendamos que configure reservas de recursos para garantir a obtenção de capacidade para recursos do Compute Engine zonais. Por exemplo, se houver uma indisponibilidade zonal, pode ter de aprovisionar máquinas virtuais noutra zona para fornecer a capacidade necessária para compensar as que estão indisponíveis devido à indisponibilidade. As reservas de recursos garantem que tem os recursos disponíveis para aprovisionar as máquinas virtuais adicionais.

  • Use nomes DNS zonais. Para mitigar o risco de indisponibilidades entre regiões, recomendamos que use nomes DNS zonais para identificar de forma exclusiva as máquinas virtuais que usam nomes DNS nos seus ambientes. Google Cloud usa nomes DNS zonais para máquinas virtuais do Compute Engine por predefinição. Para mais informações sobre o funcionamento do DNS interno do Compute Engine, consulte o artigo DNS interno. Para facilitar uma migração futura entre regiões e tornar a sua configuração mais fácil de manter, recomendamos que considere os nomes DNS zonais como parâmetros de configuração que pode alterar no futuro.

  • Escolha opções de armazenamento adequadas. O Compute Engine suporta várias opções de armazenamento para as suas máquinas virtuais, como volumes de discos persistentes e SSDs locais:

    • Os volumes de discos persistentes são distribuídos por vários discos físicos e estão localizados independentemente das suas máquinas virtuais. Os discos persistentes podem ser zonais ou regionais. Os discos persistentes zonais armazenam dados numa única zona, enquanto os discos persistentes regionais replicam dados em duas zonas diferentes. Quando escolher opções de armazenamento para os seus ambientes de região única, recomendamos que escolha discos persistentes regionais, uma vez que lhe oferecem opções de comutação por falha se ocorrerem falhas zonais. Para mais informações sobre como reagir a falhas zonais quando usa discos persistentes regionais, consulte Opções de alta disponibilidade com o disco persistente regional e Abertura de falhas do disco persistente regional.
    • Os SSDs locais têm um débito elevado, mas armazenam dados apenas até uma instância ser parada ou eliminada. Por isso, os SSDs locais são ideais para armazenar dados temporários, caches e dados que pode reconstruir por outros meios. Os discos persistentes são dispositivos de armazenamento duradouros aos quais as máquinas virtuais podem aceder como discos físicos.

  • Conceber e implementar mecanismos de proteção de dados. Quando cria os seus ambientes de região única, recomendamos que implemente mecanismos automáticos para proteger os seus dados se ocorrerem eventos adversos, como falhas zonais, regionais ou multirregionais, ou ataques deliberados por terceiros maliciosos. O Compute Engine oferece várias opções para proteger os seus dados. Pode usar essas funcionalidades de opções de dados como bases para conceber e implementar os seus processos de proteção de dados.

GKE

O GKE ajuda a implementar, gerir e dimensionar cargas de trabalho contentorizadas no Kubernetes. O GKE baseia-se no Compute Engine, pelo que as recomendações na secção anterior sobre o Compute Engine aplicam-se parcialmente ao GKE.

Para aumentar a fiabilidade dos seus ambientes que usam o GKE, considere os seguintes pontos de design e funcionalidades do GKE:

  • Use clusters do GKE regionais para aumentar a disponibilidade. O GKE suporta diferentes tipos de disponibilidade para os seus clusters, consoante o tipo de cluster de que precisa. Os clusters do GKE podem ter um plano de controlo zonal ou regional e podem ter nós que são executados numa única zona ou em várias zonas numa região. Os diferentes tipos de clusters também oferecem diferentes contratos de nível de serviço (SLAs). Para aumentar a fiabilidade dos seus ambientes, recomendamos que escolha clusters regionais.

    Se estiver a usar a funcionalidade GKE Autopilot, só pode aprovisionar clusters regionais.

  • Considere um ambiente de vários clusters. A implementação de vários clusters do GKE pode aumentar a flexibilidade e as propriedades de disponibilidade do seu ambiente, ao custo de aumentar a complexidade. Por exemplo, se precisar de usar uma nova funcionalidade do GKE que só pode ativar quando cria um cluster do GKE, pode evitar o tempo de inatividade e reduzir a complexidade da migração adicionando um novo cluster do GKE ao seu ambiente de vários clusters, implementando cargas de trabalho no novo cluster e destruindo o cluster antigo. Para mais informações sobre as vantagens de um ambiente do GKE com vários clusters, consulte Exemplos de utilização com vários clusters. Para ajudar a gerir a complexidade da migração, o Anthos oferece a gestão de frotas, um conjunto de capacidades para gerir um grupo de clusters do GKE, a respetiva infraestrutura e as cargas de trabalho implementadas nesses clusters. Google Cloud

  • Configure a Cópia de segurança do GKE. A Cópia de segurança do GKE é um serviço regional para fazer cópias de segurança da configuração e dos volumes da carga de trabalho num cluster do GKE de origem e restaurá-los num cluster do GKE de destino. Para proteger a configuração da carga de trabalho e os dados de possíveis perdas, recomendamos que ative e configure a cópia de segurança para o GKE. Para mais informações, consulte o artigo Vista geral da Cópia de segurança do GKE.

Cloud Run

O Cloud Run é uma plataforma de computação gerida para executar cargas de trabalho em contentores. O Cloud Run usa serviços para lhe fornecer a infraestrutura para executar as suas cargas de trabalho. Os serviços do Cloud Run são recursos regionais e os serviços são replicados em várias zonas na região em que se encontram. Quando implementa um serviço do Cloud Run, pode escolher uma região. Em seguida, o Cloud Run escolhe automaticamente as zonas nessa região nas quais implementar instâncias do serviço. O Cloud Run equilibra automaticamente o tráfego entre instâncias de serviço e foi concebido para mitigar significativamente os efeitos de uma indisponibilidade zonal.

VMware Engine

O VMware Engine é um serviço totalmente gerido que lhe permite executar a plataforma VMware no Google Cloud. Para aumentar a fiabilidade dos seus ambientes que usam o VMware Engine, recomendamos o seguinte:

  • Aprovisione nuvens privadas do VMware Engine com vários nós. O VMware Engine suporta o aprovisionamento de stacks VMware isoladas denominadas nuvens privadas, e todos os nós que compõem uma nuvem privada residem na mesma região. Os nós de nuvem privada são executados em nós de hardware bare-metal dedicados e isolados, e estão configurados para eliminar pontos únicos de falha. O VMware Engine suporta nuvens privadas de nó único, mas recomendamos a utilização de nuvens privadas de nó único apenas para validações de conceitos e fins de teste. Para ambientes de produção, recomendamos que use as nuvens privadas predefinidas com vários nós.
  • Aprovisione nuvens privadas expandidas do VMware Engine. Uma nuvem privada expandida é uma nuvem privada com vários nós cujos nós estão distribuídos pelas zonas numa região. Uma nuvem privada expandida protege o seu ambiente contra falhas de energia zonais.

Para mais informações sobre as funcionalidades de alta disponibilidade e redundância do VMware Engine, consulte o artigo Disponibilidade e redundância.

Aprovisione e configure recursos de armazenamento de dados

Depois de aprovisionar e configurar recursos de computação para os seus ambientes de região única, aprovisiona e configura recursos para armazenar e gerir dados. As secções seguintes descrevem os Google Cloud produtos de armazenamento e gestão de dados que suportam configurações regionais e multirregionais.

Cloud Storage

O Cloud Storage é um serviço para armazenar objetos, que são partes de dados imutáveis, em contentores>, que são contentores básicos para armazenar os seus dados. Quando cria um contentor, seleciona o tipo de localização do contentor que melhor cumpre os seus requisitos de disponibilidade, regulamentares e outros. Os tipos de localizações têm garantias de disponibilidade diferentes. Para proteger os seus dados contra falhas e interrupções, o Cloud Storage torna os seus dados redundantes em, pelo menos, duas zonas para contentores com um tipo de localização de região, em duas regiões para contentores com um tipo de localização de duas regiões e em duas ou mais regiões para contentores com um tipo de localização de várias regiões. Por exemplo, se precisar de disponibilizar um contentor do Cloud Storage se houver interrupções zonais, pode aprovisioná-lo com um tipo de localização regional.

Para mais informações sobre como criar mecanismos de recuperação de desastres para dados armazenados no Cloud Storage e sobre como o Cloud Storage reage a interrupções zonais e regionais, consulte o artigo Criar arquiteturas de recuperação de desastres para interrupções da infraestrutura na nuvem: Cloud Storage.

Filestore

O Filestore oferece servidores de ficheiros totalmente geridos no Google Cloud que podem ser ligados a instâncias do Compute Engine, clusters do GKE e às suas máquinas no local. O Filestore oferece vários níveis de serviço. Cada nível oferece disponibilidade, escalabilidade, desempenho, capacidade e funcionalidades de recuperação de dados únicos. Quando aprovisiona instâncias do Filestore, recomendamos que escolha o nível Enterprise, uma vez que suporta a alta disponibilidade e a redundância de dados em várias zonas numa região. As instâncias que estão noutros níveis são recursos zonais.

Bigtable

O Bigtable é um serviço de base de dados totalmente gerido, de elevado desempenho e altamente escalável para grandes cargas de trabalho analíticas e operacionais. As instâncias do Bigtable são recursos zonais. Para aumentar a fiabilidade das suas instâncias, pode configurar o Bigtable para replicar dados em várias zonas na mesma região ou em várias regiões.

Quando a replicação está ativada, se ocorrer uma interrupção, o Bigtable transfere automaticamente os pedidos para outras instâncias disponíveis nas quais replicou os dados.

Para mais informações sobre o funcionamento da replicação no Bigtable, consulte Acerca da replicação e Arquitetar a recuperação de desastres para interrupções da infraestrutura na nuvem: Bigtable.

Firestore

O Firestore é uma base de dados flexível e escalável para o desenvolvimento de apps para dispositivos móveis, Web e servidores do Firebase e Google Cloud. Quando aprovisiona uma base de dados do Firestore, seleciona a respetiva localização. As localizações podem ser multirregionais ou regionais, e oferecem diferentes garantias de fiabilidade. Se uma base de dados tiver uma localização regional, replica os dados em diferentes zonas numa região. Uma base de dados multirregional replica os dados em mais do que uma região.

Para informações sobre o funcionamento da replicação no Firestore e sobre a forma como o Firestore reage a interrupções zonais e regionais, consulte os artigos Localizações do Firestore e Arquitetar a recuperação de desastres para interrupções da infraestrutura na nuvem: Firestore.

Memorystore

O Memorystore permite-lhe configurar serviços de armazenamento de dados na memória escaláveis, seguros e altamente disponíveis. Suporta back-ends de dados para Redis, Memcached, e Valkey.

Quando aprovisiona instâncias do Memorystore para Redis, seleciona um nível de serviço para essa instância. O Memorystore for Redis suporta vários níveis de serviço de instâncias, e cada nível oferece funcionalidades únicas de disponibilidade, tamanho do nó e largura de banda. Quando aprovisiona uma instância do Memorystore para Redis, recomendamos que escolha um nível padrão ou um nível padrão com réplicas de leitura. As instâncias do Memorystore nesses dois níveis replicam automaticamente os dados em várias zonas numa região.

Para mais informações sobre como o Memorystore for Redis alcança a alta disponibilidade, consulte o artigo Alta disponibilidade para o Memorystore for Redis.

Quando aprovisiona instâncias do Memorystore para Memcached, tenha em consideração o seguinte:

  • Seleção de zona. Quando aprovisiona instâncias do Memorystore para Memcached, seleciona a região na qual quer implementar a instância. Em seguida, pode selecionar as zonas nessa região onde quer implementar os nós dessa instância ou permitir que o Memorystore para Memcached distribua automaticamente os nós pelas zonas. Para posicionar de forma ideal as instâncias e evitar problemas de aprovisionamento, como posicionar todos os nós na mesma zona, recomendamos que permita que o Memorystore for Memcached distribua automaticamente os nós pelas zonas numa região.
  • Replicação de dados entre zonas. As instâncias do Memorystore for Memcached não replicam dados entre zonas ou regiões. Para mais informações sobre como as instâncias do Memorystore for Memcached funcionam se existirem indisponibilidades zonais ou regionais, consulte o artigo Arquitetar a recuperação de desastres para indisponibilidades da infraestrutura na nuvem: Memorystore for Memcached.

Quando aprovisiona instâncias do Memorystore for Valkey, escolhe opções de disponibilidade e fiabilidade. O Memorystore for Valkey suporta várias configurações, como instâncias zonais e multizonais. Para mais informações sobre a disponibilidade e a fiabilidade do Memorystore for Valkey, consulte o artigo Memorystore for Valkey: alta disponibilidade e réplicas.

Spanner

O Spanner é uma base de dados relacional totalmente gerida com dimensionamento ilimitado, consistência forte e uma disponibilidade de até 99,999%. Para usar o Spanner, aprovisiona instâncias do Spanner. Quando aprovisiona instâncias do Spanner, considere o seguinte:

  • Configuração da instância. Uma configuração de instância define o posicionamento geográfico e a replicação das bases de dados numa instância do Spanner. Quando cria uma instância do Spanner, configura-a como regional ou multirregional.
  • Replicação. O Spanner suporta a replicação automática ao nível do byte e a criação de réplicas de acordo com as suas necessidades de disponibilidade, fiabilidade e escalabilidade. Pode distribuir réplicas em várias regiões e ambientes. As instâncias do Spanner que têm uma configuração regional mantêm uma réplica de leitura/gravação para cada zona numa região. As instâncias com uma configuração multirregional replicam dados em várias zonas em várias regiões.
  • Mover instâncias. O Spanner permite-lhe mover uma instância de qualquer configuração de instância para qualquer outra configuração de instância sem provocar qualquer tempo de inatividade ou interrupção das garantias de transação durante a transferência.

Para mais informações sobre a replicação do Spanner e sobre a forma como o Spanner reage a interrupções zonais e regionais, consulte os artigos Replicação do Spanner e Arquitetar a recuperação de desastres para interrupções da infraestrutura na nuvem: Spanner.

Aprovisione e configure recursos de estatísticas de dados

Depois de aprovisionar e configurar recursos de armazenamento de dados para os seus ambientes de região única, aprovisiona e configura recursos de estatísticas de dados. As secções seguintes descrevem os Google Cloud produtos de estatísticas de dados que suportam configurações regionais.

BigQuery

BigQuery é um armazém de dados empresariais totalmente gerido que lhe permite gerir e analisar os seus dados com funcionalidades integradas, como aprendizagem automática, análise geoespacial e Business Intelligence.

Para organizar e controlar o acesso aos dados no BigQuery, aprovisiona contentores de nível superior denominados conjuntos de dados. Quando aprovisiona conjuntos de dados do BigQuery, tenha em atenção o seguinte:

  • Localização do conjunto de dados. Para selecionar a localização do BigQuery onde quer armazenar os seus dados, configure a localização do conjunto de dados. Uma localização pode ser regional ou de várias regiões. Para qualquer tipo de localização, o BigQuery armazena cópias dos seus dados em duas zonas diferentes na localização selecionada. Não pode alterar a localização do conjunto de dados depois de o criar.
  • Planeamento de desastres. O BigQuery é um serviço regional e processa automaticamente as falhas zonais para computação e dados. No entanto, existem determinados cenários para os quais tem de planear, como interrupções regionais. Recomendamos que tenha em consideração esses cenários ao conceber os seus ambientes.

Para mais informações sobre o planeamento de recuperação de desastres e as funcionalidades do BigQuery, consulte o artigo Compreender a fiabilidade: planeamento de desastres na documentação do BigQuery e o artigo Arquitetar a recuperação de desastres para interrupções da infraestrutura na nuvem: BigQuery.

Dataproc

O Dataproc é um serviço gerido que lhe permite tirar partido das ferramentas de dados de código aberto para processamento em lote, consultas, streaming e aprendizagem automática. O Dataproc baseia-se no Compute Engine, pelo que as recomendações na secção anterior sobre o Compute Engine aplicam-se também parcialmente ao Dataproc.

Para usar o Dataproc, crie clusters do Dataproc. Os clusters do Dataproc são recursos zonais. Quando cria clusters do Dataproc, considere o seguinte:

  • Posicionamento automático de zonas. Quando cria um cluster, pode especificar a zona numa região onde quer aprovisionar os nós do cluster ou permitir que o posicionamento automático de zonas do Dataproc selecione a zona automaticamente. Recomendamos que use o posicionamento automático de zonas, a menos que precise de ajustar o posicionamento de zonas dos nós do cluster na região.
  • Modo de alta disponibilidade. Quando cria um cluster, pode ativar o modo de alta disponibilidade. Não pode ativar o modo de alta disponibilidade depois de criar um cluster. Recomendamos que ative o modo de alta disponibilidade se precisar que o cluster seja resiliente à falha de um único nó coordenador ou a interrupções zonais parciais. Os clusters do Dataproc de alta disponibilidade são recursos zonais.

Para mais informações sobre como o Dataproc reage a interrupções zonais e regionais e como aumentar a fiabilidade dos seus clusters do Dataproc em caso de falhas, consulte o artigo Arquitetar a recuperação de desastres para interrupções da infraestrutura na nuvem: Dataproc.

Dataflow

O Dataflow é um serviço totalmente gerido para executar pipelines de processamento de dados por streaming e em lote. Para usar o Dataflow, cria pipelines do Dataflow e, em seguida, o Dataflow executa tarefas, que são instâncias desses pipelines, em nós de trabalho. Uma vez que os trabalhos são recursos zonais, quando usa recursos do Dataflow, deve ter em atenção o seguinte:

  • Pontos finais regionais. Quando cria uma tarefa, o Dataflow requer que configure um ponto final regional. Ao configurar um ponto final regional para a sua tarefa, restringe o posicionamento dos recursos de computação e dados a uma região específica.
  • Posicionamento zonal. O Dataflow distribui automaticamente os nós de trabalho por todas as zonas numa região ou na melhor zona numa região, de acordo com o tipo de tarefa. O Dataflow permite-lhe substituir o posicionamento zonal dos nós de trabalho, colocando todos os nós de trabalho na mesma zona numa região. Para mitigar os problemas causados por falhas de energia zonais, recomendamos que permita que o Dataflow selecione automaticamente o melhor posicionamento de zonas, a menos que precise de colocar os nós de trabalho numa zona específica.

Para mais informações sobre como o Dataproc reage a interrupções zonais e regionais e como aumentar a fiabilidade dos clusters do Dataproc em caso de falhas, consulte o artigo Criar uma arquitetura de recuperação de desastres para interrupções da infraestrutura na nuvem: Dataflow.

Pub/Sub

O Pub/Sub é um serviço de mensagens assíncrono e escalável que desassocia os serviços que produzem mensagens dos serviços que processam essas mensagens. O Pub/Sub organiza as mensagens em tópicos. Os publicadores (serviços que produzem mensagens) enviam mensagens para tópicos, e os subscritores recebem mensagens de tópicos. O Pub/Sub armazena cada mensagem numa única região e replica-a em, pelo menos, duas zonas nessa região. Para mais informações, consulte a vista geral da arquitetura do Pub/Sub.

Quando configurar o seu ambiente do Pub/Sub, considere o seguinte:

  • Pontos finais globais e regionais. O Pub/Sub suporta pontos finais globais e regionais para publicar mensagens. Quando um publicador envia uma mensagem para o ponto final global, o Pub/Sub seleciona automaticamente a região mais próxima para processar essa mensagem. Quando um produtor envia uma mensagem para um ponto final regional, o Pub/Sub processa a mensagem nessa região.
  • Políticas de armazenamento de mensagens. O Pub/Sub permite-lhe configurar políticas de armazenamento de mensagens para restringir onde o Pub/Sub processa e armazena mensagens, independentemente da origem do pedido e do ponto final que o publicador usou para publicar a mensagem. Recomendamos que configure políticas de armazenamento de mensagens para garantir que as mensagens não saem do seu ambiente de região única.

Para mais informações sobre como o Pub/Sub processa interrupções zonais e regionais, consulte o artigo Arquitetar a recuperação de desastres para interrupções da infraestrutura na nuvem: Pub/Sub.

Adapte as suas cargas de trabalho a ambientes de região única

Quando concluir o aprovisionamento e a configuração dos seus ambientes, tem de considerar como tornar as suas cargas de trabalho mais resilientes a falhas zonais e regionais. Cada carga de trabalho pode ter os seus próprios requisitos e propriedades de disponibilidade e fiabilidade, mas existem alguns princípios de design que pode aplicar e estratégias que pode adotar para melhorar a sua postura de resiliência geral no caso improvável de falhas zonais e regionais. Quando cria e implementa as suas cargas de trabalho, considere o seguinte:

  • Implementar práticas e princípios de Engenharia de Fiabilidade de sites (EFS). A automatização e a monitorização extensiva fazem parte dos princípios fundamentais da SRE. Google Cloud fornece as ferramentas e os serviços profissionais para implementar a SRE para aumentar a resiliência e a fiabilidade dos seus ambientes e para reduzir o trabalho repetitivo.
  • Crie em função da escalabilidade e resiliência. Quando cria cargas de trabalho destinadas a ambientes de nuvem, recomendamos que considere a escalabilidade e a resiliência como requisitos inerentes que as suas cargas de trabalho têm de respeitar. Para mais informações sobre este tipo de design, consulte o artigo Padrões para apps escaláveis e resilientes.
  • Crie a pensar na recuperação de falhas de infraestrutura na nuvem. Google Cloud As garantias de disponibilidade são definidas pelos Google Cloud Contratos de Nível de Serviço. No caso improvável de ocorrer uma falha zonal ou regional, recomendamos que conceba as suas cargas de trabalho de forma a serem resilientes a falhas zonais e regionais.
  • Implemente a redução de carga e a degradação suave. Se existirem falhas na infraestrutura na nuvem ou falhas noutras dependências das suas cargas de trabalho, recomendamos que conceba as suas cargas de trabalho de forma a serem resilientes. As suas cargas de trabalho devem manter determinados níveis de funcionalidade bem definidos, mesmo que existam falhas (degradação elegante), e devem conseguir reduzir alguma proporção da respetiva carga à medida que se aproximam das condições de sobrecarga (redução de carga).
  • Planeie a manutenção regular. Quando conceber os seus processos de implementação e processos operacionais, recomendamos que pense também em todas as atividades que tem de realizar como parte da manutenção regular dos seus ambientes. A manutenção regular deve incluir atividades como a aplicação de atualizações e alterações de configuração às suas cargas de trabalho e respetivas dependências, e como essas atividades podem afetar a disponibilidade dos seus ambientes. Por exemplo, pode configurar uma política de manutenção do anfitrião para as suas instâncias do Compute Engine.
  • Adote uma abordagem de desenvolvimento orientada por testes. Quando conceber as suas cargas de trabalho, recomendamos que adote uma abordagem de desenvolvimento orientado por testes para garantir que as cargas de trabalho se comportam como esperado de todos os ângulos. Por exemplo, pode testar se as suas cargas de trabalho e infraestrutura na nuvem cumprem os requisitos funcionais, não funcionais e de segurança de que necessita.

O que se segue?

Colaboradores

Autor: Marco Ferrari | Arquiteto de soluções na nuvem

Outros colaboradores: