Migrar entre regiões do Google Cloud: projete ambientes resilientes de uma região no Google Cloud

Last reviewed 2023-12-08 UTC

Neste documento, ajudamos você a projetar ambientes resilientes de região única no Google Cloud. Este documento é útil se você planeja migrar um ambiente de região única ou se estiver avaliando a oportunidade de fazer isso no futuro e quiser saber como será o processo.

Este documento faz parte de uma série:

Este documento tem como objetivo fornecer orientações sobre como projetar ambientes resilientes de região única no Google Cloud e se concentra nos seguintes componentes de arquitetura:

A orientação neste documento pressupõe que você esteja projetando e implementando ambientes de região única. Se você usa um ambiente de região única agora, poderá migrar para um multirregional no futuro. Se você está pensando em fazer uma migração e evolução futura dos seus ambientes zonais e de região única para ambientes multirregionais, consulte Migrar entre regiões do Google Cloud: primeiros passos.

Propriedades de diferentes arquétipos de implantação

O Google Cloud fornece serviços em diferentes regiões ao redor do mundo. Cada região é uma área geográfica fisicamente independente que consiste em áreas de implantação chamadas de zonas. Para mais informações sobre regiões e zonas do Google Cloud, consulte Geografia e locais.

Ao projetar seu ambiente do Google Cloud, é possível escolher entre os seguintes arquétipos de implantação, apresentados em ordem crescente de confiabilidade e sobrecarga operacional:

  • Arquétipo zonal: você provisiona recursos do Google Cloud em uma única zona dentro de uma região e usa os serviços zonais quando eles estão disponíveis. Se os serviços zonais não estiverem disponíveis, use os serviços regionais.
  • Arquétipo de região única: você provisiona recursos do Google Cloud em várias zonas dentro de uma região e usa serviços regionais quando possível.
  • Arquétipo multirregional: você provisiona recursos do Google Cloud em várias zonas em diferentes regiões. Os recursos zonais são provisionados em uma ou mais zonas em cada região.

Os arquétipos de implantação anteriores têm propriedades de confiabilidade diferentes, e é possível usá-los para fornecer as garantias de confiabilidade que seu ambiente precisa. Por exemplo, um ambiente multirregional tem mais probabilidade de sobreviver a uma interrupção regional em comparação com um ambiente de região única ou zona. Para mais informações sobre as propriedades de confiabilidade de cada arquétipo de arquitetura, consulte Como usar zonas e regiões para alcançar confiabilidade e o Guia de confiabilidade da infraestrutura do Google Cloud.

Projetar, implementar e operar um ambiente baseado nesses arquétipos de implantação requer níveis diferentes de esforço devido às propriedades de custo e complexidade de cada arquétipo. Por exemplo, um ambiente zonal pode ser mais barato e mais fácil de projetar, implementar e operar em comparação com um ambiente regional ou multirregional. O esforço e o custo possivelmente menores do ambiente zonal se devem à sobrecarga adicional que você precisa gerenciar para coordenar cargas de trabalho, dados e processos que residem em diferentes regiões.

A tabela a seguir resume a distribuição de recursos, as propriedades de confiabilidade e a complexidade de cada arquétipo de arquitetura. Ela também descreve o esforço necessário para projetar e implementar um ambiente com base em cada um deles.

Nome do arquétipo de arquitetura Distribuição de recursos Ajuda a resistir Complexidade de design
Ambiente zonal Em uma única zona Falhas de recursos Requer coordenação dentro de uma única zona
Ambiente de região única Em várias zonas, em uma única região Falhas de recursos, interrupções zonais Requer coordenação entre várias zonas em uma única região
Ambiente multirregional Em várias zonas e regiões Falhas de recursos, falhas temporárias zonais, interrupções regionais, interrupções multirregionais Requer coordenação entre várias zonas, em diversas regiões

Escolher arquétipos de implantação para seus ambientes

Para escolher o arquétipo de arquitetura que melhor atende às suas necessidades, faça o seguinte:

  1. Defina os modelos de falha que você quer evitar.
  2. Avalie os arquétipos de implantação para determinar qual atende melhor às suas necessidades.

Definir modelos de falha

Para definir modelos de falha, considere as seguintes perguntas:

  • Quais componentes do seu ambiente precisam de modelos de falha? Os modelos de falha podem se aplicar a tudo que você provisiona ou implanta no Google Cloud. Um modelo de falha pode ser aplicado a um indivíduo ou a todos os recursos em uma zona ou região inteira. Recomendamos que você aplique um modelo de falha a tudo que forneça valor, como cargas de trabalho, dados, processos e qualquer recurso do Google Cloud.
  • Quais são os requisitos de alta disponibilidade, continuidade de negócios e recuperação de desastres para esses componentes? Cada componente do ambiente pode ter os próprios objetivos de nível de serviço (SLOs, na sigla em inglês) que definem os níveis de serviço aceitáveis para esse componente e os próprios requisitos de recuperação de desastres. Por exemplo, o SLA do Compute Engine indica que, se você precisar alcançar mais de 99,5% de tempo de atividade mensal, será necessário provisionar instâncias em várias zonas em uma única região. Para mais informações, consulte o Guia de planejamento de recuperação de desastres.
  • Quantos modelos de falha você precisa definir? Em um ambiente típico, nem todos os componentes precisam fornecer as mesmas garantias de confiabilidade. Se você oferece garantias de maior tempo de atividade e maior resiliência, geralmente é necessário fazer mais esforço e gastar mais recursos. Ao definir seus modelos de falha, recomendamos que você considere uma abordagem em que vários modelos de falha são definidos para cada componente, e não apenas um para todos os componentes. Por exemplo, cargas de trabalho críticas para os negócios geralmente precisam oferecer maior confiabilidade, mas pode ser aceitável oferecer garantias de confiabilidade menores para outras cargas de trabalho menos importantes.
  • De quantos recursos os modelos com falha precisam para se proteger contra falhas? Para se proteger contra os modelos de falha que você definiu, são gastos recursos como o tempo e o custo necessários para que as pessoas projetem, provisionem e configurem mecanismos de proteção e processos automatizados. Recomendamos que você avalie quantos recursos precisa proteger contra cada modelo de falha definido.
  • Como você vai detectar que uma falha está acontecendo? Ser capaz de detectar que uma falha está acontecendo ou está prestes a acontecer é fundamental para que você possa iniciar os processos de mitigação, recuperação e reconciliação. Por exemplo, é possível configurar o Google Cloud Observability para receber alertas sobre a queda de desempenho.
  • Como você pode testar os modelos de falha que está definindo? Ao definir modelos de falha, recomendamos que você pense em como testar continuamente cada modelo para verificar se ele protege efetivamente contra as falhas a que os modelos se destinam. Por exemplo, é possível injetar falhas nos ambientes ou, para avaliar a capacidade dos ambientes de tolerar falhas, adote a engenharia de caos.
  • Qual é o impacto esperado caso ocorra um modelo de falha específico? Para entender o impacto que uma falha pode ter nos seus negócios, recomendamos que, para cada modelo de falha, você estime as consequências de cada falha para a qual o modelo foi projetado. Esse entendimento é útil para estabelecer prioridades e ordens de recuperação para que você e seus processos lide com os componentes mais críticos primeiro.
  • Quanto tempo você espera que as falhas durem nos modelos de falha que você está definindo? A duração de uma falha pode afetar significativamente os planos de mitigação e recuperação. Portanto, ao definir modelos de falha, recomendamos considerar quanto tempo uma falha pode durar. Ao considerar quanto tempo uma falha pode durar, considere também quanto tempo leva para identificar uma falha, reconciliá-la e restaurar os recursos com falha.

Para mais considerações sobre modelos de falha e como projetar um plano de recuperação de desastres confiável, consulte Como arquitetar a recuperação de desastres para interrupções de infraestrutura em nuvem.

Avaliar arquétipos de implantação

Depois de definir os modelos de falha que você quer evitar, avalie os arquétipos de implantação para determinar o que é melhor para suas necessidades. Ao avaliar os arquétipos de implantação, considere as seguintes questões:

  • De quantos arquétipos de implantação você precisa? Não é necessário escolher apenas um arquétipo de arquitetura que se encaixe em todos os ambientes. Em vez disso, é possível implementar uma abordagem híbrida em que você escolhe vários arquétipos de implantação de acordo com as garantias de confiabilidade necessárias para se proteger contra os modelos de falha definidos. Por exemplo, se você definiu dois modelos de falha, um que requer um ambiente zonal e outro regional, é recomendável escolher arquétipos de implantação separados para se proteger contra cada modelo de falha. Se você escolher vários arquétipos de implantação, recomendamos avaliar a complexidade crescente de projetar, implementar e operar vários ambientes.
  • De quantos recursos você precisa para projetar e implementar ambientes com base nos arquétipos de implantação? Projetar e implementar qualquer tipo de ambiente requer recursos e esforço. Recomendamos que você avalie quantos recursos acha que precisará para projetar e implementar cada ambiente com base no arquétipo escolhido. Quando você tem uma compreensão completa de quantos recursos são necessários, pode equilibrar as compensações entre as garantias de confiabilidade que cada arquétipo de arquitetura oferece e o custo e a complexidade do design, implementando e operando ambientes com base nesses arquétipos.
  • Você espera migrar um ambiente baseado em um arquétipo de arquitetura para outro baseado em outro arquétipo? No futuro, é possível migrar cargas de trabalho, dados e processos de um ambiente do Google Cloud para outro ambiente. Por exemplo, é possível migrar de um ambiente zonal para um regional.
  • Os ambientes que você está projetando e implementando são essenciais para os negócios? Ambientes críticos para os negócios provavelmente precisam de mais garantias de confiabilidade. Por exemplo, é possível optar por projetar e implementar um ambiente multirregional para cargas de trabalho, dados e processos essenciais aos negócios e projetar um ambiente zonal ou regional para cargas de trabalho, dados e processos.
  • Você precisa dos recursos oferecidos por arquétipos de arquitetura específicos para determinados ambientes? Além das garantias de confiabilidade que cada arquétipo de arquitetura oferece, os arquétipos também oferecem diferentes garantias de escalonabilidade, proximidade geográfica, latência e localidade de dados. Recomendamos que você considere essas garantias ao escolher os arquétipos de implantação para seus ambientes.

Além dos aspectos técnicos dos modos de falha que você definiu seguindo as orientações anteriores, recomendamos que considere todos os requisitos não funcionais, como requisitos regulatórios, locais e de soberania. Esses requisitos podem restringir as opções disponíveis para você. Por exemplo, se você precisa atender aos requisitos regulamentares que determinam o uso de uma região específica, projete e implemente um ambiente de região única ou de zona nessa região.

Escolher uma região do Google Cloud para seu ambiente

Ao começar a projetar seus ambientes de região única, você precisa determinar a região que melhor se adapta aos requisitos de cada ambiente. As seções abaixo descrevem essas duas categorias de critérios de seleção:

  • Critérios funcionais. Esses critérios são sobre quais produtos do Google Cloud uma região específica oferece e se uma região específica atende à sua latência e proximidade geográfica com usuários e outros ambientes fora do Google Cloud. Por exemplo, se as cargas de trabalho e os dados tiverem requisitos de latência para seus usuários ou outros ambientes fora do Google Cloud, talvez seja necessário escolher a região mais próxima dos usuários ou outros ambientes para minimizar a latência.
  • Critérios não funcionais. Esses critérios são sobre os preços dos produtos associados a regiões específicas, requisitos de pegada de carbono e requisitos e regulamentações obrigatórios em vigor para sua empresa. Por exemplo, mercados altamente regulamentados, como bancos e setores públicos, têm requisitos muito rigorosos e específicos sobre localidade de dados e carga de trabalho e como compartilham a infraestrutura do provedor de nuvem com outros clientes.

Se você escolher uma região específica do Google Cloud agora, poderá migrar no futuro para diferentes regiões ou para um ambiente multirregional. Se você estiver pensando em migrar para outras regiões, consulte Migrar entre regiões do Google Cloud: primeiros passos.

Avaliar critérios funcionais

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

  • Quais são seus requisitos de proximidade geográfica? Ao escolher uma região do Google Cloud, talvez seja necessário colocar cargas de trabalho, dados e processos perto dos usuários ou dos seus ambientes fora do Google Cloud, como os ambientes no local. Por exemplo, se você estiver segmentando uma base de usuários concentrada em uma área geográfica específica, recomendamos escolher uma região do Google Cloud mais próxima dessa área. Escolher uma região do Google Cloud que melhor se adapte aos seus requisitos de proximidade geográfica permite que seus ambientes garantam menor latência e tempos de reação menores às solicitações dos usuários e dos seus ambientes fora do Google Cloud. Ferramentas como o painel de latência do Google Cloud e ferramentas não oficiais, como o GCPing e o Seletor de região do Google Cloud, podem fornecer uma ideia geral das características de latência das regiões do Google Cloud. No entanto, recomendamos que você faça uma avaliação abrangente para avaliar se as propriedades de latência atendem aos seus requisitos, cargas de trabalho, dados e processos.
  • Qual das regiões em que você quer usar oferece os produtos de que você precisa? Recomendamos que você avalie os produtos disponíveis em cada região do Google Cloud e quais regiões fornecem os serviços necessários para projetar e implementar seus ambientes. Para mais informações sobre quais produtos estão disponíveis em cada região e os respectivos cronogramas de disponibilidade, consulte Locais do Cloud. Além disso, alguns produtos podem não oferecer todos os recursos em todas as regiões em que estão disponíveis. Por exemplo, as regiões e zonas disponíveis para o Compute Engine oferecem tipos de máquina específicos em regiões específicas do Google Cloud. Para mais informações sobre os recursos que cada produto oferece em cada região, consulte a documentação do produto.
  • Os recursos necessários em cada região do Google Cloud estão dentro dos limites de cota por região? O Google Cloud usa cotas para restringir a quantidade de um determinado recurso compartilhado do Google Cloud que você pode usar. Algumas cotas são globais e se aplicam ao uso do recurso em qualquer lugar no Google Cloud, enquanto outras são regionais ou zonais e se aplicam ao uso do recurso em uma região específica do Google Cloud. Por exemplo, a maioria das cotas de uso de recursos do Compute Engine, como o número de máquinas virtuais que podem ser criadas, são regionais. Para mais informações sobre cotas e como aumentá-las, consulte Como trabalhar com cotas.

Avaliar critérios não funcionais

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

  • Você prefere uma pegada de carbono baixa? O Google Cloud investe continuamente na sustentabilidade e em energia livre de carbono nas regiões do Google Cloud, além de se comprometer com energia livre de carbono para todas as regiões da nuvem. As regiões do Google Cloud têm pegadas de carbono diferentes. Para informações sobre a pegada de carbono de cada região do Google Cloud e como incorporar energia livre de carbono à sua estratégia de localização, consulte Energia livre de carbono para regiões do Google Cloud.
  • Seus ambientes precisam atender a regulamentações específicas? Governos e entidades nacionais e supranacionais muitas vezes regulam de maneira restrita determinados mercados e áreas de negócios, como setores bancários e públicos. Esses regulamentos podem exigir que cargas de trabalho, dados e processos residam apenas em determinadas regiões geográficas. Por exemplo, talvez seja necessário atender aos requisitos de soberania de dados, operacionais e de software para garantir determinados níveis de controle e transparência em relação a cargas de trabalho e dados sensíveis em execução na nuvem. Recomendamos que você avalie seus requisitos regulatórios atuais e futuros ao escolher as regiões do Google Cloud para seus ambientes. Também é recomendável selecionar as regiões do Google Cloud que melhor se adaptam aos seus requisitos regulatórios.

Projetar e criar seus ambientes de região única

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

  1. Crie sua base no Google Cloud.
  2. Provisione e configure recursos de computação.
  3. Provisione e configure recursos de armazenamento de dados.
  4. Provisione e configure recursos de análise de dados.

Ao projetar seu ambiente, considere os seguintes princípios gerais de design:

  • Provisione recursos regionais. Muitos produtos do Google Cloud oferecem suporte ao provisionamento de recursos em várias zonas de uma região. Recomendamos que você provisione recursos regionais em vez de recursos zonais quando possível. Teoricamente, é possível provisionar recursos zonais em várias zonas em uma região e gerenciá-los por conta própria para alcançar uma confiabilidade maior. No entanto, essa configuração não se beneficiaria totalmente de todos os recursos de confiabilidade da infraestrutura do Google que sustenta os serviços do Google Cloud.
  • Verifique se os ambientes funcionam conforme o esperado com as suposições do modelo de falha. Ao projetar e implementar seus ambientes de região única, recomendamos que você verifique se eles atendem aos requisitos para se proteger contra os modelos de falha que você está considerando, antes de promover esses ambientes como parte do ambiente de produção. Por exemplo, é possível simular interrupções zonais para verificar se os ambientes de região única podem sobreviver com interrupção mínima.

Para princípios de design mais gerais para a criação de ambientes confiáveis em uma ou várias regiões e para informações sobre como o Google alcança melhor confiabilidade com serviços regionais e multirregionais, consulte Como arquitetar a recuperação de desastres para falhas na infraestrutura em nuvem: temas comuns.

Criar sua base no Google Cloud

Para criar a base dos ambientes de região única, consulte Migração para o Google Cloud: criar a base. A orientação neste documento visa criar uma base para migrar cargas de trabalho, dados e processos para o Google Cloud, mas também é aplicável à criação de uma base para ambientes de região única. Depois de ler o documento, continue lendo este.

Depois de construir sua base no Google Cloud, você vai projetar e implementar controles e limites de segurança. Essas medidas de segurança ajudam a garantir que cargas de trabalho, dados e processos permaneçam dentro das respectivas regiões. As medidas de segurança também ajudam a garantir que seus recursos não vazem nada para outras regiões devido a bugs, configurações incorretas ou ataques maliciosos.

Provisionar e configurar recursos de computação

Depois de criar a base para seus ambientes de região única, provisione e configure recursos de computação. As seções a seguir descrevem os produtos de computação do Google Cloud que oferecem suporte a implantações regionais.

Compute Engine

O Compute Engine é a infraestrutura como serviço do Google Cloud (IaaS). Ele usa a infraestrutura mundial do Google para oferecer máquinas virtuais e serviços relacionados aos clientes.

Os recursos do Compute Engine são zonais, como máquinas virtuais ou Persistent Disk zonal, regional, como endereços IP externos estáticos ou globais, como snapshots do Persistent Disk. Para mais informações sobre os recursos zonais, regionais e globais suportados pelo Compute Engine, consulte Recursos globais, regionais e zonais.

Para permitir melhor flexibilidade e gerenciamento de recursos dos recursos físicos, o Compute Engine separa as zonas dos recursos físicos. Para mais informações sobre essa abstração e como ela afeta você, consulte Zonas e clusters.

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

  • Grupos regionais gerenciados de instâncias (MIGs): As máquinas virtuais do Compute Engine são recursos zonais, portanto, ficarão indisponíveis em caso de uma interrupção zonal. Para atenuar esse problema, o Compute Engine permite criar MIGs regionais que provisionam máquinas virtuais em várias zonas em uma região automaticamente, de acordo com a demanda e a disponibilidade regional. Se as cargas de trabalho tiverem estado, também será possível criar MIGs regionais com estado para preservar dados e configurações com estado. Os MIGs regionais são compatíveis com a simulação de falhas zonais. Para informações sobre como simular uma falha zonal ao usar um MIG regional, consulte Simular uma interrupção de zona em um MIG regional. Para informações sobre como os MIGs regionais se comparam a outras opções de implantação, consulte Escolher uma estratégia de implantação do Compute Engine para sua carga de trabalho.
  • Formato de distribuição de destino. Os MIGs regionais distribuem máquinas virtuais de acordo com o formato de distribuição de destino. Para garantir que a distribuição da máquina virtual não seja diferente em mais de uma unidade entre duas zonas em uma região, recomendamos que você escolha o formato de distribuição EVEN ao criar MIGs regionais. Para informações sobre as diferenças entre formas de distribuição de destino, consulte Comparação de formas.
  • Modelos de instância. Para definir as máquinas virtuais a serem provisionadas, os MIGs usam um tipo de recurso global chamado modelos de instância. Embora os modelos de instância sejam recursos globais, eles podem se referir a recursos regionais ou zonais. Ao criar modelos de instância, recomendamos que você mencione recursos regionais em vez de recursos zonais quando possível. Se você usar recursos zonais, recomendamos avaliar o impacto do uso. Por exemplo, se você criar um modelo de instância que se refira a um volume do Persistent Disk disponível apenas em uma determinada zona, não será possível usar esse modelo em outras zonas, porque o volume do Persistent Disk não está disponível nessas outras zonas.
  • Configure o balanceamento de carga e o escalonamento. O Compute Engine oferece suporte ao tráfego de balanceamento de carga entre instâncias do Compute Engine e ao escalonamento automático para adicionar ou remover automaticamente máquinas virtuais de MIGs, de acordo com a demanda. Para aumentar a confiabilidade e a flexibilidade dos ambientes e evitar o fardo de gerenciamento de soluções autogerenciadas, recomendamos que você configure o balanceamento de carga e o escalonamento automático. Para mais informações sobre como configurar o balanceamento de carga e o escalonamento para o Compute Engine, consulte Balanceamento de carga e escalonamento.
  • Configurar reservas de recursos. Para garantir que seus ambientes tenham os recursos necessários quando você precisar deles, recomendamos que você configure reservas de recursos para fornecer garantia na aquisição de capacidade para os recursos zonais do Compute Engine. Por exemplo, se houver uma interrupção zonal, talvez seja necessário provisionar máquinas virtuais em outra zona para fornecer a capacidade necessária para compensar as que estão indisponíveis por causa da interrupção. As reservas de recursos garantem que você tenha os recursos disponíveis para provisionar as outras máquinas virtuais.
  • Use nomes DNS zonais. Para reduzir o risco de interrupções entre regiões, recomendamos o uso de nomes DNS zonais para identificar exclusivamente máquinas virtuais que usam nomes DNS nos seus ambientes. Por padrão, o Google Cloud usa nomes DNS zonais para máquinas virtuais do Compute Engine. Para mais informações sobre como o DNS interno do Compute Engine funciona, consulte DNS interno. Para facilitar uma migração futura nas regiões e tornar sua configuração mais sustentável, recomendamos que você considere os nomes DNS zonais como parâmetros de configuração que podem ser alterados no futuro.
  • Escolha as opções de armazenamento adequadas. O Compute Engine aceita várias opções de armazenamento para máquinas virtuais, como volumes de Persistent Disk e unidades de estado sólido (SSDs, na sigla em inglês) locais:
    • Os volumes dos discos permanentes são distribuídos em vários discos físicos e estão localizados independentemente das máquinas virtuais. Os discos permanentes podem ser zonais ou regionais. Os discos permanentes zonais armazenam dados em uma única zona, enquanto os discos permanentes regionais replicam dados em duas zonas diferentes. Ao escolher opções de armazenamento para os ambientes de região única, recomendamos que você escolha discos permanentes regionais, porque eles oferecem opções de failover se houver falhas zonais. Para mais informações sobre como reagir a falhas zonais ao usar discos permanentes regionais, consulte Opções de alta disponibilidade ao usar o Persistent Disk regional e Failover do Persistent Disk regional.
    • Os SSDs locais têm alta capacidade, mas armazenam dados somente até que uma instância seja interrompida ou excluída. Portanto, os SSDs locais são ideais para armazenar dados temporários, caches e dados que podem ser reconstruídos por outros meios. Os discos permanentes são dispositivos de armazenamento duráveis que podem ser acessados por máquinas virtuais, como discos físicos.
  • Projetar e implementar mecanismos de proteção de dados. Ao projetar seus ambientes de região única, recomendamos a implementação de mecanismos automatizados para proteger os dados em caso de eventos adversos, como falhas zonais, regionais ou multirregionais ou ataques deliberados por terceiros mal-intencionados. O Compute Engine oferece várias opções para proteger os dados. Use esses recursos de opções de dados como elementos básicos para projetar e implementar seus processos de proteção de dados.

GKE

O GKE ajuda você a implantar, gerenciar e escalonar cargas de trabalho conteinerizadas no Kubernetes. O GKE se baseia no Compute Engine. Portanto, as recomendações na seção anterior sobre o Compute Engine se aplicam parcialmente ao GKE.

Para aumentar a confiabilidade dos ambientes que usam o GKE, considere os seguintes pontos de design e recursos do GKE:

  • Use clusters regionais do GKE para aumentar a disponibilidade. O GKE aceita diferentes tipos de disponibilidade para os clusters, dependendo do tipo de cluster que você precisa. Os clusters do GKE podem ter um plano de controle zonal ou regional e podem ter nós executados em uma única zona ou em várias zonas dentro de uma região. Diferentes tipos de cluster também oferecem diferentes contratos de nível de serviço (SLAs). Para aumentar a confiabilidade dos seus ambientes, recomendamos que você escolha clusters regionais. Se você estiver usando o recurso do Autopilot do GKE, só vai poder provisionar clusters regionais.
  • Considere um ambiente de vários clusters. Implantar vários clusters do GKE pode aumentar a flexibilidade e as propriedades de disponibilidade do ambiente, aumentando a complexidade. Por exemplo, se você precisa usar um novo recurso do GKE que só pode ativar ao criar um cluster do GKE, é possível evitar inatividade e reduzir a complexidade da migração adicionando um novo cluster do GKE ao ambiente de vários clusters, implantando cargas de trabalho no novo cluster e destruindo o antigo. Para mais informações sobre os benefícios de um ambiente do GKE de vários clusters, consulte Casos de uso de vários clusters: Para ajudar a gerenciar a complexidade da migração, o Google Cloud oferece gerenciamento de frotas, um conjunto de recursos para gerenciar um grupo de clusters do GKE, a infraestrutura deles e as cargas de trabalho implantadas nesses clusters.
  • Configure o Backup para GKE. O Backup para GKE é um serviço regional para fazer backup de configurações e volumes de carga de trabalho em um cluster do GKE de origem e restaurá-lo em um cluster do GKE de destino. Para proteger a configuração da carga de trabalho e os dados contra possíveis perdas, recomendamos que você ative e configure o Backup para GKE. Para mais informações, consulte Visão geral do backup para GKE.

Cloud Run

O Cloud Run é uma plataforma de computação gerenciada para executar cargas de trabalho em contêineres. O Cloud Run usa serviços para fornecer a infraestrutura necessária para executar suas cargas de trabalho. Os serviços do Cloud Run são recursos regionais e são replicados em várias zonas na região em que estão. Ao implantar um serviço do Cloud Run, é possível escolher uma região. Em seguida, o Cloud Run escolhe automaticamente as zonas dentro dessa região para implantar instâncias do serviço. O Cloud Run equilibra automaticamente o tráfego entre instâncias de serviço e foi projetado para mitigar consideravelmente os efeitos de uma interrupção zonal.

VMware Engine

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

  • Provisione nuvens privadas do VMware Engine de vários nós. O VMware Engine oferece suporte ao provisionamento de pilhas VMware isoladas chamadas de 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 isolados e dedicados, e são configurados para eliminar pontos únicos de falha. O VMware Engine oferece suporte a nuvens privadas de nó único, mas recomendamos o uso de nuvens privadas de nó único para provas de conceito e testes. Para ambientes de produção, recomendamos que você use as nuvens privadas padrão de vários nós.
  • Provisionar nuvens privadas estendidas do VMware Engine. Uma nuvem privada estendida é uma nuvem privada de vários nós com nós distribuídos entre as zonas de uma região. Uma nuvem privada estendida protege seu ambiente contra interrupções zonais.

Para mais informações sobre os recursos de alta disponibilidade e redundância do VMware Engine, consulte Disponibilidade e redundância.

Provisionar e configurar recursos de armazenamento de dados

Depois de provisionar e configurar recursos de computação para ambientes de região única, você provisionará e configurará recursos para armazenar e gerenciar dados. As seções a seguir descrevem os produtos de armazenamento e gerenciamento de dados do Google Cloud que oferecem suporte a configurações regionais e multirregionais.

Cloud Storage

O Cloud Storage é um serviço para armazenar objetos, que são dados imutáveis, em buckets, que são contêineres básicos para armazenar seus dados. Ao criar um bucket, você seleciona o tipo de local do bucket que melhor atende aos seus requisitos de disponibilidade, regulamentação, entre outros. Os tipos de local têm garantias de disponibilidade diferentes. Para proteger os dados contra falhas e interrupções, o Cloud Storage torna seus dados redundantes em pelo menos duas zonas para buckets com um tipo de localização de região, em duas regiões para buckets que têm um tipo de local birregional e em duas ou mais regiões para buckets que têm um tipo de local multirregional. Por exemplo, se você precisar disponibilizar um bucket do Cloud Storage se houver interrupções zonais, provisione-o com um tipo de localização de região.

Para mais informações sobre como projetar mecanismos de desastre para dados armazenados no Cloud Storage e como o Cloud Storage reage a interrupções zonais e regionais, consulte Como arquitetar a recuperação de desastres para interrupções de infraestrutura em nuvem: Cloud Storage.

Filestore

O Filestore fornece servidores de arquivos totalmente gerenciados no Google Cloud que podem ser conectados a instâncias do Compute Engine, clusters do GKE e suas máquinas locais. O Filestore oferece vários níveis de serviço. Cada nível oferece recursos exclusivos de disponibilidade, escalonabilidade, desempenho, capacidade e recuperação de dados. Ao provisionar instâncias do Filestore, recomendamos escolher o nível Enterprise, porque ele oferece suporte a alta disponibilidade e redundância de dados em várias zonas em uma região. Instâncias em outros níveis são recursos zonais.

Bigtable

O Bigtable é um serviço de banco de dados totalmente gerenciado, de alto desempenho e alta escalonabilidade para grandes cargas de trabalho analíticas e operacionais. As instâncias do Bigtable são recursos zonais. Para aumentar a confiabilidade das instâncias, configure 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 houver uma falha temporária, o Bigtable fará o failover das solicitações automaticamente para outras instâncias disponíveis em que você replicava dados.

Para mais informações sobre como a replicação funciona no Bigtable, consulte Sobre a replicação e Como arquitetar a recuperação de desastres para interrupções da infraestrutura em nuvem: Bigtable.

Firestore

O Firestore é um banco de dados flexível e escalonável para desenvolvimento focado em dispositivos móveis, Web e servidores pelo Firebase e o Google Cloud. Ao provisionar um banco de dados do Firestore, você seleciona o local dele. Os locais podem ser multirregionais ou regionais e oferecem garantias de confiabilidade diferentes. Se um banco de dados tiver um local regional, ele vai replicar os dados em diferentes zonas dentro de uma região. Um banco de dados multirregional replica dados em mais de uma região.

Para informações sobre como a replicação funciona no Firestore e como ele reage a interrupções zonais e regionais, consulte Locais do Firestore e Como arquitetar a recuperação de desastres para falhas na infraestrutura em nuvem: Firestore

Memorystore

O Memorystore permite que você configure serviços de armazenamento de dados na memória seguros, escalonáveis e altamente disponíveis. Ele é compatível com back-ends de dados para o Redis e o Memcached.

Ao provisionar instâncias do Memorystore para Redis, você seleciona um nível de serviço para elas. O Memorystore para Redis é compatível com vários níveis de serviço de instância, e cada um deles oferece recursos exclusivos de disponibilidade, tamanho de nó e largura de banda. Ao provisionar uma instância do Memorystore para Redis, recomendamos que você escolha um nível Standard ou Standard com réplicas de leitura. As instâncias do Memorystore nesses dois níveis replicam automaticamente dados em várias zonas em uma região. Para mais informações sobre como o Memorystore para Redis alcança alta disponibilidade, consulte Alta disponibilidade para o Memorystore para Redis.

Ao provisionar as instâncias do Memorystore para Memcached, considere o seguinte:

  • Seleção de zona. Ao provisionar instâncias do Memorystore para Memcached, selecione a região em que você quer implantar a instância. Em seguida, é possível selecionar as zonas dessa região em que você quer implantar os nós dessa instância ou permitir que o Memorystore para Memcached distribua automaticamente os nós entre as zonas. Para posicionar as instâncias da maneira ideal e evitar problemas de provisionamento, como colocar todos os nós dentro da mesma zona, recomendamos que você permita que o Memorystore for Memcached distribua automaticamente os nós entre zonas dentro de uma região.
  • Replicação de dados entre zonas. As instâncias do Memorystore para Memcached não replicam dados entre zonas ou regiões. Para mais informações sobre como as instâncias do Memorystore para Memcached funcionam se houver interrupções zonais ou regionais, consulte Como arquitetar a recuperação de desastres para interrupções de infraestrutura em nuvem: Memorystore para Memcached.

Spanner

O Spanner é um banco de dados relacional totalmente gerenciado com escala ilimitada, consistência forte e disponibilidade de até 99,999%. Para usá-lo, provisione instâncias do Spanner. Ao provisionar instâncias do Spanner, considere o seguinte:

  • Configuração de instâncias. Uma configuração de instância define a colocação geográfica e a replicação dos bancos de dados em uma instância do Spanner. Ao criar uma instância do Spanner, você a configura como regional ou multirregional.
  • Replicação. O Spanner aceita a replicação automática no nível de bytes e a criação de réplicas de acordo com suas necessidades de disponibilidade, confiabilidade e escalonabilidade. É possível distribuir réplicas entre 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 em uma região. As instâncias com uma configuração multirregional replicam dados em diversas zonas em diversas regiões.
  • Como mover instâncias. O Spanner permite migrar uma instância de qualquer configuração para qualquer outra configuração sem causar inatividade ou interrupção nas garantias de transações durante a migração.

Para mais informações sobre a replicação do Spanner e sobre como o Spanner reage a interrupções zonais e regionais, consulte Replicação do Spanner e Como arquitetar a recuperação de desastres para infraestrutura em nuvem" de falhas temporárias: Spanner.

Provisionar e configurar recursos de análise de dados

Depois de provisionar e configurar os recursos de armazenamento de dados para ambientes de região única, faça o provisionamento e a configuração dos recursos de análise de dados. As seções a seguir descrevem os produtos de análise de dados do Google Cloud que oferecem suporte a configurações regionais.

BigQuery

O BigQuery é um data warehouse corporativo totalmente gerenciado que ajuda a gerenciar e analisar dados com recursos integrados, como aprendizado de máquina, análise geoespacial e business intelligence.

Para organizar e controlar o acesso a dados no BigQuery, você provisiona contêineres de nível superior chamados conjuntos de dados. Ao provisionar conjuntos de dados do BigQuery, considere o seguinte:

  • Local do conjunto de dados. Para selecionar o local do BigQuery em que você quer armazenar os dados, configure o local do conjunto de dados. Um local pode ser regional ou multirregional. Para qualquer um dos tipos de local, o BigQuery armazena cópias dos dados em duas zonas diferentes dentro do local selecionado. Não é possível alterar o local do conjunto de dados depois de criá-lo.
  • Planejamento para recuperação de desastres. O BigQuery é um serviço regional que lida com falhas zonais automaticamente, para computação e dados. No entanto, há determinados cenários que você precisa se planejar, como interrupções regionais. Recomendamos que você considere esses cenários ao projetar seus ambientes.

Para mais informações sobre o plano e os recursos de recuperação de desastres do BigQuery, consulte Noções básicas sobre confiabilidade: planejamento de desastres na documentação do BigQuery e Como arquitetar a recuperação de desastres para falhas temporárias na infraestrutura em nuvem: BigQuery

Dataproc

O Dataproc é um serviço gerenciado que permite aproveitar as ferramentas de dados de código aberto para processamento em lote, consultas, streaming e machine learning. O Dataproc se baseia no Compute Engine, portanto, as recomendações na seção anterior sobre o Compute Engine também se aplicam parcialmente ao Dataproc.

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

  • Posicionamento de zona automático. Ao criar um cluster, é possível especificar a zona em uma região em que você quer provisionar os nós dele ou permitir que o Posicionamento em zona automática do Dataproc selecione a zona automaticamente. Recomendamos que você use o posicionamento na zona automática, a menos que precise ajustar o posicionamento dos nós do cluster dentro da região.
  • Modo de alta disponibilidade. Ao criar um cluster, é possível ativar o modo de alta disponibilidade. Não é possível ativar o modo de alta disponibilidade depois de criar um cluster. Recomendamos que você ative o modo de alta disponibilidade se precisar que o cluster seja resiliente à falha de um único nó de coordenador ou a interrupções zonais parciais. Os clusters de alta disponibilidade do Dataproc são recursos zonais.

Para mais informações sobre como o Dataproc reage a interrupções zonais e regionais e como aumentar a confiabilidade dos clusters do Dataproc em caso de falhas, consulte Como arquitetar a recuperação de desastres para interrupções de infraestrutura em nuvem: Dataproc.

Dataflow

O Dataflow é um serviço totalmente gerenciado para executar pipelines de processamento de dados em lote e de streaming. Para usar o Dataflow, crie pipelines e, em seguida, execute jobs, que são instâncias desses pipelines, em nós de trabalho. Como jobs são recursos zonais, ao usar os recursos do Dataflow, considere o seguinte:

  • Endpoints regionais. Quando você cria um job, o Dataflow exige que você configure um endpoint regional. Ao configurar um endpoint regional para o job, você restringe o posicionamento de 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 de uma região ou na melhor zona de uma região, de acordo com o tipo de job. Com o Dataflow, é possível substituir o posicionamento zonal dos nós de trabalho, basta colocar todos eles na mesma zona em uma região. Para atenuar os problemas causados por interrupções zonais, recomendamos que você permita que o Dataflow selecione automaticamente o melhor posicionamento de zona, a menos que seja necessário colocar os nós de trabalho em uma zona específica.

Para mais informações sobre como o Dataproc reage a interrupções zonais e regionais e como aumentar a confiabilidade dos clusters do Dataproc em caso de falhas, consulte Como arquitetar a recuperação de desastres para interrupções de infraestrutura em nuvem: Dataflow.

Pub/Sub

O Pub/Sub é um serviço de mensagens assíncrono e escalonável que separa os serviços que produzem mensagens dos serviços que processam essas mensagens. O Pub/Sub organiza mensagens em tópicos. Os editores (serviços que produzem mensagens) enviam mensagens para tópicos, e os assinantes recebem mensagens deles. O Pub/Sub armazena cada mensagem em uma única região e as replica em pelo menos duas zonas dentro dessa região. Para mais informações, consulte Visão geral da arquitetura do Pub/Sub.

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

  • Endpoints globais e regionais: O Pub/Sub oferece suporte a endpoints globais e regionais para publicar mensagens. Quando um editor envia uma mensagem para o endpoint global, o Pub/Sub seleciona automaticamente a região mais próxima para processar essa mensagem. Quando um produtor envia uma mensagem para um endpoint regional, o Pub/Sub processa a mensagem nessa região.
  • Políticas de armazenamento de mensagens. O Pub/Sub permite configurar políticas de armazenamento de mensagens para restringir onde o Pub/Sub processa e armazena mensagens, independentemente da origem da solicitação e do endpoint usado pelo publisher para publicar a mensagem. Recomendamos que você configure políticas de armazenamento de mensagens para garantir que elas não saiam do ambiente de uma única região.

Para mais informações sobre como o Pub/Sub lida com interrupções zonais e regionais, consulte Como arquitetar a recuperação de desastres para interrupções de infraestrutura em nuvem: Pub/Sub.

Adaptar suas cargas de trabalho a ambientes de região única

Ao concluir o provisionamento e a configuração dos ambientes, pense em como tornar as cargas de trabalho mais resilientes a falhas zonais e regionais. Cada carga de trabalho pode ter os próprios requisitos e propriedades de disponibilidade e confiabilidade, mas há alguns princípios de design que podem ser aplicados e estratégias para melhorar sua postura geral de resiliência no caso improvável de falhas zonais e regionais. Ao projetar e implementar suas cargas de trabalho, considere o seguinte:

  • Implemente as práticas e os princípios da engenharia de confiabilidade do site (SRE). A automação e o monitoramento extensivo fazem parte dos princípios mais importantes da SRE. O Google Cloud fornece as ferramentas e os serviços profissionais para implementar a SRE e aumentar a resiliência e a confiabilidade dos ambientes e reduzir as tarefas repetitivas.
  • Projetar com foco em escalonabilidade e resiliência Ao projetar cargas de trabalho voltadas a ambientes de nuvem, recomendamos que você considere escalonabilidade e resiliência como requisitos inerentes que suas cargas de trabalho precisam respeitar. Para mais informações sobre esse tipo de design, consulte Padrões para aplicativos escalonáveis e resilientes.
  • Projetar para a recuperação de interrupções da infraestrutura em nuvem. As garantias de disponibilidade do Google Cloud são definidas pelo Contratos de nível de serviço do Google Cloud. No caso improvável de uma falha zonal ou regional, recomendamos que você projete suas cargas de trabalho para que sejam resilientes a falhas zonais e regionais.
  • Implemente a redução de carga e a degradação suave. Em caso de falhas na infraestrutura em nuvem ou em outras dependências das cargas de trabalho, recomendamos que você projete suas cargas de trabalho de maneira que sejam resilientes. É necessário que as cargas de trabalho mantenham certos níveis de funcionalidade bem definidos, mesmo que ocorram falhas (degradação suave), além de poderem descartar parte da carga de acordo com a abordagem de condições de sobrecarga (redução de carga).
  • Planeje a manutenção regular. Quando você projeta seus processos de implantação e seus processos operacionais, recomendamos que você também pense em todas as atividades que precisa realizar como parte da manutenção regular dos seus ambientes. A manutenção regular precisa incluir atividades como a aplicação de atualizações e alterações de configuração às cargas de trabalho e às dependências delas, e como essas atividades podem afetar a disponibilidade dos ambientes. Por exemplo, é possível configurar uma política de manutenção do host para suas instâncias do Compute Engine.
  • Adote uma abordagem de desenvolvimento conduzida por testes. Ao projetar suas cargas de trabalho, recomendamos que você adote uma abordagem de desenvolvimento orientada por testes para garantir que elas se comportem conforme o esperado de todos os ângulos. Por exemplo, é possível testar se as cargas de trabalho e a infraestrutura em nuvem atendem aos requisitos funcionais, não funcionais e de segurança necessários.

A seguir

Colaboradores

Autores:

Outros colaboradores:

Para ver perfis não públicos do LinkedIn, faça login.