🥇Jak bezproblemowo przenieść kontener OpenVZ 6 na serwer KVM

Każdy, kto chociaż raz w życiu musiał przenieść kontener OpenVZ na serwer z pełną wirtualizacją KVM, spotkał się z pewnymi problemami:

Większość informacji jest po prostu nieaktualna i dotyczyła systemów operacyjnych, które już dawno przeszły cykl EOL
Dla różnych systemów operacyjnych zawsze podawane są różne informacje i nigdy nie są brane pod uwagę możliwe błędy podczas migracji
Czasem trzeba się zmierzyć z konfiguracjami, które co jakiś czas nie chcą działać po migracji

Kiedy przenosisz 1 serwer, zawsze możesz coś naprawić na bieżąco, ale kiedy przenosisz cały klaster?

W tym artykule postaram się powiedzieć, jak poprawnie przeprowadzić migrację kontenera OpenVZ na KVM przy minimalnym przestoju i szybkim rozwiązaniu wszystkich problemów.

Mały program edukacyjny: czym jest OpenVZ i czym jest KVM?

Nie będziemy zagłębiać się w terminologię, ale powiemy ogólnie:

OpenVZ — wirtualizację na poziomie systemu operacyjnego, można ją wdrożyć nawet na kuchence mikrofalowej, ponieważ nie ma potrzeby stosowania instrukcji procesora i technologii wirtualizacji na komputerze głównym.

KVM - pełnoprawna wirtualizacja, wykorzystująca całą moc procesora i zdolna do wirtualizacji czegokolwiek, w dowolny sposób, przecinając to wzdłuż i w poprzek.

Wbrew powszechnemu przekonaniu, w środowisku dostawcy hostingu OpenVZ jest przereklamowany, ale KVM nie. Na szczęście dla tego drugiego, KVM jest teraz przereklamowany równie dobrze, jak jego brat.

Co przeniesiemy?

Do transferu konieczne było przetestowanie całej gamy systemów operacyjnych dostępnych w OpenVZ: CentOS (wersje 6 i 7), Ubuntu (14, 16 i 18 LTS), Debian 7.

Założono, że większość kontenerów OpenVZ obsługuje już jakiś rodzaj LAMPY, a niektóre mają nawet bardzo specyficzne oprogramowanie. Najczęściej były to konfiguracje z ISPmanagerem, panelem kontrolnym VestaCP (i najczęściej nieaktualizowane od lat). Należy również uwzględnić ich prośby o transfer.

Migracja odbywa się z zachowaniem Adresy IP W przypadku kontenera przenośnego założymy, że adres IP kontenera jest przechowywany na maszynie wirtualnej i będzie działał bez problemów.

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

Serwer OpenVZ, pełny dostęp root do komputera hosta, możliwość zatrzymywania/montowania/uruchamiania/usuwania kontenerów
Serwer KVM, pełny dostęp root do komputera hosta, ze wszystkim, co się z tym wiąże. Zakłada się, że wszystko jest już skonfigurowane i gotowe do pracy.

Zacznijmy przenosić

Zanim rozpoczniemy transfer, zdefiniujmy pojęcia, które pomogą Ci uniknąć nieporozumień:

KVM_NODE - Komputer hosta KVM
VZ_NODE - Komputer hosta OpenVZ
CTID - Kontener OpenVZ
VM - Serwer wirtualny KVM

Przygotowanie do migracji i tworzenie maszyn wirtualnych.

Krok 1

Ponieważ musimy gdzieś przenieść kontener, utworzymy VM z podobną konfiguracją do KVM_NODE.
Ważne! Musisz utworzyć maszynę wirtualną w tym samym systemie operacyjnym, który jest obecnie uruchomiony na CTID. Na przykład, jeśli CTID jest uruchomiony Ubuntu 14, to musisz zainstalować go również na maszynie wirtualnej Ubuntu 14. Wersje drugorzędne nie są istotne i rozbieżności między nimi nie są aż tak istotne, ale wersje główne muszą być takie same.

Po utworzeniu VM zaktualizujemy pakiety na CTID i VM (nie mylić z aktualizacją systemu operacyjnego - nie aktualizujemy go, aktualizujemy tylko pakiety i, jeśli nadejdzie, wersję systemu operacyjnego w głównym wersja).

dla CentOS Ten proces wydaje się nieszkodliwy:

# yum clean all
# yum update -y

I nie mniej nieszkodliwe dla Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Krok 2

Zainstaluj na CTID, VZ_NODE и VM narzędzie rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Nie instalujemy niczego innego ani tam, ani tam.

Krok 3

Zatrzymujemy się CTID na VZ_NODE według zespołu

vzctl stop CTID

Montaż obrazu CTID:

vzctl mount CTID

Przejdź do folderu /vz/root/CTID i wykonać

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

W katalogu głównym utwórz plik /root/exclude.txt - będzie on zawierał listę wyjątków, które nie dotrą 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

Połącz się z KVM_NODE i uruchom nasz VMaby działało i było dostępne w sieci.

Teraz wszystko jest gotowe do przeniesienia. Iść!

Krok 4

Wciąż pod urokiem, występujemy

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

Polecenie rsync wykona transfer, mamy nadzieję, że klucze są jasne - transfer odbywa się z zachowaniem dowiązań symbolicznych, praw dostępu, właścicieli i grup, a szyfrowanie jest wyłączone w celu uzyskania większej szybkości (można użyć szybszego szyfru, ale nie jest to tak ważne dla tego zadania), a także kompresja jest wyłączona.

Po zakończeniu rsync wyjdź z chroot (naciskając ctrl+d) i wykonaj

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

Krok 5

Wykonajmy kilka kroków, które pomogą nam uruchomić maszynę wirtualną po przeniesieniu z OpenVZ.
Na serwerach z Systemd wykonajmy polecenie, które pomoże nam zalogować się do zwykłej konsoli, na przykład poprzez ekran serwera VNC

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

Na serwerach CentOS 6 и CentOS 7 Pamiętaj, aby zainstalować świeże jądro:

yum install kernel-$(uname -r)

Serwer można z niego załadować, jednak po przeniesieniu może on przestać działać lub zostać usunięty.

Na serwerze CentOS 7 musisz zastosować małą poprawkę dla PolkitD, w przeciwnym razie serwer ulegnie awarii na zawsze:

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; }

Na wszystkich serwerach, jeśli zainstalowano mod_fcgid dla Apache, wykonamy małą poprawkę z uprawnieniami, w przeciwnym razie strony korzystające z mod_fcgid zawieszą się z błędem 500:

chmod +s `which suexec` && apachectl restart

I na koniec, będzie to przydatne dla Ubuntu, Debian dystrybucje. Ten system operacyjny może ulec awarii i spowodować trwały błąd rozruchu.

pętla jest zbyt szybka. trochę ograniczając wykonanie

nieprzyjemne, ale łatwe do naprawienia, w zależności od wersji systemu operacyjnego.

Na Debian 9 poprawka wygląda następująco:

przeprowadzamy

dbus-uuidgen

jeśli otrzymamy błąd

/usr/local/lib/libdbus-1.so.3: nie znaleziono wersji `LIBDBUS_PRIVATE_1.10.8′

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

jeśli wszystko jest w porządku, robimy to

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 to nie pomoże, wypróbuj drugą opcję.

Drugie rozwiązanie problemu z trochę ograniczając wykonanie odpowiedni dla prawie każdego Ubuntu и Debian dystrybucje.

Wykonujemy

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

I 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 magistralę komunikatów, której brakowało podczas uruchamiania. Debian/Ubuntu i usunięto modules_dep, które pochodziło z OpenVZ i uniemożliwiało załadowanie wielu modułów jądra.

Krok 6

Ponownie uruchamiamy maszynę wirtualną, sprawdzamy w VNC, jak przebiega ładowanie i w idealnym przypadku wszystko załaduje się bez problemów. Chociaż możliwe jest, że po migracji pojawią się pewne specyficzne problemy, wykraczają one poza zakres tego artykułu i zostaną poprawione, gdy tylko się pojawią.

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

Źródło: www.habr.com