🥇Como transferir um container OpenVZ 6 para um servidor KVM sem dor de cabeça

Todos que precisaram, pelo menos uma vez na vida, transferir um contêiner OpenVZ para um servidor com virtualização KVM total, enfrentaram alguns problemas:

A maior parte das informações está banalmente desatualizada e era relevante para ciclos EOL do sistema operacional que já passaram há muito tempo.
Diferentes sistemas operacionais sempre oferecem informações variadas, e nunca discutem possíveis erros durante a migração.
Às vezes, é necessário lidar com configurações que simplesmente não funcionam após a migração.

Quando você transfere um servidor, sempre pode corrigir algo no caminho, mas e quando transfere um cluster inteiro?

Neste artigo, tentarei explicar como migrar corretamente um contêiner OpenVZ para KVM com o mínimo de tempo de inatividade e uma solução rápida para todos os problemas.

Um pequeno esclarecimento: o que é OpenVZ e o que é KVM?

Não vamos nos aprofundar na terminologia, mas diremos em termos gerais:

OpenVZ — virtualização em nível de sistema operacional, que pode ser implementada até em um micro-ondas, pois não há necessidade de instruções de CPU e tecnologias de virtualização na máquina host.

KVM — virtualização completa, que utiliza toda a potência da CPU e pode virtualizar qualquer coisa, de qualquer forma, cortando em todas as direções.

Contrário à crença popular de que no ambiente provedores de hospedagem OpenVZ há supersolicitação, enquanto no KVM não — para felicidade dos últimos, o KVM atualmente é supersolicitado tão bem quanto seu colega.

O que iremos transferir?

Como cobaia para a migração, tivemos que utilizar toda a gama de sistemas operacionais disponíveis no OpenVZ: CentOS (versões 6 e 7), Ubuntu (14, 16 e 18 LTS), Debian 7.

Pressupunha-se que na maioria dos contêineres OpenVZ já estivesse rodando algum tipo de LAMP, e alguns até tinham algum software muito específico. Na maioria das vezes, essas foram configurações com o painel de controle ISPmanager, VestaCP (e normalmente, não atualizadas há anos). É necessário levar em conta também suas demandas para a migração.

A migração é realizada com a preservação endereços IP do contêiner transferível, suponhamos que o IP que estava no contêiner será mantido na VM e funcionará sem problemas.

Antes da transferência, vamos garantir que temos tudo em mãos:

Servidor OpenVZ, acesso root completo à máquina host, a possibilidade de parar/montar/iniciar/remover contêineres.
Servidor KVM, acesso root completo à máquina host, com todas as implicações. Pressupõe-se que tudo já esteja configurado e pronto para funcionar.

Começamos a migração

Antes de iniciar a migração, vamos definir os termos para evitarmos confusões:

KVM_NODE — máquina host KVM
VZ_NODE — máquina host OpenVZ
CTID — container OpenVZ
VM — servidor virtual KVM

Preparação para a migração e criação de máquinas virtuais.

Passo 1

Como precisamos de um lugar para migrar o container, vamos criar VM com uma configuração semelhante em KVM_NODE.
Importante! A VM deve ser criada exatamente no mesmo sistema operacional que está atualmente rodando no CTID. Por exemplo, se o CTID tiver Ubuntu 14 instalado, a VM também deve ter Ubuntu 14. Versões menores não são críticas, mas as maiores devem ser idênticas.

Após criar a VM, devemos atualizar os pacotes no CTID e na VM (não confundir com a atualização do sistema operacional — não devemos atualizá-lo, apenas os pacotes e, se for o caso, a versão do sistema operacional na sua versão principal).

Para CentOS, esse processo parece inofensivo:

# yum clean all
# yum update -y

E não menos inofensivo para Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Passo 2

Vamos instalar em CTID, VZ_NODE e VM uma ferramenta rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Não instalamos mais nada nem lá, nem cá.

Passo 3

Parar o processo CTID para VZ_NODE com o comando

vzctl stop CTID

Montamos a imagem CTID:

vzctl mount CTID

Vamos para a pasta /vz/root/CTID e executamos

mount --bind /dev dev && mount --bind /sys sys && mount --bind /proc proc && chroot .

Sob chroot, criamos o arquivo /root/exclude.txt — ele conterá a lista de exceções que não serão migadas para o novo servidor.

/boot
/proc
/sys
/tmp
/dev
/var/lock
/etc/fstab
/etc/mtab
/etc/resolv.conf
/etc/conf.d/net
/etc/network/interfaces
/etc/networks
/etc/sysconfig/network*
/etc/sysconfig/hwconf
/etc/sysconfig/ip6tables-config
/etc/sysconfig/kernel
/etc/hostname
/etc/HOSTNAME
/etc/hosts
/etc/modprobe*
/etc/modules
/net
/lib/modules
/etc/rc.conf
/usr/share/nova-agent*
/usr/sbin/nova-agent*
/etc/init.d/nova-agent*
/etc/ips
/etc/ipaddrpool
/etc/ips.dnsmaster
/etc/resolv.conf
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/sysconfig/network-scripts/ifcfg-ens3

Conectamos em KVM_NODE e iniciamos nosso VM, para que funcione e esteja acessível pela rede.

Agora tudo está pronto para a migração. Vamos lá!

Passo 4

Ainda sob chroot, executamos

rsync --exclude-from="/root/exclude.txt" --numeric-ids -avpogtStlHz --progress -e "ssh -T -o Compression=no -x" / root@KVM_NODE:/

O comando rsync realizará a migração; esperamos que as chaves sejam claras — a migração será feita mantendo links simbólicos, permissões, proprietários e grupos, além de ter a criptografia desativada para maior velocidade (poderíamos usar um cifrador mais rápido, mas isso não é tão crítico para esta tarefa), o que também desativou a compressão.

Após a conclusão do rsync, saímos do chroot (pressionando ctrl+d) e executamos

umount dev && umount proc && umount sys && cd .. && vzctl umount CTID

Passo 5

Vamos realizar algumas ações que nos ajudarão a iniciar a VM após a migração do OpenVZ.
Em servidores com Systemd executaremos o comando que nos ajudará a fazer login no console comum, por exemplo, através da tela VNC do servidor

mv /etc/systemd/system/getty.target.wants/getty@tty2.service /etc/systemd/system/getty.target.wants/getty@tty1.service

Em servidores CentOS 6 e CentOS 7 vamos instalar o núcleo atualizado:

yum install kernel-$(uname -r)

O servidor pode ser inicializado a partir dele, mas após a transferência, pode deixar de funcionar ou ser removido.

No servidor CentOS 7 é necessário aplicar uma pequena correção para o PolkitD, caso contrário, o servidor entrará em um loop de inicialização infinito:

getent group polkitd >/dev/null && echo -e "e[1;32mO grupo polkitd já existee[0m" || { groupadd -r polkitd && echo -e "e[1;33mGrupo polkitd adicionadoe[0m" || echo -e "e[1;31mFalha ao adicionar o grupo polkitde[0m"; }

getent passwd polkitd >/dev/null 
&& echo -e "e[1;32mO usuário polkitd já existee[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "Usuário para polkitd" polkitd && echo -e "e[1;33mUsuário polkitd adicionadoe[0m" || echo -e "e[1;31mFalha ao adicionar o usuário polkitde[0m"; }

rpm -Va polkit* && echo -e "e[1;32mVerificação do rpm polkit* realizada com sucessoe[0m" || { echo -e "e[1;33mResetando a propriedade do usuário/grupo do rpm polkit* e as permissõese[0m"; rpm --setugids polkit polkit-pkla-compat; rpm --setperms polkit polkit-pkla-compat; }

Em todos os servidores, se o mod_fcgid foi instalado para o Apache, vamos aplicar uma pequena correção nas permissões, caso contrário, os sites que usam mod_fcgid terão erro 500:

chmod +s `which suexec` && apachectl restart

E por último, isso será útil para distribuições Ubuntu e Debian. Este sistema operacional pode cair em um loop de inicialização infinito com o erro

looping too fast. throttling execution a little

é desagradável, mas fácil de corrigir, dependendo da versão do sistema operacional.

Sobre Debian 9 a correção será assim:

executamos

dbus-uuidgen

se recebermos um erro

/usr/local/lib/libdbus-1.so.3: version `LIBDBUS_PRIVATE_1.10.8′ not found

verificamos a presença do LIBDBUS

ls -la /lib/x86_64-linux-gnu | grep dbus
libdbus-1.so.3 -> libdbus-1.so.3.14.15 
libdbus-1.so.3.14.15 <-- precisamos deste
libdbus-1.so.3.14.16

se tudo estiver certo, executamos

cd /lib/x86_64-linux-gnu
rm -rf libdbus-1.so.3
ln -s libdbus-1.so.3.14.15 libdbus-1.so.3

Caso não ajude — tentamos a segunda opção.

A segunda opção para resolver o problema com throttling execution a little serve praticamente para todas as distribuições Ubuntu e Debian.

Executamos

bash -x /var/lib/dpkg/info/dbus.postinst configure

Allowed Logout URLs Ubuntu 14, Debian 7 além disso, executamos:

adduser --system --home /nonexistent --no-create-home --disabled-password --group messagebus

rm -rf /etc/init.d/modules_dep.sh

O que fizemos? Restauramos o messagebus, que estava faltando para iniciar o Debian/Ubuntu e removemos o modules_dep, que veio do OpenVZ e impedia a inicialização de muitos módulos do núcleo.

Passo 6

Reiniciamos a VM, verificamos no VNC como está a inicialização e, idealmente, tudo deve inicializar sem problemas. No entanto, pode haver alguns problemas específicos após a migração — mas estes vão além do escopo deste artigo e serão corrigidos à medida que surgirem.

Espero que esta informação seja útil! 🙂

Fonte: habr.com