Energieeffiziente Verwaltung von Linux-Rechenclustern

Transkript

1 DEPARTMENT FÜR INFORMATIK SYSTEMSOFTWARE UND VERTEILTE SYSTEME Individuelles Projekt Energieeffiziente Verwaltung von Linux-Rechenclustern Moritz Brandt 17. Juli 2008 Erstprüfer: Zweitprüfer: Prof. Dr.-Ing. Oliver Theel Dipl.-Inform. Philipp Hahn

2

3 Die folgende Arbeit befasst sich mit der energieeffizienten Verwaltung eines Linux- Rechenclusters. Es werden verschiedene Techniken evaluiert und eine praktische Umsetzung eines auf Virtualisierung basierenden Systems beschrieben. The following theses deals with energy efficient management of an example linux cluster. Different technics are evaluated before an virtualisation based solution will be presented.

4 Inhaltsverzeichnis 1 Einleitung Motivation Problemstellung Zielstellung Überblick Anforderungen Infrastruktur Nutzungsprofil Kriterien Evaluation Rechner herunterfahren Evaluation Bewertung Taktreduzierung Evaluation Bewertung Ruhezustände Evaluation Bewertung Virtualisierung Techniken Evaluation Bewertung Entwurf Einleitung Konzeption Migrationsstrategie Netzwerk Dialogbetrieb Gastsystem Wirtssystem Infrastruktur Implementierung 30 4

5 5.1 Technik Infrastruktur des Systems Wirtssystem Basissystem UnionFS Inital RAM Filesystem Migrationsstrategie Frontend Monitor Netzwerkboot Gastsystem Abschluss Ergebnisse der Implementierung Fazit Ausblick Abkürzungsverzeichnis 44 Abbildungsverzeichnis 45 Literaturverzeichnis 46 5

6 1 Einleitung Ein großes Problem der heutigen Zeit stellt der ständig zunehmende Energieverbrauch der Menschheit dar. Obwohl die Forschung ständig versucht neue Energiequellen zu finden und erneuerbare Energiequellen zu nutzen, bleibt die einfachste Möglichkeit diesem Problem Herr zu werden, Energie effizienter zu nutzen und weniger zu verschwenden, um auch nächsten Generationen eine lebenswerte Umwelt zu hinterlassen. 1.1 Motivation Bereits 1999 betrug der Anteil der durch den Betrieb von Rechnern verursachten Energieverbrauchs in den USA über ein Prozent des Gesamtenergieverbrauches des Landes. Dabei tragen unnötig laufende Rechner den größten Anteil an diesem Bedarf [WWF05]. Während auf mobilen Plattformen schon länger versucht wird Energie effizienter zu nutzen um Batterielaufzeiten zu erhöhen, wird in Rechenclustern, durch ein fehlendes Powermanagement viel Energie verschwendet. Im Rechencluster der ARBI wurde ein einfaches Powermanagement eingeführt um Energie einzusparen. Hierzu werden die Rechner außerhalb der typischen Arbeitszeiten bei Nichtbenutzung abgeschaltet. Dies führte zwar zu einer Energieeinsparung von etwa 50%, brachte jedoch auch unerwünschte Nebeneffekte mit sich so führte das Abschalten der Rechner zu einem Verlust der Remote-Erreichbarkeit. Dies ist eine störende Eigenschaft im Mehrbenutzer-Betrieb und kann in vielen Clustern nicht toleriert werden, da beispielsweise Mitarbeiter die Rechner auch Nachts noch von zu Hause nutzen möchten. In der Serverwelt bietet Virtualisierung eine neue Möglichkeit Energie einzusparen. Durch Virtualisierung können mehrere Systeme auf einer physikalischen Hardware untergebracht werden dies sorgt für eine effizientere Ausnutzung der Hardwareressourcen. So kann Energie, die zum Beispiel für Kühlung und Betrieb zusätzlicher Rechner benötigt wird, eingespart werden. In Serversystemen ist das ausschalten von Rechnern grundsätzlich nicht möglich, da die von ihnen bereitgestellten Dienste dauerhaft zur Verfügung stehen sollen. Virtualisierung macht es möglich Systeme zur Laufzeit auf andere Hardware zu migrieren ohne ihre Ausführung zu unterbrechen. Dieses Vorgehen ermöglicht ein kontrolliertes Load-Balancing benötigt ein Dienst mehr Ressourcen als gerade zur Verfügung stehen, so kann das betreffende System auf einen weniger ausgelasteten Rechner migriert werden. Virtualisierung kann eventuell helfen unerwünschte Nebeneffekte eines einfachen Powermanagements (wie dem Herunterfahren von Rechnern) in Rechenclustern zu minimieren. So kann ein nicht verwendeter Rechner anstatt ihn herunterzufahren auf 6

7 einen ohnehin laufenden Rechner, dessen Ressourcen nicht vollständig genutzt werden, migriert werden. So bleibt das System erreichbar, verbraucht aber keine Energie. 1.2 Problemstellung Die Anforderungen an Serversysteme unterscheiden sich von denen an gewöhnliche Rechencluster. So ist der Dialogbetrieb in Serversystemen nicht vorgesehen lediglich Prozessoren, Arbeitspeicher, Festspeicher sowie Netzwerkschnittstellen werden benötigt um typische Serverdienste zur Verfügung zu stellen. Der typische Dialogbetriebe im Benutzeralltag erfordert zusätzliche Funktionen Virtualisierungslösung können in solchen Szenarien also nicht ohne weiteres eingesetzt werden. 1.3 Zielstellung Ziel des Projektes ist es zunächst, bestehende Techniken zum Einsparen von Energie zu evaluieren und auf ihre Einsatzmöglichkeiten zu prüfen. Eine Lösung basierend auf Virtualisierung soll anschließend prototypisch für einen Linux-Rechencluster entworfen und implementiert werden. Abschließend sollen die Ergebnisse der Implementation evaluiert werden um Aussagen über Nutzen und Anwendbarkeit des neu entwickelten Konzeptes zu machen. 1.4 Überblick Im nächsten Kapitel werden zunächst die Anforderungen an ein Powermanagement in einem Rechencluster identifiziert. Anschließend werden bestehende Techniken zum Einsparen von Energie hinsichtlich der identifizierten Anforderungen evaluiert. Es folgt der Entwurf eines tragfähigen Konzepts sowie dessen Implementierung auf einem Linux-Cluster. Abschließend sollen die Ergebnisse der Implementierung zusammengetragen und bewertet werden. 7

8 2 Anforderungen Die Anforderungen an ein Powermanagement sind sehr stark an das Nutzungsprofil eines konkreten Rechenclusters gebunden. Während in einem Internetcafé die Rechner nach den Öffnungszeiten einfach ausgeschaltet werden können, müssen in vielen Clustern die Rechner auch Nachts noch eingeschaltet bleiben, um zum Beispiel die Remote-Nutzung zu gestatten. Im folgenden wird zunächst ein exemplarischer Rechencluster und sein Nutzungsprofil beschrieben. Als Vorlage dient hierbei ein typische Rechencluster wie er an Universitäten eingesetzt wird. Diese Beschreibungen sollen helfen einen Kriterienkatalog zu erstellen mit dem im nächsten Kapitel verschiedene Techniken zur Energieeinsparung untersucht werden. 2.1 Infrastruktur Der betrachtete Rechencluster besteht aus 22 Workstations die auf verschiedene Räumlichkeiten aufgeteilt sind. Sie sind mit Pentium 4 CPUs ausgestattet und verfügen über einen Gigabyte Arbeitsspeicher. Als Betriebssystem kommt Debian GNU/Linux im Release etch zum Einsatz. Um die Wartung zu erleichtern ist das System zentral auf einem NFS-Server installiert. Der Kernel wird aus dem Netzwerk gebootet. Außerdem existieren 4 Server welche die gesamte Infrastruktur des Clusters bereitstellen. Hierzu gehören ein DHCP-, DNS-, TFTP- sowie ein NFS-System. Das NFS-System verteilt, neben dem Wurzelverzeichnis für die zentrale Systeminstallation der Workstations auch die Heimatverzeichnisse der Benutzer. Die Server sind jeweils zwei Gigabyte Arbeitsspeicher ausgestattet. Auf den Servern werden auch weitere Dienste angeboten, diese sind jedoch im Rahmen dieser Arbeit nicht von Bedeutung. 2.2 Nutzungsprofil Die Workstations des Rechenclusters werden auf verschiedene Arten genutzt, dabei macht der Dialogbetrieb einen großteil der Anwendung aus. Die Benutzer sitzen dabei direkt vor den Rechnern und nutzen ihre Hardware innerhalb einer interaktiven grafischen Sitzung. Die Dauer und Ressourcen-Nutzung einer solchen Sitzung kann variieren. Derartige Sitzungen treten aber hauptsächlich zu bestimmten Stoßzeiten (Arbeitszeiten) auf. Manche Nutzer vergessen sich aus ihren Sitzungen auszuloggen, oder tun dies absichtlich nicht, um ihre Sitzung nicht neu starten zu müssen sie haben keine Lust alle Anwendungen neu zu öffnen nachdem sie wieder an den Arbeitsplatz zurückgekehrt sind. 8

9 Einige der Workstations werden außerdem im Mehrbenutzer-Betrieb verwendet und stellen Netzwerkdienste verschiedener Art zur Verfügung. Darunter fällt auch die unregelmäßig auftretende Remote-Nutzung durch Benutzer (zum Beispiel per SSH). Die Server des Clusters sind dauerhaft in Betrieb. Die Ressourcenausnutzung variiert dabei. Vor allem außerhalb der Arbeitszeiten werden sie nur wenig beansprucht. 2.3 Kriterien Im folgenden werden aus dem Nutzungsprofil und der allgemeinen Forderung nach möglichst hoher Energieeffizienz die Anforderungen an ein Powermanagement für den betrachteten Cluster beschrieben. Diese sollen die Grundlage für eine Evaluation bestehender Einsparungstechniken sowie den späteren Entwurf darstellen. Zu beachten ist, dass nicht alle diese Kriterien gleichzeitig erfüllbar sind so sind die Forderung nach möglichst geringem Energieverbrauch und dauerhafter Verfügbarkeit des Systems widersprüchlich es muss später also ein möglichst guter Kompromiss gefunden werden. Energiesparsamkeit: Es soll möglichst viel Energie eingespart werden. Ressourcennutzung: Bei Bedarf sollen alle verfügbaren Ressourcen genutzt werden können. Möchte ein Benutzer einen rechenintensiven Prozess ausführen, so möchte er möglichst alle Hardware-Ressourcen seines Rechners nutzen. Dialogbetrieb: Die Nutzung im Dialogbetrieb muss möglich sein. Dazu gehört eine interaktive grafische Sitzung mit diversen Anwendungsprogrammen. Insbesonders muss die Benutzung gängiger Büroapplikationen möglich sein. Der Benutzer verwendet hierfür Maus, Tastatur, Anzeige, Drucker sowie eine Netzwerkverbindung. Die Nutzung anderer Ein- und Ausgabegeräte wie Audio-Hardware oder USB ist wünschenswert. Netzwerkverfügbarkeit: Die Systeme sollen möglichst immer im Netzwerk verfügbar sein, damit den Benutzern ständig ein Remotezugriff ermöglicht wird. Sitzungspersistenz: Sitzungen müssen persistent bestehen bleiben, damit Benutzter jederzeit die Arbeit an der Stelle wiederaufnehmen können, an der sie aufgehört haben. Wartbarkeit: Das System soll möglichst einfach und ohne viel Aufwand wartbar sein, dass erhöht die Systemsicherheit und spart Zeit und Kosten. Automatisierbarkeit: Das Powermanagement sollte möglichst automatisch stattfinden. Vergessene Nutzersitzung sollten erkannt werden um mehr Energie einzusparen. Vergisst der Be- 9

10 nutzer zum Beispiel den Rechner auszuschalten, sollte das Powermanagement entsprechend reagieren und zum Beispiel den Rechner herunterfahren. Nutzertransparenz: Die Umsetzung soll für den Benutzer möglichst transparent sein. Der Benutzer soll nicht merken das ein Powermanagement stattfindet und seine üblichen Nutzungsmuster beibehalten dürfen. Umsetzbarkeit: Das Konzept muss auf dem betrachteten Cluster umsetzbar sein, insbesondere soll die bestehende Hardware weiterhin genutzt werden. Außerdem muss das Konzept innerhalb der zur Verfügung stehenden Projektzeit durchführbar sein. 10

11 3 Evaluation Im folgenden werden bestehende Konzepte zur Einsparung von Energie vorgestellt und im Hinblick auf die vorher aufgestellten Kriterien untersucht. Dabei werden die im vorherigen Kapitel 2 aufgestellten Anforderungen als Bewertungsgrundlage verwendet. 3.1 Rechner herunterfahren Eine sehr einfache aber Energie sparende Technik ist es, einen ungenutzten Rechner herunterzufahren und von der Energieversorgung zu trennen Evaluation Energiesparsamkeit: Das Abschalten eines Rechners ist maximal energiesparend. Ist er von der Energieversorgung getrennt, so verbraucht er keine Energie. Ressourcennutzung: Schaltet ein Benutzer den Rechner ein, so kann er alle verfügbaren Hardware- Ressourcen für seine Prozesse nutzen. Dialogbetrieb: Der Dialogbetrieb ist vollständig möglich, er stellt einen klassischen Anwendungsfall dar. Die gesamte Hardware samt aller Ein- und Ausgabegeräte steht dem System zur Verfügung und eine grafische Benutzeroberfläche kann verwendet werden. Netzwerkverfügbarkeit: Ist ein Rechner ausgeschaltet, so steht das System im Netzwerk nicht mehr zur Verfügung. Dieses Problem ließe sich mittels Wake-on-LAN lösen hierzu kann ein sogenanntes Magic-Paket an dem betroffenen Rechner geschickt werden wodurch dieser gestartet wird. Voraussetzung hierfür ist jedoch eine entsprechende Unterstützung durch die Netzwerkkarte. Außerdem darf der Rechner nicht vollständig von der Energieversorgung getrennt werden. Die Netzwerkkarte muss weiterhin mit Strom versorgt werden. Ein Problem dieses Vorgehens stellt die erhöhte Latenz dar. Will der Benutzer beispielsweise eine Remote-Verbindung zu einem Rechner aufbauen, so muss dieser zunächst hochgefahren werden. Eine weitere Lösung dieses Problems könnte ein transparentes Routing darstellen. Versucht der Benutzer einen ausgeschalteten Rechner zu erreichen, so wird er auf 11

12 einen ohnehin laufenden Rechner geroutet dies kann auch einer der dauerhaft laufenden Server sein. Da die Heimatverzeichnisse der Benutzer auf allen Rechnern die selben sind, sie werden zentral von einem NFS-Server verteilt, kann der Benutzer trotzdem auf seine Dateien zugreifen. Nachteilig an dieser Lösung ist, dass der Benutzer nicht die Ressourcen seines eigentlichen Zielrechners zur Verfügung gestellt bekommt. Sitzungspersistenz: Das halten einer Nutzersitzung ist nicht ohne weiteres möglich. Beim Abschalten gehen die Zustandsinformationen der Benutzersitzung verloren. Eine Möglichkeit diese Nachteile zu kompensieren stellt die Verwendung einer Sitzungsverwaltung dar. Für das X-Window-System existieren Implementierungen wie XSession oder ksmserver diese erfordern jedoch stets eine Unterstützung durch das jeweilige Anwendungsprogramm was die Verwendung unpraktikabel macht. Wartbarkeit: Die Wartbarkeit eines Clusters wird durch das Abschalten der Rechner erschwert. Die auf den Rechnern laufenden Systeme können nicht ohne weiteres aktualisiert werden. Hier kann die oben beschriebene Wake-on-LAN Lösung Abhilfe schaffen. Auch eine zentrale Installation des Betriebssystems, wie sie im betrachteten Cluster bereits eingesetzt wird, verringert den Wartungsaufwand Systemaktualisierungen können zentral vorgenommen werden. Automatisierbarkeit: Die Automatisierbarkeit des Powermanagements ist problematisch. Es ist nicht möglich exakt festzustellen unter welchen Umständen ein Rechner ausgeschaltet werden darf. In der Praxis wird hier zumeist die Aktivität einer Benutzersitzung ausgewertet werden Maus und Tastatur längere Zeit nicht benutzt, so wird die Sitzung inaktiv. Nach einer bestimmten Zeit wird der Rechner heruntergefahren, Prozesse welche noch im Hintergrund laufen werden zerstört. Ob ein Prozess beendet werden darf ist stets eine individuelle Entscheidung und nicht ohne großen Aufwand zu erkennen. Ein vergessenes Internetradio zu beenden wäre für den Benutzer vermutlich erträglich, der Verlust von ungesicherten Dokumenten oder laufenden Transaktionen hingegen schon. Hier müsste man ein aufwendiges Monitoring einführen um derartige Situation detailliert differenzieren zu können. Aus Sicht des Betriebssystem ist es nicht möglich herauszufinden welche Ein- und Ausgaben oder Prozesse für den Benutzer wichtig sind. Eine einfach Lösung des Problems bietet die Übergabe dieser Pflicht an den Benutzer. Dieser kann den Rechner nach Beendigung seiner Arbeit herunterfahren. Dies wirkt sich negativ auf die Nutzertransparentz aus der Benutzer ist aktiv am Powermanagement beteiligt. Greift der Benutzer nicht in den Prozess ein, er fährt den Rechner nicht herunter, so läuft der Rechner weiter und verbraucht unvermindert Energie. 12

13 Nutzertransparenz: Die Nutzertransparenz ist niedrig. Der Benutzer muss in den Prozess eingreifen um die Probleme der Idle-Erkennung zu lösen (siehe Automatisierbarkeit). Umsetzbarkeit: Die Umsetzbarkeit für den betrachteten Cluster ist gegeben es wird keine zusätzliche Hardware gebraucht. Die Umsetzung kann durch wenige Skripts erfolgen Bewertung Das klassische Konzept des Abschaltens kann viel Energie einsparen, es entstehen jedoch auch entscheidende Nachteile. So kann weder Sitzungspersistenz noch eine Automatisierung des Powermangements akzeptabel bewerkstelligt werden. Auch die Unterstützung von Remote-Diensten ist nur bedingt möglich. 3.2 Taktreduzierung Moderne Hardware bietet zunehmend Unterstützung für die Senkung des Energiebedarfs. Solche Techniken entstammen der Welt des Mobile-Computings und werden heutzutage vornehmlich in Laptops eingesetzt. Aktuelle Prozessoren unterstützen sogenannte P-States diese geben bestimmte Takt- und Spannungsstufen vor und können durch das Betriebssystem dynamisch angepasst werden. Verringert sich die Prozessorauslastung, so wird die Taktfrequenz entsprechend reduziert, das führt zu einer Reduzierung der thermische Verlustleistung und damit zu einer Einsparung von Energie Evaluation Energiesparsamkeit: Das Einsparungspotential ist eher gering. Wird der Rechner nicht genutzt, so verbraucht er dennoch Energie. Bezogen auf das Gesamtsystem kann durch eine Taktreduzierung etwa 8,5% Energie eingespart[wol]. Ressourcenverfügbarkeit: Der Benutzer kann stets alle vorhandenen Ressourcen nutzen. Steigt der Bedarf, so wird der Prozessor entsprechend hochgetaktet. Dialogbetrieb: Der Dialogbetrieb kann problemlos gewährleistet werden. Netzwerkverfügbarkeit: Die Netzwerkverfügbarkeit wird nicht beeinflusst. Sitzungspersistenz: Sitzungen bleiben stets erhalten. Wartbarkeit: Es entsteht kein zusätzlicher Wartungsaufwand. 13

14 Automatisierbarkeit: Die Automatisierung des Powermanagements stellt kein Problem dar. Moderne Kernel unterstützen die P-States und entsprechende Drosselungstrategien. Nutzertransparenz: Das Betriebssystem übernimmt das Powermanagement. Der Vorgang ist für den Benutzer vollständig transparent. Umsetzbarkeit: Heutzutage ist die Unterstützung für Taktreduzierung vor allem in Mobilprozessoren verbreitet. Nur sehr aktuelle Desktop- und Serverprozessoren unterstützen diese Technik Bewertung Den große Vorteil von Taktreduzierung stellt die hohe Transparenz für den Benutzer dar. Die Taktreduzierung hat keine negativen Nebeneffekte. Das Einsparungspotential ist zwar vorhanden, ist jedoch im Vergleich zum Abschalten des Rechners gering, außerdem ist stets entsprechende Hardware notwendig. 3.3 Ruhezustände Eine Reduzierung des Energieverbrauchs kann durch die Verwendung sogenannter Ruhezustände erreicht werden. Die Technische Umsetzung dieser Zustände erfolgt durch die ACPI und wird von heutzutage von nahezu jeder aktuellen Hardware/Betriebssystemkombination unterstützt. Neben dem Zustand Ausgeschaltet (S5) existieren in der Spezifikation von ACPI[CCC + 06] zusätzlich Zustände für Suspend-to-memory (Standby) und Suspend-to-disk (Hibernation). Diese ermöglichen eine Speicherung des gesamten Ausführungszustandes der Hardware. Suspend-to-memory speichert diese Zustandsinformationen im Hauptspeicher des Systems nur der Arbeitsspeicher muss weiter mit Energie versorgt werden. Suspend-to-disk speichert den Zustand auf der Festplatte des Rechners da dieser nicht flüchtig ist, kann der Rechner vollständig abgeschaltet werden. Wird das System wieder aufgeweckt wird der vorher gespeicherte Zustand wieder hergestellt. Prozesse laufen exakt dort weiter wo sie aufgehört haben. Suspend-to-memory erlaubt hierbei wesentlich kürzere Einschlaf- und Aufweckzeiten da keine aufwändige Transaktion der Zustandsinformation auf die langsame Festplatte stattfinden muss Evaluation Energiesparsamkeit: Ruhezustände sorgen für eine hohe Energieeinsparung. Während das Einsparungspotential von Suspend-to-disk dem des einfachen Abschaltens gleicht der gesamte Rechner kann vom Strom getrennt werden, so wird bei Suspend-to-memory 14

15 weiterhin Energie verbraucht der Arbeitsspeicher muss weiterhin versorgt werden, wofür aktuelle Rechner 2 15 Watt verbrauchen [Kö]. Ressourcenverfügbarkeit: Schaltet ein Benutzer den Rechner ein, so kann er alle verfügbaren Hardware- Ressourcen für seine Prozesse nutzen. Dialogbetrieb: Der Dialogbetrieb ist vollständig möglich, er stellt einen klassischen Anwendungsfall dar. Netzwerkverfügbarkeit: Ist ein Rechner ausgeschaltet, so steht das System im Netzwerk nicht mehr zur Verfügung. Es entstehen die gleichen Probleme wie beim Herunterfahren des Rechners (vergleiche Abschnitt 3.1.1) ist der Rechner im Ruhezustand, so kann er nicht im Netzwerk erreicht werden. Sitzungspersistenz: Nutzersitzungen bleiben vollständig erhalten. Nach dem Aufwecken befindet sich das System im gleichen Zustand wie vor dem Einschlafen. Wartbarkeit: Die Wartbarkeit eines Clusters verändert sich wie beim Abschalten des Rechners (vergleiche Abschnitt 3.1.1). Eine Aktualisierung der installierten Systeme wird erschwert. Automatisierbarkeit: Es entstehen die gleichen Probleme wie beim Herunterfahren des Rechners (vergleiche Abschnitt 3.1.1). Die Erkennung des Idle -Zustandes ist schwierig. Nutzertransparenz: Es entstehen die gleichen Probleme wie beim Herunterfahren des Rechners (vergleiche Abschnitt 3.1.1). Der Benutzer muss in den Prozess des Powermanagements aktiv eingreifen. Umsetzbarkeit: Die Umsetzbarkeit für den betrachteten Cluster ist gegeben die Hardware der Workstations unterstützt ACPI Bewertung Ruhezustände sind dem klassischen Abschalten sehr ähnlich. Vorteile ergeben sich durch eine Sitzungspersistenz und, vor allem bei Suspend-to-memory, eine schneller Bereitschaftszeit. Für die Entwicklung des OLPC-Laptop wurde die Aufweckzeit auf 160ms reduziert, dies ist jedoch nur durch die Verwendung ganz bestimmter Hardware in Verbindung mit einer eigens entwickelten Firmware möglich [OLP]. 15

16 3.4 Virtualisierung In der Serverwelt gilt momentan Virtualisierung als eine der ganz großen Chancen Energie effizienter zu nutzen. Obwohl die grundsätzlich Idee nicht neu ist, sie stammt bereits aus der Mitte der 60er Jahre, so findet sie erst heutzutage seinen Weg in die Rechencluster [Ver07]. Die Idee besteht darin mehrere virtuelle Systeme auf einer physikalischen Hardware unterzubringen dies wird als Konsolidierung bezeichnet. Wo früher oft viele Rechner benötigt wurden, reicht dank Virtualisierung oft eine Hardware aus. Das spart Anschaffungs- und Betriebskosten. In bestimmten Serverclustern sollen so bis zu 70% Energie eingespart werden [Ver07]. Moderne Virtualisierunglösungen bieten Funktionen zum übertragen von virtualisierten Umgebungen auf andere Hardware. Dabei können diese Systeme weiter ausgeführt werden. Außerdem besteht die Möglichkeit (wie bei den Ruhezuständen) den Ausführungszustand der virtualisierten Systeme abzuspeichern und später wiederherzustellen Techniken Es bestehen verschiedene Ansätze eine solche Virtualisierung umzusetzen. Da in dieser Arbeit die Virtualisierung als Energiesparstrategie eingesetzt werden soll, werden zunächst zwei verschiedene Lösungen vorgestellt. Zu Beginn der Projektzeit wurden viele bestehende Virtualisierungslösungen auf die Einsetzbarkeit geprüft (zum Beispiel KVM, VirtualBox, VM-Ware und QEMU). Folgend werden ausschließlich Lösungen vorgestellt die eine Migration von Gästen erlauben und außerdem frei erhältlich sind. OpenVZ Gast 0 libc Gast 1 libc Gast N libc Linux Kernel Hardware Abbildung 3.1: Darstellung der Betriebssystempartitionierung durch OpenVZ 16

17 OpenVZ[OVZ] ist die freie Variante von Vituozzo[Vir]. Es handelt sich um eine auf Linux basierende Betriebssystempartitionierung. Dabei stellt der Bertriebssystemkern sogenannte Virtuelle Umgebungen zur Verfügung die jeweils eigenständige Systeme beinhalten können. Dazu wird die gesamte Ressourcenverwaltung des zu Grunde liegenden Linux-Kernels partitioniert. Dies betrifft zum Beispiel die Prozessverwaltung, den Netzwerkstack und die Benutzer- und Gruppenverwaltung. Im Gegensatz zu einer Hypervisor basierten Lösung (siehe Abschnitt 3.4.1) verwenden alle virtuellen Umgebungen den selben Kernel und laden jeweils eine eigene Instanz der darunter liegenden System-Bibliotheken (siehe Abbildung 3.1). Dies sorgt für einen relativ geringen Virtualisierungs-Overhead und macht eine flexibles Management der Ressourcen möglich. So ist zum Beispiel die Verteilung des Arbeitsspeichers dynamisch zur Laufzeit anpassbar. Momentan findet OpenVZ vor allem Verwendung bei Webhostern. Dabei wird fast ausschließlich das kommerzielle Pendant Virzuozzo eingesetzt. Es bietet zusätzlich zur eigentlichen Virtualisierung eine vorgefertigte Management Lösung, welche auf den Serverbetrieb ausgelegt ist. Webhoster können ihren Kunden so ein scheinbar eigenen Server verkaufen, nutzen jedoch die Konsolidierung um Hardware- und Energiekosten gering zu halten. Xen Xen ist die zweite freie Virtualisierungslösung die eine Relokalisierung der Gäste zwischen verschiedenen Wirten ermöglicht. Sie verwendet eine sogenannte Paravirtualisierung. Das bedeutet, dass die Betriebssysteme, welche in den virtuellen Umgebungen laufen sollen, entsprechend angepasste werden müssen. Ein sogenannter Hypervisor stellt eine Abstraktionsschicht zur Hardware dar. Eine privilegierte Umgebung kann über eine API den Hypervisor kontrollieren und so einen Virtualisierungsstack verwalten. Dieser stellt den Gastsystemen eine scheinbar physikalische Hardware zur Verfügung die Gäste verwenden also einen eigenen Kernel zur Ressourcenverwaltung. Abbildung 3.2 stellt diese Architektur schematisch dar. Um ein Betriebsystem in einer paravirtualisierten Umgebung laufen zu lassen, werden ungenutzte Privilegierungszustände der x86-architektur genutzt. Die System-Calls der Gastbetriebssysteme müssen dann jedoch modifiziert werden um diese Privilegierungszustände entsprechend zu nutzen. In GNU basierten Systemen sind diese in der GNU C-Library[LIB] implementiert, von der eine an den Betrieb als Gastsystem angepasste Variante existiert. Dank der Virtualisierungs-Erweiterung aktueller CPUs (zum Beispiel: AMD-V, Intel-VT) müssen diese Modifikationen nicht mehr gemacht werden. Es lassen sich auch völlig unmodifizierte Betriebsysteme als Gassystem einsetzen. Dies ermöglicht zum Beispiel auch die Verwendung von Microsoft Windows als Gastsystem. Der große Nachteil von Xen ist vor allem die unflexible Ressourcenverwaltung. Der privilegierten Umgebung ist es nicht ohne weiteres möglich in die Gastsysteme hinein zu schauen, da der Hypervisor die Hardware verwaltet. Eine dynamische Ressourcenverwaltung, zum Beispiel die dynamische Anpassung der Hauptspeichergröße, ist so nicht möglich. Außerdem entsteht im Gegensatz zur Betriebssystempartitionierung ein größerer 17

18 Gast 0 GNU/Linux privilegierte Umgebung GNU/Linux Virtualisierungsstack Gast 1 GNU/Linux Gast N GNU/Linux Hypervisor API Hypervisor Hardware Abbildung 3.2: Darstellung der Xen-Architektur Overhead jede virtuelle Umgebung verwendet einen eigenen Kernel. Ein großer Vorteil von Xen stellt die sogenannte Live Migration dar. Hierbei wird bei der Übertragung von Gastsystemen auf eine andere Hardware zunächst der gesamte Speicherinhalt kopiert. Das Gastsystem läuft zunächst auf dem Quellrechner weiter. Wird der Speicherinhalt einer Kachel nach der Übertragung noch einmal verändert, so wird er als Dirty-Page markiert. Kurz bevor das System auf der Zielhardware gestartet wird, wird es auf dem Quellrechner angehalten. Dann werden die Dirty-Pages und alle Registerinhalte übertragen. Anschließend wird das System auf der Zielhardware gestartet. Bei einer entsprechen leistungsfähigen Netzwerkinfrastruktur kann die Ausfallzeit so auf wenige Millisekunden reduziert werden, so dass Netzwerkverbindungen bestehen bleiben können [SBZD07] Evaluation Energiesparsamkeit: Durch Virtualisierung kann in Serverclustern viel Energie eingespart werden. Wird ein System nicht im Dialogbetrieb genutzt, so kann es auf ohnehin laufender Hardware weiterlaufen. Dies spart Energie. 18

19 Ressourcenausnutzung: Die Ressourcenverfügbarkeit ist hoch und kann sehr flexibel angepasst werden. Möchte ein Benutzer im Dialogbetrieb arbeiten, so kann die virtuelle Umgebung auf seinen Rechner migriert werden bis auf den, durch die Virtualisierung entstehende, Overhead kann er so alle Ressourcen nutzen. Benötigt das System nur wenige Ressourcen, zum Beispiel um den Remote-Zugriff zu erlauben, so kann es mit mehreren anderen Systemen auf einer gemeinsamen Hardware laufen. Dialogbetrieb: Die Nutzung eines virtuellen Systems im grafischen Dialogbetrieb ist problematisch. Virtualisierungslösungen sind an den Einsatz im Serverumfeld angepasst für den Dialogbetrieb typische Geräte, wie Maus, Tastatur und Anzeige werden nicht virtualisiert. Netzwerkverfügbarkeit: Durch Migration auf ohnehin laufende Server kann eine dauerhafte Netzwerk- Verfügbarkeit der Systeme erreicht werden. Sitzungspersistenz: Nutzersitzungen bleiben vollständig erhalten. Durch den durchgängigen Betrieb der Systeme müssen die Benutzer ihre Sitzungen nicht beenden. Das Checkpointing kann zusätzlich den Ausführungszustand sichern. Wartbarkeit: Die Wartbarkeit des Systems wird erschwert. Virtuelle Systeme müssen verwaltet werden, die Zahl der zu wartenden Systeme vervielfacht sich. Automatisierbarkeit: Es entstehen die gleichen Probleme wie beim Herunterfahren des Rechners (vergleiche Abschnitt 3.1.1). Die Erkennung des Idle -Zustandes ist sehr schwierig. Nutzertransparenz: Es entstehen die gleichen Probleme wie beim Herunterfahren des Rechners (vergleiche Abschnitt 3.1.1), der Benutzer muss in den Prozess aktiv eingreifen. Umsetzbarkeit: Die Umsetzbarkeit für den betrachteten Cluster ist gegeben Virtualisierungslösungen können auf den Workstations verwendet werden Bewertung Virtualisierung kann in Serversystemen viel Energie einsparen, bringt aber auch einige Nachteile mit sich. Die Automatisierbarkeit und Nutzertransparentz ist, wie beim Ausschalten eines Rechners oder der Verwendung von Ruhezuständen, problematisch. Sitzungspersistenz kann wie bei Ruhezuständen hergestellt werden dazu können Checkpoints des Systemzustandes erstellt werden sofern das System nicht ohnehin ständig in Betrieb bleiben soll. 19

20 Netzwerkverfügbarkeit und die Ressourcenaussnutzung sind dank Virtualisierung besser zu errreichen, als bei den anderen vorgestellten Techniken. 20

21 4 Entwurf Das folgende Kapitel beschreibt den Entwurf eines Powermanagements durch Virtualisierung. Dabei sollen die bei der Evaluation erkannten Probleme möglichst gut durch bestehende Techniken gelöst werden. Auf Ideen zur Erweiterung, welche während der Projektzeit entstanden sind, wird jeweils an geeigneter Stelle eingegangen. 4.1 Einleitung Aufbauend auf den Untersuchungen aus dem vorangegangenen Kapitel 3 wurde Xen als Virtualisierungslösung ausgewählt. Diese Entscheidung hatte folgende Gründe: rege Projektaktivität gute Dokumentation vielfach eingesetzt vorhandene Literatur Unterstützung von verschiedenen Betriebssystemen durch entsprechende Hardwareunterstützung der CPU Live-Migrationsfähigkeit 4.2 Konzeption Das grundlegende Konzept besteht darin, sämtliche Arbeitssysteme des ursprünglichen Clusters zu virtualisieren und die Nutzer dann auf diesen virtuellen Systemen agieren zu lassen. Abbildung 4.1 stellt dieses Konzept schematisch dar jede Workstation wird in ein Wirtssystem zur Beherbergung virtualisierter Systeme umgewandelt und bekommt genau ein Gastsystem zugeordnet. Ein Server innerhalb des Clusters kann mehrere dieser Gastsysteme aufnehmen, sofern dieser über genügend freie Ressourcen verfügt. Als kritische Ressource erweist sich hier vor allem der Arbeitsspeicher dieser muss so dimensioniert sein, dass er den Gesamtbedarf aller gleichzeitig auf dem Server laufenden Gastsysteme deckt. Nach Relokalisierung eines virtuellen Systems auf den Server, kann die korrespondierende Workstation abgeschaltet werden. Energie wird eingespart obwohl das eigentliche System weiterhin läuft. Eine wichtige Entwurfsentscheidung stellt die Eins-zu-Eins-Beziehung zwischen Rechnern und virtuellen Umgebungen dar. Dieses Vorgehen erleichtert die Verwaltung von 21

22 Server Wirt Migration Pool Gast 0 Gast 1 Gast N 1:1 Workstation 0 1:1 Workstation 1 1:1 Workstation N Wirt 0 Wirt 1 Wirt N Abbildung 4.1: Veranschaulichung des Konzeptes Gastsystemen jede Workstation kann ihre korrespondierenden virtuellen Umgebung eigenständig verwalten. Es muss keine zusätzliche Management Komponente in das System integriert werden. Theoretisch wäre es möglich mehr Gastsysteme als Workstations in das System einzugliedern. Dies ist jedoch im Dialogbetrieb irreführend, denn der User ist es gewohnt vor dem Rechner zu sitzen an dem er arbeitet das Powermanagement soll trotz Virtualisierung für den Nutzer transparent erscheinen. 4.3 Migrationsstrategie Das in Abbildung 4.2 gezeigte Ablaufdiagramm veranschaulicht den Betriebszyklus eines Workstation-Rechners. Beim Beenden seiner Sitzung entscheidet der Nutzer selbst was mit der virtuellen Umgebung passieren soll. Dabei soll er folgende drei Möglichkeiten haben: das Gastsystem herunterfahren, es wird beim nächsten Anschalten neu instantiiert. Dies entspricht dem Herunterfahren des Rechners mit all seinen Vor- und Nachteilen. einen Checkpoint der Sitzung erstellen, der gesamte Systemzustand wird in eine Datei gespeichert und wird beim nächsten Anschalten wiederhergestellt. Dies entspricht den Schlafzuständen und führt somit zu einer Nichterreichbarket. das System auf den Server übertragen wo es weiterläuft, es wird beim nächsten Anschalten zurück zur Workstation relokalisiert. Das System ist also weiterhin erreichbar. 22

23 Einschalten Läuft Instanz auf dem Server? ja Instanz lokalisieren nein Existiert ein Checkpoint? ja Checkpoint laden nein Instanz neu erstellen Sitzungsbetrieb beenden Benutzerentscheidung Instanz relokalisieren Checkpoint speichern Instanz beenden Ausschalten Abbildung 4.2: Ablaufdiagramm des Betriebszyklusses einer Workstation Allen Möglichkeiten ist gemein, dass die Workstation anschließend heruntergefahren werden kann, um Energie zu sparen. Dieses Vorgehen ermöglicht eine einfache Umsetzung. Beim Einschalten einer Workstation müssen lediglich die drei Fälle rückwärts abgearbeitet werden. Trotz dieser starken Vereinfachung kann dieses Konzept bei adäquater Bedienung durch den Benutzer alle erwünschten Vorteile bringen. Neben den Strategien des Ausschaltens und der Schlafzustände, welche äquivalent abgebildet werden, kann durch die Migration von Systemen auch der Vorteil der Virtualisierung genutzt werden. Auf eine Erkennung von Idle-Zuständen wird im Rahmen dieser Arbeit verzichtet. Dazu wäre nach den Erkenntnissen der Evaluation eine komplexe Monitoring-Lösung nötig, welche innerhalb der verfügbaren Projektzeit nicht umsetzbar wäre. Die Möglichkeit das System zu erweitern soll bei der Implementierung jedoch berücksichtigt werden, so ist ein Interface zum skripten der Aktionen angedacht. Eine Erweiterung des Systems wird somit sehr einfach möglich. 23

24 Nachteil dieser Strategie ist, dass der Benutzer sich aktiv an dem Prozess beteiligen muss; wird er nicht aktiv, so läuft der Rechner unvermindert weiter und verbraucht entsprechend viel Energie. Andererseits reduziert die Interaktion mit dem Benutzer die Gefahr, seine Sitzung fälschlicherweise zu migrieren oder gar zu beenden. Eine denkbare Erweiterung wäre es, dass bestimmte Rechner (zum Beispiel nach den Arbeitszeiten) migriert, gespeichert oder beendet werden. Eine Wake-On-LAN Lösung könnte im Umkehrzug die Rechner wieder wecken. 4.4 Netzwerk Im folgenden soll eine genauere Betrachtung der Netzwerkstruktur erfolgen. Innerhalb des Clusters kann jede Workstation durch eine IP-Adresse und einen zugehörigen symbolischen Namen erreicht werden. Hierfür verfügt der Cluster bereits über eine geeignete Infrastruktur. Mittels DNS können symbolische Namen zu IP-Adressen aufgelöst werden. Die IP-Adressen werden auf Basis der MAC-Adressen der in den Workstations verbauten Netzwerkkarten mittels DHCP zugewiesen. Durch die Virtualisierung jedes physikalischen Rechners verdoppelt sich der Bedarf an Adressen. Die Wirtssysteme müssen zur Übertragung der Gäste von Workstation zu Server, und umgekehrt, eine Adresse besitzen. Gäste benötigen eine Adresse für den Remotezugriff (zum Beispiel SSH) oder andere Netzwerkdienste. Xen nutzt hiefür das Konzept einer Netzwerkbrücke. Wie in Abbildung 4.3 zu sehen, wird die physikalische Netzwerkschnittstelle an eine interne Netzwerkbrücke gekoppelt. Anschließend wird das ARP der Netzwerkkarte deaktiviert sie funktioniert nun wie ein Hub. Die privilegierte Domain erhält eine Netzwerkschnittstelle (eth) welche eine Kopie der ursprünglichen Netzwerkschnittstelle darstellt. Diese virtuelle Netzwerkschnittstelle übernimmt die MAC-Adresse der ursprünglichen Netzwerkkarte und kann anschließend mit einer IP-Adresse versehen werden. Die privilegierte Domain ist dann in den Cluster eingebunden. Bei der Instantiierung eines Gastsystems werden innerhalb der privilegierten Umgebung neue virtuelle Interfaces (vif) erstellt, zu der Netzwerkbrücke hinzugefügt, und innerhalb des Gastsystems als Netzwerkschnittstelle verfügbar gemacht. Das Gastsystem kann so auch mit einer Adresse versehen werden. Eine Kommunikation zwischen Wirtsund Gastsystem kann also innerhalb der Netzwerkstacks der privilegierten Umgebung stattfinden. Da der betrachtete Cluster derzeit VLANs verwendet um sicherheitskritische Teile des Netzwerkes voreinander zu schützen, wurde ein Konzept erarbeitet welches die Trennung von Wirten und Gästen in verschiedene VLANs ermöglicht. Abbildung 4.4 zeigt eine solche Konfiguration. Zu sehen ist, dass die physikalische Schnittstelle zunächst in verschiedene VLAN-Schnittstellen aufgetrennt wird. In der privilegierten Umgebung kann eine dieser Schnittstellen verwendet werden. Die andere VLAN-Schnittstelle wird, wie oben beschrieben, in eine Netzwerkbrücke eingekoppelt. Ist der verfügbare Adressvorrat knapp, so kann überlegt werden Wirts- und Gastsysteme in verschiedene Teilnetze zuzuordnen. So ist es denkbar, die Wirtssysteme in ein 24

25 Router/Switch privilegierte Umgebung phy eth bridge vif0 vif1 Gast0 Gast1 eth eth Abbildung 4.3: Darstellung des Netzwerkbrücken-Konzepts eigenes privates Teilnetz zu versetzen. Da für den Dialogbetrieb jedoch ohnehin eine direkte Kommunikation zwischen Gast und Wirt notwendig ist (siehe nächster Abschnitt), und ein solches Vorgehen ein zusätzliches Routing notwendig machen würde, wurde auf ein solches Konzept zu Gunsten des Implementierungsaufwandes verzichtet. 4.5 Dialogbetrieb Der Dialogbetrieb, das heißt die Nutzung einer grafischen Arbeitsumgebung, stellt nach den Erkenntnissen der Evaluation ein weiteres zu lösendes Problem dar. Eine direkte Interaktion mit dem Gastsystem ist nur mittels netzwerktransparenter Dienste möglich. Grafikhardware, Maus und Tastatur werden nicht virtualisiert und stehen deshalb innerhalb der Gastsysteme nicht zur Verfügung. Eine umsetzbare Möglichkeit entstammt dem Linux-Terminal-Server-Projekt [LTSa], dessen Ziel die entfernte Nutzung ressourcenstarker Rechner ist. Sogenannte Thin-Clients werden als Frontend verwendet. Innerhalb des Projektes hat sich die Nutzung des X eigenen XDMC-Protokoll durchgesetzt. Dieses erlaubt die Nutzung eines im Netzwerk entfernten X-Server obwohl die Ein- und Ausgabe Hardware des lokalen Systems genutzt wird. 25

26 Trennung der Netze von Wirt und Gästen auf MAC Ebene (VLAN) privilegierte Umgebung Router/Switch phy eth (VLAN 6) eth (VLAN 8) bridge vif0 vif1 Gast0 Gast1 eth eth Abbildung 4.4: Darstellung der Netzwerkbrücken-Konzepts mit VLANs Dieses Konzept kann leicht auf das bestehende Problem übertragen werden ein X- Server innerhalb der privilegierten Domain kann verwendet werden um ein Gastsystem zu bedienen. Leider kommt die Nutzung von XDMCP nicht in Frage Nutzersitzungen werden terminiert sobald die Verbindung abbricht, da die Sitzungsverwaltung auf Seiten des Frontends realisiert ist. Die Verwendung von VNC bietet hier eine passende Alternative. VNC basiert auf einem modifizierten X-Server welcher im Gastsystem installiert werden kann. Innerhalb des Gastsystems kann nun ein eigener Displaymanager verwendet werden, welcher die Nutzersitzungen auf Seite des Gastsystems verwaltet. Das Trennen des Frontends stellt so kein Problem mehr dar. Innerhalb der privilegierten Umgebung muss nun nur noch ein Kiosk -Terminal laufen welches die Verbindung zum korrespondierenden Gastsystem herstellt. Die Interaktion des Nutzers mit der virtualisierten Umgebung wird also über ein netzwerktransparenten Dienst ermöglicht. Abbildung 4.5 veranschaulicht dieses Vorgehen. Durch die Verwendung von VNC ist die Nutzung von Maus, Tastatur und Bildschirm ermöglicht worden. Dies ermöglicht die Anwendung von vielen typischen Applikation, jedoch besteht keine Möglichkeit USB-Lauwerke oder Audiogeräte zu verwenden. 26

27 Benutzer Direkte Interaktion mit der Hardware durch die privilegierte Umgebung. Workstation privilegierte Umgebung X Server VNC Viewer Indirekte Interaktion des Nutzers mit dem Gastsystem durch netzwerktransparente Dienste (hier VNC) Gast VNC Server X Client Abbildung 4.5: Interaktion des Nutzers mit dem Gastsystem mittels netzwerktransparenter Dienste Innerhalb des LTS-Projektes gibt es auch hierfür Lösungen. Sie funktionieren auf ähnliche Weise. USB-Laufwerke und Audiohardware werden über netzwerktransparente Protokolle verfügbar gemacht. Für Audiohardware kann hier PulseAudio zum Einsatz kommen. Auf dem Frontend läuft ein Soundserver mit Hardwarezugriff auf die Soundkarte, das System, welches die Hardware nutzen möchte, kann sich über ein Netzwerkprotokoll mit diesem Soundserver verbinden und so indirekt die Soundhardware nutzen [PAU]. Für USB-Laufwerke existiert ein netzwerktransparentes Dateisystem. Es besteht aus zwei Komponenten: Ein Server-Dämon auf der Frontend-Seite stellt die tatsächlichen Dateisysteme auf dem USB-Laufwerk im Netzwerk zur Verfügung, ein FUSE-Modul auf der Gegenseite verbindet sich mit diesem Dämon und stellt diese im Zielsystem bereit [LTSb]. 27

28 4.6 Gastsystem Als Gastsystem kommt prinzipiell jedes bestehende Betriebssystem in Frage, es müssen jedoch einige Details beachtet werden. Da die Rechner keine Hardwareunterstützung für Virtualisierung besitzen, muss das Gastsystem an den paravirtualisierten Betrieb angepasst sein. Dieses Kriterium erfüllen momentan alle GNU basierten Betriebssysteme. Damit Gäste effizient relokalisiert werden können ist es außerdem notwendig ihre Wurzeldateisysteme auf netzwerktransparenten Speicher auszulagern. Im Zusammenhang mit Xen werden meist sehr schnelle Hardware-SAN-Lösungen verwendet [SBZD07]. Da der Cluster jedoch nicht über solche Hardware verfügt wird hier auf NFS zurückgegriffen. Um die Wartbarkeit zu erhöhen soll das Gastsystem zentral installiert werden. Um den konkurrierenden Schreibzugriff zu umgehen (und eine damit verbundene Korrumpierung des Systems) darf das verteilte Dateisystem nur-lesend eingehängt werden. Dies führt jedoch zu Problemen: Das Betriebssystem muss auf sein Wurzeldateisystem auch schreibend zugreifen können. Als Beispiel sei hier die Datei utmp angegeben, welche Buchführungsinformationen über aktuell eingeloggte Benutzer enthält. Diese muss während des Betriebes beschreibbar sein. Um dieses Problem zu lösen wird ein Copy-On-Write Wurzeldateisystem verwendet, wie es auch auf vielen Linux-Live-CDs eingesetzt wird. Über das nur lesbare NFS wird transparent ein beschreibbares Dateisystem gelegt welches sich im Hauptspeicher befindet. Schreibzugriffe werden abgefangen und in dieses schreibbare Dateisystem geleitet (Copy-On-Write). Lesezugriffe werden durch sämtliche Ebenen geleitet und liefern so als Ergebnis die Vereinigung aller vereinten Dateisysteme. Abbildung 4.6 zeigt ein solches vereintes Wurzeldateisystem für Wirt und Gast. Bestehende Implementierungen sind zum Beispiel UnionFS und AUFS (Another-UnionFS). instanziiert Wirt NFS für Checkpoints schreibend UnionFS Wurzeldateisystem lesend/schreibend NFS lesend tmpfs schreibend Gast UnionFS Wurzeldateisystem lesend/schreibend NFS lesend tmpfs schreibend NFS Server /srv/host /srv/host /srv/guest Abbildung 4.6: Darstellung der Dateisysteme im System 28

29 Um das Gastsystem im Dialogbetrieb nutzen zu können muss es natürlich eine grafische Oberfläche besitzen und den in Abschnitt 4.5 beschriebenen VNC Dienst zur Verfügung stellen. 4.7 Wirtssystem Das Wirtssystem muss mit einem funktionsfähigen Xen-System ausgerüstet sein, um Gastsysteme zu beherbergen. Insbesondere muss es die Relokalisierung von Gästen ermöglichen. Das in Abschnitt 4.6 vorgestellte Konzept des Copy-On-Write Wurzeldateisystems, zur Verwendung eines einzigen nur-lesend Dateisystems für sämtliche Gäste, kann auch auf das Wirtssystem übertragen werden. So kann das Wirtssystem auch zentral verwaltet werden. Der Wartungsaufwand wird so minimiert: Trotz der Verdoppelung der Systeme innerhalb des Clusters müssen lediglich zwei Images gepflegt werden. Soll ein Checkpoint eines Gastsystems erstellt werden kann dieses nun nicht mehr ohne weiteres im Wirtssystem gespeichert werden; das Wurzeldateisystem ist zwar beschreibbar, bietet jedoch nur wenig Platz da es sich im Hauptspeicher befindet. Eine einfache Lösung des Problems bietet ein weiterer NFS-Share (siehe Abbildung 4.6). Wird der Kernel des Wirtssystems nun auch noch aus dem Netzwerk gebootet, so ist die Integration neuer Workstations in den Cluster sehr einfach möglich. 4.8 Infrastruktur Aus den vorhergehenden Überlegungen kann nun festgelegt werden welche Infrastruktur für die Umsetzung des Konzeptes notwendig ist: Für die Netzwerkeingliederung wird ein funktionierendes DNS/DHCP System benötigt. Für die Wurzeldateisysteme des Wirts- und Gastsystems wird ein NFS benötigt. Für das speichern von Checkpoints wird ein NFS benötigt. Für das booten der Wirtssysteme aus dem Netzwerk ist ein TFTP-Server notwendig. 29

30 5 Implementierung Das folgende Kapitel beschreibt die Implementierung des in Kapitel 4 beschriebenen Systems. Ziel ist die Erstellung eines Wirts-, sowie eines exemplarischen Gastsystems. Vorgefertigte Abbilder befinden sich auf der diesem Dokument beiliegenden CD im Verzeichnis /dist; sie können für eine Schnellinstallation verwendet werden. Referenzierte Skripte und Konfigurationsdateien befinden sich auf der CD unterhalb des Verzeichnisses /src. Verweise darauf werden kursiv dargestellt. Verzeichnisse in der Installationsumgebung werden in Schreibmaschinenschrift dargestellt. 5.1 Technik Für die Umsetzung des Entwurfs wurde die Linux Distribution Debian Etch in der zum Entwicklungszeitpunkt aktuellen Version 4.0 verwendet. Debian bietet vielfältige Möglichkeiten zur Anpassung an neue Einsatzszenarien und ist hervorragend dokumentiert. Außerdem wird es bereits für die Workstations des Clusters verwendet. Zur Programmierung werden BASH-Skripts verwendet, welche in die von Debian bereitgestellte Infrastruktur integriert werden. 5.2 Infrastruktur des Systems Für die Implementation wurden zunächst vier Rechner des Clusters verwendet. Der Rechner lliira dient der Entwicklung und stellt ein NFS zur Verfügung. Es werden insgesamt folgende drei NFS-Shares benötigt: 1. Wurzeldateisystem des Wirtssystems 2. Wurzeldateisystem des Gastsystems 3. schreibbarer Netzwerkspeicher zur Speicherung von Checkpoints, welcher innerhalb des Wirtssystems eingebunden wird Die verwendete Konfiguration für NFS ist unter../ext/etc/exports zu finden. Sie kann als Vorlage für die Integration in ein Produktivsystem dienen. Der Rechner leira wird als Serversystem verwendet. Auf ihm sollen virtuelle Umgebungen migriert werden, sofern sie nicht im Dialogbetrieb verwendet werden. Zwei weitere Rechner ( mask und malar ) sollen als Workstationrechner verwendet werden. Auf ihnen wird das Wirtssystem betrieben. 30

31 mask Wirtssystem im Desktopmodus mit Frontend 1:1 1:1 malar Wirtssystem im Desktopmodus mit Frontend mask-vm malar-vm Zusammenfassung der Wirtssysteme zur Reduzierung des Implementierungs- und Wartungsaufwandes Switch leira Wirtssystem im Servermodus ohne Frontend Infrastruktur DNS DHCP TFTP lliira Entwicklungssystem NFS Wirtssysten Gastsystem Checkpoint-Storage Server Abbildung 5.1: Darstellung der verwendeten Infrastruktur zur Implementierung Zusätzlich entsteht für jeden dieser Rechner eine virtuelle Umgebung die als Arbeitssystem verwendet wird. Die Cluster Infrastruktur stellt bereits DHCP, DNS sowie TFTP Dienste zur Verfügung, so dass diese vom System genutzt werden können. Abbildung 5.1 veranschaulicht diese Situation. Die mit Server umrandeten Komponente ließen sich in einem späteren Produktivsystem alle auf einem einzigen Rechner betreiben, dabei wäre es auch möglich die Dienste innerhalb eigener virtuellen Umgebungen zu betreiben. 5.3 Wirtssystem Das Wirtssystem hat drei grundlegende Funktionen: Es beherbergt virtuelle Umgebungen. Es wird als Frontend für virtuelle Umgebungen verwendet. Er verwaltet die korrespondierende virtuelle Umgebung. Um die Implementierung des Gesamtsystems übersichtlich zu halten wird der Server zunächst auch mit dem Wirtssystem betrieben er stellt dann allerdings keine Fron- 31

32 tend Funktionalität zur Verfügung und muss auch keine Logik zur Verwaltung der Gäste besitzen Basissystem Zur Erzeugung des Basissystems kommt das Tool debootstrap zum Einsatz. Es ist in der Lage eine minimale Installation der Distribution Debian zu erzeugen. Nach der Erzeugung eines Verzeichnisses (welches per NFS verteilt wird) kann die Installation wie folgt vorgenommen werden: mkdir / srv / host debootstrap etch / srv / host http : / / f t p. de. debian. org / debian Anschließend werden zunächst einige Grundlegenden Einstellungen angepasst, dazu werden die entsprechenden Dateien in das System übertragen: host/etc/fstab Die Dateisystemtabelle muss angepasst werden damit der Wirt das beschreibbare Dateisystem zur Speicherung von Checkpoints verwenden kann. host/etc/hosts Der Rechnername für das Loopback-Interface wird gesetzt. host/etc/network/interfaces Eine Basiskonfiguration für das Loopback-Interface muss vorgenommen werden. Anschließend kann in das neu erzeugte System gewechselt werden, um weitere Komponenten zu installieren. Dies geschieht wie folgt: chroot / srv / host Innerhalb des neuen Systems werden nun die Basiskomponenten für eine privilegierte Xen Umgebung installiert. Das Metapaket xen-linux-systen xen-686 enthält den Hypervisor, Kernel, entsprechende Module und den Xen-Control-Dämon. Dieser Dämon wickelt die Instantiierungen und Migrationen von Gastsystemen ab. Außerdem muss eine an den paravirtualisierten Betrieb angepasst C-Bibliothek installiert werden. Unter Verwendung der Debian Paketverwaltung ist dies wie folgt möglich: apt get i n s t a l l xen linux systen xen 686 l i b c 6 xen Für die Umsetzung des in Abschnitt 4.4 beschriebenen Netzwerkbrücken-Konzeptes werden außerdem die bridge-utils benötigt: apt get i n s t a l l bridge u t i l s 32

33 5.3.2 UnionFS Um das System von einem nur-lesbaren Dateisystem zu betreiben soll UnionFS verwendet werden. Vorher müssen die Xen-Kernel-Header installiert werden, damit das Kernelmodul übersetzt werden kann. Die Installation wird von Debian durch das Tool moduleassistant unterstützt und erfolgt weitgehend automatisch: apt get i n s t a l l linux headers xen 686 apt get i n s t a l l unionfs source module a s s i s t a n t l xen 686 a i u n i o n f s Inital RAM Filesystem Während frühere Linux-Kernel die Funktionalität enthielten, Netzwerkkarten zu konfigurieren um anschließend von ihnen zu booten, verwenden modernere Kernelversionen eine sogenannte Initial-Ramdisk. Es handelt sich dabei um ein komprimiertes Dateisystem welches ein minimales Wurzeldateisystem enthält und vom Kernel in den Arbeitsspeicher geladen wird. Innerhalb dieser minimalen Umgebung kann der Kernel zunächst konfiguriert werden (zum Beispiel Module nachladen), bevor das minimale Wurzeldateisystem durch das echte ersetzt wird. Um eine solche Init-Umgebung zu erzeugen verwendet Debian die initramfs-tools. Diese ermöglichen eine systematische Anpassung dieser Umgebung. Dazu werden sogenannte Hooks verwendet um Änderung zum Erzeugungszeitpunkt vorzunehmen. Die kann zum Beispiel das Hinzufügen zusätzliche Module oder Binaries in die Ramdisk sein. Außerdem können Skripts in die Ramdisk aufgenommen werden, welche während des Bootvorgangs innehalb der Init-Prozedur ausgeführt werden, zum Beispiel die Einbindung von UnionFS oder das konfigurieren des Netzwerkes. Eine entsprechende Konfiguration für die initramfs-tools kann von host/etc/initramfstools in das neue System übertragen werden. Diese enthält ein Hook-Skript welches die bridge-utils in die Init-Umgebung kopiert. Außerdem enthält sie Skripts um das Netzwerk während des Bootvorgangs zu konfigurieren. Hierbei wird das einfache Netzwerkbrücken -Konzept verwendet (siehe Abschnitt 4.4). Ein weiteres Skript hängt das Wurzeldateisystem mittels UnionFS ein. Nachdem die Konfigurationsdateien entsprechend übertragen wurden, muss die Ramdisk lediglich neu erstellt werden: update i n i t r a m f s u v Migrationsstrategie Um die in Abschnitt 4.3 beschriebene Migrationsstrategie umzusetzen muss die Konfiguration des Xen-Control-Dämons aus host/etc/xen in das System übertragen werden. Diese ist bezüglich der Netzwerkkonfiguration angepasst sie sorgt dafür, dass bei der Instantiierung neuer Gäste die virtuellen Netzwerkschnittstellen in die, während des Bootvorgangs erzeugte, Netzwerkbrücke gehängt werden. Dies geschieht über ein Skript 33

34 welches ausgeführt wird, sobald ein Gastsystem erzeugt wird. Außerdem wird innerhalb dieser Konfiguration der Relokalisierungsdienst gestartet. Zusätzlich enthält diese Konfiguration die Einstellungen für die Gastsysteme. Hier wird angegeben von welchem NFS-Verzeichnis die Gäste gebootet werden sollen und wieviel Arbeitsspeicher ihnen zur Verfügung stehen soll. Es liegen Einstellungsdateien für drei Maschinen bei; anhand dieser sollte die Erstellung weiterer Gastsysteme leicht vorzunehmen sein. Es fehlt jedoch noch ein Kernel und eine Initram-Disk für den Gast, diese werden wir später hinzufügen. Nachdem der Xen-Dämon konfiguriert ist, wird das Verzeichnis host/etc/xen+ in das neue System übertragen. Es enthält eine Konfigurationsdatei welche die Zuordnung von Wirts- und Gastsystemen vornimmt. Dies geschieht über die vom DNS vergebenen symbolischen Namen jedem Wirt wird eine virtuelle Umgebung mit dem Suffix -vm zugeordnet. Dies kann an dieser Stelle leicht angepasst werden, so ist zum Beispiel die Zuordnung über eine Tabelle denkbar. Da der Server zunächst auch mit dem Wirtssystem betrieben werden soll, kann in der Konfigurationsdatei angegeben werden welcher Rechner der Server sein soll. Außerdem enthält das Verzeichnis eine Skript-Bibliothek, welche Funktionen bereitstellt, die von mehreren der verwendeten Skripts benötigt werden. Um die verschiedenen Abläufe aus Abbildung 4.2 umzusetzen, müssen die drei Skripts aus host/usr/sbin und das Init-Skript host/etc/init.d/xen+-restore dem System hinzugefügt werden. Das Init-Skript übernimmt die Instantiierung der virtuellen Umgebung abhängig von ihren Zustand. Die drei anderen Skripts stoßen jeweils eine der in Abschnitt 4.3 beschriebenen Benutzerentscheidungen an. Anschließend muss das Init-Skript noch aktiviert werden, so dass es beim booten ausgeführt wird. Wichtig ist das dies nach dem Start des Xen-Control-Dämon geschieht. Dies kann durch folgendes Vorgehen erreicht werden: update rc. d xen+ r e s t o r e d e f a u l t s 90 Das Relokalisieren von virtuellen Maschinen ist jeweils auf dem aktuellen Wirtssystem der Umgebung anzustoßen. Das Init-Skript nutzt SSH um eine Migration vom Server auf die Workstation anzustoßen. Die Installation des SSH-Dienstes kann wie folgt vorgenommen werden: apt get i n s t a l l openssh s e r v e r Anschließend muss die Konfiguration aus host/etc/ssh übertragen werden. Sie deaktiviert die strikte Schlüsselverifikation; dies sorgt dafür, dass nicht jeder Wirt separat als bekannter Rechner konfiguriert werden muss. In einem Produktivsystem sollte dies aus Sicherheitsgründen umgestellt werden. Um einen Zugriff zwischen den Wirtssystemen zu ermöglichen muss ein Schlüssel erzeugt werden. Jeder Wirtsrechner vertraut diesem Schlüssel, so ist ein Zugriff zwischen allen Wirtssystemen möglich. In einem Produktivsystem wäre nur der Zugriff vom jeweiligen Wirt auf den Server notwendig die Zusammenlegung der Wirts- und Serverfunktionalität macht ein solches 34

35 Vorgehen erforderlich. Ein fertig generiertes Schlüsselpaar kann aus host/root in das System übertragen werden. Um das beschreibbare Netzwerkdateisystem zur Speicherung von Checkpoints in das Wirtssystem einzuhängen werden die NFS Userspace-Tools benötigt. Diese können wie folgt installiert werden: apt get i n s t a l l nfs common Da Debian Netzwerkdateisysteme beim aktivieren des Netzwerkinterfaces einbindet, und dieses bereits in der Init-Umgebung geschehen ist, muss ein weiteres Init-Skript den Einbindevorgang anstoßen. Das Skript kann von host/etc/init.d/xen+-network übertragen werden und anschließend aktiviert werden: update rc. d xen+ network d e f a u l t s Frontend Das Frontend läuft innerhalb der privilegierten Umgebung. Für die Interaktion mit dem Gastsystem soll VNC zum Einsatz kommen. Zunächst erfolgt die Installation des X- Window-Systems: apt get i n s t a l l xserver xorg core xorg Auf den verwendeten Workstations wird der Nvidia-Treiber benötigt, um die native Auflösung der an sie angeschlossenen Displays verwenden zu können. Zunächst muss der Quellcode des Kernelmoduls installiert werden. Dazu werden die contrib und non-free Repositories der Distribution benötigt. Diese können aktiviert werden in dem die Datei host/etc/apt/sources.list in das System kopiert wird. Anschließend werden zunächst die Modulquellen installiert: apt get nvidia kernel source Dieses Kernelmodul ist nicht mit der Xen-C-Bibliothek kompatibel und muss daher zunächst gepatcht werden [Nvi]. Dazu wird zunächst der Quellcode des Moduls entpackt und anschließend der Patch host/nvidia-patch.txt angewendet. Der module-assistant unterstützt (wie bei UnionFS) das Übersetzten und Installieren des Moduls: mkdir n v i d i a cd n v i d i a t a r x z f / usr / s r c / nvidia kernel source. t a r. gz patch p1 < nvidia_patch. t x t MODULE_LOC=tmp/ modules module a s s i s t a n t l xen 686 \ unpack once b u i l d n v i d i a module a s s i s t a n t l xen 686 i n s t a l l n v i d i a Nachdem das Kernelmodul installiert ist, fehlt noch der Userspace Treiber für das X-Window-System. Dieser kann unverändert aus der Distribution verwendet werden: apt get i n s t a l l nvidia glx 35

36 Zum Abschluss der Installation von X wird muss noch eine an die Hardware der Workstations angepasste Konfiguration in das System übertragen werden diese kann aus dem Verzeichnis host/etc/x11 in das Wirtssystem kopiert werden. Neben den richtigen Einstellungen für Grafikkarte, Tastatur und Maus wird zusätzlich das Starten von X durch einen User ermöglicht, dem nicht das aktuelle Terminal gehört. Dies ist notwendig um das Frontend unter einer unprivilegierten Benutzerkennung zu betreiben Das Betreiben des Frontends als unprivilegierter Benutzer soll eine Korrumpierung des Wirtssystems erschweren. Zunächst wird ein neuer Benutzer angelegt: adduser xen Die Skripts zum Herunterfahren, Migrieren und Checkpoint erstellen müssen mit Administratorprivilegien ausgeführt werden. Um auch dem Frontendbenutzer dies zu erlauben wird sudo verwendet. Es ermöglicht die Ausführung von System-Skripts durch unprivilegierte Benutzer. Es kann wie folgt installiert werden: apt get i n s t a l l sudo Eine entsprechende Konfiguration befindet sich in host/etc/sudoer und kann in das System übertragen werden. Um die Verbindung mit dem Gastsystem herzustellen wird ein VNC-Viewer benötigt. Dieser kann wie folgt installiert werden: apt get i n s t a l l xvncviewer Um die Auslösung der Shutdown-Skripts mittels Tastenkombinationen zu ermöglichen, und so eine unkomplizierte Bedienung durch den Benutzer zu gewährleisten, wird das Paket xbindkeys verwendet. Es ermöglicht die Zuordnung von Skripts zu Tastenkombinationen. Voreingestellt sind: STRG+ALT+M: Migration des Gastes und herunterfahren der Workstation. STRG+ALT+S: Herunterfahren des Gastes und der Workstation. STRG+ALT+C: Checkpoint des Gastzustandes erstellen und herunterfahren der Workstation. Um dem User ein visuelles Feedback über seine Aktion zu geben wird xosd verwendet. Dies ermöglicht die Ausgabe von Text auf dem Wurzelfenster des X-Window-Systems. Die benötigten Pakete können wie folgt installiert werden: apt get i n s t a l l xbindkeys xosd bin Zum Abschluss der Installation des Frontends müssen noch die Konfiguration für xbindkeys und einige Wrapper-Skripts aus host/home/xen in das System übertragen werden. Diese Wrapper-Skripts erzeugen eine OSD-Ausgabe bevor die vom Benutzer erwünschte Aktion durchgeführt wird. Abbildung 5.2 zeigt den Bildschirminhalt eines Wirtssystems bei der Benutzung als Frontend nachdem eine Migration gestartet wurde. 36

37 Um das Frontend schließlich beim Booten zu starten muss nur noch das entsprechende Init-Skript aus host/etc/init.d/xen+-frontend übertragen und aktiviert werden. Die Ausführung dieses Init-Skripts sollte nach der Ausführung des Init-Skripts zur Umsetzung der Migrationsstrategie erfolgen. Eine Aktivierung kann wie folgt stattfinden: update rc. d xen+ frontend d e f a u l t s 95 Abbildung 5.2: Bildschirminhalt während der Migration (Vollbildmodus des VNC- Viewers zur Veranschaulichung deaktiviert) Monitor Um einen Überblick über den Systemstatus zu ermöglichen, soll der Status des Wirtssystems auf einem Terminal einsehbar sein. Dazu wird ein Xen-Monitor verwendet, welcher alle laufenden VMs auflistet. Dieser Monitor läuft unter derselben Benutzerkennung wie das Frontend. Auf welchen Terminal der Monitor angezeigt wird kann in der xen+- Konfiguration eingestellt werden. Um die Verwendung eines Terminals zu ermöglichen werden die console-tools benötigt. Diese werden wie folgt installiert: apt get i n s t a l l console t o o l s Mit dem Init-Skript host/etc/init.d/xen+-monitor kann der Monitor beim Booten gestartet werden. Dazu wird es in das System übertragen und wie folgt aktiviert: 37