vSphere 5: Plattform für das Cloud Computing

30. Januar 2012

Hochgradige Skalierbarkeit und Automatisierung des IT-Betriebs – diesen Forderungen müssen sich moderne Virtualisierungsplattformen stellen, wenn sie als ein Fundament für die verschiedenen Ausprägungen des Cloud Computing dienen sollen. Hier bietet der Branchenprimus Vmware mit vSphere 5 die neueste Version seiner Umgebung, die immer noch als die Nummer Eins im Virtualisierungsbereich gilt.

Bild 2. Die Funktion „Policy Driven Storage“ verteilt die Ein-Ausgabeanfragen auf den passenden Speicher. Quelle: Vmware

Auch wenn kein Zweifel besteht, dass Microsoft einige Fortschritte im Bereich der Virtualisierung im Unternehmensbereich gemacht hat, so besteht doch kein Zweifel, dass die Nummer Eins in Sachen Server-Virtualisierung Vmware ist. Sie brauchten bereits 1999 mit der Vmware Workstation 1.0 eine Virtualisierungslösung auf den Markt und hatten auch den ersten „Bare Metal Hypervisor“: den ESX Server, der 2001 sein Debüt gab. Seitdem hat sich Vmware im Virtualisierungsmarkt von allen Konkurrenten absetzen können. Derzeit sollen in etwa 75 Prozent aller Vorhaben im Bereich der Enterprise Virtualization abgedeckt sein.

Anzeige
CS espresso series

Basis für die Private Cloud

Bereits im Juni 2011 wurde vSphere 5 vorgestellt –und damit die Messlatte für die Server-Virtualisierung in Unternehmen nochmals höher gelegt. Des Weiteren gilt vSphere 5 als ein solides Fundament, um mit Hilfe der Virtualisierung eine private Cloud aufzubauen. Denn Vmware gilt auch als eines der führenden Unternehmen, wenn es um den Aufbau von Cloud-Architekturen geht. Denn die Virtualisierungsplattform gehört zu der grundlegenden Technik, wenn es darum geht, eine Cloud aufzubauen. Dabei konkurriert das Unternehmen nicht mit den Anbietern von Infrastrukturdiensten wie zum Beispiel Amazon oder Salesforce. Bei Vmware steht dagegen die Konzentration weniger auf der Public Cloud als vielmehr auf der Ergänzung oder Abrundung der internen IT mit Cloud-Techniken – also dem Aufbau von Hybrid und Private Clouds.

Das Prinzip der Public Cloud besteht darin, dass ein Anbieter einen Satz von Diensten zur Verfügung stellt, die ein Anwender – oder Unternehmen – sozusagen abonnieren kann. Zu diesen Diensten gehören IaaS (Infrastructure as a Service), PaaS (Platform as a Service) sowie SaaS (Software as a Service). Beim IaaS-Modell betreibt man virtuelle Maschinen (VMs) auf der Infrastruktur eines Anbieters, wobei die Anbindung an diese VMs über das Internet läuft.

Ein gängiges Beispiel für IaaS ist die EC2 (Elastic Compute Cloud) von Amazon. Dagegen bezieht man von einem Cloud Provider beim PaaS-Modell die kompletten Betriebssystemdienste auch gleich mit. Vertreter dieser Gattung sind Salesforce.com und Microsofts Azure. Noch höher im Software Stack geht es dann bei SaaS: Hier wird eine komplette Applikation geleast – das kann eine ERP-Software wie SAPs Business By Design oder auch Microsofts Office 365 sein.

Der Vorteil der Cloud-Konzepte lautet: Abgerechnet wird nach wahrem Verbrauch. Somit entfallen großartige Investitionskosten, dafür bekommt man eine höhere Flexibilität für die Dynamik im IT-Verbrauch seines Unternehmens.

Bei der Private Cloud steht die Idee dahinter, dass man diese Cloud zu seiner bestehenden IT-Infrastruktur hinzunimmt und damit zu einem flexibleren Konstrukt kommt. Damit sollen die Anforderungen an die Dynamik aber auch eine weitgehende Automatisierung des IT-Betriebs erreicht werden. Dazu ist die Virtualisierung ein absolutes Muss und zugehörige Techniken wie vMotion, Storage vMotion und der DRS (Distributed Resource Scheduler) bieten hier gute Ansatzpunkte. Damit lassen sich automatisch die Arbeitslasten zwischen den Pools der Infrastruktur verschieben.

Der Vorteil der Private Cloud ergibt sich aus der Flexibilität: Nicht mehr eine Ressource kümmert sich  um eine spezielle Arbeitslast. Es wird dagegen eine dynamischere Infrastruktur erreicht, bei der die Arbeitslasten automatisch verschoben werden und somit von den verfügbaren Ressourcen bestmöglich bedient werden. Zudem erhöht sich auch die Effizienz: Bei geringer Auslastung kann sogar ein automatisches Abschalten von Systemen stattfinden, wenn die kleineren Lasten von vielen Systemen auf einige wenige Systeme verschoben werden, die dann gut ausgelastet sind. Hier kann der DRS in beiden Szenarien eine deutliche Verbesserung bringen. Des Weiteren lässt sich mit dem Aufbau einer Private Cloud auch die Basis für eine Verrechnung der Services aufbauen – die Chargeback-Funktionalität, wie sie zum Beispiel von vCenter Chargeback geboten wird.

Für das Management einer Cloud ist bei Vmware in erster Linie der vCloud Director zuständig. Mit seiner Hilfe lassen sich IaaS-Module über mehrere Cluster im Rechenzentrum hinweg bereitstellen und verwalten. Dazu erlaubt das Tool auch das Erzeugen von „virtuellen Rechenzentren“ sowie das Bereitstellen von VMs und von virtuellen Applikationen (vApps).

ESXi wird zum Hypervisor-Standard

Der Kern von vSphere ist traditionell der ESX Server Hypervisor von Vmware. Mit dem ESXi hat Vmware einen kleineren Hypervisor eingeführt, den das Unternehmen sogar als frei verfügbares Produkt anbietet. Dabei verfügt der ESXi-Hypervisor prinzipiell über dieselben Virtualisierungsfähigkeiten wie der größere ESX Server Hypervisor. Doch es fehlt ihm die Service Console – dafür kommt ein zeichenbasiertes Benutzer-Interface und das Remote Management durch den vSphere Client ins Spiel. Beim ESXi gibt es auch keinen eingebauten Webserver. Sprich der Anwender muss sich den vSphere-Client „von Hand“ herunterladen.

Bei vSphere 5 wurde der ESXi zum bevorzugten Hypervisor. Der Grund liegt auf der Hand: Die Software ist zum einen nicht so umfangreich und zum anderen bietet das auch eine reduzierte Angriffsfläche. Einfacher ausgedrückt: Weniger Softwareumfang führt zu einem sichereren Code.

Des Weiteren bietet der ESX1 für vSphere 5 eine eingebaute Firewall. Damit kann man den Datenverkehr einschränken – etwa durch die Parameter IP-Adresse und/oder Subnetz. Bei vSphere 5 wird allerdings auch der ältere ESX Server Hypervisor weiterhin unterstützt. Die frei verfügbare Version des ESXi Hypervisors trägt nun die Bezeichnung „Vmware Hypervisor“. Mehr Informationen zum Thema „Migration von ESX auf ESXi“ bietet die Website von Vmware.

Alles eine Frage der Editionen

Die Vielfalt der Editionen hat Vmware bei vSphere 5 vereinfacht: die „Advanced Edition“ blieb dabei auf der Strecke. Nun stehen nur mehr die folgenden Varianten bereit:

  • Standard,
  • Enterprise und
  • Enterprise Plus.

Der Migrationspfad von vSphere 4.1 Advanced führt zu vSphere 5 Enterprise. Alle Editionen von vSphere 5 nutzen den ESXi Hypervisor und sie alle unterstützen auch vMotion. Damit lassen sich virtuelle Maschinen (VMs) im laufenden Betrieb von einem ESX(i)- zu einem anderen ESX(i)-Server verschieben, ohne dass es zu Unterbrechung des Betriebs für die Anwender kommt. Die Vorgaben für die virtuellen Prozessor- und virtuellen Arbeitsspeicher-Ressourcen hängen von den Lizenzschemata bei vSphere ab.

Der Einstiegspunkt für die meisten mittleren Unternehmen ist vSphere 5 Standard. Diese Edition umfasst die Unterstützung für VMs, die bis zu acht virtuelle CPUs nutzen können. Aber auch die Funktionalitäten von hochverfügbaren Clustern und das Disaster Recovery wird damit schon abgedeckt. Dagegen zielt die Enterprise-Edition auf größere Unternehmen ab. Dazu kommen noch das Zuweisen von mehr Arbeitsspeicher und CPU-Ressourcen für laufende VMs, ebenso die Unterstützung für „Storage vMotion“ und der DRS (Distributed Resource Scheduler).

Mit Storage vMotion wird es möglich, die Dateien einer laufenden VM zwischen verschiedenen Speicherorten – ohne dass die VM ihren Betrieb unterbrechen muss – zu verschieben. Der DRS bietet eine dynamische Lastverteilung sowie Energiesparoptionen in Form eines Power Managements für mehrere ESX- und ESXi-Hosts.

Die Edition Enterprise Plus gilt als das obere Ende der vSphere-Produktlinie. Es enthält sämtliche Funktionen der Enterprise-Variante, verfügt aber auch noch über die Option des „Distributed Switch“, über die „Host Profiles“ und den „Policy Driven Storage“.

In den meisten Unternehmen wird eine zentralisierte Verwaltung gefragt sein. Daher brauchen sie auch den vCenter Server von Vmware. Diese Software ist nötig, um viele erweiterte Funktionen von vSphere aktivieren zu können. Es geht dabei in erster Linie um das Bereitstellen, das Überwachen und das Verwalten von VMs. Zwei Editionen des vCenter Servers sind dabei käuflich zu erwerben:

  • vCenter Server Foundation und
  • vCenter Server Standard.

Die „Foundation“ gibt es für knapp 1500,– Dollar. Sie unterstützt bis zu drei vSphere-Host-Systeme. Die Standard-Edition gibt es für knapp 5000,– Dollar – sie ist allerdings nicht in Bezug auf die Anzahl der zu verwaltenden Hosts beschränkt. Damit last sich zudem eine Automatisierung von  Verwaltungsaktionen (also eine Prozess Automatisierung) über den vCenter Orchestrator erzielen.

Hoch skalierbare VMs

Eine der wichtigsten Änderungen bei vSphere 5 ist die Unterstützung von extrem skalierbaren VMs. Damit kann eine VM ab vSphere 5 bis zu 1 TByte an virtuellen Arbeitsspeicher nutzen – das ist viermal soviel wie es das Vorgänger-Release erlaubt. In der Enterprise Plus Edition können die VMs zudem bis zu 32 virtuelle CPUs nutzen. Mit 32 Prozessoren und 1 TByte Arbeitsspeicher sollte man selbst die größten Arbeitslasten heutiger Applikationen stemmen können.

Bild 3. Die Automatisierung des Betriebs erlaubt der Distributed Resource Scheduler (DRS). Quelle: Vmware

Die vSphere Storage Appliance

Die Akzeptanz von vSphere bei kleineren und mittleren Unternehmen (SMBs, Small – Midsized Businesses) ist nicht so hoch ausgeprägt wie bei den größeren Firmen. Ein Grund dafür sind die Anforderungen im Speicherbereich: Wer die Hochverfügbarkeitsfunktionen von vSphere – wie etwa vMotion – verwenden will, der braucht ein Speichernetzwerk (SAN, Storage Area Network).

Doch bei kleineren Unternehmen kommt immer noch DAS (Direct Attached Storage) zum Einsatz, also Festplatten, die in den Servern eingebaut sind. Daher bringt vSphere 5 eine neue Option ins Spiel: die vSphere Storage Appliance (VSA).

Sie erlaubt  das Erzeugen von gemeinsamem Speicher auf der Basis von DAS (Direct Attached Storage), also Festplatten, die in zwei oder drei lokalen ESX-Servern eingebaut sind. Auch wenn man aufgrund der Namensgebung vermutet, dass es sich bei der VSA um ein Hardware-System handelt: VSA ist ein reines Software-Produkt.

Die VSA halbiert den nicht für den Systemstart (das Booten) vorgesehenen Speicherbereich auf jedem vSphere-Server und macht darauf bei jedem Serverknoten einen Datenträger als zum primären Volume und den anderen zum Replikat eines anderen Knotens. Damit wird eine Replikation der Speicherbereiche erzielt. Wenn nun ein Knoten ausfällt, übernehmen die beiden übrig gebliebenen (oder der eine übrig gebliebene Knoten) die Arbeit und der Datenspeicher wird auf das Replikat umgelenkt.

Allerdings ergeben sich bei der VSA doch einige Einschränkungen, wie zum Beispiel auf der Website von speicherguide zu sehen ist.

Eine Aussage bezieht sich auf die Effizienz der Speichernutzung: Der ESXi-5.0-Server repliziert seine Daten automatisch auf ein Laufwerk eines weiteren Knotens im ESX-Cluster. Da diese lokal auf RAID-10-LUNs gespeichert sind, wird bis zu viermal mehr Speicherplatz belegt als auf einer dedizierten Speicherlösung mit RAID 5 oder 6. Hinzu kommt, dass bei einem Austausch der Rechner-Hardware die Übernahme der Daten auf ein neues System ungleich komplizierter wird als bei der Nutzung von externen Speichern.

Richtlinien für den Speicher

Der Policy Driven Storage ist ebenfalls eine Erweiterung, die vSphere 5 mit sich bringt. Damit ist der Administrator in der Lage, Richtlinien anzulegen und somit zu bestimmen, wo VMs liegen sollen und sie mit Hilfe von vMotion dorthin zu verschieben. Diese Storage Policies verbinden die VMs, die Datenspeicher und die SAN-Geräte mit Speicherprofilen.

Damit soll sichergestellt werden, dass die VMs immer auf den passenden Speicherort verweisen, so dass die vorgegebenen Service Level Agreements (SLAs) eingehalten werden. Ein Speicherprofil identifiziert die Speichercharakteristika, die eine bestimmte VM haben soll.
Wenn eine VM erzeugt wird, kann sie optional auch ein Speicherprofil zugewiesen bekommen.

Die Speicherrichtlinie bestimmt dann die zugehörigen Speicherorte, die zu den Anforderungen des Profils passen. Dann muss der Administrator dem gewünschten und passenden Speicherort zustimmen. Wenn ein Storage vMotion-Prozess initiiert wird, werden nur die Speicherorte verwendet, die zu den Speicher-Charakteristika des Profils passen.

Storage DRS

Eine weitere Optimierung im Bereich des Speichersubsystems ist bei vSphere 5 Enterprise Plus mit dem „Storage DRS“ gegeben. Mit dieser Funktionalität soll ein Ausbalancieren der VM-Dateien über verschiedene Datenspeicher erfolgen. Dies erfolgt automatisch und verwendet dazu Parameter aus dem Speichersubsystem – wie etwa den Datendurchsatz zum Speicher oder die verfügbaren freien Kapazitäten.

Dazu zeichnet Storage DRS die Verzögerungsinfos beim Zugriff auf alle Datenspeicher in einem Cluster auf. Liegt die Verzögerungszeit für eine gewisse Zeitspanne unterhalb eines vorgegebenen Schwellenwerts, dann startet Storage DRS automatisch eine oder gar mehrere Verschiebeaktionen (über Storage vMotion) und erzielt so eine sinnvolle Verteilung der Ein-Ausgabelast innerhalb des Clusters.

Bild 3. Die Automatisierung des Betriebs erlaubt der Distributed Resource Scheduler (DRS). Quelle: Vmware

Die Verwaltungs-Konsole für vSphere 5

Bei vSphere war bisher immer ein vCenter Server nötig, um ein zentralisiertes Management der Virtualisierungsplattformen zu ermöglichen. Dabei war bei allen früheren vSphere-Versionen ein vCenter Server nur auf einem Windows-Serverbetriebssystem einsetzbar. Ab vSphere 5 kann der vCenter Server in Form der vCenter Server Appliance (vCSA) zum Einsatz kommen.

Bei dieser vCSA handelt es sich um  eine vordefinierte VM, die aus SUSE Linux Enterprise Server 11 und einer Linux-Version des vCenter Servers besteht. Die vCSA verwendet eine eingebettete Versions von IBMs Datenbank DB2 und kann bis zu 50 VMs unterstützen. Um eine noch höhere Skalierbarkeit zu bieten, last sich eine Konfiguration aufbauen,  bei der eine Verbindung zu einer eigenen DB2 (oder einer Oracle-Instanz) besteht. Die vCSA unterstützt den Microsoft SQL Server nicht.

Zunächst lässt sich die vCSA über einen Webbrowser konfiguriert. Nach abgeschlossener  Erstkonfiguration kann sie der Administrator mit Hilfe des vSphere Clients verwalten – ganz wie er es von der Windows-Version her gewohnt ist. Die vCSA arbeitet im Bereich der Authentifizierung mit dem Active Directory oder dem NIS (Network Information Service). Allerdings spielt die aktuelle Version nicht mit der IP Version 6 zusammen.

vSphere Essentials für kleine und mittlere Unternehmen

Der Einsatz in Unternehmen gehört zum primären Ziel von vSphere. Dabei liegt die Konzentration eher bei den großen Unternehmen. Für kleinere und mittlere Unternehmen erweist sich der Ansatz oftmals als zu teuer und zu komplex. Daher bringt Vmware mit dem vSphere Essentials Kit und dem vSphere Essentials Kit Plus zwei Versionen, die sich für kleinere und mittlere Konfigurationen eignen.

Beide Kits unterstützen bis zu sechs CPUs, 32 GByte virtuellen Arbeitsspeicher pro VM und bis zu acht virtuelle CPUs pro Gastbetriebssystem. Der prinzipielle Unterschied zwischen den beiden Kits ist das Thema Hochverfügbarkeit: Der vSphere Essential Plus deckt diese Funktionalität ab, ebenso die Datenwiederherstellungs- und die vMotion-Features.

Diese Eigenschaften sind beim günstigeren vSphere Essential Kit nicht enthalten. Vmware verlangt in den USA einen Listenpreis in Höhe von 495 Dollar und benötigt zudem noch einen Supportvertrag für ein Jahr. Für die größere Version – vSphere Essentials Plus – verlangt Vmware knapp 4500 Dollar. Um eine zentrale Verwaltung zu bieten, ist „vCenter Server for Essentials“ in den beiden Kits enthalten. Mehr Infos zu den Essential-Kits finden sich auf der Website von Vmware.

Änderungen im Lizenzmodell

Die vSphere-Plattform gilt als vergleichsweise teuer. Daher wollte man das Lizenzmodell umstellen und damit ein eher Cloud-artiges „Bezahlen nach Gebrauch“ erreichen. Bei vSphere 5 ist dabei immer noch das Lizenzmodell am Einsatz der Prozessoren ausgerichtet, doch es geht nicht mehr um die physischen Vorgaben – also CPU-Kerne und Arbeitsspeicher pro physischen Server.

Vmware berechnet nun nach dem gepoolten virtuellen Arbeitsspeicher (vRAM, sprich Arbeitsspeicher, der pro VM zum Einsatz kommt). Dazu benötigt jeder physische Prozessor eine vSphere 5 Prozessorlizenz. Die vRAM-Nutzung wird aus einem Jahresmittel (365 Tage) der maximalen vRAM-Nutzung aller laufenden VMs ermittelt. Es gibt aber kein automatisches Herunterfahren, wenn die Lizenzgrenzen überschritten werden. Es kommt dann lediglich zu einem Alarm, der von vCenter ausgegeben wird, wenn das verfügbare gepoolte vRAM überschritten wird.

Doch die Anwender waren mit diesem Modell nicht zufrieden – den dieses Modell führt zu höheren Kosten, vor allem wenn man mit Memory Overcommittment arbeitet. Diese Änderungen betreffen vor allem die Einsatzfelder, in denen die Serverkonsolidierung vorangetrieben wird – ein Hauptargument für den Einsatz von Virtualisierungs-Plattformen.

Daher ist Vmware auch recht schnell vom eigentlichen neuen Konzept abgewichen und hat zum Beispiel die Verdopplung der vRAM-Grenze vorgenommen. Damit sollten die meisten bestehenden Installationen ihre Ausgaben für die Lizenzierung nicht erhöhen müssen. Denn ein Abwandern zur Microsoft-Lösung, dem Hyper-V, will Vmware nicht riskieren.

Michael Otey/rhh

Lesen Sie auch