Como arquitetar a recuperação de desastres para interrupções de infraestrutura em nuvem

Last reviewed 2023-01-16 UTC

Este artigo faz parte de uma série sobre a recuperação de desastres (DR) no Google Cloud. Nesta parte, abordamos o processo para arquitetar cargas de trabalho usando o Google Cloud e a criação de elementos básicos resistentes a falhas na infraestrutura em nuvem.

A série contém estas partes:

• Guia de planejamento de recuperação de desastres
• Elementos básicos da recuperação de desastres
• Cenários de recuperação de desastres para dados
• Cenários de recuperação de desastres para aplicativos
• Como arquitetar a recuperação de desastres para cargas de trabalho com restrição de localidade
• Casos de uso da recuperação de desastres: aplicativos de análise de dados com restrição de localidade
• Como arquitetar a recuperação de desastres para interrupções de infraestrutura em nuvem (este documento)

Introdução

À medida que as cargas de trabalho são movidas para a nuvem pública, elas precisam traduzir o conhecimento da construção de sistemas resilientes locais para a infraestrutura de hiperescala de provedores de nuvem como o Google Cloud. Neste artigo, você conhecerá os conceitos padrão do setor sobre recuperação de desastres, como o objetivo de tempo de recuperação (RTO, na sigla em inglês) e o objetivo de ponto de recuperação (RPO, na sigla em inglês) da infraestrutura do Google Cloud.

Neste documento, seguimos um dos princípios fundamentais do Google para alcançar uma disponibilidade de serviço extremamente alta: planejamento para a falha. Embora o Google Cloud oferece serviços extremamente confiáveis, os desastres acontecem (desastres naturais, cortes de fibra e falhas imprevisíveis de infraestrutura) e causam interrupções. Com o planejamento para interrupções, os clientes do Google Cloud criam aplicativos com desempenho previsível durante esses eventos inevitáveis, usando os produtos do Google Cloud com mecanismos de DR "integrados".

A recuperação de desastres é um tema amplo que abrange muito mais do que apenas falhas de infraestrutura, como bugs de software ou corrupção de dados, e você terá um plano completo. No entanto, neste artigo, nos concentramos em uma parte de um plano de DR geral: como projetar aplicativos resilientes a interrupções de infraestrutura em nuvem. Especificamente, neste artigo abordamos:

1. a infraestrutura do Google Cloud, como os eventos de desastre se manifestam como interrupções do Google Cloud e como o Google Cloud é arquitetado para minimizar a frequência e o escopo das interrupções;
2. um guia de planejamento de arquitetura que oferece um framework para categorizar e projetar aplicativos com base nos resultados de confiabilidade pretendidos;
3. uma lista detalhada de produtos do Google Cloud que oferecem recursos de DR integrados que você talvez queira usar no aplicativo.

Para mais detalhes sobre o planejamento geral de DR e o uso do Google Cloud como componente na sua estratégia de DR local, consulte o guia de planejamento de recuperação de desastres. Além disso, mesmo que a alta disponibilidade seja um conceito estreitamente relacionado à recuperação de desastres, ela não é abordada neste artigo. Para mais detalhes sobre a arquitetura de alta disponibilidade, consulte Framework de arquitetura do Google Cloud.

Observação sobre a terminologia: neste artigo, nos referimos à disponibilidade ao discutirmos a capacidade de um produto ser acessado e usado de maneira significativa ao longo do tempo, enquanto a confiabilidade se refere a um conjunto de atributos, incluindo disponibilidade, mas também itens como durabilidade e exatidão.

Como o Google Cloud foi projetado para resiliência

Data centers do Google

Os data centers tradicionais dependem da maximização da disponibilidade de componentes individuais. Na nuvem, o escalonamento permite que operadores como o Google distribuam serviços em muitos componentes com tecnologias de virtualização e, portanto, excedem a confiabilidade tradicional dos componentes. Isso significa afastar a ideia de arquitetura de confiabilidade para longe dos muitos detalhes que antes preocupavam você. Em vez de se preocupar com os vários modos de falha dos componentes (como resfriamento e entrega de energia), é possível planejar no que diz respeito aos produtos do Google Cloud e as métricas de confiabilidade estabelecidas deles. Essas métricas refletem o risco de interrupção agregada de toda a infraestrutura. Isso permite que você se concentre muito mais no design, na implantação e nas operações de aplicativos, em vez de gerenciamento de infraestrutura.

O Google projeta a infraestrutura para atender às metas de disponibilidade agressivas, com base na nossa extensa experiência na criação e execução de data centers modernos. O Google é líder mundial no design de data centers. De energia a resfriamento a redes, cada tecnologia de data center tem as próprias redundâncias e mitigações, incluindo planos FMEA. Os data centers do Google são criados de uma maneira que equilibra muitos riscos diferentes e apresenta aos clientes um nível consistente de disponibilidade esperado para produtos do Google Cloud. O Google usa a própria experiência para modelar a disponibilidade da arquitetura geral do sistema físico e lógico. Isso garante que o design do data center atenda às expectativas. Os engenheiros do Google fazem grandes esforços do ponto de vista operacional para ajudar a garantir que essas expectativas sejam atendidas. A disponibilidade real medida normalmente excede nossas metas de design com bastante margem.

Ao refinar todos esses riscos e mitigações dos data centers em produtos voltados para o usuário, o Google Cloud livra você dessas responsabilidades operacionais e relacionadas ao projeto. Em vez disso, você se concentra na confiabilidade projetada nas regiões e zonas do Google Cloud.

Regiões e zonas

Os produtos do Google Cloud são fornecidos em um grande número de regiões e zonas. As regiões são áreas geográficas fisicamente independentes que contêm três ou mais zonas. As zonas representam grupos de recursos de computação física em uma região que têm um alto grau de independência entre si em termos de infraestrutura física e lógica. Elas fornecem conexões de rede de grande largura de banda e baixa latência para outras zonas da mesma região. Por exemplo, a região asia-northeast1 no Japão contém três zonas: asia-northeast1-a, asia-northeast1-b e asia-northeast1-c.

Os produtos do Google Cloud são divididos em recursos zonais, regionais ou multirregionais.

Os recursos zonais estão hospedados em uma única zona. Uma interrupção de serviço nessa zona pode afetar todos os recursos nela. Por exemplo, uma instância do Compute Engine é executada em uma zona única especificada. Se uma falha de hardware interrompe o serviço nessa zona, essa instância do Compute Engine fica indisponível durante a interrupção.

Os recursos regionais são implantados de maneira redundante em várias zonas em uma região. Isso proporciona mais confiabilidade em relação aos recursos de zona.

Os recursos multirregionais são distribuídos nas regiões e entre elas. Em geral, os recursos multirregionais têm maior confiabilidade do que os regionais. No entanto, nesse nível, os produtos precisam otimizar a disponibilidade, o desempenho e a eficiência dos recursos. Como resultado, é importante entender as vantagens e desvantagens de cada produto multirregional que você decide usar. Elas são documentadas com base em produtos específicos mais adiante neste documento.

Como aproveitar as zonas e regiões para aumentar a confiabilidade

Os SREs do Google gerenciam e escalonam produtos de usuários globais altamente confiáveis, como o Gmail e a Pesquisa, usando uma variedade de técnicas e tecnologias que aproveitam a infraestrutura de computação no mundo todo. Isso inclui redirecionar o tráfego para fora dos locais indisponíveis usando o balanceamento de carga global, executar várias réplicas em muitos locais ao redor do planeta e replicar dados entre os locais. Esses mesmos recursos estão disponíveis para clientes do Google Cloud em produtos como o Cloud Load Balancing, o Google Kubernetes Engine (GKE) e o Spanner.

O Google Cloud geralmente projeta produtos para oferecer os seguintes níveis de disponibilidade para zonas e regiões:

Recurso	Exemplos	Meta de design de disponibilidade	Inatividade implícita
Zonal	Disco permanente, Compute Engine	99,9%	8,75 horas/ano
Regional	Cloud Storage regional, disco permanente replicado, GKE regional	99,99%	52 minutos/ano

Observação: estas são as diretrizes de design. Consulte compromissos de nível de serviço do Google Cloud em Contratos de nível de serviço do Google Cloud.

Compare as metas de design de disponibilidade do Google Cloud com seu nível de inatividade aceitável para identificar os recursos adequados do Google Cloud. Mesmo que os designs tradicionais se concentrem na melhoria da disponibilidade no nível do componente para melhorar a disponibilidade do aplicativo resultante, os modelos na nuvem se concentram na composição dos componentes para atingir essa meta. Muitos produtos no Google Cloud usam essa técnica. Por exemplo, o Spanner oferece um banco de dados multirregional que compõe várias regiões para fornecer disponibilidade de 99,999%.

A composição é importante porque, sem ela, a disponibilidade do aplicativo não pode exceder a dos produtos do Google Cloud que você usa. Na verdade, a menos que seu aplicativo nunca falhe, ele terá uma disponibilidade menor que os produtos subjacentes do Google Cloud. No restante desta seção, você geralmente verá como é possível usar uma composição de produtos regionais e zonais para alcançar maior disponibilidade de aplicativos do que uma única zona ou região proporcionaria. Na próxima seção, você verá um guia prático sobre como aplicar esses princípios aos aplicativos.

Como planejar os escopos de interrupção de zona

As falhas de infraestrutura geralmente causam interrupções de serviço em uma única zona. Em uma região, as zonas foram projetadas para minimizar o risco de falhas correlacionadas com outras zonas. Uma interrupção de serviço em uma zona geralmente não afeta o serviço de outra zona na mesma região. Uma interrupção no escopo de uma zona não significa necessariamente que a zona inteira está indisponível. Ela apenas define o limite do incidente. É possível que uma interrupção de zona não tenha efeito tangível sobre recursos específicos nessa zona.

É uma ocorrência rara, mas também é essencial observar que várias zonas ainda sofrem uma interrupção correlacionada em algum momento de uma única região. Quando duas ou mais zonas sofrem uma interrupção, a estratégia de escopo de interrupção regional abaixo é aplicada.

Os recursos regionais foram desenvolvidos para ser resistentes a interrupções de zona, entregando o serviço com base em uma composição de várias zonas. Se uma das zonas que fazem o backup de um recurso regional for interrompida, o recurso ficará automaticamente disponível em outra zona. Verifique com atenção a descrição da capacidade do produto no apêndice para mais detalhes.

O Google Cloud oferece apenas alguns recursos por zona, como máquinas virtuais (VMs) do Compute Engine e um disco permanente. Se você planeja usar recursos zonais, precisará executar sua própria composição de recursos projetando, criando e testando o failover e a recuperação entre recursos zonais localizados em várias zonas. Algumas estratégias incluem:

• rotear seu tráfego rapidamente para máquinas virtuais em outra zona usando o Cloud Load Balancing quando uma verificação de integridade determinar que uma zona está enfrentando problemas;
• usar modelos de instância do Compute Engine e/ou grupos de instâncias gerenciadas para executar e escalonar instâncias de VM idênticas em várias zonas;
• usar um disco permanente regional para replicar dados de maneira síncrona em outra zona de uma região. Para mais detalhes, veja Opções de alta disponibilidade usando DPs regionais.

Como planejar os escopos de interrupção regionais

Uma interrupção regional é uma interrupção do serviço que afeta mais de uma zona em uma única região. Essas tarefas são maiores, interrupções com menos frequência e podem ser causadas por desastres naturais ou falhas de infraestrutura em larga escala.

Para um produto regional projetado para fornecer 99,99% de disponibilidade, uma interrupção ainda pode ser convertida a quase uma hora de inatividade para um produto específico a cada ano. Portanto, os aplicativos essenciais podem precisar ter um plano de DR de várias regiões em vigor se essa duração de interrupção for inaceitável.

Os recursos multirregional são projetados para serem resistentes a interrupções da região, fornecendo serviços de várias regiões. Conforme descrito acima, produtos multirregionais oferecem o equilíbrio entre latência, consistência e custo. A compensação mais comum é entre a replicação de dados síncrona e assíncrona. A replicação assíncrona oferece menor latência ao custo do risco de perda de dados durante uma interrupção. Por isso, é importante verificar a descrição da capacidade do produto no apêndice para mais detalhes.

Observação: no BigQuery, um local multirregional não fornece replicação entre regiões nem redundância regional. Os dados serão armazenados em uma única região na localização geográfica.

Se você quiser usar regional e permanecer resilientes às interrupções regionais, é preciso executar a própria composição de recursos projetando, criando e testando o failover e recuperação entre recursos regionais localizados em várias regiões. Além das estratégias por zona acima, que também podem ser aplicadas em várias regiões, considere:

• Os recursos regionais precisam replicar os dados para uma região secundária, para uma opção de Multi-Regional Storage, como o Cloud Storage, ou uma opção de nuvem híbrida, como o GKE Enterprise.
• Depois de realizar uma mitigação de interrupção regional, teste-a regularmente. Há poucas coisas piores do que imaginar que você está resistente a uma interrupção de região única e descobrir que esse não é o caso no momento.

Abordagem de resiliência e disponibilidade do Google Cloud

O Google Cloud supera regularmente as metas de design de disponibilidade, mas não presuma que este desempenho é a disponibilidade mínima para a qual é possível projetar. Em vez disso, você precisa selecionar as dependências do Google Cloud com destinos projetados para a confiabilidade pretendida do seu aplicativo. Assim, o tempo de inatividade do aplicativo mais o tempo de inatividade do Google Cloud fornecerá o resultado que você procura.

Um sistema bem projetado pode responder à pergunta: "O que acontece quando uma zona ou região tem uma interrupção de 1, 5, 10 ou 30 minutos?" Isso precisa ser considerado em muitas camadas, incluindo:

• O que meus clientes enfrentarão durante uma interrupção?
• Como detectarei uma interrupção?
• O que acontece com meu aplicativo durante uma interrupção?
• O que acontece com meus dados durante uma interrupção?
• O que acontece com meus outros aplicativos devido a uma interrupção (devido a dependências cruzadas)?
• O que preciso fazer para recuperar um problema depois que uma interrupção é resolvida? Quem faz isso?
• Quem preciso enviar notificações sobre uma interrupção e em que período?

Guia passo a passo para projetar a recuperação de desastres para aplicativos no Google Cloud

Nas seções anteriores, abordamos como o Google desenvolve a infraestrutura em nuvem, assim como algumas abordagens para lidar com interrupções zonais e regionais.

Nesta seção, você aprende a desenvolver um framework para aplicar o princípio da composição aos seus aplicativos com base nos resultados de confiabilidade pretendidos.

Os aplicativos do cliente no Google Cloud voltados para objetivos de recuperação de desastres, como RTO e RPO, precisam ser arquitetados para que as operações essenciais aos negócios, sujeitas ao RTO/RPO, tenham apenas dependências de componentes do plano de dados responsáveis. para processamento contínuo de operações do serviço. Em outras palavras, essas operações críticas para o cliente não podem depender das operações do plano de gerenciamento, que gerenciam o estado da configuração e a configuração de push para o plano de controle e o plano de dados.

Por exemplo, os clientes do Google Cloud que pretendem alcançar o RTO para operações essenciais para os negócios não devem depender de uma API de criação de VMs ou da atualização de uma permissão do IAM.

Etapa 1: coletar os requisitos atuais

A primeira etapa é definir os requisitos de disponibilidade para seus aplicativos. Neste momento, a maioria das empresas já tem algum nível de orientação de design, que pode ser desenvolvido internamente ou derivado de regulamentos ou outros requisitos legais. Essa orientação de design geralmente é codificada em duas métricas principais: objetivo de tempo de recuperação (RTO, na sigla em inglês) e objetivo de ponto de recuperação (RPO, na sigla em inglês). Em termos de negócios, o RTO se traduz como "Em quanto tempo depois de um desastre estarei pronto para começar a trabalhar". O RPO se traduz como "Quantos dados posso perder no caso de um desastre".

Antes, as empresas definiram os requisitos de RTO e de RPO para uma ampla variedade de eventos de desastre, de falhas de componentes a terremotos. Isso fazia sentido no mundo local, onde os planejadores precisavam mapear os requisitos de RTO/RPO por todo o software e a pilha de hardware. Na nuvem, você não precisa mais definir seus requisitos com esses detalhes, porque o provedor cuida disso. Em vez disso, é possível definir os requisitos de RTO e RPO em termos de escopo de perda (zonas ou regiões inteiras) sem ser específico sobre os motivos subjacentes. Para o Google Cloud, isso simplifica a coleta de requisitos em três cenários: uma interrupção de zona, uma interrupção regional ou a interrupção improvável de várias regiões.

Reconhecendo que nem todos os aplicativos têm a mesma criticalidade, a maioria dos clientes categoriza os aplicativos em níveis de gravidade nos quais um requisito de RTO/RPO específico pode ser aplicado. Quando reunidos, o RTO/RPO e a criticidade do aplicativo simplificam o processo de arquitetar um determinado aplicativo respondendo:

1. O aplicativo precisa ser executado em várias zonas na mesma região ou em várias zonas em várias regiões?
2. O aplicativo do Google Cloud depende de quais produtos?

Este é um exemplo de saída do exercício de coleta de requisitos:

RTO e RPO da Importância do aplicativo para exemplo de organização:

Importância do aplicativo	% de Apps	Aplicativos de exemplo	Interrupção de zona	Interrupção da região
Nível 1 (mais importante)	5%	Geralmente aplicativos globais ou externos voltados para o cliente, como pagamentos em tempo real e vitrines de comércio eletrônico.	RTO Zero RPO Zero	RTO Zero RPO Zero
Nível 2	35%	Normalmente, aplicativos regionais ou aplicativos internos importantes, como CRM ou ERP.	RTO de 15 min RPO de 15 minutos	RTO de 1 hora RPO de 1 hora
Nível 3 (menos importante)	60%	Normalmente os aplicativos para equipes ou departamentos, como back-office, reservas, viagens internas, contabilidade e RH.	RTO de 1 hora RPO de 1 hora	RTO 12h RPO de 12 horas

Etapa 2: mapeamento de recursos para produtos disponíveis

A segunda etapa é compreender os recursos de resiliência dos produtos do Google Cloud que os aplicativos usarão. A maioria das empresas revisa as informações de produtos relevantes e adiciona orientações sobre como modificar as arquiteturas para acomodar lacunas entre os recursos do produto e os requisitos de resiliência. Nesta seção, abordamos algumas áreas comuns e recomendações sobre limitações de dados e aplicativos neste espaço.

Como mencionado anteriormente, os produtos ativados para DR do Google atendem a dois tipos de escopos de interrupção: regional e zonal. Interrupções parciais precisam ser planejadas da mesma forma que uma interrupção total quando se trata de DR. Isso fornece uma matriz inicial de alto nível de quais produtos são adequados para cada cenário por padrão:

Recursos gerais do produto do Google Cloud
(consulte o Apêndice para saber mais sobre recursos específicos do produto)

	Todos os produtos do Google Cloud	Produtos regionais do Google Cloud com replicação automática entre zonas	Produtos multirregionais ou globais do Google Cloud com replicação automática em todas as regiões
Falha de um componente dentro de uma zona	Coberto*	Coberto	Coberto
Interrupção de zona	Não coberto	Coberto	Coberto
Interrupção da região	Não coberto	Não coberto	Coberto

* Todos os produtos do Google Cloud são resilientes a falhas de componentes, exceto nos casos específicos indicados na documentação do produto. Normalmente, são cenários em que o produto oferece acesso direto ou mapeamento estático a uma parte do hardware de especialização, como memória ou discos de estado sólido (SSD).

Como o RPO limita as opções de produtos

Na maioria das implantações na nuvem, a integridade dos dados é o aspecto com arquitetura mais significativa a ser considerado para um serviço. Pelo menos alguns aplicativos têm um requisito de RPO de zero, o que significa que não haverá perda de dados no caso de uma interrupção. Isso normalmente exige que os dados sejam replicados de maneira síncrona para outra zona ou região. A replicação síncrona tem vantagens e desvantagens relacionadas ao custo e à latência. Portanto, mesmo que muitos produtos do Google Cloud forneçam replicação síncrona em todas as zonas, apenas algumas oferecem regiões diferentes. Isso significa que não é incomum que diferentes tipos de dados dentro de um aplicativo tenham valores de RPO distintos.

Para dados com um RPO maior que zero, os aplicativos podem aproveitar a replicação assíncrona. A replicação assíncrona é aceitável quando dados perdidos podem ser recriados facilmente ou podem ser recuperados em uma fonte dourada de dados, se necessário. Também pode ser uma escolha sensata quando uma pequena quantidade de perda de dados é aceitável no contexto de durações esperadas de interrupção regional e por zona. Também é importante ressaltar que, durante uma interrupção temporária, os dados gravados no local afetado, mas que ainda não foram replicados para outro local, geralmente ficam disponíveis após a resolução. Isso significa que o risco de perda permanente é menor que o risco de perder o acesso a dados durante uma interrupção.

Principais ações: estabeleça se você realmente precisa de RPO zero e, em caso positivo, se é possível fazer isso para um subconjunto de dados. Isso aumenta drasticamente o intervalo de serviços ativados para DR disponíveis com você. No Google Cloud, conseguir o RPO zero significa usar produtos predominantemente regionais para seu aplicativo, que, por padrão, são resilientes à interrupção escalonadas por zona, mas não às interrupções escalonadas por região.

Como a RTO limita as opções de produtos

Um dos principais benefícios da computação em nuvem é a capacidade de implantar a infraestrutura sob demanda. No entanto, isso não é o mesmo que a implantação instantânea. O valor de RTO do seu aplicativo precisa acomodar o RTO combinado dos produtos do Google Cloud que seu aplicativo usa e todas as ações que seus engenheiros ou SREs precisam executar para reiniciar as VMs ou os componentes do aplicativo. Uma RTO medida em minutos significa projetar um aplicativo que se recupera automaticamente de um desastre sem intervenção humana ou com etapas mínimas, como o envio de um botão para failover. Historicamente, o custo e a complexidade desse tipo de sistema têm sido muito altos, mas os produtos do Google Cloud, como balanceadores de carga e grupos de instâncias, tornam esse design muito mais acessível e simples. Portanto, considere o failover e a recuperação automatizados para a maioria dos aplicativos. Esteja ciente de que projetar um sistema para esse tipo de failover quente entre regiões é complicado e caro. Apenas uma pequena fração de serviços críticos garante esse recurso.

A maioria dos aplicativos terá uma RTO entre uma hora e um dia, o que permite um failover morno em um cenário de desastre, com alguns componentes do aplicativo sendo executados o tempo todo em um modo de espera, como bancos de dados, enquanto outros são escalonados no caso de um desastre real, como servidores da Web. Para esses aplicativos, considere a automação para os eventos de escalonamento horizontal. Serviços com um RTO ao longo de um dia são os mais críticos e geralmente podem ser recuperados do backup ou recriados do zero.

Principais ações: defina se você precisa de um RTO de (quase) zero para failover regional e, em caso afirmativo, se pode fazer isso para um subconjunto de serviços. Isso muda o custo de execução e manutenção do serviço.

Etapa 3: desenvolver suas próprias arquiteturas e guias de referência

A etapa final recomendada é criar os próprios padrões de arquitetura específicos da empresa para ajudar as equipes a padronizar a abordagem de recuperação de desastres. A maioria dos clientes do Google Cloud produz um guia para as equipes de desenvolvimento correspondentes às expectativas individuais de resiliência de negócios com as duas principais categorias de cenários de interrupção no Google Cloud. Dessa forma, as equipes podem categorizar facilmente quais produtos ativados para DR são adequados para cada nível de crítica.

Criar diretrizes de produtos

Voltando à tabela de exemplo do RTO/RPO acima, você tem um guia hipotético que lista quais produtos seriam permitidos por padrão para cada nível de crítica. Observe que quando determinados produtos são identificados como não adequados por padrão, sempre é possível adicionar seus próprios mecanismos de replicação e failover para ativar a sincronização entre zonas ou regiões, mas este exercício é diferente do escopo deste artigo. As tabelas também incluem links para mais informações sobre cada produto para ajudar você a entender os recursos em relação ao gerenciamento de interrupções de zona ou região.

Padrões de arquitetura de amostra para uma organização de exemplo - Resiliência de interrupção da zona

Produto do Google Cloud	O produto atende aos requisitos de interrupção de zona para a organização de exemplo com a configuração correta?
	Nível 1	Nível 2	Nível 3
Compute Engine	Não	Não	Não
Dataflow	Não	Não	Não
BigQuery	Não	Não	Sim
GKE	Sim	Sim	Sim
Cloud Storage	Sim	Sim	Sim
Cloud SQL	Não	Sim	Sim
Spanner	Sim	Sim	Sim
Cloud Load Balancing	Sim	Sim	Sim

Esta tabela é um exemplo baseado apenas nas camadas hipotéticas mostradas acima.

Padrões de arquitetura de amostra para uma organização de exemplo - Resiliência de interrupção de região

Produto do Google Cloud	O produto atende aos requisitos de interrupção de região para a organização de exemplo (com configuração de produto apropriada)
	Nível 1	Nível 2	Nível 3
Compute Engine	Sim	Sim	Sim
Dataflow	Não	Não	Não
BigQuery	Não	Não	Sim
GKE	Sim	Sim	Sim
Cloud Storage	Não	Não	Não
Cloud SQL	Não	Sim	Sim
Spanner	Sim	Sim	Sim
Cloud Load Balancing	Sim	Sim	Sim

Esta tabela é um exemplo baseado apenas nas camadas hipotéticas mostradas acima.

Para mostrar como esses produtos serão usados, as seções a seguir abordam algumas arquiteturas de referência para cada um dos níveis de criticidade do aplicativo. Essas descrições de nível superior deliberadamente representam as principais decisões de arquitetura e não representam um design de solução completo.

Exemplo de arquitetura de nível 3

Importância do aplicativo	Interrupção de zona	Interrupção da região
Camada 3 (menos importante)	RTO 12 horas RPO 24 horas	RTO 28 dias RPO 24 horas

Os ícones esmaecidos indicam a infraestrutura que será ativada para recuperação.

Nesta arquitetura, descrevemos um aplicativo cliente/servidor tradicional: os usuários internos se conectam a um aplicativo em execução em uma instância de computação, apoiada por um banco de dados para armazenamento permanente.

É importante observar que essa arquitetura aceita valores melhores de RTO e RPO do que o necessário. No entanto, você também precisa eliminar etapas manuais extras quando elas são caras ou pouco confiáveis. Por exemplo, recuperar um banco de dados de um backup noturno poderia ser compatível com o RPO de 24 horas, mas isso geralmente precisa de um especialista, como um administrador de banco de dados que pode não estar disponível, especialmente se vários serviços fossem afetados ao mesmo tempo. Com a infraestrutura sob demanda do Google Cloud, é possível criar essa capacidade sem comprometer significativamente os custos. Assim, essa arquitetura usa a HA do Cloud SQL em vez de um backup/restauração manual para interrupções zonais.

Principais decisões arquitetônicas para interrupção da zona - RTO de 12h e RPO de 24h:

• Um balanceador de carga interno é usado para fornecer um ponto de acesso escalonável para os usuários, o que permite o failover automático para outra zona. Mesmo que o RTO seja de 12 horas, alterações manuais em endereços IP ou até mesmo atualizações de DNS podem demorar mais que o esperado.
• Um grupo de instâncias gerenciadas por região é configurado com várias zonas, mas poucos recursos. Isso otimiza os custos, mas ainda permite que as máquinas virtuais sejam escalonadas rapidamente na zona de backup.
• Uma configuração de alta disponibilidade do Cloud SQL oferece failover automático a outra zona. Os bancos de dados são significativamente mais difíceis de recriar e restaurar em comparação com as máquinas virtuais do Compute Engine.

Principais decisões arquitetônicas para interrupção da região: RTO de 28 dias e RPO de 24 horas:

• Um balanceador de carga seria construído na região 2 apenas em caso de interrupção regional. O Cloud DNS é usado para fornecer um recurso de failover regional orquestrado, mas manual, uma vez que a infraestrutura na região 2 só seria disponibilizada no caso de uma interrupção da região.
• Um novo grupo de instâncias gerenciadas seria construído somente no caso de interrupção da região. Isso otimiza os custos e é improvável que sejam invocados de acordo com o curto período da maioria das interrupções regionais. Para simplificar, o diagrama não mostra as ferramentas associadas necessárias para reimplantar ou a cópia das imagens do Compute Engine necessárias.
• Uma nova instância do Cloud SQL é recriada e os dados são restaurados de um backup. Novamente, o risco de uma interrupção prolongada em uma região é extremamente baixo, então essa é outra troca de otimização de custos.
• O Cloud Storage multirregional é usado para armazenar esses backups. Isso proporciona resiliência automática de zona e região no RTO e RPO.

Exemplo de arquitetura de nível 2

Importância do aplicativo	Interrupção de zona	Interrupção da região
Nível 2	RTO 4 horas RPO zero	RTO 24 horas RPO 4 horas

Nesta arquitetura, descrevemos um armazenamento de dados com usuários internos que se conectam a uma camada de visualização da instância do Compute e uma camada de ingestão e transformação de dados que preenche o armazenamento de dados de back-end.

Alguns componentes individuais dessa arquitetura não são diretamente compatíveis com o RPO necessário para a respectiva camada. No entanto, por serem usados em conjunto, o serviço geral atende ao RPO. Nesse caso, como o Dataflow é um produto zonal, siga as recomendações para design de alta disponibilidade a fim de evitar a perda de dados durante uma interrupção. No entanto, a camada do Cloud Storage é a fonte dourada desses dados e é compatível com um RPO de zero. Como resultado, é possível ingerir novamente todos os dados perdidos no BigQuery usando a zona b em caso de uma interrupção na zona a.

Principais decisões arquitetônicas para interrupção da zona - RTO de 4h e RPO de zero:

• Um balanceador de carga é usado para fornecer um ponto de acesso escalonável para os usuários, o que permite o failover automático para outra zona. Mesmo que o RTO seja de quatro horas, as alterações manuais em endereços IP ou até mesmo as atualizações de DNS podem levar mais tempo do que o esperado.
• Um grupo de instâncias gerenciadas regional para a camada de computação de visualização de dados é configurado com várias zonas, mas recursos mínimos. Isso otimiza os custos, mas ainda permite que as máquinas virtuais sejam escalonadas rapidamente.
• O Cloud Storage regional é usado como uma camada de preparação para a ingestão inicial de dados, proporcionando resiliência automática de zonas.
• O Dataflow é usado para extrair dados do Cloud Storage e transformá-los antes de carregá-los no BigQuery. No caso de uma interrupção da zona, esse é um processo sem estado que pode ser reiniciado em outra zona.
• O BigQuery disponibiliza o back-end do data warehouse para o front-end de visualização de dados. No caso de uma interrupção da zona, os dados perdidos serão reprocessados no Cloud Storage.

Principais decisões arquitetônicas para interrupção da região: RTO de 24h e RPO de 4h :

• Um balanceador de carga em cada região é usado para fornecer um ponto de acesso escalonável para os usuários. O Cloud DNS é usado para fornecer um recurso de failover regional orquestrado, mas manual, uma vez que a infraestrutura na região 2 só seria disponibilizada no caso de uma interrupção da região.
• Um grupo de instâncias gerenciadas regional para a camada de computação de visualização de dados é configurado com várias zonas, mas recursos mínimos. Isso não será acessível até que o balanceador de carga seja reconfigurado, mas não requer intervenção manual caso contrário.
• O Cloud Storage regional é usado como uma camada de preparação para a ingestão inicial de dados. Ele está sendo carregado ao mesmo tempo nas duas regiões para atender aos requisitos do RPO.
• O Dataflow é usado para extrair dados do Cloud Storage e transformá-los antes de carregá-los no BigQuery. No caso de uma interrupção da região, isso preencheria o BigQuery com os dados mais recentes do Cloud Storage.
• O BigQuery fornece o back-end do data warehouse. Em operações normais, isso seria atualizado de maneira intermitente. No caso de interrupção da região, os dados mais recentes serão reprocessados pelo Dataflow do Cloud Storage.

Exemplo de arquitetura de nível 1

Importância do aplicativo	Interrupção de zona	Interrupção da região
Camada 1 (mais importante)	RTO zero RPO zero	RTO 4 horas RPO 1 hora

Nesta arquitetura, descrevemos uma infraestrutura de back-end de aplicativo para dispositivos móveis com usuários externos que se conectam a um conjunto de microsserviços em execução no GKE. O Spanner fornece a camada de armazenamento de dados de back-end para dados em tempo real, e os dados históricos são transmitidos para um data lake do BigQuery em cada região.

Novamente, alguns componentes individuais dessa arquitetura não são diretamente compatíveis com o RPO necessário para o nível. No entanto, por serem usados juntos, o serviço geral atende ao RPO. Nesse caso, o BigQuery é usado para consultas analíticas. As regiões são alimentadas simultaneamente pelo Spanner.

Principais decisões de arquitetura para interrupção da zona, RTO de zero e RPO de zero:

• Um balanceador de carga é usado para fornecer um ponto de acesso escalonável para os usuários, o que permite o failover automático para outra zona.
• Um cluster regional do GKE é usado na camada do aplicativo configurada com várias zonas. Isso realiza o RTO de zero em cada região.
• O Spanner multirregional é usado como uma camada de persistência de dados, fornecendo resiliência de dados de zona automática e consistência de transação.
• O BigQuery oferece o recurso de análise para o aplicativo. Cada região recebe dados do Spanner e é acessada de maneira independente pelo aplicativo.

Principais decisões de arquitetura para interrupção da região: RTO de quatro horas e RPO de uma hora:

• Um balanceador de carga é usado para fornecer um ponto de acesso escalonável para os usuários, o que permite o failover automático para outra região.
• Um cluster regional do GKE é usado na camada do aplicativo configurada com várias zonas. No caso de interrupção da região, o cluster na região alternativa é escalonado automaticamente para assumir a carga extra de processamento.
• O Spanner multirregional é usado como uma camada de persistência de dados, fornecendo resiliência de dados de região automática e consistência de transação. Esse é o componente principal para atingir o RPO entre regiões de uma hora.
• O BigQuery oferece o recurso de análise para o aplicativo. Cada região recebe dados do Spanner e é acessada de maneira independente pelo aplicativo. Essa arquitetura compensa o componente do BigQuery, permitindo que ela atenda aos requisitos gerais do aplicativo.

Apêndice: referência ao produto

Nesta seção, descrevemos os recursos de arquitetura e DR dos produtos do Google Cloud mais usados nos aplicativos dos clientes e que podem ser facilmente usados para atender aos requisitos de DR.

Temas comuns

Muitos produtos do Google Cloud oferecem configurações regionais ou multirregionais. Os produtos regionais são resilientes a falhas de zona, e os produtos multirregionais e globais são resilientes a interrupções regionais. Em geral, isso significa que, durante uma falha, seu aplicativo sofre o mínimo de interrupções. O Google alcança esses resultados com algumas abordagens arquitetônicas comuns que espelham a orientação arquitetônica acima.

• Implantação redundante: os back-ends e armazenamento de dados do aplicativo são implantados em várias zonas em uma região e em várias regiões em um local multirregional.

• Replicação de dados: os produtos usam replicação síncrona ou assíncrona nos locais redundantes.

  • A replicação síncrona significa que, quando seu aplicativo faz uma chamada de API para criar ou modificar dados armazenados pelo produto, ele recebe uma resposta bem-sucedida somente depois que o produto grava os dados em vários locais. A replicação síncrona garante que você não perca acesso a nenhum dos dados durante uma interrupção da infraestrutura do Google Cloud, porque todos os dados estão em um dos locais de back-end disponíveis.

    Mesmo que essa técnica ofereça proteção máxima de dados, ela pode ter desvantagens em termos de latência e desempenho. Produtos de várias regiões que usam a replicação síncrona têm uma desvantagem muito maior: geralmente na ordem de dezenas ou centenas de milissegundos de latência extra.

  • Assíncrona replicação significa que, quando seu aplicativo faz uma chamada de API para criar ou modificar dados armazenados pelo produto, ele recebe uma resposta bem-sucedida depois que o produto grava os dados em um único local. Com a solicitação de gravação, o produto replica os dados para outros locais.

    Essa técnica fornece menor latência e maior capacidade na API do que a replicação síncrona, mas à custa da proteção de dados. Se o local em que você gravou dados sofrer uma interrupção antes que a replicação seja concluída, você perderá o acesso a esses dados até que a interrupção seja resolvida.

• Como lidar com interrupções com balanceamento de carga: o Google Cloud usa o balanceamento de carga do software para encaminhar solicitações para os back-ends de aplicativos apropriados. Em comparação a outras abordagens, como o balanceamento de carga DNS, essa abordagem reduz o tempo de resposta do sistema para uma interrupção. Quando ocorre uma interrupção de localização do Google Cloud, o balanceador de carga detecta rapidamente que o back-end implantado nesse local ficou "não íntegro" e direciona todas as solicitações para um back-end em um local alternativo. Isso permite que o produto continue atendendo às solicitações do aplicativo durante uma interrupção de local. Quando a interrupção do local é resolvida, o balanceador de carga detecta a disponibilidade dos back-ends de produtos nesse local e retoma o envio do tráfego para esse local.

Access Context Manager

Com o Access Context Manager, as empresas podem configurar níveis de acesso que são mapeados para uma política definida nos atributos da solicitação. As políticas são espelhadas por região.

No caso de uma interrupção zonal, as solicitações para zonas indisponíveis são exibidas de maneira automática e transparente de outras zonas disponíveis na região.

No caso de interrupção regional, os cálculos de política da região afetada ficarão indisponíveis até que a região fique disponível novamente.

Transparência no acesso

A transparência no acesso permite que os administradores da organização do Google Cloud definam um controle de acesso minucioso e baseado em atributos para projetos e recursos no Google Cloud. Ocasionalmente, o Google precisa acessar os dados dos clientes para fins administrativos. Quando acessamos os dados dos clientes, a transparência no acesso fornece registros de acesso para os clientes afetados do Google Cloud. Esses registros de transparência no acesso ajudam a garantir o compromisso do Google com a segurança e a transparência dos dados no tratamento de dados.

A Transparência no acesso é resiliente contra interrupções zonais e regionais. Se uma interrupção zonal ou regional ocorrer, a transparência no acesso continuará processando os registros de acesso administrativo em outra zona ou região.

AlloyDB para PostgreSQL

O AlloyDB para PostgreSQL é um serviço de banco de dados totalmente gerenciado e compatível com o PostgreSQL. Ele oferece alta disponibilidade em uma região por meio dos nós redundantes da instância primária que estão em duas zonas diferentes da região. A instância primária mantém a disponibilidade regional acionando um failover automático para a zona de espera quando a zona ativa encontra um problema. O armazenamento regional garante a durabilidade dos dados em caso de perda de uma única zona.

Como outro método de recuperação de desastres, o AlloyDB para PostgreSQL usa a replicação entre regiões a fim de fornecer recursos de recuperação de desastres replicando de maneira assíncrona os dados do cluster primário em clusters secundários que estão em regiões separadas do Google Cloud.

Interrupção zonal: durante a operação normal, apenas um dos dois nós de uma instância primária de alta disponibilidade está ativo e atende a todas as gravações de dados. Esse nó ativo armazena os dados na camada de armazenamento regional separada do cluster.

O AlloyDB para PostgreSQL detecta automaticamente falhas no nível da zona e aciona um failover para restaurar a disponibilidade do banco de dados. Durante o failover, o AlloyDB para PostgreSQL inicia o banco de dados no nó de espera, que já está provisionado em uma zona diferente. Novas conexões de banco de dados são encaminhadas automaticamente para essa zona.

Do ponto de vista de um aplicativo cliente, uma interrupção de zona se assemelha a uma interrupção temporária da conectividade de rede. Após a conclusão do failover, um cliente pode se reconectar à instância no mesmo endereço usando as mesmas credenciais, sem perda de dados.

Interrupção regional: a replicação entre regiões usa a replicação assíncrona, que permite que a instância primária confirme as transações antes de elas serem confirmadas em réplicas. A diferença de tempo entre o momento em que uma transação é confirmada na instância primária e o momento em que ela é confirmada na réplica é conhecida como atraso de replicação. A diferença de tempo entre o momento em que a instância primária gera o registro prévio de escrita (WAL) e o momento em que o WAL acessa a réplica é chamada de atraso de liberação. Os atrasos de replicação e de liberação dependem da configuração da instância do banco de dados e da carga de trabalho gerada pelo usuário.

No caso de uma interrupção regional, é possível promover clusters secundários em uma região diferente para se tornarem clusters primários graváveis e autônomos. Esse cluster promovido não replica mais os dados do cluster primário original ao qual foi associado anteriormente. Devido ao atraso de liberação, algumas perdas de dados podem ocorrer porque pode haver transações no cluster primário original que não foram propagadas para o cluster secundário.

O RPO de replicação entre regiões é afetado pela utilização da CPU do cluster primário e pela distância física entre a região do cluster primário e a região do cluster secundário. Para otimizar o RPO, recomendamos testar a carga de trabalho com uma configuração que inclua uma réplica a fim de estabelecer um limite seguro de transações por segundo (TPS), que é o TPS sustentado mais alto que não acumula atraso de liberação. Se a carga de trabalho exceder o limite seguro de TPS, o atraso de liberação se acumulará, o que poderá afetar o RPO. Para limitar o atraso de rede, escolha pares de regiões no mesmo continente.

Para mais informações sobre como monitorar o atraso de rede e outras métricas do AlloyDB para PostgreSQL, consulte Monitorar instâncias.

IA antilavagem de dinheiro

A IA antilavagem de dinheiro (AML AI) fornece uma API para ajudar instituições financeiras globais a detectar lavagem de dinheiro com mais eficiência. A IA antilavagem de dinheiro é uma oferta regional, o que significa que os clientes podem escolher a região, mas não as zonas que a compõem. A carga dos dados e do tráfego é balanceada automaticamente entre as zonas de uma região. As operações (por exemplo, para criar um pipeline ou executar uma previsão) são automaticamente escalonadas em segundo plano e têm a carga balanceada entre zonas, conforme necessário.

Interrupção zonal: a AML AI armazena dados para os recursos regionalmente e eles são replicados de maneira síncrona. Quando uma operação de longa duração termina com sucesso, é possível contar com os recursos, independentemente de falhas zonais. O processamento também é replicado entre as zonas, mas essa replicação tem como objetivo o balanceamento de carga e não a alta disponibilidade. Portanto, uma falha zonal durante uma operação pode resultar em uma falha na operação. Se isso acontecer, realize a operação novamente para resolver o problema. Durante uma interrupção de zona, os tempos de processamento podem ser afetados.

Interrupção regional: os clientes escolhem a região do Google Cloud em que querem criar os recursos da AML AI. Os dados jamais são replicados entre regiões. O tráfego do cliente nunca é roteado para uma região diferente pela AML AI. Em caso de falha regional, a AML AI volta a ficar disponível assim que a falha é resolvida.

Chaves de API

As chaves de API fornecem um gerenciamento de recursos de chave de API escalonável para um projeto. As chaves de API são um serviço global, o que significa que elas são visíveis e podem ser acessadas de qualquer local do Google Cloud. Os dados e metadados são armazenados de maneira redundante em várias zonas e regiões.

As chaves de API são resilientes a falhas temporárias zonais e regionais. No caso de interrupção zonal ou interrupção regional, as chaves de API continuam a atender solicitações de outra zona na mesma região ou em uma região diferente.

Para mais informações sobre chaves de API, consulte Visão geral da API de chaves de API.

Apigee

A Apigee fornece uma plataforma segura, escalonável e confiável para desenvolvimento e gerenciamento de APIs. A Apigee oferece implantações de região única e multirregional.

Interrupção zonal: os dados de ambiente de execução do cliente são replicados em várias zonas de disponibilidade. Portanto, uma interrupção de zona única não afeta a Apigee.

Interrupção regional: para instâncias da Apigee de região única, se uma região ficar inativa, as instâncias da Apigee não estarão disponíveis nessa região e não poderão ser restauradas em regiões diferentes. Para instâncias multirregionais da Apigee, os dados são replicados de maneira assíncrona em todas as regiões. Portanto, a falha de uma região não reduz completamente o tráfego. No entanto, talvez não seja possível acessar dados não comprometidos na região com falha. É possível desviar o tráfego de regiões não íntegras. Para alcançar o failover automático de tráfego, configure o roteamento de rede usando grupos de instâncias gerenciadas (MIGs, na sigla em inglês).

AutoML Translation

O AutoML Translation é um serviço de tradução automática que permite importar seus próprios dados (pares de frases) para treinar modelos personalizados para suas necessidades específicas do domínio.

Interrupção zonal: o AutoML Translation tem servidores de computação ativos em várias zonas e regiões. Também é compatível com a replicação síncrona de dados entre zonas nas regiões. Esses recursos ajudam o Translation AutoML a atingir um failover instantâneo sem perda de dados para falhas zonais e sem exigir entrada ou ajuste de clientes.

Interrupção regional: no caso de falha regional, o AutoML Translation não está disponível.

Lote

O Batch é um serviço totalmente gerenciado para enfileirar, programar e executar jobs em lote no Google Cloud. As configurações em lote são definidas no nível da região. Os clientes precisam escolher uma região para enviar os jobs em lote, e não uma zona em uma região. Quando um job é enviado, o Batch grava dados de clientes de maneira síncrona em várias zonas. No entanto, os clientes podem especificar as zonas em que as VMs em lote executam jobs.

Falha zonal: quando uma única zona falha, as tarefas em execução nela também falham. Se as tarefas tiverem configurações de repetição, o Batch fará o failover automaticamente para outras zonas ativas na mesma região. O failover automático está sujeito à disponibilidade de recursos em zonas ativas na mesma região. Os jobs que exigem recursos zonais (como VMs, GPUs ou discos permanentes zonais) que estão disponíveis apenas na zona com falha são enfileirados até que a zona com falha se recupere ou até que os tempos limite dos jobs em fila sejam atingidos. Quando possível, recomendamos que os clientes permitam que o Batch escolha recursos zonais para executar os jobs deles. Isso ajuda a garantir que os jobs sejam resilientes a uma interrupção de zona.

Falha regional: em caso de falha regional, o plano de controle de serviço está indisponível na região. O serviço não replica dados ou solicitações de redirecionamento entre regiões. Recomendamos que os clientes usem várias regiões para executar os jobs e redirecionar jobs para uma região diferente se uma região falhar.

Proteção de dados e contra ameaças do BeyondCorp Enterprise

O BeyondCorp Enterprise Threat and Data Protection faz parte da solução BeyondCorp Enterprise. Ele amplia o Chrome com uma variedade de recursos de segurança, incluindo proteção contra malware e phishing, Prevenção contra perda de dados (DLP, na sigla em inglês), regras de filtragem de URL e relatórios de segurança.

Os administradores do BeyondCorp Enterprise podem optar por armazenar o conteúdo principal do cliente que viola as políticas de DLP ou malware em eventos de registro de regras do Google Workspace e/ou no Cloud Storage para investigações futuras. Os eventos de registro de regras do Google Workspace são alimentados por um banco de dados multirregional do Spanner. O BeyondCorp Enterprise pode levar até várias horas para detectar violações da política. Durante esse período, todos os dados não processados estão sujeitos à perda de dados devido a uma interrupção zonal ou regional. Quando uma violação é detectada, o conteúdo que viola suas políticas é gravado nos eventos de registro de regras do Google Workspace e/ou no Cloud Storage.

Falha temporária por zona e região: como a proteção de dados e contra ameaças do BeyondCorp Enterprise é multizonal e multirregional, ele pode sobreviver a uma perda completa e não planejada de uma zona ou região sem perda de disponibilidade. Ele oferece esse nível de confiabilidade ao redirecionar o tráfego para o serviço em outras zonas ou regiões ativas. No entanto, como a proteção de dados e contra ameaças do BeyondCorp Enterprise pode levar várias horas para detectar violações de DLP e malware, todos os dados não processados em uma zona ou região específica estão sujeitos à perda por uma interrupção zonal ou regional.

BigQuery

O BigQuery é um armazenamento de dados sem servidor, altamente escalonável e econômico projetado para a agilidade dos negócios. O BigQuery é compatível com os seguintes tipos de localização para conjuntos de dados do usuário:

• uma região: uma localização geográfica específica, como Iowa (us-central1) ou Montreal (northamerica-northeast1);
• uma multirregião: uma área geográfica grande que contém dois ou mais lugares geográficos, como os Estados Unidos (US) ou a Europa (EU).

Em ambos os casos, os dados são armazenados de modo redundante em duas zonas de uma única região no local selecionado. Os dados gravados no BigQuery são gravados nas zonas principal e secundária de maneira síncrona. Isso protege contra a indisponibilidade de uma única zona na região, mas não contra uma falha temporária regional.

Autorização binária

A autorização binária é um produto de segurança da cadeia de suprimentos de software do GKE e do Cloud Run.

Todas as políticas de autorização binária são replicadas em várias zonas em cada região. A replicação ajuda as operações de leitura da política de autorização binária a se recuperarem de falhas de outras regiões. A replicação também torna as operações de leitura tolerantes a falhas zonais em cada região.

As operações de aplicação obrigatória da autorização binária são resilientes contra interrupções do serviço zonais, mas não são resilientes contra interrupções do serviço regionais. As operações de aplicação são executadas na mesma região do cluster do GKE ou do job do Cloud Run que está fazendo a solicitação. Portanto, em caso de uma falha regional, não há nada em execução para fazer solicitações de aplicação da autorização binária.

Gerenciador de certificados

O Gerenciador de certificados permite adquirir e gerenciar certificados Transport Layer Security (TLS) para uso com diferentes tipos de Cloud Load Balancing.

No caso de uma interrupção zonal, o Gerenciador de certificados regional e global é resiliente a falhas zonais, porque os jobs e bancos de dados são redundantes em várias zonas dentro de uma região. No caso de interrupção regional, o Gerenciador de certificados global é resiliente a falhas regionais porque os jobs e bancos de dados são redundantes em várias regiões. O Gerenciador de certificados regionais é um produto regional. Portanto, ele não aguenta uma falha regional.

Sistema de detecção de intrusões do Cloud

O Sistema de detecção de intrusões do Cloud (Cloud IDS) é um serviço zonal que fornece endpoints de IDS com escopo zonal, que processam o tráfego de VMs em uma zona específica. Por isso, não é tolerante a interrupções dos serviços zonais ou regionais.

Interrupção do serviço zonal: o Cloud IDS está vinculado a instâncias de VM. Se um cliente planeja mitigar interrupções dos serviços zonais implantando VMs em várias zonas (manualmente ou por grupos gerenciados de instâncias regionais), ele também precisa implantar endpoints do Cloud IDS nessas zonas.

Interrupção do serviço regional: o Cloud IDS é um produto regional. Ele não oferece nenhuma funcionalidade entre regiões. Uma falha regional eliminará toda a funcionalidade do Cloud IDS em todas as zonas nessa região.

Chronicle SIEM

O Chronicle SIEM, que faz parte do Chronicle, é um serviço totalmente gerenciado que ajuda as equipes de segurança a detectar, investigar e responder a ameaças.

O Chronicle SIEM tem ofertas regionais e multirregionais.

• Nas ofertas regionais, os clientes podem escolher a região, mas não as zonas que a compõem. O balanceamento de carga dos dados e do tráfego é feito automaticamente nas zonas da região selecionada, e os dados são armazenados de modo redundante nas zonas de disponibilidade da região.

• Multirregiões são georredundantes. Os dados são armazenados de maneira redundante em todas as regiões, o que fornece um conjunto mais amplo de proteções do que o armazenamento regional e garante a funcionalidade do serviço mesmo em caso de perda de uma região completa. Os dados são replicados de maneira assíncrona. Isso significa que há uma janela de tempo (um objetivo de ponto de recuperação, ou RPO) em que os dados ainda não são replicados entre regiões. Após o RPO, os dados são disponibilizados em várias regiões. Não há garantias disponíveis para o atraso de replicação.

Falha temporária por zona:

• Implantações regionais: o Chronicle SIEM é implantado em várias zonas dentro de uma região. As solicitações são veiculadas de qualquer zona dentro da região e os dados são replicados em várias zonas da região. No caso de interrupção total da zona, as zonas restantes continuam a exibir o tráfego e processar os dados. O provisionamento redundante e o escalonamento automático para o Chronicle SIEM garantem que o serviço permaneça operacional nas zonas sobreviventes durante essas mudanças de carga.

• Implantações multirregionais: o Chronicle SIEM é implantado em várias regiões. Os dados são replicados de maneira assíncrona nas regiões. No caso de interrupção total da região, não há garantias disponíveis para a replicação de dados e a capacidade do serviço de voltar para uma zona ou região diferente.

Falha temporária regional:

• Implantações regionais: o Chronicle SIEM armazena todos os dados do cliente em uma única região, e o tráfego nunca é roteado entre regiões. No caso de uma interrupção regional, o Chronicle SIEM ficará indisponível até que a interrupção seja resolvida.

• Implantações multirregionais: o Chronicle SIEM replica os dados em várias regiões, e o tráfego é automaticamente redirecionado para as regiões restantes. Não há garantias do atraso da replicação e da capacidade de continuar a veiculação a partir das regiões restantes.

Inventário de recursos do Cloud

O Inventário de recursos do Cloud é um serviço global de alto desempenho, resiliente e que mantém um repositório de recursos de metadados e políticas do Google Cloud. O Cloud Asset Inventory fornece ferramentas de pesquisa e análise que ajudam a rastrear recursos implantados em organizações, pastas e projetos.

No caso de interrupção da zona, o Inventário de recursos do Cloud continua a atender às solicitações de outra zona na mesma região ou em uma região diferente.

No caso de uma falha temporária regional, o Inventário de recursos do Cloud continua a atender solicitações de outras regiões.

Bigtable

O Bigtable é um serviço de banco de dados NoSQL de alto desempenho e totalmente gerenciado para grandes cargas de trabalho de análise e operacionais.

Visão geral da replicação do Bigtable

O Bigtable oferece um recurso de replicação flexível e totalmente configurável, que pode ser usado para aumentar a disponibilidade e a durabilidade dos dados, copiando-os para clusters em várias regiões. ou várias zonas na mesma região. O Bigtable também pode fornecer failover automático para suas solicitações quando você usa a replicação.

Ao usar configurações multirregionais ou multirregionais com roteamento de vários clusters, no caso de uma interrupção zonal ou regional, o Bigtable encaminha automaticamente o tráfego e atende às solicitações de o cluster disponível mais próximo. Como a replicação do Bigtable é assíncrona e consistente eventual, mudanças muito recentes nos dados no local da falha podem estarão indisponíveis se ainda não tiverem sido replicadas para outros locais.

Considerações sobre desempenho

Importante: é necessário garantir que o uso da CPU e os tamanhos de dados mantenham os valores máximos recomendados, e os clusters precisam permanecer provisionados de maneira adequada o tempo todo para que a replicação seja executada de maneira previsível.

Quando as demandas de recursos da CPU excedem a capacidade do nó disponível, o Bigtable sempre prioriza a veiculação de solicitações recebidas antes do tráfego de replicação.

Para mais informações sobre como usar a replicação do Bigtable com sua carga de trabalho, consulte a Visão geral da replicação do Cloud Bigtable e exemplos de configurações de replicação.

Os nós do Bigtable são usados para atender às solicitações recebidas e para executar a replicação de dados de outros clusters. Além de manter a contagem suficiente de nós por cluster, também é preciso garantir que seus aplicativos usem o design de esquema adequado para evitar pontos de acesso, o que pode causar uso excessivo ou desequilibrado de CPU e maior latência de replicação.

Para mais informações sobre como projetar o esquema do aplicativo para maximizar o desempenho e a eficiência do Bigtable, consulte Práticas recomendadas de design do esquema.

Monitoramento

O Bigtable oferece várias maneiras de monitorar visualmente a latência de replicação das instâncias e dos clusters usando os gráficos para replicação disponíveis no console do Google Cloud.

Também é possível monitorar programaticamente as métricas de replicação do Bigtable usando a API Cloud Monitoring.

Certificate Authority Service

Com o Certificate Authority Service (CA Service), os clientes podem simplificar, automatizar e personalizar a implantação, o gerenciamento e a segurança de autoridades de certificação (CA, na sigla em inglês) privadas e emitir certificados de maneira resiliente em grande escala.

Interrupção zonal: o serviço de CA é resiliente a falhas zonais, porque o plano de controle é redundante em várias zonas em uma região. Se houver uma interrupção zonal, o serviço de CA continuará a atender solicitações de outra zona na mesma região sem interrupção. Como os dados são replicados de forma síncrona, não há perda ou dados corrompidos.

Interrupção regional: o serviço de CA é um produto regional, por isso não pode suportar uma falha regional. Se você precisar de resiliência a falhas regionais, crie CAs emissoras em duas regiões diferentes. Crie a CA emissora principal na região em que você precisa de certificados. Crie uma CA substituta em uma região diferente. Use o substituto quando a região da CA subordinada primária tiver uma interrupção. Se necessário, as duas CAs podem encadear a mesma CA raiz.

Cloud Billing

Com a API Cloud Billing, os desenvolvedores podem gerenciar o faturamento dos projetos do Google Cloud de maneira programática. A API Cloud Billing foi projetada como um sistema global com atualizações gravadas de forma síncrona em várias zonas e regiões.

Falha zonal ou regional: a API Cloud Billing faz o failover automaticamente para outra zona ou região. As solicitações individuais podem falhar, mas uma política de repetição permite que as tentativas subsequentes sejam bem-sucedidas.

Cloud Build

O Cloud Build é um serviço que executa suas versões no Google Cloud.

O Cloud Build é composto por instâncias isoladas por região que replicam dados de maneira síncrona em várias zonas da região. Recomendamos que você use regiões específicas do Google Cloud em vez da região global. Verifique se os recursos usados pelo build (incluindo buckets de registros, repositórios do Artifact Registry e outros) estão alinhados à região. em que seu build é executado.

No caso de uma falha temporária zonal, as operações do plano de controle não são afetadas. No entanto, a execução de versões na zona com falha será atrasada ou perdida permanentemente. As versões recém-acionadas serão distribuídas automaticamente para as zonas em funcionamento restantes.

No caso de uma falha regional, o plano de controle fica off-line e, no momento, a execução de versões é atrasada ou perdida permanentemente. Gatilhos, pools de workers e dados de versões nunca são replicados entre regiões. Recomendamos que você prepare gatilhos e pools de workers em várias regiões para facilitar a mitigação de uma falha temporária.

Cloud CDN

O Cloud CDN distribui e armazena em cache o conteúdo em muitos locais na rede do Google para reduzir a latência de exibição para os clientes. O conteúdo em cache é exibido da melhor maneira possível. Quando uma solicitação não pode ser exibida pelo cache do Cloud CDN, ela é encaminhada para servidores de origem, como VMs de back-end ou buckets do Cloud Storage, onde o conteúdo original é armazenado.

Quando uma zona ou região falha, os caches nos locais afetados ficam indisponíveis. As solicitações de entrada são encaminhadas para os locais e caches de borda disponíveis do Google. Se esses caches alternativos não puderem exibir a solicitação, eles a encaminharão para um servidor de origem disponível. Desde que o servidor possa exibir a solicitação com dados atualizados, não haverá perda de conteúdo. O aumento da taxa de ausências no cache fará com que os servidores de origem tenham mais tráfego do que o normal conforme os caches são preenchidos. As solicitações subsequentes serão exibidas a partir dos caches não afetados pela interrupção da zona ou da região.

Para mais informações sobre o Cloud CDN e o comportamento do cache, consulte a documentação do Cloud CDN.

Cloud Composer

O Cloud Composer é um serviço gerenciado de orquestração de fluxos de trabalho que permite criar, programar, monitorar e gerenciar fluxos de trabalho que abrangem nuvens e data centers no local. Os ambientes do Cloud Composer são criados no projeto de código aberto do Apache Airflow.

A disponibilidade da API Cloud Composer não é afetada pela indisponibilidade zonal. Durante uma falha temporária zonal, você mantém acesso à API Cloud Composer, incluindo a capacidade de criar novos ambientes do Cloud Composer.

Um ambiente do Cloud Composer tem um cluster do GKE como parte da própria arquitetura. Durante uma falha temporária zonal, os fluxos de trabalho no cluster podem ser interrompidos:

• No Cloud Composer 1, o cluster do ambiente é um recurso zonal, portanto, uma interrupção zonal pode tornar o cluster indisponível. Os fluxos de trabalho que estão em execução no momento da falha podem ser interrompidos antes da conclusão.
• No Cloud Composer 2, o cluster do ambiente é um recurso regional. No entanto, os fluxos de trabalho executados em nós de zonas afetadas por uma falha zonal podem ser interrompidos antes da conclusão.

Nas duas versões do Cloud Composer, uma interrupção zonal pode interromper a execução de fluxos de trabalho parcialmente executados, incluindo as ações externas configuradas por você. Dependendo do fluxo de trabalho, isso pode causar inconsistências externamente, por exemplo, se o fluxo de trabalho parar no meio de uma execução de várias etapas para modificar armazenamentos de dados externos. Portanto, considere o processo de recuperação ao projetar seu fluxo de trabalho do Airflow, incluindo como detectar estados de fluxo de trabalho parcialmente executados e reparar qualquer mudança parcial de dados.

No Cloud Composer 1, durante uma interrupção zonal, é possível optar por iniciar um novo ambiente do Cloud Composer em outra zona. Como o Airflow mantém o estado dos fluxos de trabalho no banco de dados de metadados, a transferência dessas informações para um novo ambiente do Cloud Composer pode realizar outras etapas e preparação.

No Cloud Composer 2, é possível resolver interrupções zonais configurando a recuperação de desastres com snapshots do ambiente com antecedência. Durante uma interrupção zonal, é possível mudar para outro ambiente transferindo o estado dos fluxos de trabalho com um snapshot do ambiente. Somente o Cloud Composer 2 é compatível com a recuperação de desastres com snapshots do ambiente.

Cloud Data Fusion

O Cloud Data Fusion é um serviço totalmente gerenciado de integração de dados corporativos. Ele pode ser usado para gerar e gerenciar pipelines de dados. Ele tem três edições.

• Falhas zonais afetam instâncias da edição Developer.

• Falhas regionais afetam instâncias da edição Basic e Enterprise.

Para controlar o acesso a recursos, projete e execute pipelines em ambientes separados. Essa separação permite projetar um pipeline uma vez e executá-lo em vários ambientes. É possível recuperar os pipelines nos dois ambientes. Para mais informações, consulte Fazer backup e restaurar dados da instância.

As recomendações a seguir se aplicam a falhas regionais e zonais.

Falhas no ambiente de design do pipeline

No ambiente de design, salve os rascunhos de pipelines em caso de falha. Dependendo dos requisitos específicos de RTO e RPO, é possível usar os rascunhos salvos para restaurar o pipeline em uma instância diferente do Cloud Data Fusion durante uma falha.

Falhas no ambiente de execução do pipeline

No ambiente de execução, inicie o pipeline internamente com gatilhos ou programações do Cloud Data Fusion ou externamente com ferramentas de orquestração, como o Cloud Composer. Para recuperar as configurações de ambiente de execução dos pipelines, faça backup dos pipelines e configurações, como plug-ins e programações. Em uma falha, use o backup para replicar uma instância em uma região ou zona não afetada.

Outra maneira de se preparar para falhas é ter várias instâncias nas regiões com a mesma configuração e conjunto de pipelines. Se você usar a orquestração externa, os pipelines em execução poderão ter o balanceamento de carga automático entre as instâncias. Tome cuidado para garantir que não haja recursos, como fontes de dados ou ferramentas de orquestração, vinculados a uma única região e usados por todas as instâncias, porque isso pode se tornar um ponto central de interrupção em uma falha. Por exemplo, é possível ter várias instâncias em diferentes regiões e usar o Cloud Load Balancing e o Cloud DNS para direcionar as solicitações de execução do pipeline para uma instância que não é afetada por uma falha. Confira as arquiteturas de exemplo nível um e nível três.

Falhas em outros serviços de dados do Google Cloud no pipeline

A instância pode usar outros serviços do Google Cloud como fontes de dados ou ambientes de execução de pipeline, como Dataproc, Cloud Storage ou BigQuery. Esses serviços podem estar em diferentes regiões. Quando a execução inter-regional é necessária, uma falha em qualquer uma das regiões leva a uma interrupção. Neste cenário, siga as etapas padrão de recuperação de desastres, tendo em mente que a configuração entre regiões com serviços essenciais em regiões diferentes é menos resiliente.

Cloud Deploy

O Cloud Deploy oferece entrega contínua de cargas de trabalho em serviços de ambiente de execução, como o GKE e o Cloud Run. O serviço é composto por instâncias regionais que replicam dados de maneira síncrona nas zonas da região.

Interrupção zonal: as operações do plano de controle não são afetadas. No entanto, os builds do Cloud Build (por exemplo, operações de renderização ou implantação) em execução quando uma zona falha são atrasadas ou perdidas permanentemente. Durante uma interrupção, o recurso do Cloud Deploy que acionou o build (uma versão ou lançamento) exibe um status de falha que indica que a operação subjacente falhou. É possível recriar o recurso para iniciar um novo build nas zonas de funcionamento restantes. Por exemplo, crie uma nova implantação reimplantando a versão em um destino.

Interrupção regional: as operações do plano de controle ficarão indisponíveis, bem como os dados do Cloud Deploy, até que a região seja restaurada. Para facilitar a restauração do serviço em caso de uma interrupção regional, recomendamos que você armazene o pipeline de entrega e as definições de meta no controle de origem. É possível usar esses arquivos de configuração para recriar os pipelines do Cloud Deploy em uma região em funcionamento. Durante uma interrupção, os dados sobre versões existentes são perdidos. Crie uma nova versão para continuar implantando softwares nos seus destinos.

Cloud DNS

O Cloud DNS é um serviço de Sistema de Nome de Domínio (DNS, na sigla em inglês) global, resiliente e de alto desempenho. Com ele, você publica nomes de domínio no DNS global com economia.

No caso de interrupção zonal, o Cloud DNS continua atendendo solicitações de outra zona na mesma região ou em uma região diferente sem interrupção. As atualizações nos registros do Cloud DNS são replicadas de maneira síncrona nas zonas da região em que são recebidas. Portanto, não há perda de dados.

No caso de interrupção regional, o Cloud DNS continua atendendo às solicitações de outras regiões. É possível que atualizações muito recentes nos registros do Cloud DNS não estejam disponíveis porque as atualizações são processadas primeiro em uma única região antes de serem replicadas de maneira assíncrona em outras regiões.

Cloud Functions

O Cloud Functions é um ambiente de computação sem estado em que os clientes podem executar seu código de função na infraestrutura do Google. O Cloud Functions é uma oferta regional, ou seja, os clientes podem escolher a região, mas não as zonas que compõem uma região. Os dados e o tráfego são balanceados automaticamente entre as zonas de uma região. As funções são escalonadas automaticamente para atender ao tráfego de entrada e têm a carga balanceada entre zonas conforme necessário. Cada zona mantém um programador que fornece esse escalonamento automático por zona. Ele também está ciente da carga que outras zonas estão recebendo e provisiona capacidade extra na zona para permitir falhas zonais.

Falha temporária zonal: o Cloud Functions armazena metadados, bem como a função implantada. Esses dados são armazenados regionalmente e gravados de maneira síncrona. A API Cloud Functions Admin só retorna a chamada de API depois que os dados são confirmados em um quórum dentro de uma região. Como os dados são armazenados em regiões, as operações do plano de dados também não são afetadas por falhas zonais. O tráfego é roteado automaticamente para outras zonas em caso de falha zonal.

Falha temporária regional: os clientes escolhem a região do Google Cloud em que querem criar a função. Os dados jamais são replicados entre regiões. O tráfego do cliente nunca vai ser roteado para uma região diferente pelo Cloud Functions. Em caso de falha regional, o Cloud Functions volta a ficar disponível assim que a falha é resolvida. Recomendamos aos clientes implantar em várias regiões e usar o Cloud Load Balancing para conseguir maior disponibilidade, se precisarem.

API Cloud Healthcare

A API Cloud Healthcare, um serviço para armazenar e gerenciar dados de saúde, foi criada para fornecer alta disponibilidade e oferece proteção contra falhas zonais e regionais, dependendo de uma configuração escolhida.

Configuração regional: na configuração padrão, a API Cloud Healthcare oferece proteção contra falhas zonais. O serviço é implantado em três zonas em uma região, e os dados também triplicam nas diferentes zonas da região. Em caso de falha zonal, afetando a camada de serviço ou a camada de dados, as zonas restantes assumem o controle sem interrupção. Com a configuração regional, se uma região inteira em que o serviço estiver localizado passar por uma falha temporária, ele ficará indisponível até que a região fique on-line novamente. No caso inesperado de uma destruição física de uma região inteira, os dados armazenados nela serão perdidos.

Configuração multirregional: na configuração multirregional, a API Cloud Healthcare é implantada em três zonas pertencentes a três regiões diferentes. Os dados também são replicados em três regiões. Isso protege contra a perda de serviço em caso de uma interrupção em toda a região, já que as regiões restantes serão assumidas automaticamente. Os dados estruturados, como o FHIR, são replicados de maneira síncrona em várias regiões. Portanto, estão protegidos contra a perda de dados em caso de uma interrupção em toda a região. Os dados armazenados em buckets do Cloud Storage, como DICOM e Ditado ou objetos HL7v2/FHIR, são replicados de maneira assíncrona em várias regiões.

Cloud Identity

Os serviços do Cloud Identity são distribuídos em várias regiões e usam balanceamento de carga dinâmico. O Cloud Identity não permite que os usuários selecionem um escopo de recurso. Se uma zona ou região específica sofrer uma interrupção, o tráfego será distribuído automaticamente para outras zonas ou regiões.

Os dados permanentes são espelhados em várias regiões com replicação síncrona na maioria dos casos. Por motivos de desempenho, alguns sistemas, como caches ou alterações que afetam um grande número de entidades, são replicados de maneira assíncrona nas regiões. Se a região principal em que os dados mais atuais estiverem armazenados sofrer uma interrupção, o Cloud Identity exibirá dados desatualizados de outro local até que a região principal fique disponível.

Cloud Interconnect

O Cloud Interconnect oferece aos clientes o acesso RFC 1918 às redes do Google Cloud a partir dos data centers locais por cabos físicos conectados à borda de peering do Google.

O Cloud Interconnect oferece aos clientes um SLA de 99,9% se provisionarem conexões para dois domínios de disponibilidade de borda (EAD, na sigla em inglês) em uma área metropolitana. Um SLA de 99,99% estará disponível se o cliente provisionar conexões em dois EADs em duas áreas metropolitanas para duas regiões com roteamento global. Para mais informações, consulte Visão geral da topologia para aplicativos não críticos e Visão geral da topologia para aplicativos no nível de produção.

O Cloud Interconnect é independente da zona de computação e fornece alta disponibilidade na forma de EADs. No caso de uma falha no EAD, a sessão do BGP para esse EAD falha e o tráfego falha para o outro EAD.

No caso de uma falha regional, as sessões do BGP para essa região interrompem o tráfego e fazem o failover para os recursos na região de trabalho. Isso se aplica quando o roteamento global está ativado.

Cloud Key Management Service

O Cloud Key Management Service (Cloud KMS) fornece gerenciamento de recursos de chave criptográfica escalonável e altamente durável. O Cloud KMS armazena todos os dados e metadados nos bancos de dados do Spanner que oferecem alta durabilidade de dados e disponibilidade com replicação síncrona.

Os recursos do Cloud KMS podem ser criados em uma única região, várias regiões ou globalmente.

No caso de interrupção zonal, o Cloud KMS continua a atender a solicitações de outra zona na mesma região ou em uma região diferente sem interrupção. Como os dados são replicados de forma síncrona, não há perda ou dados corrompidos. Quando a interrupção da zona é resolvida, a redundância total é restaurada.

No caso de interrupção regional, os recursos regionais nessa região estão off-line até que a região fique disponível novamente. Observe que, mesmo em uma região, pelo menos três réplicas são mantidas em zonas separadas. Quando uma disponibilidade maior for necessária, os recursos serão armazenados em uma configuração multirregional ou global. As configurações globais e multirregionais foram projetadas para ficar disponíveis em uma interrupção regional ao armazenar e disponibilizar dados com redundância geográfica em mais de uma região.

Cloud External Key Manager (Cloud EKM)

O gerenciador de chaves externas do Cloud é integrado ao Cloud Key Management Service para permitir o controle e o acesso a chaves externas com parceiros terceirizados compatíveis. É possível usar essas chaves externas para criptografar dados em repouso que serão usados em outros serviços do Google Cloud compatíveis com a integração de chaves de criptografia gerenciadas pelo cliente (CMEK).

• interrupção temporária zonal: o gerenciador de chaves externas do Cloud é resiliente a interrupções zonais devido à redundância fornecida por várias zonas em uma região. Quando há uma interrupção temporária na zona, o tráfego é redirecionado para outras zonas na região. Durante o redirecionamento do tráfego, você pode notar um aumento nos erros, mas o serviço continua disponível.

• Interrupção regional:o gerenciador de chaves externas do Cloud não está disponível durante uma interrupção temporária regional na região afetada. Não há mecanismo de failover que redirecione solicitações entre regiões. Recomendamos que os clientes usem várias regiões para executar os jobs.

O gerenciador de chaves externas do Cloud não armazena dados de clientes persistentemente. Portanto, não há perda de dados durante uma interrupção temporária regional no sistema gerenciador de chaves externas do Cloud. No entanto, o gerenciador de chaves externas do Cloud depende da disponibilidade de outros serviços, como o Cloud Key Management Service e de fornecedores externos. Se esses sistemas interrupçãorem durante uma interrupção temporária regional, você poderá perder dados. O RPO/RTO desses sistemas está fora do escopo dos compromissos do gerenciador de chaves externas do Cloud.

Cloud Load Balancing

O Cloud Load Balancing é um serviço gerenciado, totalmente distribuído e definido por software. Com o Cloud Load Balancing, um único endereço IP anycast pode servir como front-end para back-ends em regiões do mundo todo. Ele não é baseado em hardware, então você não precisa gerenciar uma infraestrutura física de balanceamento de carga. Os balanceadores de carga são componentes essenciais da maioria dos aplicativos.

O Cloud Load Balancing oferece balanceadores de carga regionais e globais. Ele também oferece balanceamento de carga entre regiões com failover automático multirregional, que redireciona o tráfego para os back-ends de failover quando os back-ends principais não estão íntegros.

Os balanceadores de carga globais são resilientes a falhas temporárias regionais e zonais. Os balanceadores de carga regionais são resilientes a falhas temporárias zonais, mas são afetados por interrupções na região deles. No entanto, em ambos os casos, é importante entender que a resiliência do seu aplicativo geral depende não apenas do tipo de balanceador de carga que você implanta, mas também da redundância dos back-ends.

Para mais informações, consulte Visão geral do Cloud Load Balancing.

Cloud Logging

O Cloud Logging consiste em duas partes principais: o roteador de registros e o armazenamento do Cloud Logging.

O roteador de registros processa os eventos de registro de streaming e direciona os registros para o Cloud Storage, Pub/Sub, BigQuery ou armazenamento do Cloud Logging.

O armazenamento do Cloud Logging é um serviço para armazenar, consultar e gerenciar a conformidade de registros. Ele é compatível com muitos usuários e fluxos de trabalho, incluindo desenvolvimento, conformidade, solução de problemas e alertas proativos.

Logs Router e registros de entrada: durante uma interrupção zonal, a API Cloud Logging encaminha registros para outras zonas na região. Normalmente, os registros que são roteados do roteador de registros para o Cloud Logging, BigQuery ou Pub/Sub são gravados no destino final assim que possível, enquanto os registros enviados ao Cloud Storage são armazenados em buffer e gravados em lotes por hora.

Entradas de registro: em caso de interrupção temporária ou regional, as entradas de registro que foram armazenadas em buffer na zona ou região afetada e não foram gravadas no destino de exportação ficam inacessíveis. As métricas com base em registros também são calculadas no Roteador de registros e estão sujeitas às mesmas restrições. Uma vez entregues ao local de exportação do registro selecionado, os registros serão replicados de acordo com o serviço de destino. Os registros exportados para o armazenamento do Cloud Logging são replicados de maneira síncrona em duas zonas em uma região. Para ver o comportamento de replicação de outros tipos de destino, consulte a seção relevante neste artigo. Os registros exportados para o Cloud Storage são agrupados e gravados a cada hora. Portanto, recomendamos usar o armazenamento do Cloud Logging, BigQuery ou Pub/Sub para minimizar a quantidade de dados afetada por uma interrupção.

Metadados de registro: metadados como a configuração de coletor e exclusão são armazenados globalmente, mas armazenados em cache regionalmente. Em caso de interrupção, as instâncias do roteador de registro regional operariam. Falhas de região única não têm impacto fora da região.

Cloud Monitoring

O Cloud Monitoring consiste em uma variedade de recursos interconectados, como painéis (integrados e definidos pelo usuário), alertas e monitoramento de tempo de atividade.

Todas as configurações do Cloud Monitoring, incluindo painéis, verificações de tempo de atividade e políticas de alertas, são definidas globalmente. Todas as alterações feitas nelas são replicadas de maneira síncrona para várias regiões. Portanto, durante interrupções temporárias zonais e regionais, as alterações de configuração bem-sucedidas são duráveis. Além disso, ainda que as falhas temporárias de leitura e gravação possam ocorrer quando uma zona ou região inicialmente falha, o Cloud Monitoring redireciona as solicitações para as zonas e regiões disponíveis. Nessa situação, você pode repetir as alterações de configuração com espera exponencial.

Ao gravar métricas para um recurso específico, primeiro o Cloud Monitoring identifica a região em que o recurso reside. Em seguida, ele grava três réplicas independentes dos dados de métrica na região. A gravação geral da métrica regional é retornada como bem-sucedida assim que uma das três gravações zonais for bem-sucedida. Não há garantia de que as três réplicas estejam em zonas diferentes dentro da região.

• Por zona: durante uma interrupção de zona, as gravações e leituras de métricas estão completamente indisponíveis para recursos na zona afetada. Efetivamente, o Cloud Monitoring atua como se a zona afetada não existisse.

• Regional: durante uma interrupção regional, as gravações e leituras de métricas ficam totalmente indisponíveis para recursos na região afetada. Efetivamente, o Cloud Monitoring atua como se a região afetada não existisse.

Cloud NAT

O Cloud NAT (conversão de endereços de rede) é um serviço gerenciado definido por software que permite que determinados recursos sem endereços IP externos criem conexões de saída com a Internet. Ele não é baseado em VMs ou dispositivos de proxy. O Cloud NAT configura o software Andromeda que alimenta a rede de nuvem privada virtual (VPC, na sigla em inglês) para que ela forneça conversão de endereços de rede de origem (NAT ou SNAT de origem) para VMs sem endereços IP externos. O Cloud NAT também fornece conversão de endereços de rede de destino, (NAT ou DNAT de origem), para pacotes de resposta de entrada estabelecidos.

Para mais informações sobre a funcionalidade do Cloud NAT, consulte a documentação.

Interrupção zonal: o Cloud NAT é resiliente a falhas zonais porque o plano de controle e o plano de dados de rede são redundantes em várias zonas de uma região.

Interrupção regional: o Cloud NAT é um produto regional, portanto, não pode suportar uma falha regional.

Cloud Router

O Cloud Router é um serviço do Google Cloud totalmente distribuído e gerenciado que usa o Border Gateway Protocol (BGP) para divulgar intervalos de endereços IP. Ele programa rotas dinâmicas personalizadas com base nas divulgações do BGP recebidas de um par. Em vez de uma ferramenta ou dispositivo físico, cada Cloud Router é composto de tarefas de software que atuam como alto-falantes e participantes do BGP.

No caso de uma falha temporária zonal, o Cloud Router com uma configuração de alta disponibilidade (HA) é resiliente a falhas zonais. Nesse caso, uma interface pode perder a conectividade, mas o tráfego é redirecionado para outra interface pelo roteamento dinâmico usando o BGP.

No caso de uma interrupção regional, o Cloud Router é um produto regional, portanto, não pode suportar uma falha regional. Se os clientes tiverem ativado o modo de roteamento global, o roteamento entre a região com falha e outras regiões poderá ser afetado.

Cloud Run

O Cloud Run é um ambiente de computação sem estado em que os clientes podem executar o código em contêiner na infraestrutura do Google. O Cloud Run é uma oferta regional, ou seja, os clientes podem escolher a região, mas não as zonas que compõem uma região. Os dados e o tráfego são balanceados automaticamente entre as zonas de uma região. As instâncias de contêiner são escalonadas automaticamente para atender ao tráfego de entrada e têm a carga balanceada nas zonas conforme necessário. Cada zona mantém um programador que fornece esse escalonamento automático por zona. Ele também está ciente da carga que outras zonas estão recebendo e provisiona capacidade extra na zona para permitir falhas zonais.

Falha temporária zonal: o Cloud Run armazena metadados, assim como o contêiner implantado. Esses dados são armazenados regionalmente e gravados de maneira síncrona. A API Cloud Run Admin só retorna a chamada de API depois que os dados são confirmados em um quórum dentro de uma região. Como os dados são armazenados em regiões, as operações do plano de dados também não são afetadas por falhas zonais. O tráfego será roteado automaticamente para outras zonas no caso de uma falha zonal.

Falha temporária regional: os clientes escolhem a região do Google Cloud em que querem criar o serviço do Cloud Run. Os dados jamais são replicados entre regiões. O tráfego do cliente nunca vai ser roteado para uma região diferente pelo Cloud Run. Em caso de falha regional, o Cloud Run volta a ficar disponível assim que a falha é resolvida. Recomendamos aos clientes implantar em várias regiões e usar o Cloud Load Balancing para conseguir maior disponibilidade, se precisarem.

Cloud Run for Anthos

O Cloud Run for Anthos é um serviço global que permite aos os clientes executarem cargas de trabalho sem servidor nos clusters dos clientes. A finalidade dele é garantir que as cargas de trabalho do Cloud Run for Anthos sejam implantadas corretamente nos clusters dos clientes e que o status da instalação do Cloud Run for Anthos seja refletido nos recursos de assinatura da API OnePlatform. Esse serviço participa apenas da instalação ou do upgrade de recursos do Cloud Run for Anthos nos clusters dos clientes. Ele não está envolvido na execução de cargas de trabalho do cluster. Os clusters dos clientes que pertencem a projetos com o Cloud Run for Anthos ativado são distribuídos entre réplicas em várias regiões e zonas. Cada cluster é monitorado por uma única réplica.

Interrupção do serviço zonal e regional: os clusters monitorados por réplicas que foram hospedados em um local passando por uma interrupção do serviço são redistribuídos automaticamente entre réplicas íntegras em outras zonas e regiões. Enquanto essa reatribuição estiver em andamento, pode haver um curto período em que alguns clusters não são monitorados pelo Cloud Run for Anthos. Se, durante esse período, o usuário decidir ativar os recursos do Cloud Run for Anthos no cluster, a instalação desses recursos começará quando o cluster se reconectar a uma réplica de serviço íntegra do Cloud Run for Anthos.

Cloud Shell

O Cloud Shell oferece aos usuários do Google Cloud acesso a instâncias de usuário único do Compute Engine pré-configuradas para tarefas de integração, educação, desenvolvimento e operador.

O Cloud Shell não é adequado para executar cargas de trabalho de aplicativos. Em vez disso, ele se destina a casos de uso educacionais e de desenvolvimento interativo. Ele tem limites de cota de execução por usuário, é encerrado automaticamente após um curto período de inatividade e a instância é acessível apenas para o usuário atribuído.

As instâncias do Compute Engine que apoiam o serviço são recursos zonais. Portanto, no caso de uma interrupção zonal, o Cloud Shell de um usuário fica indisponível.

Cloud Source Repositories

O Cloud Source Repositories permite que os usuários criem e gerenciem repositórios de códigos-fonte particulares. Este produto foi projetado com um modelo global, portanto, você não precisa configurá-lo para resiliência regional ou zonal.

Em vez disso, as operações git push no Cloud Source Repositories replicam de maneira síncrona a atualização do repositório de origem para várias zonas em várias regiões. Isso significa que o serviço é resiliente a interrupções em qualquer região.

Se uma zona ou região específica sofrer uma interrupção, o tráfego será distribuído automaticamente para outras zonas ou regiões.

O recurso para espelhar automaticamente repositórios do GitHub ou do Bitbucket pode ser afetado por problemas nesses produtos. Por exemplo, o espelhamento será afetado se o GitHub ou o Bitbucket não conseguirem alertar o Cloud Source Repositories sobre novas confirmações ou se o Cloud Source Repositories não puder recuperar conteúdo do repositório atualizado.

Spanner

O Spanner é um banco de dados escalonável, altamente disponível, multiversão, replicado de maneira síncrona e fortemente consistente com semântica relacional.

As instâncias regionais do Spanner replicam os dados de maneira síncrona em três zonas de uma única região. Uma gravação em uma instância regional do Spanner é enviada de maneira síncrona para todas as três réplicas e confirmada para o cliente depois de pelo menos duas réplicas (maioria de quórum de 2 de 3) terem confirmado a gravação. Isso torna o Spanner resiliente a falhas de zona ao fornecer acesso a todos os dados, uma vez que as gravações mais recentes foram mantidas e a maioria de quórum para gravações ainda pode ser alcançada com duas réplicas.

As instâncias multirregionais do Spanner incluem um quórum de gravação que replica dados de maneira síncrona em cinco zonas localizadas em três regiões (duas réplicas de leitura e gravação cada na região líder padrão e em outra região e uma réplica na região testemunha). Uma gravação em uma instância multirregional do Spanner é confirmada após pelo menos três réplicas (maioria de quórum de 3 de 5) terem confirmado a gravação. No caso de uma falha de zona ou região, o Spanner tem acesso a todos os dados (incluindo gravações mais recentes) e atende a solicitações de leitura/gravação, já que os dados são mantidos em pelo menos três zonas em duas regiões no momento em que a gravação é confirmada para o cliente.

Consulte a documentação sobre instâncias do Spanner para mais informações sobre essas configurações. Para mais informações sobre como funciona a replicação do Spanner, consulte a documentação sobre replicação.

Cloud SQL

O Cloud SQL é um serviço de banco de dados relacional totalmente gerenciado para MySQL, PostgreSQL e SQL Server. O Cloud SQL usa máquinas virtuais gerenciadas do Compute Engine para executar o software do banco de dados. Ele oferece uma configuração de alta disponibilidade para redundância regional, protegendo o banco de dados contra uma interrupção na zona. As réplicas entre regiões podem ser provisionadas para proteger o banco de dados contra uma interrupção regional. Como o produto também oferece uma opção de zona, que não é resiliente a uma interrupção de zona ou região, tenha o cuidado para selecionar a configuração de alta disponibilidade ou as réplicas entre regiões (ou ambas).

Interrupção zonal: a opção de alta disponibilidade cria uma instância de VM principal e em espera em duas zonas separadas em uma região. Durante a operação normal, a instância de VM primária atende a todas as solicitações, gravando arquivos de banco de dados em um disco permanente regional, que é replicado de maneira síncrona para as zonas principal e de espera. Se uma interrupção de zona afetar a instância principal, o Cloud SQL iniciará um failover durante o qual o Persistent Disk será anexado à VM em espera e o tráfego será roteado novamente.

Durante esse processo, o banco de dados precisa ser inicializado, o que inclui o processamento de quaisquer transações gravadas no registro de transações, mas não aplicadas ao banco de dados. A quantidade e o tipo de transações não processadas podem aumentar o tempo de RTO. Altas gravações recentes podem levar a um backlog de transações não processadas. O tempo de RTO é muito mais afetado por (a) atividade de alta gravação recente e (b) alterações recentes em esquemas de banco de dados.

Por fim, quando a interrupção zonal é resolvida, acione manualmente uma operação de failback para retomar a exibição na zona principal.

Para mais detalhes sobre a opção de alta disponibilidade, consulte a documentação de alta disponibilidade do Cloud SQL.

Interrupção regional: a opção réplica entre regiões protege o banco de dados contra interrupções regionais criando réplicas de leitura da instância principal em outras regiões. A replicação entre regiões usa replicação assíncrona, o que permite que a instância primária confirme transações antes de serem confirmadas em réplicas. A diferença de tempo entre o momento em que uma transação é confirmada na instância primária e quando é realizada na réplica é conhecida como "atraso da replicação" (que pode ser monitorada). Essa métrica reflete as transações que não foram enviadas do primário para as réplicas, bem como as transações que foram recebidas, mas não foram processadas pela réplica. As transações não enviadas para a réplica ficariam indisponíveis durante uma interrupção regional. As transações recebidas, mas não processadas pela réplica, afetam o tempo de recuperação, conforme descrito abaixo.

O Cloud SQL recomenda testar a carga de trabalho com uma configuração que inclua uma réplica para estabelecer um limite de "transações seguras por segundo (TPS)", que é o maior TPS sustentado que não acumula atraso de replicação. Se sua carga de trabalho exceder o limite seguro de TPS, o atraso da replicação será acumulado, afetando negativamente os valores de RPO e RTO. Como orientação geral, evite usar configurações de instância pequenas (<2 núcleos de vCPU, <100 GB de discos ou DP-HDD), que são suscetíveis a atrasos de replicação.

No caso de uma interrupção regional, você precisa decidir se quer promover manualmente uma réplica de leitura. Essa é uma operação manual porque uma promoção pode causar um cenário de dupla personalidade, em que a réplica promovida aceita novas transações, mesmo que tenha atrasado a instância principal no momento da promoção. Isso pode causar problemas quando a falha regional é resolvida e você precisa reconciliar as transações que nunca foram propagadas do primário para as instâncias de réplica. Se isso for problemático para suas necessidades, considere um produto de banco de dados de replicação síncrona entre regiões, como o Spanner.

Depois de acionado pelo usuário, o processo de promoção segue etapas semelhantes à ativação de uma instância de espera na configuração de alta disponibilidade. Nesse processo, a réplica de leitura precisa processar o registro de transações, o que aumenta o tempo total de recuperação. Como não há um balanceador de carga integrado envolvido na promoção da réplica, redirecione manualmente os aplicativos para o primário promovido.

Para mais detalhes sobre a opção de réplica entre regiões, consulte a documentação sobre réplica entre regiões do Cloud SQL.

Para mais informações sobre o DR do Cloud SQL, consulte:

• Recuperação de desastres do banco de dados do Cloud SQL para MySQL
• Recuperação de desastres do banco de dados do Cloud SQL para PostgreSQL
• Recuperação de desastres do banco de dados do Cloud SQL para SQL Server

Cloud Storage

O Cloud Storage fornece, em todo o mundo, um armazenamento de objetos altamente unificado, escalonável e altamente durável. Os buckets do Cloud Storage podem ser criados em um dos três tipos diferentes de local: em uma única região, em uma região birregional ou em uma multirregião em um continente. Com os buckets regionais, os objetos são armazenados de maneira redundante nas zonas de disponibilidade em uma única região. Os buckets birregionais e multirregionais, por outro lado, têm redundância geográfica. Isso significa que, após a replicação de dados recém-gravados em pelo menos uma região remota, os objetos são armazenados de maneira redundante em todas as regiões. Essa abordagem oferece aos dados em buckets birregionais e multirregionais um conjunto mais amplo de proteções do que o armazenamento regional.

Os buckets regionais foram projetados para ser resilientes em caso de falha temporária em uma única zona de disponibilidade. Se uma zona sofrer uma interrupção, os objetos na zona indisponível serão exibidos de maneira automática e transparente de qualquer outro lugar na região. Os dados e metadados são armazenados de maneira redundante entre as zonas, começando com a gravação inicial. Nenhuma gravação é perdida se uma zona ficar indisponível. No caso de uma interrupção regional, os buckets regionais nessa região ficam off-line até que a região fique disponível novamente.

Se precisar de maior disponibilidade, armazene dados em uma configuração birregional ou multirregional. Os buckets birregionais e multirregionais são buckets únicos (sem locais principais e secundários separados), mas armazenam dados e metadados de maneira redundante em todas as regiões. No caso de uma interrupção regional, o serviço não é interrompido. Pense nos buckets birregionais e multirregionais como ativos-ativos em que é possível ler e gravar cargas de trabalho em mais de uma região simultaneamente, enquanto o bucket se mantém consistentemente forte. Isso pode ser muito atraente para clientes que queiram dividir a carga de trabalho entre as duas regiões como parte de uma arquitetura de recuperação de desastres.

As regiões birregionais e multirregionais são altamente consistentes, porque os metadados são sempre gravados de maneira síncrona nas regiões. Essa abordagem permite que o serviço sempre determine qual é a versão mais recente de um objeto e de onde ele pode ser exibido, inclusive de regiões remotas.

Os dados são replicados de forma assíncrona. Isso significa que há uma janela de tempo do RPO em que objetos recém-gravados começam a ser protegidos como objetos regionais, com redundância nas zonas de disponibilidade em uma única região. Em seguida, o serviço replica os objetos dentro dessa janela do RPO para uma ou mais regiões remotas, para torná-los geograficamente redundantes. Após a conclusão dessa replicação, os dados podem ser exibidos de forma automática e transparente de outra região no caso de uma interrupção regional. A replicação turbo é um recurso premium disponível em um bucket birregional para receber uma janela do RPO menor, que tem como objetivo 100% dos objetos recém-gravados que são replicados e tornados geograficamente redundantes em 15 minutos.

O RPO é uma consideração importante, porque durante uma interrupção regional, os dados gravados recentemente na região afetada dentro da janela do RPO talvez ainda não tenham sido replicados para outras regiões. Como resultado, esses dados podem não estar acessíveis durante a interrupção e podem ser perdidos em caso de destruição física dos dados na região afetada.

Cloud Translation

O Cloud Translation tem servidores de computação ativos em várias zonas e regiões. Também é compatível com a replicação síncrona de dados entre zonas nas regiões. Esses recursos ajudam o Translation a atingir um failover instantâneo sem perda de dados para falhas zonais e sem exigir entrada ou ajuste de clientes. Em caso de falha regional, o Cloud Translation não está disponível.

Compute Engine

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

As instâncias do Compute Engine são recursos zonais. Portanto, em caso de interrupção de uma zona, elas não estão disponíveis por padrão. O Compute Engine oferece grupos de instâncias gerenciadas (MIGs), que escalonam automaticamente VMs extras usando modelos de instância pré-configurados, tanto em uma quanto em várias zonas dentro de uma região. Os MIGs são ideais para aplicativos que exigem resiliência a perda de zona e não têm estado, mas exigem planejamento de configuração e recurso. É possível usar vários MIGs regionais para alcançar a resiliência de interrupções de região nos aplicativos sem estado.

Os aplicativos que têm cargas de trabalho com estado ainda podem usar MIGs com estado, mas precisam de cuidados extras em planejamento de capacidade, já que não são escalonados horizontalmente. É importante que, em qualquer um dos cenários, você configure e teste corretamente os modelos de instância do Compute Engine e os MIGs com antecedência, para garantir que os recursos de failover funcionem para outras zonas. Consulte a seção Desenvolver suas próprias arquiteturas e guias de referência acima para mais informações.

Locatário único

O locatário individual permite que você tenha acesso exclusivo a um nó de locatário individual, que é um servidor físico do Compute Engine dedicado a hospedar apenas as VMs do projeto.

Os nós de locatário individual, como as instâncias do Compute Engine, são recursos zonais. No caso improvável de uma interrupção zonal, eles ficam indisponíveis. Para reduzir as falhas zonais, crie um nó de locatário individual em outra zona. Como determinadas cargas de trabalho podem se beneficiar dos nós de locatário individual para fins de licenciamento ou contabilidade CAPEX, você precisa planejar uma estratégia de failover com antecedência.

A recriação desses recursos em um local diferente pode gerar custos de licenciamento adicional ou violar os requisitos de contabilidade do CAPEX. Para orientações gerais, consulte Desenvolver suas próprias arquiteturas e guias de referência.

Os nós de locatário individual são recursos zonais e não podem suportar falhas regionais. Para escalonar entre zonas, use MIGs regionais.

Rede para o Compute Engine

Para informações sobre configurações de alta disponibilidade para conexões do Interconnect, consulte os seguintes documentos:

• 99,99% de disponibilidade na Interconexão dedicada
• 99,99% de disponibilidade na Interconexão por parceiro

É possível provisionar endereços IP externos no modo global ou regional, o que afeta a disponibilidade deles em caso de falha regional.

Resiliência do Cloud Load Balancing

Os balanceadores de carga são componentes essenciais da maioria dos aplicativos. É importante entender que a resiliência do aplicativo geral depende não apenas do escopo do balanceador de carga escolhido (global ou regional), mas também da redundância dos serviços de back-end.

A tabela a seguir resume a resiliência do balanceador de carga com base na distribuição ou no escopo do balanceador de carga.

Escopo do balanceador de carga	Arquitetura	Resiliente a interrupção de zona	Resiliente a interrupção regional
Global	Cada balanceador de carga é distribuído em todas as regiões
Entre regiões	Cada balanceador de carga é distribuído em várias regiões
Regional	Cada balanceador de carga é distribuído em várias zonas na região		Uma interrupção em uma determinada região afeta os balanceadores de carga regionais nessa região.

Para mais informações sobre como escolher um balanceador de carga, consulte a documentação do Cloud Load Balancing.

Testes de conectividade

Os Testes de conectividade são uma ferramenta de diagnóstico que permite verificar a conectividade entre os endpoints da rede. Ela analisa a configuração e, em alguns casos, realiza uma análise de plano de dados em tempo real entre os endpoints. Um endpoint é uma origem ou um destino de tráfego de rede, como uma VM, um cluster do Google Kubernetes Engine (GKE), uma regra de encaminhamento do balanceador de carga ou um endereço IP. Os Testes de conectividade são uma ferramenta de diagnóstico sem componentes do plano de dados. Ela não processa nem gera tráfego de usuários.

Interrupção do serviço zonal: os recursos dos Testes de conectividade são globais. É possível gerenciá-las e visualizá-las no caso de uma interrupção do serviço zonal. Os recursos dos Testes de conectividade são os resultados dos seus testes de configuração. Esses resultados podem incluir os dados de configuração de recursos zonais (por exemplo, instâncias de VM) em uma zona afetada. Se houver uma interrupção do serviço, os resultados da análise não serão precisos, porque a análise é baseada em dados desatualizados anteriores à interrupção do serviço. Não confie neles.

Interrupção do serviço regional: em uma interrupção do serviço regional, ainda é possível gerenciar e visualizar os recursos dos Testes de conectividade. Os recursos dos Testes de conectividade podem incluir dados de configuração de recursos regionais, como sub-redes, em uma região afetada. Se houver uma interrupção do serviço, os resultados da análise não serão precisos, porque a análise é baseada em dados desatualizados anteriores à interrupção do serviço. Não confie neles.

Container Registry

O Container Registry fornece uma implementação hospedada do Docker Registry escalonável que armazena com segurança e privacidade as imagens de contêineres do Docker. O Container Registry implementa a API HTTP Docker Registry (em inglês).

O Container Registry é um serviço global que armazena, de maneira síncrona, metadados de imagens de maneira redundante em várias zonas e regiões. As imagens de contêiner são armazenadas em buckets multirregionais do Cloud Storage. Com essa estratégia de armazenamento, o Container Registry oferece resiliência de interrupção de zona em todos os casos e resistência regional a qualquer dado que foi replicado de maneira assíncrona para várias regiões pelo Cloud Storage.

Database Migration Service

O Database Migration Service é um serviço totalmente gerenciado do Google Cloud para migrar bancos de dados de outros provedores de nuvem ou de data centers locais para o Google Cloud.

O Database Migration Service é arquitetado como plano de controle regional. O plano de controle não depende de uma zona individual em uma determinada região. Durante uma interrupção de zona, você mantém o acesso às APIs do Database Migration Service, incluindo a capacidade de criar e gerenciar jobs de migração. Durante uma interrupção regional, você perde o acesso aos recursos do Database Migration Service que pertencem a essa região até que a interrupção seja resolvida.

O Database Migration Service depende da disponibilidade dos bancos de dados de origem e destino usados para o processo de migração. Se um banco de dados de origem ou de destino do Database Migration Service não estiver disponível, as migrações deixarão de progredir, mas nenhum dado de núcleo ou job do cliente será perdido. Os jobs de migração são retomados quando os bancos de origem e destino são disponibilizados novamente.

Por exemplo, é possível configurar um banco de dados de destino do Cloud SQL com alta disponibilidade (HA, na sigla em inglês) ativada para receber um banco de dados de destino resiliente a interrupções zonais.

As migrações do Database Migration Service passam por duas fases:

• Despejo completo: executa uma cópia completa dos dados da origem para o destino, de acordo com a especificação do job de migração.
• Captura de dados alterados (CDC): replica alterações incrementais da origem ao destino.

Interrupção zonal: se ocorrer uma falha zonal durante qualquer uma dessas fases, você ainda poderá acessar e gerenciar recursos no Database Migration Service. A migração de dados é afetada da seguinte maneira:

• Despejo completo: falha na migração de dados é necessário reiniciar o job de migração depois que o banco de dados de destino concluir a operação de failover.
• CDC: a migração de dados está pausada. O job de migração é retomado automaticamente assim que o banco de dados de destino conclui a operação de failover.

Interrupção regional: o Database Migration Service não é compatível com recursos inter-regionais e, portanto, não é resiliente contra falhas regionais.

Dataflow

O Dataflow é o serviço de processamento de dados sem servidor e totalmente gerenciado do Google Cloud para pipelines de streaming e em lote. Por padrão, um endpoint regional configura o pool de workers do Dataflow para utilizar todas as zonas disponíveis na região. A seleção de zona é calculada para cada worker no momento em que ele é criado, com base na otimização da aquisição de recursos e do uso de reservas não usadas. Na configuração padrão dos jobs do Dataflow, os dados intermediários são armazenados pelo serviço do Dataflow e o estado do job é armazenado no back-end. Se uma zona falhar, os jobs do Dataflow poderão continuar em execução, porque os workers serão recriados em outras zonas.

Considere as seguintes limitações:

• O posicionamento regional oferece suporte apenas para jobs que usam o Streaming Engine ou o Dataflow Shuffle. Os jobs que desativaram o Streaming Engine ou o Dataflow Shuffle não podem usar o posicionamento regional.
• O posicionamento regional se aplica somente a VMs. Ele não se aplica a recursos relacionados ao Streaming Engine e ao Dataflow Shuffle.
• As VMs não são replicadas em várias zonas. Se uma VM ficar indisponível, os itens de trabalho serão considerados perdidos e serão reprocessados por outra VM.
• Se ocorrer um esgotamento em toda a região, o serviço Dataflow não poderá criar mais VMs.

Como arquitetar os pipelines do Dataflow para alta disponibilidade

É possível executar vários pipelines de streaming em paralelo para processamento de dados de alta disponibilidade. Por exemplo, é possível executar dois jobs de streaming paralelos em diferentes regiões. A execução de pipelines paralelos fornece redundância geográfica e tolerância a falhas para o processamento de dados. Ao considerar a disponibilidade geográfica de fontes de dados e coletores, é possível operar pipelines completos em uma configuração multirregional altamente disponível. Para mais informações, consulte Alta disponibilidade e redundância geográfica em "Projetar fluxos de trabalho de pipeline do Dataflow".

No caso de interrupção da zona ou região, é possível evitar a perda de dados reutilizando a mesma assinatura no tópico do Pub/Sub. Para garantir que os registros não sejam perdidos durante o embaralhamento, o Dataflow usa o backup upstream, o que significa que o worker que envia os registros repete as RPCs até receber uma confirmação positiva de que o registro foi recebido e os efeitos colaterais do processamento do registro foram confirmados no armazenamento permanente downstream. O Dataflow também continuará tentando realizar RPCs se o worker que estiver enviando os registros ficar indisponível. Tentar realizar RPCs novamente garante que cada registro seja entregue exatamente uma vez. Para mais informações sobre a garantia de entrega única do Dataflow, consulte Entrega única no Dataflow.

Se o pipeline estiver usando agrupamento ou janelas de tempo, será possível usar a funcionalidade de busca da funcionalidade Pub/Sub ou Repetição do Kafka após uma interrupção por zona ou região para processar novamente os elementos de dados para chegar ao mesmo resultado resultados de cálculos. Se a lógica de negócios usada pelo pipeline não depender de dados anteriores à interrupção, a perda de dados das saídas do pipeline poderá ser minimizada até 0 elemento. Se a lógica de negócios do pipeline depender dos dados processados antes da interrupção (por exemplo, se forem usadas janelas deslizantes longas ou se uma janela de tempo global estiver armazenando contadores cada vez maiores), use Snapshots do Dataflow para salvar o estado do pipeline de streaming e iniciar uma nova versão do job sem perder o estado.

Dataproc

O Dataproc fornece recursos de streaming e processamento de dados em lote. O Dataproc é arquitetado como um plano de controle regional em que os usuários gerenciam clusters do Dataproc. O plano de controle não depende de uma zona individual em uma determinada região. Portanto, durante uma interrupção de zona, você mantém o acesso às APIs do Dataproc, incluindo a capacidade de criar novos clusters.

É possível criar clusters do Dataproc em:

• Clusters do Dataproc no Compute Engine
• Clusters do Dataproc no GKE

Clusters do Dataproc no Compute Engine

Como um cluster do Dataproc no Compute Engine é um recurso zonal, uma interrupção zonal torna o cluster indisponível ou o destrói. O Dataproc não cria snapshots do status do cluster automaticamente. Portanto, uma interrupção na zona pode causar a perda dos dados que estão sendo processados. O Dataproc não mantém os dados do usuário no serviço. Os usuários podem configurar os pipelines para gravar resultados em muitos armazenamentos de dados. Pense na arquitetura do armazenamento de dados e escolha um produto que ofereça a resiliência de desastres necessária.

Se uma zona sofrer uma interrupção, é possível optar por recriar uma nova instância do cluster em outra zona, selecionando uma zona diferente ou usando o recurso de colocação automática no Dataproc para selecionar automaticamente uma zona disponível. Quando o cluster estiver disponível, o processamento de dados poderá ser retomado. Também é possível executar um cluster com o modo de alta disponibilidade ativado, reduzindo a probabilidade de uma interrupção de zona parcial afetar um nó mestre e, portanto, todo o cluster.

Clusters do Dataproc no GKE

Os clusters do Dataproc no GKE podem ser zonais ou regionais.

Para mais informações sobre a arquitetura e os recursos de DR dos clusters do GKE zonais e regionais, consulte a seção do Google Kubernetes Engine mais adiante neste documento.

Document AI

A Document AI é uma plataforma de compreensão de documentos que pega dados não estruturados de documentos e os transforma em dados estruturados, facilitando o entendimento, a análise e o consumo. A Document AI é uma oferta regional. Os clientes podem escolher a região, mas não as zonas dela. Os dados e o tráfego são balanceados automaticamente entre as zonas de uma região. As funções são escalonadas automaticamente para atender ao tráfego de entrada e têm a carga balanceada entre zonas conforme necessário. Cada zona mantém um programador que fornece esse escalonamento automático por zona. O programador também está ciente da carga que outras zonas estão recebendo e provisiona capacidade extra na zona para permitir falhas zonais.

interrupção temporária por zona: a Document AI armazena documentos do usuário e dados de versão do processador. Esses dados são armazenados por região e gravados de forma síncrona. Como os dados são armazenados por região, as operações do plano de dados não são afetadas por falhas zonais. O tráfego é encaminhado automaticamente para outras zonas em caso de falha de zona, com um atraso baseado no tempo que serviços dependentes, como a Vertex AI, levam para se recuperar.

Interrupção regional:os dados nunca são replicados entre regiões. Durante uma interrupção regional, a Document AI não fará failover. Os clientes escolhem a região do Google Cloud em que querem usar a Document AI. No entanto, esse tráfego do cliente nunca é roteado para outra região.

Verificação de endpoints

A Verificação de endpoints permite que administradores e profissionais de operações de segurança criem um inventário de dispositivos que acessam os dados de uma organização. A Verificação de endpoints também fornece confiabilidade crítica de dispositivo e controle de acesso baseado em segurança como parte da solução da BeyondCorp Enterprise.

Use a Verificação de endpoints quando quiser uma visão geral do estado da segurança dos laptops e computadores da sua organização. Quando a Verificação de endpoints é pareada com as ofertas da BeyondCorp Enterprise, ela ajuda a aplicar um controle de acesso refinado aos recursos do Google Cloud.

A Verificação de endpoints está disponível para Google Cloud, Cloud Identity, Google Workspace Business e Google Workspace Enterprise.

Eventarc

O Eventarc fornece eventos fornecidos de maneira assíncrona de provedores do Google (próprios), apps de usuário (de terceiros) e software como serviço (de terceiros) usando serviços com acoplamento flexível que reagem a mudanças de estado. Ele permite que os clientes configurem os destinos deles (por exemplo, uma instância do Cloud Run ou uma Função do Cloud de segunda geração) para serem acionados quando um evento ocorrer em um serviço de provedor de eventos ou no código do cliente.

Interrupção zonal: o Eventarc armazena metadados relacionados a acionadores. Esses dados são armazenados por região e gravados de forma síncrona. A API Eventarc que cria e gerencia gatilhos e canais só retorna a chamada de API quando os dados foram confirmados em um quórum dentro de uma região. Como os dados são armazenados por região, as operações do plano de dados não são afetadas por falhas zonais. No caso de uma falha zonal, o tráfego é roteado automaticamente para outras zonas. Os serviços do Eventarc para receber e entregar eventos de terceiros e de terceiros são replicados nas zonas. Esses serviços são distribuídos por região. As solicitações para zonas indisponíveis são automaticamente disponibilizadas a partir de zonas disponíveis na região.

Interrupção regional: os clientes escolhem a região do Google Cloud em que querem criar os gatilhos do Eventarc. Os dados jamais são replicados entre regiões. O tráfego de clientes nunca é roteado pelo Eventarc para uma região diferente. No caso de uma falha regional, o Eventarc é disponibilizado novamente assim que a interrupção é resolvida. Para ter maior disponibilidade, é recomendável que os clientes implantem acionadores em várias regiões, se quiserem.

Observações:

• Os serviços do Eventarc para receber e entregar eventos próprios são fornecidos da melhor maneira possível e não são cobertos pelo RTO/RPO.
• A entrega de eventos do Eventarc para os serviços do Google Kubernetes Engine é fornecida com base no melhor esforço e não é coberta pelo RTO/RPO.

Filestore

Os níveis Básico e HighScale são recursos zonais. Eles não são tolerantes a falhas da zona ou região implantada.

As instâncias de nível Enterprise do Filestore são recursos regionais. O Filestore adota a política de consistência rigorosa exigida pelo NFS. Quando um cliente grava dados, o Filestore não retorna uma confirmação até que a alteração seja mantida e replicada em duas zonas para que as leituras subsequentes retornem os dados corretos.

Em caso de falha na zona, uma instância de nível Enterprise continua a disponibilizar dados de outras zonas e, nesse meio tempo, aceita novas gravações. As operações de leitura e gravação podem ter um desempenho prejudicado, a operação de gravação pode não ser replicada. A criptografia não é comprometida porque a chave será disponibilizada por outras zonas.

Recomendamos que os clientes criem backups externos em caso de novas interrupções em outras zonas da mesma região. O backup pode ser usado para restaurar a instância em outras regiões.

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. O Firestore oferece replicação automática de dados em várias regiões, fortes garantias de consistência, operações atômicas em lote e transações ACID.

O Firestore oferece locais regionais e multirregionais aos clientes. O tráfego tem a carga balanceada automaticamente entre zonas de uma região.

As instâncias regionais do Firestore replicam dados de maneira síncrona em pelo menos três zonas. No caso de falha zonal, as gravações ainda podem ser confirmadas pelas duas (ou mais) réplicas restantes, e os dados confirmados são mantidos. O tráfego roteia automaticamente para outras zonas. Um local regional oferece custos menores, latência de gravação mais baixa e colocalização com outros recursos do Google Cloud.

As instâncias multirregionais do Firestore replicam dados de maneira síncrona em cinco zonas em três regiões (duas regiões de veiculação e uma região de testemunha), e são robustas contra falhas zonais e regionais. No caso de falha zonal ou regional, os dados confirmados são mantidos. O tráfego encaminha automaticamente para zonas/regiões de veiculação, e as confirmações ainda são exibidas por pelo menos três zonas entre as duas regiões restantes. As multirregiões maximizam a disponibilidade e a durabilidade dos bancos de dados.

Firewall Insights

O Firewall Insights ajuda você a entender e otimizar suas regras de firewall. Ele fornece insights, recomendações e métricas sobre como suas regras de firewall estão sendo usadas. O Firewall Insights também usa machine learning para prever o uso futuro de regras de firewall. O Firewall Insights permite que você tome decisões melhores durante a otimização de regras de firewall. Por exemplo, o Firewall Insights identifica regras que ele classifica como excessivamente permissivas. É possível usar essas informações para tornar a configuração do firewall mais rigorosa.

Interrupção zonal: como os dados do Firewall Insights são replicados em zonas, eles não são afetados por uma interrupção zonal, e o tráfego do cliente é roteado automaticamente para outras zonas.

Interrupção regional: como os dados do Firewall Insights são replicados nas regiões, eles não são afetados por uma interrupção regional e o tráfego do cliente é roteado automaticamente para outras regiões.

Frota

As frotas permitem que os clientes gerenciem vários clusters do Kubernetes como um grupo e que os administradores da plataforma usem serviços de vários clusters. Por exemplo, as frotas permitem que os administradores apliquem políticas uniformes em todos os clusters ou configurem a Entrada em vários clusters.

Quando você registra um cluster do GKE a uma frota, por padrão, o cluster tem uma assinatura regional na mesma região. Ao registrar um cluster que não é do Google Cloud em uma frota, é possível escolher qualquer região ou local global. A prática recomendada é escolher uma região próxima à localização física do cluster. Isso fornece a latência ideal ao usar o gateway de conexão para acessar o cluster.

No caso de uma interrupção zonal, as funcionalidades da frota não são afetadas, a menos que o cluster subjacente seja zonal e fique indisponível.

No caso de interrupção regional, as funcionalidades da frota falham estaticamente para os clusters de assinatura na região. A mitigação de uma interrupção regional requer a implantação em várias regiões, conforme sugerido por Como arquitetar a recuperação de desastres para interrupções de infraestrutura em nuvem.

Google Cloud Armor

O Google Cloud Armor ajuda você a proteger suas implantações e aplicativos contra vários tipos de ameaças, incluindo ataques DDoS volumétricos e ataques a aplicativos, como scripting em vários locais e injeção de SQL. O Google Cloud Armor filtra o tráfego indesejado nos balanceadores de carga do Google Cloud e impede que ele entre na VPC e consuma recursos. Algumas dessas proteções são automáticas. Alguns exigem que você configure políticas de segurança e as anexe a serviços ou regiões de back-end. As políticas de segurança do Google Cloud Armor com escopo global são aplicadas em balanceadores de carga globais. As políticas de segurança com escopo regional são aplicadas a balanceadores de carga regionais.

Interrupção zonal: no caso de uma interrupção zonal, os balanceadores de carga do Google Cloud redirecionam o tráfego para outras zonas em que instâncias de back-end íntegras estão disponíveis. A proteção do Google Cloud Armor está disponível imediatamente após o failover do tráfego porque as políticas de segurança do Google Cloud Armor são replicadas de maneira síncrona em todas as zonas de uma região.

Interrupção regional: em caso de interrupções regionais, os balanceadores de carga globais do Google Cloud redirecionam seu tráfego para outras regiões onde instâncias de back-end íntegras estão disponíveis. A proteção do Google Cloud Armor está disponível imediatamente após o failover de tráfego porque as políticas de segurança globais do Google Cloud Armor são replicadas de maneira síncrona em todas as regiões. Para se proteger contra falhas regionais, configure as políticas de segurança regionais do Google Cloud Armor para todas as regiões.

Google Kubernetes Engine

O Google Kubernetes Engine (GKE) oferece serviços gerenciados do Kubernetes simplificando a implantação de aplicativos em contêineres no Google Cloud. É possível escolher entre topologias de cluster regionais ou zonais.

• Ao criar um cluster zonal, o GKE provisiona uma máquina de plano de controle na zona escolhida, bem como máquinas de worker (nós) na mesma zona.
• Para clusters regionais, o GKE provisiona três máquinas de controle em três zonas diferentes dentro da região escolhida. Por padrão, os nós também estão espalhados por três zonas, mesmo que você possa criar um cluster regional com nós provisionados apenas em uma zona.
• Os clusters de várias zonas são semelhantes aos clusters zonais, porque incluem uma máquina mestre, mas oferecem a capacidade de abranger nós em várias zonas.

Falha temporária por zona: para evitar interrupções zonais, use clusters regionais. O plano de controle e os nós são distribuídos em três zonas diferentes dentro de uma região. Uma interrupção de zona não afeta os nós de plano de controle e os workers de trabalho implantados nas outras duas zonas.

Interrupção regional: a mitigação de uma interrupção regional requer a implantação em várias regiões. Ainda que não seja oferecido como uma capacidade de produto integrada, a topologia multirregional é uma abordagem adotada por vários clientes do GKE hoje, e pode ser implementada manualmente. É possível criar vários clusters regionais para replicar suas cargas de trabalho em várias regiões e controlar o tráfego para esses clusters usando a entrada em vários clusters.

VPN de alta disponibilidade

A VPN de alta disponibilidade é uma oferta resiliente do Cloud VPN que criptografa com segurança o tráfego da nuvem privada no local, de outra nuvem privada virtual ou de outra rede de provedores de serviços de nuvem para a nuvem privada virtual (VPC, na sigla em inglês) do Google Cloud.

Os gateways da VPN de alta disponibilidade têm duas interfaces, cada uma com um endereço IP de pools de endereços IP separados, divididos logicamente e fisicamente em diferentes PoPs e clusters, para garantir a redundância ideal.

Interrupção zonal: no caso de uma interrupção zonal, uma interface pode perder conectividade, mas o tráfego é redirecionado para a outra interface pelo roteamento dinâmico usando o protocolo de gateway de borda (BGP, na sigla em inglês).

Interrupção regional: no caso de uma interrupção regional, as duas interfaces podem perder a conectividade por um breve período.

Identity and Access Management

O Identity and Access Management (IAM) é responsável por todas as decisões de autorização para ações em recursos da nuvem. O IAM confirma se uma política concede permissão para cada ação (no plano de dados) e processa atualizações nelas usando uma chamada SetPolicy (no plano de controle).

Todas as políticas do IAM são replicadas em várias zonas em cada região, ajudando as operações do plano de dados do IAM a se recuperarem de falhas de outras regiões e tolerantes a falhas de zona em cada região. A resiliência do plano de dados do IAM em relação a falhas de zona e região permite arquiteturas multirregionais e de várias zonas para alta disponibilidade.

As operações do plano de controle do IAM podem depender da replicação entre regiões. Quando as chamadas SetPolicy são bem-sucedidas, os dados são gravados em várias regiões, mas a propagação para outras regiões tem consistência posterior. O plano de controle do IAM é resiliente a falhas em uma única região.

Identity-Aware Proxy

O Identity-Aware Proxy fornece acesso a aplicativos hospedados no Google Cloud, em outras nuvens e no local. O IAP é distribuído por região, e as solicitações para zonas indisponíveis são exibidas automaticamente de outras zonas disponíveis na região.

Falhas regionais no IAP afetam o acesso aos aplicativos hospedados na região afetada. Recomendamos que você implante em várias regiões e use o Cloud Load Balancing para ter maior disponibilidade e resiliência contra interrupções regionais.

Looker (Google Cloud Core)

O Looker (Google Cloud Core) é uma plataforma de Business Intelligence que oferece provisionamento, configuração e gerenciamento simplificados e otimizados de uma instância do Looker pelo console do Google Cloud. O Looker (Google Cloud Core) permite que os usuários analisem dados, criem painéis, configurem alertas e compartilhem relatórios. Além disso, o Looker (Google Cloud Core) oferece um ambiente de desenvolvimento integrado para modeladores de dadose e recursos avançados de API e embedding para desenvolvedores.

O Looker (Google Cloud Core) é composto por instâncias isoladas regionalmente que replicam dados de forma síncrona nas zonas da região. Verifique se os recursos usados pela instância, como as fontes de dados a que o Looker (Google Cloud Core) se conecta, estão na mesma região em que a instância é executada.

Interrupção do serviço zonal: as instâncias do Looker (Google Cloud Core) armazenam metadados e os próprios contêineres implantados. Os dados são gravados de forma síncrona nas instâncias replicadas. Em uma interrupção do serviço zonal, as instâncias do Looker (Google Cloud Core) continuam sendo disponibilizadas por outras zonas disponíveis na mesma região. Todas as transações ou chamadas de API serão retornadas depois que os dados fizerem commit para um quórum em uma região. Se a replicação falhar, a transação não fará commit e o usuário será notificado sobre a falha. Se mais de uma zona falhar, as transações também falharão e o usuário será notificado. O Looker (Google Cloud Core) interrompe todas as programações ou consultas em execução no momento. Será necessário reprogramá-los ou colocá-los em fila novamente depois de resolver a falha.

Interrupção do serviço regional: as instâncias do Looker (Google Cloud Core) na região afetada não estão disponíveis. O Looker (Google Cloud Core) interrompe todas as programações ou consultas em execução no momento. Será necessário reprogramá-los ou colocá-los em fila novamente depois de resolver a falha. É possível criar novas instâncias manualmente em uma região diferente. Também é possível recuperar as instâncias usando o processo definido em Importar ou exportar dados de uma instância do Looker (Google Cloud Core). Recomendamos que você configure um processo periódico de exportação de dados para copiar os recursos com antecedência, no caso improvável de uma interrupção do serviço regional.

Looker Studio

O Looker Studio é um produto de visualização de dados e Business Intelligence. Ele permite que os clientes se conectem aos dados armazenados em outros sistemas, criem relatórios e painéis usando esses dados e compartilhem os relatórios e painéis em toda a organização. O Looker Studio é um serviço global e não permite que os usuários selecionem um escopo de recurso.

No caso de interrupção zonal, o Looker Studio continua a atender solicitações de outra zona na mesma região ou em uma região diferente sem interrupção. Os recursos do usuário são replicados de maneira síncrona nas regiões. Portanto, não há perda de dados.

No caso de interrupção regional, o Looker Studio continua a atender solicitações de outra região sem interrupção. Os recursos do usuário são replicados de maneira síncrona entre as regiões. Portanto, não há perda de dados.

Memorystore para Memcached

O Memorystore para Memcached é a oferta gerenciada do Memcached do Google Cloud. O Memorystore para Memcached permite que os clientes criem clusters do Memcached que podem ser usados como bancos de dados de chave-valor de alta capacidade de processamento para aplicativos.

Os clusters do Memcached são regionais, com nós distribuídos em todas as zonas especificadas pelo cliente. No entanto, o Memcached não replica dados entre nós. Portanto, uma falha zonal pode resultar em perda de dados, também descrita como uma limpeza de cache parcial. As instâncias do Memcached continuarão funcionando, mas terão menos nós. O serviço não iniciará novos nós durante uma falha zonal. Os nós do Memcached em zonas não afetadas continuarão veiculando o tráfego, embora a falha zonal resulte em uma taxa de ocorrência em cache menor até que a zona seja recuperada.

Em caso de falha regional, os nós do Memcached não veiculam tráfego. Nesse caso, os dados são perdidos, o que resulta em uma limpeza de cache completa. Para atenuar uma interrupção regional, é possível implementar uma arquitetura que implante o aplicativo e o Memorystore para Memcached em várias regiões.

Memorystore for Redis

O Memorystore para Redis é um serviço totalmente gerenciado do Redis para o Google Cloud que pode reduzir a carga de gerenciamento de implantações complexas do Redis. Atualmente, ele oferece dois níveis: Básico e Standard. Para o nível Básico, uma interrupção zonal ou regional causará perda de dados, também conhecida como descarga total de cache. Para o nível Standard, uma interrupção regional causará a perda de dados. Uma interrupção de zona pode causar perda parcial de dados para a instância do nível padrão devido à replicação assíncrona.

Importante: para que a replicação seja realizada de maneira previsível, verifique se o uso da CPU e a memória do sistema taxa de uso permanecem dentro dos valores recomendados.

Interrupção zonal: as instâncias do nível Standard replicam de maneira assíncrona as operações do conjunto de dados do nó primário para o nó de réplica. Quando ocorre a interrupção na zona do nó primário, o nó de réplica é promovido a nó primário. Durante a promoção, ocorre um failover e o cliente do Redis precisa se reconectar à instância. Após a reconexão, as operações são retomadas. Para mais informações sobre a alta disponibilidade de instâncias do Memorystore para Redis no nível Standard, consulte Alta disponibilidade do Memorystore para Redis.

Se você ativar réplicas de leitura na instância de nível padrão e só tiver uma, o endpoint de leitura não estará disponível durante a interrupção de uma zona. Para mais informações sobre a recuperação de desastres de réplicas de leitura, consulte Modos de falha para réplicas de leitura.

Interrupção regional: o Memorystore para Redis é um produto regional, portanto, uma única instância não pode suportar uma falha regional. Como alternativa, programe tarefas periódicas a fim de exportar a instância do Redis para um bucket do Cloud Storage em uma região diferente. Quando ocorre uma interrupção regional, é possível restaurar a instância do Redis em uma região diferente do conjunto de dados exportado.

Descoberta de serviços de vários clusters e Entrada em vários clusters

Os serviços de vários clusters (MCS) do GKE consistem em vários componentes. Os componentes incluem o hub do Google Kubernetes Engine (que orquestra vários clusters do Google Kubernetes Engine usando assinaturas), os próprios clusters e os controladores do hub do GKE (entrada em vários clusters, descoberta de serviços de vários clusters). Os controladores do hub orquestram a configuração do balanceador de carga do Compute Engine usando back-ends em vários clusters.

No caso de uma interrupção zonal, a descoberta de serviços de vários clusters continua a atender solicitações de outra zona ou região. No caso de uma interrupção regional, a descoberta de serviços de vários clusters não faz failover.

No caso de uma interrupção zonal para a entrada em vários clusters, se o cluster de configuração for zonal e estiver no escopo da falha, o usuário precisará fazer o failover manualmente. O plano de dados é estático quanto ao failover e continuará exibindo o tráfego até o failover do usuário ocorra. Para evitar a necessidade de um failover manual, use um cluster regional como o cluster de configuração.

No caso de uma interrupção regional, a entrada em vários clusters não faz failover. Os usuários precisam ter um plano de DR ativo para failover manual no cluster de configuração. Para mais informações, consulte Como configurar a entrada em vários clusters e Como configurar serviços de vários clusters.

Para mais informações sobre o GKE, consulte a seção "Google Kubernetes Engine" em Como arquitetar a recuperação de desastres para interrupções da infraestrutura em nuvem.

Network Analyzer

O Network Analyzer monitora automaticamente as configurações de rede VPC e detecta configurações incorretas e não ideais. Ele fornece insights sobre topologia de rede, regras de firewall, rotas, dependências de configuração e conectividade em serviços e aplicativos. Ele identifica falhas de rede, fornece informações sobre a causa raiz e sugere possíveis soluções.

O Network Analyzer é executado continuamente e aciona análises relevantes com base em atualizações quase em tempo real na configuração da sua rede. Se o Network Analyzer detectar uma falha de rede, ele tentará correlacioná-la com mudanças recentes na configuração para identificar as causas raiz. Sempre que possível, ele fornece recomendações para sugerir informações sobre como corrigir os problemas.

O Network Analyzer é uma ferramenta de diagnóstico sem componentes do plano de dados. Ela não processa nem gera tráfego de usuários.

Interrupção do serviço zonal: o serviço do Network Analyzer é replicado globalmente, e a disponibilidade não é afetada por uma interrupção do serviço zonal.

Se os insights do Network Analyzer contiverem configurações de uma zona que está passando por uma interrupção do serviço, isso afetará a qualidade dos dados. Os insights sobre a rede que se referem às configurações dessa zona ficam desatualizados. Não confie em nenhum insights fornecido pelo Network Analyzer durante interrupções do serviço.

Interrupção do serviço regional: o serviço do Network Analyzer é replicado globalmente, e a disponibilidade não é afetada por uma interrupção do serviço regional.

Se os insights do Network Analyzer contiverem configurações de uma região que está passando por uma interrupção do serviço, isso afetará a qualidade dos dados. Os insights sobre a rede que se referem às configurações dessa região ficam desatualizados. Não confie em nenhum insights fornecido pelo Network Analyzer durante interrupções do serviço.

Topologia de rede

A Topologia de rede é uma ferramenta de visualização que mostra a topologia da sua infraestrutura de rede. A visualização da infraestrutura mostra redes de nuvem privada virtual (VPC), conectividade híbrida de entrada e saída com as suas redes locais, conectividade com serviços gerenciados pelo Google e as métricas associadas.

Interrupção do serviço zonal: no caso de uma interrupção do serviço zonal, os dados dessa zona não aparecerão na Topologia de rede. Os dados de outras zonas não são afetados.

Interrupção do serviço regional: no caso de uma interrupção do serviço regional, os dados dessa região não aparecerão na Topologia de rede. Os dados de outras regiões não são afetados.

Painel de desempenho

O Painel de desempenho oferece visibilidade do desempenho de toda a rede do Google Cloud, bem como do desempenho dos recursos do seu projeto.

Com esses recursos de monitoramento de desempenho, é possível distinguir entre um problema no aplicativo e um problema na rede subjacente do Google Cloud. Também é possível depurar problemas históricos de desempenho de rede. O Painel de desempenho também exporta dados para o Cloud Monitoring. É possível usar o Monitoring para consultar os dados e ter acesso a mais informações.

Falha temporária por zona:

No caso de uma interrupção do serviço zonal, os dados de latência e perda de pacotes sobre o tráfego da zona afetada não aparecerão no Painel de desempenho. Os dados de latência e perda de pacote sobre o tráfego de outras zonas não são afetados. Quando a interrupção do serviço termina, os dados de latência e perda de pacote são retomados.

Falha temporária regional:

No caso de interrupção do serviço regional, os dados de latência e perda de pacote sobre o tráfego da região afetada não aparecerão no Painel de desempenho. Os dados de latência e perda de pacote sobre o tráfego de outras regiões não são afetados. Quando a interrupção do serviço termina, os dados de latência e perda de pacote são retomados.

Network Connectivity Center

O Network Connectivity Center é um produto de gerenciamento de conectividade de rede que emprega uma arquitetura hub e spoke. Com essa arquitetura, um recurso de gerenciamento central funciona como um hub e cada recurso de conectividade funciona como um spoke. Atualmente, os spokes híbridos são compatíveis com VPN de alta disponibilidade, Interconexão dedicada e por parceiro e dispositivos de roteador SD-WAN dos principais fornecedores terceirizados. Com os spokes híbridos do Network Connectivity Center, as empresas podem conectar cargas de trabalho e serviços do Google Cloud a data centers locais, outras nuvens e filiais por meio do alcance global da rede do Google Cloud.

Interrupção zonal: um spoke híbrido do Network Connectivity Center com configuração de alta disponibilidade é resiliente a falhas zonais, porque o plano de controle e o plano de dados de rede são redundantes em várias zonas dentro de uma região.

Interrupção regional: um spoke híbrido do Network Connectivity Center é um recurso regional, por isso não pode suportar uma falha regional.

Níveis de serviço de rede

Os níveis de serviço de rede permitem otimizar a conectividade entre sistemas na Internet e nas instâncias do Google Cloud. Ele oferece dois níveis de serviço, Premium e Standard. Com o nível Premium, um endereço IP do nível Premium anycast anunciado globalmente pode servir como front-end para back-ends regionais ou globais. Com o nível Standard, um endereço IP de nível Standard anunciado regionalmente pode servir como front-end para back-ends regionais. A resiliência geral de um aplicativo é influenciada pelo nível de serviço de rede e pela redundância dos back-ends a que ele está associado.

Interrupção zonal: os níveis Premium e Standard oferecem resiliência contra interrupções zonais quando associados a back-ends com redundância regional. Quando ocorre uma interrupção zonal, o comportamento do failover para casos que usam back-ends regionalmente redundantes é determinado pelos próprios back-ends associados. Quando associado a back-ends zonais, o serviço fica disponível novamente assim que a interrupção é resolvida.

Interrupção regional: o nível Premium oferece resiliência contra interrupções regionais quando está associado a back-ends globalmente redundantes. No nível Standard, todo o tráfego para a região afetada falhará. O tráfego para todas as outras regiões não é afetado. Quando ocorre uma interrupção regional, o comportamento do failover para casos que usam o nível Premium com back-ends globalmente redundantes é determinado pelos próprios back-ends associados. Ao usar o nível Premium com back-ends regionais ou o nível Standard, o serviço será disponibilizado novamente assim que a interrupção for resolvida.

Espelhamento de pacotes

O Espelhamento de pacotes clona o tráfego de instâncias especificadas na rede da nuvem privada virtual (VPC) e encaminha os dados clonados para instâncias protegidas por um balanceador de carga interno regional para análise. O Espelhamento de pacotes captura todos os dados de tráfego e de pacote, incluindo payloads e cabeçalhos.

Para mais informações sobre a funcionalidade de Espelhamento de pacotes, consulte a página de visão geral do Espelhamento de pacotes.

Interrupção zonal: configure o balanceador de carga interno para que haja instâncias em várias zonas. Se ocorrer uma interrupção na zona, o Espelhamento de pacotes desviará pacotes clonados para uma zona íntegra.

Interrupção regional: o Espelhamento de pacotes é um produto regional. Se houver uma interrupção regional, os pacotes na região afetada não serão clonados.

Persistent Disk

O Persistent Disk está disponível em configurações regionais e zonais.

O Persistent Disk zonal é hospedado em uma única zona. Se a zona do disco não estiver disponível, o Persistent Disk ficará indisponível até que a interrupção da zona seja resolvida.

O Persistent Disk regional fornece replicação síncrona de dados entre duas zonas em uma região. No caso de uma interrupção na zona da sua máquina virtual, é possível forçar a anexação de um Persistent Disk regional a uma instância de VM na zona secundária do disco. Para executar essa tarefa, é preciso iniciar outra instância de VM nessa zona ou manter uma instância de VM de espera ativa nessa zona.

Private Service Connect

O Private Service Connect é um recurso da rede do Google Cloud que permite que consumidores acessem serviços gerenciados de maneira particular na rede VPC deles. Da mesma forma, ele permite que produtores do serviço gerenciado hospedem esses serviços em redes VPC separadas e ofereçam uma conexão particular aos consumidores.

Endpoints do Private Service Connect para serviços publicados

Um endpoint do Private Service Connect se conecta a serviços em outra rede VPC usando uma regra de encaminhamento do Private Service Connect. O produtor de serviço fornece um serviço usando conectividade particular a um consumidor de serviço, expondo um único anexo de serviço. Em seguida, o consumidor de serviço poderá atribuir um endereço IP virtual da VPC para esse serviço.

Interrupção zonal: o tráfego do Private Service Connect proveniente do tráfego de VM gerado pelos endpoints de clientes VPC do consumidor ainda pode acessar serviços gerenciados expostos na rede VPC interna do produtor de serviços. Esse acesso é possível porque o tráfego do Private Service Connect faz o failover para back-ends de serviço mais íntegros em uma zona diferente.

Interrupção regional: o Private Service Connect é um produto regional. Ele não é resistente a interrupções regionais. Os serviços gerenciados multirregionais podem ter alta disponibilidade durante interrupções regionais configurando endpoints do Private Service Connect em várias regiões.

Endpoints do Private Service Connect para APIs do Google

Um endpoint do Private Service Connect se conecta às APIs do Google usando uma regra de encaminhamento do Private Service Connect. Com essa regra de encaminhamento, os clientes podem usar nomes de endpoint personalizados com os endereços IP internos.

Interrupção zonal: o tráfego do Private Service Connect de endpoints de clientes VPC do consumidor ainda pode acessar as APIs do Google porque a conectividade entre a VM e o endpoint fará o failover automaticamente para outra zona funcional da mesma região. As solicitações que já estão em andamento quando uma falha temporária começa vão depender do tempo limite do TCP do cliente e do comportamento de nova tentativa para recuperação.

Consulte a recuperação do Compute Engine para mais detalhes.

Interrupção regional: o Private Service Connect é um produto regional. Ele não é resistente a interrupções regionais. Os serviços gerenciados multirregionais podem ter alta disponibilidade durante interrupções regionais configurando endpoints do Private Service Connect em várias regiões.

Para mais informações sobre o Private Service Connect, consulte a seção "Endpoints" em Tipos do Private Service Connect.

Pub/Sub

O Pub/Sub é um serviço de mensagens para integração de aplicativos e análise de stream. Os tópicos do Pub/Sub são globais, o que significa que são visíveis e acessíveis em qualquer local do Google Cloud. No entanto, qualquer mensagem é armazenada em uma única região do Google Cloud, mais próxima do editor e permitida pela política de localização de recursos. Assim, um tópico pode ter mensagens armazenadas em diferentes regiões no Google Cloud. A política de armazenamento de mensagens do Pub/Sub pode restringir as regiões em que as mensagens são armazenadas.

Interrupção zonal: quando uma mensagem do Pub/Sub é publicada, ela é gravada de maneira síncrona no armazenamento em pelo menos duas zonas dentro da região. Portanto, se uma única zona ficar indisponível, não haverá impacto visível para o cliente.

Interrupção regional: durante uma interrupção regional, as mensagens armazenadas na região ficam inacessíveis. Os editores e assinantes que se conectam à região afetada por um endpoint regional ou global não conseguem se conectar. Os editores e assinantes que se conectam a outras regiões ainda conseguem se conectar, e as mensagens disponíveis em outras regiões são entregues aos assinantes mais próximos da rede com capacidade.

Se o aplicativo depender da ordem das mensagens, revise as recomendações detalhadas da equipe do Pub/Sub. As garantias de ordenação de mensagens são fornecidas por região e podem ser interrompidas se você usar um endpoint global.

reCAPTCHA Enterprise

O reCAPTCHA Enterprise é um serviço global que detecta atividades fraudulentas, spam e abuso. Ele não exige nem permite a configuração de resiliência regional ou zonal. As atualizações dos metadados de configuração são replicadas de maneira assíncrona a cada região em que o reCAPTCHA Enterprise é executado.

No caso de uma interrupção zonal, o reCAPTCHA Enterprise continua atendendo solicitações de outra zona na mesma região ou em uma região diferente sem interrupção.

No caso de uma interrupção regional, o reCAPTCHA Enterprise continua atendendo solicitações de outra região sem interrupção.

Secret Manager

O Secret Manager é um produto de gerenciamento de credenciais e secrets do Google Cloud. Com o Secret Manager, é possível auditar e restringir facilmente o acesso a secrets, criptografar secrets em repouso e garantir que informações confidenciais sejam protegidas no Google Cloud.

Os recursos do Secret Manager normalmente são criados com a política de replicação automática (recomendado), o que faz com que sejam replicados globalmente. Se a organização tiver políticas que não permitem a replicação global de dados de secrets, os recursos do Secret Manager podem ser criados com políticas de replicação gerenciadas pelo usuário, em que uma ou mais regiões são escolhidas para que um secret seja replicado.

Falha temporária zonal: no caso de falha temporária zonal, o Secret Manager continua a exibir solicitações de outra zona na mesma região ou em outra região sem interrupção. Em cada região, o Secret Manager sempre mantém pelo menos duas réplicas em zonas separadas (na maioria das regiões, três réplicas). Quando a falha temporária zonal é resolvida, a redundância total é restaurada.

Falha temporária regional: no caso de uma falha temporária regional, o Secret Manager continua a exibir solicitações de outra região sem interrupção, supondo que os dados foram replicados para mais de uma região. Por meio da replicação automática ou da replicação gerenciada pelo usuário para mais de uma região. Quando a falha temporária regional é resolvida, a redundância total é restaurada.

Security Command Center

O Security Command Center é a plataforma global de gerenciamento de riscos em tempo real do Google Cloud. Ele consiste em dois componentes principais: detectores e descobertas.

Os detectores são afetados por interrupções regionais e zonais de maneiras diferentes. Durante uma interrupção regional, os detectores não podem gerar novas descobertas para recursos regionais porque os recursos que eles precisam verificar não estão disponíveis.

Durante uma interrupção de zona, os detectores podem levar desde alguns minutos até horas para retomar a operação normal. O Security Command Center não perde os dados descobertos. Ele também não gera novos dados de descoberta para recursos indisponíveis. No pior dos casos, os agentes do Container Threat Detection podem ficar sem espaço de buffer enquanto se conectam a uma célula íntegra, o que pode resultar na perda de detecções.

As descobertas são resilientes a interrupções regionais e zonais porque são replicadas de maneira síncrona entre as regiões.

Proteção de dados confidenciais (incluindo a API DLP)

A proteção de dados confidenciais fornece serviços de classificação, criação de perfil, desidentificação, tokenização e análise de risco de privacidade. Ele trabalha de maneira síncrona nos dados enviados nos corpos de solicitação ou de maneira assíncrona nos dados que já estão presentes nos sistemas de armazenamento em nuvem. A proteção de dados confidenciais pode ser invocada por meio dos endpoints globais ou específicos da região.

Endpoint global: o serviço foi projetado para ser resistente a falhas regionais e zonais. Se o serviço estiver sobrecarregado durante a falha, os dados enviados para o método hybridInspect podem ser perdidos.

Para criar uma arquitetura resistente a falhas, inclua uma lógica para examinar a descoberta pré-falha mais recente produzida pelo método hybridInspect. Em caso de interrupção, os dados enviados ao método podem ser perdidos, mas não mais do que os últimos 10 minutos antes do evento de falha. Se houver descobertas mais recentes do que 10 minutos antes do início da interrupção, isso indica que os dados que resultaram na descoberta não foram perdidos. Nesse caso, não é necessário reproduzir novamente os dados anteriores ao carimbo de data/hora da descoberta, mesmo que estejam dentro do intervalo de 10 minutos.

Endpoint regional: os endpoints regionais não são resilientes a falhas regionais. Se for necessária resiliência a uma falha regional, faça failover para outras regiões. As características de falha zonal são as mesmas que as mencionadas acima.

Service Usage

A API Service Usage é um serviço de infraestrutura do Google Cloud que permite listar e gerenciar APIs e serviços nos projetos do Google Cloud. É possível listar e gerenciar APIs e serviços fornecidos pelo Google, pelo Google Cloud e por produtores terceirizados. A API Service Usage é um serviço global e resiliente a interrupções temporárias zonais e regionais. No caso de interrupção zonal ou regional, a API Service Usage continua a atender solicitações de outra zona em diferentes regiões.

Para mais informações sobre o Service Usage, consulte a Documentação do Service Usage.

Speech-to-Text

A Speech-to-Text permite converter áudio de voz em texto usando técnicas de machine learning, como modelos de rede neural. O áudio é enviado em tempo real pelo microfone de um aplicativo ou processado como um lote de arquivos de áudio.

Falha temporária por zona:

• API Speech-to-Text v1: durante uma interrupção do serviço zonal, a API Speech-to-Text versão 1 continua atendendo solicitações de outra zona na mesma região sem interrupção. No entanto, todos os jobs em execução na zona com falha serão perdidos. Os usuários precisam repetir os jobs com falha, que serão roteados automaticamente para uma zona disponível.

• API Speech-to-Text v2: durante uma interrupção do serviço zonal, a API Speech-to-Text versão 2 continua atendendo solicitações de outra zona na mesma região. No entanto, todos os jobs em execução na zona com falha serão perdidos. Os usuários precisam repetir os jobs com falha, que serão roteados automaticamente para uma zona disponível. A API Speech-to-Text só retorna a chamada de API depois que os dados fizerem commit em um quórum dentro de uma região. Em algumas regiões, aceleradores de IA (TPUs) estão disponíveis apenas em uma zona. Nesse caso, uma interrupção do serviço nessa zona faz com que o reconhecimento de fala falhe, mas não há perda de dados.

Falha temporária regional:

• API Speech-to-Text v1: a API Speech-to-Text versão 1 não é afetada por falhas regionais porque é um serviço global multirregional. O serviço continua a atender solicitações de outra região sem interrupção. No entanto, os jobs em execução na região com falha são perdidos. Os usuários precisam repetir os jobs que falharam, que serão roteados automaticamente para uma região disponível.

• API Speech-to-Text v2:

  • API Speech-to-Text versão 2 multirregional. O serviço continua a atender solicitações de outra zona na mesma região sem interrupção.

  • API Speech-to-Text versão 2 de região única. O serviço define o escopo da execução do job para a região solicitada. A API Speech-to-Text versão 2 não encaminha o tráfego para uma região diferente, e os dados não são replicados para outra região. Durante uma falha regional, a API Speech-to-Text versão 2 fica indisponível nessa região. No entanto, ela ficará disponível novamente quando a interrupção do serviço for resolvida.

Serviço de transferência do Cloud Storage

O Serviço de transferência do Cloud Storage gerencia transferências de dados de várias fontes de nuvem para o Cloud Storage, bem como para, de e entre sistemas de arquivos.

A API Serviço de transferência do Cloud Storage é um recurso global.

O Serviço de transferência do Cloud Storage depende da disponibilidade da origem e do destino de uma transferência. Se uma origem ou um destino de transferência não estiver disponível, as transferências vão deixar de progredir. No entanto, nenhum dado principal do cliente ou dados do job são perdidos. As transferências são retomadas quando a origem e o destino são disponibilizados novamente.

É possível usar o Serviço de transferência do Cloud Storage com ou sem um agente, da seguinte maneira:

• As transferências sem agente usam workers regionais para orquestrar jobs de transferência.

• As transferências baseadas em agente usam agentes de software instalados na sua infraestrutura. As transferências baseadas em agente dependem da disponibilidade dos agentes de transferência e da capacidade deles de se conectarem ao sistema de arquivos. Ao decidir onde instalar os agentes de transferência, considere a disponibilidade do sistema de arquivos. Por exemplo, se você estiver executando agentes de transferência em várias VMs do Compute Engine para transferir dados para uma instância do Filestore de nível empresarial (um recurso regional), considere localizar as VMs em diferentes zonas dentro da região da instância do Filestore.

  Se os agentes ficarem indisponíveis ou a conexão com o sistema de arquivos for interrompida, as transferências deixarão de progredir, mas nenhum dado será perdido. Se todos os processos do agente forem encerrados, o job de transferência será pausado até que novos agentes sejam adicionados ao pool de agentes da transferência.

Durante uma interrupção, o comportamento do Serviço de transferência do Cloud Storage é o seguinte:

• Interrupção por zona: durante uma interrupção zonal, as APIs do Serviço de transferência do Cloud Storage permanecem disponíveis, e você pode continuar criando jobs de transferência. Os dados continuam sendo transferidos.

• Interrupção regional: durante a interrupção regional, as APIs do Serviço de transferência do Cloud Storage continuam disponíveis, e você pode continuar criando jobs de transferência. Se os workers da transferência estiverem localizados na região afetada, a transferência de dados é interrompida até que a região fique disponível novamente e a transferência seja retomada automaticamente.

Vertex ML Metadata

O Vertex ML Metadata permite que você registre os metadados e artefatos produzidos pelo sistema de ML e consulte-os para ajudar a analisar, depurar e auditar o desempenho do sistema de ML ou os artefatos que ele produz.

Interrupção zonal: na configuração padrão, o Vertex ML Metadata oferece proteção contra falhas zonais. O serviço é implantado em várias zonas em cada região, com dados replicados de maneira síncrona em diferentes zonas dentro de cada região. Em caso de falha na zona, as zonas restantes assumem o controle com o mínimo de interrupção.

Interrupção regional: o Vertex ML Metadata é um serviço regionalizado. No caso de uma interrupção regional, o Vertex ML Metadata não faz o failover para outra região.

Vertex AI Model Registry

O Vertex AI Model Registry permite que os usuários simplifiquem o gerenciamento, a governança e a implantação de modelos de ML em um repositório central. O Vertex AI Model Registry é uma oferta regional com alta disponibilidade e proteção contra interrupções zonais.

Interrupção zonal: o registro de modelos da Vertex AI oferece proteção contra interrupções zonais. O serviço é implantado em três zonas em cada região, com dados replicados de maneira síncrona em diferentes zonas dentro da região. Se uma zona falhar, as zonas restantes assumirão o controle sem perda de dados e interrupção mínima do serviço.

interrupção temporária regional: o Vertex AI Model Registry é um serviço regionalizado. Se uma região falhar, o Model Registry não fará o failover.

Vertex AI Pipelines

O Vertex AI Pipelines é um serviço da Vertex AI que permite automatizar, monitorar e controlar fluxos de trabalho de machine learning (ML) sem servidor. O Vertex AI Pipelines foi criado para oferecer alta disponibilidade e proteção contra falhas zonais.

Interrupção zonal: na configuração padrão, o Vertex AI Pipelines oferece proteção contra falhas zonais. O serviço é implantado em várias zonas em cada região, com dados replicados de maneira síncrona em diferentes zonas dentro da região. Em caso de falha na zona, as zonas restantes assumem o controle com o mínimo de interrupção.

Interrupção regional: o Vertex AI Pipelines é um serviço regionalizado. No caso de uma interrupção regional, o Vertex AI Pipelines não fará o failover para outra região. Se ocorrer uma interrupção regional, recomendamos que você execute os jobs do pipeline em uma região de backup.

Vertex AI para Pesquisa

A Vertex AI para Pesquisa é uma solução de pesquisa personalizável com recursos de IA generativa e conformidade empresarial nativa. A Vertex AI para Pesquisa é implantada e replicada automaticamente em várias regiões no Google Cloud. Para configurar onde os dados são armazenados, escolha uma multirregião compatível, como: global, EUA ou UE.

Interrupção do serviço zonal e regional: o UserEvents enviado à Vertex AI para Pesquisa pode não ser recuperável devido ao atraso assíncrono de replicação. Outros dados e serviços fornecidos pela Vertex AI para Pesquisa continuam disponíveis devido ao failover automático e à replicação síncrona de dados.

Vertex AI Training

O Vertex AI Training oferece aos usuários a capacidade de executar jobs de treinamento personalizados na infraestrutura do Google. O Vertex AI Training é uma oferta regional, o que significa que os clientes podem escolher a região para executar os jobs de treinamento. No entanto, os clientes não podem escolher zonas específicas dentro dessa região. O serviço de treinamento pode balancear automaticamente a execução do job em diferentes zonas dentro da região.

Falha temporária zonal: o Vertex AI Training armazena metadados do job de treinamento personalizado. Esses dados são armazenados por região e gravados de forma síncrona. A chamada da API Vertex AI Training só é retornada quando esses metadados são confirmados em um quórum em uma região. O job de treinamento pode ser executado em uma zona específica. Uma interrupção de zona leva à falha da execução atual do job. Nesse caso, o serviço tentará novamente o job automaticamente encaminhando-o para outra zona. Se várias tentativas falharem, o status do job será atualizado para "Com falha". As solicitações subsequentes do usuário para executar o job são roteadas para uma zona disponível.

Falha temporária regional: os clientes escolhem a região do Google Cloud em que querem executar os jobs de treinamento. Os dados jamais são replicados entre regiões. O Vertex AI Training define a execução do job para a região solicitada e nunca encaminha os jobs de treinamento para uma região diferente. No caso de falha regional, o serviço do Vertex AI Training não fica disponível nessa região e se torna disponível novamente quando a falha é resolvida. Recomendamos que os clientes usem várias regiões para executar os jobs e, no caso de interrupção temporária, direcionem os jobs para uma região diferente disponível.

Nuvem privada virtual (VPC)

A VPC é um serviço global que fornece conectividade de rede a recursos (VMs, por exemplo). No entanto, as falhas são zonais. No caso de uma falha zonal, os recursos nessa zona ficarão indisponíveis. Da mesma forma, se uma região falhar, apenas o tráfego de entrada e saída da região com falha será afetado. A conectividade de regiões íntegras não é afetada.

interrupção temporária zonal: se uma rede VPC cobrir várias zonas e uma delas interrupçãor, a rede VPC continuará íntegra para zonas íntegras. O tráfego de rede entre recursos em zonas íntegras continuará funcionando normalmente durante a falha. Uma falha zonal afeta apenas o tráfego de rede de entrada e saída de recursos na zona com falha. Para atenuar o impacto de falhas zonais, recomendamos que você não crie todos os recursos em uma única zona. Em vez disso, ao criar recursos, distribua-os por zonas.

interrupção temporária regional: se uma rede VPC cobrir várias regiões e uma delas interrupçãor, a rede VPC continuará íntegra para regiões íntegras. O tráfego de rede entre recursos em regiões íntegras continuará funcionando normalmente durante a falha. Uma falha regional afeta apenas o tráfego de rede de entrada e saída de recursos na região com falha. Para atenuar o impacto de falhas regionais, recomendamos que você distribua recursos por várias regiões.

VPC Service Controls

O VPC Service Controls é um serviço regional. Com o VPC Service Controls, as equipes de segurança das empresas podem definir controles refinados de perímetro e aplicar essa conduta de segurança nos vários serviços e projetos do Google Cloud. As políticas do cliente são espelhadas regionalmente.

Interrupção zonal: o VPC Service Controls continua a exibir solicitações de outra zona na mesma região sem interrupção.

Interrupção regional: as APIs configuradas para aplicação da política do VPC Service Controls na região afetada ficarão indisponíveis até que a região fique disponível novamente. Os clientes são incentivados a implantar os serviços do VPC Service Controls em várias regiões se quiser maior disponibilidade.

Fluxos de trabalho

O Workflows é um produto de orquestração que permite aos clientes do Google Cloud:

• implantar e executar fluxos de trabalho que conectam outros serviços usando HTTP;
• automatizar processos, incluindo a espera em respostas HTTP com novas tentativas automáticas por até um ano;
• implementar o processamento em tempo real com execuções orientadas a eventos de baixa latência.

Um cliente do Workflows pode implantar fluxos de trabalho que descrevam a lógica de negócios que ele quer executar e, em seguida, executar os fluxos de trabalho diretamente com a API ou com acionadores baseados em eventos (atualmente limitados ao Pub/Sub ou Eventarc). O fluxo de trabalho em execução pode manipular variáveis, fazer chamadas HTTP e armazenar os resultados ou definir callbacks e aguardar para serem retomados por outro serviço.

Interrupção zonal: o código-fonte dos fluxos de trabalho não é afetado por interrupções zonais. Os fluxos de trabalho armazenam o código-fonte dos fluxos de trabalho com os valores das variáveis e as respostas HTTP recebidas pelos fluxos de trabalho em execução. O código-fonte é armazenado regionalmente e gravado de maneira síncrona: a API do plano de controle só é retornada quando esses metadados são confirmados em um quórum dentro de uma região. As variáveis e os resultados HTTP também são armazenados regionalmente e gravados de maneira síncrona, pelo menos a cada cinco segundos.

Se uma zona falhar, os fluxos de trabalho serão retomados automaticamente com base nos últimos dados armazenados. No entanto, as solicitações HTTP que ainda não receberam respostas não serão repetidas automaticamente. Use políticas de repetição para solicitações que podem ser repetidas com segurança, conforme descrito na nossa documentação.

Interrupção regional: os fluxos de trabalho são um serviço regionalizado. No caso de interrupção regional, os fluxos de trabalho não farão failover. Os clientes são incentivados a implantar fluxos de trabalho em várias regiões se quiser maior disponibilidade.

Anthos Service Mesh

O Anthos Service Mesh permite configurar uma malha de serviço gerenciada que abrange vários clusters do GKE. Esta documentação refere-se apenas ao Anthos Service Mesh gerenciado, a variante no cluster é auto-hospedada e as diretrizes regulares da plataforma precisam ser seguidas.

Interrupção zonal: a configuração da malha, como está armazenada no cluster do GKE, é resiliente a interrupções zonais, desde que o cluster seja regional. Os dados que o produto usa para contabilidade interna são armazenados regional ou globalmente e não são afetados se uma única zona estiver fora de serviço. O plano de controle é executado na mesma região que o cluster do GKE compatível (para clusters zonais, é a região que o contém) e não é afetado por interrupções dentro de uma única zona.

Interrupção regional: o Anthos Service Mesh fornece serviços para clusters do GKE, que são regionais ou zonais. Em caso de interrupção regional, o Anthos Service Mesh não fará failover. O GKE também não. Incentivamos os clientes a implantar malhas que constituam clusters do GKE que cubram diferentes regiões.

Diretório de serviços

O Diretório de serviços é uma plataforma para descobrir, publicar e conectar serviços. Ele fornece informações em tempo real, em um único lugar, sobre todos os seus serviços. O Diretório de serviços permite que você realize o gerenciamento de inventário de serviços em grande escala, quer você tenha alguns ou milhares de endpoints de serviço.

Os recursos do Diretório de serviços são criados por região, correspondendo ao parâmetro de localização especificado pelo usuário.

Interrupção zonal: durante uma interrupção zonal, o Diretório de serviços continua a atender solicitações de outra zona na mesma região ou em uma região diferente sem interrupção. Dentro de cada região, o Diretório de serviços sempre mantém várias réplicas. Depois que a interrupção zonal é resolvida, a redundância total é restaurada.

Interrupção regional: o diretório de serviços não é resiliente a interrupções regionais.