Jak bez problemu 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, że wśród dostawców hostingu OpenVZ zostanie wyprzedany, ale KVM nie - na szczęście dla tego ostatniego, KVM jest teraz wyprzedany nie gorzej niż jego brat.

Co przeniesiemy?

Jako obiekty testowe 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.

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 adresu IP przenoszonego kontenera, założymy, że adres IP, który posiadał kontener jest zapisany 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 systemie operacyjnym, który aktualnie działa na CTID. Na przykład, jeśli na CTID jest zainstalowany Ubuntu 14, to na maszynie wirtualnej musi być zainstalowany Ubuntu 14. Wersje poboczne nie są ważne, a ich rozbieżność nie jest tak krytyczna, ale wersje główne powinny 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).

W przypadku CentOS proces ten wygląda nieszkodliwie:

# yum clean all
# yum update -y

I nie mniej nieszkodliwe dla Ubuntu i Debiana:

# 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/[email protected] /etc/systemd/system/getty.target.wants/[email protected]

Na serwerach 6 CentOS и 7 CentOS 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 7 CentOS 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 ostatnia rzecz jest przydatna w przypadku dystrybucji Ubuntu i Debian. Ten system operacyjny może spowodować awarię wiecznego rozruchu z powodu błędu

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 Nadaje się do prawie wszystkich dystrybucji Ubuntu i Debian.

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 my zrobiliśmy? Przywróciliśmy magistralę komunikatów, której brakowało do uruchomienia Debiana/Ubuntu i usunęliśmy moduły_dep, które pochodziły z OpenVZ i zakłócały ł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