Open Source Jahrbuch 2007

Transkript

1 Dieser Artikel ist Teil des Open Source Jahrbuchs , 1991 Free Software Foundation, Inc. 59 Temple Place - Suite 330, Boston, MA , USA Everyone is pert, but changing it is not allowed. Preamble The licenses for most software are designed to take away your freedom to ended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. dation s software and to any other program whose authors commit to using it. (Some other Free Software Foundation.) You can apply it to your programs, too. Bernd When we Lutterbeck speak of free software, we are referring to freedom, not price. Our freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or ces of it in new free programs; and that you Matthias know you Bärwolff can do these things. To protect your rights, we need to make o surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the softa program, whether gratis or for a fee, you Robert must give A. the Gehring recipients (Hrsg.) all the rights that you have. You must make sure them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) ute and/or modify the software. Also, for each author s protection and ours, we want to make certain that everyone tware is modified by someone else and passed on, we want its recipients to know that what they have is not the origioriginal authors reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid patent licenses, in effect making the program Open proprietary. To prevent this, we Source have made it clear that any patent must rms and conditions for copying, distribution and modification follow. TERMS AND CONDITIONS FOR COPYING, DISTRIr other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this am or work, and a work based on the Program means either the Program or any derivative work under copyright law: r verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without you. Activities other than copying, distribution and modification are not covered by this License; they are outside its t from the Program is covered only if its contents constitute a work based on the Program (independent of having been the Program does. 1. You may copy and distribute verbatim copies of the Program s Jahrbuch source cod e as 2007 you receive it, in h on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this ents of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transn exchange for a fee. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part nsed as a whole at no charge to all third parties under the terms of this License. c) If the modified program normally ted running for such interactive use in the most ordinary way, to print or display an announcement including an appro-, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling itself is interactive but does not normally print such an announcement, your work based on the Program is not required work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably consie, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute gram, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the readable source code, which must be distributed under the terms of Sectio ns 1 and 2 above on a medium customarily r, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing onding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for ceived as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial disable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form Zwischen freier Software und Gesellschaftsmodell mplete source code means all the source code for all modules it contains, plus any associated interface definition files, cutable. However, as a special exception, the source code distributed need not include anything that is normally distrimpiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accomade by offering access to copy from a designated place, then offering equivalent access to copy the source code from third parties are not compelled to copy the source along with the object code. 4. You may not copy, modify, sublicense, nse. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically termied copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivais License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your or copying, distributing or modifying the Program or works based on it. 6. Each time you redistribute the Program (or Open Source Jahrbuch 2007 erhältlich unter Die komplette Ausgabe enthält viele weitere interessante Artikel. Sie können diesen und andere Artikel im Open-Source-Jahrbuch-Portal kommentieren oder bewerten: Lob und Kritik sowie weitere Anregungen können Sie uns auch per mitteilen.

2 OpenVZ und Xen DENNIS ZIMMER UND ANDREAS NIEDERLÄNDER (CC-Lizenz siehe Seite 563) Der folgende Artikel behandelt das Thema Virtualisierung im Open-Source Umfeld. Neben einer Einführung in die Geschichte und Technologie der Virtualisierung werden Architektur und Funktionsumfang der Virtualisierungsprogramme erläutert. Im Kern dieses Artikels stehen die beiden Open Source-Virtualisierungsumgebungen OpenVZ und Xen. Für beide Produkte werden Funktionsweise und Charakteristika sowie Installation, Konguration und Verwaltung beschrieben. Eine kurze Zusammenfassung der Vor- und Nachteile sowie des Einsatzgebietes soll dem Leser die Gelegenheit geben, das für ihn passende Produkt auswählen zu können. Ein Blick auf andere Virtualisierungsprodukte und die mögliche Entwicklung in der Zukunft runden den Artikel ab. Schlüsselwörter: Leistungsbewertung Paravirtualisierung Virtualisierung Betriebssystemvirtualisierung 1 Grundlagen der Virtualisierung Virtualisierung wurde von vielen Analysten als einer der Trends der nächsten Jahre dargestellt, da durch die Virtualisierung immense Vorteile im Serverbetrieb entstehen können. Welche Vorteile rechtfertigen eine solche Präsenz in den Medien und was ist bzw. wie funktioniert Virtualisierung eigentlich? In einem Satz: Virtualisierung stellt die Trennung des Betriebssystems und der darauf betriebenen Applikationen von der physikalischen Hardware dar. Die Virtualisierungssoftware erstellt eine logische Hardwareumgebung für jede virtuelle Maschine, die komplett unabhängig von der darunterliegenden physikalischen Hardware ist. Daher sind die virtuellen Maschinen komplett von der physikalischen Hardware abgeschottet und können diese nicht kompromittieren. Der Unterschied zwischen der virtuellen und der physikalischen Umgebung ist für die Prozesse und Programme innerhalb der virtuellen Maschine im Normalfall nicht sichtbar.

3 Dennis Zimmer und Andreas Niederländer Die Ansteuerung der Hardware, das Zuweisen der Ressourcen und die Rechteverwaltung regelt die Virtualisierungssoftware. Es besteht keine Möglichkeit für die virtuelle Maschine, aus dieser virtuellen Umgebung auszubrechen. Genau diese Trennung ist auch notwendig, um sichere und efziente Umgebungen aufzubauen. 2 Virtualisierungstechnologien Virtualisierung ist zuallererst von Emulation zu unterscheiden. Der groÿe Unterschied zwischen Virtualisierung und Emulation liegt darin, dass Emulatoren die gesamte Hardwarearchitektur nachbilden. Dadurch ist es beispielsweise möglich, auf einem x86-system RISC-Prozessoren oder Motorola-CPUs nachzustellen. Dies erfordert jedoch enorme Rechenleistung seitens des Wirtssystems, da jeder Prozessorbefehl sowie die Hauptspeicheradressierung umgesetzt werden müssen. Virtualisierung verfolgt einen anderen Ansatz: Hier wird nicht die komplette Hardware nachgestellt, sondern nur einzelne Hardwarekomponenten. CPU- und Hauptspeichernutzung können durch die Virtualisierungsprodukte zwar eingeschränkt und partitioniert werden, es erfolgt aber keine Architekturumsetzung. Dadurch wird Performance gewonnen, allerdings wird die Heterogenität eingeschränkt. Auch Virtualisierungstechniken werden in verschiedene Arten aufgeteilt: Hardwarevirtualisierung oder Komplettvirtualisierung, Paravirtualisierung und Betriebssystemvirtualisierung. Hardwarevirtualisierung Diese Form der Virtualisierung wird von bekannten Unternehmen wie Microsoft und VMware in ihren Produkten verwendet. 1 Technisch wird bei einer Komplettvirtualisierung jedem Gastsystem eine angepasste Hardware präsentiert. Diese Virtualisierungsschicht präsentiert dem Gastsystem eine immer gleiche Peripherie. Lediglich Prozessor- und Hauptspeicherzugriffe werden direkt an die physikalische Hardware durchgereicht, alle anderen Geräte werden emuliert. Da diese Emulierung Leistung kostet, werden im Gastsystem entsprechende Hardwaretreiber und Tools installiert, um Leistungsverluste zu minimieren. Dieser Leistungsverbrauch, auch virtualization overhead genannt, schmälert die reale Leistung, die den Gastsystemen durch das Wirtssystem zur Verfügung gestellt werden kann. Paravirtualisierung Der bekannteste Vertreter der Paravirtualisierung ist Xen. Paravirtualisierung unterscheidet sich von der Komplett- oder Hardwarevirtualisierung in dem Sinne, dass hierfür eine Anpassung des Gastsystems notwendig wird. Während die Hardwarevirtualisierung der virtuellen Maschine eine komplette Umgebung mit Standardgeräten zur Verfügung stellt, merkt das Gastbetriebssystem nichts von der Virtualisierung und muss nicht angepasst werden. Paravirtualisierung basiert jedoch darauf, dass die virtuelle Maschine mit der speziell 1 Spezielleres zu Microsoft Virtual Server und VMware-Produkten ist in Zimmer (2005) zu nden. 264

4 OpenVZ und Xen für die Virtualisierung kreierten virtuellen Hardware kommunziert. Diese wird durch die Virtualisierungsschicht (VMM oder Virtual Machine Monitor) erstellt. Dies kann sie jedoch nur, wenn der Betriebssystemkern (Kernel) 2 so angepasst wird, dass dieser statt mit der physikalischen Standardhardware mit der virtualisierten Hardware kommuniziert. Dadurch muss die physikalische Hardware nicht für jede einzelne virtuelle Maschine virtualisiert werden, sondern die Gastbetriebssysteme greifen direkt auf eine angepasste Hardware zu. Hierbei nutzen Hypervisor 3 und Gastsysteme immer die gleichen Treiber. Betriebssystemvirtualisierung Die Betriebssystemvirtualisierung geht einen anderen Weg und virtualisiert nicht ein Hardwaresystem, sondern partitioniert das Betriebssystem in mehrere, von der Basis her gleiche Teile. Vorteil der Betriebssystemvirtualisierung ist, dass idealerweise bei der Erstellung der Gastsysteme nur die Individualdaten der virtuellen Maschine angelegt werden. Alle gleichen Betriebssystemdaten (Programmbibliotheken etc.) des Wirtssystems werden durch die Gäste mitgenutzt. Dies gilt ebenfalls für die laufenden Prozesse. Weitere Anpassungen des Gastbetriebssystems sind in keiner Form nötig. Abweichende Daten werden im Heimatverzeichnis der virtuellen Maschine abgelegt. Mittels dieser Technik besteht eine virtuelle Maschine in der Grundausstattung nur aus sehr wenigen Dateien und verbraucht deutlich weniger Hauptspeicher als ein normal installierter Server. Betriebssystemvirtualisierung steht für eine sehr hohe Ausnutzung der Wirtssystemressourcen, d. h. einen geringen Virtualisierungsoverhead (13 %). Darüber hinaus ist aufgrund der geringen Leistungsansprüche der Gäste eine sehr hohe Anzahl virtueller Maschinen auf verhältnismäÿig schwacher Hardware möglich (ca. Faktor zehn gegenüber Komplettvirtualisierung). Gröÿter Nachteil ist die Abhängigkeit des Gastsystems vom Wirtssystem, da eine homogene Basis vorausgesetzt wird. Wichtigster Aspekt auch dieser Form der Virtualisierung ist, dass alle Gäste voneinander getrennt und unabhängig agieren können. Technik 3 OpenVZ OpenVZ 4 gehört zu den Betriebssystemvirtualisierungsprodukten, partitioniert also das Wirtsbetriebssystem und nutzt dieses auch in Teilen mit (siehe Abbildung 1). Entstanden aus dem kommerziellen Virtualisierungsprodukt Virtuozzo von SWsoft, ermöglicht OpenVZ die Virtualisierung von Linux. SWsoft hat aus OpenVZ ein Community-Projekt gemacht, welches auf ein stetig wachsendes Interesse stöÿt. OpenVZ 2 Der Kernel ist das Kernstück des Betriebssystems, siehe dazu Betriebssystemkern. 3 Hypervisor ist ein Synonym für VMM

5 Dennis Zimmer und Andreas Niederländer ist quelloffen, kostenfrei und steht unter der GPL bzw. QPL 5. Ziel dieses Projektes ist es, Bestandteil des ofziellen Linux-Kernels zu werden. Einen Teilerfolg hat OpenVZ schon erzielt, da OpenVZ zukünftig in der Distribution Debian 6 enthalten sein wird. 3.1 OpenVZ-Verwaltung Die Verwaltung der Virtualisierung erfolgt ausschlieÿlich mithilfe mächtiger Kommandozeilentools, die auch durch Skripte automatisiert werden können. Darunter nden sich neben den Basistools zur Verwaltung auch Zusatzprogramme zur Ressourcenkontrolle oder der Templateverwaltung. Nachteil von OpenVZ ist dabei die zwingende Homogenität: Auf einem Kernel-2.6-Wirtsbetriebssystem können nur Gastsysteme, die auf dem gleichen Kernel basieren, betrieben werden. Das Virtual Environment (VE) 7 wird mittels eines Templates erstellt, das eine Kernkomponente von OpenVZ darstellt. In einem solchen Template sind alle Dateien des Linux-Systems eingebunden, die benötigt werden, um die VE auf dem Wirtssystem zu betreiben. Es wird immer nur der Kernel des laufenden Wirtssystems genutzt. Grundsätzlich existiert immer nur ein Template pro OpenVZ-Server. Alle darauf basierenden VEs nutzen diesen und legen Änderungen gegenüber diesem System in einem eigenen Verzeichnis ab. Unter diesen Änderungen sind Softwareinstallationen und Kongurationsänderungen zu verstehen, z. B. die Anpassung der Kongurationsdatei /etc/fstab. Dadurch wird eine höhere Speicherdichte (ca. 100 MB pro VE ohne Applikationen) erreicht, durch die viel Speicherplatz eingespart werden kann. Dieses Verfahren ist beim groÿen Bruder Virtuozzo nochmals deutlich verbessert worden, resultierend in einem Festplattenbedarf der VEs im Bereich von 1030 Mbyte (Standardinstallation ohne Applikationen). Die Templates werden für die gängigsten Linux-Derivate zum Download auf der Webseite bereitgestellt. Weiterhin ist es bei entsprechender Kenntnis auch möglich, Templates mittels des Programms vzpkg selbst zu erstellen. Die Vermutung, es würden Sicherheitslücken durch die Nutzung von gleichen Daten (Template) und Prozessen entstehen, bestätigt sich nicht. Derzeit ist keine Möglichkeit bekannt, aus dem Gastsystem in andere Gäste oder gar den Wirt zu gelangen. Es herrscht eine vollkommene Trennung der Systeme. Allerdings sollte das Wirtssystem wie bei jeder Virtualisierung sehr gut abgeschottet und ausfallsicher aufgestellt werden. Dies gilt sowohl für die Hard- als auch für die Software. Zusätzlich ist es möglich, die maximal nutzbaren Ressourcen des Wirtssystems pro virtueller Maschine einzuschränken, was in vielen Fällen sehr nützlich sein kann, wenn z. B. VEs 5 Q Public License eine von der Open-Source-Initiative zertizierte Softwarelizenz, die sich von der bekannten GNU General Public License (GPL) unterscheidet. Man darf Software, die unter der QPL veröffentlicht wurde, in unveränderter Form kopieren und weitergeben, solange man das Paket unangetastet lässt d. h. Copyright-Hinweise, Warenzeichen und Haftungsauschlüsse müssen mitgegeben werden, so wie sie der Hersteller angegeben hat. Dies sichert die Integrität der Originalversion. Siehe auch VE bezeichnet die virtuelle Maschine unter OpenVZ. 266

6 OpenVZ und Xen Technik Abbildung 1: Die OpenVZ-Architektur Dritten zur Verfügung gestellt werden. Verschiedene Peripherieformen sind aufgrund dieser Technik jedoch derzeit eingeschränkt, wodurch der Einsatz von beispielsweise USB oder paralleler Schnittstelle im Gast nicht möglich ist. Seit Juni 2006 wurde insbesondere die Netzwerk-Unterstützung weiterentwickelt, so dass OpenVZ nun IPv6 und Bridging unterstützt und somit eine breitere Anwendungsunterstützung ermöglicht. 3.2 Einsatzgebiete von OpenVZ OpenVZ ist aufgrund der Homogenität beim Einsatz auf reine Linux-Umgebungen beschränkt. Für die Integration in eine bestehende Linux-Installation existieren auf der ofziellen Webseite und auch auf verschiedenen Community-Webseiten detaillierte Anleitungen. Ohne diese sind fortgeschrittene Linux-Kenntnisse zwingend notwendig, da der zu startende Kernel ausgetauscht werden muss. Ist das System erst einmal installiert, präsentiert sich OpenVZ sehr zuverlässig und performant. Es können durchaus auch produktive Systemumgebungen virtualisiert werden. Dennoch ist der Haupteinsatzbereich in kleineren Umgebungen, insbesondere Test- und Entwicklungsumgebungen, zu sehen. Mit der neuesten Version wurden zwei sehr interessante und wichtige Funktionalitäten eingeführt: virtuelle Ethernet-Netzwerke und Live-Migration. Vormals bestand nur die Möglichkeit eines virtuellen Netzwerks, das nur eine logische Trennung durch 267

7 Dennis Zimmer und Andreas Niederländer Abbildung 2: Die Xen-Architektur IP-Subnetze zulieÿ. Mit den nun verfügbaren virtuellen Netzwerken kann die virtuelle Maschine deutlich exibler genutzt werden, z. B. durch die Verwendung eigener MAC-Adressen und Netzwerknamen. Live-Migration bedeutet das Verschieben eines VE zwischen zwei OpenVZ-Servern ohne ein Herunterfahren der virtuellen Maschine. Jedoch muss diese derzeit noch kurz angehalten werden, was zu einem minimalen Ausfall führt. Allerdings ist derzeit der Einsatz von Zusatzkarten oder Peripherie (z. B. Faxkarten) meist nicht möglich. 4 Xen Xen 8 verfolgt gegenüber OpenVZ einen anderen Weg: Ähnlich wie bei den Produkten aus dem Hause VMware wird hier für jeden Gast ein eigener Kernel gestartet. Das bedeutet prinzipiell, dass auf einem Wirt verschiedene Betriebssysteme gleichzeitig gestartet werden können. Dies ist allerdings auf normaler x86-hardware ohne Anpassung des Gast-Kernels nicht möglich. Schuld daran sind die sogenannte Ring-0-Befehle der x86-prozessoren, die exklusiv dem Kernel eines Betriebssystems vorbehalten sind. Um mehrere Betriebssysteme zu starten, ist es daher unumgänglich, diese Befehle aus dem Kernel des Gastes zu entfernen bzw. zu ersetzen. Während VMware dies on-the y beim Betrieb des Gastes macht, muss dieser bei Xen vor dem Start entsprechend angepasst werden (Paravirtualisierung) Eine detaillierte Beschreibung der Funktionsweise von Xen und der Einrichtung ndet sich in Radonic und Meyer (2006). 268

8 OpenVZ und Xen Xen selbst besteht eigentlich nur aus einer dünnen Virtualisierungsschicht, dem VMM (Virtual Machine Monitor), der einzeln nicht zu nutzen ist (siehe Abbildung 2). Die virtuellen Systeme werden bei Xen jeweils als Domain bezeichnet. Nach dem Start des VMM benötigt Xen einen besonderen Gast, der direkten Zugriff auf die I/O-Bereiche der Hardware erhält. Dieser Gast wird als Dom0 bezeichnet und dient auch der Kontrolle der anderen Gäste. Alle anderen Gäste auch DomUs genannt bedienen sich der Hardware, die durch die Dom0 zur Verfügung gestellt wird. Somit kann die Dom0 von der Funktionsweise her auch als Wirt-System bezeichnet werden. Auf Xen werden groÿe Hoffnungen gesetzt, da viele namhafte Hardware- und Betriebssystemhersteller die Unterstützung dieses Produktes zugesichert haben, darunter Intel, IBM, RedHat und Microsoft. Für einen Einsatz in Unternehmen sind Herstellersupport sowie eine zentrale Verwaltungsoberäche zwingend erforderlich. Beides wird durch das Unternehmen XenSource angeboten, jedoch fehlen zur kürzlich erschienenen XenEnterprise noch Erfahrungswerte. Um Xen einzusetzen, muss also zurzeit auf komfortable Management-Software verzichtet werden. Aber auch mithilfe der mitgelieferten Befehlszeilentools und der rudimentären Konguration, die z. B. SUSE Linux mitbringt, ist es durchaus möglich, eine leistungsfähige Xen-Umgebung umzusetzen. Red Hat plant grundsätzlich, Xen in sein Enterprise-Produkt RHEL zu integrieren, verzögert die Auslieferung jedoch noch. Nach Aussagen von Red Hat spielen hier die noch fehlende Stabilität und Lücken im Sicherheitsbereich eine Rolle. Geplant ist die Integration von Xen in RedHat Enterprise Linux 5. Technik 4.1 Einsatzgebiet von Xen Aktuell wird Xen hauptsächlich für die Virtualisierung von Linux-Systemen eingesetzt, da mit Linux aufgrund der offenen Quellen Paravirtualisierung möglich ist und Distributionen Werkzeuge zur Installation und Administration mitbringen. SUSE Linux Enterprise Server 10 kann quasi out of the box als Xen-Wirt inkl. virtueller Linux Maschinen über eine grasche Oberäche installiert werden. Das macht den Einstieg einfacher. Die Einsatzgebiete für solche Maschinen sind überall dort zu nden, wo aktuell Linux-Maschinen ihren Dienst tun. Einfache Maschinen ohne besonderen Ressourcen-Bedarf (z. B. DNS- oder DHCP-Server) können bereits jetzt ohne Bedenken in einer Xen-Umgebung eingesetzt werden. Ein typisches Szenario für System-Administratoren ist das Update von älteren Linux-Systemen auf eine neue Distribution. Oft sind alte Maschinen mit vielen Diensten ausgestattet, die dabei für den Betrieb des Netzes laufen müssen. Für ein Update auf eine neue Maschine sind ausgiebige Tests, möglichst kurze Ausfallzeiten bei der Umstellung sowie ein Rollback-Szenario nötig. Etwas entspannter ist die Situation mit Hilfe von Virtualisierung. Zunächst wird ein neues Linux-System installiert und das alte System in einer virtuellen Umgebung gestartet. Im Idealfall ändert sich dadurch zunächst nichts für 269

9 Dennis Zimmer und Andreas Niederländer die Clients im Netzwerk: Sie greifen immer noch auf den alten Server zu mit dem Unterschied, dass der Server virtuell ist. Im zweiten Schritt installiert man neben dem alten Server als Gast weitere virtuelle Maschinen, auf die man dann die Dienste des alten Servers nach und nach migriert, bis der alte Server dann ganz deaktiviert werden kann. Ein Rollback auf die alte Konguration ist hier dann ganz einfach: Man aktiviert den entsprechenden Dienst einfach wieder auf der alten (virtuellen) Maschine. Auf die Problematik des Zugriffs mehrerer Betriebssysteme auf den Prozessor und der damit notwendigen Anpassung des Gastbetriebssystemkernels haben die beiden groÿen Hersteller von x86-kompatiblen Prozessoren reagiert. So gibt es seit kurzem Prozessoren, die es erlauben, ein Gastbetriebssystem ohne Anpassung des Kernels zu betreiben. Intel nennt diese Technik Vanderpool Technology (VT) und AMD Pacica. Aktuelle Prozessoren der beiden Hersteller sind bereits am Markt verfügbar. Die groÿen Serverhersteller beginnen seit Sommer 2006, ihre Produkte mit VT bzw. Pacica auszustatten. Mit dieser Technik, die auch vollständige Virtualisierung genannt wird, ist es prinzipiell möglich, jedes x86-betriebssystem in einer virtuellen Umgebung zu starten also auch Windows. 4.2 Vor- und Nachteile von Xen Der Einsatz von Virtualisierung mit Xen hat auch seine Nachteile. Das wohl gröÿte Manko ist derzeit die noch fehlende Integration in die Wirtssysteme. Ansprechende Kongurations- und Administrationsoberächen, wie man sie beispielsweise von VMware 10 gewohnt ist, sucht man vergeblich. Auch die Möglichkeit, ein oder mehrere Snapshots eines Gastes zu erstellen, bietet Xen von sich aus nicht. Hierzu muss man auf entsprechende Techniken des darunterliegenden Betriebssystems des Wirts z. B. LVM Snapshots zurückgreifen. Ein weiterer Nachteil ist die feste Partitionierung des Speichers. Es ist nicht möglich, dass die Gäste den zur Verfügung stehenden Hauptspeicher dynamisch nutzen können. Vielmehr gibt es hier nur eine starre Partitionierung, die für einen Gast immer denselben Anteil an Speicher belegt, egal, ob der Gast diesen Speicher nun braucht oder nicht. Trotzdem kann Xen in vielen Bereichen Vorteile aufweisen. Durch die dünne Virtualisierungsschicht arbeiten die Gäste nahe an der Hardware, ein Aspekt, der sich vor allem in der Gesamtperformance der Gäste niederschlägt. Benchmarks mit unserer Testhardware haben ergeben, dass der Zugriff auf Block-Devices hier unsere SATA-Platten nur etwa 10 Prozent langsamer ist als im Wirtssystem. Zugriffe auf das RAM des Gastes waren in unseren Tests genauso schnell wie auf dem Wirt. Kein Wunder, da der Wirt (als Dom0) ja letztendlich auch nur ein Gast des VMM ist. Die Workload-Protection genannte Technik erlaubt es dem Administrator sogar, die Zugriffe auf die Ressourcen mit entsprechenden Prioritäten zu versehen und Grenzen für den Ressourcenverbrauch (insbesondere CPU) festzulegen. Somit sollen z. B. 10 Mehr zu dem VMware Server und dem VMware Player in Zimmer (2006) 270

10 OpenVZ und Zen Denial-of-Service-Angriffe auf einen Gast nur begrenzten Einuss auf andere Gäste auf der gleichen Maschine haben. Weitere Pluspunkte im Bereich Lastverteilung kann Xen durch die bereits erwähnte Live-Migration sammeln. Die breite Unterstützung durch namhafte Soft- und Hardwarehersteller unterstreicht das hohe Potenzial von Xen im professionellen Einsatz. 4.3 Zukunftsperspektiven Es ist davon auszugehen, dass Xen das Open-Source-Virtualisierungsprodukt der nächsten Jahre wird. Es sieht so aus, als könnten sich die Konkurrenten wie AMD und Intel oder auch Microsoft und die Open-Source-Community auf diesen neutralen Standard einigen. Wir können also davon ausgehen, dass die Integration von Xen fester Bestandteil zukünftiger Linux-Distributionen sein wird und dass es in Zukunft nur noch Server mit der notwendigen CPU-Unterstützung geben wird. Dadurch wird sich auch das Angebot an kommerziellem Support erweitern, insbesondere für die Enterprise-Distributionen. Ob Xen allerdings langfristig bezüglich Umfang, Stabilität und Zertizierung mit ESX, dem weit verbreiteten und äuÿerst leistungsfähigen Virtualisierungsprodukt von VMware, vergleichbar sein wird, bleibt offen. Technik 5 Fazit Virtualisierung ist und bleibt ein zukunftsträchtiges Thema. Die beiden Produkte OpenVZ und Xen können sowohl bei Einzelanwendern als auch in professionellen Infrastrukturen bei entsprechender Planung eingesetzt werden. Aufgrund der Weiterentwicklung durch die Community und professionelle Unternehmen werden die Produkte stetig verbessert und nehmen an Funktionsumfang zu. Vor allem Xen wird in der nächsten Zeit in vielen Linux-Distributionen zu nden sein. Einige Virtualisierungshersteller nutzen schon jetzt die Xen-Basis, um kommerzielle Produkte und Leistungen anzubieten. Literatur Radonic, A. und Meyer, F. (2006), XEN3, 1. Au., Franzis' Verlag GmbH, Poing. Zimmer, D. (2005), VMware und Microsoft Virtual Server, 1. Au., Galileo Press, Bonn. Zimmer, D. (2006), VMware Server und VMware Player, 1. Au., Galileo Press, Bonn. 271