O serviço Disaster Recovery da Jotelulu, explicado

Juan Ignacio Oller Aznar

Leia este artigo para compreender o serviço Disaster Recovery da Jotelulu.

O serviço Disaster Recovery da Jotelulu visa garantir que tanto os nossos partners como os seus clientes têm uma ferramenta para garantir a sobrevivência das suas infraestruturas e serviços em caso de contingência grave no data center onde os serviços estão alojados.

Este serviço permite evacuar as subscrições de Servidores ou Desktop Remoto, minimizando o impacto no serviço que prestam e levando-as para outra região para garantir que o serviço não é afetado.

O Disaster Recovery da Jotelulu permite ao partner selecionar uma subscrição de servidores existentes dentro da Jotelulu e replicá-la noutra zona de disponibilidade, garantindo que os dados serão replicados diligentemente de acordo com a periodicidade definida pelo administrador. Uma das garantias que este serviço nos oferece é que, quando a infraestrutura for evacuada para o local remoto, continuará a manter o endereço da rede pública e privada (IPv4), bem como todos os serviços que o cliente publicou na origem. Com isto, o cliente consegue que, mesmo que ocorra a evacuação de recursos, todas as alterações sejam transparentes e o serviço seja evacuado em muito pouco tempo.

Imagem. Plano de replicação de um DR na Jotelulu

NOTA: devemos dizer, antes de continuar, que este é um serviço “vivo”, como todos os serviços da Jotelulu, razão pela qual, com o tempo, este serviço irá evoluir e assumir novas funcionalidades.

NOTA: uma assinatura de DR pode conter um ou mais planos de DR.

NOTA: um plano de DR só pode ter uma assinatura de origem.

Para começar, temos uma primeira subscrição: esta é a subscrição que originalmente presta serviço aos nossos clientes. Se nesta assinatura, por exemplo de servidores, ativarmos o serviço Disaster Recovery (DR), o que vai acontecer é que será ativada uma segunda assinatura noutra região, que se comportará como um espelho e na qual será feita uma replicação do conteúdo da primeira assinatura.

Quando estabelecemos a replicação, devemos configurar uma série de pontos, como a quantidade de cópias que iremos guardar, quando começaremos a fazer a cópia ou com que frequência faremos a cópia, mas esta configuração não é imutável e pode ser alterada posteriormente.

A assinatura espelho, criada para suportar a nossa assinatura funcional (aquela que está realmente operacional), não será visível para os utilizadores enquanto a assinatura principal estiver ativa.

Se, a qualquer momento, decidirmos pausar ou parar a replicação do DR, os dados deixarão de ser replicados para a assinatura de backup. No entanto, existe uma pequena diferença entre as duas formas de parar a replicação. Quando falamos em interromper uma subscrição de DR, existe a opção de a pausar e a opção de a interromper:

Pausa: quando pausamos a replicação, não são feitas mais replicações até que seja retomada a replicação.
Interrupção: quando interrompemos a replicação, não são feitas mais replicações até que seja retomada a replicação, mas neste caso podemos proceder à alteração da configuração, se quisermos.

Se, por algum motivo, quiser ativar o failover e evacuar os recursos para a assinatura de cópia de segurança, o controlo e operação passarão para este espelho de forma suave, porque a cópia é feita de forma regular e de acordo com a nossa configuração.

O que esta operação de failover vai produzir é a visibilidade e acessibilidade da subscrição secundária, a que foi criada ao registar o serviço DR, que passa assim a fornecer o serviço, enquanto a subscrição de origem se torna inacessível e invisível.

Para que tal aconteça, inicialmente terão de ser definidos vários parâmetros, entre os quais já referimos anteriormente o número de replicações, a frequência de replicação, o momento de início, etc. Também devemos selecionar a forma de realizar a replicação: IP ou DNS. Esta escolha vai condicionar a forma como os recursos são evacuados. É importante notar que o IP de origem estará sempre presente para oferecer transparência aos clientes.

Por outro lado, também devemos saber que, uma vez evacuados os recursos, não haverá replicação nem DR na nova assinatura, precisamente por se tratar de uma nova assinatura.