Virtuelle Server als Container für verteiltes Rechnen

Virtuelle Server als Container für verteiltes Rechnen am Beispiel Xen und Reliable Server Pooling Johannes Formann Essen, 10.11.2008

Zusammenfassung In diesem Dokument werden die Erfahrungen bei der Entwicklung eines Prototypen zur Nutzung von virtuellen Servern als Plattform für verteiltes Rechnen beschrieben, und unter dem Aspekt des Overheads bewertet. Abstract In this document the developement of a prototype that manages virtual servers as a platform for distributed computing is described. The performance of this prototype is later evaluated and compared to the existing Reliable Server Pooling Scripting Service. Danksagung Ich bedanke mich bei der Unterstützung durch den Lehrstuhl Technik der Rechnernetze, insbesondere bei dem der Arbeit Betreuer Thomas Dreibholz, bei der Erstellung der Arbeit. ii

Abbildungsverzeichnis 1 Basisstruktur von virtuellen Servern..................... 4 2 Struktur von Betriebssystemvirtualisierung................. 4 3 Schema für vollständige Virtualisierung................... 5 4 Schema für teilweise Virtualisierung..................... 6 5 Schema für Typ-1 Virtualisierungslösung.................. 6 6 Schema für Typ-2 Virtualisierungslösung.................. 7 7 Architektur von Reliable Server Pooling nach[22].............. 12 8 Protokollablauf zwischen Pool User und Pool Element ohne Fehlersituationen und Keep-Alive Paketen....................... 18 9 Zustandsmaschinen des Pool Users..................... 20 10 Zustandsmaschinen des Pool Elements................... 22 11 Gesamtlaufzeiten des Scripting-Service und des Xen Scripting Services bei jeweils 5 Läufen................................ 38 12 Laufzeiten der Pakete beim Scripting Service bei 5 verschiedenen Läufen 39 13 Laufzeiten der Pakete beim Xen Scripting Service bei 5 verschiedenen Läufen..................................... 41 iii

Tabellenverzeichnis 1 Zuordnung existierender Virtualisierungstechniken............. 7 2 Aggregierte Messwerte OMNeT++ Läufe.................. 33 3 Durchschnittliche Laufzeit eines Paketes beim Scripting Service..... 40 4 Durchschnittliche Laufzeit eines Paketes beim Xen Scripting Service... 40 iv

Abkürzungsverzeichnis ASAP Aggregate Server Access Protocol BOINC Berkeley Open Infrastructure for Network Computing BSD Berkeley Software Distribution COW Copy on Write CPU central processing unit / Hauptprozessor ctx security context patch ENRP Endpoint Handlespace Redundancy Protocol IP Internet Protokoll KVM Kernel-based Virtual Machine LXC LinuX Container OMNeT++ Objective Modular Network Testbed in C++ PE Pool Element PH Pool Handle PR Pool Registrar PU Pool User RSerPool Reliable Server Pooling QEMU Quick Emulator SCTP Stream Control Transmission Protocol SETI Search for Extraterrestrial Intelligence v

Inhaltsverzeichnis I Einleitung 1 1 Vorwort 1 2 Leitidee für die Bachelorarbeit 1 3 Bestehende Lösungen zum verteilten Rechnen 2 3.1 BOINC-Framework.............................. 2 3.2 XGrid..................................... 2 3.3 Proprietäre Systeme............................. 2 3.4 Sun GridEngine................................ 3 3.5 Xenoserver................................... 3 II Techniken 3 4 Virtuelle Server 3 4.1 Definition................................... 3 4.2 Aufbau..................................... 4 4.2.1 Betriebssystemvirtualisierung.................... 4 4.2.2 Systemvirtualisierung......................... 5 4.3 Existierende Virtualisierungslösungen.................... 7 4.4 Einsatzgebiete für virtuelle Servern..................... 8 4.5 Nachteile von virtuellen Servern....................... 9 5 Xen 9 5.1 Struktur.................................... 9 5.2 Optionen.................................... 10 5.3 Libvirt..................................... 10 6 Reliable Server Pooling (RSerPool) 11 6.1 Terminologie & Funktionsverteilung..................... 11 6.2 Aufbau..................................... 12 6.3 Der Prototyp - rsplib............................. 12 6.4 Scripting Service............................... 13 III Implementierung 13 7 Anforderungen an den Prototypen 13 7.1 Anforderung an den Dienst für verteiltes Rechnen in virtuellen Servern. 13 vi

8 Aufbau des Prototypen 15 8.1 Kommunikation................................ 16 8.1.1 Nachrichten.............................. 16 8.2 Protokollablauf................................ 17 8.3 Pool User................................... 19 8.4 Pool Element................................. 21 9 Implementierung 22 9.1 Pool User / Client.............................. 23 9.2 Pool Element................................. 24 9.2.1 XSSserver.h.............................. 24 9.2.2 XSSserver.cc.............................. 24 9.2.3 XSScontrol.............................. 25 9.3 Wrapper für den Scripting-Service...................... 26 IV Tests 26 10 Versuchsaufbau 26 10.1 Verwendete Hardware............................. 26 10.2 Genutzte Software.............................. 27 10.3 Konfiguration................................. 27 10.3.1 Image-Konfiguration für Scriptingservice-Kompatibilität..... 28 10.3.2 Kurze Läufe (OMNeT++)...................... 29 10.3.3 Lange Läufe.............................. 29 10.4 Messung.................................... 31 11 Auswertung der OMNeT++ Test 31 11.1 Erwartungen.................................. 31 11.2 Beobachtungen................................ 33 11.3 Bewertung................................... 34 12 Auswertung der Langläufertests 35 12.1 Erwartungen.................................. 35 12.2 Beobachtungen................................ 38 12.3 Bewertung................................... 41 V Zusammenfassung 42 13 Zusammenfassung & Ausblick 42 13.1 Zusammenfassung............................... 42 13.2 Offene Themen................................ 43 vii

VI Anhang 44 A Skripte zur Verwaltung und zur Ermittlung der Messergebnisse 44 A.1 xssdistribute.................................. 44 A.2 Startskript für Xen Scripting Service bei der Nutzung von Templates.. 46 A.3 Benchmark-Skript OMNeT++........................ 47 A.4 test1.r..................................... 49 A.5 unreliable.sh.................................. 49 A.6 Benchmark-Skript dnetc........................... 50 A.7 Für dnetc angepasstes ssrun-skript..................... 52 B Messergebnisse 53 C Quelltext 60 C.1 XSSpackets.h................................. 60 C.2 XSSclient.cc.................................. 64 C.3 Pool Element / XSSserver.......................... 81 C.3.1 XSSserver.h.............................. 81 C.3.2 XSSserver.cc.............................. 84 C.3.3 XSScontrol.............................. 108 Literatur 109 viii

Teil I Einleitung 1 Vorwort In dieser Ausarbeitung wird die Konzeption und Entwicklung des Prototypen zum verteilten Rechnen in virtuellen Maschinen auf Basis von Xen dokumentiert, und die gewonnenen Erkenntnisse präsentiert. Im Folgenden wird zunächst kurz die zugrunde liegende Idee vorgestellt, welche motivierte die Arbeit zu beginnen. In Teil II werden die verwendeten Techniken/Software präsentiert und im Teil III wird die Implementierung erklärt. Im Teil IV werden die durchgeführten Tests vorgestellt und ausgewertet, damit zum Schluss in Teil V ein Resümee gezogen werden kann. 2 Leitidee für die Bachelorarbeit Die Idee für die Bachelorarbeit ist zu überprüfen, in wieweit sich virtuelle Server als Container für das verteilte Rechnen eignen. Virtuelle Server bieten den Vorteil, dass in ihnen auch potentiell schädlicher Code ausgeführt werden kann ohne das Hostsystem zu gefährden. Verschiedene Untersuchungen[27, 16, 18, 17] haben gezeigt, dass der Overhead bei CPUlastigen Workloads sehr gering ist Daher liegt der Fokus dieser Arbeit darauf, die Infrastruktur 1 zu betrachten. Dazu werden die in dem Projektseminar[25] erarbeiteten Erfahrungen mit einer Verwaltung von virtuellen Servern mit dem Reliable Server Pooling Framework für die Verwaltung von virtuellen Servern genutzt, um ein neuen auf Reliable Server Pooling basierenden Prototypen zu schreiben, der auf die Bedürfnisse des verteilten Rechnens angepasst ist. Details werden in Kapitel 7 und 8 vorgestellt. Dieser Prototyp wird dann genutzt, um bei dem Scripting Service (siehe Kapitel 6.4 und [23]) eine sichere Ausführungsumgebung zur Verfügung zu stellen ohne die vorhandenen Skripte anpassen zu müssen 2. 1 die Verteilung der dafür notwendigen Daten, Starten der Systeme 2 eine Anpassung ist natürlich notwendig um zwischen den beiden Techniken zu wechseln, diese soll sich jedoch auf ein Minimum beschränken. 1

3 Bestehende Lösungen zum verteilten Rechnen Es existieren zum Zeitpunkt der Arbeit eine Reihe von anderen Projekten zum verteilten Rechnen, von den im folgenden einige kurz Vorgestellt werden, und die Unterschiede zu den realisierten Prototypen aufgezeigt. 3.1 BOINC-Framework Das BOINC[15, 3] Framework (Berkeley Open Infrastructure for Network Computing) ist ein populäres Framework um verteilte Rechenaufgaben an große Nutzerkreise zu verteilen. Es wird von Projekten wie SETI@home[5], Einstein@home[8], ClimatePrediction[7] und vielen anderen genutzt. Im Gegensatz zu den Prototypen müssen Programme die dieses Framework nutzen möchten an die API angepasst werden, und die Nutzer, welche die Rechenzeit zur Verfügung stellen, müssen den Programmen vertrauen. Zentral gespeicherte Sicherungspunkte sind nicht vorgesehen. Der große Vorteil des BOINC-Frameworks ist, dass es bereits auf einer sehr großen Anzahl von Rechnern installiert ist, und für viele Plattformen bereit steht. 3.2 XGrid XGrid[13] ist ein von Apple entwickelte Plattform für verteiltes Rechnen. Es ermöglicht leicht die verteilte Ausführung von Batch-Jobs, welche sich als Kommandozeilenprogramme ausführen lassen. Es gibt von Dritten entwickelte Clients in Java[12] und C[14], mit denen dann auch auf verschiedenen Plattformen die Berechnung verteilt werden kann. Im Gegensatz zu dem Prototypen werden keine Sicherungspunkte zentral gespeichert und auf den Rechner, auf den die Berechnung ausgeführt wird, muss den Programmen vertraut werden. Eine Anpassung der Programme ist aufgrund der Batch-Architektur selten notwendig. 3.3 Proprietäre Systeme Bei den proprietären Systemen, wie zum Beispiel beim distributed.net Projekt verwendet werden, gelten die schon beim BOINC-Framework aufgeführten Nachteile auch. Zusätzlich ist die Programmierung aufwendiger, da die Infrastruktur selber implementiert werden muss. 2

3.4 Sun GridEngine Die GridEngine[10] von Sun ist eine Plattform für das verteilte Rechnen, mit ausgefeilten Queuing-Strategien und Policies. Da die GridEngine die Verteilung auf Basis von Batch-Jobs vornimmt, ist keine Anpassung der Programme notwendig. Es werden zusätzlich, sofern durch das Programm oder das Betriebssystem unterstützt, Sicherungspunkte ermöglicht. Es werden aber auch hier die auszuführenden Programme nicht isoliert, so dass man den Bytecode vertrauen muss. 3.5 Xenoserver Das Xenoserver[11] Projekt nutzt virtuelle Server um verteiltes Rechnen in sicheren Containern zu ermöglichen. Es bietet die Möglichkeit die Rechenzeit an Dritte zu verkaufen, benötigt aber damit zur Abbrechnung auch eine verhältnismäßig komplizierte Infrastruktur. Es besitzt jedoch im Gegensatz zu dem implementierten Prototypen keine Möglichkeit Sicherungspunkte anzulegen. Teil II Techniken 4 Virtuelle Server 4.1 Definition Im Rahmen dieser Arbeit ist ein virtueller Server, auch kurz vserver genannt, als eine Instanz einer Betriebssystem- oder Hardwarevirtualisierung 3 definiert. Ein virtueller Server stellt sich aus Benutzersicht fast 4 wie ein echtes System dar, der aber unter der Kontrolle eines Virtualisierungssystem läuft, welches den Betrieb mehrerer virtueller Server auf einem Server erlaubt. 3

Abbildung 1: Basisstruktur von virtuellen Servern 4.2 Aufbau Der prinzipielle Aufbau eines Virtualisierungssystem, zum Betrieb von virtuellen Servern, ist in Abbildung 1 dargestellt. Auf der Hardware 5 läuft das, hier noch nicht näher definierte, Virtualisierungssystem. Das Virtualisierungssystem übernimmt die folgenden Aufgaben: Die Ressourcenzuweisung zu den virtuellen Servern (RAM, CPU-Zeit, Speichermedien, Zugriff auf das Netzwerk und evtl. Peripheriegeräte). Die Isolation zwischen den verschiedenen virtuellen Servern. Die virtuellen Server dürfen nicht in der Lage sein Ressourcen zu ändern die einem anderen virtuellen Server exklusiv zugeteilt wurden. Die Verwaltung der virtuellen Server (starten, stoppen u.u. weitere). Zur Realisierung des Virtualisierungssystems gibt es es verschiedene Ansätze, die wichtigsten werden im Folgenden vorgestellt. 4.2.1 Betriebssystemvirtualisierung Abbildung 2: Struktur von Betriebssystemvirtualisierung Bei der Betriebssystemvirtualisierung läuft ein gemeinsam genutzter Betriebssystemkern, welcher die unterschiedlichen virtuellen Server isoliert, so dass jeder virtuelle Server nur die ihm zugeordneten Daten, Programme und Prozesse sehen und nutzen kann. Der schematische Aufbau ist in Abbildung 2 dargestellt. Die Folgenden Lösungen sind in diesen Ansatz zuzuordnen: OpenVZ/Virtuoozzo, CTX, BSD-Jails, Solaris-Zones. 3 Die Virtualisierung führt eine Abstrahierungsschicht ein, welche es erlaubt die Ressourcen eines Computers aufzuteilen. 4 Je nach verwendeter Technik gibt es einige Einschränkungen. Diese Betreffen meist die Hardwareunterstützung oder den Betriebssystemkern. 5 Es gibt auch (nicht X86) Systeme, die ein einfaches Virtualisierungssystem in Hardware unterstützen. 4

Die Vorteile sind der sehr geringe Overhead und die Möglichkeit Ressourcen dynamisch nach Bedarf zu verteilen (insbesondere RAM/Swap). Die Nachteile sind, dass man auf eine bestimmte Betriebssystemversion für alle virtuellen Server auf dem System festgelegt ist. Auch ist häufig die Funktionalität des Kernels für die virtuellen Server eingeschränkt 6. Aus konzeptueller Sicht der größte Nachteil ist, dass durch den geteilten Kernel die Isolation im Fehlerfalle relativ gering ist. 4.2.2 Systemvirtualisierung Bei der Systemvirtualisierung wird für jeden virtuellen Server ein eigenes Betriebssystem gestartet. Diese sind voneinander unabhängig. Dabei sind meistens verschiedene Betriebssysteme, zumindest verschiedene Betriebssystemversionen, auf einem Virtualisierungssystem möglich. Man unterscheidet dabei nach dem Funktionsumfang zwischen der vollständigen Systemvirtualisierung, auch Hardwarevirtualisierung genannt, und der teilweisen Systemvirtualisierung, auch Paravirtualisierung genannt. Nach der Implementierung unterscheidet man zwischen Typ-1 Virtualisierungslösungen, bei denen der Hypervisor 7 direkt auf der Hardware aufsetzt, und Typ-2 Virtualisierungslösungen, die auf ein laufendes Betriebssystem aufsetzen. Abbildung 3: Schema für vollständige Virtualisierung vollständige Systemvirtualisierung / Hardwarevirtualisierung Bei der vollständigen Virtualisierung emuliert das Virtualisierungssystem für die virtuellen Server das Verhalten von real existierender Hardware. Emuliert werden dabei nur die Ein- und Ausgabegeräte, wie auch in Abbildung 3 skizziert, nicht die CPU, da es sich sonst um Systememulationen handelt. Daher laufen die Gastsysteme ohne weitere Anpassungen, vorrausgesetzt es gibt Treiber für die bereitgestellte Hardware 8. Der Vorteil an diesem Vorgehen ist, dass Systeme ohne Anpassungen installiert oder von bestehenden Servern kopiert werden können, und auch Betriebssysteme laufen, die nicht 6 z.b. Module laden, logische Geräte einrichten, Imagedateien mounten, Netzwerkfilter einrichten 7 Der wichtigste Teil einer Virtualisierungslösung, regelt den Zugriff auf die Ressourcen 8 Es wird meistens sehr verbreitete Hardware emuliert, sodass in der Regel Treiber vorhanden sind. 5

auf ein Virtualisierungssystem angepasst werden können 9. Der Nachteil an diesem Vorgehen ist, dass durch die Emulierung der Hardware relativ viele Ressourcen 10 benötigt werden. Abbildung 4: Schema für teilweise Virtualisierung teilweise Systemvirtualisierung / Paravirtualisierung Bei der teilweisen Systemvirtualisierung stellt das Virtualisierungssystem, wie in Abbildung 4 zu sehen, den virtuellen Servern ein API zur Kommunikation bereit. Dieses API ermöglicht einen effizienten Datentausch zwischen den virtuellen Servern und dem Virtualisierungssystem, muss aber von den jeweiligen Betriebssystemen unterstützt werden. Der Vorteil ist, der im Vergleich zur vollständigen Virtualisierung, deutlich reduzierte Overhead. Der Nachteil ist, dass das Betriebsystem, welches in den virtuellen Server laufen soll, zur Unterstützung der API modifiziert werden muss, was nicht immer möglich ist 11. Abbildung 5: Schema für Typ-1 Virtualisierungslösung Typ-1 Virtualisierung / Typ-1 Hypervisor Bei den Typ-1 Virtualisierungslösungen, teilweise auch Bare Metal Hypervisor genannt, läuft der Hypervisor 12 direkt auf der Hardware. Das Schema dazu ist in Abbildung 5 dargestellt. Dieser Ansatz hat als Vorteil, dass eine sehr gute Isolation der virtuellen Server möglich ist und die Ressourcenzuweisung sehr gut kontrolliert werden kann. Durch das direkte Laufen auf der Hardware ist der Overhead verhältnismäßig gering. 9 z.b. weil der Quelltext nicht verfügbar ist (Windows) oder sich der Aufwand nicht lohnen würde (Linux 2.2 Kernel) 10 vor allen CPU-Leistung, aber auch RAM. 11 zu hoher Aufwand, oder keinen Zugriff auf den Quellcode 12 der Kern der Virtualisierungslösung, der die Ressourcenzuteilung & Kontrolle übernimmt 6

Als Nachteil ist zu sehen, dass der Hypervisor etwas komplexer wird, da die Hardware vom Hypervisor verwaltet werden muss. Abbildung 6: Schema für Typ-2 Virtualisierungslösung Typ-2 Virtualisierung Bei den Typ-2 Virtualisierungslösungen, teilweise auch Hosted Hypervisor genannt, läuft der Hypervisor als Programm in einem Betriebssystem. Das Schema dazu ist in Abbildung 6 dargestellt. Dieser Ansatz hat als Vorteile, dass die Installation meistens einfach ist und die Virtualisierungslösung keine Hardwaretreiber benötigt. Als Nachteil ist zu sehen, dass durch das Betriebssystem und durch das Laufen ohne Betriebssystemprivilegien 13 ein deutlich höherer Overhead vorhanden ist. 4.3 Existierende Virtualisierungslösungen Die Tabelle 1 ordnet verschiedene auf dem Markt für X86-Systeme befindliche Virtualisierungslösungen den zuvor beschriebenen Eigenschaften zu. Typ-1 Typ-2 Hardwarevirtualisierung VMware ESX Server Xen mit Intel VT oder AMD-V Technik Linux KVM mit Intel VT oder AMD-V Technik VMware Workstation/Server/Player Virtual PC von Microsoft Parallels Workstation QEMU mit Modul kqemu (sonst Emulator) Paravirtualisierung Xen User-Mode-Linux Tabelle 1: Zuordnung existierender Virtualisierungstechniken 13 bei X86 Hardware die Ring-0 Rechte 7

4.4 Einsatzgebiete für virtuelle Servern Der Einsatz von virtuellen Server ermöglicht eine Konsolidierung von Servern und eine flexiblere Verwaltung der Ressourcen. Serverkonsolidierung: Das Ziel bei der Serverkonsolidierung ist es, viele wenig ausgelastete oder alte Server auf wenige leistungsfähige Server zusammenzufassen und dadurch Betriebskosten 14 zu sparen. Virtuelle Server werden aus verschiedenen Gründen gebraucht: Verschiedene Dienste sollen auf unterschiedlichen Systemen laufen, um die Gefahr von Fehlerausbreitungen 15 zu reduzieren. Es handelt sich um Produktions-, Test- und Backupsystem. Verschiedene Dienste setzen inkompatible Betriebssysteme voraus oder sind anderweitig inkompatibel 16. Dabei muss man im Einzelfall schauen welche Ansprüche an die Lösung gestellt werden. Falls zum Beispiel eine sehr hohe Isolation der unterschiedlichen virtuellen Server gefordert wird, fallen die Betriebssystemvirtualisierungslösungen häufig aus. Flexible Verwaltung der Ressourcen: Durch das Abstrahieren von der Hardware können virtuelle Server viel leichter dem Bedarf angepasst werden, sofern entsprechende Ressourcen vorhanden sind. Beispielsweise kann einem virtuellen Server ein höherer Anteil an CPU & RAM zugewiesen werden, falls dieser hoch belastet ist oder auch recht einfach auf einen anderen, leistungsfähigeren, Server umgezogen werden. Auch können virtuelle Server oft sehr schnell bei Bedarf installiert werden, da das Virtualisierungssystem verschiedene Hilfen dafür anbietet 17. Isolierung von nicht vertrauenswürdigen Programmen: virtuelle Server bieten auch die Möglichkeit Programme, denen nicht vertraut wird 18, in einem isolierten Container laufen zu lassen und damit keinerlei Zugriff auf die Daten des Hostsystems zu geben. Es kann als Sonderfall der Serverkonsolidierung gesehen werden, da die Alternative ein Server pro Programm wäre. 14 z.b. Strom, Klimatisierung, Wartung 15 d.h. wenn Dienst A ein Problem bekommt, und dabei sogar evtl. das Betriebssystem beeinträchtigt, soll Dienst B weiter funktionieren 16 z.b. wollen gleiche Netzwerkports öffnen 17 z.b. die Möglichkeit Vorlagen zu erstellen, bei denen dann nur noch die jeweils Individuellen Parameter gesetzt werden müssen, wie der Name des Systems oder die IP-Nummer 18 z.b. Verdacht auf implementierte Hintertüren, Schadfunktionen etc. 8

4.5 Nachteile von virtuellen Servern Virtuelle Server bringen aber auch einige Nachteile mit sich: Die Virtualisierungslösung erzeugt zusätzlichen Overhead Bei einem Hardwaredefekt sind, aufgrund der Serverkonsolidierung, in der Regel mehr Systeme betroffen. Es gibt zusätzlichen Administrations- und Verwaltungsaufwand Installation und Wartung des Virtualisierungssystems Planen der Ressourcenzuteilung, berücksichtigen welche virtuellen Server zusammen auf einen Server passen (von den Ressourcenbedarf), und evtl. auch welche nicht zusammen auf einen Server dürfen (z.b. Produktivsystem und Backupsystem) 5 Xen Xen[1, 2] ist ursprünglich ein Typ-1 System zur teilweisen Systemvitualisierung Mit aktuellen Prozessoren 19 ist auch vollständige Systemvirtualisierung möglich. Xen wurde an der Universität von Cambridge ursprünglich für das XenoServers-Projekt entwickelt[6]. Da Xen als Virtualisierungslösung für dieses Projekt gewählt wurde, wird es im folgenden vorgestellt. 5.1 Struktur Der Xen-Hypervisor läuft als Typ-1 Hypervisor direkt auf der Hardware. Um den Xen- Hypervisor klein zu halten, ist in diesen nur die Speicherverwaltung, das Prozessormanagement, Basis-Treiber die die BIOS-Funktionen nutzen und die virtuellen Kommunikationskanäle implementiert. In aktuellen Versionen kommen u.a. zusätzliche Funktionen hinzu, um Energiespartechniken nutzen zu können. Die Hardware wird dabei von der privilegierten 20 Domain-0, das ist der erste virtuelle Server der automatisch gestartet wird, verwaltet 21. Die Domain-0 kommuniziert dabei über spezielle Kanäle 22 mit dem Hypervisor, wie die anderen virtuellen Server auch. 19 die Intels Vanderpool oder AMDs Pacifica Technik unterstützen 20 die anderen virtuellen Server haben normalerweise keinerlei direkte Zugriffsmöglichkeit auf die angeschlossene Hardware 21 Einzelne Geräte können auch anderen virtuellen Servern zugewiesen werden, falls eine Reihe von Bedingungen erfüllt ist. 22 meistens als Ringpuffer implementiert 9

Damit die verschiedenen virtuellen Server nur auf den zugewiesenen RAM zugreifen können, werden die Betriebssystemkernel bei der Paravirtualisierung in dem Ring-1 23 betrieben. Bei der vollständigen Systemvirtualisierung werden die Speicherbereichen für die virtuellen Server in den Non-Root-Mode [29] versetzt und damit die Rechte ausreichen beschränkt, sodass für den virtuellen Server alle 4 CPU-Ringe zur Verfügung stehen und der Kern damit normal im Ring-0 laufen kann. 5.2 Optionen Xen bietet neben einem recht geringen Overhead (siehe [16, 24]) eine Reihe von Features, die die Verwaltung von virtuellen Servern vereinfachen: virtuelle Server können ohne Downtime 24 auf andere Server migriert werden, sofern einige Bedingungen erfüllt sind der Speicher, auf dem das Image 25 des virtuellen Servers liegt muss auf beiden beteiligten Servern zugreifbar sein der Zielserver muss die gleichen CPU-Befehle oder eine Obermenge davon unterstützen die Netzwerkverbindung muss umgeleitet werden können. (Entweder gleiches L2-Netzwerk oder die Möglichkeit passende Routen zu setzen) dem virtuellen Server darf keine Hardware zugewiesen sein. virtuelle Server können zu Wartungs- 26 oder Debugzwecken angehalten werden. Es ist dabei möglich den Speicherinhalt in eine Datei zu schreiben. Dank eines sehr flexiblen CPU-Schedulers ist es möglich sowohl Gewichtungen bei der CPU-Nutzung anzugeben, als auch feste Verteilungen vorzugeben. Dies kann auch gemischt werden. 5.3 Libvirt Libvirt[9] ist eine Bibliothek, welche für verschiedene Virtualisierungslösungen 27 eine (möglichst) einheitliche und stabile API bietet und mit C,C++ und Python direkt genutzt werden kann. Für weitere Sprachen wie Perl, OCaml, Ruby, Java und C# stehen auch Bindings zur Verfügung. 23 Die X86-Architektur bietet 4 verschiedene Sicherheitsringe mit abnehmenden Privilegien an. Dabei hat Ring-0 hat sämtliche Rechte, auch für sog. sensitive Befehle, und die Ringe 1-3 hierarchisch abfallende Rechte. D.h. ein Prozess in Ring-1 kann auch auf Speicherbereiche von Ring-3 zugreifen, aber nicht umgekehrt. 24 für einen kurzen Zeitraum, normalerweise deutlich kürzer als 1 Sekunde, wird der virtuelle Server angehalten, um die letzten unsauberen Speicherseiten zu kopieren 25 der persistente Speicher für den virtuellen Server welcher u.a. das Betriebssystem enthält 26 z.b. Erstellung eines Backups/Schnappschuss 27 aktuell: Xen, QEmu, (Linux) KVM, LXC und OpenVZ 10

Das API bietet Funktionen, die für die Verwaltung von virtuellen Servern benötigt werden. Dazu gehört unter Anderen das Anlegen der Konfiguration, Starten & Stoppen von virtuellen Servern, Informationen über den Zustand des Hostsystems und der virtuellen Server zu liefern. Die libvirt nutzt bei Xen direkte Schnittstellen zu den jeweiligen Daemon, so dass die Performance im Vergleich zu den Kommandozeilenwerkzeugen deutlich besser ist. Da die Daten in nativen Datentypen geliefert werden, ist keine Konvertierungen notwendig, was die Programmierung erleichtert. Libvirt bietet zudem eine API, um die verschiedenen Speichersysteme zu verwalten, die mögliche Grundlagen für virtuelle Server sind. 6 Reliable Server Pooling (RSerPool) Mit Reliable Server Pooling wird vom IETF[4, 26] eine Architektur spezifiziert, welche logische Sitzungen eines Clients mit einem Pool von Servern verwaltet. Dabei stehen sowohl Mechanismen zur Lastverteilung auf die im Pool befindlichen Servern bereit, als auch zur Fehlererkennung und für die Unterstützung eines Failovers auf ein funktionierendes Pool Element. Reliable Server Pooling nutzt SCTP als Transportprotokoll, um auf Netzwerkebene eine hohe Sicherheit & Verfügbarkeit erzielen zu können. 6.1 Terminologie & Funktionsverteilung (Server) Pool: Eine Gruppe von Servern, die den gleichen Dienst anbieten. Pool Handle (PH): Das eindeutige Identifikationsmerkmal eines Server Pools, welches zur Unterscheidung von Server Pools dient. Pool Element (PE): Ein einzelner Server in einem Pool. Besitzt eine im Pool eindeutige ID, die Pool Element ID. Pool User (PU): Ein Client, der den Dienst nutzt. Pool Policy: Regel die vorgibt, nach welchen Kriterien ein neuer Nutzer auf die Pool Elements verteilt werden soll. Mögliche Pool Policys sind u.a. Round Robin (abwechseln), Random (zufällige Verteilung), Least Used (der die geringste Last hat). Pool Registrar (PR): Verwaltet den Pool (Welche Pool Elemets sind verfügbar, u.u. die dort herrschende Last) und löst für anfragende Pool-Usern das Pool Handle in Adressen der Pool Elements auf, unter Beachtung der Pool Policy. Endpoint Handlespace Redundancy Protocol (ENRP): Protokoll, das zwischen Pool Registrars genutzt wird, um auf allen PR eine konsistente Sicht auf den Pool zu haben.[22, 30, 28] 11

:&(0%/7('; 2< 8=(7-=/)>?77%&?$$%/&7'/,77%@A BCD@E?77%&FG%/",&;?",($H I/%(-*J%K#>",'*L=&(>%77%&LI% 6%$%#*2&%HMBA @NO OPD>QEDQ 3,KH MBA @NO OPD>QDQD :&(0%/7('; 2< 8=(7-=/)>?77%&?$$%/&7'/,77%@A BCD@E?77%&FG%/",&;?",($H /,'*)%-J%K#>",'*L=&(>%77%&LI% 6%$%#*2&%HMBA @NO OPD>QEQN 3,KH MBA @NO OPD>QDQD R-7'/,S'T 6*% +%$(,-$%.%/0%/ 122$(&) +.%/122$U #/2> '2S2$ 7=('% S=// %&'$; =&I%/ 7',&I,/I(9,'(2& -; '*%!?63 (7 I%7()&%I'2 -=($I 7;7'%"7#/20(I(&) *()*$;,0,($,-$% 7%/0(S%7 -; "%S*,&(7"7,&I #/2'2S2$7 <2/ %7',-$(7*(&)F S2&V)=/(&)F,SS%77(&),&I "2&('2/(&) #22$7 2< 7%/0%/ /%72=/S%7L W=' +.%/122$ (7 &2' 2&$;,-$% '2 ",&,)% #22$7 2< /%I=&I,&' 7%/0%/7,&I <,S($(','% 7%/0(S% <,($20%/ -%'4%%& 7%/0%/7H (',$72 (&S$=I%7 72#*(7'(S,'%I "%S*,&(7"7<2/ 7%/0%/ 7%$%S'(2&7 4('*(& '*% #22$7L 6*%7%"%S*,&(7"7",5% +.%/122$ =7%<=$ <2/,##$(S,'(2&7 (& $2,I -,$,&S(&),&I I(7'/(- ='%I S2"#='(&) 7S%&,/(27L R7 #,/' 2< 2=/ +.%/122$ /%7%,/S*,&I '2 0%/(<; /%7=$'7 2< 2=/ 7("=$,'(2& "2I%$ (& /%,$>$(<% 7S%&,/(27F 4% *,0% S/%,'%I, S2"#$%'% ("#$%"%&','(2& #/2'2';#% 2< '*% +.%/> 122$ </,"%42/5L!& '*(7 #,#%/F 4% 4($$ )(0%, I%',($%I I%7S/(#'(2& 2< '*% S2&S%#'7F (I%,7,&I /%,$(9,'(2&7 2< 2=/ #/2'2';#%L 3=/'*%/"2/%F 4% 4($$ 7*24 #%/<2/",&S% (77=%7 /,(7%I -; '*% ",&,)%"%&' 2< $,/)% 7%/0%/7 #22$7F,7 (' (7 &%S%77,/;<2/ $2,I -,$,&S(&) 2/ I(7'/(- ='%I S2"#='(&) 7S%&,/(27LX% 4($$ %K#$,(& '*%,$)2/('*"7,&I I,', 7'/=S'=/ %7 4% I%7()&%I'2 72$0% '*%7%S*,$$%&)%7,&I V&,$$; #/%7%&', /2=)* #%/<2/",&S% %0,$=,'(2& '*,' 0%/(V%7 2=/ S2&S%#'L Y%;42/I7H!&'%/ &%',##$(S,'(2&7F!10E I%#$2;"%&',&I,##$(S,'(2&7F..QF7%/0%/ #22$7 RL ^2'(0,'(2&!L +?Z!RWZ?.?+[?+ 1\\Z!]G 3()L OL 6*% +.%/122$R/S*('%S'=/% Abbildung 7: Architektur von Reliable Server Pooling nach[22] 7#%S(VS <,($20%/ #/2S%I=/%7,&I (&S2&7(7'%&',##$(S,'(2& '2 I(<<%/%&'..Q,I,#','(2&$,;%/7L 6*% S2&0%/)%&S%2< S$,77(S,$S(/S=('>74('S*%I&%'42/57 Aggregate Server Access WL Protocol!&'/2I=S'(2& (ASAP): Das Protokoll, welches zwischen den PU (L%L 1.6]_!.8]U,&I I,', &%'42/57 (L%L!1>-,7%IU(7 /,#(I$; #/2)/%77(&)L6*(7 und ("#$(%7 den '*,' PR 1.6] und 7()&,$$(&) zwischen 62 S2#% den 4('* PE '*% S*,$$%&)% und PR 2< S/%,'(&) genutzt, =&(V%IF wird.[19, 28] Es regelt die Registrierung, 0%/; *()* voni%)/%% PE2< und I,&S; die 72$='(2& Auflösung 7%% abb <2/ I%',($7UF von PH '*%!?63 zu+%$(,-$% Serveradressen. 0(, '*%..Q #/2'2S2$ (7 '/,&7#2/'%I20%/!1 &%'42/57L $()*'4%()*'F /%,$>'("%F 7S,$,-$%,&I %K'%&I,-$% /%I=&>.(&S%..Q7()&,$$(&)&%'42/572<<%/,0,($,-($('; %L)L,' "27' ON "(&='%7I24&'("% #%/ ;%,/.%/0%/ 122$(&) X2/5(&) G/2=# 4,7 <2=&I%I '2 7#%S> <2/,&; 7()&,$$(&) /%$,'(2&7*(# -%'4%%&'42 7()&,$$(&) (<;,&I I%V&% '*% +%$(,-$%.%/0%/ 122$(&) S2&S%#'L R& %&I#2(&'7`<2/ "2/% (&<2/",'(2& 7%% aobuf,$$ $(&57,&I 20%/0(%4 2< '*%,/S*('%S'=/%S=//%&'$; =&I%/7',&I,/I(9,> S2"#2&%&'72< '*% &%'42/5 I%0(S%7 "=7' -% /%I=&I,&'L '(2&,&II%7S/(-%I-; 7%0%/,$!&'%/&%' 8/,<'7 (7 7*24& (& X*%& '/,&7#2/' 6.2 (&) 7()&,$$(&) Aufbau 20%/!1 &%'42/57F 7=S* V)=/% OL /%I=&I,&S; S2&S%#'7,$72 *,0% '2 -%,##$(%I '2,S*(%0% ^=$'(#$% 7%/0%/ %$%"%&'7#/20(I(&) '*% 7,"%7%/0(S% '*% /%c=(/%i,0,($,-($(';l Z(&5 /%I=&I,&S; (&!1 &%'> -%$2&)'2, 7%/0%/#22$ '2 #/20(I% -2'* /%I=&I,&S;,&I 42/57(7 7=##2/'%I=7(&)'*%.'/%,"d2&'/2$ Der Aufbau der Reliable 6/,&7"(77(2& Server 7S,$,-($(';L Pooling.%/0%/ #22$7 Architektur,/% (I%&'(V%I -;, ist =&(c=% in Abbildung!8 7 abgebildet. Man 1/2'2S2$.d61 a@bf adbf I%',($7 <2$$24 (& 7%S'(2&!!U` S,$$%I#22$ *,&I$% 1eU 4('*(& '*% 7%'2<,$$ 7%/0%/ #22$7F /%I=&I,&S; 2< kann &%'42/5dabei I%0(S% S2"#2&%&'7(7 gut die 7=##2/'%I drei logischen '*% *,&I$%7#,S%L Elemente R 7%/0%/ (&(Pool, #22$ (7 User, S,$$%I, Registrare #22$ und Pool Elements) -; '*%.G1_R.1 erkennen 7()&,$$(&) ),'%4,; und #/2S%77_,##$(S,'( deren Kommunikationsbeziehungen. 2& %$%"%&' 1?U 2< '*% /%7#%S'(0% #22$L 6*% *,&I$%7#,S% 7%/0%/ #/2S%77US2&S%#'aObL e24%0%/f '*(7 S2&S%#'*,7 (7 ",&,)%I-; /%I=&I,&'/%)(7'/,/7 1+UL 6*% /%)(7'/,/7 72"%$("(','(2&7H &2 7=##2/'2< I;&,"(S,II('(2&,&I/%> 7;&S*/2&(9%'*%(/ 0(%4 2< '*% *,&I$%7#,S%=7(&) '*%?&I> "20,$ 2< S2"#2&%&'7F Da die $("('%I Reliable 4,;72< 7%/0%/ Server 7%$%S'(2&F&2 Pooling #2(&' *,]I$%7#,S%+%I=&I,&S; Architektur sehr 1/2'2S2$ hohe?]+1acbul Verfügbarkeit 1+7 ermöglichen soll, können, wie in der Abbildung 7 auch zu erkennen, die Serverdienste auf mehrere Geräte verteilt werden. Die Pool Registare gleichen sich dabei über das ENRP-Protokoll ab und können gleichzeitig mehrere Pools verwalten. Die Pool Elements melden sich mit dem ASAP-Protokoll bei einem Registrar an (den so genannten Home-Registrar), der danach periodisch die Erreichbarkeit des Pool Elements überprüft. Ein Pool User fragt über das ASAP-Protokoll einen beliebigen PR, der dann einen (oder auch mehrere) nach der Pool Policy ausgewählte PE zurück liefert. Zu dem ersten Eintrag wird dann versucht eine Verbindung aufzubauen. Zwischen den PU und dem PE wird dann das Anwendungsspezifische Protokoll gesprochen. Je nach Anwendung muss das Protokoll ergänzt werden, um den in der Reliable Server Pooling Architektur vorgesehene Failover bei einem Ausfall eines PE zu ermöglichen. 6.3 Der Prototyp - rsplib Der Prototyp rsplib[20] wurde maßgeblich von Thomas Dreibholz entwickelt. Als Lizenz wurde die GPL gewählt. 12