Ziele definieren
Geht es um die Bereitstellung homogener, aber abgetrennter virtueller Ausführungsumgebungen, so kann der Ansatz der vollen Virtualisierung sehr gut weiterhelfen. Auch bei unterschiedlichen physischen Wirtssystemen besteht die Möglichkeit, die virtuellen Maschinen dennoch gleich zu gestalten. Damit lassen sich die Gastsysteme beliebig und teilweise sogar dynamisch über einen Pool von physischen Systemen verschieben, sofern Voraussetzungen wie zum Beispiel ein SAN erfüllt sind.
Gleichzeitig ist durch Over-Committment, also ein mehrfaches Verplanen physischer Ressourcen in den virtuellen Maschinen, ein Einsparungseffekt zu erzielen. Dazu müssen allerdings die Lastprofile zueinander passen: Spitzen mehrerer virtueller Systeme dürfen nicht gleichzeitig auftreten.
Das Wirtssystem und seine Gäste wie auch die Gastsysteme untereinander sind strukturell voneinander vollständig entkoppelt - ein wichtiger Sicherheitsaspekt. Alle benutzen lediglich dieselbe CPU. Dabei ist es egal, ob das Wirtssystem ein eigenständiger Virtual Machine Monitor ist - wie etwa VMware ESX -, auf dem als Gastsysteme Linux, FreeBSD oder Windows laufen, oder ob die virtuelle Maschine ein vollständiges Wirtssystem voraussetzt, etwa wie Microsofts Virtual PC (Abbildung 2).
Die Komplexität des zweiten Szenarios ist aber eher hoch, weil zur Verwaltung der Gastsysteme noch eine weitere Softwarekomponente für die Virtualisierung hinzukommt. Die Ausführungsgeschwindigkeit unprivilegierter Maschinen-Instruktionen eines virtuellen Systems ist bei vollständiger Virtualisierung theoretisch identisch mit der einer nativen Umgebung, obwohl die derzeitigen Intel- und AMD-Prozessoren noch leistungsmindernde Anpassungen erfordern.
Bei der Leistung der virtuellen Peripherie kann es allerdings große Unterschiede geben. Hier sind im Einzelfall genaue Untersuchungen erforderlich, ob das gewünschte Virtualisierungsziel überhaupt erreichbar ist.
|
Abbildung 1: Virtuelle Maschine mit einem Virtual Machine Monitor. Ein konkretes Beispiel für diesen Aufbau ist VMware ESX.
|
|
Abbildung 2: Virtuelle Maschine mit vollständigem Wirtsbetriebssystem. So arbeitet zum Beispiel VMware Workstation.
|
Virtuelle Server
Erzwingen die Anforderungen keine vollständige Virtualisierung, sondern geht es hauptsächlich um eine sichere Kapselung von Anwendungen und Diensten und darf der Betriebssystemkern für Gäste und Wirt identisch sein, dann kommen virtuelle Serverumgebungen oder Betriebssystempartitionen in Betracht. Wenn ein Betriebssystemkern über die Möglichkeit verfügt, die Menge der Prozesse, das Dateisystem sowie alle weiteren Ressourcen derart aufzuteilen, dass sich Prozesse unterschiedlicher Partitionen nicht gegenseitig beeinflussen und auch die Ressourcen der anderen Partition nicht erreichen, dann lassen sich diese Partitionen beinahe wie eigenständige physische Server betreiben. (Abbildung 3).
|
Abbildung 3: Partitionierung des Betriebssystems. Das ist die Technik von Linux Vserver und OpenVZ, der Jails in FreeBSD oder der Zonen in Solaris.
|
Die Vorteile der Partitionierung sind: Weniger Latenz und Overhead gegenüber virtuellen Maschinen, bei denen mehrere Kerne neben- und übereinander arbeiten und Daten mehrfach gepuffert und umkopiert werden. Genau wie bei virtuellen Maschinen ist hier auf das Lastprofil der Dienste und Applikationen in den Partitionen zu achten. Der Performanceverlust gegenüber einer nativen Umgebung ist zwar vernachlässigbar, doch eine Kapazitätsplanung muss auch hier erfolgen. Ein Over-Committment ist nicht grenzenlos möglich.
Wenn also Aktivitätsträger (Threads) nicht mehr nur in traditionellen Prozessen gekapselt sind, sondern darüber hinaus genau einer Partition zugeordnet werden, können Root-Prozesse der Partition A die Prozesse der Partition B weder sehen noch beeinflussen. Gleiches gilt für das Dateisystem. Bekommt die Partition A einen Teilbaum ab »/A« exklusiv zugeordnet und die Partition B einen Teilbaum ab »/B«, dann sind hier auch die Rechte des übermächtigen Root-Users gut kanalisiert. Natürlich muss der Admin auch alle anderen Ressourcen entsprechend zuteilen, zum Beispiel die Netzwerkinterfaces. Ein direkter Hardwarezugriff ist dabei sicher auszuschließen. Ein Zugriff auf »/dev/kmem« oder »/dev/sda« darf ausschließlich den Root-Prozessen einer bestimmten Partition erlaubt sein.
| Whitepaper |
|---|
|
The Role of Open Source in Data Integration
Obwohl in den letzten Jahren viele technische Fortschritte erzielt werden konnten, verfügen die meisten Datenintegrationsprozesse nach wie vor nur über eine sehr begrenzte Automatisierung. Das vorliegende White Paper von dem Industry Analyst Mark Madson wird zunächst ein grundlegendes Verständnis von Daten Integration vermitteln, die Vorzüge von Open Source Lösungen für Daten Integration erläutern und Ihnen professionelle Empfehlungen geben, damit Sie Ihre Integrationsjobs noch einfacher und produktiver gestalten können.
Download PDF (Registrierung erforderlich)
|
|
Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele (Folge 2)
Der zweite Teil des Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele White Papers beleuchtet anhand weiterer ausgewählter Case Studies die Implementierung von Open Source Datenintegration in der Praxis und benennt die daraus resultierenden Vorteile.
Download PDF (Registrierung erforderlich)
|
Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links"
nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedrucken Fassung entsprechen.
|
