Πώς να μεταφέρετε το κοντέινερ OpenVZ 6 στον διακομιστή KVM χωρίς πονοκεφάλους

Όποιος χρειάστηκε να μεταφέρει ένα κοντέινερ OpenVZ σε έναν διακομιστή με πλήρη εικονικοποίηση KVM τουλάχιστον μία φορά στη ζωή του, έχει αντιμετωπίσει ορισμένα προβλήματα:

• Οι περισσότερες πληροφορίες είναι απλώς ξεπερασμένες και αφορούσαν λειτουργικά συστήματα που είχαν περάσει από καιρό τον κύκλο EOL
• Διαφορετικές πληροφορίες παρέχονται πάντα για διαφορετικά λειτουργικά συστήματα και τα πιθανά σφάλματα κατά τη μετεγκατάσταση δεν λαμβάνονται ποτέ υπόψη
• Μερικές φορές πρέπει να αντιμετωπίσετε διαμορφώσεις που κάθε τόσο δεν θέλουν να λειτουργούν μετά τη μετεγκατάσταση

Όταν μεταφέρετε 1 διακομιστή, μπορείτε πάντα να διορθώσετε κάτι εν κινήσει, αλλά όταν μεταφέρετε ένα ολόκληρο σύμπλεγμα;

Σε αυτό το άρθρο θα προσπαθήσω να σας πω πώς να μετεγκαταστήσετε σωστά ένα κοντέινερ OpenVZ στο KVM με ελάχιστο χρόνο διακοπής λειτουργίας και μια γρήγορη λύση σε όλα τα προβλήματα.

Ένα μικρό εκπαιδευτικό πρόγραμμα: τι είναι το OpenVZ και τι το KVM;

Δεν θα εμβαθύνουμε στην ορολογία, αλλά θα πούμε γενικά:

OpenVZ — εικονικοποίηση σε επίπεδο λειτουργικού συστήματος, μπορείτε να την αναπτύξετε ακόμη και σε φούρνο μικροκυμάτων, καθώς δεν χρειάζονται οδηγίες CPU και τεχνολογίες εικονικοποίησης στον κεντρικό υπολογιστή.

KVM - Πλήρης εικονικοποίηση, που χρησιμοποιεί όλη τη δύναμη της CPU και μπορεί να εικονικοποιήσει οτιδήποτε, με οποιονδήποτε τρόπο, κόβοντάς το κατά μήκος και σταυρωτά.

Σε αντίθεση με τη δημοφιλή πεποίθηση ότι μεταξύ των παρόχων φιλοξενίας το OpenVZ θα γίνει υπερπουλημένο, αλλά το KVM δεν θα γίνει - ευτυχώς για το τελευταίο, το KVM είναι πλέον υπερπουλημένο όχι χειρότερα από τον αδελφό του.

Τι θα μεταφέρουμε;

Ως υποκείμενα δοκιμής για τη μεταφορά, έπρεπε να χρησιμοποιήσουμε ολόκληρο το δάσος των λειτουργικών συστημάτων που είναι διαθέσιμα στο OpenVZ: CentOS (εκδόσεις 6 και 7), Ubuntu (14, 16 και 18 LTS), Debian 7.

Θεωρήθηκε ότι τα περισσότερα από τα κοντέινερ OpenVZ εκτελούσαν ήδη κάποιο είδος LAMP και μερικά είχαν ακόμη και κάποιο πολύ συγκεκριμένο λογισμικό. Τις περισσότερες φορές, αυτές ήταν διαμορφώσεις με τον πίνακα ελέγχου ISPmanager, VestaCP (και τις περισσότερες φορές δεν ενημερώθηκαν για χρόνια). Πρέπει επίσης να ληφθούν υπόψη τα αιτήματα μεταφοράς τους.

Η μετεγκατάσταση πραγματοποιείται ενώ διατηρείται η διεύθυνση IP του μεταφερόμενου κοντέινερ· θα υποθέσουμε ότι η IP που είχε το κοντέινερ είναι αποθηκευμένη στο VM και θα λειτουργεί χωρίς προβλήματα.

Πριν από τη μεταφορά, ας βεβαιωθούμε ότι έχουμε τα πάντα στη διάθεσή σας:

• Διακομιστής OpenVZ, πλήρης πρόσβαση root στον κεντρικό υπολογιστή, δυνατότητα διακοπής/προσάρτησης/εκκίνησης/διαγραφής κοντέινερ
• Διακομιστής KVM, πλήρης πρόσβαση root στον κεντρικό υπολογιστή, με ό,τι συνεπάγεται. Υποτίθεται ότι όλα είναι ήδη ρυθμισμένα και έτοιμα για χρήση.

Ας ξεκινήσουμε τη μεταφορά

Πριν ξεκινήσουμε τη μεταφορά, ας ορίσουμε όρους που θα σας βοηθήσουν να αποφύγετε τη σύγχυση:

KVM_NODE - Μηχάνημα υποδοχής KVM
VZ_NODE - Μηχανή υποδοχής OpenVZ
CTID - Δοχείο OpenVZ
VM - Εικονικός διακομιστής KVM

Προετοιμασία για μετανάστευση και δημιουργία εικονικών μηχανών.

Βήμα 1

Εφόσον πρέπει να μετακινήσουμε το κοντέινερ κάπου, θα δημιουργήσουμε VM με παρόμοια διαμόρφωση με KVM_NODE.
Σημαντικό! Πρέπει να δημιουργήσετε ένα VM στο λειτουργικό σύστημα που εκτελείται αυτήν τη στιγμή σε CTID. Για παράδειγμα, εάν το Ubuntu 14 είναι εγκατεστημένο στο CTID, τότε το Ubuntu 14 πρέπει να εγκατασταθεί στο VM. Οι δευτερεύουσες εκδόσεις δεν είναι σημαντικές και η ασυμφωνία τους δεν είναι τόσο σημαντική, αλλά οι κύριες εκδόσεις θα πρέπει να είναι οι ίδιες.

Μετά τη δημιουργία του VM, θα ενημερώσουμε τα πακέτα στο CTID και στο VM (δεν πρέπει να συγχέεται με την ενημέρωση του λειτουργικού συστήματος - δεν το ενημερώνουμε, ενημερώνουμε μόνο τα πακέτα και, εάν φτάσει, την έκδοση του λειτουργικού συστήματος εντός του κύριου εκδοχή).

Για το CentOS αυτή η διαδικασία φαίνεται ακίνδυνη:

# yum clean all
# yum update -y

Και όχι λιγότερο ακίνδυνο για το Ubuntu και το Debian:

# apt-get update
# apt-get upgrade

Βήμα 2

Εγκατάσταση σε CTID, VZ_NODE и VM χρησιμότητα rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

Δεν εγκαθιστούμε τίποτα άλλο ούτε εκεί ούτε εκεί.

Βήμα 3

Κάνουμε μια στάση CTID επί VZ_NODE ομάδα

vzctl stop CTID

Τοποθέτηση της εικόνας CTID:

vzctl mount CTID

Μεταβείτε στο φάκελο /vz/root/CTID και να εκτελέσει

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

Κάτω από τη ρίζα, δημιουργήστε ένα αρχείο /root/exclude.txt - θα περιέχει μια λίστα εξαιρέσεων που δεν θα μεταβούν στον νέο διακομιστή

/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

Σύνδεση με KVM_NODE και λανσάρουμε το δικό μας VMώστε να λειτουργεί και να είναι προσβάσιμο μέσω του δικτύου.

Τώρα όλα είναι έτοιμα για μεταγραφή. Πηγαίνω!

Βήμα 4

Ακόμα κάτω από το ξόρκι, παίζουμε

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

Η εντολή rsync θα εκτελέσει τη μεταφορά, ελπίζουμε ότι τα κλειδιά είναι καθαρά - η μεταφορά πραγματοποιείται με τη διατήρηση των συμβολικών συνδέσμων, των δικαιωμάτων πρόσβασης, των κατόχων και των ομάδων και η κρυπτογράφηση είναι απενεργοποιημένη για μεγαλύτερη ταχύτητα (μπορείτε να χρησιμοποιήσετε κάποιο πιο γρήγορο κρυπτογράφηση, αλλά αυτό δεν είναι τόσο σημαντικό για αυτήν την εργασία), καθώς και η συμπίεση είναι απενεργοποιημένη.

Μετά την ολοκλήρωση του rsync, βγείτε από το chroot (πατώντας ctrl+d) και εκτελέστε

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

Βήμα 5

Ας εκτελέσουμε πολλά βήματα που θα μας βοηθήσουν να εκκινήσουμε το VM μετά τη μεταφορά από το OpenVZ.
Σε διακομιστές με Σύστημα ας εκτελέσουμε μια εντολή που θα μας βοηθήσει να συνδεθούμε σε μια κανονική κονσόλα, για παράδειγμα, μέσω μιας οθόνης διακομιστή VNC

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

Σε διακομιστές 6 CentOS и 7 CentOS Φροντίστε να εγκαταστήσετε έναν νέο πυρήνα:

yum install kernel-$(uname -r)

Ο διακομιστής μπορεί να φορτωθεί από αυτόν, αλλά μετά τη μεταφορά μπορεί να σταματήσει να λειτουργεί ή να διαγραφεί.

Σε διακομιστή 7 CentOS πρέπει να εφαρμόσετε μια μικρή επιδιόρθωση για το PolkitD, διαφορετικά ο διακομιστής θα διακοπεί για πάντα:

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

Σε όλους τους διακομιστές, εάν έχει εγκατασταθεί το mod_fcgid για Apache, θα εκτελέσουμε μια μικρή επιδιόρθωση με δικαιώματα, διαφορετικά οι ιστότοποι που χρησιμοποιούν mod_fcgid θα διακοπούν με σφάλμα 500:

chmod +s `which suexec` && apachectl restart

Και το τελευταίο πράγμα είναι χρήσιμο για διανομές Ubuntu και Debian. Αυτό το λειτουργικό σύστημα μπορεί να καταρρεύσει σε μια αιώνια εκκίνηση με ένα σφάλμα

βρόχο πολύ γρήγορα. λιγο επιβλητική εκτέλεση

δυσάρεστο, αλλά διορθώνεται εύκολα, ανάλογα με την έκδοση του λειτουργικού συστήματος.

Επί Debian 9 η επιδιόρθωση μοιάζει με αυτό:

πραγματοποιούμε

dbus-uuidgen

αν λάβουμε σφάλμα

/usr/local/lib/libdbus-1.so.3: η έκδοση `LIBDBUS_PRIVATE_1.10.8′ δεν βρέθηκε

ελέγξτε την παρουσία του 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

αν όλα είναι εντάξει, το κάνουμε

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

Εάν δεν σας βοηθήσει, δοκιμάστε τη δεύτερη επιλογή.

Η δεύτερη λύση στο πρόβλημα με λιγο επιβλητική εκτέλεση Κατάλληλο για όλες σχεδόν τις διανομές Ubuntu και Debian.

πραγματοποιούμε

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

Και για Ubuntu 14, Debian 7 Επιπλέον εκτελούμε:

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

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

Τι καναμε? Αποκαταστήσαμε το messagebus, το οποίο έλειπε για την εκτέλεση του Debian/Ubuntu, και αφαιρέσαμε το modules_dep, το οποίο προερχόταν από το OpenVZ και παρενέβαινε στη φόρτωση πολλών λειτουργικών μονάδων πυρήνα.

Βήμα 6

Κάνουμε επανεκκίνηση του VM, ελέγχουμε στο VNC πώς εξελίσσεται η φόρτωση και, ιδανικά, όλα θα φορτωθούν χωρίς προβλήματα. Αν και είναι πιθανό να εμφανιστούν ορισμένα συγκεκριμένα προβλήματα μετά τη μετεγκατάσταση, αυτά δεν εμπίπτουν στο πεδίο εφαρμογής αυτού του άρθρου και θα διορθωθούν όταν προκύψουν.

Ελπίζω αυτές οι πληροφορίες να είναι χρήσιμες! 🙂

Πηγή: www.habr.com