So implementieren Sie die Online-Hot-Migration von virtuellen KVM-Maschinen (Bild und Text)

1. Migrationsmethode für virtuelle KVM-Maschinen und zu beachtende Probleme

Es gibt zwei Möglichkeiten, virtuelle KVM-Maschinen zu migrieren:
1. Statische Migration (Kaltmigration): Bei der Kaltmigration kopieren Sie bei ausgeschalteter virtueller Maschine die Festplattendatei und die XML-Konfigurationsdatei der virtuellen Maschine (diese beiden Dateien bilden eine virtuelle Maschine) auf den zu migrierenden Zielhost und verwenden dann den Befehl „virsh define *.xml“ auf dem Zielhost, um die virtuelle Maschine neu zu definieren.
2. Dynamische Migration (Hot Migration): Hot Migration wird häufiger verwendet. Normalerweise laufen auf diesem Server einige Dienste, die nicht unterbrochen werden dürfen, sodass eine Hot Migration erforderlich ist. In diesem Blogbeitrag werden die Schritte der Hot Migration ausführlich beschrieben.

1. Kalte Migration

Normalerweise ist das Verzeichnis, in dem wir die Festplatten virtueller Maschinen speichern, auf einer Festplatte mit einem NFS-Dateisystem gemountet, und diese Festplatte ist normalerweise ein LVM-Dateisystem. Wenn eine Kaltmigration erforderlich ist, mounten Sie daher einfach das NFS-Dateisystem auf dem Zielhost. Sie können dann die Festplattendatei der zu migrierenden virtuellen Maschine sehen, die normalerweise mit .qcow2 oder .raw endet. Senden Sie dann einfach die XML-Konfigurationsdatei der virtuellen Maschine an den Zielserver und definieren Sie sie neu. Sie können die migrierte virtuelle Maschine über den Befehl „virsh list --all“ anzeigen.

2. Heiße Migration

Wenn der Quellhost und der Zielhost ein Speichersystem gemeinsam nutzen, müssen lediglich der vCPU-Ausführungsstatus, der Speicherinhalt und die Gerätezustände der virtuellen Maschine des Clients über das Netzwerk an den Zielhost gesendet werden. Andernfalls muss der Festplattenspeicher des Clients an den Zielhost gesendet werden. Ein gemeinsam genutztes Speichersystem bedeutet, dass sich die Image-Dateiverzeichnisse der Quell- und Ziel-VMs auf einem gemeinsam genutzten Speicher befinden.

Der spezifische Prozess der dynamischen KVM-Migration läuft auf Basis eines gemeinsam genutzten Speichersystems wie folgt ab:

1. Wenn die Migration beginnt, läuft der Client noch auf dem Host und gleichzeitig werden die Speicherseiten des Clients auf den Zielhost übertragen.
2. QEMU/KVM überwacht und zeichnet während des Migrationsprozesses alle Änderungen an allen übertragenen internen Seiten auf und beginnt mit der Übertragung der Änderungen an den Speicherseiten im vorherigen Prozess, nachdem alle Speicherseiten übertragen wurden.
3. QEMU/KVM schätzt die Übertragungsgeschwindigkeit während des Migrationsprozesses. Wenn die verbleibenden Speicherdaten innerhalb eines einstellbaren Zeitraums (standardmäßig 30 Millisekunden) übertragen werden können, fährt QEMU/KVM den Client auf dem Quellhost herunter und überträgt die verbleibenden Daten auf den Zielhost. Schließlich stellt der übertragene Speicherinhalt den Betriebsstatus des Clients auf dem Zielhost wieder her.
4. An diesem Punkt ist der dynamische Migrationsvorgang von KVM abgeschlossen. Der migrierte Client ist so konsistent wie möglich mit dem Client vor der Migration, es sei denn, auf dem Zielhost fehlen einige Konfigurationen, z. B. eine Bridge. Beachten Sie, dass der dynamische Migrationsprozess nicht abgeschlossen werden kann und nur eine statische Migration durchgeführt werden kann, wenn die Speichernutzung im Client sehr hoch ist und häufig geändert wird und die Geschwindigkeit, mit der die Daten im Speicher ständig geändert werden, schneller ist als die Speichergeschwindigkeit, die KVM übertragen kann.

3. Überlegungen zur Migration

Unabhängig davon, ob es sich um eine Kaltmigration oder eine Heißmigration handelt, sind die Vorsichtsmaßnahmen größtenteils ähnlich.

Die Anforderungen an den Zielserver vor der Migration lauten wie folgt:

• Am besten migrieren Sie Server mit derselben CPU-Marke.
• 64-Bit kann nur zwischen 64-Bit-Hosts migriert werden und 32-Bit kann zwischen 32-Bit- und 64-Bit-Hosts migriert werden.
• Die Namen der virtuellen Maschinen im Hostcomputer dürfen nicht in Konflikt geraten.
• Der Zielhost und der Quellhost verfügen soweit wie möglich über die gleiche Softwarekonfiguration, z. B. über die gleiche Bridge-Netzwerkkarte, den gleichen Ressourcenpool usw.
• Die Einstellungen von cat /proc/cpuinfo |grep nx auf den beiden migrierten Hosts sind gleich. NX, dessen vollständiger Name „No eXecute“ lautet, bedeutet „kein eXecute“. Es handelt sich um eine auf die CPU angewendete Technologie, um den Speicherbereich in Bereiche zum Speichern nur von Prozessorbefehlssätzen oder nur von Daten zu unterteilen. Jeder Speicher, der NX-Technologie verwendet, wird als Nur-Daten-Speicher dargestellt, sodass der Befehlssatz des Prozessors nicht in diesen Bereichen gespeichert werden kann. Diese Technologie kann die meisten Pufferüberläufe verhindern, das heißt, einige Schadprogramme platzieren ihre eigenen bösartigen Befehlssätze im Datenspeicherbereich anderer Programme und führen diese aus, wodurch sie die Kontrolle über den gesamten Computer erlangen.

Zusammenfassung:

1. Statische Migration

• Kopieren Sie die Image-Datei und die Konfigurationsdatei der virtuellen Maschine.
• Definieren Sie diese virtuelle Maschine neu.

2. Dynamische Migration

• Gemeinsam genutzten Speicher erstellen;
• Mounten Sie den gemeinsam genutzten Speicher auf beiden Maschinen (manuell; verwenden Sie den Ressourcenpool).
• Starten Sie die dynamische Migration.
• Erstellen Sie eine Konfigurationsdatei für die migrierte virtuelle Maschine.
• Definieren Sie die virtuelle Maschine neu.

2. Beispiel für die Hot-Migration einer virtuellen KVM-Maschine

1. Umweltvorbereitung:

Meine Umgebung sieht hier wie folgt aus:

Drei Linux-Server, davon zwei KVM-Server, mit den IP-Adressen 192.168.20.2 und 192.168.20.3. Einer ist ein NFS-Server mit der IP-Adresse 192.168.20.4, der für den gemeinsamen Speicher verwendet wird (die drei Server müssen sich gegenseitig anpingen können).
Beide virtuellen KVM-Maschinen müssen über eine KVM-Umgebung verfügen.

Ich habe eine fertige KVM-Umgebung, deshalb werde ich sie hier nicht zeigen. Wenn Sie keine KVM-Umgebung haben, können Sie den Blog-Beitrag „Grundlegende Verwaltung der KVM-Virtualisierung“ lesen, um sie einzurichten (es ist ganz einfach, installieren Sie einfach einige Pakete mit yum und starten Sie den Dienst „libvirtd“. Möglicherweise müssen Sie den Server neu starten).

2. Konfigurieren Sie den gemeinsam genutzten NFS-Speicher

Der NFS-Server 192.168.20.4 ist wie folgt konfiguriert:

[root@nfs ~]# yum -y install nfs-utils rpcbind #Installieren Sie die erforderlichen Softwarepakete[root@localhost ~]# systemctl enable nfs #Stellen Sie NFS so ein, dass es automatisch startet[root@localhost ~]# systemctl enable rpcbind #Stellen Sie rpcbind so ein, dass es automatisch startet[root@nfs ~]# mkdir -p /nfsshare #Erstellen Sie ein gemeinsam zu nutzendes Verzeichnis[root@nfs ~]# vim /etc/exports #Bearbeiten Sie die NFS-Konfigurationsdatei, die Standardeinstellung ist empty/nfsshare *(rw,sync,no_root_squash)
#Die erste Spalte stellt das freigegebene Verzeichnis dar. #Das Sternchen in der zweiten Spalte bedeutet, dass der gesamte Netzwerkzugriff erlaubt ist.
#rw steht für Lese- und Schreibberechtigungen; sync steht für synchrones Schreiben auf die Festplatte;
#no_root_squash bedeutet, dass dem aktuellen Client lokale Root-Berechtigungen erteilt werden, wenn er als Root aufruft # (der Standardwert ist root_squash, was als nfsnobody-Benutzer behandelt wird). Wenn no_root_squash hinzugefügt wird,
#Dies kann zu einer Herabstufung Ihrer Berechtigungen führen und das Lesen und Schreiben (wr) unmöglich machen.
[root@nfs ~]# systemctl restart rpcbind #Dienst starten[root@nfs ~]# systemctl restart nfs #Dienst starten[root@nfs ~]# netstat -anpt | grep rpc #Bestätigen, dass der Dienst gestartet wurde[root@nfs ~]# showmount -e #Freigegebenes Verzeichnis dieser Maschine anzeigenListe für NFS exportieren:
/nfsshare *
[root@nfs ~]# Firewall-cmd --add-service=rpc-bind --permanent 
[root@nfs ~]# Firewall-cmd --add-service=nfs --permanent 
[root@nfs ~]# Firewall-cmd --add-service=mountd --permanent 
[root@nfs ~]# systemctl restart firewalld #Starten Sie die Firewall neu, damit die Konfiguration wirksam wird

Die NFS-Serverkonfiguration ist jetzt abgeschlossen! ! !

Der Migrationsvorgang basiert hier auf der grafischen Desktopumgebung. Wenn Sie die Befehlsmigration verwenden müssen, können Sie dieses Dokument als Referenz herunterladen. Ich habe die Verwendung der Befehlsmigration nicht untersucht.

Die beiden KVM-Server sind wie folgt konfiguriert (beide KVM-Hosts müssen wie folgt konfiguriert werden):

1. Installieren Sie das Softwarepaket rpcbind und starten Sie den rpcbind-Dienst. Um das Abfragetool showmount zu verwenden, installieren Sie auch nfs-utils:

[root@localhost ~]# yum -y installiere nfs-utils rpcbind 
[root@localhost ~]# systemctl aktiviere rpcbind
[root@localhost ~]# systemctl start rpcbind
[root@kvm ~]# showmount -e 192.168.20.4 #Abfrage des vom NFS-Server freigegebenen Verzeichnisses Exportliste für 192.168.20.4:
/nfsshare *
[root@kvm ~]# mount -t nfs 192.168.20.4:/nfsshare /kvm/disk/ #Mount [root@kvm ~]# df -hT /kvm/disk/
Dateisystemtyp Kapazität Verwendet Verfügbar Verwendet % Einhängepunkt 192.168.20.4:/nfsshare nfs4 50G 33M 50G 1 % /kvm/disk
#Schreiben Sie eine Testdatei auf einen der Server, um zu sehen, ob sie auf anderen Servern angezeigt wird [root@kvm1 ~]# touch /kvm/disk/test #Erstellen Sie eine Testdatei auf einem der KVM-Server [root@kvm2 ~]# ls /kvm/disk #Stellen Sie sicher, dass der Test auch im Verzeichnis des zweiten KVM-Servers angezeigt wird

An dieser Stelle wird darauf geachtet, dass die von den beiden KVM-Servern verwendeten Verzeichnisse auf derselben Platte gespeichert sind (Hinweis: Die Verzeichnispfade zum Mounten des NFS-Dateisystems der beiden KVM-VMs müssen konsistent sein. Dabei werden beide KVM-VMs in das Verzeichnis /kvm/disk/ gemountet, da es sonst bei nachfolgenden Operationen zu Fehlern kommt).

3. Erstellen Sie Speichervolumes auf zwei KVM-Servern:

[root@kvm1 ~]# virt-manager #Öffnen Sie die Konsole der virtuellen Maschine 

Im folgenden Dialogfeld ist der Zielpfad „/kvm/disk“ der KVM-Maschine, der Hostname ist die IP-Adresse des NFS-Servers und der Quellpfad ist das vom NFS-Server freigegebene Verzeichnis.

Die oben genannten Vorgänge müssen auch auf dem zweiten KVM ausgeführt werden. Am besten definieren Sie denselben Speicherpoolnamen. Um unnötigen Ärger zu vermeiden.

3. Erstellen Sie eine neue virtuelle Maschine auf kvm1 für Migrationstests

:

Laden Sie selbst eine CentOS-ISO-Systemdatei hoch. Hier müssen Sie die zu installierende ISO-Datei angeben:

An diesem Punkt können Sie die virtuelle Maschine normal installieren.

4. Konfigurieren Sie das neu erstellte virtuelle Maschinennetzwerk im Bridge-Modus, und Sie können das externe Netzwerk anpingen

Die folgenden Vorgänge dienen hauptsächlich dazu, die Hot-Migration virtueller Maschinen bei der Bereitstellung von Diensten für Benutzer öffentlicher Netzwerke zu simulieren.

1) Die Vorgänge von kvm1 sind wie folgt:

[root@kvm ~]# systemctl stop NetworkManager #Stoppen Sie diesen Dienst[root@kvm ~]# virsh iface-bridge ens33 br0 #Wenn beim Ausführen dieses Befehls die folgende Meldung angezeigt wird, machen Sie sich keine Sorgen, da sie bereits vorhanden ist. Verwenden Sie das zusätzliche Gerät br0, um die Brücke ens33 zu generieren. Die Brückenschnittstelle br0 konnte nicht gestartet werden
[root@kvm ~]# ls /etc/sysconfig/network-scripts/ | grep br0  
ifcfg-br0 #Stellen Sie sicher, dass diese Datei vorhanden ist[root@kvm ~]# virsh destroy centos7.0 #Schließen Sie die neu erstellte Domäne der virtuellen Maschine centos7.0 wird gelöscht[root@kvm ~]# virsh edit centos7.0 #Bearbeiten Sie die Konfigurationsdatei der virtuellen Maschine und suchen Sie die Schnittstelle
<interface type='bridge'> #Ändern Sie dies in bridge
 <mac address='52:54:00:a9:cc:5f'/> #Löschen Sie die Mac-Adresszeile <source bridge='br0'/> #Ändern Sie dies wie folgt #Speichern und beenden [root@kvm1 ~]# virsh start centos7.0 
Domäne centos7.0 wurde gestartet

Konfigurieren Sie nach dem Starten der virtuellen Maschine die Konfigurationsdatei der Netzwerkkarte der virtuellen Maschine. Die Standard-Netzwerkkartendatei ist ifcfg-eth0:

Starten Sie den Netzwerkdienst neu und bestätigen Sie die IP-Adresse:

Jetzt können Sie den Befehl „ping www.baidu.com“ auf der virtuellen Maschine ausführen, um ein kontinuierliches Pingen des öffentlichen Netzwerks zu ermöglichen.

2) Der KVM2-Betrieb läuft wie folgt ab:

[root@kvm ~]# systemctl stop NetworkManager #Stoppen Sie diesen Dienst[root@kvm ~]# virsh iface-bridge ens33 br0 #Wenn beim Ausführen dieses Befehls die folgende Meldung angezeigt wird, machen Sie sich keine Sorgen, da sie bereits vorhanden ist. Verwenden Sie das zusätzliche Gerät br0, um die Brücke ens33 zu generieren. Die Brückenschnittstelle br0 konnte nicht gestartet werden
[root@kvm ~]# ls /etc/sysconfig/network-scripts/ | grep br0  
ifcfg-br0 #Stellen Sie sicher, dass diese Datei vorhanden ist. #Da kvm2 keine virtuelle Maschine hat, müssen Sie das Netzwerk nur in den Bridge-Modus ändern.
#Die obige Konfiguration soll verhindern, dass die virtuelle Maschine nach der Migration auf diesen Server nicht mehr mit dem öffentlichen Netzwerk kommunizieren kann.

5. Beginnen Sie mit der Vorbereitung der Hot-Migration des neu erstellten CentOS 7

1) Führen Sie die folgenden Vorgänge auf dem KVM1-Server aus:

[root@kvm1 ~]# virt-manager #Öffnen Sie die Konsole der virtuellen Maschine 

Füllen Sie das Formular wie folgt aus und klicken Sie nach Abschluss auf „Verbinden“:

Sie werden aufgefordert, die folgenden Softwarepakete zu installieren:

So installieren Sie:

[root@kvm1 ~]# yum -y installiere openssh-askpass 

Geben Sie im angezeigten Dialogfeld „Ja“ ein:

Geben Sie das Root-Passwort des Zielhosts ein:

6. Starten Sie die Hot-Migration

Warten Sie, bis die Migration abgeschlossen ist. Der Vorgang ist schnell:

Migration abgeschlossen:

Gehen Sie nun zum Ziel-KVM-Server und öffnen Sie die neu migrierte virtuelle Maschine (Sie werden feststellen, dass der Ping-Befehl noch immer ausgeführt wird und nie unterbrochen wurde):

Sie können „virsh list --all“ auf den beiden KVM-Servern verwenden, um zu bestätigen, ob die virtuelle Maschine auf den zweiten KVM-Server migriert wurde.

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.