Manual para recuperação de desastres

Quando o assunto é recuperação de desastres, não há um plano único que cubra todas as possibilidades. Este artigo oferece diretrizes para lidar com diversos cenários de recuperação de desastres usando a infraestrutura de nuvem do Google.

Terminologia

Este artigo usa os seguintes termos:

Para uma discussão mais ampla sobre esses conceitos, além de princípios gerais para desenvolver um plano de recuperação de desastres, consulte Desenvolver um plano de recuperação de desastres com o Google Cloud Platform.

Cenários

Esta seção explora os cenários de recuperação de desastres comuns e fornece estratégias de recuperação e implementações de exemplo para cada uma delas no Google Cloud Platform.

Recuperação de dados históricos

Com frequência, os dados históricos precisam ser arquivados por motivos de conformidade, mas também são comumente arquivados para uso em análises históricas futuras. Nos dois casos, é importante arquivar os dados de registro e de bancos de dados relevantes de maneira durável usando um formato de fácil acesso e transformação.

Em geral, os dados históricos têm um RTO médio ou grande. Porém, como se espera que sejam completos e precisos, eles tendem a ter um RPO pequeno.

Como arquivar dados de registro

Os dados de registro, em geral, são usados para análises de tendências históricas e possíveis análises judiciais. No geral, eles não precisam ficar armazenados por anos. Porém, como observado anteriormente, é importante que esses dados possam ser facilmente importados em um formato passível de ser analisado.

O Google Cloud Platform fornece diversas opções para exportar dados de registro, incluindo:

  • Stream para intervalos do Google Cloud Storage, que periodicamente grava seus registros no Cloud Storage. Os arquivos recebem carimbo de data e hora, são criptografados e armazenados em pastas com nomes adequados, facilitando a localização dos registros de um determinado período.
  • Stream para conjuntos de dados do BigQuery, que transmite os registros para um conjunto de dados do BigQuery. O BigQuery armazena dados de maneira fixa, em formato somente leitura.

Para detalhes sobre como exportar registros, consulte Exportar seus registros.

Como arquivar dados de bancos de dados

Os backups de bancos de dados relacionais normalmente usam uma solução em vários níveis, em que os dados ativos são armazenados em um dispositivo de armazenamento local e os backups em soluções de armazenamento progressivamente "mais frias". Nesta solução, um cron job (ou semelhante) faz backup dos dados ativos em um segundo nível em intervalos regulares, e outro job é usado para fazer backup dos dados daquele nível para outro em intervalos ligeiramente maiores.

Uma implementação possível dessa estratégia no Google Cloud Platform é usar discos permanentes para o nível de dados ativos, um intervalo do Cloud Storage padrão para o segundo nível e um intervalo Neartime do Cloud Storage para o último nível. Nessa implementação, os níveis são conectados da seguinte maneira:

  1. Configure o aplicativo para fazer backup dos dados em um disco permanente anexado à instância.
  2. Configure uma tarefa, como um cron job, para mover os dados para o intervalo padrão do Cloud Storage após determinado período de tempo.
  3. Por fim, configure outro cron job ou use o serviço de transferência do Cloud Storage para mover os dados de um intervalo padrão para um intervalo Nearline.

Veja no diagrama abaixo este exemplo de implementação:

Backup em vários níveis
Figura 1: backup em vários níveis

Para criar uma solução de recuperação de desastres completa, você precisa implementar um método de restauração de backups em uma versão compatível com o banco de dados. Veja as três abordagens possíveis:

  • Criar uma imagem personalizada que tem uma versão própria do sistema de banco de dados instalado.

    Assim, você poderá criar uma nova instância do Compute Engine com essa imagem para testar o processo de importação. Essa abordagem requer etapas de testes regulares e rigorosas.

  • Tirar instantâneos regulares do seu sistema de bancos de dados.

    Se o sistema de banco de dados estiver alocado em um disco permanente do Compute Engine, você poderá tirar instantâneos sempre que fizer algum upgrade. Se o sistema ficar inativo ou você precisar reverter para uma versão anterior, basta criar um novo disco permanente a partir do instantâneo desejado e fazer dele um disco de recuperação para uma nova instância do Compute Engine. Para evitar que os dados sejam corrompidos, a abordagem requer o congelamento do disco do sistema de bancos de dados enquanto você tira o instantâneo.

  • Exportar os dados para um formato simples altamente portátil, como CSV, XML ou JSON, e armazená-los em um Nearline do Cloud Storage.

    Essa abordagem proporciona flexibilidade máxima, permitindo importar os dados para o sistema de banco de dados que você escolher. Além disso, JSON e CSV podem ser facilmente importados para o BigQuery, que tornará as análises futuras mais simples e diretas.

Como arquivar diretamente no BigQuery

Dependendo do seu caso de uso, é possível arquivar dados de evento em tempo real diretamente no BigQuery usando inserções de streaming. Isso é particularmente útil para realizar análises de grandes volumes de dados. Para evitar substituições acidentais, você deve usar o IAM para gerenciar quem tem acesso para atualização e exclusão dos dados gravados nas tabelas.

Recuperação de dados corrompidos

Quando um banco de dados é corrompido, seus dados precisam ser recuperados facilmente e disponibilizados com rapidez. Uma boa abordagem é usar backups em combinação com os arquivos de registro transacionais do banco de dados corrompido para retorná-lo a um ponto em que estava em bom estado.

Se você escolheu usar o Cloud SQL, o banco de dados MySQL totalmente gerenciado do Google Cloud Platform, é preciso ativar os backups automatizados e registros binários para as instâncias do Cloud SQL. Isso permite que você realize facilmente uma recuperação de ponto no tempo, o que restaura o banco de dados a partir de um backup e o recupera em uma nova instância do Cloud SQL. Para mais detalhes, consulte Backups e recuperação do Cloud SQL.

Se você gerencia seus próprios bancos de dados relacionais com o Compute Engine, os princípios são os mesmos. No entanto, você é responsável por gerenciar o serviço de banco de dados e implementar um processo de backup adequado.

Se estiver usando um armazenamento de dados apenas para anexação, como o BigQuery, você poderá adotar várias estratégias:

  • Exportar os dados do BigQuery e criar uma nova tabela que contenha os dados exportados, excluindo os dados corrompidos.
  • Armazenar os dados de períodos específicos em tabelas diferentes. Esse método garante que você precisará restaurar apenas um subconjunto de dados em uma nova tabela, e não o conjunto todo.
  • Armazenar os dados originais no Cloud Storage. Isso permite que você crie uma nova tabela e atualize os dados corrompidos. A partir daqui, você pode direcionar seus aplicativos para uma nova tabela.

Além disso, se o RTO permitir, você poderá impedir o acesso à tabela com dados corrompidos deixando seu aplicativo off-line até que os dados não corrompidos sejam restaurados na nova tabela.

Recuperação de aplicativos

É importante manter altos níveis de tempo de atividade. Um serviço indisponível é sinal de perda de negócios. Essa seção examinará maneiras de fazer failover do seu aplicativo para outro local o quanto antes.

Failover de servidores em espera ativa

Esta solução apresenta um servidor on-line continuamente em espera ativa. Ele não receberá tráfego enquanto o servidor de aplicativos principal estiver em pleno funcionamento.

Se o servidor for executado integralmente no Google Compute Engine, você poderá simplificar o failover do aplicativo usando o serviço de balanceamento de carga HTTP do Compute Engine. O balanceamento de carga HTTP aceita tráfego por meio de um endereço IP externo global e o distribui de acordo com as regras de encaminhamento definidas por você. Quando configurado corretamente, o serviço fará o failover automaticamente para o servidor em espera caso a instância principal apresente um problema de integridade.

Failover de servidor em espera semiativa

Esta solução é idêntica ao failover de servidor em espera ativa, mas omite o uso do serviço de balanceamento de carga HTTP do Compute Engine em favor de ajustes manuais de DNS. Aqui, o RTO é determinado pela velocidade com que você ajusta o registro DNS para eliminar a transição para o servidor em espera.

Failover de servidor em espera passiva

Esta solução conta com um servidor de aplicativos off-line em espera idêntico à instância principal. Caso o servidor principal fique off-line, o servidor em espera será instanciado. Quando estiver on-line, o tráfego será direcionado a ele.

O diagrama a seguir ilustra uma possível implementação:

Exemplo de servidor em espera passiva
Figura 2: exemplo de servidor em espera passiva

Neste exemplo, você executará:

  • uma instância de veiculação. Ela faz parte de um grupo de instâncias, que é usado como serviço de back-end para um balanceador de carga HTTP.
  • uma instância mínima que realiza as seguintes funções:

    • Executa um cron job para gerar instantâneos da instância de veiculação em intervalos regulares.
    • Verifica a integridade da instância de veiculação em intervalos regulares.

Essa instância mínima faz parte de um grupo de instâncias gerenciado, que é controlado por um autoescalador do Compute Engine. O autoescalador é configurado para sempre manter exatamente uma instância minima em execução, utilizando um modelo de instância para criar uma nova caso aquela em execução no momento fique indisponível.

Se a instância mínima detectar que a instância de veiculação não está emitindo respostas por um período específico, ela instanciará uma nova usando o instantâneo mais recente e a incluirá no grupo gerenciado. Quando a nova instância ficar on-line, o balanceador de carga HTTP começará a direcionar o tráfego para ela, conforme ilustrado abaixo:

Exemplo de servidor em espera passiva
Figura 3: estado de espera passiva após recuperação

Failover de site estático semiativo

É improvável, mas caso você não consiga veicular seu aplicativo a partir de instâncias do Compute Engine, você pode reduzir as interrupções no serviço com um site estático em espera baseado no Cloud Storage. Esta solução é muito econômica e pode ser particularmente efetiva se o seu site tiver poucos ou nenhum elemento dinâmico. Em caso de falhas, basta alterar as configurações de DNS e uma instância será veiculada imediatamente.

O diagrama a seguir ilustra um exemplo de implementação:

Exemplo de site estático passivo
Figura 4: exemplo de site estático passivo

No exemplo acima, o aplicativo primário é executado em instâncias do Compute Engine. Elas são organizadas em grupos de instâncias gerenciadas, que servem como serviços de back-end para o balanceador de carga HTTP. O balanceador de carga HTTP direciona o tráfego recebido para as instâncias de acordo com sua própria configuração, as respectivas configurações dos grupos e a integridade de cada instância.

Na configuração normal, o Cloud DNS está ajustado para direcionar a este aplicativo primário, e o site estático em espera fica adormecido. Caso o aplicativo do Compute Engine não possa ser veiculado, basta configurar o Cloud DNS para direcionar ao site estático.

Recuperação remota

Se o ambiente de produção estiver no local ou em outro fornecedor de nuvem, o Google Cloud Platform pode ser um destino para backups e arquivos. Com Direct Interconnect, Direct Peering e/ou Cloud VPN, você pode adaptar facilmente as estratégias de recuperação de desastres descritas anteriormente para sua situação. Esta seção aborda métodos de integrar o Google Cloud Platform a estratégias de recuperação remota de desastres.

Como replicar o armazenamento com o Google Cloud Platform

Se você estiver replicando de um dispositivo de armazenamento local, poderá usar o Direct Interconnect ou o peering direto para estabelecer uma conexão com o Google Cloud Platform e, em seguida, copiar seus dados para a solução de armazenamento de sua escolha. Os dados podem ser restaurados para o armazenamento local ou para o Google Cloud Platform.

O diagrama abaixo ilustra uma possível implementação desta solução:

Replicação de armazenamento no local para o Google Cloud Storage
Figura 5: replicação de armazenamento no local para o Google Cloud Storage

Ao replicar de outros serviços de nuvem, use a Google Cloud Storage XML API. Ela é interoperável com algumas ferramentas e bibliotecas de armazenamento em nuvem que funcionam com serviços como o Amazon Simple Storage Service (Amazon S3) e o HP Helion Eucalyptus Storage (Walrus).

Como replicar dados de aplicativos com o Google Cloud Platform

Neste cenário, as cargas de trabalho de produção estão no local e o Google Cloud Platform é o destino para o failover de recuperação de desastres.

Uma possível solução é definir no Google Cloud Platform um pacote de recuperação mínimo, como um servidor de aplicativos em espera passiva e um banco de dados ativo. Configure o servidor para ajustar a escala rapidamente caso seja necessário executar uma carga de trabalho de produção. Nesse caso, o banco de dados precisa estar atualizado. No entanto, os servidores de aplicativos só serão instanciados quando houver necessidade de alternar para a produção. Dependendo do seu RTO, o ponto de inicialização de imagem apropriado será usado para iniciar e configurar uma instância de trabalho.

O diagrama abaixo ilustra como um aplicativo de vários níveis pode ser executado no local usando um pacote de recuperação mínimo no Google Cloud Platform.

Plano de recuperação do local para o Google Cloud Platform
Figura 6: plano de recuperação do local para o Google Cloud Platform

Apenas a instância do servidor do banco de dados está em execução no lado do Google Cloud Platform. Conforme mencionado anteriormente, essa instância precisa ser executada sempre, de modo que possa receber os dados replicados.

Para reduzir custos, você pode executar o banco de dados no menor tipo de máquina capaz de realizar tais serviços. Quando os aplicativos no local precisarem de failover, deixe o sistema do banco de dados pronto para produção desta forma:

  1. Destrua a instância mínima e garanta que o disco permanente contenha o sistema do banco de dados intacto. Se o sistema estiver no disco de inicialização, será preciso definir o estado de exclusão automática do disco como false antes de destruir a instância.
  2. Crie uma nova instância usando um tipo de máquina com os recursos apropriados para processar a carga de produção.
  3. Anexe os discos permanentes que contêm o sistema do banco de dados à nova instância.

Em caso de desastre, o serviço de monitoramento será acionado para acelerar as instâncias de nível de Web e de nível de aplicativo no Google Cloud Platform. Em seguida, você pode ajustar o registro do Cloud DNS para direcionar ao nível de Web. Se estiver usando o serviço de balanceamento de carga HTTP do Compute Engine, poderá direcionar ao IP externo do balanceador. O diagrama a seguir ilustra o estado do ambiente de produção geral após o plano de recuperação de desastres ser executado.

Estado pós-recuperação
Figura 7: estado pós-recuperação

Para valores de RTO menores, você pode ajustar a estratégia acima mantendo todas as instâncias do Compute Engine em operação, mas sem receber tráfego. Consulte Failover de servidor em espera semiativa. Em geral, essa estratégia é mais cara. Se o RTO não permitir o tempo necessário para executar o bootstrap a partir de uma configuração mínima, implemente um ambiente totalmente operacional que veicule o tráfego tanto para o local quanto para o Google Cloud Platform, conforme ilustrado abaixo:

Ambiente de produção híbrido ativo/ativo (local e Google Cloud Platform)
Figura 8: ambiente de produção híbrido ativo/ativo (local e Google Cloud Platform)

Se optar por implementar a abordagem híbrida, certifique-se de usar um serviço DNS que suporte roteamento pesado ao transmitir tráfego para dois ambientes de produção. Desse modo, você pode entregar o mesmo aplicativo de cada um dos ambientes. Caso um ambiente fique indisponível, desative o roteamento DNS para esse ambiente.

Manter a consistência da imagem de máquina

Ao optar por implementar uma solução híbrida no local/na nuvem ou na nuvem/na nuvem, você provavelmente precisará encontrar uma maneira de manter a consistência nos ambientes de produção.

Para ver como criar um pipeline automatizado para a construção contínua de imagens com o Packer e outros utilitários de código aberto, consulte Criações automatizadas de imagem com Jenkins, Packer e Kubernetes.

Se for necessária uma imagem totalmente configurada, use um software como o Packer, que pode criar imagens de máquina idênticas para diversas plataformas a partir de um único arquivo de configuração. No caso do Packer, você pode colocar o arquivo de configuração no controle de versão para acompanhar qual versão é implementada na produção.

Como opção, use ferramentas de gerenciamento de configuração como Chef, Puppet, Ansible ou Saltstack para configurar instâncias com granularidade mais fina, criando imagens de base, imagens minimamente configuradas ou imagens totalmente configuradas, conforme necessário. Para mais informações sobre como usar essas ferramentas com eficácia, consulte Gerenciamento do Compute Engine com Puppet, Chef, Salt e Ansible.

Também é possível converter e importar manualmente as imagens existentes, como Amazon AMIs, imagens de Virtualbox e imagens de disco RAW, para o Compute Engine.

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

Enviar comentários sobre…