Como transferir o contêiner OpenVZ 6 para o servidor KVM sem dores de cabeça

Qualquer pessoa que pelo menos uma vez na vida precisou transferir um contêiner OpenVZ para um servidor com virtualização KVM completa encontrou alguns problemas:

• A maior parte das informações está simplesmente desatualizada e era relevante para sistemas operacionais que já haviam ultrapassado o ciclo EOL há muito tempo.
• Informações diferentes são sempre fornecidas para sistemas operacionais diferentes e possíveis erros durante a migração nunca são considerados
• Às vezes você tem que lidar com configurações que de vez em quando não querem funcionar após a migração

Ao transferir 1 servidor, você sempre pode consertar algo na hora, mas quando transfere um cluster inteiro?

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

Um pequeno programa educacional: o que é OpenVZ e o que é KVM?

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

OpenVZ — virtualização no nível do sistema operacional, você pode até implantá-la em um micro-ondas, já que não há necessidade de instruções de CPU e tecnologias de virtualização na máquina host.

KVM - virtualização completa, utilizando todo o poder da CPU e capaz de virtualizar qualquer coisa, de qualquer forma, cortando-a longitudinalmente e transversalmente.

Ao contrário da crença popular de que entre os provedores de hospedagem o OpenVZ será vendido em excesso, mas o KVM não - felizmente para este último, o KVM agora não é vendido em excesso, tanto quanto seu irmão.

O que vamos transportar?

Como cobaias para a transferência, tivemos que utilizar toda a floresta de sistemas operacionais que estão disponíveis no OpenVZ: CentOS (versões 6 e 7), Ubuntu (14, 16 e 18 LTS), Debian 7.

Supunha-se que a maioria dos contêineres OpenVZ já estavam executando algum tipo de LAMP, e alguns até tinham algum software muito específico. Na maioria das vezes, eram configurações com o ISPmanager, painel de controle VestaCP (e na maioria das vezes, sem atualização há anos). Os seus pedidos de transferência também devem ser tidos em conta.

A migração é realizada preservando o endereço IP do container transferido; assumiremos que o IP que o container possuía está salvo na VM e funcionará sem problemas.

Antes de transferir, vamos nos certificar de que temos tudo em mãos:

• Servidor OpenVZ, acesso root completo à máquina host, capacidade de parar/montar/iniciar/excluir contêineres
• Servidor KVM, acesso root completo à máquina host, com tudo o que isso implica. Presume-se que tudo já esteja configurado e pronto para funcionar.

Vamos começar a transferir

Antes de iniciarmos a transferência, vamos definir termos que ajudarão você a evitar confusões:

KVM_NODE - Máquina host KVM
VZ_NODE - Máquina host OpenVZ
IDCT - Contêiner OpenVZ
VM - Servidor virtual KVM

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

Passo 1

Como precisamos mover o contêiner para algum lugar, criaremos VM com uma configuração semelhante a KVM_NODE.
Importante! Você precisa criar uma VM no sistema operacional que está atualmente em execução no CTID. Por exemplo, se o Ubuntu 14 estiver instalado no CTID, então o Ubuntu 14 deverá ser instalado na VM. As versões secundárias não são importantes e sua discrepância não é tão crítica, mas as versões principais devem ser as mesmas.

Após a criação da VM, iremos atualizar os pacotes no CTID e na VM (não confundir com atualização do SO - não atualizamos, apenas atualizamos os pacotes e, se chegar, a versão do SO dentro do principal versão).

Para CentOS este processo parece inofensivo:

# yum clean all
# yum update -y

E não menos inofensivo para Ubuntu e Debian:

# apt-get update
# apt-get upgrade

Passo 2

Instalar em IDCT, VZ_NODE и VM utilidade rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Não estamos instalando mais nada lá ou ali.

Passo 3

Fazemos uma parada IDCT em VZ_NODE a equipe

vzctl stop CTID

Montando a imagem IDCT:

vzctl mount CTID

Vá para a pasta /vz/root/IDCT e executar

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

Na raiz, crie um arquivo /root/exclude.txt - ele conterá uma lista de exceções que não chegarão ao 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

Nós nos conectamos a KVM_NODE e lançar nosso VMpara que funcione e seja acessível pela rede.

Agora tudo está pronto para transferência. Ir!

Passo 4

Ainda sob o feitiço, nós atuamos

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 transferência, esperamos que as chaves estejam claras - a transferência é realizada preservando links simbólicos, direitos de acesso, proprietários e grupos, e a criptografia está desabilitada para maior velocidade (você poderia usar alguma cifra mais rápida, mas isso não é tão importante para esta tarefa), assim como a compactação está desativada.

Após completar o rsync, saia do chroot (pressionando ctrl+d) e execute

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

Passo 5

Vamos realizar várias etapas que nos ajudarão a iniciar a VM após a transferência do OpenVZ.
Em servidores com Systemd vamos executar um comando que nos ajudará a fazer login em um console normal, por exemplo, por meio de uma tela de servidor VNC

mv /etc/systemd/system/getty.target.wants/[email protected] /etc/systemd/system/getty.target.wants/[email protected]

Em servidores 6 CentOS и 7 CentOS Certifique-se de instalar um kernel novo:

yum install kernel-$(uname -r)

O servidor pode ser carregado a partir dele, mas após a transferência ele pode parar de funcionar ou ser excluído.

No servidor 7 CentOS você precisa aplicar uma pequena correção para PolkitD, caso contrário o servidor irá travar para sempre:

getent group polkitd >/dev/null && echo -e "e[1;32mpolkitd group already existse[0m" || { groupadd -r polkitd && echo -e "e[1;33mAdded missing polkitd groupe[0m" || echo -e "e[1;31mAdding polkitd group FAILEDe[0m"; }

getent passwd polkitd >/dev/null 
&& echo -e "e[1;32mpolkitd user already existse[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "User for polkitd" polkitd && echo -e "e[1;33mAdded missing polkitd usere[0m" || echo -e "e[1;31mAdding polkitd user FAILEDe[0m"; }

rpm -Va polkit* && echo -e "e[1;32mpolkit* rpm verification passede[0m" || { echo -e "e[1;33mResetting polkit* rpm user/group ownership & permse[0m"; rpm --setugids polkit polkit-pkla-compat; rpm --setperms polkit polkit-pkla-compat; }

Em todos os servidores, se o mod_fcgid para Apache foi instalado, faremos uma pequena correção com direitos, caso contrário os sites que usam mod_fcgid irão travar com o erro 500:

chmod +s `which suexec` && apachectl restart

E a última coisa é útil para distribuições Ubuntu e Debian. Este sistema operacional pode travar em uma inicialização eterna com um erro

loop muito rápido. estrangulando um pouco a execução

desagradável, mas facilmente corrigido, dependendo da versão do sistema operacional.

На Debian 9 a correção fica assim:

nós realizamos

dbus-uuidgen

se obtivermos um erro

/usr/local/lib/libdbus-1.so.3: versão `LIBDBUS_PRIVATE_1.10.8′ não encontrada

verifique 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 <-- нужен этот
libdbus-1.so.3.14.16

se tudo estiver em ordem, nós fazemos

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

Se não ajudar, tente a segunda opção.

A segunda solução para o problema com estrangulando um pouco a execução Adequado para quase todas as distribuições Ubuntu e Debian.

Realizamos

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

E para Ubuntu 14, Debian 7 Adicionalmente realizamos:

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

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

O que nos fizemos? Restauramos o messagebus, que estava faltando para rodar o Debian/Ubuntu, e removemos o module_dep, que veio do OpenVZ e interferia no carregamento de muitos módulos do kernel.

Passo 6

Reinicializamos a VM, verificamos no VNC como está o carregamento e, idealmente, tudo carregará sem problemas. Embora seja possível que alguns problemas específicos apareçam após a migração, eles estão além do escopo deste artigo e serão corrigidos à medida que surgirem.

Eu espero que esta informação seja útil! 🙂

Fonte: habr.com