2 Virtuelle Maschinen im Unternehmen

Was nützt die beste Technik, wenn man keine Verwendung dafür hat? In diesem Kapitel werden Ihnen die möglichen Vorteile einer Servervirtualisierung für Ihr Unternehmen näher gebracht.

Im folgenden Kapitel will ich Ihnen die Techniken der Servervirtualisierung näher bringen. Dazu gehören auch die Vorteile, die eine Virtualisierung hinsichtlich der Kosten und der administrativen Möglichkeiten mit sich bringt. Eine repräsentative Studie von Gartner zum Thema Servervirtualisierung kam zu folgendem Ergebnis:

»Bei Unternehmen, die keine Virtualisierungstechnologien nutzen, steigen die Ausgaben für Hardware, Software, Arbeitskräfte und räumlichen Platz für Intel-Server jährlich um 25 Prozent «

Ein Ergebnis, das Sie schon nach der Lektüre dieses Kapitels nicht wundern wird.

2.1 Welchen Nutzen bringen virtuelle Maschinen?

Ich denke, nach dem ersten Kapitel dieses Buches werden Ihnen schon einige Vorteile aufgefallen sein oder Sie haben sich sogar schon Gedanken über die sich bietenden Möglichkeiten gemacht. Gerade innerhalb eines Unternehmens fällt es schwer, vorhandene Strukturen aufzubrechen und zu neuen Ufern zu gelangen. Dies liegt nicht nur daran, dass die Technologie zumindest im Intel-Bereich noch sehr jung ist, sondern auch an den Personalstrukturen innerhalb der IT-Abteilung. Gerade hier sind Meinungsveschiedenheiten zwischen jüngeren und älteren Mitarbeitern normal. Es muss Einiges an Überzeugungsarbeit geleistet werden, um Vorurteile und Bedenken aus dem Weg zu räumen.

Aber ich kann Ihnen versichern, dass sich eine Umstellung bei entsprechender Projektarbeit vor der Einführung in sehr vielen Fällen lohnen wird. Ich habe mir früher selbst zweifelnd die ersten VMware-Produkte angesehen und mich gefragt, ob so etwas überhaupt außerhalb eines Einzelplatzes funktionieren kann.

Mittlerweile bin ich natürlich davon überzeugt, und ich denke eher daran, welche physikalischen Server man nicht in die virtuelle Welt übernehmen kann. Allerdings wäre es vermessen zu glauben, alle physikalischen Maschinen wären problemlos umzustellen. Hier kommen zwei große Themenbereiche auf den Tisch: Sicherheit und Leistungsfähigkeit. Da es wenig ratsam ist, bei der Sicherheit Kompromisse einzugehen, sollten einige Serveranwendungen nicht virtualisiert werden. Dazu gehören beispielsweise Backup-Systeme. Des Weiteren würde ich persönlich auch keine Hauptfirewallkomponenten unter einem Virtualisierungsprodukt betreiben, da bei solchen Systemen die Sicherheit nicht hoch genug sein kann und jedes Zusatzprodukt ein Risiko bedeutet. Hinsichtlich der Leistungsfähigkeit fällt auf, dass ausnahmslos alle Virtualisierer zurzeit auf maximal 3,6 GB Hauptspeicher zurückgreifen können, was für manche Serversysteme einfach noch nicht ausreichend ist. Eine Dualprozessorunterstützung (Virtual SMP, erfordert eine entsprechende Lizenz) in der virtuellen Maschine bietet nur VMware ESX, wobei auch das für manches System nicht in Frage kommt, da noch mehr Prozessorleistung benötigt wird. Daher ist für ein gutes Gelingen immer eine akribische, realistische Planung Voraussetzung, die idealerweise in Projektform erfolgt. Sobald diese oben genannten Beschränkungen aufgehoben sind, wird es deutlich schwieriger werden, Argumente gegen eine Virtualisierung zu finden.

Manche Vorteile einer virtuellen Maschine gegenüber einer physikalischen Maschine erschließen sich leicht. Nehmen Sie alleine die immer identische Hardware innerhalb einer Virtualisiererversion, die auch immer gleiche Treiber bedeutet. Daher kann man virtuelle Maschinen sehr gut mit eingebetteten Systemen vergleichen, in denen eine unveränderte Hardwareumgebung dafür sorgt, dass die Treiberunterstützung enorm gut und stabil ist. Es gibt nicht wenige Anwendungen, die in einer virtuellen Umgebung viel stabiler laufen als zuvor in der physikalischen. Allerdings bleibt hier zu erwähnen, dass bei einem Versionswechsel der Virtualisierungsprodukte Hardwareänderungen durch den Hersteller vorgenommen werden, die in der virtuellen Maschine nachgezogen werden müssen (falls man von den neuen Funktionen bzw. höheren Leistungsdaten profitieren will). Der Abstand zwischen den Hardwareversionen der Virtualisierer darf dabei nicht zu groß werden, da unter Umständen die Kompatibilität zwischen den Wirt-Systemen leidet, mit der Folge, dass eine VM nicht mehr auf einen anderen Wirt übertragen werden kann.

Obigen Gedanken kann man einfach weiterspinnen. Bei gleicher Hardware entfällt für Administratoren das lästige Suchen nach neueren Treibern oder Firmwareupdates (bzw. nur in dem oben genannten Fall). Bis auf die Hardware der Wirt-Systeme ist selbst die Hardware absolut pflegeleicht und erleichtert so dem Administrator die Arbeit. Dass fünf Server weniger Arbeitsaufwand verursachen als fünfzig, ist leicht einzusehen. Zudem sinken die Wartungskosten mit der Anzahl der Server. Sie müssen nur Wartungsverträge für die physikalischen Maschinen abschließen und deren Funktion überwachen, zumindest was die reine Hardwarewartung angeht. (Der Aufwand für Software- bzw. Betriebssystemwartung bleibt selbstverständlich der gleiche.)

Ähnlich verhält es sich mit der Hardware. Stellen Sie sich vor, der Hauptspeicher einer Ihrer Server wäre komplett belegt und müsste deshalb dringend erweitert werden (derzeit sind virtuell maximal 3,6 GB möglich). Nun fängt das immer gleiche Prozedere an: Zunächst wird ermittelt, welche RAM-Bausteine überhaupt auf die Hardware passen! Sind überhaupt noch genügend Speicherbänke frei? Wenn ja, gibt es die erforderliche Speichertechnik überhaupt noch, schließlich kommt ein Server auch mal in die Jahre. Wie viel Hauptspeicher benötigen Sie überhaupt? Je nach Konstellation kann es Ihnen sogar passieren, dass Sie den gesamten Speicher tauschen müssen, weil alle Speicherbänke belegt sind und der vorhandene Speicher nicht mit dem neuen kompatibel ist. Unter Umständen ist der Hauptspeicher danach dermaßen überdimensioniert, dass Sie ihn niemals benötigen werden. Dann müssen Sie diesen Speicher bestellen und je nach Server von einer externen Firma einbauen lassen. Der Server muss längere Zeit ausgeschaltet werden, um ihn aus dem Rack auszubauen. Dies alles dauert seine Zeit und verursacht Kosten!

Vielleicht sagen Sie jetzt, dass dies übertrieben sei. Es ist aber leider in der Praxis öfter der Fall, als einem lieb ist. Doch wie läuft es bei einer virtuellen Maschine? Man fährt sie herunter und konfiguriert soviel Hauptspeicher wie diese Maschine benötigt (von der 3,6 GB-Grenze einmal abgesehen). Und Sie können genau bestimmen, wie viele Megabyte mehr es sein sollen, ohne ein Byte zu verschwenden. Ihnen kann es egal sein, wie und welche Speicherbänke belegt sind. Nun starten Sie diese VM wieder und fertig! Sie läuft genauso stabil wie vorher, verfügt jedoch über mehr Speicher.

Die Zeitspanne des Ausfalls liegt im Sekundenbereich! Versuchen Sie das mal mit einer physikalischen Maschine. Ähnlich verhält es sich mit anderen Komponenten wie Festplatten oder CD-Laufwerken. Sie verlagern die komplette Administration in wenige physikalische Wirt-Systeme, die dann allerdings sehr gut ausgestattet sind.

Womit wir beim Thema Ausfallzeiten wären. Sie haben durch virtuelle Server deutlich geringere Ausfallzeiten durch »Hardwarewartung«, falls man in diesem Zusammenhang überhaupt von Hardwarewartung sprechen kann. Durch die so genannte »Encapsulation« (Zusammenführung aller Komponenten einer virtuellen Maschine in wenige Dateien auf dem Wirt-System), ist es im Wartungsfalle problemlos möglich, virtuelle Maschinen auf einem anderen Wirt-System zu starten. Während VMware GSX und Microsoft Virtual Server dies nur bei ausgeschalteten virtuellen Maschinen zulassen, können Sie dies mit der VMware Virtual-Infrastruktur (VMware ESX, VirtualCenter und SAN) sogar mit laufenden VMs tun.

Seien Sie ehrlich, die Kosten für die »dicken« Server sind wirklich nicht mehr besonders hoch. Ganz im Gegenteil: Mittlerweile hat fast jeder Mitarbeiter einen derart leistungsfähigen PC, dass man darauf problemlos einige Server laufen lassen könnte. Wenn man sich zudem eine Preisliste von vor fünf Jahren anschaut und das damalige Preis-/Leistungsverhältnis mit dem heutigen vergleicht, ist der Unterschied enorm.

Hier sind wir auch schon beim Kern der Sache. Die Hardware ist mittlerweile so leistungsfähig geworden, dass selbst nach Studien von anerkannten Institutionen und Unternehmen (IBM, http://www-5.ibm.com/de/umwelt/effizienz/produkte.html) kaum ein Server zu mehr als 10 – 15 % ausgelastet ist. Schauen Sie sich einfach mal ein paar Ihrer Server an. Laufen sie auf Vollast? Das wird nur in wenigen Ausnahmen der Fall sein. Aber probieren Sie mal den umgekehrten Weg und versuchen Sie, eine Hardware zu kaufen, die von Ihren Servern voll ausgelastet wird. Vielleicht finden Sie ein so betagtes Gerät bei Ebay.

Sie bezahlen diese Mehrleistung aber trotzdem, obwohl Sie sie nicht nutzen. Mit einem Servervirtualisierungskonzept können Sie diese leistungsschwachen Systeme sauber voneinander getrennt auf einem oder wenigen Wirt-Systemen laufen lassen und damit die Hardwareressourcen in vollem oder zumindest hohem Maße ausnutzen.

Denken Sie auch an die Infrastruktur Ihres Serverraumes, der mit vielen Racks und darin verbauten Serversystemen ausgestattet ist. Diese System verursachen einen immensen Lärm und benötigen sehr viel Energie. Diese Stromkosten können Sie sehr leicht reduzieren.

Bei der unterbrechungsfreien Stromversorgung (USV), ohne die kein professionelles Rechenzentrum betrieben werden kann, ist es nicht anders. Je höher die Leistungsdaten der USV sein müssen, desto teurer ist sie. Da durch eine geringere Anzahl an physikalischen Systemen auch der Strombedarf sinkt, muss eine USV deutlich weniger Leistung vorhalten, was gerade in diesem Bereich Gold wert ist.

Da die Energiebedarf eines Servers nur zu einem geringen Teil wirklich produktiv genutzt wird, der größte Teil aber als Abwärme aus dem Servergehäuse geblasen wird, kommen wir zum wichtigen Aspekt, der wohl jedem Administrator im wahrsten Sinne des Wortes den Schweiß auf die Stirn treibt. Die Hitzeentwicklung innerhalb des Serverraumes! Weniger Server bedeuten weniger Wärme. Wohlgemerkt, weniger Server bei oftmals gleicher Performance wie zuvor. Aber auch Klimaanlagen gehören nicht gerade zu den in der Anschaffung günstigsten Geräten.

Wie bei den Servern haben Sie normalerweise auch für USV und Klimaanlagen Wartungsverträge mit den Herstellern. Durch die geringere Anzahl an Servern benötigen Sie auch weniger Racks im Serverraum, was Platz für andere Dinge lässt. Aber dabei wird nicht nur die Anzahl der Server verringert, sondern auch die der notwendigen Switches und sonstigen Netzwerkkomponenten, kann doch vieles innerhalb der Virtualisierung ablaufen.

Gerade für Administratoren eröffnen sich viele neue Möglichkeiten, ohne dass dazu zusätzliche Systeme angeschafft werden müssten. Bei jeder Virtualisierungssoftware ist eine Fernsteuerung direkt über die Konsole von der virtuellen Maschine möglich. Daher ist ein KVM Switch nur noch für das Wirt-System notwendig. Zudem ist ein komplettes Management integriert, mit dem Hardware-Änderungen sehr einfach von jedem Ort aus über Browser oder andere Anwendungen durchgeführt werden können. So können komplette Testumgebungen in kürzester Zeit aufgebaut werden, da man von der virtuellen Festplatte bis zum virtuellen Netzwerk alles in der Hand hat.

Stellen Sie sich vor, Sie müssten ein neues Service Pack auf einem Ihrer produktivsten Server installieren. Was tun Sie sinnvollerweise? Sie sichern erst einmal das System. Im Endeffekt wiederholt sich das gleiche Prozedere, wie wir es vom Hardwaretausch her kennen:

Herunterfahren des Systems

Starten mit einer Bootdiskette oder Boot-CD

Starten des Imaging Tools und Ablegen des Images auf einem Netzlaufwerk

Neustart des Systems

Einspielen des Patches

Bis hierher sind locker 30 – 40 Minuten vergangen.

Doch nun ist der Patch fehlerhaft und zerschießt Ihnen das komplette das System. Wie geht es weiter?

Herunterfahren des Systems

Starten mit einer Bootdiskette oder Boot-CD

Starten des Imaging Tools und Zurückspielen des letzen Images

Neustart des Systems

Wieder mindestens 30 – 40 Minuten verschwendet.

Ablauf z. B. unter VMware ESX:

Herunterfahren des Systems

Kopieren der Festplattendatei

Neustarten des Systems

Einspielen des Patches

Wenn alles gut läuft, können Sie in 15 bis 20 Minuten fertig sein. Diese Zahlen treffen selbstverständlich nur für kleinere Serversysteme und nur für die Systempartition zu. Falls ein Server mit mehreren 100 GB zurückgespielt werden muss, verzögert sich der Ablauf entsprechend. Der Zeitvorteil entspringt hier weniger dem Kopiervorgang, sondern ergibt sich aus der Tatsache, dass niemand vor Ort eine CD einlegen muss und der Bootvorgang selbst deutlich schneller vonstatten geht. Falls der Patch fehlschlägt, kopieren Sie einfach die gesicherte Festplattendatei zurück.

Aber es geht natürlich auch schneller! Denken Sie einfach, dass System liefe immer noch im Originalzustand:

Einschalten des REDO Logs über die Kommandozeile für die Systemfestplatte

Einspielen des Patches

Wenn der Patch fehlschlägt, verwerfen Sie einfach das REDO Log, ansonsten wird es einfach in die Festplattendatei integriert. Falls dieses System überhaupt ausfällt, dann nur wenige Minuten.

Interessant ist auch die Möglichkeit, verschiedene Betriebssysteme oder unterschiedliche Betriebsysteme und/oder Softwarestände gleichzeitig vorzuhalten. Mit virtuellen Maschinen ist dies kein Problem. Es wird immer alles sauber voneinander getrennt. Der Traum eines jeden Administratoren oder Entwicklers wird wahr. Ich nutze diese Funktionalität mittlerweile vor jeder größeren Installation, und es klappt hervorragend.

Genauso vorteilhaft verhält es sich mit der Netzwerkfunktionalität. Ich kann einem System während der Laufzeit den Netzwerkzugriff verwehren oder ihn abändern. Selbst das Ziehen eines Netzwerksteckers bereitet in der physikalischen Realität oft Probleme. Ich muss erst einmal wissen, wo der Rechner steht und welche Netzwerkkarte ich genau ziehen muss. Habe ich das erst einmal herausgefunden, dann bleibt mir der Weg vor Ort nicht erspart, denn aus der Ferne kann ich nicht agieren. Ganz anders bei der Virtualisierung: Durch einfaches Kopieren oder Klonen von Festplattendateien können problemlos eigene »Vorlagenserver« erstellt werden, die immer wieder kopiert schnell zu neuen, identischen Servern werden.

Mit VMware VirtualCenter kann man diese Templates an zentraler Stelle verwalten und mit Hilfe von XML-Konfigurationsdateien mehrere neue Server in kurzer Zeit realisieren. Durch die geringe Vorlaufzeit beschleunigt sich der Prozess der Neuanschaffung eines Servers (Neuerstellung eigentlich) deutlich. Falls ein virtueller Server nur für kurze Zeit benötigt wird, z. B. zum Testen einer neuen Software, ist er in kürzester Zeit erstellt und auch wieder gelöscht.

Stellen Sie sich vor, Sie müssten extra neue Hardware anschaffen, um verschiedene Sachen zu testen. Darüber hinaus kann ich mir durch die Möglichkeit von Templates den Einsatz von Disaster Recovery-Programmen sparen, die in den meisten Fällen nichts weiter machen, als ein Grundbetriebssystem wiederherzustellen und sich danach auf die normale Sicherung des Betriebssystems zu verlassen. Bei einer virtuellen Maschine reicht es, einfach einen neuen Server anhand eines Templates zu erstellen, den Backup-Klienten zu installieren und über diesen die aktuellste Sicherung aufzuspielen.

Kommt Ihnen vielleicht folgendes Beispiel bekannt vor: Sie haben noch Eigenentwicklungen, die unter MS-DOS oder Microsoft Windows NT laufen. Der Entwickler ist längst im Ruhestand oder ausgeschieden, und eine Aktualisierung der Software würde erhebliche Kosten verursachen. Ihr Problem: Diese Anwendung läuft vielleicht überhaupt nicht mehr auf aktueller Hardware, da es an Treiberunterstützung mangelt und die alte Hardware kurz vor der Verschrottung steht. Mit Virtualisierung ist das kein Problem, da die virtuelle Hardware auch MS-DOS unterstützt und einer Portierung in eine virtuelle Maschine, die unter einem aktuellen und leistungsfähigen Wirt-System läuft, nichts mehr im Weg steht. Diese virtuelle Maschine kann dann eine unter vielen sein, da heutige Serversysteme von enormer Leistungsfähigkeit sind.

Wie Sie im letzten Absatz feststellen konnten, war von verschiedenen Betriebssystemen die Rede. Durch die Virtualisierung können Sie je nach Produkt eine Vielzahl von verschiedenen Betriebssystemen innerhalb einer virtuellen Maschine betreiben. Bei den großen kommerziellen Produkten ist es unabhängig vom Wirt-Betriebssystem problemlos möglich, verschiedene Gast-Betriebssysteme gleichzeitig und unabhängig voneinander zu betreiben. Damit können Sie die Konsolidierung weiter vorantreiben, da Sie nicht Windows VMs von Linux oder MS-DOS VMs trennen müssen, sondern alle auf dem gleichen Wirt-System betreiben können. Welche Gast-Betriebssysteme von welchem Produkt genau unterstützt werden, das erfahren Sie in Kapitel 3, Virtualisierungssoftware – eine Marktübersicht.

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.