Verwendung von VMware- Virtualisierungsplattformen mit EMC VPLEX

Transkript

1 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

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 Best Practices-Planung 2

3 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 Multipathing und Lastausgleich VMware ESX Server Version 3 und statischer Lastausgleich VMware ESX Server Version 4 und NMP VMware ESX Server Version 4 mit PowerPath/VE Funktionen von PowerPath/VE PowerPath/VE-Management Migration vorhandener VMware-Umgebungen in VPLEX Unterbrechungsfreie Migrationen mit Storage vmotion Migration mit Kapselung vorhandener Devices VMware-Bereitstellungen in einer VPLEX Metro-Umgebung VMware-Cluster-Konfiguration Unterbrechungsfreie Migration virtueller Maschinen mit vmotion Ändern der Konfiguration nicht replizierter VPLEX Metro-Volumes Virtualisierte vcenter Server-Instanzen in VPLEX Metro Fazit Quellennachweise Best Practices-Planung 3

4 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. Best Practices-Planung 4

5 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. Best Practices-Planung 5

6 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. Best Practices-Planung 6

7 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 Best Practices-Planung 7

8 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 Best Practices-Planung 8

9 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. Best Practices-Planung 9

10 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. Best Practices-Planung 10

11 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. Best Practices-Planung 11

12 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. Best Practices-Planung 12

13 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. Best Practices-Planung 13

14 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. Best Practices-Planung 14

15 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 Best Practices-Planung 15

16 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 a001b 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. Best Practices-Planung 16

17 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. Best Practices-Planung 17

18 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. Best Practices-Planung 18

19 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. Best Practices-Planung 19

20 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. Best Practices-Planung 20

21 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 Best Practices-Planung 21

22 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 Best Practices-Planung 22

23 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/Ointensive 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. Best Practices-Planung 23

24 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. Best Practices-Planung 24

25 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 Best Practices-Planung 25

26 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 ) für Server zu sehen. Best Practices-Planung 26

27 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 Best Practices-Planung 27

28 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. Best Practices-Planung 28

29 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. Best Practices-Planung 29

30 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. Best Practices-Planung 30

31 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. Best Practices-Planung 31

32 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 Best Practices-Planung 32