Hoe om OpenVZ 6-houer na KVM-bediener oor te dra sonder hoofpyn

Enigiemand wat minstens een keer in hul lewe 'n OpenVZ-houer na 'n bediener met volle KVM-virtualisering moes oordra, het probleme ondervind:

  • Die meeste van die inligting is eenvoudig verouderd en was relevant vir bedryfstelsels wat lankal die EOL-siklus geslaag het
  • Verskillende inligting word altyd vir verskillende bedryfstelsels verskaf, en moontlike foute tydens migrasie word nooit oorweeg nie
  • Soms het jy te doen met konfigurasies wat elke nou en dan nie wil werk na migrasie nie

As jy 1 bediener oordra, kan jy altyd iets dadelik regmaak, maar wanneer jy 'n hele groep oordra?

In hierdie artikel sal ek probeer om jou te vertel hoe om 'n OpenVZ-houer korrek na KVM te migreer met minimale stilstand en 'n vinnige oplossing vir alle probleme.

'n Klein opvoedkundige program: wat is OpenVZ en wat is KVM?

Ons gaan nie diep in terminologie in nie, maar sal in algemene terme sê:

OpenVZ - virtualisering op die bedryfstelselvlak, jy kan dit selfs op 'n mikrogolf ontplooi, aangesien daar geen SVE-instruksies en virtualisasietegnologie op die gasheermasjien nodig is nie.

KVM - Volwaardige virtualisasie, wat al die krag van die SVE gebruik en in staat is om enigiets op enige manier te virtualiseer, dit in die lengte en dwars te sny.

In teenstelling met die algemene opvatting dat OpenVZ onder gasheerverskaffers oorverkoop sal word, maar KVM nie - gelukkig vir laasgenoemde is KVM nou nie erger as sy broer oorverkoop nie.

Wat sal ons oordra?

As proefpersone vir die oordrag moes ons die hele bos bedryfstelsels wat op OpenVZ beskikbaar is, gebruik: CentOS (6 en 7 weergawes), Ubuntu (14, 16 en 18 LTS), Debian 7.

Daar is aanvaar dat die meeste van die OpenVZ-houers reeds 'n soort LAMP gebruik het, en sommige het selfs baie spesifieke sagteware gehad. Meestal was dit konfigurasies met die ISPmanager, VestaCP-kontrolepaneel (en meestal nie vir jare opgedateer nie). Hul oordragversoeke moet ook in ag geneem word.

Migrasie word uitgevoer terwyl die IP-adres van die oorgeplaaste houer bewaar word; ons sal aanvaar dat die IP wat die houer gehad het op die VM gestoor is en sonder probleme sal werk.

Kom ons maak seker dat ons alles byderhand het voordat ons oordra:

  • OpenVZ-bediener, volle worteltoegang tot die gasheermasjien, vermoë om houers te stop/monteer/begin/vee
  • KVM-bediener, volle worteltoegang tot die gasheermasjien, met alles wat dit impliseer. Daar word aanvaar dat alles reeds gekonfigureer en gereed is om te gaan.

Kom ons begin oordrag

Voordat ons met die oordrag begin, kom ons definieer terme wat u sal help om verwarring te voorkom:

KVM_NODE - KVM-gasheermasjien
VZ_NODE - OpenVZ gasheer masjien
CTID - OpenVZ-houer
VM - KVM virtuele bediener

Voorbereiding vir migrasie en die skep van virtuele masjiene.

Stap 1

Aangesien ons die houer iewers heen moet skuif, sal ons skep VM met 'n soortgelyke opset as KVM_NODE.
Belangrik! Jy moet 'n VM skep op die bedryfstelsel wat tans op CTID loop. Byvoorbeeld, as Ubuntu 14 op die CTID geïnstalleer is, dan moet Ubuntu 14 op die VM geïnstalleer word. Klein weergawes is nie belangrik nie en hul verskil is nie so krities nie, maar hoof weergawes moet dieselfde wees.

Nadat ons die VM geskep het, sal ons die pakkette op die CTID en op die VM opdateer (nie te verwar met die opdatering van die bedryfstelsel nie - ons werk dit nie op nie, ons werk net die pakkette op en, as dit aankom, die bedryfstelselweergawe binne die hoof weergawe).

Vir CentOS lyk hierdie proses skadeloos:

# yum clean all
# yum update -y

En nie minder skadeloos vir Ubuntu en Debian nie:

# apt-get update
# apt-get upgrade

Stap 2

Installeer op CTID, VZ_NODE и VM nut rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Ons installeer niks anders of daar of daar nie.

Stap 3

Ons maak 'n stop CTID op VZ_NODE per span

vzctl stop CTID

Monteer die beeld CTID:

vzctl mount CTID

Gaan na die /vz/root/-lêergidsCTID en uitvoer

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

Onder die wortel, skep 'n lêer /root/exclude.txt - dit sal 'n lys van uitsonderings bevat wat nie na die nuwe bediener sal kom nie

/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

Ons maak verbinding met KVM_NODE en begin ons VMsodat dit werk en toeganklik is oor die netwerk.

Nou is alles gereed vir oordrag. Gaan!

Stap 4

Nog in die ban, ons presteer

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

Die rsync-opdrag sal die oordrag uitvoer, ons hoop dat die sleutels duidelik is - die oordrag word uitgevoer met die behoud van simskakels, toegangsregte, eienaars en groepe, en enkripsie is gedeaktiveer vir groter spoed (jy kan 'n vinniger syfer gebruik, maar dit is nie so belangrik vir hierdie taak nie), sowel as kompressie is gedeaktiveer.

Nadat u rsync voltooi het, verlaat chroot (deur ctrl+d te druk) en voer uit

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

Stap 5

Kom ons voer verskeie stappe uit wat ons sal help om die VM te begin na die oordrag van OpenVZ.
Op bedieners met Systemd kom ons voer 'n opdrag uit wat ons sal help om by 'n gewone konsole aan te meld, byvoorbeeld deur 'n VNC-bedienerskerm

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

Op bedieners CentOS 6 и CentOS 7 Maak seker dat jy 'n vars pit installeer:

yum install kernel-$(uname -r)

Die bediener kan daaruit gelaai word, maar na die oordrag kan dit dalk ophou werk of uitgevee word.

Op bediener CentOS 7 jy moet 'n klein oplossing vir PolkitD toepas, anders sal die bediener vir ewig ineenstort:

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

Op alle bedieners, as mod_fcgid vir Apache geïnstalleer is, sal ons 'n klein regstelling met regte uitvoer, anders sal werwe wat mod_fcgid gebruik, ineenstort met fout 500:

chmod +s `which suexec` && apachectl restart

En die laaste ding is nuttig vir Ubuntu- en Debian-verspreidings. Hierdie bedryfstelsel kan met 'n fout in 'n ewige selflaai ineenstort

loop te vinnig. versmoor uitvoering 'n bietjie

onaangenaam, maar maklik reggemaak, afhangende van die OS weergawe.

Op Debian 9 die regstelling lyk so:

ons voer uit

dbus-uuidgen

as ons 'n fout kry

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

kontroleer die teenwoordigheid van 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

as alles in orde is, doen ons dit

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

As dit nie help nie, probeer die tweede opsie.

Die tweede oplossing vir die probleem met versmoor uitvoering 'n bietjie Geskik vir byna alle Ubuntu- en Debian-verspreidings.

Ons voer uit

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

En vir Ubuntu 14, Debian 7 Verder voer ons uit:

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

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

Wat het ons gedoen? Ons het boodskapbus herstel, wat ontbreek het om Debian/Ubuntu te laat loop, en modules_dep verwyder, wat van OpenVZ gekom het en inmeng met die laai van baie kernmodules.

Stap 6

Ons herlaai die VM, kyk in VNC hoe die laai vorder en, ideaal gesproke, sal alles sonder probleme laai. Alhoewel dit moontlik is dat sommige spesifieke probleme na die migrasie sal verskyn, val dit buite die bestek van hierdie artikel en sal dit reggestel word soos dit opduik.

Ek hoop hierdie inligting is nuttig! 🙂

Bron: will.com

Voeg 'n opmerking