Sogar einen einzelnen Server virtualisieren

Ich stelle in Gesprächen rund um die Virtualisierung sehr häufig fest, dass das Konzept der Konsolidierung – das im Kontext der Server-Virtualisierung das Zusammenführen mehrerer zuvor physischer Workloads auf einem einzigen physischen Gerät bezeichnet, wobei die Trennung durch die Grenzen der virtuellen Maschinen gewährleistet wird – als der Kerngrundsatz und das fundamentale Merkmal der Virtualisierung behandelt wird. Ohne Zweifel stellt die Workload-Konsolidierung eine erstaunliche Chance der Virtualisierung dar, aber es ist äußerst wichtig, dass der Wert der Virtualisierung und der Wert der Konsolidierung nicht verwechselt werden. Allzu oft habe ich festgestellt, dass die Konsolidierung als der Schlüsselwert der Virtualisierung und als deren primäre Rechtfertigung angesehen wird, doch das ist nicht der Fall. Die Konsolidierung ist eine Zusatzfunktion, sollte aber niemals erforderlich sein, wenn man die Virtualisierung rechtfertigt. Die Virtualisierung sollte eine nahezu ausgemachte Sache sein, während die Konsolidierung bewertet werden muss und vielfach nicht zum Einsatz käme. Dass Workloads nicht konsolidiert werden sollten, sollte niemals zu der Überzeugung führen, dass diese Workloads nicht virtuell sein sollten. Ich möchte den Entscheidungsraum der Virtualisierung erkunden, um zu sehen, wie wir diesen Punkt betrachten sollten.

Virtualisierung sollte als Hardware-Abstraktion verstanden werden, denn das ist es, was sie in praktischem Sinne wahrhaftig ist. Die Virtualisierung kapselt die Hardware und präsentiert den Gastbetriebssystemen einen vorhersehbaren, makellosen Hardware-Satz. Das mag klingen, als füge es Komplikationen hinzu, aber in Wirklichkeit vereinfacht es tatsächlich eine Menge Dinge, sowohl für die Hersteller von Betriebssystemen und Treibern als auch für die IT-Praktiker, die Systeme entwerfen. Gerade weil Computer, Computer-Peripheriegeräte und Betriebssysteme derart komplexe Gebilde sind, entfernt diese zusätzliche Schicht letztlich tatsächlich Komplexität aus dem System, indem sie standardisierte Schnittstellen schafft. Aus Standardisierung erwächst Einfachheit.

Genau dasselbe Konzept, einer Softwareschicht eine standardisierte, virtuelle Maschine zu präsentieren, existiert auch in anderen Bereichen des Computings, etwa in der Art und Weise, wie viele Programmiersprachen implementiert sind. Dies ist ein sehr ausgereiftes und zuverlässiges Computing-Modell.

Die Hardware-Abstraktion und die Stabilität, die sie mit sich bringt, sind allein schon Grund genug, durchgängig auf Virtualisierung zu standardisieren, aber die praktische Natur der Hardware-Abstraktion, wie sie von allen uns heute zur Verfügung stehenden Enterprise-Virtualisierungsprodukten umgesetzt wird, bringt uns noch wichtigere Funktionen. Gewiss lassen sich die meisten Vorteile der Virtualisierung auch auf andere Weise erzielen, aber selten so vollständig, zuverlässig, einfach oder kostenlos wie durch die Virtualisierung.

Der größte Satz zusätzlicher Funktionen ergibt sich typischerweise aus der Abstraktion von Storage und Arbeitsspeicher, die die Möglichkeit eröffnet, vom Storage oder sogar vom gesamten laufenden Zustand einer virtuellen Maschine einen Snapshot zu erstellen, das heißt, ein Abbild des laufenden Systems anzufertigen und es in einer Datei zu speichern. Diese Fähigkeit führt zu vielen sehr wichtigen Möglichkeiten, etwa der Möglichkeit, vor der Installation neuer Software, der Änderung von Konfigurationen oder dem Patchen einen System-Snapshot zu erstellen, was extrem schnelle Rollbacks erlaubt, falls etwas schiefgehen sollte. Diese scheinbar geringfügige Funktion kann zu großer Sorgenfreiheit und zur Gesamtzuverlässigkeit des Systems führen. Sie macht zudem das Testen von Funktionen und das Zurückrollen oder wiederholte Testen in Nicht-Produktionsumgebungen sehr einfach.

Die Fähigkeit, aus der Abstraktionsschicht heraus einen Snapshot zu erstellen, führt auch zur Fähigkeit, „Image-basierte Backups“ anzufertigen, das heißt Backups, die über den Snapshot-Mechanismus auf der Ebene des Blockgeräts erstellt werden statt aus der Dateisystemschicht des Betriebssystems heraus. Dies ermöglicht betriebssystemunabhängige Backup-Mechanismen und Backups, die den gesamten System-Storage-Pool auf einmal umfassen. Image-Backups ermöglichen das, was traditionell als „Bare-Metal-Restores“ bekannt war – das gesamte System kann ohne zusätzliche Interaktion in einen vollständig lauffähigen Zustand wiederhergestellt werden – einfach und sehr schnell. Nicht alle Hypervisor-Hersteller beinhalten diese Fähigkeit oder beinhalten sie in gleichem Maße, sodass es, obwohl es sich konzeptionell um eine bedeutende Funktion handelt, entscheidend ist, dass das Ausmaß, in dem diese Funktion existiert oder lizenziert ist, von Fall zu Fall betrachtet werden muss (namentlich beinhaltet HyperV dies vollständig, XenServer beinhaltet es teilweise, und VMware vSphere beinhaltet es nur in den nicht-kostenlosen Lizenzstufen). Wo verfügbar, ermöglichen Image-basierte Backups eine extrem schnelle Wiederherstellung mit Geschwindigkeiten, die mit anderen Backup-Methoden undenkbar wären. Das Wiederherstellen von Systemen in Minuten ist möglich, von der Katastrophe zur Wiederherstellung!

Die Fähigkeit, virtuelle Maschinen als Dateien zu behandeln (zumindest, wenn sie nicht aktiv laufen), bietet zusätzliche Vorteile, die mit den oben aufgeführten Backup-Vorteilen verwandt sind. Namentlich die Fähigkeit, schnell und einfach zwischen physischen Hosts zu migrieren und sich sogar zwischen unterschiedlicher Hardware zu bewegen. Traditionell bedeuteten Hardware-Upgrades oder -Austausche einen komplizierten, gefahrenträchtigen Migrationsprozess. Mit moderner Virtualisierung kann der Wechsel von bestehender Hardware zu neuer Hardware ein zuverlässiger, zerstörungsfreier Prozess mit sicheren Rückfalloptionen und geringer oder möglicherweise sogar gar keiner Ausfallzeit sein! Aufgaben, die ungewöhnlich sind, aber zuvor sehr riskant waren, können heute oft trivial werden.

Oft ist dies der wahre Vorteil der Virtualisierungs- und Abstraktionsmechanismen. Es geht nicht zwangsläufig darum, den täglichen Betrieb eines Systems zu verbessern, sondern darum, das Risiko zu reduzieren und künftig Flexibilität und Optionen zu bieten. Sich auf Unbekannte vorzubereiten, die entweder unvorhersehbar sind oder in den meisten gängigen Situationen schlicht ignoriert werden. Eine solche Planung wird selten überhaupt durchgeführt, sehr zum Leidwesen der IT-Abteilungen, die mit schwierigen und gefährlichen Upgrades zurückbleiben, welche leicht hätten entschärft werden können.

Es gibt viele Funktionen der Virtualisierung, die nur auf besondere Szenarien anwendbar sind. Viele Virtualisierungsprodukte beinhalten Live-Migrations-Werkzeuge, um laufende Workloads ohne Ausfallzeit zwischen Hosts oder möglicherweise sogar zwischen Storage-Geräten zu verschieben. Optionen für Hochverfügbarkeit und Fehlertoleranz sind oft verfügbar und erlauben es manchen Workloads, sich schnell oder sogar transparent von einem Hardware-Ausfall des Systems zu erholen, indem sie ohne Benutzereingriff von der ausgefallenen Hardware zur redundanten Hardware wechseln. Obwohl dies eher ein Nischenvorteil ist und gewiss nicht in eine Liste der Gründe gehört, warum „nahezu alle Workloads“ virtuell sein sollten, ist es als ein primäres Beispiel für Funktionen erwähnenswert, die oft verfügbar sind und später hinzugefügt werden könnten, falls ein Bedarf dafür entsteht – solange die Virtualisierung von Anfang an genutzt wird. Andernfalls wäre eine Migration zur Virtualisierung erforderlich, bevor man solche Funktionen nutzen könnte.

Virtualisierungsprodukte werden typischerweise mit umfangreichen Zusatzfunktionen ausgeliefert, die nur in bestimmten Fällen von Bedeutung sind. Sehr viele von ihnen fallen in einen großen Pool des „für den Fall künftigen Bedarfs“. Die womöglich größte von allen ist das Konzept der Konsolidierung, wie ich zu Beginn dieses Artikels erwähnt hatte. Wie andere fortgeschrittene Funktionen, etwa die Hochverfügbarkeit, ist die Konsolidierung kein Kernwert der Virtualisierung, wird aber oft damit verwechselt. Workloads, die nicht beabsichtigen, Hochverfügbarkeit oder Konsolidierung zu nutzen, sollten dennoch virtualisiert werden – ohne jeden Zweifel. Doch diese Funktionen sind als künftige Optionen so potenziell wertvoll, selbst für Szenarien, in denen sie heute nicht genutzt werden, dass sie ungeachtet dessen erwähnenswert sind.

Die Konsolidierung kann äußerst wertvoll sein, und es lässt sich leicht nachvollziehen, warum so viele Menschen schlicht annehmen, dass sie genutzt werden wird, da sie so oft so wertvoll ist. Die Verfügbarkeit dieser Möglichkeit, sobald eine Infrastruktur einmal vorhanden ist, ist ein zentraler Punkt der Flexibilität, um die Unbekannten künftiger Workloads zu bewältigen. Selbst wenn die Konsolidierung heute völlig unnötig ist, besteht eine sehr gute Chance, sogar in den kleinsten Unternehmen, dass sie zu einem unbekannten Zeitpunkt in der Zukunft nützlich sein wird. Die Virtualisierung bietet uns eine Absicherung gegen das Unbekannte, indem sie unsere Systeme auf ein Höchstmaß an Flexibilität vorbereitet. Einer der wichtigsten Aspekte jeder IT-Entscheidung ist das Steuern und Reduzieren von Risiken. Die Virtualisierung tut genau dies.

Bei der Virtualisierung geht es um Stabilität, Flexibilität, Standardisierung, Verwaltbarkeit und das Befolgen von Best Practices. Es gibt heute kein bedeutendes Enterprise-Virtualisierungsprodukt, das nicht zumindest in irgendeiner Form kostenlos verfügbar wäre. Jede Anschaffung würde natürlich eine sorgfältige Analyse von Wert gegenüber Aufwand erfordern. Da jedoch derzeit von allen vier zentralen Produktlinien in diesem Bereich (Xen, KVM, HyperV und VMware vSphere) hervorragende Enterprise-Optionen kostenlos verfügbar sind, müssen wir keine solche Analyse anstellen. Wir müssen lediglich aufzeigen, dass die Implementierung kein Negativum ist.

Was die Entscheidungsfindung einfach macht, ist, dass wir, wenn wir den Nominalfall betrachten – das absolute Minimum, das jede Enterprise-Virtualisierung bietet, nämlich die kostenlosen Vorteile aus Abstraktion, Kapselung und Storage –, feststellen, dass wir in praktisch allen Fällen einen kleinen Vorteil haben, keine messbaren Nachteile und einen sehr großen potenziellen Vorteil aus den Bereichen der Flexibilität und der Absicherung gegen künftigen Bedarf. Dies lässt uns mit einem klaren Gewinn und der einfachen Entscheidung zurück, dass die Virtualisierung – da sie kostenlos ist und für sich genommen im Wesentlichen keine Nachteile hat – in jedem Fall genutzt werden sollte, in dem es möglich ist (was zum jetzigen Zeitpunkt im Wesentlichen alle Workloads sind). Zusätzliche, nicht zum Kern gehörende Funktionen wie Konsolidierung und Hochverfügbarkeit sollten separat und erst nachdem die Entscheidung zur Virtualisierung bereits gefestigt ist, bewertet werden. Kein fehlender Bedarf an diesen erweiterten Funktionen legt in irgendeiner Weise nahe, dass die Virtualisierung nicht aufgrund ihrer eigenen Vorzüge gewählt werden sollte.

Dies ist schlicht eine Erläuterung bestehender Best Practices der Branche, die seit vielen Jahren darin bestehen, alle potenziellen Workloads zu virtualisieren. Dies ist weder neu noch ein Richtungswechsel. Allein die Tatsache, dass die durchgängige Virtualisierung seit nahezu einem Jahrzehnt eine Best Practice der Branche ist, zeigt, was für eine bewährte und akzeptierte Methodik dies ist. Es wird immer Workloads geben, die aus dem einen oder anderen Grund schlicht nicht virtualisiert werden können, aber diese sollten sehr wenige und weit verstreut sein und eine eingehende Prüfung veranlassen, um herauszufinden, warum dies der Fall ist.

Bei der Entscheidung, ob virtualisiert werden soll oder nicht, sollte der Ansatz immer darin bestehen, die Virtualisierung als ausgemachte Sache vorauszusetzen und nur dann davon abzuweichen, wenn ein solider, begründeter technischer Grund dies unmöglich macht. Nahezu alle Argumente gegen die Virtualisierung entspringen einer Position des Missverständnisses, verbunden mit der Überzeugung, dass Konsolidierung, Hochverfügbarkeit, externer Storage, Lizenzkosten und andere lose verwandte oder unverwandte Konzepte der Virtualisierung irgendwie wesenseigen seien. Das sind sie nicht und sie sollten nicht in eine Entscheidung zwischen virtueller und physischer Bereitstellung einbezogen werden. Sie sind getrennt und sollten als getrennte Optionen bewertet werden.

Es ist erwähnenswert, dass, da die Konsolidierung nicht Teil unserer Entscheidungsmatrix bei der Bildung des Basiswerts der Virtualisierung ist, alle Gründe, die wir anführen, gleichermaßen sowohl für Eins-zu-eins-Bereitstellungen (also eine einzelne virtuelle Maschine auf einem einzelnen physischen Gerät) als auch für konsolidierte Workloads (also mehrere virtuelle Maschinen auf einem einzelnen physischen Gerät) gelten. Es gibt keine Situation, in der ein Workload „zu klein“ wäre, um virtualisiert zu werden. Wenn überhaupt, ist es umgekehrt: Nur bei den größten Workloads, typischerweise mit extremer Latenzempfindlichkeit, existiert noch ein Nischenszenario der Nicht-Virtualisierung als Randfall, aber selbst diese Fälle verschwinden rasch, da die Latenzverbesserungen bei der Virtualisierung und die Gesamtkapazitäten für Workloads zunehmen. Diese Fälle sind so selten und verschwinden so schnell, dass es wahrscheinlich unklug ist, überhaupt die Zeit aufzuwenden, diese Fälle zu erwähnen, da es nahelegt, dass Ausnahmen, basierend auf Kapazitätsbedarf, häufig genug sind, um sie in Betracht zu ziehen, was sie nicht sind, besonders nicht im SMB-Markt. Je kleiner der Workload, desto idealer für die Virtualisierung, aber dies dient nur dazu zu untermauern, dass kleine Unternehmen mit einzelnen Workloads der idealste Fall für die durchgängige Virtualisierung sind und keine Ausnahme von den Best Practices darstellen – nicht, um nahezulegen, dass größere Unternehmen ihrerseits nach Ausnahmen suchen sollten.