Einführung und Überblick

Kommentieren Drucken
Teil 1 von 19 aus der Serie "Virtualisierungstechniken"

Seit Mitte 2007 ist die Virtualisierung in aller Munde. Eigentlich ist der Netzwerker es nicht so sehr gewohnt, sich mit Betriebssystem- und Anwendungskonzepten auseinanderzusetzen. Vielmehr war es ja das Bestreben der letzten Jahrzehnte, ein möglichst universelles Netz zu schaffen, mit dem man einerseits alles verbinden konnte, was man verbinden wollte und welches man durch entsprechende Konzepte skaliert hat, wenn es einmal eng wurde. Im Bereich eines RZ-Netzes kann die Virtualisierung aber weitreichende Konsequenzen haben, auf die man vorbereitet sein muss. Gleichzeitig wird bewusst, dass Virtualisierung und I/O-Konsolidierung eng miteinander verknüpft sind. Leider informieren die Hersteller von Virtualisierungssoftware nur sehr oberflächlich, weil sie viel Wissen über die inneren Mechanismen eines Betriebssystems voraussetzen. Dadurch fällt es dem Netzwerker schwer, einzuschätzen, was da eigentlich passiert. Genau diesem Mangel soll diese Serie abhelfen und das Verständnis für die Mechanismen der Virtualisierung soweit fördern, dass die Konsequenzen für RZ-Netze besser eingeschätzt werden können.

Wir werden das noch weiter vertiefen, aber die Virtualisierung setzt letztlich voraus, dass Speicherressouren ebenfalls virtualisiert sind (und zwar weit über das normale Verständnis eines schon lange so genannten virtuellen Speichers hinaus) und dass man auf sie freizügig zugreifen kann. I/O-Konsolidierung ist für die Virtualisierung nicht einfach „nice to have“, sondern bei weitergehenden Konzepten unabdingbar. Damit kommen wir sofort in den Bereich der Speicherproblematik. Das ist aber technisch wiederum nicht so einfach, weil sich in der Vergangenheit universelle Datennetze und spezialisierte Speichernetze unterschiedlich entwickelt haben. Auch das gehört natürlich zu den Themen dieser Serie.

Zwei Dinge fallen dem externen Betrachter sofort auf: Netzwerker entscheiden normalerweise nicht über die Einführung einer Virtualisierungslösung, sondern Systembetreiber. Die Systembetreiber verlangen aber dann, dass das Netz auch weiterhin so problemlos funktioniert wie bisher. Dem steht nun krass entgegen, dass die Netzwerker sich nicht viel mit der Virtualisierung beschäftigen mussten.

Nun ja, man könnte nun sagen, dass sie es sich einfach ansehen sollen. Dem steht aber wieder gegenüber, dass die Thematik nicht ohne weiteres trivial ist und Leute, die da drin stecken, so darüber reden, dass man nichts mehr versteht. Die Hersteller entsprechender Software, wie z. B. VMware, haben aber eine völlig unverständliche Informationspolitik. Noch nie in meiner langjährigen Tätigkeit habe ich so grottenschlechte Informationen zu einem Thema gefunden. Also, entweder wusste man es vorher schon oder konnte durch die Information nichts erfahren.

Also, die Serie könnten wir auch „Virtualisierung für Netzwerker“ nennen, ich will versuchen, das Thema so aufzuarbeiten, dass man die wesentlichen Dinge versteht und dann auch klar wird, wie weit und wie tief ihr Einfluss auf zukünftige Netze sein wird.

Wir kümmern uns also um

  • Grundkonzepte:
    • Grundideen, Vorzüge, Anforderungen (Überblick)
    • Prozesse im klassischen Betriebssystem
    • Vom klassischen Betriebssystem zur Virtualisierung
    • Grundsätzliche Konstruktionsalternativen
    • Transaktionsverarbeitung
  • Kommunikation virtueller Maschinen
    • IPC
    • Virtuelle Switches
  • Speicher- und I/O-Konsolidierung
  • I/O-Virtualisierung
  • weitere Virtualisierungsthemen
  • Konsequenzen für die Netzwerke

Virtualisierung: Grundidee, Vorzüge, Anforderungen

Zunächst betrachten wir in diesem Abschnitt Grundideen und die Ausgangslage. Dabei sehen wir mögliche Vorzüge der Virtualisierung. Es gibt sehr unterschiedliche Virtualisierungsmethoden wie Hosted Virtualization oder das Hypervisor-Konzept. Diese Methoden führen dann wiederum zu unterschiedlichen Konstruktionsalternativen, die in der Praxis auch ggf. kombiniert werden können. Außerdem ist Virtualisierung in der jetzigen Form recht jung, so dass eine Überarbeitung eines Produktes durchaus eine auch andere Konstruktion beinhaltet.

In den vergangenen Jahrzehnten gab es vorwiegend eine starre Zuordnung zwischen Rechner, Betriebssystem und Anwendungen. Schon in den 80er-Jahren wurde versucht, diese starre Zuordnung aufzulösen. Der sicherlich bekannteste Virtualisierungs-Urahn ist das VM (Virtual Machines) Betriebssystem von IBM.

Letztlich möchte man eine flexiblere Möglichkeit haben, Anwendungen auf Rechner und deren Ressourcen zu verteilen. Es geht dabei nicht um Anwendungen, die so rechenintensiv sind, dass sie mehrere Rechner benötigen, um in sinnvoller Zeit fertig zu werden, dafür gibt es gute Lösungen, sondern es geht um Anwendungen, die dergestalt sind, dass mehrere von ihnen auf einem einzelnen Rechner gut laufen.

Außerdem gibt es eine Reihe von Zielen, die man fast schon als traditionell bezeichnen könnte, wie z. B. die Steigerung der Leistung bei Transaktionsverarbeitung und Datenbankzugriffen, die ja für die allermeisten Anwendungen in modernen Unternehmen und Organisationen wirklich substantiell sind.

Wie schon gesagt könnte uns das eigentlich alles egal sein, aber die Einführung von Virtualisierung kann erhebliche Rückwirkungen auf die Netzwerke haben.

Es gibt eine Reihe von grundsätzlichen Motivationen, die sich anschaulich erklären lassen.

In einer normalen Umgebung ohne Virtualisierung gibt es unterschiedlich ausgelastete Rechner in dürftiger Organisationsstruktur. Das gilt vor allem für die so beliebten Farmen kleinerer Server. Ein Großrechnerbetreiber wird sich natürlich wehren, wenn man seine Struktur als unorganisiert bezeichnet, aber er muss immer relativ viel Arbeit aufwenden, um die Auslastung eines oder mehrerer Großrechner zu optimieren.

Der Einsatz von Virtualisierung eröffnet die Möglichkeit, Server besser zu organisieren und optimaler auszulasten, siehe dazu Bild 1.

Das hat vor allem den Vorteil, dass man auch ohne zusätzliche Server kaufen zu müssen, eine Redundanz schaffen kann, die man so vorher nicht hatte.

Die Virtualisierung kann kurz so charakterisiert werden, dass sie die bisher unflexiblen physikalischen Maschinen mit ihrer normalerweise recht starren Zuordnung zwischen Maschinen und Anwendungen flexibilisiert und ein System schafft, in dem man (virtuelle) Maschinen mit ihren assoziierten Anwendungen relativ freizügig über die physischen Maschinen zuordnen und bewegen kann.

Zur Redundanz sehen wir in Bild 2 wie Anwendungen von einer Maschine, die ein Problem hat, auf eine andere Maschine bewegt werden können, die eigentlich nur deshalb frei ist, weil man vorher mit Hilfe der Virtualisierung die Zuordnungen zwischen physischen Maschinen und Anwendungen neu organisieren und sozusagen aufräumen konnte.

Es gibt viele Systeme, bei denen Speichersysteme und Server am gleichen Netz angeschlossen sind, z. B. mit iSCSI (Network Attached Storage, NAS). In diesem Fällen kann man die Speichersysteme einfach in die Virtualisierung einbeziehen und auf ihnen ähnliche Funktionen ausüben, wie sie hinsichtlich der Anwendungen auf den Servern vorgenommen wurden: neu sortieren und optimieren. Im Bild 3 ist das so dargestellt, dass die zu bestimmten Anwendungen gehörigen Speicherbereiche ebenfalls neu angeordnet werden können. Auf diese Weise schafft man ebenfalls Redundanz ohne neue Speichersysteme kaufen zu müssen.

Natürlich möchte man das auch mit anderen Speichersystemen machen. Leider stößt man da auf das oben bereits angesprochene Problem, dass sich die Netze für „normale“ Systeme und spezialisierte Speicher in der Vergangenheit sehr unterschiedlich entwickelt haben. Die High-End-Alternative zum NAS ist das Storage Area Network SAN, welches überwiegend in Fibre Channel FC-Technologie ausgeführt wurde. Der FC hat von der Konstruktion her andere Eigenschaften als das Ethernet und es ist alles andere als trivial, das in einer Netzstruktur zusammenzufügen. Insgesamt kann man festhalten, dass Unternehmen und Organisationen viel Geld in FC-SANs gesteckt haben, weil dieses Umfeld eine Reihe zusätzlicher Möglichkeiten, vor allem hinsichtlich Administration, Disaster Recovery und Organisation bietet, auf die man natürlich in Zukunft keineswegs verzichten möchte.

Die Hersteller von Virtualisierungsprodukten wie VMware, Citrix oder Microsoft geben eine Reihe von Versprechungen, die eintreten sollen, wenn man die Virtualisierung sinnvoll implementiert und einsetzt:

  • Senkung der HW-Kosten 35 – 70%
  • Halbierung der Betriebskosten
  • Senkung des Platzbedarfs 35 – 50%
  • Senkung des Stromverbrauchs 40 – 60%
  • Dynamische Anpassung an die Betriebsmittel
  • Hochverfügbarkeit
  • Einfaches Backup-Konzept
  • Einfache Desaster-Recovery-Lösung

Das Faszinierende ist nun, dass diejenigen, die das wirklich ausprobiert haben, derartige Ergebnisse tatsächlich bestätigen. Allerdings ist auch klar geworden, dass man zwangsläufig wieder auf eine Reihe neuer Probleme stößt, aber dazu mehr.

Der Erfolg der Virtualisierungstechnologien ist natürlich auch dadurch zu erklären, dass die Ausgangslage in vielen Fällen so schlecht ist, dass selbst eine weit suboptimale Virtualisierung hier schon Verbesserungen bringt. Generell kann man die Ausgangslage oft folgendermaßen charakterisieren:

  • Viele allein stehende Server mit lokalem Speicher
  • Viel lokaler Speicher, unkoordinierte Ansammlungen von Network Attached Storage NAS und anderen lokalen Speicherformen
  • SANs eher in großen Umgebungen
  • Das bedeutet:
    • Stark unterschiedlich ausgelastete Server
    • Hohe Kosten für HW, Lizenzen und Pflege
    • 100% Desaster Recovery schwierig bis unmöglich
    • Unübersichtlicher Betrieb
    • Abwärme, Stromverbrauch, Platzbedarf
    • Desolate Verkabelungssituation

Technisch gesehen kann man sagen, dass die Virtualisierung erst dann wirklich eine Chance bekommt, Sinn zu machen, wenn die zugrundeliegende Technik das unterstützt. Zunächst einmal benötigen wir eine Multi-Core-Architektur. Das ist aber ja weiter auch nicht problematisch, da die technische Entwicklung stark in diese Richtung geht. Intel hat Mitte 2009 eine 8-Core-Prozessorfamilie für Server vorgestellt, 4-Core-Prozessoren gibt es schon in Notebooks.

In Bild 4 sehen wir noch eine typische Struktur mit zwei 4-Core-Prozessoren.

In Bild 4 sehen wir aber noch etwas anderes: Für den Anschluss eines entsprechenden Servers an die Außenwelt sollten es schon 10 Gbps sein, Server mit Ein-Gigabit-Schnittstellen gehören der Vergangenheit an.

Am Beispiel Intel können wir das schön zeigen: Der Standard 2010/11 ist der Nehalem mit 8 Cores und 16 Threads und einer viermal so großen Speicherbandbreite wie sein unmittelbarer Vorgänger. Für die Zukunft heißt das:

  • Moores Law ist für die nächsten 10 Jahre gesichert.
  • Die 32-nm-Technik kommt in 2010 (Westmere).
  • Mit 8 Sockets werden wir innerhalb der nächsten 3 Jahre bis zu 128 Cores pro Server sehen.

Natürlich gibt es auch Engpässe:

  • I/O allgemein,
  • kupferbasierende Schnittstellen sind auf 100 Gigabit limitiert,
  • Glasfaser-Schnittstellen sind momentan deutlich zu teuer,
  • RAM: 128 Cores erfordern bis zu 512 GB RAM.

Das Fazit ist: die Rechenleistung pro Server steigt in den nächsten 3 bis 5 Jahren um bis zu Faktor 10 (Core-Verdopplung, Multithreads, mehr Leistung pro Core). Damit ist es aber noch lange nicht zu Ende. Schon 2008 hatte Intel einen experimentellen 80-Core-Prozessor auf der Größe eines halben Fingernagels. Gehen Sie einfach mal auf www.intel.com, da ist sehr schön dokumentiert, was uns alles noch erwartet.

Bild 5 zeigt abschließend noch ein Architekturdiagramm des Nehalem.

Also, sehen wir uns jetzt einmal an, wie das auf der Seite des Betriebssystems funktioniert.

Teil 2: Prozesse in klassischen Betriebssystemumgebungen »


zugeordnete Kategorien: Virtualisierung
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.