Guia de planejamento de recuperação de desastres

Este artigo é a primeira parte de uma série de várias partes, que discute a recuperação de desastres (DR) no Google Cloud Platform (GCP). Nesta parte, apresentamos uma visão geral do processo de planejamento de "Recuperação de desastres" (DR, na sigla em inglês): o que você precisa saber para projetar e implementar um plano de DR. Nas partes seguintes, discutimos casos de uso de DR específicos, com implementações de exemplo no GCP.

A série consiste nestas partes:

Introdução

Casos de interrupção de serviço podem acontecer a qualquer momento. Sua rede pode ter uma interrupção, seu último push de aplicativo pode apresentar um erro crítico ou talvez você tenha que lidar com um desastre natural. Quando as coisas dão errado, é importante ter um plano de DR robusto, direcionado e bem testado.

Com a adoção de um plano de recuperação de desastres bem-projetado e bem-testado, no caso de uma catástrofe é possível garantir que o impacto sobre os resultados da empresa seja mínimo. Independentemente das suas necessidades de DR, o Google Cloud Platform (GCP) tem uma seleção de produtos e recursos robusta, flexível e econômica, que pode ser usada para criar ou ampliar a solução certa para você.

Noções básicas de planejamento de DR

A DR é um subconjunto do planejamento de continuidade de negócios. O planejamento de DR começa verificando os negócios com uma análise de impacto, em que são definidas duas métricas principais:

  • Um objetivo do tempo de recuperação (RTO, na sigla em inglês), que é o período máximo aceitável em que o aplicativo pode ficar off-line. Este valor é normalmente definido como parte de um contrato de nível de serviço (SLA, na sigla em inglês) maior.
  • Um objetivo do ponto de recuperação (RPO, na sigla em inglês), que é o período máximo aceitável em que os dados podem ser perdidos pelo aplicativo devido a um grande incidente. Essa métrica varia com base nas maneiras como os dados são usados. Por exemplo, os dados do usuário que são frequentemente modificados podem ter um RPO de apenas alguns minutos. Por outro lado, dados menos críticos e modificados com pouca frequência podem ter um RPO de várias horas. Nessa métrica, apenas é descrito o período de tempo, não é abordada a quantidade ou a qualidade dos dados perdidos.

Normalmente, quanto menores forem os valores de RTO e RPO, ou seja, quanto mais rápido o aplicativo precisar se recuperar de uma interrupção, maior será o custo para que ele seja executado. O gráfico a seguir mostra a proporção de custo para RTO/RPO.

Gráfico mostrando que os pequenos RTO/RPO são associados a alto custo.

Como os valores RTO e RPO menores geralmente significam maior complexidade, a sobrecarga administrativa associada segue uma curva semelhante. Um aplicativo de alta disponibilidade pode exigir que você gerencie a distribuição entre dois data centers fisicamente separados, gerencie a replicação e muito mais.

Os valores de RTO e RPO geralmente são convertidos em outra métrica: o objetivo de nível de serviço (SLO), que é um elemento chave mensurável de um SLA. SLAs e SLOs são frequentemente confundidos. Um SLA é o acordo completo, que especifica qual serviço deve ser fornecido, como ele é suportado, horários, locais, custos, desempenho, penalidades e responsabilidades das partes envolvidas. Os SLOs são características específicas e mensuráveis do SLA, como disponibilidade, taxa de transferência, frequência, tempo de resposta ou qualidade. Um SLA pode conter muitos SLOs. RTOs e RPOs são mensuráveis e devem ser considerados SLOs.

Leia mais sobre SLOs e SLAs no livro Engenharia de confiabilidade de sites do Google.

Talvez você esteja planejando uma arquitetura para alta disponibilidade (HA, na sigla em inglês). O HA não se sobrepõe totalmente ao DR, mas geralmente é necessário considerar o HA quando você está pensando nos valores de RTO e RPO. O HA ajuda a garantir um nível acordado de desempenho operacional, geralmente tempo de atividade, por um período maior que o normal. Quando você executa cargas de trabalho de produção no GCP, é possível usar um sistema distribuído globalmente para que, se algo der errado em uma região, o aplicativo continue a fornecer o serviço, mesmo que esteja disponível com amplitude reduzida. Em essência, esse aplicativo chama seu plano de DR.

Por que usar o GCP?

Os custos associados ao RTO e ao RPO podem ser bastante reduzidos com o GCP, quando comparado ao atendimento dos requisitos de RTO e RPO nas instalações. Por exemplo, no planejamento tradicional de recuperação de desastres você precisa atender a vários requisitos, incluindo:

  • capacidade: aquisição de recursos suficientes para fazer o dimensionamento conforme necessário;
  • segurança: segurança física para proteger os recursos;
  • infraestrutura de rede: componentes de software, como firewalls e balanceadores de carga;
  • suporte: disponibilização de técnicos capacitados para realizar manutenções e solucionar problemas;
  • largura de banda: largura de banda adequada para carga de pico;
  • instalações: infraestrutura física, incluindo equipamentos e energia.

Ao fornecer uma solução altamente gerenciada em uma plataforma de produção de classe mundial, o GCP permite que você ignore a maioria ou todos esses fatores complicadores, eliminando muitos custos comerciais no processo. Além disso, o foco do GCP na simplicidade administrativa faz com que os custos de gerenciamento de um aplicativo complexo também sejam reduzidos.

No GCP há vários recursos relevantes para o planejamento de DR, incluindo:

  • Uma rede global. O Google tem uma das maiores e mais avançadas redes de computadores do mundo. A rede de backbone do Google tem milhares de quilômetros de cabo de fibra óptica, usa rede definida por software avançada e tem serviços de armazenamento em cache próximo dos usuários finais para oferecer desempenho rápido, consistente e escalonável.
  • Redundância. Vários pontos de presença (PoPs, na sigla em inglês) em todo o mundo significam uma redundância forte. Seus dados são espelhados automaticamente em dispositivos de armazenamento em vários locais.
  • Dimensionamento. O GCP foi desenvolvido para ser dimensionado como outros produtos do Google (por exemplo, pesquisa e Gmail), mesmo quando você enfrenta um grande pico de tráfego. Os serviços gerenciados, como App Engine, autoescaladores do Compute Engine e Cloud Datastore, oferecem escalonamento automático que permite a expansão e a redução do aplicativo conforme necessário.
  • Segurança. O modelo de segurança do Google se baseia em mais de 15 anos de experiência, ajudando a manter os clientes seguros em aplicativos do Google, como o Gmail e o G Suite. Além disso, as equipes de engenharia de confiabilidade do Google ajudam a garantir alta disponibilidade e impedir o abuso de recursos da plataforma.
  • Conformidade. O Google passa por auditorias de terceiros independentes que verificam se o GCP está alinhado aos regulamentos e práticas recomendadas de segurança, privacidade e conformidade. O GCP está em conformidade com certificações como ISO 27001, SOC 2/3 e PCI DSS 3.0.

Padrões de DR

Os padrões de DR são considerados como frio, morno ou quente. Esses padrões indicam a facilidade com que o sistema pode se recuperar quando algo dá errado. Uma analogia poderia ser o que você faria se estivesse dirigindo e furasse um pneu de carro.

Três fotos de cenários de carros com pneus furados: sem reposição; um sobressalente com ferramentas; um pneu furado.

O que você fará depende de como estará preparado para lidar com um pneu furado:

  • Frio: você não tem pneu sobressalente, então precisará chamar alguém para vir até você com um pneu novo e substituí-lo. Sua viagem é interrompida até que a ajuda chegue para fazer o reparo.
  • Morno: você tem um pneu sobressalente e um kit de substituição para poder voltar à estrada usando o que tem no carro. No entanto, você precisa interromper sua jornada para reparar o problema.
  • Quente: você tem pneus "run-flat". Talvez você precise desacelerar um pouco, mas não há impacto imediato na jornada. Você precisará resolver o problema, mas os pneus funcionam bem o suficiente para que possa continuar, embora precise acabar resolvendo o problema.

Como criar um plano detalhado de DR

Nesta seção, fornecemos recomendações sobre como criar seu plano de DR.

Projetar de acordo com as metas de recuperação

Ao projetar seu plano de DR, você precisa combinar suas técnicas de aplicativo e recuperação de dados e analisar a visão geral. A maneira típica de fazer isso é observar seus valores de RTO e RPO e qual padrão de DR é possível adotar para atender a esses valores. Por exemplo, no caso de dados orientados para conformidade histórica, você provavelmente não precisa de acesso rápido aos dados, portanto, um valor grande de RTO e um padrão de DR frio é apropriado. No entanto, se serviço on-line sofrer uma interrupção, convém recuperar o mais rápido possível os dados e a parte do aplicativo voltada para o cliente. Nesse caso, um padrão quente seria mais apropriado. Seu sistema de notificação por e-mail, que normalmente não é essencial para os negócios, provavelmente é um candidato a um padrão morno.

Para receber orientações sobre como usar o GCP na abordagem de cenários comuns de DR, examine os cenários de recuperação de aplicativos. Nesses cenários, são apresentadas estratégias de DR direcionadas para vários casos de uso, além de exemplos de implementações no GCP para cada um.

Projetar para recuperação completa

Não basta apenas ter um plano para fazer backup ou arquivar seus dados. Verifique se em seu plano de DR foi abordado o processo de recuperação completo, desde o backup até a restauração e a limpeza. Discutimos isso nos documentos relacionados sobre dados e recuperação de DR.

Tornar as tarefas específicas

Quando é hora de executar seu plano de DR, você não quer ficar preso adivinhando o que as etapas significam. Faça com que as tarefas de seu plano de DR incluam um ou mais comandos ou ações concretas e não ambíguas. Por exemplo, "Executar o script de restauração" é muito geral. Por outro lado, "Abrir Bash e executar /home/example/restore.sh " é preciso e concreto.

Implementar medidas de controle

Adicione controles para evitar a ocorrência de desastres e detectar problemas antes que eles ocorram. Por exemplo, você tem a opção de adicionar um monitor que envie um alerta quando um fluxo de destruição de dados, como um pipeline de exclusão, mostrar picos inesperados ou outras atividades incomuns. Esse monitor também pode eliminar os processos do canal, se um determinado limite de exclusão for atingido, evitando uma situação catastrófica.

Preparar seu software

Parte do seu planejamento de recuperação de desastres é garantir que o software em que você confia esteja pronto para um evento de recuperação.

Verificar a possibilidade de instalação do software

Certifique-se de que o software do aplicativo possa ser instalado a partir da origem ou de uma imagem pré-configurada. Verifique se está devidamente licenciado para implantar qualquer software necessário no GCP. Consulte o fornecedor do software para receber orientação.

Projetar implantação contínua para recuperação

Seu conjunto de ferramentas de implantação contínua (CD) é um componente integral quando você está implantando seus aplicativos. Como parte do seu plano de recuperação, você precisa considerar onde, no ambiente recuperado, você implantará os artefatos. Planeje onde você quer hospedar seu ambiente de CD e artefatos, eles precisam estar disponíveis e operacionais no caso de um desastre.

Implementar controles de segurança e conformidade

A segurança é importante quando você cria um plano de DR. Os mesmos controles que você tem em seu ambiente de produção precisam se aplicar ao ambiente recuperado. Os regulamentos de conformidade também se aplicam ao ambiente recuperado.

Configurar a segurança da mesma forma usada para os ambientes de DR e produção

Verifique se seus controles de rede fornecem a mesma separação e bloqueio, usados no ambiente de produção. Aprenda a configurar a VPC compartilhada e os firewalls do GCP para permitir o estabelecimento de uma rede centralizada e o controle de segurança da sua implantação, configurar sub-redes, controlar o tráfego de entrada e saída, entre outros. Entenda como usar contas de serviço para implementar privilégios mínimos para aplicativos que acessam APIs do GCP. Verifique se estão sendo usadas contas de serviço como parte das regras de firewall.

Garanta que seja concedido, aos usuários, o mesmo acesso ao ambiente de DR que eles têm no ambiente de produção de origem. Na lista a seguir, descrevemos maneiras de sincronizar permissões entre ambientes:

  • Se ambiente de produção for o GCP, a replicação de políticas do IAM no ambiente de DR será direta. É possível usar métodos de infraestrutura como código (IAC, na sigla em inglês) e empregar ferramentas como o Cloud Deployment Manager para implantar suas políticas do Cloud IAM para produção. Em seguida, use as mesmas ferramentas para vincular as políticas aos recursos correspondentes no ambiente de DR como parte do processo para manter esse ambiente.

  • Se o ambiente de produção estiver no local, mapeie os papéis funcionais, como o administrador da rede e os papéis do auditor, para as políticas do IAM que tenham os papéis apropriados do IAM. A documentação do IAM tem alguns exemplos de configurações de papéis funcionais. Por exemplo, consulte a documentação sobre como criar papéis funcionais de rede e de registro de auditoria.

  • Você precisa configurar as políticas do IAM para conceder permissões apropriadas aos produtos. Por exemplo, convém restringir o acesso a intervalos específicos do Cloud Storage.

  • Se o ambiente de produção for outro provedor de nuvem, mapeie as permissões nas políticas de IAM do provedor para as políticas de IAM do GCP. Por exemplo, se o ambiente de produção for AWS, leia GCP para profissionais do AWS: gerenciamento para conhecer os detalhes.

Verificar sua segurança de DR

Depois de configurar as permissões para o ambiente de recuperação de desastres, verifique se tudo foi testado. Crie um ambiente de teste. Use os métodos do IAC, que empregam ferramentas como o Deployment Manager, para implantar suas políticas do IAM no ambiente de teste. Verifique se o acesso que você concede aos usuários confere as mesmas permissões que os usuários recebem no local.

Verificar se os usuários podem efetuar login no ambiente DR

Da mesma forma, não espere que ocorra um desastre. Verifique, antes, se os usuários podem acessar o ambiente de recuperação de desastres. Verifique se foram concedidos direitos de acesso apropriados a usuários, desenvolvedores, operadores, cientistas de dados, administradores de segurança, administradores de rede e quaisquer outros papéis na organização. Se você estiver usando um sistema de identidade alternativo, verifique se as contas foram sincronizadas com sua conta do Cloud Identity. Como o ambiente de recuperação de desastres será seu ambiente de produção por um tempo, adote medidas para que os usuários que precisarão acessar esse ambiente façam login e resolvam qualquer problema de autenticação. Incorpore usuários que estejam efetuando login no ambiente de DR como parte dos testes regulares de DR implementados por você.

Para gerenciar centralmente quem tem acesso SSH às máquinas virtuais (VMs) iniciadas, ative o recurso de login do sistema operacional nos projetos do GCP que constituam seu ambiente de DR.

Treinar usuários

Os usuários precisam entender como realizar, no GCP, as ações que estão acostumados a realizar no ambiente de produção, como efetuar login, acessar VMs e assim por diante. Usando o ambiente de teste, treine seus usuários para executar essas tarefas de maneira a proteger a segurança do seu sistema.

Verificar se o ambiente de DR atende aos requisitos de conformidade

Verifique se o acesso a seu ambiente de DR está restrito somente àqueles que precisam de acesso. Verifique se os dados de PII estão editados e criptografados. Se você realizar testes de penetração regulares no ambiente de produção, deverá incluir seu ambiente de DR como parte desse escopo e realizar testes regulares com a permanência em um ambiente de DR.

Verifique se, enquanto seu ambiente de DR estiver em serviço, todos os registros coletados serão preenchidos no arquivo de registros do ambiente de produção. Da mesma forma, verifique se, como parte de seu ambiente de recuperação de desastres, é possível exportar registros de auditoria, que são coletados por meio do Stackdriver, para seu arquivo de coletor de registros principal. Use as facilidades do coletor de exportação. Para registros de aplicativos, crie um espelho do ambiente de monitoramento e geração de registros no local. Se o ambiente de produção for outro provedor de nuvem, mapeie o registro e o monitoramento desse provedor para os serviços equivalentes do GCP. Tenha um processo para formatar a entrada no ambiente de produção.

Usar o Cloud Storage como parte das rotinas diárias de backup

Usar o Cloud Storage para armazenar backups. Verifique se os intervalos em que estão seus backups têm as permissões apropriadas aplicadas a eles.

Gerenciar segredos adequadamente

Gerenciar segredos e chaves para envolvidos com o aplicativo usando o GCP para hospedar o serviço de gerenciamento de chaves/segredo (KMS). Use o Cloud KMS ou uma solução de terceiros, por exemplo, o HashiCorp Vault com um back-end do GCP, como Cloud Spanner ou Cloud Storage.

Tratar dados recuperados como dados de produção

Verifique se os controles de segurança aplicados aos dados de produção também se aplicam aos dados recuperados: as mesmas permissões, criptografia e requisitos de auditoria devem se aplicar.

Saiba onde seus backups estão localizados e quem está autorizado a restaurar os dados. Verifique se o processo de recuperação é auditável após uma recuperação de desastre, veja quem teve acesso aos dados de backup e quem executou a recuperação.

Verificar se o plano de DR funciona

Você quer ter certeza de que seu planejamento vale a pena, garantindo que, se ocorrer um desastre, tudo funcionará como você pretende.

Manter mais de um caminho de recuperação de dados

No caso de um desastre, seu método de conexão ao GCP pode ficar indisponível. Implemente um meio alternativo de acesso ao GCP para ajudar a garantir a transferência de dados para o GCP. Teste regularmente se o caminho de backup está operacional.

Testar o plano regularmente

Depois de criar um plano de DR, teste-o regularmente e observe quaisquer problemas que surgirem. Ajuste o plano como necessário. Use o GCP para testar cenários de recuperação a um custo mínimo. Para ajudar nos testes, é recomendável que você implemente o seguinte:

  • Automatizar o provisionamento de infraestrutura com o Deployment Manager. É possível usar o Deployment Manager para automatizar o aprovisionamento de instâncias da VM e outras infraestruturas do GCP. Se você estiver executando o ambiente de produção no local, será necessário ter um processo de monitoramento que possa iniciar o processo de DR ao detectar uma falha e acionar as ações de recuperação apropriadas.
  • Monitorar e depurar os testes com o Stackdriver Logging e o Stackdriver Monitoring. O GCP tem excelentes ferramentas de geração de registros e monitoramento que podem ser acessadas por chamadas de API. Com isso, é possível automatizar a implantação de cenários de recuperação por meio da reação às métricas. Ao criar testes, verifique se você tem monitoramento e alertas adequados que possam acionar ações de recuperação apropriadas.
  • Executar o teste anotado anteriormente:

    • Teste se as permissões e o acesso do usuário funcionam no ambiente de DR, como fazem no ambiente de produção.
    • Realize testes de penetração no ambiente DR.
    • Realize um teste em que o caminho de acesso habitual ao GCP não funcione.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…