Best-Practices-Planung - Data Storage, Converged, … von VMware-Virtualisierungspla ttformen mit...

Verwendung von VMware-Virtualisierungsplattformen mit

EMC VPLEX Best-Practices-Planung

Abstract

In diesem White Paper werden die für VMware-Virtualisierungsplattformen relevanten Funktionen von EMC® VPLEX™ erläutert. Außerdem werden Best Practices zur Konfiguration der VMware-Umgebung für den optimalen Einsatz von EMC VPLEX beschrieben. Darüber hinaus werden Methoden zur Migration einer vorhandenen VMware-Bereitstellung in die EMC VPLEX-Produktreihe besprochen.

Mai 2010

Verwendung von VMware-Virtualisierungsplattformen mit EMC VPLEX mit EMC VPLEX Best Practices-Planung 2

Copyright © 2010 EMC Corporation. Alle Rechte vorbehalten.

EMC geht davon aus, dass die Informationen in dieser Publikation zum Zeitpunkt der Veröffentlichung korrekt sind. Die Informationen können jederzeit ohne vorherige Ankündigung geändert werden.

DIE IN DIESEM DOKUMENT ENTHALTENEN INFORMATIONEN WERDEN OHNE GEWÄHR ZUR VERFÜGUNG GESTELLT. EMC CORPORATION MACHT KEINE ZUSICHERUNGEN ODER ÜBERNIMMT KEINE HAFTUNG JEDWEDER ART IM HINBLICK AUF DIE IN DIESEM DOKUMENT ENTHALTENEN INFORMATIONEN UND SCHLIESST INSBESONDERE JEDWEDE IMPLIZITE HAFTUNG FÜR DIE GEBRAUCHSTAUGLICHKEIT ODER EIGNUNG FÜR EINEN BESTIMMTEN ZWECK AUS.

Für die Nutzung, das Kopieren und die Verteilung der in dieser Veröffentlichung beschriebenen EMC Software ist eine entsprechende Softwarelizenz erforderlich.

Eine aktuelle Liste der EMC Produktnamen finden Sie im Abschnitt zu Marken der EMC Corporation auf emc2.de.

Alle anderen in diesem Dokument erwähnten Marken sind Eigentum der jeweiligen Inhaber.

Art.-Nr. h7118


Inhaltsverzeichnis Zusammenfassung ............................................................................................. 4 Einleitung ............................................................................................................ 4

Zielgruppe .................................................................................................................................... 5 EMC VPLEX – Übersicht ..................................................................................... 5

EMC VPLEX-Architektur .............................................................................................................. 5 EMC VPLEX-Produktreihe ........................................................................................................... 6 EMC VPLEX-Cluster-Architektur ................................................................................................. 6

Bereitstellung von VPLEX-Speicher in VMware-Umgebungen ....................... 8 Überlegungen zur Konnektivität ...................................................................... 17 Multipathing und Lastausgleich ...................................................................... 20

VMware ESX Server Version 3 und statischer Lastausgleich ................................................... 21 VMware ESX Server Version 4 und NMP .................................................................................. 22 VMware ESX Server Version 4 mit PowerPath/VE ................................................................... 23

Funktionen von PowerPath/VE .............................................................................................. 24 PowerPath/VE-Management .................................................................................................. 24

Migration vorhandener VMware-Umgebungen in VPLEX .............................. 26 Unterbrechungsfreie Migrationen mit Storage vMotion ............................................................. 26 Migration mit Kapselung vorhandener Devices ......................................................................... 28

VMware-Bereitstellungen in einer VPLEX Metro-Umgebung ........................ 36 VMware-Cluster-Konfiguration ................................................................................................... 37 Unterbrechungsfreie Migration virtueller Maschinen mit vMotion .............................................. 42 Ändern der Konfiguration nicht replizierter VPLEX Metro-Volumes ......................................... 43 Virtualisierte vCenter Server-Instanzen in VPLEX Metro .......................................................... 47

Fazit .................................................................................................................... 49 Quellennachweise ............................................................................................. 49


Zusammenfassung Die mit dem Betriebssystem EMC GeoSynchrony™ ausgeführte EMC® VPLEX™-Produktreihe bietet eine umfassende Auswahl neuer Funktionen für das Zeitalter des Cloud Computings. EMC VPLEX überwindet die physischen Schranken von Rechenzentren und ermöglicht Benutzern an unterschiedlichen Standorten den gleichzeitigen Zugriff auf eine einzelne Datenkopie. Dies ermöglicht eine transparente Migration von aktiven virtuellen Maschinen zwischen Rechenzentren. Durch diese Funktion wird ein transparenter Lastausgleich zwischen mehreren Standorten möglich. Gleichzeitig besteht die Flexibilität zur Migration von Workloads zwischen Standorten im Vorfeld geplanter Ereignisse. Darüber hinaus können bei einer Serviceunterbrechung in einem Rechenzentrum aufgrund von ungeplanten Ereignissen die ausgefallenen Services am noch aktiven Standort mit minimalem Aufwand und Recovery Time Objective (RTO) neu gestartet werden.

Die VMware-Virtualisierungsplattform dient zur Virtualisierung der gesamten IT-Infrastruktur einschließlich Server, Speicher und Netzwerke. Die Software VMware fasst diese Ressourcen zusammen und stellt sie in der virtuellen Umgebung als einheitliche Gruppe von Elementen dar. Damit macht VMware vSphere 4 die Vorteile von Cloud Computing im Rechenzentrum nutzbar und trägt zur Reduzierung der IT-Kosten und zur Steigerung der Effizienz der Infrastruktur bei. Anbietern von Hosting-Services ermöglicht VMware vSphere 4 außerdem eine wirtschaftlichere und effizientere Bereitstellung von Cloud-Services, die mit den internen Cloud-Infrastrukturen von Kunden kompatibel sind. VMware vSphere 4 bietet im Vergleich zur Vorgängerversion VMware Infrastructure 3 beträchtliche Verbesserungen hinsichtlich Performance und Skalierbarkeit. So können nun auch äußerst ressourcenintensive Anwendungen wie große Datenbanken in internen Clouds bereitgestellt werden. Mit diesen Performance- und Skalierbarkeitsverbesserungen ermöglicht VMware vSphere 4 eine zu 100 Prozent virtualisierte interne Cloud.

Die EMC VPLEX-Produktreihe ist daher die ideale Ergänzung einer auf VMware-Technologie basierenden Virtualisierungsumgebung. Da mit EMC VPLEX sowohl ein lokaler als auch ein verteilter Verbund bereitgestellt werden kann, der eine transparente Kooperation physischer Datenelemente an einem Standort oder an zwei geographisch getrennten Standorten ermöglicht, können IT-Administratoren physische Grenzen überwinden und das VMware-basierte Cloud-Angebot erweitern. Durch die EMC VPLEX-Funktionen für den lokalen Verbund können die heterogenen Datenspeicherlösungen an einem physischen Standort zusammengefasst werden, und der Speicher kann als Ressourcen-Pool für die VMware-Virtualisierungsplattform genutzt werden. Damit sind die wesentlichen Grundlagen für ein Cloud-Angebot gelegt. Insbesondere eine Ausweitung der VPLEX-Funktionen auf mehrere Rechenzentren ermöglicht IT-Administratoren die Nutzung von Private- bzw. Public-Cloud-Angeboten von Hosting-Service-Anbietern. Die durch ein VMware-Virtualisierungssystem in Kombination mit EMC VPLEX erzielten Synergieeffekte helfen daher den Kunden dabei, die Total Cost of Ownership (TCO) zu senken und gleichzeitig einen dynamischen Service bereitzustellen, der sich zügig an die sich ändernden geschäftlichen Anforderungen anpassen lässt.

Einleitung In diesem White Paper wird die EMC VPLEX-Produktreihe vorgestellt. Dabei wird insbesondere auf die Cluster-Architektur und die für Private-Cloud-Lösungen relevanten Funktionen eingegangen. Anschließend wird die Bereitstellung von VPLEX-Speicher in VMware-Umgebungen erörtert, und es werden Tipps zur optimalen Methode für die Verbindung zwischen VMware-Virtualisierungsplattformen und EMC VPLEX sowie zur Auswahl einer Multipathing Policy erteilt, mit der sich in der virtualisierten Umgebung die bestmögliche Flexibilität und Performance erzielen lässt. Darüber hinaus werden verschiedene Methoden zur Migration vorhandener VMware-Bereitstellungen zu EMC VPLEX präsentiert. Zum Schluss werden die Best Practices zur Nutzung von EMC VPLEX Metro in einer VMware-Umgebung zur Maximierung von Flexibilität, Belastbarkeit und Datensicherheit bei gleichzeitiger Minimierung der Risiken nicht verfügbarer Daten aufgrund von ungeplanten Ereignissen erläutert.


Zielgruppe Dieses White Paper richtet sich an VMware-Administratoren, Speicheradministratoren und IT-Architekten, die für die Planung, Erstellung, Verwaltung und Nutzung virtualisierter IT-Umgebungen mit VMware vSphere- und EMC VPLEX-Technologien zuständig sind. Es wird davon ausgegangen, dass der Leser mit VMware-Technologie, EMC VPLEX und zugehöriger Software vertraut ist.

EMC VPLEX – Übersicht Bei der EMC VPLEX-Produktreihe mit dem Betriebssystem EMC GeoSynchrony handelt es sich um eine SAN-basierte Verbundlösung, die physische Beschränkungen in Umgebungen mit einem bzw. mehreren virtualisierten Rechenzentren überwindet. EMC VPLEX ist die weltweit erste Plattform, die sowohl einen lokalen als auch einen verteilten Verbund bereitstellt. Der lokale Verbund ermöglicht die transparente Kooperation physischer Speicherelemente an einem Standort. Der verteilte Verbund weitet das Konzept auf zwei räumlich entfernte Standorte aus. Der verteilte Verbund wird durch die mit VPLEX verfügbare bahnbrechende Technologie AccessAnywhere™ ermöglicht, mit der eine einzelne Datenkopie über Entfernungen gemeinsam genutzt, abgerufen und verschoben werden kann.

Die Kombination aus einem virtualisierten Rechenzentrum und der EMC VPLEX-Produktreihe bietet Kunden gänzlich neue Wege zur Lösung von IT-Problemen und zur Einführung neuer Datenverarbeitungsmodelle. Konkret haben Kunden jetzt folgende Möglichkeiten:

Verschieben von virtualisierten Anwendungen zwischen Rechenzentren Workload Balancing und Verlagerung über mehrere Standorte hinweg Aggregation von Rechenzentren und Bereitstellung rund um die Uhr

EMC VPLEX-Architektur EMC VPLEX stellt die Architektur der nächsten Generation für Datenmobilität und Informationszugriff dar. Die neue Architektur basiert auf der mehr als 20-jährigen Erfahrung von EMC in den Bereichen Entwicklung, Implementierung und Perfektionierung von Lösungen der Enterprise-Klasse für intelligente Caches und verteilte Datensicherheit.

Wie in Abb. 1 dargestellt, ermöglicht VPLEX den Verbund von EMC Speicher und Speicher anderer Anbieter. VPLEX agiert zwischen den Servern und den heterogenen Speicherressourcen und nutzt eine neue Architektur mit einzigartigen Merkmalen:

Scale-Out-Cluster-Hardware, mit der Kunden klein anfangen und mit planbaren Service-Levels wachsen können

Erweitertes Daten-Caching mit großem SDRAM-Cache zur Verbesserung der Performance und zur Reduzierung von I/O-Latenz und Array-Konflikten

Verteilte Cache-Kohärenz für Automatisierung von Freigabe, Ausgleich und Failover von I/O im Cluster

Konsistente Anzeige einer oder mehrerer LUNs über verschiedene VPLEX-Cluster hinweg. Dies gilt für Cluster innerhalb desselben Rechenzentrums ebenso wie für über synchrone Entfernungen miteinander verbundene Cluster und ermöglicht neue Modelle von Hochverfügbarkeit und Arbeitslastverlagerung.


Abb. 1: EMC VPLEX ermöglicht Verbund heterogener Speicher

EMC VPLEX-Produktreihe Die VPLEX-Produktreihe besteht aus zwei Angeboten:

VPLEX Local: Diese Lösung ist für Kunden geeignet, die einen Verbund homogener oder heterogener Speichersysteme in einem Rechenzentrum benötigen, sowie für die Verwaltung von Datenmobilität zwischen physischen Datenspeichereinheiten.

VPLEX Metro: Diese Lösung ist für Kunden geeignet, die gleichzeitigen Zugriff und Datenmobilität an zwei in synchroner Entfernung voneinander entfernt liegenden Standorten benötigen. VPLEX Metro bietet die einzigartige Möglichkeit der Darstellung von LUNs am VPLEX Metro-Remote-Standort, ohne dass am Remote-Standort physischer Speicher für diese LUNs erforderlich ist.

In Abb. 2 wird die EMC VPLEX-Produktreihe mit den aktuellen Architekturbeschränkungen dargestellt.

Abb. 2: EMC VPLEX-Produktreihe mit Architekturbeschränkungen

EMC VPLEX-Cluster-Architektur VPLEX nutzt eine einzigartige Cluster-Architektur, mit der Kunden die Einschränkungen des Rechenzentrums überwinden und Server in mehreren Rechenzentren bereitstellen können, um den gleichzeitigen Lese- und Schreibzugriff auf gemeinsam genutzte Blockspeicher-Devices zu ermöglichen. Ein VPLEX-Cluster (siehe Abb. 3) kann durch zusätzliche Engines erweitert und durch die Kombination mehrerer Cluster zu einer VPLEX Metro-Konfiguration skaliert werden. In der ersten Version unterstützt ein VPLEX Metro-System bis zu zwei Cluster, die sich im selben Rechenzentrum oder an zwei verschiedenen Standorten innerhalb synchroner Entfernungen befinden können (ca. bis zu 100 Kilometer). VPLEX Metro-Konfigurationen unterstützen Anwender dabei, Workloads transparent zu verschieben und gemeinsam zu nutzen, Rechenzentren zu konsolidieren und die Ressourcennutzung in Rechenzentren zu optimieren.


Darüber hinaus bieten VPLEX-Cluster unterbrechungsfreie Datenmobilität, heterogenes Speichermanagement und verbesserte Anwendungsverfügbarkeit.

Abb. 3: Schematische Darstellung von EMC VPLEX Metro Ein VPLEX-Cluster besteht aus einer, zwei oder vier Engines. Die Engine ist für die Föderierung des I/O-Streams zuständig und stellt über Fibre Channel Datenübertragungsverbindungen zu Hosts und Speichern her. Ein einzelner VPLEX-Cluster besteht aus einer Engine mit den folgenden Hauptkomponenten:

• Zwei Directors, die die Software GeoSynchrony ausführen und über Fibre-Channel- und Gigabit-Ethernet-Verbindungen mit Speicher, Hosts und anderen Directors im Cluster verbunden sind

• Ein Standby-Netzteil, das Reservestrom zur Überbrückung von vorübergehenden Stromausfällen liefert

• Zwei Managementmodule mit Schnittstellen für das Remote-Management einer VPLEX-Engine Jedes Cluster umfasst außerdem:

• Einen Managementserver, der die Cluster verwaltet und eine Schnittstelle von einer Remote-Managementstation bereitstellt

• Einen EMC 40U-Standardschrank, der die gesamte Ausstattung des Clusters enthält


Darüber hinaus enthalten Cluster mit mehr als einer Engine:

Zwei Fibre Channel Switches für die Kommunikation zwischen den Directors der verschiedenen Engines • Zwei universelle Netzteile (UPSs), die den Reservestrom für die Fibre Channel Switches

liefern und vorübergehende Stromausfälle des Systems überbrücken können

Bereitstellung von VPLEX-Speicher in VMware-Umgebungen EMC VPLEX stellt eine intuitive, assistentengestützte Managementschnittstelle zur Bereitstellung von Speicher für verschiedene Betriebssysteme einschließlich der VMware-Virtualisierungsplattform bereit. Für fortgeschrittene Anwender steht auch eine Befehlszeilenschnittstelle (CLI) zur Verfügung. Abb. 4 zeigt die grafische Benutzeroberfläche (GUI) zur Bereitstellung von Speicher in EMC VPLEX.

Abb. 4: Grafische Managementoberfläche von EMC VPLEX


Die in Abb. 4 dargestellte Browser-basierte Managementoberfläche zeigt in schematischer Weise die an dem Prozess beteiligten Komponenten. Der EMC VPLEX-Speicher wird mit einem logischen Konstrukt namens „Storage View“ (Speicheransicht) dargestellt, das sich aus den Objekten „Registered initiators“ (Registrierten Initiatoren), „VPLEX ports“ (VPLEX-Ports) und „Virtual Volume“ (Virtuelles Volume) zusammensetzt. Das Objekt „Registered initiators“ enthält die WWPN der Initiatoren, die Zugriff auf den Speicher benötigen. Im Fall einer VMware-Umgebung enthält das Objekt „Registered initiators“ die WWPN der HBAs in den mit EMC VPLEX verbundenen VMware ESX-Servern. Das Objekt „VPLEX ports“ enthält die Front-End Ports des VPLEX-Arrays, über die die „Registered initiators“ auf die virtuellen Volumes zugreifen. Das Objekt „Virtual Volume“ ist eine Zusammenstellung von Volumes, die aus den Speicher-Volumes konstruiert werden, die EMC VPLEX von den Back-End-Speicher-Arrays bereitgestellt werden. Unten links in Abb. 4 ist zu erkennen, dass ein virtuelles Volume aus einem „Device“ konstruiert wird, das wiederum aus mehreren, auf einer als „Extent“ bezeichneten abstrakten Einheit aufbauenden Devices besteht. Die Abbildung veranschaulicht außerdem, dass ein „Extent“ auf der Grundlage des in EMC VPLEX bereitgestellten „Storage Volume“ (Speicher-Volume) erstellt wird.

Unten rechts in Abb. 4 sind die sieben Schritte für das Speicher-Provisioning mit EMC VPLEX dargestellt. Bei EMC VPLEX Metro unterstützt der Assistent ein zentrales System zur Bereitstellung von Speicher für unterschiedliche Cluster-Mitglieder. Der erste Schritt beim Speicher-Provisioning in EMC VPLEX ist die Erkennung der angeschlossenen Speicher-Arrays. Dieser Schritt muss jedoch selten ausgeführt werden, da die Speicherumgebung von EMC VPLEX auf Änderungen überwacht wird.

Der zweite Schritt besteht darin, den für EMC VPLEX verfügbaren Speicher zu „beanspruchen“. Hierbei wird das in Abb. 4 dargestellte „Speicher-Volume“ erstellt. Ein Beispiel dieses Vorgangs finden Sie in Abb. 5. Aus der Abbildung geht hervor, dass die VPLEX-Software zur Vereinfachung des Vorgangs automatisch anwenderfreundliche Namen für die in den Speicher-Arrays verfügbaren Devices vorschlägt.


Abb. 5: Beanspruchung von Speicher-Volumes mit dem VPLEX-Assistenten

Sobald die Speicher-Volumes erstellt wurden, müssen Extents daraus gebildet werden. Für diese Aufgabe steht im VPLEX-Managementsystem ein Assistent zur Verfügung. Dieser Assistent wird über den Link „Step 3: Create Extents from Storage Volumes“ aufgerufen (siehe Abb. 4). In Abb. 6 ist der erste Schritt des Assistenten dargestellt.


Abb. 6: Erster Schritt im Assistenten zur Erstellung von Extents

Aus Gründen der Einfachheit sollten Sie in VMware-Umgebungen auf dem Speicher-Volume, das auf dem im Speicher-Array verfügbaren Device erstellt wurde, ein einzelnes Extent erstellen. In diesem Fall müssen die Standardeinträge des in der Abbildung gelb markierten Bereichs nicht geändert werden. In einem späteren Schritt können Benutzer ein einzelnes Extent erstellen, das sich über die gesamte Kapazität des Speicher-Volumes erstreckt. siehe Abb. 7.

Abb. 7: Festlegen der Kapazität eines Extents bei der Erstellung aus einem Speicher-Volume

Wie in Abb. 7 dargestellt, können die Benutzer, nachdem Sie auf „Next“ geklickt haben, den Konfigurationsvorschlag prüfen und den Plan ausführen. Im letzten Schritt werden die von EMC VPLEX durchgeführten Aufgaben geprüft. Die letzten beiden Schritte im Assistenten sind in Abb. 8 dargestellt.


Abb. 8: Erstellen von Extents mit dem VPLEX-Assistenten

Der nächste Schritt beim Speicher-Provisioning in einer VMware-Umgebung mit EMC VPLEX ist die Erstellung eines VPLEX-Devices auf Grundlage des im vorangegangenen Schritt erstellten Extents. Der Assistent für diesen Schritt kann von der Startseite des GUI-Management-Tools für EMC VPLEX aus aufgerufen werden. Durch Klicken auf den Link „Step 4: Create Devices from Extents“ (siehe Abb. 4) wird das in Abb. 9 dargestellte neue Popup-Fenster angezeigt.


Abb. 9: Erstellen von VPLEX-Devices mit einem Extent

Aus der Abbildung geht hervor, dass der Assistent die Möglichkeit zur Erstellung eines virtuellen Volumes mithilfe des VPLEX-Devices bietet (der in Abb. 9 gelb markierte Bereich). Dieses standardmäßig aktivierte Kontrollkästchen sollte nur bei der Planung virtueller Volumes mit mehreren Extents oder bei der Erstellung von Devices für VPLEX Metro-Umgebungen deaktiviert werden. Nach Möglichkeit sollte bei der Erstellung des virtuellen Volumes für VMware-Umgebungen auf eine 1:1-Zuordnung geachtet werden, d. h. ein separates virtuelles Volume für jedes Extent. Mit dieser Maßnahme soll die Infrastruktur so einfach wie möglich gehalten werden. Zur Demonstration des Assistenten zur Erstellung virtueller Volumes (siehe Abb. 9) wurde allerdings für das Beispiel in diesem White Paper ein VPLEX-Device erstellt, ohne ein virtuelles Volume zu erstellen.

Ein virtuelles Volume kann unter Zuhilfenahme von einem oder mehreren VPLEX-Devices erstellt werden. Der Assistent zur Erstellung virtueller Volumes ist in Abb. 10 dargestellt. Das im vorangegangenen Schritt erstellte VPLEX-Device erhält den Namen des Speicher-Volumes mit dem Präfix „device_“.

Abb. 10: Erstellen virtueller Volumes aus VPLEX-Devices

Wie bereits erläutert, kann das virtuelle Volume in der VMware-Virtualisierungsplattform durch die Erstellung einer Speicheransicht mit den Objekten „Registered initiators“, „VPLEX ports“ und „Virtual Volumes“ verfügbar gemacht werden. Hierfür muss zuerst die WWN der Initiatoren auf den VMware ESX-Servern in EMC VPLEX registriert werden. Durch Klicken auf den Link „Step 6: Register Initiators“ wird der in Abb. 11 dargestellte Bildschirm angezeigt.


Abb. 11: Liste der in EMC VPLEX registrierten und angemeldeten Initiatoren

Wenn sich die Initiatoren in der Zone der Front-End Ports von EMC VPLEX befinden, werden sie automatisch bei EMC VPLEX angemeldet. Wie in Abb. 11 dargestellt, werden diese Initiatoren mit dem Präfix „UNREGISTERED-“ und der WWPN des Initiators angezeigt. Initiatoren können allerdings auch manuell registriert werden, bevor sie in die Zone der Front-End Ports von VPLEX aufgenommen werden. Für diesen Vorgang wird die in Abbildung Abb. 11 grün hervorgehobene Schaltfläche verwendet. Die bei EMC VPLEX angemeldeten Initiatoren können wie folgt registriert werden: Markieren Sie den nicht registrierten Initiator, und klicken Sie auf die Schaltfläche „Register“. Siehe Abb. 12. Im vergrößerten Ausschnitt der Abbildung wird das Fenster angezeigt, das durch Klicken auf die Schaltfläche geöffnet wird. In der Abbildung ist auch zu erkennen, dass EMC VPLEX die Zuweisung eines anwenderfreundlichen Namens für den nicht registrierten Initiator und die Auswahl eines Host-Typs für den registrierten Initiator ermöglicht.


Abb. 12: Registrieren von VMware-HBAs in EMC VPLEX

Der letzte Schritt des Speicher-Provisionings für die VMware-Umgebung in EMC VPLEX besteht in der Erstellung der Speicheransicht. Rufen Sie hierfür auf der Startseite des VPLEX-Managementsystems den letzten Assistenten (Step 7: Create Storage Views) auf. In Abb. 13 ist das Fenster dargestellt, das bei der Auswahl des letzten Schritts geöffnet wird. Links im Fenster sind die Schritte zur Erstellung einer Speicheransicht aufgeführt. Der Assistent stellt der VMware-Virtualisierungsplattform die entsprechenden virtuellen Volumes über den definierten Satz von VPLEX-Front-End-Ports bereit. Der folgende Abschnitt „Überlegungen zur Konnektivität“ enthält die Empfehlung bezüglich der für die Anbindung von VMware ESX-Servern an EMC VPLEX zu verwendenden VPLEX-Ports.

Abb. 13: Assistent zur Erstellung von VPLEX-Speicheransichten


In Abb. 14 ist die mit dem Assistenten erstellte Speicheransicht dargestellt. Die WWN des über diese Ansicht verfügbaren virtuellen Volumes ist in der Abbildung hervorgehoben. Anhand dieser Informationen werden in der VMware-Virtualisierungsplattform die Devices identifiziert.

Abb. 14: Anzeigen von Details der Speicheransicht über die VPLEX-Managementoberfläche

Die Erkennung des neu bereitgestellten Speichers kann auf den VMware ESX-Servern durch ein erneutes Scannen des SCSI-Busses initiiert werden. Das Scan-Ergebnis ist in Abb. 15 dargestellt. Hier ist zu sehen, dass den VMware ESX-Server auf ein Device mit der WWN 6000144000000010a001b07360847619 zugreift. Durch einen schnellen Vergleich der WWN mit den in Abb. 14 grün hervorgehobenen Informationen wird bestätigt, dass das vom VMware ESX-Server erkannte Device tatsächlich das neu bereitgestellte virtuelle VPLEX-Volume ist. Laut Abbildung lautet die FC-Herstellerkennung (Organizationally Unique Identifier, OUI) für EMC VPLEX-Devices 00:01:44.


Abb. 15: Erkennen von neu bereitgestelltem VPLEX-Speicher auf einem VMware ESX-Server

Sobald das VPLEX-Device von den VMware ESX-Servern erkannt wurde, können diese zur Erstellung eines VMware-Dateisystems (Datastore) oder als RDM verwendet werden. Im Sinne einer optimalen Performance müssen die I/Os für EMC VPLEX jedoch an 64-KB-Blockgrenzen ausgerichtet sein. Außerdem gibt es in bestimmten Situationen bei einem Ausfall eine geringe Wahrscheinlichkeit beschädigter Daten, wenn es bei den I/Os an EMC VPLEX zu falschen Zuordnungen kommt. Daher müssen sämtliche I/Os zwischen Host-Betriebssystem und EMC VPLEX an einer 64-KB-Grenze ausgerichtet sein.

Das mit VMware Infrastructure Client bzw. vSphere Client erstellte VMware-Dateisystem sorgt automatisch für eine Ausrichtung der Dateisystemblöcke. Eine nicht richtig ausgerichtete Partition auf einem Gastbetriebssystem kann sich negativ auf die Performance auswirken und wie bereits zuvor erwähnt unter bestimmten Umständen zu einer Beschädigung von Daten führen. Daher müssen alle auf dem Gastbetriebssystem erstellten Partitionen (ganz gleich, ob auf einer virtuellen Festplatte eines VMware-Dateisystems oder einem RDM) auf ein Mehrfaches von 64 KB ausgerichtet sein.

Überlegungen zur Konnektivität EMC VPLEX steht für einen Paradigmenwechsel im Bereich von Speicherverbünden, der zu höherer Flexibilität, Performance und Verfügbarkeit führt. Im folgenden Abschnitt werden die Empfehlungen zum Anschluss von VMware ESX-Servern an EMC VPLEX erläutert. Mit der Einhaltung dieser Empfehlungen wird selbst bei abnormalen Vorgängen die höchstmögliche Konnektivität und Verfügbarkeit für die VMware-Virtualisierungsplattform sichergestellt.

Im Rahmen von Best Practices muss jeder VMware ESX-Server in der VMware vSphere- bzw. VMware Infrastructure-Umgebung mindestens zwei physische HBAs aufweisen, und jeder HBA muss an mindestens zwei Front-End Ports auf verschiedenen Directors von EMC VPLEX angeschlossen sein. Mit dieser Konfiguration können jederzeit sämtliche HBAs auf dem VMware ESX-Server verwendet werden, selbst wenn einer der Front-End Ports von EMC VPLEX aufgrund von Wartungsarbeiten oder ungeplanten Unterbrechungen ausfällt.


Wenn eine Konfiguration mit einer VPLEX-Engine an eine VMware vSphere- bzw. VMware Infrastructure-Umgebung angeschlossen wird, müssen sämtliche HBAs mit den Front-End Ports der Directors A und B der VPLEX-Engine verbunden werden. Die Verbindung mit den VPLEX-Front-End-Ports umfasst dabei Folgendes: zuerst den Anschluss eindeutiger Hosts an Port 0 des jeweiligen I/O-Moduls, das die Front-End Directors moduliert, und anschließend den Anschluss zusätzlicher Hosts an die verbliebenen Ports des I/O-Moduls. In Abb. 16 ist ein schematisches Beispiel der Verbindungen mit einer an eine einzelne VPLEX-Engine angeschlossenen VMware-Virtualisierungsplattform mit vier Nodes dargestellt.

Abb. 16: Anschließen eines VMware vSphere-Servers an einen VPLEX-Cluster mit einer Engine

Wenn wie in der mittleren und großen VPLEX-Cluster-Konfiguration mehrere VPLEX-Engines verfügbar sind, müssen die HBAs der VMware ESX-Server an unterschiedliche Engines angeschlossen werden. In Abb. 17 sind zum Beispiel die Verbindungen bei einem an einen VPLEX-Cluster mit zwei Engines angeschlossenen VMware ESX Server-Cluster mit vier Nodes dargestellt.

Sowohl in Abb. 16 als auch in Abb. 17 sind die Verbindungen zwischen den VPLEX-Engines und den Speicher-Arrays nicht dargestellt. Bei diesen Verbindungen sollten die Best-Practices-Empfehlungen für das Array beachtet werden. Eine detaillierte Erläuterung der Best Practices beim Anschluss des Back-End-Speichers würde den Rahmen dieses White Papers sprengen. Interessierte Leser seien auf folgendes TechBook verwiesen: EMC VPLEX Architecture and Deployment: Enabling the Journey to the Private Cloud.


Abb. 17: Anschließen von ESX-Servern an VPLEX-Cluster mit mehreren Engines

Wenn der VMware ESX-Server nach den in diesem Abschnitt besprochenen Best Practices an EMC VPLEX angeschlossen wird, stellt der VMware-Kernel vier Pfadverknüpfungen zu den einzelnen Devices im System her. In Abb. 18 sind die verfügbaren und vom VMware-Kernel für eines der Verbund-Devices in EMC VPLEX verwendeten Pfade dargestellt. Wie aus der Abbildung hervorgeht, kann der VMware-Kernel über einen der vier Pfade auf das Device zugreifen. Bei EMC VPLEX handelt es sich um ein Active Active Array, das einen gleichzeitigen Zugriff auf beliebige VPLEX-Devices von allen Front-End Ports aus ermöglicht. Dies wird vom VMware-Kernel automatisch erkannt; siehe grüne Hervorhebung in Abb. 18.


Abb. 18: VMware-Kernel-Pfade für ein VPLEX-Device

Die Verbindungen von den VMware ESX-Servern zum VPLEX-Cluster mit mehreren Engines können an eine steigende Anzahl von Engines angepasst werden. Bei den in diesem Abschnitt erläuterten Methoden geht es jeweils darum, sämtliche Front-End Ports zu nutzen und gleichzeitig ein Maximum an Performance und Lastausgleich für die VMware-Virtualisierungsplattform zu erzielen.

Multipathing und Lastausgleich Der VMware ESX-Server stellt systemeigene Channel-Failover-Funktionen bereit. Der ESX-Server für Active/Active-Speichersysteme weist standardmäßig jedem über SCSI angeschlossenen Device den ersten erkannten Pfad als bevorzugten Pfad mit „fester“ Failover Policy („Fixed“) zu. Dieser Pfad wird immer als aktiver Pfad für die I/O-Übertragung an dieses Device verwendet – es sei denn, der Pfad ist aufgrund eines geplanten oder ungeplanten Ereignisses nicht verfügbar. Die anderen vom VMware ESX-Server erkannten Pfade für das Device werden als passiver Failover-Pfad nur dann genutzt, wenn der aktive Pfad ausfällt. Daher stellen VMware ESX-Server automatisch sämtliche I/Os in die Wartschlange des ersten verfügbaren HBA im System. Der andere HBA hingegen wird erst dann aktiv genutzt, wenn der Ausfall des primären HBA festgestellt wird. Dieses Verhalten führt zu einer nicht ausgeglichenen Konfiguration zwischen ESX-Server und EMC VPLEX. Dieses Ungleichgewicht kann auf verschiedene Weise angegangen werden. Welche der in den folgenden Abschnitten erläuterte Methode am angemessensten ist, hängt von der Version des VMware ESX-Servers und der verwendeten Multipathing-Software ab.


VMware ESX Server Version 3 und statischer Lastausgleich In Version 3 von VMware ESX Server wird EMC VPLEX-Devices regelmäßig die Pfadmanagement-Policy des zuletzt verwendeten Pfads zugewiesen. Da es sich bei VPLEX um ein Active/Active-System handelt, muss sichergestellt werden, dass die Pfad-Failover-Policy auf „Fixed“ gesetzt ist. Zudem muss zum Lastausgleich und für Multipathing eine statische Zuweisung bevorzugter Alternativpfade zu den aus EMC VPLEX exportierten Devices durchgeführt werden. Entsprechend den Empfehlungen im vorangegangenen Abschnitt für die Anbindung von VMware ESX-Servern an EMC VPLEX muss jeder ESX-Server über mindestens vier separate Pfade verfügen. Mit diesem Ansatz sollten die Pfade des VMware-Dateisystems auf EMC VPLEX gleichmäßig auf die verfügbaren Ressourcen verteilt werden. Änderungen am bevorzugten Pfad müssen auf allen ESX-Servern, die auf die VPLEX-Devices zugreifen, vorgenommen werden.

Der bevorzugte Pfad kann entweder über die Befehlszeilenschnittstellen oder über VMware Infrastructure Client festgelegt werden. Ein Beispiel hierfür ist in Abb. 19 dargestellt. In Abb. 20 wird die Einstellung des bevorzugten Pfads für zwei Datastores dargestellt, die sich auf einem EMC VPLEX-Device befinden, das über die Front-End Ports A0-FC00, A1-FC00, B0-FC00 und B1-FC00 zu erreichen ist. Der bevorzugte Pfad für den zweiten Datenspeicher wurde geändert; es wird nun der zweite HBA verwendet.

Abb. 19: Festlegen des bevorzugten Pfads in VMware ESX Server Version 3

Abb. 20: EMC VPLEX-Devices mit statischem Lastausgleich unter ESX Server Version 3


VMware ESX Server Version 4 und NMP VMware ESX Server Version 4 verfügt mit den Policys „Fixed“, „Round Robin“ und „Most Recently Used“ über erweiterte Funktionen für Pfadmanagement und Lastausgleich. Die Standard-Policy des ESX-Kernels bei Active Active Arrays lautet „Fixed“. Bei den meisten Active Active Arrays wie EMC Symmetrix-Arrays ist das Rundlaufverfahren („Round-Robin“) jedoch die angemessenere Variante. Allerdings kann die Verwendung des einfachen Lastausgleichalgorithmus der Policy „Round-Robin“ zu Störungen der erweiterten Cache-Managementfunktionen von EMC VPLEX führen. Daher empfiehlt EMC beim Anschluss von VMware ESX Server Version 4 an EMC VPLEX die Verwendung der Policy „Fixed“ mit statischem Lastausgleich – also wie bei ESX Server Version 3. Darüber hinaus müssen die am bevorzugten Pfad vorgenommenen Änderungen auf allen ESX-Servern durchgeführt werden, die auf die VPLEX-Devices zugreifen.

Der bevorzugte Pfad kann in VMware ESX Server Version 4 mithilfe von vSphere Client festgelegt werden. In Abb. 21 ist dargestellt, wie der bevorzugte Pfad für eine physische Festplatte in einer VMware vSphere-Umgebung definiert wird. In Abb. 22 wird der bevorzugte Pfad für zwei Datastores festgelegt, die sich jeweils auf einem EMC VPLEX-Device befinden, das über die Front-End Ports A0-FC00, A1-FC00, B0-FC00 und B1-FC00 zu erreichen ist.

Abb. 21: Festlegen des bevorzugten Pfads in VMware ESX Server Version 4

Abb. 22: EMC VPLEX-Devices mit statischem Lastausgleich unter ESX Server Version 4


VMware ESX Server Version 4 mit PowerPath/VE EMC PowerPath®/VE bietet PowerPath-Multipathing-Funktionen zur Optimierung von virtuellen VMware vSphere-Umgebungen. Mit PowerPath/VE können Sie jetzt das Pfadmanagement in heterogenen physischen und virtuellen Umgebungen standardisieren. PowerPath/VE ermöglicht die Automatisierung einer optimalen Nutzung von Server, Speicher und Pfad in einer dynamischen virtuellen Umgebung. Durch Hyper-Konsolidierung können in einer virtuellen Umgebung Hunderte oder sogar Tausende unabhängiger virtueller Maschinen ausgeführt werden, und zwar sogar virtuelle Maschinen mit unterschiedlichem Grad an I/O-Intensität. I/O-intensive Anwendungen können zur Unterbrechung der I/O aus anderen Anwendungen führen, und vor der Einführung von PowerPath/VE musste der Lastausgleich auf einem ESX-Host-System daher – wie in vorangegangenen Abschnitten bereits erwähnt – manuell konfiguriert werden. Manuelle Lastausgleichsverfahren, mit denen sichergestellt wird, dass bei allen virtuellen Maschinen die jeweils erforderlichen individuellen Reaktionszeiten eingehalten wurden, nehmen äußerst viel Zeit in Anspruch und lassen sich logistisch nur schwer effizient umsetzen.

PowerPath/VE funktioniert zusammen mit VMware ESX und ESXi als Multipathing-Plug-In (MPP), das erweiterte Pfadmanagementfunktionen für ESX- und ESXi-Hosts bereitstellt. PowerPath/VE wird nur auf vSphere (ESX Server Version 4) unterstützt. Ältere ESX-Versionen verfügen nicht über die für PowerPath/VE erforderliche PSA.

PowerPath/VE wird als Kernel-Modul auf dem vSphere-Host installiert. Wie in Abb. 23 dargestellt, dient PowerPath/VE als Ergänzung zum vSphere-I/O-Stack-Framework und überträgt die erweiterten Multipathing-Funktionen – dynamischer Lastausgleich und automatisches Failover – auf die VMware vSphere-Plattform.

Abb. 23: PowerPath/VE-vStorage-API für Multipathing Plug-In

Kernstück des Pfadmanagements in PowerPath/VE ist die serverresidente Software, die zwischen der Schicht des SCSI-Device-Treibers und dem Rest des Betriebssystems eingefügt wird. Mit dieser Treibersoftware wird ein „Pseudo-Device“ für ein bestimmtes Array-Volume (LUN) erstellt, und zwar unabhängig von der Zahl der physischen Pfade, in denen es auftritt. Das Pseudo-Device (bzw. logische Volume) stellt sämtliche physischen Pfade zu einem bestimmten Device dar. Anschließend wird es zur Erstellung eines VMware-Dateisystems bzw. für die Raw-Device-Zuordnung (Raw Device Mapping, RDM) eingesetzt. Diese Einheiten können anschließend für den Anwendungs- und Datenbankzugriff verwendet werden.


Die besondere Bedeutung von PowerPath/VE liegt in der Architektur und der Position im I/O-Stack. PowerPath/VE ist über dem HBA angeordnet. Dies ermöglicht eine heterogene Unterstützung von Betriebssystemen und Speicher-Arrays. Durch die Integration in die I/O-Treiber laufen sämtliche I/Os über PowerPath. PowerPath kann somit als zentraler Punkt für I/O-Steuerung und -Management dienen. Da PowerPath/VE im ESX-Kernel untergebracht ist, befindet es sich unterhalb der Ebene des Gastbetriebssystems, der Datenbanken und des Dateisystems. Die einzigartige Position von PowerPath/VE im I/O-Stack prädestiniert das System für eine Rolle als Management- und Kontrollpunkt für die Infrastruktur. Damit geht eine Steigerung des Werts im Stack einher.

Funktionen von PowerPath/VE PowerPath/VE bietet die folgenden Funktionen:

• Dynamischer Lastausgleich: PowerPath ist so konzipiert, dass alle Pfade gleichzeitig genutzt werden. I/O-Anforderungen an ein logisches Device werden über alle verfügbaren Pfade verteilt, damit nicht ein einzelner Pfad die gesamte I/O-Last trägt.

• Automatische Pfadwiederherstellung: Durch eine periodisch durchgeführte automatische Wiederherstellung werden logische Devices bei der Pfadwiederherstellung nach einem Fehlerzustand neu zugewiesen. Nach der Wiederherstellung wird die I/O automatisch gleichmäßig über alle aktiven Kanäle neu verteilt.

• Device-Prioritäten: Die Einstellung einer hohen Priorität für einzelne oder mehrere Devices erhöht deren I/O-Performance auf Kosten der übrigen Devices. Es wird weiterhin versucht, die Last möglichst gleichmäßig auf die sonstigen Pfade zu verteilen. Diese Einstellung ist besonders hilfreich, wenn auf einem Host mehrere virtuelle Maschinen mit unterschiedlichen Anforderungen an die Anwendungs-Performance und die Verfügbarkeit vorhanden sind.

• Automatisische Performance-Optimierung: PowerPath/VE erkennt automatisch den Typ des Speicher-Arrays und wählt standardmäßig den besten Performance-Optimierungsmodus aus. Für VPLEX lautet der Standardmodus „Adaptive“.

• Dynamisches Pfad-Failover und dynamische Pfad-Recovery: Beim Ausfall eines Pfads sorgt PowerPath/VE für eine Neuverteilung des I/O-Datenverkehrs dieses Pfads auf die funktionierenden Pfade. Über den ausgefallenen Pfad wird keine I/O mehr gesendet, und es wird ein Alternativpfad gesucht. Wenn ein aktiver Pfad verfügbar ist, wird die I/O über diesen Pfad umgeleitet. PowerPath/VE kann verschiedene Ausfälle im I/O-Kanal kompensieren (z. B. den Ausfall von HBAs, Glasfaserkabeln, Fibre Channel Switches und Speicher-Array-Ports).

• Überwachung von I/O-Statistiken: PowerPath/VE sorgt nicht nur für einen I/O-Lastausgleich, sondern zeichnet auch die I/O-Statistiken für sämtliche Pfade auf. Diese Statistiken können vom Administrator über den Befehl rpowermt angezeigt werden.

• Automatischer Pfadtest: PowerPath/VE testet regelmäßig aktive und ausgefallene Pfade. Durch den Test von aktiven, im Leerlauf befindlichen Pfaden können Ausfälle bereits erkannt werden, bevor eine Anwendung versucht, I/O darüber zu senden. Die Pfade werden als ausgefallen gekennzeichnet, noch bevor der Ausfall in der Anwendung festgestellt wird. Dadurch kommt es zu weniger Verzögerungen infolge von Auszeiten und Wiederholversuchen. PowerPath/VE testet auch als ausgefallen markierte Pfade und stellt automatisch den Zustand der Dienstbereitschaft wieder her, wenn die Pfade den Test bestehen. Die I/O-Last wird automatisch auf alle aktiven und verfügbaren Pfade verteilt.

PowerPath/VE-Management Überwachung, Management und Konfiguration von PowerPath/VE für vSphere erfolgen in PowerPath/VE mit dem Befehlssatz rpowermt. Syntax, Argumente und Optionen sind den bekannten Befehlen aus dem bei allen anderen PowerPath-Betriebssystem-Plattformen mit Multipathing-Support verwendeten powermt sehr ähnlich. Der wesentliche Unterschied besteht darin, dass es sich bei rpowermt um ein Remote-Management-Tool handelt.


Nicht alle vSphere-Installationen verfügen über eine Schnittstelle zur Servicekonsole. Für das Management eines ESXi-Hosts benötigen die Kunden die Option zur Verwendung von vCenter Server bzw. vCLI (auch als VMware Remote Tools bezeichnet) auf einem Remote-Server. Bei PowerPath/VE für vSphere wird das Befehlszeilen-Dienstprogramm rpowermt für ESX und ESXi eingesetzt. PowerPath/VE für vSphere kann nicht auf dem ESX-Host selbst gemanagt werden. Es gibt weder eine lokale noch eine Remote-GUI für PowerPath auf ESX. Administratoren müssen ein Gastbetriebssystem auf einem physischen Rechner zuweisen, von dem aus ein oder mehrere ESX-Hosts gemanagt werden können. Das Dienstprogramm rpowermt wird unter Windows 2003 (32-Bit) und Red Hat 5 Update 2 (64-Bit) unterstützt.

Wenn der vSphere-Host-Server an EMC VPLEX angeschlossen ist, weist das PowerPath/VE-Kernel-Modul auf dem vSphere-Host jedem Device im Array sämtliche Pfade zu und vergibt einen Pseudo-Device-Namen (wie weiter oben erläutert). Ein Beispiel hierzu sehen Sie in Abb. 24. Dort ist das Ergebnis der Befehlseingabe rpowermt display host=x.x.x.x dev=emcpower11 dargestellt: Der Ausgabe ist zu entnehmen, dass das Device über vier Pfade verfügt, und es wird der Standardoptimierungsmodus für VPLEX-Devices (ADaptive) angezeigt. Wie in den vorangegangenen Abschnitten erläutert, kann in diesem Modus das erweiterte Cache-Kohärenz- und Managementsystem von EMC VPLEX nicht vollständig genutzt werden. EMC empfiehlt daher, die PowerPath-Management-Policy für alle VPLEX-Geräte von „ADaptive“ in „StreamIO“ (si) zu ändern. In Zukunft werden PowerPath-Algorithmen automatisch die angemessene Policy für die erkannten EMC VPLEX-Devices zuweisen.

Abb. 24: Ausgabe des Befehls rpowermt display auf einem VPLEX-Device

Die Pfadmanagement-Policy für VPLEX-Devices kann über den rpowermt-Befehl in „StreamIO“ geändert werden. In Abb. 25 ist der genaue Befehl dargestellt. Es wird auch die neue Policy angezeigt, die für das Device emcpower11 in Abb. 24 wirksam ist.

Abb. 25: Ändern der PowerPath/VE-Pfadmanagement-Policy für VPLE-Devices


In dem in Abb. 25 dargestellten Befehl wird die Policy mithilfe der Klassendefinition für VPLEX-Devices (Invista®) geändert. Im seltenen Fall, in dem auf die VMware-Virtualisierungsplattform über Invista- und VPLEX-Devices zugegriffen wird, muss die Änderung der Pfadmanagement-Policy für jedes Device einzeln vorgenommen werden. Weitere Informationen hierzu und zu den rpowermt-Befehlen und -Ausgaben finden Sie im PowerPath/VE for VMware vSphere Installation and Administration Guide auf Powerlink®.

In dem Maße, in dem zusätzliche VPLEX-Engines in einem Cluster verfügbar werden, kann die Konnektivität skaliert werden. PowerPath/VE unterstützt bis zu 32 Pfade zu einem Device. Durch diese Konnektivitätsmethode wird sichergestellt, dass alle Front-End Directors und Prozessoren genutzt werden. Dies ermöglicht maximale Performance und maximalen Lastausgleich für an EMC VPLEX angeschlossene vSphere-Hosts in Kombination mit PowerPath/VE.

Migration vorhandener VMware-Umgebungen in VPLEX Vorhandene Bereitstellungen von VMware-Virtualisierungsplattformen können in VPLEX-Umgebungen migriert werden. Dazu stehen eine Reihe von Alternativen zur Verfügung. Die einfachste Methode der Migration in eine VPLEX-Umgebung ist die Verwendung von Storage vMotion. Diese Methode ist jedoch nur dann praktikabel, wenn das Speicher-Array über eine für den größten Datastore in der VMware-Umgebung ausreichende Kapazität verfügt. Darüber hinaus ist die Arbeit in Storage vMotion sehr aufwändig, insbesondere wenn Hunderte von virtuellen Maschinen bzw. Terabyte konvertiert werden müssen, wenn auf den virtuellen Maschinen Snapshots vorhanden sind oder wenn die VMware-Virtualisierungsplattform über ESX Server Version 3.0 oder früher verfügt. In diesen Fällen empfiehlt es sich unter Umständen, die EMC VPLEX-Funktionen zur Kapselung vorhandener Devices einzusetzen. Bei dieser Methode sind jedoch geplante Unterbrechungen des Betriebs der VMware-Virtualisierungsplattform nicht zu vermeiden.

Unterbrechungsfreie Migrationen mit Storage vMotion In Abb. 26 werden die in VMware ESX Server Version 3.5 verfügbaren, mit vSphere vCenter Server gemanagten Datastores angezeigt. Die Ansicht ist über das Client-seitige EMC Virtual Storage Integrator-Plug-In verfügbar, mit dem die speicherbezogenen Informationen aus vSphere Client erweitert werden. Weitere Informationen zu EMC Virtual Storage Integrator finden Sie in der im Abschnitt „Quellennachweise“ aufgeführten Dokumentation.

Aus Abb. 26 geht hervor, dass sich die virtuelle Maschine „W2K8 VM1 (VI3)“ im Datenspeicher „DataStore_1“ auf Device „4EC“ in einem Symmetrix VMAX™-Array befindet. Im vergrößerten Ausschnitt ist die Version des ESX-Kernels (3.5, Build 153875) für Server 10.243.168.160 zu sehen.


Abb. 26: Anzeige von Details zum in EMC Storage Viewer angezeigten EMC Speichergerät

In Abb. 27 ist zu sehen, welche Devices auf dem ESX-Server verfügbar sind. Es gibt zwei Devices mit der Produktkennung „Invista“; weitere Details fehlen jedoch. Dies liegt daran, dass EMC Virtual Storage Integrator zum aktuellen Zeitpunkt noch nicht in der Lage ist, die in EMC VPLEX verfügbaren Devices aufzulösen. In der Abbildung sind auch die NAA-Nummern der Devices aufgeführt. Wie bereits erwähnt, steht FC-OUI 00:01:44 für EMC VPLEX-Devices. Daher kann der Abbildung entnommen werden, dass der VMware ESX-Server mit Devices aus den EMC Symmetrix VMAX-Arrays und EMC VPLEX angezeigt wird.

Abb. 27: Anzeige von EMC VPLEX-Devices in einem VMware ESX Server-Cluster


Die Migration von Daten von den Symmetrix VMAX-Arrays zum in VPLEX verfügbaren Speicher kann mithilfe von Storage vMotion erfolgen, nachdem auf den in VPLEX verfügbaren Devices geeignete Datastores erstellt wurden. In Abb. 28 sind die Schritte zum Start der Migration einer virtuellen Maschine von Datastore_1 zum Zieldatenspeicher Target_1 auf einem VPLEX-Device dargestellt. Das Migrationsverfahren wurde in ESX Server Version 3.5 demonstriert. Es trifft jedoch auch auf ESX-Server zu, auf denen ESX Server, Version 4.0 und höher, ausgeführt wird. Darüber hinaus ist zu beachten, dass der in Abb. 28 dargestellte Migrationsassistent nur bei Nutzung von vCenter Server, Version 4.0 und höher, verfügbar ist. Die Funktionalität von Storage vMotion ist nur über das Befehlszeilen-Dienstprogramm für vCenter Server Version 2.5 verfügbar. Eine ausführliche Erläuterung von Storage vMotion würde den Rahmen dieses White Papers sprengen. Weitere Informationen zu Storage vMotion finden Sie in der im Abschnitt „Quellennachweise“ aufgeführten Dokumentation.

Abb. 28: Verwendung von Storage vMotion zur Migration virtueller Maschinen zu VPLEX-Devices

Migration mit Kapselung vorhandener Devices Wie bereits erläutert, bietet Storage vMotion zwar die Möglichkeit einer unterbrechungsfreien Migration von einer vorhandenen VMware-Bereitstellung zu EMC VPLEX, aber in der Praxis ist diese Möglichkeit nicht immer durchführbar. In diesen Fällen können die EMC VPLEX-Kapselungsfunktionen genutzt werden. Das Verfahren ist allerdings nicht unterbrechungsfrei. Die Dauer der Unterbrechung kann durch eine ordnungsgemäße Planung und Ausführung jedoch so gering wie möglich gehalten werden.


Zur Kapselung und Migration einer vorhandenen VMware-Bereitstellung müssen die folgenden vorbereitenden Schritte ausgeführt werden.

1. Die Back-End Ports von EMC VPLEX müssen per Zoning den Front-End Ports des Speicher-Arrays zugeordnet werden, in dem derzeit die Speicherressourcen bereitgestellt werden.

2. Im nächsten Schritt muss das LUN-Masking im Speicher-Array geändert werden, damit EMC VPLEX Zugriff auf die Devices erhält, die die VMware-Datastores hosten. Im Beispiel aus dem vorangegangenen Abschnitt müssen die Devices 4EC (für Datastore_1) und 4F0 (für Datastore_2) gegenüber EMC VPLEX maskiert werden.

In Abb. 29 werden die Devices angezeigt, die nach den Änderungen beim Masking und nach einem erneuten Scan des Speicher-Arrays in EMC VPLEX sichtbar sind. Außerdem ist die SYMCLI-Ausgabe der Symmetrix VMAX-Devices mit den entsprechenden WWNs aufgeführt. Bei einem schnellen Vergleich wird deutlich, dass EMC VPLEX Zugriff auf die Devices mit den zu kapselnden Datastores hat.

Abb. 29: Erkennen von in EMC VPLEX zu kapselnden Devices

3. Sobald die Devices in EMC VPLEX angezeigt werden, müssen sie beansprucht werden. Dieser Schritt ist in Abbildung 30 dargestellt. Mit dem Flag „-appc“ wird während des Beanspruchungsvorgangs sichergestellt, dass der Inhalt des beanspruchten Devices erhalten bleibt und dass das Device zur weiteren Verwendung in EMC VPLEX gekapselt wird.


Abbildung 30: Kapseln von Devices in EMC VPLEX unter Beibehaltung vorhandener Daten

4. Nach der Beanspruchung der Devices muss ein einzelnes Extent erstellt werden, das sich über die gesamte Festplatte erstreckt. In Abb. 31 ist dieser Schritt für die beiden Datastores dargestellt, die in diesem Beispiel gekapselt werden.

Abb. 31: Erstellen von Extents auf gekapselten, von VPLEX beanspruchten Speicher-Volumes

5. Mit dem im vorangegangenen Schritt erstellten Extent muss ein (lokales) VPLEX-Device mit einem RAID-1-Laufwerk erstellt werden. Dieser Vorgang ist in Abb. 32 für die beiden Datenspeicher Datastore_1 und Datastore_2 auf den Devices 4EC und 4F0 dargestellt. Der Schritt muss für alle Speicher-Array-Devices wiederholt werden, die gekapselt und in der VMware-Umgebung bereitgestellt werden müssen.


Abb. 32: Erstellen eines mit RAID 1 geschützten VPLEX-Devices auf gekapselten VMAX-Devices

6. Auf jedem im vorangegangenen Schritt erstellten VPLEX-Device muss ein virtuelles Volume erstellt werden. Dieser Vorgang ist in Abb. 33 für die VMware-Datenspeicher Datastore_1 und Datastore_2 dargestellt.

Abb. 33: Erstellen virtueller Volumes in VPLEX für die VMware-Virtualisierungsplattform

7. In EMC VPLEX kann eine Speicheransicht durch manuelle Registrierung der WWN der HBAs auf den VMware ESX-Servern erstellt werden, die der VMware-Virtualisierungs-Domain angehören. Die Speicheransicht muss vorab erstellt werden, damit die VMware-Virtualisierungsplattform auf die in Schritt 6 erstellten virtuellen Volumes zugreifen kann. Hierdurch kann die Serviceunterbrechung während des Wechsels vom ursprünglichen Speicher-Array zu EMC VPLEX so gering wie möglich gehalten werden. Ein Beispiel dieses Schritts aus der in dieser Studie verwendeten Umgebung sehen Sie in Abb. 34.


Abb. 34: Erstellen einer Speicheransicht zur Darstellung gekapselter Devices für VMware ESX-Server

8. Parallel zu den in EMC VPLEX durchgeführten Vorgängen müssen neue Zonen erstellt werden, in denen die an der Migration beteiligten VMware ESX-Server auf die Front-End Ports von EMC VPLEX zugreifen. Diese Zonen müssen dem entsprechenden Zone Set hinzugefügt werden. Darüber hinaus müssen die Zonen aus dem Zone Set entfernt werden, in denen der VMware ESX-Server auf das Speicher-Array zugreift, dessen Devices gekapselt werden. Das geänderte Zone Set darf jedoch nicht aktiviert werden, bevor das Wartungsfenster für die virtuellen VMware-Maschinen geschlossen werden kann.

9. Bei geöffnetem Wartungsfenster müssen zuerst sämtliche virtuellen Maschinen ordnungsgemäß heruntergefahren werden, die von der Migration betroffen wären. Dies kann über VMware Infrastructure Client, vSphere Client oder auf VMware SDK basierende Befehlszeilen-Dienstprogramme erfolgen.

10. Die im VPLEX-System angezeigten Devices dienen als Host für den ursprünglichen Datastore. Allerdings mounten die VMware ESX-Hosts Datastores nicht automatisch, da VMware ESX Datastores als Snapshot betrachtet, weil die WWN der über das VPLEX-System verfügbaren Devices nicht mit der WWN der im Symmetrix VMAX-System angezeigten Devices übereinstimmt.

Mit VMware vSphere können Datastores, die als Snapshots betrachtet werden, für jedes Device einzeln neu signiert werden. Hiermit wird das Risiko des versehentlichen erneuten Signierens der gekapselten Devices des VPLEX-Systems reduziert. Durch die Verwendung von persistentem Mounten ergeben sich auch andere Vorteile wie die Speicherung der Historie sämtlicher virtueller Maschinen. Im Sinne einer homogenen vSphere-Umgebung empfiehlt EMC die Verwendung persistenter Mount-Vorgänge für in VPLEX gekapselte VMware-Datastores. Bei VMware-Umgebungen mit VMware ESX Version 3.5 oder früher muss dieser Schritt übersprungen werden.

Aktivieren Sie das in Schritt 8 erstellte Zone Set. Durch einen erneuten manuellen Scan des SCSI-Bus auf den VMware ESX-Servern sollten die ursprünglichen Devices entfernt und die über das VPLEX-System verfügbaren gekapselten Devices dargestellt werden.

In Abb. 35 ist ein Beispiel aus einer VMware vSphere-Umgebung dargestellt. Wie in der Abbildung zu sehen, werden sämtliche ursprünglichen virtuellen Maschinen in der Umgebung nun als nicht verfügbar markiert. Dies liegt daran, dass die auf den Devices


im VMAX-System erstellten Datenspeicher Datastore_1 und Datastore_2 nicht mehr verfügbar sind.

Abb. 35: Erneutes Scannen des SCSI-Bus auf den VMware ESX-Servern

In der nächsten Abbildung sind die Ergebnisse nach dem persistenten Mounten der von EMC VPLEX bereitgestellten Datastores dargestellt. Nun sind alle virtuellen Maschinen wieder verfügbar, auf die zuvor nicht zugegriffen werden konnte. Beim persistenten Mounten der als Snapshots betrachteten Datastores bleiben sowohl die UUID des Datastores als auch die Bezeichnung erhalten. Da auf die virtuellen Maschinen mittels der UUID der Datastores verwiesen wird, kann vCenter Server durch das persistente Mounten die zuvor als nicht zugänglich betrachteten virtuellen Maschinen wieder erkennen.

Die folgenden Schritte 11 bis 14 gelten nicht für homogene vSphere-Umgebungen.


Abb. 36: Persistentes Mounten von Datastores auf gekapselten VPLEX-Devices

11. Wenn in der VMware-Umgebung ESX Server, Version 3.5 oder früher, verwendet wird (selbst wenn das Management über VMware vCenter Server Version 4 erfolgt), empfiehlt sich das erneute Signieren der von EMC VPLEX bereitgestellten gekapselten Devices. Diese Empfehlung beruht auf der Tatsache, dass das Verfahren zum erneuten Signieren von als Snapshots betrachteten Devices in diesen Versionen von VMware ESX Server weder auf bestimmte Devices beschränkt ist noch rückgängig gemacht werden kann. In VMware ESX Server, Version 4.0 und höher, ist bei als Snapshots betrachteten Devices ein selektives erneutes Signieren möglich.

Die in den Datastores gehosteten virtuellen Maschinen müssen aus dem vCenter Server-Bestand entfernt werden. Dies kann über Virtual Infrastructure Client, vSphere Client oder auf VMware SDK basierende Befehlszeilen-Dienstprogramme erfolgen. Bei einer Aufhebung der Registrierung der virtuellen Maschinen werden sämtliche Verlaufsinformationen hierzu aus der Virtual Center-Datenbank gelöscht.

12. Ändern Sie zum erneuten Signieren der Datastores und zur Aktivierung des in Schritt 8 erstellten Zone Sets auf einem der VMware ESX-Hosts das Flag „LVM.EnableResignature“ der erweiterten Einstellungen.

Das in Schritt 0 erstellte Zone Set muss zu diesem Zeitpunkt aktiviert sein. Durch einen erneuten manuellen Scan des SCSI-Bus auf den VMware ESX-Servern sollten die ursprünglichen Devices entfernt und die über EMC VPLEX verfügbaren gekapselten Devices dargestellt werden.

In Abb. 37 sind die Datastores nach Abschluss der erneuten Signierung dargestellt. Die ursprüngliche Bezeichnung der Datastores wurde mit dem Präfix snap- versehen.


Abb. 37: Erneutes Signieren von Datastores auf gekapselten VPLEX-Devices

13. Nachdem die VPLEX-Devices erkannt und die VMware-Datastores erneut signiert wurden, muss der erweiterte Parameter „LVM.EnableResignature“ auf 0 gesetzt werden.

14. Die virtuellen Maschinen, deren Registrierung in Schritt 8 aufgehoben wurde, können dem vCenter Server-Bestand über Virtual Infrastructure Client, vSphere Client oder auf VMware SDK basierende Befehlszeilen-Dienstprogramme wieder hinzugefügt werden. Ein Beispiel hierzu sehen Sie in Abb. 38.


Abb. 38: Hinzufügen virtueller Maschinen aus erneut signierten VPLEX-Devices zu vCenter Server

15. Nach der ordnungsgemäßen Identifizierung bzw. Registrierung können die virtuellen Maschinen aktiviert werden.

Im oben beschriebenen Verfahren wurde für Managementaufgaben bei EMC VPLEX die VPLEX-Befehlszeilenschnittstelle verwendet. Dieselben Vorgänge können jedoch auch über die grafische Managementoberfläche von VPLEX durchgeführt werden.

VMware-Bereitstellungen in einer VPLEX Metro-Umgebung EMC VPLEX überwindet physische Grenzen von Rechenzentren und ermöglicht Benutzern den gleichzeitigen Zugriff auf Daten von verschiedenen Standorten aus.1 Diese Funktionen waren im VMware-Kontext bislang nicht verfügbar. Insbesondere die Möglichkeit zum gleichzeitigen Zugriff auf die gleichen Devices unabhängig vom physischen Standort ermöglicht die Einrichtung geographisch weit verzweigter Cluster auf Grundlage der VMware-Virtualisierungsplattform.2 Durch diese Funktion wird ein transparenter Lastausgleich zwischen mehreren Standorten möglich. Gleichzeitig besteht die Flexibilität zur Migration von Workloads zwischen Standorten im Vorfeld geplanter Ereignisse wie der Wartung von Hardware. Darüber hinaus können bei einer Serviceunterbrechung in einem Rechenzentrum aufgrund von ungeplanten Ereignissen die ausgefallenen Services am noch aktiven Standort mit minimalem Aufwand schnell und problemlos neu gestartet werden. Dennoch müssen beim Design der VMware-Umgebung einige potenzielle Fehlerszenarien berücksichtigt und die Risiken einer Serviceunterbrechung verringert 1 Die VPLEX-Architektur ist auf die Unterstützung des gleichzeitigen Zugriffs von mehreren Standorten aus ausgerichtet. In der ersten Version wird jedoch nur eine Konfiguration an zwei Standorten in synchroner Entfernung unterstützt. 2 Für diese Lösung ist eine Ausdehnung des VLAN auf mehrere physische Rechenzentren erforderlich. Hierfür können Technologien wie Cisco Overlay Transport Virtualization (OTV) eingesetzt werden.


werden. In den folgenden Absätzen werden die Best Practices für den Entwurf der optimalen VMware-Umgebung erläutert. Weitere Informationen zur Konfiguration von EMC VPLEX Metro finden Sie im TechBook EMC VPLEX Architecture and Deployment: Enabling the Journey to the Private Cloud auf Powerlink.

VMware-Cluster-Konfiguration Ein VMware-HA-Cluster bestimmt mit einem Heartbeat, ob die anderen Nodes im Cluster erreichbar sind und auf Anforderungen reagieren. Bei einem Ausfall der Kommunikation bestimmt die VMware-HA-Software auf dem VMware ESX-Server in der Regel unter Zuhilfenahme des Standard-Gateways für den VMware-Kernel, ob eine Isolierung vorgenommen werden soll. Diese Vorgehensweise ist notwendig, weil es sich programmgesteuert nicht feststellen lässt, ob ein Kommunikationsabbruch auf einen Server- oder einen Netzwerkausfall zurückzuführen ist.

Das gleiche grundlegende Problem – die Frage, ob ein Konnektivitätsausfall zwischen den Nodes der VPLEX-Cluster auf einen Netzwerk- oder einen Standortfehler zurückzuführen ist – gilt für räumlich getrennte VPLEX-Cluster. Ein Netzwerkausfall führt bei EMC VPLEX gemäß festgelegter Regeln zu einem automatischen Abbruch des gesamten I/O an die Devices („Trennung“) an einem der beiden Standorte. Die I/O-Vorgänge zwischen dem anderen Standort und dem Device werden ganz normal fortgesetzt. Da die Regeln einzeln auf Devices angewendet werden, kann es darüber hinaus vorkommen, dass bei einer Netzwerkaufteilung an beiden Standorten aktive Devices vorhanden sind. Die Auferlegung der Regeln zur Minimierung der Auswirkungen von Netzwerkunterbrechungen macht sich beim Ausfall eines Standorts bemerkbar. In diesem Fall setzt der VPLEX-Cluster gemäß den Regeln zur Bestimmung des Standorts, der bei einem Kommunikationsausfall getrennt wird, am noch intakten Standort automatisch die I/O zu einigen der Devices am noch funktionierenden Standort aus. Daher bietet die VPLEX-Software die Möglichkeit, I/Os zu den getrennten Devices manuell wieder aufzunehmen. Eine ausführlichere Erläuterung der einzelnen Verfahren würde den Rahmen dieses White Papers sprengen. Weitere Informationen zu EMC VPLEX Metro finden Sie im TechBook EMC VPLEX Architecture and Deployment: Enabling the Journey to the Private Cloud.

In Abb. 39 ist die empfohlene Cluster-Konfiguration für VMware-Bereitstellungen mit über EMC VPLEX Metro zur Verfügung gestellten Devices dargestellt. Aus der Abbildung geht hervor, dass die VMware-Virtualisierungsplattform in zwei separate VMware-Cluster aufgeteilt ist. Die einzelnen Cluster umfassen die VMware ESX-Server an jedem physischen Rechenzentrum (Standort A und B). Beide VMware-Cluster werden jedoch in einer einzelnen Rechenzentrumseinheit gemanagt, die die logische Kombination mehrerer an der Lösung beteiligter physischer Standorte darstellt. Im vergrößerten Bereich der Abbildung sind die Einstellungen der einzelnen Cluster zu sehen. VMware DRS und VMware HA sind in jedem Cluster aktiv. Dadurch ist der Einsatzbereich dieser Komponenten der VMware-Lösung auf einen einzelnen physischen Standort begrenzt.


Abb. 39: Konfiguration von VMware-Clustern mit Devices aus EMC VPLEX Metro

Obwohl in Abb. 39 nur zwei VMware-Cluster abgebildet sind, können die VMware ESX-Server an den einzelnen physischen Standorten in mehrere VMware-Cluster unterteilt werden. Mit der empfohlenen Konfiguration wird das Ziel verfolgt, bei den an verschiedenen Standorten befindlichen ESX-Servern eine Vermischung in einem VMware-Cluster-Objekt zu verhindern.

Die in der logischen Darstellung der verbundenen physischen Rechenzentren (Standort A und B) aufgeführten VMware-Datenspeicher sind in Abb. 40 dargestellt. Aus der Abbildung geht hervor, dass in beiden Rechenzentren eine Reihe von VMware-Datastores verfügbar sind.3 Aus diesem Grund wirkt sich die logische Trennung der VMware DRS- und VMware HA-Domains in keiner Weise auf die Fähigkeit in VMware vCenter Server aus, eine transparente Migration der virtuellen Maschinen im Cluster des jeweiligen Standorts zum jeweils anderen Standort durchzuführen (siehe folgenden Abschnitt). Aus der Abbildung geht auch hervor, dass eine VPLEX Metro-Konfiguration nicht unbedingt die Replikation sämtlicher in EMC VPLEX Metro erstellter virtueller Volumes an allen physischen Standorten von Rechenzentren erfordert.4 Virtuelle Maschinen,

3 Die Erstellung eines gemeinsamen Datastores, der für VMware ESX-Server an beiden Standorten zugänglich ist, wird durch die Erstellung eines verteilten Devices in EMC VPLEX Metro ermöglicht. Eine ausführliche Erläuterung der Vorgehensweisen zur Erstellung verteilter Devices würde den Rahmen dieses White Papers sprengen. Weitere Informationen finden Sie im TechBook EMC VPLEX Architecture and Deployment: Enabling the Journey to the Private Cloud. 4 Es ist möglich, VMware-Clustern an beiden Standorten ein nicht repliziertes virtuelles Volume zu präsentieren. In einer solchen Konfiguration, in der die I/O-Aktivität, die am Standort ohne Datenkopie generiert wird, nicht im Cache des VPLEX-Cluster am Standort gespeichert wird, genügt es, dass das Speicher-Array das virtuelle Volume hostet. Eine derartige Konfiguration kann erhebliche Performance-Einbußen nach sich ziehen. Außerdem sind die Kundendaten im Falle unvorhergesehener Ereignisse am Standort mit der Replikation des Speicher-Arrays und bei einer einmaligen Migration virtueller Maschinen zwischen Rechenzentren nicht geschützt.


die in Datastores gehostet werden, welche mit einer einzelnen Datenkopie in virtuellen Volumes gekapselt sind und dem VMware-Cluster an diesem Standort bereitgestellt werden, sind allerdings an diesen Standort gebunden und können nicht unterbrechungsfrei zum zweiten Standort migriert werden. Ein Schutz vor ungeplanten Ereignissen besteht jedoch. Die Notwendigkeit zum Hosten einer Gruppe virtueller Maschinen auf nicht replizierten virtuellen Volumes kann auf verschiedenen Gründen beruhen, beispielsweise der besonderen geschäftlichen Bedeutung der auf diesen Datastores gehosteten virtuellen Maschinen.

Abb. 40: Speicheransicht der den VMware-Clustern bereitgestellten Datastores

Abb. 41 zeigt ein breiteres Bild der Informationen in Abb. 40. Diese Abbildung enthält Informationen zu den virtuellen Maschinen und den Datastores der in dieser Studie verwendeten Konfiguration. Aus der Abbildung geht hervor, dass ein Datastore virtuelle Maschinen an einem einzigen physischen Standort hostet. Außerdem ist die WWN des SCSI-Devices dargestellt, auf dem der Datastore „Distributed_DSC_Site_A“ gehostet wird. Die Konfiguration des virtuellen VPLEX Metro-Volumes mit der in Abb. 41 angezeigten WWN geht aus Abb. 42 hervor. Hier wird ersichtlich, dass das virtuelle Volume in die Hosts des VMware-Clusters an Standort A exportiert wird.


Abb. 41: Darstellung der in dieser Studie verwendeten Datastores und virtuellen Maschinen


Abb. 42: Einzelheiten zu einem in einer VMware-Umgebung bereitgestellten Metro-Plex-Volume

In Abb. 43 sind die Regeln dargestellt, die für das virtuelle Volume durchgesetzt werden, auf dem der Datastore „Distributed_DSC_Site_A“ gehostet ist. Aus der Abbildung geht hervor, dass die Regeln so eingestellt sind, dass im Falle einer Netzwerkaufteilung die I/Os an Standort B ausgesetzt werden. Daher sind die im Datastore „Distributed_DSC_Site_A“ gehosteten virtuellen Maschinen hiervon bei einer Netzwerkaufteilung nicht betroffen. Gleichermaßen sorgen die Regeln bei den virtuellen Maschinen an Standort B dafür, dass die I/Os an diese Datastores im Falle einer Netzwerkaufteilung nicht betroffen sind.

Abb. 43: Anzeigen von Trennungsregeln auf verteilten VPLEX-Devices


Unterbrechungsfreie Migration virtueller Maschinen mit vMotion Ein Beispiel der Migration aktiver virtueller Maschinen zwischen dem Cluster und somit zwischen physischen Rechenzentren ist in Abb. 44 dargestellt. Aus der Abbildung geht klar hervor, dass aus der Perspektive von VMware vCenter Server der physische Standort der Rechenzentren bei der Funktion zum Transfer aktiver Workloads zwischen von EMC VPLEX Metro unterstützten Standorten keine Rolle spielt.

Abb. 44: vCenter Server ermöglicht die Live-Migration virtueller Maschinen zwischen Standorten

Abb. 45 zeigt einen Snapshot der unterbrechungsfreien Migration einer virtuellen Maschine zwischen zwei Standorten. In der Abbildung ist auch die Konsole der virtuellen Maschine während der Migration dargestellt. Während des Vorgangs sind keine Auswirkungen auf diese virtuelle Maschine zu beobachten.


Abb. 45: Fortschritt einer vMotion-Migration zwischen zwei physischen Standorten

Aus den oben erläuterten Gründen empfiehlt EMC dringend, keine einzelne virtuelle Maschine zwischen zwei Standorten zu migrieren. Eine Teilmigration der virtuellen Maschinen in einem Datastore kann im Fall einer Netzwerkaufteilung zu unnötigen Serviceunterbrechungen führen. Beispielsweise sorgen nach einer erfolgreichen Migration der virtuellen Maschine IOM02 (siehe Abb. 44 und Abb. 45) die auf den Devices im Datastore geltenden Regeln für eine Aussetzung der I/O an dem Standort, an dem die migrierte virtuelle Maschine ausgeführt wird. Die Aussetzung der I/Os führt zu einem sofortigen Abbruch der von IOM02 bereitgestellten Services. Um derartige Ereignisse zu vermeiden, empfiehlt EMC die Migration aller virtuellen Maschinen in einem Datastore und eine anschließende Änderung der geltenden Regeln für die Devices, auf denen sich der betroffene Datastore befindet. Dabei muss sichergestellt werden, dass die an das Device gesendeten I/Os an dem Standort fortgesetzt werden, an dem die Migration erfolgte.

Ändern der Konfiguration nicht replizierter VPLEX Metro-Volumes Wie in den vorangegangenen Absätzen erwähnt, schränkt EMC VPLEX Metro die Konfiguration des vom Cluster exportierten virtuellen Volumes nicht ein. Bei einer VPLEX Metro-Konfiguration kann eine Kombination aus nicht replizierten und replizierten virtuellen Volumes exportiert werden. Welche Art von virtuellem Volume konfiguriert werden muss, ergibt sich meist aus geschäftlichen Anforderungen. Wenn sich die geschäftlichen Anforderungen ändern, kann die Konfiguration des virtuellen Volumes, auf dem die virtuellen Maschinen gehostet werden, ohne Unterbrechung in ein repliziertes virtuelles Volume geändert werden, das mehreren VMware-Clustern an unterschiedlichen physischen Standorten für den gleichzeitigen Zugriff zur Verfügung steht.


In Abb. 46 ist der Datenspeicher „Conversion_Datastore“ dargestellt, der zurzeit nur in einem Cluster verfügbar ist, das an einem Standort gehostet wird (in diesem Fall Standort A). Aus diesem Grund können die virtuellen Maschinen in diesem Datastore erst dann unterbrechungsfrei zum zweiten Standort in der VPLEX Metro-Konfiguration5 migriert werden, wenn der Remote-Zugriff für das Device aktiviert wird, auf dem der Datastore „Conversion_Datastore“ erstellt wurde, oder wenn die Konfiguration des VPLEX-Devices in ein verteiltes Device mit Datenkopien an beiden Standorten konvertiert wurde.

Abb. 46: An Einzelstandort in einer Metro-Plex-Konfiguration verfügbarer VMware-Datastore

In Abb. 47 ist die Konfiguration des virtuellen Volumes dargestellt, auf dem sich der Datastore befindet. Aus der Abbildung ist ersichtlich, dass das virtuelle Volume ein einzelnes Device enthält, das am gleichen Standort verfügbar ist. Wenn es aufgrund geänderter geschäftlicher Anforderungen notwendig wird, den Datastore zu replizieren und an beiden Standorten verfügbar zu machen, kann die Konfiguration einfach geändert werden, falls am zweiten Standort (demjenigen ohne Kopie der Daten) ausreichend physischer Speicher vorhanden ist.

5 Mit Technologien wie Storage vMotion kann die virtuelle Maschine zu einem virtuellen VPLEX Metro-Volume migriert werden, das repliziert wird und an beiden Standorten verfügbar ist. So können virtuelle Maschinen unterbrechungsfrei zwischen Standorten migriert werden. Diese Verfahrensweise bedeutet jedoch unnötige zusätzliche Komplexität. Dennoch kann dieses Verfahren für die Migration virtueller Maschinen verwendet werden, bei denen der Overhead der synchronen Replikation vermieden werden muss.


Abb. 47: Einzelheiten zu einem nicht replizierten virtuellen Metro-Plex-Volume

Im Folgenden wird erläutert, wie ein nicht repliziertes und in einem virtuellen Volume gekapseltes Device konvertiert und anschließend an einem zweiten Standort repliziert und dem VMware-Cluster bereitgestellt wird. Die Vorgehensweise gliedert sich in vier Schritte:

1. Erstellen Sie ein Device an dem Standort, an dem sich die Kopie der Daten befinden soll. Die in Abb. 48 dargestellte Vorgehensweise zur Erstellung eines Devices ist unabhängig vom Host-Betriebssystem und wurde im Abschnitt „Bereitstellung von VPLEX-Speicher in VMware-Umgebungen“ erläutert.

Abb. 48: Erstellen eines Devices in EMC VPLEX über die GUI

2. Der nächste Schritt besteht in der Hinzufügung des neu erstellten Devices als Spiegel des vorhandenen Devices, das geographisch geschützt werden soll. Dies ist in Abb. 49 dargestellt. Wie der vorangegangene Schritt ist auch dieser Schritt unabhängig vom Host-Betriebssystem, das die mit den Devices erstellten virtuellen Volumes nutzt.


Abb. 49: Ändern der Art des Schutzes eines VPLEX-Devices von RAID 0 in verteiltes RAID 1

3. Erstellen oder ändern Sie das LUN-Masking in EMC VPLEX Metro, um bei den an die Nodes am zweiten Standort angeschlossenen VMware ESX-Servern den Zugriff auf das virtuelle Volume mit den replizierten Devices zu aktivieren. Die Ergebnisse dieses Schritts sind in Abb. 50 dargestellt.


Abb. 50: Erstellen einer Ansicht zur Bereitstellung des virtuellen VPLEX-Volumes am zweiten Standort

4. Das neu exportierte virtuelle VPLEX-Volume mit den replizierten Devices muss im VMware-Cluster am zweiten Standort erkannt werden. Die Vorgehensweise hierfür ist mit dem Hinzufügen eines SCSI-Devices in einem VMware-Cluster identisch. Abb. 51 zeigt, dass der replizierte Datastore nun nach einem erneuten Scan des SCSI-Bus in beiden VMware-Clustern an Standort A und B verfügbar ist.

Abb. 51: Anzeigen von VMware ESX-Servern mit Zugriff auf einen Datastore

Virtualisierte vCenter Server-Instanzen in VPLEX Metro VMware unterstützt virtualisierte Instanzen von vCenter Server, Version 4.0 oder höher. Die Ausführung von vCenter Server und der zugehörigen Komponenten auf einer virtuellen Maschine bietet Kunden größtmögliche Flexibilität und höchsten Komfort, da die Vorteile eines virtuellen Rechenzentrums von allen Komponenten in einer VMware-Bereitstellung genutzt werden können. In einer EMC VPLEX Metro-Umgebung kann eine unüberlegte vCenter Server-Bereitstellung auf einer virtuellen Maschine im Falle eines Standortausfalls erhebliche Probleme verursachen. Dies gilt insbesondere, wenn vCenter Server für das Management der ebenfalls auf dem gleichen EMC VPLEX Metro-Cluster bereitgestellten VMware-Umgebungen verwendet wird.


Wie bereits erläutert, setzt EMC VPLEX bei einem Standortausfall bzw. einer Netzwerkaufteilung zwischen den Standorten automatisch sämtliche I/Os an einem Standort aus. An welchem Standort dies geschieht, hängt von den beim Auftreten des Ereignisses aktiven Regeln ab. Dieses Verhalten kann zu einer Erhöhung des RTO bei einem Standortausfall führen, wenn sich VMware vCenter Server auf einem verteilten EMC VPLEX-Volume befindet, das an beiden Standorten repliziert wird. Das Problem lässt sich am besten anhand eines Beispiels erläutern:

Angenommen, in einer VMware-Umgebung werden vCenter Server und SQL Server auf unterschiedlichen virtuellen Maschinen ausgeführt. Die beiden virtuellen Maschinen werden jedoch auf einem replizierten EMC VPLEX-Device (D) zwischen den beiden Standorten A und B gehostet. Es sei beispielsweise angenommen, dass vCenter Server und SQL Server an Standort A ausgeführt werden. Gemäß der Best-Practices-Empfehlung müssten die I/Os an Device D an Standort B ausgesetzt werden. Bei dieser Empfehlung würden die virtuellen Maschinen mit den vSphere-Managementanwendungen bei einer Netzwerkaufteilung weiter an Standort A ausgeführt.6 Wenn es jedoch an Standort A zu einer vollständigen Unterbrechung des Services kommt, kann die VMware-Umgebung nicht mehr gemanagt werden, weil die Instanz von Device D an Standort B ausgesetzt wäre. In diesem Fall müssten folgende Abhilfemaßnahmen ergriffen werden:

1. Die I/Os an Device D an Standort B müssen wiederaufgenommen werden. Dies kann über die VPLEX-Managementoberfläche erfolgen.

2. Sobald die I/Os an Device D wiederaufgenommen wurden, muss der vSphere Client auf einen der ESX-Server an Standort B zeigen, der Zugriff auf den auf Device D befindlichen Datastore hat.

3. Die virtuelle Maschine, auf der sich die Instanzen von vCenter Server und SQL Server befinden, muss mithilfe von vSphere Client registriert werden.

4. Nach der Registrierung der virtuellen Maschinen muss zuerst SQL Server gestartet werden.

5. Sobald SQL Server uneingeschränkt funktionsfähig ist, muss vCenter Server gestartet werden.

Auf diese Weise würde bei einem Ausfall an Standort A an Standort B eine voll funktionsfähige VMware-Managementumgebung wiederhergestellt.

Das Beispiel oben zeigt eindeutig, dass die Umgebung durch das Hosten von vCenter Server auf einem replizierten VPLEX Metro-Device im Falle eines Standortausfalls die Komplexität der Umgebung erhöht. Diese zusätzliche Komplexität kann auf zwei Arten vermieden werden:

Die Instanzen von vCenter Server und SQL Server müssen auf nicht replizierten EMC VPLEX-Devices gehostet werden. Mit VMware Heartbeat können vCenter-Daten zwischen den Standorten transparent repliziert werden. Dadurch wird ein Recovery-Mechanismus für den Fall eines Standortausfalls bereitgestellt. Diese Lösung ermöglicht ein automatisches Failover von vCenter Server auf den noch funktionsfähigen Standort. Ein manueller Eingriff ist nicht oder so gut wie nicht erforderlich. Weitere Informationen finden Sie in der Dokumentation zu VMware vCenter Server Heartbeat.

Die Instanzen von vCenter Server und SQL Server können sich an einem dritten, unabhängigen Standort befinden, der vom Ausfall des Standorts mit den VMware ESX-Servern nicht betroffen ist. Durch diese Lösung sind die VMware-Managementservices auch bei einer Netzwerkaufteilung verfügbar, bei der die Kommunikation zwischen den EMC VPLEX Metro-Standorten unterbrochen wird.

6 Im Falle einer Netzwerkaufteilung würden die virtuellen Maschinen an Standort B unterbrechungsfrei weiter ausgeführt. Da jedoch vCenter Server an Standort A keine Netzwerkverbindung zu den Servern an Standort B hat, kann die VMware ESX Server-Umgebung an Standort B nicht gemanagt werden. Erweiterte Funktionen wie DRS und Vmotion sind ebenfalls nicht verfügbar.


Kunden sollten die Vor- und Nachteile der einzelnen Lösungen genau analysieren und auf Grundlage dieser Analyse die für ihre Umgebung am besten geeignete Lösung auswählen.

Fazit EMC VPLEX mit dem Betriebssystem EMC GeoSynchrony ist eine SAN-basierte Verbundlösung der Enterprise-Klasse, die über Fibre Channel verbundene Speicher-Array-Pools aggregiert und verwaltet. Diese können sich entweder in einem einzelnen Rechenzentrum oder in mehreren, über die MAN-Entfernung räumlich voneinander getrennten Rechenzentren befinden. Des Weiteren zeichnet sich die Produktreihe durch eine einzigartige Scale-Up- und Scale-Out-Architektur aus. Dank des erweiterten Daten-Cachings und der verteilten Cache-Kohärenz bieten EMC VPLEX-Lösungen eine hohe Workload-Belastbarkeit, automatische Freigabe, Verteilung und Failover von Speicher-Domains sowie lokalen und Remote-Datenzugriff mit planbaren Service-Levels. Ein Rechenzentrum auf der Grundlage einer VMware-Virtualisierungsplattform und der Funktionen von EMC VPLEX sorgt für eine höhere Performance, Skalierbarkeit und Flexibilität. Darüber hinaus können Kunden durch die EMC VPLEX-Funktionen für einen unterbrechungsfreien und heterogenen Datentransfer und das Volume-Management innerhalb synchroner Entfernungen flexible und kostengünstige Cloud-Services an mehreren physischen Standorten anbieten.

Quellennachweise Die im Folgenden aufgeführten weiterführendenen Informationen zu VPLEX finden Sie auf emc2.de und Powerlink:

• Implementierung und Planung von Best Practices für EMC VPLEX – Technische Hinweise • EMC VPLEX Architecture and Deployment: Enabling the Journey to the Private

Cloud TechBook Die im Folgenden aufgeführten weiterführendenen Informationen zu EMC Produkten mit VMware finden Sie auf EMC2.de und Powerlink: • (Verwendung von VMware vSphere mit EMC Symmetrix-Speicher) white paper • EMC Symmetrix VMAX and VMware Virtual Infrastructure - Applied Technology (White

Paper) (EMC Symmetrix VMAX und VMware Virtual Infrastructure in der Praxis) • Using EMC CLARiiON Storage with VMware vSphere and VMware Infrastructure TechBook

(Verwendung von EMC CLARiiON-Speicher mit VMware vSphere und VMware Infrastructure) • Using EMC Symmetrix Storage in VMware Virtual Infrastructure Environments TechBook

(Verwenden von EMC Symmetrix-Speicher in VMware Virtual Infrastructure-Umgebungen) • Virtual Storage Integrator for vSphere Client 3.0 Product Guide (Produkthandbuch zu Virtual

Storage Integrator für vSphere Client 3.0; nur Powerlink) • EMC PowerPath/VE for VMware vSphere Version 5.4 and Service Pack Installation and

Administration Guide (Installations- und Administratorhandbuch zu EMC PowerPath/VE für VMware vSphere Version 5.4 und Service Pack; nur Powerlink)

Die folgenden Informationsquellen befinden sich auf der VMware-Website: • VMware vSphere online library (Online-Bibliothek zu VMware vSphere) • vCenter Server Heartbeat Reference Guide (Referenzhandbuch zu vCenter Server Heartbeat)

http://www.emc2.de/collateral/hardware/white-papers/h6531-using-vmware-vsphere-with-emc-symmetrix-wp.pdf

http://www.emc2.de/collateral/hardware/white-papers/h6209-symmetrix-v-max-vmware-virtual-infrastructure-wp.pdf

http://www.emc2.de/collateral/hardware/white-papers/h6209-symmetrix-v-max-vmware-virtual-infrastructure-wp.pdf

http://www.emc2.de/collateral/software/solution-overview/h2197-vmware-esx-clariion-stor-syst-ldv.pdf

http://www.emc2.de/collateral/hardware/solution-overview/h2529-vmware-esx-svr-w-symmetrix-wp-ldv.pdf

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/Technical_Documentation/300-008-703.pdf

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/Technical_Documentation/300-008-703.pdf

http://pubs.vmware.com/vsp40u1/wwhelp/wwhimpl/js/html/wwhelp.htm#href=welcome/welcome.html

http://www.vmware.com/pdf/heartbeat_55_u2_reference_guide.pdf

Best-Practices-Planung - Data Storage, Converged, … von VMware-Virtualisierungspla ttformen mit...

Documents

Transcript of Best-Practices-Planung - Data Storage, Converged, … von VMware-Virtualisierungspla ttformen mit...