ProHoster > Dienoraštis > Administravimas > Kaip be galvos skausmo perkelti OpenVZ 6 konteinerį į KVM serverį

Kaip be galvos skausmo perkelti OpenVZ 6 konteinerį į KVM serverį

Kiekvienas, kuriam bent kartą gyvenime teko perkelti OpenVZ konteinerį į serverį su visa KVM virtualizacija, susidūrė su šiomis problemomis:

  • Dauguma informacijos yra tiesiog pasenusi ir buvo aktuali OS, kurios jau seniai praėjo EOL ciklą
  • Visada pateikiama skirtinga informacija apie skirtingas operacines sistemas ir niekada neatsižvelgiama į galimas klaidas perkėlimo metu
  • Kartais tenka susidurti su konfigūracijomis, kurios po perkėlimo retkarčiais nenori veikti

Kai perkeliate 1 serverį, visada galite ką nors ištaisyti, bet kai perkeliate visą klasterį?

Šiame straipsnyje pabandysiu papasakoti, kaip teisingai perkelti OpenVZ konteinerį į KVM su minimaliomis prastovomis ir greitu visų problemų sprendimu.

Maža edukacinė programa: kas yra OpenVZ ir kas yra KVM?

Mes nesigilinsime į terminologiją, bet pasakysime bendrais bruožais:

OpenVZ - Virtualizacija operacinės sistemos lygiu, netgi galite ją įdiegti mikrobangų krosnelėje, nes pagrindiniame kompiuteryje nereikia procesoriaus instrukcijų ir virtualizacijos technologijų.

KVM - visavertė virtualizacija, naudojanti visą procesoriaus galią ir galinti virtualizuoti bet ką, bet kokiu būdu, pjaunant išilgai ir skersai.

Priešingai populiariems įsitikinimams, kad tarp prieglobos paslaugų teikėjų „OpenVZ“ bus perparduotas, tačiau KVM – ne – pastarųjų laimei, KVM dabar perparduotas ne ką prasčiau nei jo brolis.

Ką pernešime?

Kaip perkėlimo bandomieji subjektai turėjome naudoti visą „OpenVZ“ prieinamų operacinių sistemų mišką: „CentOS“ (6 ir 7 versijos), „Ubuntu“ (14, 16 ir 18 LTS), „Debian 7“.

Buvo daroma prielaida, kad daugumoje OpenVZ konteinerių jau veikia kažkoks LAMP, o kai kurie netgi turėjo labai specifinę programinę įrangą. Dažniausiai tai buvo konfigūracijos su ISPmanager, VestaCP valdymo skydeliu (ir dažniausiai neatnaujinamos daugelį metų). Taip pat reikia atsižvelgti į jų perkėlimo prašymus.

Perkėlimas vykdomas išsaugant perkelto konteinerio IP adresą; manysime, kad konteinerio turėtas IP yra išsaugotas VM ir veiks be problemų.

Prieš perkeldami įsitikinkime, kad viską turime po ranka:

  • OpenVZ serveris, visa root prieiga prie pagrindinio kompiuterio, galimybė sustabdyti / prijungti / paleisti / ištrinti konteinerius
  • KVM serveris, visa šakninė prieiga prie pagrindinio kompiuterio su viskuo, ką tai reiškia. Daroma prielaida, kad viskas jau sukonfigūruota ir paruošta naudoti.

Pradėkime perkelti

Prieš pradėdami perkėlimą, apibrėžkime terminus, kurie padės išvengti painiavos:

KVM_NODE - KVM pagrindinis kompiuteris
VZ_NODE - OpenVZ pagrindinis kompiuteris
CTID - OpenVZ konteineris
VM - KVM virtualus serveris

Pasiruošimas migracijai ir virtualių mašinų kūrimas.

Žingsnis 1

Kadangi turime kur nors perkelti konteinerį, mes sukursime VM su panašia konfigūracija KVM_NODE.
Svarbu! Turite sukurti VM operacinėje sistemoje, kuri šiuo metu veikia naudojant CTID. Pavyzdžiui, jei CTID yra įdiegtas Ubuntu 14, tai VM turi būti įdiegtas Ubuntu 14. Mažos versijos nėra svarbios ir jų neatitikimas nėra toks kritiškas, tačiau pagrindinės versijos turėtų būti vienodos.

Sukūrę VM, atnaujinsime paketus CTID ir VM (nepainioti su OS atnaujinimu - mes jos neatnaujiname, atnaujiname tik paketus ir, jei jis ateina, OS versiją pagrindiniame versija).

CentOS atveju šis procesas atrodo nekenksmingas:

# yum clean all
# yum update -y

Ir ne mažiau nekenksmingas Ubuntu ir Debian:

# apt-get update
# apt-get upgrade

Žingsnis 2

Įdiegti CTID, VZ_NODE и VM naudingumas rsync:

Centos:

# yum install rsync -y

„Debian“, „Ubuntu“:

# apt-get install rsync -y

Daugiau nieko nemontuojame nei ten, nei ten.

Žingsnis 3

Sustojame CTID apie VZ_NODE komanda

vzctl stop CTID

Vaizdo montavimas CTID:

vzctl mount CTID

Eikite į aplanką /vz/root/CTID ir vykdyti

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

Šakninėje šaknyje sukurkite failą /root/exclude.txt – jame bus sąrašas išimčių, kurios nepateks į naują 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

Mes prisijungiame prie KVM_NODE ir paleiskite mūsų VMkad jis veiktų ir būtų pasiekiamas tinkle.

Dabar viskas paruošta perkėlimui. Pirmyn!

Žingsnis 4

Vis dar užkeikę mes atliekame

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

Komanda rsync atliks perkėlimą, tikimės, kad raktai yra aiškūs - perkėlimas atliekamas išsaugant simbolius, prieigos teises, savininkus ir grupes, o šifravimas yra išjungtas, kad būtų didesnis greitis (galite naudoti greitesnį šifrą, bet tai nėra taip svarbu šiai užduočiai), taip pat glaudinimas išjungtas.

Baigę rsync, išeikite iš chroot (spausdami ctrl+d) ir paleiskite

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

Žingsnis 5

Atlikime kelis veiksmus, kurie padės paleisti VM perkėlus iš OpenVZ.
Serveriuose su Systemd vykdykime komandą, kuri padės mums prisijungti prie įprastos konsolės, pavyzdžiui, per VNC serverio ekraną

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

Serveriuose 6 Centos и 7 Centos Būtinai įdiekite naują branduolį:

yum install kernel-$(uname -r)

Iš jo galima įkelti serverį, tačiau po perdavimo jis gali nustoti veikti arba būti ištrintas.

Serveryje 7 Centos turite pritaikyti nedidelį PolkitD pataisymą, kitaip serveris suges amžinai:

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

Visuose serveriuose, jei buvo įdiegtas mod_fcgid for Apache, atliksime nedidelį pataisymą su teisėmis, kitaip svetainės, kuriose naudojamas mod_fcgid, sugenda ir bus 500 klaida:

chmod +s `which suexec` && apachectl restart

Ir paskutinis dalykas yra naudingas Ubuntu ir Debian platinimams. Ši OS gali sugriūti į amžiną įkrovą su klaida

kilpa per greitai. šiek tiek stabdydamas vykdymą

nemalonu, bet lengvai pataisoma, priklausomai nuo OS versijos.

Apie Debian 9 pataisymas atrodo taip:

vykdome

dbus-uuidgen

jei gausime klaidą

/usr/local/lib/libdbus-1.so.3: versija `LIBDBUS_PRIVATE_1.10.8′ nerasta

patikrinkite, ar yra 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

jei viskas tvarkoje, tai ir darome

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

Jei tai nepadeda, išbandykite antrąjį variantą.

Antrasis problemos sprendimas su šiek tiek stabdydamas vykdymą Tinka beveik visiems Ubuntu ir Debian platinimams.

Mes vykdome

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

Ir už Ubuntu 14, Debian 7 Papildomai atliekame:

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

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

Ką mes padarėme? Atkūrėme pranešimų magistralę, kurios trūko, kad būtų galima paleisti Debian/Ubuntu, ir pašalinome modules_dep, kuri atkeliavo iš OpenVZ ir trukdė įkelti daugelį branduolio modulių.

Žingsnis 6

Perkrauname VM, patikriname VNC kaip vyksta įkėlimas ir idealiu atveju viskas bus įkelta be problemų. Nors gali būti, kad kai kurios konkrečios problemos atsiras po perkėlimo, jos nepatenka į šio straipsnio taikymo sritį ir bus ištaisytos, kai tik atsiras.

Tikiuosi, kad ši informacija bus naudinga! 🙂

Šaltinis: www.habr.com

Добавить комментарий