Business Continuity

É notório o crescente interesse das empresas no tema de Recuperação de Desastres (Disaster Recovery | DR). Comparado a alguns anos atrás, nota-se um incremento de interesse por parte de empresas e orgãos públicos de todos os tamanhos. As razões variam:

  • Há mais regulamentações e normas de serviço que passam a exigir planos de continuidade de negócios (Business Continuity Plan | BCP), nos quais recuperação de desastres é uma parte desse plano
  • As tecnologias evoluiram e se tornaram mais acessiveis.
    • Antes era necessário construir uma infra-estrutura física redundante ou alugar uma área na infra-estrutrura física de terceiros, prestadores de serviços de datacenter
  • Há uma maior consciência dos gestores de negócios da dependência que suas empresas e atividades tem da tecnologia e, o impacto financeiro e/ou de imagem que a insdisponibilidade prolongada pode gerar.

A implementação de qualquer sistema de recuperação de desastres (desde um cluster local, passando por uma replicação remota, até um cluster geográfico) era, até pouco tempo, um projeto bem estudado de detalhado, levando em consideração uma série de fatores que influenciam no desenho e garantem, tanto a segurança do processo e das informações envolvidas, quanto a performance e a cobertura de todos os pontos únicos de falha, mesmo que essa cobertura se desse pela decisão de não aplicar deteminadas configurações que adicionam complexidade, custos ou criticidade a eles. 

Os fatores que são levados em consideração no desenho de um projeto de recuperação de desastres variam do objetivo (prover disponibilidade local, regional ou geográfico, automatizado, automático ou manual). São vários, mais alguns exemplos mais comuns são:

  • Espectativas/Necessidades de SLA de cada categoria de aplicação
    • RTO - Recovery Time Objective - Tempo aceitável/suportável, do ponto de vista do negócio, entre a ocorrência de uma falha e sua correção/mitigação
    • RPO - Recovery Point Objective - Ponto no passado no qual é aceitável, do ponto de vista do negócio, que os dados de uma determinada aplicação sejam recuperados, considerando ou não potências perdas de dados
  • Proteção de Aplicações
    • Número, tipo e quantidade de dados de cada uma das aplicações consideradas críticas para o negócio
    • Espectativas de variação do volume total de dados das aplicações envolvidas ao longo do tempo
    • Taxas de modificação de dados das aplicações ao longo do tempo (segundo a segundo dependendo do projeto)
  • Conectividade disponível ou tecnicamente/financeiramente viável entre as localidades (em caso de recuperações regionais ou geográficas)
    • Tipo e quantidade de conexões
    • Largura e Flutuação de Banda
    • Latência / Tempo de resposta

A análise desses parâmetros definem, desde o tipo de processo necessário ou possível a ser utilizado para cada aplicação, em uma relação de custo/benefício, até a arquitetura necessária para se atingir esses objetivos.

O que chama atenção nos últimos anos, com a disseminação da necessidade, da consciência e dos métodos com relação a recuperação de desastres, é a aplicação inadequada dos processos possíveis. Seja pela não observância dos critérios acima, seja por desconhecimento do cliente ou do fornecedor. Isso gera riscos para as aplicações, para o processo e, consequêntemente, para o negócio.

Duas condições me preocupam em especial por ter visto serem utilizados de forma inadequada por clientes e fornecedores:

  • Replicação Síncrona e Espelhamento Remoto
  • Recuperação de Falhas (Failover) Automática entre Localidades

 

Replicação Sincrona e Espelhamento Remoto

A replicação sincrona é a forma pela qual, todos os bits alterados na origem são simultâneamente armazenados nos dispositivos de gravação da origem e do destino e, só depois, a aplicação recebe o OK (Acknoledge) e continua a operação. Esse tipo de processo é realizado, ou de Storage para Storage, ou por Software de Replicação, ou por dispositivos de virtualização de SAN (SAN é a rede armazenamento | Storage Area Network). Em processos de replicação, o lado origem é ativo (online) e o destino é passivo (offline).

Espelhamento Remoto é muito similar a replicação sincrona no que tange a gravação simultânea, com a digerença de que, no espelhamento, ambos os lados são ativos/acessíveis. Esse tipo de processo é realizado por dispositivos de virtualização da SAN ou por software, geralmente gerenciadores de volumes (Volume Managers).

Por conta dessa característica (gravação simultânea na origem e no destino), esse tipo de processo só deveria ser utilizado em conexões (links) de baixa latência (tempo de resposta) e que tivessem garantia de largura, sem flutuações importantes.

Geralmente se utilizam cabos de fibra ótica exclusivos ou links contratados do tipo DWDM para tal, pois garantem esses parâmetros.

Cabe ressaltar que esse tipo de conexão sofre uma limitação de distância de aproximadamente 100km. Isso porque, acima dessa distância, a latência começa a ficar proibitiva para o funcionamento das aplicações. A latência aceitável varia de aplicação para aplicação mas, dificilmente chega a 5 milissegundos.

O erro esta em tentar se valer de outros tipos de conexão para realizar replicações sincronas ou espelhamentos remotos. Duas situações podem ocorrer:

  • Um incremento da latência pode, no melhor dos casos, deixar as aplicações lentas, no pior dos casos, ser intolerável pelas aplicações, derrubando-as/indisponibilizando-as
  • Uma flutuação importante da banda pode, desde deixar as aplicações lentas, até derruba-las ou, no pior dos casos, causar o dessincronismo dos dados remotos, tornando-os inúteis até que um ressincronismo integral seja realizado o que, na prática, quer dizer que não há proteção contra desastres efetivo nesse período de ressincronismo, que pode levar horas ou mesmo dias.

 

Failover Automático entre Localidades

Failover automático é o processo pelo qual, na eventualidade de uma falha de uma aplicação por razões físicas ou lógicas em um servidor ou localidade, um outro servidor na mesma localidade ou em localidade diferente assume, automaticamente e sem interferência manual, a operação daquela aplicação.

Para que seja adequado, seguro e garantido para o negócio, o failover automático entre localidades deve respeitar algumas condições, dentre as quais as mais importantes:

  • A replicação das alterações deve ser sincrona ou via espelhamento, respeitando as condições acima. Dessa forma, garante-se que, ao assumir o funcionamento da aplicação, a localidade remota esteja operando à partir do último ponto antes da falha (perda zero de dados).
  • Não devem haver pontos únicos de falha na comunicação entre as localidades, tudo deve ser redundante e verificável

Na inexistência de qualquer das condições acima, seja porque os links são inadequados para replicação sincrona, ou porque há pontos únicos de falha, a declaração de desastre (failover), deve ser manual:

  • Na impossibilidade de replicar de forma sincrona, há o risco de perda de dados se houver atraso, portanto, essa decisão deve ser uma decisão de negócio, não de uma ferramenta. Os gestores devem avaliar se, naquela ocorrência em específico é melhor aguardar a correção/estabilização local ou assumir uma eventual perda das últimas informações e declarar desastre, movendo os serviços para a localidade remota.
  • Existindo pontos únicos de falha, os gestores devem avaliar se, naquela ocorrência, é realmente uma indisponibilidade e os serviços devem ser assumidos pela localidade remota, ou trata-se de um falso positivo e os serviços devem ser mantidos na localidade original.

Entre localidades, entende-se que, devem haver conexões redundantes e completamente independentes entre si, inclusive em relação ao fornecedor da conexão e seu caminho físico (devem seguir rotas distintas). Repare que, mesmo contratando links de fornecedores diferentes, muitas vezes esses fornecedores compartilham os caminhos físicos ou parte dos caminhos logo, inclusive isso deve ser levantado e considerado na eliminação dos pontos únicos de falha.

Não havendo conexões redundantes, o risco é que, em uma indisponibilidade de link, a localidade remota entenda que a localidade original está indisponível e assuma o fornecimento dos serviços, enquanto a localidade original ainda está com esses serviços ativos. Essa condição indesejável tem o nome técnico de Split Brain. Há, portanto, risco de se perder o sincronismo das informações entre as localidades e, mais grave, o risco de que cada localidade esteja processando dados de forma dessincronizada entre si, causando uma inconsistência, no mínimo, muito difícil de ser sanada.

 

Por que dessa análise e dessas orientações?

Até alguns anos atrás, a recuperação de desastres entre localidades não estava financeiramente ao alcance de todos e, envolviam análise e consultoria especializada. Uma evolução muito boa nesse mercado é que, hoje, há alternativas acessíveis - especialmente a opção de realizar recuperações de desastres na nuvem - e fáceis de implementar que exigem pouca, ou mesmo nenhuma consultoria especializada.

Conexões entre o datacenter do cliente (ou CPD) e a nuvem são feitas, na imensa maioria dos casos, através de um túnel VPN rodando em um link de internet convêncional, com alta latência, alta flutuação de banda e não redundante ou, sem garantia integral de redundância física e de caminhos.

O problema reside no fato de que alguns produtos, inadivertidamente, oferecem as opções de failover automático e replicação sincrona para recuperação de desastres em provedores de nuvem (Cloud Computing). Seja por desconhecimento do fornecedor ou do cliente, das condições adequadas para uso desses recursos, a realidade é que alguns clientes estão colocando seus sistemas, seus dados e seus negócios em risco ao utilizar esse tipo de processo, tendo por baixo uma infraestrutura inadequada para isso.

A intenção desse artigo é, portanto, desmistificar a panacéia do failover automático e da replicação sincrona e alertar que, mesmo que seu produto ou serviço de recuperação de desastres possua essas duas funcionalidades, isso não quer dizer que seja adequado, seguro e funcional para o seu negócio. Ao contrário, continua sendo importante uma avaliação das condições existentes.

 

Conheça as soluções de Recuperação de Desastres da Symantec para quaisquer cenários e necessidades, inclusive para nuvem:

go.symantec.com/DisasterRecovery