on 09-30-2014 01:27 PM
É 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:
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:
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 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:
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:
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:
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: