Como migrar seu lab EVE-NG para outro servidor / plataforma

Olá Pessoal,

Como sabem, sou um “lab freak”. Sempre fui… desde que comecei na área. Desde cedo percebi que nada substitui um bom “hands-on”! Quando percebi que a ferramenta EVE-NG começou a amadurecer, embarquei de cabeça. E tenho usado o EVE há mais de 7 anos, para criar os mais diversos labs. Se você ainda não usa o EVE, sugiro que reconsidere. E se quer um passo a passo de como instalá-lo, deixe um comment abaixo. Eu posso criar um tutorial mais adiante.

A plataforma EVE-NG pode ser instalada como uma máquina virtual (VM) ou em um servidor nativo (bare-metal). A instalação do EVE como uma VM é bem simples. Basta baixar o template (OVA) e importá-la no seu VM Player ou servidor ESXi (recomendado).

Rodar o EVE em cima de uma plataforma de virtualização (como VMware, Virtual Box ou mesmo ambientes Cloud) cria o efeito “nested virtualization”. É como criar uma VM ESX dentro de um servidor ESX. E qual o problema disso? BAIXA PERFORMANCE. Rodar o EVE em uma plataforma virtualizada rouba recursos preciosos e o resultado fica muito aquém do desejado. Nos testes que fiz usando meu servidor ESX, instalar o EVE em um servidor dedicado (bare-metal) aumentou a performance em mais de 50% (se comparado ao ESX).

Eu sempre rodei meu EVE em bare-metal (nativo em um servidor físico dedicado). Semana passada, percebi que um dos discos deste servidor estava começando a falhar. Era hora de trocar o disco. A dúvida que vem quando uma situação destas chega é: “Como fazer o backup dos meus labs e imagens, e como restaurá-los em um novo disco / servidor?”

Tenho labs rodando em meu EVE que possuem inúmeras configurações, feitas no decorrer de anos. Refazer tudo do zero seria uma enorme dor de cabeça. Para exemplificar, eis uma de minhas topologias:

E esta é apenas UMA delas. Eu tenho – no momento – 4 topologias rodando (dica: para fazer isso no meu EVE, crio 4 usuários e cada lab roda associado a um usuário distinto – assim posso sair de um lab rodando e acessar outro, sem problemas).

Como fazer o backup de tudo isso SEM perder nenhuma configuração, e também fazer o backup das minhas imagens? Para fazer isso, é preciso antes entender um pouco como o EVE funciona.

O EVE é muito mais do que um simples “emulador”. Ele é uma plataforma de virtualização completa (assim como é o VMware ESX, por exemplo). O EVE usa o hypervisor tipo 1 nativo do Linux, chamado KVM e também usa QEMU – um hypervisor tipo 2 – como “engine” para a criação das VMs. É possível fazer isso no Linux sem usar o EVE, mas você perde a parte gráfica. Desta forma, o EVE pode ser definido como um front-end para o Linux KVM + QEMU.

A forma como as coisas funcionam é bem diferente de outros hypervisors – como ESX. NO EVE, você carrega a imagem que será usada para a criação de suas VMs (uma imagem Linux, por exemplo). Quando você cria uma VM e referencia esta imagem, o QEMU cria uma instância desta imagem dentro de um diretório associado à VM. Veja um exemplo… eis o que ocorre quando crio uma VM Linux em meu lab:

Percebam que a VM que estou criando referencia uma imagem que chamei de “linux-ununtu-20.04-clean”. Abaixo você pode ver, no diretório de imagens usadas pelo QEMU (/opt/unetlab/addons/qemu), o diretório da imagem selecionada (seta vermelha)

Dentro deste diretório, é possívem encontrar a imagem usada em formato qcow2, usada pelo QEMU:

Assim que você conclui a adição de uma VM ao seu lab ela recebe um número (ID). Este número pode ser visto ao clicar em sua VM com o botão direito do mouse (ver abaixo, em vermelho)

Para verificar a instância criada para esta VM (necessário para realizar o BKP), você deve acessar o diretório tmp (/opt/unetlab/tmp). Este é o diretório onde todas as instâncias de VMs de todos os seus labs residem. No meu caso, eis a listagem deste diretório:

Os números apresentados referem-se aos “pods” existentes no meu EVE. Pods são definidos no momento da criação de um usuário. No caso, o lab que contém a VM Linux que acabei de adicionar encontra-se no pod 1. Como sei? Porque o usuário que estou usando é “marco”, o este usuário está associado ao por “1”:

Agora que sabemos o pod associado ao usuário que criou o lab, podemos examinar o conteúdo deste diretório:

Note que há dois sub-diretórios dentro dele: “2d6e42d1-9bc5-4f69-965b-0c2fb446becd” e  “f1325384-35eb-4758-99dd-58cbd456cc7b”. Isso significa que o usuário “marco” (pod 1) possui dois labs criados. O que queremos examinar é o “2d6e42d1-9bc5-4f69-965b-0c2fb446becd”. Como sei? Basta clicar no botão “Lab Details” do EVE:

Vamos cavar um pouco mais fundo e dar uma olhada no diretório do lab:

Vejam (em vermelho), que dentro do diretório do lab existe apenas um sub-diretório com o número “1”.  Este diretório bate com o ID da VM criada no lab. Se você tem um lab com 10 VMs QEMU, o diretório de seu lab terá 10 sub-diretórios numerados de 1 a 10. Olhando dentro do sub-diretório “1”, encontramos a instância de disco virtual criada pelo EVE para esta VM, também em formato qcow2:

Parece igual à imagem que vimos no início do post (no diretório /opt/unetlab/addons/qemu/linux-ubuntu-20.04-clean/), mas é bem diferente. A imagem inicial é a usada para a criação da VM. A imagem que existe dentro do pod é uma instância daquela imagem – o que no mundo VMware chamamos de “snapshot”.  Ou seja, se quiser fazer o backup de sua VM, você deve fazer o backup da instância qcow2 existente no pod.

Bom, tudo isso para explicar como o sistemna de instanciamento do EVE / QEMU funciona. Agora que temos uma idéia, sabemos que para efetuar um backup de qualquer lab, é importante copiar as imagens / instâncias armazenadas no diretório /opt/unetlab/tmp/{número do pod}/{ID do lab}. E, se quiser fazer um backup de todos os labs de uma só vez, mais fácil… basta copiar TODO o diretório /opt/unetlab/tmp/.

É vital que você não se esqueça de também fazer o backup das imagens em /opt/unetlab/addons/qemu, e também dos labs em /opt/unetlabs/labs (este diretório mantém os arquivos dos labs com as estruturas UNL, utilizadas pelo EVE para renderizar as topologias, interconexões e nodes de rede).

Finalmente, você deve fazer o backup da base de dados do EVE (a base que contém as informações de usuários). Para salvar um backup chamado de “dbbkp.sql” de toda a base no diretório “root”, acesse a linha de comando de seu servidor EVE e digite:

mysqldump -u root -p --all-databases > /root/dbbkp.sql

Quando a senha for solicitada, digite “eve-ng”

Pronto!

Agora, como transferir TUDO para outro servidor? Primeiro, é preciso instalar o EVE em outro servidor (seja bare-metal ou uma VM). Prepare tudo seguindo as instruções em https://www.eve-ng.net/index.php/documentation/installation/

Uma vez que a nova máquina EVE esteja pronta e acessível, você pode transferir os arquivos de 2 formas:

  1. OFFLINE – Copie os diretórios /opt/unetlab/tmp, /opt/unetlab/addons/qemu e /opt/unetlab/labs para um disco externo USB (você terá que “montar” o disco USB em seu servidor para isso funcionar. Este processo está fora do escopo deste post). Copie também o backup da base de dados que você realizou anteriormente.  Conecte o disco USB no novo servidor EVE e copie os arquivos para os respectivos lugares (eu prefiro usar “rsync” para este processo ao invés de usar o comando “cp”). Uma vez que o processo de transferência termine, carregue o backup da base de dados usando o comando: mysql -p < /root/dbbkp.sql (senha: eve-ng) e pronto! Nada mais a ser feito (não é nem preciso reinicializar o servidor!).
  2. ONLINE – Se ambas as máquinas estiverem online e comunicáveis, você pode usar o comando “rsync” para enviar o conteúdo da máquina antiga para a nova. Eis os comandos (no exemplo, a máquina antiga tem o IP 1.1.1.1 e a nova o IP 1.1.1.2)
# Instale rsync em ambas as máquinas:
apt update
apt install rsync

# Transfira os aquivos da máquina antiga para  nova:
rsync -az /opt/unetlab/addons/qemu 1.1.1.2:/opt/unetlab/addons/ --info=progress2
rsync -az /opt/unetlab/labs 1.1.1.2:/opt/unetlab/ --info=progress2
rsync -az /opt/unetlab/tmp 1.1.1.2:/opt/unetlab/ --info=progress2
rsync -az /root/dbbkp.sql 1.1.1.2:/root/ --info=progress2

# Carregue o backup da base de dados
mysql -p < /root/dbbkp.sql

# Pronto!!!

DICA: Eu gosto de manter cópias do estado de algumas VMs durante alguns labs, para o caso de algo dar errado. Como EVE-NG community (a versão gratuita) não oferece a função snapshot, o que eu faço é copiar algumas instâncias de certas VMs para um diretório “BKP” que eu criei dentro do caminho /opt/unetlab/tmp/

Assim, quando uma alteração na VM causa algum problema, eu apenas copio o backup da instância de volta para o diretório correto. Por exemplo, vamso pegar a VM que criamos anteriormente (instância armazenada no diretório /opt/unetlab/tmp/1/2d6e42d1-9bc5-4f69-965b-0c2fb446becd/1). Eis o que eu faço para criar um backup apenas desta VM:

# criar diretório BKP
mkdir /opt/unetlab/tmp/BKP

# Copiar instância(s) desejada(s) para o diretório criado
rsync -az /opt/unetlab/tmp/1/2d6e42d1-9bc5-4f69-965b-0c2fb446becd/1 /opt/unetlab/tmp/BKP/

E quando eu quiser voltar o backup:

rsync -az /opt/unetlab/tmp/BKP/1 /opt/unetlab/tmp/1/2d6e42d1-9bc5-4f69-965b-0c2fb446becd/

Isso me dá mais segurança ao alterar alguma cosia em uma imagem na qual já venho trabalhando há dias 🙂

Ah, e nunca se esqueça de manter seus backups religiosamente em dia, e FORA do servidor (por exemplo, em um disco externo). Assim, quando a coisa for para o brejo, você pelo menos tem algo para restaurar seus labs 🙂 Eu atualizo meu backup externo uma vez por semana. É possível até mesmo automatizar o processo, utilizando um cronjob. Mas isso fica para um outro post!

É isso pessoal, espero que este post seja útil.

Abraço

Marco

3 comentários

  1. Muito bom tutorial Marco. Mas a minha dúvida é em relação ao próprio servidor. Qual seria a configuração mínima do servidor recomendável para rodarmos um laboratório completo no EVE, com uma média de 8 hosts(routers, switches) ?

  2. Oi Renato! Eu posso fazer um post sobre isso mais adiante. Eu diria que depende muito do que você quer montar. Se for trabalhar apenas com cisco IOL, por exemplo – sem usar VMs mais pesadas como Linux, Windows, etc – uma máquina com 8G de RAM e de 2 a 4 cores deve ser suficiente para um lab com até 8 nodes. Vai ficar apertado, mas dá.

    1. Obrigado, já da para ter uma noção.

Deixe um comentário