Ein guter Freund von mir meinte neulich: “Virtualisierung? Das ist doch nur eine Retro-Bewegung, zurück zum Mainframe, diesmal halt auf Commodity-Hardware.” Was er vergessen hat zu erwähnen: Oft setzt man nicht nur “Commodity-Hardware” ein sondern eben auch die Betriebssysteme, die man sowieso schon im Unternehmen hat. Unter Linux bietet jede halbwegs aktuelle Distribution hier Virtualisierung auf [KVM] (http://www.linux-kvm.org/page/Main_Page), der Kernel Virtual Machine. Und obwohl KVM gegenüber anderen Lösungen durchaus den einen oder anderen Nachteil hat - für die meisten Fälle ist es “gut genug”. Die Kombination aus leistungsfähiger, vernünftig gepreister Hardware und einer gut etablierten Software-Infrastruktur hat denn auch dazu geführt, daß die Einstiegshürde für die Einführung von Virtualisierungsumgebungen in Firmen massiv gesunken ist. Als direkte Folge davon beobachte ich seit knapp zwei Jahren in meinem persönlichen “Dunstkreis” (IRC, G+, einschlägige Mailinglisten etc.) eine wahre Flut von Support-Anfragen zu Virtualisierungsthemen - soweit nicht verwunderlich. Was mich jedoch mit Sorge erfüllt ist die Tatsache, daß fast 50% der vorgeblich technischen Fragen, die so aufschlagen, ihrer prinzipiellen Natur eigentlich nicht technisch sind. Vielmehr sind sie der Ausdruck einer Sackgasse, in die man sich mit einer Virtualisierungslösung manövriert hat und die man nun mit technischen Mitteln zu lösen versucht.

Das eingangs erwähnte Zitat spricht von “Commodity-Hardware” und ich ergänzte das um “vernünftig gepreist”. Doch was genau steckt hinter diesen Aussagen eigentlich? Nun, zum einen natürlich, daß man im Jahr 2012 also Plattform für Virtualisierung in den meisten Fällen im Prinzip die gleiche Hardware-Architektur einsetzen kann, die man wahrscheinlich eh schon im Unternehmen hat. Man braucht keine Power- oder Sparc(haha!)-Prozessoren, keine NUMA-Architektur und ganz allgemein keine Hardware, die ein ganzes Rack in Beschlag nimmt. Dies vereinfacht natürlich ganz erheblich den Beschaffungsprozess: i386/x86_64-Serverhardware mit Unterstützung für Virtualisierung bekommt man beim gleichen Hänlder, bei dem man auch die letzten 20 Applikationsserver gekauft hat. Das einzige, was man tun muß, ist ein paar mehr Cores und deutlich mehr RAM reinzubauen. Der Sprung ist dabei nur auf dem Papier groß: Eine mir bekannte Firma kauft Standardserver für ihre Applikationsserver meist mit Hexacores und 6GiB RAM. Während der Vorüberlegungen zur Virtualisierung einer größeren Testumgebung hat besagte Firma als Virtualisierungshost die exakt selber Hardware-Plattform angedacht, nur mit zwei statt einem Prozessormodul (also 12 statt 6 Cores), einem anderen Prozessor-Typ und 96GiB RAM (Faktor 16). Ohne Frage: Da bekommt besagte Firma eine HW-Plattform, mit der sie jede Menge Erfahrung hat. Also alles gut? Sehen wir uns mal die Kosten an (alles laut Herstellerseite): Für einen normalen Applikationsserver legt besagte Company recht gemäßigte 2.844,10€ hin. Für die große Hardware zahlt man mindestens 13.548,15€. Während man hier also schon Faktor vier hat, ist das leider noch nicht alles an Kosten: Will man Virtualisierung nämlich mit mehr als einem Server betreiben, so kommen ganz schnell weitere Posten hinzu: Pro Server ein FC-Controller. Mindestens eine Storage mit FC-Anschluß. Wenn man mehr als zwei Server und eine einzelen Storage hat: Mindestens ein SAN-Switch. Keine Frage: Jede einzelne dieser Komponenten ist “vernünftig gepreist” - in ihrer Summe stellen sie jedoch durchaus eine erhebliche Investition dar. Und egal bei welchem Unternehmen man arbeitet: Investitionen müssen einen wirtschaftlichen Nutzen haben. Man würde nun annehmen, daß die meisten Firmen angesichts dieser Tatsache ihre Virtualisierungs-Projekte genauestens planen, um zu verhindern, daß sie noch in der Planungsphase an die Wand gefahren werden. Die traurige Realität ist aber oft eine andere. Und die Tatsache, daß Virtualisierung nicht mehr komplex ist, ist nur ein Faktor dabei.

Der schlimmste Fehler (der betroffene Admin wird gerade in ##linux im freenode-Netz verarztet) wird dabei interessanterweise gar nicht auf technischer, sondern auf Management-Ebene gemacht (ein weiteres Zeichen dafür, daß Virtualisierung kein technisches Problem ist): Dem Auftrag, Virtualisierungstechniken einzuführen, fehlt es oft an Abgrenzung und Commitment. Mit “Abgrenzung” ist die klare Definition des Ziels gemeint, quasi das Festlegen der Parameter, an denen sich die zu realisierende Infrastruktur zu orientieren hat. Interessanterweise erlebe ich immer wieder, daß hier selbst die Basics “verkackt” werden. Man sollte annehmen, daß der Mindestsatz an Fragen, die man im Projektauftrag beantwortet finden würde, unter anderem die zwei grundlegendsten umfasst:

  • Wie viele Systeme sollen virtualisiert werden?
  • Welche Art(en) von Systemen soll virtualisiert werden?

Von besonderem Interesse ist dabei die zweite Frage: Eine saubere Anforderungsdefinition ermöglicht es jeder halbwegs technisch kompetenten Person, auf Anhieb eine Reihe von Fragen zu beantworten:

  • Wieviel CPU, Speicher und I/O muß ich pro Gast bereitstellen?
  • Welche Performance-Garantien muß ich - wenn überhaupt - sicherstellen?
  • Muß ich Maschinen in einem oder in Dutzenden von VLANs bereitstellen können?
  • Wie muß ich die Netzwerkanbindung dimensionieren?
  • Was ist der Personenkreis, der Zugriff auf die Management-Interfaces der Virtualisierungslösung bekommen soll? (oder anders: Brauche ich ACLs und eine GUI?)
  • Welche Maßnahmen muß ich - wenn überhaupt - zur Erhöhung der Verfügbarkeit treffen?
  • Welche Abhängigkeiten haben die virtualisierten Server untereinander?
  • Welche Abhängigkeiten bestehen zwischen den virtualisierten Systemen und dem Rest meiner IT-Infrastruktur?

Die Bantwortung dieser Frage kann natürlich extreme Unterschiede in der Dimensionierung der Umgebung haben: Der Anwendungsfall “ein Admin will RPM-Pakete für verschiedene Distributionen/Architekturen bauen und benötigt dazu mehrere Systeme, auf denen er nach belieben Development-Tools nachinstallieren kann” lässt sich mit einem mehrere Jahre alten Server mit minimalem RAM abdecken: VM mit CentOS 5/i386 starten, Paket bauen, VM stoppen. VM mit CentOS5/x86_64 hochfahren, RPM bauen, VM stoppen. Da capo al fine, “Management” der VMs mit virsh. Die Anforderung “Virtualisierung von 60 Applikations- und acht Telco-Servern, welche Zugriff auf ISDN-Hardware benötigen, mit mehr als 99.9% Verfügbarkeit, für vier Organisationseinheiten innerhalb des Unternehmens” dürfte eine gänzlich anders geartete Lösung erfordern. Und wenn besagte 60 Applikationsserver dann mal laufen und man feststellt, daß die zentrale, nicht-virtualisierte Datenbank unterdimensioniert ist und das Jahresbudget keine Erweiterung selbiger hergibt, hat man einen wunderbaren Shitstorm geschaffen.

Mit “Commitment” ist gemeint, daß eine klare Aussage dazu getroffen wird, wie lange die unter dem Punkt “Abgrenzung” gemachten Aussagen gültig sein sollen und wie verbindlich sie sind. Wenn ich weiß, daß die einzuführende Plattform innerhalb von zwei Jahren wachsen wird, dann kann ich von Anfang an eine Struktur aufbauen, die dies leisten können wird - muß aber natürlich oft eine höhere Anfangs-Investition tätigen. Anders gesagt beschreibt “Anbrenzung” den kurzfristig herzustellenden Zustand, “Commitment” die langfristge Situation.

Spätestens hier merkt man, worauf ich hinaus will: Vielen Unternehmen (und ich bin mal wieder in der glücklichen Situation, daß das bei meiner Firma nicht der Fall ist!) fehlt es an einer gesunden Strategie, was Virtualisierung angeht. Über die Gründe dafür kann ich nur spekulieren, aber meines Erachtens nach sind es vor allem zwei Dinge, die hier oft verkehrt laufen: Durch die allgegenwärtige Berichterstattung in der “einschlägigen Fachpresse” wird das Thema als relativ trivial wahrgenommen - was auf einer rein atomaren, technischen Ebene durchaus richtig ist. Die intrinsische Komplexität ergibt sich nämlich aus der Anforderung, mit der Lösung das bestmögliche Ergebnis für das Unternehmen zu realisieren. Die Definition, was dieses Ziel sein soll, ist jedoch kein technisches, sondern ein Management-Problem. Funktioniert hier die Kommunikation zwischen den an einem Projekt beteiligten Technikern und Managern nicht, zeigt sich das Management gegenüber den Ratschläge der Techniker uneinsichtig, fehlt es den am Projekt beteiligten Architekten/Engineers an technischer Erfahrung oder Überblick über vorhandene Lösungen oder zeigt sich die Firmenleitung unfähig, langfristige Strategie-Ziele zu formulieren - um Andreas zu zitieren, “von der Hand in den Mund” - so wird jedes Virtualisierungsprojekt noch vor der ersten HW-Bestellung scheitern.

Der zweite Grund, warum man oft keine guten Strategien findet, ist meiner Ansicht nach nicht so gewichtig wie das bereits genannte, ich will ihn aber nicht unerwähnt lassen: Virtualisierung wird oft als Allheilmittel gesehen. Egal ob es um die Senkung von TCO (“Total Cost of Ownership”) geht, das “Konsolidieren” von Altlasten oder das Erhöhen von Verfügbarkeit: Für viele Manager und Techniker scheint die Antwort stets “Wir virtualisieren!” zu lauten. Dabei könnte nichts falscher sein als das: Wenn uralte Legacy-Software anstatt auf eigene Hardware plötzlich in einer virtualisierten FreeDOS-Umgebung läuft, dann ist das keine “Konsolidierung” - im Gegenteil, das einzige was man damit getan hat, ist den Schmerz zu reduzieren, den eine IT im angesicht solcher Altlasten empfinden sollte - denn nur Schmerzen werden eine IT dazu bewegen, sich ernsthaft nach Alternativen umzusehen.

Was mich ebenfalls immer zum Lachen bringt sind die Behauptungen, mit Virtualisierung würden sich auch die Bestandteile der TCO, die von den Posten “Deployment” und “(Konfigurations-)Management” verursacht werden, drastisch reduzieren. Wie man im Jahr 2012 zu solch grenzwertigen Aussagen kommen kann, ist mir völlig unverständlich. Während man ganz klar sagen muß, daß eigentlich jede Virtualisierungslösung eine Methode bietet, um schnell eine bestimmte Art von Gast aus Images (“Systemabbildern”) oder Templates (“Vorlagen”) zu erstellen, so benötige ich nur für das schnelle Deployment von neuen Servern ganz sicher keine Virtualisierung. Und das ist jetzt nicht unbedingt eine neue technische Errungenschaft: Ich habe schon im Jahr 2000 Dutzende von IBM PowerPC-Workstations unter AIX über Netz deployed. Ohne Interaktion. In Zeiten, in denen jeder “Billo-Server” PXE-Boots kann und Frameworks wie cobbler/foreman/koan mir die automatisierte Installation von fast allem erlauben löst die Behauptung, das Deployment von Systemen sei mit Virtualisierungsumgebungen signifikant einfacher, bei mir nur ein belustigtes Schnauben aus.

Nicht anders verhält es sich mit dem Punkt “(Konfigurations-)Management”: Wer im Linux-Bereich nicht in der Lage ist, ein zentrales Konfigurationsmanagement auf real existierender Hardware zu nutzen, der wird durch Virtualisierung seine Management-Kosten nicht senken können. Und nur am Rande: Das Thema Backup ist hier kein anderes. Ja, mit Virtualisierungslösungen kann man ein System meist als Image sichern und auch schnell wieder herstellen. Aber auch dafür muß es ein existierendes Backup-Konzept geben, und wenn man nicht nur Nullen in seiner Technik hat, dann kann jedes Backup-Konzept sicherstellen, daß man ausgefallene Maschinen schnell wieder zum Leben erwecken kann. Ich habe neulich für meinen Chef einen “proof of concept” zu einem speziellen Virtualisierungs-Thema gebaut - und als ich ihm das dann vorgestellt habe, war das erste, was ich erwähnt habe, daß die Implementierung exakt die selben Tools verwendet, die wir auch zum Deployment und Management von echter Hardware benutzen (was übrigens auch für das zentrale Verteilen von Software oder Updates gilt). Eine gute Infrastruktur wird Virtualisierung umarmen, aber Virtualisierung ist nicht in der Lage, aus dem Nichts heraus eine gute Infrastruktur aufzubauen.

Wo also stehen wir? Ähnlich wie im Zeitalter von Mainframes haben wir heutzutage die interessante Situation, daß der Einsatz einer neuen Technologie kein technisches Problem mehr ist. Hand in Hand damit geht einher, daß das Management in einem sehr viel höheren Maß als gewöhnlich direkt über Erfolg oder Misserfolg von Virtualisierungsprojekten entscheidet. Hier erleben wir einen Paradigmenwechsel, der die Belastung von Führungskräften nicht unerheblich erhöht: Die Anforderungen an sie wachsen enorm, wenn die einzuführende Lösung wirtschaftlich rentabel sein soll. Erschwerend kommt hinzu, daß in der “einschlägigen Fachpresse”, aber auch in den Werbematerialien der Hersteller, kaum hilfreiche Hinweise zu finden sind, wie sie diese Herausforderung meistern können. Hier besteht für die Industrie als ganzes Nachholbedarf - und bis sich die Situation ändert ist das beste, das Thema Virtualisierung wie einen Mainframe zu behandeln:

Mit Respekt vor dessen Komplexität.

Ich höre mir jetzt “Pictures at an Exhibition” von Mussorgski an. Euch einen schönen Sonntag!