VSPEX garantiert den erfolgreichen Weg in die Private Cloud

Bei der Umstellung auf eine Private Cloud gilt die Regel: Besser auf zertifizierte Lösungen setzen, als die Infrastruktur selbst aufbauen. Wer dabei auf die VSPEX-Lösung setzt, spart sich viel Planungs-, Konfigurations- und Testaufwand. In diesem Beispiel wird gezeigt, wie sich mit dem Hyper-V (auf Basis Windows 2012 Server) und der VNX-Speicherfamilie eine Private Cloud aufsetzen lässt, die sich für den Betrieb von bis zu 50 virtuellen Maschinen eignet.

Wer das komplette White Paper (100 Seiten mit einer detaillierten Beschreibung und der zugehörigen Dimensionierung für alle Module (einmal für 50 und einmal für 100 VMs) zu dieser Aufgabenstellung haben möchte: Am Ende jeder Beitragsseite ist noch ein Registrierungsformular zu sehen, über das Sie das PDF beziehen können.

Wer heutzutage die Virtualisierung seiner IT-Infrastruktur im Unternehmen produktiv einsetzen möchte, der muss zuerst das Zusammenspiel von Server-Hardware, Netzwerkinfrastruktur und dem Storage-Subsystem mit der betreffenden Virtualisierungs-Plattform sicherstellen. Diese Aufgabe erweist sich in der Praxis als sehr aufwändig – vor allem, wenn auf dieser Virtualisierungs-Infrastruktur dann auch eine Private Cloud aufgebaut werden soll. Daher sollte man sich besser vorab validierte und modulare Architekturen ansehen, wie sie zum Beispiel EMC mit dem VSPEX-Konzept vorgestellt hat.

Vordefinierte Lösung erspart Aufwand

Beim VSPEX-Ansatz kombiniert der Speicherspezialist Techniken von mehreren Herstellern, damit für die Anwender auch Entscheidungsmöglichkeiten in Bezug auf die Server-Hardware, die Hypervisor-, die Datenverarbeitungs- und Netzwerkebene offen stehen.

Der Vorteil von VSPEX liegt zum einen im deutlich reduzierten Aufwand für die Planung und Konfiguration der kompletten Servervirtualisierung, zum anderen in der beschleunigten Umstellung der IT aufgrund einer optimierten Bereitstellung. Zudem ergeben sich eine größere Flexibilität bei der Auswahl, eine höhere Effizienz sowie geringere Risiken. Die VSPEX-Infrastrukturlösungen umfassen die Unified Storage-Plattform VNXe sowie flexible Optionen beim Backup-Portfolio.

Multiprotokoll im Speichernetz

Mit VNXe ist es für ein Unternehmen möglich, Multiprotokoll-SAN- und -NAS-Infrastrukturen in eine einzige Storage-Plattform zu integrieren, die über eine einzige Schnittstelle gemanagt wird: EMC Unisphere. Beim EMC-Speicher kann „Thin Provisioning“ zum Einsatz kommen, um eine Zuordnung von zu viel Speicher für die jeweiligen Anwendungen zu vermeiden. EMC verwendet zudem die Deduplizierungs-Technologie.

Damit werden das Backup und das Recovery von NAS- und SAN-basierten Anwendungen schneller, effizienter und skalierbarer. Im Zuge der höheren Ressourcenauslastung ergibt sich daher eine Reduzierung des Backup-Speicherbedarfs für die virtuelle Umgebung um das 10- bis 30fache, so EMC.

Bei den Virtualisierungs-Plattformen sind die vorab validierten VSPEX-Lösungen so ausgelegt, dass die Anwender die passenden Lösungen für die Anwendungsumgebung auswählen können: VSPEX stellt Dimensionierungs- und Skalierungsrichtlinien für Lösungen für Microsoft Hyper-V und VMware vSphere 5.X bereit. Diese Komponenten werden dann mit passender Netzwerkinfrastruktur (für die Anbindung der Speichersysteme, für das Client-Netzwerk sowie die Serververwaltung) sowie mit EMCs Unified Storage- und Backup-Technologien kombiniert.

Freie Wahl bei den Festplattentypen

VSPEX mit VNXe bietet dem Anwender die freie Wahl bei Festplattentypen (S-ATA, SAS oder SSD) und Größenordnung und je nach Hypervisor mit EMC Avamar die Möglichkeit, Backups auf Guest- oder Image-Ebene einzusetzen. Mit Hilfe von Avamar kann der Anwender seine gesamte virtuelle Umgebung schützen und Backups erstellen, Daten in einem einzigen Schritt wiederherstellen und Backups geschäftskritischer Applikationen erstellen. Dabei unterstützt die Lösung über spezielle Plug-Ins auch Microsoft-basierte Anwendungen, wie etwa Exchange Server, SQL Server und den Sharepoint Server.

In diesem Beitrag wird eine Referenzarchitektur skizziert, die mit VSPEX eine private Cloud auf der Basis des Hyper-V (die dritte Generation, die im Zuge des Windows Server 2012 zur Verfügung steht) bereitstellen kann, die für eine Belastung von 50 virtuellen Maschinen (VMs) geeignet ist.

Der Hyper-V hat in der aktuellen Version gegenüber vSphere von VMware aufgeholt. So kann Microsofts Virtualisierungs-Plattform nun bis zu 64 virtuelle CPUs und bis zu 1 TByte virtuelles DRAM in einer VM unterstützen. Das Verschieben von VMs von einem Host auf einen anderen ist mit der Live Migration ebenfalls ohne merkbare Unterbrechung für die Applikation auf dem Gastbetriebssystem machbar.

Abbildung 1 gibt einen groben Überblick zur vorgestellten Lösung für eine private Cloud. Die Hypervisor-Ebene kapselt die Anwendungen von der darunter liegenden Computing-Ressourcen ab. Damit lassen sich dann je nach Belastung automatisch die Workloads verschieben. Generell wird hier auch eine „vernünftige Dimensionierung“ für die Computing-Ressourcen vorgestellt – die ist naturgemäß von den Belastungen durch die Applikationen und die angeschlossenen Client-Systeme abhängig.

Über die Netzwerkebene wird der „Kontakt“ zwischen den Anwendern der Private Cloud und den Ressourcen, die sich in der Cloud befinden, hergestellt. In diesem Kontext schlägt die VSPEX-Konfiguration vor, wie viele Netzwerk-Ports für diese Lösung nötig sind. Zudem wird die allgemeine Netzwerkarchitektur gezeigt und vorgeschlagen, mit welchen Systemen sich ein derartiger Aufbau umsetzen lässt.

In der Realität erweist sich vor allem das Speichersubsystem als kritisch: Wenn hier nicht die passenden Vorkehrungen getroffen werden, ist das Private Cloud-Konzept recht schnell zum Scheitern verurteilt. Wenn verschiedene Virtualisierungs-Hosts auf gemeinsame Daten zugreifen, ist eine hohe Performance – also geringe Zugriffsverzögerung und ein hoher Datendurchsatz – nötig.

Hier spielt die VNXe-Familie ihre Vorteile aus – ein großes Augenmerk liegt dabei auf der Hochverfügbarkeit. Denn beim Ausfall des Speichers „hängen“ die Computing-Ressourcen in der Luft. Im Bereich der Computing-Ressourcen kommt bei dieser Konfiguration daher auch das Failover Clustering des Hyper-V zum Einsatz. Damit lassen sich dann vor allem geplante Ausfallzeiten – etwa wegen Wartungsarbeiten an einem physischen System – problemlos abwickeln. Aber auch das Thema Backup und Recovery erweist sich für derartige Einsatzbereiche als sehr wichtig.

Zusammenspiel von SC VMM und ESI

Als Verwaltungs- und Überwachungswerkzeug kommt hier der System Center Virtual Machine Manager (SC VMM) zum Einsatz. Damit erfolgt die Verwaltung der Virtualisierungs-Hosts, der Netzwerkumgebung sowie auch in gewissen Umfang der Speicher-Ressourcen: Alles was für das Erzeugen und verteilen von VMs nötig ist, wird vom SC VMM abgedeckt.

Zudem ist noch der EMC Storage Integrator (ESI) vorgesehen. Dabei handelt es sich um einen agentenloses Plug-in. Es erlaubt die Applikations-spezifische Provisionierung von Speicherplatz für alle Anwendungen, die auf Windows Server (also im Gastbetriebssystem der VM) aufsetzen. Dieses Tool von EMC eignet sich für den Einsatz mit den Virtualisierungs-Plattformen vSphere 5, Hyper-V und Xenserver.

Damit sind Administratoren in der Lage, sowohl blockbasierten als auch dateiorientierten Speicher zum Beispiel für Windows oder für Sharepoint-Sites bereitzustellen. Dazu sind im Rahmen des ESI mehrere Assistenten vorgesehen, die die Komplexität bei diesen Vorgängen reduzieren – konkret für die folgenden Aufgaben:

• Provisionieren, Formatieren und Darstellen von Laufwerken für Windows-Server,
• Provisionieren von neuen Cluster-Festplatten und automatisches Hinzufügen zum Cluster
• Provisionieren von gemeinsamen CIFS-Speicher und das Mounten dieses Speichers an Windows-basierte Server sowie
• das Provisionieren von Sharepoint-Speicher, Sites und Datenbanken.

Die Auswahl einer passenden Server-Infrastruktur für eine private Cloud ist nicht allein von den technischen Umgebungsparametern abhängig. Es geht dabei auch um den Support der Systeme, um gewachsene Beziehungen zu einem bestimmten Server-Hersteller aber auch um die Verwaltungsfunktionen für die Serverwelten. Deswegen schreibt die VSPEX-Lösung keinen speziellen Serveranbieter vor – im Gegenteil sie ermöglicht den Einsatz von vielen Varianten.

Daher erfolgt die Spezifikation der Computing-Ressourcen in Form von Prozessorkernen und einer Angabe der Arbeitsspeicherkapazität (DRAM). Das hat den entscheidenden Vorteil: Diese Ressourcen lassen sich dann entweder mit Hilfe von 20 Servern bereitstellen – oder aber mit nur zwei, entsprechend „starken“ Systemen.

In Abbildung 2 ist ein Beispiel zu sehen, bei dem die Anforderungen an die Computing-Ressourcen für eine bestehende Konfiguration mit mindestens 25 Prozessorkernen und insgesamt 200 GByte an DRAM abgedeckt werden können. Ein Unternehmen könnte diese Anforderung mit günstigen Servern (mit jeweils 16 Prozessorkernen und 64 GByte DRAM pro Server) abdecken, ein anderes Unternehmen wählt dagegen höherwertigere Systeme mit 20 Prozessorkernen und 144 GByte.

Je nach zusätzlichen gewünschten Reserven würde dann das eine Unternehmen vier Server kaufen (die bestimmende Größe sind in diesem Beispiel nicht die Prozessorkerne, sondern der Arbeitsspeicher), das andere nur deren zwei. Soll auch noch das Thema Hochverfügbarkeit adressiert werden, ist ein zusätzliches System nötig – in beiden Konfigurationsvarianten.

Dabei bestimmt die Größe des Zusatzservers die Last, die man im Falle eines Systemdefekts an einer Maschine noch problemlos stemmen kann. Hier darf aber ein Hinweis nicht fehlen: Um ein möglichst hohe Kompatibilität bei den Servern sicherzustellen, sollten die Befehlssätze der verwendeten CPUs nicht allzu sehr voneinander abweichen – anders ausgedrückt: Entweder die AMD- oder die Intel-Serverprozessoren verwenden.

Die Dimensionierung der Netzwerkebene sollte auf alle Fälle ausfallsicher sein. Dabei gilt es, die Anbindung an den Hyper-V-Host, an die Speicher-Arrays, an die Switch-Verbindung und die Uplinks der Switches entsprechend zu konzipieren. Nur so bekommt man sowohl genügend Bandbreite im Netzwerkbereich, als auch entsprechende Redundanz.

In Abbildung 3 ist ein Vorschlag zu sehen, der diese Vorgaben umsetzt. In dieser geprüften VSPEX-Lösung erfolgt das Trennen des Netzwerkverkehrs – nach seinen verschiedenen Übertragungstypen – mit Hilfe von Virtuellen LANs (VLANs). Das verbessert nicht nur den Datendurchsatz, sondern erleichtert die Verwaltung des Netzwerks, erhöht die Sicherheit, führt zu einer höheren Verfügbarkeit und grenzt die einzelnen Applikationen voneinander ab.

iSCSI bietet das MC/S

Als Basis kommt das iSCSI-Protokoll zum Einsatz. Es bietet die Funktionalität „MC/S“ (Multiple Connections per Session) und kombiniert in einer einzigen Session mehrere Verbindungen. Das führt zu einer schnelleren und hochverfügbaren Datenübertragung. Die VNXe-Systeme von EMC unterstützen diese Funktionalität. Zudem ist in diesem Ansatz das MC/S so konfiguriert, dass sich neben der Redundanz der Verbindungen auch eine Lastverteilung ergibt.

Das Speichersubsystem wird mit Hilfe der VNX-Familie von EMC aufgebaut. Dabei gilt die VMXe-Serie als die kleinere Ausgabe, die sich vor allem auf die Anforderungen konzentriert, wie sie bei kleineren Unternehmen auftreten. Die „große“ VNX ist dagegen für den Einsatz in mittleren und größeren Unternehmen vorgesehen.

Hochverfügbarkeit des Speichers

Die VNX-Familie unterstützt die Block- und Datei-basierte Speichermethoden. Sie ist zudem gut für den Einsatz in virtualisierten Infrastrukturen geeignet. In Bezug auf die Hochverfügbarkeit lassen damit sogar 99,999prozentige Verfügbarkeitswerte realisieren.

Die Verwaltung der Systeme erfolgt über die Suite EMC Unisphere. Für die Aufgaben im Bereich der Sicherung und Wiederherstellung ist noch der Networker (im Zusammenspiel mit den Deduplizierungs-Lösungen von Data Domain) einbezogen.

In Abbildung 4 ist eine logische Darstellung der Architektur zu sehen, die sich für eine Belastung von bis zu 50 VMs eignet – zusammen mit allen Zusatzdiensten und -Tools (DNS, Domänencontroller, SQL Server und SC VMM).

Rainer Huttenloher