Ich verwende in meinem Cluster(PVE 6.1) ein lokales Storage. So wie ich das beobachte, hat bei der Live-Migration vor allem das Lesen auf dem Quellsystem deutliche Performanceauswirkungen. Jede Livemigration erzeugt gleich eine deutlich bemerkbare I/O-Wait. Wenn das System ohnehin schon unter einer hohen Last steht, dann kann das kritisch werden.
Das ist ja nicht verwunderlich auf einem Festplattenstorage, was ja einen kontinuierlichen Wechsel der Festplatten-Schreib-/Leseköpfe zwischen der normalen aktuellen Arbeitslast und der sequentiellen Migrationslast bedeutet.
Das Schreiben hingegen ist kaum eine Belastung bei normaler asynchroner I/O. Es kommen regelmässig serialisierte Bursts, was den Betrieb auf dem Zielsystem nicht beeinträchtigt. Nur falls synchrone Schreibvorgänge da sind werden die evtl. ausgebremst.
Wenn ich nur die Migrationsgeschwindigkeit herunterstelle, dann löse ich zum Teil das Problem mit Lesebelastung am Quellsystem, bekomme aber gleichzeitig evtl. ein neues: Die Migration des RAM am Ende der Livemigration wird dann auch nur mit der eingestellten Geschwindigkeit durchgeführt. Ist die Geschwindigkeit sehr niedrig, dann besteht die Gefahr bei großer Arbeitspeichermenge oder sich sehr schnell ändernden Daten im Arbeitsspeicher, dass die Migration fehlschlägt, weil es mit dem niedrigen Limit nicht gelingt die Datenmenge zu bewältigen.
Dabei ist die RAM-Synchronisation in Bezug auf die Festplattenschreib- und -leseleistung ohne Bedeutung. Es wird ja nur aus dem RAM gelesen/in den RAM geschrieben und über das Netzwerk übertragen. D. h. da könnte man durchaus den Turbo einschalten um den RAM mit höherer Geschwindigkeit zu synchronisieren.
Natürlich könnte auch das Änderungvolumen der Daten auf der Festplatte zu groß sein, damit eine Synchronisation erfolgreich ist; aber das ist ja leider nicht zu ändern.
Der Vorschlag wäre also: Getrennte Geschwindigkeitseinstellungen für Storage- und RAM-Synchronisation
Sind meine Gedannkengänge hier schlüssig?
Meine Umgebung
* Proxmox 6.1
* Virtualisierungshosts mit ca. 6-12 Festplatten(keine SSDs)
* dediziertes Storage-Netzwerk
* Alle Netzwerkverbindungen: 1 GBit
* Heterogener CPU-Pool
* Storage: "directory" auf einem ZFS-Dateisytem
Das ist ja nicht verwunderlich auf einem Festplattenstorage, was ja einen kontinuierlichen Wechsel der Festplatten-Schreib-/Leseköpfe zwischen der normalen aktuellen Arbeitslast und der sequentiellen Migrationslast bedeutet.
Das Schreiben hingegen ist kaum eine Belastung bei normaler asynchroner I/O. Es kommen regelmässig serialisierte Bursts, was den Betrieb auf dem Zielsystem nicht beeinträchtigt. Nur falls synchrone Schreibvorgänge da sind werden die evtl. ausgebremst.
Wenn ich nur die Migrationsgeschwindigkeit herunterstelle, dann löse ich zum Teil das Problem mit Lesebelastung am Quellsystem, bekomme aber gleichzeitig evtl. ein neues: Die Migration des RAM am Ende der Livemigration wird dann auch nur mit der eingestellten Geschwindigkeit durchgeführt. Ist die Geschwindigkeit sehr niedrig, dann besteht die Gefahr bei großer Arbeitspeichermenge oder sich sehr schnell ändernden Daten im Arbeitsspeicher, dass die Migration fehlschlägt, weil es mit dem niedrigen Limit nicht gelingt die Datenmenge zu bewältigen.
Dabei ist die RAM-Synchronisation in Bezug auf die Festplattenschreib- und -leseleistung ohne Bedeutung. Es wird ja nur aus dem RAM gelesen/in den RAM geschrieben und über das Netzwerk übertragen. D. h. da könnte man durchaus den Turbo einschalten um den RAM mit höherer Geschwindigkeit zu synchronisieren.
Natürlich könnte auch das Änderungvolumen der Daten auf der Festplatte zu groß sein, damit eine Synchronisation erfolgreich ist; aber das ist ja leider nicht zu ändern.
Der Vorschlag wäre also: Getrennte Geschwindigkeitseinstellungen für Storage- und RAM-Synchronisation
Sind meine Gedannkengänge hier schlüssig?
Meine Umgebung
* Proxmox 6.1
* Virtualisierungshosts mit ca. 6-12 Festplatten(keine SSDs)
* dediziertes Storage-Netzwerk
* Alle Netzwerkverbindungen: 1 GBit
* Heterogener CPU-Pool
* Storage: "directory" auf einem ZFS-Dateisytem
Last edited:
