ProHoster > Blogs > Administrācija > Kā bez galvassāpēm pārsūtīt OpenVZ 6 konteineru uz KVM serveri

Kā bez galvassāpēm pārsūtīt OpenVZ 6 konteineru uz KVM serveri

Ikviens, kuram vismaz vienu reizi dzÄ«vē ir bijis nepiecieÅ”ams pārsÅ«tÄ«t OpenVZ konteineru uz serveri ar pilnu KVM virtualizāciju, ir saskārusies ar dažām problēmām:

  • Lielākā daļa informācijas ir vienkārÅ”i novecojusi un attiecas uz operētājsistēmām, kuras jau sen bija izturējuÅ”as EOL ciklu
  • Par dažādām operētājsistēmām vienmēr tiek sniegta atŔķirÄ«ga informācija, un iespējamās kļūdas migrācijas laikā nekad netiek ņemtas vērā
  • Dažkārt nākas saskarties ar konfigurācijām, kuras ik pa brÄ«dim pēc migrācijas nevēlas darboties

Pārsūtot 1 serveri, jūs vienmēr varat kaut ko labot lidojuma laikā, bet, pārsūtot visu klasteru?

Å ajā rakstā es mēģināŔu jums pastāstÄ«t, kā pareizi migrēt OpenVZ konteineru uz KVM ar minimālu dÄ«kstāvi un ātru visu problēmu risinājumu.

Neliela izglītības programma: kas ir OpenVZ un kas ir KVM?

Mēs neiedziļināsimies terminoloģijā, bet teiksim vispārīgi:

OpenVZ ā€” virtualizācija operētājsistēmas lÄ«menÄ«, to var izvietot pat mikroviļņu krāsnÄ«, jo resursdatorā nav nepiecieÅ”amas CPU instrukcijas un virtualizācijas tehnoloÄ£ijas.

KVM - pilnvērtÄ«ga virtualizācija, izmantojot visu CPU jaudu un spēj virtualizēt jebko, jebkurā veidā, griežot to gareniski un Ŕķērsām.

Pretēji izplatÄ«tajam uzskatam, ka starp hostinga pakalpojumu sniedzējiem OpenVZ kļūs pārpārdots, bet KVM nē ā€“ pēdējam par laimi, KVM tagad ir pārpārdots ne sliktāk kā tā brālis.

Ko mēs pārvedīsim?

Kā pārsÅ«tÄ«Å”anas testa subjekti mums bija jāizmanto viss OpenVZ pieejamo operētājsistēmu mežs: CentOS (6 un 7 versijas), Ubuntu (14, 16 un 18 LTS), Debian 7.

Tika pieņemts, ka lielākajā daļā OpenVZ konteineru jau darbojas kāda veida LAMP, un dažiem pat bija ļoti specifiska programmatÅ«ra. Visbiežāk tās bija konfigurācijas ar ISPmanager, VestaCP vadÄ«bas paneli (un visbiežāk tās nav atjauninātas gadiem ilgi). Jāņem vērā arÄ« viņu pārcelÅ”anas pieprasÄ«jumi.

Migrācija tiek veikta, saglabājot pārsÅ«tÄ«tā konteinera IP adresi; mēs pieņemsim, ka konteinera IP adrese ir saglabāta virtuālajā maŔīnā un darbosies bez problēmām.

Pirms pārsūtīŔanas pārliecināsimies, ka mums viss ir pa rokai:

  • OpenVZ serveris, pilna root piekļuve resursdatoram, iespēja apturēt/uzmontēt/sākt/dzēst konteinerus
  • KVM serveris, pilna root piekļuve resursdatoram ar visu, ko tas nozÄ«mē. Tiek pieņemts, ka viss jau ir konfigurēts un gatavs darbam.

Sāksim pārsūtīŔanu

Pirms sākam pārsÅ«tÄ«Å”anu, definēsim terminus, kas palÄ«dzēs izvairÄ«ties no neskaidrÄ«bām:

KVM_NODE - KVM resursdatora maŔīna
VZ_NODE - OpenVZ resursdatora maŔīna
CTID - OpenVZ konteiners
VM - KVM virtuālais serveris

SagatavoŔanās migrācijai un virtuālo maŔīnu izveide.

Solis 1

Tā kā konteiners kaut kur jāpārvieto, mēs izveidosim VM ar līdzīgu konfigurāciju KVM_NODE.
SvarÄ«gi! Jums ir jāizveido virtuālā maŔīna operētājsistēmā, kas paÅ”laik darbojas ar CTID. Piemēram, ja CTID ir instalēts Ubuntu 14, tad VM ir jāinstalē Ubuntu 14. Mazākās versijas nav svarÄ«gas un to neatbilstÄ«ba nav tik kritiska, bet galvenajām versijām jābÅ«t vienādām.

Pēc virtuālās maŔīnas izveidoÅ”anas mēs atjaunināsim pakotnes CTID un virtuālajā maŔīnā (nejaukt ar OS atjaunināŔanu - mēs to neatjauninām, mēs atjauninām tikai pakotnes un, ja tā pienāk, OS versiju galvenajā sistēmā. versija).

CentOS Ŕis process izskatās nekaitīgs:

# yum clean all
# yum update -y

Un ne mazāk nekaitīgs Ubuntu un Debian:

# apt-get update
# apt-get upgrade

Solis 2

Instalējiet uz CTID, VZ_NODE Šø VM lietderÄ«ba rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Mēs neko citu neinstalējam ne tur, ne tur.

Solis 3

Mēs apstājamies CTID par VZ_NODE komanda

vzctl stop CTID

Attēla uzstādÄ«Å”ana CTID:

vzctl mount CTID

Dodieties uz mapi /vz/root/CTID un izpildīt

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

Zem saknes izveidojiet failu /root/exclude.txt ā€” tajā bÅ«s saraksts ar izņēmumiem, kuri nenokļūs jaunajā serverÄ«.

/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

Pievienot KVM_NODE un palaidiet mūsu VMlai tas darbotos un būtu pieejams tīklā.

Tagad viss ir gatavs pārsūtīŔanai. Aiziet!

Solis 4

Joprojām burvībā mēs uzstājamies

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

Komanda rsync veiks pārsÅ«tÄ«Å”anu, ceram, ka atslēgas ir skaidras - pārsÅ«tÄ«Å”ana tiek veikta, saglabājot simboliskās saites, piekļuves tiesÄ«bas, Ä«paÅ”niekus un grupas, un Å”ifrÄ“Å”ana ir atspējota, lai nodroÅ”inātu lielāku ātrumu (varētu izmantot kādu ātrāku Å”ifru, bet Å”im uzdevumam tas nav tik svarÄ«gi), kā arÄ« ir atspējota saspieÅ”ana.

Pēc rsync pabeigÅ”anas izejiet no chroot (nospiežot ctrl+d) un izpildiet

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

Solis 5

Veiksim vairākas darbÄ«bas, kas mums palÄ«dzēs palaist virtuālo maŔīnu pēc pārsÅ«tÄ«Å”anas no OpenVZ.
Uz serveriem ar Systemd izpildīsim komandu, kas palīdzēs mums pieteikties parastajā konsolē, piemēram, caur VNC servera ekrānu

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

Uz serveriem 6 CentOS Šø 7 CentOS Noteikti instalējiet jaunu kodolu:

yum install kernel-$(uname -r)

No tā serveri var ielādēt, taču pēc pārsÅ«tÄ«Å”anas tas var pārstāt darboties vai tikt izdzēsts.

Uz servera 7 CentOS jums ir jāpiemēro neliels PolkitD labojums, pretējā gadījumā serveris uz visiem laikiem avarēs:

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

Visos serveros, ja mod_fcgid for Apache tika instalēts, mēs veiksim nelielu labojumu ar tiesībām, pretējā gadījumā vietnes, kas izmanto mod_fcgid, avarēs ar kļūdu 500:

chmod +s `which suexec` && apachectl restart

Un pēdējā lieta ir noderÄ«ga Ubuntu un Debian izplatÄ«Å”anām. Å Ä« OS var ietriekties mūžīgā sāknÄ“Å”anas laikā ar kļūdu

cilpa pārāk ātri. nedaudz ierobežojot izpildi

nepatīkams, bet viegli labojams, atkarībā no OS versijas.

uz Debian 9 labojums izskatās Ŕādi:

mēs veicam

dbus-uuidgen

ja mēs saņemam kļūdu

/usr/local/lib/libdbus-1.so.3: versija `LIBDBUS_PRIVATE_1.10.8ā€² nav atrasta

pārbaudiet LIBDBUS klātbūtni 

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

ja viss ir kārtībā, mēs to darām

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

Ja tas nepalīdz, izmēģiniet otro iespēju.

Otrs problēmas risinājums ar nedaudz ierobežojot izpildi Piemērots gandrīz visiem Ubuntu un Debian izplatījumiem.

Mēs veicam

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

Un par ubuntu 14, Debian 7 Papildus veicam:

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

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

Ko mēs esam izdarÄ«juÅ”i? Mēs atjaunojām ziņojumu kopni, kuras trÅ«ka, lai palaistu Debian/Ubuntu, un noņēmām modules_dep, kas nāca no OpenVZ un traucēja daudzu kodola moduļu ielādi.

Solis 6

Mēs pārstartējam VM, pārbaudām VNC, kā notiek ielāde, un ideālā gadÄ«jumā viss tiks ielādēts bez problēmām. Lai gan ir iespējams, ka pēc migrācijas parādÄ«sies dažas Ä«paÅ”as problēmas, tās neietilpst Ŕī raksta darbÄ«bas jomā un tiks labotas, tiklÄ«dz tās radÄ«sies.

Es ceru, ka Ŕī informācija ir noderÄ«ga! šŸ™‚

Avots: www.habr.com

Pievieno komentāru