Gedankenspiel: Windows virtualisation mit Solaris,X4600 und X4500 und SunRays

Die Idee von Mika, die er in einem Kommentar zu meinem Blog abgegeben hat, hat Potential. Erhebliches Potential je länger ich darüber nachdenke. Das was ich hier schreibe, ist ein Gedankenspiel. Ich habs noch nicht ausprobiert, aber es waere echt mal einen Versuch wert. Eine ganze Reihe der Features sind allerdings noch nicht im production-grade Solaris enthalten, sondern erst in Opensolaris. Man verzeihe mir, wenn der Text vielleicht etwas wirr ist, aber ich habe ohne weitere Formulierung meine Gedanken in die Tastatur fliessen lassen. Ich bitte um rege Kommentierung. Wenn man ein System mit Prozessoren hat, die Hardwarevirtualisierung unterstützen, kann man in den virtuellen Maschinen auch ein unmodifiziertes Windows laufen lassen. Das funktioniert sehr gut. Jetzt bringe man in das Gedankenspiel drei Maschinen ein:

• Alpha- eine X4600. Auf diesem System werden die einzelnen Windows VMs gehostet
• thesource- eine X4500. Dieses System hat nur die Aufgabe massenhaft Disks via iSCSI zur Verfügung zu stellen. Wozu das gut ist, wird gleich deutlich.
• theview-Eine T1000, die lediglich die Aufgabe hat, einen SunRay-Server darszustellen. Wozu das gut ist, kommt gleich auch noch</ul> Was man mit Alpha anfängt dürfte recht klar sein. Auf diesem System laufen die eigentlichen Windows VMs. Was allerdings nicht auf diesem System ist, sind die dazugehoerigen virtuellen Datenträger.
  Diese bereitzustellen, ist aufgabe von thesource. Eine sehr interessante Frage ist doch bei Windows die schnelle Bereitstellung von Windows Systemen. Hier kann uns ZFS helfen. Auf der X4500 werden sogenannte emulated volumes bereit gestellt. Opensolaris kann wiederum diese als iSCSI Volumes im Netz zur Verfügung stellen. In der Xen-Konfiguration auf alpha werden nun diese iSCSI-Volumes von den Windows VMs genutzt. Das interessante daran ist nun, das ich mir anfangs eine Masterinstallation vorbereitete. Dieses emulated Volume kann ich genauso wie ein ZFS-Filesystem einfrieren und clonen. Will ich also eine neue Windowsinstallation bereitstellen, so brauche ich nur die Masterinstallation nehmen und clonen. Dank ZFS geht das in wenigen Sekunden. Diesen Clone stelle ich wiederum via iSCSI bereit. Charmante weitere Vorteile:
  • für jede neue Windows-Installation verbraucht nur das Delta zwischen den einzelnen Installationen als Speicher
  • Als Backupmimik könnte man sich folgendes Konzept vorstellen: Man cloniert das Filesystem und macht sofort einen Snapshot. Dann baut man den Clone zu einer vollständigen Installation aus. Wieder einen Snapshot. Mit Hilfe dieser beiden Snapshots erzeugt man einen inkrementellen Backupdatenstrom mit zfs send. Will man jetzt im Laufe der weiteren Lebenszeit der WindowsVM weitere Backups anfertigen, wird das Filesystem wiederum eingefroren, und fertigt einen Backupdatenstrom mit den Deltas zwischen vollständiger Instanz und aktuellem Zustand an.
  • Restore funktioniert dann ähnlich. Neuen Clone mit gleichem Namen erzeugen und dann die beiden beim Backup erzeugten Differenzdatenströme einspielen (also jenen, der den Clone zu einer eigenen Installation macht, und dann den neuesten Differenzdatenstrom, der die Änderungen seit Inbetriebnahme berücksichtigt).</ul> Der SunRay-Server theview ist dann lediglich dazu da, via rdesktop die einzelnen Windows-VM an den Arbeitsplätzen zur Verfügung zu stellen. Hier könnte man eine Logik vorstellen, die beim Einstecken der SunRay-Karte automatisch eine Session startet, die sich auf eine bestimmte VM connected via rdesktop, in der die Windowsmaschine des Nutzers läuft. Für VMware wurden solche Mechaniken schon zusammen mit SunRays implementiert. Das kann man sogar noch weiter treiben: Mit Xen 3.0.4 soll restore/save und migrate auch HVM-Guest funktionieren. Wenn ein Nutzer meinetwegen seit einer Stunde nicht mehr an einer SunRay sein Karte eingesteckt hat, so könnte man sich einen Automatismus einfallen lassen, der die entsprechende VM beendet und den zustand abspeichert (xm save). Dies würde die Resourcen auf den Windows-VM-Maschinen wesentlich entlasten.Steckt der Nutzer dann irgendwo wieder seine Karte ein, wird die VM wieder gestartet (xm restore). Will man das ganze jetzt ins Extreme treiben könnte man sich sogar eine Kopplung von XEN Live Migration und der Fault Management Architecture in Solaris vorstellen: Droht ein Hardwarefehler alpha ausser betrieb zu setzen, so koennte eine automatische Live Migration alle Windows-VMs auf eine andere X4600 (beta,gamma,delta usw) live migrieren. Die Nutzer an den SunRays sollten von diesem Vorgang nichts merken. Ob die SunRay kaputt geht, ist eh egal, da die Dinge r zustandslos sind. Bei Ausfall eines SunRay-Servers muesste nur eine Neukonnektierung via rdesktop erfolgen. Endlich mal ein verlässlicher PC-Arbeitsplatz. Versucht das mal mit einem herkömmlichen Arbeitsplatz;) Ich glaub ich brauch mal ganz dringend ein paar Testmaschinen ....