🥇Jak przenieść kontener OpenVZ 6 na serwer KVM bez bólu głowy

Każdy, kto kiedykolwiek musiał przenieść kontener OpenVZ na serwer z pełną wirtualizacją KVM, napotkał pewne problemy:

Większość informacji jest po prostu przestarzała i była aktualna dla już dawno minionych cykli EOL systemów operacyjnych.
Dla różnych systemów operacyjnych zawsze dostępne są różne informacje, a nigdy nie omawia się możliwych błędów podczas migracji.
Czasami trzeba zmierzyć się z konfiguracjami, które za nic nie chcą działać po migracji.

Gdy przenosisz jeden serwer, zawsze możesz coś poprawić na bieżąco, ale co zrobić, gdy przenosisz cały klaster?

W tym artykule postaram się opowiedzieć, jak prawidłowo migrować kontener OpenVZ na KVM przy minimalnym czasie przestoju i szybkim rozwiązaniu wszystkich problemów.

Krótka pigułka: czym jest OpenVZ, a czym jest KVM?

Nie będziemy zgłębiać terminologii, a powiemy w ogólnych zarysach:

OpenVZ — wirtualizacja na poziomie systemu operacyjnego, można ją uruchomić nawet na mikrofalówce, ponieważ nie ma potrzeby posiadania instrukcji CPU i technologii wirtualizacji na maszynie gospodarza.

KVM — pełna wirtualizacja, która wykorzystuje moc CPU i jest w stanie wirtualizować wszystko, jak tylko chce, ciąć wzdłuż i wszerz.

Wbrew powszechnemu przekonaniu, że w środowisku dostawców hostingu, OpenVZ jest przerośnięty, a KVM nie — na szczęście dla tych ostatnich, KVM obecnie przerośnie tak samo skutecznie jak jego brat.

Co będziemy przenosić?

Jako obiekty do przeniesienia musieliśmy wykorzystać cały las systemów operacyjnych dostępnych na OpenVZ: CentOS (wersje 6 i 7), Ubuntu (14, 16 i 18 LTS), Debian 7.

Zakładano, że na większości kontenerów OpenVZ już działa mniej więcej LAMP, a niektóre mają nawet dość specyficzne oprogramowanie. Najczęściej były to konfiguracje z panelami administracyjnymi ISPmanager, VestaCP (i to zazwyczaj nieaktualizowane od lat). Należy uwzględnić także ich wymagania dotyczące migracji.

Migracja odbywa się z zachowaniem adresy IP przenoszonego kontenera, zakładając, że IP, które miało kontener, zostaje na VM i będzie działać bez problemu.

Przed przeniesieniem upewnijmy się, że mamy wszystko pod ręką:

Serwer OpenVZ, pełny dostęp root do maszyny gospodarza, możliwość zatrzymywania/montowania/uruchamiania/usuwania kontenerów.
Serwer KVM z pełnym dostępem root do maszyny hosta, z wszystkimi tego konsekwencjami. Zakładamy, że wszystko jest już skonfigurowane i gotowe do pracy.

Przechodzimy do migracji

Zanim zaczniemy migrację, określimy terminy, które pomogą uniknąć zamieszania:

KVM_NODE — maszyna hosta KVM
VZ_NODE — maszyna hosta OpenVZ
CTID — kontener OpenVZ
VM — wirtualny serwer KVM

Przygotowanie do migracji i tworzenie wirtualnych maszyn.

Krok 1

Ponieważ musimy gdzieś przenieść kontener, stworzymy VM z analogiczną konfiguracją na KVM_NODE.
WAŻNE! Wirtualną maszynę należy tworzyć dokładnie na tym systemie operacyjnym, który obecnie działa na CTID. Na przykład, jeśli na CTID zainstalowano Ubuntu 14, to na VM również należy zainstalować Ubuntu 14. Minory nie są istotne i ich niezgodność nie jest krytyczna, ale główne wersje muszą być identyczne.

Po stworzeniu VM wykonujemy aktualizację pakietów na CTID i na VM (nie mylić z aktualizacją systemu operacyjnego — nie aktualizujemy go, aktualizujemy tylko pakiety i, jeśli się pojawi, wersję systemu operacyjnego w ramach głównej wersji).

Dla CentOS ten proces wygląda niegroźnie:

# yum clean all
# yum update -y

I równie niegroźnie dla Ubuntu, Debiana:

# apt-get update
# apt-get upgrade

Krok 2

Instalujemy na CTID, VZ_NODE i VM do konwertowania nagrań audio do formatu CAS, który jest obsługiwany przez emulatory, jednak z jakiegoś powodu nie udało mi się odczytać nagrań z moich kaset. rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Nic więcej nie instalujemy ani tam, ani tam.

Krok 3

Wykonujemy zatrzymanie CTID na VZ_NODE poleceniem

vzctl stop CTID

Montowanie obrazu CTID:

vzctl mount CTID

Przechodzimy do folderu /vz/root/CTID i wykonujemy

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

Pod chrootem tworzymy plik /root/exclude.txt — będzie zawierał listę wyjątków, które nie trafią na nowy serwer

/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

Łączymy się z KVM_NODE i uruchamiamy nasz VM, aby działał i był dostępny w sieci.

Teraz wszystko gotowe do migracji. Zaczynamy!

Krok 4

Będąc wciąż pod chrootem, wykonujemy

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

Polecenie rsync wykona migrację, mamy nadzieję, że klucze są zrozumiałe — migracja odbywa się z zachowaniem symlinków, praw dostępu, właścicieli i grup, a szyfrowanie jest wyłączone dla uzyskania większej prędkości (można było użyć jakiegoś szybszego szyfru, ale nie jest to tak istotne w ramach tego zadania), podobnie jak wyłączono kompresję.

Po zakończeniu działania rsync, wychodzimy z chroota (naciskając ctrl+d) i wykonujemy

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

Krok 5

Wykonamy kilka działań, które pomogą nam uruchomić VM po migracji z OpenVZ.
Na serwerach z Systemd wykonamy polecenie, które pomoże nam zalogować się w normalnej konsoli, na przykład przez VNC ekran serwera

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

Na serwerach CentOS 6 i CentOS 7 obowiązkowo zainstalujemy świeże jądro:

yum install kernel-$(uname -r)

Serwer może być z niego uruchomiony, ale po przeniesieniu może przestać działać lub zostać usunięty.

Na serwerze CentOS 7 należy zastosować niewielką poprawkę dla PolkitD, w przeciwnym razie serwer wpadnie w wieczne bootowanie:

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

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

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

Na wszystkich serwerach, jeśli mod_fcgid został zainstalowany dla Apache, wykonamy niewielką poprawkę z prawami, w przeciwnym razie strony korzystające z mod_fcgid będą padać z błędem 500:

chmod +s `which suexec` && apachectl restart

I ostatnie, przyda się dla systemów Ubuntu, Debian. Ten system może wpaść w wieczne bootowanie z błędem

looping too fast. throttling execution a little

nieprzyjemnie, ale łatwo do naprawienia, w zależności od wersji systemu.

Na Debian 9 poprawka wygląda tak:

wykonujemy

dbus-uuidgen

jeśli otrzymujemy błąd

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

sprawdzamy obecność 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 <-- potrzebny jest ten
libdbus-1.so.3.14.16

jeśli wszystko w porządku, wykonujemy

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

Jeśli nie pomaga — próbujemy drugą opcję.

Druga opcja rozwiązania problemu z throttling execution a little pasuje praktycznie do wszystkich dystrybucji Ubuntu i Debian.

Wykonujemy

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

A dla Ubuntu 14, Debian 7 dodatkowo wykonujemy:

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

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

Co zrobiliśmy? Przywróciliśmy messagebus, którego brakowało do uruchomienia Debian/Ubuntu i usunęliśmy modules_dep, który pochodził z OpenVZ i przeszkadzał w ładowaniu wielu modułów jądra.

Krok 6

Restartujemy VM, sprawdzamy w VNC jak idzie ładowanie i w idealnym przypadku — wszystko załaduje się bez problemów. Chociaż mogą wystąpić pewne specyficzne problemy po migracji — ale wykraczają one poza ramy tego artykułu i są naprawiane w miarę ich występowania.

Mam nadzieję, że te informacje będą przydatne! 🙂

Źródło: habr.com