Este artigo é a sexta parte de uma série em que discutimos 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
- 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:
- 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;
- um guia de planejamento de arquitetura que oferece um framework para categorizar e projetar aplicativos com base nos resultados de confiabilidade pretendidos;
- 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 (em inglês) 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 e o Cloud 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, Google Kubernetes Engine regional | 99,99% | 52 minutos/ano |
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 Cloud 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.
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 armazenamento multirregional, como o Cloud Storage, ou uma opção de nuvem híbrida, como o Anthos.
- 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.
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 criticação, 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:
- O aplicativo precisa ser executado em várias zonas na mesma região ou em várias zonas em várias regiões?
- 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 4h
RPO 1h |
| Nível 2 | 35% | Normalmente, aplicativos regionais ou aplicativos internos importantes, como CRM ou ERP. | RTO 4h
RPO Zero |
RTO 24h
RPO 4h |
| Nível 3
(menos importante) |
60% | Normalmente os aplicativos para equipes ou departamentos, como back-office, reservas, viagens internas, contabilidade e RH. | RTO 12h
RPO 24h |
RTO 28 dias
RPO 24h |
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.
Amostra de arquitetura de exemplo para 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 | Sim | Sim | Sim |
| Dataflow | Não | Não | Não |
| BigQuery | Não | Não | Sim |
| Google Kubernetes Engine | Sim | Sim | Sim |
| Cloud Storage | Sim | Sim | Sim |
| Cloud SQL | Não | Sim | Sim |
| Cloud Spanner | Sim | Sim | Sim |
| Cloud Load Balancing | Sim | Sim | Sim |
Esta tabela é um exemplo baseado apenas nas camadas hipotéticas mostradas acima.
Exemplos de arquitetura de exemplo para organização de exemplo - Resiliência de interrupção de região:
| Google Cloud Product | 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 |
| Google Kubernetes Engine | Sim | Sim | Sim |
| Cloud Storage | Não | Não | Não |
| Cloud SQL | Sim | Sim | Sim |
| Cloud 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 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 RPG 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 camada. No entanto, por serem usados juntos, o serviço geral atende ao RPO. Nesse caso, como o Dataflow é um produto zonal, é preciso seguir recomendações para o design de alta disponibilidade para evitar a perda de dados durante uma interrupção de zona. No entanto, a camada do Cloud Storage é a fonte dourada desses dados e é compatível com um RPO de zero. Isso significa que os dados perdidos podem ser reingeridos no BigQuery usando a zona b em caso de 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 armazenamento de dados 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 armazenamento de dados. 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 apps para dispositivos móveis com usuários externos que se conectam a um conjunto de microsserviços em execução no Google Kubernetes Engine. O Cloud 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. Cada região é alimentada simultaneamente do Cloud 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 Google Kubernetes Engine é usado para a camada do aplicativo, que é configurada com várias zonas. Isso realiza o RTO de zero em cada região.
- O Cloud 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 Cloud 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 Google Kubernetes Engine é usado para a camada do aplicativo, que é 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 Cloud 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 Cloud 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 dentro de uma região e 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.
Compute Engine
O Compute Engine é a 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 (Beta), 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 Padrões de arquitetura acima para mais informações.
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.
Os clusters são executados no Compute Engine. Como o cluster é um recurso zonal, uma interrupção por zona torna o cluster indisponível ou destrói o cluster. 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.
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. Os jobs do Dataflow são zonais, e a configuração padrão não preserva os resultados do cálculo intermediário durante uma interrupção por zona. Uma abordagem de recuperação típica para esses pipelines padrão do Dataflow é reiniciar um job em uma zona ou região diferente e reprocessar os dados de entrada novamente.
Como arquitetar os pipelines do Dataflow para alta disponibilidade
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. Como parte da garantia única do Dataflow, ele só observará as mensagens no Pub/Sub se elas permanecerem no destino ou se uma mensagem passar por uma operação de agrupamento/gestão de janelas e for salva no estado de pipeline durável do Dataflow. Se não houver operações de agrupamento/janelamento de tempo, um failover para outro job do Dataflow em outra zona ou região reutilizando a assinatura não causará perda de dados nos dados de saída do pipeline.
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. A perda de dados das saídas do pipeline pode ser minimizada até zero elementos, caso a lógica de negócios usada pelo pipeline não dependa de dados antes da interrupção. Se a lógica de negócios do pipeline depender de dados que foram processados antes da interrupção (por exemplo, se forem usadas janelas de deslizamento longas ou se uma janela de tempo global estiver armazenando mais contadores), o Dataflow oferece um recurso de criação de snapshots (atualmente em Preview) que oferece um backup de snapshot do estado de um pipeline.
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 duas opções de configuração relacionadas à disponibilidade em conjuntos de dados do usuário.
Configuração de regiões única
Em uma única configuração de região, os dados são armazenados de maneira redundante em duas zonas de uma única região. Os dados gravados no BigQuery são gravados primeiro na zona principal e depois replicados de maneira assíncrona em uma zona secundária. Isso protege contra indisponibilidade de uma única zona na região. Os dados gravados na zona principal, mas que não foram replicados para a zona secundária no momento da interrupção, não estão disponíveis. No caso improvável de uma zona ser destruída, esses dados podem ser perdidos permanentemente.
Configuração multirregional (US / EU)
Semelhante à configuração de região única, na configuração multirregional dos EUA/UE, os dados são armazenados de maneira redundante em duas zonas de uma região. Além disso, o BigQuery mantém uma cópia extra de backup dos dados em uma segunda região. Se a região principal sofrer uma interrupção, os dados serão exibidos pela região secundária. Os dados que não foram replicados ficarão indisponíveis até que a região principal seja restaurada.
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.
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 Cloud 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 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.
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.
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 uma única região, regiões duplas ou multirregiões em um continente.
Se uma zona sofrer uma interrupção, os dados 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 quando uma zona fica indisponível.
No caso de interrupção regional, os buckets regionais nessa região estão off-line até que a região fique disponível novamente. Quando uma disponibilidade maior for necessária, considere o armazenamento de dados em uma configuração birregional ou multirregional. Locais birregionais e multirregionais são projetados para permanecer disponíveis em uma falha regional ao armazenar dados com redundância geográfica em mais de uma região usando a replicação assíncrona.
O Cloud Storage usa o Cloud Load Balancing para veicular buckets de várias regiões e multirregionais de várias regiões. No caso de uma interrupção regional, a exibição não é interrompida. Como a redundância geográfica é alcançada de modo assíncrono, alguns dados gravados recentemente podem não ser acessíveis durante a interrupção e podem ser perdidos em caso de destruição física dos dados na região afetada.
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.
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 afetada
ficam inacessíveis. As operações administrativas, como criação e exclusão
de tópicos e assinaturas, são multirregionais e resilientes a uma interrupção de
qualquer região do Google Cloud. As operações de publicação também são resilientes a interrupções de região, desde que pelo menos uma região permitida pela política de armazenamento de mensagens esteja disponível e o aplicativo use o endpoint global (pubsub.googleapis.com) ou vários endpoints regionais.
Por padrão, o Pub/Sub não restringe o local de
armazenamento de mensagens.
Se o aplicativo depende de ordenação de mensagens, consulte 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.
Cloud Composer
O Cloud Composer é a implementação do Apache Airflow gerenciada do Google Cloud. O Cloud Composer é arquitetado como um plano de controle regional em que é possível gerenciar os clusters do Cloud Composer. 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 Cloud Composer, incluindo a capacidade de criar novos clusters.
Os clusters são executados no Google Kubernetes Engine. Como o cluster é um recurso zonal, uma interrupção por zona torna o cluster indisponível ou destrói o cluster. Os fluxos de trabalho que estão em execução no momento da interrupção podem ser interrompidos antes da conclusão. Isso significa que a interrupção causa a perda do estado de fluxos de trabalho parcialmente executados, incluindo quaisquer ações externas que o fluxo de trabalho tenha sido configurado pelo usuário para realizar. 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, reparar alterações parciais de dados e assim por diante.
Durante uma interrupção da zona, é possível usar o Cloud Composer para iniciar uma nova instância do cluster em outra zona. Quando o cluster estiver disponível, o fluxo de trabalho poderá ser retomado. Dependendo das suas preferências, convém executar um cluster de réplica inativa em outra zona e alternar para essa réplica no caso de uma interrupção zonal.
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 da zona: a opção de alta disponibilidade cria uma instância de VM principal e em espera em duas zonas separadas dentro de 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 da região: 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 inglês), em que a réplica promovida aceita novas transações, mesmo que tenha vazado 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 Cloud Spanner.
Uma vez 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: a réplica de leitura precisa processar o registro de transações e o balanceador de carga precisa redirecionar o tráfego. O processamento do registro de transações orienta o tempo de recuperação total.
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.
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.
Roteador de registros e registros de entrada: durante uma interrupção de zona, 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 Spanner
O Cloud 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 Cloud Spanner replicam os dados de forma síncrona em três zonas em uma única região. Uma gravação em uma instância regional do Cloud Spanner é enviada de forma 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 Cloud Spanner resiliente a uma falha de zona fornecendo 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 Cloud 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 outra região e uma réplica na região testemunha). Uma gravação em uma instância multirregional do Cloud 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 Cloud 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 Cloud Spanner para mais informações sobre essas configurações. Para mais informações sobre como funciona a replicação do Cloud Spanner, consulte a documentação sobre replicação.