Para aumentar a disponibilidade das aplicações, qualquer empresa, não importa o tamanho, precisa ter um site secundário para recuperação de desastres (DR). A tecnologia atual oferece o recurso de ativar qualquer carga de trabalho instantaneamente no site secundário, caso ocorra qualquer problema no site primário.

Historicamente, por vários motivos, sites de DR foram uma solução direcionada somente para grandes corporações. No entanto, novas tecnologias e ofertas de serviços como a recuperação de desastres como serviço (DRaaS) deixam os sites de DR acessíveis e com bom custo-benefício para empresas de qualquer tamanho.

O surgimento da virtualização

Sem dúvida, o principal motivador do crescimento explosivo das soluções de recuperação de desastres foi a virtualização. Antes, a replicação de dados e aplicações para um site secundário só era possível ao aproveitar os recursos dos storage arrays, mas nem toda solução incluía recursos de replicação nativos. Além disso, a replicação na camada do storage tem duas armadilhas adicionais:

  1. De um ponto de vista tecnológico, a replicação da camada de storage requer que ambos os sites adotem o mesmo modelo ou marca de storage porque toda tecnologia de replicação é proprietária. Isso não é problema para organizações maiores, que podem criar um site secundário com o mesmo tamanho e capacidade do site primário. No entanto, organizações pequenas e médias não possuem os recursos financeiros ou o interesse para investir o mesmo orçamento para os sites primário e secundário. Elas precisam de uma solução de melhor custo-benefício.
  2. A replicação na camada de storage não possui a granularidade necessária para fazer ajuste fino na política de replicação. Um storage array não tem ciência das cargas de trabalho que hospeda. Se um servidor de arquivos e um banco de dados estão armazenados no mesmo local, são replicados usando a mesma política. Por causa disso, é difícil criar políticas diferentes e obter RPOs e RTOs distintos para cargas de trabalho diferentes. A menos que os administradores separem as cargas de trabalho em silos diferentes. No entanto, isso causa custos operacionais adicionais e requer mais recursos de TI, gerenciamento e monitoramento.

A virtualização, por outro lado, deixa os serviços de replicação mais acessíveis, configuráveis e fáceis de usar, além de eliminar essas duas grandes armadilhas. Com a virtualização, é possível definir RTOs e RPOs específicos para cada carga de trabalho, porque a unidade de gerenciamento sai do enorme e volumoso storage array para máquinas virtuais individuais e flexíveis. Um administrador de TI pode aumentar ou diminuir a prioridade de determinadas cargas de trabalho. Por exemplo, é possível configurar uma solução de replicação para criar cópias no local secundário de maneira quase contínua (a cada 15 minutos) para o importante servidor de banco de dados, mas de uma em uma hora ou uma vez por dia para um servidor de arquivos. A virtualização abstraiu a camada do hardware, possibilitando aplicar controles mais granulares para a replicação, otimizar resultados e utilizar os recursos de TI com mais eficiência.

A necessidade de um segundo site

A recuperação de desastres é uma ótima solução para aumentar a disponibilidade dos data centers modernos e faz isso aproveitando as tecnologias de ponta de replicação e virtualização para criar réplicas externas de máquinas virtuais.

Mas quando os usuários finais começam a planejar um site de DR, acabam se deparando com outros problemas: Primeiro, as despesas de capital com a construção e manutenção do site secundário são um desafio para muitas organizações. Em um segundo local, próprio ou alugado (por exemplo, um colocation center), é preciso implantar novo hardware e software de acordo com o tamanho dos ambientes de produção. Depois, ainda é necessário configurar e gerenciar o site, praticamente dobrando os esforços da infraestrutura de TI. Além disso, como as cargas de trabalho de produção são executadas principalmente no site primário, o site secundário raramente é usado. Isso eleva ainda mais o custo em relação ao seu valor, o que dificulta convencer a direção executiva do ROI.

Historicamente, somente grandes corporações tinham o orçamento necessário para bancar um site secundário privado, ou já possuíam mais que um escritório com funcionários de TI em ambos para aproveitar a instalação ou esses recursos. Mas hoje em dia, até as organizações maiores procuram formas de reduzir os gastos operacionais e de capital enquanto mantêm um site de DR.

Recuperação de desastres como serviço

Essa é uma das situações onde uma solução baseada na nuvem se encaixa perfeitamente, e é o motivo pelo qual a recuperação de desastres como serviço ganha cada vez mais popularidade. Ao alugar recursos de um provedor de serviços num modelo em que se paga pelo que se usa, os usuários finais têm o mesmo resultado (recursos de CPU, memória RAM, storage e rede disponíveis para operações de failover) sem nenhum custo de capital nem a sobrecarga de projetar, implantar e gerenciar diariamente um site de DR. Provedores de serviços com know-how em DR lidam com o gerenciamento completo da infraestrutura. Em retorno, o provedor de serviços oferece um SLA (contrato de nível de serviço) relativo à qualidade do serviço. O provedor de serviços ainda pode oferecer diferentes SLAs para cargas de trabalho distintas, mais uma vez, graças à virtualização.

Isso possibilita que os usuários finais se concentrem na atividade de replicação, planejem os diferentes valores de RPO necessários para as aplicações, além de definir a estratégia de DR e a solução de DR usando métricas de negócios em vez das necessidade de TI.

Não é à toa que DRaaS está em grande demanda. Na realidade, é possível visualizar por este gráfico do Google Trends a explosão da popularidade da DRaaS.
DRaaS popularity trends

Se procurar por outro termo de pesquisa, “Disaster Recovery,” você verá que a demanda por DR isoladamente está diminuindo, na verdade:

demand for Disaster Recovery

Isso é um sinal de que os clientes não estão pesquisando com tanta frequência em busca de uma solução genérica, mas estão procurando especificamente por DRaaS de provedores de serviços.

A profusão de soluções disponíveis no mercado é impressionante. Empresas de qualquer tamanho à procura de uma solução de DRaaS devem avaliar cuidadosamente quais opções vêm com o serviço Vamos analisar algumas delas.

1. Facilidade de uso

Facilidade de uso é geralmente uma característica ignorada das soluções de DR. As pessoas tendem a focar mais nos incríveis recursos de uma tecnologia qualquer, mas se essa tecnologia também é extremamente complexa e difícil de configurar e usar, isso sinaliza um enorme problema. O ROI prometido será difícil de atingir e o valor agregado ao seu negócio também será limitado. Por outro lado, uma solução fácil de usar pode ser testada e adotada com mais rapidez e menos esforço. O mais importante é que o usuário final pode se beneficiar de uma tecnologia que “simplesmente funciona” durante o consumo contínuo do serviço sem a necessidade de ajustá-lo constantemente, localizar e corrigir problemas e assim por diante.

Outro aspecto negligenciado: Durante um cenário de DR, os funcionários de TI geralmente são pressionados pela direção executiva sobre os problemas que enfrentam, pelo tempo de inatividade que passam e pela necessidade de retornar rapidamente às operações. Uma solução fácil de usar oferece a você a capacidade de se concentrar nas simples etapas necessárias para reiniciar as aplicações no site secundário, enquanto uma solução complexa acaba piorando os problemas em situações de pressão.

A tecnologia de nuvem da Veeam, replicação de VM por meio do Veeam Cloud Connect, é fácil de usar e simples de configurar, graças à conectividade a uma porta TCP protegida por uma conexão SSL/TLS segura e confiável para o provedor de serviços da sua escolha. Não é necessário configurar e manter conexões VPN ou abrir várias múltiplas portas nos firewalls dos clientes. O túnel único é usado para qualquer tipo de tráfego: tráfego de gerenciamento de replicação, transferências dos dados da VM e até mesmo comunicação entre as VMs durante failovers parciais. Todas as comunicações são encapsuladas no túnel único. Quando a conexão é estabelecida, não há a necessidade de configuração adicional de rede.

2. E quanto à rede?

DRaaS foi projetado principalmente para oferecer serviços de replicação, mas somente replicação não é suficiente. Na realidade, uma das maiores dores de cabeça de qualquer serviço de DR não é a replicação: É a rede. As aplicações possuem configurações específicas de rede, e muitos dos serviços modernos precisam ser publicados na internet para serem consumidos por funcionários, fornecedores e clientes. Ainda que replicar uma máquina virtual e ativá-la em um site de DR seja relativamente fácil, garantir que a rede seja adequadamente configurada e automaticamente reprogramada quando uma mudança na configuração acontece não é nada fácil, e essa garantia é geralmente considerada fato consumado. Ao procurar uma solução de DRaaS, os usuários finais devem fazer perguntas específicas para descobrir os recursos das soluções de DRaaS nessa área. A possibilidade de mover aplicações sem dificuldades entre o site primário e secundário de forma transparente não tem preço, exceto pelo tempo economizado da reconfiguração de aplicações durante um failover.

3. Autosserviço

O autosserviço é essencial a qualquer serviço de nuvem, e DRaaS não é uma exceção. Quantas operações os provedores de serviços podem automatizar? Pode parecer que isso só é importante para provedores de serviços, mas o serviço automatizado significa que os usuários finais podem solicitar alterações em suas assinaturas com mais rapidez e ajustá-las ao serviço de DRaaS rápida e facilmente. Não há sentido em consumir um serviço de nuvem se demora horas ou dias para que um provedor de serviços processe uma solicitação de alteração.

Obviamente, o autosserviço também é sobre quantas operações você pode executar independentemente, sem ter que pedir para o provedor de serviços. No fim das contas, o provedor de serviços é responsável por manter a infraestrutura subjacente, ao mesmo tempo em que todas as operações de dados e cargas de trabalho de uma empresa podem permanecer com a própria companhia.

É assim por um motivo simples, mas importante: O usuário final sabe exatamente como o serviço deve ser configurado ou reconfigurado quando necessário.

No entanto, o autosserviço também tem enorme valor na redução do tempo de inatividade durante um failover: Se algo grave acontecer com o site, o usuário pode aproveitar os recursos de autosserviço do provedor de serviços escolhido e iniciar com agilidade uma operação de failover sem perder tempo, abrindo um tíquete de suporte com o provedor de serviços.

Notas finais

A recuperação de desastres como serviço está cada vez mais popular, e muitos provedores oferecem esse tipo de serviço usando diferentes tecnologias. O cliente pode se sentir perdido ao ver todas as soluções disponíveis, mas nem todas as soluções são iguais e há valor nas opções oferecidas.

Os provedores de serviços que usam a replicação do Veeam Cloud Connect podem garantir todas as vantagens mencionadas neste artigo. Os usuários finais só precisam instalar ou fazer o upgrade para o Veeam Availability Suite v9 e assinar com um provedor de DRaaS com a tecnologia da Veeam para começar a usar o Veeam Cloud Connect.

 

Para saber mais sobre a solução de DRaaS da Veeam, consulte os links abaixo:

GD Star Rating
loading...