Die grundsätzliche Funktionsweise der Virtualisierung

Die elementare Prozesskommunikation

Ganz wesentlich in diesem Zusammenhang ist dann noch die elementare Prozesskommunikation, weil sich die Elementarprozesse durchaus etwas mitzuteilen können. Nehmen wir ein Beispiel: Die Eingabe.

Ein anwendungsunterstützender Elementarprozess ist an einer Stelle angekommen, wo er gerne eine Eingabe hätte. Wir wissen, dass er darauf nicht warten darf. Außerdem wäre das auch zwecklos, der bei einer Eingabe interessierende Wert muss von einem systemunterstützenden Elementarprozess geholt werden, denn der anwendungsunterstützende Elementarprozess hat keinerlei Zugriff auf die physikalischen Medien. Also benötigen wir eine Kommunikation zwischen diesen beiden Prozessen. Bevor er stillgelegt wird, formuliert der anwendungsunterstützende Elementarprozess einen Auftrag an den nächsten I/O-Prozess. Der I/O-Prozess sieht – nachdem man ihn geweckt hat – nach, ob für ihn ein I/O-Auftrag da ist und führt diesen aus. Wird der beauftragende anwendungsunterstützende Elementarprozess dann aufgeweckt, holt er sich als erstes den Wert ab und kann dann sofort damit weiterarbeiten.

Dieses Beispiel zeigt eine ganz elementare Interprozesskommunikation, IPC. Das ist natürlich im Laufe der Jahrzehnte wesentlich erweitert worden. Die wichtigste Erweiterung ist sicherlich, dass nicht nur anwendungsunterstützende Elementarprozesse und systemunterstützende Elementarprozesse kommunizieren können, sondern auch diese Prozessarten untereinander.

Bleibt jetzt nur noch die Frage zu klären, inwieweit die Einführung mehrerer Prozessoren oder einer Multi-Core-Architektur dem Betriebssystem hilft. Bis vor wenigen Jahren hatte ein Prozessor nur einen einzigen Rechenkern. Die Multi-Core Architektur besagt, dass ein physikalischer Prozessorchip mehrere vollständige und an und für sich autonome Rechenkerne besitzt, siehe Abbildung 2.

Wie bereits dargestellt, gibt es Elementarprozesse, die vom Scheduler gesteuert werden. Ist nur ein Prozessor vorhanden, muss der Scheduler alle Elementarprozesse auf diesen einen Prozessor abbilden, es kann also zu einer Zeit wirklich nur ein Prozess laufen. Die Verfügbarkeit mehrerer Prozessoren führt dazu, dass der Scheduler nunmehr mehr Möglichkeiten hat. Er kann jetzt zwei, vier, acht oder mehr Prozesse gleichzeitig laufen lassen, je nach Anzahl der Prozessoren oder Cores. Das hört sich jetzt einfach an, wird aber in der Praxis dadurch kompliziert, dass nicht alle Kombinationen parallel laufender Elementarprozesse wirklich sinnvoll sind.

Probleme bei Multi-Prozessor- oder Multi-Core-Umgebungen

Entwirft man nun ein System aus mehreren parallelen Prozessen für eine Multi-Prozessor oder Multi-Core-Umgebung, muss man darauf achten, dass sich die Prozesse nicht gegenseitig stören. Dafür gibt es eine einfache Grundregel: zwei Prozesse können sich genau dann nicht stören und parallel ausgeführt werden, wenn ihre Nachbereiche disjunkt sind. Es gibt dazu eine ganze umfangreiche Theorie mit noch viel mehr Regeln, aber das führt jetzt hier nicht weiter.

Pauschal kann man sagen, dass sich z.B. anwendungsunterstützende Elementarprozesse und systemunterstützende Elementarprozesse gegenseitig selten stören. Natürlich gibt es auch Prozesse, die unmittelbar voneinander abhängen und nacheinander ausgeführt werden müssen. Ich hatte ja eben die Ein- und Ausgabe vermöge entsprechender Elementarprozesse im Zusammenhang mit der IPC besprochen. Das ist genau so ein Beispiel. Man kann auch Anwendungen entwerfen, die sich eine mögliche Parallelität von Prozessen zunutze machen, um eine spezielle, umfangreiche Aufgabe zu erledigen. Das ist aber hier generell nicht das Thema und gehört auch auf eine andere Ebene. Natürlich gibt es über das Ganze noch viel mehr zu sagen, für die Erklärung der Virtualisierung reicht das aber erst mal.

Vom klassischen Betriebssystem zur Virtualisierung

Konstruktiv gesehen passiert Folgendes: man schreibt ein Programm, welches zunächst einmal den Status eines Anwendungsprogramms hat. Dieses Programm bildet die durch das Betriebssystem normalerweise erzeugte Oberfläche für die Bearbeitung von Laufzeitumgebungen, wie sie für die Ausführung von Anwendungsprogrammen erzeugt werden, in allen dafür wichtigen Einzelheiten getreu nach.

Dieses Programm ist eine virtuelle Maschine. Auf dieser virtuellen Maschine können dann Anwendungsprogramme genau so ablaufen, wie gewohnt: man erzeugt aus dem ausführfähigen Code mittels der weiter oben beschriebenen Zuordnungen eine Laufzeitumgebung, die wiederum auf Elementarprozesse abgebildet wird. Diese Elementarprozesse werden jetzt aber nicht mehr vom Scheduler der physikalischen Maschine bereitgestellt, sondern von dem Teil des „VM-Programms“, welches einen Scheduler nachbildet.

Virtualisierung bedeutet also in jedem Falle die Erzeugung einer zusätzlichen Betriebssystemebene.

Das „VM-Programm“ ist seinerseits aus der Perspektive der physischen Maschine und dem auf dieser laufenden Betriebssystem zunächst einmal nichts anderes als ein normales Anwendungsprogramm. Es muss also eine Laufzeitumgebung bekommen, die durch die Bindung an reale anwendungsunterstützende Elementarprozesse implementiert wird. Das hat Vor- und Nachteile, wie wir noch sehen werden; siehe Abbildung 3.

Sobald man verstanden hat, wie die einfache Virtualisierung funktioniert, kommen einige Bedenken auf, die die folgenden Bereiche betreffen:

• Möglicher Leistungsverlust
• CPU
• RAM
• I/O pro Sekunde, Latenz
• Netzwerk
• Offenheit
• Management (Umfang, Kosten)
• Sicherheit

Der aktuelle Schwung bei der Virtualisierung kommt daher, dass die Hersteller moderner Virtualisierungssoftware genau diese Probleme aufgegriffen und (in Stufen) weitgehend gelöst haben. Gleichzeitig hat sich mit den Multi-Core-Systemen eine Rechnergeneration entwickelt, die dafür sehr gute Voraussetzungen mit sich bringt.

Beginnen wir einfach einmal mit der Offenheit.

weiter mit: Offenheit

(ID:2050026)