Virtualisierung Markus Gerstel Hauptseminar: Databases in the Cloud, SS 2009 Betreuer: Dipl. Inf. Alexander Stage Technische Universität München 5. Mai 2009
Vortragsinhalt 1 Einleitung: Virtualisierung Virtuelle Maschinen Virtualisierung - Möglichkeit, Notwendigkeit, Chance Grenzen der Virtualisierung: Hardwareabhängigkeit 2 Grundproblem: Verschieben einer laufenden VM Verschieben virtueller Hardware Hauptspeicher Hintergrundspeicher Netzwerk Zusammenfassung 3 Ausblick
Virtuelle Maschinen Virtuelle Maschinen seit Mitte der 60er: IBM 7044 (M44) simuliert virtuelle Maschinen des Typs IBM 7044 (44X) Virtuelle Maschinen auf Großrechnern gang und gäbe x86 galt allerdings bis 1999 als ineffizient bzw gar nicht virtualisierbar Hauptursache: Nicht alle Befehle sind abfangbar.
Virtualisierung - Möglichkeit VMWare virtualisiert kompletten x86 Rechner mit (in Grenzen) frei wählbarer Hardware und sinnvoller Geschwindigkeit. Xen für kooperative Gastsysteme dann: x86-erweiterungen Pacifica/Vanderpool für unkooperative Gastsysteme Konkurrenz unter Virtualisierungslösungen (Virtual PC) führte z.b. zu kostenlosem VMWare Server eventuell Windows XP VM in Windows 7
Virtualisierung - Möglichkeit VMWare virtualisiert kompletten x86 Rechner mit (in Grenzen) frei wählbarer Hardware und sinnvoller Geschwindigkeit. Xen für kooperative Gastsysteme dann: x86-erweiterungen Pacifica/Vanderpool für unkooperative Gastsysteme Konkurrenz unter Virtualisierungslösungen (Virtual PC) führte z.b. zu kostenlosem VMWare Server eventuell Windows XP VM in Windows 7
Virtualisierung - Notwendigkeit Prozessortechnologie: Einzelkerne werden nur langsam schneller, dafür aber mehr Kerne pro Computer. Anwendungssoftware nutzt oftmals nur einen Kern. Die Folge sind ungenutzte Resourcenvorräte. Gleichzeitig wirkt Kostendruck: Energie, Hardware, Administration und Leistungsdruck: Uptime, SLAs. Verträgliche Lastprofile könnten auf einer physikalischen Maschine kombiniert werden.
Virtualisierung - Notwendigkeit Prozessortechnologie: Einzelkerne werden nur langsam schneller, dafür aber mehr Kerne pro Computer. Anwendungssoftware nutzt oftmals nur einen Kern. Die Folge sind ungenutzte Resourcenvorräte. Gleichzeitig wirkt Kostendruck: Energie, Hardware, Administration und Leistungsdruck: Uptime, SLAs. Verträgliche Lastprofile könnten auf einer physikalischen Maschine kombiniert werden.
Virtualisierung - Chance Nicht zuletzt ermöglichen Virtuelle Maschinen neue Produkte: Vom einzelnen Virtual Root Server bis zu Amazon EC2.
Abhängigkeit von Hardware Virtuelle Maschinen hervorragend geeignet für Serverdienste Statische Zuordnung VM physikalische Maschine begrenzt Ausfallsicherheit Hardware kann ausfallsicherer gestaltet werden: RAID, Redundante Netzteile, ECC-RAM,... Aber: Hardwareprobleme führen zu Absturz der VM Bei Amazon EC2 sogar zum Totalverlust der VM!
Abhängigkeit von Hardware Virtuelle Maschinen hervorragend geeignet für Serverdienste Statische Zuordnung VM physikalische Maschine begrenzt Ausfallsicherheit Hardware kann ausfallsicherer gestaltet werden: RAID, Redundante Netzteile, ECC-RAM,... Aber: Hardwareprobleme führen zu Absturz der VM Bei Amazon EC2 sogar zum Totalverlust der VM!
Abhängigkeit von Hardware Virtuelle Maschinen hervorragend geeignet für Serverdienste Statische Zuordnung VM physikalische Maschine begrenzt Ausfallsicherheit Hardware kann ausfallsicherer gestaltet werden: RAID, Redundante Netzteile, ECC-RAM,... Aber: Hardwareprobleme führen zu Absturz der VM Bei Amazon EC2 sogar zum Totalverlust der VM!
Abhängigkeit von Hardware Virtuelle Maschinen hervorragend geeignet für Serverdienste Statische Zuordnung VM physikalische Maschine begrenzt Ausfallsicherheit Hardware kann ausfallsicherer gestaltet werden: RAID, Redundante Netzteile, ECC-RAM,... Aber: Hardwareprobleme führen zu Absturz der VM Bei Amazon EC2 sogar zum Totalverlust der VM!
Lösung von Hardware Eine der Grundideen der Virtualisierung ist Abstraktion Trennung der Bindung VM physikalische Maschine Idee: Nehme den vollständigen Kontext einer VM und mache diesen verschiebbar. Probleme: Virtuelle Hardwareabhängigkeiten (CPU, Speicher, Peripherie,..) Reale Hardwareabhängigkeiten (Netzwerk, USB-Geräte, SCSI-Geräte,..) Overhead
Lösung von Hardware Eine der Grundideen der Virtualisierung ist Abstraktion Trennung der Bindung VM physikalische Maschine Idee: Nehme den vollständigen Kontext einer VM und mache diesen verschiebbar. Probleme: Virtuelle Hardwareabhängigkeiten (CPU, Speicher, Peripherie,..) Reale Hardwareabhängigkeiten (Netzwerk, USB-Geräte, SCSI-Geräte,..) Overhead
Lösung von Hardware Eine der Grundideen der Virtualisierung ist Abstraktion Trennung der Bindung VM physikalische Maschine Idee: Nehme den vollständigen Kontext einer VM und mache diesen verschiebbar. Probleme: Virtuelle Hardwareabhängigkeiten (CPU, Speicher, Peripherie,..) Reale Hardwareabhängigkeiten (Netzwerk, USB-Geräte, SCSI-Geräte,..) Overhead
Beispiel: Xen-Architektur Kontroll-System Dom0 Gast-System DomU Gast-System DomU App Xen Verwaltungssoftware App App App App Betriebssystem Betriebssystem Treiber Betriebssystem Control Interface Safe Hardware Interface Event Channel Xen Virtual Machine Monitor Hardware Host-System CPU, Festplatten, Netzwerk,... Architektur eines Xen-Systems: Hypervisor/VMM stellt x86/xen-architektur zur Verfügung, auf die das Kontroll-Betriebssystem sowie die Gast-Systeme portiert wurden. aus: M. Gerstel. Virtualisierungsansätze mit Schwerpunkt Xen. Seminar Ansätze für Betriebssysteme der Zukunft, TU München, 2005.
Migration I: CPU, Virtuelle Peripherie CPU = Sammlung von Registern (u.a. Instruktionspointer) Virtuelle Geräte = einfache Datenstrukturen Maschine anhalten, Set kopieren, Maschine fortfahren = Fertig.
Migration I: CPU, Virtuelle Peripherie CPU = Sammlung von Registern (u.a. Instruktionspointer) Virtuelle Geräte = einfache Datenstrukturen Maschine anhalten, Set kopieren, Maschine fortfahren = Fertig.
Migration II: Hauptspeicher Hauptspeicher = Datenfeld Maschine anhalten, Feld kopieren, Maschine fortfahren = Fertig. Aber: 4 GB über 1000 Mbps ohne Overhead im Bestfall: 34 Sekunden. Problem: Externe Beobachter, z.b. offene TCP-Verbindungen
Migration II: Hauptspeicher Hauptspeicher = Datenfeld Maschine anhalten, Feld kopieren, Maschine fortfahren = Fertig. Aber: 4 GB über 1000 Mbps ohne Overhead im Bestfall: 34 Sekunden. Problem: Externe Beobachter, z.b. offene TCP-Verbindungen
Migration III: Hintergrundspeicher Optimistische Annahme dass von beiden Maschinen aus erreichbarer Hintergrundspeicher vorliegt (z.b. SAN oder multi-homed SCSI-RAID-Array) Erlaubt nur Verschiebung innerhalb des LAN. Alternativ: Verteilte Speicherstruktur (z.b. Amazon S3, Google), Replikation (Deutsche Bank)
Migration III: Hintergrundspeicher Optimistische Annahme dass von beiden Maschinen aus erreichbarer Hintergrundspeicher vorliegt (z.b. SAN oder multi-homed SCSI-RAID-Array) Erlaubt nur Verschiebung innerhalb des LAN. Alternativ: Verteilte Speicherstruktur (z.b. Amazon S3, Google), Replikation (Deutsche Bank)
Migration III: Hintergrundspeicher Optimistische Annahme dass von beiden Maschinen aus erreichbarer Hintergrundspeicher vorliegt (z.b. SAN oder multi-homed SCSI-RAID-Array) Erlaubt nur Verschiebung innerhalb des LAN. Alternativ: Verteilte Speicherstruktur (z.b. Amazon S3, Google), Replikation (Deutsche Bank)
Migration IV: Netzwerk Optimistische Annahme dass gemeinsamer Netzwerkbus vorliegt (also Anschluss in gleicher Broadcastdomäne) Dann lediglich ein ARP-Paket (oder VSRP) zum Umleiten des Netzwerktraffics notwendig Nur LAN-Verschiebung ist eine starke Einschränkung: Köln, Kalifornien, New Orleans, Nordirland, Schweden, USA,... Naturkatastrophen, Versorgungsprobleme, politische Instabilität betreffen ganze Rechenzentren
Migration IV: Netzwerk Optimistische Annahme dass gemeinsamer Netzwerkbus vorliegt (also Anschluss in gleicher Broadcastdomäne) Dann lediglich ein ARP-Paket (oder VSRP) zum Umleiten des Netzwerktraffics notwendig Nur LAN-Verschiebung ist eine starke Einschränkung: Köln, Kalifornien, New Orleans, Nordirland, Schweden, USA,... Naturkatastrophen, Versorgungsprobleme, politische Instabilität betreffen ganze Rechenzentren
Migration IV: Netzwerk Optimistische Annahme dass gemeinsamer Netzwerkbus vorliegt (also Anschluss in gleicher Broadcastdomäne) Dann lediglich ein ARP-Paket (oder VSRP) zum Umleiten des Netzwerktraffics notwendig Nur LAN-Verschiebung ist eine starke Einschränkung: Köln, Kalifornien, New Orleans, Nordirland, Schweden, USA,... Naturkatastrophen, Versorgungsprobleme, politische Instabilität betreffen ganze Rechenzentren
Migration IV: Netzwerk Optimistische Annahme dass gemeinsamer Netzwerkbus vorliegt (also Anschluss in gleicher Broadcastdomäne) Dann lediglich ein ARP-Paket (oder VSRP) zum Umleiten des Netzwerktraffics notwendig Nur LAN-Verschiebung ist eine starke Einschränkung: Köln, Kalifornien, New Orleans, Nordirland, Schweden, USA,... Naturkatastrophen, Versorgungsprobleme, politische Instabilität betreffen ganze Rechenzentren
Migration IV: Netzwerk Optimistische Annahme dass gemeinsamer Netzwerkbus vorliegt (also Anschluss in gleicher Broadcastdomäne) Dann lediglich ein ARP-Paket (oder VSRP) zum Umleiten des Netzwerktraffics notwendig Nur LAN-Verschiebung ist eine starke Einschränkung: Köln, Kalifornien, New Orleans, Nordirland, Schweden, USA,... Naturkatastrophen, Versorgungsprobleme, politische Instabilität betreffen ganze Rechenzentren
Migration IV: Netzwerk Optimistische Annahme dass gemeinsamer Netzwerkbus vorliegt (also Anschluss in gleicher Broadcastdomäne) Dann lediglich ein ARP-Paket (oder VSRP) zum Umleiten des Netzwerktraffics notwendig Nur LAN-Verschiebung ist eine starke Einschränkung: Köln, Kalifornien, New Orleans, Nordirland, Schweden, USA,... Naturkatastrophen, Versorgungsprobleme, politische Instabilität betreffen ganze Rechenzentren
Migration IV: Netzwerk Optimistische Annahme dass gemeinsamer Netzwerkbus vorliegt (also Anschluss in gleicher Broadcastdomäne) Dann lediglich ein ARP-Paket (oder VSRP) zum Umleiten des Netzwerktraffics notwendig Nur LAN-Verschiebung ist eine starke Einschränkung: Köln, Kalifornien, New Orleans, Nordirland, Schweden, USA,... Naturkatastrophen, Versorgungsprobleme, politische Instabilität betreffen ganze Rechenzentren
Migration IV: Netzwerk Optimistische Annahme dass gemeinsamer Netzwerkbus vorliegt (also Anschluss in gleicher Broadcastdomäne) Dann lediglich ein ARP-Paket (oder VSRP) zum Umleiten des Netzwerktraffics notwendig Nur LAN-Verschiebung ist eine starke Einschränkung: Köln, Kalifornien, New Orleans, Nordirland, Schweden, USA,... Naturkatastrophen, Versorgungsprobleme, politische Instabilität betreffen ganze Rechenzentren
Migration IV: Netzwerk Optimistische Annahme dass gemeinsamer Netzwerkbus vorliegt (also Anschluss in gleicher Broadcastdomäne) Dann lediglich ein ARP-Paket (oder VSRP) zum Umleiten des Netzwerktraffics notwendig Nur LAN-Verschiebung ist eine starke Einschränkung: Köln, Kalifornien, New Orleans, Nordirland, Schweden, USA,... Naturkatastrophen, Versorgungsprobleme, politische Instabilität betreffen ganze Rechenzentren
Migration IV: Netzwerk Optimistische Annahme dass gemeinsamer Netzwerkbus vorliegt (also Anschluss in gleicher Broadcastdomäne) Dann lediglich ein ARP-Paket (oder VSRP) zum Umleiten des Netzwerktraffics notwendig Nur LAN-Verschiebung ist eine starke Einschränkung: Köln, Kalifornien, New Orleans, Nordirland, Schweden, USA,... Naturkatastrophen, Versorgungsprobleme, politische Instabilität betreffen ganze Rechenzentren
Hauptspeichermigration 1 Push phase 2 Stop-and-copy phase Downtime 3 Pull phase (Offensichtliche) Idee: Minimiere Downtime
Hauptspeichermigration 1 Push phase 2 Stop-and-copy phase Downtime 3 Pull phase (Offensichtliche) Idee: Minimiere Downtime
Hauptspeicher: Einfaches Pre-Copy Verfahren 1 Migrationsvorbereitung: Reservieren von Resourcen auf Zielrechner 2 Iterative Pre-Copy: Hauptspeicher wird nach und nach kopiert 3 Stop-and-Copy: Anhalten der VM auf Quellrechner, Transfer des verbleibenden Status 4 Commitment und Activation: Empfangsbestätigung des Zielrechners, Fortfahren der VM
Hauptspeicher: Einfaches Pre-Copy Verfahren 1 Migrationsvorbereitung: Reservieren von Resourcen auf Zielrechner 2 Iterative Pre-Copy: Hauptspeicher wird nach und nach kopiert 3 Stop-and-Copy: Anhalten der VM auf Quellrechner, Transfer des verbleibenden Status 4 Commitment und Activation: Empfangsbestätigung des Zielrechners, Fortfahren der VM
Hauptspeicher: Iterative Pre-Copy I Problem: Speicher wird während des Kopierens verändert Lösung: Nur kleiner Teil des Speichers wird laufend geändert: Writable Working Set (WWS) Kopiere also bevorzugt stabile Bereiche Problem: Wo sind diese? Abbruchbedingung?
Hauptspeicher: Iterative Pre-Copy I Problem: Speicher wird während des Kopierens verändert Lösung: Nur kleiner Teil des Speichers wird laufend geändert: Writable Working Set (WWS) Kopiere also bevorzugt stabile Bereiche Problem: Wo sind diese? Abbruchbedingung?
Hauptspeicher: Iterative Pre-Copy I Problem: Speicher wird während des Kopierens verändert Lösung: Nur kleiner Teil des Speichers wird laufend geändert: Writable Working Set (WWS) Kopiere also bevorzugt stabile Bereiche Problem: Wo sind diese? Abbruchbedingung?
Hauptspeicher: Iterative Pre-Copy II vmdirtypages = bool[ M ]; InitialiseShadowPTE(); foreach p M copy p; copiedpages = previousround = M ; rounds = 1; vmdirtypages = GetShadowPTE(); remainingmem = {p p M vmdirtypages[p]} ; while (previousround remainingmem - 0 rounds++< 29 remainingmem 50 copiedpages 3 M ) do vmdirtypages = GetAndFlushShadowPTE(); foreach p M if vmdirtypages[p] copy p; copiedpages++; fi previousround = remainingmem; vmdirtypages = GetShadowPTE(); remainingmem = {p p M vmdirtypages[p]} ; od
Hauptspeicher: Iterative Pre-Copy II vmdirtypages = bool[ M ]; InitialiseShadowPTE(); foreach p M copy p; copiedpages = previousround = M ; rounds = 1; vmdirtypages = GetShadowPTE(); remainingmem = {p p M vmdirtypages[p]} ; while (previousround remainingmem - 0 rounds++< 29 remainingmem 50 copiedpages 3 M ) do vmdirtypages = GetAndFlushShadowPTE(); foreach p M if vmdirtypages[p] copy p; copiedpages++; fi previousround = remainingmem; vmdirtypages = GetShadowPTE(); remainingmem = {p p M vmdirtypages[p]} ; od
Hauptspeicher: Iterative Pre-Copy II vmdirtypages = bool[ M ]; InitialiseShadowPTE(); foreach p M copy p; copiedpages = previousround = M ; rounds = 1; vmdirtypages = GetShadowPTE(); remainingmem = {p p M vmdirtypages[p]} ; while (previousround remainingmem - 0 rounds++< 29 remainingmem 50 copiedpages 3 M ) do vmdirtypages = GetAndFlushShadowPTE(); foreach p M if vmdirtypages[p] copy p; copiedpages++; fi previousround = remainingmem; vmdirtypages = GetShadowPTE(); remainingmem = {p p M vmdirtypages[p]} ; od
Hauptspeicher: Iterative Pre-Copy III (Xen) Shadow Page-Tables: Übersetzungstabellen für Speicherseiten Zugriffe über Shadow PTEs können abgefangen werden um Schreibzugriffe zu registrieren Während des Kopierens modifizierte Seiten werden im folgenden Durchlauf kopiert Ende der iterativen Kopierstrategie wenn kein Fortschritt mehr möglich, Ziel fast erreicht, zuviele Iterationen, oder Speicherinhalt zu oft kopiert
Hauptspeicher: Iterative Pre-Copy III (Xen) Shadow Page-Tables: Übersetzungstabellen für Speicherseiten Zugriffe über Shadow PTEs können abgefangen werden um Schreibzugriffe zu registrieren Während des Kopierens modifizierte Seiten werden im folgenden Durchlauf kopiert Ende der iterativen Kopierstrategie wenn kein Fortschritt mehr möglich, Ziel fast erreicht, zuviele Iterationen, oder Speicherinhalt zu oft kopiert
Hauptspeicher: Iterative Pre-Copy IIII SuspendVM(); vmdirtypages = GetAndFlushShadowPTE(); foreach p M if vmdirtypages[p] copy p; copy vmcontext; // CPU-State etc. Stop-and-Copy: VM anhalten, restlichen Speicher und CPU-Register kopieren und auf Zielrechner fortfahren
Hauptspeicher: Iterative Pre-Copy Beispiel
Hauptspeicher: Iterative Pre-Copy Runde 1 Speicherinhalt wird kopiert
Hauptspeicher: Iterative Pre-Copy Runde 1 Während des Kopiervorgangs werden Speicherseiten neu beschrieben. Entsprechende Seiten am Zielrechner sind nun veraltet.
Hauptspeicher: Iterative Pre-Copy Runde 1 Während des Kopiervorgangs werden Speicherseiten neu beschrieben. Entsprechende Seiten am Zielrechner sind nun veraltet.
Hauptspeicher: Iterative Pre-Copy Runde 1 Da Zielrechner hält nach der ersten Runde keine aktuelle Kopie des Hauptspeichers.
Hauptspeicher: Iterative Pre-Copy Runde 2 In einer zweiten Runde werden modifizierte Seiten kopiert.
Hauptspeicher: Iterative Pre-Copy Runde 2 In einer zweiten Runde werden modifizierte Seiten kopiert. Wieder kann Speicherinhalt während des Kopiervorgangs verändert werden.
Hauptspeicher: Iterative Pre-Copy Runde 2 In einer zweiten Runde werden modifizierte Seiten kopiert. Wieder kann Speicherinhalt während des Kopiervorgangs verändert werden.
Hauptspeicher: Iterative Pre-Copy Runde 2 Zahl der geänderten Seiten unterschreitet Grenzwert = Stop-and-Copy
Hauptspeicher: Iterative Pre-Copy Runde 3 Zahl der geänderten Seiten unterschreitet Grenzwert = Stop-and-Copy
Hauptspeicher: Iterative Pre-Copy Runde 3 Hauptspeichermigration abgeschlossen.
Hauptspeicher: Pre-Copy Erweiterungen Rapid Page Dirtying: Kopiere nur Seiten die in der vorletzten Runde, nicht aber in der letzten Runde modifiziert wurden. Dynamic Rate-Limiting: Erste Runden werden langsamer kopiert als Folgerunden um Netzwerklast zu reduzieren. (Wird nicht mehr verwendet) Ballooning bei Paravirtualisierung: Prozess in VM reserviert kontinuierlich freien Speicher, dieser muss nun nicht mehr kopiert werden.
Hauptspeichermigration 1 Push phase 2 Stop-and-copy phase Downtime 3 Pull phase
Hauptspeicher: Einfaches Post-Copy Verfahren 1 Migrationsvorbereitung: Reservieren von Resourcen auf Zielrechner 2 Stop-and-Copy: Anhalten der VM auf Quellrechner, Transfer des minimalen Ausführungskontexts 3 Commitment und Activation: Empfangsbestätigung des Zielrechners, Fortfahren der VM 4 Post-Copy: Hauptspeicher wird nach und nach kopiert
Hauptspeicher: Einfaches Post-Copy Verfahren 1 Migrationsvorbereitung: Reservieren von Resourcen auf Zielrechner 2 Stop-and-Copy: Anhalten der VM auf Quellrechner, Transfer des minimalen Ausführungskontexts 3 Commitment und Activation: Empfangsbestätigung des Zielrechners, Fortfahren der VM 4 Post-Copy: Hauptspeicher wird nach und nach kopiert
Hauptspeicher: Post-Copy Problem: Zugriff auf unkopierten Speicher auf der Zielmaschine Demand Paging: Active Pushing: Pre-paging: Abfangen des Seitenfehlers, Nachladen der angefragten Speicherseite über das Netzwerk Zusätzlich im Hintergrund verbleibenden Speicher kopieren Kopieren in zukünftiger Zugriffsreihenfolge (Typischerweise unbekannt Heuristiken) Vorteile gegenüber Pre-Copy: Jede Speicherseite wird höchstens einmal kopiert Schnellere Migration Aber teure Seitenfehler: wesentlich (3-10x) höhere Downtime
Hauptspeicher: Post-Copy Problem: Zugriff auf unkopierten Speicher auf der Zielmaschine Demand Paging: Active Pushing: Pre-paging: Abfangen des Seitenfehlers, Nachladen der angefragten Speicherseite über das Netzwerk Zusätzlich im Hintergrund verbleibenden Speicher kopieren Kopieren in zukünftiger Zugriffsreihenfolge (Typischerweise unbekannt Heuristiken) Vorteile gegenüber Pre-Copy: Jede Speicherseite wird höchstens einmal kopiert Schnellere Migration Aber teure Seitenfehler: wesentlich (3-10x) höhere Downtime
Hauptspeicher: Post-Copy Problem: Zugriff auf unkopierten Speicher auf der Zielmaschine Demand Paging: Active Pushing: Pre-paging: Abfangen des Seitenfehlers, Nachladen der angefragten Speicherseite über das Netzwerk Zusätzlich im Hintergrund verbleibenden Speicher kopieren Kopieren in zukünftiger Zugriffsreihenfolge (Typischerweise unbekannt Heuristiken) Vorteile gegenüber Pre-Copy: Jede Speicherseite wird höchstens einmal kopiert Schnellere Migration Aber teure Seitenfehler: wesentlich (3-10x) höhere Downtime
Hauptspeicher: Post-Copy Problem: Zugriff auf unkopierten Speicher auf der Zielmaschine Demand Paging: Active Pushing: Pre-paging: Abfangen des Seitenfehlers, Nachladen der angefragten Speicherseite über das Netzwerk Zusätzlich im Hintergrund verbleibenden Speicher kopieren Kopieren in zukünftiger Zugriffsreihenfolge (Typischerweise unbekannt Heuristiken) Vorteile gegenüber Pre-Copy: Jede Speicherseite wird höchstens einmal kopiert Schnellere Migration Aber teure Seitenfehler: wesentlich (3-10x) höhere Downtime
Hintergrundspeichermigration 1 Push phase Hintergrundspeicher 2 Stop-and-copy phase 3 Pull phase Hintergrundspeicher
Hintergrundspeichermigration 1 Push phase Hintergrundspeicher 2 Stop-and-copy phase 3 Pull phase Hintergrundspeicher
Hintergrundspeichermigration 1 Push phase Hintergrundspeicher 2 Hauptspeichermigration 3 Pull phase Hintergrundspeicher
Einfache Hintergrundspeichermigration 1 Migrationsvorbereitung: Reservieren von Resourcen auf Zielrechner 2 Intercept und Pre-Copy: Schreibzugriffe der VM werden aufgezeichnet, Hintergrundspeicher wird kopiert. 3 Hauptspeichermigration: Schreibzugriffe der VM werden weiter aufgezeichnet, und an Zielrechner übermittelt, dort angewendet. 4 Commitment und Activation: Empfangsbestätigung des Zielrechners, Fortfahren der VM
Erweiterungen Hintergrundspeichermigration Per Dateisystem belegte Blöcke identifizieren, unbelegte Bereiche nicht kopieren Gemeinsame Templates zwischen beiden Hosts erlauben reine Differenzkopie (z.b. Copy-on-Write) Ausbremsen von Schreibzugriffen auf Quellrechner um Migration zu beschleunigen (Write throttling) Aufgezeichnete Schreibzugriffe reordern, zusammenfassen,... Post-Copy (und beliebige Zwischenstufen) natürlich ebenfalls möglich
Migration Netzwerk IP-Adressen sind Einstellung des Gastbetriebssystems, Teil der Migration TCP kann sich um verlorene Pakete während der Stop-and-Copy-Phase kümmern Bei gleichbleibender IP-Adresse: Umleitung per ARP, VSRP, Routingprotokolle Bei Änderung der IP-Adresse: Rerouting/NAT, DynDNS Zusätzlich: Möglichkeit am Quellrechner eingehende Pakete an den Zielrechner weiterzureichen (z.b. VPN), solange bis alle TCP-Verbindungen geschlossen
Migration Netzwerk IP-Adressen sind Einstellung des Gastbetriebssystems, Teil der Migration TCP kann sich um verlorene Pakete während der Stop-and-Copy-Phase kümmern Bei gleichbleibender IP-Adresse: Umleitung per ARP, VSRP, Routingprotokolle Bei Änderung der IP-Adresse: Rerouting/NAT, DynDNS Zusätzlich: Möglichkeit am Quellrechner eingehende Pakete an den Zielrechner weiterzureichen (z.b. VPN), solange bis alle TCP-Verbindungen geschlossen
Migration Netzwerk IP-Adressen sind Einstellung des Gastbetriebssystems, Teil der Migration TCP kann sich um verlorene Pakete während der Stop-and-Copy-Phase kümmern Bei gleichbleibender IP-Adresse: Umleitung per ARP, VSRP, Routingprotokolle Bei Änderung der IP-Adresse: Rerouting/NAT, DynDNS Zusätzlich: Möglichkeit am Quellrechner eingehende Pakete an den Zielrechner weiterzureichen (z.b. VPN), solange bis alle TCP-Verbindungen geschlossen
Migration Netzwerk IP-Adressen sind Einstellung des Gastbetriebssystems, Teil der Migration TCP kann sich um verlorene Pakete während der Stop-and-Copy-Phase kümmern Bei gleichbleibender IP-Adresse: Umleitung per ARP, VSRP, Routingprotokolle Bei Änderung der IP-Adresse: Rerouting/NAT, DynDNS Zusätzlich: Möglichkeit am Quellrechner eingehende Pakete an den Zielrechner weiterzureichen (z.b. VPN), solange bis alle TCP-Verbindungen geschlossen
Migration Netzwerk IP-Adressen sind Einstellung des Gastbetriebssystems, Teil der Migration TCP kann sich um verlorene Pakete während der Stop-and-Copy-Phase kümmern Bei gleichbleibender IP-Adresse: Umleitung per ARP, VSRP, Routingprotokolle Bei Änderung der IP-Adresse: Rerouting/NAT, DynDNS Zusätzlich: Möglichkeit am Quellrechner eingehende Pakete an den Zielrechner weiterzureichen (z.b. VPN), solange bis alle TCP-Verbindungen geschlossen
Zusammenfassung: Durchsatz Webserver Throughput (Mbit/sec) 1000 800 600 400 200 0 870 Mbit/sec 512Kb files 100 concurrent clients Effect of Migration on Web Server Transmission Rate 1st precopy, 62 secs further iterations 9.8 secs 765 Mbit/sec 694 Mbit/sec 165ms total downtime Sample over 100ms Sample over 500ms 0 10 20 30 40 50 60 70 80 90 100 110 120 130 Elapsed time (secs) ec) 600 500 400 aus: C. Clark, K. Fraser, Figure 8: S. Results Hand, of migrating J. G. Hansen, a running web E. Jul, serverc. VM. Limpach, I. Pratt Iterative Progress and A. of Warfield. Live Migration: LiveSPECweb99 Migration of Virtual Machines. NSDI, 2005. 350 Clients (90% of max load), 800MB VM Total Data Transmitted: 960MB (x1.20) Area of Bars: VM memory transfered Memory dirtied during this iteration In the final iteration, the domain is suspended. The remaining 18.2 MB of dirty pages are sent and the VM resumes execution on the remote machine. In addition to the 201ms required to 18.2 MB copy the last round of data, an additional 9ms elapse while the 15.3 MB VM starts up. The total downtime for this experiment is 210ms. 14.2 MB 16.7 MB
Zusammenfassung: Antwortzeit Quake 3 Server Packet flight time (secs) 0.12 0.1 0.08 0.06 0.04 0.02 0 Packet interarrival time during Quake 3 migration Migration 1 downtime: 50ms 0 10 20 30 40 50 60 7 Elapsed time (secs) Migration 2 downtime: 48ms 450 400 350 Figure 10: Effect on packet response time of migrating a running Quake 3 server VM. aus: C. Clark, K. Fraser, S. Hand, J. G. Hansen, E. Jul, C. Limpach, I. Pratt and A. Warfield. Live Migration of Virtual Machines. NSDI, 2005. Iterative Progress of Live Migration: Quake 3 Server 6 Clients, 64MB VM Total Data Transmitted: 88MB (x1.37) The final iteration in this case leaves only 148KB of data to 0.8 MB transmit. In addition to the 20ms required to copy this last Area of Bars: round, an additional 40ms are spent on start-up overhead. The VM memory transfered total downtime experienced is 60ms. Memory dirtied during this iteration 0.2 MB 0.1 MB it/sec) 300 1.1 MB
Zusammenfassung Migration ist (prinzipbedingt) ressourcenintensiv CPU-Overhead: Shadowing, Trapping, Datendurchsatz (allein 30% für letzteres nach Nelson 2005) Netzwerk: Kopiervorgang, Umleitung Migration trennt VM physikalische Maschine damit wichtiges Werkzeug, essentiell für VM-Scheduling
Zusammenfassung Migration ist (prinzipbedingt) ressourcenintensiv CPU-Overhead: Shadowing, Trapping, Datendurchsatz (allein 30% für letzteres nach Nelson 2005) Netzwerk: Kopiervorgang, Umleitung Migration trennt VM physikalische Maschine damit wichtiges Werkzeug, essentiell für VM-Scheduling
Zusammenfassung Migration ist (prinzipbedingt) ressourcenintensiv CPU-Overhead: Shadowing, Trapping, Datendurchsatz (allein 30% für letzteres nach Nelson 2005) Netzwerk: Kopiervorgang, Umleitung Migration trennt VM physikalische Maschine damit wichtiges Werkzeug, essentiell für VM-Scheduling
Zusammenfassung Migration ist (prinzipbedingt) ressourcenintensiv CPU-Overhead: Shadowing, Trapping, Datendurchsatz (allein 30% für letzteres nach Nelson 2005) Netzwerk: Kopiervorgang, Umleitung Migration trennt VM physikalische Maschine damit wichtiges Werkzeug, essentiell für VM-Scheduling
Ausblick: Problem: CPUs Verschiedene CPUs = verschiedene Featuresets Teilweise sogar innerhalb einer Generation (Steppings) Betriebssysteme können eventuell nicht mit plötzlich wechselnder Plattform umgehen März 2009: AMD demonstriert Live Migration über drei CPU-Generationen (VMWare ESX)
Ausblick: Problem: CPUs Verschiedene CPUs = verschiedene Featuresets Teilweise sogar innerhalb einer Generation (Steppings) Betriebssysteme können eventuell nicht mit plötzlich wechselnder Plattform umgehen März 2009: AMD demonstriert Live Migration über drei CPU-Generationen (VMWare ESX)
Ausblick: Problem: CPUs Verschiedene CPUs = verschiedene Featuresets Teilweise sogar innerhalb einer Generation (Steppings) Betriebssysteme können eventuell nicht mit plötzlich wechselnder Plattform umgehen März 2009: AMD demonstriert Live Migration über drei CPU-Generationen (VMWare ESX)
Ausblick: Vorratsvirtualisierung als (Offsite-)Backup mit Differenz-Snapshots Virtual machine time travel using continuous data protection and checkpointing, P. Ta-Shma et. al. (2008) als Nahezu-Lockstep-Hot-Standby für HA-Systeme: High-speed Checkpointing for High-Availability, B. Cully (2007)
Ausblick: Vorratsvirtualisierung als (Offsite-)Backup mit Differenz-Snapshots Virtual machine time travel using continuous data protection and checkpointing, P. Ta-Shma et. al. (2008) als Nahezu-Lockstep-Hot-Standby für HA-Systeme: High-speed Checkpointing for High-Availability, B. Cully (2007)
Ausblick: Vorratsvirtualisierung als (Offsite-)Backup mit Differenz-Snapshots Virtual machine time travel using continuous data protection and checkpointing, P. Ta-Shma et. al. (2008) als Nahezu-Lockstep-Hot-Standby für HA-Systeme: High-speed Checkpointing for High-Availability, B. Cully (2007)
Fragen? Thank you. 謝 謝 Spasibo. Dziekuje. Danke.
Quellennachweise R. Bradford, E. Kotsovinos, A. Feldmann, H. Schiög. Live wide-area migration of virtual machines including local persistent state. VEE 2007: Proc. International Conference on Virtual Execution Environments. C. Clark, K. Fraser, S. Hand, J. G. Hansen, E. Jul, C. Limpach, I. Pratt and A. Warfield. Live Migration of Virtual Machines. NSDI, 2005. M. R. Hines, K. Gopalan. Post-Copy Based Live Virtual Machine Migration Using Adaptive Pre-Paging and Dynamic Self-Ballooning. VEE 2009: Proc. International Conference on Virtual Execution Environments. M. Nelson, B.-H. Lim, G. Hutchins. Fast Transparent Migration for Virtual Machines. Proceedings of USENIX 2005. K. K. Ramakrishnan, P. Shenoy, J. Van der Merwe. Live data center migration across WANs: a robust cooperative context aware approach. Proc. 2007 SIGCOMM workshop on Internet network management
Multi Tenancy und Software-as-a-Service Alfred Ostermeier Hauptseminar: Databases in the Cloud, SS 2009 Technische Universität München nächste Woche