O principal motivo 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 comerciais 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 do sistema, um ataque de cibersegurança 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 de tempo de atividade, 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 Well-Architected Framework e os elementos básicos de confiabilidade no 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 suas principais funções ou serviços 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 ajudam a formar uma estratégia de continuidade de negócios mais ampla. Do ponto de vista da tecnologia, 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 do ponto de recuperação (RPO) e o objetivo do tempo de recuperação (RTO). Para mais orientações sobre como usar 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, já que significa criar sistemas redundantes. Sistemas redundantes capazes de realizar 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 ou um padrão de DR deve ser motivada por uma análise de impacto nos negócios. Por exemplo, os prejuízos financeiros causados por alguns minutos de inatividade em uma organização de serviços financeiros podem exceder em muito o custo de implementação de um sistema de DR. No entanto, empresas de outros setores podem ficar horas sem funcionar 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, no entanto, é 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 interessante do ponto de vista de custo, porque permite desativar parte da infraestrutura de DR quando ela não está em uso. Para reduzir o custo de uma solução de DR, uma solução de 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 multicloud. Nesse padrão, o ambiente de produção usa um provedor de nuvem e o ambiente de DR usa outro. 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 multirregional 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:
- 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 alto volume de tráfego ao replicar bancos de dados.
- O TCO e o custo de gerenciamento da infraestrutura de rede entre nuvens.
Se os dados precisarem permanecer no seu país para atender aos requisitos regulamentares, 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 reestruturação da sua solução de nuvem, o ideal é que o segundo provedor de nuvem ofereça todos os recursos e serviços necessários na região.
Considerações sobre o design
- Expectativa de DR: as metas de RPO e RTO que sua empresa quer alcançar devem impulsionar a arquitetura de DR e o planejamento de criaçã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 de rehosting, refatoração ou reestruturação dos aplicativos para oferecer as mesmas funções e o mesmo desempenho (ou mais otimizado) no ambiente de nuvem.
- Projetar e criar: 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 de zona de destino no Google Cloud.
Invocação de DR: é importante que o design e o processo de DR considerem as seguintes questões:
- O que aciona um cenário de DR? Por exemplo, um DR pode ser acionado 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 falhas do sistema devem ser projetados para invocar o failover de acordo 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.
Teste: teste e avalie completamente o failover para DR. Verifique se ele atende às suas expectativas de RPO e RTO. Isso pode aumentar sua confiança para invocar a DR quando necessário. Sempre que uma nova mudança ou atualização for feita no processo ou na solução de tecnologia, faça os testes novamente.
Habilidades da equipe: uma ou mais equipes técnicas precisam ter as habilidades e a experiência para criar, operar e resolver problemas da carga de trabalho de produção no ambiente de nuvem, a menos que seu ambiente seja gerenciado por terceiros.
Vantagens
Usar Google Cloud para continuidade de negócios oferece várias vantagens:
- Como o Google Cloud tem muitas regiões em todo o mundo para escolher, é possível usá-lo para fazer backup ou replicar dados para um site diferente no mesmo continente. Você também pode fazer backup ou replicar dados para um site em um continente diferente.
- OGoogle Cloud permite armazenar dados no Cloud Storage
em um bucket
birregional 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 apoiar a continuidade dos negócios e os planos de DR. Além disso, para replicar mais rápido, com um RPO menor, os objetos armazenados em birregiões 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 despesas de capital e operacionais ao 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 pelo armazenamento e pela capacidade de computação que realmente usa.
- Os recursos de elasticidade, como o escalonamento automático, permitem aumentar ou reduzir automaticamente o ambiente de DR 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 emGoogle Cloud com o Compute Engine, o Cloud SQL e o Cloud Load Balancing. Nesse cenário, o banco de dados é pré-provisionado usando um banco de dados baseado em VM ou um banco de dados gerenciado pelo Google Cloud , como o Cloud SQL, para uma recuperação mais rápida com replicação contínua de dados. É possível iniciar VMs do Compute Engine com base em snapshots pré-criados para reduzir os 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, é necessário provisionar as VMs da Web e do aplicativo. Dependendo do nível de RTO desejado e das políticas da empresa, todo o processo para invocar um 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, um serviço de integração contínua, para aplicar automaticamente 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 no 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.
- Enquadre os cenários de DR aplicáveis aos seus aplicativos e dados como parte da estratégia de DR selecionada.
- Considere usar o padrão de transferência quando você estiver fazendo backup apenas de dados. Caso contrário, o padrão em malha 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 de cérebro dividido ocorre quando dois ambientes que replicam dados bidirecionalmente perdem a comunicação entre si. Essa divisão pode fazer com que os sistemas em ambos os 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 split-brain:
- Use um terceiro ambiente de computação. Esse ambiente permite que os sistemas verifiquem se há quorum antes de modificar os dados.
Permitir que as modificações de dados conflitantes sejam reconciliadas após a restauração da conectividade.
Com 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 em espera. Todas as cargas de trabalho precisam ser portáteis (quando compatíveis com os aplicativos e viáveis) para que os sistemas permaneçam consistentes em todos os ambientes. Para isso, considere usar contêineres e o Kubernetes. Ao usar o Google Kubernetes Engine (GKE), é possível simplificar o build e as operações.
Integre a implantação de sistemas em espera 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 (TTL) consideravelmente curto. Assim, você pode redirecionar os usuários para os sistemas em espera quando ocorrer um desastre.
Selecione a política de DNS e a política de roteamento que estejam de acordo 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 configuração híbrida.
Use vários provedores de DNS. Ao usar vários provedores de DNS, você pode:
- Melhorar 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 na nuvem com uma configuração de DNS de vários provedores.
Google Cloud oferece uma solução de código aberto baseada em 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 em 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 ativar alguns cenários que ocorrem ao usar esse padrão de arquitetura. Solicitações de clientes internos ou solicitações de clientes externos 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 Interconexão entre nuvens 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 mais informações, consulte Preços do Cloud Interconnect.
Considere usar sua solução de parceiro preferida no Google Cloud Marketplace para facilitar os backups e as replicações de dados, além de outras tarefas que atendam aos seus requisitos, incluindo as metas de RPO e RTO.
Teste e avalie cenários de invocação de DR para entender com que facilidade o aplicativo pode se recuperar de um evento de desastre em comparação com o valor de 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.