O principal fator para considerar a continuidade de negócios em sistemas de missão crítica é ajudar uma organização a ser resiliente e continuar as operações de negócios durante e após eventos de falha. Ao replicar sistemas e dados em várias regiões geográficas e evitar pontos únicos de falha, é possível minimizar os riscos de um desastre natural que afete a infraestrutura local. Outros cenários de falha incluem falha grave no sistema, um ataque de segurança cibernética ou até mesmo um erro de configuração do sistema.
Otimizar um sistema para resistir a falhas é essencial para estabelecer uma continuidade de negócios eficaz. A confiabilidade do sistema pode ser influenciada por vários fatores, incluindo, mas não se limitando a, desempenho, resiliência, disponibilidade, segurança e experiência do usuário. Para mais informações sobre como arquitetar e operar serviços confiáveis no Google Cloud, consulte o pilar de confiabilidade do Google Cloud Framework de arquitetura e os elementos básicos de confiabilidade em Google Cloud.
Esse padrão de arquitetura depende de uma implantação redundante de aplicativos em vários ambientes de computação. Nesse padrão, você implanta os mesmos aplicativos em vários ambientes de computação com o objetivo de aumentar a confiabilidade. A continuidade de negócios pode ser definida como a capacidade de uma organização de continuar as principais funções ou serviços de negócios em níveis aceitáveis predefinidos após um evento disruptivo.
A recuperação de desastres (DR) é considerada um subconjunto da continuidade de negócios, com foco explícito em garantir que os sistemas de TI que auxiliam as funções críticas da empresa estejam operacionais o mais rápido possível após uma interrupção. Em geral, as estratégias e os planos de DR geralmente ajudam a formar uma estratégia de continuidade de negócios mais ampla. Do ponto de vista tecnológico, quando você começa a criar estratégias de recuperação de desastres, a análise de impacto nos negócios precisa definir duas métricas principais: o objetivo de ponto de recuperação (RPO, na sigla em inglês) e o objetivo de tempo de recuperação (RTO, na sigla em inglês). Para mais orientações sobre como usar o Google Cloud para lidar com a recuperação de desastres, consulte o Guia de planejamento de recuperação de desastres.
Quanto menores forem os valores de RPO e RTO, mais rápido os serviços poderão se recuperar de uma interrupção com perda mínima de dados. No entanto, isso implica um custo maior, porque significa criar sistemas redundantes. Sistemas redundantes capazes de realizar a replicação de dados quase em tempo real e que operam na mesma escala após um evento de falha aumentam a complexidade, a sobrecarga administrativa e o custo.
A decisão de selecionar uma estratégia de DR ou padrão precisa ser orientada por uma análise de impacto nos negócios. Por exemplo, os perdas financeiras decorrentes de alguns minutos de inatividade para uma organização de serviços financeiros podem exceder em muito o custo da implementação de um sistema de DR. No entanto, empresas de outros setores podem suportar horas de inatividade sem um efeito significativo nos negócios.
Quando você executa sistemas essenciais em um data center local, uma abordagem de DR é manter os sistemas de reserva em um segundo data center em uma região diferente. Uma abordagem mais econômica, entretanto, é usar um ambiente de computação baseado em nuvem pública para fins de failover. Essa abordagem é o principal fator do padrão híbrido de continuidade de negócios. A nuvem pode ser especialmente atraente do ponto de vista de custo, porque permite desativar parte da infraestrutura de DR quando ela não está em uso. Para alcançar uma solução de DR de menor custo, uma solução em nuvem permite que uma empresa aceite o possível aumento nos valores de RPO e RTO.
O diagrama anterior ilustra o uso da nuvem como um ambiente de failover ou de recuperação de desastres para um ambiente local.
Uma variante menos comum (e raramente necessária) desse padrão é o padrão de continuidade de negócios de várias nuvens. Nesse padrão, o ambiente de produção usa um provedor de nuvem e o ambiente de DR usa outro provedor de nuvem. Ao implantar cópias de cargas de trabalho em vários provedores de nuvem, é possível aumentar a disponibilidade além do que uma implantação de várias regiões oferece.
Avaliar um DR em várias nuvens em vez de usar um provedor de nuvem com regiões diferentes exige uma análise completa de várias considerações, incluindo as seguintes:
- Gerenciamento
- Segurança
- Viabilidade geral.
- Custo
- As possíveis cobranças de transferência de dados de saída de mais de um provedor de nuvem podem ser caras com a comunicação contínua entre nuvens.
- Pode haver um grande volume de tráfego ao replicar bancos de dados.
- TCO e o custo de gerenciamento da infraestrutura de rede entre nuvens.
Se os dados precisarem ficar no seu país para atender aos requisitos regulatórios, usar um segundo provedor de nuvem que também esteja no seu país como DR pode ser uma opção. O uso de um segundo provedor de nuvem pressupõe que não há opção de usar um ambiente local para criar uma configuração híbrida. Para evitar a reengenharia da solução de nuvem, o segundo provedor de nuvem idealmente precisa oferecer todos os recursos e serviços necessários na região.
Considerações sobre o design
- Expectativa de DR: os objetivos de RPO e RTO que sua empresa quer alcançar devem orientar sua arquitetura de DR e o planejamento de construção.
- Arquitetura da solução: com esse padrão, é necessário replicar as funções e os recursos atuais do ambiente local para atender às expectativas de DR. Portanto, é necessário avaliar a viabilidade e a viabilidade de rehosting, refatoração ou reengenharia de seus aplicativos para fornecer as mesmas funções e desempenho (ou mais otimizados) no ambiente de nuvem.
- Projeto e criação: criar uma zona de destino é quase sempre um pré-requisito para implantar cargas de trabalho empresariais em um ambiente de nuvem. Para mais informações, consulte Design da zona de destino em Google Cloud.
Invocação de DR: é importante que o design e o processo de DR considerem as seguintes perguntas:
- O que aciona um cenário de DR? Por exemplo, uma DR pode ser acionada pela falha de funções ou sistemas específicos no site principal.
- Como o failover para o ambiente de DR é invocado? É um processo de aprovação manual ou pode ser automatizado para atingir uma meta de RTO baixa?
- Como os mecanismos de detecção e notificação de falha do sistema devem ser projetados para invocar o failover em conformidade com o RTO esperado?
- Como o tráfego é redirecionado para o ambiente de DR depois que a falha é detectada?
Valide suas respostas a essas perguntas com testes.
Testes: teste e avalie completamente o failover para DR. Verifique se ele atende às suas expectativas de RPO e RTO. Isso pode dar mais confiança para invocar o DR quando necessário. Sempre que uma nova mudança ou atualização for feita no processo ou na solução de tecnologia, realize os testes novamente.
Habilidades da equipe: uma ou mais equipes técnicas precisam ter as habilidades e a experiência necessárias para criar, operar e resolver problemas da carga de trabalho de produção no ambiente de nuvem, a menos que o ambiente seja gerenciado por terceiros.
Vantagens
O uso de Google Cloud para a continuidade dos negócios oferece várias vantagens:
- Como o Google Cloud tem muitas regiões no mundo para você escolher, é possível usá-lo para fazer backup ou replicar dados para um site diferente no mesmo continente. Também é possível fazer backup ou replicar dados para um site em um continente diferente.
- OGoogle Cloud oferece a capacidade de armazenar dados no Cloud Storage
em um bucket
bi ou multirregional. Os dados são armazenados de maneira redundante em pelo menos duas regiões geográficas diferentes. Os dados armazenados em buckets birregionais e multirregionais são replicados
em regiões geográficas usando a replicação padrão.
- Os buckets birregionais oferecem redundância geográfica para oferecer suporte à continuidade dos negócios e aos planos de DR. Além disso, para replicar mais rápido, com um RPO menor, os objetos armazenados em regiões duplas podem usar opcionalmente a replicação turbo entre essas regiões.
- Da mesma forma, a replicação multirregional oferece redundância em várias regiões, armazenando seus dados dentro do limite geográfico da multirregião.
- Oferece uma ou mais das seguintes opções para reduzir as despesas de capital
e operacionais para criar uma DR:
- As instâncias de VM interrompidas geram apenas custos de armazenamento e são substancialmente mais baratas do que as instâncias de VM em execução. Isso significa que você pode minimizar o custo de manutenção de sistemas em espera frios.
- O modelo de pagamento por uso do Google Cloud significa que você paga apenas pela capacidade de armazenamento e computação que realmente usa.
- Os recursos de elasticidade, como o escalonamento automático, permitem que você aumente ou diminua o ambiente de DR automaticamente, conforme necessário.
Por exemplo, o diagrama a seguir mostra um aplicativo em execução em um ambiente local (produção) que usa componentes de recuperação noGoogle Cloud com o Compute Engine, o Cloud SQL e o Cloud Load Balancing. Nesse cenário, o banco de dados é provisionado previamente usando um banco de dados baseado em VM ou um banco de dados gerenciado por Google Cloud , como o Cloud SQL, para uma recuperação mais rápida com a replicação contínua de dados. É possível iniciar VMs do Compute Engine usando snapshots pré-criados para reduzir custos durante operações normais. Com essa configuração, e após um evento de falha, o DNS precisa apontar para o endereço IP externo do Cloud Load Balancing.
Para que o aplicativo funcione na nuvem, provisione as VMs da Web e do aplicativo. Dependendo do nível de RTO e das políticas da empresa, todo o processo de invocar uma DR, provisionar a carga de trabalho na nuvem e redirecionar o tráfego pode ser concluído manualmente ou automaticamente.
Para acelerar e automatizar o provisionamento da infraestrutura, considere gerenciar a infraestrutura como código. É possível usar o Cloud Build, que é um serviço de integração contínua, para aplicar automaticamente os manifestos do Terraform ao seu ambiente. Para mais informações, consulte Como gerenciar a infraestrutura como código com o Terraform, o Cloud Build e o GitOps.
Práticas recomendadas
Ao usar o padrão de continuidade de negócios, considere as seguintes práticas recomendadas:
- Crie um plano de recuperação de desastres que documente sua infraestrutura, juntamente com os procedimentos de failover e recuperação.
- Considere as seguintes ações com base na sua análise de impacto nos negócios e
nas metas de RPO e RTO identificadas:
- Decida se o backup de dados para Google Cloud é suficiente ou se você precisa considerar outra estratégia de DR (sistemas em espera frios, mornos ou quentes).
- Defina os serviços e produtos que podem ser usados como elementos básicos para seu plano de DR.
- Defina os cenários de DR aplicáveis para seus aplicativos e dados como parte da estratégia de DR selecionada.
- Considere usar o padrão de handover quando você estiver fazendo apenas o backup de dados. Caso contrário, o padrão meshed pode ser uma boa opção para replicar a arquitetura de rede do ambiente atual.
- Minimize dependências entre sistemas que estão sendo executados em ambientes distintos, especialmente quando a comunicação é tratada de maneira síncrona. Essas dependências podem diminuir o desempenho e a disponibilidade geral.
Evite o problema de "dupla personalidade". Se você replicar dados bidirecionalmente entre ambientes, poderá ficar exposto ao problema do cérebro dividido. O problema do cérebro dividido ocorre quando dois ambientes que replicam dados bidirecionalmente perdem a comunicação um com o outro. Essa divisão pode fazer com que os sistemas nos dois ambientes concluam que o outro ambiente está indisponível e que eles têm acesso exclusivo aos dados. Isso pode levar a modificações conflitantes dos dados. Há duas maneiras comuns de evitar o problema de cérebro dividido:
- Use um terceiro ambiente de computação. Esse ambiente permite que os sistemas verifiquem se há quorum antes de modificar dados.
Permitir que as modificações de dados conflitantes sejam reconciliadas após a restauração da conectividade.
Com os bancos de dados SQL, é possível evitar o problema de "dupla personalidade" tornando a instância principal original inacessível antes que os clientes comecem a usar a nova instância principal. Para mais informações, consulte Recuperação de desastres do banco de dados do Cloud SQL.
Garanta que os sistemas de CI/CD e os repositórios de artefatos não se tornem um ponto único de falha. Quando um ambiente não está disponível, é preciso que você possa implantar novas versões ou aplicar alterações de configuração.
Torne todas as cargas de trabalho portáteis ao usar sistemas de espera. Todas as cargas de trabalho precisam ser portáveis (quando possível e com suporte dos aplicativos) para que os sistemas permaneçam consistentes em todos os ambientes. Você pode alcançar essa abordagem considerando contêineres e Kubernetes. Ao usar o Google Kubernetes Engine (GKE) Enterprise, você pode simplificar o build e as operações.
Integre a implantação de sistemas de reserva ao seu pipeline de CI/CD. Essa integração ajuda a garantir que as versões e configurações do aplicativo sejam consistentes entre os ambientes.
Para garantir que as mudanças de DNS sejam propagadas rapidamente, configure o DNS com um valor de time to live consideravelmente curto. Assim, você pode redirecionar os usuários para os sistemas em espera quando ocorre um desastre.
Selecione a política de DNS e a política de roteamento que estão alinhadas com sua arquitetura e o comportamento da solução. Além disso, é possível combinar vários balanceadores de carga regionais com políticas de roteamento de DNS para criar arquiteturas de balanceamento de carga global para diferentes casos de uso, incluindo a configuração híbrida.
Use vários provedores de DNS. Ao usar vários provedores de DNS, você pode:
- Melhore a disponibilidade e a resiliência dos seus aplicativos e serviços.
Simplifique a implantação ou migração de aplicativos híbridos que têm dependências entre ambientes locais e de nuvem com uma configuração de DNS de vários provedores.
OGoogle Cloud oferece uma solução de código aberto baseada no octoDNS para ajudar você a configurar e operar um ambiente com vários provedores de DNS. Para mais informações, consulte DNS público de vários provedores usando o Cloud DNS.
Use balanceadores de carga ao usar sistemas de espera para criar um failover automático. O hardware do balanceador de carga pode falhar.
Use o Cloud Load Balancing em vez de balanceadores de carga de hardware para gerar alguns cenários que ocorrem ao usar esse padrão de arquitetura. As solicitações de clientes internas ou externas podem ser redirecionadas para o ambiente principal ou de DR com base em diferentes métricas, como divisão de tráfego com base em peso. Para mais informações, consulte Visão geral do gerenciamento de tráfego para o balanceador de carga de aplicativo externo global.
Considere usar o Cloud Interconnect ou o Cross-Cloud Interconnect se o volume de transferência de dados de saída de Google Cloud para o outro ambiente for alto. O Cloud Interconnect ajuda a otimizar o desempenho da conectividade e pode reduzir as cobranças da transferência de dados de saída do tráfego que atender a determinadas condições. Para saber mais, consulte Preços do Cloud Interconnect.
Considere usar a solução de parceiro preferida no Google Cloud Marketplace para facilitar os backups de dados, as replicações e outras tarefas que atendem aos seus requisitos, incluindo as metas de RPO e RTO.
Teste e avalie os cenários de invocação de DR para entender a rapidez com que o aplicativo pode se recuperar de um evento de desastre em comparação com o valor RTO desejado.
Criptografar as comunicações em trânsito. Para proteger informações sensíveis, recomendamos criptografar todas as comunicações em trânsito. Se a criptografia for necessária na camada de conectividade, várias opções estarão disponíveis com base na solução de conectividade híbrida selecionada. Essas opções incluem túneis VPN, VPN de alta disponibilidade pelo Cloud Interconnect e MACsec para Cloud Interconnect.