O principal motivo para considerar a continuidade da atividade empresarial para sistemas essenciais é ajudar uma organização a ser resiliente e continuar as suas operações empresariais 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, pode minimizar os riscos de um desastre natural que afete a infraestrutura local. Outros cenários de falha incluem falhas graves do sistema, um ataque de cibersegurança ou até mesmo um erro de configuração do sistema.
A otimização de um sistema para resistir a falhas é essencial para estabelecer uma continuidade do negócio eficaz. A fiabilidade do sistema pode ser influenciada por vários fatores, incluindo, entre outros, o desempenho, a resiliência, a disponibilidade de tempo de atividade, a segurança e a experiência do utilizador. Para mais informações sobre como criar a arquitetura e operar serviços fiáveis no Google Cloud, consulte o pilar de fiabilidade do Google Cloud Framework Well-Architected e os elementos básicos da fiabilidade no Google Cloud.
Este padrão de arquitetura baseia-se numa implementação redundante de aplicações em vários ambientes de computação. Neste padrão, implementa as mesmas aplicações em vários ambientes de computação com o objetivo de aumentar a fiabilidade. A continuidade da atividade empresarial pode ser definida como a capacidade de uma organização continuar as suas principais funções ou serviços empresariais a níveis aceitáveis predefinidos após um evento disruptivo.
A recuperação de desastres (RD) é considerada um subconjunto da continuidade da atividade empresarial, focando-se explicitamente em garantir que os sistemas de TI que suportam funções empresariais críticas estão operacionais o mais rapidamente possível após uma interrupção. Em geral, as estratégias e os planos de recuperação de desastres ajudam frequentemente a formar uma estratégia de continuidade do negócio mais abrangente. Do ponto de vista tecnológico, quando começa a criar estratégias de recuperação de desastres, a análise do impacto na empresa deve definir duas métricas principais: o objetivo de ponto de recuperação (RPO) e o objetivo de tempo de recuperação (RTO). Para mais orientações sobre a utilização Google Cloud para resolver a recuperação de desastres, consulte o Guia de planeamento de recuperação de desastres.
Quanto menores forem os valores alvo de RPO e RTO, mais rapidamente os serviços podem recuperar de uma interrupção com uma perda de dados mínima. No entanto, isto implica um custo mais elevado, uma vez que significa criar sistemas redundantes. Os sistemas redundantes capazes de realizar a replicação de dados quase em tempo real e que operam à mesma escala após um evento de falha aumentam a complexidade, os custos administrativos e os custos.
A decisão de selecionar uma estratégia de recuperação de desastres ou um padrão deve ser baseada numa análise do impacto empresarial. Por exemplo, as perdas financeiras incorridas com apenas alguns minutos de inatividade para uma organização de serviços financeiros podem exceder em muito o custo de implementação de um sistema de recuperação de desastres. No entanto, as empresas noutras indústrias podem suportar horas de inatividade sem um efeito empresarial significativo.
Quando executa sistemas essenciais para a missão num centro de dados no local, uma abordagem de recuperação de desastres consiste em manter sistemas de reserva num segundo centro de dados numa região diferente. No entanto, uma abordagem mais rentável é usar um ambiente de computação baseado na nuvem pública para fins de comutação por falha. Esta abordagem é o principal motor do padrão de continuidade do negócio híbrido. A nuvem pode ser especialmente apelativa do ponto de vista dos custos, porque permite desativar parte da sua infraestrutura de recuperação de desastres quando não está em utilização. Para alcançar uma solução de recuperação de desastres de custo mais baixo, uma solução na nuvem permite que uma empresa aceite o potencial aumento nos valores de OPR e OTR.
O diagrama anterior ilustra a utilização da nuvem como um ambiente de recuperação de desastres ou de failover para um ambiente no local.
Uma variante menos comum (e raramente necessária) deste padrão é o padrão de continuidade empresarial em várias nuvens. Nesse padrão, o ambiente de produção usa um fornecedor de nuvem e o ambiente de recuperação de desastres usa outro fornecedor de nuvem. Ao implementar cópias de cargas de trabalho em vários fornecedores de nuvem, pode aumentar a disponibilidade além do que uma implementação multirregional oferece.
A avaliação de uma recuperação de desastres em várias nuvens em comparação com a utilização de um fornecedor de nuvem com diferentes regiões requer uma análise exaustiva de várias considerações, incluindo o seguinte:
- Capacidade de gestão
- Segurança
- Viabilidade geral.
- Custo
- Os potenciais custos de transferência de dados de saída de mais do que um fornecedor de nuvem podem ser dispendiosos com a comunicação contínua entre nuvens.
- Pode haver um elevado volume de tráfego ao replicar bases de dados.
- Custo total de propriedade e o custo de gestão da infraestrutura de rede entre nuvens.
Se os seus dados tiverem de permanecer no seu país para cumprir os requisitos regulamentares, pode usar um segundo fornecedor de nuvem que também esteja no seu país como DR. Essa utilização de um segundo fornecedor de nuvem pressupõe que não existe nenhuma opção para usar um ambiente no local para criar uma configuração híbrida. Para evitar a reestruturação da sua solução na nuvem, o ideal é que o segundo fornecedor de nuvem ofereça todas as capacidades e serviços necessários na região.
Considerações de design
- Expectativa de DR: os objetivos de RPO e RTO que a sua empresa quer alcançar devem orientar a arquitetura de DR e o planeamento de compilação.
- Arquitetura de solução: com este padrão, tem de replicar as funções e as capacidades existentes do seu ambiente no local para cumprir as suas expetativas de recuperação de desastres. Por conseguinte, tem de avaliar a viabilidade e a exequibilidade da reativação da alojamento, da refatoração ou da reestruturação das suas aplicações para fornecer as mesmas funções (ou mais otimizadas) e o mesmo desempenho no ambiente da nuvem.
- Conceber e criar: a criação de uma zona de destino é quase sempre um pré-requisito para implementar cargas de trabalho empresariais num ambiente de nuvem. Para mais informações, consulte o artigo Design da zona de destino no Google Cloud.
Invocações de DR: é importante que o design e o processo de DR tenham em consideração as seguintes questões:
- O que aciona um cenário de recuperação de desastres? Por exemplo, uma DR pode ser acionada pela falha de funções ou sistemas específicos no site principal.
- Como é que a comutação por falha para o ambiente de recuperação de desastres é invocada? É um processo de aprovação manual ou pode ser automatizado para atingir um objetivo de RTO baixo?
- Como devem ser concebidos os mecanismos de deteção e notificação de falhas do sistema para invocar a comutação por falha em conformidade com o RTO esperado?
- Como é que o tráfego é reencaminhado para o ambiente de recuperação após a deteção da falha?
Valide as suas respostas a estas perguntas através de testes.
Testes: teste e avalie exaustivamente a comutação por falha para a recuperação de desastres. Certifique-se de que cumpre as suas expetativas de RPO e RTO. Desta forma, pode ter mais confiança para invocar a DR quando necessário. Sempre que for feita uma nova alteração ou atualização ao processo ou à solução tecnológica, volte a realizar os testes.
Competências da equipa: uma ou mais equipas técnicas têm de ter as competências e a experiência para criar, operar e resolver problemas da carga de trabalho de produção no ambiente de nuvem, a menos que o seu ambiente seja gerido por terceiros.
Vantagens
A utilização Google Cloud para a continuidade do negócio oferece várias vantagens:
- Uma vez que o Google Cloud tem muitas regiões em todo o mundo à sua escolha, pode usá-lo para fazer uma cópia de segurança ou replicar dados para um site diferente no mesmo continente. Também pode fazer uma cópia de segurança ou replicar dados para um site num continente diferente.
- Google Cloud oferece a capacidade de armazenar dados no Cloud Storage
num
contentor de duas regiões ou multirregional. Os dados são armazenados de forma redundante em, pelo menos, duas regiões geográficas separadas. Os dados armazenados em contentores de duas regiões e multirregionais são replicados em regiões geográficas através da replicação predefinida.
- Os contentores de duas regiões oferecem georredundância para suportar a continuidade das atividades e os planos de recuperação de desastres. Além disso, para replicar mais rapidamente, com um RPO mais baixo, os objetos armazenados em duas regiões podem usar opcionalmente a replicação turbo nessas regiões.
- Da mesma forma, a replicação multirregional oferece redundância em várias regiões, armazenando os seus dados dentro do limite geográfico da região múltipla.
- Oferece uma ou mais das seguintes opções para reduzir as despesas de capital
e as despesas operacionais para criar uma DR:
- As instâncias de VM paradas só incorrem em custos de armazenamento e são substancialmente mais baratas do que as instâncias de VM em execução. Isto significa que pode minimizar o custo de manutenção dos sistemas de reserva a frio.
- O modelo de pagamento por utilização Google Cloud significa que só paga pelo armazenamento e pela capacidade de computação que realmente usa.
- As capacidades de elasticidade, como o dimensionamento automático, permitem-lhe dimensionar automaticamente o seu ambiente de recuperação de desastres conforme necessário.
Por exemplo, o diagrama seguinte mostra uma aplicação em execução num ambiente no local (produção) que usa componentes de recuperação emGoogle Cloud com o Compute Engine, o Cloud SQL e o Cloud Load Balancing. Neste cenário, a base de dados é aprovisionada previamente através de uma base de dados baseada em VMs ou de uma base de dados gerida, como o Cloud SQL, para uma recuperação mais rápida com replicação de dados contínua. Google Cloud Pode iniciar VMs do Compute Engine a partir de instantâneos pré-criados para reduzir o custo durante as operações normais. Com esta configuração e após um evento de falha, o DNS tem de apontar para o endereço IP externo do Cloud Load Balancing.
Para ter a aplicação operacional na nuvem, tem de aprovisionar as VMs Web e de aplicações. Consoante o nível de RTO segmentado e as políticas da empresa, o processo completo para invocar uma DR, aprovisionar a carga de trabalho na nuvem e reencaminhar o tráfego pode ser concluído manual ou automaticamente.
Para acelerar e automatizar o aprovisionamento da infraestrutura, considere gerir a infraestrutura como código. Pode usar o Cloud Build, que é um serviço de integração contínua, para aplicar automaticamente manifestos do Terraform ao seu ambiente. Para mais informações, consulte o artigo Gerir a infraestrutura como código com o Terraform, o Cloud Build e o GitOps.
Práticas recomendadas
Quando usar o padrão de continuidade da empresa, considere as seguintes práticas recomendadas:
- Crie um plano de recuperação de desastres que documente a sua infraestrutura, juntamente com os procedimentos de ativação pós-falha e recuperação.
- Considere as seguintes ações com base na análise do impacto na empresa e nos alvos de RPO e RTO necessários identificados:
- Decida se a cópia de segurança dos dados para o Google Cloud é suficiente ou se tem de considerar outra estratégia de recuperação de desastres (sistemas de reserva a frio, a quente ou ativos).
- Defina os serviços e os produtos que pode usar como elementos básicos para o seu plano de DR.
- Enquadre os cenários de DR aplicáveis para as suas aplicações e dados como parte da sua estratégia de DR selecionada.
- Considere usar o padrão de transferência quando estiver apenas a fazer uma cópia de segurança dos dados. Caso contrário, o padrão com malha pode ser uma boa opção para replicar a arquitetura de rede do ambiente existente.
- Minimize as dependências entre sistemas que estão a ser executados em ambientes diferentes, especialmente quando a comunicação é processada de forma síncrona. Estas dependências podem abrandar o desempenho e diminuir a disponibilidade geral.
Evite o problema de divisão de cérebros. Se replicar dados bidirecionalmente em vários ambientes, pode ficar exposto ao problema de divisão de cérebros. O problema de divisão de cérebro ocorre quando dois ambientes que replicam dados bidirecionalmente perdem a comunicação entre si. Esta divisão pode fazer com que os sistemas em ambos os ambientes concluam que o outro ambiente está indisponível e que têm acesso exclusivo aos dados. Isto pode levar a modificações dos dados em conflito. Existem duas formas comuns de evitar o problema de divisão de cérebro:
- Usar um ambiente de computação de terceiros. Este ambiente permite que os sistemas verifiquem a existência de um quórum antes de modificar os dados.
Permitir a conciliação de modificações de dados em conflito após o restauro da conetividade.
Com as bases de dados SQL, pode evitar o problema de divisão de cérebros tornando a instância principal original inacessível antes de os clientes começarem a usar a nova instância principal. Para mais informações, consulte o artigo Recuperação de desastres da base de dados do Cloud SQL.
Certifique-se de que os sistemas de CI/CD e os repositórios de artefactos não se tornam um único ponto de falha. Quando um ambiente não está disponível, tem de conseguir implementar novos lançamentos ou aplicar alterações de configuração.
Torne todas as cargas de trabalho portáteis quando usar sistemas de espera. Todas as cargas de trabalho devem ser portáteis (quando suportadas pelas aplicações e viáveis) para que os sistemas permaneçam consistentes em todos os ambientes. Pode alcançar esta abordagem considerando os contentores e o Kubernetes. Ao usar a edição Enterprise do Google Kubernetes Engine (GKE), pode simplificar a compilação e as operações.
Integre a implementação de sistemas de reserva no seu pipeline de CI/CD. Esta integração ajuda a garantir que as versões e as configurações das aplicações são consistentes em todos os ambientes.
Certifique-se de que as alterações de DNS são propagadas rapidamente configurando o DNS com um valor de tempo de vida razoavelmente curto para poder reencaminhar os utilizadores para sistemas de espera quando ocorrer um desastre.
Selecione a política de DNS e a política de encaminhamento que se alinham com a sua arquitetura e comportamento da solução. Além disso, pode combinar vários equilibradores de carga regionais com políticas de encaminhamento de DNS para criar arquiteturas de equilíbrio de carga globais para diferentes exemplos de utilização, incluindo a configuração híbrida.
Use vários fornecedores de DNS. Quando usa vários fornecedores de DNS, pode:
- Melhorar a disponibilidade e a capacidade de recuperação das suas aplicações e serviços.
Simplifique a implementação ou a migração de aplicações híbridas que têm dependências em ambientes no local e na nuvem com uma configuração de DNS de vários fornecedores.
Google Cloud oferece uma solução de código aberto baseada no octoDNS para ajudar a configurar e operar um ambiente com vários fornecedores de DNS. Para mais informações, consulte o artigo DNS público de vários fornecedores com o Cloud DNS.
Use balanceadores de carga quando usar sistemas de espera para criar uma comutação por falha automática. Tenha em atenção que o hardware do equilibrador de carga pode falhar.
Use o Cloud Load Balancing em vez de balanceadores de carga de hardware para ativar alguns cenários que ocorrem quando usa este padrão de arquitetura. Os pedidos de clientes internos ou pedidos de clientes externos podem ser redirecionados para o ambiente principal ou o ambiente de recuperação de desastres com base em diferentes métricas, como a divisão do tráfego com base no peso. Para mais informações, consulte o artigo Vista geral da gestão de tráfego para o Application Load Balancer externo global.
Considere usar o Cloud Interconnect ou o Cross-Cloud Interconnect se o volume de transferência de dados de saída Google Cloud para Google Cloud o outro ambiente for elevado. O Cloud Interconnect pode ajudar a otimizar o desempenho da conetividade e pode reduzir os encargos de transferência de dados de saída para o tráfego que cumpre determinadas condições. Para mais informações, consulte os preços do Cloud Interconnect.
Considere usar a sua solução de parceiros preferida no Google Cloud Marketplace para ajudar a facilitar as cópias de segurança, as replicações e outras tarefas de dados que cumprem os seus requisitos, incluindo os objetivos de OPR e OTR.
Teste e avalie cenários de invocação de DR para compreender com que facilidade a aplicação consegue recuperar de um evento de desastre em comparação com o valor de RTO alvo.
Encripte as comunicações em trânsito. Para proteger informações confidenciais, recomendamos que encriptem todas as comunicações em trânsito. Se a encriptação for necessária na camada de conetividade, estão disponíveis várias opções com base na solução de conetividade híbrida selecionada. Estas opções incluem túneis de VPN, VPN de alta disponibilidade através do Cloud Interconnect e MACsec para o Cloud Interconnect.