Infrastruktur für virtualisierte Umgebungen

Ratgeber: Storage für virtuelle Maschinen auswählen

28.10.2011 von Beate Herzog
Die Virtualisierung von Servern lastet Ressourcen besser aus. Allerdings muss dann auch die Storage-Infrastruktur auf die sich verändernden Anforderungen abgestimmt sein. Lesen Sie, was Speichersysteme in virtualisierten Umgebungen leisten müssen und was die Hersteller anbieten.

Virtualisierung im Rechenzentrum führt auf verschiedenen Ebenen - Speicher, Netzwerk, Rechner, Anwendungen - Abstraktionsschichten ein, die eine flexiblere Verwaltung der zugrunde liegenden physikalischen Schicht ermöglichen. Durch die Einführung virtueller Provisionierungsmodelle auf dem Speicher und virtueller Laufwerke auf der Ebene des Hypervisors sind Konfigurationen nicht mehr wie gewohnt direkt von der darunterliegenden physikalischen Ebene abhängig. Dies führt dazu, dass sich Konfigurationen im laufenden Betrieb logisch verändern und an die jeweiligen Anforderungen der aktuellen Betriebssituation anpassen lassen. Daher gelten für das Speicherkonzept einige grundsätzliche Regeln, in deren Rahmen eine erste Konfiguration des Speichersystems vorgenommen werden sollte.

Die Storage-Regeln sollten abhängig von den jeweiligen Betriebsparametern verändert werden:

Single-Point-of-Failure-Ansatz: Desaster Recovery und Desaster Avoidance

Viele Betreiber von Rechenzentren mit virtuellen Serverfarmen planen zusätzlich zu ihrem Hauptrechenzentrum weitere redundante Rechenzentren an entfernten Standorten - zumindest wäre dies ratsam. Die virtuellen Server sollen dabei in den meisten Fällen auf alle Rechenzentren verteilt aufgebaut und im Regelfall im Betrieb mit gegenseitigem Lastausgleich auf allen Rechnern verteilt betrieben werden.

Für die Speicherumgebung sowie die angeschlossene virtualisierte Serverlandschaft sollte es gegen einzelne Systemausfälle oder den Verlust eines ganzen Rechenzentrums einen standortübergreifenden Schutz geben. Der integrierte Einsatz gestaffelter, voneinander abhängiger Technologien für Desaster Recovery und Desaster Avoidance kommt hier in Betracht. Um einen standortübergreifenden Schutz der virtualisierten RZ-Umgebung zu gewährleisten, wäre es ratsam, eine Kombination von nativer Speicherreplikation und Hypervisor-eigenen strukturierten Wiederanlaufverfahren virtueller Server einzuführen.

Eine native Replikation zwischen Speichersystemen spiegelt Daten zwischen Arrays automatisch mit deren eigenen Bordmitteln, ohne dass der Eingriff durch externe Verfahren beziehungsweise Steuermethoden nötig ist. Für die synchrone Replikation sollte eine Round-Trip-Zeit von 5 ms nicht überschritten werden; in den meisten Fällen entspricht dies bei guter Leitungsqualität Strecken von 100 bis 150 km. Dies ist vom verwendeten Protokoll unabhängig, sodass sich sowohl klassische FC- als auch IP-Strecken verwenden lassen. Bei Round-Trip-Zeiten von über 5 ms beziehungsweise Leitungslängen von mehr als 150 km können die Speichersysteme asynchron gekoppelt werden. Neu geschriebene Daten gelangen dann mit einem gewissen Zeitverzug zum entfernten Speichersystem.

Wiederanlaufverfahren simulieren

Einschlägige Zusatzprodukte erweitern die bestehenden virtuellen Serverumgebungen um Verwaltungsfunktionen zur Planung und Steuerung von Ausfallszenarien. Katastrophenfallpläne können mit ihrer Hilfe konfiguriert und in den meisten Fällen in einem Simulationsmodus getestet werden. Dabei greifen die Hypervisor-Systeme auf eine automatisch generierte lokale Kopie der Daten im entfernten Rechenzentrum zurück und starten virtuelle Maschinen in einem abgeschirmten Testnetzwerk, während die produktiven Systeme weiterhin in Betrieb bleiben.

Bei der Ausführung dieser Pläne in einem realen Ausfallszenario werden die virtuellen Server im produktiven Rechenzentrum bei Möglichkeit noch heruntergefahren und im entfernten Standort gestartet. Einige Produkte steuern dabei auch den produktiven Übergang des Speichers. Mit dieser Steuerung kann die Reihenfolge beim Wiederanfahren von Servern festgelegt werden. Im Rahmen der Planung können auch virtuelle Server mit geringer Priorität in den Stand-by-Modus versetzt werden. Dadurch lassen sich Serverumgebungen im Normalbetrieb sehr effizient nutzen und Betriebsreserven von mindestens 50 Prozent für automatisierte Ausfallumgebungen anderweitig verplanen.

Die Rückkehr nach einem Ausfall in das zentrale Rechenzentrum ist über dieselben Wege wie beim Desaster-Szenario möglich. Der Einsatz entsprechender Software erlaubt die einfache Planung und Durchführung von K-Fall-Szenarien und stellt sicher, dass virtualisierten Server im Normalbetrieb ressourcenschonend genutzt werden.

Native Replikation bei hohen Anforderungen

Bei sehr hohen Anforderungen an die Verfügbarkeit von Rechensystemen im Notfall und für eine durchgängige Servermobilität zwischen RZ-Standorten ist die native Speicherreplikation zwischen zwei Arrays vorzuziehen. Dabei werden Datenplatten zwischen mehreren Speichersystemen automatisch repliziert. Die Festplatten stehen an beiden Standorten im Normalbetrieb zum Lesen und Schreiben zur Verfügung.

Bei einem Ausfallszenario werden über eine Kontrollinstanz (Witness) die Daten am jeweils verbleibenden Standort unterbrechungsfrei bereitgestellt. Die Kontrollinstanz verhindert Split-Brain-Zustände, bei denen zwei Speichersysteme im Falle des Verlusts der Verbindung unabhängig voneinander produktiv, also lesend und schreibend laufen. Bei einer Round-Trip-Zeit bis zu 5 ms ist eine synchrone Kopplung der Systeme möglich. Diese Zeit entspricht je nach Qualität einer Leitungslänge von 100 bis 150 km.

Auf der Serverebene kann dank der speicherübergreifenden lesenden und schreibenden Bereitstellung von Daten mit einem standortübergreifenden Modell mit gemeinsam genutzten Platten gearbeitet werden. So können virtuelle Cluster in den einzelnen Standorten oder standortübergreifende "Stretched Cluster" auf ein und denselben Datenbestand zugreifen. Beim Einsatz solcher Strechted Cluster lassen sich für das automatische Starten virtueller Server im Störungsfall die Hochverfügbarkeitsmerkmale des Hypervisor nutzen.

Für geplante Speichersystem- oder Rechenzentrumsabschaltungen sowie Katastrophenfälle, in denen ein manuelles Eingreifen noch möglich ist, können nicht-automatische Verfahren zur Evakuierung der virtuellen Server aus einem Rechenzentrum zum Einsatz kommen. Bei vollautomatisierten Failover-Szenarien sind in beiden Lokationen ausreichend Server und Netzwerkressourcen bereitzustellen. Diese Ressourcen sind bei einem RZ-Ausfall im jeweils verbliebenen Rechenzentrum für das automatische Wiederanfahren der virtuellen Server des ausgefallenen Standorts zu gewährleisten.

Virtualisierungsplattformen und ihre Speichereigenschaften

Obwohl es im Markt der Virtualisierungsplattformen eine fast unüberschaubare Fülle an Produkten gibt, wird dieser seit einigen Jahren von lediglich drei Produkten dominiert. VMware hält mit seinem ESX Server (vSphere) und den anderen Paketen einen - noch langsam zunehmenden - Anteil von knapp 60 Prozent, während Citrix mit dem XenServer und Microsoft mit Hyper-V nur jeweils ein Fünftel der Anwender von sich überzeugen können.

VMware ESX

VMware hat die mit Abstand längste und größte Erfahrung mit virtualisierten Systemen, beschäftigt sich das amerikanische Unternehmen doch seit 1998 ausschließlich mit dieser Materie. Der für den Rechenzentrumseinsatz geeignete ESX Server unterstützt eine breite Palette von Betriebssystemen, unter anderem Windows, Netware, Linux und Solaris. Seine Funktionen erstrecken sich von der automatischen Erzeugung einzelner Umgebungen über die Bewegung von Serverabbildern im Rechenzentrum und über dessen Grenzen hinweg bis hin zu voll automatisierten Failover- und Fallback-Szenarien. Hierfür bietet der ESX Server (vSphere) eine Schnittstelle namens VAAI, die sowohl von Anwendungs- als auch von Speicherseite zur Steuerung der Software genutzt werden kann. Die Verwaltungsanwendung vCenter Server kann mehrere ESX-Systeme konfigurieren und überwachen und ist die Voraussetzung dafür, dass die Hochverfügbarkeits- und Datenmobilitätsfunktionen genutzt werden können. Neben dem ESX Server bietet VMware weitere, oft kostenlose Pakete zum Betrieb auf Windows-, Linux- und mobilen Plattformen an. Annähernd 60 Prozent aller virtualisierten Server laufen mit einer Version von VMware.

Microsoft Hyper-V

Im Gegensatz zum VMware ESX Server ist Microsoft Hyper-V eine Erweiterung, die auf Basis von Windows 2008 Server R2 installiert wird. Durch diese Architektur unterstützt das System mit wenigen Abweichungen alle Speicherfunktionen, die auch vom Windows Server geboten werden. Für Gastsysteme beschränkt sich Hyper-V auf Windows und wenige Linux-Derivate. Zum Verschieben von virtuellen Servern und für andere Hochverfügbarkeitsmerkmale benötigt Hyper-V einen Windows-Cluster. Die Verwaltung geschieht über die Microsoft Management Console und ist damit ein integrativer Bestandteil der Serverumgebung des Herstellers. Microsoft hält mit Hyper-V einen Marktanteil von knapp 20 Prozent.

Citrix XenServer

Wie VMware ESX ist auch XenServer ein Produkt, das direkt auf einer Hardware installiert wird. Virtuelle Maschinen laufen hier in sogenannten Domänen, für die entweder der Hypervisor oder andere Domänen sichtbar sind. Zur Verwaltung des gesamten Serverkomplexes dient die erste gestartete Domäne, in deren Betriebssystem diese Funktionalität integriert werden muss. Im Gegensatz zu allen anderen Produkten benötigt der XenServer eine spezielle Hardware (AMD-V oder Intel VT), um alle Virtualisierungsfunktionen transparent ausführen zu können. Zwar werden auch andere Betriebssysteme unterstützt, jedoch konzentriert sich die Entwicklung des XenServers auf den Linux- und BSD-Bereich. Außer den unter diesen Betriebssystemen zur Verfügung stehenden Speicherfunktionen, vor allem im Cluster-Bereich, stellt XenServer keine eigenen Lösungen zur Verfügung. Trotz größter Bemühungen aller Beteiligten, die Software zum Industriestandard zu machen, ist das Produkt mit nur knapp 20 Prozent am Markt der Virtualisierungsplattformen beteiligt.

Oracle VM

Oracle hat seine Virtualisierungslösung Oracle VM seit Ende 2007 im Programm. Es handelt sich dabei um ein System zur Virtualisierung von Servern. Im Sommer 2011 wurde die Version 3.0 vorgestellt. Als solches spielt Oracle VM in der Liga der Virtualisierungssysteme von VMware und dessen ESXi-Server, dem Microsoft Hyper-V oder Citrix XenServer. Oracle VM 3.0 unterstützt 128 virtuelle CPUs pro virtueller Maschine. Auf den eigenen Sun Fire X4800 M2 Servern zeigte Oracle eine Installation mit 160 physikalischen CPUs und 2 TByte Arbeitsspeicher. Oracle VM basiert auf den Konzepten von Xen und setzt auf diesem Open-Source-Produkt auf. Infolgedessen ist Oracle VM mit Citrix XenServer vergleichbar, dessen Wurzeln ebenfalls in Xen liegen. Die Oracle-Virtualisierungssoftware unterstützt Anwendungen von Oracle und anderen Anbietern gleichermaßen. Dennoch wird Oracle mit dem begrenzten Angebot kaum in Wettbewerb zu VMware oder Microsoft treten wollen und können. Das ist derzeit aber auch nicht das Ziel des Datenbankgiganten. Für die Kunden von Oracle steht damit auch eine Oracle-eigene Virtualisierungssoftware zur Verfügung.

Einen detaillierten Überblick zu Oracles Lösungen finden Sie im Artikel Ratgeber: Was ist was bei der Oracle Server- und Desktop-Virtualisierung?

Speichersysteme für virtualisierte Umgebungen

Im Zeitalter von Cloud und Virtualisierung schmücken sich natürlich alle Speicherhersteller mit der Unterstützung virtueller Systeme. Allerdings sind die Gräben zwischen marketingseitigem Anspruch und technischer Realisierung bei einigen Herstellern noch relativ breit und tief.

EMC

Der Marktführer bei Enterprise-Arrays hat sich vor Jahren bereits die Mehrheit am damals noch kleinen Nischenhersteller VMware gesichert. Mit kräftiger Finanzhilfe von EMC hat sich VMware inzwischen zum unbestrittenen Marktführer im Segment der Virtualisierung entwickelt. Als logische Konsequenz hat sich EMC vor allem der Integration von VMware-Funktionalitäten in seine Speichersysteme und Software verschrieben. Sowohl die VNX (ehemals CLARiiON) als auch die SYMMETRIX VMAX verfügen über die umfangreichste Unterstützung von VMware im Markt. Alle beschriebenen Szenarien, vom manuellen Verlegen der Rechenlandschaft über automatisierte K-Fall-Reaktionen bis zum Wiedereintritt in die geregelte Produktion, werden von beiden EMC-Baureihen ohne Einschränkung unterstützt. Virtualisierungspakete wie Microsoft HyperV, XenServer von Citrix und Oracle Virtual Box werden zwar ebenfalls unterstützt, bieten allerdings von sich aus schon eine wesentlich schmalere Palette an Automatisierungsmöglichkeiten. Gemeinsam mit Cisco und VMware bietet EMC seit über einem Jahr eine integrierte Plattform namens VCE (Virtual Computing Environment) an, die sich aus einem VMAX- oder VNX-Speichersystem, einem UCS-Server von Cisco und VMware zusammensetzt. Insgesamt ist EMC mit über 70 Prozent Anteil an den Speicherplattformen für virtualisierte Server unangefochtener Platzhirsch.

NetApp

Nach EMC ist NetApp die beliebteste Plattform für virtualisierte Umgebungen - allerdings mit knapp 20 Prozent Marktanteil in gehörigem Abstand. Die neueste Version der NetApp Filer integriert sich mit dem VAAI des VMware ESX Servers und stellt über Funktionen des jeweils angeschlossenen Betriebssystems Failover- und Fallback-Mechanismen für andere Virtualisierungsplattformen zur Verfügung. Allerdings gibt es im Gegensatz zur EMC-Lösung weder Möglichkeiten, mehrere Pfade zum Speichersystem gleichzeitig zu nutzen, noch eine detaillierte Sicht vom ESX Server auf die Speicherumgebung. Als Analyse- und Optimierungswerkzeug für VMware- und Hyper-V-Umgebungen liefert NetApp Akorri BalancePoint aus, das als Teil der OnCommand Suite vertrieben wird. Auch NetApp hat im Jahr 2011 eine integrierte Lösung zusammen mit Cisco und VMware auf den Markt gebracht, den sogenannten FlexPod. Hier werden wie beim Vorbild VCE ein UCS-Server, ein NetApp-Speicher und ein ESX-Server kombiniert - während dieser allerdings vollständig montiert beim Kunden angeliefert wird, besteht der FlexPod aus einzelnen Komponenten, die vor Ort von Partnern montiert und eingerichtet werden müssen.

HDS

HDS sieht sich selbst als Vorreiter der Virtualisierung von Speichersystemen und verfolgt diese Strategie mit seinen USP-V- und VSP-Speicherplattformen seit einigen Jahren konsequent. Allerdings muss der Hersteller noch in einigen Bereichen nachlegen, was die Unterstützung virtualisierter Serverumgebungen betrifft. So mangelt es bisher an Lösungen für die Hochverfügbarkeit zwischen mehreren Speichersystemen an einem Standort, genauso wie der nativen Integration in Verwaltungsoberflächen der verschiedenen Hypervisor-Anbieter. Darüber hinaus gibt es zwar von Kunden selbst gescriptete Lösungen im Bereich Failover und Fallback, diese werden jedoch von HDS nur im Rahmen des Supports für die jeweilige Serverplattform unterstützt. All diese Einschränkungen bescheren HDS einen aktuellen Marktanteil von unter 5 Prozent für virtualisierte Serverplattformen. Allerdings profitiert der Kunde von der Einbindung von Fremdsystemen. Diese werden in einem Speicher-Pool zusammengefasst, und alle Funktionen, die VSP bietet, lassen sich hier auch anwenden.

Hewlett-Packard

Auch HP hat sich den besonderen Anforderungen virtualisierter Umgebungen gestellt, konnte diese aber nicht in Eigenentwicklung stemmen, sondern bietet nun vor allem seine LeftHand-Serie als Lösung an. Das LeftHand-Cluster bringt dabei den größten Nutzen für eine virtualisierte Umgebung. Zunächst lassen sich Funktionen wie Thin Provisioning, Tiering oder Replikation nutzen. Darüber hinaus kann das Cluster Node-weise wachsen, wobei mit jedem hinzugefügten Node nicht nur Kapazität, sondern Gesamtleistung hinzugefügt werden wie Netzwerk, Controller und Cache.

Anbieter mit VAAI-Support im Überblick

Neben den erwähnten Marktführern bieten auch 3Par (HP), Dell/Compellent, EqualLogic und IBM Speichersysteme mit VAAI-Unterstützung an.

Folgende Produkte und Hersteller nutzen ebenfalls die VAAI-Schnittstelle von VMware:

(cvi)