22Servervirtualisierung mit Hyper-V

Weder an Bildung und Wuchs, noch an Geist und künstlicher Arbeit. Dennoch geb’ ich sie willig zurück, ist solches ja besser. Lieber mög’ ich das Volk errettet schaun, denn verderbend. Gleich nur ein Ehrengeschenk bereitet mir, daß ich allein nicht Ungeehrt der Danaer sei; nie wäre das schicklich!

Bei der Servervirtualisierung gibt es im Wesentlichen zwei »Hebel«, die diese Technologie attraktiv machen:

Ein Hauptpunkt ist, dass das installierte und konfigurierte Betriebssystem unabhängig von der Serverhardware ist. Die Vorteile liegen auf der Hand:

• Einfacher Umzug von Servern auf andere Hardware, zum Beispiel beim Austausch der Hardware, bei der Hardwarewartung und so weiter.
• Schneller Wiederanlauf im Hardwarefehlerfall: Anstatt umständlich ein Backup auf eine Ersatzhardware zu bringen, wird einfach die virtuelle Maschine kopiert und kann auf einem beliebigen anderen Server, der als Host dient, in Betrieb genommen werden.
• Durch die Hardwareunabhängigkeit entfällt natürlich auch die Notwendigkeit, »Eigenarten« zu berücksichtigen, wie beispielsweise die Installation spezieller Treiber.

Durch den oben genannten »schnellen Wiederanlauf« ergeben sich ganz neue Möglichkeiten für Ausfallkonzepte, die wesentlich preisgünstiger umsetzbar sind als mit konventionellen Failover-Clustern.

Abbildung 22.1 Bei der Servervirtualisierung laufen mehrere virtuelle Maschinen auf einem physikalischen Server (Host).

Abbildung 22.2 Fällt eine physikalische Maschine aus, können die virtuellen Maschinen problemlos auf einer anderen Hardware wieder in Betrieb genommen werden. Ist die Umgebung entsprechend vorbereitet und konfiguriert, geschieht das innerhalb weniger Minuten.

Weiterhin führt Servervirtualisierung zu einer besseren Nutzung der Ressourcen. Aus Gründen der Stabilität und Wartbarkeit ist man dazu übergegangen, pro Dienst oder Applikation einen dedizierten Server bereitzustellen. Das ist fachlich sicherlich auch richtig, führt aber dazu, dass ein kleinerer Mittelständler plötzlich ein bis zwei Dutzend Server im Rechenzentrum hat. Ein großer Teil dieser Server dümpelt den ganzen Tag ohne nennenswerte Last vor sich hin. Durch die Möglichkeit, mehrere Server als virtuelle Maschinen auf einer physikalischen Maschine zu betreiben, ergeben sich diese Vorteile:

• Bessere Ressourcenausnutzung
• Es muss weniger Hardware beschafft werden, was geringere Hardwarewartungskosten bedeutet.
• Geringerer Energieverbrauch; bei diesem Punkt sind sowohl die direkten Energiekosten (Betrieb der Server) als auch die indirekten (zum Beispiel Betrieb der Kühlung) zu betrachten.

Zusammenfassend kann man also sagen, dass Servervirtualisierung sowohl zu einer vereinfachten Administration (wobei ich die verbesserten Möglichkeiten beim Wiederanlauf dieser Kategorie zurechne) als auch zu einer Reduktion der direkten Kosten (Beschaffung, Wartung, Energie) führt.

Aufgrund der signifikanten Vorteile wird in den meisten Unternehmen und Organisationen über Servervirtualisierung nachgedacht und diskutiert – viele »tun es« auch tatsächlich. Nachdem durchaus lange Zeit die Produkte von VMware die »absolute Lufthoheit« bei der Servervirtualisierung hatten, kommt in der letzten Zeit Bewegung in den Markt, zumindest ein bisschen:

• Platzhirsch ist unzweifelhaft VMware.
  • Das Flaggschiff Virtual Infrastructure (aka ESX Server) ist das System der Wahl in den Unternehmen. Es bietet diverse spannende Features, wie beispielsweise das recht spektakuläre VMotion (Verschieben von virtuellen Maschinen zwischen Servern im laufenden Betrieb), besticht durch ausgereifte Management-Werkzeuge (Virtual Center, das aber extra zu lizenzieren ist) und hat sich als stabile und leistungsfähige Enterprise-Class-Lösung einen hervorragenden Namen gemacht. Virtual Infrastructure ist allerdings nicht ganz billig.
  • Mittlerweile ist mit ESXi ein kostenlos erhältliches Produkt auf dem Markt. Hierbei handelt es sich letztendlich um den »nackten« Hypervisor, dem unter anderem auch die bekannte Linux-basierte Service Console fehlt.
  • Diverse weitere Produkte komplettieren das Portfolio im Servervirtualisierungsbereich; zu nennen wären beispielsweise die VMware Workstation und der VMware Player.
• Microsoft ist ebenfalls seit längerer Zeit im Virtualisierungsmarkt aktiv und bietet folgende Produkte an:
  • Als Test- und Entwicklungslösung wurde lange Virtual PC positioniert. Virtual PC lief meiner Erfahrung nach stabil, war einfach zu bedienen und kostete nichts. Die letzte Version war mit Windows 7 lauffähig. Windows 8 enthält Hyper-V.
  • Im Serverbereich war bis zum Sommer 2008 der Virtual Server 2005 das verfügbare Produkt. Wie die Jahreszahl im Namen schon sagt, ist das Produkt in die Jahre gekommen. So fehlt beispielsweise die Unterstützung von x64-Betriebssystemen als Gast – was heute schon ziemlich übel ist. Auch bei den sonstigen Features, der Performance und den Management-Möglichkeiten konnte der Virtual Server nicht mal ansatzweise mit VMware Virtual Infrastructure mithalten.

    Seit Windows Server 2008 ist Hyper-V verfügbar – eine völlig neue Virtualisierungslösung, die den »alten« Virtual Server ersetzt. Hyper-V auf dem Stand von Windows Server 2008 (ohne R2) beherrschte einige VMware-Features (wie etwa das Verschieben von virtuellen Maschinen im laufenden Betrieb) nicht, das hat sich aber teilweise mit der in R2 enthaltenen Version geändert. Hierbei stellte sich jedoch auch die Frage, ob diese Features wirklich einen echten Business-Value darstellen oder eher »nice to have« sind. Mit Windows Server 2012 ist nun Hyper-V in der dritten Generation erhältlich. Diverse Enterprise-Features sind hinzugekommen, unter anderem die sehr interessante Replikation von virtuellen Maschinen.

• Citrix/Xen: Der dritte große kommerzielle Hersteller im Bereich der Servervirtualisierung ist Citrix, der dieses Standbein durch die Übernahme von Xen bekommen hat. Der XenServer ist in vier verschiedenen Ausprägungen (Editions) erhältlich, die von einer frei verfügbaren Starter-Edition bis hin zu einer Version mit diversen Enterprise-Features reicht.

Neben diesen Lösungen der drei großen Hersteller sind diverse »kleinere« Produkte am Markt, die teilweise mehr oder weniger lukrative Nischen bedienen oder aber experimentellen Status haben.

Da ich glaube, dass Microsoft mit Hyper-V eine sehr interessante und zukunftsweisende Lösung auf den Markt gebracht hat, möchte ich in diesem Kapitel ein wenig genauer darauf eingehen.

Warum ist es sinnvoll, sich mit Hyper-V zu beschäftigen und nicht einfach den etablierten Standard, also VMware Virtual Infrastructure, zu wählen? Ich will hier keinesfalls behaupten, dass Hyper-V nun in jedem Fall die bessere Wahl ist; Virtual Infrastructure hat nach wie vor in dem einen oder anderen Szenario einen Technologievorsprung. Außerdem ist anzumerken, dass es derzeit eine enorme Zahl von gut funktionierenden VI-Installationen gibt.

Ich sehe beim Einsatz von Hyper-V folgende Vorteile (die Reihenfolge stellt keine Wertung da):

• Die Hyper-V-Technologie ist vergleichsweise preiswert zu bekommen.
• Mit der Hyper-V-Technologie fühlen sich Windows Server-Administratoren deutlich »heimischer«: Die Administrationsoberfläche ist, wie von den Microsoft-Produkten her gewohnt, recht einfach zu bedienen; zudem bilden bekannte Microsoft-Technologien die Basis.
• Hyper-V ist Microsofts Hauptprodukt im Virtualisierungsumfeld. Man kann also davon ausgehen, dass Microsoft alles tun wird, um den zweifelsfrei in einigen Bereichen noch existierenden Technologievorsprung des »großen Mitbewerbers« einzuholen.
• Obwohl es ein Supportabkommen zwischen Microsoft und VMware gibt, denke ich, dass es im Supportfall einfacher ist, nur einen Hersteller im Boot zu haben. Dieses Argument wird immer wieder gern kontrovers diskutiert, ich persönlich habe jedenfalls den Eindruck, dass eine Ein-Hersteller-Strategie, soweit durchzuhalten, gar nicht so verkehrt ist.

22.1 Allgemeine Überlegungen zur Servervirtualisierung

Bevor wir uns mit dem Hyper-V-Produkt beschäftigen, werden wir noch ein paar Basisaspekte der Servervirtualisierung besprechen. Diese gelten selbstredend nicht nur in Hyper-V-Umgebungen, sondern haben generelle Gültigkeit.

22.1.1 Scale-out vs. Scale-up

Wenn Sie mit der Planung einer Servervirtualisierungsumgebung beginnen, müssen Sie zunächst entscheiden, ob Sie eher einen Scale-out- oder einen Scale-up-Ansatz bevorzugen. Die Unterscheidung ist recht simpel:

• Scale-out: Die Last, also die virtuellen Maschinen, wird auf mehrere »kleine« Server verteilt, beispielsweise auf Zwei-Sockel-Systeme, also Systeme mit bis zu zwei Prozessoren – hier kann man übrigens auch sehr gut Blade-Systeme vorsehen (Abbildung 22.3).

  

  Abbildung 22.3 Scale-out: Die Last wird auf viele kleinere Computer verteilt.

• Scale-up: Die Last wird auf wenige »große« Server verteilt, im Extremfall auf ein einziges System. Bei diesem Ansatz wird man beispielsweise auf Server mit bis zu acht Prozessoren zugreifen (Abbildung 22.4).

Abbildung 22.4 Scale-up: Wenige »große« Server teilen sich die Last.

Nun stellt sich die Frage, wo die Vor- und Nachteile der Ansätze liegen. Ich gehöre eher zur Scale-out-Fraktion, und zwar aus diesen Gründen:

• Der Ansatz bietet eine höhere Redundanz. Wenn beispielsweise sechs kleinere Server statt zwei große eingesetzt werden, fallen beim Ausfall eines Servers nicht 50 %, sondern nur 17 % der Gesamtleistung weg.
• Der Scale-out-Ansatz bietet eine einfachere Skalierbarkeit. Wenn Sie feststellen, dass Sie zusätzliche Leistung benötigen, ist es alles in allem »einfacher«, dem Gesamtsystem einen kleinen Server anstelle einer großen Maschine hinzuzufügen. Hier sind finanzielle Aspekte wie die sprungfixen Kosten zu nennen, aber auch die technische Vorgehensweise.
• Der Scale-out-Ansatz dürfte preisgünstiger sein. Die Kosten pro Prozessor und pro GByte sind bei Zwei-Sockel-Maschinen geringer als bei Vier- oder Acht-Sockel-Servern. Die Anzahl der von den virtuellen Maschinen benötigten Prozessoren und RAM-GBytes wird bei beiden Maschinen in etwa identisch sein.

Das Hauptargument für den Scale-up-Ansatz ist, dass weniger Maschinen weniger Administrationsaufwand bedeuten. Nun verhält es sich so, dass die am Markt erhältlichen Management-Werkzeuge den Scale-out-Ansatz optimal unterstützen. Zu nennen sind hier:

• VMware Virtual Center
• Microsoft System Center Virtual Maschine Manager

Wie »klein« die eingesetzten Server für einen Scale-out-Ansatz sind bzw. sein sollen, hängt von der konkreten Umgebung ab. Es hat wenig Sinn, einen solchen Ansatz so nachhaltig zu verfolgen, dass Sie hinterher 100 Server benötigen; in einem solchen Fall würden sich dann doch eher Vier- anstelle von Zwei-Sockel-Maschinen empfehlen. Die Vorteile des Scale-out-Ansatzes bleiben auch erhalten, wenn Sie in einer großen Umgebung mit Vier- oder Acht-Prozessor-Servern arbeiten. Das theoretische Modell »Scale-out« legt letztendlich nicht den Typ der Hardware fest, sondern beschreibt, dass Sie in die Breite (viele Server) gehen, anstatt mit wenigen Servern »in die Höhe« zu bauen.

22.1.2 Servervirtualisierung und SAN

Servervirtualisierung und Speichernetze (Storage Area Network, SAN) sind eine nahezu ideale Kombination. Es gibt hierbei zwei wesentliche Aspekte, nämlich Redundanz und Flexibilität. Warum das so ist, zeigt die Skizze aus Abbildung 22.5:

• Zunächst wird die virtuelle Maschine auf dem links abgebildeten Server ausgeführt. Sämtliche Daten der virtuellen Maschine, also insbesondere die Dateien der virtuellen Festplatten, aber auch die Konfiguration, liegen auf dem gemeinsamen Storage-System.
• Falls die Hardware des ursprünglichen Servers ausfällt oder die virtuelle Maschine aus einem anderen Grund verschoben werden soll (zum Beispiel aus Leistungsgründen), braucht sie lediglich auf einem anderen Server gestartet zu werden. Die virtuellen Festplatten und die Konfigurationsinformationen sind auf dem Storage-System gespeichert und stehen somit allen Servern zur Verfügung.

Diese Darstellung ist, was die technische Seite betrifft, zwar deutlich vereinfacht, denn es gibt hier bezüglich des konkurrierenden Zugriffs verschiedener Server auf dasselbe Dateisystem schon einige Themen zu beachten – grundsätzlich ist die Funktionsweise aber so wie beschrieben.

Abbildung 22.5 Eine nahezu ideale Kombination: Servervirtualisierung und SAN

So richtig elegant wird es dann in einer großen Umgebung, die über zwei Rechenzentren verteilt ist (Abbildung 22.6):

• Es ergibt Sinn, die (physikalischen) Server so über die Rechenzentren zu verteilen, dass bei Totalausfall eines RZ das jeweils andere zumindest alle »lebenswichtigen« virtuellen Maschinen ausführen kann.
• Sinnvollerweise müssen die Storage-Systeme gespiegelt werden. Nur dann sind Sie auf den nicht sehr wahrscheinlichen, aber immerhin möglichen Fall vorbereitet, dass ein Storage-System ausfällt. Auch wenn die Katastrophe eintritt, nämlich der Ausfall eines kompletten Rechenzentrums, gibt es so eine Lösung.

Abbildung 22.6 Eine größere, über zwei Standorte verteilte virtuelle Umgebung mit zwei gespiegelten SAN-Storage-Systemen

22.1.3 Planung und Performance

Es ist eigentlich vollkommen einleuchtend, dass für den Betrieb der virtuellen Maschinen genügend physikalische Ressourcen zur Verfügung stehen müssen – trotzdem wird hier in der Praxis häufig nicht optimal dimensioniert. Im Grunde genommen sind vier »Dimensionierungsbereiche« zu betrachten (Abbildung 22.7):

• Prozessorleistung
• Hauptspeicherausbau
• Netzwerkbandbreite
• Festplattenspeicher

Eine hundertprozentig genaue Größeneinteilung hinzubekommen, ist nicht ganz trivial; man kann allerdings recht ordentliche Richtwerte errechnen, zumindest dann, wenn es die zukünftigen virtuellen Maschinen bereits gibt. In diesem Fall ist der erste Schritt, Messdaten zu erheben, was Sie entweder »zu Fuß« mit dem Performancemonitor (bzw. Systemmonitor) erledigen können, oder Sie setzen spezielle Messwerkzeuge ein (zum Beispiel PlateSpin Recon, das mittlerweile zu NetIQ gehört).

Abbildung 22.7 Die physikalischen Ressourcen müssen »richtig« dimensioniert sein, um einen störungsfreien und performanten Betrieb zu ermöglichen.

Die benötigten Daten sind:

• Von den zukünftigen virtuellen Maschinen tatsächlich genutzte Prozessortakte.
• Der von den zukünftigen VMs benötigte Hauptspeicher – hier ist insbesondere der tatsächlich genutzte Speicher interessant.
• Die lesenden und schreibenden Disk-IOs.
• Die benötigte Netzwerkbandbreite.

Aus Erfahrung kann ich berichten, dass bei virtuellen Umgebungen, die »zu langsam« laufen, meistens ein Problem bei der Dimensionierung des Plattensystems vorliegt. Mehrere virtuelle Maschinen, die jeweils über Betriebssystem- und Datenpartition verfügen, verursachen eine nicht unerhebliche Belastung der Festplatten. Sofern nicht entsprechend viele Festplatten in den RAID-Sets vorhanden sind, ist das Ergebnis eine entsprechend langsame Verarbeitung der Zugriffe, was dann das ganze System ausbremst – wie immer gilt, dass ein RAID 5 mit drei riesigen SATA-Platten vermutlich die Größenanforderungen, aber bestimmt nicht die Performanceanforderungen erfüllt.

Auch wenn man Scale-out-Fan ist, benötigt man einigermaßen leistungsfähige Server. Eine wesentliche Komponente ist das Plattensystem, bei dessen Dimensionierung man mit besonderer Sorgfalt zu Werke gehen sollte.

22.1.4 Was soll virtualisiert werden?

Eine der häufigsten Fragen, die ich im Zusammenhang mit Servervirtualisierung beantworte, ist, welche Server nun virtualisiert werden sollen. Etwas konkreter fragen mich meine Kunden beispielsweise: »Uli, sollen wir den Exchange Server virtualisieren?« oder »Empfiehlst du uns, die Oracle-Datenbank zu virtualisieren?« oder »Sollen wir auch die Terminalserver in die virtuelle Umgebung migrieren?«

Wie immer sind Pauschalaussagen nicht besonders sinnvoll. Um sich den jeweils »richtigen« Antworten zu nähern, sollten wir uns zunächst vor Augen führen, warum wir überhaupt Servervirtualisierung einsetzen. Die häufigsten Gründe sind:

• einfachere Wiederherstellungsszenarien, Verbesserung der Verfügbarkeit
• bessere Ausnutzung von Ressourcen, höhere Energieeffizienz
• Vereinfachung der Administration

Etwas konkretere Antworten könnten also sein:

• »Kleinere« Server zu virtualisieren, ergibt eigentlich immer Sinn.
• Applikationen, die auf moderner Hardware am Leistungslimit laufen, sind nicht die optimalen Virtualisierungskandidaten. Wenn Sie für eine solche virtuelle Maschine einen kompletten Hyper-V-Server benötigten, ist das kein ideales Verhältnis. Aus diesem Grund werden beispielsweise Terminalserver häufig nicht virtualisiert: Sie sind meistens stark ausgelastet und, zumindest wenn sie in einer Farm mit mehreren gleichartigen Servern betrieben werden, als »Einzelstück« auch durchaus nicht unverzichtbar.

  Ich kenne allerdings auch Szenarien, in denen ein Terminalserver eine Spezialanwendung mit wenigen Anwendern bedient und folglich nicht eine von vielen Maschinen einer Farm ist. Bei solchen Servern empfiehlt sich die Virtualisierung, weil das Recovery-Verfahren dann vergleichsweise einfach ist.

Virtualisierung bietet zweifelsfrei viele Vorteile, man muss aber auch ein paar Probleme bzw. mögliche Probleme im Hinterkopf behalten:

• Einige Applikationen bzw. Applikationsserver profitieren sehr von den Mehrkernarchitekturen moderner Prozessoren. Beispiele sind SQL-Server und Exchange-Server. Die Servervirtualisierung deckt sozusagen diese Architekturen zu. Dies könnte sich als sehr leistungsmindernd auswirken.
• Es muss stets geprüft werden, ob die eingesetzten Applikationen vom Hersteller auch in einer virtualisierten Umgebung unterstützt werden. Da Servervirtualisierung mittlerweile eher die Regel als die Ausnahme ist, dürfte das eigentlich kein Problem sein; es gibt aber immer wieder Hersteller, für die der Einsatz von Servervirtualisierung ein Grund ist, den Support zu verweigern. Ich empfehle, dies im Vorfeld abzuklären. Auch wenn ein Hersteller keinen Support bietet, können Sie die Vorteile der Virtualisierung so hoch bewerten, dass diese mehr Gewicht als der »Makel« der nicht unterstützten Umgebung bekommen. Das ist allerdings eine Entscheidung, die jeder selbst treffen muss.

---

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.