Live migration ενός KVM guest μαζί με το storage του, βήμα προς βήμα

Η μεταφορά μιας εικονικής μηχανής που τρέχει ανάμεσα σε hosts χωρίς κοινόχρηστο storage ακούγεται σαν μαγεία μέχρι να την κάνετε μερικές φορές. Μετά είναι checklist: επιβεβαιώνετε ότι οι hosts είναι συμβατοί, προετοιμάζετε τον προορισμό ώστε ο guest να βρει ό,τι περιμένει, τρέχετε μία εντολή, και ξέρετε πότε να μην το επιχειρήσετε. Εδώ είναι αυτή η checklist για σκέτο KVM με libvirt.

Τι συμβαίνει πραγματικά σε ένα live migration

Με --copy-storage-all, το libvirt ζητά από το QEMU στον προορισμό να δημιουργήσει τον guest, και μετά μεταδίδει τον δίσκο ενώ ο guest συνεχίζει να τρέχει και να γράφει. Μόλις ο δίσκος γίνει mirror, η μνήμη αντιγράφεται σε γύρους: κάθε γύρος στέλνει τις σελίδες που ο guest λέρωσε κατά τον προηγούμενο. Όταν το υπόλοιπο σύνολο λερωμένων σελίδων είναι αρκετά μικρό για να σταλεί μέσα στο επιτρεπόμενο downtime, ο guest παύει, οι τελευταίες σελίδες και η κατάσταση συσκευών περνούν απέναντι, και συνεχίζει στον προορισμό. Η παύση είναι συνήθως λίγες εκατοντάδες χιλιοστά του δευτερολέπτου. Οι συνδέσεις δικτύου επιβιώνουν επειδή ο guest κρατά τη MAC και την IP διεύθυνσή του, και το switch μαθαίνει τη νέα θέση από τα πρώτα πακέτα του guest.

Όλα όσα μπορούν να πάνε στραβά είναι αναντιστοιχία ανάμεσα σε ό,τι περιμένει ο guest και σε ό,τι προσφέρει ο προορισμός. Οπότε ελέγξτε πρώτα αυτά.

Βήμα πρώτο: αποφασίστε live ή cold

Το live migration είναι το σωστό εργαλείο όταν πηγή και προορισμός είναι συμβατοί και ο ρυθμός εγγραφής του guest είναι μέτριος. Είναι το λάθος εργαλείο όταν όλα αλλάζουν μονομιάς: διαφορετική γενιά CPU, διαφορετική διάταξη δικτύου και διαφορετική έκδοση hypervisor στην ίδια μεταφορά. Τότε η ασφαλής διαδρομή είναι η cold: κλείνετε καθαρά τον guest, αντιγράφετε τον δίσκο, τον ορίζετε στον στόχο, τον ξεκινάτε, και κρατάτε την πηγή ανέγγιχτη ως rollback.

Ένα primary βάσης δεδομένων με πολύ υψηλό ρυθμό λερώματος σελίδων μπορεί επίσης να μη συγκλίνει ποτέ. Μετρήστε πριν δοκιμάσετε:

virsh domdirtyrate-calc <guest> --seconds 5
virsh domstats <guest> --dirtyrate

Βήμα δεύτερο: ελέγξτε τη συμβατότητα CPU

Το μοντέλο CPU του guest πρέπει να υπάρχει στον προορισμό. Αν ο guest χρησιμοποιεί host-passthrough, οι CPU των δύο hosts πρέπει ουσιαστικά να ταιριάζουν. Συγκρίνετε τον ορισμό του guest με τον host προορισμού:

virsh dumpxml <guest> > guest.xml                       # on the source
xmllint --xpath '//cpu' guest.xml > guest-cpu.xml
virsh hypervisor-cpu-compare guest-cpu.xml              # on the destination

identical ή superset σημαίνει προχωράτε. incompatible σημαίνει είτε αλλάζετε τον guest σε ένα επώνυμο μοντέλο CPU που υποστηρίζουν και οι δύο hosts (στην επόμενη επανεκκίνησή του) είτε τον μεταφέρετε cold.

Βήμα τρίτο: προετοιμάστε το δίκτυο του προορισμού

Κάθε bridge, ή VLAN πάνω σε bridge, στο οποίο συνδέονται οι διεπαφές του guest πρέπει να υπάρχει στον προορισμό με το ίδιο όνομα, και πρέπει να μεταφέρει τα ίδια VLANs στο uplink:

virsh domiflist <guest>      # on the source: which bridges
ip -br link show type bridge # on the destination: do they exist?

Ένα bridge που λείπει αποτυγχάνει καθαρά το migration στην αρχή. Ένα bridge που υπάρχει αλλά κάθεται σε uplink χωρίς το VLAN κάνει migration επιτυχώς και αφήνει τον guest απρόσιτο, που είναι χειρότερο. Ελέγξτε και την πλευρά του switch.

Βήμα τέταρτο: προετοιμάστε το storage του προορισμού

Ο προορισμός χρειάζεται κάπου να προσγειωθεί ο δίσκος, σε μια διαδρομή που το libvirt διαχειρίζεται ως storage pool:

virsh pool-define-as images dir --target /var/lib/libvirt/images
virsh pool-start images && virsh pool-autostart images

Για τις περισσότερες διατάξεις το libvirt δημιουργεί μόνο του το image προορισμού. Για ασυνήθιστες, δημιουργήστε το εκ των προτέρων με ακριβώς το ίδιο εικονικό μέγεθος και format με την πηγή:

qemu-img info --output=json /var/lib/libvirt/images/<guest>.qcow2   # note virtual-size
qemu-img create -f qcow2 /var/lib/libvirt/images/<guest>.qcow2 <virtual-size>

Βήμα πέμπτο: migration

Από τον host πηγής, με πρόσβαση SSH με κλειδί στον προορισμό ως ο χρήστης του libvirt:

virsh migrate --live --persistent --undefinesource \
  --copy-storage-all --auto-converge --verbose \
  <guest> qemu+ssh://<destination>/system

• Το --live κρατά τον guest σε λειτουργία.
• Το --copy-storage-all κάνει mirror ολόκληρο τον δίσκο. (Υπάρχει το --copy-storage-inc για δίσκους των οποίων το βασικό image είναι ήδη στον προορισμό.)
• Το --auto-converge περιορίζει ελαφρά τη CPU του guest αν η μνήμη λερώνεται ταχύτερα από όσο μπορεί να σταλεί, ώστε και οι απασχολημένοι guests να τελειώνουν.
• Τα --persistent και --undefinesource μεταφέρουν τον ορισμό μαζί με τον guest, ώστε να μην ξαναεμφανιστεί στον παλιό host στην επόμενη επανεκκίνηση.

Χρησιμοποιούμε την απευθείας διαδρομή migration αντί για --tunnelled όταν αντιγράφεται storage. Όσο τρέχει, παρακολουθήστε την πρόοδο από ένα δεύτερο τερματικό:

virsh domjobinfo <guest>

Το domjobinfo δείχνει τα δεδομένα που απομένουν, τον ρυθμό λερώματος και το αναμενόμενο downtime. Αν προφανώς δεν συγκλίνει, το virsh domjobabort <guest> σταματά την εργασία και αφήνει τον guest να τρέχει στην πηγή, ανέγγιχτο.

Βήμα έκτο: επαληθεύστε στην άφιξη

Ελέγξτε, από έξω από τον guest:

virsh list --all                      # running on the destination only
virsh domblklist <guest>              # disk at the expected path
virsh domifaddr <guest> --source arp  # address visible on the network

Αν ο guest είναι load balancer ή replica βάσης δεδομένων, επιβεβαιώστε ότι έχει ξαναπάρει τον ρόλο του (κατάσταση VRRP, νήματα replication) αντί να το υποθέσετε.

Μόνο μετά από αυτό, αφαιρέστε το παλιό image δίσκου από την πηγή, ή καλύτερα, κρατήστε το μέχρι τον επόμενο κύκλο συντήρησης.

Η checklist σας

• Live ή cold αποφασισμένο συνειδητά, με τον ρυθμό λερώματος μετρημένο για απασχολημένους guests.
• Μοντέλο CPU συγκριμένο με τον host προορισμού.
• Κάθε bridge και VLAN παρόν στον προορισμό, συμπεριλαμβανομένων των uplinks του switch.
• Ένα storage pool στον προορισμό, αρκετός ελεύθερος χώρος, και προδημιουργημένο image όπου η διάταξη το χρειάζεται.
• Η εντολή migrate να τρέχει με αντιγραφή storage και auto converge, παρακολουθούμενη με domjobinfo.
• Ο guest επαληθευμένος από έξω, και το αντίγραφο της πηγής κρατημένο μέχρι να είστε σίγουροι.

Αν θέλετε να μεταφέρετε guests χωρίς να τους κατεβάσετε, ή χρειάζεστε έναν δρόμο έξω από τον τρέχοντα hypervisor σας, ευχαρίστως να βοηθήσουμε.

CTA

Μιλήστε με έναν μηχανικό

Related

Σχετικά: Live migration και έξοδος από hypervisor · Private cloud σε KVM με OLVM · Μεταφορά σε εμάς χωρίς αλλαγή διευθύνσεων: επέκταση Layer 2