Server-Virtualisierung und Konsolidierung im Rechenzentrumsbetrieb

Inhaltsverzeichnis

Vorwort

Kurzfassung

Abstract

1 Inhalt und Zweck der Arbeit

2 Grundlagen der Virtualisierung
2.1 Konzept der Virtualisierung
2.1.1 Entstehung des Virtualisierungs-Ansatzes
2.1.2 Ziele der Virtualisierung
2.1.3 Prinzip ohne Virtualisierung
2.1.4 Prinzip mit Virtualisierung
2.2 Prinzipien der Virtualisierung
2.2.1 Grundlegende Prinzipien
2.2.2 Prozessor-Berechtigungsmodell
2.2.3 Speicherverwaltung
2.2.4 Betriebssystemarchitektur
2.2.5 Prozesssteuerung und Multitasking
2.2.6 Exkurs: Emulation
2.3 Virtualisierungstechniken
2.3.1 Grundlegende Virtualisierungstechniken
2.3.2 Spezielle Virtualisierungstechniken
2.4 Varianten der Virtualisierung
2.4.1 Transparente Virtualisierung
2.4.2 Paravirtualisierung
2.5 Hardwareunterstützte Virtualisierung
2.5.1 Prozessorsteuerung
2.5.2 Hauptspeicherzugriffe

3 Virtualisierungslösungen
3.1 Virtualisierungsprodukte
3.1.1 Hypervisor-Klassen
3.2 VMware
3.2.1 VMware Server/Workstation/Player
3.2.2 VMware ESX Server und Virtual Infrastructure
3.3 Xen
3.3.1 Open Source Xen und XenSource
3.4 Microsoft
3.4.1 Microsoft Virtual PC und Virtual Server

4 Performance
4.1 Theoretische Performance
4.1.1 Trap-and-Emulate
4.1.2 Binary Translation
4.1.3 Paravirtualisierung
4.2 Praktische Performance
4.2.1 Xen
4.2.2 VMware
4.2.3 Benchmarks
4.2.4 Paravirtualisierung
4.3 Weitere Bewertungskriterien

5 Virtualisierung im Einsatz
5.1 Allgemeines
5.2 Entwicklung
5.3 Definitionen
5.3.1 Verfügbarkeit
5.3.2 Datenschutz
5.3.3 Datensicherheit
5.4 Verfügbarkeit
5.4.1 Hardware
5.4.2 SAN-Anbindung
5.4.3 LAN-Anbindung
5.4.4 Geplanter Ausfall
5.4.5 Ungeplanter Ausfall
5.4.6 Storage-Subsysteme
5.5 Datenschutz
5.6 Datensicherheit
5.7 Kosten

6 Spezielle Fragestellungen
6.1 Virtualisierung im Vergleich
6.1.1 Hardware
6.1.2 Lizenzierung
6.1.3 LAN-Anbindung
6.1.4 SAN-Anbindung
6.1.5 Standardisierung
6.1.6 Vertraulichkeit
6.1.7 Integrität
6.1.8 Verfügbarkeit
6.1.9 Schutzbedarf
6.2 Virtuelles Switching
6.3 Unterschiedlicher Schutzbedarf

7 Zusammenfassung und Ausblick

8 Referenzen
8.1 Literaturverzeichnis
8.2 Weblinks

9 Anhang
9.1 Anhang A
9.2 Anhang B

Vorwort

Im Jahr 2001 wurde ich zum ersten Mal auf eine Virtualisierungssoftware namens VMware Workstation, damals noch in der Version 2, aufmerksam.

Es war für mich das geeignete Werkzeug, umfangreiche Testinstallationen zur Vorbereitung einer größeren Netzwerkumstellung durchzuführen. Verschiedene Windows-Arbeitsgruppen und mehrere Windows-NT-Domänen sollten in einer neuen Active-Directory-Domänenstruktur konsolidiert werden. Dies alles musste ressourcenneutral ohne Anschaffung neuer Hardwaresysteme geschehen; denn die Bestandssysteme waren für den Verwendungszweck ausreichend performant und aktuell.

Die Verwendung einer Virtualisierungssoftware war also Mittel zum Zweck. Ich konnte die einzelnen Arbeitsschritte gefahrlos testen, und der Neuaufbau des Active Directory konnte in großen Teilen parallel zum Produktionsbetrieb der Bestandssysteme erfolgen.

Seit diesem Zeitpunkt ist die Verwendung paralleler, virtualisierter Betriebssystemumgebungen aus meinem administrativen Alltag nicht mehr wegzudenken.

Mit der Weiterentwicklung von VMware Workstation wurde das Produkt immer stabiler und performanter, so dass ich Notfallsysteme in Form virtueller Maschinen für einige wichtige Serversysteme implementierte. Für den Routinebetrieb waren solche virtuellen Systeme noch nicht geeignet, aber immerhin konnte damit schon eine Grundverfügbarkeit sichergestellt werden.

Nachdem ich im Jahr 2004 meine Tätigkeit im Rechenzentrum des Universitätsklinikums Bonn aufgenommen hatte, wurde ich mit dem Projekt der Einführung einer Virtualisierungs-Infrastruktur auf der Basis von VMware ESX Server für den Produktionsbetrieb betraut. Seitdem betreue und koordiniere ich den Betrieb und den weiteren Aufbau dieser Virtualisierungslösung, die inzwischen als Primärplattform für produktive Serverinstallationen im Rechenzentrum etabliert ist.

In dieser Diplomarbeit beschäftige ich mich mit den theoretischen Grundlagen von Virtualisierung sowie den Besonderheiten von Virtualisierung auf der Basis von x86-Hardware.

Im Laufe meiner Beschäftigung mit dieser Thematik hat sich gezeigt, dass das Verständnis der Grundlagen von Virtualisierung hilfreich, wenn nicht gar unerlässlich in der Arbeit mit virtualisierten und zu virtualisierenden Systemen ist.

Zudem möchte ich in dieser Arbeit aufarbeiten, wie Virtualisierung auf der Basis von VMware im praktischen und produktiven Einsatz genutzt werden kann und wo die Grenzen von Virtualisierungslösungen liegen.

Mein Dank gilt Herrn Prof. Dr.-Ing. Alfred Scheerhorn, der die Betreuung dieser Diplomarbeit im Fachbereich IT-Sicherheit an der Fachhochschule Trier übernommen hat.

Ebenso gilt mein Dank der Geschäftsleitung des Zentralbereichs für Information und Steuerung des Universitätsklinikums Bonn, die mir im Jahr 2004 die Möglichkeit geboten hat, ein interessantes Aufgabengebiet zu übernehmen, und es mir ermöglicht hat, alle notwendigen Termine des Studiums wahrzunehmen.

Das Studium der Informatik habe ich als nebenberufliches Fernstudium in den vergangenen fünf Jahren als Zweitstudium absolviert. Dabei gilt besonderer Dank meiner Familie – vor allem meiner Frau und meinen Eltern, die mich immer wieder motiviert haben und mir die notwendigen Freiräume geschaffen haben, ein solches Studium neben einer vollen beruflichen Tätigkeit durchführen zu können.

Neuwied, im Februar 2008

Kurzfassung

Die vorliegende Diplomarbeit befasst sich mit der Verwendung von Virtualisierungstechniken im Rahmen von Serverkonsolidierungen. Dabei werden die am Rechenzentrum des Universitätsklinikums Bonn im Produktionsbetrieb verwendeten Verfahren beschrieben und bewertet.

Bei der Verwendung von Hardware auf der Basis von x86-Architekturen ergeben sich für den Einsatz von Virtualisierungslösungen besondere Anforderungen an die Entwicklung von Virtualisierungssoftware. Zudem beschränkt sich die Verwendung von Virtualisierungslösungen im Produktionsumfeld nicht auf den Betrieb von Systemumgebungen, sondern erfordert auch weitere Funktionalitäten zur Unterstützung von Hochverfügbarkeit, Datensicherheit und Datenschutz.

Auf der Grundlage einer theoretischen Einführung in die Grundlagen von Virtualisierung und der speziellen Problematik von Virtualisierung auf x86-Hardware wird ein Überblick über die Virtualisierungslösungen von VMware, Xen und Microsoft gegeben.

Anhand der Systembeschreibung einer Virtualisierungs-Infrastruktur auf der Basis des produktiven Einsatzes von VMware im Rechenzentrum des Universitätsklinikums Bonn wird das Verfahren aus Sicht der IT-Sicherheit bewertet. Die vorgestellten Verfahren und Lösungen stehen jeweils im Vergleich zu einer fiktiven Lösung mit einem konventionellen Ansatz unter Verwendung physischer, nicht virtualisierter Hardware.

Dabei erweist sich eine virtualisierte Serverinfrastruktur auf der Grundlage von VMware als uneingeschränkt produktionstauglich, sowohl unter den Aspekten der Systemperformance als auch vor dem Hintergrund von Anforderungen der IT-Sicherheit und im Hinblick auf die Frage nach der Wirtschaftlichkeit.

Abstract

This diploma thesis expands on the use of virtualization technology in within consolidation of servers. A description and an evaluation is worked out for the processes in productive operations in Bonn University Hospitals Data Center.

There are certain requirements for the development of virtualization solutions when using hardware based on the x86 architecture. In addition to the practical use of virtualization for operating systems environments there is a need to provide further functionality to support high availability, safety and security.

Based on an abstract view of virtualization and a special view of virtualization on x86 hardware a review is given for the software solutions from VMware, Xen and Microsoft.

An evaluation is provided from the point view of IT-Security for the virtualization environment in the University of Bonn Hospitals Data Center. The discussed processes and solutions are compared to a fictitious scenario based on the use of physical, non-virtualized hardware.

As a result the VMware virtualized infrastructure of servers proves to be unrestricted suitable for productive operations, as well as for requirements of IT-Security and for economic needs.

1 Inhalt und Zweck der Arbeit

Die vorliegende Arbeit soll einen Überblick über die Möglichkeiten der Virtualisierung von Betriebssystemumgebungen auf der Basis von x86-Hardware geben.

Dabei liegt der Schwerpunkt der Betrachtung auf dem Ziel der Virtualisierung von Serversystemen in Produktivumgebungen, besonders im Einsatz von Windows Server.

Im theoretischen Teil dieser Arbeit werden die Probleme und Besonderheiten bei der Virtualisierung von Betriebssystemumgebungen auf der x86-Hardwareplattform ausführlich erläutert; darüber hinaus werden die beiden Virtualisierungslösungen von VMware und Xen verglichen.

Die Konsolidierung vieler physikalischer Systeme auf einer oder mehreren Virtualisierungsplattformen wird dabei vorrangig aus technischer Sicht bewertet. Hierbei werden die Aspekte Verfügbarkeit, Datensicherheit und Datenschutz aus den Themengebieten der IT-Sicherheit behandelt.

Im praktischen Teil dieser Arbeit wird eine Virtualisierungslösung im Produktivbetrieb am Beispiel einer VMware-ESX-Server-Umgebung im Rechenzentrum des Universitätsklinikums Bonn beschrieben.

Dort waren nicht nur Kostengründe für die Entscheidung zum Aufbau einer Virtualisierungsumgebung maßgeblich; vor allem die Möglichkeiten der Erhöhung von Verfügbarkeit spielten dabei eine wesentliche Rolle.

Ergänzend zu den technischen Betrachtungen erfolgt im Rahmen dieser Arbeit eine kurze Bewertung der Virtualisierungslösung VMware ESX Server im Vergleich zu einer konventionellen Lösung unter Verwendung realer Hardware.

In einem Vergleich einer Virtualisierungslösung mit einem konventionellen Lösungsansatz werden auch die Kosten beider Ansätze bewertet. Diese Arbeit erhebt dabei ausdrücklich nicht den Anspruch, die Kostenbetrachtungen mit den Maßstäben einer kaufmännischen Auswertung durchzuführen.

2 Grundlagen der Virtualisierung

2.1 Konzept der Virtualisierung

2.1.1 Entstehung des Virtualisierungs-Ansatzes

Virtualisierung ist modern; Virtualisierung ist aber nicht neu.

In den vergangenen Jahren ist die Grundidee der Virtualisierung wieder in den Blickpunkt des Interesses gerückt. Was auf der Ebene von Großrechnern schon in den 60er Jahren begann und bis heute von Rechenzentren produktiv genutzt wird, hält seit einigen Jahren auch Einzug auf Rechnersysteme unterhalb der Mainframe-Hardware.

Der Virtualisierungs-Ansatz entstand aus praktischen und naheliegenden Erwägungen: Zwar verfügte man in Rechenzentren – gemessen am damaligen Stand der Technik – über leistungsfähige Rechnersysteme, doch konnten die davon bereitgestellten Ressourcen nicht effizient genutzt werden.

Gerade die kostenintensive Prozessorleistung konnte in den verwendeten Großrechnersystemen in den meisten Fällen zeitlich nicht durchgängig genutzt werden.

Die Dateneingabe auf der Basis von Lochkarten war üblich, und während der langen Phasen zwischen Eingabe und Ausgabe der Daten lag die Ressource Prozessorleistung brach. Gleiches galt auch für die Zeiten während der eigentlichen Verarbeitung der Daten. Speicher- und Peripheriezugriffe waren langsam; und während das Großrechnersystem diese Zugriffe steuerte, wurde die Prozessorleistung nicht genutzt. Es war die Zeit des Stapelverarbeitungsbetriebs^[1] in Einbenutzer-Betriebssystemen.

Mit der Zeit stieg die Nachfrage nach Rechenkapazitäten, die im Wesentlichen durch Prozessorzeiten bestimmt war. Schnellere Peripheriezugriffe waren zwar ebenfalls relevant, aber im Vergleich zur Prozessorressource sekundär.

Die Anschaffung und der Betrieb weiterer Rechnersysteme war teuer. Hohe Anschaffungskosten, hohe Unterhaltungskosten für den Betrieb und nicht zuletzt auch räumliche Probleme waren zu dieser Zeit Hindernisse bei der Bereitstellung von Rechenkapazitäten.

Der Ansatz, die Nutzung der vorhandenen Rechenzeit zu optimieren, entstand als logische Konsequenz aus diesen Gegebenheiten.

Wenn es gelingen würde, die brachliegende Rechenkapazität von Großrechnersystemen für einen oder mehrere parallele Anwendungsfälle zu nutzen, so könnte ein enormer Produktivitätsgewinn erzielt werden.

Die Grundidee der Virtualisierung war entstanden. Man nannte diesen Ansatz Time Sharing System (TSS).

Ein erstes System, das den Namen Compatible Time Sharing System (CTSS) trug, wurde 1961 vom Massachusetts Institute of Technology^[2] auf der Basis eines Cray-Großrechnersystems gezeigt. Es war die erste Implementierung des Time Sharing Systems und war kompatibel mit FMS^[3], dem damaligen Standardbetriebssystem für das Batch Processing auf dem IBM-Großrechnersystem 7094^[4]. CTSS virtualisierte^[5] das IBM-7094-System, so dass IBM-7094-Code darauf unmodifiziert laufen konnte.

In den frühen 60er Jahren begann IBM mit der Entwicklung eines Großrechnersystems der neuen Generation: System/360. Die wesentliche Anstrengung galt dem Aufbau einer Rechnerarchitektur, zu der die zukünftig folgenden Weiterentwicklungen abwärtskompatibel sein sollten.

Abwärtskompatibilität war in dieser Zeit selbst zwischen den verschiedenen Generationen von Großrechnersystemen eines Herstellers nicht gegeben. Die Ablösung eines Rechnersystems war damit gleichbedeutend mit der Notwendigkeit, den Code der verwendeten Programme neu zu implementieren. Der Ansatz des Time Sharing Systems wurde bei der Entwicklung des System/360 zuerst nicht verfolgt, hielt aber nach und nach Einzug ist die Entwicklung.

Parallel zu den Arbeiten an einer softwarebasierten Virtualisierungslösung entwickelte IBM in der frühen 60er Jahren das Prinzip der logischen Partitionierung (LPAR^[6] ) von Großrechnersystemen. LPAR war eine hardwarebasierte Virtualisierungslösung, die das Rechnersystem in mehrere Partitionen aufteilte, die voneinander völlig unabhängig waren. Jede Partition stellte dabei die gleiche Hardware zur Verfügung, die im Großrechnersystem verwendet wurde, beschränkt nur hinsichtlich des Umfangs.

Entsprechend dem softwarebasierten Ansatz wurde 1965 auf dem neu entwickelten IBM System/360 ein Time Sharing System implementiert. Die Steuerungssoftware der Virtualisierungsumgebung^[7] bezeichnete man als Control Program (CP), das Betriebssystem für die virtuellen Maschinen als Conversational Monitor System (CMS).

Das entstandene System ist damit der Vorläufer aller virtuellen Systeme. Rechenzeit konnte nun von Betreibern des CP/CMS-Systems günstiger angeboten werden.

Zu dieser Zeit wurde das Produkt zwar von IBM unterstützt, die Entwicklung aber maßgeblich vom MIT bestimmt. Die Software wurde unter dem Namen VM bekannt.

Anfang der 70er Jahre verwendete IBM das System VM zur Emulation des neuen System/370 auf der Hardware des System/360 und begann die Vermarktung von VM.

In der Folgezeit wurde VM immer weiter entwickelt und an die neuen Generationen von Großrechnersystemen angepasst. Im Jahr 2005 erfolgte die Umbenennung in z/VM, was die Nähe des Betriebssystems für IBM-Serie Z (Mainframe) hervorhebt.

Auch andere Hersteller haben sich in der Vergangenheit mit der Entwicklung von Virtualisierungslösungen beschäftigt. An dieser Stelle soll aber nur auf die Entwicklungsgeschichte der Virtualisierung am Beispiel von IBM eingegangen werden, weil diese auch mit der Technologieführerschaft in der Historie begründet ist.

In den 80er und 90er Jahren wurden aufwendige Virtualisierungslösungen auf Großrechnersystemen durch das Aufkommen kostengünstiger x86-Hardware unwirtschaftlich.

Client-Server-Anwendungen auf der Software-Ebene und günstige x86-basierte Workstations und Server auf der Hardware-Ebene lösten die Prinzipien des Terminalcomputings mit der Umsetzung des Clientcomputings ab.

Die IT-Umgebungen in den meisten Unternehmen wuchsen stark, sowohl auf der Client- als auf der Serverseite. Wo früher ein Großrechner mit einigen angeschlossenen Terminals seinen Dienst verrichtet hatte, fand sich nun oftmals eine Vielzahl von x86-Servern und x86-Workstations wieder, wobei die Zahl der Workstations gegenüber der Zahl von Terminals sehr stark zunahm.

Mainframes verloren zwar nicht völlig an Bedeutung; sie wurden in ihrer Verwendung aber speziell auf besondere Einsatzzwecke konzentriert.

Aber auch die Entwicklung der x86-Hardware legte im Laufe der Zeit den Ansatz nahe, die Optimierung ungenutzter Ressourcen zu anzustreben, statt die IT-Umgebung immer weiter aufzurüsten. Wie viele Jahrzehnte zuvor, entstanden auch in x86-Umgebungen Bestrebungen nach Virtualisierung.

Ergänzend zu den Ansätzen der Virtualisierung auf Großrechnern, bei denen im Wesentlichen Kostenaspekte im Vordergrund standen, wurde beim Ansatz der Virtualisierung auf x86-Architekturen auch das Ziel verfolgt, die Verfügbarkeit zu erhöhen.

Eine besondere Problematik bei der Virtualisierung der x86-Architektur besteht in der Tatsache, dass die x86-Hardware anfänglich bewusst auf die Unterstützung von Virtualisierung verzichtet hat, auch um den Kostenvorteil zu erzielen.

In den folgenden Kapiteln wird ausführlich auf die Problematik der softwarebasierten Virtualisierung von x86-Hardware eingegangen. Zudem werden auch hardwarebasierte Lösungen zur Umsetzung von Virtualisierung auf x86-Hardare gezeigt.

2.1.2 Ziele der Virtualisierung

Mit dem Einsatz von Virtualisierungsverfahren sind heute verschiedene Absichten verbunden.

Der grundlegende Ansatz des Virtualisierungskonzepts ist die Abstraktion virtueller Umgebungen von der zugrunde liegenden Hardware. Virtualisierung verfolgt das primäre Ziel, die produktive Systemumgebung unabhängig von der technischen Plattform zu machen.

Dieser Ansatz der Entkopplung von logischer Systemumgebung und physischer Hardware zieht in der Konsequenz einige weitere Möglichkeiten nach sich, die wir als sekundäres Ziel von Virtualisierung betrachten können. Auch diese neuen Möglichkeiten – besonders die Auswirkungen von Virtualisierung auf die Verfügbarkeit – werden in den folgenden Kapiteln erläutert.

2.1.3 Prinzip ohne Virtualisierung

In einer konventionellen IT-Umgebung werden die einzelnen Hardwaresysteme im Ansatz unabhängig voneinander betrieben; auf jedem Hardwaresystem wird genau ein Betriebssystem betrieben, welches innerhalb seiner Betriebssystemumgebung eine Anwendungsebene bereitstellt. Auf dieser Anwendungsebene können eine oder mehrere Anwendungen betrieben werden, die aber im selben Systemkontext laufen.

Man unterscheidet im Gesamtsystem verschiedene Schichten: Hardwareschicht, Betriebssystemschicht und Anwendungsschicht.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.1: Schichtenmodell ohne Virtualisierung

Das Betriebssystem läuft somit direkt auf der Hardware und muss dazu eine vollständige Hardwareunterstützung für die eingesetzten Komponenten bereitstellen. Die Hardware eines Systems wird also vollständig von einem Betriebssystem verwaltet. Somit steht auf der Anwendungsebene der Leistungsumfang des gesamten Hardwaresystems als Ressource zur Verfügung.

2.1.4 Prinzip mit Virtualisierung

In einer IT-Umgebung, die Virtualisierungsverfahren verwendet, wird auf der Hardwareschicht eine Virtualisierungsschicht aufgesetzt. Oberhalb dieser Virtualisierungsschicht setzt die Anwendungsschicht auf.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.2: Schichtenmodell mit Virtualisierung

Allerdings unterscheiden sich die Inhalte der Schichten bei Verwendung von Virtualisierungsverfahren von einem Ansatz ohne Virtualisierung in wesentlichen Punkten. Sowohl die Virtualisierungs- als auch die Anwendungsschicht müssen genauer betrachtet werden.

Innerhalb der Virtualisierungsschicht verwaltet ein Hypervisor vollständig die verwendete Hardware. Man kann sich diese Hypervisor-Schicht als Betriebssystem vorstellen, welches die gesamte eingesetzte Hardware kontrolliert.

Auf dieser Hypervisor-Schicht – aber noch innerhalb der Virtualisierungsschicht – setzt die Ebene des Virtual Machine Monitors (VMM) auf. Genauer formuliert handelt es sich dabei um mehrere VMMs. Jede einzelne dieser VMMs hat die Aufgabe, eine Systemumgebung für genau eine virtuelle Maschine bereitzustellen und zu verwalten.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.3: Detail Virtualisierungsschicht

Betrachtet man die Unterteilung der Virtualisierungsschicht in die Hypervisor- und die VMM-Ebene, so stellt man analog zum konventionellen Ansatz ohne Virtualisierung fest, dass man innerhalb dieser Schicht die Hypervisor-Ebene als Betriebssystemschicht und die VMM-Ebene als Anwendungsschicht betrachten kann. Der Unterschied besteht nun darin, dass beim Einsatz von Virtualisierungsverfahren die Anwendungsschicht oberhalb der Virtualisierungsschicht aufsetzt.

Auch diese Anwendungsschicht muss näher betrachtet werden, damit das Prinzip der Virtualisierung nachvollzogen werden kann.

Auf der VMM-Ebene der Virtualisierungsschicht setzen nun die virtuellen Maschinen als Anwendungen innerhalb der Anwendungsschicht auf.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.4: Detail Anwendungsschicht (bei Virtualisierung)

Betrachten wir eine virtuelle Maschine in Analogie zu einem System ohne Verwendung von Virtualisierung, so können wir Parallelen zwischen der Hardwareschicht (Prinzip ohne Virtualisierung) und der VMM-Ebene (Prinzip mit Virtualisierung) feststellen. Die Betriebssystemschicht und die Anwendungsschicht (Prinzip ohne Virtualisierung) können bei Verwendung von Virtualisierung vollständig der virtuellen Maschine – also der Anwendungsschicht – zugeordnet werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.5: Detail virtuelle Maschine

Damit ist ein wesentlicher Punkt deutlich geworden: Durch die Verwendung des Virtualisierungsprinzips verschiebt sich im Schichtenmodell die Betriebssystemebene der virtuellen Maschine auf die Anwendungsschicht.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.6: Vergleich der Schichtenmodelle

Im Folgenden wird gezeigt, dass dieser Ansatz neben einer großen Reihe von Vorteilen auch einige Probleme mit sich bringt. Die Probleme bei der Implementierung von Virtualisierungslösungen, besonders bei Verwendung von x86-Hardware, liegen genau in diesem Punkt begründet.

2.2 Prinzipien der Virtualisierung

2.2.1 Grundlegende Prinzipien

Popek und Goldberg formulierten bereits 1974 in ihrem Artikel "Formal Requirements for Virtualizable Third Generation Architectures" [POP1] die grundlegenden Forderungen an eine Virtualisierungsumgebung, die bis heute gelten.

Ihre Anforderungen an einen Virtual Machine Monitor (VMM), dessen prinzipielle Aufgabe sowie Zuordnung im Schichtenmodell bereits erläutert wurden, umfassen:

Equivalence (Gleichwertigkeit):

Gleichwertigkeit des Laufzeitverhaltens einer virtuellen Maschine zu einem System ohne Verwendung von Virtualisierung.

Ressource Control (Ressourcenkontrolle):

Der Virtual Machine Monitor muss die ausschließliche Kontrolle über die verwendeten virtualisierten Ressourcen haben.

Efficiency (Effizienz):

Zum Erreichen einer effizienten Umgebung muss der überwiegende Anteil der Befehlsausführungen innerhalb der virtuellen Maschine ohne Beteiligung des VMM erfolgen.

Heutige Virtualisierungslösungen erfüllen die ersten beiden Forderungen uneingeschränkt.

Dass die dritte Forderung – besonders bei der Virtualisierung von x86-Architekturen – nicht umsetzbar ist, wird im Folgenden erläutert.

Vorausschauend sei aber bereits an diesem Punkt die Erfüllung der Forderung nach Effizienz festgestellt, weil Popek und Goldberg mit dieser Forderung eine performante Virtualisierungsumgebung sicherstellen wollten, die sich damit wesentlich von einer unperformanten Emulationsumgebung abhebt. Aktuelle Virtualisierungslösungen erfüllen die Forderung nach Effizienz durch die Verwendung spezieller Techniken bei der Implementierung, was ebenfalls im Folgenden erläutert wird.

2.2.2 Prozessor-Berechtigungsmodell

Sowohl Prozessoren der x86-Architektur als auch RISC-Prozessoren verwenden das Ring-Modell zur Privilegierung von Prozessen, die ein Betriebssystem auf ihnen ausführt.

Das Ring-Modell, auch Domain-Modell genannt, unterscheidet vier Berechtigungsstufen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.7: Prozessor Ring-Modell

Prozesse, die in der Privilegierungsstufe von Ring 0 laufen, haben uneingeschränkte Rechte. Kernel-Prozesse^[8] laufen in diesem Berechtigungskontext (Kernel Mode^[9] ).

Alle anderen Prozesse^[10] laufen im eingeschränkten Berechtigungskontext der übrigen Ringe 1 bis 3 (User Mode).

Betriebssysteme wie Linux und Windows nutzen jedoch nur Ring 0 und Ring 3 in der Unterscheidung der Berechtigungen.

Durch die Nutzung von nur zwei Ringen im Berechtigungsmodell der CPU-Steuerung bleibt eine Portabilität des Betriebssystem-Quellcodes auf Prozessorarchitekturen, die nur ein zweistufiges Berechtigungsmodell implementiert haben, mit vertretbarem Aufwand möglich.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.8: Privilegierungsstufen im klassischen Schichtenmodell

Prozesse, die im unprivilegierten Modus laufen und Hardwarezugriffe ausführen wollen, können dies nicht direkt tun, sondern müssen es über die entsprechenden Betriebssystem-Schnittstellen^[11] anfordern. Die Aufrufe werden an diese Schnittstellen übergeben, und die gewünschten Rückgabewerte werden über den gleichen Mechanismus zurückerhalten. Damit ist sichergestellt, dass nur das Betriebssystem direkten Zugriff auf die Hardwareressourcen hat.

Versucht ein unprivilegierter Prozess einen Zugriff auf eine Ressource, die eine höhere Berechtigungsstufe voraussetzt, so wird eine Exception^[12] ausgelöst.

Diese Exception wird dann von einem Betriebssystemprozess im Berechtigungskontext von Ring 0 aufgenommen und behandelt. Die Aufnahme einer Exception bezeichnet man als Trap.

Jeder Kontextwechsel^[13] des Prozessors von einer Berechtigungsstufe zu einer anderen benötigt – abhängig vom verwendeten Prozessor – einige hundert bis zu einige tausend Prozessor-Taktzyklen und belegt damit verhältnismäßig viel Rechenzeit.

Das Wissen um diesen Sachverhalt ist wichtig für die realistische Abschätzung des Laufzeitverhaltens virtueller Maschinen.

2.2.3 Speicherverwaltung

Moderne Betriebssysteme wie Linux und Windows verwenden eine zweistufige, seitenorientierte Verwaltung ihres virtuellen Speichers; sie wenden die virtualisierte Speicherverwaltung an, auch ohne dass das Betriebssystem selbst in einer virtualisierten Umgebung läuft.

Virtuelle Speicherverwaltung auf Betriebssystemebene bedeutet hierbei, dass jeder Prozess virtuell den gesamten adressierbaren Hauptspeicher über seine eigene Speichertabelle^[14] verwalten kann, unabhängig von der physikalisch im Hardwaresystem verfügbaren Speichergröße.

In einer 32-Bit-Prozessorarchitektur umfasst dieser adressierbaren Speicher 232 Byte = 4 GB. Unterteilt ist der reale Speicher in einzelne Seiten mit einer konstanten Größe, in der Regel 4 KB [VOG1].

Ein Prozess nutzt damit Speicher, der sich für ihn als zusammenhängender Bereich darstellt. Greift er auf diesen Speicher lesend oder schreibend zu, so wird über eine Seitentabelle die tatsächliche Adresse im Hauptspeicher ermittelt.

Der physikalische Hauptspeicher des Systems wird von einer Speicherverwaltungseinheit, der Memory Management Unit (MMU), verwaltet. Sie verhindert konkurrierende Lese- und Schreibzugriffe verschiedener Prozesse auf Speicherbereiche, die nicht explizit für die Verwendung durch mehrere Prozesse vorgesehen sind.^[15]

Auf diese Weise ist sichergestellt, dass jeder Prozess seinen exklusiven Speicherbereich nutzt, welcher sich für ihn selbst als zusammenhängend darstellt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.9: Hauptspeicherverwaltung mit virtuellem Speicher

Die Memory Management Unit verwaltet im Hintergrund den physikalischen Speicher transparent für die Prozesse. Diese Verwaltung umfasst auch das Auslagern wenig verwendeter Speicherseiten des Hauptspeichers in eine Auslagerungsdatei^[16] auf einem Festplattenlaufwerk und das Zurückholen von ausgelagerten Speicherseiten bei Bedarf. Dieser Vorgang wird auch als Paging bezeichnet.

Die Anforderung zum Zurückschreiben ausgelagerter Speicherseiten wird über eine Ereignisbehandlung eines Seitenfehlers ausgelöst: Führt ein Prozess einen Zugriff auf eine Speicherseite aus, für die sich nach der Umrechnung über die Seitentabelle ergibt, dass sie nicht mehr im physikalischen Hauptspeicher liegt, sondern über den Paging-Mechanismus ausgelagert wurde, so tritt ein Ausnahmezustand ein, der im Hintergrund durch das Einlagern der betreffenden Seite behandelt wird.

Aktuelle Betriebssysteme verfügen über eine Mehrstufigkeit bei der Berechnung der realen Speicheradresse mit Hilfe der Seitentabellen. Dieser Ansatz verhindert die Notwendigkeit einer einzigen großen Seitentabelle pro Prozess durch die Aufteilung in mehrere kleine, hierarchisch geordnete Seitentabellen. Diese können ihrerseits selbst über den Paging-Mechanismus bei Bedarf ausgelagert werden.

MMUs moderner Prozessoren beschleunigen das beschriebene Verfahren des zwei- oder mehrstufigen Pagings erheblich durch die Verwendung spezieller Pufferregister, der Translation Lookaside Buffer (TLB), in denen häufig benötigte Tabelleneinträge gespeichert werden und bei Bedarf ausgelesen werden können. Dabei entfällt die Notwendigkeit, eine Adresse zu berechnen,, was das Verfahren sehr beschleunigt.

2.2.4 Betriebssystemarchitektur

Betriebssysteme – hier im Folgenden am Beispiel von Linux und Windows beschrieben – basieren auf ihrem Betriebssystemkern (Kernel). Bei einem Betriebssystemkern kann man grob unterscheiden zwischen dem Ansatz, die Betriebssystem-Basisfunktionalitäten in einem einzigen monolithischen Kernel zu implementieren, und dem Microkernel-Ansatz. Beim Microkernel-Ansatz ist die Grundidee, nur die Basisfunktionalitäten eines Betriebssystems in einem minimalen Kern zu implementieren und die weiteren notwendigen Komponenten in verschiedenen Bausteinen^[17] bereitzustellen.

Linux verfolgte ursprünglich den Ansatz des monolithischen Kernel, Windows^[18] den Microkernel-Ansatz.

Im Schichtenmodell eines Linux-Systems setzt der Kernel direkt auf der Hardwareschicht auf; darüber befindet sich eine Schicht, über die Systemaufrufe zum Kernel gesteuert werden. Softwarekomponenten dieser Schichten laufen im Berechtigungskontext des Kernel-Modes und haben damit uneingeschränkten Zugriff auf die Ressourcen. Darüber liegen die Schichten des User-Modes, in dem auf der obersten Ebene die Anwendungen laufen. Die Anwendungen greifen auf Funktionalitäten der darunter liegenden Schicht über Libraries zu.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.10: Schichtenmodell Linux

In Windows-Betriebssystemen wurde mit der Einführung der NT^[19] -Familie das Microkernel-Konzept umgesetzt.

Im Schichtenmodell eines Windows-Systems setzt eine Hardware-Abstraktionsschicht (HAL^[20] ) direkt auf der Hardware auf. Ähnlich wie bei einer virtuellen Maschine wird auf dieser Ebene die Hardware abstrahiert und ist für höher liegende Schichten nur noch über fest definierte Schnittstellen steuerbar.

Auf dem HAL setzt die Betriebssystemschicht mit dem Windows-Microkernel auf. Dieser Kernel kann auf die Hardware somit nur über den HAL zugreifen. Man kann den HAL aber trotzdem nicht als Virtualisierungsschicht bezeichnen, weil sich der Kernel trotz der Verwendung einer Abstraktionsschicht immer noch sehr stark an der Hardwarearchitektur orientieren muss. Bei der Portierung auf andere Hardware-Architekturen muss daher neben dem HAL auch noch der Betriebssystemkern angepasst werden.

Die weiteren Kernelmodule liegen oberhalb der Microkernel-Schicht und bilden zusammen mit dem Ein- und Ausgabe-Manager die Executive-Schicht eines Windows-Systems. Alle genannten Systemkomponenten laufen im Berechtigungskontext des Kernel-Modes.

Die darauf basierenden weiteren Schichten – Subsystemschicht und Anwendungsschicht – laufen im eingeschränkten User-Mode.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.11: Schichtenmodell Windows

Unabhängig vom grundlegenden Kernelentwurf, ob monolithischer Ansatz oder Microkernel mit Modulen, laufen in beiden Betriebssystemfamilien Hardwarezugriffe aus der Anwendungsschicht nur über die Betriebssystemschicht ab.

Die Anwendungen laufen innerhalb von Schichten, die systemseitig im beschränkten User-Mode ausgeführt werden; das Betriebssystem läuft auf Schichten, die im privilegierten Kernel-Mode ausgeführt werden.

Diese prinzipielle Zuordnung von Schichten und Berechtigungen ist wesentlich für die weitere Betrachtung der Funktionsweise von Virtualisierungslösungen.

2.2.5 Prozesssteuerung und Multitasking

Betriebssysteme haben die Grundaufgabe, die verschiedenen Prozesse eines Systems zu verwalten. Teilweise sind dies betriebssystemeigene Prozesse, bei den restlichen Prozessen handelt es sich um Anwendungsprozesse.

Modere Betriebssysteme sind Mehrbenutzersysteme, gegenüber den Einbenutzersystemen früherer Zeiten. Diese hatten immer nur ein Programm abzuarbeiten. Auf dem Prozessor wurde immer nur ein Prozess ausgeführt.

Heutige Betriebssysteme haben die Aufgabe, die verschiedenen Anwendungen – dargestellt durch Prozesse – gleichzeitig auszuführen. Auf Einprozessorsystemen ist dies nicht möglich, weil ein Prozessor, genauer gesagt ein Prozessorkern, immer nur einen Prozess gleichzeitig ausführen kann. Somit hat sich prinzipiell auf der Prozessorebene gegenüber der Vergangenheit nichts verändert.

Dem Betriebssystem fällt nun die Aufgabe zu, die Parallelität der Prozesse umzusetzen. Da sich auch ein Betriebssystem nicht über die Grenzen, die von der Hardware technisch gesetzt werden, hinwegsetzen kann, führt es diese Prozesse nur scheinbar gleichzeitig aus^[21].

Das Betriebssystem verfügt über eine Komponente, die diese Prozesssteuerung übernimmt: den Scheduler.

Laufende Prozesse werden durch einen Timer-Interrupt des Betriebssystems mehrere hundert Mal pro Sekunde unterbrochen, und die Kontrolle über die Rechenzeit wird zurück an den Scheduler gegeben. Dieser startet die Bearbeitung eines anderen Prozesses, welcher dann bis zum nächsten Timer-Interrupt ausgeführt wird.

Beim Auftreten des nächsten Timer-Interrupts wird der aktuelle Zustand des Prozesses – sein Kontext^[22] – für eine spätere Weiterbearbeitung gespeichert. Der Timer-Interrupt übergibt nach erfolgreicher Prozessunterbrechung, einschließlich der Kontextspeicherung, die Steuerung an den Scheduler, welcher den Kontext des nun anstehenden Prozesses wiederherstellt und die Weiterbearbeitung dieses Prozesses startet.

Dieser Prozess arbeitet dann wieder so lange, bis der Zyklus durch einen Timer-Interrupt von Neuem beginnt. Dieses Prinzip des Multitaskings bezeichnet man als präemptives Multitasking.

Wichtig ist dabei, dass der Timer-Interrupt unabhängig vom Prozess ausgeführt wird. Die Abarbeitung der Prozesse wird immer wieder durch einen Timer-Interrupt von außen unterbrochen und vom Scheduler neu gestartet. Damit ist sichergestellt, dass ein fehlerhafter Prozess nicht das Gesamtsystem zu Absturz bringen kann, indem er die gesamte Prozessor-Rechenzeit belegt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.12: Prozessteuerung beim präemptiven Multitasking

Welches Scheduling-Verfahren bei der Prozessteuerung verwendet wird, ist abhängig von der Implementierung des Schedulers im Betriebssystem.

Scheduling-Strategien [VOG1] unterscheiden sich lediglich durch die Priorität, die sie den verschiedenen Prozessen zuweisen, und beeinflussen damit die Häufigkeit der Ausführung innerhalb eines Zeitintervalls.

[...]

---

^[1] Batch Processing

^[2] MIT

^[3] Fortran Monitor System

^[4] IBM-Großrechnersystem 7094: Rechenleistung 350000 MIPS (Maschinenbefehle pro Sekunde, vergleichbar mit ca. 1 MHz Taktfrequenz bei einem Intel-8080-Prozessor), 32 KB Hauptspeicher, 3,5Mio. $ [WL1]

^[5] Für die Unterscheidung von Virtualisierung und Emulation wird auf ein separates Kapitel verwiesen.

^[6] Logical Partitions

^[7] Erläuterung zur Funktion von Hypervisors werden in einem separaten Kapitel gegeben.

^[8] Betriebssystemprozesse

^[9] Auch Supervisor-Mode genannt

^[10] Anwendungsprozesse

^[11] Kernelaufrufe (System Calls), kurz: Syscall

^[12] Ausnahmezustand

^[13] Context Switching

^[14] Page Table

^[15] Shared Memory

^[16] Pagefile

^[17] Module

^[18] Windows-Betriebssysteme der NT-Familie: Windows NT, 2000, XP, 2003 ff.

^[19] New Technology

^[20] Hardware Abstraction Layer

^[21] Quasi-Parallelität

^[22] Prozesskontext